DEV Community: Duarte Roso

My first Solidity Smart Contract

Duarte Roso — Sat, 25 Mar 2023 18:22:51 +0000

My first Solidity Smart Contract

After setting up our environment we are now ready to write our first smart contract using Solidity.

In this article we will be writing a basic smart contract, some tests as well as a deployment script to push it into the blockchain. As a bonus, we will configure Hardhat to give us cost estimations from our code. Exciting!

Index

Project Setup
Smart Contract: Person
Testing the contract
Gas reporter
Deploying the Contract
Storage Layout
Smart Contract: Better Person
Better?
Conclusion

Project Setup

If you followed the previous article you know how to create a new project using hardhat. Go ahead and create it; you can delete the contents of contracts, scripts as well as test, we will be creating new files for each category.

Smart Contract: Person

Imagine for a moment we want to represent a "person" as a smart contract. For simplicity sake a person will be limited to their birth date. Create a contract and call it PersonV1.sol (there will be V2 later).

We start off by the smart contract license. A full list of licenses can be found here. We will go with MIT because it is the second easiest to understand after WTFPL

// SPDX-License-Identifier: MIT

Right after, we need to select the solidity version we want our contract to be compiled with. We will go with latest.

pragma solidity ^0.8.17;

A contract is defined by the keyword contract followed by a meaningful name. If you are familiar with object-oriented programming languages, it is similar to defining a class.

contract PersonV1 {
    uint256 public year;
    uint256 public month;
    uint256 public day;

    constructor(
        uint256 _year,
        uint256 _month,
        uint256 _day
    ) {
        year = _year;
        month = _month;
        day = _day;
    }
}

Our person is defined by the year, the month and the day she was born. Obviously, this is a rather over simplified example as nothing other than the address of this contract makes this person unique in the eyes of the law. Moving on...

The birth date of this person is set at the constructor level, meaning that once set it cannot be changed; we will be adding a method exactly for this purpose to show the cost of altering data on the blockchain. We willingly ignore bad input for the sake of keeping it simple.

contract PersonV1 {
    // ...

    function setAge(
        uint256 _year,
        uint256 _month,
        uint256 _day
    ) public {
        year = _year;
        month = _month;
        day = _day;
    }
}

With this we are able to change our smart contract and measure the cost of such operations. Just like a regular program each operation has a cost, whereas on a CPU the cost is payed with time and energy, on the blockchain the cost is payed with money. We will later try to optimize our contract and understand how we can better write smart contracts to minimize the monetary cost.

You can now compile your contract to make sure the syntax is correct.

npx hardhat compile

Testing the contract

Testing a smart contract is the single most important task a smart contract developer will be doing. A flawed contract is a contract that is open for attacks, potentially putting at risk the Ether you have placed into it.

Thankfully our smart contract does not receive any ETH, we don't have to worry about breaches. Regardless, it is a good practice to test every single functionality of your contract; with basic cases as well a edge cases to make sure it can handle all situations.

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

describe("PersonV1", function () {

    const year: BigNumberish = 1987
    const month: BigNumberish = 4
    const day: BigNumberish = 17

    async function deployPerson() {
        const Person = await ethers.getContractFactory("PersonV1")
        const contract = await Person.deploy(year, month, day)
        return contract
    }

    describe("Deployment", function () {
        it("should set the right age", async function () {
            const contract = await deployPerson()
            //
            const y = await contract.year()
            expect(y).equal(year)
            //
            const m = await contract.month()
            expect(m).equal(month)
            //
            const d = await contract.day()
            expect(d).equal(day)
        })

        it("should update the age", async function () {
            const contract = await deployPerson()
            //
            await contract.setAge(year + 1, month + 1, day + 1)
            //
            const y = await contract.year()
            expect(y).equal(year + 1)
            //
            const m = await contract.month()
            expect(m).equal(month + 1)
            //
            const d = await contract.day()
            expect(d).equal(day + 1)
        })
    })
})

In our first test (defined by the first it function), we make sure that the values passed when constructing our smart contract are correctly saved. On our second test we call the age setter method and verify the new values have been saved into the blockchain.

As you can see, any interaction with the contract requires an await keyword. This is because interacting with the blockchain is not an immediate operation and therefore needs to wait for the value before proceeding.

Run the tests to make sure everything gets the green light.

npx hardhat test

Gas reporter

Hardhat has a feature that, after setting it up and connecting all the pieces, allows our tests to report gas usage based on data taken from CoinMarketCap. It remains an estimate and the actual price will vary depending on a number of factors, but it is useful enough to start optimizing our smart contracts.

The gas reporter package does not come with the default project setup. Run the following command to add it:

pnpm add -D hardhat-gas-reporter

Now in our hardhat.config.ts we can import the package to expose new configuration options:

import "hardhat-gas-reporter";

Adding this import will add a new gasReporter property to HardhatUserConfig. This new property has multiple entries, the ones we need right now are used to set the currency and to set the API key to connect to CoinMarketCap.
To get an API key, head to CoinMarketCap, after creating an account and you will find your key in the Overview page. They offer multiple plans, from free to enterprise, that come with more or less limitations. For our needs the free tier is more than enough.

const config: HardhatUserConfig = {
  //...
  gasReporter: {
    currency: "USD",
    enabled: true,
    coinmarketcap: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  }
};

We are all set up! Running our tests will from now on include a summary of our gas usage:

pnpm hardhat test

As it is right now, it would cost us roughly $12 to add a new person to the blockchain... ouch! Another $1.50 to change their birth data.

Deploying the Contract

Create a deploy.ts file under scripts. This will be our deploy script that we will use to actually deploy our smart contract into the local blockchain. It is in this stage that we can pass custom values to the constructor of our smart contract or apply any other logic you may require.

import { ethers } from "hardhat";

async function printMemoryLayout(address: string, count: number) {
  console.log("### Memory Layout")
  for (let idx = 0; idx < count; ++idx) {
    let slot = await ethers.provider.getStorageAt(address, idx)
    console.log(`Slot\t#${idx}\t${slot}`);
  }
}

async function deployPersonV1() {
  const PersonV1 = await ethers.getContractFactory("PersonV1")
  const contract = await PersonV1.deploy(1987, 4, 17)
  await contract.deployed()
  console.log("PersonV1 deployed!")
  printMemoryLayout(contract.address, 3)
}

async function main() {
  await deployPersonV1()
}

main().catch((error) => {
  console.error(error)
  process.exitCode = 1
});

In the deployPersonV1 function we start off by getting the PersonV1 contract factory and using it to deploy a new instance of the smart contract by passing it three inputs as expect by PersonV1's constructor. Notice that, again, all methods that interact with the blockchain require an await.

We also have a printMemoryLayout function that we call after deploying the PersonV1 contract. This method will be useful to check our contract storage layout.

Time to publish our first smart contract!

npx hardhat run scripts/deploy.ts --network localhost

Storage Layout

In the EVM, the maximum size a type can have is 256 bits. It stores values in slots which also happen to have a size of 256 bits. This means that in a slot you can fit data with a combined size of at most 256 bits. For example, in a slot you can fit:

1 int256/uint256
2 int128/uint128
4 int64/uint64
...
32 int8/uint8

Or it can be combined: 1 int128/uint128 and 2 int64/uint64 because 1x128 (bits) + 2x64 (bits) = 256 (bits)

When compiling your smart contract, the compiler will attempt to pack your data into the most optimized way in order to use the least slots possible.

After deploying the contract, the following layout was printed.

### Memory Layout
Slot    #0  0x00000000000000000000000000000000000000000000000000000000000007c3
Slot    #1  0x0000000000000000000000000000000000000000000000000000000000000004
Slot    #2  0x0000000000000000000000000000000000000000000000000000000000000011

These values might not seem relevant until you look at its hexadecimal values. Remember that our contract had only three values:

uint256 public year initialized to 1987 or 0x07C3 which can be seen at the end of Slot #0
uint256 public month initialized to 4 or 0x04 which can be seen at the end of Slot #1
uint256 public day initialized to 17 or 0x11 which can be seen at the end of Slot #2

A 256 bits long number seems a bit of a waste for values that will never be able to make full use of its capacity. Remember that the solidity compiler will try to pack the memory as best as possible but sometimes the developer needs to give it a hand.

Smart Contract: Better Person

In our first contract, all our data was of type uint256 which can have a maximum value of

115792089237316195423570985008687907853269984665640564039457584007913129639935

Personally, I cannot pronounce that number...

More importantly no month has that many days, no year has that many months and the universe will not have that many years (or will it?).

Therefore we can definitely save a lot of space by using appropriate types that fit our usage, namely uint8 (whose maximum value is 255) for the month and day and an uint16 (whose maximum value is 65535) for the year.

Create a new file under contracts and name it PersonV2.sol. This will be a duplicate of PersonV1 but instead of using 3 uint256 we will use smaller sized types.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract PersonV2 {
    uint16 public year;
    uint8 public month;
    uint8 public day;

    constructor(
        uint16 _year,
        uint8 _month,
        uint8 _day
    ) {
        year = _year;
        month = _month;
        day = _day;
    }

    function setAge(
        uint16 _year,
        uint8 _month,
        uint8 _day
    ) public {
        year = _year;
        month = _month;
        day = _day;
    }
}

We can use the same tests as for PersonV1 as nothing was changed. Duplicate test/PersonV1.ts an name it PersonV2.ts. Make sure you replace any reference of PersonV1 with PersonV2!

Finally let's also duplicate the deploy code for our PersonV2 contract.

async function deployPersonV2() {
  const PersonV2 = await ethers.getContractFactory("PersonV2")
  const contract = await PersonV2.deploy(1987, 4, 17)
  await contract.deployed()
  console.log("PersonV2 deployed!")
  printMemoryLayout(contract.address, 3)
}

async function main() {
  //...
  await deployPersonV2()
}

Better?

After you deploy both smart contracts, you will see a different storage layout for each:

PersonV1 deployed!
### Memory Layout
Slot    #0  0x00000000000000000000000000000000000000000000000000000000000007c3
Slot    #1  0x0000000000000000000000000000000000000000000000000000000000000004
Slot    #2  0x0000000000000000000000000000000000000000000000000000000000000011
PersonV2 deployed!
### Memory Layout
Slot    #0  0x00000000000000000000000000000000000000000000000000000000110407c3
Slot    #1  0x0000000000000000000000000000000000000000000000000000000000000000
Slot    #2  0x0000000000000000000000000000000000000000000000000000000000000000

For PersonV2, slot #1 and slot #2 are zero-ed out although both contract contain three member. Why would that be?

Unlike previously, this time the solidity compiler was able to do its magic after a bit of our help. You see, the compiler will attempt to pack storage memory into as few slots as possible. Whereas before each of our data was using 256 bits, now we are only using a fraction of that!

You can still see that our data hasn't changed. Slot #0 of PersonV2 has the value of 0x110407c3, the slots aggregation of PersonV1.
If we decompose this value:

Day now fits in 8 bits, i.e. 2 bytes = 0x11 (17)
Month also fits in 8 bits, i.e. 2 bytes = 0x04 (4)
Year fits in 16 bits, i.e. 4 bytes = 0x07c3 (1987)

We have effectively reduced our storage footprint by a lot! Does that help cost wise?

Each time we alter the blockchain, a cost has to be paid. This time we are deploying a contract that will use less storage space on the blockchain. Comparing the cost of deployment for each version of our contract speaks for itself:

PersonV1 = $12.60
PersonV2 = $9.34 (25% less!)

Same goes for the method that alters the state of the blockchain:

PersonV1 = $1.52
PersonV2 = $1.14 (25% less!)

Conclusion

Creating a smart contract, creating tests to verify all its functionality and creating a deploy script is the foundation of what it means to be a smart contract developer.

On top of that, thanks to some basic profiling tools and common sense, the developer is able make a smart contract more cost effective.

In this article we attempted to cover all of these points to hopefully give you a good starting point on becoming a smart contract developer. The most challending part will be to audit your contracts to avoid any exploits and potentially loosing money.

Remember: only practice makes perfect and stay curious!

Introduction to EVM Smart Contract development

Duarte Roso — Thu, 26 Jan 2023 18:52:12 +0000

Introduction to EVM SmartContract development

In this introduction, we will go through the basics of Hardhat, its most useful commands and a basic Hardhat workflow.

Index

Prerequisite
Hardhat
1. Intro
2. Initial Setup
3. Important Commands
  1. Create local network
  2. Compile smart contracts
  3. Test smart contracts
  4. Deploy smart contracts
Solidity
1. About
2. Version
Vyper
1. Solidity or Vyper
Blockchain communication
First Run
Conclusion

Prerequisite

This articles starts with a few assumptions, assumptions needed to keep the scope of the article to a minimum. If you are not familiar with the following topics or you need to refresh your knowledge, I advice to take the time to read about them before continuing.

We assume that you are familiar with:

Overall concepts and terminology of the blockchain
Comfortable using the terminal and cli tools
Familiarity with development tools like VSCode, TypeScript, Solidity, npm

Hardhat

Intro

Hardhat is a development environment for developing on a blockchain; in our case we will focus on the Ethereum network. It provides a set of tools that makes developing smart contracts easier:

TypeScript support
Connect to a local network or test networks
Run tests for your smart contracts
Estimate costs for deploying & calling your smart contracts
Inspect the memory slot layout of your contracts

just to name a few. It also provides an abstraction to communicate with a wallet, be it MetaMask or a hardware wallet. This way we don't need to worry about the technicalities of our wallet, we can talk directly with our smart contracts.

Initial Setup

Hardhat is available as a NPM package and can easily be installed using your favorite package manager.

Start by initializing a new project in an empty folder:

mkdir intro
cd intro/
pnpm init

This will setup your project by creating a package.json file. To add Hardhat run the following command:

pnpm add -D hardhat

Once the command completes we can use npx to create our first Hardhat project:

npx hardhat

We will be creating a TypeScript project, simply because having the types will help us understand the data we are handling as well as save us some painful headaches. Therefore select Create a TypeScript project and follow the instructions.

Your project structure should look like the following

The folders that matter to us in this introduction are:

contracts - where we will place our smart contracts
scripts - where we will place our deploy scripts (and others)
tests - where we will place our tests for our smart contracts

Important commands

With our project ready to be used, let us take some time to learn a few Hardhat commands.

Create local network

npx hardhat node

Use this command to create a local network. You are not limited by it, any network can be configured (test or mainnet)

Your local node will be setup with 10 accounts each owning 10000ETH. Hardhat will always generate the same accounts conveniently saving us from changing the account addresses in our scripts each time we launch a local node.

NOTE: These private addresses are for testing locally and locally only! Any ETH sent to those addresses on any network (mainnet or test) will be lost!

The process does not return, therefore my advice is to run it on a side terminal. You can even share a process across multiple projects you might be working on.

The node process will print information about any transaction occurring on our local blockchain, useful to check contract addresses, gas spending, etc.

NOTE: The local network will not keep state in between runs, that is, each time this command is run will give you a fresh new blockchain.

Compile smart contracts

npx hardhat compile

Other commands might trigger a compilation if hardhat sees any change in our smart contracts' code. Still, it is a good practice to run the compilation independently.

Upon a successful compilation, hardhat will generate nicely crafted types to use with your TypeScript code, allowing us to make use of the beautiful type system.

Test smart contracts

npx hardhat test

This command will run any test found under the tests/ folder.

Once we configure our project, it will even be able to give us some cost estimation from deploying contracts and from calling our contract's functions.

Deploy smart contracts

npx hardhat run <script> --network <ethereum_network>

We will be using this command to deploy our smart contracts into a specified network (mostly our local network).

Solidity

About

Solidity is the programming language used to create smart contracts on the Ethereum blockchain or any blockchain compatible with the Ethereum Virtual Machine, EVM for short.

Version

Being a programming language, it needs a compiler to convert the code into bytecode that can be understood by the EVM. Luckily, Hardhat already provides us with a compiler so no further setup is required.

You can find the current used version of the Solidity compiler in hardhat.config.ts

If you wish to use a different version, simply update it in there and voila!

Vyper

Vyper is another programming language used to create smart contracts on any EVM compatible blockchain. Unlike Solidity, Vyper is based on the python syntax.

Hardhat does not add support for Vyper on a fresh installation. Therefore we need to explicitly add it to our dev dependencies:

pnpm add -D @nomiclabs/hardhat-vyper

We now need to tell hardhat to compile our Vyper contracts. Head to hardhat.config.ts to add a vyper import

import "@nomiclabs/hardhat-vyper";

This will extend the HardhatUserConfig to include an optional Vyper parameter to our config

const config: HardhatUserConfig = {
  // your versions may differ from mine
  solidity: "0.8.17",
  vyper: { version: "0.3.7" }
};

Solidity or Vyper

Should we use one over the other? Why do we need more than one language to develop our smart contracts?

The answer to these questions will depend on multiple factors. If two programming languages offer the same set of functionality then it becomes a matter of personal choice. In our case there is a clear difference, one which is very important to know and understand how to use.

Vyper is a simpler languages restricting the logic of our smart contract. By being more strict in its features it is often cheaper to run a Vyper contract than a twin Solidity contract due to its predictability:

Recursions are forbidden
No Inheritance
No dynamic data structures

By controlling these aspects of a program, the compiler can produce more optimized code that will need less processing power to execute. Remember: less processing == less gas used (i.e. cheaper).

Because interacting with blockchains has a cost, a developer should be able to use different tools to perform the task in an optimized manner.

If you need complex logic: use Solidity
For simple transaction based contracts: use Vyper

The blockchain world is still at an early age. The blockchains we know today will change, they might fade away and leave space to new, more modern, more advanced blockchains.
Programming languages will appear, based on or adapted from languages we already know and love.

What is important today might become irrelevant tomorrow. Be adaptable and curious!

Blockchain communication

We are still missing an important piece to make this all work. We need a way to interact with the blockchain from our code.

The two most popular libraries at the time of writing are:

Web3.js
ethers.js

Hardhat provides a plugin for both, but decides to use ethers.js by default. Both these libraries will provide similar functionality and you can read the differences in this article.

First run

At this point, nothing is blocking us from experimenting with what the default project provides us so far. Let’s try it!

First of all, head to the project folder. The following steps will be your usual workflow in compiling, testing and deploying.

Step 1

Start the local node if it isn't already running.

npx hardhat node

Step 2

Compile your smart contracts.

npx hardhat compile

Step 3

Test your smart contracts.

npx hardhat test

Step 4

Deploy your smart contracts.

npx hardhat run scripts/deploy.ts --network localhost

Step 5

Check your smart contract was added to the blockchain. Check in the terminal running the local node process for the output.

You should see something similar to the following:

This means a first block was mined (Block #1), it used 326016 GAS and our contract can be found at the (local) address 0x5fbdb2315678afecb367f032d93f642f64180aa3

Conclusion

We have covered the very basics of smart contract development.

We are able to create a Hardhat project, we learned about the essential commands that Hardhat provides and we understand the flow of developing smart contracts using Hardhat.

In the next article, we will write our first smart contract, write our first test and our first deployment script. We will also configure our hardhat project to get estimations of the cost of each of our operation on the blockchain.

Hope to see you there!