igneum/docs/plans/proving-v1.md
igneum-labs 55ea10cc26 Proving v1: prover on by default, the aggregated segment record, host modes chain, aggregate and verify-segment, the app's aggregator step, spec 7.8, the fast-time harness and the coverage tool
Step 1: app/igneum-app/src/provedefault.rs decides once per install (NVIDIA 12 GB or more, WSL2 answering on
Windows, Linux native, Apple silicon off until measured), never switching an explicit on back off; the Settings
switch line and the tile line say why (5 unit tests). tools/proving-v1/pc2-prover-cost.ps1 is the PC 2 job
(5 min mining alone, 5 min with the prover, GPU memory and host RAM peaks, the sp1-gpu-server's SM targets).

Step 2: the host gains --mode chain (consecutive fixtures, each block aggregated with the previous block's
proof by recursion), --mode aggregate (the live aggregator over shard proof files, a run of blocks in one
process) and --mode verify-segment (the node's verifier against the pinned aggregator key); the app's prover
loop gains aggregate_once (spec 7.8). Eight consecutive live fixtures (blocks 81046 to 81053, node 1's export
at tip 81076) under proving/fixtures/chain/. tools/proving-v1/pc2-chain.ps1 is the PC 2 job (held).

Steps 3 and 4: tools/proving-v1/coverage.mjs (the proven-block share and the on-chain latency from one node's
RPC), tools/proving-v1/net.mjs (the fast-time 3-node harness on 29950+ with the known-finished and
known-failed cases of the chain rule and the unproven rule), the four proving_v1 fields in
infra/fast-time/override-60x.json. Spec 7.8, the 7.4 rows, the 5.3 sentence, docs/plans/proving-v1.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-05 20:21:04 +00:00

8.4 KiB

Proving v1: segment records, the chain rule, the unproven rule; the 0.3.11 rollout

5 October 2026, from 18:55 UTC (the project lead: "open the proving round asap"). Branches proving-v1 in the main repository (worktree /Users/joshm/Projects/igneum-wt-proving-v1, from master a93199a) and in the fork (vendor/igneum-node-pv1, from release-0.3.6 a24ab01a; to be rebased onto the 0.3.10 tip when it lands on release-0.3.6). Status words follow docs/spec/00-overview.md 0.2. Every number here is in docs/bench-log.md with its command. Nothing ships from this plan: it delivers branches, numbers and the rollout for 0.3.11.

The gap this closes

The litepaper says every block is proven within about a minute. Proving v0 (proving-v0.md, spec 7.7) proves some shards: one prover (PC 2's RTX 5090) takes the newest shard assigned to it, about one shard every 30 s, so under a tenth of blocks carry a proof; consensus does not require one; the aggregator guest (design 5.3) runs on fixtures only. Proving v1 adds the aggregated segment record on chain (spec 7.8), the chain rule (segment N's record verifies N-1, inside the proof by recursion), the unproven rule (a segment nobody proves in T seconds pays nothing and may be skipped), the prover on by default on every machine that can prove, and the measurements that say how many cards cover the chain.

The round, step by step

Step What State
1 Prover on by default (app/igneum-app/src/provedefault.rs, engine.rs apply_prove_default): on at install when the machine can prove (NVIDIA card with 12 GB or more; WSL2 answering on Windows; Linux native; Apple silicon off until measured), never switching an explicit on back off; the Settings switch line and the tile line say why. Unit tests (5). The cost of proving on a mining machine: PC 2 job prover-cost-pc2-pv1 (5 min mining alone, 5 min with the prover, the GPU memory peak and the host RAM peak, the sp1-gpu-server's compiled SM targets) Implemented; the measurement is HELD (coordinator, 19:00Z): PC 2's RTX 5090 worker has been exiting on a pack seed mismatch since 18:35Z, so the first run's "mining alone" is 0 MH/s and void; re-run after the go
2 Segment aggregation: SegmentRecord (586 bytes, the aggregator guest's 340-byte statement inline), section IGNS before the shard section, p2p message 72 at protocol 14, the native block statement and the veto, the credit split (split_pool_credit), the payout at the carrier, igneum-miner sign-segment-record, the RPCs; host modes chain (consecutive fixtures), aggregate (live shard proofs from the pool, a run of blocks in one process) and verify-segment (the node's verifier, pinned aggregator key); the app's aggregator step (prover.rs aggregate_once) Implemented, unit-tested (consensus core 2 new tests, exec 2, params 1); the GPU measurement (N = 2, 4, 8 blocks on PC 2) is HELD with step 1; the Mac CPU run of --mode chain over 2 live blocks is the known-finished case
3 Coverage: tools/proving-v1/coverage.mjs (the proven-block share and the on-chain proof latency over a window from one node's RPC, the live page beside it) Implemented and run for 3 min (below); the 30-min window waits for the fleet
4 The chain rule and the unproven rule in consensus behind proving_v1_activation_daa (spec 7.8 items 2, 6, 7); unit tests; the fast-time 3-node harness tools/proving-v1/net.mjs (ports 29950+, suffix 956, trust mode) with the known-finished and known-failed cases Implemented; the harness run waits for the Mac build of the fork (vendor/igneum-node/target-pv1)
5 This plan: the rollout for 0.3.11 and the project lead's decisions Written below

Numbers (every one from docs/bench-log.md, "proving v1")

(filled as the measurements land; see the bench log entries of 5 October 2026 named "proving v1 ...")

The rule, in one paragraph (spec 7.8)

From the first chain block A at or above proving_v1_activation_daa, chain blocks form fixed segments of N (proving_v1_segment_blocks). A segment record carries the aggregated proof of the segment's last block, whose chain_len says how many consecutive blocks the recursion attests. Every node checks the record's statement against its own native block statement (every field but the provers commitment and chain_len), the chain rule (a proof that does not chain to the previous segment, chain_len = N, is valid only for the first segment or after an unproven one) and the deadline (T = proving_v1_unproven_daa DAA seconds after the segment's last block; a record carried later pays nothing). The pool credit of every attested block splits: proving_v1_aggregator_share_bps to the aggregator, the rest to the shards as v0. A block is never invalid for lack of a proof; the mandatory rule (spec 7.8 item 10) is Designed and off, with no switch yet.

Rollout for 0.3.11 (the digest handshake pattern of 0.3.9 and tonight's switches)

The switch moves the consensus digest only once it is set (consensus_digest: the four v1 fields enter the hash when proving_v1_activation_daa != never), so a 0.3.11 node on the unswitched devnet keeps the 0.3.10 digest and the rolling upgrade does not partition the network. The order, each step with its check:

  1. Rebase and build. Fork proving-v1 rebased onto the 0.3.10 tip on release-0.3.6; the six node suites and the app tests as PC 2 build jobs; the Mac node and the Windows exes by the Mac cross-build; the Linux node by PC 1; the HiveOS package republished from the same fork commit (rule: the HiveOS package carries the node of the release commit and the same override object, infra/hive, as 0.3.9's hive-sync-039o checked it).
  2. Pinned guests. The guest ids do not change in this round (shard 0x2b1a81cb413236cf063077b46ed3111628f6c41036bcf6e23ee4cbbf5679ef7a, aggregator 0x474678f35f7545db28055d5e5bbc308231d84a5a072202087a2a8d5b09123896, pinned 2026-10-05T16:20:38Z): the aggregator guest already carried the chain rule and only the HOST gained modes. So no provers-off drain is needed for the guests; --mode id on every machine after the update must print the same two ids, and the node now reads them at start (program_ids: IGNEUM_PROOF_PROGRAM_IDS or the verifier's --mode id) and names them in the native statement.
  3. Hand nodes and the seed first, with the UNCHANGED override object (the digest stays): observer, node 1, the seed on the 0.3.11 node; peers back within 20 s; the proving v1: segment records from DAA score never line in each log.
  4. Manifest and apps. publish-manifest.sh --version 0.3.11 with the unchanged object; update-now to every app; every machine on 0.3.11 with a DAA score and a hash rate (the watcher takes the commit as an argument). The app's prover default applies at the first start on 0.3.11: every NVIDIA machine with WSL2 goes on; the log line prover default: ... on each.
  5. The switch. When every node runs 0.3.11: publish the object with proving_v1_activation_daa = H (24 h ahead, the rule of fee-switch-devnet.md) and the three parameters; read the expected digest on a scratch node first; update-now; the hand nodes and the seed with the same object; the digest sweep; the first paid segment record (igneum_getSegmentRecords) and igneum_getProvingStatus.v1.segmentsInWindow after H.
  6. The mandatory rule stays off: no switch exists for it yet; it gets one when the measured share is one.

What the project lead must decide

Decision Proposed Why
proving_v1_segment_blocks (N) 4 the N = 2, 4, 8 measurement on the 5090 decides; 4 keeps a record every 4 s at 1 block/s and the recursion cost per block constant
proving_v1_unproven_daa (T) 600 equals the 600-block record window of v0: nothing is payable for a segment after it either way; the fleet's measured latency (p99) must sit well inside it
proving_v1_aggregator_share_bps 1,000 (a tenth) the aggregation is one recursion per block, far cheaper than the shards; a tenth pays a second role without starving the shard provers; it is a consensus parameter in the digest
proving_v1_activation_daa (H) 24 h after the 0.3.11 publish the fee-switch rule
Aggregator sortition none in v1 (first valid record wins) design 5.3's VRF draw is O-7.3; with one or two aggregators on the devnet a draw changes nothing yet
Apple silicon default off until the GPU prover is measured on a Mac