Architecture
Last updated
Last updated
Zircuit is based on a novel hybrid architecture that combines battle-tested rollup infrastructure with zero-knowledge proofs. Its architecture consists of:
Sequencers that process transactions in order to construct L2 blocks
Provers to generate validity proofs for these blocks
Smart contracts to interact with the system on L1
The result is a zkEVM rollup with fast finality that doesn't need a challenge period for withdrawal transactions.
An overview of the transaction flow is illustrated in the following image.
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 provers, each with a specific role. For example, one may prove that a transaction was executed correctly, while another might prove that a relevant Keccak operation was performed correctly; a third may then prove the aggregation of the operations performed by prior two proofs.
As a result, Zircuit leverages parallel proof generation for speedy proof generation, but also proof aggregation to produce a single proof that can be verified on chain. By decomposing circuits into specialized parts and aggregating proofs, Zircuit achieves greater efficiency with lower operating costs. The final validity proof generated is the aggregation of proofs for a batch of L2 blocks.
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..
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.
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.
