Calldata Usage

The process of reducing the byte size of calldata before it is posted on-chain. Techniques include:

• Zero-byte vs. Non-zero-byte pricing: Packing data to minimize expensive non-zero bytes.
• State diffs: Transmitting only the final state changes instead of full transaction data.
• Brotli and Zstandard: Applying general-purpose compression algorithms to batch data.

A method where multiple cryptographic signatures from different transactions are combined into a single, verifiable signature. This drastically reduces the calldata needed per transaction in a batch, as individual signature data (65+ bytes each) is replaced with a single aggregated proof.

A fundamental cost trade-off. Writing to contract storage is a persistent, high-gas operation, while using calldata is a temporary, lower-cost input. Optimization often involves designing protocols to pass data via calldata for computation, avoiding unnecessary permanent storage writes.

Submitting multiple user operations or transactions within a single calldata payload. This amortizes the fixed cost of transaction overhead (like signatures and nonces) across many actions. It's a core scaling technique for rollups and account abstraction bundles.

Using the Application Binary Interface (ABI) correctly to minimize calldata. Key practices include:

• Using uint8 over uint256 for small numbers when possible.
• Packing multiple small variables into a single bytes or uint256 slot via bitwise operations.
• Understanding how arrays and dynamic types add offset pointers that increase size.

The primary economic incentive. On Ethereum, calldata is priced based on its byte composition. Optimization directly reduces the L1 data fee, which is the dominant cost for Layer 2 rollups. This makes transactions cheaper for end-users and increases network throughput.

On the Ethereum mainnet, calldata is priced per byte. The cost is 16 gas for a zero byte and 68 gas for a non-zero byte. This structure incentivizes data compression, such as using zero bytes for padding or compact function selectors. For example, a function call with the signature transfer(address,uint256) incurs a higher base cost than a more compact, custom encoding.

For Optimistic and ZK Rollups, calldata is the primary cost driver as it's published to Ethereum for data availability. While the rollup may charge users a small fee for execution, the dominant cost is the L1 data fee. This makes calldata compression (e.g., using efficient serialization formats) and data availability sampling critical research areas for reducing user transaction costs.

Calldata is generally cheaper than other data locations:

• Storage (SSTORE): Extremely expensive (up to 20,000+ gas for a new slot).
• Memory (MSTORE): Moderate cost (3-12 gas per word), but volatile.
• Calldata: Read-only, with costs incurred only on transaction input. Best practice is to read directly from calldata instead of copying to memory for simple access.

Key strategies to minimize calldata costs include:

• Using bytes over string for dynamic data to avoid expensive ABI encoding overhead.
• Packing arguments into fixed-size bytes arrays to maximize zero bytes.
• Event Logging for Data: Emitting data in events is often cheaper than storing it, as log topics cost 375 gas and data costs 8 gas per byte.

EIP-4844 introduces blob-carrying transactions with dedicated blob gas. This creates a separate, cheaper gas market for large data batches used by L2s, significantly reducing the cost of data availability compared to legacy calldata. Blobs are large (~128 KB) and are pruned after ~18 days, separating long-term storage cost from short-term data availability.

The Application Binary Interface (ABI) encoding scheme directly affects calldata size and cost. Tuple encoding and dynamic array headers add overhead. For instance, a dynamic array adds a 32-byte offset and a 32-byte length field. Understanding ABI encoding is essential for predicting gas costs and designing efficient function signatures.

The core use of calldata is to specify which smart contract function to execute and with what arguments. The first 4 bytes are the function selector, a hash of the function signature, while the remaining bytes are the ABI-encoded arguments. This is the fundamental mechanism for all contract interactions, from simple transfers to complex DeFi operations.

When deploying a new smart contract via a transaction, the calldata field contains the compiled bytecode of the contract being created. For factory contracts that create other contracts, the calldata includes both the factory's function call and the initcode for the new contract. This is essential for protocols that deploy user-specific contracts, like proxy wallets or liquidity pools.

Using calldata for function parameters, instead of memory, is a key gas-saving technique for functions that are called externally. Calldata is a non-modifiable, read-only reference, so data does not need to be copied to memory, saving significant gas. This is especially important for large arrays or strings passed to view/pure functions or external calls.

The call, delegatecall, and staticcall opcodes use raw calldata as their primary argument. Developers can craft custom calldata to:

• Interact with contracts without their ABI.
• Perform multicall operations in a single transaction.
• Implement upgradeable proxies via delegatecall. This provides maximum flexibility for complex interoperability and gas-efficient batch operations.

While events are emitted in transaction logs, their indexed topics are often derived from or directly contain values originally passed in the transaction's calldata. Off-chain applications and indexers use these topics to efficiently filter and query for specific on-chain events, such as a token transfer to a particular address or a specific NFT sale.

In meta-transactions and gasless transactions, a user signs a message (often containing the intended function call details) off-chain. A relayer submits this signature in the calldata. The contract then uses ecrecover to validate the signature against the signed message hash, which is typically a hash of the target address, calldata, and other parameters.

The primary rule is to store only essential data in calldata. Gas cost is directly proportional to the number of non-zero bytes and zero-bytes transmitted. Strategies include:

• Compress arguments: Use smaller integer types (e.g., uint128 vs uint256) when possible.
• Use indexes or identifiers: Pass a user ID or array index instead of a full address or string.
• Off-chain computation: Perform complex calculations off-chain and pass only the final result or proof.

Solidity packs multiple function arguments into a single 32-byte word when possible. You can exploit this by ordering parameters from most to least significant. For example, placing several uint8 or bool variables consecutively allows them to be packed, reducing total calldata size and gas. This is similar to storage packing but applies to transaction inputs.

For external functions that do not modify storage, declare reference-type parameters (like string, bytes, arrays) as calldata instead of memory. This prevents an expensive copy operation from calldata to memory, saving significant gas. The data is read directly from the immutable transaction payload.

Instead of storing large datasets in contract state (which is expensive for both writes and reads), emit an event with the data in its parameters. Events store data much more cheaply in transaction logs, which are indexed and queryable off-chain. This is ideal for non-critical historical records or analytics.

Reduce the overhead of multiple transactions by batching user actions into a single call. A single function with an array of structs in calldata is far more gas-efficient than dozens of individual transactions, as it amortizes the fixed cost (21,000 gas for the transaction) and reduces redundant calldata headers.

Transaction data is the raw payload included in an Ethereum transaction, primarily consisting of the calldata field. It is distinct from other transaction components like the to address, value, or gasLimit. This data is immutable, publicly visible on-chain, and is the primary input for smart contract function execution.

EVM Memory is a volatile, expandable byte array used for temporary data storage during contract execution. It is cheaper to write to than storage but is erased after the transaction. Calldata is often copied into memory using instructions like CALLDATACOPY for manipulation, as memory is mutable while calldata is read-only.

Contract Storage is a persistent, key-value store permanently written on-chain, making it the most expensive data location in terms of gas. While calldata is used for input, storage is for long-term state. Writing to storage from calldata incurs high gas costs (e.g., 20,000 gas for a zero-to-non-zero SSTORE).

Application Binary Interface (ABI) Encoding is the standard for serializing function calls and data into the bytecode format that constitutes calldata. It defines how to pack:

• Function selectors (first 4 bytes)
• Arguments (dynamic/static types)
• Offsets for dynamic arrays and strings Tools like web3.js and ethers.js handle this encoding automatically.

Calldata gas cost is non-linear: 4 gas for a zero byte and 16 gas for a non-zero byte. EIP-2028 reduced the cost of non-zero bytes from 68 to 16 gas, significantly optimizing data-heavy L2 rollups. This makes calldata the preferred location for bulk data input, as it is far cheaper than storage operations.

Event Logs are a specialized, indexed data structure emitted by contracts, stored separately from contract state. While calldata is input data for execution, logs are output data for off-chain consumption. Logs are much cheaper than storage (~375-750 gas) and are a key mechanism for dApp frontends and indexers to track contract activity.