decider for offchain verification

Overview: This section describes the Decider (compressed SNARK / final proof) for the non-ethereum use cases in which the verification of the Nova+CycleFold proofs is done offchain. For onchain Ethereum use cases, check out the decider-onchain section.

Setup

At the final stage of the Nova+CycleFold folding, after iterations, we have the committed instances and their respective witnessess.

cyclefold diagram Diagram source: CycleFold paper (https://eprint.iacr.org/2023/1192.pdf). In the case of this document , so , , .

We work with a cycle of curves and , where and . We will use for referring to , and for referring to . The main circuit constraint field is , and circuit constraint field is .

The and contain:

And contains:

Decider high level checks

  • 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.

Offchain Decider approach

In the offchain case, since we can end up with proofs in both curves of the cycle, we try to fit all the computations natively in each curve respectively.

We use the same checks numbers as the ones used in the Onchain Decider in order to make the relation of the checks easier to follow.

Circuit1 ()

  • 1: Enforce and satisfy , the RelaxedR1CS relation of the AugmentedFCircuit
  • 2: Check that and
  • 3: Check that and
  • 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

Circuit2 ()

Note that in onchain decider, step 4 (Pedersen commitments verification of ) is checked in-circuit, necessitating ~5M constraints.

In the case of offchain decider, we aim to reduce the number of constraints for commitment verification for CycleFold instances. To this end, we apply the same approach as in step 7 of the onchain decider for checking commitments in primary instances. That is, we now use KZG commitments as well for the CycleFold instances, enabling us to separate expensive parts in commitments verification from the circuit.

Below are checks for the Circuit2:

  • 4.1: Check correct computation of the KZG challenges for which we do through in-circuit Transcript.
  • 4.2: check that the KZG evaluations for are correct

    • where are the interpolated polynomials from respectively.
  • 5: Enforce and satisfy , the RelaxedR1CS relation of the CycleFoldCircuit
    • This check becomes native because the constraint system is now over .

Outside the circuits

  • 6.2. Check the commitments in are the correct folding of those in
  • 7.3: Verify the KZG proofs with respect to the commitments and the challenges .
  • 4.3: Verify the KZG proofs with respect to the commitments and the challenges .

Proving scheme

We could use a SNARK adapted to RelaxedR1CS, but before that is ready we use a regular R1CS SNARK and check the RelaxedR1CS relations in-circuit as described above. Two proofs are generated, one for each circuit over their respective curves of the cycle.