Lately, I've been talking about my move into the Web3, Ethereum, and crypto space since making the switch from a traditional web, mobile, and cloud background.

Since making that move, a shocking number of people have reached out to me who are also thinking about doing the same.

It's really great to see so many other people interested in these fields. And if I'm being honest – it feels validating to know that so many others are also on the fence and are so deeply interested in the space as well.

As for me, I was nervous about making the career switch. Moving into a completely new area of specialization, with a technology I was still getting ramped up on, and a community I was not yet involved with, was a big leap. Especially compared to a very comfortable role with a FAANG company that paid really well (and a team that I really loved).

After over a month, I have zero regrets with the change. I'm also the happiest I've been in a long time, and am excited and energized about the things I have the opportunity to work on everyday.

I decided to write this post to give a blueprint for anyone looking to get into blockchain, crypto, Ethereum, and Web3 from a traditional development background. I can point people to this blog post the next time I get asked how to get into the space.

I'll break this article up into a few main parts:

1. Technologies and resources to learn
2. Tradeoffs and considerations
3. People to follow
4. Companies hiring and doing interesting stuff
5. General tips and landing a job

Let's dive in.

Technologies and Resources to Learn About Ethereum and Blockchain

What I'm most interested in is usually a function of where I predict technology will be in the near future and where I see the current momentum being. So that's what I will focus on here (and this is what I am doing personally).

To me, the most exciting parts of this space are decentralization, DeFi, governance / DAOs, and decentralized web infrastructure.

Because of this, I'm focusing on both Ethereum development and Solidity. With the Solidity programming language ,you can program smart contracts for Ethereum as well as for many other EVM compatible blockchains.

As of this writing, Ethereum also has the powerful and important combination of momentum, developer mindshare, and existing production dapps.

Ethereum is also currently moving to a new consensus mechanism, proof of stake. This addresses the environmental concerns I used to have about how cryptocurrency works at a core level.

Once you learn how everything works fundamentally, I encourage you to then check out other blockchains and projects outside of Ethereum and EVM.

This will give you a better understanding of the industry as a whole. It will also help you see if there are other projects that attract you or that you believe are better approaches to achieving the goal that is Web3.

Consider looking into Solana, Polkadot, Near, Avalanche or Cosmos.

To get started learning blockchain development with Ethereum and Solidity, I suggest you do the following:

1. Read the Ethereum docs

Scan through the Ethereum docs. Be sure to check out the section Intro to Ethereum as well as anything else that catches your eye.

Also be sure to check out the dapp showcase to get a good understanding of the successful apps being built and used in the current ecosystem.

2. Read the Solidity documentation

The Solidity docs are a really good place to get started, especially solidity by example. This gives you a few examples of popular smart contracts like voting, an auction, remote purchase, and micropayments.

You can copy and paste these contracts in the Remix IDE to start executing and modifying them to see how they work.

I also did a video walkthrough of the voting contract here.

3. Get comfortable with the Remix IDE

It's really easy to play around with and start building smart contracts without having to set up any type of development environment by using the Remix IDE. It's part of the Remix Project which is funded by the Ethereum Foundation.

This Remix IDE allows you to create, edit, and execute smart contracts directly from your browser. It offers a perfect environment for learning how solidity works. It's also great for building out various types of smart contracts and playing around with them as you are learning both solidity and how to interact with Ethereum

4. Try building out a full stack dapp

In addition to Solidity, the other parts of the the development stack include a local Ethereum environment like Hardhat or Truffle, a wallet like Metamask, as well as a client-side library that allows you to interact with the blockchain, like either Ethers.js or Web3.js.

To understand how all of this all fits together, it's useful to build out a full stack dapp on this stack from scratch. You can set up the front end project as well as the local development environment and deploy, run, and interact with a smart contract on the blockchain.

Here are two introductory courses to get you going with this:

1. Ethereum Programming Tutorial - DeFi, Solidity, Truffle, Web3.js
2. The Complete Guide to Full Stack Ethereum Development (and here it is in article form, too)

5. Consider reading these books

The space itself moves very quickly, so technical books often get out of date just as quickly. The fundamentals of what Web3 is, though, have not changed much at all.

There are a few really great books that helped me not only grasp the current state of everything, but that also helped open my eyes to the future possibilities and opportunities that lie within it.

Token Economy - How the Web3 reinvents the internet

If you only read one of these books, this is the one I'd say is the most important. It is a masterful deep dive into all of the shortcomings of the web as we know it, what Web3 aims to be, how it will affect various parts of our lives as we know it, and what needs to happen for this vision to be realized.

You can view the book here.

The Infinite Machine - How an Army of Crypto-hackers Is Building the Next Internet with Ethereum

This is the amazing story of how Ethereum came to be, walking you through the history of it all. It is a very thorough and entertaining account of the origin story of Ethereum, I highly recommend checking it out.

You can view the book here.

New Village - Power Back to People

This is a really cool story of how blockchain technologies and decentralization will affect the future of the world.

You can view the book here

How to DeFi

As you can probably tell by the title, this book focuses on how you can start using DeFi today. It gives you a good understanding about how you can use it today as well as some applications of it that we will see at some time in the future.

You can view the book here

The Spatial Web

The Spatial Web is a book that explores the future of the web and all of the implications, not only of Web3 and decentralization, but how everything will come together to enable things that we may have not yet considered.

It does a good job weighing the positive and negatives as well as ways that we may be able to address any negative outcomes of what is to come.

You can view the book here

And here are a couple of solidity books:

• Hands-On Smart Contract Development with Solidity and Ethereum
• Mastering Ethereum

6. Listen to these podcasts

Here are some good podcasts:

• Founders of Web 3 – The people that are creating and building the next phase of the internet.
• Bankless – The Ultimate Guide to Crypto Finance
• Into the Ether – Podcast about Ethereum
• Crypto 101
• Epicenter – Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies

7. Watch these YouTube channels

• Ethereum Foundation
• Eat the Blocks – Short videos on blockchain development
• Finematics – Sharing interesting DeFi videos
• Dapp University – Videos in the Ethereum space
• BlockGeeks – General Blockchain Training
• The Daily Gwei
• Austin Griffith

I've also begun doing videos and tutorials on Ethereum and Solidity, so consider checking out my YouTube channel.

Tradeoffs and Considerations of Switching Careers

There are always things to consider when making a career transition, but especially when considering this space.

There are a lot of positives, but there are also unknowns as well as negatives. Let's talk about some of them.

It's nascent tech

While there are many existing dapps and companies already flourishing, this space is very much still coming into existence in many ways.

There are a lot of problems that we still need to solve, and there are no clear answers for many questions you'll have. The problems being solved are often complex, sometimes combining one or more aspects of distributed systems, game theory, cryptography, economics, social and political science, identity, psychology, and more.

Because of this, there are still things that we cannot yet build with the existing solutions that are available.

I personally think this is one of the more exciting things about all of it it, but it's not for everyone.

It's a volatile space

Many of the projects are built around various types of tokens. The value of many of these tokens rises and falls dramatically, and you often see that people gain and lose excitement in the entire space based on these swings.

If you haven't fundamentally bought into the ideas behind decentralization itself, you may find these ups and downs mentally taxing.

It's full of speculation

Because a lot of people only buy into certain tokens in a speculative way, it attracts some people who are in it only for the money.

You see things like scammers trying to get over on people and steal their money, endless talk about price swings from people who are speculating, and outright scam projects that often discredit the industry as a whole.

This is an annoying part of it and I don't really see it going away anytime soon.

This thread

I would also check out this Twitter thread. Although I have not experienced all of these things, he is definitely shining a light on some of the things I have seen.

General Tips and How to Land a Blockchain or Crypto-Related Job

There are many areas within the space that you can focus on and provide a positive impact on a team. I'd look into the different areas like governance, DeFi, NFTs, and decentralized web protocols to see what interests you the most and then focus on that.

There are a lot of opportunities and a lot of ways to stand out and get noticed. If you find an interesting project and would like to get involved, jump right into their community and ecosystem and start learning. Then see where you may be able to help out. Join their Discord or look at their GitHub issues to find ways that you can contribute.

This will give you an opportunity to meet people involved in the project and will open up discussions for potentially landing a role with them. In fact, it is very common for people within the teams to take notice of active community participants, they will then often reach out and try to recruit you without you even applying.

The pay is usually good. Depending on where you are coming from, it could be more or less, but it's probably not going to be at the high levels of what you see at FAANG companies.

There is probably more potential upside. Most companies offer a combination of base pay + equity in the form of their digital token, so if you stick around and can help make the project successful and the value of the token goes up, you can often make more than what you would in many other areas.

People to follow on Twitter

Here are a few people who you may consider following on Twitter:

Vitalik
Ashleigh Schapp
Arthur Hayes
Stani Kulechov
Gloria Kimbwala
Niran Babalola
Ric Burton
Dennison Bertram
Mana Silvora
Austin Griffith
Santiago Palladino
Zaki Manian
Anthony Sassano

I also found this comprehensive list created by someone on Twitter.

A few people on my team at Edge & Node:
Yaniv Tal
Tegan Kline
Eva Beylin
Adam Fuller
Brandon Ramirez

Teams doing interesting stuff (and hiring)

Compound
Uniswap
Chainlink
Skynet Labs
Aave
Matic
Livepeer
Consensys
ENS
OpenZeppelin
Foundation
Zora
Synthetix
Digital Currency Group

You can also find a pretty decent list of job opportunities in cryptocurrency here.

Also, my team at Edge & Node is hiring!

Conclusion

Did I mention this space is volatile? Be ready for some high highs and low lows, but also for some of the most fun you may have in your career.

You'll be working alongside some of the smartest people in tech trying to solve some of the most complex problems that I think will ultimately have a massive positive impact on humanity.

In this article, you'll learn how to build full stack dApps with React, Ethers.js, Solidity, and Hardhat.

You can find the code for this project here. The video course for this tutorial is here.

I recently joined Edge & Node as a Developer Relations Engineer and have been diving deeper into smart contract development with Ethereum. I have settled upon what I think is the best stack for building full stack dApps with Solidity:

• Client Framework – React
• Ethereum development environment – Hardhat
• Ethereum Web Client Library – Ethers.js
• API layer – The Graph Protocol

But I ran into a problem while figuring all this out. While there's fairly good documentation out there for each of these tools individually, there's not a lot that helps you put them all together and understand how they work with each other.

There are some really good boilerplates out there like scaffold-eth (which also includes Ethers, Hardhat, and The Graph), but they may be too much to pick up for people just getting started.

I wanted an end-to-end guide to show me how to build full stack Ethereum apps using the most up-to-date resources, libraries, and tooling.

Here's what I was interested in:

1. How to create, deploy, and test Ethereum smart contracts to local, test, and mainnet
2. How to switch between local, test, and production environments / networks
3. How to connect to and interact with the contracts using various environments from a front end like React, Vue, Svelte, or Angular

After spending some time figuring all of this out, I finally got going with the stack that I felt really happy with. Then I thought it would be nice to write up how to build and test a full stack Ethereum app using this stack.

I hope this guide will be useful not only for other people out there who may be interested in this stack, but also for myself for future reference. This is that reference.

The Tech We'll Be Using

Let's go over the main pieces we will be using and how they fit into the stack.

1. Ethereum development environment

When building smart contracts, you will need a way to deploy your contracts, run tests, and debug Solidity code without dealing with live environments.

You will also need a way to compile your Solidity code into code that can be run in a client-side application – in our case, a React app. We'll learn more about how this works a little later.

Hardhat is an Ethereum development environment and framework designed for full stack development, and it's the framework that I will be using for this tutorial.

Other similar tools in the ecosystem are Ganache and Truffle.

2. Ethereum Web Client Library

In our React app, we will need a way to interact with the smart contracts that have been deployed. We will need a way to read for data as well as send new transactions.

ethers.js aims to be a complete and compact library for interacting with the Ethereum Blockchain and its ecosystem from client-side JavaScript applications like React, Vue, Angular, or Svelte. It is the library we'll be using.

Another popular option in the ecosystem is web3.js

3. Metamask

Metamask helps you handle account management and connecting the current user to the blockchain. MetaMask enables users to manage their accounts and keys in a few different ways while isolating them from the site context.

Once a user has connected their MetaMask wallet, you as a developer can interact with the globally available Ethereum API (window.ethereum) that identifies the users of web3-compatible browsers (like MetaMask users). Whenever you request a transaction signature, MetaMask will prompt the user in a comprehensible way.

4. React

React is a front end JavaScript library for building web applications, user interfaces, and UI components. It's maintained by Facebook and many individual developers and companies.

React and its large ecosystem of metaframeworks like Next.js, Gatsby, Redwood, Blitz.js, and others enable all types of deployment targets including traditional SPAs, static site generators, server-side rendering, and a combination of all three.

React continues to seemingly dominate the front-end space, and I think will continue to do so for the near future and possibly beyond.

5. The Graph

For most apps built on blockchains like Ethereum, it's hard and time-intensive to read data directly from the chain. So in the past, you'd see people and companies building their own centralized indexing server and serving API requests from these servers. This requires a lot of engineering and hardware resources and breaks the security properties required for decentralization.

The Graph is an indexing protocol for querying blockchain data that lets you create fully decentralized applications. It solves this problem by exposing a rich GraphQL query layer that apps can consume.

In this guide we won't be building a subgraph for our app, but will do so in a future tutorial.

What we will be building

In this tutorial, we'll be building, deploying, and connecting to a couple of basic smart contracts:

1. A contract for creating and updating a message on the Ethereum blockchain
2. A contract for minting tokens, which allows the owner of the contract to send tokens to others and to read the token balances, and lets owners of the new tokens also send them to others.

We will also build out a React front end that will allow a user to:

1. Read the greeting from the contract deployed to the blockchain
2. Update the greeting
3. Send the newly minted tokens from their address to another address
4. Once someone has received tokens, allow them to also send their tokens to someone else
5. Read the token balance from the contract deployed to the blockchain

Prerequisites

1. Node.js installed on your local machine
2. MetaMask Chrome extension installed in your browser

You do not need to own any Ethereum for this guide as we will be using fake / test Ether on a test network for the entire tutorial.

How to get started with create-react-app

To get started, we'll create a new React application:

npx create-react-app react-dapp

Next, change into the new directory and install ethers.js and hardhat using either NPM or Yarn:

npm install ethers hardhat @nomiclabs/hardhat-waffle ethereum-waffle chai @nomiclabs/hardhat-ethers

How to Install and Configure an Ethereum Development Environment

Next, initialize a new Ethereum Development Environment with Hardhat:

npx hardhat

? What do you want to do? Create a sample project
? Hardhat project root: <Choose default path>

Now you should see the following artifacts created for you in your root directory:

• hardhat.config.js – The entirety of your Hardhat setup (that is, your config, plugins, and custom tasks) is contained in this file.
• scripts – A folder containing a script named sample-script.js that will deploy your smart contract when executed
• test – A folder containing an example testing script
• contracts – A folder holding an example Ethereum smart contract

Because of a MetaMask configuration issue, we need to update the chain ID on our HardHat configuration to be 1337. We also need to update the location of the artifacts for our compiled contracts so they're in the src directory of our React app.

To make these updates, open hardhat.config.js and update the module.exports to look like this:

module.exports = {
  solidity: "0.8.3",
  paths: {
    artifacts: './src/artifacts',
  },
  networks: {
    hardhat: {
      chainId: 1337
    }
  }
};

Our smart contract

Next, let's have a look at the example contract we have at contracts/Greeter.sol:

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

import "hardhat/console.sol";


contract Greeter {
  string 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;
  }
}

This is a very basic smart contract. When deployed, it sets a Greeting variable and exposes a function (greet) that can be called to return the greeting.

It also exposes a function that allows a user to update the greeting (setGreeting). When deployed to the Ethereum blockchain, these methods will be available for a user to interact with.

Let's make one small modification to the smart contract. Since we set the solidity version of our compiler to 0.8.3 in hardhat.config.js, let's also be sure to update our contract to use the same version of solidity:

// contracts/Greeter.sol
pragma solidity ^0.8.3;

How to Read and Write to the Ethereum Blockchain

There are two ways to interact with a smart contract – reading or writing / transactions. In our contract, greet can be considered reading, and setGreeting can be considered writing / transactional.

When writing or initializing a transaction, you have to pay for the transaction to be written to the blockchain. To make this work, you need to pay gas which is the fee or price required to successfully conduct a transaction and execute a contract on the Ethereum blockchain.

As long as you are only reading from the blockchain and not changing or updating anything, you don't need to carry out a transaction and there will be no gas or cost to do so. The function you call is then carried out only by the node you are connected to, so you don't need to pay any gas and the read is free.

From our React app, we will interact with the smart contract using a combination of the ethers.js library, the contract address, and the ABI that will be created from the contract by Hardhat.

What is an ABI? ABI stands for application binary interface. You can think of it as the interface between your client-side application and the Ethereum blockchain where the smart contract you are going to be interacting with is deployed.

ABIs are typically compiled from Solidity smart contracts by a development framework like Hardhat. You can also often find the ABIs for a smart contract on Etherscan

How to Compile the ABI

Now that we have gone over the basic smart contract and know what ABIs are, let's compile an ABI for our project.

To do so, go to the command line and run the following command:

npx hardhat compile

Now, you should see a new folder named artifacts in the src directory. The artifacts/contracts/Greeter.json file contains the ABI as one of the properties. When we need to use the ABI, we can import it from our JavaScript file:

import Greeter from './artifacts/contracts/Greeter.sol/Greeter.json'

We can then reference the ABI like this:

console.log("Greeter ABI: ", Greeter.abi)

Note that Ethers.js also enables human readable ABIs, but will will not be going into this during this tutorial.

How to Deploy and Use a Local Network / Blockchain

Next, let's deploy our smart contract to a local blockchain so that we can test it out.

To deploy to the local network, you first need to start the local test node. To do so, open the CLI and run the following command:

npx hardhat node

When we run this command, you should see a list of addresses and private keys.

These are 20 test accounts and addresses created for us that we can use to deploy and test our smart contracts. Each account is also loaded up with 10,000 fake Ether. In a moment, we'll learn how to import the test account into MetaMask so that we can use it.

Next, we need to deploy the contract to the test network. First update the name of scripts/sample-script.js to scripts/deploy.js.

Now we can run the deploy script and give a flag to the CLI that we would like to deploy to our local network:

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

Once this script is executed, the smart contract should be deployed to the local test network and we should be then able to start interacting with it.

When the contract was deployed, it used the first account that was created when we started the local network.

If you look at the output from the CLI, you should be able to see something like this:

Greeter deployed to: 0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0

This address is what we will use in our client application to talk to the smart contract. Keep this address available as we will need to use it when connecting to it from the client application.

To send transactions to the smart contract, we will need to connect our MetaMask wallet using one of the accounts created when we ran npx hardhat node. In the list of contracts that the CLI logs out, you should see both an Account number as well as a Private Key:

➜  react-defi-stack git:(main) npx hardhat node
Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/

Accounts
========
Account #0: 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 (10000 ETH)
Private Key: 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

...

We can import this account into MetaMask in order to start using some of the fake Eth available there. To do so, first open MetaMask and update the network to be Localhost 8545:

Next, in MetaMask click on Import Account from the accounts menu:

Copy then paste one of the Private Keys logged out by the CLI and click Import. Once the account is imported, you should see the Eth in the account:

Now that we have a deployed our smart contract and set up our account, we can start interacting with it from the React app.

How to Connect the React Client

In this tutorial we are not going to be worrying about building a beautiful UI with CSS and all of that – we are focused 100% on the core functionality to get you up and running. From there, you can take it and make it look good if you'd like.

With that being said, let's review the two objectives that we want from our React application:

1. Fetch the current value of greeting from the smart contract
2. Allow a user to update the value of the greeting

So how do we accomplish this? Here are the things we need to do to make this happen:

1. Create an input field and some local state to manage the value of the input (to update the greeting)
2. Allow the application to connect to the user's MetaMask account to sign transactions
3. Create functions for reading and writing to the smart contract

To do this, open src/App.js and update it with the following code, setting the value of greeterAddress to the address of your smart contract:

import './App.css';
import { useState } from 'react';
import { ethers } from 'ethers'
import Greeter from './artifacts/contracts/Greeter.sol/Greeter.json'

// Update with the contract address logged out to the CLI when it was deployed 
const greeterAddress = "your-contract-address"

function App() {
  // store greeting in local state
  const [greeting, setGreetingValue] = useState()

  // request access to the user's MetaMask account
  async function requestAccount() {
    await window.ethereum.request({ method: 'eth_requestAccounts' });
  }

  // call the smart contract, read the current greeting value
  async function fetchGreeting() {
    if (typeof window.ethereum !== 'undefined') {
      const provider = new ethers.providers.Web3Provider(window.ethereum)
      const contract = new ethers.Contract(greeterAddress, Greeter.abi, provider)
      try {
        const data = await contract.greet()
        console.log('data: ', data)
      } catch (err) {
        console.log("Error: ", err)
      }
    }    
  }

  // call the smart contract, send an update
  async function setGreeting() {
    if (!greeting) return
    if (typeof window.ethereum !== 'undefined') {
      await requestAccount()
      const provider = new ethers.providers.Web3Provider(window.ethereum);
      const signer = provider.getSigner()
      const contract = new ethers.Contract(greeterAddress, Greeter.abi, signer)
      const transaction = await contract.setGreeting(greeting)
      await transaction.wait()
      fetchGreeting()
    }
  }

  return (
    <div className="App">
      <header className="App-header">
        <button onClick={fetchGreeting}>Fetch Greeting</button>
        <button onClick={setGreeting}>Set Greeting</button>
        <input onChange={e => setGreetingValue(e.target.value)} placeholder="Set greeting" />
      </header>
    </div>
  );
}

export default App;

To test it out, start the React server:

npm start

When the app loads, you should be able to fetch the current greeting and log it out to the console. You should also be able to make updates to the greeting by signing the contract with your MetaMask wallet and spending the fake Ether.

How to Deploy and Use a Live Test Network

There are several Ethereum test networks like Ropsten, Rinkeby, or Kovan that we can also deploy to in order to have a publicly accessible version of our contract available without having to deploy it to mainnet.

In this tutorial we'll be deploying to the Ropsten test network.

To start off, first update your MetaMask wallet to connect to the Ropsten network.

Next, send yourself some test Ether to use during the rest of this tutorial by visiting this test faucet.

We can get access to Ropsten (or any of the other test networks) by signing up with a service like Infura or Alchemy (I'm using Infura for this tutorial).

Once you've created the app in Infura or Alchemy, you will be given an endpoint that looks something like this:

https://ropsten.infura.io/v3/your-project-id

Be sure to set the ALLOWLIST ETHEREUM ADDRESSES in the Infura or Alchemy app configuration to include the wallet address of the account you will be deploying from.

To deploy to the test network we need to update our Hardhat config with some additional network information. One of the things we need to set is the private key of the wallet we will be deploying from.

To get the private key, you can export it from MetaMask.

I'd suggest not hardcoding this value in your app but instead setting it as something like an environment variable.

Next, add a networks property with the following configuration:

module.exports = {
  defaultNetwork: "hardhat",
  paths: {
    artifacts: './src/artifacts',
  },
  networks: {
    hardhat: {},
    ropsten: {
      url: "https://ropsten.infura.io/v3/your-project-id",
      accounts: [`0x${your-private-key}`]
    }
  },
  solidity: "0.7.3",
};

To deploy, run the following script:

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

Once your contract is deployed you should be able to start interacting with it. You should be now able to view the live contract on Etherscan Ropsten Testnet Explorer

How to Mint Tokens

One of the most common use cases of smart contracts is creating tokens. Let's look at how we can do that. Since we know a little more about how all of this works, we'll be going a little faster.

In the main contracts directory, create a new file named Token.sol.

Next, update Token.sol with the following smart contract:

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

import "hardhat/console.sol";

contract Token {
  string public name = "Nader Dabit Token";
  string public symbol = "NDT";
  uint public totalSupply = 1000000;
  mapping(address => uint) balances;

  constructor() {
    balances[msg.sender] = totalSupply;
  }

  function transfer(address to, uint amount) external {
    require(balances[msg.sender] >= amount, "Not enough tokens");
    balances[msg.sender] -= amount;
    balances[to] += amount;
  }

  function balanceOf(address account) external view returns (uint) {
    return balances[account];
  }
}

Note that this token contract is for demo purposes only and is not ERC20-compliant. We will be covering ERC20 tokens later.

This contract will create a new token called "Nader Dabit Token" and set the supply to 1000000.

Next, compile this contract:

npx hardhat compile

Now, update the deploy script at scripts/deploy.js to include this new Token contract:

const hre = require("hardhat");

async function main() {
  const [deployer] = await hre.ethers.getSigners();

  console.log(
    "Deploying contracts with the account:",
    deployer.address
  );

  const Greeter = await hre.ethers.getContractFactory("Greeter");
  const greeter = await Greeter.deploy("Hello, World!");

  const Token = await hre.ethers.getContractFactory("Token");
  const token = await Token.deploy();

  await greeter.deployed();
  await token.deployed();

  console.log("Greeter deployed to:", greeter.address);
  console.log("Token deployed to:", token.address);
}

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

Now, we can deploy this new contract to the local or Ropsten network:

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

Once the contract is deployed, you can start sending these tokens to other addresses.

To do so, let's update the client code we will need in order to make this work:

import './App.css';
import { useState } from 'react';
import { ethers } from 'ethers'
import Greeter from './artifacts/contracts/Greeter.sol/Greeter.json'
import Token from './artifacts/contracts/Token.sol/Token.json'

const greeterAddress = "your-contract-address"
const tokenAddress = "your-contract-address"

function App() {
  const [greeting, setGreetingValue] = useState()
  const [userAccount, setUserAccount] = useState()
  const [amount, setAmount] = useState()

  async function requestAccount() {
    await window.ethereum.request({ method: 'eth_requestAccounts' });
  }

  async function fetchGreeting() {
    if (typeof window.ethereum !== 'undefined') {
      const provider = new ethers.providers.Web3Provider(window.ethereum)
      console.log({ provider })
      const contract = new ethers.Contract(greeterAddress, Greeter.abi, provider)
      try {
        const data = await contract.greet()
        console.log('data: ', data)
      } catch (err) {
        console.log("Error: ", err)
      }
    }    
  }

  async function getBalance() {
    if (typeof window.ethereum !== 'undefined') {
      const [account] = await window.ethereum.request({ method: 'eth_requestAccounts' })
      const provider = new ethers.providers.Web3Provider(window.ethereum);
      const contract = new ethers.Contract(tokenAddress, Token.abi, provider)
      const balance = await contract.balanceOf(account);
      console.log("Balance: ", balance.toString());
    }
  }

  async function setGreeting() {
    if (!greeting) return
    if (typeof window.ethereum !== 'undefined') {
      await requestAccount()
      const provider = new ethers.providers.Web3Provider(window.ethereum);
      console.log({ provider })
      const signer = provider.getSigner()
      const contract = new ethers.Contract(greeterAddress, Greeter.abi, signer)
      const transaction = await contract.setGreeting(greeting)
      await transaction.wait()
      fetchGreeting()
    }
  }

  async function sendCoins() {
    if (typeof window.ethereum !== 'undefined') {
      await requestAccount()
      const provider = new ethers.providers.Web3Provider(window.ethereum);
      const signer = provider.getSigner();
      const contract = new ethers.Contract(tokenAddress, Token.abi, signer);
      const transation = await contract.transfer(userAccount, amount);
      await transation.wait();
      console.log(`${amount} Coins successfully sent to ${userAccount}`);
    }
  }

  return (
    <div className="App">
      <header className="App-header">
        <button onClick={fetchGreeting}>Fetch Greeting</button>
        <button onClick={setGreeting}>Set Greeting</button>
        <input onChange={e => setGreetingValue(e.target.value)} placeholder="Set greeting" />

        <br />
        <button onClick={getBalance}>Get Balance</button>
        <button onClick={sendCoins}>Send Coins</button>
        <input onChange={e => setUserAccount(e.target.value)} placeholder="Account ID" />
        <input onChange={e => setAmount(e.target.value)} placeholder="Amount" />
      </header>
    </div>
  );
}

export default App;

Next, run the app:

npm start

We should be able to click on Get Balance and see that we have 1,000,000 coins in our account logged out to the console.

You should also be able to view them in MetaMask by clicking on Add Token:

Next click on Custom Token and enter the token contract address and then Add Token. Now the tokens should be available in your wallet:

Next, let's try to send those coins to another address.

To do so, copy the address of another account and send them to that address using the updated React UI. When you check the token amount, it should be equal to the original amount minus the amount you sent to the address.

How to Build An ERC20 Token

The ERC20 Token Standard defines a set of rules that apply to all ERC20 tokens which allow them to easily interact with each other. ERC20 makes it really easy for someone to mint their own tokens that will have interoperability with others on the Ethereum blockchain.

Let's look at how we can build our own token using the ERC20 standard.

First, install the OpenZepplin smart contract library where we will be importing the base ERC20 Token:

npm install @openzeppelin/contracts

Next, we'll create our token by extending (or inheriting from) the ERC20 contract:

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

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

contract NDToken is ERC20 {
    constructor(string memory name, string memory symbol) ERC20(name, symbol) {
        _mint(msg.sender, 100000 * (10 ** 18));
    }
}

The constructor allows you to set the token name and symbol, and the _mint function allows you to mint the tokens and set the amount.

By default, ERC20 sets the number of decimals to 18, so in our _mint function we multiply 100,000 by 10 to the 18 power to mint a total of 100,000 tokens, each with 18 decimal places (similarly to how 1 Eth is made up of 10 to the 18 wei.

To deploy, we need to pass in the constructor values (name and symbol), so we might do something like this in our deploy script:

const NDToken = await hre.ethers.getContractFactory("NDToken");
const ndToken = await NDToken.deploy("Nader Dabit Token", "NDT");

By extending the original ERC20 token, your token will inherit all of the following functions and functionality:

function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

Once deployed, you can use any of these functions to interact with the new smart contract. For another example of an ERC20 token, check out Solidity by example here: https://solidity-by-example.org/app/erc20/.

Conclusion

Ok, we covered a lot in this article. But for me this is kind of the bread and butter / core of getting started with this stack.

It's kind of what I wanted to have, not only as someone who was learning all of this stuff, but also in the future if I ever need to reference anything I may need. I hope you learned a lot.

If you want to support multiple wallets in addition to MetaMask, check out Web3Modal which makes it easy to implement support for multiple providers in your app with a fairly simple and customizable configuration.

In my future tutorials and guides, I'll be diving into more complex smart contract development and also how to deploy them as subgraphs to expose a GraphQL API on top of them and implement things like pagination and full text search.

I'll also be going into how to use technologies like IPFS and Web3 databases to store data in a decentralized way.

If you have any questions or suggestions for future tutorials, let me know.

TL;DR Check this back end and front end solutions for delegated transactions. It is universal for any token which supports the delegation of its functions. Read more below.

This mostly technical article provides a universal framework and a working solution for Ethereum tokens and applications that eliminates the need to pay fees in Ether, a problem that is practically killing the user experience of many blockchain applications.

Imagine spending dollars and then being asked to also hand over some Hryvnias as a transaction fee. That's how Ethereum tokens work so far.

In other words, for example, to transfer any Ethereum token (like Tether, DAI, BAT, DREAM, etc.), the user has to also spend some Ether (internal Ethereum platform currency). This introduces a big inconvenience that prevents the mass adoption of DApps: users have to purchase multiple currencies instead of just one to interact with the blockchain network.

The Problem

Tokens, as we imagine them today are just fuel for applications and services on top of blockchain networks. Organizations create their own tokens (using ICOs, IEOs, etc) and run services/applications that utilize them, introducing their own micro-economy (widely known as a token economy). But almost every token turns out to be quite a complex currency itself. By design of how blockchain networks work, in order to do something with your tokens, you also need another currency — often Ether (for Ethereum) to be able to transfer tokens.

To illustrate the problem, let's look into how users come to use different blockchain-powered services and applications like:

• Trickle - where you create secure, hourly-based contracts with an untrusted party in any token
• Loom - where you use Loom tokens to create sidechains in Loom Network
• Cryptokitties.co - where you breed, trade and transfer kitties (ERC721 tokens)
• Others (there are a lot!)

All these applications use tokens, as well as they require you to purchase Ether. The complexity of using crypto tokens as we know them today is one of the biggest reasons why 99% of crypto startups fail (or avoid adopting real crypto, for example, by replacing it with virtual coins).

As you may already know, the harder it is to use the application, the fewer users it will get right from the beginning. This is something known as The User Onboarding Funnel, which is still a big pain for blockchain-powered applications and services:

The typical user onboarding funnel of a decentralized, blockchain-based application

To understand why I put 0.001% of users prior to the service use, let's see what exactly purchasing some Ether means:

• Creating a crypto wallet
• Registering on Exchange (and learning all the exchange rules, including country policies!)
• Passing KYC (though it's getting easier, still, many countries have limited access to exchanges)
• Purchasing a minimum allowed amount of Ether (usually, it's whopping $50 while you need just nearly $0.05 to perform one or two transactions)
• Withdrawing Ether to your wallet
• Not to mention reading lengthy guides on how to perform all these steps properly

Instead of just:

• Creating a crypto wallet

Of course, it highly depends on how the application or service is made. But, so far, there was no better simplification of the onboarding flow as just cutting crypto tokens from there, or making them fake, "virtual" currency with deposit and withdrawal function. Unfortunately, the latter approach is now the common one across all startups and companies adopting crypto, for many good reasons. Another reason could be a monetization strategy, but this is another big story worth a dedicated article (Interested? Comment out!).

Getting back to the transaction fees problem, we can state the following, which is hard to argue with.

It is natural for the user to purchase only the cryptocurrency they really need (for instance, tokens: Tether, DAI, BAT, DREAM, etc.), and they would normally expect to pay any transaction fees in this cryptocurrency.

So why not just allow them to do so? Because it's quite complex indeed. Let's see why, and how this has just got easier with our open-sourced solution (at least for Ethereum).

Existing Approaches

From the very beginning of blockchain existence, there were a couple of solutions that could simplify the user onboarding flow to the flow depicted below, avoiding the step of purchasing an intermediate currency like Ether. Still, creating a blockchain wallet is not an easy step, but some users who do understand the value of the application/service go through this step quite well.

The user onboarding funnel with delegated transactions

The solution which allows to avoid using intermediate currencies (Ether for Ethereum) is called "delegated transactions", or "meta transactions".

In short, delegated transaction, or "meta transaction" in blockchain is the type of transaction which performs an intended action on one account's behalf, while it is conducted (published) by another account (delegate), who actually pays fees for the transaction.

There are multiple approaches around the internet of the generalized concept of delegated transactions I am presenting in this article. But it seems that none of them are still widely adopted, as these approaches are quite complex by its nature, very specific as for the implementation, as well as some of them are quite complex to standardize. To be more constructive, existing approaches can be divided into 3-4 groups: those which use proxy smart contracts, those which embed delegation into a smart contract itself and, theoretically, there is an opportunity for the blockchain-native implementation (say, Ethereum 2.0).

1. Delegated transactions approaches which use proxy-contracts

Proxy contracts, or, in this context, identity contracts are tiny contracts deployed to replace the user account which wants to avoid paying fees. This smart contract is programmed to act as a wallet, as well as a "caller" (sender) of other smart contract's functions. The key is that it is a delegate account that triggers all the actions, while the true "owner" of this smart contract is another user. The user just generates correct signatures in order to control their funds stored on a smart contract address (= in their wallet).

A visualization of how identity contracts look like

Pros of this approach:

• It works with any tokens and contracts which are already deployed to the network

Cons of this approach:

• Users don't see tokens in their wallet, because they are physically on an identity smart contract
• As a result, a need to develop custom UIs and custom tools/wallets
• Identity smart contract deployment and assignment initial fees, as opposed to no fees at all
• Requires a comprehensive standard to be widely adopted

2. Semi-delegated transactions via "Operator" pattern (ERC777)

There is a token standard that describes this approach — ERC777. In short, any token holder can authorize any other account to freely manage their tokens. I won't call it delegated transactions but nevertheless, I need to mention that, as here we somewhat delegate control over your tokens to other accounts.

A visualization of ERC777 standard's "operator" pattern

Pros of this approach:

• Standardized

Cons of this approach:

• Highly centralized around the "operator" accounts
• Weak security due to operators have 100% control over your tokens
• Initial fees for approval transaction
• Requires additional UIs/tools development

3. Delegated transactions embedded directly into a (token) smart contract

Just the same as it is possible to implement custom fees in a proxy smart contract, paying fees in tokens can be implemented directly in a token smart contract. For example, using the approach I described in my previous article, it is possible to implement a function in a smart contract, which will transfer tokens accepting the user's signature, instead of requiring the user to call this function directly. We have implemented this approach in our DREAM Token, which is used on our dreamteam.gg platform.

A visualization of how embedding delegation into the token contract looks like

As you may notice, in contrast to the previous approach there is no identity contract anymore, and there is an optional way to call other smart contracts directly from the token contract.

Pros of this approach:

• Users see their tokens as usual on their wallet's balance
• No initial fees for account initialization
• May not even require a standard (continue reading)

Cons of this approach:

• If you have a (token) smart contract that is already deployed to the network, you cannot apply this approach to it directly. While you can always deploy a new token and, for example, a "migration" utility, which will allow other users to swap tokens (burn the old token and mint a new one)
• Because a standard for this approach is yet not well-defined, implementation can drastically vary
• A need to develop custom UI/tools for delegated transactions (continue reading — solved!)

4. Delegated transactions on the (blockchain) platform level

This is far the best one of all the described approaches above but also the one which is not implemented anywhere yet (by anywhere I mean the most popular blockchain platforms). There is a hope that its support comes with Ethereum 2.0 release, or at least I've heard from Vitalik that they are in progress with something cool there.

Theoretically, we can imagine this approach as being able to make an "offline" signature of two transactions at a time: one which does something useful for the signing account which wants to avoid paying fees (for example, transferring tokens) and another one which does something useful for the delegate (for example, paying fee in tokens to the account which executes these two transactions).

A visualization of how platform-native delegated transactions could look like

But the problem is, regarding Ethereum 2.0, this feature has a chance to land only in 2022 or even later. I also suppose that this feature will still require a dedicated back end (similar to the one which is introduced within this article), as it is hard to imagine how miners will accept fees in tokens. Simply put, if some of them refuse to accept fees in tokens than it makes little sense to do it on a "mining" level at all, not to mention how much would it take to track all token prices and volumes across exchanges, in a decentralized manner.

Pros of this approach:

• No need to change smart contracts that were already deployed
• No initial fees for account initialization
• May not even require a custom UI/tools if standardized

Cons of this approach:

• Most likely, will still require a centralized back end (the "delegate")
• Not yet implemented on a platform level (as of 2019)

The Solution

From the four approaches above, except for the platform-level approach which is yet to be implemented and standardized in 2022+, the most appealing one is the third approach, where we embed delegated functions directly to the token smart contract. Thus, we save the standard token paradigm allowing wallets to normally work with the smart contract and have no need to wait until delegated transactions will land natively in one of the top blockchain platforms. We will stick to this approach and make it universal just below.

Delegated transactions support programmed right in the token smart contract is awesome. But how to deal with its cons? In fact, the only problem which is tough to deal with (as you cannot modify existing smart contracts), you will need to deploy a new token smart contract if you have already deployed it without delegated functions (for instance, standard ERC20 or ERC721 tokens). The next step, in this case, would be adding a way to migrate tokens from one smart contract to another. For example, you can decide to implement one more function in the new smart contract that will allow token holders to migrate their assets from the old smart contract.

Token migration function implementation can vary, starting from implementing receiveApproval in the new token, if the previous token supports approveAndCall, or ending with utilizing approve + transferFrom framework if you have just a bare minimal ERC20 (the user _approve_s tokens to the new token contract address and then calls a function in the new contract which burns old tokens and mints new ones — but this requires a standard fee for the user for the approval transaction). Actually, there is more: you can decide not to burn old tokens but to "lock" them on a new token smart contract, minting new tokens — this opens an opportunity to implement two-sided token migration, which is awesome — you won't need to list the "new" token on the exchange, while the users will still be able to send the old token to exchanges without fees in Ether! If you are interested, please fill the issue here if you want to know more details on how to do it, because this approach is worth a whole new article.

In my previous article, I provided an example of the token smart contract which supports delegation of such functions like transfer, transferFrom, approve and approveAndCall. Exactly these "delegated" functions allow users to pay fees in tokens, instead of Ether.

How delegation works in Ethereum, in short. Read more in this article.

But that wasn't enough to start the mass adoption. In this article, I am providing a complete universal back end solution (Transaction Publisher in the picture above), as well as a configurable widget (check it here), which allows you to replace Ether fees for token fees today.

Some key points before we dive in:

• This delegated transactions back end is made to be universal, or standard-free, meaning that you can have any implementation of delegated functions and use any signature standard(s) in your token. From the back end standpoint, you just need to write a manifest file for your token, describing its usage.
• Currently, converting collected fees in tokens back to Ether is a manual action on exchanges. But it could be a potential improvement for automation in the future (if needed).

The Concept Behind the Universal Solution

What does it mean that the token supports delegated transactions? Let's look at it using the ERC20 standard token as an example.

Smart Contract

As for the token smart contract, the approach is quite straightforward. In addition to every method like transfer(to, value) which we want to be "delegatable", we add a companion function which, instead of inspecting msg.sender, accepts the signature of a user and does the same what the original function meant to do by validating this signature inside the smart contract. Thus, for example, for transfer(to, value) function we can add transferViaSignature(to, value, ...aditionalParams) function. As you know from public-key cryptography, no one can create a valid signature except private key owner, so that's why this approach is as secure as Ethereum itself.

And the coolest part is that the delegated function implementation, as well as its signature doesn't matter much, from the delegate back end standpoint. You can even decide to implement one "call by signature" function for all other functions that the smart contract supports. Delegate back end just need to know how to call this function, which is solved by providing an off-chain contract manifest for the delegate back end. For example, the argument additionalParams in transferViaSignature can vary and can include anything from this list, if not more: fee, fee recipient address, expiration timestamp, a signature standard used, a signature itself, nonce number or any other unique delegated transaction ID and so on. Regarding the smart contract design, in order to understand why exactly these arguments, read my previous article.

We also want to allow "delegates" to earn something in order to cover their Ether spending, as well as to be profitable. Thus, we have to add a fee, but a much more natural fee than Ether: a fee in the token itself. So that, for example, if you need to transfer 100 tokens, you pay 3 more tokens to the delegate depending on its price and network conditions to perform a transfer, and this should be preserved in a smart contract logic.

Back End

All right, now we have a token that allows transferring someone else's tokens by using their signature. Now, the crucial part is to automate the process of requesting and publishing such transactions. And here where our open-sourced back end (and a front end) kicks in.

Below is the sequence diagram describing how front end (client) communicates with the back end from the delegated transaction request to its publishing to the network:

1. (hidden on the diagram) The client requests information from the delegated back end to understand which contracts does it support, as well as which functions can it delegate.
2. The client requests a particular smart contract's function to be delegated. Most importantly, the back end returns the fees it charges and a data to be signed by the client.
3. The client signs the data in their wallet. Signing is a free operation, unlike publishing transaction to the network.
4. The client sends their signature back, thus confirming their intent to perform this particular delegated transaction. The back end validates this transaction against the current network.
5. Finally, the back end publishes a transaction to the network.
6. (hidden on the diagram) The client constantly polls the back end for the delegated request status until it receives a mined status. Note: it is important to poll the back end instead of using a transaction hash to understand when the transaction is mined. It is a very common case when the gas price suddenly increases, and, in order for the transaction to be mined quickly, the back end may republish it with a higher gas price. Though it is currently not implemented, it is very likely to be implemented soon.

Sequence diagram representing the simplified flow of how delegated transaction is delivered to the network

This approach is universal, and only requires the manifest file for the back end to understand how to calculate fees and which signature standard to use on the client side. Here is another visualization of the components of the system and their interaction sequence:

Component diagram

We've provided a comprehensive documentation for this solution. You can check how the back end API is structured, as well as find the token manifest file which describes how to work with a particular token contract. We encourage you to contribute your own tokens there!

And you don't need much setup: it's already there with the universal front end!

Front End

Open-sourced front end part of the delegated transactions is the user interface which is set up for every token: just run your delegated transactions back end and you are ready to go!

What it looks like

It is made to be an embeddable widget, which will guide the user through the procedure of sending tokens. You can plug any back end, token or call any token function with it by utilizing additional URL parameters you can specify.

Using this widget, and by implementing something similar to widely used, but not standardized approveAndCall function in your token smart contract, you will be able to call other smart contracts with arbitrary data by paying fees in tokens!

Here is a quick guide for you if you want to play with this UI yourself:

1. Access the widget via this link.
2. It will ask you to switch to the Kovan test network.
3. Get some test Ether using any available Kovan faucet.
4. Use test Ether to mint some test tokens: call mintTokens function in a token smart contract which will give you 10 test tokens.
5. Now, get back to the widget and try to transfer these tokens!

If you open up the browser's developer tools, you may notice that there are a couple of back ends connected by default — they provide the front end with all required information to make a delegated request according to given widget URL parameters. All backends are requested during the widget load and, if any of them can provide a delegation for a particular contract's function, then the widget requests additional information: fees, supported signatures, etc. If there are multiple back ends which can delegate the same contract function, all of them are requested and the back end which provides the best fee will be used for the transaction.

Transaction mining time is seemingly fixed, but it can vary because of the network conditions. The back end uses an actual network fee when calculating the token fee, however, it may change before the user decides to execute the transaction. Thus, the "underpriced" transaction is submitted to the network and can be pending for a while. While the back end is currently not programmed to deal with this case, it might be implemented in future — transactions will be republished with higher gas fees in case of the network fee increases. But, we will also need to count this into the token fee.

Signature Standards

The last question which you may be wondering is — which signature standard to use for your token. There are several available: _ethsign (deprecated), _ethpersonalSign (note that old Trezor and Ledger produce a different signatures because of ambiguity in a standard, so you may want to include both), _ethsignTypedData (deprecated), _eth_signTypedDatav3 and so on. I would recommend supporting at least two: ageless _ethpersonalSign and new _eth_signTypedDatav3 (as of 2019).

Signature standards comparison — what the user sees

The front end is programmed to always prefer the user-readable standard like eth_signTypedData_v3 to any others eth_personalSign. So if your token supports many signature standards, and you added all of them to the manifest file of your token, it will display eth_signTypedData_v3 prompt first.

Conclusion

Delegated transactions are great: they solve one of the biggest problems of blockchain application adoption, which eases the mass adoption of crypto overall. I will put a couple of thesis in a Q&A format here for you to answer the last questions that you may still have after reading this article:

• Our open-source solution is free to use and production-ready, feel free to apply it to your applications or tokens!
• The described approach does not compromise security nor centralization. Think this way: the centralized back end is only a helper for someone who wants to transfer tokens without fee in Ether. If the back end is hacked, or it is just unavailable, there's no problem to interact with the network just as it was before, by paying fees in Ether. As well as the back end cannot harm or trick the user to steal their tokens when a proper signature standard is used (it's up to your token implementation).
• There is a way to support delegated transactions for existing, already-deployed tokens. However, it requires the additional Ether-consuming step to migrate existing tokens to a new token contract. And, by programming a new token contract properly, as well as designing your application to work with both tokens you can even avoid a need to list a new token on exchanges.
• By using the existing tokens as an example, which is available in delegated transactions back end and front end repositories, you can produce your own manifest for your own token.
• Read the instructions on how to set up your own back end for a token, and then add it to the URL of your widget (or commit to the open-source repository).
• Have a token which already supports delegated transactions? Plug it into our UI with these three quite simple steps: (1) create a manifest for your token and put your token abi file while setting up the delegate back end, (2) run this back end, exposing a public API URL and (3) use URL parameters in a widget to reference your back end or commit it directly to our open-source repository. Read more about it in GitHub's readme file.

I hope that was a really helpful piece of information for all the searchers of incredible. Feel free to contact me or fill the issue here if I missed something. Have fun, let the token economy be simple!

I attended a talk on Ethereum sometime back and was fascinated by the possibilities it provided and started exploring the ecosystem. It is a pretty nascent ecosystem that is catching up fast among the developer community. In this post I will explain the technology behind Ethereum so that we can get started with developing with Ethereum. This assumes you have technology background and basic understanding of blockchain so that we can discuss the Ethereum implementation.

First things first

Blockchain provides a de-centralized, peer to peer network where digital assets can be transferred from one peer to another. The major problem we face in a de-centralized network is who will verify the validity of all the transactions taking place? The short answer is everyone.

Imagine a document with some information . Each person in the network keeps a copy of the same document. If there is an update in the document, it is propagated across the network and everyone updates their own copy of the document. Lets say a new person comes with different content in the document, then all the others can verify their copy and detect that the new person is lying and kick him out of the network. This is basically how a blockchain works.

First we need to understand few basic terms to get started.

Hash

We can use a cryptographic hash function(SHA256) to convert any string to its equivalent hash. The hash has two unique properties:

1. The hash produced has one to one mapping with the input string. The same input always produces the same unique hash and no other input can have the same hash.
2. Even a small change in the input string will lead to a large change in the output hash and thus the input can be easily validated.

Transaction

The process by which assets are moved from one party to another in the network is known as Transaction. All transactions are recorded and permanently stored.Lets say A wants to transfer 5 Ether to B. Then this is a transaction in the network.

Block

Many transactions are combined together to form a block. Each block consists a unique hash which identifies it in the network. A block is chained to previous block using the hash of the previous block.

Genesis Block

The initial block or state of the blockchain that is agreed upon by all the nodes in the network.

Blockchain

As the transactions are added many blocks are created and then they are chained together using their hashes into blockchain network.

Proof of work

A proof of work is a piece of data which is difficult (costly, time-consuming) to produce but easy for others to verify and which satisfies certain requirements. When there is a transaction in the network, any node that tries to process the transaction should solve a cryptographic puzzle for it to be accepted to the block. This is known as proof of work. The work that is to be performed can be done only by trial and error and this has to be performed for any valid transaction in the network before it can become part of the blockchain.

Mining

The process of processing a transaction and adding it to the block by carrying out the proof of work is known as mining. The miners(nodes) get the rewards of the transaction once the transaction is accepted as part of the blockchain.

Merkle Tree

A Merkle tree is a tree in which every non-leaf node is labelled with the hash of the labels of its child nodes. We can verify that the data blocks received from other nodes are received undamaged and unaltered, and even to check that the other nodes do not lie and send fake blocks.

Working

We can now move on to basic working of a blockchain.

1. Each node starts with genesis block and builds its way up to the “current state” of the blockchain. When it receives a new block each node verifies its hash and thus validates if its a valid block or not and keeps building the chain.
2. Once there is a transaction in the network, the miner mines it by generating the required proof of work. Then the miner adds it to his copy of the network and propagates the change to the nearby nodes.
3. All the nodes which receives it will validate the proof of work and then add it to their respective copies. If it is not valid, then the block is not added to the chain.
4. When there is a conflict in the network , then the “longest chain rule” is applied to resolve it. Lets say two miners claim the same block and both have valid proof of work. Then the longest chain rule is applied which is whichever miner has the longest chain of blocks will be taken as the winner and that is added to the blockchain.

Ethereum

Now that you have got a grasp of blockchain lets move ahead with Ethereum. Ethereum is a decentralized platform that allows us to write applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference. It consists of Ethereum Virtual Machine(EVM) which provides the container in which all the smart contracts can be executed.

Smart contracts

Ethereum allows us to write applications on the blockchain and this applications are known as smart contracts. These smart contracts reside on the blockchain and they are immutable in nature, ie. the code cannot be deleted or modified in the blockchain once it is deployed. This can be written using Solidity or other languages, but the most preferred is solidity. It is a turing complete language.

Ether

Ether is the cryptocurrency used in the Ethereum blockchain.

Accounts

In Ethereum, the state is made up of objects called “accounts”, with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. There are two types of accounts in Ethereum:

• Externally owned accounts : These accounts are owned by users, controlled by private keys. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction.
• Contract accounts: These accounts are owned by contract code. In a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.

Gas

As smart contracts are turing complete any infinity loop or other code can be written and the blockchain can be crashed. To prevent from such attacks Ethereum uses a concept called gas. Gas is nothing but some transaction cost which is paid to execute the transaction using Ether(basic currency in Ethereum chain). Each instruction requires some gas to be executed and the gas is sent along with any call that needs to modify the blockchain.

DAPPS

These are distributed apps that can be built using the smart contracts and providing an interface for the users(accounts). Different kinds of applications can be developed which will interact with smart contracts residing in the blockchain.

Basic Workflow using Ethereum

We can discuss a basic workflow in Ethereum network for better understanding of how all these concepts work together in unison.

1. We can write smart contracts and deploy it to Ethereum network. Once deployed these contracts cannot be changed.
2. Any account or another smart contract in the network can execute these smart contracts functions through transactions.
3. The smart contracts can be called and executed by sending transactions to the contract. These transactions cost gas and a certain gas should also be sent along with the transaction.
4. Sometimes we just need to know the state of some contract without modifying the blockchain. These are known as calls and they do not cost any gas.
5. We can build various Dapps by executing the smart contracts using transactions and calls , thus allowing the user to directly interact the smart contract in different ways.

I believe this post provides basic understanding of the blockchain and Ethereum. In my next post I will provide a detailed guide to getting started with building Dapps using Ethereum.

If you liked this story, feel free to reach out to me at https://kaizencoder.com/

You will learn how to create a todo app with Ethereum smart contracts using the Solidity programming language. You will also learn to write tests, deploy to the blockchain, and create a client-side application.

You can watch the full video course on the freeCodeCamp.org YouTube channel (1.5 hour watch).

In this tutorial we will:

• Setup a blockchain with multiple nodes
• Setup mining nodes
• Connect the multiple nodes and setup the blockchain network
• Test the blockchain network by mining blocks and verifying that blocks are propagated to all the nodes
• Verify that the local copy of blockchain on all the nodes is updated

Setup and Prerequisite Software

Go Etheruem (Geth) is a command line client interface tool that allows you to interact with your private Ethereum blockchain.

If you need to install Homebrew on your Mac, place the following line in your terminal command prompt:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Once Homebrew is installed, install Geth:

$ brew tap ethereum/ethereum$ brew install ethereum

Configure the Genesis Block

Create a new project directory. Within it create the **genesis.json** file using any editor of your choice. I use Visual Studio code on Mac, which is a free editor:

$ mkdir project3$ cd project3

Copy the following JSON into your **genesis.json** file, and save the file in your project directory.

\\genesis.json file

{

"config": {

"chainId": 4321,

"homesteadBlock": 0,

"eip155Block": 0,

"eip158Block": 0

},

"alloc": {},

"difficulty" : "0x20000",

"gasLimit"   : "0x8880000"

}

Set up the first node (Node 1)

Once the **genesis.json** file is saved, you are ready to create your first node. To create your first node, open a new terminal window and navigate to your project folder, and type in the following command:

$ geth --datadir blkchain1 init genesis.json

This command initializes a new blockchain node using the configuration specified in the **genesis.json** file. By using — -datadir we specify the name of the directory where the local copy of the blockchain will be stored on the node.

This command will create a directory called **blkchain1** in your project directory. This directory contains the **geth** and **keystore** directories. The blockchain data will be stored in the local database in the **geth** directory.

You can verify this by navigating into the **blkchain1** directory in your command terminal and typing in ls -l. Also navigate to the **geth** sub-directory and type in ls -l.

Now that your Node 1 is initialized, let’s start Node 1 using Geth. Within your terminal window, navigate to your project folder (where you saved your **genesis.json** file) and type in the following:

$ geth --datadir blkchain1 --nodiscover --networkid 1234 console

This command will start your first node and bring up the Geth console, where you can type in commands to interact with the Node1 blockchain.

You will see the following:

Let’s break down this “geth console” command and understand it:

— -datadir blkchain1:
specifies the data directory of the blockchain. If you do not specify this, it will default to the main Ethereum blockchain.

--nodiscover:
disables the peer discovery mechanism and enables manual peer addition.

--networkid 1234:
identity of your Ethereum network, other peer nodes will also have the same network identifier. The network id can be any random integer value.

Now that you are in the Geth Console, to get more information about the node we will use the admin command. Type in the following command in the Geth console:

> admin.nodeInfo

This will give you more information about your node:

Notice the following:

• by default the listener port is 30303
• the enode id is your node id
• the discovery port is ‘0’, since we set it to --nodiscover.

To get a list of all admin commands, type in “admin.” and press

Now, let’s setup an account where the mined ethers will be collected. Type in the following in the Geth console:

> personal.newAccount()

You can put in any passphrase — this is your password. The command returns the account id.

To get a list of all the accounts:

> personal.listAccounts

Node 1 is now ready!

Keep the terminal window (with the Geth Console for Node1) open and running. We will open a new terminal window to setup Node 2.

Set up the second node (Node 2)

Now let’s setup a second node in the blockchain network. The process will be similar to setting up Node1.

Open a new terminal window and navigate to the project folder that contains the **genesis.json** file.

Initialize the new node with the following command:

$ geth --datadir blkchain2 init genesis.json

Note: Since we want this node to be part of the same blockchain, we use the same genesis block.

This will create a new node whose data will be stored in a new directory called **blkchain2** (this will contain the local copy of the blockchain database for the node 2).

To get the node 2 up and running with a Geth console, type in the following:

$ geth --datadir blkchain2 --nodiscover --networkid 1234 --port 30304 console

This will start up Node 2 and bring up the Geth console connected to Node 2.

Note the following differences for Node 2:

• we specify a port number 30304
  The default port 30303 is already being used by the first node, so if we do not specify a separate port it will throw an error.
• we give the same networkid as we did for node 1. This is important, since we want both the nodes to be part of the network
• we specify that the — -datadir for node2 will be in **blkchain2**

Run the admin.nodeInfo command in Geth Console for Node2:

> admin.nodeInfo

Notice that this provides the node information for Node 2. You can compare the enode id by running the same admin.nodeInfo command in the Terminal window running the Geth console for Node1.

NODE 1

NODE 2

Similar to Node 1, we can setup an account on Node 2 by typing in personal.newAccount() in the Geth console for Node2.

You can use any passphrase for the account.

> personal.newAccount()

Node 2 is now ready!

Keep open both the terminal windows, one running the Geth Console (Node1) and the second running the Geth Console (Node2), side by side.

In the next step we will connect Node1 and Node2 and create the blockchain network!

Connect the Nodes

Congratulations! You have 2 blockchain nodes running.

The next step is to connect them to each other and create a network. We will do this by adding one of the nodes to the other as a “peer”.

Run the following command on the Geth Consoles of both Node1 and Node2:

> admin.peers

Notice that both return an empty array, since the nodes are not connected to any other nodes.

Let’s add Node1 as a peer to Node2.

1. Run the admin.nodeInfo command on Node1

2. Copy the enode id for Node 1:

"enode://549468e6d00e135128af33e03a6d27b0ee5fda7fbd0154b2e83fe68afdfda869eb6ace6ccaefe84ed7a5b804529dcef49f0b5d64be97da87b1e28ddecfca227a@[::]:30303?discport=0"

3. In the Geth Console for Node2, add the Node1 as a peer to Node2 using the command admin.addPeer(“//enode id”):

> admin.addPeer("enode://549468e6d00e135128af33e03a6d27b0ee5fda7fbd0154b2e83fe68afdfda869eb6ace6ccaefe84ed7a5b804529dcef49f0b5d64be97da87b1e28ddecfca227a@[::]:30303?discport=0")

Now when you run the admin.peers command in either of the Geth Console you will see the other Node listed as a peer!

Hurray! You now have a connect blockchain network!

But how do we know for sure?

Let’s put it to the test, shall we? Let’s update something in Node1 and see if that change is propagated through the blockchain network to Node2.

Verify that you have a connected blockchain and a distributed database

Ok, thus far you should have:

• Two terminal windows open
  One running Geth Console for Node1, and the second running Get Console for Node2
• Node 1 saves its local copy of the blockchain in the **blkchain1** folder
• Node 2 saves its local copy of the blockchain in the **blkchain2** folder
• Also, in the previous step you connected the two nodes using admin.addPeer()

Thus, if the new blocks are mined and added in Node 1, this new block should propagate over the blockchain network, and the local blockchain copy of node2 should update automatically.

Let us verify if this happens.

In the Geth Console(Node1) let’s begin mining:

> miner.start(1)

To check how many blocks have been mined at Node1 at any point, run the following in the Geth Console (Node1):

> eth.blockNumber

This will return the number of the current block mined (or the blockchain height).

After a few blocks have been mined, go to the Geth Console (Node 2) and run the eth.blockNumber command.

You will notice that the block height in Node 2 matches with the block height in Node 1! This verifies that the Blocks that were mined in Node 1 were propagated over the Blockchain to Node 2.

To kick it up a notch, you can verify the data in the actual blocks on Node 1 and Node 2.

Wait until about 10 blocks have been mined and then run the following command in Geth Console(Node1) and Geth Console(Node2):

> eth.getBlock(3)

This command displays the contents of Block 3 from the blockchain. Notice that the data displayed in Geth Console (Node1) and Geth Console(Node2) is identical, indicating that the Block3 that was mined by Node1 was propagated over the blockchain network and is also part of the local blockchain data in Node 2.

Node 1

Node 2

Hurray!! You now have a fully functional and connected multi-node private Ethereum network!

Happy Coding!

Follow me on Medium for the latest updates and posts!