Skip to content

Project Idea: Static Analysis to predict access list #26

@pipermerriam

Description

@pipermerriam

When a client to the Portal Network executes something like eth_call or eth_estimateGas, they will typically be doing so without the actual state data, and thus, they will need to retrieve state on demand from the network.

The simple initial implementation would pause EVM execution each time state data is accessed, retrieve that data from the network, and then proceed with execution. This approach suffers from all of the data needing to be retrieved one piece at a time. We can do better.

Given a transaction payload, some collection of known state data (which might be empty), we should be able to predict a significant amount of the accounts and storage slots that will be accessed.

Lets pretend we have such a function:

def divine_access_list(transaction, known_state) -> AccessList:
    ...

At the very beginning of the transaction we can "predict" that the tx.sender and tx.to accounts will be needed, along with the bytecode for the tx.to account. Once these values have been retrieved, we can call the function again, but this time with known_state containing this account information and bytecode.

Now, suppose that the bytecode was something like:

PUSH1 0x00 SLOAD ...

From this, we can perform some very simple static analysis to know that we will be needing the value at storage slot 0.

This logic could then be run in a loop that looked something like this.

# start with zero state
known_state = []

while True:
    # figure out which state we're able to determine that we need
    state_data_to_retrieve = divine_access_list(tx, known_state)

    # if we cannot determine any additional state needs from static 
    # analysis then maybe we're at a dead end and can only determine 
    # the remaining needs via execution
    if not state_data_to_retrieve:
        break
    
    # fetch the state from wherever we're getting it from and 
    # merge it in with the state we may already have
    new_state_data = retrieve_state(state_data_to_retrieve)
    known_state.merge(new_state_data)

This could be run alongside the EVM execution, passively determining values we are going to need and retrieving them, while the other process actually performs the EVM execution.

So the project would be to write a version of this predictive engine, and then to do some experiment with real transactions on mainnet to measure how effective it can be at predicting what state will be needed during execution.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions