What is an ABI and why is it needed to interact with contracts?

Question

ABI is referenced in many places including the official Ethereum website. What is an ABI and why is it necessary to use?

Answer 1

ABI stands for application binary interface.

In general, an ABI is the interface between two program modules, one of which is often at the level of machine code. The interface is the de facto method for encoding/decoding data into/out of the machine code.

In Ethereum, it's basically how you can encode Solidity contract calls for the EVM and, backwards, how to read the data out of transactions.

Answer 2

The ABI, Application Binary Interface, is basically how you call functions in a contract and get data back.

An ABI determines such details as how functions are called and in which binary format information should be passed from one program component to the next...

An Ethereum smart contract is bytecode deployed on the Ethereum blockchain. There could be several functions in a contract. An ABI is necessary so that you can specify which function in the contract to invoke, as well as get a guarantee that the function will return data in the format you are expecting.

From Ethereum's ABI specification, an example:

contract Foo {
  function bar(real[2] xy) {}
  function baz(uint32 x, bool y) returns (bool r) { r = x > 32 || y; }
  function sam(bytes name, bool z, uint[] data) {}
}

If we wanted to call baz with the parameters 69 and true, we would pass 68 bytes in total, which can be broken down into:

0xcdcd77c0: the Function Selector. This is derived as the first 4 bytes of the Keccak-256 hash of the ASCII form of the Function Signature baz(uint32,bool). 0x0000000000000000000000000000000000000000000000000000000000000045: the first parameter, a uint32 value 69 padded to 32 bytes 0x0000000000000000000000000000000000000000000000000000000000000001: the second parameter - boolean true, padded to 32 bytes

The 68 bytes is what would be specified in the data field of a transaction, also called calldata: a security note on that is here. (To summarise, be careful what you put in the data field, because it can have unintended, possibly malicious side-effects when passing it to the calling contract.)

To avoid a common pitfall when deriving the Function Selector, the canonical types must be used, for example uint256 instead of uint.

Here is an example in Solidity of computing a Function Selector for sam above:

bytes4(keccak256("sam(bytes,bool,uint256[])")

Using a higher-level library such as web3.js abstracts most of these details, but the ABI in JSON format still needs to be provided to web3.js.

Note: the ABI is an abstraction that is not part of the core Ethereum protocol. Anyone can define their own ABI for their contracts (starting example), and any callers of such contracts would have to comply with that ABI to get meaningful results. However, it is simpler for all developers to use current compilers (example Solidity) and libraries (example web3.js, ethers.js) which all comply with the ABI above.

Answer 3

Contract Defintion: Formal definition in high-level code (e.g. solidity).

Compiled Contract: The contract converted to byte-code to run on the Ethereum Virtual Machine (EVM), adhering to the specification. Note the function names and input parameters are hashed during compilation. Therefore, for another account to call a function, it must first be given the function name and arguments - hence the ABI.

Application Binary Interface - ABI: A list of the contract's functions and arguments (in JSON¹ format). An account wishing to use a smart contract's function uses the ABI to hash the function definition, so it can create the EVM bytecode required to call the function. This is then included in the data field, T_d, of a transaction and interpreted by the EVM with the code at the target account (the address of the contract).

---

¹Use of JSON is a de-facto standard; it's not in the formal spec but changing it would result in a need to amend many of the tools.

Answer 4

think of "ABI" as an "API" at a low level.

Think of it as the compiled version of an API (or as an API on the low level). As you know the contracts are stored as bytecodes in a binary format into the blockchain under a specific address. No one understands binary, so the ABI defines the structures and methods that you will use to interact with that binary contract (just like the API did), only on a lower level. The ABI indicates to the caller the needed information (functions signatures and variables declarations) to encode a meaningful(understood by the VM) call to the bytecode(contract).

additional info "from the official doc"

An Application Binary Interface (ABI) is intended to serve as the de facto method for encoding & decoding data into & out of transactions

.

We assert that all contracts will have the interface definitions of any contracts they call available at compile-time.

Answer 5

In case you want to use a simple online tool to encode parameters you could use https://abi.hashex.org

You insert the abi code to automatically parse parameters types or just enter them manually. In Function type selector constructor should be picked.

Here is an example, at the bottom are abi-encoded parameters that you enter in etherscan.io constructor parameters field input.

Answer 6

I was having a terribly hard time understanding the why part of this question myself, so I'd like to add one thing thanks to this excellent answer:

"How these bytes are interpreted into structured data is up to the program and thus 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. they should implement the ABI specification, but they do not have to."

tl;dr a contract written in Solidity can interact with a contract written in Viper or Bamboo because they all implement and adhere to the ABI specification.

Answer 7

Just copy this json. This is contract ABI

Answer 8

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.

Source

Answer 9

An ABI is like others said the Application Binary Interface - it's a lower level interface but it doesn't have to be inaccessible to programmers, for instance on linux: /sys/bus/usb/devices/.../power/persist
is an example of an ABI. You can access many other Linux ABI's via /sys/bus/

See: https://www.kernel.org/doc/Documentation/ABI/

Answer 10

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.

Source of this article - https://www.alchemy.com/overviews/what-is-an-abi-of-a-smart-contract-examples-and-usage