Concepts

This page provides a glossary of Zircuit concepts and terms.

Some of these concepts are unique to Zircuit, while others are common rollup terms.

Bridge transaction - a cross chain transaction that requires a bridge component to manage it. Typically bridge transactions lock up assets like ETH or ERC-20 tokens on one chain and mint corresponding assets on another chain, like Zircuit. A deposit transaction is a special case where the source chain is Ethereum and the target chain is Zircuit, while a withdrawal transaction is the special case where the source chain is Zircuit and the target chain is Ethereum.

Cross domain message - data relayed across chains. Typically a cross domain message would contain information representing a function call on a contract on the other chain. Such a function call can be an ERC-20 token transfer, for example.

Sending a cross domain message - the act of sending the message to the cross domain messaging contract on the source chain. Sending a cross domain message requires placing a message on the source chain in the respective smart contract’s state so that it can be processed further. For example, one can send a cross domain message from Ethereum to Zircuit.

Relaying a cross domain message - the act of taking a message that was already sent on the source chain and applying it to the target chain in the form of a transaction. This is the finalization step of cross domain messaging.

Replaying a cross domain message - the act of re-sending an existing Ethereum to Zircuit message with a different gas limit to the cross domain messaging contract on Ethereum. Replaying is not applicable to the Zircuit to Ethereum direction.

Sequencer - an off-chain component which provides transactions to the L2 execution engine. Transactions posted by the batch submitter to Ethereum are determined by the state of L2 derived by the sequencer node. As part of the main rollup node, it also watches Ethereum to derive the state of the L2 from the previously posted batches and state roots, and to observe deposit transactions. The L2 derivation includes checking that previous state roots and transactions were recorded on Ethereum, as well as tracking things like gas price on Ethereum to update relevant values on L2.

Batch submitter - an off-chain component which writes transaction batches, determined by the sequencer, to Ethereum. The batcher provides full data availability on Ethereum for Zircuit. In turn, users have a soft commitment that their transaction will be included and proven in the L2 chain.

Verifier smart contract - a smart contract deployed on Ethereum. It accepts or rejects zero-knowledge proofs constructed for batches of L2 blocks.

Prover - an off-chain component responsible for generating zero-knowledge proofs of state transitions or parts of them. A prover may be very specific or very general. A specific prover may prove a Keccak operation, while a more general one may prove that a block is constructed correctly.

Proof aggregation is the process of collecting multiple proofs, possibly from multiple different circuits, and creating a single proof for all these proofs. More general Zircuit provers may take other proofs as input and may aggregate other proofs, to create a single output. The Zircuit provers are organized by a component called the proof orchestrator, which keeps track of which transitions need to be proved and which proofs need to be aggregated. The input to the proving pipeline is the L2 blocks, and the ultimate result is a validity proof for a batch of blocks.

Proposer - an off-chain component which writes proven updates to the Zircuit state on L1. After the provers generate a validity proof for a batch of blocks, the proposer writes a new state root for the L2. It does this by providing the state root computed by the state transitions within the batch and the validity proof to the Zircuit contracts on Ethereum. The state is accepted when the verifier, as part of the proposer’s call to the contract, verifies the validity proof.

Block status - an L2 block can have one of the following statuses: Waiting for Proof or Proved. A block that has the status Waiting for Proof means that the sequencer has produced the block, but the provers have not yet submitted a state root for a batch which contains the block. A block with the Proved status is one that has been created by the sequencer and is contained in a block batch which was submitted to the verifier contract with a validity proof.

Transaction status - an L2 transaction can have one of the following statuses:

• Success, if the top level call succeeded.

• Pending, if the transaction is in the mempool of the L2.

• Failed, otherwise.

As Zircuit is built in part on the OP Stack, the Optimism glossary may also be helpful.