Wischain Node

The Wischain node plays a crucial role in managing the Wischain blockchain by dividing it into segments that are optimized for proof generation and commitment on Layer 1 (L1). This process involves two primary components: chunks and batches.

Components

• Chunks: A chunk represents a contiguous segment of the Layer 2 (L2) ledger, comprising a collection of L2 blocks. Chunks serve as the fundamental unit for zkEVM (Zero-Knowledge Ethereum Virtual Machine) proving, ensuring that the necessary computations and validations can be efficiently handled.

• Batches: A batch is formed from multiple chunks and is submitted to L1 along with an aggregated proof. Batches enable the efficient handling of multiple chunks simultaneously, streamlining the process of proof verification on the Ethereum network.

The Wischain node consists of several key submodules:

1. Chunk Proposer: This submodule is responsible for collecting L2 blocks and proposing chunks, adhering to specific limits and constraints outlined below.

2. Batch Proposer: This component gathers chunks and proposes batches while enforcing certain restrictions to ensure optimal performance and compliance with protocol standards.

3. Relayer: The relayer's role is to submit batch data and associated proofs to Layer 1, facilitating the seamless integration of Wischain transactions into the Ethereum ecosystem.

Chunk and Batch Constraints

In contrast to the execution node, the Wischain node is a more streamlined component focused on collecting L2 blocks, creating chunks and batches, and submitting them to L1. Here, we detail the essential constraints that the Wischain node must adhere to during chunk and batch creation.

Constraints on Chunks

• No Proof Overflow: To avoid proof overflow, the circuit capacity checker is utilized to ensure that a chunk can include as many blocks as necessary without exceeding the circuit's limits.

• L1 Payload Limit: The transaction payload inherited from the batch proposer cannot exceed 128KB, which is a critical constraint to ensure compatibility with Ethereum’s transaction processing requirements.

Constraints on Batches

• L1 Payload Size: Ethereum imposes a hardcoded limit of 128KB on the transaction payload size for all transactions, including those generated from Wischain.

• L1 Commit Gas: The gas cost associated with committing a batch is directly proportional to the number of blocks and transactions it contains. It is essential to ensure that this gas cost remains within the L1 block gas limit to prevent transaction failures.

• Number of Chunks: A batch must contain an optimal number of chunks to facilitate efficient aggregation by the prover, thereby enhancing the overall performance of the proof generation process.

Conclusion

In summary, the Wischain node efficiently organizes and manages the data on the Wischain blockchain by utilizing chunks and batches to optimize proof generation and commitment on Layer 1. By adhering to the outlined constraints, the Wischain ecosystem ensures reliable and efficient operation within the Ethereum network, enhancing the scalability and performance of decentralized applications.