draft: remaining feature branch changes we might want

[p0mvn]

Motivation

Draft holding everything from the VCT feature branch not yet extracted into the split series. Stacked on #411 (split/vct-verify-core) so the diff shows only the remaining work.

Contents (extraction map)

• State — VCT runtime + fast path: vct.rs + embedded mainnet frontier, CommitmentRootSource seam, request/error plumbing, committer fast path, fail-closed reopen, prop tests (next slices per the agreed order).
• Consensus/zebrad wiring: vct_fast_sync config knob, start.rs plumbing.
• Tooling: zebra-checkpoints mainnet-frontier generation + checkpoint-update.yml artifact step.
• Network (independent): hedged head-of-line block download (HedgedBlocksByHash, route_hedge) + blocksync congestion-control spec + zakura testkit cleanup.
• Perf tooling (independent): zebra-replay-bench, make/perf.mk, deploy/runner — already open as feat(perf): add replay benchmark tooling #404.
• Not for extraction: checkpoint precompute (CommitCheckpointPrecomputed) — dropped with perf(chain): precompute note-commitment tree hashing off the committer #387.

Not intended to merge as-is; reference source for the remaining split PRs.

AI Disclosure

• AI tools were used: Claude for PR description and split-plan analysis

[v12-auditor]

Note

Complete: Audit complete. V12 found three issues worth reviewing.

Open the full results here.

Finding	Severity	Details
F-95117	🟠 High	Forged checkpoint block metadata The precomputed checkpoint request path accepts cached block metadata that is not re-bound to the underlying block at the consensus service boundary. CheckpointVerifiedBlock::with_hash stores a caller-supplied hash while deriving only the height and transaction hashes from the block bytes. Router::call routes CommitCheckpointPrecomputed directly to CheckpointVerifier::call_precomputed before applying the normal max_checkpoint_height router cutoff. The checkpoint verifier then validates PoW and checkpoint-chain membership against the cached hash and height, not a freshly recomputed block.hash(). A caller with access to the public consensus service API can therefore submit block bytes under a forged checkpoint hash and put them on the checkpoint path that skips full semantic validation.
F-95118	🟠 High	Poisoned root stalls sync A bad peer-supplied VCT root can wedge checkpoint commit in an in-place retry loop after the note-commitment frontier has been frozen. Header sync persists untrusted BlockCommitmentRoots into the provisional Zakura root store, and PeerSource exposes those rows to the VCT committer. When fast-path verification rejects a supplied root, vct_reject_supplied_root invalidates the root and returns VctSuppliedRootUnavailable. The finalized write loop treats that error as retryable, keeps the same block parked, sleeps, and retries without notifying header sync or otherwise requesting a replacement root. On the next attempt the root is absent while vct_frontier_frozen is true, so the committer refuses legacy recompute and returns the same retryable error again.
F-95119	🟡 Medium	Ironwood root omitted The VCT fast path omits Ironwood from the root source, verification step, handoff frontier, and fast-path persistence. PeerSource reads full BlockCommitmentRoots rows but returns only Sapling and Orchard roots to the committer. verify_commitment_roots folds the supplied roots into the history tree with Default::default() for Ironwood even though Ironwood-onward history leaves use the supplied Ironwood root. At checkpoint handoff, only Sapling and Orchard frontiers are verified, and the committed tip treestate installs a default Ironwood tree. On a Nu7-enabled VCT deployment, the handoff can therefore finalize a default Ironwood state instead of the peer-supplied and header-authenticated Ironwood root.

And one more auto-invalidated finding.

Analyzed 50 files, diff 848f9a8...66320d7.

[p0mvn]

Ref