Calldata Usage

Calldata is immutable and read-only for the duration of a transaction. Once a transaction is submitted, the data cannot be altered by the executing contract. This ensures predictable execution and prevents reentrancy attacks that rely on modifying input parameters mid-execution. The contract can only read from this dedicated memory area, making it a secure channel for user-provided arguments.

Reading from calldata is cheaper than reading from memory (memory). For functions that only need to read external input, declaring parameters as calldata instead of memory or storage optimizes gas usage. This is because calldata is a non-modifiable external data location, avoiding the gas cost of copying data into a new, modifiable memory location within the EVM.

Calldata is strictly formatted according to the Ethereum Application Binary Interface (ABI) specification. This encoding includes:

• The function selector (first 4 bytes)
• Padded arguments for each parameter
• Dynamic data with offsets and length prefixes This standardized encoding allows any client or contract to correctly decode and interpret the transaction's intent, enabling seamless interoperability across the ecosystem.

Calldata is the exclusive data location for parameters of external functions. When Contract A calls an external function on Contract B, all arguments are packed into the calldata field of the internal message call. This distinguishes it from internal function calls, which can use memory or calldata and do not incur the same external transaction overhead.

Smart contracts can inspect raw calldata using the global variable msg.data, which contains the complete byte sequence. To decode it, developers use abi.decode() in conjunction with known type signatures. For example: (uint256 x, address addr) = abi.decode(msg.data[4:], (uint256, address)); This allows for low-level parsing and the creation of generic proxy or router contracts.

Calldata efficiently handles dynamic types like bytes and arrays (uint256[]). In the ABI encoding, these are represented with an offset pointer to where the actual data resides within the calldata byte stream, followed by the length and the data itself. This allows contracts to process variable-length inputs, such as signature data or batch operation parameters, without prior knowledge of their size.

The primary use of calldata is to pass input arguments to a smart contract function. It is a read-only, non-persistent byte array containing the function selector and ABI-encoded parameters. For external functions, calldata is the recommended data location for array and struct parameters as it is the cheapest in terms of gas consumption, avoiding unnecessary copies to memory.

Using the calldata data location for reference types (arrays, strings, structs) in external functions is a key gas optimization technique. It is cheaper than memory because arguments are read directly from the transaction data without duplication. This is critical for functions that handle large data payloads, such as batch operations or Merkle proofs.

• Example: function verifyProof(bytes calldata proof, bytes32 root) external pure.

Calldata is explicitly constructed for low-level address calls using address.call{value: msg.value}(data). The data bytes must contain the target function's selector and ABI-encoded arguments. This pattern is used for generic proxy contracts, multi-sig wallets, and interacting with unknown contract interfaces. delegatecall uses the calldata of the calling contract to execute code in the context of another.

On Optimistic Rollups like Optimism and Arbitrum, calldata is the primary medium for publishing transaction data to Ethereum Layer 1 for data availability and fraud proofs. This makes the cost of L2 transactions highly sensitive to Ethereum's gas fees. Zero-Knowledge Rollups like zkSync often use calldata for a similar purpose, though some employ data blobs for greater efficiency.

While not stored on-chain, calldata is instrumental in off-chain contexts. Indexers and clients decode event logs and revert errors by parsing the original transaction's calldata alongside the contract ABI. This allows applications to reconstruct the exact function and arguments that were called, which is essential for analytics, debugging, and transaction decoding tools.

The complete, unparsed calldata for the current call is accessible via the msg.data global variable. This is used in fallback() and receive() functions to handle arbitrary calls, and for implementing custom function dispatchers or signature-based schemes (like ERC-2771 meta-transactions). It provides raw access to the entire input data byte array.

Transaction data is the raw payload included in an Ethereum transaction, which includes the calldata field. This data is immutable, publicly visible on-chain, and is the primary input for smart contract execution. It is distinct from other transaction fields like to, value, and gasLimit.

Memory is a volatile, expandable byte-array used by the EVM for temporary data storage during a contract's execution. Unlike calldata, memory is mutable and is wiped clean after the transaction. Calldata is often copied into memory for manipulation by a contract's opcodes.

Storage is the persistent, key-value data structure permanently written to the Ethereum state. It is the most expensive resource to modify. Calldata is a read-only input, while storage holds the contract's long-term state. Writing to storage consumes significantly more gas than reading calldata.

ABI Encoding is the standard process of converting function calls and their parameters into the bytecode format that constitutes calldata. It defines the structure, including the function selector (first 4 bytes) and the packed arguments. Tools like web3.js and ethers.js handle this encoding automatically.

The gas cost for calldata is non-zero and follows specific rules: each zero-byte costs 4 gas and each non-zero byte costs 16 gas (post-EIP-2028). This creates a direct economic incentive to pack data efficiently and use zero-bytes where possible, making it cheaper than storage but not free.

The function selector is the first 4 bytes of the calldata, derived from the Keccak-256 hash of the function signature (e.g., transfer(address,uint256)). It uniquely identifies which function in the contract's bytecode should be executed, allowing the EVM to route the call correctly.