Let's look at a transaction that sets a state variable to 0x1
. The contract we want to interact with has a setter and a getter for the variable a
:
pragma solidity ^0.4.11;
contract C {
uint256 a;
function setA(uint256 _a) {
a = _a;
}
function getA() returns (uint256) {
return a;
}
}
Created a transaction that makes the call setA(1)
. The transaction's input data is:
0xee919d500000000000000000000000000000000000000000000000000000000000000001
To the EVM, this is just 36 bytes of raw data. It is passed to the Smart Contract unprocessed as calldata
. If the Smart Contract is a Solidity program, then it interprets these input bytes as a method call, and executes the appropriate assembly code for setA(1)
.
The input data can be broken down to two subparts:
# The method selector (4 bytes)
0xee919d50
# The method arguments (32 bytes)
00000000000000000000000000000000000000000000000000000000000000001
The first four bytes is the method selector. The rest of the input data are method arguments in chunks of 32 bytes. In this case there is only 1 argument, the value 0x1
.
The method selector is the keccak256 hash of the method signature. In this case the method signature is setA(uint256)
, which is the name of the method and the types of its arguments.
As far as the EVM is concerned, the transaction's input data (calldata
) is just a sequence of bytes. The EVM doesn't have builtin support for calling methods.