search

ethereum / hevm

symbolic EVM evaluator
https://hevm.dev
GNU Affero General Public License v3.0
225 stars 46 forks source link

Confusion about "Latest" BlockNumber when Symbolic executing a contract #528

Open ethever opened 3 weeks ago

ethever commented 3 weeks ago

Confusing about BlockNumber of Latest when Symbolic execution a contract. What happens when i symbolic execute a contract that consuming a lot of time (span lots of blocks), the interpreter fetching the latest state from rpc. But from the point of contract, those state may not be consistent? https://github.com/ethereum/hevm/blob/eee947de40c62ec7c57a8b7288d7844b82d2415a/src/EVM/Fetch.hs#L70

msooseth commented 2 weeks ago

Sorry, this is a bit unclear to me. Can you maybe clarify a bit? I may be missing something to fully grasp what you mean. Can you maybe give an example?

ethever commented 2 weeks ago

I found in https://docs.alchemy.com/reference/eth-getstorageat that the third params of eth_getStorageAt stands for getting latest proposed block when be set to latest. As to blockchain, the blocks are chain together in remote rpc node: Block0 --> Block1 --> Block2 --> ... --> BlockN -->.... And then the state changing becomes: State0 --> State1 --> State2 --> ... --> StateN --> ....

Now supprots I run hevm symbolic --address some_live_address_onchain on BlockN. The hevm will fetch the latest storage at the contract some_live_address_onchain at BlockN to perform some execution. Unfortunately, however, the contract some_live_address_onchain contains some complex logic that will take hevm a significant amount of time to execute, this can take up to 100 blocks' worth of time. Finally, supports again the hevm have to perform some eth_getStorageAt action to end the execution according to the logic in some_live_address_onchain contract. But this time hevm fetch storage at BlockN+100. From BlockN to BlockN+100, the storage of some_live_address_onchain will probably be changed, causing a non-consistent at the view of execution some_live_address_onchain contract.

Yet, I think the semantic of latest param at rpc call should be latest M, but with M be a specified blocknumber being fetched at the start of the execution(hevm symbolic).

Or what mistake I made?

Something about latest&eth_getStorageAt: https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_getstorageat https://ethereum.org/en/developers/docs/apis/json-rpc/#default-block

msooseth commented 2 weeks ago

Oh, I see. Yeah, this is a "time of check time of use" issue kinda, see TOCTOU: https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use

OK, I'll see what I can do :)