Skip to content

Commit 374482b

Browse files
Merge pull request 0xPolygon#180 from 0xPolygon/empieichO-docs-review
Update Learn - AggLayer doc
2 parents c348890 + 9400660 commit 374482b

File tree

1 file changed

+13
-12
lines changed

1 file changed

+13
-12
lines changed

docs/learn/agglayer.md

Lines changed: 13 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Aggregation layer
22

3-
Solving the scalability problem in blockchains means scaling access to shared state and liquidity across many chains. To do so requires a new approach to blockchain architecture, namely, aggregated blockchains. Polygon Labs researchers and engineers have designed a solutionthe **aggregation layer**, or **AggLayer**which will seamlessly connect any ZK-enabled L2 or L1 chain.
3+
Solving the scalability problem in blockchains means scaling access to shared state and liquidity across many chains. To do so requires a new approach to blockchain architecture, namely, aggregated blockchains. Polygon Labs researchers and engineers have designed a solution -- the **aggregation layer**, or **AggLayer** -- which will seamlessly connect any ZK-enabled L2 or L1 chain.
44

55
In this document, we look at:
66

@@ -82,7 +82,7 @@ Here's what happens in the AggLayer when users interact with individual Polygon
8282

8383
7. Optionally, the aggregated proof can also guarantee that a list of updated state roots $S_i$ is valid.
8484

85-
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$.
85+
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\}$.
8686

8787
The above procedure is depicted in the simplified diagram below.
8888

@@ -95,7 +95,7 @@ The above procedure is depicted in the simplified diagram below.
9595

9696
There's a subtle detail about validiums that needs to be noted.
9797

98-
For all rollup chains, we have all data necessary to retrieve the proof of inclusion for a particular message in some list $M_i$.
98+
For all rollup chains, we have all data necessary to retrieve the proof of inclusion for a particular message in some list $\{M_i\}$.
9999

100100
But this is not so with validium chains. For instance, there could be a 'data withholding' attack.
101101

@@ -106,16 +106,16 @@ The solution that enables validium users to circumvent 'data withholding' attack
106106

107107
#### Proof aggregation interface
108108

109-
The `submitBatch` data interface is 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.
109+
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.
110110

111111
| Field | Type | Description |
112112
| :----------------------: | :-------------: | ------------------------------------------------------------------------- |
113113
| Chain ID | Int | Identifier for chain submitting a batch and proof |
114114
| New State Root | u256 | Commitment to the updated chain state |
115115
| Batch Proof | Plonky2/3 Proof | Proof guaranteeing validity of batch of tx |
116116
| Consensus Proof | Plonky2/3 Proof | Proof of consensus for decentralized sequencers/signature for centralized |
117-
| Message Queue | Vec<Message> | LxLy message queue resulting from batch |
118-
| Calldata | Vec<Calldata> | Calldata that must be posted to Ethereum |
117+
| Message Queue | Vec&lt;Message&gt; | LxLy message queue resulting from batch |
118+
| Calldata | Vec&lt;Calldata&gt; | Calldata that must be posted to Ethereum |
119119
| Cross-Chain Dependencies | Vec<*> | Cross-chain state root dependencies and bundles that the batch builds on. |
120120

121121

@@ -127,9 +127,10 @@ The problem with the aggregation layer, as described, is that it suffers from hi
127127

128128
Currently, proving time for a batch is a few minutes, and batches are posted to Ethereum every 30-60 minutes, which prohibits fast cross-chain messaging and interoperability.
129129

130-
In order to reduce latency to levels that make cross-chain interactions feel like using a single chain, we need to safely confirm batches before:
131-
1. A proof is generated (validity).
132-
2. A batch is posted to Ethereum (finality).
130+
In order to reduce latency to levels that make cross-chain interactions feel like using a single chain, we need to safely confirm batches before:
131+
132+
1. A proof is generated (validity).
133+
2. A batch is posted to Ethereum (finality).
133134

134135

135136
#### Finality
@@ -164,9 +165,9 @@ The `SubmitBatchWithoutProof` data interface is used to post batches to the Aggl
164165
| :------------------------: | :------------: | :-------------------------------------------------------------------------- |
165166
| Chain ID | Int | Identifier for chain submitting a batch and proof |
166167
| New State Root | u256 | Commitment to the updated chain state |
167-
| Consensus Witness | Vec<Signature> | Witness required to verify consensus for a chain |
168-
| Message Queue | Vec<Message> | LxLy message queue resulting from batch |
169-
| Calldata | Vec<Calldata> | Calldata that must be posted to Ethereum |
168+
| Consensus Witness | Vec&lt;Signature&gt; | Witness required to verify consensus for a chain |
169+
| Message Queue | Vec&lt;Message&gt; | LxLy message queue resulting from batch |
170+
| Calldata | Vec&lt;Calldata&gt; | Calldata that must be posted to Ethereum |
170171
| *Cross-Chain Dependencies* | Vec<*> | *Cross-chain state root dependencies and bundles that the batch builds on.* |
171172

172173

0 commit comments

Comments
 (0)