5 min read

Overview

While interacting with a smart contract ABI is one of the essential components. In this guide, let us understand what the ABI of smart contracts is.

Prefer a video walkthrough? Follow along with Radek and learn about ABI in 11 minutes.

Subscribe to our YouTube channel for more videos!Subscribe

What is ABI?

ABI (Application Binary Interface) in the context of computer science is an interface between two program modules, often between operating systems and user programs.

EVM (Ethereum Virtual Machine) is the core component of the Ethereum network, and smart contract is pieces of code stored on the Ethereum blockchain which are executed on EVM. Smart contracts written in high-level languages like Solidity or Vyper need to be compiled in EVM executable bytecode; when a smart contract is deployed, this bytecode is stored on the blockchain and is associated with an address. For Ethereum and EVM, a smart contract is just this sequence of bytecode. To access functions defined in high-level languages, users need to translate names and arguments into byte representations for byte code to work with it. To interpret the bytes sent in response, users need to convert back to the tuple of return values defined in higher-level languages. Languages that compile for the EVM maintain strict conventions about these conversions, but in order to perform them, one must know the precise names and types associated with the operations. The ABI documents these names and types precisely, easily parseable format, doing translations between human-intended method calls and smart-contract operations discoverable and reliable.

It is very similar to API (Application Program Interface), a human-readable representation of a code’s interface. ABI defines the methods and structures used to interact with the binary contract, just like API does but on a lower-level. The ABI indicates the caller of the function to encode the needed information like function signatures and variable declarations in a format that the EVM can understand to call that function in bytecode; this is called ABI encoding. ABI encoding is mostly automated, taken care of by compilers like REMIX or wallets interacting with the blockchain. Contract ABI is represented in JSON format. There are clear specifications of how to encode and decode a contract ABI.

Understanding the elements of ABI

The JSON format of a contract’s ABI is given by various functions and/or events descriptions.

Following are the elements present in the ABI description of a function:

• type: Defines the type of function. It can be one of the following, ‘function’, ‘constructor’, ‘receive' (for receive ether function), or ‘fallback’ (for default function).
• name: Defines the name of the function.
• inputs: It is an array of objects which defines parameters; each object has:
  • name: Defines the name of the parameters.
  • type: Defines the canonical types of the parameters. For example, uint256.
  • components: Used to define tuple types, if a tuple type is reached, it is represented as type = tuple [other properties of tuple elements like name, type goes here].
• outputs: It is an array of output objects similar to inputs.
• stateMutability: Defines the mutability of a function. It can be one of the following values: ‘pure’ (specified not to read or write blockchain state), ‘view’ (specified when blockchain state is to be read, but no modification can be done), ‘nonpayable’ (this is the default mutability and doesn’t need to be mentioned while writing a function in code, this means a function does not accept Ether; using this we can read and write blockchain state), ‘payable’ (mentioning this means a function accepts Ether and can read/write blockchain state).

Note: The ABI of Constructor and fallback functions have name and output fields blank; even the input field is empty for the fallback function.

Following are the elements present in the ABI description of an event:

• type: here, it’s always ‘event’.
• name: Defines the name of the event.
• inputs: It is an array of objects which defines parameters; each object has:
  • name: Defines the name of the parameters.
  • type: Defines the canonical types of the parameters. For example, uint256.
  • components: Used to define tuple types, if a tuple type is reached, it is represented as type = tuple [other properties of tuple elements like name, type goes here].
  • indexed: This is ‘true’ if the field is part of the log’s topics and ‘false’ if it is one of the log’s data segments.
• anonymous: This field is true if the event was declared as anonymous in the contract code.

How to get/generate ABI?

One of the most common ways is to copy the ABI using the ABI button under compile tab of Ethereum REMIX IDE after the smart contract has complied.

Another way is compiling and generating ABI using solc, which provides JavaScript bindings for Solidity Compiler. To install solc, we need to have npm, which comes with node.js. Check if node.js is installed on your system or not.

$ node -v

If not installed, you can download the LTS version of NodeJS from the official website.

Now let’s install solc

$ npm install solc

We’ll compile and generate ABI for the following contract, test.sol which is a contract to increment the value of a variable:

Explanation of the code above

Line 1: Specifying SPDX license type, which is an addition after Solidity ^0.6.8; whenever the source code of a smart contract is made available to the public, these licenses can help resolve/avoid copyright issues. If you do not wish to specify any license type, you can use a special value UNLICENSED or simply skip the whole comment (it won’t result in an error, just a warning).

Line 2: Declaring the Solidity version.

Line 4: Starting our contract name test.

Line 6: Declaring a private variable named count of type unsigned integer and assigning value zero to it.

Line 8-10: Declaring a public function increment, which increases the value of count by one when called.

Line 12-14: Declaring a public function getCount which will return the value of count in unsigned integer form.

Now, let’s get the ABI for the above contract.

$ solcjs test.sol --abi

A file named test_sol_test.abi will be created in the same directory; it will have the ABI in the JSON format something like this:

[
    {
        "inputs": [],
        "name": "getCount",
        "outputs": [
            {
                "internalType": "uint256",
                "name": "",
                "type": "uint256"
            }
        ],
        "stateMutability": "view",
        "type": "function"
    },
    {
        "inputs": [],
        "name": "increment",
        "outputs": [],
        "stateMutability": "nonpayable",
        "type": "function"
    }
]

Conclusion

Now that you know what ABI is, learn more about Solidity,  Vyper smart contracts, and create your smart contracts. Learn more about ABI specifications from Solidity docs.

Subscribe to our newsletter for more articles and guides on Ethereum. If you have any feedback, feel free to reach out to us via Twitter. You can always chat with us on our Discord community server, featuring some of the coolest developers you'll ever meet :)