We saw in the previous clip that any smart contract which is written in
a high-level programming language like Solidity can be fed into a compiler
in order to generate bytecode.
This bytecode in fact translates to a number of opcodes,
and this is also something which is produced by the compiler.
As an example,
we had taken a look at a simple Hello World program written in Solidity.
And following that,
we saw that this is in fact translated to these lines of bytecode.
In case you're wondering, this is in fact the actual bytecode
of the Solidity code which you see in front of you.
So once we have a bytecode for a particular smart contract,
this can be used with an EVM in order to run the contract code.
However, if someone were to only give us the bytecode of a smart contract, and
in fact, this is exactly what is saved on the blockchain network.
You can see that it is not possible for us to decipher
exactly what this contract represents by merely looking at the bytecode.
So if there was a method in the smart contract which we wanted to invoke,
we can't really tell what methods it contains in the first place.
This bytecode includes a function called print Hello World, but
there are no interfaces available here in order for us to invoke it directly.
The same can be said with the opcodes as well.
And while this is definitely a lot more human-readable than the bytecode,
it still doesn't give us any information about what methods
are contained within this contract code.
So if you were to know the location of a smart contract on the blockchain
network, this will give us access to the bytecode of that contract.
While the bytecode itself can be executed, smart contracts are only useful
if we can pick the specific method which we would like to invoke.
And the bytecode alone does not allow us to decipher these methods.
So if you would like to execute specific methods which are defined within
a smart contract, what we really need are some details about those methods and
some interfaces in order to access them.
And what can provide this information to us?
Well, an application binary interface is one such structure.
This is in fact simply a JSON file.
And within it, it includes descriptions of the contract itself and
each of the functions which are defined within it.
The description will include the function parameters,
as well as the return types.
Given these descriptions, we have all the necessary information
in order to call the functions from a smart contract.
To understand exactly what an application binary interface, or ABI,
looks like, let us go back to our Hello World program in the Solidity language.
You can see for example, that this includes a function called
print Hello World, which takes in no arguments, but it returns a string value.
And the ABI file for this contract, well, this is what it looks like.
You can clearly see that this is a JSON definition and
that the name of the function, which is defined here is printHelloWorld.
The input field shows that it does not take in any arguments.
And the output field confirms that there is just a single value,
which is return, and this is of type string.
So this is all very useful, but how exactly is an ABI file generated?
Well, this is also an output of a smart contract compiler.
So along with the bytecode of a contract,
which enables the contract code to be executed.
And the opcodes, which allow us to calculate the complexity of operations in
a contract, a compiler can also generate an ABI file.
What we really need are simply the ABI and the bytecode.
So the ABI file, as we have seen includes a description of the contract.
However, this is something which cannot be executed on its own.
The bytecode, on the other hand, can be executed but
does not really include any context of the contract.
So we don't really know, for
example, what methods are included within the contract.
However, a combination of the ABI and
the bytecode does give us all of the necessary information
in order to invoke and then execute specific methods in the smart contract.
So if you happen to have a rather large contract with
a number of different functions defined within it, you'll probably call just
a single function at any given time in order to invoke a transaction.
And the way to do this is by a combination of the bytecode
and the ABI for the contract.
Once you have the two of these, it is possible for you to call specific methods
in a smart contract, and then invoke the transactions which you need.