Authored by Kwame Bryan
A brief overview of an ABI
In our last gaming lifehack, we compiled and deployed a simple ERC-20 token and integrated it into the ChainSafe Gaming SDK. Congratulations to anyone who used that tutorial and got it working!
In this guide, we will integrate the Application Binary Interface (ABI) to interface between Ethereum and our blockchain games. The Ethereum Virtual Machine (EVM) is at the core of the Ethereum network, and our smart contracts are pieces of code stored on the Ethereum blockchain which are executed on the EVM.
As an aside, when a smart contract is deployed, this bytecode is stored on the blockchain and is associated with an address. This concept is very similar to an API if you're coming from the Web2 world. The difference is that the ABI defines the methods and structures used to interact with the binary contract - just like the API does - but at a lower level.
For example, if we create a Solidity smart contract named ‘Test' as shown below:
The ABI that we're working with would look like this:
The ABI indicates to the caller of the function to encode the needed information (like function signatures, variable declarations, etc.) in a format that the EVM can understand so as to call that function in bytecode - this is called ABI encoding.
The elements of an ABI
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).
Generating the ABI and integrating it into the ChainSafe Gaming SDK
Next, let's use Remix to compile and deploy a simple, smart contract. Then we will verify this smart contract on Etherscan and integrate it into the ChainSafe Gaming SDK.
In the example, we will create, store, and return a stored number. There are two outputs: one is the ABI Output, and the second is the output of the execution of the code, i.e., the simple Deploy and Run Output of the Solidity code.
This is the ABI that will be generated from this smart contract.
Here's a video showing this process from beginning to end.
Got further questions? Hop into our Discord and join an active community of web3 game devs in the #gaming-general channel. Or, if you've got a project you'd like to show off, make sure to share it on our #gaming-showcase channel!
ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for the decentralized web. Alongside client implementations for Ethereum, Polkadot, Filecoin, and Mina, we're building a portfolio of web3 products - Files, Storage, web3.unity, and more. As part of our mission to build innovative products for users and better tooling for developers, ChainSafe embodies an open source and community-oriented ethos. To learn more, click here.