reth icon indicating copy to clipboard operation
reth copied to clipboard

Block hash data inconsistency when reading data from a different process that leads to incorrect EVM execution.

Open dvush opened this issue 10 months ago • 1 comments

Describe the bug

I believe that there are 2 issues

  1. When database is opened from a different process, trying to get the last 256 block hashes sometimes fails.
  2. This will cause evm execution for txs that use BLOCKHASH opcode have incorrect execution without explicit fail.

Steps to reproduce

  1. Have reth beta running on the machine
  2. In the separate process open the database and static files storage (ProviderFactory)
  3. For each new block try reading last 256 (except the current one) block hashes

example code to detect that:

    for i in 1u64..=256 {
        let hash = provider_factory.block_hash(current_block_number - i)?;
        if hash.is_none() {
            eyre::bail!(
                "Missing historical block hash for block {}, current block: {}",
                current_block_number - i,
                current_block_number
            );
        }

Node logs

No response

Platform(s)

Linux (x86)

What version/commit are you on?

reth Version: 0.2.0-beta.6 Commit SHA: ac29b4b73

(external process and the node use the same version)

What database version are you on?

Current database version: 2 Local database version: 2

Which chain / network are you on?

mainnet

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

  • [X] I agree to follow the Code of Conduct

dvush avatar Apr 24 '24 09:04 dvush