Skip to content

feat: build, chain-validate, and seed evo snapshot state - #7593

Draft
PastaPastaPasta wants to merge 14 commits into
dashpay:developfrom
PastaPastaPasta:feat/evo-snapshot-chain
Draft

feat: build, chain-validate, and seed evo snapshot state#7593
PastaPastaPasta wants to merge 14 commits into
dashpay:developfrom
PastaPastaPasta:feat/evo-snapshot-chain

Conversation

@PastaPastaPasta

@PastaPastaPasta PastaPastaPasta commented Aug 13, 2026

Copy link
Copy Markdown
Member

Issue being fixed or feature implemented

Stacked on #7592 — every commit below the final one belongs to that PR (rebased onto develop post-#7603, including the review-blocker fixes); this PR adds only the final commit. It will be rebased once #7592 merges.

Part of the AssumeUTXO M4 decomposition (#7579 — see the series map there); stacked on the format-core PR and reviewable as one question: given the v3 format, how does snapshot content get produced from chain state, verified against it, and seeded back into EvoDB? The dumptxoutset/load lifecycle wiring is deliberately absent — it is the next and final PR of the series.

What was done?

Three layers, one commit each:

  1. Build & chain-validate (evo/snapshot.cpp): BuildEvoSnapshot() collects active/safety commitments, rotation snapshots, historical MN-list diffs, and exact score modifiers from chain state; ValidateEvoSnapshotAgainstChain() verifies a decoded snapshot against the block index, deployments, work-block ancestry, rotation horizons, and per-entry seeded modifiers.
  2. EvoDB seeding surface (deterministicmns, llmq/blockprocessor, llmq/snapshot, creditpool, mnhftx, evodb): Seed* writers that store exactly the state reconstruction later reads, without publishing into the shared NORMAL-chainstate caches. GetHashModifier() prefers a seeded exact modifier when the work block's data is unavailable and cross-checks it against recomputation when it is; a mismatch throws SnapshotStateMismatchError, which is unreachable in production until the load integration seeds modifiers (the next PR routes it into the controlled invalid-snapshot path — the plumbing is deliberately not wired here). GetDeterministicMNListHash() switches to the canonical codec hash so completion markers and payload-derived hashes share one identity.
  3. Partial-history support: BuildEvoSnapshot() originally required every enabled LLMQ type to carry exactly signingActiveQuorumCount actives plus full safety and rotation horizons, which a young chain, a freshly activated type, or a rotation type with pre-activation horizon cycles cannot satisfy — dumptxoutset would fail on valid chain state (flagged as blocking by review on backport: assumeutxo M4 — evo snapshot format v3 and LLMQ reconstruction #7579). The builder now emits the history that exists, context-free validation treats parameter counts as maxima, and chain validation requires every carried entry to sit at a derived horizon position while tolerating absent ones. This does not make withholding easier: the completion-time CbTx quorum merkle root pins the active set exactly, historical-diff and modifier tallies must mirror the carried commitments, and completion-time quorum reconstruction establishes sufficiency. Two regression tests (young-chain builder, partial-history validation) fail against the previous exact-count enforcement.

One accepted dev-channel caveat: the GetDeterministicMNListHash() encoding switch means a develop node that activated a snapshot before this change and completes validation after it would fail completion conservatively (marker hash mismatch) and re-sync from the base. No released version carries the old markers.

How Has This Been Tested?

Full unit suite green on a --enable-werror build; the chain-aware test block exercises reconstruction from seeded state only, pre/post-DIP3 validation matrices, rotation bitset/work-list binding, and the two new partial-history regressions. Snapshot suites also run under a --with-sanitizers=undefined,integer build.

Breaking Changes

None on any release branch (see the dev-channel caveat above).

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

PastaPastaPasta and others added 8 commits August 19, 2026 23:15
…e validation

First code PR of the assumeutxo M4 series (dashpay#7579 decomposition): the versioned interchange format for Dash's evo state alongside a UTXO snapshot - canonical serialization, DoS-bounded validating decode, and every validation invariant that needs no chain context. Chain-aware building/validation and dump/load integration follow in the next PRs of the series.

Canonical ordering exists because snapshot content is hashed and cross-checked; per-object serializers are reused through a bounded stream wrapper, with bespoke code only at container level (ordering, bounds, per-entry budgets); decode-time checks deliberately stay out of the trusted hot EvoDB deserializers. AssumeutxoData gains the EvoSnapshotHash anchor the format is pinned by. Includes the aggregate rotation skip-list bound (lists accumulate across every quorum index and wrap the combined MN list), the CRangesSet bounded unserializer, and a vendored-immer shift-base ubsan suppression reachable only through the deliberately hash-colliding test fixtures.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… sign change

The mask for rejecting out-of-range trailing bits promotes through operator~ to a negative int before its implicit conversion back to uint8_t, which clang's implicit-integer-sign-change check reports for every bitset whose size is not a multiple of eight. The evo snapshot unit tests are the first to deserialize such bitsets under the sanitizer job. Same bits, stated explicitly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The codec PR shipped UnserializeBounded without its unit coverage; add the malformed/canonical decode matrix and the round-trip checks from the original series.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The signal map normalizes iteration order, so wire order was unobservable after decode: any permutation of the same signal set was accepted by Unserialize() and reserialized sorted, violating the require_canonical_order contract that every other top-level collection enforces. Require the strictly ascending bit order the serializer emits at the only point where wire order is visible, which also subsumes the duplicate-bit rejection.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…LMQ size

-llmqtestparams and -llmqdevnetparams mutate size, minSize, threshold, and dkgBadVotesThreshold on the CChainParams copy of the LLMQ table, so a commitment produced under a supported non-default quorum size was rejected by the static Consensus::available_llmqs sizing: a larger size exceeded the read bound and a smaller one failed the exact comparison. The context-free layer now enforces an allocation ceiling (EVO_SNAPSHOT_MAX_QUORUM_SIZE) plus signers/validMembers internal consistency; exact sizing already happens in the chain-aware validation, which iterates the effective consensus.llmqs table and calls VerifySizes against it. Count, rotation, and interval fields stay on the static table since the overrides cannot change them.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Validate() bounded only the MNHF map's cardinality: out-of-money-range credit pool amounts, a currentLimit above locked, signal bits at or above VERSIONBITS_NUM_BITS, and signal heights outside [0, base height] all received a canonical snapshot hash. ConstructCreditPool guarantees 0 <= currentLimit <= locked in every deployment branch and consensus admits MNHF signals only for bits below VERSIONBITS_NUM_BITS at their mined height, so enforce exactly those invariants.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PastaPastaPasta and others added 2 commits August 20, 2026 01:21
Unserialize() appended to quorums, historical_mn_list_diffs, and quorum_modifiers and merged into the existing MNHF signal map, so a successful decode into a reused object accumulated state the consumed bytes never contained and could still pass Validate(). Clear the collections up front.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CDeterministicMNList's HAMT hashes proTxHash by its first 8 bytes, so a snapshot supplying up to 100,000 distinct, canonically ordered hashes sharing one 64-bit prefix made every AddMN copy the whole immer collision node: quadratic work and allocation from a single crafted snapshot. Real proTxHashes are uniform txids, where even one shared prefix among 100,000 has probability ~3e-10, so bound collision runs at 8. Enforced on the sorted base list during decoding (before the inserts), on the merged current-plus-additions prefix set before every historical diff application, and as an object-level invariant; the run detector sorts a plain vector so it cannot itself be driven into hash-collision buckets.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PastaPastaPasta and others added 4 commits August 20, 2026 08:33
The context-free CbTx cross-check compared the MN root, active-quorum root, and credit-pool balance but never the height, so a CbTx claiming a different height passed whenever those values were unchanged; the test even verified successfully with nHeight left at zero against a height-500 list. Compare cbtx.nHeight with the snapshot list's height.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The top-level decoder always constructs a fresh local, but direct stream >> data into a reused CQuorumSnapshotData retained prior commitments and rotation entries and could exceed the incoming count bounds. Clear the three vectors up front, matching CEvoSnapshot::Unserialize.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The per-diff operation budget charges only additions, updates, and removals, so a few hundred bytes of zero-operation diff entries could drag a maximum-size list across the whole table-wide history horizon: every entry traverses, sorts, and canonically hashes the full reconstructed list (~19M record serializations from a small input). Charge a cumulative record budget up front in ReconstructHistoricalMNLists. The table-wide horizon sums types no single network enables together, so even a ceiling-sized list under a fully loaded real configuration stays well below half the budget.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Second code PR of the assumeutxo M4 series: BuildEvoSnapshot() collects commitments, rotation snapshots, historical MN-list diffs, and exact score modifiers from chain state; ValidateEvoSnapshotAgainstChain() verifies a decoded snapshot against the block index, deployments, and quorum reconstruction; and the EvoDB seeding surface writes exactly the state reconstruction later reads. The chain-aware implementations live in the header-less evo/snapshot_chain.cpp unit so the codec in evo/snapshot.cpp never includes validation.h (no evo/snapshot -> validation cycle); ChainstateManager code is untouched here and stays in validation.cpp later in the series.

Parameter-derived quorum counts are carried as maxima rather than exact requirements: a young chain, a freshly activated type, or a rotation type whose horizon predates activation legitimately has less history, and requiring the full horizon made dumptxoutset fail on valid chain state (flagged as blocking by review on the original M4 PR). Completeness is anchored by the completion-time CbTx quorum merkle root, the historical-diff and modifier tallies, and completion-time quorum reconstruction; two regression tests fail against exact-count enforcement. GetHashModifier() prefers a seeded exact modifier when work-block data is unavailable and cross-checks it when present; the mismatch error stays unreachable until the load integration seeds modifiers. GetDeterministicMNListHash() switches to the canonical codec hash (dev-channel-only marker-compat caveat in the PR description).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@PastaPastaPasta
PastaPastaPasta force-pushed the feat/evo-snapshot-chain branch from b23a6a5 to 604253c Compare August 20, 2026 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant