Application Binary Interface(ABI) in Ethereum Virtual Machine
Last Updated : 11 May, 2022
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; else 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) 0xcdcd77c0 First parameter uint32 value 69 padded to 32 bytes 0x0000000000000000000000000000000000000000000000000000000000000045: Second parameter boolean true, padded to 32 bytes 0x0000000000000000000000000000000000000000000000000000000000000001:
2) balanceOf is a function used to obtain the balance. The function signature is as follows:
balanceOf(address)
Calculating the keccak256 hash of this signature string produces:
0x70a08231b98ef4ca268c9cc3f6b4590e4bfec28280db06bb5d45e689f2a360be
Taking the top four bytes gives us the following function selector or Method ID as also obtained above:
0x70a08231
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 // 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" } ] Output:
Similar Reads
Solidity - Basics of Interface Interfaces are the same as abstract contracts created by using an interface keyword, also known as a pure abstract contract. Interfaces do not have any definition or any state variables, constructors, or any function with implementation, they only contain function declarations i.e. functions in inte
2 min read
Virtualization | A Machine Reference Model Prerequisite: Introduction to Virtualization When an execution environment is virtualized at unlike levels of the stack of computation then it requires a reference model which defines the interfaces within the level of abstractions, and this level of abstraction hides the details of implementations.
3 min read
Hardware Based Virtualization Prerequisite - Virtualization In Cloud Computing and Types, Types of Server Virtualization, Hypervisor A platform virtualization approach that allows efficient full virtualization with the help of hardware capabilities, primarily from the host processor is referred to as Hardware based virtualizatio
5 min read
Virtualization | Xen: Paravirtualization Prerequisites - Introduction to Virtualization, Machine Reference Model of Virtualization Xen is an open source hypervisor based on paravirtualization. It is the most popular application of paravirtualization. Xen has been extended to compatible with full virtualization using hardware-assisted virtu
5 min read
SAP ABAP | Interfaces ABAP(Advanced Business Application Programming) is an object-oriented programming language that supports many oops concepts like other programming languages. It supports all the four pillars of oops i.e. Inheritance, Polymorphism, Abstraction, and Encapsulation. The interface is one of the oops conc
4 min read