chore(avm): attacker-simulation tests for shift/unshift row-0 guarantees#22743
Merged
jeanmon merged 1 commit intomerge-train/avmfrom Apr 28, 2026
Merged
chore(avm): attacker-simulation tests for shift/unshift row-0 guarantees#22743jeanmon merged 1 commit intomerge-train/avmfrom
jeanmon merged 1 commit intomerge-train/avmfrom
Conversation
3885099 to
4ac1b78
Compare
Add two AvmVerifierTests cases that simulate a malicious prover injecting a non-zero value into keccak_memory_addr polynomials in positions the proving system is expected to structurally enforce as zero: - ProvingSystemSecurityShiftedLastRowMustBeZero (active): forges addr_shift at row N-1 by overwriting the shifted view with an independent polynomial after AvmProver construction. The PCS shift-consistency check catches the mismatch and verification fails. - DISABLED_ProvingSystemSecurityUnshiftedFirstRowMustBeZero (disabled): same pattern for the unshifted polynomial at row 0. Kept disabled because it requires relaxing two safeguards in polynomials/polynomial.cpp (Polynomial::add_scaled / operator+= and Polynomial::shifted); the test comment documents the exact patches needed and why, for later audit reproduction. Both tests invoke run_check_circuit on a separate ProverPolynomials instance holding the same malicious mutation to demonstrate that every main/lookup/permutation relation still holds on the attacker's trace -- so the verifier's rejection comes from the PCS shift algebra, not from a relation violation.
4ac1b78 to
4a81b9b
Compare
IlyasRidhuan
approved these changes
Apr 28, 2026
Merged
chrismarino
pushed a commit
to chrismarino/aztec-packages
that referenced
this pull request
May 5, 2026
BEGIN_COMMIT_OVERRIDE chore(avm)!: remove hack for bb pilcom to see shifted temp columns (AztecProtocol#22723) chore(avm): attacker-simulation tests for shift/unshift row-0 guarantees (AztecProtocol#22743) END_COMMIT_OVERRIDE
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.
Add two AvmVerifierTests cases that simulate a malicious prover injecting a non-zero value into keccak_memory_addr polynomials in positions the proving system is expected to structurally enforce as zero:
ProvingSystemSecurityShiftedLastRowMustBeZero (active): forges addr_shift at row N-1 by overwriting the shifted view with an independent polynomial after AvmProver construction. The PCS shift-consistency check catches the mismatch and verification fails.
DISABLED_ProvingSystemSecurityUnshiftedFirstRowMustBeZero (disabled): same pattern for the unshifted polynomial at row 0. Kept disabled because it requires relaxing two safeguards in polynomials/polynomial.cpp (Polynomial::add_scaled / operator+= and Polynomial::shifted); the test comment documents the exact patches needed and why, for later audit reproduction.
Both tests invoke run_check_circuit on a separate ProverPolynomials instance holding the same malicious mutation to demonstrate that every main/lookup/permutation relation still holds on the attacker's trace -- so the verifier's rejection comes from the PCS shift algebra, not from a relation violation.