fix: incremental frontierRootHash to avoid O(N²) on pre-Byzantium blocks

[diega]

PR description

Bonsai full sync hangs indefinitely at the 2016 DoS attack blocks (~2.3M) on mainnet because frontierRootHash() copies the entire accumulator and rebuilds the Merkle trie from scratch on every per-transaction call, giving O(N²) total cost per block.

Commit 1: copy constructor refactor

Replaces the two-phase cloneFromUpdater copy pattern in PathBasedWorldStateUpdateAccumulator with a proper copy constructor chain. Each level copies its own fields with compile-time type safety. This is a prerequisite for commit 2, which adds a subclass-specific field (frontierDirtyAddresses) that needs to be copied correctly.

Commit 2: incremental frontier root computation

Two trackers make the frontier receipt path incremental instead of rebuilding from scratch on every call. They share lifecycle (built once per block, reset on persist()), are paired via FrontierRootHashTracker.StorageRootUpdater, and cover the two layers of the state that the frontier path touches.

FrontierRootHashTracker handles the account trie. The accumulator's commit() override captures addresses from getUpdatedAccounts() and getDeletedAccountAddresses() into a frontierDirtyAddresses set (after super.commit() has populated accountsToUpdate, so every dirty address is guaranteed to resolve). On each frontierRootHash() call the tracker lazily creates the account trie, applies only the addresses dirtied since the previous call, and clears them on success.

FrontierStorageRootTracker handles the storage tries. It keeps each dirty account's storage trie alive and applies only the slot deltas introduced since the last call. Two implementations:

• CachingFrontierStorageRootTracker: the incremental path described above.
• NO_OP: wired in when worldStateConfig.isTrieDisabled() is true. The frontier receipt path is unreachable in that mode (snap sync downloads receipts from peers rather than recomputing them), so this sentinel just makes the invariant explicit and keeps the caching impl branch-free on the config flag.

Why it's safe to operate on the live accumulator instead of copying it: the previous accumulator.copy() was introduced to prevent setStorageRoot() mutations from corrupting the live state. But setStorageRoot() sets deterministic values computed from the trie: the same values that persist() will compute at end-of-block. The frontier path writes no trie nodes to storage. The accumulator is only read and mutated in the same way that persist() would later.

Commit 3: BonsaiTrieFactory

Commit 2 gives the frontier path its own trie lifecycle, but the underlying tries still went through the normal createTrie() path, which returns ParallelStoredMerklePatriciaTrie when parallel computation is enabled. This adds ForkJoinPool scheduling overhead on every per-transaction call without benefit: the frontier path is inherently sequential because each receipt depends on the prior transaction's state root.

This commit introduces BonsaiTrieFactory with a TrieMode enum (ALWAYS_SEQUENTIAL vs PARALLELIZE_ALLOWED) that centralizes the trie implementation decision. The frontier path passes ALWAYS_SEQUENTIAL for both account and storage tries, eliminating the parallel overhead. The normal persist() / block computation path continues to use PARALLELIZE_ALLOWED.

Post-Byzantium receipts use a status code instead of a state root, so the frontier path is only active for pre-Byzantium blocks. Neither commit changes behavior for post-Byzantium blocks or the normal block computation path.

Empirical validation

Full sync of mainnet with Bonsai + --bonsai-parallel-tx-processing-enabled, driven by a Teku 26.2.0 on the same machine via the engine API:

Build	Result
main	Silently stalls at block ~347k inside clearStorage → entriesFrom → TreeMap.put. No OOM, no exception; CPU pegged on the importBlock thread until it quiesces. A thread dump shows ~25 min of accumulated CPU time in that single path.
main + these commits + #10235 (Caffeine Address.hashCache)	Cleared the full 2,283,416–2,700,000 "from Shanghai" DoS window with 0 state-root mismatches and 0 stalls. Throughput drops to ~3–10 Mg/s inside the window (blocks are legitimately heavy) and recovers to 55–80 Mg/s once out, as expected.

The 347k stall is not inside the DoS zone; it's caused by the O(N²) frontier receipt path itself, triggered by any pre-Byzantium block that SELFDESTRUCTs a contract with non-trivial storage (common in the Frontier/Homestead era). The DoS blocks are where the issue becomes spectacular, but the bug is active much earlier. The two fixes are complementary: either one alone leaves one of the two stalls standing; only the combination clears the window end to end.

Verifying the performance improvement locally

The O(N²) scaling can be reproduced by measuring individual frontierRootHash() call times across a simulated block (500 accounts × 20 storage slots, no persist() between calls):

// Setup: create 500 accounts each with 20 storage slots, commit, persist
// ...
for (int i = 0; i < 500; i++) {
    WorldUpdater updater = worldState.updater();
    updater.getAccount(addresses[i]).setBalance(Wei.of(1000 + i));
    updater.commit();
    updater.markTransactionBoundary();

    long start = System.nanoTime();
    worldState.frontierRootHash();
    long elapsed = System.nanoTime() - start;
    // Before fix: elapsed grows linearly with i (O(N²) total)
    // After fix: elapsed stays constant
}

Before this PR: the last call takes 8–11x longer than the first.
After this PR: the last call is the same speed or faster than the first.

The parallel trie overhead can be verified by comparing frontierRootHash() wall time with parallelStateRootComputationEnabled=true vs false using RocksDB-backed storage. Before this PR: ~1.9x overhead. After: ~1.0x.

Fixed Issue(s)

fixes #10155

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests