Context
client/geth is the only client that supports --binary-trie / TrieModeBinary (others reject at parse via internal/clientpolicy/policy.go). The binary-trie codepath has good unit-test coverage (generator/grouped_emission_test.go, generator/binary_stack_trie.go, internal/entitygen/canonical.go golden constants), but no end-to-end test drives the geth-fork binary against a binary-trie DB and verifies it boots + serves RPC.
This is structurally separate from the MPT cross-client invariant — binary-trie state root is fundamentally different from the MPT root, so a bintrie CI job must NOT participate in the existing cross-client genesis-root aggregator.
Proposed design (geth-only)
- New test
TestE2ESuiteWithBinaryTrie in client/geth/e2e_test.go. Mirrors the existing TestE2ESuite but sets TrieMode: generator.TrieModeBinary + BinaryTrie: true when calling WriteGenesisBlockFull. Pins against a new CanonicalOsakaBinaryTrieRoot constant.
- New workflow job
geth-bintrie-suite in .github/workflows/ci.yml, parallel to (not in matrix with) the existing geth-suite. Uploads geth-bintrie-result.json — explicitly excluded from the cross-client MPT genesis-root aggregator.
- First CI run will fail with
got X; want <unset>; copy the printed hash into the constant in a follow-up commit.
Files to add/modify
.github/workflows/ci.yml — new geth-bintrie-suite job (template per existing cgo-suite composite action structure, but geth-only and no Docker — geth runs in-process via oracle build tag).
client/geth/e2e_test.go — new TestE2ESuiteWithBinaryTrie (~80 LoC).
client/geth/golden_test.go — new TestGethGoldenStateRootBinaryTrie.
internal/entitygen/canonical.go — new CanonicalOsakaBinaryTrieRoot constant.
- Optional
Makefile — new test-geth-bintrie-suite target.
Verified prereqs
client/geth/writer.go:179, 224, 232 already accept binaryTrie bool. The geth-fork submodule supports the path. No upstream work needed.
Out of scope
- Binary-trie support for besu/nethermind/reth. They reject
--binary-trie at parse today; landing it would be substantial per-client work.
Context
client/gethis the only client that supports--binary-trie/TrieModeBinary(others reject at parse viainternal/clientpolicy/policy.go). The binary-trie codepath has good unit-test coverage (generator/grouped_emission_test.go,generator/binary_stack_trie.go,internal/entitygen/canonical.gogolden constants), but no end-to-end test drives the geth-fork binary against a binary-trie DB and verifies it boots + serves RPC.This is structurally separate from the MPT cross-client invariant — binary-trie state root is fundamentally different from the MPT root, so a bintrie CI job must NOT participate in the existing cross-client genesis-root aggregator.
Proposed design (geth-only)
TestE2ESuiteWithBinaryTrieinclient/geth/e2e_test.go. Mirrors the existingTestE2ESuitebut setsTrieMode: generator.TrieModeBinary+BinaryTrie: truewhen callingWriteGenesisBlockFull. Pins against a newCanonicalOsakaBinaryTrieRootconstant.geth-bintrie-suitein.github/workflows/ci.yml, parallel to (not in matrix with) the existinggeth-suite. Uploadsgeth-bintrie-result.json— explicitly excluded from the cross-client MPT genesis-root aggregator.got X; want <unset>; copy the printed hash into the constant in a follow-up commit.Files to add/modify
.github/workflows/ci.yml— newgeth-bintrie-suitejob (template per existingcgo-suitecomposite action structure, but geth-only and no Docker — geth runs in-process viaoraclebuild tag).client/geth/e2e_test.go— newTestE2ESuiteWithBinaryTrie(~80 LoC).client/geth/golden_test.go— newTestGethGoldenStateRootBinaryTrie.internal/entitygen/canonical.go— newCanonicalOsakaBinaryTrieRootconstant.Makefile— newtest-geth-bintrie-suitetarget.Verified prereqs
client/geth/writer.go:179, 224, 232already acceptbinaryTrie bool. The geth-fork submodule supports the path. No upstream work needed.Out of scope
--binary-trieat parse today; landing it would be substantial per-client work.