Ohadn/verify program builtin without extra component#1724
Conversation
ohad-nir-starkware
requested review from
anatgstarkware and
gilbens-starkware
as code owners
ohad-nir-starkware
changed the base branch from
main
to
ohadn/verify_program_builtin-deployment-padded
ohad-nir-starkware
force-pushed
the
ohadn/verify_program_builtin-without-extra-component
branch
from
e9ef36b to
fb85506
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
ohad-nir-starkware
force-pushed
the
ohadn/verify_program_builtin-without-extra-component
branch
from
fb85506 to
2e34cfc
Compare
stwo_cairo_prover/crates/cairo-air/src/components/constraints_regression_test_values.rs
Show resolved
Hide resolved
ohad-nir-starkware
force-pushed
the
ohadn/verify_program_builtin-without-extra-component
branch
from
2e34cfc to
34a0c28
Compare
| let curr_program_24 = eval.get_preprocessed_column(ProgramColumn::new(24).id()); | ||
| let curr_program_25 = eval.get_preprocessed_column(ProgramColumn::new(25).id()); | ||
| let curr_program_26 = eval.get_preprocessed_column(ProgramColumn::new(26).id()); | ||
| let curr_program_27 = eval.get_preprocessed_column(ProgramColumn::new(27).id()); |
There was a problem hiding this comment.
ProgramColumn log_size may mismatch verify_program log_size
High Severity
ProgramColumn is always log_size 12 (MAX_PROGRAM_LOG_LEN), but verify_program's log_size is variable (derived from program segment length). When pad_program_segment is false, the component's domain can differ from the preprocessed column's domain, causing the polynomial evaluations to return incorrect values at the verifier's OODS point. The old design avoided this via a logup cross-component lookup between the variable-size verify_program and the fixed-size program_component.
ohad-nir-starkware
force-pushed
the
ohadn/verify_program_builtin-without-extra-component
branch
5 times, most recently
from
83f894b to
48615a5
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| let program_length = relocatable_memory[0].len(); | ||
| let padded_program_length = 1 << MAX_PROGRAM_LOG_LEN; | ||
| // Pad the program segment (segment 0) to constant size. | ||
| let padded_program_length = program_length.next_power_of_two(); |
There was a problem hiding this comment.
Small programs panic due to insufficient SIMD padding
Medium Severity
Changing padded_program_length from the fixed 1 << MAX_PROGRAM_LOG_LEN (4096, log_size=12) to program_length.next_power_of_two() means small programs can produce a log_size smaller than LOG_N_LANES (typically 4). For example, a program with 8 entries yields log_size=3, which fails the assert!(log_size >= LOG_N_LANES) in verify_program::ClaimGenerator::new. The old fixed padding always guaranteed log_size=12, safely above the SIMD minimum.
Additional Locations (1)
ohad-nir-starkware
force-pushed
the
ohadn/verify_program_builtin-without-extra-component
branch
from
48615a5 to
c955424
Compare
1 participant
Note
Medium Risk
Medium risk because it changes AIR/witness generation and lookup composition for
verify_program, which can affect proof correctness and compatibility with existing traces.Overview
Removes the separate
program_componentand rewiresverify_programto read program limbs directly from preprocessedProgramColumns, shrinking its trace width and interaction trace shape.Updates prover/witness plumbing and CASM registry metadata accordingly (component lists, claimed sums, lookups, regression expectations), and changes program padding from a fixed
MAX_PROGRAM_LOG_LENsize to dynamic next power-of-two padding in both the adapter program segment and the global preprocessed program table.Reviewed by Cursor Bugbot for commit c955424. Bugbot is set up for automated code reviews on this repo. Configure here.
This change is