Understanding the Compilation Process in Solidity

ยท

4 min read

In the previous tutorial, we learned how to use Remix IDE to compile and deploy a Solidity smart contract. Now, let's examine what happens during the compilation process of a Solidity smart contract.

This guide will explain the behind-the-scenes activities that occur when you compile your Solidity code. By the end, you'll have a better understanding of ABI (Application Binary Interface), bytecode, and how they work together to connect your smart contract to the Ethereum blockchain and external applications.


Step 1: Source Code and the Solidity Compiler

For example, 1_Storager.sol, which contains the code for your smart contract.

When you compile this file using Remix IDE, it leverages a compiler known as Solc (Solidity Compiler) to process the code.

Key Point:

  • Remix IDE is just an interface; the actual compilation is performed by Solc.

Step 2: Output of Compilation

When Solc processes the source.sol file, it generates two key outputs:

  1. ABI (Application Binary Interface)

  2. Bytecode

What is ABI?

The ABI (Application Binary Interface) serves as a bridge between your smart contract and the external world. If youโ€™re building a decentralized application (dApp), your frontend (e.g., a ReactJS application) will use the ABI to communicate with the smart contract.

  • Functionality: The ABI defines the structure of your contract, including functions, events, and variables. It specifies how external applications can call functions or access data from your contract.

  • Example: If your smart contract contains two functions, store and retrieve, the ABI will include details about these functions, such as their names, input parameters, and output types.


What is Bytecode?

The bytecode is the low-level representation of your smart contract, which gets deployed to the Ethereum blockchain. Unlike the human-readable Solidity code, bytecode consists of machine-readable instructions that Ethereum nodes execute.

  • Contents: Bytecode contains the logic of your smart contract encoded in a format understood by the Ethereum Virtual Machine (EVM).

  • Deployment: When you deploy a contract, only the bytecode gets stored on the blockchain, not your Solidity source code.


Example: ABI and Bytecode in Action

Let look up the built-in contract โ€œ1_Storage.solโ€

// SPDX-License-Identifier: GPL-3.0

pragma solidity >=0.8.2 <0.9.0;

/**
 * @title Storage
 * @dev Store & retrieve value in a variable
 * @custom:dev-run-script ./scripts/deploy_with_ethers.ts
 */
contract Storage {

    uint256 number;

    /**
     * @dev Store value in variable
     * @param num value to store
     */
    function store(uint256 num) public {
        number = num;
    }

    /**
     * @dev Return value 
     * @return value of 'number'
     */
    function retrieve() public view returns (uint256){
        return number;
    }
}

Compilation Outputs

  1. ABI
    The ABI contains metadata about the functions (store and retrieve) and variables in the contract:

     [
         {
             "inputs": [],
             "name": "retrieve",
             "outputs": [
                 {
                     "internalType": "uint256",
                     "name": "",
                     "type": "uint256"
                 }
             ],
             "stateMutability": "view",
             "type": "function"
         },
         {
             "inputs": [
                 {
                     "internalType": "uint256",
                     "name": "num",
                     "type": "uint256"
                 }
             ],
             "name": "store",
             "outputs": [],
             "stateMutability": "nonpayable",
             "type": "function"
         }
     ]
    
  2. Bytecode
    The bytecode consists of hexadecimal instructions for the Ethereum Virtual Machine (EVM):

     6080604052348015600e575f5ffd5b506101298061001c5f395ff3fe6080604052348015600e575f5ffd5b50600436106030575f3560e01c80632e64cec11460345780636057361d14604e575b5f5ffd5b603a6066565b60405160459190608d565b60405180910390f35b606460048036038101906060919060cd565b606e565b005b5f5f54905090565b805f8190555050565b5f819050919050565b6087816077565b82525050565b5f602082019050609e5f8301846080565b92915050565b5f5ffd5b60af816077565b811460b8575f5ffd5b50565b5f8135905060c78160a8565b92915050565b5f6020828403121560df5760de60a4565b5b5f60ea8482850160bb565b9150509291505056fea26469706673582212202cea03f67c4fe745ae13812f1274b78c1f2a3eddb43bb7dd680a2b702d0b068664736f6c634300081c0033
    

    This code is what gets deployed to the blockchain, enabling the smart contract to operate.


Key Takeaways

  1. Public Nature of Bytecode

    • Once deployed on the blockchain, the bytecode becomes public and readable.

    • However, the Solidity source code itself doesnโ€™t have to be public.

  2. Immutability

    • Bytecode is immutable; you cannot change it after deployment.
  3. ABI as a Bridge

    • ABI facilitates communication between external applications (e.g., ReactJS) and the smart contract.
  4. Non-Reversible Process

    • ABI and bytecode are generated from the Solidity source code.

    • Itโ€™s a one-way processโ€”you canโ€™t regenerate the original Solidity code from ABI or bytecode.


Conclusion

Understanding the compilation process is crucial because it is the foundation for developing, deploying, and interacting with smart contracts. By learning how ABI and bytecode function, you can efficiently connect your smart contracts with external applications and make use of the Ethereum blockchain for your dApps.

Stay tuned and happy coding! ๐Ÿš€

ย