# Proof Lifecycle and Architecture

## Proof Lifecycle

<figure><img src="https://4246424545-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhJBnSjWavskB78iiJW5t%2Fuploads%2Fl2HbMkWKiC28cYN4frfF%2FUntitled%20Diagram.webp?alt=media&#x26;token=0ebed1ed-2e97-4a17-9c22-22fe34e2ee3a" alt="" width="518"><figcaption></figcaption></figure>

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*

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

4. *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

<figure><img src="https://4246424545-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhJBnSjWavskB78iiJW5t%2Fuploads%2FUvhdRqsJcerLY7LOPVXT%2FDiagram_less.png?alt=media&#x26;token=ec47ed9a-a0bf-4afa-992e-9b6510914db0" alt=""><figcaption></figcaption></figure>

#### 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.&#x20;
* 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.