Electron Labs
  • Quantum: Proof Aggregation for Ethereum
    • Introduction
    • Proof Lifecycle and Architecture
    • Quantum Protocol Specifications
    • Integration
    • Developer tutorial for integrating Quantum
    • Gas Cost Analysis
    • Developer Chat
Powered by GitBook
On this page
  • Proof Lifecycle
  • Architecture
  1. Quantum: Proof Aggregation for Ethereum

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.

PreviousIntroductionNextQuantum Protocol Specifications

Last updated 6 months ago

Proof Lifecycle

  1. Protocol Proof Generation

  1. Quantum Aggregation

  1. Protocol Specific Action

  1. Quantum Contract Verification

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.

Protocol A generates a proof πA\pi_{A}πA​ for its public inputs pisApis_{A}pisA​ corresponding to some vkeyAvkey_{A}vkeyA​.

Protocol A submits (πA,pisA)(\pi_{A}, pis_{A})(πA​,pisA​) to the quantum aggregation layer corresponding to some pre registered vkeyAvkey_{A}vkeyA​.

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

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

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

The Protocol A smart contract pre-stores combined_vkey_hashcombined\_vkey\_hashcombined_vkey_hash, which is Hash(Hash(vkeya),verifier_id)Hash(Hash(vkey_{a}), verifier\_id)Hash(Hash(vkeya​),verifier_id).

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

Protocol A sends its public inputs pisApis_{A}pisA​ and the inclusion proof πinc\pi_{inc}πinc​ to its own smart contract.

The Protocol A Contract makes a cross-contract call to the Quantum Contract, providing pisApis_{A}pisA​, combined_vkey_hashcombined\_vkey\_hashcombined_vkey_hash, and πinc\pi_{inc}πinc​ as inputs.

Quantum Contract verifies whether πinc\pi_{inc}πinc​ corresponding to the pisApis_{A}pisA​ and combined_vkey_hashcombined\_vkey\_hashcombined_vkey_hash is correct.