[dendisuhubdy]

Three v0.8.3 fixes from the 2026-10-28 chain-21 network experiment, one commit each.

#151: prover RNG runs in parallel, ProverData is cached

Random columns and Merkle salts in parallel. The hiding PCS's random columns (commit, quotient chunks, ZK randomisation polynomial) and the hiding MMCS's Merkle salts are now ChaCha20 counter-mode streams (vendor/p3-merkle-tree/src/counter_rng.rs):

• Each call takes one fresh 256-bit secret key from the configuration's existing generator. The spin lock is held only for that 32-byte draw, never while values are generated.
• Within the call, (lane = matrix, chunk = 1024 rows) selects the ChaCha nonce, so all chunks fill in parallel.
• Values are sampled exactly as before: StandardUniform rejection sampling over Goldilocks.
• Chunking never depends on the thread count, so a seeded run is reproducible.
• Security rests on ChaCha20 as a PRF under a secret key. That is the same assumption the old generators made (StdRng is ChaCha12; KeyRngV2::from_seed is a keyed Poseidon2 sponge).

Which generators get the parallel path. OS entropy (SaltRng::Fresh) and seed-keyed sponges (proving-config clones) do. Verifier-key label streams (KeyRngV2::from_label) do not: they keep the serial draw bit for bit, so no verifier key moves. tests/verifier_key.rs and tests/key_derivation_v2.rs are unchanged and pass.

Wire format and verifier unchanged. No verifier function is touched. tests/counter_rng.rs::a_new_proof_passes_the_unchanged_v080_verifier_path checks that a new proof passes the admission path v0.8.0 nodes run (non_canonical_proof, auth_header, verify_auth) and that it round-trips canonically.

ProverData cache. ProverData is a pure function of (profile, tier, table heights):

• key_config salts the preprocessed commit from the public label streams.
• The hiding PCS pads preprocessed columns with zeros, not random values.
• The preprocessed columns depend on no program.

So prove_traces takes it from a process-wide LRU (machine::cached_prover_data), shared by every Machine the wallet and rand-prover create:

• 4 shapes, tiers ≤ 16, single-flight.
• Tier-18 msauth data is not kept resident.

tests/prover_data_cache.rs checks that two proofs cost one build, and that both verify on a machine that rebuilds the verifier key. That second check proves the cached commitment is the verifier key's.

Tier-14 bundle proof timing. Production profile, Apple M4 Max, 16 threads, hidden_bundle.rs mixed() case, two passes each:

phase	before	after (first proof)	after (cache warm)
total	19.5 s	11.3–11.7 s	10.1 s
main trace commit	5 875 ms	2 347	2 345
permutation commit	2 412	999	995
quotient eval + chunk LDE (incl. chunk randomisation)	2 757	1 404	1 511
quotient commit	3 521	3 154	3 189
ZK randomisation commit	1 119	461	461
opening + FRI (commit-phase salts)	1 359	387	553
preprocessed commit / ProverData	1 435	1 420	0
LogUp permutation trace gen	1 026	1 027	1 005

Auth proof, tier 10: 1 446 ms → 922 ms.

What is left is mostly Poseidon2 Merkle hashing (parallel) and quotient evaluation.

#152: one decode per admission, faster hex, docs refreshed

• One decode per proof per admission. executor::decode_canonical_shared memoises the canonical decode on the exact bytes: 16 entries, a hit compares the bytes in full, refusals are not kept. These paths all go through it:

  • non_canonical_proof
  • auth_header_of
  • the pinned digest
  • bundle_gas_limit
  • both verifies
  • the call-policy reads

  The ledger and the ConfidentialExecutor trait are unchanged. The ledger still hands each check the bytes in the same order; the decodes meet inside the executor, so no verdict can change. tests/decode_memo.rs shows five reads cost one decode with identical verdicts.

• Faster hex. rand_sendTransaction decodes its body with faster-hex 0.10.1 (MIT; cargo deny check licenses sources bans: ok). rpc::tests::the_hex_body_decodes_as_hex_does checks the result matches hex::decode for both cases, mixed case, 0x, odd lengths and bad characters at lane boundaries.

• Docs. docs/block-space.md, docs/node-hardware.md §2.1 and docs/compute-optimization.md §1.1 had the tier-12 research proof's 16 ms / 838 ms. They now give the issue's chain-21 numbers (73 ms warm, 1.6 s cold, n = 38, M4 Max), the v0.8.3 numbers, and the per-block line.

Admission verify timing. 38 captured chain-21 transactions × 30 warm reps, the node's executor without its verdict cache. The "after" bench clears the decode memo before each rep, so every rep is a fresh admission. Two passes each:

	before	after
warm verify, p50	70.8 / 72.2 ms	61.4 / 62.2 ms
warm verify, p99	73.6 / 76.5 ms	64.4 / 66.5 ms
cold verify (key build), p50	1.55 / 1.59 s	1.53 / 1.56 s
body decode (hex + bincode), p50	18.0 / 18.1 ms	1.2 / 1.2 ms
header checks (non_canonical + auth_header + digest + gas)	9.7 ms	4.4 ms
one admission (decode + warm verify)	~90 ms	~63 ms

#153: faucet means this node can mint

admission::faucet_refusal is now the single test for whether this node can mint. All three must hold:

• the faucet is on;
• the node is a validator;
• its key is in faucet_minters.

rand_status.faucet and rand_getEmission.faucet report exactly that. rand_mint checks it before building anything, and a non-minter's error names the minter set. docs/rpc.md documents the change and has a v0.8.3 changelog entry. Tests:

• admission::tests::the_faucet_is_served_only_by_a_validator_whose_key_is_a_faucet_minter
• node::tests::a_validator_outside_the_faucet_minters_refuses_rand_mint_up_front

Tests

• zkvm, integration suites (Test-profile proof round trips at tier 10 and up): 91 passed, 0 failed, 7 ignored, across 13 suites:
  • counter_rng 7
  • prover_data_cache 1
  • decode_memo 1
  • verifier_key 2
  • key_derivation_v2 6
  • key_cache 2
  • zk 3
  • privacy_floor 4
  • e2e 25 (+6 ignored)
  • executor 24 (+1 ignored)
  • auth_cheating 3
  • logup_blind 2
  • proof_binding 11
• zkvm lib: 44 passed.
• zkvm, mock-cuda: cargo check --features mock-cuda --tests compiles.
• node lib: 772 passed, 1 failed, 5 ignored. The failure is msauth_key::tests::an_exe_in_the_tree_target_falls_back_only_when_opted_in, which asserts that the test binary sits under the source tree's target/. It was built with a shared CARGO_TARGET_DIR outside the tree, and the test's file is untouched here. The faucet, status, emission and hex tests are among the 772.
• clippy -D warnings:
  • randprotocol-node --all-targets: clean.
  • p3-fri, p3-merkle-tree (lib): clean.
  • randprotocol-zkvm: not in the CI lint set and carries pre-existing findings; none are on lines this PR adds.
• cargo deny check licenses sources bans: ok. cargo check --locked: ok. The lockfile diff is only faster-hex, heapless 0.8 and p3-fri → p3-merkle-tree.

Measurement conditions

• Each timed run waited until no rand --rpc http://127.0.0.1:18690 process (the chain-21 experiment) existed.
• A run aborted and retried if the experiment started during it. 10 runs were retried.
• 1-minute load average at the start of each accepted run: 4.5–11.3. Other worktrees' cargo builds were running on the Mac.
• The bench instrumentation (tracing spans, examples/verify_latency.rs, the prover_phase_breakdown test) is from bench/verify-latency and is not in this PR.

Follow-ups

• Port Prover: 41% of a tier-14 bundle proof is single-threaded RNG (hiding columns + Merkle salts); preprocessed commit rebuilt every proof #151 to zkp-circuits research/ and its vendor/p3-*. deploy/sync-zkvm.sh now refuses a re-vendor from a circuits commit that lacks it, and keeps the three new test files.
• rand-zkvm-cuda's own HidingMmcs still draws salts serially. The PCS random columns on that backend are parallel now.

Closes #151
Closes #152
Closes #153

🤖 Generated with Claude Code

https://claude.ai/code/session_01GFs5h141Ct6RTGGrCTQ1vy

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!