Ethereum is one of the major pioneers in the decentralized ecosystem. And Web3.js is an essential tool if you're working on Ethereum-based projects.

To fully understand why this tool is important, we must first take a deeper dive into Ethereum development.

Grab your coffee, young Web3 enthusiast. We're going on a journey that will change your Web3 career forever.

Prerequisites

Before you can carry on with this tutorial, you'll need to understand the basics of JavaScript, and should be able to install npm packages.

If you've worked with JavaScript before, the rest of this tutorial should be a breeze.

What is Ethereum Development?

Ethereum is a decentralized open-source blockchain platform that lets developers build decentralized applications, popularly known as dAPPs. These dApps are built on top of the Ethereum blockchain, harnessing some of the core features of the Ethereum network.

Ethereum is written in Solidity, which is the primary programming language used in the Ethereum ecosystem. You can use Solidity to design smart contracts, which are basically self-executing contracts that power a lot of dApps.

If you want to work in Ethereum development, understanding smart contracts is extremely important.

Smart contracts consist of the terms of the agreement between buyer and seller that are directly written into the lines of code. This code is written in Solidity, which can only exist in the blockchain network.

To become an Ethereum developer, you are going to work mainly around the network, building smart contracts and dApps.

Let's talk about the tools you are going to need:

• Solidity
• Ether.js
• JavaScript/React for front-end visual interaction

The World of Web3.js

Now that you have an idea of what Ethereum development is, we can begin to understand Web3.js a little better.

Web3.js is a collection of libraries that allow you to interact with a local or remote Ethereum node, using HTTP, IPC, or Web Sockets (which is my personal favorite). It is written in JavaScript, and to put it simply, it lets you interact with the blockchain more efficiently.

By reading data from the blockchain, you will be able to make transactions and deploy smart contracts live on the mainnet.

How to Set Up Web3.js

Web3.js can access blockchain information from both the back end and front end to make transactions and deploy smart contracts.

You are going to need Node.js, which you can easily download from the official website. The installation process is pretty straightforward.

After you've successfully installed Node and npm (the official package manager for Node), open your command line in the root folder of your project and type the following command:

npm install web3 --save

Then you'll be able to import Web3.js into a Node script using this simple code:

const Web3 = require("web3")

We've got some of the hard part locked down. Now we just need our project to communicate directly with the blockchain.

To initiate our Web3 provider, we must instantiate, which just means creating a Web3 instance, and pass a constructor to the URL of the provider.

In this case, we'll have to find an Ethereum node that we can connect to and start crafting magic.

There are multiple node providers like Alchemy, Chainstack, and Moralis, and there's a lot of documentation when it comes to getting a direct access.

You can make use of the Ganache instance as well, which will essentially help you set up the environment for anything you need to work in your local environment.

To understand how to set up Ganache, you can read the linked guide that covers everything you need to know.

You simply place this below your code like so:

const Web3 = require("web3")
const web3 = new Web3("http://localhost:8545")

To test that you have successfully configured everything, you can write some simple code to get the latest block number on the blockchain:

var Web3 = require("web3")
const web3 = new Web3("http://localhost:8545"")

web3.eth.getBlockNumber(function (error, result) {
  console.log(result)
})

This function simply accepts a callback as a parameter, then prints the result as an integer. Running this would just give you a block number on your console.

There are many other functions you can use. The web3 official documentation provides a comprehensive list of functions that you can learn about and try out.

Conclusion

If you're wanting to get into Ethereum development, Web3.js will be a vital part of your stack. Throughout your journey, you are going to be interacting with the Ethereum node more frequently and Web3.js will come in handy.

There are other alternatives like Ether.js, which also strive to provide a complete library that can interact with the Ethereum node. But Web3 is known to have a larger network of support, a larger community of developers, and more mature documentation that you can refer to regarding problems of any sort.

Hopefully this article has given all of the insights you need for you to start your Ethereum journey. I'm available on Twitter, if you have any questions.

But this implies that you have no control over the information relating to your identification, who has access to personally identifiable information (PII), and to what extent.

As a result, Decentralized Identity provides identity-related information that is self-controlled, private, and portable. Decentralized identifiers and attestations serve as the main building pieces.

Thanks to Ceramic's decentralized application databases, application developers can reuse data across applications and automatically make them interoperable.

In this article, you will learn about Decentralized Identity, Decentralized Identifiers, Ceramic network, and how to build a decentralized identity profile with Ethereum on Ceramic Networks.

Here's what we'll cover:

• What is a Decentralized Identity?
• What are Decentralized Identifiers?
• What is Ceramic Data Network?
• Why Ceramic Network?
• How to Build a Decentralized Identity Profile with Next.js
• Prerequisites
• Project Setup and Installation
• Install TailwindCSS in Next.js
• Authenticate Users
• Create/Update User Profile
• How to Test the Application
• Conclusion
• References

What is a Decentralized Identity?

Decentralized Identity is a digital identification concept where people, companies, and items are in charge of their data and can share it selectively without relying on a centralized authority.

This is made possible by using decentralized technologies, such as blockchain. These give people control and ownership over the information associated with their identities rather than having it stored on a central server or managed by a third party.

A decentralized identity is a self-owned, independent identity that enables trusted data exchange.

Blockchain-based digital wallets, such as those used to store and handle cryptocurrencies, serve as a practical illustration of decentralized identification. Users of these wallets control the private keys that provide them access to their money and can distribute their public keys to others to accept payments from them.

Users who manage their private keys can conduct transactions with others without relying on a central authority, such as a bank, and keep custody of their money.

What are Decentralized Identifiers?

Decentralized identifiers (DIDs) are issued, held, and controlled by individuals. Since they are kept on peer-to-peer networks or distributed ledgers (blockchains), they are globally unique, highly available, and cryptographically verifiable.

Decentralized identifiers can be associated with individuals, groups, or governmental entities.

DIDs are a vital component of the developing decentralized identity ecosystem. They are designed to offer a uniform process for developing, maintaining, and exchanging digital identities unaffiliated with any one company or piece of technology.

This implies that a DID can be maintained and controlled by the person or entity to which it belongs and utilized across various systems and applications.

In recent years, smart contract platforms like Ethereum have demonstrated the utility of decentralized applications (dApps) that can be assembled like blocks to create new applications. This is especially evident in tokens that build upon one another, in DeFi protocols that use one another, and so on.

Thanks to Ceramic, data on the internet can now have the same kind of composability. Any data type, including profiles, social connections, blog posts, identities, reputations, and so on., can be included. You will learn more about Ceramic Network in the section below.

What is Ceramic Network?

Ceramic is a public, permissionless, open-source protocol that offers computation, state transitions, and consensus for all data structures on the decentralized web.

With the help of stream processing provided by Ceramic, developers can build apps that are strong, safe, trustless, and censorship-resistant using dynamic information – without using unreliable database servers.

Ceramic stores all content in smart documents, which are append-only IPFS logs. Before being anchored in a blockchain for consensus, each commit is verified by a decentralized identification (DID).

All papers in Ceramic are openly discoverable and can be referenced by other documents or queried by any other network user because the system is entirely peer-to-peer.

Why Ceramic Network?

Data interoperability is one of Ceramic Network's key benefits. This platform features a flexible and modular data schema that enables the decentralized and interoperable sharing and combining of various sorts of data.

Developers now have an easier time creating decentralized identification solutions that can be integrated with other programs and systems.

The infrastructure of Ceramic Network is scalable, fault-tolerant, decentralized, and highly available. This enables developers to create robust decentralized identity systems available to users everywhere.

Ceramic Network also provides a set of developer tools and libraries, making it simple to create decentralized identity apps and services. These tools include SDKs, APIs, developer guides, and an expanding ecosystem of open-source tools and libraries.

Now that you have learnt the theories behind decentralized identity, let's take a practical deep dive and get your hands dirty.

How to Build a Decentralized Identity Profile with Next.js

Prerequisites

To go through this tutorial, you'll need some experience with JavaScript and React.js. Experience with Next.js isn't a requirement, but it's nice to have.

Make sure to have Node.js or npm installed on your computer. If you don't, click here.

Also, it'll be very useful to have a basic understanding of blockchain technology and Web3 concepts.

Project Setup and Installation

Navigate to the terminal and cd into any directory of your choice. Then run the following commands:

mkdir decentralized-identity-project
cd decentralized-identity-project
npx create-next-app@latest .

Accept the following options:

Install the @self.id/react and @self.id/web packages using the code snippet below:

npm install @self.id/web @self.id/react

Next, start the app using the following command:

npm run dev

You should have something similar to what is shown below: the default boilerplate layout for Next.js 13.

Install TailwindCSS in Next.js

In this section, you will set up Tailwind CSS in a Next.js project. Install tailwindcss and its peer dependencies via npm, and then run the init command to generate both tailwind.config.js and postcss.config.js.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Navigate to the tailwind.config.js file, and add the paths to your template files with the following code snippet.

/** @type {import('tailwindcss').Config} */

module.exports = {
  content: [
    "./app/**/*.{js,ts,jsx,tsx}",
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",

    // Or if using `src` directory:
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Delete all the CSS styles inside globals.css . Add the @tailwind directives for each of Tailwind’s layers to your globals.css file.

@tailwind base;
@tailwind components;
@tailwind utilities;

Configure the Provider Component

The Provider component must be placed at the top of the application tree to use the hooks detailed below. You can use it to supply an initial state as well as a specific configuration for the Self.ID clients and queries.

Update the _app.js file under the pages folder with the following code snippet:

// Import the Provider component from the "@self.id/react" library.
import { Provider } from "@self.id/react";

// Import the "globals.css" file from the "@/styles" directory.
import "@/styles/globals.css";

// Define the App component as a default export.
export default function App({ Component, pageProps }) {

  // Render the Provider component, which provides authentication and authorization functionality to the application.
  // Pass a client prop to the Provider component, which configures the Ceramic testnet with the "testnet-clay" value.
  // Render the Component with its props inside the Provider component, which allows the application to access the authentication and authorization context.

  return (
    <Provider client={{ ceramic: "testnet-clay" }}>
      <Component {...pageProps} />
    </Provider>
  );
}

In the code snippet above, we:

• Imported a context provider component and global CSS styles and then defined an App component that wraps the entire application with the context provider.
• Configured the context provider with a Ceramic testnet client, which allows the application to access authentication and authorization functionality.
• Finally, the Component is rendered with its props inside the context provider, allowing the application to access the authentication and authorization context.

Build the Layout

Next, navigate to the index.js file under the pages folder and update it with the following code:

// Import the Head component from the "next/head" module.
import Head from "next/head";

// Import the useViewerConnection and useViewerRecord hooks from the "@self.id/react" library.
import { useViewerConnection, useViewerRecord } from "@self.id/react";

// Import the EthereumAuthProvider component from the "@self.id/web" library.
import { EthereumAuthProvider } from "@self.id/web";

// Import the useState hook from the "react" module.
import { useEffect, useState } from "react";


export default function Home() {

  return (
    <>
      <Head>
        <title>
          Decentralized Identity: Build a Profile with NextJs, Ethereum & Ceramic Network
        </title>
        <meta name="description" content="Generated by create next app" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main className="min-h-screen bg-gray-200">
        <div className="bg-gray-600 py-4 px-4 sm:px-6 lg:px-8 lg:py-6 shadow-lg text-white">
          <div className="container mx-auto px-6 md:px-0">
            <h1 className="text-2xl font-bold text-white text-center">
              Decentralized Identity: Build a Profile with NextJs, Ethereum & Ceramic Network
            </h1>
          </div>
        </div>

        <div className="flex items-center justify-center pt-20 font-sans overflow-hidden">
          <div className="max-w-md w-full mx-auto">
            <div className="bg-white p-10 rounded-lg shadow-lg">
              <form>
                <div className="mb-6">
                  <label
                    className="block text-gray-700 font-bold mb-2"
                    htmlFor="name"
                  >
                    Name
                  </label>
                  <input
                    className="border border-gray-300 p-2 w-full rounded-lg"
                    type="text"
                    name="name"
                    id="name"
                    placeholder="Your name"
                  />
                </div>
                <div className="mb-6">
                  <label
                    className="block text-gray-700 font-bold mb-2"
                    htmlFor="bio"
                  >
                    Bio
                  </label>
                  <textarea
                    className="border border-gray-300 p-2 w-full rounded-lg"
                    name="bio"
                    id="bio"
                    rows="5"
                    placeholder="Write something about yourself"
                  ></textarea>
                </div>
                <div className="mb-6">
                  <label
                    className="block text-gray-700 font-bold mb-2"
                    htmlFor="username"
                  >
                    Username
                  </label>
                  <input
                    className="border border-gray-300 p-2 w-full rounded-lg"
                    type="text"
                    name="username"
                    id="username"
                    placeholder="Your username"
                  />
                </div>
                <div className="flex items-center justify-between">
                  <button
                    className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
                    type="submit"
                  >
                    Update Profile
                  </button>
                  <button
                    className="bg-green-500 hover:bg-green-700 text-white font-bold py-2 px-4 rounded"
                    type="button"
                  >
                    Connect Wallet
                  </button>
                </div>
              </form>
            </div>
          </div>
        </div>
      </main>
    </>
  );
}

To start the application, run the following command and navigate to localhost:3000 on your browser; you should have something similar to what is shown below:

How to Authenticate Users

In this section, you will implement user authentication to allow users to connect their wallets and interact with the application.

Update the index.js with the following code:

//..

export default function Home() {

  // State variables for connection, connect function, and disconnect function
  const [connection, connect, disconnect] = useViewerConnection();


  const [isWindow, setIsWindow] = useState(null);


  // State variable for viewer's basic profile data
  const record = useViewerRecord("basicProfile");

  // Function to create EthereumAuthProvider using window.ethereum provider
  async function createAuthProvider() {
    const addresses = await window.ethereum.request({
      method: "eth_requestAccounts",
    });
    return new EthereumAuthProvider(window.ethereum, addresses[0]);
  }

  // Function to connect to viewer's account using created authProvider
  async function connectAccount() {
    const authProvider = await createAuthProvider();
    await connect(authProvider);
  }

  // Rendered JSX code
  return (
    <>
      {/* ... */}
      <div className="flex items-center justify-between">
        {/* ... */}

        {/* Conditionally render a button to connect/disconnect user */}
        {connection.status === "connected" ? (
          <button
            className="bg-red-500 hover:bg-red-700 text-white font-bold py-2 px-4 rounded"
            type="button"
            onClick={() => disconnect()}
          >
            Disconnect
          </button>
        ) : isWindow && "ethereum" in window ? (
          <button
            className="bg-green-500 hover:bg-green-700 text-white font-bold py-2 px-4 rounded"
            type="button"
            disabled={connection.status === "connecting" || !record}
            onClick={() => {
              connectAccount();
            }}
          >
            Connect Wallet
          </button>
        ) : (
          <p className="text-red-500 text-sm italic mt-2 text-center w-full">
            An injected Ethereum provider such as{" "}
            <a href="https://metamask.io/">MetaMask</a> is needed to
            authenticate.
          </p>
        )}
      </div>
    </>
  )
}

In the code snippet above,

• The useViewerConnection hook is used to set up a state variable for the user's connection status, connect and disconnect.
• isWindow to set the initial state of the the window to avoid React hydration error
• The useViewerRecord hook is used to retrieve the user's basic profile data.
• The createAuthProvider function creates an EthereumAuthProvider object using the window.ethereum provider.
• The connectAccount function calls createAuthProvider and connects to the user's account using connect(authProvider).
• The JSX code conditionally renders a button based on the user's connection status and the availability of an ethereum provider in the window object.
• If the user is already connected, the button will enable them to disconnect. If the user is not yet connected and an ethereum provider is available, the button will enable them to connect. But if the user is not connected and no ethereum provider is available, a message will be displayed to inform the user that an injected Ethereum provider like MetaMask is required to authenticate.

Testing out the authentication functionality, you should have something similar to what is shown below:

How to Create or Update a User Profile

In the previous section, you learned how to successfully authenticate users. Next, you will implement functionality to create and update an authenticated user with the following code snippet:

pages/index.js

//...


export default function Home() {
// Use the useState hook to create state variables and functions to update them
  const [name, setName] = useState("");
  const [bio, setBio] = useState("");
  const [username, setUsername] = useState("");

  //...

// Define an asynchronous function called updateProfile to update the profile information
  async function updateProfile() {
    // If any of the required fields are empty, return early and do not update
     if (!name || !bio || !username) {
       return;
     }

     // Use the merge method to update the record with the new information
     await record.merge({
       name,
       bio,
       username,
     });
   }

  // Render the component's UI
  return (
    <>

    {/* ... */}

    <div className="flex items-center justify-center pt-20 font-sans overflow-hidden">
          <div className="max-w-md w-full mx-auto">
            <div className="bg-white p-10 rounded-lg shadow-lg">
              <form>
               {/* ... */}
              </form>
            </div>
            {connection.status === "connected" && record && record.content ? (
              <div className="flex flex-col items-center mt-8">
                <h2 className="text-3xl font-bold mb-6 text-gray-900">
                  Profile Information
                </h2>
                <div className="w-full max-w-md bg-white p-8 rounded-lg shadow-lg">
                  <p className="mb-4">
                    <span className="font-bold text-gray-700 mr-2 text-lg">
                      Name:
                    </span>{" "}
                    <span id="nameOutput" className="text-lg">
                      {record.content.name || "No name set"}
                    </span>
                  </p>

                  <p className="mb-4">
                    <span className="font-bold text-gray-700 mr-2 text-lg">
                      Bio:
                    </span>{" "}
                    <span id="bioOutput" className="text-lg">
                      {record.content.bio || "No bio set"}
                    </span>
                  </p>
                  <p>
                    <span className="font-bold text-gray-700 mr-2 text-lg">
                      Username:
                    </span>{" "}
                    <span id="usernameOutput" className="text-lg">
                      {record.content.username || "No username set"}
                    </span>
                  </p>
                </div>
              </div>
            ) : (
              <div className="mt-8">
                <div className="bg-white p-8 rounded-lg shadow-lg">
                  <p>No profile found.</p>
                </div>
              </div>
            )}

          </div>
        </div>
    </>
  ) 
}

In the code above,

• The component uses the useState hook to manage the state of three variables: name, bio, and username.
• There's an async function called updateProfile that is responsible for merging the current state of the variables into a record.
• If any of the variables is empty, the updateProfile function returns without updating the record.
• There are three conditional statements that render a different UI based on whether a record is found or not.
• The first conditional statement checks whether the record is still loading, and if it is, it displays a Loading... message.
• The second conditional statement checks whether there's no record content and the connection status is connected. If this is true, it displays a No profile found. message.

The third conditional statement checks whether the record content exists. If it does, it displays the profile information, which includes the user's name, bio, and username.

You are almost there. In the form tag, update the name, bio and username input field with the following code:

<div className="mb-6">
  <label
    className="block text-gray-700 font-bold mb-2"
    htmlFor="name"
  >
    Name
  </label>
  <input
    //...
    onChange={(e) => {
      setName(e.target.value);
    }}
  />
</div>
<div className="mb-6">
  <label
    className="block text-gray-700 font-bold mb-2"
    htmlFor="bio"
  >
    Bio
  </label>
  <textarea
    //...
    onChange={(e) => {
      setBio(e.target.value);
    }}
  ></textarea>
</div>
<div className="mb-6">
  <label
    className="block text-gray-700 font-bold mb-2"
    htmlFor="username"
  >
    Username
  </label>
  <input
    //...
    onChange={(e) => {
      setUsername(e.target.value);
    }}
  />
</div>

In the code snippet above, setName, setBio, and setUsername are functions provided by the useState hook that update the state of name, bio, or username.

Next, the Update Profile button.

//...

 <button
     className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
     type="submit"
     disabled={!record.isMutable || record.isMutating}
     onClick={() => updateProfile()}
 >
    {record.isMutating ? "Updating..." : "Update Profile"}
</button>

//..

In the code snippet above, the button is disabled when the record is not mutable or is currently mutating.

When the button is clicked, it calls the updateProfile function, which is responsible for updating the user's profile information. If the record mutates, the button will display Updating.... Otherwise, it will display Update Profile.

You can test out the application similar to what is shown below.

Kindly find the complete code on GitHub repository here.

Conclusion

In this post, you learn about Decentralized Identity, Decentralized Identifiers, Ceramic networks, why Ceramic network is useful, and how to build a decentralized identity profile with Ethereum on Ceramic Networks.

References

• Ceramic Network
• Ceramic Documentation
• Decentralized Identity - Ethereum

I'd love to connect with you at Twitter | LinkedIn | GitHub | Portfolio

See you in my next article. Take care!

If you're a developer who's interested in Blockchain development, you should know something about NFTs, or Non-Fungible Tokens. So in this article, we'll learn about the engineering behind them so you can start building your own.

At the end of the project, you will have your own Ethereum wallet with a new NFT in it. This tutorial is beginner-friendly and does not require any prior knowledge of the Ethereum network or smart contracts.

The NFT contract has only 14 lines of code

What is an NFT?

NFT stands for non-fungible token. This quote from ethereum.org explains it well:

NFTs are tokens that we can use to represent ownership of unique items. They let us tokenise things like art, collectibles, even real estate. They can only have one official owner at a time and they're secured by the Ethereum blockchain – no one can modify the record of ownership or copy/paste a new NFT into existence.

What is an NFT standard or ERC-721?

The ERC-721 is the most common NFT standard. If your Smart Contract implements certain standardized API methods, it can be called an ERC-721 Non-Fungible Token Contract.

These methods are specified in the EIP-721. Open-sourced projects like OpenZeppelin have simplified the development process by implementing the most common ERC standards as a reusable library.

What is minting an NFT?

By minting an NFT, you publish a unique token on a blockchain. This token is an instance of your Smart Contract.

Each token has a unique tokenURI, which contains metadata of your asset in a JSON file that conforms to certain schema. The metadata is where you store information about your NFT, such as name, image, description, and other attributes.

An example of the JSON file for the "ERC721 Metadata Schema" looks like this:

{
    "attributes": [
        {
            "trait_type": "Shape",
            "value": "Circle"
        },
        {
            "trait_type": "Mood",
            "value": "Sad"
        }
    ],
    "description": "A sad circle.",
    "image": "https://i.imgur.com/Qkw9N0A.jpeg",
    "name": "Sad Circle"
}

How do I store my NFT's metadata?

There are three main ways to store an NFT's metadata.

First, you can store the information on-chain. In other word, you can extend your ERC-721 and store the metadata on the blockchain, which can be costly.

The second method is to use IPFS. And the third way is to simply have your API return the JSON file.

The first and second methods are usually preferred, since you cannot temper the underlying JSON file. For the scope of this project, we will opt for the third method.

For a good tutorial on using NFTs with IPFS, read this article by the Alchemy team.

What We'll Be Building

In this tutorial, we'll be creating and minting our own NFT. It is beginner-friendly and does not require any prior knowledge of the Ethereum network or smart contracts. Still, having a good grasp on those concepts will help you understand what is going on behind the scenes.

In an upcoming tutorial, we'll build a fully-functional React web app where you can display and sell your NFTs.

If you are just getting started with dApp development, begin by reading through the key topics and watch this amazing course by Patrick Collins.

This project is intentionally written with easily understandable code and is not suitable for production usage.

Prerequisites

Metamask

We need an Ethereum address to interact with our Smart Contract. We will be using Metamask as our wallet. It is a free virtual wallet that manages your Ethereum addresses. We will need it to send and receive transactions (read more on that here). For example, minting an NFT is a transaction.

Download their Chrome extension and their mobile app. We will need both as the Chrome extension does not display your NFTs.

Make sure to change the network to "Ropsten Test Network" for development purposes. You will need some Eth to cover the fees of deploying and minting your NFT. Head to the Ropsten Ethereum Faucet and enter your address. You should soon see some test Eth in your Metamask account.

Alchemy

To interact with the Ethereum Network, you will need to be connected to an Ethereum Node.

Running your own Node and maintaining the infrastructure is a project on its own. Luckily, there are nodes-as-a-service providers which host the infrastructure for you. There are many choices like Infura, BlockDaemon, and Moralis. We will be using Alchemy as our node provider.

Head over to their website, create an account, choose Ethereum as your network and create your app. Choose Ropsten as your network.

On your dashboard, click "view details" on your app, then click "view key". Save your http key somewhere as we will need that later.

NodeJS/NPM

We will be using NodeJS for the project. If you don't have it installed, follow this simple tutorial by freeCodeCamp.

Initialize the project

In your terminal, run this command to make a new directory for your project:

mkdir nft-project
cd nft-project

Now, let's make another directory, ethereum/, inside nft-project/ and initialize it with Hardhat. Hardhat is a dev tool that makes it easy to deploy and test your Ethereum software.

mkdir ethereum
cd ethereum
npm init

Answer the questions however you want. Then, run those commands to make a Hardhat project:

npm install --save-dev hardhat
npx hardhat

You will see this prompt:

888    888                      888 888               888
888    888                      888 888               888
888    888                      888 888               888
8888888888  8888b.  888d888 .d88888 88888b.   8888b.  888888
888    888     "88b 888P"  d88" 888 888 "88b     "88b 888
888    888 .d888888 888    888  888 888  888 .d888888 888
888    888 888  888 888    Y88b 888 888  888 888  888 Y88b.
888    888 "Y888888 888     "Y88888 888  888 "Y888888  "Y888

Welcome to Hardhat v2.0.8

? What do you want to do? …
  Create a sample project
❯ Create an empty hardhat.config.js
  Quit

Select create an empty hardhat.config.js. This will generate an empty hardhat.config.js file that we will later update.

For the web app, we will use Next.js to initialize a fully-functional web app. Go back to the root directory nft-project/ and initialize a boilerplate Next.js app called web:

cd ..
mkdir web
cd web
npx create-next-app@latest

Your project now looks like this:

nft-project/
    ethereum/
    web/

Awesome! We are ready to dive into some real coding.

How to Define Our .env Variables

Remember the Alchemy key we grabbed from our test project earlier? We will use that along with our Metamask account's public and private keys to interact with the blockchain.

Run the following commands, make a file called .env inside your ethereum/ directory, and install dotenv. We will use them later.

cd ..
cd ethereum
touch .env
npm install dotenv --save

For your .env file, put the key you have exported from Alchemy and follow those instructions to grab your Metamask's private key.

Here's your .env file:

DEV_API_URL = YOUR_ALCHEMY_KEY
PRIVATE_KEY = YOUR_METAMASK_PRIVATE_KEY
PUBLIC_KEY = YOUR_METAMASK_ADDRESS

The Smart Contract for NFTs

Go to the ethereum/ folder and create two more directories: contracts and scripts. A simple hardhat project contains those folders.

• contracts/ contains the source files of your contracts
• scripts/ contains the scripts to deploy and mint our NFTs

mkdir contracts
mkdir scripts

Then, install OpenZeppelin. OpenZeppelin Contract is an open-sourced library with pre-tested reusable code to make smart contract development easier.

npm install @openzeppelin/contracts

Finally, we will be writing the Smart Contract for our NFT. Navigate to your contracts directory and create a file titled EmotionalShapes.sol. You can name your NFTs however you see fit.

The .sol extension refers to the Solidity language, which is what we will use to program our Smart Contract. We will only be writing 14 lines of code with Solidity, so no worries if you haven't seen it before.

Start with this article to learn more about Smart Contract languages. You can also directly jump to this Solidity cheat sheet which contains the main syntax.

cd contracts
touch EmotionalShapes.sol

This is our Smart Contract:

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

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

contract EmotionalShapes is ERC721 {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIdCounter;

    constructor() ERC721("EmotionalShapes", "ESS") {}

    function _baseURI() internal pure override returns (string memory) {
        return "YOUR_API_URL/api/erc721/";
    }

    function mint(address to)
        public returns (uint256)
    {
        require(_tokenIdCounter.current() < 3); 
        _tokenIdCounter.increment();
        _safeMint(to, _tokenIdCounter.current());

        return _tokenIdCounter.current();
    }
}

Let's go through the code and understand what is going on.

1. At the top of the file, we specified which OpenZeppelin module to import. We need the ERC721 contract as it is the 'base' of our Smart Contract. It has already implemented all the methods specified in EIP-721 so we can safely use it.
2. A Counter is useful to generate incremental ids for our NFTs. We named the variable _tokenIdCounter
3. In the constructor, we initialized our ERC721 with its name and its symbol. I chose EmotionalShapes and ESS.
4. We override the default _baseURI function by returning our own. We will get to build that in a second. In summary, it is the URL that will be added as 'prefix' to all our tokenURIs. In the above example, the metadata of our NFTs will live in a JSON file at YOUR_API_URL/[api/erc721/](https://e110-99-121-58-31.ngrok.io/api/erc721/)1.
5. We implement the 'mint' function. It is the function that lets you publish an instance of this Smart Contract on the blockchain. I required the _tokenIdCounter variable to be less than 3 as I will only create three instances of my NFT. You can remove that if you want to mint more.
6. Finally, inside the mint function, we increment the _tokenIdCounter variable by 1, so our id will be 1, followed by 2, followed by 3. Then, we call the function provided by OpenZeppelin _safeMint to publish the token.

Don't worry if you feel lost. You can attend a workshop led by volunteers from freeCodeCamp, where we invite devs of similar skill levels to build stuff together, including this NFT project.

The events are free and remote, so you can ask any questions directly. You can register here. The seats are limited so you will be invited to the next available events.

How to Build the Metadata for our NFT

As mentioned earlier, there are three main ways of storing your tokenURI. We will be building a simple API endpoint which resolve in our NFT's information as JSON.

Our Next.js project gives us a handy way to develop API routes. Go to the web/ folder, find the api/ folder within the pages/ folder, and make our dynamic [id].js route in a erc721/ folder (read more about routing here):

// web/pages/api/erc721/[id].js

const metadata = {
  1: {
    attributes: [
      {
        trait_type: "Shape",
        value: "Circle",
      },
      {
        trait_type: "Mood",
        value: "Sad",
      },
    ],
    description: "A sad circle.",
    image: "https://i.imgur.com/Qkw9N0A.jpeg",
    name: "Sad Circle",
  },
  2: {
    attributes: [
      {
        trait_type: "Shape",
        value: "Rectangle",
      },
      {
        trait_type: "Mood",
        value: "Angry",
      },
    ],
    description: "An angry rectangle.",
    image: "https://i.imgur.com/SMneO6k.jpeg",
    name: "Angry Rectangle",
  },
  3: {
    attributes: [
      {
        trait_type: "Shape",
        value: "Triangle",
      },
      {
        trait_type: "Mood",
        value: "Bored",
      },
    ],
    description: "An bored triangle.",
    image: "https://i.imgur.com/hMVRFoJ.jpeg",
    name: "Bored Triangle",
  },
};

export default function handler(req, res) {
  res.status(200).json(metadata[req.query.id] || {});
}

For the sake of this project, I made the code as easily understandable as possible. This is definitely not suited for production (please don't use an Imgur url for your NFT). Make sure to define the metadata for all the NFTs that you intend to mint.

Now, go to the web directory, and start your Next.js app with this command:

npm run dev

Your app should be running on localhost:3000. To make sure our endpoint works, go to http://localhost:3000/api/erc721/1 and it should resolve with a JSON object of your first NFT's metadata.

How to Expose the Metadata for our NFT

Since your app is hosted locally, other apps cannot access it. Using a tool like ngrok, we can expose our local host to a publicly accessible URL.

1. Go to ngrok.com and complete the registration process
2. Unzip the downloaded package
3. In your terminal, make sure you cd into the folder where you unzipped your ngrok package
4. Follow the instruction on your dashboard and run

./ngrok authtoken YOUR_AUTH_TOKEN

5. Then, run this command to create a tunnel to your web app hosted on localhost:3000

./ngrok http 3000

6. You are almost there! On your terminal, you should see something like this:

ngrok by @inconshreveable                                                                            (Ctrl+C to quit)

Session Status                online                                                                                 
Account                       YOUR_ACCOUNT (Plan: Free)                                                                       
Version                       2.3.40                                                                                 
Region                        United States (us)                                                                     
Web Interface                 http://127.0.0.1:4040                                                                  
Forwarding                    http://YOUR_NGROK_ADDRESS -> http://localhost:3000                             
Forwarding                    https://YOUR_NGROK_ADDRESS -> http://localhost:3000

Go to YOUR_NGROK_ADDRESS/api/erc721/1 to make sure your endpoint works correctly.

How to Deploy our NFT

Now that we have done all the ground work (oof), let's go back to our ethereum/ folder and get ready to deploy our NFT.

Change the _baseURI function in your ethreum/contracts/YOUR_NFT_NAME.sol file to return your ngrok address.

// ethereum/conrtacts/EmotionalShapes.sol

contract EmotionalShapes is ERC721 {
...
    function _baseURI() internal pure override returns (string memory) {
        return "https://YOUR_NGROK_ADDRESS/api/erc721/";
    }
...
}

To deploy our NFT, we will first need to compile it using Hardhat. To make the process easier, we will install ethers.js.

npm install @nomiclabs/hardhat-ethers --save-dev

Let's update our hardhat.config.js:

require("dotenv").config();
require("@nomiclabs/hardhat-ethers");

module.exports = {
  solidity: "0.8.0",
  defaultNetwork: "ropsten",
  networks: {
    hardhat: {},
    ropsten: {
      url: process.env.DEV_API_URL,
      accounts: [`0x${process.env.PRIVATE_KEY}`],
    },
  },
};

To learn more about the hardhat configuration file, take a look at their documentation. We have configured the ropsten network with our Alchemy URL and provided it with the private key of your metamask account.

Finally, run:

npx hardhat compile

This lets hardhat generate two files per compiled contract. We should see a newly created artifacts/ folder that contains your compiled contracts in the contracts/ folder. To learn more about how that works, read this tutorial by the Hardhat team.

Now, let's write a script to finally deploy our NFT to the test network. In your scripts/ folder, create a file called deploy.js.

// ethereum/scripts/deploy.js

async function main() {
  const EmotionalShapes = await ethers.getContractFactory("EmotionalShapes");
  const emotionalShapes = await EmotionalShapes.deploy();

  console.log("EmotionalShapes deployed:", emotionalShapes.address);
}

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

This code is inspired by the hardhat deployment tutorial.

A ContractFactory in ethers.js is an abstraction used to deploy new smart contracts, so EmotionalShapes here is a factory for instances of our token contract. Calling deploy() on a ContractFactory will start the deployment, and return a Promise that resolves to a Contract. This is the object that has a method for each of your smart contract functions.

How to view the NFT on the blockchain

Run the deployment script:

node ./scripts/deploy.js

You should see in your terminal EmotionalShapes deployed: SOME_ADDRESS. This is the address where your Smart Contract is deployed on the ropsten test network.

If you head over to https://ropsten.etherscan.io/address/SOME_ADDRESS, you should see your freshly deployed NFT. Yes! You did it!

If you are stuck somewhere in the tutorial or feeling lost, again, you can join our live workshops where we will build this project together in a Zoom call.

How to Mint your NFT

Now that you have deployed your NFT, it's time to mint it for yourself! Create a new file called mint.js in your scripts/ folder. We will be using ethers.js to help us.

Start by adding the ethers.js package:

npm install --save ethers

Then, populate the mint.js file:

require("dotenv").config();
const { ethers } = require("ethers");

const contract = require("../artifacts/contracts/EmotionalShapes.sol/EmotionalShapes.json");
const contractInterface = contract.abi;

// https://docs.ethers.io/v5/api/providers
const provider = ethers.getDefaultProvider("ropsten", {
  alchemy: process.env.DEV_API_URL,
});

// https://docs.ethers.io/v5/api/signer/#Wallet
const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

//https://docs.ethers.io/v5/api/contract/contract
const emotionalShapes = new ethers.Contract(
  YOUR_NFT_ADDRESS,
  contractInterface,
  wallet
);

const main = () => {
  emotionalShapes
    .mint(process.env.PUBLIC_KEY)
    .then((transaction) => console.log(transaction))
    .catch((e) => console.log("something went wrong", e));
};

main();

I have left comments to where you can find more information about the different methods. We first grab the contract's interface (ABI). From ethereum.org:

An application binary interface, or ABI, is the standard way to interact with contracts in the Ethereum ecosystem, both from outside the blockchain and for contract-to-contract interactions.

Your ABI defines how others interact with your contract. Then, we created our provider with Alchemy (remember about node-as-a-service). Finally, we initialize our wallet with our private key.

The main() function calls the mint method in the Smart Contract we had just deployed. The mint method takes only one parameter, to, which indicate the receiver of the token. Since we are minting for ourself, we put the public address of our Metamask account.

If everything goes well, you should see the transaction logged in your terminal. Grab the hash property and go to https://ropsten.etherscan.io/tx/YOUR_HASH. You should see the minting transaction there!

How to View the NFT in your Metamask Wallet

You need to start by downloading the mobile version of Metamask. Then, log into your account.

You should see an NFTs tab along with an add NFT button. Click on the button and enter the address of your Smart Contract along with the ids that you have minted. If you have followed the tutorial, you should start with an id of 1.

View NFTs in your Metamask wallet

Conclusion

Congratulations! You have just minted your own NFT. In the next part of the project, we will be building the front end React app to interact with our contract. The end goal is to build a fully functional web app where you can sell your own NFTs.

Lastly, you can join our live workshops with volunteers from freeCodeCamp where we will build this project together with other developers.

The events are free for everyone across the world and invitations are sent first-come, first-serve. If you'd like to lead the workshops, DM me on Twitter, we'd love to have you! We also organize other type of events like hiring fairs and social meetups.

Let me know what you want to build. NFTs are still in its infancy and novel ideas are more than welcome. Can't wait to see what crazy idea you have!

I first had what I can only describe as a spiritual awakening about 10 years ago to the fact that technology would (figuratively) rule the world. And since then, I've been obsessed with wanting to understand how software works and how to build it.

Since that moment, my life has changed significantly for the better. I can only attribute it to the simple fact that I have relied not only on my own instincts, but on those of people much smarter and more experienced than I am.

My hypothesis is this: try to find and follow the lead of those who have exhibited a long track record of success, find interests in their wake, and do my best to excel at them (while continuing to explore my own curiosities).

This approach has led me to try and master JavaScript, and then React, and finally to build a successful consultancy. All this ultimately landed me on a team at AWS in a life changing experience that lasted a little over 3 years. All of this with no high school diploma or college degree.

During this time (like many developers) I've relentlessly dived into books, podcasts, blog posts, YouTube videos, and source code of every kind. But there has always been a topic that has captured my curiosity the most – futurism.

Futurists like Gerd Leonhard and Michio Kaku speak of a future that's sometimes beautiful and sometimes bleak. But it's always with the passion and phrasing that make your thoughts wander and move past the current moment in time and into a mind boggling world that does not yet exist.

I recently had another "aha" moment, similar to my technological awakening, that has completely changed the direction of my career and my life. In the spirit of these futurists, I want to talk about why Web3 excites me just as much as their ideas, but is instead happening as we speak.

Why is Web3 So Exciting?

This post is meant to dive more into what I think are the benefits and repercussions of Web3. If you want to know my interpretation of what Web3 is, see my thoughts here.

Web3 represents a handful of ideas which together bring about entirely new mental models, organizational structures, and community incentives. These force us to rethink many things that we have become accustomed to.

All of the recent innovation happening is possible because of decentralized protocols. The internet itself has thrived because of native internet protocols that we use everyday, like HTTP, FTP, TCP, and SSH.

One of the reasons these protocols have been so successful was that they were widely adopted and not subject to change. If I build a site using HTTP, people can use it without any centralized intermediary – we can trust that it is going to work.

There are two major pieces of native functionality that have been left out up until recently – payments and state.

Blockchains have enabled both of these things, opening the door for programmable money and state without the need of a centralized server, bank, or any intermediary at all.

Web3 Enables Ownership

One of the driving forces and the one that resonates with most people (and me) is that Web3 enables ownership.

Gaming

At some point the internet and gaming became almost indistinguishable. Not only because most games continue to receive updates over time, but the most popular ones are often the most interactive ones.

Fortnite took a lot of people by surprise because it created an innovative new combination of gameplay, peer-to-peer connection, and a unique business model – and everyone gets the game for free.

The experience is very interactive, you can join old friends and make new ones, there are constant improvements and enhancements that just happen automatically – the game is consistently evolving.

The monetization strategy was also innovative. Fortnite allows players to buy in-game currency as well as skins that they can wear in the game. If you have a child you know that the $65 you may have spent on the game itself is probably peanuts compared to the amount of money kids spend over the lifetime of their gameplay.

The problem, though, is this: when the player decides to stop playing the game or outgrows it, where has all that money gone? More importantly, who is allowed as a creator to benefit from all of the purchasing power? The answer is, well, Fortnite (the platform).

What if, instead, players retained ownership of their items and were able to keep or sell them? Their items would maintain, increase, or decrease in value like any physical asset.

These types of experiences and communities are now being made possible via NFTs. NFTs enable scarcity in a world where there was in the past no scarcity.

Axie Infinity is an example of how this looks in practice. It is a blockchain-based game that is the most successful of its kind, and has recently had explosive growth, catapulting it to over $1 billion in sales with over $780 million in the 30 days ending August 10 2021.

Parallel is an online card game that has done over $100 million in sales and is still extremely early. Dark Forest enables players to get paid to play the game.

When players realize they can retain much of the value of their time and investments while still enjoying the benefit of the game, it changes the way they view gaming and where they spend their money. But it also aligns new incentives around the game itself. If the game succeeds, they can share in that success, therefore they become even more invested.

The combination of ownership, community, and creators who have built audiences creates a whirlwind of new and exciting opportunities that we are just starting to begin see explored.

Ryan Watt, the head of YouTube gaming agrees.

Social media and art

Social media platforms were revolutionary. They allowed anyone from almost any background the ability to grow and foster large audiences using tools that were made free to anyone with a device and an internet connection.

There are no gatekeepers to becoming famous on social media as there have been in the past in film and TV. The intermediary was abstracted away and peer to peer connections and content sharing was made possible.

The flaw in these implementations is that they offer a terrible monetization system, not just for the platform but for the creator as well.

Advertising and the exploitation of user data is the go to play. Also almost all of the money generated by the platform, goes to the platform – the platform monetizes the content being created by its users in exchange for use of the platform itself. This is how social media works today.

In Web3, both creators and the community are able to gain and retain ownership within a platform, creating a synergy that, once experienced, makes the legacy interactions of the past seem archaic and undesirable.

When I say ownership, I don't only mean ownership of content, but actual equity as well.

We are seeing the beginnings of this in the art world of Web3. Artists who were, in the past, often barely making it are now able to leverage their platforms, often in collaboration with other community members or causes. They can create projects that leverage NFT collections to give community members as well as the public a way to participate and distribute equity all around. Art and code are also beginning to overlap.

Projects like Generative Masks allow talented creators like Takawo Shunsuke to leverage the skills he's acquired throughout his career to generate over $3 million in sales for his collection in just a few minutes. He's able to spread awareness for himself and his cause, and create another new community (of owners) simultaneously.

The best part is that he's giving it all back to the communities he's benefited from. On top of that, smart contracts allow him to programmatically enable a commission for any future sale that happens going forward, and in just a couple of weeks that amounts to another $600,000.00+.

Generative art itself is an emerging category that combines code and creativity and is something that could alone warrant an entire post. But it suits the coming era particularly well, as it enables artists to scale their creativity, community, and distribution.

There will continue to be a larger and larger percentage of digital artists because they can use powerful tools and programs to create art that can then be used in an infinite number of ways. They can then put it for sale on an international, 24 hour, liquid market.

OpenSea, the top online art marketplace today, has seen an absolute explosion in growth the past few months.

Even recently surpassing Etsy in sales.

Whether this type of volume continues, I have no idea. My guess is that there will be some volatility and fairly large swings both up and down. But there is definitely something there.

Most of these NFT projects are launched on Ethereum. Ethereum is soon merging a new consensus mechanism that will make NFTs orders of magnitude more environmentally friendly as a means of sales and transfer of art, which in the past all required ground transportation.

Future of social media

As it stands today, users of social media platforms can begin leveraging Web3 tools, communities, and platforms to begin monetizing their audience.

I believe there will be a breakthrough app that will disrupt social media as we know it built in the in the next 1 - 3 years that blends all of these ideas together in a way that we haven't experienced yet.

Many people have echoed a similar sentiment. Aave, a very successful DeFi protocol built on Ethereum, has already begun work on a decentralized version of Twitter:

Jack Dorsey of Twitter is also working on a Decentralized version of Twitter, though I believe that this type of application will ultimately come from the community or a DAO.

DAOs, grants, community ownership, and social tokens

DAO stands for Decentralized Autonomous Organization. You can read about what a DAO is here, here, and here, but I want to focus on how DAOs will play a part in the new creator economy.

Shared ownership is a characteristic you'll see carried across all areas of Web3, including how we think about companies and incentive structures around how business is done.

In Web2 companies, cash usually comes from investors and there is no value returned to them for years. Ownership is largely concentrated in the first handful of employees along with their investors.

It usually takes years to reach a point where investors or employees with equity can begin to see any return on their investment and time spent, often through the old ways of advertising and exploitation of user data.

Web3 and blockchains bring about entirely new business models, made possible by tokenization and cryptoeconomic protocols.

There are quite literally countless ways that these tokens are being utilized to create new ways of collaboration and building, ranging from DAOs to web infrastructure to micro-economies:

PartyDAO which created over $200,000 in revenue in its first day, was "built in 3 months by a small group of internet friends working part-time", and is backed by a smart contract

Compound, a decentralized finance protocol that allows you to lend and borrow cryptocurrency without trusting a third party with your funds has a market cap of over $2 billion as of this writing

Super Rare is a digital art platform that recently launched a token, airdropping as much as $140,000 to its earliest users

Gitcoin is a platform that enables developers to get paid for working on open source projects

Graph Protocol is a decentralized web infrastructure protocol that allows developers to build APIs to enable the performant querying of blockchain data, all enabled by its native utility token

Seed Club is a social token incubator that’s focused on helping creators launch and grow social tokens

Friends with Benefits is a social DAO and community that I'm part of that is 100% owned and governed by the participants

PleasrDAO allows investors to come together to purchase high-value non-fungible tokens like this piece from Edward Snowden.

Most DAOs have desirable grants programs, enabling developers and other participants to work with various teams and projects at their will, on things they find interesting or that fit their skill set.

There are more and more people beginning to work full time for grants and with DAOs vs traditional full time employment.

Conclusion

If this sounds like something you're interested in being involved in, I'd suggest that you jump right in. Try P2E (play to earn), get involved with a DAO, or even mint your own NFT.

Also check out How to Get into Crypto, Ethereum, and Web3 as a Developer which is what I put together after getting my own start in the space.

If you want to learn more about these ideas, I encourage you to follow some of the people I mention in this post:

Also, here are some of my favorite articles that touch on some of the stuff I've outlined here:

The Rise of Micro-Economies

The Creator Economy: Today Vs. 2025

The Value Chain of the Open Metaverse

The DAO of DAOs

Thanks to Aditi for helping me with ideas and edits as I was getting this across the finish line 🙏

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.

About four months ago, I switched to Hardhat from Truffle. This cool new kid on the block drastically improved my coding experience. So today I want to share it with my fellow Solidity developers.

In this post, I will walk you through the initial set-up, compilation, testing, debugging, and finally deployment.

At the end of this post, you will be able understand how to deploy an NFT contract to the local network with Hardhat.

The goal of this post is to make you familiar with Hardhat. I won’t talk about how to write a test or Solidity syntax. However, you should be able to follow along without any Solidity knowledge if you know how to write JavaScript.

See this repo for the code.

How to Set Up the Project

Let’s start an npm project first:

npm init --yes

Then install the Hardhat package:

npm install --save-dev hardhat

Cool! Now you are ready to create a new Hardhat project:

npx hardhat

Choose Create an empty hardhat.config.js:

This will create hardhat.config.js in your root directory with the solidity compiler version specified:

/**
 * @type import('Hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.7.3",
};

How to Write and Compile the Contract

All right, we will start writing a simple contract and then we'll compile it.

Make a new Solidity file within a new contracts directory:

 mkdir contracts && cd contracts && touch MyCryptoLions.sol

We'll use the open-zeppelin package to write our NFT contract. So first, install the open-zeppelin package:

npm install --save-dev @openzeppelin/contracts

Here is the contract code we will be compiling:

pragma solidity ^0.7.3;

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

contract MyCryptoLions is ERC721 {
    constructor(string memory name, string memory symbol)
        ERC721(name, symbol)
    {}
}

The first thing you need to do in any solidity file is to declare the compiler version. Then we can import the ERC721 contract (NFT contract) from open-zeppelin just like you do in JavaScript.

Solidity is a contract-oriented language. Just like an object-oriented language, contracts can have members such as functions and variables. In our code, we have only the constructor, which will be called when we deploy our contract.

Our contract inherits the ERC721 and then passes the name and symbol arguments which are going to be passed to the ERC721 contract. They literally decide the name and symbol of your NFT token.

We will pass whatever values we want to name and symbol at the point of deployment.

To compile it, run:

npx hardhat compile

You might get some warnings but we'll ignore them to keep things simple. You should see Compilation finished successfully at the bottom.

You should also notice that the /arfifacts and /cache directories were generated. You don’t have to worry about them for this post, but it’s good to keep in mind that you can use abi in the artifacts if you want to interact with the contract when you build the frontend.

How to Test the Contract

Since smart contracts are mostly financial applications – and they're also hard to change – testing is critical.

We will use some packages for testing. Install with the command below:

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

ethereum-waffle is a testing framework for smart contracts. chai is an assertion library. We'll write tests in waffle using Mocha alongside Chai. ethers.js is a JavaScript SDK for interacting with the Ethereum blockchain. The other two packages are plugins for Hardhat.

Now, let’s make a new directory test in the root directory and make a new file called test.js in it:

mkdir test && cd test && touch test.js

Make sure you require @nomiclabs/hardhat-ethers in the hardhat.config.js to make it available everywhere:

require("@nomiclabs/hardhat-ethers");

Here is a simple test:

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

describe("MyCryptoLions", function () {
  it("Should return the right name and symbol", async function () {
    const MyCryptoLions = await hre.ethers.getContractFactory("MyCryptoLions");
    const myCryptoLions = await MyCryptoLions.deploy("MyCryptoLions", "MCL");

    await myCryptoLions.deployed();
    expect(await myCryptoLions.name()).to.equal("MyCryptoLions");
    expect(await myCryptoLions.symbol()).to.equal("MCL");
  });
});

This code deploys our contract to the local Hardhat network and then checks if the name and symbol values are what we expect.

Run the test:

Awesome, it passed the test!

How to Use console.log() in Hardhat

Now here is the coolest thing you can do with Hardhat. You can use console.log() just like you do in JavaScript, which was not possible before. console.log() alone is more than enough reason to switch to Hardhat.

Let’s go back to your solidity file and use console.log().

pragma solidity ^0.7.3;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "hardhat/console.sol";

contract MyCryptoLions is ERC721 {
    constructor(string memory name, string memory symbol) ERC721(name, symbol) {
        console.log("name", name);
        console.log("symbol", symbol);
        console.log("msg.sender", msg.sender); //msg.sender is the address that initially deploys a contract
    }
}

And run the test again with npx hardhat test. Then the command will compile the contract again, and then run the test. You should be able to see some values logged from the contract.

This makes debugging a lot easier for you.

One caveat is that it supports only these data types:

• uint
• string
• bool
• address

But other than that, you can use it as if you are writing JavaScript.

How to Deploy the Contract

All right! Now let’s deploy our contract. We can deploy our contract to one of the testing networks, the Mainnet, or even a mirrored version of the Mainnet in local.

But in this post, we will deploy to the local in-memory instance of the Hardhat Network to keep things simple. This network is run on startup by default.

Make a new directory called scripts in the root directory and deploy.js in it.

mkdir scripts && cd scripts && touch deploy.js

Here is the deploy script. You deploy along with constructor values:

async function main() {
  const MyCryptoLions = await hre.ethers.getContractFactory("MyCryptoLions");
  const myCryptoLions = await MyCryptoLions.deploy("MyCryptoLions", "MCL");

  await myCryptoLions.deployed();

  console.log("MyCryptoLions deployed to:", myCryptoLions.address);
}

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

You might want to remove console.log() before you deploy. And then run this deploy script with:

npx hardhat run scripts/deploy.js
MyCryptoLions deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3

Boom! Now your NFT contract is deployed to the local network.

You can target any network configured in the hardhat.config.js depending on your needs. You can find more about configuration here.

Wrapping Up

Hardhat has some other cool features like helpful stack trace, support for multiple Solidity compiler versions, a robust Mainnet forking, great TypeScript support and contract verification in Etherescan. But that’s for another time!

In the cryptoverse, a lot of attention is laid on Bitcoin. But don't let that overshadow the growing interest in Ethereum, which is revolutionizing the way we think of applications.

So, what is a Dapp? A Dapp, or decentralized application, is a software application that runs on a distributed network. It's not hosted on a centralized server, but instead on a peer-to-peer decentralized network.

Alright, that's the short version, but there's a lot more to unpack. Let's dive into the world of Dapps, more specifically those built on the Ethereum protocol.

What is Ethereum?

To understand what a Dapp is, you first need to understand what Ethereum is. Now, there are other protocols that are used to build Dapps, like EOS, NEO, Stellar, Tron, and Cardano, but the big dog is Ethereum.

Ethereum is a network protocol that allows users to create and run smart contracts over a decentralized network. A smart contract contains code that runs specific operations and interacts with other smart contracts, which has to be written by a developer. Unlike Bitcoin which stores a number, Ethereum stores executable code.

So, why should you care?

Because Ethereum removes the need for a third party to handle transactions between peers. Since the middle man is replaced by code, all kinds of costs are reduced, including time and money.

Just like Bitcoin removes the need for someone to hold your money, Ethereum removes the need for someone to broker a deal.

Now you might be wondering, where are all these smart contracts? Well, they're essentially hosted on multiple computer nodes all across the world.

These nodes contain all of the information of all the world's smart contracts, including code, transactions, etc. They're constantly working to keep this information up-to-date so they all have the exact same copy. This what makes smart contracts, and cryptocurrencies in general, decentralized.

And since all of the nodes have the same information and are spread across the world, the removal of a node won't interrupt the execution of any smart contract. Redundancy ensures uptime.

What is a Dapp?

Now that we have a good idea of what Ethereum and smart contracts are, we can start diving into the details of what a Dapp is.

Just to be clear, a Dapp is just like any other software application you use. It could be a website or an app on your phone. What makes a Dapp different than a traditional app is that it's built on a decentralized network, like Ethereum.

When you're creating your own Ethereum smart contracts, you're actually writing a piece of the backend code for your Dapp. And while your Dapp will have a user interface like a traditional app, either all or part of the backend is built on top of Ethereum.

Dapp = frontend + smart contract backend

This backend code is written in an Ethereum-specific language, including Solidity (the most popular), Serpent, and Vyper. Below is an example of a simple "Hello World" contract written in Solidity.

pragma solidity ^0.4.22;

contract helloWorld {
 function printHelloWorld () public pure returns (string) {
   return 'Hello World!';
 }
}

If the smart contract is deployed onto Ethereum's mainnet (i.e., production) or even a local testnet, your Dapp can execute the code in the smart contract by calling the function printHelloWorld().

But what about the frontend? Is there any specific language you need to use for your Dapp?

Nope! You can use whatever frontend language/framework you want. But it is possible to host your frontend code on decentralized storage nodes to make both your frontend and backend decentralized.

Take a look at technologies like Swarm and IPFS to learn more about decentralized storage.

OK, so Dapps are just applications that have some or all of their backend decentralized and possibly even have a decentralized frontend. Why should you care?

The development of Dapps is another step toward a future of the Internet that's commonly referred to as Web 3.0.

Ethereum Dapps: The Backbone of Web 3.0

Since the creation of the Internet, the amount of information and human interaction has exploded. We're able to produce and consume information at near infinite levels.

Unfortunately, the ability to control this information has become heavily centralized over time. This includes information about your social life, health, finances, and much more. Those who control this information are the ultimate owners of it and can use it as they see fit.

These are essentially middle men that hold your information on their centralized servers so they can provide you with services, like holding your money, hosting you website, connecting with family and friends, etc. And at the push of a button, they can completely remove you from accessing this (your?) information and all related services.

This is a monopoly on the information you produce and consume as well as the services you use. Thankfully, Web 3.0 changes all of that and Ethereum Dapps are playing a central role.

Web 3.0 is a lot of things, but at its core is a technology based on decentralization. By decentralizing information and services, large corporations and governments won't be able to control users of the Internet through monopolistic, authoritarian tactics.

Ethereum Dapps, with their ability to decentralize information and services, gives Web 3.0 a platform to deliver a completely free (as in freedom) and accessible Internet for everyone. No longer will there be a central point of control because there won't be middle men to facilitate the flow of information and services.

Some of the most promising Ethereum tokens and Dapps are laying the foundation for the future of the Internet, including:

• Basic Attention Token (BAT): used to improve privacy and value transfer between users, publishers, and advertisers. Used in the Brave browser.
• Golem (GNT): used to run code on one or many distributed compute nodes.
• Minds: a social media platform that improves value transfer between content creators and consumers.
• TokenSets: used to manage cryptocurrency assets via tokenized automated asset management strategies.
• Aave: used to earn interest on cryptocurrency deposits and borrow cryptocurrency assets.
• IDEX: a decentralized cryptocurrency exchange.

Closing Thoughts

Since the creation of Bitcoin, the first cryptocurrency, there's been a massive growth in the cryptoverse.

Being able to store data in a decentralized way was a necessary stepping stone to the decentralization of code execution. With Ethereum, it's now possible to deploy smart contracts across the world to power the backend for existing and future Dapps.

And as more and more Dapps are launched, we'll get closer and closer to a more free, fair, and accessible Internet.

I’m Grant and I’m a freelance SEO and content professional. If you’re looking to grow your brand's organic search traffic, I can help with your fintech SEO. Cheers!

Blockchain is almost always used instead of the terms Bitcoin and cryptocurrency. And there are many other places this technology can be used. We are beginning to barely scratch the surface of it.

With all the hype around it, we know that the Blockchain Technology (BlockTech) is going to be huge. But what makes it unique?

In this article, we are going to explore the key characteristic features of BlockTech.

Decentralized System

Blockchain is a Decentralized Technology, by design.

When something is controlled by a central authority, where the power to make decision lies in the hands of the apex of the management, such system is called a Centralized System. Banks, for example, are a centralized system, where it’s the responsibility of the Governor to make decisions.

On the contrary, when the power is vested in the hands of the people or the users, such system is said to be a Decentralized System. The peer to peer network, Torrent, for example is a decentralised system, where the user has complete control.

Distributed Ledger

Blockchains use distributed Ledger Technology (DLT) to store and access the data around.

When something is stored on a Distributed Ledger, multiple copies of it are made across the network at the same time. Unlike traditional databases, distributed ledger do not have a central database or administration functionality.

When applied in a decentralized system like Blockchain, each user has a copy of the ledger and participates in the transaction verification. This gives Blockchain the property of Immutability and ensures security. Since, the data is distributed, there is no centralized version of the data for the hackers to corrupt. The data and the records are public and easily verifiable. This also eliminates single point of Failure.

Secure Ecosystem (Cryptographic Hash)

BlockTech uses the concepts like Proof of Work and Hash encryption to ensure security and immutability. Proof of work involves several people around the world using computational algorithm to try and find the appropriate hash value that satisfies a predefined condition regarding the hash value.

Mining

Torrent is a peer-to-peer decentralised network used to share files. BlockTech uses similar technology. What differentiates the users is that, in Torrent, the system relies on the honor code of the users to seed the files. Whereas, in blockchain, the users who are involved in the transaction have economic incentives. These users are called “Miners.” The Miners spend their computing resources to solve the cryptographic hashes and ensure immutability and reliability of the transaction. Every successful solution (decryption) ensures some economic benefit.

Chronological and Time stamped

Blockchains, ideally, are just very sophisticated linked lists where each block is a repository that stores information pertaining to a transaction and also links to the previous block in the same transaction. These blocks are arranged in an order and are time-stamped during creation to ensure a fair record.

Consensus Based

Consensus Based is an approach to decision making. It is a creative and dynamic way of reaching agreement between all members of a group. A transaction on Blockchain can be executed only if all the parties on the network unanimously approve it. It is however, subjected to alterations to suit various circumstances.

More info about Blockchain:

• What is the Blockchain and how does it work?
• Technical primer to Blockchain and Ethereum
• Learn the Solidity programming language in 2 hours
• Build your first blockchain app with this free course
• The most popular programming languages for blockchain development

You'll learn how to build 5 Ethereum Dapps. For each of them, this course demonstrates how to:

• develop smart contracts,
• test smart contracts,
• and build a web frontend to interact with the smart contract.

The course covers:

• The architecture of Dapps
• Solidity, the programming language for Ethereum smart contract
• Remix, the online IDE for Solidity
• Truffle, the framework for Solidity smart contracts
• Ganache, the local development Blockchain
• Web3, the JS library to integrate a Dapp frontend
• Metamask, the Ethereum wallet used by most Dapps (browser extension)
• Deployment to public testnet (Ropsten) and mainnet, using Infura API

Watch the full course below or on the freeCodeCamp YouTube channel (5 hour watch).

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).

Article Highlights:

• How to store private keys on the back end without security concerns
• How to properly design smart contracts and what to “decentralize”
• Decentralized and semi-centralized applications architecture examples
• How to deal with low-level stuff like network load and failures

It’s going to be big, let’s do it!

Decentralized Programs and Blockchain

Despite the fact that blockchain is facing a lot of adoption and regulation difficulties today, it’s a kind of technology which is here to stay, whether it’s blockchain, hashgraph, tempo or any other distributed ledger technology still to come, regardless of the algorithm.

The main value that blockchain and other similar technologies bring can be generalized as follows: they allow people to write and run programs which, practically, cannot be changed after creation nor tampered with during execution. In other words, these programs always run as designed, and no single party can influence their behavior.

This definition is valid for many cryptocurrencies that exist today if we consider them as programs that define how coins can be transferred back and forth. This also explains why cryptocurrencies and many kinds of tokens have real value: they cannot be generated out of thin air, by their defined “underlying programs”.

Ethereum/EOS/Tron/… platforms, in contrast to Bitcoin, implement a more complex program layer, which in turn implements the execution environment allowing anyone to write their own decentralized programs on top of the platform. This user-defined programs always run as designed, without any exceptions, and their security is guaranteed by the platform.

Decentralized Applications

These secure and unchangeable programs running on a decentralized network in combination with traditional front-end and back-end technologies are what we call decentralized applications (ÐApps) today. Through some of them can be semi-centralized, a major part of activities in the truly decentralized application should happen out of a central party’s control.

If someone asked me to draw how DApps work today, I would probably have drawn this

To imagine what we call decentralized applications today, take any existing centralized web resource like YouTube or Instagram as an example and imagine that instead of a password-protected centralized account you have your “crypto identity” bound to the web/mobile resource.

That’s what Wallet Software provides you. The private key from this identity (a secret, having which, you can act on behalf of this identity) is stored on your local device and never goes online, making no one able to control this identity but you. With this identity, you can perform different actions in both centralized (web resource controlled by a central authority) and decentralized (which is a different network from the traditional www, the goal of which is to eliminate the central authority) networks, using the website as an access point and/or as a graphical user interface. The whole point of this “crypto identity” is that your actions are cryptographically secured, and no one is able to change what have you signed nor your signature.

Today, the computational and storage capabilities of fault-tolerant decentralized networks like Ethereum, EOS or Tron are limited. If they were scalable, we could use decentralized networks to store the whole decentralized application, including its graphical user interface, data and business logic. In this case, we would call these applications truly decentralized/distributed.

However, because those networks are not scalable today, we combine different approaches to achieve the maximum decentralization level for our applications. The “traditional” back end as we know it isn’t going anywhere. For instance:

• We use back end to host front end for a decentralized application.
• We use back end for integrations with any other existing technologies and services. Real, world-class applications cannot live in an isolated environment.
• We use back end to store and process anything big enough for a decentralized network (blockchain in particular). Practically, the whole application and its business logic are stored somewhere in the world, excluding the blockchain part only. Not to mention, IPFS and similar storage layers cannot guarantee the accessibility of files, hence we cannot rely on them without hosting the files ourselves either. In other words, there’s always a need for a dedicated running server.

There’s no way of building a secure and partially decentralized application without using a solid back end as of today, and the whole point of this article is to explain how to do this right.

(De)centralization and Tokens

It so happens that almost all decentralized applications today are built around so-called tokens — custom-built (or just simply cloned) cryptocurrencies that drive a particular decentralized application. Tokens are simply a programmable currency or assets, that’s it.

While token smart contracts determine how users can transfer tokens, application smart contracts can extend everything missing in token smart contracts. Both smart contracts run on top of decentralized networks

Usually, a token is a “smart contract” (a custom program) written on top of the decentralized platform like Ethereum. By owning some tokens you are basically able to get different services on a web resource or mobile app, and trade this token for something else. The key point here is that the token lives on its own and it is not controlled by a central authority.

There are many examples of applications that are build around tokens: from numerous collectible games like CryptoKitties (ERC721 tokens) to more service-oriented apps like LOOM Network, or even browsers like Brave and gaming platforms like DreamTeam (ERC20-compatible tokens).

Developers themselves determine and decide how much control they will (or won’t) have over their applications. They can build the whole application’s business logic on top of smart contracts (like CryptoKitties did), or, they can make no use of smart contracts at all, centralizing everything on their servers. However, the best approach is somewhere in the middle.

Back End for Decentralized Networks

From a technical point of view, there has to be a bridge that connects tokens and other smart contracts with the web/mobile application.

In today’s fully decentralized applications, where clients interact with smart contracts directly, this bridge is narrowed down to a JSON RPC API capabilities of public APIs or node pools like Infura, which in turn are forced to exist because of the fact that not every device can run and support its individual network node. However, this API provides an only basic and very narrow set of functions, which barely allow making simple queries nor efficiently aggregate data. Because of this, eventually, custom back end kicks in, making the application semi-centralized.

The whole interaction with the decentralized network can be narrowed down to just one or two points, depending on the application needs:

1. Listening to the network events (like token transfers) / reading the network state.
2. Publishing transactions (invoking state-changing smart contract functions like token transfer).

Implementing both of these points is quite tricky, especially if we want to build a secure and reliable back-end solution. Here are the main points which we are going to break down below:

• First of all, in Ethereum, events retrieval is not production-ready out of the box. Because of multiple reasons: network nodes can fail while fetching a large number of events, events can disappear or change because of network forks, etc. We have to build an abstraction layer to sync events from the network and guarantee their reliable delivery.
• The same for transaction publishing, we have to abstract Ethereum’s low-level stuff like nonce counters and gas estimations, as well as transaction republishing, providing a reliable and stable interface. Moreover, transaction publishing implies using private keys, which requires advanced back-end security.
• Security. We are going to take it seriously and face that it’s impossible to guarantee that private keys won’t ever be compromised on a back end. Luckily, there is an approach to designing a decentralized application without even a need for back-end accounts to be highly secured.

In our practice, all of this made us create a robust back-end solution for Ethereum which we name Ethereum Gateway. It abstracts other microservices from Ethereum’s fun and provides a reliable API to work with it.

As a fast-growing startup, we cannot disclose the complete solution (just yet) for obvious reasons, but I am going to share everything that you need to know to make your decentralized application work flawlessly. However, if you have any specific questions or inquiries, feel free to contact me. Comments to this article are much appreciated as well!

_Back End Monitoring for Ethereum. The monitor demonstrates activities mainly regarding our [recurring billing feature](https://github.com/dreamteam-gg/smart-contracts/blob/master/contracts/token/TokenRecurringBilling.md" rel="noopener" target="blank" title=") (though you can see peaks happening each hour).

Decentralized Applications Architecture

This part of the article highly depends on the needs of a particular decentralized application, but we will try to sort out some basic interaction patterns on top of which these applications are built (ÐPlatform = Decentralized Platform = Ethereum/EOS/Tron/Whatever):

Client ⬌ ÐPlatform: fully decentralized applications.

The client (browser or mobile application) talks to the decentralized platform directly with the help of Ethereum “wallet” software like Metamask, Trust or hardware wallets like Trezor or Ledger. Examples of DApps build in such manner are CryptoKitties, Loom’s Delegated Call, crypto wallets themselves (Metamask, Trust, Tron Wallet, others), decentralized crypto exchanges like Etherdelta and so on.

ÐPlatform ⬌ Client ⬌ Back End ⬌ ÐPlatform: centralized or semi-centralized applications.

The client interaction with the decentralized platform and the server has little in common. The good example of this is any (centralized) crypto exchange today, like BitFinex or Poloniex: the currencies you trade on exchanges are simply recorded in the traditional database. You can “top up” your database balance by sending assets to a specific address (ÐPlatform ⬌ Client) and then withdraw assets after some actions in the app (Back End ⬌ ÐPlatform), however, everything you do in terms of a “ÐApp” itself (Client ⬌ Back End) does not imply your direct interaction with the ÐPlatform.

Another example is Etherscan.io, which uses semi-centralized approach: you can do all useful decentralized actions there, but the application itself just doesn’t make sense without their comprehensive back end (Etherscan continuously syncs transactions, parses data and stores it, ultimately providing a comprehensive API/UI).

Something in between: still, centralized or semi-centralized applications.

The above approaches combined. For example, we can have an application which provides various services in exchange for crypto, allowing you to log in and sign information with your crypto identity.

Hopefully, the interaction pattern of fully decentralized applications (Client ⬌ ÐPlatform) does not raise any questions. By relying on such amazing services like Infura or Trongrid one can simply build an application which doesn’t require a server at all. Almost all client-side libraries like Ethers.js for Ethereum or Tron-Web for Tron can connect to these public services and communicate with the network. However, for more complex queries and tasks, you may need to allocate your own server anyway.

The rest of the interaction patterns which involve back end make things more interesting and complex. To put all these in a picture, let’s imagine a case where our back end reacts to some event in the network. For example, the user publishes an allowance transaction which gives us permission to charge them. To make a charge, we have to publish the charge transaction in response to the emitted allowance event:

An example flow of server’s reaction to the user’s action in the decentralized network

From the back end point of view here’s what happens:

1. We listen to a particular network event by continuously polling the network.
2. Once we get an event, we perform some business logic and then decide to publish a transaction in response.
3. Prior to publishing the transaction, we want to ensure that it will likely be mined (in Ethereum, the successful transaction gas estimation means there are no errors against the current network state). However, we can’t guarantee that the transaction will be mined successfully.
4. Using a private key, we sign and publish the transaction. In Ethereum we also have to determine the gas price and gas limit of the transaction.
5. After publishing the transaction, we continuously poll the network for its status.
6. If it takes too long and we can’t get the status of the transaction, we have to re-publish it or trigger a “fail scenario”. Transactions can be lost for various reasons: network congestion, dropping peers, network load increase, etc. In Ethereum, you can also consider re-signing a transaction with a different (actual) gas price.
7. After we finally get our transaction mined, we can perform more business logic if needed. For example, we can notify other back end services about the fact of the transaction being completed. Also, consider waiting for a couple of confirmations prior to making final decisions regarding the transaction: the network is distributed and hence the result can change in a matter of seconds.

As you can see, there’s a lot going on! However, your application may not require some of these steps, depending on what you are trying to achieve. But, building a robust and stable back end requires having a solution for all the problems mentioned above. Let’s break this down.

Decentralized Applications Back End

Here I want to highlight some of the points which arise most of the questions, namely:

• Listening to network events and reading data from the network
• Publishing transactions & how to do it securely

Listening to Network Events

In Ethereum, as well as in other decentralized networks, a concept of smart contract events (or event logs, or just logs) allows off-chain applications to be aware of what is happening in the blockchain. These events can be created by smart contract developers at any point of the smart contract code.

For example, within the well-known ERC20 token standard each token transfer has to log the Transfer event, thus letting off-chain applications know that there is a token transfer happened. By “listening” to these events we can perform any (re)actions. For instance, some mobile crypto-wallets send you a push/email notification when tokens are transferred to your address.

In fact, there’s no reliable solution for listening to network events out of the box. Different libraries allow you to track/listen to events, however, there are many cases when something can go wrong, resulting in lost or unprocessed events. To avoid losing events, we have to build a custom back end, which will maintain the events sync process.

Depending on your needs, the implementation can vary. But to put you in a picture here is one of the options of how can you build reliable Ethereum events delivery in terms of microservice architecture:

Reliable delivery of Ethereum events to all back end services

These components work in the following way:

1. Events sync back end service constantly polls the network, trying to retrieve new events. Once there are some new events available, it sends these events to the message bus. Upon successful event submission to the message bus, as for blockchain, we can save the last event’s block in order to request new events from this block next time. Keep in mind that retrieving too many events at once may result in always failing requests, so you have to limit the number of events/blocks you request from the network.
2. The message bus (for example, Rabbit MQ) routes the event to every queue which was set up individually for each back end service. Prior to event publishing, events sync back end service specifies the routing key (for example, a smart contract address + event topic), while consumers (other back end services) create queues which are subscribed for particular events only.

As a result, each back end service gets only those events it needs. Moreover, the message bus guarantees the delivery of all events once they are published to it.

Of course, you can use something else instead of the message bus: HTTP callbacks, sockets, etc. In this case, you’ll need to figure out how to guarantee callbacks delivery yourself: manage exponential/custom callback retries, implement custom monitoring and so on.

Publishing Transactions

There are a couple of steps we have to perform in order to publish a transaction to the decentralized network:

1. Preparing the transaction. Along with transaction data, this step implies requesting the network state in order to find out whether this transaction is valid and is going to be mined (gas estimation in Ethereum) and the transaction’s sequential number (nonce in Ethereum). Some of the libraries try to do this under the hood, however, these steps are important.
2. Signing the transaction. This step implies the usage of the private key. Most likely, here you’ll want to embed the custom private key assembly solution (for instance).
3. Publishing and republishing the transaction. One of the key points here is that your published transaction always has a chance to get lost or dropped from the decentralized network. For example, in Ethereum, the published transaction can be dropped if the network’s gas price suddenly increases. In this case, you have to republish the transaction. Moreover, you may want to republish the transaction with other parameters (at least with higher gas price) in order to get it mined as soon as possible. Thus, republishing the transaction can imply re-signing it, if the replacement transaction wasn’t pre-signed before (with different parameters).

The above points regarding Ethereum transaction publishing visualized

By utilizing the above approaches you can end up building something similar to the thing which is presented in the sequence diagram below. On this particular sequence diagram, I demonstrate (in general!) how the blockchain recurring billing works (there’s more in a linked article):

1. The user executes a function in a smart contract, which ultimately allows the back end to perform a successful charge transaction.
2. A back end service responsible for a particular task listens to the event of charge allowance and publishes a charge transaction.
3. Once the charge transaction is mined, this back end service responsible for a particular task receives an event from the Ethereum network and performs some logic (including setting the next charge date).

_The general sequence diagram of how [blockchain recurring billing](https://hackernoon.com/payments-of-tomorrow-decentralized-recurring-billing-47d126d895fd" rel="noopener" target="blank" title=") works, demonstrating the interaction between back-end services and Ethereum network

Back End Security & Smart Contracts

Transaction publishing always involves using a private key. You may be wondering if it is possible to keep private keys secure. Well, yes and no. There are numerous complex strategies and different types of software which allow storing private keys on the back end quite securely. Some private key storage solutions use geo-distributed databases, while others even suggest the use of special hardware. However, in any case, the most vulnerable point of a semi-centralized application is where the private key is assembled and used to sign a transaction (or, in case of special hardware, a point of triggering a transaction signing procedure). Hence, theoretically, there’s no 100% reliable solution which will enable bullet-proof protection from compromising stored private keys.

Now think this way. In many cases, you don’t even need to secure private keys on the back end that often. Instead, you can design smart contracts and the whole application in such a manner that a private key leak won’t affect their usual behavior. With this approach, it doesn’t matter how authorized accounts interact with the smart contract. They’re just “triggering” a smart contract to do its usual job, and the smart contract itself performs any required validation. I call it the “operational accounts pattern”.

Operational accounts pattern for decentralized applications, where you don’t need military-grade security for your back-end accounts

This way, in case of emergency:

• The only thing the attacker can steal is a tiny amount of Ether (as of Ethereum) deposited to the operational accounts for transaction publishing
• The attacker won’t be able to harm the smart contract logic nor anyone who is involved in the process
• Compromised operational accounts can be quickly replaced with other ones, however, this requires either the manual replacement (generating new accounts, and reauthorizing accounts in all smart contracts) or developing an additional solution which will do all the magic with a single transaction from a super-secure (hardware or multi-sig) master account.

For instance, in our recurring billing for Ethereum solution, no matter what happens on a back end, the recurring billing smart contract is designed in such a manner that we have a whole month of time for replacing the compromised accounts if any of them are compromised.

But still, if you want to get your back end private key storage as secure as possible, you can try using Vault with a great plugin for Ethereum which stores and manages Ethereum accounts (also, keep an eye on our open-source modules — we are about to release something similar soon). I am not going to dive deep into the details here, though you can visit the linked projects and learn from there yourself.

This isn’t even all I have to say. However, this article turned out to be much longer than I expected so I have to stop. Subscribe to my Medium / other networks if you’re interested in software, crypto, travel tips or just want to follow something interesting. Hope I’ve provided a big valuable piece of information and you’ll find it useful. Feel free to comment and spread this article!

Installing the Ethereum node client on a machine can be a tedious process. There is a simpler way this can be done using a Docker client. This is a guide for running the GETH (Ethereum-Go) node client from inside a Docker container. GETH is the GoLang implementation of the Ethereum protocol. There is an image available to pull from the Docker hub repository that can run the environment.

The GoEthereum website lists the following available images with descriptions.

• ethereum/client-go:latest is the latest develop version of Geth
• ethereum/client-go:stable is the latest stable version of Geth
• ethereum/client-go:{version} is the stable version of Geth at a specific version number
• ethereum/client-go:release-{version} is the latest stable version of Geth at a specific version family

The following ports are opened by default when running from the container.

• 8545 TCP, used by the HTTP based JSON RPC API
• 8546 TCP, used by the WebSocket based JSON RPC API
• 30303 TCP and UDP, used by the P2P protocol running the network
• 30304 UDP, used by the P2P protocol's new peer discovery overlay

The Docker client software must be installed on the machine you are going to run the container from. Containers can only run if you have the Docker client installed. Depending on your operating system, the correct version of the client will be needed.

There are separate versions for Windows, Linux and the MacOS. The container can even be run on a Linux instance running on AWS, like a typical Linux installation. Once the Docker client is installed, the underlying platform doesn’t matter. The commands will be the same for all.

Getting The Image

Open a terminal on Linux or MacOS, or PowerShell command prompt from Windows. In the CLI prompt, type the following command:

docker pull ethereum/client-go

This pulls the Docker image from the hub repository where it was uploaded by the Ethereum developers. Once you have issued this command, the following verbose or similar should be displayed:

I have already pulled the image, so the verbose may look different. When you issue the pull command it will always download the latest image available, which is good practice.

Running The Node

Now you can start the node by issuing the following command:

We want to run the node with the flag options -i and -t to display information from our container. The -p indicates the use of a port number, in this case 30303. Likewise, the command can be run without the flags and it will simply use the default ports and settings from inside the container.

The following information should appear from the terminal.

The INFO line that shows the config reveals what the node client software has installed. The node client is running the latest (as of this posting) version of the Ethereum software which is Constantinople that is a user activated hard fork at block height 7280000.

When running in JSON-RPC API:

Take note that running the option rpcaddr “0.0.0.0” is not secure, since you are opening up your node to all traffic. If your ETH wallet were unlocked, a hacker can get to your node in this way and take your coins. I don’t cover security in this article, but you can read more about that here (securing your GETH node’s RPC ports). Always abide to safe and best practices.

If the node displays the following in the INFO line, there will be a problem:

config=”{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: Engine: ethash}”

The Constantinople: indicates the software was not updated. There is also no line for ConstantinopleFix, which appears in the correct configuration.

Persistent Data

For persistent blockchain data, Docker data volumes should be used with the option -v. The /path/on/host should be replaced with the location you specify. For this the following command must be used:

Checking Node Status

You can check the container’s status using the following command:

docker ps

This will display the Container ID with the image name, status and ports used.

#These are the commands to run from the Docker CLI to run the Ethereum Go node client

#GETTING THE IMAGE

docker pull ethereum/client-go


#RUNNING THE NODE

docker run -it -p 30303:30303 ethereum/client-go

#RUNNING NODE USING API

docker run -it -p 8545:8545 -p 30303:30303 ethereum/client-go --rpc --rpcaddr "0.0.0.0"

#Note, warning about using --rpcaddr "0.0.0.0" in a live environment. It is an insecure way of opening your node.
#There are different ways to secure your ports, but this is one thing to take note of if you plan to use the API.


#PERSISTENT DATA

docker run -it -p 30303:30303 -v /path/on/host:/root/.ethereum ethereum/client-go

Running GETH from a Docker Container

Take note that this does not automatically mine ETH. That is a different process. For getting quick access to the Ethereum blockchain, this is the purpose for running GETH.

For full code source, visit: https://github.com/Play3rZer0/GETHDocker.git

Here at Daitan we are always looking for new technologies that can help our clients solve their problems more efficiently. Lately one that has captured a lot of our and our clients’ attention is Blockchain.

In this article, our goal is to present a practical way of implementing your own supply chain application based on a blockchain platform!

The system is used for one of the problems where I think applying blockchain gives the highest value: a supply chain.

This application has been explored a lot lately on PoCs and huge companies are already experimenting with that for their operations.

Using blockchain to solve this type of problem is a good alternative because we can benefit from the transparency and efficient provenance tracking inherent to the technology.

Since this article intends to be simple and not a complete project, we will streamline the problem a lot.

At the end, we still have an end-to-end system that can demonstrate the applicability of the technology to this particular set of problems.

Choosing a Platform

Currently there are a lot of platforms that allow you to make your own blockchain or use a public blockchain for your own projects, so we will leverage one instead of building from scratch.

These projects have a lot of backing from players from both enterprises and the open source community, so we believe that using one is the most practical path for the majority of problems, allowing us to focus on the business logic instead of the infrastructure.

For our demo we chose the Ethereum Project. It is a popular platform and all the development tools available make implementation of solutions over it easy to accomplish.

The Manufacturing Story

We have established the domain, but what specifically do we intend to make?
Let’s describe a simple car manufacturing problem and the players involved in the process.

First, we have the parts factory, responsible for producing wheels, body parts, engines and transmissions. The factory informs each part production using the “ProductManagement” smart contract, which will keep details about each part and product.

Additionally, the factory states that it is the owner of a specific part by calling a method from the “ChangeOwnership” smart contract, which will keep the owner history of each part and product.

Going further on the chain, we have a car factory that buys parts from the part factory to manufacture cars. The “ChangeOwnership” contract is where we keep this type of operation, so we have another method to allow the parts factory to transfer the part ownership to the car factory.

With enough parts, the car factory can finally start to manufacture cars. Similar to what the parts factory did to inform its job, the car factory now uses the “ProductManagement” smart contract to state a specific car assembly. Each car has a set of properties, like a serial number, and also has a parts list, that ties cars to specific parts.

The ownership is controlled by the “ChangeOwnership” contract and so the car factory sets that car ownership to itself.

Finally, we add dealers to the scenario and they can buy cars from a factory and the latter can transfer the car ownership using “ChangeOwnership”. The blockchain stores every transaction that involved that car or any of the parts that compose it, so the dealer (or any other part) can track everything that a specific item has gone through. In our case this tracking will be done by watching the events generated by the transactions. This will become clear when we analyze the code.

The complete product flow can be seen in the picture below:

Car Manufacturing Supply Chain

We know what to do, but we still need to arm ourselves with some tools to enable the development.

Environment and Tools

First, we need to make a clear distinction between the networks of the Ethereum ecosystem. The main network (called Mainnet) is where the real apps reside and where each unit of ether has real value.

This mean that everything you record there is bound to exist as long as Ethereum itself exists. Additionally, ether can only be obtained by mining or by buying it with real money.

Using that network to develop demonstrations seems like a bad idea, so there are other networks that are better at supporting development. These networks can be public networks, like the one called Rinkeby, or you can even create your own Ethereum network!

While using a public Test Net like Rinkeby provides us a better way to validate our DApp (Decentralized App), we will create our own network to shorten the transaction acceptance time and simplify the development the most.

The tool we will use to create our network is called Ganache.

Ganache is a simple tool that creates a local Ethereum network and you can connect to it just like you would with the main network. It also provides you with 10 accounts with 100 ether every time you run it.

I like to live on the terminal, so instead of using the Ganache UI, I will use ganache-cli, the command line version of Ganache that is a NodeJS-based tool and can be installed with npm:

npm install -g ganache-cli

To run, just execute ganache-cli and you are good to go! When you run the CLI, it will generate a mnemonic for your wallets. The mnemonic is a 12-word phrase that is the root for generating the account private keys and consequently the wallets.

The output is like the following image:

Save the mnemonic to use later. Whenever you need to run Ganache again you can preserve the same accounts providing the mnemonic with the -m parameter:

ganache-cli -m "now frame tenant chronic oven cube minute immune leaf clock demand volume"

Note: mnemonics created by Ganache are not safe and should not be used for wallets on the Ethereum network

Now that we have our network we need to be able to test and deploy our contracts to it. This is accomplished by another tool called Truffle, part of the same development suite as Ganache. Truffle can also be installed with npm, so just run:

npm install -g truffle

We will use Truffle to prepare our project structure, so run truffle init and check the folder structure that is created:

ethereum-supply-chain|-contracts| — Migrations.sol|-migrations| — 1_initial_migration.js|-testtruffle-config.js

• Contracts: contains the code for our smart contracts
• Migrations: contains the deployment instructions to our contracts
• Test: contains the tests for the contracts
• Truffle-config.js (or truffle.js depending on your O.S.): main configuration file, points to the Ethereum networks that we can deploy to

The configuration file comes with a lot of content, but most of it is commented. To add our local network to the deployment options just uncomment the following part (lines 49–53):

Finally, we need to provide an interface to our users to let them interact with the Ethereum networks.

One of the options for this is to install Metamask, a browser plugin that manages wallets and also enables web systems to speak with the Ethereum networks.

Once installed, Metamask provides an interface to check wallet funds on different networks. Whenever a web system requires an operation that involves payment, Metamask asks for user approval.

To install it, just go to their website and choose the extension to your browser.

After the installation, Metamask needs to create or import a wallet, so choose “import with seed phrase” and paste the mnemonic you got from ganache-cli.

Note: Metamask is currently in beta, so keep that in mind whenever you use it and follow the instructions given after configuration

And that is all we need for now, let’s dive into the code!

Smart Contracts Hands On

The first thing we need to do is to implement the logic behind each of the smart contracts, so we begin with “ProductManagement”.

This contract should have one method for registering parts and another to register products, even if the requirements for each operation are very similar.
We do that because we want to check that all the parts exist when we try to build a new product. So we can have the following methods:

• Part registration: create a mapping given the details of the part itself (type, serial number and manufacturing date), the factory that made it (factory id) and the current owner (owner id).
• Product registration: create a mapping given the same as part registration plus the id of each of the parts present on the product.
• Getters for the mappings so that we can check parts’ and products’ existence and get their details.

The contract code that we need to implement that is:

We define structs for parts and products that map all the information required to “build” our parts and products, and after that we add the mappings that will keep all registered items.

The buildPart method is simple: it uses a helper function to concatenate the sender address and part information on a bytes array and calculate a hash. This hash is the key used when registering and later querying the data, so we return it to aid development.

Since Ethereum transactions are not validated and run when you call the smart contract, we receive a transaction hash and can’t use it for our web app, but we can issue a call instead of a transaction to check the results easily.

In a real system we would expect the manufacturer to provide the part hash with the physical part, but we won’t think about this mechanism here. We know the information used to generate the hash, so we can calculate it when we need, and that is exactly what we do on the testing code and also on the web app.

We won’t cover the test code so that we don’t extend the article, but check it out in our repository!

The buildProduct method is just an extension of the buildPart method, adding a simple check to guarantee that all the parts were registered before attempting to create the product.

Two things are really worth noting about the code:

• Solidity generates getters automatically for public mappings, so we don’t need to worry about that!
• But we need to worry when returning array values, exactly the case for our product parts. We have created a “getParts” function to address this need.

Continuing our development we will code the “ChangeOwnership” contract. It has a simple purpose: manage the part and product transfer between interested parties.

Since we will use IDs on the ownership transfer operation, we can have one method for manufacturers to register their “initial ownership” and another method to change the ownership to other parties.

We just need to receive a parameter to tell us if we want to register parts or products to know which mapping to check on the “ProductManagement” contract and also where to store the current item owner. The code is the following:

We use a “ProductManagement” instance to query for parts and products whenever we try to interact with them. This highlights an important aspect of smart contracts: you can use them to call other smart contracts! One option to do that is to declare the contract ABI on the beginning of the contract file, but just the parts required by your contract. In our case it means:

To point to the correct contract, we just need to pass the contract address when instantiating it, like this:

pm = ProductManagement(prod_contract_add);

Proceeding on the “ChangeOwnership” code review, we can also see that we define two events, TransferPartOwnership and TransferProductOwnership. Events can be logged with transactions, so that will the core of our “tracking” functionality.

Whenever a part or product is successfully transferred to another account, we will emit an event.

Take the addOwnership function as an example: we verify that the item exists, check if it is still unregistered and that the manufacturer is the one asking ownership. If we verify all that, we then store the manufacturer as the part owner and record that on Ethereum as an event. Later, we can query events about that part from its hash and see all the transfers.

The only other point to note about this code is on the function “changeOwnership”: whenever a car changes the owner we also change the ownership of the parts that compose it. But enough about code review, let’s check how to deploy it.

Contract Deployment

To migrate our contracts to Ethereum we need to create a simple deployment file on the “deployments” folder. We can base ourselves on the “1_initial_migration.js” file created by Truffle, so our code becomes:

We can finally deploy our code to our local Ethereum network by running:

truffle migrate -network development

When running that you will probably note that the ganache-cli terminal outputs a lot of messages, including some like:

Transaction: 0x9fe6d2ece9cdca2f12b574ead7abb7bea7feab316f5cd6ebbd5b713e76850a1dContract created: 0xb6a3c3cf9d1e27e43e5fb12e505d79764748edbe

Those represent our contract addresses, so save them to be able to communicate later. We will need this address on our web interface!

Web interface Hands On

Our system now has both smart contracts ready and all we need is the interface to use them.

We made a page for each role on our scenario, so we have a “Part Factory View”, a “Car Factory View” and a “Dealer View”. We won’t get into the specifics of the methods implemented for the interactions, but let’s give an overview to instigate you to check the code!

The part factory interactions, like part registration, ownership addition and ownership transfer, can be performed on the interface shown below. It is interesting to note Metamask asking for permission for every single transaction we make.

Part Manufacturing Interface

Looking at things from a car manufacturer’s perspective, we have the part list populated from the records on the blockchain, then the part selection to assemble the car, the car build, and finally we transfer the ownership to a dealer. Just like a part factory, the car factory also has its own interface, shown below. All interactions with Ethereum use the part/car hash created from their properties.

Car Manufacturing Interface

The final view is from dealers, and for our example that is the simplest: we can just check the cars and parts for the owner history. Check the image below for details:

Dealer View with Owner History for Cars and Parts

Under the hood, we use the web3 library to call our smart contracts’ methods. The library provides us with objects representing our contracts and methods, and for that we only need to set:

• Network location
• Contract ABI (smart contract definition)
• Contract address
• Wallet to use for operations

By default, ganache-cli runs the network on the 8545 port and the ABI is generated every time you compile and deploy your contracts (but only when we update the code, so we don’t need to change that).

If you ever need to, get the value stored on the “build” folder of the setup.
The contract address we must specify with the values saved before, so change the following lines to your values:

Now that we have our page ready to interact with our smart contracts, we just need to prepare the functions that use the objects provided by web3 and our system is complete!

The functions basically get the data from the input fields on the page and then call the functions with them as parameters. The complete code is too big to fit this article, but let’s check just two parts that explain most of the interactions with the blockchain. The first is:

The “window.co” object is our “ChangeOwnership” contract, and both currentPartOwner and addOwnership are methods provided by it.
The difference here is on the function used to call them: call vs send.
Web3 1.0 requires you to specify the type of interaction that you want to do with the blockchain: reads or transactions.

So whenever you use a method with “call” you are just reading data from the blockchain, it costs you no ether and also does not change the chain state.

On the other hand, if you use “send” you have to send gas to perform the operation and it creates a transaction. As we have said before, transactions are not mined immediately, so take that into account when developing real world Dapps.

Finally, the second part to be highlighted is:

Remember when we said that Events would be our supply chain core? This line is used to get all events from a specific type, filtering the results by the part hash.

It means that we can get everything that happened with a single part, and if we want we can also get the part details using the same hash and calling “parts” from “ProductManagement”.

Pretty cool, huh?

Wrapping Up

And we’re done!

Every time a part manufacturer wants to notify a new part production, a car manufacturer wants to assemble that in a car, or we want to move the parts and cars from one owner to another, we can simply use the web interface to do it.

We have a transparent record that allows manufacturers, dealers and buyers to have the same information about the products.

If a problem is found about a certain serial number range in the factories, the factory can check where to tackle and solve the problem.

The same is true in the opposite direction: dealers and buyers can trace back their products’ parts to the factories in case they have problems or need replacements.

Implementing the system based on a blockchain also provides a distributed and consistent record that none of the participants can alter without traces, so we avoid foul play.

We have simplified the supply chain scenario a lot, but we hope that this demo has shown the power of using the blockchain in this context. Now you can start your solution planning and consider it as an implementation alternative.

I hope you enjoyed it!