> For the complete documentation index, see [llms.txt](https://docs.electron.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.electron.dev/quantum-proof-aggregation-for-ethereum/proof-lifecycle-and-architecture.md).

# Proof Lifecycle and Architecture

## Proof Lifecycle

<figure><img src="/files/1EdTKKmHW1GLdb813guO" 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="/files/Fqg0PE0Vdvq2dox3i0fF" 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.