DEV Community: Ephraim Chukwu

Testing a Smart Contract

Ephraim Chukwu — Sat, 07 May 2022 22:49:36 +0000

Smart contracts are series of operation programmed to carry out a particular logic. While this is a typical feature of any software, to carry out an operation, smart contracts are different because all interaction to the logic of smart contracts cost money, excepts for a view function not called by a smart contract. And with the programmed smart contract being an account, it is susceptible to attack and funds could be stolen.

Due to the possibility of a smart contract having a bug, it is important to run a test on the logic in a contract so as to find out possible errors. In this article, you will understand what test do, understand different kind of tests, and will also walk you through some testing operation with a framework.

Why You Must Test Your Smart Contracts?

Test aids programmers in checking the logic in their codes. These tests are programmed scenarios to help ascertain the effectiveness of an algorithm. They could be programmed to check that a function that does addition when passed in two parameters, for example, sum(2,2) should equal 4.

These set of operations are important to help unravel the presence of bugs. Test being a pointer of bugs, they are crucial for your smart contracts in order to check for possible vulnerabilities. The correctness of a logic is discovered when you run multiple thorough tests of different scenarios.

Different Kinds of Tests

There are different kind of tests that exist, depending on the number of operations under observaton. While it is certain that despite carrying out tests and pushing your codebase for auditing to reduce bugs, there are possibility of discovering novel vulnerability. Possible test scenarios are as follows:

UNIT-TESTING

Unit-testing is a form of testing a fraction or small units of your application locally. This scrutinizes the correctness of an operation in a software. In a test-driven ecosystem, minute parts of a software are tested to ensure that it correlates with the coded logic.

TESTS FOR INTEGRATION

When features and libraries are integrated into smart contracts, the integration test expects to know the validity of logic. You can test that the Openzeppelin utilities, may be Reentrancy Guard or the SafeMath library, are working appropriately as expected when integrated into your project.

FUZZ TESTING

Fuzz testing are the insertion of wrong or incorrect inputs to help discover defects in a software. It is often called fuzzing because it is a process of carrying out or interracting with applications in an unexpected scenarios in order to unravel faults in the development process.

END-TO-END FUNCTIONAL TESTING

This form of testing is a complete test to check all the functionalities in the application. It tests the application as if it is running on the mainnet. This involves forking mainnet, impersonating addresses, setting balance of an address, getting storage and warping time and much more features.

Testing Smart Contract with Hardhat

Hardhat is a fast, extensible and flexible ethereum development tool for creating, testing and deploying smart contracts. This is a Javascript framework created to help in the compilation of contracts, test for possible bugs, debug errors and deploy to different networks. The Hardhat framework comes with a lot of packages that enables you write your contract and also allows for the use of ethers to test smart contract and run scripts for deployment.

We will be testing the default contract that comes with the Hardhat framework. You can check out this for the installation.

When you successfully install hardhat, you will find the contract below in contracts/Greeter.sol.

//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

import "hardhat/console.sol";

contract Greeter {
    string private greeting;

    constructor(string memory _greeting) {
        console.log("Deploying a Greeter with greeting:", _greeting);
        greeting = _greeting;
    }

    function greet() public view returns (string memory) {
        return greeting;
    }

    function setGreeting(string memory _greeting) public {
        console.log("Changing greeting from '%s' to '%s'", greeting, _greeting);
        greeting = _greeting;
    }
}

The Greeter contract is a simple contract that has a state private string variable, called greeting. It has a constructor that receives a string memory variable as a parameter. This parameter sets at constructor is consoled log with the imported hardhat console and the next line sets the state string variable to the input from the constructor.

The two functions, the one with the view visibility and the one without, reads from state and writes to state respectively . The view function greet reads the present greeting value. The other, setGreeting, receives a parameter to change or set the greeting.

The default test that comes with the contract above is as follows:

import { expect } from "chai";
import { ethers } from "hardhat";

describe("Greeter", function () {
  it("Should return the new greeting once it's changed", async function () {
    const Greeter = await ethers.getContractFactory("Greeter");
    const greeter = await Greeter.deploy("Hello, world!");
    await greeter.deployed();

    expect(await greeter.greet()).to.equal("Hello, world!");

    const setGreetingTx = await greeter.setGreeting("Hola, mundo!");

    // wait until the transaction is mined
    await setGreetingTx.wait();

    expect(await greeter.greet()).to.equal("Hola, mundo!");
  });
});

This is a chai test. Chai is a Javascript testing framework to tests for bugs. Other popular ones are Mocha and Jest. It is important to add that with the introduction of Foundry, it is possible now to run tests all with the Solidity language.

According to the code, it first imports expect from chai and imports ethers. The describe method is to identify the function being tested. The it description notes the primary purpose for the test.

In order to tests the function in the contract, it is important to first deploy the contract and then make its functions accessible for testing. This is where ethers help in deployment. Greeter is the constant that gets the contract to be deployed, the constant greeter is passing in the value to the constructor and the next line deploys the contract.

The first expect checks that on calling the greeter function which is a read function, the outputs will be equal to the passed "Hello World!. The next line is the calling of the setGreeting function and a value passed to it. The line that follows checks that transaction is successfully mined and then it expects that the new greeting value is truly the new value.

There are other possible checks that these tests framework make available. They include expectRevert, beforeEach, greaterThan, and many more.

All of these are to check the validity of the operation whether it tallies with its intended purpose. Test assures you to a level that your contract is less prone to attack.

With this introduction to testing of smart contract, I hope that you will build the habit of testing your logic so that your contract doesn't become the hacker's next target.

...More Than Just Solidity

Ephraim Chukwu — Tue, 03 May 2022 23:19:49 +0000

Reminiscing through the past, I’ve dug into a well of thoughts concerning this road; this road to becoming a smart contract developer. One moment I want beat myself slightly on the chest, label myself a blockchain developer, and claim it anywhere, another moment I remember how much of unread resources I have; the wide pore of knowledge I’ve unfilled. In this article, I will share why the pursuit, whether as a smart contract developer or a core blockchain developer, you must have an engagement way beyond Solidity.

Being a relatively new ecosystem, ushering big changes to every aspect of human lives, blockchain technology over the past few months has been dubbed one of the highest paying programming job. This, on a higher scale, isn’t untrue. It’s a field that involves money it self. If you must engage with a decentralized applications built on a blockchain network, you require to pay for transactions. Simply put, all engagements are transactions. For this reason, there are way too much technicalities into the system and the everyday growth in making this technology widely acceptable, is on a press, fast growing and accommodating field.

While this is not only being accepted among users, blockchain development is the learn-in-five-hours-to-make-300k-dollars-a-year. Developers are hopping on understanding Solidity, know the basics and build smart contracts that hoards money for people. What else does smart contract properly written in the Solidity, Vyper, Serpent language do rather than save funds after all?

As wrong as this might seem, the rate of hacks of smart contracts is on the rise. This, for anyone who follows the crypto twitter spaces, will agree on how disheartening it is to loss money to a blackhat or to lock funds due to poor or unnoticeable algorithms lapses. This is why the emphasis is on good understanding of data structure and algorithms.

While my engagement with blockchain as a developer isn’t exhaustive enough to warrant this content, the little leap I’ve had from my four month knowledge infusion in Web3bridge bootcamp has exposed me, especially taking lessons from a tutor who is vast in the technology. The tutor, unfortunately, won’t agree to being the best of smart contract developers because his own pursuit of knowledge, not just in aspect of blockchain, isn’t ending anytime soon. The pursuit is a cycling into the dark forest.

While Ethereum didn’t initiate the ground for blockchain technology, a whole lot of arguments goes into how it differs from Bitcoin. It doesn’t cross your mind right. I will give you a few different; Ethereum supports for smart contract, Bitcoin doesn’t. The underlying native currency differs. Bitcoin to BTC as Ethereum to Ethers. While Ethereum uses accounts for transactions, Bitcoin uses UTXO (Unspent Transactions Output). How much of these differences do you know apart from Solidity? This isn’t just it.

The Ethereum Virtual Machine, EVM, being a turing complete stack-based machine, it’s bounded by gas usage for transactions. Don’t mind the fluff but how much do you know about how the EVM works. How are transactions added to a block and how do these blocks get propagated across nodes? What’s the effectiveness of gas to the EVM? Who are miners and how much influence do they have in the validation of transactions? What consensus mechanism does Ethereum use? What are EIPs (Ethereum Improvements Proposals) and how does it differ from Ethereum Request for Comments(ERCs)? How are these salience to Ethereum ecosystem? This again, aside being a whole log of jargon, is relevance if you must use solidity to build contracts on the EVM and compatible networks.

EVM opcodes? You, provably, have seen them somewhere or will certainly see them as you ride on as a solidity developer but do you care to check how your high level language are compiled into opcodes which the EVM understands. You sure can speak on gas optimization, slot storage, proxy pattern, and more. A whole lot already, right?

Need I add that these are truly overwhelming. And for this, it is the primary reason you must not end up as a basic solidity developer. A minute knowledge of how this system works will only yield “costly-trodden” application that your user's can’t use; less-performant dapps.

Take another glance, just one glance into blockchain and you will see how that glance seems unable to disconnect. Then, as unexpected, if you’re filled with zeal to the brim, you become immerse, not as the originator, but as one filled with curiosity; wondering how the blockchain foundation was laid like the plentitude of people riding to a phase where answers are given to their many questions.

SUPER KEYWORD IN SOLIDITY

Ephraim Chukwu — Mon, 02 May 2022 22:02:45 +0000

Solidity, like other programming language, is a statically typed language for creating smart contracts with complex algorithmic programs. This higher language is afterwards compiled into opcodes that virtual machines understand. Despite the speciality of the language, it borrows ideas iimmensely from other existing programming languages. This article hopes to help you understand the super keyword in Solidity.

The Solidity language is designed with the attributes of inheritance and it supports polymorphism. While inheritance is simplying the sharing in the same functions as the inheritor contract, polymorphism is the ability to make internal or external calls to functions of the same name and the same type of parameters. Due to the possibilities of having a long hierarchy of inheritance, the super keyword was therefore introduced to enable easy accessibility.

The super keyword are mentioned often in contracts with a lot of inheritance possessing the some functions with the same parameter types. When this code is called, super.funcName(), it calls the last base contract before the contract that makes the call.

For instance, there are three contracts: A, B, C. If C inherits B and B inherits A, and they all have the same functions. If the super and the method function in the contract C, the last implementation of the function in B is what will be called. If A is the parent root contract, it won't be possible to use because it has no inheritance.

Here are practical examples:

pragma solidity 0.8.7;

contract A {
   function doSomething() external returns(bool) {}
}

contract B is A {
   function doSomething() external override returns(bool) {
     //super.doSomething();
}
}

contract C is B {
   function doSomething() external override returns(bool) {
   super.doSomething();
}
}

The code block above indicates clearly what the super keyword do and how it is relevance in the tree of inheritance in solidity.

Why Smart Contracts Are Not the Backend You Think?

Ephraim Chukwu — Sun, 01 May 2022 22:48:41 +0000

Backend development, to many functioning websites and technologies, are crucial because this aspect handles quite a lot of technicalities under the wood. It ranges from handling the databases of users, security, performance, authorization and authentication. The list of functionalities that a Backend fraction of an app development unfolds more depending on the kind of technology integrated into the application. Nonetheless, there’s a need to lay emphasizes on database, security, and the paired, authorization and authentication.

Shifting the scene to the web3 ecosystem where most interaction with a decentralized application is with a smart contract. Smart contracts are different your understanding of backend development in web2. Every interaction, with a blockchain network, comes with a cost. Herein, I’ll explain how smart contracts are not the usual backend that must receive all of the details of the users of your software applications.

WHY GET ALL THE INFORMATION OF YOUR USERS?

For some beginners, writing smart contract is similar with writing backend codes that receives virtually all the information of the users of the application. Some are quick to hop in on the creation of projects that captures names, births and many other personal information. Sorry to make this known to you, smart contracts are too smart to be made smarter with those information.

Interaction with blockchain technology, despite the privacy it creates, make known to the general public who and who is interacting with a smart contract. You don't want to give way more details to block explorers. Aside from the revelation of the details of your users to the public, the way smart contract operates, the mechanisms expect that a smart contract is gas-optimized inclined. A good understanding of gas optimization will unearth the principles of creating an optimized dapps that doesn't scare users with high gas cost for interacting with your decentralized application.

In order to make this more clear, I will show some practical examples I have witnessed from some beginners.

pragma solidity 0.8.5;

contract Office {
    struct OfficeWorkers {
     string name;
     address owner;
     uint256 phoneNumber;
   }


  function doSomething() external view returns(bool) {}

}

The block of codes above includes a struct that receives a string, address and an unsigned integer. Pretty receptive, right?

This indeed details who calls the function and provides the information but the sad truth is, the smart contract ecosystem involves money which invariably makes the provision irrelevant. With the codes above, it certainly will skyrocket the cost of calling a function to add those information to the state machine storage. Do well to check it out.

From a critical review of the block of codes, there are more than just one flaw of your smart contract becoming a database. The variable packing within the struct is poor. Variable packing? This is how your variables are structured to take a place on storage. We will look into it in another content in the nearest future.

Being a sensitive technology, writing smart contracts expects caution and concentration to understand how state machine aids successful transaction. The knowledge will help you filter appropriately unnecessary data that must go to the blockchain and create efficient decentralized applications.

DEPLOY CONTRACTS WITH OPENZEPPELIN DEFENDER RELAYER

Ephraim Chukwu — Wed, 30 Mar 2022 18:11:48 +0000

Openzeppelin is one of the reputable libraries in the smart contract ecosystem that provides secured, reusable and quality contracts for development. One of the fastest and safest way to get your contracts deployed, whether to the mainnets or testnets, is to use the Openzeppelin Defender Relayer.

In this article, you should learn of the processes of shipping faster and secured-laden contracts with the Openzeppelin Defender Relayer. Also, at the end of the article, you should have more than one reason why you should adopt it for your next contract deployment.

What is a Defender Relayer?

The Openzeppelin Defender Relayer is a generated address that provides you an API key and secret that could stand in place of your wallet addresses. This generated addresses enhance fast deployment and reduces the risk of exploit that occurs during the processes of deployment. Like your wallet addresses, these addresses are capable of sending and receiving ethers and tokens.

Processes for Contract Deployment

Before diving deep into the processes, it is important to mention that the contracts we will deploy at the end of the processes is only a simple ERC20 token, deployed on the polygon network.

Create the working environment using Hardhat and Ethers JS.

mkdir defender-relayer
cd defender-relayer

When you have successfully created a folder for the project, install hardhat.

npx install hardhat

Install the Openzeppelin contracts and the defender-relay-client packages.

npm install @openzeppelin/contracts

npm install defender-relay-client

Do note that you can begin your project with yarn if you are fine with it.

When you have all of these packages installed successfully, open the code on your VS code.

code .

Write a simple ERC20 token named Defender Relayer with the symbol ODR.

Do ensure to import the Openzeppelin ERC20 token and then inherit it. From the image above, it shows also the import of hardhat console that gives us the liberty to see an output in our terminal. Isn't that amazing?

Well, that's the simple token contract and our token name is Defender Relayer with the symbol ODR.

Then write the script for deployment.

Line 1 to 7 deals with importing the required dependencies. Line 9 to 29 helps with the getting of the contract and deployment. Line 33 to 38 handles error if there is one.

Sign up on Openzeppelin Defender Relayer. After successful registration, click on the relayer to generate an API_KEY and an API_SECRET. These are all what replaces your private key which you would have normally added if you are to deploy using your own development account.

Ensure that you take note of the API key and secret. Fund the address with the token or coin you intend to interact with. During the course of creating your relayer, ensure to select the network you want to deploy on. Copy and paste it in your .env file. Something similar to this below:

API_KEY=xxxxxxxxxxxxxxxxx
API_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Get a RPC_URL from either Moralis, Alchemy, or Infura. For me, I used Moralis but anyone works fine.

If you are very much familiar with the usage of any of these node provider, you sure will understand the importance of the tool. If you are not, do kindly go through their site and documentation. The guide for usage is simple and clear.

On getting thee network you intend to deploy on, add it to your .env file and set your hardhat config.

MUMBAI_URL=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

For the network configuration, check out the hardhat documentation.

After completion of the set-up, it is now time to deploy our script with the defender relayer serving as the deployer of the contract.

npx hardhat run scripts/deploy.js --network mumbai

Viola! The deployment is successful. You can therefore check your relayer account, particularly the address you created, it will have a list of transaction that has occurred with the address.

Why Adopt the Usage of Openzeppelin Defender Relayer?

There have been, more than we can count, cases of exploits due to the lapses of developers to properly securing their private keys during development. Aside from these overwhelming lapses, there are more technical processes involved in deploying with your private keys as the principal deployer.

What then are makes Openzeppelin defender relayer special?

Safety

This tool has shielded developers from losing funds and their other properties during the course of development.

Fast

Deploying with Openzeppelin Defender Relayer is fast. If you encounter errors during the course of deployment, its error messages are clear and straight to point.

Do enjoy the easy and quick way of deployment!

How to Convert Epoch Timestamp to Date Using JavaScript

Ephraim Chukwu — Thu, 24 Mar 2022 01:56:09 +0000

Being a relatively new language that ushered in the use of time in seconds, Solidity provides a global feature called block.timestamp. In this short piece, I explain how you can convert epoch timestamp emitted from your backend solidity contracts into appropriate date that includes day, month, year and time.

The Unix Epoch dates back to 1st of January, 1970. This aided computer system globally in tracking time in relation to dated information. It has been widely adopted in many computer languages, dynamic applications and sophisticated ecosystem.

Due to the bignumberish state of the time generated, questions around how this will be used, especially for frontend web3 developers, lure many into a state of brainstorming.

Here is the simple solution:

function getDate(x) {
   const myDate = new Date(x * 1000);
   return myDate;
}

The x passed into the above function is the epoch timestamp that comes in this form:

1601528702

It is multiplied by 1000 so as to convert it from milliseconds to seconds.

The return value from the code snippet above gives us a range of choice to make. This returns a full text string generated from your browser's time zone. We can thereafter convert these beads of texts to a locale string, to string, or if we are interested in the time zone representation, using the in-built JavaScript attributes.

For better clarification, the following are possible manipulation.

 myDate.toLocaleString(); // '3/24/2022, 2:06:03 AM'
 myDate.toGMTString(); // 'Thu, 24 Mar 2022 01:06:03 GMT'
 myDate.toJSON(); // '2022-03-24T01:06:03.440Z'
 myDate.toDaateString(); // 'Thu Mar 24 2022'

You can do well to check out other inherent methods that JavaScript provides aside from the ones above.

Apart from block.timestamp that requires the expertise of developers to manipulate from the knowledge of clients and users of our decentralized application, there are other features such as the conversion of wei to ether, block.number, msg.data etc.

I hope this helps. Keep enjoying your codes.