Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Open
ethever opened this issue Aug 17, 2024 · 3 comments
Open
Labels
question Further information is requested

Comments

@ethever
Copy link

ethever commented Aug 17, 2024

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?

toRPC Latest = String "latest"

@ethever ethever changed the title Confusing about BlockNumber of Latest when Symbolic execution a contract Confusing about BlockNumber of Latest when Symbolic execute a contract Aug 17, 2024
@msooseth
Copy link
Collaborator

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?

@msooseth msooseth added the question Further information is requested label Aug 28, 2024
@ethever
Copy link
Author

ethever commented Aug 28, 2024

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
Copy link
Collaborator

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 :)

@msooseth msooseth changed the title Confusing about BlockNumber of Latest when Symbolic execute a contract Confusion about BlockNumber of what is "Latest" when Symbolic executing a contract Aug 29, 2024
@msooseth msooseth changed the title Confusion about BlockNumber of what is "Latest" when Symbolic executing a contract Confusion about "Latest" BlockNumber when Symbolic executing a contract Aug 29, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants