ethereum / ethereum/execution-specs
Genesis state-root computation is coupled to the MPT across the testing tooling
- Dominant language
- Python
- Stars
- 1.2k
- Forks
- 505
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 116
Description
Genesis-state-root computation is coupled to the Merkle Patricia Trie in several places
across the testing tooling. PR #3246 fixed one of them because it was actively producing
wrong fixtures, but the general problem deserves a designed solution rather than another
point fix.
### What #3246 changed
Fixtures for the experimental `BinaryTree` (EIP-8297) fork carried a genesis root no client could reproduce. The fix routes it through `spec_calc_state_root(alloc, fork)`, matching what `specs/blockchain.py` already did.
That was in scope because it was a live defect on the fill path. The wider coupling was not.
### What remains
Two `execute`-path sites still compute a genesis root without resolving the fork's provider:
- `packages/testing/src/execution_testing/cli/pytest_commands/plugins/execute/rpc/hive.py:153`
- `packages/testing/src/execution_testing/cli/pytest_commands/plugins/execute/eth_config/execute_types.py:371`
(this one has `self.config.fork()` in scope, so it could route today)
### The broader concern (raised by @kevaundray on #3246)
> I found that on the CL, there is a coupling to the MPT because the CL hardcodes a EL block
> -- I'm wondering if doing it this way will make us need to change more tooling
That is the part worth designing rather than patching. If the consensus-layer side assumes an
MPT-shaped EL genesis block, then threading the provider through each EL-side call site may
not be sufficient, and may not even be the right shape — we could end up with provider
resolution scattered across the tooling while the actual blocker sits elsewhere.
### Proposed next step
Investigate before changing anything further:
1. Enumerate every genesis-root computation across `fill`, `execute`, hive integration, and
any CL-facing fixture or genesis generation.
2. Establish concretely where the CL hardcodes an EL block and what it assumes about it.
3. Decide whether the right fix is threading the fork through each site, a single
provider-aware genesis builder, or something upstream of both.
4. Then implement, rather than continuing to fix sites one at a time as they are found.
Filed as a follow-up to #3246 so that PR can land on its correctness merits; no work here
blocks it.
Contributor guide
Research direction
Start with the two remaining execute-path sites in packages/testing/src/execution_testing/cli/pytest_commands/plugins/execute/rpc/hive.py:153 and execute/eth_config/execute_types.py:371, then compare them with the fix in #3246 and specs/blockchain.py. Enumerate genesis-root computations across fill, execute, hive, and CL-facing fixture generation, and identify the CL assumption about the EL genesis block. Done means a chosen design is documented and the affected paths consistently follow it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- testing, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100