Proof Lifecycle and Architecture

This section describes the lifecycle of a zero-knowledge (ZK) proof through quantum, and also gives a brief introduction to Quantum Aggregation Layer Architecture.

Proof Lifecycle

1. Protocol Proof Generation

• Protocol A generates a proof $\pi_{A}$ for its public inputs $pis_{A}$ corresponding to some $vkey_{A}$.

• Protocol A submits $(\pi_{A}, pis_{A})$ to the quantum aggregation layer corresponding to some pre registered $vkey_{A}$.

2. Quantum Aggregation

• The quantum aggregation layer collects proofs from multiple protocols, including $\pi_{A}$.

• It generates an aggregated proof $\pi_{agg}$ that encompasses all individual proofs.

• The aggregated proof $\pi_{agg}$ is verified on the Quantum Contract, upon successful verification the individual proofs within $\pi_{agg}$ are considered valid

3. Protocol Specific Action

• After aggregated proof verification, Protocol A sends its public inputs $pis_{A}$ to its own smart contract.

• The Protocol A smart contract pre-stores $Hash(vkey_{A})$ and computes $Hash(pis_{A})$.

4. Quantum Contract Verification

• The Protocol A Contract makes a cross-contract call to the Quantum Contract, providing $Hash(pis_{A})$ and $Hash(vkey_{A})$ as inputs.

• Quantum Contract verifies whether a proof corresponding to the $pis_{A}$ and $vkey_{A}$ was aggregated and verified as part of the $\pi_{agg}$.

Architecture

Reduction step

Each individual proof gets reduced to the same snark, with the same number of public inputs. This uniformity helps us keep the final aggregation circuit fixed when aggregating a fixed batch size, regardless of what the original proof's scheme was. The public inputs of the aforementioned reduced snark are built in a such a way that information about verification key and public inputs of the original snark are encoded in it. Once the reduction circuit is compiled, the user receives the verification key of the same, which will be used later to assert that the reduced proof has actually been created using this circuit.

Aggregation step

The aggregation circuit does the following three things:

• Verify correctness of each reduced proof against the reduction circuit's verification key.

• Verify that the public inputs of each reduced proof are equal to the values recreated using the original verification key and original public inputs.

• For each original snark, hash it's verification key, it's corresponding reduction circuit's verification key, and it's public inputs to create the public inputs of this aggregation circuit.

The reduction circuit's verification key is included in the final hash to assert that the reduced proof was actually verified against the same verification key that was provided to the user during the reduction step. The hash of the original verification key and the reduced verification key is henceforth referred as vKeyHash.

Smart Contract

In the smart contract, we store a mapping from vKeyHash to publicInputsHash. This map gets updated every time a superproof is submitted. At the user level, they only have to query this map corresponding to their vKeyHash, and if the result they get is equal to their public inputs, it is equivalent to verifying a proof on their own. For now, the public inputs gets overwritten every time a superproof is submitted, but in future we plan to provide support for historical public inputs as well.