This section outlines the complete user journey with the Quantum Protocol, basically highlighting all the user interactions with Quantum.
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 circuitKey, which will be used in subsequent interactions with the protocol.
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.
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 Superproof 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.
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 difference prover: Risc0 zkVM for the first two stages, Circom for SNARKification, and Gnark for Consolidation.
Reduction:
In this stage, each user-submitted proof ($\pi$) 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 reduced proofs ($\pi_{reduced}$) and public inputs ($pis_{reduced}$) are then recursively verified and encoded into a Merkle tree within another Risc0 zkVM circuit. This produces the aggregated proof ($\pi_{agg}$) and its corresponding aggregated public inputs ($pis_{agg}$).
SNARKification:
The aggregated proof ($\pi_{agg}$) and corresponding public inputs ($pis_{agg}$) undergo a further transformation at this stage. Using a Circom circuit, the proof is recursively verified and converted into a Groth16 proof ($\pi_{snark}$) with its associated public inputs ($pis_{snark}$).
Consolidation:
In the final step, the Groth16 proof ($\pi_{snark}$) and its public inputs ($pis_{snark}$) are recursively verified inside a Gnark circuit. This produces the final proof ($\pi_{final}$) and its public inputs ($pis_{final}$). While this step may seem redundant, it ensures the system is future-proof by enabling seamless integration with additional VMs for reduction and aggregation, requiring minimal modifications.