-
Notifications
You must be signed in to change notification settings - Fork 48
Description
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.