Understanding Smart Contract External Method Calls

·

Smart contracts manage data on the Ethereum blockchain, but without interaction, data remains inert. These contracts act as mediators between stored information and external applications. This article explores how Solidity and the Ethereum Virtual Machine (EVM) enable external programs to call contract methods and modify their state.

External programs aren’t limited to DApps or JavaScript—any application capable of HTTP RPC communication with an Ethereum node can interact with deployed contracts by creating transactions. These transactions, once accepted by the network, alter the blockchain’s state.

Think of transactions as HTTP requests for smart contracts. They initiate changes, much like web requests trigger database updates.

The Structure of a Contract Transaction

Consider a transaction setting a state variable to 0x1. The contract includes setter and getter functions for variable a:

pragma solidity ^0.4.11;
contract C {
    uint256 a;
    function setA(uint256 _a) {
        a = _a;
    }
    function getA() returns(uint256) {
        return a;
    }
}

When calling setA(1), the input data for the transaction is:

0xee919d500000000000000000000000000000000000000000000000000000000000000001

To the EVM, this is 36 bytes of raw data passed as calldata to the contract. A Solidity-based contract interprets these bytes as a method call and executes the corresponding assembly code for setA(1).

The data breaks down into:

The method selector is the first four bytes of the Keccak-256 hash of the method signature. Here, the signature is setA(uint256).

Using Python, we can compute the selector:

from ethereum.utils import sha3
sha3("setA(uint256)").hex()
# Returns: 'ee919d50445cd9f463621849366a537968fe1ce096894b0d0c001528383d4769'

Taking the first four bytes:

sha3("setA(uint256)")[0:8].hex()
# Returns: 'ee919d50'

The Application Binary Interface (ABI)

The EVM treats transaction input data (calldata) as a raw byte sequence with no innate support for method calls. Smart contracts simulate method calls by parsing input data in a structured manner. The Ethereum Contract ABI defines a common encoding scheme that enables interoperability across different languages on the EVM.

We’ve seen how the ABI encodes a simple method call like setA(1). Later, we’ll examine encoding for methods with more complex parameters.

Calling Getter Methods

Methods that change state require transactions and consume gas. Getter methods like getA() don’t alter state, so we can use the eth_call RPC to simulate the transaction locally. This is useful for read-only operations or gas estimation.

eth_call resembles a cached HTTP GET request:

To call getA, compute the method selector:

sha3("getA()")[0:8].hex()
# Returns: 'd46300fd'

With no arguments, the input data is the method selector. We can send an eth_call request to an Ethereum node:

curl -X POST \
-H "Content-Type: application/json" \
"https://rinkeby.infura.io/YOUR_INFURA_TOKEN" \
--data '
{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_call",
    "params": [
        {
            "to": "0x62650ae5c5777d1660cc17fcd4f48f6a66b9a4c2",
            "data": "0xd46300fd"
        },
        "latest"
    ]
}
'

The EVM returns raw bytes:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": "0x0000000000000000000000000000000000000000000000000000000000000001"

According to the ABI, these bytes represent the value 0x1.

Assembly for External Method Calls

How does a compiled contract process raw input data for method calls? Examine a contract with setA(uint256):

pragma solidity ^0.4.11;
contract C {
    uint256 a;
    function setA(uint256 _a) payable {
        a = _a;
    }
}

The assembly code for the method call resides in the contract body. Key sections include:

  1. Selector Matching: The contract checks the first four bytes of calldata against known method selectors.
  2. Argument Loading and Execution: If a match is found, arguments are loaded from calldata, and the method executes.

In pseudocode:

methodSelector = calldata[0:4]
if methodSelector == "0xee919d50":
    @arg1 = calldata[4:36]
    sstore(0x0, @arg1)
else:
    revert

Handling Multiple Methods

For contracts with multiple methods, the compiler generates sequential if-else checks:

pragma solidity ^0.4.11;
contract C {
    uint256 a;
    uint256 b;
    function setA(uint256 _a) { a = _a; }
    function setB(uint256 _b) { b = _b; }
}

The assembly checks each method selector in turn:

methodSelector = calldata[0:4]
if methodSelector == "0x9cdcf9b":
    goto setB
elsif methodSelector == "0xee919d50":
    goto setA
else:
    revert

ABI Encoding for Complex Method Calls

Method calls always start with a four-byte selector followed by 32-byte argument chunks. The ABI specification details encoding for complex types.

Using pyethereum’s encode_abi function, we can explore encoding for various data types.

Basic Types:

encode_abi(["uint256", "uint256", "uint256"], [1, 2, 3]).hex()
# Returns 96 bytes of padded data

Fixed-Size Arrays:
Elements are padded to 32 bytes and placed consecutively.

Dynamic Arrays:
ABI uses head-tail encoding. The head contains pointers to tail positions where array data is stored.

Example with three dynamic arrays:

encode_abi(
    ["uint256[]", "uint256[]", "uint256[]"],
    [[0xa1, 0xa2, 0xa3], [0xb1, 0xb2, 0xb3], [0xc1, 0xc2, 0xc3]]
).hex()

Strings and Bytes:
These are tightly packed in 32-byte chunks, with a length prefix.

Nested Arrays:
Each nesting level adds a layer of indirection.

Gas Costs and ABI Design

ABI truncates method selectors to four bytes instead of using full 32-byte hashes. This design is gas-cost motivated:

Method selectors, being cryptographic hashes, are mostly non-zero bytes. Truncation saves gas despite zero-padding elsewhere.

Negative integers are padded with 1s, which are non-zero and costly. This reflects the trade-offs in ABI’s low-level design.

Conclusion

Smart contract interactions involve sending raw bytes. Contracts perform computations, possibly alter state, and return raw bytes. Method calls are an abstraction provided by the ABI, which acts as a serialization format for cross-language RPC functionality.

Architectural parallels exist between DApps and web applications:

👉 Explore more Ethereum development strategies

Frequently Asked Questions

What is the purpose of the ABI in Ethereum?
The Application Binary Interface defines how data is encoded for interactions between smart contracts and external applications. It ensures that different programs can correctly encode method calls and decode responses, enabling interoperability across the Ethereum ecosystem.

How does method selector matching work?
Smart contracts compare the first four bytes of transaction calldata against precomputed Keccak-256 hashes of method signatures. If a match is found, the contract executes the corresponding function. Otherwise, the transaction may revert.

Why are some bytes zero-padded in ABI encoding?
EVM operates on 32-byte words. Data smaller than 32 bytes is padded to maintain consistent word alignment, simplifying data handling in the virtual machine. Zero-padding also reduces gas costs compared to using non-zero values.

Can contracts handle methods with dynamic parameters?
Yes, using head-tail encoding. The head contains pointers to dynamic data stored in the tail section of calldata. This allows contracts to handle variable-length arrays, strings, and complex nested structures efficiently.

How do gas costs influence ABI design?
Gas costs for non-zero bytes are significantly higher than for zeros. ABI optimizations, like truncating method selectors and zero-padding, minimize transaction costs. Design choices reflect economic incentives on the Ethereum network.

What happens if no method selector matches?
Contracts typically revert the transaction when no matching method is found. This ensures that state remains unchanged and gas isn’t wasted on invalid operations.