Flow of assets
The X1 bridge is a decentralized bridge that enables users to securely transfer assets between L1 and L2. Here's how it works:
- To bridge an asset from L1 to L2, the user must lock the asset in L1. The L2 bridge smart contract will then mint a wrapped token in L2, representing an equivalent value of the asset. After the minting process is finished, the user or recipient can claim the asset in L2.
- In the opposite operation, after burning the wrapped token in L2, the L1 bridge smart contract unlocks the original asset in L1.
Asset transferring is enabled by three smart contracts:
- The bridge smart contract (
- The global exit root manager (
- The consensus contract (
Please refer to the previous document for more detailed information:
X1 bridge smart contracts
Smart contracts for asset transfer
Flow of assets in X1 bridge
Asset flow from L1 → L2
Bridge function of the zkEVM bridge smart contract (
ZkEVMBridge.sol) on the L1 network is invoked. If the bridge request is valid, the bridge smart contract appends an exit leaf to the L1 exit tree and computes the new L1 exit tree root.
- The Global Exit Root Manager (
ZkEVMGlobalExitRoot.sol) appends the new L1 exit tree root to the global exit tree and computes the global exit root.
- The Sequencer fetches the latest global exit root from the global exit root manager.
- At the start of the transaction batch, the sequencer stores the global exit root in special storage slots of the L2 Global Exit Root Manager smart contract (
ZkEVMGlobalExitRootL2.sol), allowing L2 users to access it.
- In order to complete the bridging process, the user calls the
Claim function of the bridge smart contract and provides a Merkle proof to demonstrate that the correct exit leaf was included and represented in the Global Exit Root.
- The bridge smart contract obtains the L2 Global Exit Root Manager smart contract's global exit root and validates the user's Merkle proof of inclusion. If the Merkle proof is valid, the bridging process succeeds; otherwise, the transaction fails.
Asset flow from L2 → L1
- The user calls the Bridge function of the zkEVM bridge smart contract (
ZkEVMBridge.sol) on Layer 2. If the bridge request is valid, the bridge smart contract appends an exit leaf to the L2 exit tree and computes the new L2 exit tree root.
- The L2 Global Exit Root Manager (
ZkEVMGlobalExitRootL2.sol) is called to append the new L2 exit tree root to the global exit tree and compute the global exit root:
For the sake of simplicity, the intermediate step is not depicted in the figure below. That step is: The user's bridging transaction gets included in one of the batches selected and sequenced by the sequencer.
- The aggregator generates a zk-proof attesting to the computational integrity in the execution of sequenced batches (where one of these batches includes the user's bridging transaction).
- For verification purposes, the aggregator sends the zk-proof together with all relevant batch information that leads to the new L2 exit tree root (computed in step 2 above), to the consensus contract (
- The consensus contract utilizes the
verifyBatches function to verify validity of the received zk-proof. If valid, the consensus contract sends the new L2 Exit Tree Root to the Global Exit Root Manager smart contract (
ZkEVMGlobalExitRoot.sol) in order to update the Global Exit Tree.
- In order to complete the bridging process on the L1 network, the user calls the
Claim function of the bridge smart contract, and provides Merkle proof of the fact that the correct exit leaf was included in the computation of Global Exit Root.
- The bridge smart contract retrieves the global exit root from the L1 Global Exit Root Manager smart contract and verifies validity of the Merkle proof. If the Merkle proof is valid, the bridge smart contract successfully completes the bridging process. Otherwise, the transaction is reverted.
The architecture shown in the diagram below is simplified, emphasizing the connection between different bridge elements.
It doesn't include the interaction between the consensus contract and the sequencer, which is discussed in more detail in earlier subsections of this documentation, particularly in the consensus contract