fix(specs): BPO3 inherits BPO2, not Amsterdam; run BPO transition pyspec fixtures

[Marchhill]

Changes

• Reparent BPO3 from Amsterdam.Instance to BPO2.Instance. BPO forks are blob-parameter-only forks chained BPO1→BPO2→BPO3→BPO4→BPO5, with Amsterdam a parallel branch (matching the execution-spec-tests fork lineage). Inheriting Amsterdam wrongly enabled EIP-7928 (and every other Amsterdam EIP) on BPO3/BPO4/BPO5, so BPO2→BPO3 transition blocks demanded a BAL hash and failed with MissingBlockLevelAccessListHash.
• Add regression test ForkTests.Bpo_forks_are_blob_only_and_do_not_inherit_Amsterdam asserting the BPO parent chain and that EIP-7928 stays Amsterdam-only.
• Add the missing Pyspec fixture classes Bpo2ToBpo3AtTime15k/Bpo3ToBpo4AtTime15k (blockchain + engine variants) to Ethereum.Blockchain.Pyspec.Test/Tests.cs. tests-glamsterdam-devnet@v6.1.1 ships for_bpo2tobpo3attime15k and for_bpo3tobpo4attime15k under both blockchain_tests/ and blockchain_tests_engine/, but Tests.cs stopped at Bpo2ToAmsterdamAtTime15k, so these transition fixtures were never run in CI — which is how the fork-lineage bug went unnoticed.
• Add TangerineWhistle/SpuriousDragon blockchain + state fixture classes: an audit of the archive found for_tangerinewhistle and for_spuriousdragon under blockchain_tests/ and state_tests/ also had no fixture classes. Every for_* directory in the archive now maps to a fixture class across all five fixture trees (blockchain, engine, sync, state, transaction).

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

• ForkTests pass, including the new lineage regression test.
• New fixture classes verified locally: 96/96 pass (FullyQualifiedName~Bpo2ToBpo3AtTime15k|FullyQualifiedName~Bpo3ToBpo4AtTime15k); without the reparent these fail with MissingBlockLevelAccessListHash.
• TangerineWhistle/SpuriousDragon classes verified locally: 232/232 pass.
• CI Pyspec chunking needs no changes: default chunks shard per-test by stable-name hash and only exclude the AmsterdamParallel/AmsterdamBatchRead variants by name.

Documentation

Requires documentation update

• Yes
• No

Requires explanation in Release Notes

• Yes
• No

Remarks

The same BPO3(Amsterdam.Instance) bug exists on master, but the fixture classes must not be added there: master pins tests-bal@v7.2.0, which has no for_bpo2tobpo3attime15k/for_bpo3tobpo4attime15k dirs. The spec fix alone can be cherry-picked to master separately.

🤖 Generated with Claude Code

[claude]

Claude finished @Marchhill's task in 3m 36s —— View job

---

Review: BPO3 fork lineage fix

• Read the PR diff
• Examined BPO fork lineage (BPO1–BPO5, Amsterdam) and NamedReleaseSpec replay mechanism
• Verified BPO3 reparent correctness & Apply chain
• Checked regression test & Pyspec fixture additions
• Verified fixture directory convention + fixture version pin

---

Verdict: LGTM — correct, well-scoped bugfix. No Critical/High/Medium issues. ✅

Why the reparent is correct

NamedReleaseSpec builds each spec by replaying the parent chain root→leaf (ReplayAncestors in NamedReleaseSpec.cs:69), so with the old BPO3(Amsterdam.Instance) the replay included Amsterdam.Apply, cumulatively enabling every Amsterdam EIP (7928 BAL, 7954 max-code-size, 2780, the engine-API V5/V6 bumps, etc.) on BPO3/4/5. Reparenting to BPO2.Instance restores the intended blob-only chain Osaka → BPO1 → BPO2 → {BPO3 → BPO4 → BPO5}, with Amsterdam(BPO2) as a parallel branch — matching the EEST fork tree. This is confirmed empirically: the for_bpo2tobpo3attime15k fixtures carry no BAL hash, so they fail with MissingBlockLevelAccessListHash under the old lineage and pass under the new one.

Blast radius is contained to the test path ✅

I checked that the reparent does not affect real-network consensus. Live specs are assembled cumulatively-by-timestamp through ChainSpecBasedSpecProvider (from ChainSpec.Parameters transition timestamps), not from these *.Instance singletons. The NamedReleaseSpec singletons are consumed only via SpecNameParser (EF/pyspec fixtures). No SpecProvider references BPO3/4/5.Instance, so no mainnet/devnet activation path regresses.

Fixture additions verified ✅

• Naming follows the established convention: Bpo2ToBpo3AtTime15kBlockchainTests → for_bpo2tobpo3attime15k (via PyspecTestFixture.cs:129, LoadPyspecTestsStrategy handles the for_ prefix). Consistent with the existing Bpo2ToAmsterdam entry.
• The branch pins tests-glamsterdam-devnet@v6.1.1 (Constants.cs:9), which the PR states ships these dirs under both blockchain_tests/ and blockchain_tests_engine/.
• Regression test Bpo_forks_are_blob_only_and_do_not_inherit_Amsterdam asserts both the parent chain and that EIP-7928 stays Amsterdam-only — a clean guard against reintroducing the bug.

Low / informational (non-blocking)

• There are intentionally two different fork orderings in play, which is worth a note for future readers: the NamedReleaseSpec lineage treats BPO3–5 as parallel to Amsterdam (EEST test-generation model), whereas the real devnet-6 chronological schedule in GethGenesisLoader._blobScheduleForks places Amsterdam(5) before BPO3(6)…BPO5(8). These don't conflict because the live path is cumulative-by-timestamp (so Amsterdam EIPs remain active at BPO3 time on a real chain), but the divergence between the "test lineage" and "wire schedule" is subtle. No action needed — just flagging so the distinction is understood.

Nice catch on the missing CI coverage that let this slip through.

[flcl42]

No comments needed

[github-actions]

EVM Opcode Benchmark Diff

Aggregated runs: base=3, pr=3
Noisy rerun opcodes: DUP4

No significant regressions or improvements detected.