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}$.

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

1. Protocol Specific Action

• The Protocol A smart contract pre-stores $combined\_vkey\_hash$, which is $Hash(Hash(vkey_{a}), verifier\_id)$.

• After aggregated proof verification, Protocol A requests quantum node for inclusion proof $\pi_{inc}$.

• Protocol A sends its public inputs $pis_{A}$ and the inclusion proof $\pi_{inc}$ to its own smart contract.

1. Quantum Contract Verification

• The Protocol A Contract makes a cross-contract call to the Quantum Contract, providing $pis_{A}$, $combined\_vkey\_hash$, and $\pi_{inc}$ as inputs.

• Quantum Contract verifies whether $\pi_{inc}$ corresponding to the $pis_{A}$ and $combined\_vkey\_hash$ is correct.

Architecture

Reduction step

Each individual proof gets reduced to the same proof type, with public inputs as one keccak hash output . This leads to a final aggregation circuit which verifies variable number of reduced proofs of the same type.

Aggregation step

The aggregation circuit does the following three things:

• Compute reduction circuit's public inputs by combining the original verification key hash and original public inputs hash.

• Verify correctness of each reduced proof against the reduction circuit's public input and verifier id corresponding to the original proving scheme used by the user.

• The public input of the aggregation circuit is a batch merkle root called superRoot where each leaf corresponds to an individual reduction proof.

• Each individual leaf's value can be deduced using Hash(combined_vkey_hash||protocol_pis_hash)

Smart Contract

In the smart contract, we store a bool mapping from superRoot to true/false. This map gets updated every time a superproof is submitted. At the user level, they only have to query this map and check if the superRoot corresponding to their proof returns True, and if the result they get is equal to True, they have to just do a simple merkle inclusion check corresponding to this root which verifies that their proof was verified as part of this aggregated proof.