Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Ethereum
ABI Overview

What is an ABI of a Smart Contract?

Examples and Usage for Developers
Last Updated:
March 9, 2022
Table of Contents

{{building-alchemy-ad}}

Introduction

The Application Binary Interface (ABI) of a smart contract gives a contract the ability to communicate and interact with external applications and other smart contracts. Receiving data from external sources can be critical for completing the goals of the application and the user.  

In traditional web development, conversations about data happen between applications and servers through API's (Application Program Interface). Servers act as centralized sources of information that feed data to application by request. 

On a blockchain, no such centralization of data exists.  Nodes essentially act as servers and smart contracts are on chain "hosted" functions.  Applications outside of the blockchain (and other smart contracts) need a way to communicate with smart contracts that are on-chain. This is where ABI comes into play. 

Why ABI?

Before going into more details about what ABI is, it is good to understand why we have it.

Smart contracts are the core applications of the EVM (Ethereum Virtual Machine). The purpose of smart contracts is to execute transactions when certain conditions defined in the contract are met. These conditions can be events both on or off-chain. Smart contracts are written in high-level languages like Solidity but they are stored on the EVM  as executable bytecode, which is in binary format. 

Source: https://hackernoon.com/hn-images/1*Sz1a7G2pQ62UnkHoieve4w.jpeg

Since this bytecode is not human readable, it requires interpretation to be understood. ABI allows anyone writing a smart contract to be able to communicate between a web application written in a high-level language like Javascript and the bytecode that the EVM understands. 

What is an ABI?

Like its Web2 cousin, the API, ABI acts as a function selector, defining the specific methods that can be called to a smart contract for execution. These specific methods and their connected data types are listed in a generated JSON RPC file. 

Source:https://static.packt-cdn.com/products/9781789954111/graphics/assets/fe0f2ffc-2f3c-4615-9cb5-43c8e036239b.png

Unlike an API, we can't just send a request directly in JSON format to a smart contract and expect a response since a contract only communicates in bytecode. To translate this into something the EVM understands, this information is encoded via ABI encoding.  These encodings include function signatures and variable declarations so that the EVM knows exactly which function to execute within the smart contract. 



The responses are also in the bytecode so interpretation is required before it is processed by a web application. The advantage of using bytecode in the response is that we can also expect a certain structure to be returned after calling a contract's function. 

How to use ABI?

Generation 

If you are using tooling like Hardhart/Truffle or an IDE like Remix, the contract ABI is automatically generated for you. You can also manually create the ABI by using the Solidity Compiler NPM package. After installing the package, you can run the ‘solcjs contractname.sol --abi’ command in a terminal. This will generate an .abi file if performed successfully. 

Now that you have a generated ABI, let's look at some of the elements in this file:  


Executing

As ABI operates as the interpreter between the EVM bytecode and Javascript of a website,  it is needed when you want to execute any functions of a smart contract. In addition to the ABI, the contract's address on the blockchain is required. Here is a small Javascript code snippet to show how this is done:




If you are interested in finding the ABI of an already deployed contract, you can find this by searching on Etherscan with the contract's address. For example here:



Encoding 

Since all communication is done in bytecode, it would be difficult to expect developers to encode these messages themselves. Fortunately, popular compilers like Remix can also handle the encoding for you. These encodings follow a certain pattern, so one can have a better idea of what is going on by reviewing the ABI Specification.

The first four bytes are the function signature which indicates what type of function in the smart contract is being executed. A popular function identifier is a9059cbb which indicates that this is an ERC20 transfer. There is a database directory of function signatures here where you can explore more. 


Source: https://miro.medium.com/max/1400/1*YDi7sDUmAc3wjN8TcIBrog.png

From the fifth byte onward are where the arguments are encoded. Responses follow this similar structure but without the function signature included. 

Conclusion

ABI can oftentimes be an overlooked aspect of working with smart contracts but it plays an important role in the usability of this technology.  Building on smart contract tutorials is a great way to understand the power of this silent workhorse and a great way to apply your knowledge.

ABI Overview

What is an ABI of a Smart Contract?

Examples and Usage for Developers

Introduction

The Application Binary Interface (ABI) of a smart contract gives a contract the ability to communicate and interact with external applications and other smart contracts. Receiving data from external sources can be critical for completing the goals of the application and the user.  

In traditional web development, conversations about data happen between applications and servers through API's (Application Program Interface). Servers act as centralized sources of information that feed data to application by request. 

On a blockchain, no such centralization of data exists.  Nodes essentially act as servers and smart contracts are on chain "hosted" functions.  Applications outside of the blockchain (and other smart contracts) need a way to communicate with smart contracts that are on-chain. This is where ABI comes into play. 

Why ABI?

Before going into more details about what ABI is, it is good to understand why we have it.

Smart contracts are the core applications of the EVM (Ethereum Virtual Machine). The purpose of smart contracts is to execute transactions when certain conditions defined in the contract are met. These conditions can be events both on or off-chain. Smart contracts are written in high-level languages like Solidity but they are stored on the EVM  as executable bytecode, which is in binary format. 

Source: https://hackernoon.com/hn-images/1*Sz1a7G2pQ62UnkHoieve4w.jpeg

Since this bytecode is not human readable, it requires interpretation to be understood. ABI allows anyone writing a smart contract to be able to communicate between a web application written in a high-level language like Javascript and the bytecode that the EVM understands. 

What is an ABI?

Like its Web2 cousin, the API, ABI acts as a function selector, defining the specific methods that can be called to a smart contract for execution. These specific methods and their connected data types are listed in a generated JSON RPC file. 

Source:https://static.packt-cdn.com/products/9781789954111/graphics/assets/fe0f2ffc-2f3c-4615-9cb5-43c8e036239b.png

Unlike an API, we can't just send a request directly in JSON format to a smart contract and expect a response since a contract only communicates in bytecode. To translate this into something the EVM understands, this information is encoded via ABI encoding.  These encodings include function signatures and variable declarations so that the EVM knows exactly which function to execute within the smart contract. 



The responses are also in the bytecode so interpretation is required before it is processed by a web application. The advantage of using bytecode in the response is that we can also expect a certain structure to be returned after calling a contract's function. 

How to use ABI?

Generation 

If you are using tooling like Hardhart/Truffle or an IDE like Remix, the contract ABI is automatically generated for you. You can also manually create the ABI by using the Solidity Compiler NPM package. After installing the package, you can run the ‘solcjs contractname.sol --abi’ command in a terminal. This will generate an .abi file if performed successfully. 

Now that you have a generated ABI, let's look at some of the elements in this file:  


Executing

As ABI operates as the interpreter between the EVM bytecode and Javascript of a website,  it is needed when you want to execute any functions of a smart contract. In addition to the ABI, the contract's address on the blockchain is required. Here is a small Javascript code snippet to show how this is done:




If you are interested in finding the ABI of an already deployed contract, you can find this by searching on Etherscan with the contract's address. For example here:



Encoding 

Since all communication is done in bytecode, it would be difficult to expect developers to encode these messages themselves. Fortunately, popular compilers like Remix can also handle the encoding for you. These encodings follow a certain pattern, so one can have a better idea of what is going on by reviewing the ABI Specification.

The first four bytes are the function signature which indicates what type of function in the smart contract is being executed. A popular function identifier is a9059cbb which indicates that this is an ERC20 transfer. There is a database directory of function signatures here where you can explore more. 


Source: https://miro.medium.com/max/1400/1*YDi7sDUmAc3wjN8TcIBrog.png

From the fifth byte onward are where the arguments are encoded. Responses follow this similar structure but without the function signature included. 

Conclusion

ABI can oftentimes be an overlooked aspect of working with smart contracts but it plays an important role in the usability of this technology.  Building on smart contract tutorials is a great way to understand the power of this silent workhorse and a great way to apply your knowledge.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer