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 will enable communication between two L2 chains or between an L2 chain and Ethereum as the L1.
1
+
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 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_.
4
4
5
5
Its modular design capacitates projects to deploy their own rollups and connect them to the Polygon ecosystem.
6
6
7
7
## Ideal attributes
8
8
9
-
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:
10
10
11
11
-**Accessibility**: Projects can request creation of a rollup and connect it to the Polygon ecosystem.
12
12
-**Unified liquidity**: All rollups can connect through the same bridge, enabling L2 to L2 bridges.
13
13
-**Polygon CDK**: All the rollups can use the same stack.
14
14
-**Rollup-project oriented**: Every project can have its own rollup.
15
-
-**Cross-rollup communication**: All the rollups can communicate using the LxLy bridge.
15
+
-**Cross-rollup communication**: All the rollups connect and communicate using the LxLy bridge, enabling seamless L2 to L2 bridging.
16
16
-**Rollup upgradability**: All the deployed rollups should be upgradeable in accordance with its own governance mechanism.
17
17
18
18
These functionalities are accomplished by modifying a few key components in the architecture of the zkEVM bridge version-1.
@@ -21,69 +21,69 @@ These functionalities are accomplished by modifying a few key components in the
21
21
22
22
Here is a brief review of the zkEVM bridge's architecture.
23
23
24
-
Version-1 consists mainly of three (3) smart contracts;
24
+
Version-1 consists mainly of three (3) smart contracts:
25
25
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.
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.
29
29
30
30
### Global exit trees review
31
31
32
-
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.
33
33
34
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_.
35
35
36
-
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_.
37
37
38
-
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.
39
39
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.
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.
41
41
42
-
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`.
43
43
44
44
The below figure depicts a _bridge_ of assets and a _claim_ of assets;
45
45
46
46
47
47
48
-
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:
49
49
50
-
- Retrieve the Global exit root from the mainnet, and make it available in L2, and
51
-
- 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.
52
52
53
-
## LXLY bridge version-2 design
53
+
## LxLy bridge version-2 design
54
54
55
-
Multiple zk-rollups such as zkEVMs, zk-Validiums or zk-VMs, can be created and connected through the same LXLY ridge.
55
+
Multiple ZK rollups such as zkEVMs, zk-Validiums or zk-VMs, can be created and connected through the same LxLy bridge.
56
56
57
-
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).
58
58
59
-
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.
60
60
61
-
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.
62
62
63
-
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.
64
64
65
65
### What remains unchanged from version-1?
66
66
67
-
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.
68
68
69
-
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.
70
70
71
-
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.
72
72
73
-
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.
74
74
75
75
76
76
77
77
### Rollup manager's role
78
78
79
-
The Rollup manager is in charge of the following lists of availability;
79
+
The rollup manager is in charge of the following lists of availability:
80
80
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_ 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.
83
83
84
-
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.
85
85
86
-
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:
87
87
88
88
```bash
89
89
functionaddNewRollupType(
@@ -96,34 +96,34 @@ The [Rollup manager SC](https://github.com/0xPolygonHermez/zkevm-contracts/blob/
96
96
) ...
97
97
```
98
98
99
-
-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,
100
100
101
-
- 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,
102
102
- Requests creation of a rollup with the selected specifications,
103
-
- Governance SC invokes the Rollup manager's `addNewRollupType()` function,
104
-
- 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.
105
105
106
106
### Overall flow of events
107
107
108
-
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:
109
109
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.
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.
116
116
117
117
118
118
119
119
## Conclusion
120
120
121
-
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.
122
122
123
-
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.
124
124
125
125
The next step is to enable developers wishing to create a zk-rollup to choose between a zkEVM and a zkValidium rollup.
126
126
127
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.
128
128
129
-
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).
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/zkprover/hashing-state-machines/paddingkk-bit-sm.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,11 +14,11 @@ A block of 136 rows of bytes in the Padding-KK SM corresponds to $\mathtt{1993}$
14
14
15
15
16
16
17
-
**First subdivision:** Consists of $\mathtt{9*136 = 1224}$ rows, where each of the $\mathtt{136}$ byte-rows has been expanded into $\mathtt{9}$ rows (i.e., $\mathtt{8}$ rows for the $\mathtt{8}$ bits plus $\mathtt{1}$ row for the byte that represents the $\mathtt{8}$ bits). The decomposition of the bytes into the 8 bits (with an extra row, just for the byte), is done for easy implementation in PIL. This subdivision of $\mathtt{1224}$ rows represents the bitrate of the KECCAK-F permutation. Therefore, a strategy to ensure that the bits are accurately and correctly provided, as input to the KECCAK-F SM, needs to be derived.
17
+
First subdivision: Consists of $\mathtt{9*136 = 1224}$ rows, where each of the $\mathtt{136}$ byte-rows has been expanded into $\mathtt{9}$ rows (i.e., $\mathtt{8}$ rows for the $\mathtt{8}$ bits plus $\mathtt{1}$ row for the byte that represents the $\mathtt{8}$ bits). The decomposition of the bytes into the 8 bits (with an extra row, just for the byte), is done for easy implementation in PIL. This subdivision of $\mathtt{1224}$ rows represents the bitrate of the KECCAK-F permutation. Therefore, a strategy to ensure that the bits are accurately and correctly provided, as input to the KECCAK-F SM, needs to be derived.
18
18
19
-
**Second subdivision:** Consists of the $\mathtt{512}$ rows, and represents the capacity input-bits in the $\mathtt{1600}$-bit state of the KECCAK-F SM. Within the KECCAK-F state machine, unlike the bits in the first subdivision of $\mathtt{1224}$ rows, the capacity bits are not affected by any exterior bits.
19
+
Second subdivision: Consists of the $\mathtt{512}$ rows, and represents the capacity input-bits in the $\mathtt{1600}$-bit state of the KECCAK-F SM. Within the KECCAK-F state machine, unlike the bits in the first subdivision of $\mathtt{1224}$ rows, the capacity bits are not affected by any exterior bits.
20
20
21
-
**Third subdivision:** Consists of $\mathtt{256 + 1}$ rows represents the 256 bits of the intermediate hash value produced by the KECCAK-F permutation. At the end of hashing each 1088 bits (136-byte) string, this intermediate hash value actually coincides with the final hash of the KECCAK-256 hash function. Each hash value, the final digest, is packed into eight 32-bit registers at the final row of this subdivision.
21
+
Third subdivision: Consists of $\mathtt{256 + 1}$ rows represents the 256 bits of the intermediate hash value produced by the KECCAK-F permutation. At the end of hashing each 1088 bits (136-byte) string, this intermediate hash value actually coincides with the final hash of the KECCAK-256 hash function. Each hash value, the final digest, is packed into eight 32-bit registers at the final row of this subdivision.
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/zkprover/main-state-machine/index.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,12 +16,12 @@ It is a piece of software, composed of a set of instructions, which implements a
16
16
17
17
All EVM opcodes are interpreted in the ROM, as well as interpretation of batches and the execution logic of transactions. The ROM is therefore the interpreter of all opcodes to the Polygon zkEVM, allowing the main SM to execute Polygon zkEVM's L2 state transitions with _computational integrity_.
18
18
19
-
!!!info
19
+
!!!info
20
20
In order to avoid any misunderstandings in the future, it is helpful to distinguish between the set of ROM instructions and EVM opcodes:
21
21
22
-
**ROM Instructions**: Set of instructions created and developed by Polygon to target a ”special” zero-knowledge virtual machine (main SM) that can execute computations with probable _computational integrity_.
22
+
ROM Instructions: Set of instructions created and developed by Polygon to target a ”special” zero-knowledge virtual machine (main SM) that can execute computations with probable _computational integrity_.
23
23
24
-
**EVM opcodes**: Set of instructions designed to target the EVM, used to define smart contract’s computations.
24
+
EVM opcodes: Set of instructions designed to target the EVM, used to define smart contract’s computations.
25
25
26
26
Although zkASM instructions and EVM opcodes are different types of instructions, the Polygon zkEVM's ROM contains a piece of code written in zkASM instructions to implement each EVM opcode.
0 commit comments