Calldata Compression

Calldata compression reduces the size of data that Layer 2 rollups post to Layer 1, directly lowering transaction costs for rollup users.

Key Takeaways

L1 data posting is the dominant cost for rollup users, so calldata compression directly translates into lower transaction fees by shrinking the data each batch consumes on Ethereum.
Common techniques include zero-byte optimization, address table lookups (replacing 20-byte addresses with short indices), custom compact encoding (dropping ABI padding), and general-purpose compressors like zlib and brotli.
Even after EIP-4844 shifted rollups from calldata to blob transactions, compression remains critical: smaller compressed batches mean fewer blobs purchased and lower fees in the blob fee market.

What Is Calldata Compression?

Calldata compression refers to a set of techniques that Layer 2 rollups use to reduce the size of transaction data before posting it to Ethereum Layer 1. Because rollups derive their security from publishing enough data for anyone to reconstruct the L2 state, the cost of that data submission is the single largest component of user-facing transaction fees. Compressing the data before it hits L1 directly lowers those fees.

A standard Ethereum transaction might use 100+ bytes of calldata per transfer, much of it padded or predictable. Rollups batch hundreds or thousands of L2 transactions into a single L1 submission, so even modest per-transaction savings compound into significant cost reductions across an entire batch.

Why L1 Data Cost Dominates

Ethereum charges gas for every byte of calldata included in a transaction. Before EIP-2028 (Istanbul, December 2019), non-zero calldata bytes cost 68 gas each. EIP-2028 reduced non-zero bytes to 16 gas while keeping zero bytes at 4 gas. This 4:1 pricing ratio between non-zero and zero bytes created a direct incentive to engineer data formats that maximize zero bytes.

For rollups, the L1 data cost typically accounts for 80-90% of total user fees, with L2 execution being comparatively cheap. Any reduction in data size maps almost linearly to a reduction in user cost, making compression one of the highest-leverage optimizations a rollup can implement.

How It Works

Rollup compression operates at multiple layers, from transaction-level encoding to batch-level algorithms. The most effective systems combine several of these techniques.

Zero-Byte Optimization

Ethereum's calldata pricing charges less for zero bytes (4 gas) than non-zero bytes (16 gas). Compression schemes exploit this by encoding data into formats that produce more zeros. One approach uses run-length encoding for zero sequences: instead of storing a long run of zero bytes, the encoder stores a single marker followed by a count.

Optimism's early compression used a simple zero-byte run-length encoding (ZLE) algorithm that replaced strings of consecutive zeros with a count value. While straightforward, this approach provided meaningful savings because ABI-encoded calldata is heavily padded with zeros.

Note that after EIP-7623 (Pectra, 2025), calldata gas costs were raised to 10 gas per zero byte and 40 gas per non-zero byte, making calldata even more expensive relative to blobs and further encouraging the migration to blob-based data posting.

Address Table Lookups

Ethereum addresses are 20 bytes long, but many rollup transactions reference the same addresses repeatedly: popular token contracts, DEX routers, bridge contracts. Address table compression maintains a registry of known addresses and replaces each 20-byte address with a short index.

Arbitrum implements this through an Address Table precompile that maps addresses to integer indices. A transaction referencing a registered address can use a 3-4 byte index instead of the full 20-byte address, saving 16-17 bytes per reference. In testing, this technique alone has shown roughly 26% gas reduction for certain transaction types.

Sequence's compression system takes this further with a directory of frequently used addresses, where each can be referenced by a 3-byte directory index. Their production deployment across Arbitrum, Optimism, and Base reported approximately 5x calldata compression and roughly 50% lower L2 fees.

// Conceptual address table compression
// Before: full 20-byte address in calldata
// 0xdAC17F958D2ee523a2206206994597C13D831ec7

// After: 3-byte index lookup
// Table entry 0x00012F -> maps to the full address
// Decompressor contract resolves index back to address on-chain

Custom Compact Encoding

Standard Ethereum transactions use ABI encoding, which pads every value to 32 bytes. A uint8 value of 5 occupies a full 32-byte slot, wasting 31 bytes. Rollups can define custom encoding formats that pack values tightly.

Key techniques in compact encoding include:

Omitting reconstructible fields: the nonce can be recovered from the L2 pre-state, gas price and gas limit can be set at the batch level, and chain ID is implicit
Signature aggregation: instead of including a full 65-byte signature per transaction, rollups can aggregate signatures or use proof systems that validate batches collectively
Tight bit-packing: encoding values using only the bytes they actually need rather than padding to 32-byte boundaries
Template-based encoding: for batches of similar transactions (such as token transfers), storing the common structure once and only varying the unique fields per transaction

These techniques can reduce a standard ~112-byte ETH transfer to approximately 12 bytes of rollup calldata, roughly a 9x compression ratio.

General-Purpose Compression

After application-level encoding, rollups apply standard compression algorithms to the entire batch before posting to L1:

Optimism uses zlib compression and, since the Fjord upgrade, bases L1 data fees on an estimate of the transaction's size after FastLZ compression (with a minimum of 100 bytes per transaction)
Arbitrum Nitro uses brotli compression on each batch, which generally achieves higher compression ratios than zlib at the cost of more computation

General-purpose compressors work best on structured, repetitive data. They are less effective on addresses, hashes, and signatures, which appear essentially random to the algorithm. This is why application-level techniques (address tables, field omission) and general-purpose compression are complementary: the former removes the data that compressors cannot shrink.

The Shift to Blobs (EIP-4844)

EIP-4844 (Proto-Danksharding), activated in March 2024, introduced blob transactions as a new, cheaper way for rollups to post data to Ethereum. Instead of embedding data in calldata, rollups now attach fixed-size 128 KiB blobs to their transactions. Blobs are priced through a separate blob fee market with its own base fee, independent of the regular gas market.

Research shows that rollups rapidly migrated from calldata to blobs after EIP-4844, with calldata-based data posting falling to near zero. Blobs are temporary (pruned after approximately 18 days) and are not accessible to the EVM, which makes them cheaper but limits their use to data availability.

Compression remains essential in the blob era for two reasons:

Blob space is limited and priced dynamically: if a rollup can compress its batch into fewer blobs, it pays less in the blob fee market
Blob capacity per block is capped (currently targeting 6 blobs per block), so efficient compression means more transactions can fit within the network's throughput limits

Use Cases

Reducing Rollup Transaction Fees

The most direct use case is lowering costs for end users. Every byte saved in L1 data posting translates to lower fees. For high-volume rollups processing millions of transactions daily, even small per-transaction savings accumulate into significant cost reductions that make the chain more competitive.

Enabling Micropayments and High-Frequency Applications

Applications like gaming, social media tipping, and IoT microtransactions require sub-cent fees to be viable. Aggressive calldata compression helps rollups reach the fee levels these use cases demand. Without compression, the fixed L1 data cost per transaction would price out many of these applications.

Increasing Effective Throughput

Compression effectively multiplies a rollup's throughput without requiring changes to the base layer. If a rollup compresses its data by 5x, it can fit 5x more transactions into the same amount of L1 block space (or blob space), increasing the network's capacity without any protocol upgrades.

Cross-Chain and Multi-Layer Posting

Bitcoin Layer 2 solutions face similar data-posting constraints. Protocols like Spark and other Bitcoin L2s must consider data efficiency when anchoring state to the Bitcoin base layer, where block space is even more scarce and expensive than on Ethereum. Compression techniques originally developed for Ethereum rollups inform the design of data-efficient protocols across all blockchain ecosystems.

Risks and Considerations

Decompression Overhead

Any compression scheme requires a decompression step. For rollups, this means either an on-chain decompressor contract (which costs execution gas) or an off-chain decompression requirement for validators and verifiers. The gas savings from smaller calldata must exceed the gas cost of decompression, or the net effect is negative.

Complexity and Attack Surface

Custom encoding formats and compression logic add complexity to the rollup's critical path. Bugs in compression or decompression can lead to state mismatches between the rollup and its verification system. For optimistic rollups, a compression bug could cause fraud proofs to fail. For ZK-rollups, the compression logic must be provable within the proof system.

Diminishing Returns

Compression techniques interact with each other. Applying address table lookups and field omission before general-purpose compression can reduce the effectiveness of the latter, since there is less redundancy left to exploit. Teams must benchmark combined approaches against real transaction data to find the optimal combination for their specific workload.

Pricing Model Changes

Ethereum's calldata pricing has changed multiple times (EIP-2028 lowered non-zero byte costs, EIP-7623 raised them, EIP-4844 introduced blobs). Compression strategies optimized for one pricing regime may become suboptimal under another. Rollups must design flexible compression pipelines that can adapt to evolving L1 economics.