feat(state): verify VCT roots during header sync (move verification off the committer)

[p0mvn]

Reapplication of #366 onto ironwood-main (rebased over the #444 squash-merge of roman/vct-config). The original PR was written against the old feat/pre-release-main feature branch; this ports the same change to the current branch structure.

Goal

Make header-sync commit the single authoritative verify+fold for peer-supplied commitment roots, so a lying peer is caught early and attributably at the network boundary (scored + refetched), and the finalized committer no longer needs the successor at all (no successor look-ahead, no await-successor park, no deadlock).

What changed vs the original #366

The base branch evolved, so the port adapts rather than replays:

• The original's first commit (parts-based ZIP-221 leaf building) is dropped: it was already merged into this lineage in a refined struct-based form (feat(chain): add history tree parts APIs #439, HistoryTreeBlockParts). The verifier folds via push_from_parts(network, HistoryTreeBlockParts { .. }) instead of the original's many-argument signature.
• Peer-supplied roots live in the unified commitment_roots_by_height column family on this branch (with per-height tx counts and auth_data_root already carried), so the original's separate zakura_header_commitment_roots_by_height CF does not exist here. Only the new zakura_header_frontier_tree CF is added.
• The Ironwood pin uses this branch's Nu6_3 activation (verify_supplied_ironwood_root_below_nu6_3 / InvalidPreNu6_3IronwoodRoot), not the original's Nu7 variant.
• The committer's successor machinery on this branch had grown a VctWriteManager look-ahead and a prevalidation/dedup cache; both are removed along with NextVctBlock and the commit_finalized(_direct) successor threading.

Commits

1. feat(state): verify supplied roots at header-sync commit (frontier MMR) — extract a header-driven header_commitment_is_valid_for_chain_history core; add verify_supplied_roots_from_parts + the sub-Heartwood/sub-NU5/sub-Nu6_3 direct checks; persist a running header-frontier ZIP-221 MMR (new zakura_header_frontier_tree CF) that each committed range's roots are folded into and verified against the header commitments; reject a bad range with CommitHeaderRangeError::InvalidCommitmentRoots.
2. feat(state): move VCT verification to header sync; committer trusts pre-verified roots — map InvalidCommitmentRoots → InvalidRange peer scoring in the header-sync driver; drop the committer's successor look-ahead and the write-worker await-successor park; remove the successor threading from commit_finalized/commit_finalized_direct. The committer re-checks its own header commitment and folds the (already header-sync-verified) roots.
3. test(state): rework VCT tests for header-sync verification; remove dead successor machinery — remove the successor/dedup machinery and its tests (deferral, two dedup tests, poisoned-root refill); update the wrong-root test to the one-block-lag expectation (the tip case is header-sync's job); simplify VctState/VctCommitState/VctWriteManager; regenerate CF snapshots.

Test evidence

• cargo check --workspace --all-targets clean
• cargo fmt --all -- --check clean
• cargo clippy -p zebra-state -p zebrad --all-targets clean
• cargo test -p zebra-state: 289 passed, 0 failed, 2 ignored

AI disclosure

Reapplied and adapted with Claude Code (Fable); the contributor is the responsible author.

[v12-auditor]

Note

Complete: Audit complete. V12 found one issue worth reviewing.

Open the full results here.

Finding	Severity	Details
F-95471	🟠 High	Unauthenticated range-tip roots A Zakura peer controls the tree_aux_roots carried in a header-range commit, and the driver forwards those roots into state for CommitHeaderRange. The new header-root verifier checks each header commitment against the tree before folding that same height’s supplied roots, and its own documentation states that a range [start..=end] authenticates only roots through end - 1. The header-range batch nevertheless treats the returned tree as verified state and stores root rows for every supplied height, including the unauthenticated range tip. The finalized VCT fast path then trusts those header-sync roots for the current block after the diff removed successor lookahead, folds them without waiting for H + 1, and writes the supplied roots as shielded anchors and history-tree state. A malicious peer can therefore place a bad root at the last height of a committed range and have it consumed before any successor header authenticates it.

And two more auto-invalidated findings.

Analyzed 12 files, diff 2debd4f...0a15345.