Decider for Onchain Verification

Overview: This section describes the approach for the Decider (compressed SNARK / final proof) in order to be able to verify the Nova+CycleFold proofs onchain (in Ethereum's EVM).

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 the Nova+CycleFold folding, after iterations, we have the committed instances and their respective witnessess.

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

These are the same checks for both the Onchain & Offchain Deciders. The difference lays on how are performed.

  1. check
  2. check that and
  3. check that and
  4. correct RelaxedR1CS relation of of the AugmentedFCircuit
  5. check commitments of with respect (where )
  6. check the correct RelaxedR1CS relation of of the CycleFoldCircuit
  7. check commitments of with respect (where )

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 following checks:

  • 1.1: check that the given NIFS challenge is indeed well computed. This challenge is then used outside the circuit by the Verifier to compute NIFS.V obtaining
  • 2: check that and
  • 3: check that and
  • 4: correct RelaxedR1CS relation of of the AugmentedFCircuit
  • 5.1: Check correct computation of the KZG challenges which we do through in-circuit Transcript.
  • 5.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
  • 6: check the correct RelaxedR1CS relation of of the CycleFoldCircuit (this is non-native operations and with naive sparse matrix-vector product blows up the number of constraints)
  • 7: Pedersen commitments verification of with respect (the witness of the committed instance) (where , this check is native in )
    The following check is done non-natively (in ):

Additionally we would have to check (outside of the circuit):

  • 1.2: check
  • 5.3: Commitments verification of with respect (where )

The check 7 would be too expensive if using Pedersen commitments verification in-circuit (non-natively), so we changed these commitments from Pedersen to KZG, and then verify the KZG commitments outside of the circuit and directly 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 KGZ commitments of check 7 and check 8.

In this way, the final proof to be verified onchain would be:

  • a Groth16 proof of the checks 1.1, 2, 3, 4, 5.1, 5.2, 6, 7
  • the KZG proofs verification (check 5.3)
  • the NIFS.V (check 1.2), which relates the inputs of the checks in the Groth16 proof and check 5

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.1: check that the given NIFS challenge is indeed well computed
  • 2: check: <1000
  • 3: hash check: 2634
  • 4: relation: 3(x+52k)
  • 5.1: Check correct computation of the KZG challenges: 7708
  • 5.2: check that the KZG evaluations are correct 262k
  • 6: relation (non-native): 5.1M
  • 7: Pedersen check of commitments (native): <5M both commitments (including the inputs allocations). This is a couple of native MSMs of <1500 elements each one

Total: 1000 + 2634 + 3*(x+52_252) + 7708 + 262_000 + 4_967_155 + 5_146_236

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 6 and 7 respectively).