You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/2_architecture/agg_mode_components/1_deep_dive.md
+80-47Lines changed: 80 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,64 +1,97 @@
1
1
# Proof Aggregation Service Deep Dive
2
2
3
-
The Proof Aggregation Service runs **once every 24 hours** and performs the following steps:
4
-
5
-
1.**Fetch Proofs from the Verification Layer**
6
-
Queries `NewBatchV3` events from the `AlignedLayerServiceManager` and downloads the batches from `S3`, starting from the last processed block of the previous run.
7
-
8
-
2.**Filter Proofs**
9
-
Filters proofs by supported verifiers and proof types.
10
-
11
-
3.**Aggregate Proofs in the zkVM**
12
-
Selected proofs are aggregated using a zkVM.
13
-
14
-
4.**Construct the Blob**
15
-
A blob is built containing the [commitments](#proof-commitment) of the aggregated proofs.
16
-
17
-
5.**Send Aggregated Proof**
18
-
The final aggregated proof and its blob are sent to the `AlignedProofAggregationService` contract for verification.
19
-
20
-
> [Note]
21
-
> Currently if you want your proof to be verified in the `AggregationMode` you need to submit it via the `VerificationLayer`. In the future, users will have the option to choose whether they want to continue using this method or switch to using only the Aggregation service.
22
-
23
-
## Aggregators and Supported Proof Types
24
-
25
-
Two separate aggregators are run every 24 hours:
26
-
27
-
-**Risc0**: Aggregates proofs of types `Composite` and `Succinct`.
28
-
-**SP1**: Aggregates proofs of type `Compressed`.
3
+
## Architecture Overview
4
+
5
+
The Proof Aggregation Service consists of three main components that work together to aggregate user proofs and submit them on-chain.
1. User deposits ETH into `AggregationModePaymentService` contract to get quota.
29
+
2.`Payments Poller` monitors the contract for deposit events.
30
+
3.`Payments Poller` updates user quotas in the database.
31
+
4. User submits proofs to the `Gateway`.
32
+
5.`Gateway` validates and stores proofs in the database.
33
+
6.`Proof Aggregator` fetches pending proofs from the database.
34
+
7.`Proof Aggregator` aggregates proofs in the zkVM and submits to `AlignedProofAggregationService` contract.
35
+
36
+
## Supported Proof Types
37
+
38
+
The aggregation service currently supports:
39
+
40
+
-**SP1**: Aggregates proofs of type `Compressed`
29
41
30
42
## Proof Commitment
31
43
32
44
The **proof commitment** is a hash that uniquely identifies a proof. It is defined as the keccak of the proof public inputs + program ID:
33
45
34
-
-**For SP1**:
46
+
-**For SP1**:
35
47
The commitment is computed as: `keccak(proof_public_inputs_bytes || vk_hash_bytes)`
36
-
-**For Risc0**:
37
-
The commitment is computed as: `keccack(receipt_public_inputs_bytes || image_id_bytes)`
38
48
39
49
## Multilayer Aggregation
40
50
41
-
To scale aggregation without exhausting zkVM memory, aggregation is split in two programs:
42
-
43
-
1.**User Proof Aggregator**
44
-
Processes chunks of `n` user proofs. Each run creates an aggregated proof that commits to a Merkle root of the user proofs inputs. This step is repeated for as many chunks as needed. Usually each chunks contains `256` proofs but it can be lowered based on the machine specs.
45
-
46
-
2.**Chunk Aggregator**
51
+
To scale aggregation without exhausting zkVM memory, aggregation is split into two programs:
52
+
53
+
```
54
+
User Proofs (n per chunk)
55
+
│
56
+
┌───────────────────────┼───────────────────────┐
57
+
│ │ │
58
+
▼ ▼ ▼
59
+
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
60
+
│ Chunk 1 │ │ Chunk 2 │ │ Chunk N │
61
+
│ Aggregator │ │ Aggregator │ │ Aggregator │
62
+
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
63
+
│ │ │
64
+
│ Aggregated Proofs + Merkle Roots │
65
+
│ │ │
66
+
└───────────────────────┼───────────────────────┘
67
+
│
68
+
▼
69
+
┌─────────────────┐
70
+
│ Chunk │
71
+
│ Aggregator │
72
+
└────────┬────────┘
73
+
│
74
+
▼
75
+
┌─────────────────┐
76
+
│ Final Proof + │
77
+
│ Merkle Root │
78
+
└─────────────────┘
79
+
```
80
+
81
+
1.**User Proof Aggregator**
82
+
Processes chunks of `n` user proofs. Each run creates an aggregated proof that commits to a Merkle root of the user proofs inputs. This step is repeated for as many chunks as needed. Usually each chunk contains `256` proofs but it can be lowered based on the machine specs.
83
+
84
+
2.**Chunk Aggregator**
47
85
Aggregates all chunk-level proofs into a single final proof. It receives:
48
86
49
87
- The chunked proofs
50
-
- The original [proofs commitments](#proof-commitment) included each chunk received
88
+
- The original [proofs commitments](#proof-commitment) included in each chunk received
51
89
52
-
During verification, it checks that each chunk’s committed Merkle root matches the reconstructed root to ensure input correctness. The final Merkle root, representing all user [proofs commitments](#proof-commitment), is then committed as a public input.
90
+
During verification, it checks that each chunk's committed Merkle root matches the reconstructed root to ensure input correctness. The final Merkle root, representing all user [proofs commitments](#proof-commitment), is then committed as a public input.
53
91
54
92
## Verification
55
93
56
-
Once aggregated, the proof is sent to Ethereum and verified via the `AlignedProofAggregationService` contract. Depending on the proving system, the contract invokes:
57
-
58
-
-`verifySP1` for SP1 proofs
59
-
-`verifyRisc0` for Risc0 proofs
60
-
61
-
Each function receives:
94
+
Once aggregated, the proof is sent to Ethereum and verified via the `AlignedProofAggregationService` contract. The contract invokes `verifySP1` which receives:
62
95
63
96
- The public inputs
64
97
- The proof binary
@@ -69,17 +102,17 @@ If verification succeeds, the new proof is added to the `aggregatedProofs` map i
69
102
70
103
### Proof Inclusion Verification
71
104
72
-
To verify a user’s proof on-chain, the following must be provided:
105
+
To verify a user's proof on-chain, the following must be provided:
73
106
74
107
- The proof bytes
75
108
- The proof public inputs
76
-
- The program ID
109
+
- The program ID (vk hash)
77
110
- A Merkle proof
78
111
79
-
The Merkle root is computed and checked for existence in the contract using the `verifyProofInclusion` function of the `ProofAggregationServiceContract`, which:
112
+
The Merkle root is computed and checked for existence in the contract using the `verifyProofInclusion` function of the `AlignedProofAggregationService` contract, which:
80
113
81
114
1. Computes the merkle root
82
-
2. Returns `true` or `false` depending if there exists an `aggregatedProof` with the computed root.
115
+
2. Returns `true` or `false` depending on whether there exists an `aggregatedProof` with the computed root.
The aggregation mode currently supports the following proving systems:
14
+
15
+
-**SP1** - Succinct's zkVM (compressed proofs)
16
+
17
+
## Step-by-Step Setup
18
+
19
+
Follow these steps to start the aggregation mode locally using the Ethereum package environment.
20
+
21
+
### 1. Start the Ethereum Package
22
+
23
+
Start the local Ethereum network using Kurtosis:
24
+
25
+
```bash
26
+
make ethereum_package_start
27
+
```
28
+
29
+
This command spins up a local Ethereum network with all necessary components. To stop it run:
30
+
31
+
```bash
32
+
make ethereum_package_rm
33
+
```
34
+
35
+
### 2. Start the Gateway
36
+
37
+
Start the aggregation mode gateway service:
38
+
39
+
```bash
40
+
make agg_mode_gateway_start_ethereum_package
41
+
```
42
+
43
+
The gateway handles proof submissions and manages the proof queue. This command also starts the required Docker containers (PostgreSQL) and runs database migrations automatically.
44
+
45
+
### 3. Start the Payments Poller
46
+
47
+
In a separate terminal, start the payments poller:
48
+
49
+
```bash
50
+
make agg_mode_payments_poller_start_ethereum_package
51
+
```
52
+
53
+
The payments poller monitors the blockchain for payment events and updates user quotas accordingly.
54
+
55
+
### 4. Send a Payment (Deposit)
56
+
57
+
Deposit funds to get quota for submitting proofs:
58
+
59
+
```bash
60
+
make agg_mode_gateway_send_payment
61
+
```
62
+
63
+
This deposits funds using a default test account. For custom deposits, you can use the CLI directly.
64
+
65
+
### 5. Submit a Proof
66
+
67
+
Submit an SP1 proof to the gateway:
68
+
69
+
```bash
70
+
make agg_mode_gateway_send_sp1_proof
71
+
```
72
+
73
+
This sends a test SP1 Fibonacci proof to the gateway.
74
+
75
+
### 6. Start the Proof Aggregator
76
+
77
+
In a separate terminal, start the proof aggregator:
78
+
79
+
```bash
80
+
AGGREGATOR=sp1 make proof_aggregator_start_ethereum_package
81
+
```
82
+
83
+
The proof aggregator fetches pending proofs from the database, aggregates them, and submits the aggregated proof on-chain.
0 commit comments