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

[dvush]

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

[github-actions[bot]]

This issue is stale because it has been open for 21 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.

[0x416e746f6e]

🌷🌷🌷🌷🌷

(trying to see if some flowers could help bring some attention to this issue)

[jenpaff]

@0x416e746f6e could you confirm that the issue is fixed? It seems like with Pectra this will become a non-issue since the last 256 block hashes will be served from state with EIP-2935, feel free to re-open if you're still running into issues here

[0x416e746f6e]

@0x416e746f6e could you confirm that the issue is fixed? It seems like with Pectra this will become a non-issue since the last 256 block hashes will be served from state with EIP-2935, feel free to re-open if you're still running into issues here

@dvush do you know if this is fixed? I am completely out of context

[dvush]

As of today its not fixed but lets check after Pectra upgrade.

On the other hand the issue is a bit deeper and even after Pectra it would not be solved. The thing that is broken here that worked before is ability to open reth db from other process and use it without thinking too much. Even if this particular instance will be fixed I think just trying to fetch headers for blocks in the past would should the same inconsistency again. But reth already moved to the model when "opening db from other process" will not work so I doubt that its fixable long term.