Incorrect block stored in database for MPT mode

[greged93]

Describe the bug

The blocks stored in database during the pipeline syncing for the MPT mode do not contain the correct state root (hence not the correct hash). We should modify the block stored at the end of the Merkle stage.

Steps to reproduce

1. Run cargo run --release --bin scroll-reth-mpt --features "scroll,skip-state-root-validation" --manifest-path crates/scroll/bin/scroll-reth-mpt/Cargo.toml -- node --chain scroll-mainnet --metrics 0.0.0.0:9001 --debug.tip 0xd73993f9db2b3f3cf884a2d0ae8b5e695cfcfe36b856c6ec334334de7f2f2fdb --http --http.addr 0.0.0.0 --http.port 8545
2. Query ETH_RPC_URL=localhost:8545 cast block 100 and ETH_RPC_URL=https://1rpc.io/scroll cast block 100.
3. State roots and block hashes should be different.

Node logs

No response

Platform(s)

Mac (Apple Silicon)

Container Type

Not running in a container

What version/commit are you on?

reth-scroll-cli Version: 1.1.4-dev
Commit SHA: dba9746
Build Timestamp: 2024-12-27T18:08:30.555578000Z
Build Features: scroll
Build Profile: release

What database version are you on?

Current database version: 2
Local database version: 2

Which chain / network are you on?

scroll-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

cargo run --release --bin scroll-reth-mpt --features "scroll,skip-state-root-validation" --manifest-path crates/scroll/bin/scroll-reth-mpt/Cargo.toml -- node --chain scroll-mainnet --metrics 0.0.0.0:9001 --debug.tip 0xd73993f9db2b3f3cf884a2d0ae8b5e695cfcfe36b856c6ec334334de7f2f2fdb --http --http.addr 0.0.0.0 --http.port 8545

Code of Conduct

• I agree to follow the Code of Conduct

[frisitano]

So the problem here is that when we sync we do not overwrite the state root that is provided in the block and as such the state root and block hash represents that of the bmpt instead of the mpt.

Question: If we sync exclusively from the mpt l2geth network peer will we receive blocks with the mpt state root and associated block hash?

[greged93]

I actually don't think so, from Omer:

and it doesn't change block hashes. So the state root you will get from eth_getBlock* family of functions will be the zktrie root.
to get the corresponding mpt root, you need to call scroll_diskRoot(blockNumber or blockHash)

I would suggest to log the state root or store it in database.

[frisitano]

Let's go with the simplest solution first and log the state root.