Fundamentos de blockchain
Calldata
Calldata is read-only input supplied to a contract call.
Los artículos de investigación y las referencias se publican en inglés. La navegación está disponible en siete idiomas.
En este artículo
The instructions carried to a contract
Calldata is the input supplied to a contract call. A website can describe an action as “claim”, “verify” or “connect”, but those labels are not the instructions the EVM executes. The destination address and input bytes determine which code is reached and what values it receives. The transaction can also carry native currency separately from its input data.
For a conventional Solidity ABI call, the first four bytes select a function and the remaining bytes encode its arguments. Dynamic values use offsets and lengths, so a payload is not always a simple list of values read from left to right. The ABI is an interpretation scheme, not a certificate that the destination implements honest behaviour. Solidity ABI specification.
Decode the action and then inspect the destination
Consider a page offering a reward. Its call decodes as a token approval with a spender address and a large amount. The decoded fields do not match the simple story “receive a reward”: they describe granting another address spending authority. That mismatch deserves explanation before signing. The useful questions are which token is affected, which spender gains permission and how much it may spend.
Decoding alone still does not establish the complete effect. A familiar-looking function signature at an unfamiliar contract does not turn that contract into the official token. An explorer may display a guessed function name. Function selectors are only four bytes long, so a selector is not a globally unique statement of meaning. Check the chain, exact destination, relevant code and any proxy implementation.
Read nested calls as well as the outer label
A batch operation can carry several inner calls. If a wallet displays only the outer function’s name, an approval or transfer can be hidden inside a structure the user never expands. The review needs to follow the concrete arguments through the batch, including each destination and attached value. “One signature” does not necessarily mean one economic action.
For an illustrative review, write down three columns: what the page promised, what the wallet displayed and what the call encoded. A promise to claim 10 tokens, a generic “contract interaction” screen and an instruction authorising a third-party spender are materially different records. Keeping all three allows another reviewer to identify where the user’s understanding diverged from the signed instruction.
The same input can produce a different result later
A smart contract’s functions can read persistent state and modify it during execution. Input is therefore only one part of the result. A price, permission, pause flag or implementation can change between an earlier test and the actual transaction. Ethereum: contract state and functions.
Archive the transaction hash, destination, input bytes, relevant block and code version when documenting an incident. If a simulation is part of the evidence, record the state it used. Do not replace missing execution evidence with a reassuring decoded label. The entry on simulation limits develops this distinction, while typed-data review covers signatures that are not ordinary contract transactions.