Quantum Protocol Specifications

User Journey Overview

This section outlines the complete user journey with the Quantum Protocol, basically highlighting all the user interactions with Quantum.

Circuit Registration

Users begin by registering the quantum circuits they wish to generate and aggregate proofs for. This is accomplished seamlessly using the quantum-sdk. During the Circuit Registration phase, users submit circuit-specific data (e.g., verification keys) to the Quantum Node. In return, they receive a unique identifier called the circuitHash, which will be used in subsequent interactions with the protocol.

Proof Submission

Once a circuit is registered, users can submit their proof ($\pi$) along with their public inputs ($pis$) to the Quantum Node. Upon submission, the user receives a proofHash, a unique identifier for their proof. The proofHash allows users to track the status of their proof during the aggregation process.

Inclusion Check

Within a designated time window, the Quantum Node aggregates all user-submitted proofs into an Aggregated Proof ($\pi_{agg}$). The aggregation is encoded in a binary Merkle tree, whose root, known as the Super Root, is submitted and then verified on the QuantumVerifier contract deployed on Ethereum. Post this users can verify that their individual proof is included in the aggregated proof. This process, referred to as the Inclusion Check, involves obtaining an inclusion_proof from the Quantum Node. The inclusion_proof is a Merkle proof that allows the user to independently verify that their proof was verified and included as part of the aggregated proof ($\pi_{agg}$) verified on-chain.

Aggregation Backend Overview

This section provides a high-level overview of the aggregation backend architecture. Details regarding constraints, public inputs, and their linkages across different stages are covered in the Specifications

The aggregation backend operates in four distinct stages: Reduction, Aggregation, SNARKification, and Consolidation. Each stage leverages a different prover: Risc0 zkVM for the reduction, Risc0 zkVM and Sp1 zkVM for the aggregation, Circom for SNARKification, and Gnark for Consolidation. The following flow diagram explains the whole process concisely:

Reduction:

At this stage, each user-submitted proof ($\pi$) (excluding SP1 proofs) and its corresponding public inputs ($pis$) are individually verified within a Risc0 zkVM circuit. This circuit implements the verification algorithm for the proving scheme and some hashing. The result of this process is a compressed proof ($\pi_{reduced}$) along with new reduced public inputs ($pis_{reduced}$).

Aggregation:

The sp1 proofs and the reduced proofs ($\pi_{reduced}$), along with their public inputs ($pis_{reduced}$), are recursively verified and encoded into two Merkle trees - using Sp1 zkVM for the former, and Risc0 zkVM for the latter. This produces the 2 aggregated proofs ($\pi_{agg1}, \pi_{agg2}$) and their corresponding aggregated public inputs ($pis_{agg1},pis_{agg2}$).

SNARKification:

The aggregated proofs ($\pi_{agg1},\pi_{agg2}$) and the corresponding public inputs ($pis_{agg1},pis_{agg2}$) undergo a further transformation at this stage. The proofs with their associated public inputs ($pis_{snark1},pis_{snark2}$) are recursively verified and converted into 2 Groth16 proofs ($\pi_{snark1},\pi_{snark2}$) using the circuits provided here and here, respectively.

Consolidation:

At the final stage, the Groth16 proofs ($\pi_{snark1},\pi_{snark2}$) and their public inputs ($pis_{snark1},pis_{snark2}$) are recursively verified inside a Gnark circuit. This produces the final proof ($\pi_{final}$) and its public inputs ($pis_{final}$).

Specifications

This section goes into depth about each component and the inner workings of the Quantum Protocol.

1. Circuit Registration

In this stage, the user submits circuit-specific data, which primarily includes the information necessary to verify proofs generated for the circuit. Depending on the proving scheme, either all or a subset of this data is used in formation of circuitVKey. For all the proving schemes, excluding SP1, this data is combined and hashed with the Risc0 Image ID associated with the verifier (reduction) circuit for the selected proving scheme. The resulting hash, known as the circuitHash, is returned to the user as a unique identifier for their circuit.

The circuitHash also plays a critical role in later stages, such as during the User Inclusion Check.

Formula for Computing circuitHash:

For SP1 Proofs,

$$circuitHash=user\_circuit\_data$$

For all other proving schemes,

$$circuitHash=Keccak(user\_circuit\_data ∣∣ risc0\_image\_id)$$

• $user\_circuit\_data$: The circuit-specific data, which varies based on the proving scheme.
• $risc0\_image\_id$: The unique identifier for the reduction circuit used in the protocol.

This hashing mechanism ensures that each circuit is uniquely identifiable and securely tied to its associated verification logic.

• Gnark Groth16/Plonk

  For Gnark Groth16/Plonk, the user's Verification Key is serialized into bytes using the Borsh serialization format. The serialized bytes are then hashed using the Keccak Hash algorithm to compute $user\_circuit\_data$.

  $$user\_circuit\_data = Keccak(user\_vkey\_bytes)$$
• SnarkJS Groth16

  For SnarkJS Groth16, the user’s Verification Key is converted into *PreparedVerifyingKey,* and then serialised into bytes using Canonical Serialize.

  $$user\_circuit\_data = Keccak(prepared\_vkey\_bytes)$$
• Risc0 Compressed

  For Risc0 Compressed Proofs, just the user’s risc0 Image Id is used.

  $$user\_circuit\_data = Keccak(user\_circuit\_image\_id\_bytes)$$
• SP1 Succinct

  For SP1 Succinct Proofs, $user\_circuit\_data$ is computed from SP1VerifyingKey using this function.

  $$user\_circuit\_data = keccak(sp1\_verifying\_key)$$
• Plonky2

  For Plonky2, the user sends VerifierOnlyCircuitData and CommonCircuitData during Circuit Registration as both of them are required to successfully verify a Plonky2 proofs.

  $$user\_circuit\_data = keccak(vkey_{u} \ || \ common\_data_{u})$$
• Halo2 KZG/KZG-EVM

  For Halo2 KZG/KZG-EVM, the user sends PlonkProtocol and s_g2 as both are required to successfully verify Halo2 KZG or KZG-EVM proofs.

  $$user\_circuit\_data = keccak(protocol\_data_{u} \ || \ s\_g2_{u})$$

2. Proof Submission

In this stage, the user submits the proof $\pi_{u}$ they want aggregated, along with the corresponding public inputs $pis_{u}$. In return, the user receives a unique proofId. This proofId is computed as follows:

$$proofId = Keccak(circuitHash \ || \ Keccak(\pi_{u}) \ || \ Keccak(pis_{u}))$$

The proofHash allows users to track the status of their proof during the aggregation process and also serves as the leaf node in the binary Merkle tree that corresponds to the Super Root.

3. Reduction

The reduction stage validates the user's proof within a Risc0 circuit for all the proving schemes excluding SP1. The Risc0 circuit executes the verifier logic specific to each proving scheme, where each proving scheme is associated with a distinct reduction circuit, identified by a unique Risc0 Image ID.

This step produces a compressed proof ($\pi_{red}$), unifying proofs from different proving schemes into a standardized format. The reduction circuit accepts all the necessary data for verifying a proof as private input, while the public input for the reduction circuit is typically as follows:

$$pis_{red} == ( \ keccak(user\_circuit\_data \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u})) )$$

• Gnark Groth16/Plonk , SnarkJS Groth16

  Private Inputs (Reduction circuit private inputs):

  1. $vkey_{u}$ : User circuit verification key
  2. $\pi_{u}$ : Proof user wants to get aggregated corresponding to $vkey_{u}$
  3. $pis_{u}$: Public inputs corresponding to $\pi_{u}$

  Public Input ( $pis_{red}$ : Reduction Circuit Public Input):

  1. $pis_{red}$ $( \ keccak(keccak(vkey_{u} ) \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u})))$

  Reduction Circuit Constraints:

  1. $snark\_verify(vkey_{u}, \pi_{u}, pis_{u}) == True$
  2. $pis_{red} == ( \ keccak(keccak(vkey_{u}) \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u})) )$
• Risc0 Compressed

  Private Inputs (Reduction circuit private inputs):

  1. $image\_id_{u}$ : User risc0 circuit Image Id
  2. $journal_{u}$ : User generated risc0 journal

  Public Inputs ( $pis_{red}$ : Reduction Circuit Public Input):

  1. $pis_{red}$$(keccak(image\_id_{u} \ || \ keccak(journal_{u}) ))$

  Reduction Circuit Constraints:

  1. $risc0\_verify\_compressed(image\_id_{u}, journal_{u}) == True$
  2. $pis_{red} ==(keccak(image\_id_{u} \ || \ keccak(journal_{u})))$
• Plonky2

  Private Inputs (Reduction Circuit Private Inputs):

  1. $common\_data_{u}$: User plonky2 circuit common_data
  2. $vkey_{u}$: User circuit verification_only data
  3. $\pi_{u}$: Plonky2 proof user wants to get aggregated corresponding to $vkey_{u}$
  4. $pis_{u}$ : User circuit public inputs

  Public Inputs:

  1. $pis_{red}$($keccak(keccak(vkey_{u} \ || \ common\_data_{u}) \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u}))$)

  Constraints:

  1. $plonky2\_verify\_proof(common\_data_{u}, vkey_{u}, pis_{u}, \pi_{u})$
  2. $pis_{red} == keccak(keccak(vkey_{u} \ || \ common\_data_{u}) \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u}))$
• Halo2 KZG/EVM

  Private Inputs:

  1. $protocol\_data_{u}$
  2. $s\_g2_{u}$
  3. $pis_{u}$
  4. $\pi_{u}$

  Public Inputs:

  1. $pis_{red}$$(keccak(protocol\_data_{u} \ || \ s\_g2_{u}) \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u}))$

  Constraints:

  1. $halo2\_verify(protocol\_data_{u}, pis_{u}, s\_g2_{u}, \pi_{u})$
  2. $pis_{red} == (keccak(protocol\_data_{u} \ || \ s\_g2_{u}) \ || \ keccak(\pi_{u}) \ || \ keccak(pis_{u}))$

4. Aggregation

In the aggregation stage, all the reduced proofs and public input pairs are recursively verified inside a single risc0 circuit and all the SP1 proofs are recursively verified inside a single sp1 circuit. These circuits encode all the user's proof in binary Merkle trees, producing 2 compressed proofs $(\pi_{agg1},\pi_{agg2})$

Within a Risc0 circuit, each individual proof is verified against its Reduction circuit’s Risc0 Image Id . These Image Id’s are hardcoded in the aggregation circuit corresponding to their proof_types.

Risc0

Public Input ($pis_{agg1}$): $risc0\_root$

Private Inputs:

1. Reduced Proofs: $(\pi_{red_{i}})_{i=0}^{i=batch\_size}$
2. Reduced Public Inputs: $(pis_{red_{i}})_{i=0}^{i=batch\_size}$
3. User Proof Types: $(proof\_type_{i})_{i=0}^{i=batch\_size}$
4. User Proof Hashes: $(\pi\_hash_{i})_{i=0}^{i=batch\_size}$
5. User Public Input Hashes: $(pis\_hash_{i})_{i=0}^{i=batch\_size}$
6. User Circuit Datas: $(ckt\_data)_{i=0}^{i=batch\_size}$

Constraints:

1. $(verify\_risc0\_proof(\pi_{red_{i}}, pis_{red_{i}}, redn\_image\_id_{i}) == True)_{i=0}^{i=batch\_size}$
2. $(pis_{red_{i}} == keccak(ckt\_data_{i} \ || \ \pi\_hash_{i} \ || \ pis\_hash_{i} ))_{i=0}^{i=batch\_size}$
3. $risc0\_root == construct\_tree(leaves); \\leaves=[keccak(keccak(ckt\_data_{i} \ || \ redn\_image\_id_{i}) \ || \ \pi\_hash_{i} \ || \ pis\_hash_{i})]_{i=0}^{i=batch\_size}$

SP1

Public Input ($pis_{agg2}$): $sp1\_root$

Private Inputs:

1. User Proofs: $(\pi_{u_{i}})_{i=0}^{i=batch\_size}$
2. Public Inputs: $(pis_{u_{i}})_{i=0}^{i=batch\_size}$
3. User Public Inputs: $(pis_{i})_{i=0}^{i=batch\_size}$
4. User Circuit Datas: $(ckt\_data)_{i=0}^{i=batch\_size}$

Constraints:

1. $(verify\_sp1\_proof(ckt\_data_{i},\pi_{u_{i}}, pis_{u_{i}}) == True)_{i=0}^{i=batch\_size}$
2. $sp1\_root == construct\_tree(leaves); \\leaves=[keccak(ckt\_data_{i} \ || \ pis\_hash_{i})]_{i=0}^{i=batch\_size}$

5. Snarkification

This stage converts compressed proofs ($\pi_{agg1},\pi_{agg2}$) to 2 groth16 proofs ($\pi_{snark1},\pi_{snark2}$) using the circuits provided here and here. The only reason for this step is to reduce on-chain verification cost on Ethereum. The public input in this stage which is the $super\_root$ is defined as:

$super\_root == keccak(risc0\_root\ || \ sp1\_root)$

6. Consolidation

At this stage, the Groth16 proofs ($\pi_{snark1},\pi_{snark2}$) and their public inputs ($pis_{snark1},pis_{snark2}$) are recursively verified inside a Gnark circuit. This produces the final proof ($\pi_{final}$) and its public inputs ($pis_{final}$). Additionally, this stage future-proofs the system by enabling seamless integration with additional VMs for reduction and aggregation, requiring minimal modifications.

7. On-chain Superproof Verification

Once the Snarkification step is complete, the Groth16 proof ($\pi_{final}$) is submitted to the QuantumVerifier contract on Ethereum for on-chain verification. The corresponding public input ($pis_{final}$), which is the Super Root, is also passed to the contract.

The QuantumVerifier contract validates the proof against the public input using the Groth16 verifier logic. If the verification is successful, the Super Root ($pis_{final}$) is stored in the Quantum contract's state as a record of successful aggregation and proof verification.

8. User Inclusion Check

After the Super Root ($pis_{final}$) is verified and stored on-chain, individual users can perform an Inclusion Check to verify that their proof ($\pi_u$) was correctly included in the aggregated proof.

Steps for Inclusion Check:

1. Retrieve the inclusion proof :

   • The user queries the Quantum Node for an inclusion_proof associated with their submitted proof.

   • The inclusion_proof is a Merkle proof that demonstrates that the user’s proof ($\pi_{u}$) was correctly verified using the appropriate verifier circuit identified by $redn\_image\_id_{proving\_scheme}$, corresponding to the public inputs ($pis_{u}$) for the circuit with circuit data $ckt\_data_{u}$. It also confirms that this verified proof was included in the Merkle tree whose root is the Super Root.
2. Validate their public inputs on-chain using the Inclusion Proof :

   i. Pre-storing the circuit_hash:

   • The user first registers their circuit with the protocol and stores the circuit_hash in their protocol-specific smart contract.

   • The circuit_hash uniquely identifies the user’s circuit and is derived during the Circuit Registration phase as: $circuitHash=Keccak(user\_circuit\_data ∣∣ risc0\_image\_id)$
   • This serves as the foundation for reconstructing and verifying the inclusion proof.

   ii. Sending Proof Details to the Contract:

   • The user submits the following to their protocol smart contract:

     • $Keccak(\pi_{u})$: The hash of the user’s individual proof.
     • $pis_{u}$: The public inputs corresponding to the proof.
     • $inclusion\_proof$: A Merkle proof that links the user’s proof to the Super Root stored on-chain.

   iii. Reconstructing the Leaf:

   • Inside the protocol smart contract, the submitted data is used to reconstruct the Merkle leaf as: $leaf=Keccak(circuitHash ∣∣ Keccak(π_u) ∣∣ Keccak(pis_u))$
   • This leaf represents the hashed representation of the user’s proof and its associated public inputs, tied to the specific circuit.

   iv. Verifying the Inclusion Proof:

   • The reconstructed leaf is verified against the Merkle tree using the submitted inclusion_proof.

   • The smart contract calls the Quantum Verifier contract to cross-check the inclusion_proof against the Super Root stored on-chain during the On-Chain Superproof Verification step.

   v. Validation Outcome:

   • If the inclusion_proof is valid and the Merkle proof matches the Super Root, the user’s public inputs ($pis_{u}$) are confirmed as part of the aggregated proof.
   • This ensures that the user’s proof was correctly included, verified, and aggregated within the protocol.