Batch Submission

The fundamental operation where a sequencer or proposer collects multiple user transactions off-chain, bundles them into a single data batch, and submits this batch to the base layer (e.g., Ethereum L1). This reduces the per-transaction overhead of gas fees and block space consumption.

• Example: 1000 L2 transfers submitted as one L1 calldata transaction.
• Key Benefit: Amortizes fixed L1 costs (like signature verification) across many operations.

A designated network node responsible for ordering transactions, creating batches, and submitting them to the parent chain. The sequencer provides fast pre-confirmations to users while ensuring the batch's data is eventually published for data availability.

• Centralized Sequencer: Common in early rollups for simplicity and efficiency.
• Decentralized Sequencer Set: Aims for censorship resistance via proof-of-stake or other consensus mechanisms.

Batch submission enables powerful data compression techniques before the data hits the base chain. Redundant data (like signature fields) can be omitted, and transactions can be encoded more efficiently.

• Techniques: Signature aggregation, state diffs, custom RLP encoding.
• Impact: Can reduce L1 calldata costs by 10-100x compared to individual L1 transactions.

The critical guarantee that the data for all transactions in a batch is published and accessible on a secure base layer (like Ethereum). This allows anyone to reconstruct the chain state and challenge invalid state transitions.

• DA Methods: Full data on-chain (Optimistic/ZK Rollups), data availability committees, or data availability sampling.
• Without DA: The system becomes a validium, trading off some security for lower costs.

Each batch is accompanied by a state root commitment (a cryptographic hash of the post-batch state). The method of verifying this commitment defines the rollup type.

• Optimistic Rollups: Submit state root with a fraud proof challenge period.
• ZK-Rollups: Submit a validity proof (ZK-SNARK/STARK) with each batch, providing immediate finality.
• Purpose: Ensures the batch execution was correct without re-executing all tx on L1.

The frequency of batch submission creates a trade-off between latency and cost efficiency. Submitting more frequently reduces user wait time for L1 finality but increases overall cost.

• Typical Intervals: Range from minutes (cost-optimized) to seconds (latency-optimized).
• Soft vs. Hard Finality: Users get instant soft confirmation from the sequencer, with hard finality achieved upon batch inclusion and verification on L1.

Solana's parallel execution engine uses a form of batch submission at the consensus level. Validators batch thousands of transactions into a block and process them concurrently across multiple cores. Key aspects include:

• State is partitioned into accounts, allowing non-conflicting transactions to execute in parallel.
• The leader (block producer) orders and submits the entire batch for parallel verification.
• This design is fundamental to achieving Solana's high throughput, often cited at thousands of transactions per second (TPS).

In Optimistic Rollups like Arbitrum and Optimism, the sequencer node performs batch submission to Layer 1.

• The sequencer orders off-chain transactions and creates a compressed batch (often just state roots or transaction hashes).
• This batch is periodically submitted as a single transaction to a bridge contract on Ethereum (e.g., the Inbox).
• This reduces cost per transaction and is central to the rollup's scalability, with finality relying on a fraud proof window.

Zero-Knowledge Rollups like zkSync Era and StarkNet use batch submission for both data and proofs.

• Transactions are executed off-chain and their state transitions are aggregated into a batch.
• A ZK-SNARK or ZK-STARK proof is generated for the entire batch, cryptographically verifying all transactions.
• Only the compressed state data and the single validity proof are submitted to Layer 1. This is arguably the most computationally intensive form of batching, providing instant cryptographic finality.

Decentralized sequencer projects like Astria and Espresso exemplify batch submission as a service.

• They operate a network of nodes that order transactions for multiple rollups.
• Instead of each rollup running its own sequencer, they all send transactions to this shared network.
• The network creates a cross-rollup block (a batch of batches) and submits it to the underlying Layer 1. This promotes decentralization, interoperability, and potential atomic cross-rollup composability.

With EIP-4844 (Proto-Danksharding), Ethereum introduced a dedicated mechanism for batch data submission.

• Rollups post their batched transaction data as blobs—large, temporary data packets attached to a beacon block.
• Blobs are cheaper than calldata and are designed to be pruned after ~18 days.
• This creates a scalable data layer specifically optimized for the batch submission needs of L2 rollups, separating data availability from execution.

The security of a batch submission system depends on the Data Availability (DA) of the underlying transaction data. If data is withheld, the system cannot verify the batch's validity. Fraud proofs are cryptographic proofs that allow any honest participant to challenge an invalid batch, but they require the data to be available to construct. This creates a critical dependency on the DA layer's liveness and censorship resistance.

A single sequencer (or a small committee) is often responsible for ordering and submitting batches. This creates centralization risks:

• Censorship: The sequencer can exclude or reorder transactions.
• MEV Extraction: The sequencer can profit from manipulating transaction order.
• Liveness Failure: If the sequencer goes offline, the chain may halt. Decentralized sequencer sets and proposer-builder separation (PBS) are proposed mitigations.

To disincentivize malicious behavior, sequencers are often required to post a bond (or stake). This bond can be slashed if the sequencer submits an invalid batch or is provably dishonest. The size of the bond must be economically significant relative to the potential profit from an attack, creating a crypto-economic security model.

After a batch is submitted, a challenge period (or dispute window) begins. During this time, funds cannot be immediately withdrawn from the system, as fraud proofs can be submitted. This period, often 7 days, represents a trade-off between security guarantees and capital efficiency. Longer periods increase security but reduce usability for users and liquidity providers.

Batching transactions amortizes fixed costs (like L1 gas) across many operations, achieving significant cost efficiency. However, the mechanisms to make the system trust-minimized and decentralized (e.g., fraud proof verification, decentralized sequencing) add overhead. The design space involves balancing this low cost with sufficient decentralization to maintain security assurances.

In an Optimistic Rollup, the sequencer compresses hundreds of L2 transactions into a single batch, posts a minimal state root and calldata to Ethereum, and assumes it's valid (optimistic execution). A Verifier can challenge it during the challenge period by submitting a fraud proof. The economic security relies on at least one honest verifier existing and the data being available on-chain.