test(lfm): choose the grinding leg's control by the host's verdict, not nonce + 1 - #954
Merged
Merged
Conversation
…ot nonce + 1 The 09-07 failures of the_emitted_grinding_check_accepts_exactly_the_hosts_nonces fired on the CONTROL arm: under Rpo the recurring find_any winner 0x1400000000000009 has a host-VALID successor 0x140000000000000A (one nonce in 256 is valid at factor 8), so the test asked the emitter to reject a nonce is_valid_nonce accepts. The emitter was right; the control was not a control. The control is now the first host-rejected nonce after the winner, asserted as such before the leg is asked to agree, and the ground nonce is printed. A new deterministic test pins the incident pair and its first rejected successor for Rpo, and walks Rpx and Poseidon to both verdicts, without grinding, asserting the leg's verdict equals is_valid_nonce on every nonce. The emitter and grinding.rs are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The "grinding defect" behind the failures of
lfm::algebraic_commit::tests::the_emitted_grinding_check_accepts_exactly_the_hosts_nonceswas the test's own negative control, not the emitter. The control used
nonce + 1as a"nonce the host would reject". At grinding factor 8 one nonce in 256 is valid, so the
successor of a valid nonce is itself valid with probability 2^-8, and
generate_nonce'sfind_anyre-samples the same few chunk-start winners run after run. Once a recurringwinner has a valid successor, the control fires deterministically for that scheduling
outcome, which looks exactly like a value-specific emitter defect.
Under Rpo with the test's seed at factor 8, the recurring winner
0x1400000000000009hasthe host-VALID successor
0x140000000000000A. The emitter proved it becauseis_valid_nonceaccepts it.emit_grinding_checkandgrinding.rsare unchanged: theemitter follows the host's specification exactly for every nonce below p.
Changes (one file:
prover/src/lfm/algebraic_commit.rs, tests only)is_valid_noncerejects, asserts that rejection before asking the leg to agree, andprints the ground nonce and the control for every run.
the_emitted_grinding_check_agrees_with_the_host_on_the_incident_nonces:pins the Rpo verdicts literally (
…09valid,…0Avalid,…0Brejected), constructsthe arena directly (no grinding) for
0x1400000000000009and+1under Rpo, Rpx andPoseidon, walks forward sequentially until each tenant has shown both verdicts, and
asserts the leg's verdict equals the host's on every nonce.
GRINDING_SEED_CELL,GRINDING_FACTOR,grinding_leg_program,grinding_members,leg_proves) so both tests exercise the same program.Evidence
Mechanism verified by computation: a Python port of RPO from
prover/src/lfm/rpo.rs,checked against the 19-entry Miden
hash_elementsknown-answer table and against allthree observed valid Rpo winners, evaluated under the test's seed at factor 8:
0x14000000000000090x001503362b7f3c960x140000000000000A0x007fac32538532ee0x140000000000000B2^56All 13 probe runs (box B, 09-07) are predicted by the single rule "fail iff the Rpo
winner's successor is host-valid": winners
0x2000000000000025(successor rejected,PASS ×5),
66(successor rejected, PASS ×6),0x1400000000000009(successor valid,FAIL ×2 at the control arm, line 1115).
Direction of the defect, for traceability
The 2026-09-01 handoff described a REJECT-direction defect ("
emit_grinding_checkREJECTSa nonce
is_valid_nonceaccepts"). That claim was an inference from the test failingunder load ("
find_anychanges which valid nonce is sampled, therefore the failure meansREJECT"); it assumed
nonce + 1is always host-rejected and no failing arm was read. The09-07 probe read the arm: the control (ACCEPT). There was one cause, not two, and it was
the control. The handoff's "latent on main" is withdrawn on the same basis:
origin/maincarries neither this test nor the pattern, and the two host-side
wrapping_add(1)tampertests in
crypto/starkare robust by construction (the nonce is absorbed, so any changemoves every later challenge).
Gate
Box A, this commit's content (be808f3d, rebased as efdda93), ×10 under a 64-way spin,
walls 68–76 s. Every run:
Runs 7, 9, 10 also showed
Rpx: nonce 0x1400000000000009 host=false machine=false.Ground/control pairs varied per run (e.g. Rpo
0x42/0x43,0x9000000000000025/…26,0xb000000000000006/…07; Rpx0x4000000000000024/…25,0xc0000000000000b3/…b4;Poseidon
0x200000000000000e/…0f).make linton efdda93 (box A):G_LINT exit=0, all six passes, no error or Diff lines.cargo fmt --allapplied;cargo check -p lambda-vm-prover --testsclean, 0 warnings.