spec: Recursion - #943
Conversation
Kimi Code ReviewAutomated review by Kimi (Moonshot AI) |
Codex Code Review
|
| *Record $record$.* | ||
| The record contains all challenges the prover derived using Fiat-Shamir. | ||
|
|
||
| *Tasks for $verify'_b\(commitment_0, commitment_1, b, proof, record)$:* |
There was a problem hiding this comment.
This is missing a few of the ad-hoc checks, which are (I think) mostly related to memory and paging.
It would probably be a good idea to have an overview of those somewhere central as well.
There was a problem hiding this comment.
I'm not content with this section, at all. Indeed, stuff is missing.
I propose we have a full verifier description in verifier.typ (including all the ad-hoc checks you mention) and here only mention how to transform that monolithic verifier into the split/recursive verifier in this section.
wdyt of that split?
There was a problem hiding this comment.
I rewrote this section. Let me know what you think!
Co-authored-by: Robin Jadoul <robin.jadoul@gmail.com>
Co-authored-by: Erik <159244975+erik-3milabs@users.noreply.github.com>
| When recursing on this process, the prover provides the verifier with this commitment. | ||
| We thus have to demonstrate the commitments the prover provides are as expected. | ||
| This is achieved by having the verification algorithm `COMMIT` (see @commit) | ||
| to the public input it is provided. | ||
| This act produces an imbalance in the LogUp-component of the proof-of-verification, | ||
| which must be balanced during verification in the _next_ recursion layer. | ||
| In later recursions, the verifier must consistently `COMMIT` to its public input | ||
| and use the _same_ public input to balance out the LogUp-component of the proof | ||
| it is provided. | ||
| This solution effectively kicks the can down the road; the final verifier has to | ||
| provide the initial input to the program as input to verify the recursive proof. |
There was a problem hiding this comment.
- We may not have access to COMMIT in a future flock-fieldvm hybrid
- Isn't this handled by
$\mathbb{c}_1 = \bar{\mathbb{x}}$ already? Since the instance$\mathbb{x}$ includes the public input?
| $ | ||
|
|
||
| *Final verification.* | ||
| $verify'(commit(instance), (commit(verify'_b), commit(verify'_f)), 1, proof^((n))) =? one$ |
There was a problem hiding this comment.
| $verify'(commit(instance), (commit(verify'_b), commit(verify'_f)), 1, proof^((n))) =? one$ | |
| $verify'(commit(instance), (commit(verify'_b), commit(verify'_f)), 1, proof^((n))) =^? one$ |
| $ | ||
|
|
||
| *Final verification.* | ||
| $verify'(commit(instance), (commit(verify'_b), commit(verify'_f)), 1, proof^((n))) =? one$ |
There was a problem hiding this comment.
We may be able to get rid of the b argument by having the statement being proven the OR of both options:
I know a proof that is either accepted for the original statement OR for the recursion function.
I suppose this is essentially absorbing this bit into the proof or witness, but it cleans up the final verification and allows proofs without compressing to be used without any further change.
2 participants
No description provided.