Add memory checks for prover_input, as well as range_checks for prover_input, syscalls/exceptions

[LindaGuiga]

This PR addresses the prover_input and syscalls/exceptions points from this issue.

• STACK_BEHAVIORS is addressed to add stack constraints for prover_input.
• CTLs and ArithmeticStark are updated to include range checks for prover_input, syscalls and exceptions in the CpuStark.

[LindaGuiga]

The latest push was to rebase on main, since the PR had conflicts with this merged PR.

[nbgl]

Looks good, but the cross-table lookup could be made simpler and more efficient :)

[nbgl]

Each of these cross-table lookups adds an extra column to the CPU table, so ideally we'd like to have as few of them as possible. Luckily, we can just use the first CTL (cpu_stark::ctl_arithmetic_base_rows()) for range checks.

[nbgl]

These can be deleted: we can reuse the base arithmetic CTL.

[LindaGuiga]

@nbgl The reason why I didn't reuse the base arithmetic CTL here was because I only selected the useful columns in the CPU for prover_input and syscalls/exceptions. For prover_input, the logic would still work with the base arithmetic CTL, but since we only wanted to range check output[6] for syscalls and exceptions, I thought we had to create an additional ctl. Am I missing something?
What I also thought we could do to avoid adding a CPU column is to range check handler_addr0-2 and syscall_info/exc_info, since they're already in the columns selected by the base CTL, instead of only range checking the gas. What do you think?

[nbgl]

We want to add COL_MAP.op.syscall + COL_MAP.op.exception + COL_MAP.op.prover_input to the OPS list. This can be done with the Column::sum API, but will require a reworking of ctl_data_ternops.

This way we don't have to have a separate cross-table lookup just for range checks.

[LindaGuiga]

@nbgl Thank you for your review!
I replaced the u32 values for range checks by U256 to simplify things, as you suggested.
Regarding the use of ctl_arithmetic_base_rows instead of additional CTLs, since the columns required, on the cpu side, for syscalls and exceptions are different from the other operations, I not only range checked the gas but also the handler addresses and syscall/exc_info, since they are also U256s and are already in the "correct" rows. What do you think of this approach?

[LindaGuiga]

@nbgl I pushed a new version that does not introduce a new CTL for the range checks but instead adds a column OPCODE_COL in ArithmeticStark containing the opcode if the operation is a range check. This allows us to reuse ctl_arithmetic_rows for the range checks.
I constrained the new opcode column to be 0 when the operation is anything but a range check.
What do you think of this approach?

[LindaGuiga]

@nbgl I pushed a new version that doesn't introduce a new CTL: the idea is that instead of range-checking the last memory channel for arithmetic operations, we check the next row's mem_channels[0] which should also contain the result (since it contains the new top of the stack). This enables us to check the new top of the stack for prover_inputs, syscalls and exceptions, which contains the values we want to range check. What do you think of this approach?

[pgebheim]

hey @nbgl -- What's the status on reviewing this?

[pgebheim]

Hey @Nashtare -- are you going to be reviewing this to get it merged?

[Nashtare]

@pgebheim yeah I can, though I didn't as @nbgl was assigned the review already

[nbgl]

Thank you!

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information