Rollup Process

This document provides an overview of the rollup process within the Wischain ecosystem.

Workflow Overview

The rollup process is illustrated through a structured workflow involving several key components. The Layer 2 (L2) sequencer comprises three essential modules:

1. Sync Service: This module subscribes to events emitted from the Layer 1 (L1) bridge contract. When it detects newly appended messages in the L1 inbox, the Sync Service generates a new L1MessageTx transaction and adds it to the local L1 transaction queue.

2. Mempool: The mempool collects transactions that users submit directly to the L2 sequencer.

3. Executor: This module pulls transactions from both the L1 transaction queue and the L2 mempool, executing them to create a new L2 block.

The rollup node consists of three additional modules:

1. Relayer: This module is responsible for submitting commit transactions and finalizing transactions to the rollup contract, ensuring data availability and finality.

2. Chunk Proposer: This module proposes new chunks following the constraints outlined in the Transaction Batching guidelines.

3. Batch Proposer: Similar to the Chunk Proposer, but focused on proposing new batches of transactions.

The rollup process can be divided into three main phases: transaction execution, batching and data commitment, and proof generation and finalization.

Phase 1: Transaction Execution

• Users initiate transactions to either the L1 bridge contract or the L2 sequencer.

• The Sync Service in the L2 sequencer retrieves the latest appended L1 transactions from the bridge contract.

• The L2 sequencer processes transactions from both the L1 message queue and the L2 mempool to construct L2 blocks.

Phase 2: Batching and Data Commitment

• The rollup node continuously monitors the latest L2 blocks and gathers transaction data.

• If the defined criteria (as described in the Transaction Batching section) are met, the rollup node proposes a new chunk or batch and writes it to the database. If the criteria are not met, the rollup node will wait for additional blocks or chunks.

• Once a new batch is created, the rollup relayer collects the transaction data from this batch and submits a Commit Transaction to the rollup contract for data availability.

Phase 3: Proof Generation and Finalization

When the coordinator identifies a new chunk or batch in the database:

• For a new chunk, the coordinator queries the execution traces of all blocks in this chunk from the L2 sequencer and sends a chunk proving task to a randomly selected zkEVM prover.

• For a new batch, the coordinator gathers the chunk proofs of all chunks within this batch from the database and assigns a batch proving task to a randomly selected aggregator prover.

Upon receiving the proofs for a chunk or batch from a prover, the coordinator records the proof in the database. Once the rollup relayer retrieves a new batch proof from the database, it submits a Finalize Transaction to the rollup contract to verify the proof.

Commit Transaction

The Commit Transaction is critical for submitting block information and transaction data to Layer 1 for data availability. This transaction contains several components:

• The parent batch header links to the previous batch.

• Chunk data provides the details of the proposed transactions.

• A bitmap of skipped L1 messages is included to address potential proof overflow issues. This occurs when the L1 transaction associated with an L1 message exceeds the circuit's capacity, making it impossible to generate a valid proof.

The function signature for committing a batch with a blob proof is as follows:

function commitBatchWithBlobProof(
    uint8 version,
    bytes calldata parentBatchHeader,
    bytes[] memory chunks,
    bytes calldata skippedL1MessageBitmap,
    bytes calldata blobDataProof
) external;

Upon verifying that the parent batch is already committed, the function constructs the batch header and stores its hash in the Wischain contract:

mapping(uint256 => bytes32) public committedBatches;

The encoding for the batch header and chunk data is detailed in the Codec section. Most fields in the batch header can be directly derived from the chunk data. One important field to note is dataHash, which becomes part of the public input used to verify the validity proof.

Assuming a batch contains n chunks, its dataHash is computed as follows:

batch.dataHash := keccak(chunk[0].dataHash || ... || chunk[n-1].dataHash)

For each chunk containing k blocks, its dataHash is determined by:

chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] ||
                         block[0].l1TxHashes || block[0].l2TxHashes || ... ||
                         block[k-1].l1TxHashes || block[k-1].l2TxHashes)

Here, block.l1TxHashes represents the concatenated transaction hashes of the L1 transactions in the block, while block.l2TxHashes includes the concatenated transaction hashes of the L2 transactions. It's important to note that the transaction hashes of L1 transactions are not uploaded by the rollup node; instead, they are directly retrieved from the L1MessageQueue contract based on the index range of included L1 messages in the block. The L2 transaction hashes are calculated from the RLP-encoded bytes in the l2Transactions field of the chunk.

Additionally, the commitBatchWithBlobProof function includes a bitmap of skipped L1 messages to mitigate issues related to proof overflow, which Wischain is actively working to resolve through enhancements to its proving system.

Finalize Transaction

The Finalize Transaction is responsible for confirming the previously committed batch using a validity proof. It also submits the state root and the withdrawal root following the batch. The function signature for this operation is:

function finalizeBatchWithProof(
    bytes calldata batchHeader,
    bytes32 prevStateRoot,
    bytes32 postStateRoot,
    bytes32 withdrawRoot,
    bytes calldata aggrProof
) external override OnlyProver;

The finalizeBatchWithProof function first checks if the batch has been committed within the contract. It then computes the public input hash as follows:

publicInputHash := keccak(chainId || prevStateRoot || postStateRoot || withdrawRoot || batch.dataHash);

This public input hash, along with the validity proof, is sent to the Plonk Solidity verifier. Once verification is successful, the new state root and withdrawal root are recorded in the Wischain contract:

mapping(uint256 => bytes32) public override finalizedStateRoots;
mapping(uint256 => bytes32) public override withdrawRoots;

At this point, the state root of the latest finalized batch can be used trustlessly, allowing the withdrawal transactions in that batch to be executed on Layer 1 using a Merkle proof linked to the withdrawal root.

Codec

This section outlines the codec for three key data structures in the Rollup contract: BatchHeader, Chunk, and BlockContext.

The latest updates to the codec were implemented in the Bernoulli upgrade.

BatchHeader Codec

Field	Bytes	Type	Offset	Description
version	1	uint8	0	The version of the batch header
batchIndex	8	uint64	1	The index of the batch
l1MessagePopped	8	uint64	9	The number of L1 messages processed in the batch
totalL1MessagePopped	8	uint64	17	Total number of L1 messages processed after the batch
dataHash	32	bytes32	25	The data hash of the batch
blobVersionedHash	32	bytes32	57	Versioned hash of the blob containing this batch's data
parentBatchHash	32	bytes32	89	The hash of the parent batch
lastBlockTimestamp	8	uint64	121	The timestamp of the last block in this batch
blobDataProof	64	bytes32[2]	129	KZG challenge point evaluation proof

Chunk Codec

Field	Bytes	Type	Offset	Description
numBlocks	1	uint8	0	The number of blocks in the chunk
block[0]	60	BlockContext	1	Information for the first block
...	...	...	...	...
block[n-1]	60	BlockContext	60*i+1	Information for the last block

BlockContext Codec

Field	Bytes	Type	Offset	Description
blockNumber	8	uint64	0	The block number
timestamp	8	uint64	8	The block time
baseFee	32	uint256	16	The base fee for this block; currently always 0 due to EIP-1559 being disabled
gasLimit	8

uint64 | 48 | The gas limit of this block | | numTransactions | 2 | uint16 | 56 | Total number of transactions in this block (including both L1 and L2 transactions) | | numL1Messages | 2 | uint16 | 58 | Number of L1 messages in this block |

This comprehensive overview of the Wischain rollup process illustrates its efficiency and the detailed mechanisms that ensure data availability, finality, and proof generation within the ecosystem.