Open In App

Application Binary Interface(ABI) in Ethereum Virtual Machine

Smart contracts are pieces of code that are stored on the blockchain and are executed by the Ethereum Virtual Machine (EVM). The EVM also provides a comprehensive instruction set called opcodes which execute certain instructions. Opcodes are low-level codes similar to the processor’s instruction set. The common Ethereum opcodes can be accessed from the Ethereum Yellow Paper. The entire program is compiled and stored in the form of bytes or binary representation in the Ethereum blockchain as a form of address.  For Ethereum and the EVM, a contract is just a single program that is run on this sequence of bytes. Only the higher-level language like Solidity, Viper, or Bamboo defines how you get from the entry point of the program to the entry point of a particular function. When an external application or another smart contract wants to interact with the blockchain, it needs to have some knowledge of a smart contract’s interface such as a way to identify a method and its parameters. This is facilitated by the Ethereum Application Binary Interface (ABI).  

It is similar to the Application Program Interface (API), which is essentially a representation of the code’s interface in Human readable form or a high-level language. In the EVM the compiled code being stored as binary data and the human-readable interfaces disappear and smart contract interactions have to be translated into a binary format that can be interpreted by the EVM. ABI defines the methods and structures that you can simply use to interact with that binary contract (just like the API does), only on a lower level. The ABI indicates to the caller the needed information (functions signatures and variables declarations) to encode such that it is understood by the Virtual Machine call to the byte code(contract). This process is called ABI encoding.

ABI is the interface between two program modules, one of which is mostly at the machine code level. The interface is the default method for encoding/decoding data into or out of the machine code. In Ethereum it is basically how you encode a language to have contract calls to the EVM or how to read the data out of transactions. ABI encoding is in most cases automated by tools that are part of the compiler like REMIX or wallets which can interact with the blockchain. ABI encoder requires a description of the contract’s interface like function name and parameters which is commonly provided as a JSON.

Example of ABI Encoding

An Ethereum smart contract is byte code deployed on the Ethereum blockchain. There could be several functions in a contract. An ABI is necessary so that you can point to the specific function call that you want to evoke and also get a guarantee that the function will return data in the format you are expecting. 
The first four bytes of a transaction payload sent to a contract is usually used to distinguish which function in the contract to call.

1) Contract GeeksForGeeks has certain functions. Let’s call function baz(…).

 contract GeeksForGeeks {
  function empty() {}
  function baz(uint32 x, bool y) returns (bool r) 
 { if(x>0) 
     r = true;
       r =false;
  function Ritu(bytes _name, bool _x) {}

Function call baz with the parameters 69 and true, we would pass 68 bytes in total. 

Method ID. 
This is derived as the first 4 bytes of the Keccak-256 hash of the ASCII form of the signature baz(uint32,bool)

First parameter
uint32 value 69 padded to 32 bytes 

Second parameter 
boolean true, padded to 32 bytes

2) balanceOf is a function used to obtain the balance. The function signature is as follows:


Calculating the keccak256 hash of this signature string produces:


Taking the top four bytes gives us the following function selector or Method ID as also obtained above:


The ABI encoding is not part of the core protocol of Ethereum because the payload data in transactions are not required to have any structure, it is just a sequence of bytes. Similarly, the Ethereum Virtual Machine also just processes the data as a sequence of bytes. For example, a transaction contains the sequence of bytes. How these bytes are interpreted into structured data is up to the program and is up to the programming language used. In order to make it possible for two programs written in different programming languages to call each other, the compilers of such languages should implement the serialization and deserialization of data in the same way, i.e. although they should implement the ABI they are not compelled to.

Example: In the below example, a contract is created to store a number and returned the stored number. Below the example, there are two outputs: One is the ABI Output and the second one is the output of the execution of the code i.e. the simple Deploy and Run Output of the Solidity code.

// Solidity program to
// demonstrate abi encoding
pragma solidity >=0.4.22 <0.7.0;
// Creating a contract
contract Storage 
    // Declaring a state variable
    uint256 number; 
    // Defining a function
    // to store the number  
    function store(uint256 num) public 
        number = num;
    // Defining a function to 
    // send back or return the 
    // stored number
    function retrieve() public 
             view returns (uint256)
        return number;

ABI Output: 

        "inputs": [],
        "name": "retrieve",
        "outputs": [
                "internalType": "uint256",
                "name": "",
                "type": "uint256"
        "stateMutability": "view",
        "type": "function"
        "inputs": [
                "internalType": "uint256",
                "name": "num",
                "type": "uint256"
        "name": "store",
        "outputs": [],
        "stateMutability": "nonpayable",
        "type": "function"


Article Tags :