Decider for Onchain Verification
Overview
This section describes the details of Sonobe's Decider, which is a zkSNARK that compresses the IVC's final proof.
Given an IVC scheme constructed with a folding scheme based on the CycleFold approach, the decider described in this section allows one to efficiently verify the final proof onchain in Ethereum's EVM.
Below we use Nova as a concrete example of the folding scheme, but the decider itself is generic and can be used with any other folding scheme.
Warning: This section, as the rest of Sonobe, is experimental. The approach described in this section is highly experimental and has not been audited.
Context
At the final stage of IVC based on Nova+CycleFold, after iterations, we have the committed instances and their respective witnessess, where is the incoming instance, is the running instance, and is the CycleFold (running) instance.
Diagram source: CycleFold paper (https://eprint.iacr.org/2023/1192.pdf). In the case of this document , so , , .
We work on a cycle of curves composed by and , where and . We will use to refer to , and to refer to . The main circuit constraint field is , and circuit constraint field is .
Since the objective is to verify the proofs on Ethereum, we set =BN254 and =Grumpkin. Thus, is the scalar field of the BN254.
The and contain:
And contains:
Decider high level checks
Consider the Nova-based IVC for R1CS, where is the R1CS for the augmented circuit AugmentedFCircuit
, and is the R1CS for the CycleFold circuit CycleFoldCircuit
.
The decider is essentially responsible for ensuring the validity of , which contains the following checks:
- :
- The running instance and witness satisfy (relaxed) .
- The commitments in open to the values in .
- :
- The incoming instance and witness satisfy (plain) .
- The commitments in open to the values in .
- :
- The CycleFold instance and witness satisfy (relaxed) .
- The commitments in open to the values in .
- is valid:
- contains the correct hash of the initial and final states.
- is indeed an incoming instance.
In Sonobe, the logic above is implemented in a zkSNARK circuit. To reduce circuit size, we ask the prover to fold and one more time, obtaining . Now, the circuit only needs to check:
- is the correct folding of , i.e., .
- :
- The running instance and witness satisfy (relaxed) .
- The commitments in (i.e., ) open to the values in (i.e., ).
- :
- The CycleFold instance and witness satisfy (relaxed) .
- The commitments in (i.e., ) open to the values in (i.e., ).
- is valid:
- contains the correct hash of the initial and final states, i.e., and
- is indeed an incoming instance, i.e., and .
Note: These are the same checks for both the Onchain & Offchain Deciders. The difference lays on how are performed.
Onchain Decider approach
The decider proof is computed once, and after all the folding has taken place. Our aim is to be able to verify this proof in the Ethereum's EVM.
The prover computes
The Decider Circuit verifies in its R1CS relation over the checks described above. Below we explain how the checks are performed in the circuit (for circuit efficiency, the order of the checks is different from the one described above):
- 1: Enforce and satisfy , the RelaxedR1CS relation of the AugmentedFCircuit
- 2: Check that and
- 3: Check that and
- 4: Commitments verification of with respect to , where Pedersen commitments are used
- This check is native in because .
- 5: Enforce and satisfy , the RelaxedR1CS relation of the CycleFoldCircuit
- This check involves non-native operations because . With naive sparse matrix-vector product, it blows up the number of constraints.
- 6.1: Partially enforce that is the correct folding of
- By partially, we mean that only field elements in are checked, while the group elements (i.e., commitments) are not, as they are in and are expensive non-native operations.
- 7.1: Check correct computation of the KZG challenges which we do through in-circuit Transcript.
- 7.2: Check that the KZG evaluations are correct
-
where are the interpolated polynomials from respectively.
ie. , where is zero-padding to the next power of 2 length, and interpolates a (unique) polynomial from the vector
The rest of the checks are performed outside of the circuit by the verifier. In addition to verifying the decider proof, the verifier would have to check:
- 6.2: The commitments in are the correct folding of those in , i.e., and .
- 6.1 and 6.2 in together enforce .
- 7.3: The KZG proofs are valid with respect to the commitments and the challenges .
- 7.1, 7.2, and 7.3 together enforce that are the openings to the commitments .
If we use Pedersen commitment as the commitment scheme for generating , the checks for commitments would be too expensive as they are non-native in-circuit. By changing the commitment scheme to KZG, we can separate the commitments verification into 7.1, 7.2, and 7.3, where 7.1 and 7.2 can be (relatively) cheaply verified in-circuit, and 7.3 can be verified outside of the circuit (onchain).
The prover would generate a Groth16 proof over BN254 for this Decider Circuit, which can later be verified onchain in the EVM together with the KZG commitments of check 7.1 and check 7.2.
In this way, the final proof to be verified onchain would be:
- a Groth16 proof of the checks 1, 2, 3, 4, 5, 6.1, 7.1, 7.2
- the KZG proofs verification (check 7.3)
- the NIFS.V (check 6.2), which relates the inputs of the checks in the Groth16 proof and check 6.1
The RelaxedR1CS checker circuit
The "correct RelaxedR1CS relation" (used in check 1) is checked by the gadget proposed by Nalin Bhardwaj, which is a R1CS circuit that checks the RelaxedR1CS relation, more details here.
The idea is that we check in a R1CS circiut the RelaxedR1CS relation (). Note that this approach has a blowup of 3x
with respect to the original circuit number of constraints x
(when using sparse representation of the matrices).
Circuit costs
Note: the number of constraints written in this section is the current values that we have, which we aim to reduce in future iterations.
Estimated costs of the full decider-onchain circuit:
(x
is the number of constraints of the circuit that we're folding, and the AugmentedFCircuit takes ~52k constraints)
- 1: relation:
3(x+52k)
- 2: check:
<1000
- 3: hash check:
2634
- 4: Pedersen check of commitments (native):
<5M
both commitments (including the inputs allocations). This is a couple of native MSMs of <1500 elements each one - 5: relation (non-native):
5.1M
- 6.1: Partial check of : (cheap)
- 7.1: Check correct computation of the KZG challenges:
7708
- 7.2: Check that the KZG evaluations are correct
262k
Total: 3*(x+52_252) + 1000 + 2634 + 4_967_155 + 5_146_236 + 7708 + 262_000
eg: for a circuit of 500k
constraints the decider circuit would take approximately 11.9M
constraints.
As can be seen, most of the costs come from the Pedersen commitments verification and the relation (checks 4 and 5 respectively).