|
| 1 | +<center> |
| 2 | + |
| 3 | +</center> |
| 4 | + |
| 5 | +### L1 to L2 |
| 6 | + |
| 7 | +1. If a call to `bridgeAsset` or `bridgeMessage` on L1 passes validation, the bridge contract appends an exit leaf to the L1 exit tree and computes the new L1 exit tree root. |
| 8 | + |
| 9 | +2. The global exit root manager appends the new L1 exit tree root to the global exit tree and computes the global exit root. |
| 10 | + |
| 11 | +3. The sequencer fetches the latest global exit root from the global exit root manager. |
| 12 | + |
| 13 | +4. 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, allowing L2 users to access it. |
| 14 | + |
| 15 | +5. A call to `claimAsset` or `claimMessage` provides a Merkle proof that validates the correct exit leaf in the global exit root. |
| 16 | + |
| 17 | +6. The bridge contract validates the caller's Merkle proof against the global exit root. If the proof is valid, the bridging process succeeds; otherwise, the transaction fails. |
| 18 | + |
| 19 | +### L2 to L1 |
| 20 | + |
| 21 | +1. If a call to `bridgeAsset` or `bridgeMessage` on L2 passes validation, the bridge contract appends an exit leaf to the L2 exit tree and computes the new L2 exit tree root. |
| 22 | + |
| 23 | +2. The L2 global exit root manager appends the new L2 exit tree root to the global exit tree and computes the global exit root. At that point, the caller's bridge transaction is included in one of batches selected and sequenced by the sequencer. |
| 24 | + |
| 25 | +3. The aggregator generates a zk-proof attesting to the computational integrity in the execution of sequenced batches which include the transaction. |
| 26 | + |
| 27 | +4. For verification purposes, the aggregator sends the zk-proof together with all relevant batch information that led to the new L2 exit tree root (computed in step 2), to the consensus contract. |
| 28 | + |
| 29 | +5. The consensus contract utilizes the `verifyBatches` function to verify validity of the received zk-proof. If valid, the contract sends the new L2 exit tree root to the global exit root manager in order to update the global exit tree. |
| 30 | + |
| 31 | +6. `claimMessage` or `claimAsset` is then called on the bridge contract with Merkle proofs for correct validation of exit leaves. |
| 32 | + |
| 33 | +7. The bridge contract retrieves the global exit root from the L1 global exit root manager and verifies validity of the Merkle proof. If the Merkle proof is valid, the bridge completes. Otherwise, the transaction is reverted. |
| 34 | + |
| 35 | +### L2 to L2 |
| 36 | + |
| 37 | +1. When a batch of transactions is processed, the bridge contract appends the L2 exit tree with a new leaf containing the batch information. This updates the L2 exit tree root. |
| 38 | + |
| 39 | +2. The bridge contracts communicates the L2 exit tree root to the L2 global exit root manager. The L2 global exit root manager, however, does not update the global exit tree at this stage. |
| 40 | + |
| 41 | +3. For proving and verification, the zk-proof-generating circuit obtains the L2 exit tree root from the L2 global exit root manager. |
| 42 | + |
| 43 | +4. Only after the batch has been successfully proved and verified does the L2 global exit root manager append the L2 exit tree root to the global exit tree. As a result, the global exit root is updated. |
| 44 | + |
| 45 | +5. The zk-proof-generating circuit also writes the L2 exit tree root to the mainnet. The L1 bridge contract can then finalize the transfer by using the `claim` function. |
0 commit comments