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
The LxLy bridge is an interoperability solution aimed at enabling cross-chain communication among Polygon chains. It facilitates interaction between two L2 chains or between an L2 chain and Ethereum as the L1.
2
2
3
-
The LXLY Bridge is an interoperability solution aimed at enabling cross-chain communication among Polygon chains. It will enable communication between two L2 chains or between an L2 chain and Ethereum as the L1.
4
-
5
-
The LXLY Bridge SC (or [PolygonZkEVMBridgeV2](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/v2/PolygonZkEVMBridgeV2.sol)) is an improved and a more robust version of the [zkEVM Bridge](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMBridge.sol) deployed in the Polygon zkEVM mainnet_beta version_.
3
+
The LxLy bridge SC (or [PolygonZkEVMBridgeV2](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/v2/PolygonZkEVMBridgeV2.sol)) is an improved and a more robust version of the [zkEVM bridge](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMBridge.sol) deployed in the Polygon zkEVM mainnet_beta version_.
6
4
7
5
Its modular design capacitates projects to deploy their own rollups and connect them to the Polygon ecosystem.
8
6
9
7
## Ideal attributes
10
8
11
-
The LXLY Bridge is deployed in the Polygon ecosystem so as to attain the following features and functionalities;
9
+
The LxLy bridge is deployed in the Polygon ecosystem to enable the following features and functionalities:
12
10
13
11
-**Accessibility**: Projects can request creation of a rollup and connect it to the Polygon ecosystem.
14
-
-**Unified Liquidity**: All rollups can connect through the same bridge, enabling L2 to L2 bridges.
12
+
-**Unified liquidity**: All rollups can connect through the same bridge, enabling L2 to L2 bridges.
15
13
-**Polygon CDK**: All the rollups can use the same stack.
16
-
-**Rollup-Project Oriented**: Every project can have its own rollup.
17
-
-**Cross-Rollup Communication**: All the rollups can communicate using the LxLy bridge.
18
-
-**Rollup Upgradability**: All the deployed rollups should be upgradeable in accordance with its own governance mechanism.
14
+
-**Rollup-project oriented**: Every project can have its own rollup.
15
+
-**Cross-rollup communication**: All the rollups connect and communicate using the LxLy bridge, enabling seamless L2 to L2 bridging.
16
+
-**Rollup upgradability**: All the deployed rollups should be upgradeable in accordance with its own governance mechanism.
19
17
20
-
These functionalities are accomplished by modifying a few key components in the architecture of the zkEVM Bridge Version-1.
18
+
These functionalities are accomplished by modifying a few key components in the architecture of the zkEVM bridge version-1.
21
19
22
-
## zkEVM Bridge Version-1
20
+
## zkEVM bridge version-1
23
21
24
-
Here is a brief review of the zkEVM Bridge's architecture.
22
+
Here is a brief review of the zkEVM bridge's architecture.
25
23
26
-
Version-1 consists mainly of three (3) smart contracts;
24
+
Version-1 consists mainly of three (3) smart contracts:
27
25
28
-
-the Bridge contract ([PolygonZkEVMBridge.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMBridge.sol)), which handles transfer of assets and messages between networks.
29
-
-the Global Exit Root manager contract ([PolygonZkEVMGlobalExitRoot.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMGlobalExitRoot.sol)), which facilitates synchronization of state-info between the L2 and the L1.
30
-
-the Polygon zkEVM Consensus contract ([PolygonZkEVM.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVM.sol)), which handles the sequencing and verification of transactions in the form of batches.
26
+
-The bridge contract ([PolygonZkEVMBridge.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMBridge.sol)), which handles transfer of assets and messages between networks.
27
+
-The global exit root manager contract ([PolygonZkEVMGlobalExitRoot.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVMGlobalExitRoot.sol)), which facilitates synchronization of state-info between the L2 and the L1.
28
+
-The Polygon zkEVM consensus contract ([PolygonZkEVM.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/PolygonZkEVM.sol)), which handles the sequencing and verification of transactions in the form of batches.
31
29
32
-
### Global exit trees Review
30
+
### Global exit trees review
33
31
34
-
Critical to the design of the LXLY Bridge are Exit Trees and the Global Exit Tree.
32
+
Critical to the design of the LxLy bridge are exit trees and the global exit tree.
35
33
36
-
Each chain has a Merkle Tree called an _Exit Tree_, to which a leaf containing data of each asset-transfer is appended. Since such a leaf records data of the asset exiting the chain, it is called an _Exit Leaf_.
34
+
Each chain has a Merkle tree called an _exit tree_, to which a leaf containing data of each asset-transfer is appended. Since such a leaf records data of the asset exiting the chain, it is called an _Exit Leaf_.
37
35
38
-
Another Merkle Tree whose leaves are roots of the various Exit Trees is formed, and it is called the _Global Exit Tree_.
36
+
Another Merkle tree whose leaves are roots of the various exit trees is formed, and it is called the _global exit tree_.
39
37
40
-
The root of the Global Exit Tree is the single source of state-truth communicated between rollups.
38
+
The root of the global exit tree is the single source of state-truth communicated between rollups.
41
39
42
-
It is the Global Exit Root Manager contract's responsibility to update the Global Exit Tree Root and acts as a custodian for the Global Exit Tree's history.
40
+
It is the global exit root manager contract's responsibility to update the global exit tree root and acts as a custodian for the global exit tree's history.
43
41
44
-
A complete transfer of assets in Version-1 involves three smart contracts; the PolygonZkEVM.sol, the PolygonZkEVMBridge.sol and the PolygonZkEVMGlobalExitRoot.sol.
42
+
A complete transfer of assets in version-1 involves invoking three smart contracts; `PolygonZkEVM.sol`, `PolygonZkEVMBridge.sol` and `PolygonZkEVMGlobalExitRoot.sol`.
45
43
46
44
The below figure depicts a _bridge_ of assets and a _claim_ of assets;
47
45
48
46
49
47
50
-
Observe, in the above figure, that the Consensus Contract (PolygonZkEVM.sol) is able to;
48
+
Observe, in the above figure, that the consensus contract (`PolygonZkEVM.sol`) is able to:
51
49
52
-
- Retrieve the Global Exit Root from the mainnet, and make it available in L2, and
53
-
- Update the Exit Tree Root in the Global Exit Tree Root manager.
50
+
- Retrieve the global exit root from the mainnet, and make it available in L2
51
+
- Update the exit tree root in the global exit tree root manager.
54
52
55
-
## LXLY bridge version-2 design
53
+
## LxLy bridge version-2 design
56
54
57
-
Multiple zk-rollups such as zkEVMs, zk-Validiums or zk-VMs, can be created and connected through the same LXLY Bridge.
55
+
Multiple ZK rollups such as zkEVMs, zk-Validiums or zk-VMs, can be created and connected through the same LxLy bridge.
58
56
59
-
Thanks to the introduction of an additional smart contract called the [_Rollup Manager_ SC](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/v2/PolygonRollupManager.sol).
57
+
Thanks to the introduction of an additional smart contract called the [_rollup manager_](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/v2/PolygonRollupManager.sol).
60
58
61
-
Although the logic for _bridging_ or _claiming_ assets from one network to another remains the same, individual L2 Consensus SC no longer handle verification of their own network's sequenced batches.
59
+
Although the logic for _bridging_ or _claiming_ assets from one network to another remains the same, individual L2 consensus contracts no longer handle verification of their own network's sequenced batches.
62
60
63
-
In the LXLY Bridge context, the _Rollup Manager_ SC verifies sequenced batches from various networks.
61
+
In the context of the LxLy bridge, the _rollup manager_ contract verifies sequenced batches from various networks.
64
62
65
-
In addition to verification of sequenced batches, the _Rollup Manager_ SC also creates consensus contracts for networks connecting via the LXLY Bridge.
63
+
In addition to verification of sequenced batches, the _rollup manager_ contract also creates consensus contracts for networks connecting via the LxLy bridge.
66
64
67
65
### What remains unchanged from version-1?
68
66
69
-
The strategy to separate the _Bridge logic_ from the _Global Exit Root logic_ remains intact. This is key to achieving interoperability.
67
+
The strategy to separate the _bridge logic_ from the _global exit root logic_ remains intact. This is key to achieving interoperability.
70
68
71
-
Consensus contracts of each connected network handle the sequencing of their own batches, but send the Batch Data to the _Rollup Manager_ SC for verification.
69
+
Consensus contracts of each connected network handle the sequencing of their own batches, but send the batch data to the _rollup manager_ contract for verification.
72
70
73
-
The _Rollup Manager_ SC stores the information of the sequenced batches in the form of a so-called _Accumulated Input Hash_, as in the Version-1 of the zkEVM Bridge.
71
+
The _rollup manager_ contract stores the information of the sequenced batches in the form of an _accumulated input hash_, as in the version-1 of the zkEVM bridge.
74
72
75
-
Once sequenced batches have been verified, the _Global Exit Tree_ gets updated, in an approach similar to the zkEVM Bridge Version-1.
73
+
Once sequenced batches have been verified, the _global exit tree_ gets updated, in an approach similar to the zkEVM bridge version-1.
76
74
77
75
78
76
79
77
### Rollup manager's role
80
78
81
-
The Rollup Manager manages the following lists of availability;
79
+
The rollup manager is in charge of the following lists of availability:
82
80
83
-
- Rollup consensus mechanisms. The list may consist of Consensus contracts such as PolygonZkEVM.sol or zkValidium.sol.
84
-
- Verifier contracts. For example, the PolygonZkEVM.sol uses the _Verifier.sol_ SC for verification of batches.
81
+
- Rollup consensus mechanisms: The list may consist of consensus contracts such as `PolygonZkEVM.sol` or `zkValidium.sol`.
82
+
- Verifier contracts: For example, the `PolygonZkEVM.sol` uses the `Verifier.sol` contract for verification of batches.
85
83
86
-
Governance SC oversees Consensus mechanisms and Verifiers that can be added to the respective lists.
84
+
The governance contract oversees consensus mechanisms and verifiers that can be added to the respective lists.
87
85
88
-
The [Rollup Manager SC](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/v2/PolygonRollupManager.sol) has the relevant function for adding a new rollup;
86
+
The [rollup manager contract](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/v2ForkID5/contracts/v2/PolygonRollupManager.sol) has the relevant function for adding a new rollup:
89
87
90
88
```bash
91
89
functionaddNewRollupType(
@@ -98,34 +96,34 @@ The [Rollup Manager SC](https://github.com/0xPolygonHermez/zkevm-contracts/blob/
98
96
) ...
99
97
```
100
98
101
-
-In order for a rollup to be created and connected to the LXLY Bridge,
99
+
-To create and connect a rollup to the LxLy bridge,
102
100
103
-
- The developer selects the Consensus and Verifier for the required rollup amongst those available in the Rollup Manager's lists,
101
+
- The developer selects the consensus and verifier for the required rollup amongst those available in the rollup manager's lists,
104
102
- Requests creation of a rollup with the selected specifications,
105
-
- Governance SC invokes the Rollup Manager's `addNewRollupType()` function,
106
-
- Once, a rollup is created, the transfer of assets can be processed in the usual manner.
103
+
- Governance contract invokes the rollup manager's `addNewRollupType()` function,
104
+
- Once a rollup is created, the transfer of assets can be processed in the usual manner.
107
105
108
106
### Overall flow of events
109
107
110
-
The below diagram captures the following flow of events, most of which are handled by the Rollup Manager SC;
108
+
The following diagram captures the following flow of events, most of which are handled by the rollup manager contract:
111
109
112
-
- Updating Rollup Manager's lists,
113
-
- Creating rollups,
114
-
- Sequencing of batches,
115
-
- Aggregation or proving of batches,
116
-
- Verification of batches,
117
-
- Updating the Global Exit Root.
110
+
- Updating rollup manager's lists.
111
+
- Creating rollups.
112
+
- Sequencing of batches.
113
+
- Aggregation or proving of batches.
114
+
- Verification of batches.
115
+
- Updating the global exit root.
118
116
119
117
120
118
121
119
## Conclusion
122
120
123
-
Although the LXLY Bridge is still in development, it is a central component to Polygon's aggregaton layer which offers multi-chain interoperability.
121
+
Although the LxLy bridge is still in development, it is a central component to the AggLayer which offers multi-chain interoperability.
124
122
125
-
The LXLY Bridge currently works with the Polygon zkEVM as the L2 and the Ethereum network as L1.
123
+
The LxLy bridge currently works with the Polygon zkEVM as the L2 and the Ethereum network as L1.
126
124
127
125
The next step is to enable developers wishing to create a zk-rollup to choose between a zkEVM and a zkValidium rollup.
128
126
129
127
The idea of handling verification of several networks in a single contract, is a pre-cursor to the ultimate and envisaged _interop layer_ for the Polygon ecosystem.
130
128
131
-
The code for the LXLY Bridge Version-2 can be found [here](https://github.com/0xPolygonHermez/zkevm-contracts/tree/feature/v2ForkID5/contracts/v2).
129
+
The code for the LxLy bridge version-2 can be found [here](https://github.com/0xPolygonHermez/zkevm-contracts/tree/feature/v2ForkID5/contracts/v2).
Every rollup has a set of distinct identifiers that are essential for its functioning and interaction within the larger network ecosystem.
25
25
26
26
- The $\texttt{chainID}$ is a unique identifier that distinguishes a rollup from other chains in the Ethereum ecosystem, and it is crucial for preventing replay attacks. See the list of chain IDs of different networks [here](https://chainlist.org/).
27
27
- A $\texttt{networkID}$ identifier defines a rollup in the Polygon ecosystem, allowing network participants to uniquely identify and interact with the rollup. The Ethereum mainnet is identified by $\texttt{networkID = 0}$, while the $\texttt{networkID = 1}$ is reserved for the Polygon zkEVM, and so on.
28
28
- The $\texttt{rollupIndex}$ is an identifier used to identify a rollup within the rollup tree. The first rollup, being the Polygon zkEVM, has $\texttt{rollupIndex = 0}$. And in general, $\texttt{rollupIndex = networkID - 1}$.
29
29
30
-
31
-
32
-
## Global Index
30
+
## Global index
33
31
34
32
When creating and verifying proofs, an index called $\texttt{globalIndex}$ is used to uniquely locate a leaf in the new global exit tree.
35
33
36
-
A $\texttt{globalIndex}$ is a 256-bit string composed of; unused bits, mainnet flag, rollup index bits and local root index bits.
37
-
34
+
A $\texttt{globalIndex}$ is a 256-bit string composed of unused bits, mainnet flag, rollup index bits, and local root index bits.
Starting from the most significant bit, a $\texttt{globalIndex}$ consists of the following bits:
45
41
46
42
- $191$ bits of unused bits: These bits are unused, and can be filled with any value. The best option is to fill them with zeros because zeros are cheaper.
47
43
- $1$ bit of mainnet flag: This single bit serves as a flag indicating whether an exit pertains to a rollup (represented by $0$) or the mainnet (indicated by $1$).
48
44
- $32$ bit of the rollup Index: These bits indicate the specific rollup being pointed at, within the rollup exit tree. These bits are therefore only used whenever mainnet flag is $0$.
49
45
- $32$ bits of the local root index: These bits indicate the specific index being pointed at, within each rollup's local exit tree.
50
46
51
-
52
-
53
47
The figure below depicts how the $\texttt{globalIndex}$ is interpreted:
54
48
55
49
- The mainnet exit tree has the $\texttt{globalIndex = X_1_X_3}$, where
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/protocol/unified-LxLy/ulxly-interchain-exchanges.md
+1-3Lines changed: 1 addition & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
This covers node configuration parameters, interchange of tokens among chains, and the mention of an issue with CREATE2.
2
2
3
-
### Node Configuration
3
+
### Node configuration
4
4
5
5
The node configuration for a rollup (or validium) network typically involves specifying various parameters and addresses that are crucial for its operation.
6
6
@@ -32,12 +32,10 @@ Regarding the creation of the ERC-20 tokens with CREATE2:
32
32
- Use $\texttt{salt = 0}$ to create the W-ETH contract.
33
33
- Use $\texttt{salt = tokenInfoHash}$ for the rest of the wrapped tokens of the layer with tokenInfoHash defined as the following hash:
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/protocol/unified-LxLy/ulxly-rollupmanager.md
-3Lines changed: 0 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,8 +61,6 @@ The $\texttt{RollupManager}$ contract has functions; $\texttt{addNewRollupType()
61
61
62
62
It is not possible to create a new rollup of an obsolete rollup type.
63
63
64
-
65
-
66
64
## Rollup data
67
65
68
66
Although several rollups can be of the same $\texttt{RollupType}$, it's important for each rollup store its state data. This state data is included in a structure called $\texttt{RollupData\{\}}$.
@@ -101,4 +99,3 @@ Below is a schematic representation of the transparent proxy pattern within the
Proxies are frequently utilized in Ethereum for upgradability, and the exact usage of proxies in the Polygon zkEVM's upgradability is discussed [here](https://docs.polygon.technology/zkEVM/architecture/protocol/upgradability/).
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/protocol/unified-LxLy/ulxly-updating-rollups.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,5 +38,3 @@ Since the rollup has previously been initialized, the following information need
38
38
- The $\texttt{rollupCompatibilityID}$.
39
39
40
40
Observe that most of these parameters were actually provided by the $\texttt{RollupType}$, but $\texttt{RollupData}$ of already existing rollups is constructed by hand, since they do not follow any rollup type as yet.
0 commit comments