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
Polygon 2.0 envisions a protocol layer that seamlessly connects any ZK-enabled L2 or L1 chain. This layer of interoperability is referred to as the **aggregation layer**, or **AggLayer**.
4
4
5
-
This post is a direct reproduction of [**the original blog post**](https://hackmd.io/@QOKsDTFRSd-1oYqrNQ3fIA/Hkx9X3jah) made by Brendan Farmer, Co-founder @ Polygon
5
+
In this document, we look at:
6
6
7
-
Polygon 2.0 envisions a protocol layer that seamlessly connects any ZK-enabled Layer-2 (L2) or Layer-1 (L1) chain. This layer of interoperability is referred to as the **aggregation layer**, or **AggLayer**.
7
+
* What AggLayer is and the problems it addresses.
8
+
* A brief overview of how the AggLayer is implemented.
9
+
* The advantages of using an aggregated solution.
8
10
9
-
In this post, we'll be looking at:
11
+
## Polygon's networks topology
10
12
11
-
* what AggLayer is and the problems it addresses
12
-
* a brief overview of how the AggLayer is implemented
13
-
* the advantages of using an aggregated solution
13
+
Polygon Labs currently runs two main chains in production.
14
14
15
-
## Overview
15
+
The first is[ Polygon POS chain](https://docs.polygon.technology/pos/overview/), which is basically the rebranded and upgraded version of the former Matic network. A network that brings with it a massive ecosystem, where top brands such as Starbucks and Nike exist.
16
16
17
-
At this point, interoperability protocols rely heavily on bridging to connect what are essentially isolated networks. This translates to fragmented liquidity, and makes for a less than ideal user experience.
17
+
The second is[ Polygon zkEVM](https://docs.polygon.technology/zkEVM/overview/), a rollup aiming at becoming a Type-2 zkEVM, where users have the same UX as in Ethereum, enjoy the security of Ethereum, and partners have access to a huge developer community.
18
18
19
-
Polygon 2.0's AggLayer proposes a solution to that problem by acting as the service layer that aggregates ZK proofs generated by different chains, and co-ordinates cross-chain transactions. We're working with the assumption that ***atomic cross-chain transaction execution is necessary for cross-chain asset exchange***.
19
+
The experience gained since launching Polygon zkEVM in March 2023, has culminated in the POS chain upgraded to a zero-knowledge validium as announced in[ June, 2023](https://polygon.technology/blog/polygon-2-0-polygon-pos-zk-layer-2).
20
20
21
-
!!! tip
21
+
Polygon Labs further harnessed its ZK-technology by introducing the Chain Development Kit ([CDK](https://docs.polygon.technology/cdk/overview/)), and thus allowing businesses to build their own customizable blockchains. With the CDK, builders can pick and choose between a zk-rollup and a validium, as well as select either a Type-2 or Type-1 prover.
22
22
23
-
To read up more on atomic cross-chain transactions, check out [this article on shared validity sequencing](https://www.umbraresearch.xyz/writings/shared-validity-sequencing).
24
23
25
-
In this context, "atomic" means a user can send a set of transactions to multiple chains, and they can be certain that either all of the transactions will be executed succesfully, or none of them will be included on any of the chains.
26
24
27
-
The most basic example of this is a cross-chain transfer. Let’s say that Alice wants to send 1 ETH to Bob, but Alice is on Rollup A, and Bob is on Rollup B. Assuming a shared native bridge for both rollups, Alice can burn her ETH on Rollup A and mint ETH on Rollup B which is transferred to Bob. But it’s critical to guarantee that she can’t mint ETH without burning it or vice-versa - either she could lose her ETH or under-collateralize the bridge.
This is why we need atomic transactions to ensure low-latency interactions between the chains so the UX *feels* like using a single chain with the Polygon ecosystem. Any L1 or L2 connecting to the Polygon AggLayer, these chains still maintain complete sovereignty, but the ecosystem delivers **high composability** and **uniform cryptographic security** with Ethereum as the global settlement layer.
30
27
31
-
##AggLayer design sketch
28
+
### Fragmented liquidity
32
29
33
-
The Polygon network topology consists of many L2 chains and a single AggLayer, which can be centralized or decentralized. L2 chains submit proofs and state updates to the AggLayer, and the proofs are aggregated and submitted to Ethereum. This design sketch will have three components:
34
-
- Proof aggregation
35
-
- Optimistic batch confirmation
36
-
- Atomic cross-chain interaction
30
+
Although the above setting gives developers the freedom to build on chains that suit their needs, or design their own chains, such a setup lacks cross-chain interoperability.
31
+
32
+
As seen in the above diagram, each chain connects directly to Ethereum. Since every chain has its separate and exclusive bridge contract, any transfer of assets from Chain A to Chain B must go via Ethereum. This means a simple cross-chain transfer of assets involves more chain interactions than necessary.
33
+
34
+
Reliance on bridging in order to connect what are essentially isolated networks, is a common interoperability solution. But it translates to fragmented liquidity, and a less than ideal user experience.
35
+
36
+
37
+
### Atomic guarantees
38
+
39
+
Let's take a deeper look at cross-chain transfers.
40
+
41
+
First of all, we understand execution of atomic cross-chain transactions to mean that, with every set of transactions a user submits to multiple chains, the user has the guarantee that either all transactions are execute succesfully or none of them is included in any chain.[^1]
42
+
43
+
Consider the following example as a typical cross-chain transfer.
44
+
45
+
#### Atomic transfer example
46
+
47
+
Suppose Alice, who is on rollup A, wants to send 1 ETH to Bob who is on rollup B.
48
+
49
+
Assuming a shared native bridge for both rollups;
50
+
51
+
- Alice burns her 1 ETH on rollup A and mints 1 ETH on rollup B.
52
+
- The 1 ETH minted by Alice gets transferred to Bob.
53
+
54
+
Critical in this is to guarantee that it should be impossible for Alice to do any of the following two things:
55
+
56
+
1. Mint 1 ETH on rollup B without burning 1 ETH on rollup A.
57
+
2. Burn 1 ETH on rollup A without being able to mint 1 ETH on B.
58
+
59
+
The security of atomic transactions is based on this critical guarantee that users do not lose their funds and cannot double spend their tokens.
60
+
61
+
Therefore, key to realising a unified Polygon ecosystem is atomic guarantees.
62
+
63
+
64
+
## AggLayer design
65
+
66
+
As mentioned above, the Polygon network topology consists of several L2 chains that are somewhat fragmented when it comes to liquidity.
67
+
68
+
The solution to this fragmentation is a single AggLayer, which can be setup as either centralized or decentralized.
69
+
70
+
This means L2 chains submit proofs and state updates to the AggLayer, where the proofs are aggregated and submitted to Ethereum.
71
+
72
+
The overall design of AggLayer is outlined in three parts:
73
+
74
+
- Proof aggregation.
75
+
- Optimistic batch confirmation.
76
+
- Atomic cross-chain interaction.
77
+
78
+
Let's go over each part in detail.
37
79
38
-
Let's go over each component in detail.
39
80
40
81
### Proof aggregation
41
82
42
-
The `submitBatch` data interface used to transmit proofs between chains and the AggLayer, which is of the form:
83
+
<!-- Multiple chains post proofs to the AggLayer that are then aggregated before being published to Ethereum. This way, the Polygon ecosystem can post an unlimited number of chain updates for the cost of a single chain’s update, amortizing the cost of proof verification across many more transactions, and allowing for more frequent finalization. -->
84
+
85
+
Here's what happens in the AggLayer when users interact with individual Polygon chains $C_i$.
86
+
87
+
<!-- These can be thought of as copies of the Polygon zkEVM chain. -->
88
+
89
+
1. Users submit transactions to each chain $C_i$. As usual, the sequencer of each $C_i$ (whether centralized or decentralized) orders and executes the transactions. Then generates a proof $\pi_i$ attesting to the fact that the updated state $S_i'$ of each $C_i$ is valid and is consistent with a list of messages for each chain $M_i$.
90
+
91
+
2. Rather than submitting proofs $\{ \pi_i \}$ to Ethereum, chains submit $\{\pi_i, S_i', M_i\}$ to the AggLayer, which can run as a centralized or decentralized service.
92
+
93
+
3. The AggLayer takes as inputs the proofs $\{\pi_i\}$ and the associated states $\{S'_i\}$ and the message list $\{M_i\}$. It arranges the proofs $\{\pi_i\}$ in a binary tree ordered by index, where each $\pi_i$ is assigned to a leaf node.
94
+
95
+
4. For each proof $\pi_i$, the AggLayer generates a commitment to all messages $\{M_j\}$ associated with that proof.
96
+
97
+
5. At each parent node, the AggLayer generates a recursive proof $\pi'_i$ that verifies that both child proofs are valid, and a commitment to the union of messages associated with both child nodes.
98
+
99
+
6. For the root node, the AggLayer produces an aggregated proof $\pi_{\text{final}}'$ which guarantees that all proofs for all chains in the Polygon ecosystem are valid, and that the messages $\{M_i\}$ associated with all chains are consistent with the proof $\pi_{\text{final}}'$.
100
+
101
+
7. Optionally, the aggregated proof can also guarantee that a list of updated state roots $S_i$ is valid.
102
+
103
+
After producing the aggregated proof $\pi_{\text{final}}'$, the AggLayer posts that proof to Ethereum, along with a commitment to the message lists $M_i$.
104
+
105
+
The above procedure is depicted in the simplified diagram below.
There's a subtle detail about validiums that needs to be noted.
115
+
116
+
For all rollup chains, we have all data necessary to retrieve the proof of inclusion for a particular message in some list $M_i$.
117
+
118
+
But this is not so validium chains. For instance, there could be a 'data withholding' attack.
119
+
120
+
So we need to ensure that 'data withholding' attacks do no affect validium users' ability to process an exit or message from a rollup.
121
+
122
+
The solution that enables validium users to circumvent 'data withholding' attacks is, segmentation of rollup and validium message lists, as well as optionally posting the commitment to the message list for all validium nodes to Ethereum.
123
+
124
+
125
+
#### Proof aggregation interface
126
+
127
+
The `submitBatch` data interface used to transmit proofs between chains and the AggLayer, involves the following data elements. The below table records the interface data elements, their types and brief descriptions.
@@ -51,21 +136,7 @@ The `submitBatch` data interface used to transmit proofs between chains and the
51
136
| Calldata | Vec<Calldata> | Calldata that must be posted to Ethereum |
52
137
| Cross-Chain Dependencies | Vec<*> | Cross-chain state root dependencies and bundles that the batch builds on. |
53
138
54
-
Multiple chains post proofs to the AggLayer that are then aggregated before being published to Ethereum. This way, the Polygon ecosystem can post an unlimited number of chain updates for the cost of a single chain’s update, amortizing the cost of proof verification across many more transactions, and allowing for more frequent finalization.
55
-
56
-
Users interact with individual Polygon chains $C_i$. These can be thought of as copies of the Polygon zkEVM chain. They submit transactions to each $C_i$, and then for each $C_i$, the sequencer (centralized or decentralized) orders and executes them, and then generates a $\pi_i$ proof showing that the updated state $S_i'$ of each $C_i$ is valid and is consistent with a list of messages for each chain $M_i$.
57
139
58
-
From here, rather than submitting $\pi_i$ to Ethereum, chains submit $\pi_i$, $S'_i$, and $M_i$ to the AggLayer, which can run as a centralized or decentralized service.
59
-
60
-
The AggLayer takes in $\pi_i$ and the associated $S'_i$ and the message list $M_i$. It arranges the $\pi_i$ in a binary tree ordered by index, where each $\pi_i$ is assigned to a leaf node.
61
-
62
-
For each $\pi_i$, the AggLayer generates a commitment to all messages $M_i$ associated with that proof. At each parent node, the AggLayer generates a recursive proof $\pi'_i$ that verifies that both child proofs are valid, and a commitment to the union of messages associated with both child nodes.
63
-
64
-
By the root node, the AggLayer will produce an aggregated proof $\pi'$ that guarantees that all proofs for all chains in the Polygon ecosystem are valid and that the messages $M_i$ associated with all chains are consistent with the proof. Optionally, the aggregated proof can also guarantee that a list of updated state roots $S_i$ is valid.
65
-
66
-
After producing the aggregated proof $\pi'$, the AggLayer posts that proof to Ethereum, along with a commitment to the message lists $M_i$.
67
-
68
-
There's one subtle detail - we know that for all rollup chains, we'll have all data necessary to retrieve the proof of inclusion for a particular message in some list $M_i$. But we don't know this for all validium nodes, so we need to ensure that a withholding attack (with cooperation from the AggLayer) on a validium can't affect a user's ability to process an exit or message from a rollup. This can be achieved by segmenting rollup and validium message lists and optionally posting a commitment to the message list for all validium nodes to Ethereum.
69
140
70
141
71
142
### Optimistic confirmation
@@ -78,16 +149,6 @@ In order to reduce latency to levels that make cross-chain interactions feel lik
78
149
1. A proof is generated (validity).
79
150
2. A batch is posted to Ethereum (finality).
80
151
81
-
The `SubmitBatchWithoutProof` data interface is used to post tx batches to the Agglayer without a validity proof, and is of the form:
| Calldata | Vec<Calldata> | Calldata that must be posted to Ethereum |
90
-
|*Cross-Chain Dependencies*| Vec<*> |*Cross-chain state root dependencies and bundles that the batch builds on.*|
91
152
92
153
#### Finality
93
154
@@ -113,6 +174,22 @@ Fundamentally, this approach provides safety because it guarantees that a batch
113
174
114
175
This is critical, because otherwise Chain B could read a message from Chain A, mint some number of tokens, and then Chain A could equivocate and mint the same number of tokens on Chain C, undercollateralizing the bridge. Using this approach, we can obtain both low latency and safety.
115
176
177
+
#### Optimistic-case interface
178
+
179
+
The `SubmitBatchWithoutProof` data interface is used to post batches to the Agglayer without a validity proof, and is of the form:
| Calldata | Vec<Calldata> | Calldata that must be posted to Ethereum |
188
+
|*Cross-Chain Dependencies*| Vec<*> |*Cross-chain state root dependencies and bundles that the batch builds on.*|
189
+
190
+
191
+
192
+
116
193
### Atomic Cross-Chain Interaction
117
194
118
195
The final part of the unified liquidity vision is to enable cross-chain atomic interactions. Cross-chain interactions as we've described them are only asynchronous - Chain A must submit a batch and message queue, then Chain B must submit a transaction in a new batch that reads from Chain A's message queue, and so on.
@@ -151,18 +228,18 @@ We want to instead provide truly seamless interaction and give users the experie
The atomic mode for cross-chain interaction largely follows the Shared Validity Sequencing approach, with the caveat that no shared sequencer is required for all chains.
159
232
160
233
1. Users submit atomic bundles of transactions to the aggregator layer. For each bundle, an Aggregator Worker is spun up. The worker is a process running on a single node, charged with ensuring execution of all transactions in the bundle before the bundle can be included in a batch.
161
234
2. Transactions from the bundle are forwarded to their respective chains by the worker.
162
235
3. Chains take a lock on the state affected by each transaction and sequence the bundle in a new block, returning the resulting message queue to the worker. If another transaction is received that touches state affected by the bundle, it's queued for execution until after the bundle is either confirmed or rejected.
163
236
4. If each transaction in the bundle executed correctly and the resulting message queues are consistent (ie tokens minted matches tokens burned), then the bundle is included by the aggregation layer.
164
237
5. Each chain generates a validity proof for the block containing the bundle. When all validity proofs are received by the AggLayer, chains can release the lock on affected state and execute queued transactions.
165
-
238
+
239
+
240
+
241
+
242
+
166
243
#### Failure Modes
167
244
168
245
**Liveness**: A malicious user can collude with a malicious chain and submit a bundle that's known to fail on a specific chain. The colluding chain will claim successful execution, the remaining chains will generate proofs, but the colluding chain will never submit a proof, causing the bundle to time out.
@@ -178,3 +255,11 @@ Similar to the liveness attack, this will cause degradation of UX, but it's not
178
255
Aggregation presents a solution to the monolothic vs. modular chain design dilemma. It takes the performance gains and efficient resource usage of modular architecture and combines it with the unified experience of a monolothic system.
179
256
180
257
The AggLayer will allow a single ZK proof to verify state across all chains in the ecosystem and use Ethereum as the settlement layer. Once any chain publishes a ZK proof of its latest state to the AggLayer, all other chains can trust the value (state) of that chain.
258
+
259
+
260
+
!!! credits
261
+
262
+
The contents of this document were sourced from [a blog post](https://hackmd.io/@QOKsDTFRSd-1oYqrNQ3fIA/Hkx9X3jah) originally written by Brendan Farmer, Co-founder @ Polygon
263
+
264
+
265
+
[^1]: Definition taken from "Shared Sequencing: Defragmenting the L2 Rollup Ecosystem" https://hackmd.io/@EspressoSystems/SharedSequencing by Espresso Systems
0 commit comments