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 Contact 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)0xee919d5# The 1st argument (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 value0x1.
The method selector is the kecccak256 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.
Let’s calculate the method selector in Python. First, hash the method signature:# Install pyethereum https://github.com/ethereum/pyethereum/#installation> from ethereum.utils import sha3> sha3("setA(uint256)").hex()'ee919d50445cd9f463621849366a537968fe1ce096894b0d0c001528383d4769'
Then take the first 4 bytes of the hash:> sha3("setA(uint256)")[0:4].hex()'ee919d50' The Application Binary Interface (ABI)
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.
A smart contract can choose to simulate a method call by processing the input data in a structured way, as shown in the previous section.
If languages on the EVM all agree on how input data should be interpreted, then they can easily interoperate with each other. The Contract Application Binary Interface (The ABI) specifies a common encoding scheme.
We’ve seen how the ABI encodes a simple method call like setA(1). In later sections we’ll see...