Duplicate finalized frame numbers in app shard consensus

[dazthecorgi]

Summary

App shard consensus can produce duplicate frame numbers which are silently dropped.

Details

Simplex can enter view V+1 after V is notarized and certified but before V’s finalization has been applied to the shard clock store. Because the app proposer ignores the consensus parent and reads that store, V+1 can reuse V’s app frame number.

The worker persists the duplicate, skips materializing an already-seen number, then still republishes it and emits coverage at crates/quil-engine/src/app_engine.rs:2429. Archives silently ignore it at crates/quil-engine/src/archive_ingest.rs:135. A same-height clock-store entry may also be overwritten.

Repro

I added a repro in this commit: dazthecorgi@7a15239

[blacks1ne]

Fix proposed in #593.

The PR makes the Simplex-selected parent authoritative for app-shard proposals, validates height and parent linkage before voting, and prevents stale, conflicting, or replayed finalizations from being persisted and emitted as new work. The linked three-prover reproduction now produces a strictly consecutive, uniquely numbered chain, and the Linux/amd64 node build passes.

Colleagues familiar with app-shard Simplex and finalization semantics: reviews would be appreciated, particularly around the parent-link invariants and replay handling.

[blacks1ne]

@dazthecorgi — thanks for the comments on #593; you were right that it was suboptimal, and the two you flagged as attacker-controlled turn out to be a permanent halt.

The consensus digest is Poseidon(header.output) and commits to nothing else — not frame_number. Channel-3 ingress validated nothing before recording digest → frame_number, so any peer can pair a real frame's output with an arbitrary height and land it on that frame's digest. propose then builds at that height, verify derives the child's expected height and parent_selector from it and rejects the honest child, and since a nullified view doesn't advance the Simplex parent the poison is permanent. The global seam has the same primitive, and its channel 3 isn't even sender-attributed.

Reproduced rather than argued — two e2e tests that fail pre-fix and pass after: the app shard dies after frame 1 (120s timeout), the global chain after a single forged message (60s).

Fix: ingress stores block bytes and nothing else, and the activation closure no longer holds the proposer, so it's structural rather than a rule. Your "fall back to the store" suggestion is in too, but identity-checked — only when the committed head's identity is the consensus parent, since the unconditional form is what caused this issue.

Two things I left alone and would value your view on: your extra-view-per-frame point stands, but the fix looks like a design change (materialize-on-notarize with rollback, or frames committing post-state roots) rather than a revert; and separately BlockStore::put replaces unsealed candidates, so a peer can swap a mutated body under the same digest before verify reads it and nullify a view repeatably. Under all of it: the consensus digest isn't a commitment to the block.

PR: #607. Global-seam counterpart filed as #608. Review very welcome.