DEV Community: Seymour1948

Deploy a ERC20 compliant contract. Part 4.

Seymour1948 — Sun, 13 Mar 2022 06:55:40 +0000

So we are in part 4 and let's go straight to our task in the last part we hub or local network node up and running and our contract deployed in it. So let's interact with it through the hardhat console, to do that in our terminal write.

npx hardhat console --network localhost

And we are in. We are inside a node-JS console, that means we can write some commands there. First thing we will do is attach to our currently deployed contract. First we call our contract factory like we did in our test or in our deploy script.

const Glass = await hre.ethers.getContractFactory("Glass");

but now instead of deploy a new contract instance we attach to the one we already deploy. For that you need to rescue from the info published in your node running the address of the contract and with that we write.

const glass = Glass.attach("0x5fbdb2315678afecb367f032d93f642f64180aa3");

Now we are ready to do some interactions but to ease things a little bit let get the accounts we already know to play a little bit with it.

const accounts = await hre.ethers.getSigners();

and with that we can check a few things in the current contract.

await glass.balanceOf(accounts[0]);

with that we get the current balance of the first account (the one with we deployed the contract).
and lets transfer some tokens to the second account like we did in our testing.

await glass.transfer(accounts[1].address, "1000000");

If we check balances again in both accounts we will see that the tokens where rightly transferred. So that's it, this is just another way to check everything is in order.

Now is the time all we were expecting let's deploy our "battle tested" contract to a real network. To do that we will need to get access to this network. In order to do that we could run our own node of the network. That's what we did in our local network, but in this case we will try to get access through one of the providers that give you access to one of their nodes. There are several companies doing that in this case and having in mind we will be connecting to polygon we'll use Alchemy service. https://www.alchemy.com/
In their website we'll need to create and account to get access to the dashboard and in there push the upper right button "create app". In the panel displayed we should fill some details

Like you see, we set to development mode we select polygon as our network but instead using the mainnet we will be using Mumbay test net. That means we won't need right now to use real money to deploy our contract. Really convenient specially if we are still testing things.
Now that we have created our Alchemy app we can click in the last column button in our right called view key and from there we copy the http address we are provided. This is let's call it our access point and next thing we need to do is add this info to our project. But we need to have something in mind this is sensible info we need to store in a way it never leaves our local development enviroment to do that we'll do the following. We are gonna create a js file call secrets.js in our project. This file needs to be excluded for example from our control version system so let's open a special file hardhat create for us at the very beginning .gitignore add add secrets.json to the list of ignored files.

After that we will complete our secrets.json with this info.

{
  "url": "https://polygon-mumbai.g.alchemy.com/v2/[API KEY]",
  "mnemonic": "[seed-phrase]"
}

The url is the one we obtain from Alchemy and the second element call mnemonic refers to the seed we use to generate an address. We don't have a working address yet, hardhat provide us with 20 of them but obviously these address are not suitable for our next steps in order to do that we'll need to create a new one in metamask. If you don't have metamask still installed in your browser go to metamask.io and install it, if you already have metamask I advise you to install in another browser (chrome, firefox or brave are your options) and create a new account you reserve for development. In the process of creation you will be provided with 12 word, add them to the mnemonic.

So at this point we have our sensible data in a separated file that will never be included in our control version and we have a new fresh account created using our metamask wallet.
But still we need to let know hardhat how to access this data, to do that we will make some modifications to the hardhat.config.js file. We will strip the not needed info at this point

require("@nomiclabs/hardhat-waffle");
const { url, mnemonic } = require("./secrets.json");

module.exports = {
  solidity: "0.8.4",
  networks: {
    hardhat: {
      chainId: 1337,
    },
    mumbai: {
      url: url,
      accounts: { mnemonic },
    },
  },
};

What we are doing here is import data from our secrets.json file and we inject this info to our new network.
We are just to one single step of deploy our contract but we will need some Matic the currency of the network we are deploying our contract so we need to get some. We can get some from this faucet:

We will introduce our public address here and that's it, in just a little time we'll see how we receive this test tokens in order to operate in mumbai network. In order to see that in our metamask wallet we need to set this network in the wallet we can do this easily using the service provided by Chainlist. From their website we can connect our metamask wallet search for Mumbai test net and add it. That will allow us to check our current balance.
And now the moment we were waiting for. The following simple line in our terminal will do the trick.

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

After that if everything goes fine. It should we'll receive the address of the contract we just deployed with the huge difference the contract is not just in our local network but in a "real" one.
Let's check the test net explorer of the network. Navigate to the web and introduce the address of our contract. And you should see our just deployed contract right there.
We can explore the details of the transaction if we will. Check how the new minted tokens of our contract were transferred to our account.
We can even add then to the metamask wallet to make them visible.

In the lower part of the interface just click import tokens and introduce again the address of our contract and that's it we have our token balance. From there we could send to another address if we will. And that's it, I hope this series of articles help you to have a better understanding of the task can involve to deploy a contract. It's obviously a simple pet project but I tried to don't omit some relevant task you should do in your next projects, like testing using a local environment, aid in hard tested libraries or contracts, use control version, secure sensible info, and of course how to bring all from your local environment to a live net.
In future articles I will try to keep using this approach. I hope to see you there.

Deploy a ERC20 compliant contract. Part 3.

Seymour1948 — Fri, 11 Mar 2022 20:20:26 +0000

So welcome to part 3. In this part I was intended to finally deploy our contract in the live net as promise I notice there was still a couple of subjects I don't want to omit. Control version and a little bit more of testing. So let's do it. Working with a control version software garanties we have an historic of hour work that way if we need to go back it would be easier to do it. There are a lot more of advantages especially if you work in bigger projects and with other people contributing to the same project. But by now let's take just a very little glimpse of how could be work with it. We will be working wit Git, there are other control versions software but this is pretty much the standard. Just in case you don't have installed in your computer check it out

git --version

if you obtain a confirming message giving you info about the version you have installed you are good to go otherwise follow these steps from the Git Homepage. After that if you introduce the last command again in the terminal it should show you the version you just installed.
In the terminal from our current project folder just type

git init .

this will create a repository in that folder (thats what the dot means)
again if is your first time working with git you probably need to configure first two parameters your user and email with these to lines.

git config --global user.name "[name]"

git config --global user.email "[email address]"

if we type

git status

We could see in red in our terminal which files are not part of the repo, if you remember at the very beginning hardhat ask you if create a .gitignore file in that file we tell to git which files should ignore, thanks to that we don't add to the repo files not needed or even more important files than contain info we want to keep private.
So let's add this files to the repo with

git add .

if we type git status well see now our files in green this means they are prepare to be added permanently to the version history, we'll do that with

git commit -m "[descriptive message]"

our message should be descriptive enough to let know anyone what we did here. Here we could say something like contract creation and firsts tests.
After that if we type

git log

that will show our history with our first commit. Not bad as a first introduction let's add another tests to just get familiar with the workflow we should incorporate. Both testing and control version are a must and in my opinion we'll do your life easier as developer, so the sooner you get use to it the better.
In our test file we will add a couple of test.

const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("Glass", function () {
  let glassContract;
  let firtsAccount, secondAccount;
  beforeEach(async function () {
    [firtsAccount, secondAccount] = await ethers.getSigners();
    const GlassContract = await ethers.getContractFactory("Glass");
    const initialSupply = ethers.utils.parseEther("21000000");
    glassContract = await GlassContract.deploy(initialSupply);
    await glassContract.deployed();
  });
  it("Should return our contract", async function () {
    expect(glassContract).to.exist;
  });
  it("Should has an address", async function () {
    expect(ethers.utils.isAddress(glassContract.address)).to.be.true;
  });

  it("Should return amount balance of creator account ", async function () {
    expect(await glassContract.balanceOf(firtsAccount.address)).to.be.equal(
      ethers.utils.parseEther("21000000")
    );
  });
  it("Should return balance of second account ", async function () {
    await glassContract.transfer(
      secondAccount.address,
      ethers.utils.parseEther("11000000")
    );
    expect(await glassContract.balanceOf(secondAccount.address)).to.be.equal(
      ethers.utils.parseEther("11000000")
    );
  });
});

You should notice that at the very beginning of describe function we declare two new variables and inside beforeEach we assign values to then using that method getSigners(). In the previous part we saw that Hardhat create for us a local network but also provides us with 20 accounts we can use for our testing. You can get this address directly with the following command in your terminal.

npx hardhat accounts

This print the public addresses.
Have in mind this accounts are the same for everyone so be careful and don't use it for any other thing than just your tests.
So in this case with and array deconstruction we obtain just two of them. That will be enough for our new test. In the first one we check if the total balance of our minted tokens belongs to the first account. If you remember in our contract implementation we call the private function _mint which transfer this minted token to the address that deploys the contract. If we don't say any other thin in our test that would be the first account. So our first test will ensure the full amount of minted token are where they should be.
If you want just to see the test fail you can change the amount.
In the second test we are testing the transfer function in the contract. In reality we only should test our own code and this function that we inherit is way well test it but we'll get and idea how could be to test our own function if we add it some (very likely) to our bare-bone smart-contract. So if everything goes right the result is we are transferring part of our tokens to another address and they get reflected in its balance.

Ok, I think we are done with test. Till now we were deploying our contract to our local network. We were doing it in our testing phase but let see how we can do it in another way. This way will put us a step closer to our final deployment.
The first thing we will do is to launch manually our local network from terminal.

npx hardhat node

Now that we had our app up and running let focus in our deploy script to do that we will modify the one is provided in our project. For that we will open a new terminal and copy the script provided

cp scripts/sample-script.js scripts/deploy.js  && code scripts/deploy.js -r

Let's strip some of the comments, I recommend you read it first but we will end with something like this.

const hre = require("hardhat");

async function main() {
  const Glass = await hre.ethers.getContractFactory("Glass");
  const initialSupply = hre.ethers.utils.parseEther("21000000");
  const glass = await Glass.deploy(initialSupply);

  await glass.deployed();

  console.log("Glass deployed to:", glass.address);
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exit(1);
  });

We are almost ready we have our local network running in another terminal we have our deploy script now is time to actually deploy our contract. To do that in our terminal...

npx hardhat run script/deploy.js

we'll get our contract address but something is not right, if we take a look to the terminal where we launch our network nothing happened in there. The reason is because we didn't specify the network to deploy our contract and hardhat did like in our test and launch a local network for us. So let's fix that.

npx hardhat run script/deploy.js --network localhost

This time we'll see our transactions of the contract creation in our terminal where we are running our local node

So that's it for now we are closer I'm serious. Next article will be the one where we go live, but also we try hardhat console so I hope you stay with me till the end, or I should say beginning of our journey.

Deploy a ERC20 compliant contract. Part 2.

Seymour1948 — Tue, 01 Mar 2022 22:49:59 +0000

In the first part of these series we created and compiled our first contract inheriting from ERC20 open zeppelin contract.
In this section will start creating our first test. If you never have try it TDD, always there is a first time, test usually come first. In this case our first test will check if our contract has been deployed. Why work this way? you will be asking in my experience this approach allows you to think what are the key features in your program and test can help you to identify and strength all the edge cases where these features could eventually fail. These tests could grow with time to cover new features or edge cases and if somehow you need to make changes in your programs these tests still ensure all the features still works. The latter in the case of smart-contracts is way more difficult to apply because once deployed in the Mainnet will be not possible to change (things like proxies are beyond our current scope). Anyway, this immutability characteristic of smart-contracts it would be one more reason to really test your contracts all you can before deploy them. Well enough theory lest write our first test.

In the terminal we will create our test file.

touch test/glass-test.js

and we open it in VSC

code test/glass-test.js -r

In hardhat we use javascript (or maybe I should say Node.js to be more precise), I think typescript is also available but we will use the former.

In our empty file we write this first two lines.

const { expect } = require("chai");
const { ethers } = require("hardhat");

If you are not familiar with javascript like me (my previous experience is with languages like Python, C# and C++) what we are doing is this lines are importing chai and hardhat modules using require (If you remember from the first article we installed both with hardhat). Also we are using object destructuring to import the only certain parts of this modules. I let you a link to a really nice article is you want to know more about it: link
chai is our library for testing and ethers is the library we will be using to interact with Ethereum blockchain.
So let's continue with our test.

describe("Glass Contract", function () {
  it("Should return our contract", async function () {
    const GlassContract = await ethers.getContractFactory("Glass");
    const glassContract = await GlassContract.deploy(21000000);
    await glassContract.deployed();

    expect(glassContract).to.exist;
  });
});

Wow to many things to unpack (literally) here. Javascript in my experience is very fond of these nested functions so let's try to peel all the layers. In first place we have describe, this function is use in our test to group our tests, the first parameter is a string where we put the name of the object we are testing and followed by and anonymous function expression (more on type of functions in JS here but I suggest you go slowly in this one). And finally it functions which contain our individual tests. Inside our test we create using ethers library a Factory that we use to create our contract calling the method deploy of the factory. As you can see we have to provide an argument, this is the parameter indicating our initial supply for our token.

Inside of the test we are checking with expect that our glassContract variable return not null or undefined.
Well that's all, isn't it, well... probably you notice I'm skipping that async just before the function expression, and the awaits inside. With these keywords we are enabling asynchronous. What that's mean? Well think for a moment what we are doing here, we are deploying our smart-contract in a network and we don't obtain and immediate result with this keyword we wait till we get this result and then we continue. If you are not familiar with promises and asynchronous, take a look to this link.
So we finally we are done, don't we. Well, let's test it (what would be the point if we don't test our test). How we do that? from the console we type this.

npx hardhat test test/glass-test.js

Show we should get something like this in our terminal window

What happen here let's explain a little bit. Hardhat deploy our contract and then test it that our contract already exists. But where was deployed? Well hardhat comes with local built in network that is raised for our testing and later on shut it down. How convenient, isn't it?
Hardhat also give us the choice to do that in an already deployed local network or in live networks too. But let's go back for a moment to our tests. First thing is we really didn't do extrictly TDD because we really create our contract before the test but you get the idea we could do it in reverse and that would be real TDD. After that disclaimer let's try to improve a little bit our test. Because maybe we can get to the conclusion that just get in something not null or undefined is not a strong enough test to be secure we have deployed a contract, so let add another test adding a new line.

const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("Glass", function () {
  it("Should return our contract", async function () {
    const GlassContract = await ethers.getContractFactory("Glass");
    const glassContract = await GlassContract.deploy(21000000);
    await glassContract.deployed();

    expect(glassContract).to.exist;
    expect(ethers.utils.isAddress(glassContract.address)).to.be.true;
  });
});

What we are testing now is that our glassContract have an address, so with this I think we are a bit closer to be secure we have a contract in our hands.
But let's modify a little bit our code because right now we are doing two test inside or our it function, so let's split it like this.

  it("Should return our contract", async function () {
    const GlassContract = await ethers.getContractFactory("Glass");
    const glassContract = await GlassContract.deploy(21000000);
    await glassContract.deployed();

    expect(glassContract).to.exist;
  });
  it("Should has an address", async function () {
    const GlassContract = await ethers.getContractFactory("Glass");
    const glassContract = await GlassContract.deploy(21000000);
    await glassContract.deployed();
   expect(ethers.utils.isAddress(glassContract.address)).to.be.true;
  });

Notice how verbose are our tests just so close to natural language and that's perfectly find because this test are also be meant to be read in order to understand what our program (smart-contract in this case) does. But there is something is bothering me, let's refactor our code a little bit. Refactoring by definition is the process of restructuring computer code without changing or adding to its external behavior and functionality.
In this case what will do here is extract that part were we repeat our deployment (not a bad thing, we want a contract fresh for each test we take) and put in inside a function that will do exactly that without have the necessity of duplicate our code.

describe("Glass", function () {
  let glassContract;
  beforeEach(async function () {
    const GlassContract = await ethers.getContractFactory("Glass");
    glassContract = await GlassContract.deploy(21000000);
    await glassContract.deployed();
  });
  it("Should return our contract", async function () {
    expect(glassContract).to.exist;
  });
  it("Should has an address", async function () { expect(ethers.utils.isAddress(glassContract.address)).to.be.true;
  });
});

Like you can see first we declare our glassContract variable to make it available in the scope of all functions inside describe and then we use beforeEach function, a special function that executes before each test. So what we did here is we found that when we added a second test we notice we will need to repeat code everytime we create a new test so in order to avoid that we enclosed our repeated code inside a function that way if we need to modify that code we only need to modify the implementation inside that function. That's in a basic level what we try to do with this refactor process make our code more flexible and ready for new funcionalities.
So let's wrap a little bit this second part of the series.We learn to create test for our contract using javascript language. We learn how to launch our test. And finally we dedicate some time to explain the inevitable phase of refactor our code in order to make it ready to new needs.
In the next article we will finally deploy our contract in a live net so we'll see how to prepare hardhat to do that. As always I hope these series result as useful to you as they are to me.

Deploy a ERC20 compliant contract. Part 1.

Seymour1948 — Sun, 27 Feb 2022 20:53:03 +0000

The other day I read about how programming is not about code anymore and more about putting together to work different technologies. It's kind of similar to my experience under the lockdown, one of the things I decided I could occupy my time was to assembly a pc. I discover the hard way than sometimes it's not that easy to put together the different pieces to obtain something that work even if they should be compatible, the reality sometimes is different.
In this post I will try to put together all the pieces for a new assembly being now software instead of hardware. Being frameworks, languages, networks instead of cpu, motherboards, power units.
I will be using visual studio code, hardhat, polygon network, open zeppelin contracts, git, github and maybe to add a very basic front end some React.
Create your project folder. Open the terminal navigate to your projects folder and type:

mkdir polygon-eth20 && cd polygon-eth20

I'm working with VSC so to open a new VSC window with my project as folder I will do the following

code .

Let's open the terminal inside VSC with ctrl + ` and let's install hardhat with our initial dependencies. You can use yarn o npm to do this.

npm install --save-dev @nomiclabs/hardhat\-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers ethers

Next thing we should do is to start our project with

npx hardhat

In the terminal we will be asked to chose what kind of project we want to create. We chose a basic sample project, the same folder as destiny and we create a .gitignore file. This file is capital if you plan to don't upload later on private info to Github. Having this file also means that hardhat create a git repository for us for free.

Let's create a contract provided file.

touch contract\Glass.sol

Open it in VSC using its interface or using this from terminal

code contract\Glass.sol -r

-r makes the file open in the same VSC instance.
Now let's create our contract.

//SPDX-License-Identifier: MIT

pragma solidity ^0.8.4;

contract Glass {
//
}

So now we wont our contract to be ERC-20 complian so to do that we make our contract inherit from open zeppeling contract
to do that we need to intall this contracts, from terminal

npm install @openzeppelin/contracts

after that we can import it in our solidity contract file and make our contract inherit from ERC20 contract.

//SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";


contract Glass is ERC20 {
    constructor(uint256 initialSupply) ERC20 ("Glass", "GLSS"){
        _mint(msg.sender, initialSupply);
    } 
}

If you take a look to the following to ERC20 you can check the functions we are inheriting from it. I encourage you greatly to do so. In your career as developer one of the things you will do the most is reading docs and when they are not available reading code written by others so better get used to it. I don't wanna digress but write your code as if someone have to read it sooner or later even that one is the yourself of the future. Anyway, if you look we have set a constructor inside of our contract. This is a special function that is only executed once in the moment the contract is deployed, there we are setting two parameters like the name and the symbol, they are part of the standard. We can also set another parameter like decimals, if we don't the default value will be 18. Decimals are a whole subject by itself, so for now just now that in solidity we don't have anything like 1.5 and are this decimals what allows to "fraction" the units of our token.
Another important thing that happen in our constructor is we call a private function call _mint, note the underscore before the the name, just a convection but really helpful to establish at a first glance what methods will be accessible from outside and what not.
This function do something really important creates and initial amount of the tokens we are creating and in this case assign it to the contract creator (If you want to dig deeper in this subject about supply, I encourage you to do so take a look to this doc).
Msg is a global variable in solidity, we have a few of them, and msg.sender return the address of the external account (in this case) who call the contract.
All calls to contracts have to be initiated from a external account, even if in the middle we have a contract calling functions of another contract but these things are far away from the scope of this post so let's continue with our process. So our in this first transaction _mint function transfer the given amount, which we specify in the contract constructor parameters to the contract creator. And that's it we have a bare-bone ERC20 compliant contract and from here we could add more functionalities from here but what I pretend if walk for the whole process of a contract deployment in a net so let's continue.
At this point we could compile our contract and find out if we get any errors from the process so let's do it. From the terminal execute this.

npx hardhat compile

We should get a message that the process went just fine. So we were able to convert our sol file to code than the EVM (Ethereum Virtual Machine) can work with.

We end here our first part of this article in next article we will see how to deploy our contract. We'll do it first to our local network and also we will be introduce to testing in hardhat and will try to do it from a TDD (Test driven development) approach.
To be honest I'm the main target of this article, I know things but I'm new to this Web3 thing so I could be incurring in some errors and misconceptions. I hope not I'm the first interested in not mislead anyone including myself. Feel free to point out any error you could find in this or future articles and if somehow you find this useful to you great, I'm glad for it.

Hello Devs

Seymour1948 — Wed, 23 Feb 2022 19:21:58 +0000

In this blog I will write about things that attract my interest and maybe it'll become some kind of bitacora in my actual journey of learning new technologies. You are very welcome to be a witness of it or even partipate and sharing your probably invaluable experience.