fix(soundness): bind sumcheck/tower evaluations to Fiat-Shamir transcript#1294
fix(soundness): bind sumcheck/tower evaluations to Fiat-Shamir transcript#1294MavenRain wants to merge 3 commits intoscroll-tech:masterfrom
Conversation
…cript Fixes scroll-tech#1150 and scroll-tech#1162. Prover-supplied evaluations (GKR layer MLE evals, rotation evals, tower prod/logup evals) were included in proofs but never absorbed into the Fiat-Shamir transcript, allowing a malicious prover to substitute internally-consistent forgeries. Both prover and verifier now absorb these values symmetrically.
There was a problem hiding this comment.
Thanks for the PR addressing soundness issue!
While I proposed the better design down the road to fix this issue is make Transcript as a streaming between prover & verifier such any information verifier collected from prover are always included in transcript in systematical way, this involve more widely refactor. Thus current patched PR with small scope looks pretty fine!
however something I didnt spot in this PR, probably missing
- gpu tower prover: https://github.com/MavenRain/ceno/blob/d84b2ab83e0c0c4ff9f8b1d97e51033bfd24e09e/ceno_zkvm/src/scheme/gpu/mod.rs
- ceno_recursion https://github.com/MavenRain/ceno/tree/d84b2ab83e0c0c4ff9f8b1d97e51033bfd24e09e/ceno_recursion/src -> recursion verifier implemented in domain-specific-language
…+ review cleanup Bind prover-supplied evaluations into the Fiat-Shamir transcript in the recursion verifier (tower + GKR layer + rotation), fix clippy::needless_range_loop in the native tower verifier, and apply Ming's suggestion to move push calls inside the conditional blocks.
Good catch. The GKR layer GPU code (gkr_iop/src/gkr/layer/gpu/mod.rs) was already patched in this PR. For the tower-level GPU prover, prove_tower_relation_impl delegates to cuda_hal.tower.create_proof() which handles the sumcheck loop internally in the ceno-gpu-mock crate. That kernel would need a matching change to absorb per-round evals before sampling r_merge. I can open a follow-up issue/PR against ceno-gpu-mock for that, if you'd like. For ceno_recursion, I've added the matching transcript bindings in both the tower verifier (tower_verifier/program.rs) and the GKR circuit verifier (zkvm_verifier/verifier.rs), so the recursion verifier's Fiat-Shamir transcript now matches the prover's. |
…#1300) Also related to #1294 A follow-up soundness PR after rotation-flow refactor, focused on ECC->GKR bridge wiring and selector semantics. ### What changed (high level) This PR hardens ECC bridge integration with GKR by making point-binding semantics explicit and consistent across: - CPU prover path - GPU prover path - native verifier path - recursion verifier path It also tightens selector invariants in `ShardRamCircuit` and layer construction. --- ### Proving-flow diagram (current) ```text create_chip_proof | +--> [optional] prove ECC quark | - input: ec_point_exprs / ec_slope_exprs witnesses | - output: ecc_proof { rt, evals, sum } | +--> build main witness (records / layers) | +--> prove tower relation | - build tower witnesses (r/w/logup) | - sumcheck tower | - output: rt_tower, tower_proof, out_evals | +--> [optional] prove rotation | - output: rotation_proof + rotation points | +--> prove main constraints (GKR) | - initialize out_evals at rt_tower | - wire rotation claims -> selector groups | - wire ECC bridge claims (x/y/s) -> selector groups | - run GKR prove | - output: gkr_iop_proof + opening evals + input_opening_point | +--> PCS opening | '--> assemble ZKVMChipProof ### Next - refactor `prove ECC quark` after `proving tower relation` which make thing much clear
|
@MavenRain can you help to fix ci lints error? thanks! |
2 participants
Fixes #1150 and #1162. Prover-supplied evaluations (GKR layer MLE evals, rotation evals, tower prod/logup evals) were included in proofs but never absorbed into the Fiat-Shamir transcript, allowing a malicious prover to substitute internally-consistent forgeries. Both prover and verifier now absorb these values symmetrically.