Transaction Flow
Transactions on the rollup may originate from L1 or directly from the L2.
A transaction that originates on the L1 may be a deposit transaction, where ETH or other assets are bridged onto the L2, or a cross domain function call. An L2 transaction may be a transfer of assets between L2 accounts or a call to a contract deployed on the L2 from an account with funds on the L2. In either case, the transaction is processed by the rollup node, which consists of the sequencer, the execution engine, and the batcher.
The sequencer directs the execution engine as to which transactions should be in a block by adding deposit transactions generated from smart contract events on L1.
The batcher submits L2 transaction batches to the L1, so that users have full data availability. Users can use this data as this is a so-called soft commitment that their transaction is completed. A soft commitment is a commitment that the transaction will be included in the L2 chain, but it is not considered final yet as its execution has not yet been proved.
The execution engine processes the transactions in the batches and results in a new L2 state. The execution engine processes these transactions by putting them in L2 blocks.
These L2 blocks are then processed by Zircuit's zkVM-based proving system using a two-phase approach. In the first phase, Zircuit generates range proofs for several L2 blocks using SP1 (Succinct's zkVM) to prove Kona's execution. These range proofs guarantee that each state transition between L2 blocks was executed correctly - that balances are computed properly, smart contract opcodes execute as intended, and so forth. In the second phase, Zircuit performs aggregate proofs by verifying and combining multiple range proofs together to maximize the number of L2 transactions that get rolled up in a single L1 proof verification.
The proofs for batches of L2 blocks are verified on Ethereum via a smart contract. After verification succeeds, the L2 state root is updated on the relevant contracts, recording the changes contained in the L2 blocks included in the batch whose proof was just verified. At this time, those L2 blocks are considered final. Withdrawals from the L2 are now possible without an additional delay.
The verification of the validity proof concludes the transaction flow at a glance. The next two sections will dive into the processing of deposit, L2, and withdrawal transactions.
Deposits and L2 Transactions
This section covers the architecture related to deposits and L2 transactions in greater detail. A deposit transaction bridges assets like Ether or ERC-20 tokens from Ethereum to Zircuit. An L2 transaction is one that originates on Zircuit itself, like a transfer of Ether between accounts, or smart contract calls on Zircuit.
The following image highlights the specific components of Zircuit that are involved in a deposit or L2 transaction.
Deposit transactions are initiated by calling a smart contract on L1. Two contracts can be used to deposit ETH onto Zircuit: the L1StandardBridge contract and the OptimismPortal smart contract. The L1StandardBridge contract can be used to deposit Ether by calling the appropriate function. The OptimismPortal contract bridges Ether by implementing the receive function, meaning any Ether sent to this contract without specifying a function to call will automatically be bridged.
Only the L1StandardBridge can be used to bridge ERC-20 tokens, and ERC-721 tokens can be bridged via the L1ERC721Bridge contract.
Transactions that originate on L2 naturally do not need to call these smart contracts. Instead, they are sent to the chain via an RPC call or a wallet and are processed directly by the rollup node.
Once the rollup node observes a deposit or receives an L2 transaction, it constructs blocks that contain those transactions via its sequencer functionality.
The rollup node will create deposit transactions for each deposit event observed on L1 and pass these transactions along with any L2 transactions to the execution engine. The execution engine is a modified version of Geth, which supports the deposit transaction type and other minor changes necessary for rollup operation.
The rollup node also passes the transactions included in the blocks to the batcher service, which posts the transactions and their arguments as calldata on the L1, providing full data availability.
At this point, the transaction will be included on the L2 after the provers receive the relevant blocks that contain the transactions; no further interaction from the transaction’s sender is needed.
Withdrawals
Withdrawal transactions take assets like ETH off of Zircuit and return them to the L1. A withdrawal transaction is initiated by first sending an L2 transaction to the L2StandardBridge contract calling the appropriate function.
Once that transaction is included in the L2, the components in the following diagram are relevant to complete the withdrawal transaction.
The withdrawal can be completed when the state root containing the L2 withdrawal transaction is included on L1 with a corresponding proof. A proof is necessary to complete the withdrawal function, as it ensures that the account withdrawing the funds had the funds in the first place.
When the batches have been proven, the resulting state root is pushed to L1 via the L2OutputOracle smart contract alongside a validity proof for the state transition from the last state root. Once the verifier verifies the proof, the state root is recorded as final. Any withdrawals that depend on it can be processed immediately.
Last updated
Was this helpful?