Calldata

Features of calldata

• The longer the transaction calldata is (tx.data), the more gas the sender pays

• Transaction data can have arbitrary length and arbitrary values

• Solidity’s dominance has enforced a convention on how tx.data is used

• When sending a transaction to a wallet, you don’t typically put any data in, unless you are trying to send that person a message (you can even send a message without sending ether; it is considered a valid transaction)

• When sending transactions to a smart contract, the first four bytes specify the function selector, and the bytes that follow are abi-encoded function arguments

• Solidity expects the bytes after the function selector to always be a multiple of 32 in length, but this is purely just convention

• If you send more bytes, Solidity will ignore them

• However, a Yul smart contract can be programmed to respond to arbitrary length [tx.data](<http://tx.data>) in an arbitrary manner

• Function selector - first four bytes of keccak256 of the function signature

ABI specification

• Frontend apps know how to format the transaction based on the ABI specification of the contract

• In Solidity, the function selector and 32-byte encoded arguments are created under the hood by interfaces, or if you use abi.encodeWithSignature("balanceOf(address)", 0x....)

• But in Yul, you have to be explicit

• Yul doesn’t have a notion of function selectors, interfaces, or abi encoding

• If you want to make an external call to a Solidity contract, you have to implement all of that yourself