Reth vs L2 Geth Integration Consistency Tests

[frisitano]

Overview

We should develop a pattern to perform consistency checks against L2 Geth to ensure correctness.

Design Considerations

L2 geth does not support the engine API and as such we can not use the engine API to drive block production of L2 geth.

Peter Prosal

Generate a chain of test blocks using l2 geth and feed them to reth and assert consistent state root. We can serialize these blocks and run this integration test via CI.

[greged93]

Overview of solutions

The below depicts the various options available to us for diff testing l2geth and Reth.

Option 1: l2geth chain

Proposal by Peter: generate a chain of blocks using l2geth and feed it to Reth.

Pros

• Easy to generate the blocks and to feed to Reth via the import command.
• Can generate blocks containing L1 messages.

Cons

• Harder to generate edge cases or real user behaviour.

Option 2: ef-tests

Use retesteth in order to regenerate all the ef-tests suite with l2geth, getting access to about ~20k tests (minus any tests for unsupported EIP’s).

Pros

• Good coverage in testing, with multiple production edge cases.
• Very limited CI work thanks to the already available ef-tests runner.

Cons

• More dev time to generate the tests.
• Impossible to pass L1 messages (unless Scroll specific tests are written and generated via retesteth).

Option 3: Run individual stages

Similar to the stage test in Reth's CI, run individual stages up to the merkle stage. Any error during execution or merklization, would be caught in the Merkle stage.

Pros

• End to end tests including header and body fetching, senders recovery, account and storage hashing and merklization.
• Wide range of transactions and real user behaviour.
• No test generation needed.

Cons

• Might uncover bugs which aren't relevant to execution/hashing/merklization.

Option 4: Kurtosis and assertoor

Use Kurtosis package from ethpandaops in order to spin up a private Ethereum testnet running both geth and Reth as execution client. Combine with assertoor to run specific tests.

Pros

• Access to fuzzing via a random transaction spammer.
• No test generation needed thanks to assertoor.

Cons

• More dev time to understand how to exactly run kurtosis.
• Requires an engine API (at least for launching tests).
• Impossible to pass L1 messages.

I suggest we go with option 1 as an easy start, creating a chain a few blocks long, from which we can move on to option 3. If we ever require more tests, we can further investigate option 2. Option 4 should only ever be considered if l2geth supports the engine api.

[frisitano]

I think option 1 makes sense in the first instance. I would also like to propose some suggestions for a follower node that leverage the native functionality of reth. These are:

• Use --debug.tip to sync the chain to a specific block hash. This invokes the staged pipeline sync to sync reth to the specified block hash but it will not proceed past this point.
• Use --debug.etherscan which leverages etherescan as a fake CL. We would have to check that scrollscan provides parity in terms of it's API with etherscan to ensure this would work. If it does, it should allow us to follow the chain tip using scrollscan.

[Thegaram]

I suggest prioritizing quick manual tests using --debug.tip first to resolve issues (there likely are some). Then set up CI as the next step.