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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.electron.dev/quantum-proof-aggregation-for-ethereum/proof-lifecycle-and-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.