Understanding SMART CONTRACT - BYTECODE & ABI

In the last article, we saw how smart contracts are better than paper contracts. Read it here 👉 Intro to Smart Contracts

Lets Start....

We have seen how smart contracts are better than the old paper contracts, and how EVM makes sure that smart contracts keeps their promises.

Now, EVM doesn't understand any high level language. It understands low level language. So, we need to convert our smart contract into low level language i.e. BYTECODE.

💜 BYTECODE

• Bytecode is a low level language consisting combination of numbers and alphabets.
• Bytecodes are very hard to write as well as read. Basically its not human readable.
• Using different frameworks like solcjs,ethers, hardhat and many more, we can convert our smart contracts into bytecodes.
• This is how a bytecode looks for a very small and simple smart contract.

  608060405234801561001057600080fd5b50610771806100206000396000f3fe608060405234801561001057600080fd5b50600436106100575760003560e01c80632e64cec11461005c5780636057361d1461007a5780636f760f41146100965780639e7a13ad146100b2578063b2ac62ef146100e3575b600080fd5b610064610113565b
  

• We can see them as a combinations of numbers and alphabets.
• EVM is a stack machine, meaning it uses stack to run any script. It stores functions, would PUSH function, would POP them and many more.
• Bytecode may look gibberish but they are commands for EVM on how to interact with stack.
• If we convert these bytecodes into OPCODE i.e. operation code, we will see how or what commands these combinations are giving to EVM.
• There are many websites that can convert bytecode -> opcode. I am using etherscan. 👉https://etherscan.io/opcode-tool

This is what we get....

    [0] DUP1
    [2] PUSH1 0x40
    [3] MSTORE
    [4] CALLVALUE
    [5] DUP1
    [6] ISZERO
    [9] PUSH2 0x0010
    [10] JUMPI
    [12] PUSH1 0x00
    [13] DUP1
    [14] REVERT
    [15] JUMPDEST
    [16] POP
    [19] PUSH2 0x0771
    [20] DUP1
    [23] PUSH2 0x0020
    [25] PUSH1 0x00
    [26] CODECOPY
    [28] PUSH1 0x00
    [29] RETURN

👉 Remember EVM treats every number as a hexadecimal number. "0x" means that the number is a hexadecimal number. Now in-case of EVM, it doesn't need any "0x" as it treats every number as hexadecimal. So "0x40" in EVM we can put it as just "40".

Now these are different commands that helps EVM. Here is what they mean

1. PUSH1 0x40 -> This means to put 1 byte value of "0x40" in the stack. Now the hexadecimal value of PUSH1 is "60". So the commands become "6040".
2. MSTORE -> This will allocate memory of 0x60 and will move 0x40 in there. The hexadecimal code for MSTORE is "0x52".

So the final bytecode for these becomes...

604052

In this way every bytecode has their meaning and tells EVM what to do. We don't require to know about what every bytecode means for writing a smart contract. Just knowing what it does is good. But if you want to learn more, Here is a link that will help a lot Ethervm.io.

Now, In the last article we saw ABI. Well, Smart contracts are only good when someone can use it. So here helps ABI.

💜 ABI

• ABI stands for Application Binary Interface.
• ABI's are not as complicated as BYTECODE and are human readable.
• ABI looks like these :

[
  {
    "inputs": [
      {
        "internalType": "string",
        "name": "_name",
        "type": "string"
      },
      {
        "internalType": "uint256",
        "name": "_favouriteNumber",
        "type": "uint256"
      }
    ],
    "name": "addPerson",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  }
]

• As we can look these are just JSON format files with extension of .abi
• If we look closely these abi contains like type:'function' or "uint256" or "string".
• These files contains all the details about the smart contracts like variables , their type , their name as well as name of functions, access modifiers, they are payable or non-payable and many more.

Ex-> when type is "uint256" or "string" that means its a variable but when its "function" that means its a function.

• Its used when JavaScript wants to interact with smart contract, that is where abi comes in. without abi there will not be any interactions and you can't call any functions or do anything with it.

💜 Let's summarise....

• Smart contract requires bytecode and abi to run.
• Bytecode is non human readable and it tells EVM on how to execute the smart contract.
• Bytecode can be converted OpCode which is human readable.
• Every number in bytecode means a command in EVM. EVM assumes every number as hexadecimal.
• ABI is a JSON file with extension of .abi. It contains details about variables, access modifiers, function, their return types and many more.
• ABI makes it possible for JavaScript to call the functions in smart contract.

👉Remember if you can write correct BYTECODE and ABI, you can simply deploy that on the chain.

In the next article, we will see in how we can convert our smart contract to bytecode and ABI. We will also get basics of solidity and how to write smart contract and deploy.

Hello, I am Tanisk Annpurna

I post about

🚀web3, Blockchain, Ethereum

🐦Smart Contract, Solidity

🎉JavaScript, ReactJS, NodeJS

Follow and like for more such posts. !!✌️!!