By the end, you'll have a fully functional MCP server integrated with Claude Desktop in about 10 minutes. This solution applies to any MCP setup facing this standard error after Python upgrades.

Table of Contents

1. What Causes the ENOENT Error?

2. Prerequisites

3. How to Diagnose Your Broken Virtual Environment

4. How to Completely Rebuild Your Virtual Environment

5. How to Install MCP Server Dependencies

6. How to Locate Your Server Files

7. How to Test Your Server Setup

8. How to Configure Claude Desktop

9. How to Restart Claude Desktop and Test Integration

10. Understanding MCP Server Capabilities

11. Alternative Installation Methods

    • Method 1: Direct Package Installation

    • Method 2: Using UV Package Manager

12. How to Prevent Future ENOENT Errors

13. Troubleshooting Common Issues

14. Conclusion

What Causes the ENOENT Error?

The ENOENT (Error NO ENTry) error means your system can’t locate the Python executable at the specified path. This occurs when the file is missing or inaccessible.

On macOS, this typically happens when:

• You've upgraded Python through Homebrew

• The brew cleanup command removed old Python versions

• Your virtual environment's symlinks now point to non-existent files

What makes this particularly challenging is that your virtual environment folder still exists – it looks fine from the outside, but the Python executable inside is completely broken.

When MCP servers try to spawn Python processes using these broken paths, you get the dreaded ENOENT error. This affects any Python-based MCP server, whether you're building custom tools, connecting to APIs, or working with file systems.

Prerequisites

To follow this tutorial, you'll need:

• macOS with Homebrew installed

• Python 3.10 or higher

• An MCP server repository cloned locally

• Claude Desktop installed

• Basic familiarity with terminal commands and Python virtual environments

If you haven't cloned an MCP server repository yet, you can start with any open-source MCP server. For this tutorial, I'll use generic examples that work with any MCP setup:

git clone https://github.com/your-username/your-mcp-server.git
cd your-mcp-server

How to Diagnose Your Broken Virtual Environment

First, you need to confirm that your virtual environment is actually the problem. Open your terminal and navigate to your MCP directory:

cd /path/to/your/mcp-server

Now check if your Python executable exists:

ls -la venv/bin/python*

If you see broken symlinks or get "No such file or directory" errors, you've found your problem. You might see output like:

lrwxr-xr-x  1 username  staff  16 Jan  1 12:00 python -> /usr/local/bin/python3.11
lrwxr-xr-x  1 username  staff  16 Jan  1 12:00 python3 -> /usr/local/bin/python3.11

But when you try to run these Python executables:

./venv/bin/python --version

You'll get an error because the target files no longer exist. This confirms your virtual environment is broken and needs rebuilding.

How to Completely Rebuild Your Virtual Environment

The most reliable solution is to rebuild your virtual environment from scratch. This ensures all paths and dependencies are correctly configured for your current Python installation.

Here's your step-by-step rebuild process:

# Make sure you're in the MCP server directory
cd /path/to/your/mcp-server

# Remove the corrupted virtual environment
rm -rf venv

# Create a fresh virtual environment
python3 -m venv venv

# Activate the new environment
source venv/bin/activate

You should now see (venv) in your terminal prompt, indicating the virtual environment is active. This prefix confirms you're working within the isolated Python environment.

How to Install MCP Server Dependencies

With your fresh virtual environment active, install the MCP server and its dependencies. The exact installation command depends on your specific MCP server, but typically follows one of these patterns:

# For package-based installation
pip install -e .

# Or for requirements file
pip install -r requirements.txt

# Or for specific MCP frameworks
pip install fastmcp

Common MCP server dependencies include:

• FastMCP for the server framework

• JSON-RPC libraries for communication protocols

• HTTP clients for API integrations

• File system utilities for local operations

The installation process displays all packages as they install. Don't worry if you see deprecation warnings – they're normal and won't affect functionality.

How to Locate Your Server Files

After installation, identify where your main server file lives. Run this command to find all server.py files:

find . -name "server.py" -type f

You may see results like:

• ./server.py (in the root directory)

• ./src/server.py (in a source directory)

• ./mcp_server/server.py (in a package directory)

Check your current directory structure:

ls -la

Look for the main server entry point. Most MCP servers follow standard Python project structures with either a root-level server file or one nested in a package directory.

How to Test Your Server Setup

Now you’ll want to test your server to ensure it's working correctly. Start with the main server file you identified:

python server.py

If this is the correct server and everything is configured correctly, you'll see output similar to:

╭─ MCP Server ───────────────────────────────────────────────────────────────╮
│ 🖥️  Server name: Example-MCP                                              │
│ 📦 Transport: STDIO                                                        │
│ 🤝 Protocol: JSON-RPC                                                      │
╰────────────────────────────────────────────────────────────────────────────╯
[INFO] Starting MCP server with transport 'stdio'
[INFO] Server ready for connections

This output confirms your MCP server is working correctly. The server uses standard input/output (STDIO) for communication, which is perfect for Claude Desktop integration. You can stop the server with Ctrl+C.

How to Configure Claude Desktop

Now that your server runs properly, configure Claude Desktop to connect to it. The configuration file location depends on your operating system:

For macOS:

~/Library/Application Support/Claude/claude_desktop_config.json

For Windows:

%APPDATA%\Claude\claude_desktop_config.json

For Linux:

~/.config/Claude/claude_desktop_config.json

Create or edit this file with your exact paths. Your configuration should look like this:

{
  "mcpServers": {
    "example-mcp": {
      "command": "/Users/yourusername/path/to/mcp-server/venv/bin/python",
      "args": ["/Users/yourusername/path/to/mcp-server/server.py"],
      "cwd": "/Users/yourusername/path/to/mcp-server"
    }
  }
}

Replace /Users/yourusername/path/to/mcp-server/ with your actual path. You can get your precise path by running pwd in your MCP server directory.

The configuration tells Claude Desktop:

• Which Python interpreter to use (from your virtual environment)

• Where to find the server script

• Which directory to run the server from

How to Restart Claude Desktop and Test Integration

After saving your configuration file, altogether quit Claude Desktop (not just close the window). On macOS, use Cmd+Q or right-click the dock icon and select Quit. Then restart Claude Desktop.

Once Claude Desktop is running again, test your MCP integration. You can verify the connection by:

1. Looking for your MCP server name in Claude's interface

2. Testing basic MCP functionality with prompts like:

   • "What MCP tools are available?"

   • "Can you check the MCP server status?"

   • "Show me the available MCP commands"

If everything is working correctly, Claude will respond using the MCP server tools, confirming successful integration.

Understanding MCP Server Capabilities

MCP servers extend Claude's capabilities by providing structured access to external tools and data sources. Common MCP server implementations include:

1. File system operations: MCP servers can provide controlled access to local files, allowing Claude to read, analyze, and process documents while maintaining security boundaries.

2. API integrations: Connect Claude to external services through MCP servers that handle authentication, rate limiting, and data formatting for various APIs.

3. Database connections: Query databases safely through MCP servers that manage connections, handle credentials securely, and format results for Claude's consumption.

4. Custom tools: Build specialized tools for your workflow, from code analysis to data processing, all accessible through the standardized MCP interface.

The beauty of MCP is its flexibility – you can create servers for virtually any tool or service you need Claude to interact with.

Alternative Installation Methods

If you want more streamlined approaches for future setups, here are two excellent alternatives:

Method 1: Direct Package Installation

For MCP servers available as packages, you can install directly:

pip install mcp-server-package

Then use this simpler configuration:

{
  "mcpServers": {
    "example-mcp": {
      "command": "mcp-server-command"
    }
  }
}

This method works when the MCP server provides a command-line entry point through its setup configuration.

Method 2: Using UV Package Manager

UV provides more robust dependency management – perfect if you're tired of Python version conflicts:

# Install UV
curl -LsSf https://astral.sh/uv/install.sh | sh

# Use UV in your configuration
{
  "mcpServers": {
    "example-mcp": {
      "command": "uv",
      "args": [
        "run",
        "--with", "fastmcp",
        "python",
        "/path/to/mcp-server/server.py"
      ],
      "cwd": "/path/to/mcp-server"
    }
  }
}

UV automatically manages Python versions and dependencies, reducing the likelihood of environment-related errors.

How to Prevent Future ENOENT Errors

To avoid this issue in the future, follow these best practices:

1. Use Virtual Environment Copies Instead of Symlinks

When creating virtual environments, use the --copies flag:

python3 -m venv venv --copies

This creates actual copies of files instead of symlinks, making your environment more resilient to Python upgrades.

2. Pin Your Homebrew Python Version

Prevent automatic Python upgrades that break environments:

brew pin python@3.11

Remember to unpin when you're ready to upgrade intentionally.

3. Create a Health Check Script

Save this script as health_check.sh in your MCP server directory:

#!/bin/bash
# health_check.sh
echo "Checking Python virtual environment..."
source venv/bin/activate

python -c "import sys; print(f'Python: {sys.executable}')"
python -c "print('✓ Python is working')"

# Check for common MCP dependencies
python -c "import json; print('✓ JSON module available')"
python -c "import asyncio; print('✓ Asyncio available')"

echo "Health check complete!"

Make it executable and run it periodically:

chmod +x health_check.sh
./health_check.sh

4. Document Your Python Version

Create a .python-version file in your project:

python --version > .python-version

This helps you remember which Python version the project was built with.

Troubleshooting Common Issues

Even with the fix applied, you might encounter these challenges:

Import Errors

If you see import-related errors, ensure all dependencies are installed:

source venv/bin/activate
pip list  # Check installed packages
pip install -r requirements.txt  # Reinstall if needed

Permission Denied Errors

Make sure your server file is executable:

chmod +x server.py

Claude Desktop Not Finding the Server

Double-check your configuration paths are absolute, not relative:

# Good - absolute path
"/Users/username/projects/mcp-server/server.py"

# Bad - relative path
"./server.py"

Server Starts, But Claude Can't Connect

Verify that the transport method matches between your server and the configuration. Most MCP servers use STDIO, but some might use HTTP or WebSocket transports.

Multiple Python Installations

If you have multiple Python versions, be explicit about which one to use:

# Check available Python versions
ls -la /usr/local/bin/python*

# Use a specific version
/usr/local/bin/python3.11 -m venv venv

Conclusion

You've successfully fixed the "spawn python ENOENT" error by rebuilding your Python virtual environment and properly configuring your MCP server for Claude Desktop. You've also learned how to prevent future mistakes and troubleshoot common issues.

With your MCP server running smoothly, you can now:

• Build custom tools that extend Claude's capabilities

• Create integrations with your favorite services

• Develop specialized workflows for your specific needs

• Share your MCP servers with the community

The MCP ecosystem is growing rapidly, with new servers and tools being developed constantly. Whether you're building file system tools, API integrations, or custom utilities, you now have the foundation to create and maintain robust MCP servers.

Happy building, and enjoy your error-free development journey! For more tutorials, follow my work on GitHub.

We just published a course on the freeCodeCamp.org YouTube channel that will teach you how to develop smart contracts and blockchain applications using Python and Vyper—even if you have no prior programming experience. This comprehensive course covers everything from the basics of blockchain to advanced smart contract development. You'll learn to write, deploy, and interact with smart contracts while also gaining proficiency in Python scripting. Plus, you'll discover how to leverage AI tools to accelerate your development process. Patrick Collins developed this course.

What You’ll Learn in This Course

By the end of the course, you will be able to:

• Develop smart contracts using Vyper, a Pythonic smart contract language

• Script in Python, even if you start with zero experience

• Interact with smart contracts using Python and Vyper

• Utilize AI tools to enhance development efficiency

Topics Covered

This course goes beyond the basics, introducing you to key blockchain concepts and practical applications, including:

• Fuzzing – Testing smart contract security

• NFTs – Creating and managing non-fungible tokens

• Algorithmic Trading – Building automated trading strategies

• AI Integration – Using AI for smart contract development

• ERC20 Tokens – Developing and interacting with Ethereum-based tokens

• DeFi (Decentralized Finance) – Exploring financial applications on the blockchain

Course Breakdown

The course is structured into multiple hands-on sections, including:

• Blockchain Basics – Understanding how blockchain and smart contracts work

• Python Crash Course – Learning Python from scratch

• Web3 Development with Python – Interacting with blockchain via Web3Py

• Smart Contract Deployment and Interactions – Using Vyper, Boa, and Moccasin frameworks

• NFTs, ERC20 Tokens, and Stablecoins – Building real-world blockchain applications

• Algorithmic Trading and AI in Blockchain – Implementing AI-powered trading strategies

• Final Project – Applying skills in a real-world blockchain development challenge

This is one of the most in-depth courses available for learning smart contract development with Python and Vyper. Whether you are an aspiring blockchain developer or just curious about Web3, this course will equip you with the essential skills to get started.

Watch the full course now on the freeCodeCamp.org YouTube channel and begin your journey into blockchain development.

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.

This curriculum is made possible by The Solana Foundation, who gave our charity a grant to 100% fund development of this curriculum.

What will this curriculum teach you?

The Solana curriculum contains ten interactive practice projects that will guide you through learning the Solana protocol and their tools.

Through these projects, you will learn how to build and deploy smart contracts, dApps, work with their command line tools, and much more.

There are also five challenging integrated projects to test your knowledge.

How does it work?

The courses will run in a docker container using VS Code and the freeCodeCamp Courses extension.

Here's a Sample

Which Projects Will You Build as Part of the Solana Curriculum?

These projects consist of two interactive practice projects and one integrated project. Here are the projects:

1. Learn How to Set Up Solana by Building a Hello World Smart Contract
2. Learn How to Interact with On-Chain Programs
3. Build a Smart Contract
4. Learn Solana's Token Program by Minting a Fungible Token
5. Learn the Metaplex SDK by Minting an NFT
6. Build a University Certification NFT
7. Learn Anchor by Building Tic-Tac-Toe: Part 1
8. Learn Anchor by Building Tic-Tac-Toe: Part 2
9. Build an Anchor Leaderboard
10. Learn How to Build a Client-Side App: Part 1
11. Learn How to Build a Client-Side App: Part 2
12. Build a Client-Side App
13. Learn How to Build for Mainnet
14. Learn How to Deploy to Devnet
15. Build and Deploy Your Freeform App

How to Run the Courses

Follow the steps below to run the courses

Developer Environment Prerequisites

Before you get started, make sure you have these installed on your computer:

1. Docker Engine
2. VS Code and the Dev Containers extension
3. Git

How to Run the Curriculum in Docker

Follow these instructions to clone the repo and run the courses:

1. Open a terminal and clone the solana-curriculum repo with:

   git clone https://github.com/freeCodeCamp/solana-curriculum.git
   

2. Navigate to the solana-curriculum directory, and open it in a VSCode workspace with:

   code .
   

3. Press Ctrl / Cmd + Shift + P to open the command palette, and run Dev Containers: Rebuild Container and Reopen in Container. VS Code will build the container to run the projects in, it will take a few minutes the first time.

4. Once it's finished, press Ctrl / Cmd + Shift + P again and run freeCodeCamp: Run Course to start the courses. This will also take a moment.
5. The simple browser will open when it's done. If it's a blank white page, use the refresh button to update it and see the courses home page.
6. Click on one of the available projects to start a project.
7. Follow the instructions to complete the project.
8. Have fun!

If you want to switch projects, click the freeCodeCamp logo at the top to get back to the home page.

freeCodeCamp Also Offers a More General Web3 Course that Covers Blockchain Fundamentals

While you are waiting for these courses, you can try the Web3 curriculum which is now in open beta. It will teach you many Web3 and blockchain concepts you will want to know for the Solana curriculum.

Where you can Learn more about the Solana Foundation

You can learn more about The Solana Foundation on their website.

And this year's event should be no different – filled with opportunities to learn from speakers and expand your professional network.

This year, the event is focused on Blockchain Development. It will feature talks on beginner and intermediate topics.

Tickets are free if you use the code "FCC". All proceeds from the conference will go to support 4 partner organizations – one of which is freeCodeCamp.

The 2-day event will take place on March 31 from 9 a.m. to 5 p.m. , and April 1 from 9 a.m. to 2 p.m.

The event will feature both Ethereum founder Vitalik Buterin, and US Securities & Exchange Commissioner Hester Peirce.

It will also feature speakers from several major in the blockchain networks:

• Solana
• Near
• Polygon
• Maple Finance
• Aave
• Mysten Labs
• Eigenlayer
• Cega
• Gelato
• Starkware
• Across
• and many more

You can sign up at https://www.hacksummit.org

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!

For anybody to be able to use your Decentralized Application (DApp), they need to be connected to the blockchain where you've deployed your smart contract.

This article will show you how to prompt your users to switch to your preferred blockchain using JavaScript.

This guide requires that you have the MetaMask extension installed. Also, I assume you have a little bit of experience connecting with MetaMask—perhaps you've previously built a DApp. If you need a quick intro, check out this brilliant piece by MetaMask to get started.

Alright, Let’s dig in!

Step 1 — Check if the User Has MetaMask Installed

The first thing to do is to verify if the user has installed the MetaMask extension.

If they have another wallet installed besides MetaMask, switching networks using the method we are about to learn might not work. So it's a good idea to check first.

Let's check if the ethereum context has been injected into the browser. The code sample below shows how to do this:

const { ethereum } = window;

if (typeof ethereum !== 'undefined' && ethereum.isMetaMask) {  
 console.log("MetaMask is installed")
} else {
  console.log("MetaMask is not installed")
}

Here's what we're doing:

At const { ethereum } = window; we destructure the ethereum property from the windows object and assign it to a variable of the same name.

If you are unfamiliar with this syntax, destructuring involves simply extracting the content of an object or array and assigning it to a variable. Read up on this piece to learn more about destructuring.

Then we check if ethereum actually does exist using the if statement. Also, in the same condition we want to verify if the wallet installed is MetaMask.

Good! Let's see the next step.

Step 2 — How to Switch the Active Blockchain

Once we have verified that the user has MetaMask installed, the next thing to do is trigger the RPC method for switching the MetaMask active blockchain. The code looks like this:

// MetaMask Docs
try {
  await ethereum.request({
    method: 'wallet_switchEthereumChain',
    params: [{ chainId: '0xf00' }],
  });
} catch (switchError) {
// This error code indicates that the chain has not been added to MetaMask.
  if (switchError.code === 4902) {
      // Do something
  }
}

Here's what we are doing:

We invoke the ethereum.request method, passing it an object with two properties.

In the method property, we specify the wallet_switchEthereumChain RPC method, which allows Ethereum applications (DApps) to request that MetaMask switches its active Ethereum chain.

Then, the params property is an array that takes an object with the chain ID of the blockchain to switch to. chainId must be hexadecimal, hence the 0x in the sample code.

We wrap our request in a try/catch block to handle errors.

null is returned if the active chain is switched.

If the requested chain does not exist in the user's wallet, the request throws an error code error.code of 4902. If this happens, you can request to add the chain to the wallet.

You can follow this guide to see how to add a new chain to MetaMask using JavaScript.

Great! That's all it takes to switch the active chain on MetaMask with Javascript.

Let's have a quick demo in the next section.

Demo

For this example, let's write a function that, when invoked, will prompt users to switch to the Polygon chain.

const SwitchChainToPolygon = () => {
    const { ethereum } = window;
    if (typeof ethereum !== 'undefined' && ethereum.isMetaMask) return;

    try {
      await ethereum.request({
        method: 'wallet_switchEthereumChain',
        params: [{ chainId: '0x89' }],
      });
    } catch (switchError) {
      if (switchError.code === 4902) {
        // You can make a request to add the chain to wallet here
        console.log('Polygon Chain hasn't been added to the wallet!')
      }
    }
}

In the function SwitchChainToPolygon above, we destructured ethereum from the windows object, as we learned in Step 1.

Next, we verified whether ethereum does exist or not. If the ethereum is unavailable, that is if MetaMask is not installed, the function will exit/break.

If ethereum exists, we call the ethereum.request method to make an RPC call. For the method property, we give it a value of wallet_switchEthereumChain. For the params, chainId will have the value of 0x89 ( 167 in decimal) which is the chainId for the polygon blockchain.

That's all folks!

Conclusion

In this article, you have learned how to switch blockchains on MetaMask with JavaScript. This will help you provide a frictionless user experience for your users.

Thank you for taking the time to read this. I hope you found it useful. Please feel free to connect and chat with me on Twitter and YouTube. See you soon in my next article!

After 15 years in law and other roles, I’d experienced a number of jobs, countries, companies, and career paths. None of them compared to the joy and thrill I get from coding.

The downside? Picking up new coding skills can be confusing, frustrating, and time consuming. And it’s easy to forget some of the minute but important details.

So I wrote this handbook. It's intended to get you started on coding Solidity ASAP. It follows the Pareto Principle (aka the 80/20 rule) by focusing on the 20% of the info that will cover 80% of your needs.

I started assembling these concepts when I was learning Solidity, as part of my role at Chainlink Labs. I applied many of the self-learning techniques that I learned when transitioning to coder at the age of 38.

This is the resource I wish I had. It is designed to give beginner and intermediate developers solid mental models to stack as you get deeper into the language (mental models massively accelerate effective learning).

I will keep this handbook updated, but I could really use your help! Just tweet me @ZubinPratap to let me know if I need to update this handbook.

I’d like to acknowledge my amazing colleagues Kevin Ryu, Andrej Rakic, Patrick Collins, and Richard Gottleber for the invaluable guidance and input on this handbook.

Table of Contents

1. Who is this handbook for?

2. Essential prior knowledge

3. What is Solidity?

4. What is a smart contract?

5. How to declare variables and functions in Solidity?

6. Variable scope in Smart Contracts

7. How visibility specifiers work

8. What are constructors?

9. Interfaces and abstract contracts

10. Smart contract example #2

11. What is contract state?

12. State mutability keywords (modifiers)

13. Data locations – storage, memory, and stack

14. How typing works

15. Solidity data types

16. How to declare and initialize arrays in Solidity

17. What are function modifiers?

18. Error handling in Solidity - require, assert, revert

19. Inheritance in Solidity

20. Inheritance with constructor parameters

21. Type conversion and type casting in Solidity

22. How to work with floating point numbers in Solidity

23. Hashing, ABI encoding and decoding

24. How to call contracts and use the fallback function

25. How to send and receive Ether

26. Solidity libraries

27. Events and logs in Solidity

28. Time logic in Solidity

29. Conclusion and further resources

Who Is This Handbook For?

This handbook is for people who are interested in exploring the vision behind “Web3”, and who wish to acquire in-demand skills that are essential to realizing that vision.

Do not memorize it! Read it and then use it as a “desktop reference” companion. As you learn any new language, you will find that concepts, idioms, and usage can get a bit confusing or your memory fades with time. That’s ok! That’s what this handbook is designed to help you with.

Over time I may add some more advanced topics to this, or create a separate tutorial. But for now this handbook will get you most of the outcomes you require to build your first several Solidity dApps.

This handbook assumes you have at least a few months of experience with programming. By programming I mean at the very least you’ve written in JavaScript or Python or some compiled language (since HTML and CSS aren't actually "programming" languages, it won't be enough to know only them).

The only other requirements are that you are curious, committed, and not putting arbitrary deadlines on yourself.

As long as you have a laptop, and a browser with an internet connection, you’ll be able to run the Solidity code. You can use Remix in your browser to write the code in this handbook. No other IDE required!

Essential Prior Knowledge

I have also assumed that you know the basics of blockchain technology, and in particular you understand the basics of Ethereum and what smart contracts are (hint: they’re programs that run on blockchains and hence provide special trust-minimized benefits!).

You are unlikely to need them to understand this handbook. But practically speaking, having a browser wallet like Metamask and understanding the difference between Ethereum contract accounts and externally owned accounts will help you get the most out of this handbook.

What is Solidity?

Now, let’s start with understanding what Solidity is. Solidity is an object-oriented programming language influenced by C++, JavaScript and Python.

Solidity is designed to be compiled (converted from human readable to machine readable code) into bytecode that runs on the Ethereum Virtual Machine (EVM). This is the runtime environment for Solidity code, just like your browser is a runtime environment for JavaScript code.

So, you write Smart Contract code in Solidity, and the compiler converts it into bytecode. Then that bytecode gets deployed and stored on Ethereum (and other EVM-compatible blockchains).

You can get a basic introduction to the EVM and bytecode in this video I made.

What is a Smart Contract?

Here is a simple smart contract that works out of the box. It may not look useful, but you’re going to understand a lot of Solidity from just this!

Read it along with each comment to get a sense of what’s going on, and then move on to some key learnings.

We will get to some of the details like what public and view mean shortly.

For now, take seven key learnings from the above example:

1. The first comment is a machine readable line ( // SPDX-License-Identifier: MIT) that specifies the licensing that covers the code.

SPDX license identifiers are strongly recommended, though your code will compile without it. Read more here. Also, you can add a comment or “comment out” (suppress) any line by prefixing it with two forward slashes "// ".

2. The pragma directive must be the first line of code in any Solidity file. Pragma is a directive that tells the compiler which compiler version it should use to convert the human-readable Solidity code to machine readable bytecode.

Solidity is a new language and is frequently updated, so different versions of the compiler produce different results when compiling code. Some older solidity files will throw errors or warnings when compiled with a newer compiler version.

In larger projects, when you use tools like Hardhat, you may need to specify multiple compiler versions because imported solidity files or libraries that you depend on were written for older versions of solidity. Read more on Solidity’s pragma directive here.

3. The pragma directive follows Semantic Versioning (SemVer) - a system where each of the numbers signifies the type and extent of changes contained in that version. If you want a hands-on explanation of SemVer is check out this tutorial - it is very useful to understand and it’s used widely in development (especially web dev) these days.

4. Semicolons are essential in Solidity. The compiler will fail if even a single one is missing. Remix will alert you!

5. The keyword contract tells the compiler that you’re declaring a Smart Contract. If you’re familiar with Object Oriented Programming, then you can think of Contracts as being like Classes.

If you’re not familiar with OOP then think of contracts as being objects that hold data - both variables and functions. You can combine smart contracts to give your blockchain app the functionality it needs.

6. Functions are executable units of code that encapsulate single ideas, specific functionality, tasks, and so on. In general we want functions to do one thing at a time.

Functions are most often seen inside smart contracts, though they can be declared in the file outside the smart contract’s block of code. Functions may take 0 or more arguments and they may return 0 or more values. Inputs and outputs are statically typed, which is a concept you will learn about later in this handbook.

7. In the above example the variable qtyCups is called a “state variable”. It holds the contract’s state - which is the technical term for data that the program needs to keep track of to operate.

Unlike other programs, smart contract applications keep their state even when the program is not running. The data is stored in the blockchain, along with the application, which means that each node in the blockchain network maintains and synchronizes a local copy of the data and smart contracts on the blockchain.

State variables are like database “storage” in a traditional application, but since blockchains need to synchronize state across all nodes in the network, using storage can be quite expensive! More on that later.

How to Declare Variables and Functions in Solidity

Let’s break down that HotFudgeSauce Smart Contract so we understand more about each little piece.

The basic structure/syntax to defining things in Solidity is similar to other statically typed languages. We give functions and variables a name.

But in typed languages we also need to specify the type of the data that is created, passed as input or returned as output. You can jump down to the Typing Data section in this handbook if you need to understand what typed data is.

Below, we see what declaring a “State Variable” looks like. We also see what declaring a function looks like.

The first snippet declares a State Variable (I’ll explain what this is soon, I promise) called qtyCups. This can only store values that are of type uint which means unsigned integers. “Integer” refers to all whole numbers below zero (negative) and above zero (positive).

Since these numbers have a + or - sign attached, they’re called signed integers. An unsigned integer is therefore always a positive integer (including zero).

In the second snippet, we see a familiar structure when we declare functions too. Most importantly, we see that the functions have to specify a data type for the value that the function returns.

In this example, since get() returns the value of the storage variable we just created, we can see that the returned value must be a uint.

public is a visibility specifier. More on that later. view is a State-Mutability modifier. More on that below too!

It’s worth noting here that state variables can also be of other types - constant and immutable. They look like this:

Constants and immutable variables have their values assigned once, and only once. They cannot be given another value after their first value is assigned.

So if we made the qtyCups state variable either constant or immutable, we would not be able to call the increment() or decrement() functions on it anymore (in fact, the code wouldn’t compile!).

Constants must have their values hardcoded in the code itself, whereas immutable variables can have their values set once, generally by assignment in the constructor function (we’ll talk about constructor functions very soon, I promise). You can read more in the docs here.

Variable Scope in Smart Contracts

There are three scopes of variables that Smart Contracts have access to:

1. State Variables: store permanent data in the smart contract (referred to as persistent state) by recording the values on the blockchain.

2. Local Variables: these are “transient” pieces of data that hold information for short periods of time while running computations. These values are not stored permanently on the blockchain.

3. Global variables: these variables and functions are “injected” into your code by Solidity, and made available without the need to specifically create or import them from anywhere. These provide information about the blockchain environment the code is running on and also include utility functions for general use in the program.

You can tell the difference between the scopes as follows:

1. state variables are generally found inside the smart contract but outside of a function.

2. local variables are found inside functions and cannot be accessed from outside that function’s scope.

3. Global variables aren’t declared by you - they are “magically” available for you to use.

Here is our HotFudgeSauce example, slightly modified to show the different types of variables. We give qtyCups a starting value and we dispense cups of fudge sauce to everyone except me (because I’m on a diet).

How Visibility Specifiers Work

The use of the word “visibility” is a bit confusing because on a public blockchain, pretty much everything is “visible” because transparency is a key feature. But visibility, in this context, means the ability for one piece of code to be seen and accessed by another piece of code.

Visibility specifies the extent to which a variable, function, or contract can be accessed from outside the region of code where it was defined. The scope of visibility can be adjusted depending on which portions of the software system need to access it.

If you’re a JavaScript or NodeJS developer, you’re already familiar with visibility – any time you export an object you’re making it visible outside the file where it is declared.

Types of Visibility

In Solidity there are 4 different types of visibility: public, external, internal and private.

Public functions and variables can be accessed inside the contract, outside it, from other smart contracts, and from external accounts (the kind that sit in your Metamask wallet) - pretty much from anywhere. It’s the broadest, most permissive visibility level.

When a storage variable is given public visibility, Solidity automatically creates an implicit getter function for that variable’s value.

So in our HotFudgeSauce smart contract, we don’t really need to have the get() method, because Solidity will implicitly provide us identical functionality, just by giving qtyCups a public visibility modifier.

Private functions and variables are only accessible within the smart contract that declares them. But they cannot be accessed outside of the Smart Contract that encloses them. private is the most restrictive of the four visibility specifiers.

Internal visibility is similar to private visibility, in that internal functions and variables can only be accessed from within the contract that declares them. But functions and variables marked internal can also be accessed from derived contracts (that is, child contracts that inherit from the declaring contract) but not from outside the contract. We will talk about inheritance (and derived/child contracts) later on.

internal is the default visibility for storage variables.

The 4 Solidity Visibility specifiers and where they can be accessed from

The external visibility specifier does not apply to variables - only functions can be specified as external.

External functions cannot be called from inside the declaring contract or contracts that inherit from the declaring contract. Thus, they can only be called from outside the enclosing contract.

And that’s how they’re different from public functions – public functions can also be called from inside the contract that declare them, whereas an external function cannot.

What are Constructors?

A constructor is a special type of function. In Solidity, it is optional and is executed once only on contract creation.

In the following example we have an explicit constructor and it accepts some data as a parameter. This constructor parameter must be injected by you into your smart contract at the time you create it.

Solidity constructor function with input parameter

To understand when the constructor function gets called, it’s helpful to remember that a Smart Contract is created over a few phases:

• it is compiled down to bytecode (you can read more about bytecode here). This phase is called “compile time”.

• it gets created (constructed) - this is when the constructor kicks into action. This can be referred to as “construction time”.

• Bytecode then gets deployed to the blockchain. This is “deployment”.

• The deployed smart contract bytecode gets run (executed) on the blockchain. This can be considered “runtime”.

In Solidity, unlike other languages, the program (smart contract) is deployed only after the constructor has done its work of creating the smart contract.

Interestingly, in Solidity, the finally deployed bytecode does not include the constructor code. This is because in Solidity, the constructor code is part of the creation code (construction time) and not part of the runtime code. It is used up when creating the smart contract, and since it’s only ever called once it is not needed past this phase, and is excluded in the finally deployed bytecode.

So in our example, the constructor creates (constructs) one instance of the Person smart contract. Our constructor expects us to pass a string value which is called _name to it.

When the smart contract is being constructed, that value of _name will get stored in the state variable called name (this is often how we pass configuration and other data into the smart contract). Then when the contract is actually deployed, the state variable name will hold whatever string value we passed into our constructor.

Understanding the Why

You might wonder why we bother with injecting values into the constructor. Why not just write them into the contract?

This is because we want contracts to be configurable or “parameterized”. Rather than hard code values, we want the flexibility and reusability that comes with injecting data as and when we need.

In our example, let’s say that _name referred to the name of a given Ethereum network on which the contract is going to be deployed (like Rinkeby, Goerli, Kovan, Mainnet, and so on).

How could we give that information to our smart contract? Putting all those values in it would be wasteful. It would also mean we need to add extra code to work out which blockchain the contract is running on. Then we'd have to pick the right network name from a hard-coded list which we store in the contract, which takes up gas on deployment.

Instead, we can just inject it into the constructor, at the time we are deploying the smart contract to the relevant blockchain network. This is how we write one contract that can work with any number of parameter values.

Another common use case is when your smart contract inherits from another smart contract and you need to pass values to the parent smart contract when your contract is being created. But inheritance is something we will discuss later.

I mentioned that constructors are optional. In HotFudgeSauce, we didn’t write an explicit constructor function. But Solidity supports implicit constructor functions. So if we don’t include a constructor function in our smart contract, Solidity will assume a default constructor which looks like constructor() {}.

If you evaluate this in your head you’ll see it does nothing and that’s why it can be excluded (made implicit) and the compiler will use the default constructor.

Interfaces and Abstract Contracts

An interface in solidity is an essential concept to understand. Smart Contracts on Ethereum are publicly viewable and therefore you can interact with them via their functions (to the extent the Visibility Specifiers allow you to do so!).

This is what makes smart contracts “composable” and why so many Defi protocols are referred to as “money Legos” - you can write smart contracts that interact with other smart contracts that interact with other smart contracts and so on…you get the idea.

So when you want your smart contract A to interact with another smart contract B, you need B’s interface. An interface gives you an index or menu of the various functions available for you to call on a given Smart Contract.

An important feature of Interfaces is that they must not have any implementation (code logic) for any of the functions defined. Interfaces are just a collection of function names and their expected arguments and return types. They’re not unique to Solidity.

So an interface for our HotFudgeSauce Smart Contract would look like this (note that by convention, solidity interfaces are named by prefixing the smart contract’s name with an “I”:

That’s it! Since HotFudgeSauce had only three functions, the interface shows only those.

But there is an important and subtle point here: an interface does not need to include all the functions available to call in a smart contract. An interface can be shortened to include the function definitions for the functions that you intend to call!

So if you only wanted to use the decrement() method on HotFudgeSauce then you could absolutely remove get() and increment() from your interface - but you would not be able to call those two functions from your contract.

So what’s actually going on? Well, interfaces just give your smart contract a way of knowing what functions can be called in your target smart contract, what parameters those functions accept (and their data type), and what type of return data you can expect. In Solidity, that’s all you need to interact with another smart contract.

In some situations, you can have an abstract contract which is similar to but different from an interface.

An abstract contract is declared using the abstract keyword and is one where one or more of its functions are declared but not implemented. This is another way of saying that at least one function is declared but not implemented.

Flipping that around, an abstract contract can have implementations of its functions (unlike interfaces which can have zero implemented functions), but as long as at least one function is unimplemented, the contract must be marked as abstract:

You may (legitimately) wonder what the point of this is. Well, abstract contracts cannot be instantiated (created) directly. They can only be used by other contracts that inherit from them.

So abstract contracts are often used as a template or a “base contract” from which other smart contracts can “inherit” so that the inheriting smart contracts are forced to implement certain functions declared by the abstract (parent) contract. This enforces a defined structure across related contracts which is often a useful design pattern.

This inheritance stuff will become a little clearer when we discuss Inheritance later. For now, just remember that you can declare an abstract smart contract that does not implement all its functions - but if you do, you cannot instantiate it, and future smart contracts that inherit it must do the work of implementing those unimplemented functions.

Some of the important differences between interfaces and abstract contracts are that:

• Interfaces can have zero implementations, whereas abstract contracts can have any number of implementations as long as at least one function is “abstract” (that is, not implemented).

• All functions in an interface must be marked as “external” because they can only be called by other contracts that implement that interface.

• Interfaces cannot have constructors, whereas abstract contracts may.

• Interfaces cannot have state variables where abstract contracts may.

Smart Contract Example #2

For the next few Solidity concepts we’ll use the below smart contract. This is partly because this example contains a smart contract that is actually used in the real world. I've also chosen it because I have a clear bias to Chainlink Labs since I work there (😆) and it’s awesome. But it’s also where I learned a lot of Solidity, and it’s always better to learn with real-world examples.

So start by reading the code and the comments below. You’ve already learned 99% of what you need to understand the contract below, provided you read it carefully. Then move on to key learnings from this contract.

This smart contract gets the latest USD price of 1 Eth, from a live Chainlink price feed oracle (see the oracle on etherscan). The example uses the Goerli network so you don’t end up spending real money on the Ethereum mainnet.

Now to the 6 essential Solidity concepts you need to absorb:

1. Right after the pragma statement we have an import statement. This imports existing code into our smart contract.

This is super cool because this is how we reuse and benefit from code that others have written. You can check out the code that is imported on this GitHub link.

In effect, when we compile our smart contract, this imported code gets pulled in and compiled into bytecode along with it. We will see why we need it in a second…

2. Previously you saw that single-line comments were marked with //. Now you're learning about multiline comments. They may span one or more lines and use /* and */ to start and end the comments.

3. We declare a variable called priceFeed and it has a type AggregatorV3Interface. But where does this strange type come from? From our imported code in the import statement - we get to use the AggregatorV3Interface type because Chainlink defined it.

If you looked at that Github link, you’d see that the type defines an interface (we just finished talking about interfaces). So priceFeed is a reference to some object that is of type AggregatorV3Interface.

4. Take a look at the constructor function. This one doesn’t accept parameters, but we could have just as easily passed the ETH/USD Price Feed’s oracle smart contract’s address 0xD4a33860578De61DBAbDc8BFdb98FD742fA7028e to it as a parameter of type address. Instead, we are hard-coding the address inside the constructor.

But we are also creating a reference to the Price Feed Aggregator smart contract (using the interface called AggregatorV3Interface).

Now we can call all the methods available on the AggregatorV3Interface because the priceFeed variable refers to that Smart Contract. In fact, we do that next… 5. Let's jump to the function getLatestPrice(). You’ll recognize its structure from our discussion in HotFudgeSauce, but it’s doing some interesting things.

Inside this getLatestPrice() function we call the latestRoundData() function which exists on the AggregatorV3Interface type. If you look at the source code of this method you’ll notice that this latestRoundData() function returns 5 different types of integers!

Calling methods on another smart contract from our smart contract

In our smart contract, we are commenting out all 4 values that we don’t need. So this means that Solidity functions can return multiple values (in this example we are returned 5 values), and we can pick and choose which ones we want.

Another way of consuming the results of calling latestRoundData() would be:( ,int price, , ,) = priceFeed.latestRoundData() where we ignore 4 out of 5 returned values by not giving them a variable name.

When we assign variable names to one or more values returned by a function, we call it “destructuring assignment” because we destructure the returned values (separate each one out) and assign them at the time of destructuring, like we do with price above.

Since you’ve learned about interfaces, I recommend you take a look at Chainlink Labs’ GitHub repo to examine the implemented latestRoundData() function in the Aggregator contract and how the AggregatorV3Interface provides the interface to interact with the Aggregator contract.

What is Contract State?

Before we proceed any further, it’s important to make sure that the terminology that we’re going to see a lot is comprehensible to you.

“State” in computer science has a well-defined meaning. While it can get very confusing, the crux of state is that it refers to all the information that is “remembered” by a program as it runs. This information can change, update, be removed, created and so on. And if you were to take a snapshot of it at various times, the information will be in different “states”.

So the state is just the current snapshot of the program, at a point in time during its execution - what values do its variables hold, what are they doing, what objects have been created or removed, and so on.

We have previously examined the three types of variables - State Variables, Local Variables, and Global variables. State variables, along with Global variables give us the state of the smart contract at any given point in time. Thus, the state of a smart contract is a description of:

1. what values its state variables hold,

2. what values the blockchain-related global variables have at that moment in time, and

3. the balance (if any) lying in the smart contract account.

State Mutability Keywords (Modifiers)

Now that we have discussed state, state variables, and functions, let’s understand the Solidity keywords that specify what we are allowed to do with state.

These keywords are referred to as modifiers. But not all of them permit you to modify state. In fact many of them expressly disallow modifications.

Here are Solidity modifiers you will see any real-world smart contract:

Note that in Solidity version 0.8.17, there were breaking changes that enabled the use of payable as a data type. Specifically we now allowed to convert the address data type to a payable address type by doing a type conversion that looks like payable(0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF).
What this does is makes a given ethereum address payable, after which we can send Eth to that address.

Note that this use of payable is a type conversion, and not the same as the function modifier, though the same keyword is used. We will cover the address type later, but you can read about this here. | | virtual | functions | This is a slightly more advanced topic and is covered in detail in the section on Inheritance. This modifier allows the function to be “overridden” in a child contract that inherits from it. In other words, a function with the keyword virtual can be “rewritten” with different internal logic in another contract that inherits from this one. | | override | functions | This is the flip side to the virtual modifier. When a child contract “rewrites” a function that was declared in a base contract (parent contract) from which it inherits, it marks that rewritten function with override to signal that its implementation overrides the one given in the parent contract. If a parent’s virtual function is not overridden by the child, the parent's implementation will apply to the child. | | indexed | events | We will cover events later in this handbook. They are small bundles of data “emitted” by a smart contract typically in response to noteworthy events happening. The indexed keyword indicates that one of the pieces of data contained in an event should be stored in the blockchain for retrieval and filtering later. This will make more sense once we cover Events and Logging later in this handbook. | | anonymous | events | The docs say “Does not store event signature as topic” which probably doesn’t mean a lot to you just yet. But the keyword does indicate that it’s making some part of the event “anonymous”. So this will make sense once we understand events and topics later in this handbook. |

Note that variables that are not storage variables ( i.e. local variables declared and used inside the scope of a given function) do not need state modifiers. This is because they’re not actually part of the smart contract’s state. They’re just part of the local state inside that function. By definition then, they’re modifiable and don’t need controls on their modifiability.

Data Locations – Storage, Memory, and Stack

On Ethereum and EVM-based chains, data inside the system can be placed and accessed in more than one “data location”.

Data locations are part of the fundamental design and architecture of the EVM. When you see the words “memory”, “storage” and “stack”, you should start thinking “data locations” - that is, where can data be stored (written) to and retrieved (read) from.

Data location has an impact on how the code executes at run time. But it also has very important impacts on how much gas gets used during deployment and running of the smart contract.

The use of gas requires a deeper understanding of the EVM and something called opcodes - we can park that discussion for now. While useful, it is not strictly necessary for you to understand data locations.

Though I’ve mentioned 3 data locations so far, there are 2 other ways in which data can be stored and accessed in Smart Contracts: “calldata”, and “code”. But these are not data locations in the EVM’s design. They’re just subsets of the 3 data locations.

Let’s start with storage. In the EVM’s design, data that needs to be stored permanently on the blockchain is placed in the relevant smart contract’s “storage” area. This includes any contract “state variables”.

Once a contract is deployed and has its specific address, it also gets its own storage area, which you can think of as a key-value store (like a hash table) where both the keys and the values are 256 bit (32 byte) data “words”. And “words” has a specific meaning in computer architecture.

Because storage persists data on the blockchain permanently, all data needs to be synchronized across all the nodes in the network, which is why nodes have to achieve consensus on data state. This consensus makes storage expensive to use.

You’ve already seen examples of storage variables (aka contract state variables) but here is an example taken from the Chainlink Verifiable Random Number Consumer smart contract

Storage data location. Putting data in the contract's storage layout.

When the above contract is created and deployed, whatever address that is passed into the contract’s constructor becomes permanently stored in the smart contract’s storage, and is accessible using the variable vrfCoodinator. Since this state variable is marked as immutable, it cannot be changed after this.

To refresh your memory from the previous section on keywords, where we last discussed immutable and constant variables, these values are not put in storage. They become part of the code itself when the contract is constructed, so these values don’t consume as much gas as storage variables.

Now let’s move to memory. This is temporary storage where you can read and write data needed during the running of the smart contract. This data is erased once the functions that use the data are done executing.

The memory location space is like a temporary notepad, and a new one is made available in the smart contract each time a function is triggered. That notepad is thrown away after the execution completes.

When understanding the difference between storage and memory, you can think of storage as a kind of hard disk in the traditional computing world, in the sense that it has “persistent” storage of data. But memory is closer to RAM in traditional computing.

The stack is the data area where most of the EVM’s computations are performed. The EVM follows a stack based computation model and not a register based computation model, which means each operation to be carried out needs to be stored and accessed using a stack data structure.

The stack’s depth - that is the total number of items it can hold - is 1024, and each item in the stack can be 256 bits (32 bytes) long. This is the same as the size of each key and value in the storage data location.

You can read more about how the EVM controls access to the stack data storage area here.

Next, let's talk about calldata. I have assumed that you have a basic understanding about Ethereum smart contract messages and transactions. If you don’t, you should first read those links.

Messages and transactions are how smart contract functions are invoked, and they contain a variety of data necessary for the execution of those functions. This message data is stored in a read-only section of the memory called calldata, which holds things like the function name and parameters.

This is relevant for externally callable functions, as internal and private functions don’t use calldata. Only “incoming” function execution data and function parameters are stored in this location.

Remember, calldata is memory except that calldata is read-only. You cannot write data to it.

And finally, code is not a data location but instead refers to the smart contract's compiled bytecode that is deployed and stored permanently on the blockchain. This bytecode is stored in an immutable ROM (Read Only Memory), that is loaded with the bytecode of the smart contract to be executed.

Remember how we discussed the difference between immutable and constant variables in Solidity? Immutable values get assigned their value once (usually in the constructor) and constant variables have their values hard-coded into the smart contract code. Because they’re hardcoded, constant values are compiled literally and embedded directly into the smart contract’s bytecode, and stored in this code / ROM data location.

Like calldata, code is also read-only - if you understood the previous paragraph you’ll understand why!

How Typing Works

Typing is a very important concept in programming because it is how we give structure to data. From that structure we can run operations on the data in a safe, consistent and predictable way.

When a language has strict typing, it means that the language strictly defines what each piece of data’s type is, and a variable that has a type cannot be given another type.

In other words, in strictly typed languages:

But in JavaScript, which is not typed, b=a would totally work - this makes JavaScript “dynamically typed”.

Similarly, in statically typed languages you cannot pass an integer into a function that expects a string. But in JavaScript we can pass anything to a function and the program will still compile but it may throw an error when you execute the program.

For example take this function:

As you can imagine, this can produce some pretty hard-to-find bugs. The code compiles and can even execute without failing, though it produces unexpected results.

But a strongly typed language would never let you pass the string “2” because the function would insist on the types that it accepts.

Let’s take a look at how this function would be written in a strongly typed language like Go.

How typing works in syntax, using Golang for illustration purposes

Trying to pass a string (even if it represents a number) will prevent the program from even compiling (building). You will see an error like this:

./prog.go:13:19: cannot use "2" (untyped string constant) as int value in argument to add

Go build failed.

Try it out for yourself!

So types are important because data that seems the same to a human can be perceived very differently by a computer. This can cause some pretty weird bugs, errors, program crashes and even big security vulnerabilities.

Types also give developers the ability to create their own custom types, which can then be programmed with custom properties (attributes) and operations (behaviors).

Type systems exist so that humans can reason about the data by asking the question “what is this data’s type, and what should it be able to do?” and the machines can do exactly what is intended.

Here is another example of how data that looks the same to you and me may be interpreted in hugely different ways by a processor. Take the sequence of binary digits (that is the digits can only have a value of 0 or 1, which is the binary system that processors work with) 1100001010100011.

To a human, using the decimal system that looks like a very large number - perhaps 11 gazillion or something.

But to a computer that is binary, so it’s not 11 anything. The computer sees this as a sequence 16 bits (short for binary digits) and in binary this could mean the positive number (unsigned integer) 49,827 or the signed integer -15,709 or the UTF-8 representation of the British Pound symbol £ or something different!

A sequence of bits can be interpreted by a computer to have very different meanings (source)

So all this explanation is to say that types are important, and that types can be “inbuilt” into a language even if the language does not strictly enforce types, like JavaScript.

JavaScript already has inbuilt types like numbers, strings, booleans, objects, and arrays. But as we saw, JavaScript does not insist on types being stuck to the way a statically typed language like Go does.

Now back to Solidity. Solidity is very much a statically typed language. When you declare a variable you must also declare its type. Going further, Solidity will simply refuse to compile if you try to pass a string into a function that expects an integer.

In fact Solidity is very strict with types. For example, different types of integers may also fail compilation like the following example where the function add() expects an unsigned integer (positive) and will only add to that number thus always returning a positive integer. But the return type is specified as an int which means it could be positive or negative!

So even though the input and output are 256-bit integers, the fact that the function only receives unsigned integers makes the compiler complain that the unsigned integer type is not implicitly convertible to the signed integer type.

That’s pretty strict! The developer can force the conversion (called type casting) by rewriting the return statement as return int256(a + 10). But there are issues to consider with that sort of action, and that’s out of scope for what we’re talking about here.

For now, just remember that Solidity is statically typed, which means that the type of each variable must be expressly specified when declaring them in the code. You can combine types to form more complex, composite types. Next, we can discuss some of these inbuilt types.

Solidity Data Types

Types that are built into the language and come with it “out of the box” are often referred to as “primitives”. They’re intrinsic to the language. You can combine primitive types to form more complex data structures that become “custom” data types.

In JavaScript, for example, primitives are data that is not a JS object and has no methods or properties. There are 7 primitive data types in JavaScript: string, number, bigint, boolean, undefined, symbol, and null.

Solidity also has its own primitive data types. Interestingly, Solidity does not have “undefined” or “null”. Instead, when you declare a variable and its type, but do not assign a value to it, Solidity will assign a Default Value to that type. What exactly that default value is depends on the data type .

Many of Solidity’s primitive data types are variations of the same ‘base’ type. For example the int type itself has subtypes based on the number of binary digits that the integer type can hold.

If that confuses you a bit, don’t worry - it isn’t easy if you’re not familiar with bits and bytes, and I’ll cover integers a bit more shortly.

Before we explore Solidity types, there is another very important concept that you must understand - it is the source of many bugs, and “unexpected gotchas” in programming languages.

This is the difference between a value type and reference type, and the resulting distinction between data in programs being “passed by value” vs “passed by reference”. I’ll go into a quick summary below but you may also find it useful to watch this short video to strengthen your mental model before proceeding.

Pass by reference vs pass by value

At an operating system level, when a program is running, all data used by the program during its execution is stored in locations in the computer’s RAM (memory). When you declare a variable, some memory space is allocated to hold data about that variable and the value that is, or eventually will be, assigned to that variable.

There is also a piece of data that is often called a “pointer”. This pointer points to the memory location (an “address” in the computer’s RAM) where that variable and its value can be found. So the pointer effectively contains a reference to where the data can be found in the computer’s memory.

So when you pass data around in a program (for example when you assign a value to a new variable name, or when you pass inputs (parameters) into a function or method, the language’s compiler can achieve this in two ways. It can pass a pointer to the data’s location in the computer’s memory, or it can make a copy of the data itself, and pass the actual value.

The first approach is “pass by reference”. The second approach is “pass by value”.

Solidity’s data type primitives fall into two buckets - they’re either value types, or they’re reference types.

In other words, in Solidity, when you pass data around, the type of the data will decide whether you’re passing copies of the value or a reference to the value’s location in the computer’s memory.

Value Types and Reference Types in Solidity

In Solidity’s “value types”, integers are of two categories - uint is unsigned (positive integers only, so they have no plus or minus signs) and int is signed (could be positive or negative, and if you wrote them down, they’d have a plus or minus sign).

Integer types can also specify how many bits long they are - or how many bits are used to represent the integer.

An uint8 is an integer represented by 8 binary digits (bits) and can store up to 256 different values (2^8=256). Since uint is for unsigned (positive) integers, this means it can store values from 0 to 255 (not including 1 to 256).

However when you have signed integers, like an int8, then one of the bits is used up to represent whether it's a positive or negative number. That means we have only 7 bits left, and so we can only represent up to 2^7 (128) different values, including 0. So an int8 can represent anything from -127 to +127.

By extension, an int256 is 256 bits long and can store +/- (2^255) values.

The bit lengths are multiples of 8 (because 8 bits makes a byte) so you can have int8, int16, int24 etc all the way to 256 (32 bytes).

Addresses refer to the Ethereum account types - either a smart contract account or an externally owned account (aka “EOA”. Your Metamask wallet represents an EOA). So an address is also a type in Solidity.

The default value of an address (that is the value it will have if you declare a variable of type address but don’t assign it any value) is 0x0000000000000000000000000000000000000000 which is also the result of this expression: address(0).

Booleans represent either true or false values. Finally, we have fixed size byte arrays like bytes1, bytes2 … bytes32. These are arrays of fixed length that contain bytes. All these types of values are copied when they’re passed around in the code.

For “reference types”, we have arrays, which can have a fixed size specified when they’re declared, or dynamically sized arrays, which start off with a fixed size, but can be “resized” as the number of data elements in the array grows.

Bytes are a low-level data type that refer to the data that is encoded into binary format. All data is eventually reduced to binary form by the compiler so that the EVM (or, in traditional computing, the processor) can work with it.

Storing and working with bytes is often faster and more efficient compared to other data types that are more human readable.

You may be wondering why I’ve not referred to strings in either types of data in the picture above. That’s because in Solidity, strings are actually dynamically-sized arrays, and the arrays store a sequence of bytes (just binary numbers) that are encoded in the UTF-8 encoding format.

They’re not a primitive in Solidity. In JavaScript they’re referred to as primitives, but even in JavaScript strings are similar (but not the same as) to arrays and are a sequence of integer values, encoded in UTF-16.

It is often more efficient to store a string as a bytes type in a smart contract, as converting between strings and bytes is quite easy. It is therefore useful to store strings as bytes but return them in functions as strings. You can see an example below:

Other than Solidity strings, the bytes data type is a dynamically sized byte array. Also, unlike its fixed-size byte array cousin, it's a reference type. The bytes type in Solidity is a shorthand for “array of bytes” and can be written in the program as bytes or byte[].

If you’re confused by bytes and byte arrays…I sympathise.

The underlying gory details of strings and byte arrays are not too relevant for this handbook. The important point for now is that some data types are passed by reference and others are passed by copying their values.

Suffice it to say that Solidity strings and bytes without a size specified are reference types because they’re both dynamically sized arrays.

Finally, among Solidity’s primitives, we have structs and mappings. Sometimes these are referred to as “composite” data types because they’re composed from other primitives.

A struct will define a piece of data as having one or more properties or attributes, and specifying each property’s data type and name. Structs give you the ability to define your own custom type so that you can organize and collect pieces of data into one larger data type.

For example you could have struct that defines a Person as follows:

You can instantiate or initialize a Person struct in the following ways:

Mappings are similar to hashtables, dictionaries or JavaScript objects and maps, but with a little less functionality.

A mapping is also a key-value pair, and there are restrictions on the kinds of data types you can have as keys, which you can read about here. The data types associated with a mapping’s keys can be any of primitives, structs, and even other mappings.

Here is how mappings are declared, initialized, written to and read from - the below example is from the Chainlink Link Token Smart Contract source code.

Declaring and using the Mappings type in Solidity

If you try to access a value using a key that doesn’t exist in the mapping, it will return the default value of the type that is stored in the mapping.

In the above example, the type of all values in the balances mapping is uint256, which has a default value of 0. So if we called balanceOf() and passed in an address that does not have any LINK tokens issued to it, we’d get a value of 0 back.

This is reasonable in this example, but it can be a bit tricky when we want to find out whether or not a key exists in a mapping.

Currently there is no way to enumerate what keys exist in a mapping (that is, there is nothing equivalent to JavaScript’s Object.keys() method). Retrieving using a key will only return the default value associated with the data type, which does not clearly tell us whether or not the key actually exists.

There is an interesting “gotcha” with mappings. Unlike other languages where you can pass key-value data structures as an argument to function, Solidity does not support passing mappings as arguments to functions except where the functions visibility is marked as internal. So you could not write an externally or publicly callable function that would accept key-value pairs as an argument.

How to Declare and Initialize Arrays in Solidity

Solidity comes with two flavors of arrays, so it is useful to understand the different ways in which they can be declared and initialized.

The two main types of arrays in Solidity are the fixed-size array and the dynamic-sized array.

To refresh your memory, fixed-size arrays are passed by value (copied when passed around in the code) and dynamic-sized arrays are passed by reference (a pointer to the memory address is passed around in the code).

They’re also different in their syntax and their capacity (size), which then dictates when we would use one versus the other.

Here’s what a fixed-size array looks like when declared and initialized. It has a fixed capacity of 6 elements, and this cannot be changed once declared. The memory space for an array of 6 elements is allocated and cannot change.

A fixed-size array can also be declared by just declaring a variable and the size of the array and the type of its elements with the following syntax:

Contrast that with a dynamically-sized array that is declared and initialized as follows. Its capacity is unspecific and you can add elements using the push() method:

You can also declare and initialize the value of an array in the same line of code.

These arrays are available in storage. But what if you needed only temporary in-memory arrays inside a function? In that case there are two rules: only fixed size arrays are allowed, and you must use the new keyword.

Clearly, there are several ways to declare and initialize arrays. When you’re wanting to optimize for gas and computations you want to carefully consider which type of arrays are required, what their capacity is, and if they’re likely to grow without an upper bound.

This also influences and is influenced by the design of your code - whether you need arrays in storage or whether you need them only in memory.

What are Function Modifiers?

When writing functions, we often receive inputs that need some sort of validation, checking, or other logic run on those inputs before we go ahead with the rest of the “business” logic.

For example, if you’re writing in pure JavaScript, you may want to check that your function receives integers and not strings. If it’s on the backend you may want to check that the POST request contained the right authentication headers and secrets.

In Solidity, we can perform these sort of validation steps by declaring a function-like block of code called a modifier.

A modifier is a snippet of code that can run automatically before or after you run the main function (that is, the function that has the modifier applied to it).

Modifiers can be inherited from parent contracts too. It is generally used as a way to avoid repeating your code, by extracting common functionality and putting it in a modifier that can be reused throughout the codebase.

A modifier looks a lot like a function. The key thing to observe about a modifier is where the _ (underscore) shows up. That underscore is like a “placeholder” to indicate when the main function will run. It reads as if we inserted the main function where the underscore is currently.

So in the modifier snippet below, we run the conditional check to make sure that the message sender is the owner of the contract, and then we run the rest of the function that called this modifier. Note that a single modifier can be used by any number of functions.

How function modifiers are written, and the role of the underscore symbol

In this example, the require() statement runs before the underscore (changeOwner()) and that’s the correct way to ensure that only the current owner can change who owns the contract.

If you switched the modifier’s lines and the require() statement came second, then the code in changeOwner() would run first. Only after that would the require() statement run, and that would be a pretty unfortunate bug!

Modifiers can take inputs too - you’d just pass the type and name of the input into a modifier.

Modifiers are a great way to package up snippets of logic that can be reused in various smart contracts that together power your dApp. Reusing logic makes your code easier to read, maintain and reason about – hence the principle DRY (Don’t Repeat Yourself).

Error Handling in Solidity - Require, Assert, Revert

Error handling in Solidity can be achieved through a few different keywords and operations.

The EVM will revert all changes to the blockchain’s state when there is an error In other words, when an exception is thrown, and it’s not caught in a try-catch block, the exception will “bubble up” the stack of methods that were called, and be returned to the user. All changes made to the blockchain state in the current call (and its sub-calls) get reversed.

There are some exceptions, in low-level functions like delegatecall, send, call, and so on, where an error will return the boolean false back to the caller, rather than bubble up an error.

As a developer there are three approaches you can take to handle and throw errors. You can use require(), assert() or revert().

A require statement evaluates a boolean condition you specify, and if false, it will throw an error with no data, or with a string that you provide:

We use require() to validate inputs, validate return values, and check other conditions before we proceed with our code logic.

In this example, if the function’s caller does not send at least 1 ether, the function will revert and throw an error with a string message: “you must pay me at least 1 ether!”.

The error string that you want returned is the second argument to the require() function, but it is optional. Without it, your code will throw an error with no data - which is not terribly helpful.

The good thing about a require() is that it will return gas that has not been used, but gas that was used before the require() statement will be lost. That’s why we use require() as early as possible.

An assert() function is quite similar to require() except that it throws an error with type Panic(uint256) rather than Error(string).

An assert is also used in slightly different situations– where a different type of guarding is required.

Most often you use an assert to check an “invariant” piece of data. In software development, an invariant is one or more pieces of data whose value never changes while the program is executing.

In the above code example, the contract is a tiny contract, and is not designed to receive or store any ether. Its design is meant to ensure that it always has a contract balance of zero, which is the invariant we test for with an assert.

Assert() calls are also used in internal functions. They test that local state does not hold unexpected or impossible values, but which may have changed due to the contract state becoming “dirty”.

Just as require() does, an assert() will also revert all changes. Prior to Solidity’s v0.8, assert() used to use up all remaining gas, which was different from require().

In general, you’d likely use require() more than assert().

A third approach is to use a revert() call. This is generally used in the same situation as a require() but where your conditional logic is much more complex.

In addition, you can throw custom-defined errors when using revert(). Using custom errors can often be cheaper in terms of gas used, and are generally more informative from a code and error readability point of view.

Note how I improve the readability and traceability of my error by prefixing my custom error’s name with the Contract name, so we know which contract threw the error.

In the above example, we use revert once with a custom error that takes two specific arguments, and then we use revert another time with only a string error data. In either case, the blockchain state is reverted and unused gas will be returned to the caller.

Inheritance in Solidity

Inheritance is a powerful concept in Object Oriented Programming (OOP). We won't go into the details of what OOP is here. But the best way to reason about inheritance in programming is to think of it as a way by which pieces of code “inherit” data and functions from other pieces of code by importing and embedding them.

Inheritance in Solidity also allows a developer to access, use and modify the properties (data) and functions (behaviour) of contracts that are inherited from.

The contract that receives this inherited material is called the derived contract, child contract or the subclass. The contract whose material is made available to one or more derived contracts is called a parent contract.

Inheritance facilitates convenient and extensive code reuse – imagine a chain of application code that inherits from other code, and those in turn inherit from others and so on. Rather than typing out the entire hierarchy of inheritance, we can just use a a few key words to “extend” the functions and data captured by all the application code in the inheritance chain. That way child contract gets the benefit of all parent contracts in its hierarchy, like genes that get inherited down each generation.

Unlike some programming languages like Java, Solidity allows for multiple inheritance. Multiple inheritance refers to the ability of a derived contract to inherit data and methods from more than one parent contract. In other words, one child contract can have multiple parents.

You can spot a child contract and identify its parent contract by looking for the is keyword.

If you were to deploy only Contract B using the in-browser Remix IDE you’d note that Contract B has access to the getName() method even though it was not ever written as part of Contract B. When you call that function, it returns “A” , which is data that is implemented in Contract A, not contract B. Contract B has access to both storage variables A_NAME and B_NAME, and all functions in Contract A.

This is how inheritance works. This is how Contract B reuses code already written in Contract A, which could have been written by someone else.

Solidity lets developers change how a function in the parent contract is implemented in the derived contract. Modifying or replacing the functionality of inherited code is referred to as “overriding”. To understand it, let’s explore what happens when Contract B tries to implement its own getName() function.

Modify the code by adding a getName() to Contract B. Make sure the function name and signature is identical to what is in Contract A. A child contract’s implementation of logic in the getName() function can be totally different from how it’s done in the parent contract, as long as the function name and its signature are identical.

The compiler will give you two errors:

1. In Contract A, it will indicate that you are “trying to override non-virtual function” and prompt you by asking if you forgot to add the virtual keyword.

2. In Contract B, it will complain that the getName() function is missing the override specifier.

This means that your new getName in Contract B is attempting to override a function by the same name in the parent contract, but the parent’s function is not marked as virtual – which means that it cannot be overridden.

You could change Contract A’s function and add virtual as follows:

Adding the keyword virtual does not change how the function operates in Contract A. And it does not require that inheriting contracts must re-implement or override it. It simply means that this function may be overridden by any derived contracts if the developer chooses.

Adding virtual fixes the compiler’s complaint for Contract A, but not for Contract B. This is because getName in Contract B needs to also add the override keyword as follows:

We also add the pure keyword for Contract B’s getName() as this function does not change the state of the blockchain, and reads from a constant (constants, you’ll remember, are hardcoded into the bytecode at compile time and are not in the storage data location).

Keep in mind that you only need to override a function if the name and the signature are identical.

But what happens with functions that have identical names but different arguments? When this happens it’s not an override, but an overload. And there is no conflict because the methods have different arguments, and so there is enough information in their signatures to show the compiler that they're different.

For example, in contract B we could have another getName() function that takes an argument, which effectively gives the function a different “signature” compared to the parent Contract A’s getName() implementation. Overloaded functions do not need any special keywords:

Don’t worry about the abi.encodepacked() method call. I’ll explain that later when we talk about encoding and decoding. For now just understand that encodepacked() encodes the strings into bytes and then concatenates them, and returns a bytes array.

We discussed the relationship between Solidity strings and bytes in a previous section of this handbook (under Typing).

Also, since you’ve already learned about function modifiers, this is a good place to add that modifiers are also inheritable. Here’s how you’d do it:

You might wonder which version of a function will be called if a function by the same name and signature exists in a chain of inheritance.

For example, let's say there is a chain of inherited contracts like A → B → C → D → E and all of them have a getName() that overrides a getName() in the previous parent contract.

Which getName() gets called? The answer is the last one – the “most derived” implementation in the contract hierarchy.

State variables in child contracts cannot have the same name and type as their parent contracts.

For example, Contract B below will not compile because its state variable “shadows” that of the parent Contract A. But note how Contract C correctly handles this:

It’s important to note that by passing a new value to the variable author in Contract C’s constructor, we are effectively overriding the value in Contract A. And then calling the inherited method C.getAuthor() will return ‘Hemingway’ and not ‘Zubin’!

It is also worth noting that when a contract inherits from one or more parent contract, only one single (combined) contract is created on the blockchain. The compiler effectively compiles all the other contracts and their parent contracts and so on up the entire hierarchy all into a single compiled contract (which is referred to as a “flattened” contract).

Inheritance with Constructor Parameters

Some constructors specify input parameters and so they need you to pass arguments to them when instantiating the smart contract.

If that smart contract is a parent contract, then its derived contracts must also pass arguments to instantiate the parent contracts.

There are two ways to pass arguments to parent contracts - either in the statement that lists the parent contracts, or directly in the constructor functions for each parent contract. You can see both approaches below:

In Method 2 in the ChildTwo contract, you’ll note that the arguments passed to the parent contracts are first supplied to the child contract and then just passed up the inheritance chain.

This is not necessary, but is a very common pattern. The key point is that where parent contract constructor functions expect data to be passed to them, we need to provide them when we instantiate the child contract.

Type Conversion and Type Casting in Solidity

Sometimes we need to convert one data type to another. When we do so we need to be very careful when converting data and how the converted data is understood by the computer.

As we saw in our discussion on typed data, JavaScript can sometimes do strange things to data because it is dynamically typed. But that’s also why it’s useful to introduce the concept of type casting and type conversions generally.

Take the following JavaScript code:

There are two ways of converting the variable a into an integer. The first, called type casting, is done explicitly by the programmer and usually involves a constructor-like operator that uses ().

Now let's reset a to a string and do an implicit conversion, also known as a type conversion. This is implicitly done by the compiler when the program is executed.

In Solidity, type casting (explicit conversion) is permissible between some types, and would look like this:

In this example we converted an integer with a size of 256 bits (since 8 bits makes 1 byte, this is 32 bytes) into a bytes array of size 32.

Since both the integer value of 2022 and the bytes value are of length 32 bytes, there was no “loss” of information in the conversion.

But what would happen if you tried to convert 256 bits into 8 bits (1 byte)? Try running the following in your browser-based Remix IDE:

Why does the integer 2022 get converted to 230? That’s clearly an undesirable and unexpected change in the value. A bug, right?

The reason is that an unsigned integer of size 256 bits will hold 256 binary digits (either 0 or 1). So a holds the integer value ‘2022’ and that value, in bits, will have 256 digits, of which most will be 0, except for the last 11 digits which will be... (see for yourself by converting 2022 from decimal system to binary here).

The value of b on the other hand will have only 8 bits or digits, being 11100110. This binary number, when converted to decimal (you can use the same converter - just fill in the other box!) is 230. Not 2022.

Oopsie.

So what happened? When we dropped the integer’s size from 256 bits to 8 bits we ended up shaving the first three digits of data (11111100110) which totally changed the value in binary!

This, folks, is information loss.

So when you’re explicitly casting, the compiler will let you do it in some cases. But you could lose data, and the compiler will assume you know what you’re doing because you’re explicitly asking to do it. This can be the source of many bugs, so make sure you test your code properly for expected results and be careful when explicitly casting data to smaller sizes.

Casting up to larger sizes does not result in data lost. Since 2022 needs only 11 bits to be represented, you could declare the variable a as type uint16 and then up-cast it to a variable b of type uint256 without data loss.

The other kind of casting that is problematic is when you’re casting from unsigned integers to signed integers. Play around with the following example:

Note that a , being a signed integer of size 16 bits holds -2022 as a (negative integer) value. If we explicitly type cast it to an unsigned integer (only positive) values, the compiler will let us do it.

But if you run the code, you’ll see that b is not -2022 but 63,514! Because uint cannot hold information regarding the minus sign, it has lost that data, and the resulting binary gets converted to a massive decimal (base 10) number - clearly undesirable, and a bug.

If you go further, and un-comment the line that assigns the value of c, you’ll see the compiler complain with 'Explicit type conversion not allowed from "int16" to "uint256"'. Even though we are up-casting to a larger number of bits in uint256, because c is an unsigned integer, it cannot hold minus sign information.

So when explicitly casting, be sure to think through what the value will evaluate to after you’ve forced the compiler to change the type of the data. It is the source of many bugs and code errors.

There is more to Solidity type conversions and type casting and you can go deep into some of the nitty gritty in this article.

How to Work with Floating Point Numbers in Solidity

Solidity doesn’t handle decimal points. That may change in the future, but currently you cannot really work with fixed (floating) point numbers like 93.6. In fact typing int256 floating = 93.6; in your Remix IDE will throw an error like : Error: Type rational_const 468 / 5 is not implicitly convertible to expected type int256.

What’s going on here? 468 divided by 5 is 93.6, which seems a weird error, but that’s basically the compiler saying it cannot handle floating point numbers.

Follow the suggestions of the error, and declare the variable’s type to be fixed or ufixed16x1.

You’ll get an “UnimplementedFeatureError: Not yet implemented - FixedPointType” error.

So in Solidity, we get around this by converting the floating point number to a whole number (no decimal points) by multiplying by 10 raised to the exponent of the number of decimal places to the right of the decimal point.

In this case we multiply 93.6 by 10 to get 936 and we have to keep track of our factor (10) in a variable somewhere. If the number was 93.2355 we would multiply it by 10 to the power 4 as we need to shift the decimal 4 places to the right to make the number whole.

When working with ERC tokens we will note that the decimal places are often 10, 12, or 18.

For example, 1 Ether is 1*(10^18) wei, which is 1 followed by 18 zeros. If we wanted that expressed with a floating point, we would need to divide 1000000000000000000 by 10^18 (which will give us 1), but if it was 1500000000000000000 wei, then dividing by 10^18 will throw a compiler error in Solidity, because it cannot handle the return value of 1.5.

In scientific notation, 10^18 is also expressed as 1e18, where 1e represents 10 and the number after that represents the exponent that 1e is raised to.

So the following code will produce a compiler error: “Return argument type rational_const 3 / 2 is not implicitly convertible to expected type…int256”:

The result of the above division operation is 1.5, but that has a decimal point which Solidity does not currently support. Thus Solidity smart contracts return very big numbers, often up to 18 decimal places, which is more than JavaScript can handle. So you'll need to handle that appropriately in your front end using JavaScript libraries like Ethersjs that implement helper functions for the BigNumber type.

Hashing, ABI Encoding and Decoding

As you work more with Solidity, you’ll see some strange-sounding terms like hashing, ABI encoding, and ABI decoding.

While these can take some effort to wrap your head around, they’re quite fundamental to working with cryptographic technology, and Ethereum in particular. They’re not complex in principle, but can be a bit hard to grasp at first.

Let’s start with hashing. Using cryptographic math, you can convert any data into a (very large) unique integer. This operation is called hashing. There are some key properties to hashing algorithms:

1. They’re deterministic - identical inputs will always produce an identical output, each time and every time. But the chance of producing the same output using different inputs is extremely unlikely.

2. It is not possible (or computationally infeasible) to reverse engineer the input if you only have the output. It is a one-way process.

3. The output’s size (length) is fixed - the algorithm will produce fixed-size outputs for all inputs, regardless of the input size. In other words the outputs of a hashing algorithm will always have a fixed number of bits, depending on the algorithm.

There are many algorithms that are industry-standard for hashing but you’ll likely see SHA256 and Keccak256 most commonly. These are very similar. And the 256 refers to the size - the number of bits in the hash that is produced.

For example, go to this site and copy and paste “FreeCodeCamp” into the text input. Using the Keccak256 algorithm, the output will (always) be 796457686bfec5f60e84447d256aba53edb09fb2015bea86eb27f76e9102b67a.

This is a 64 character hexadecimal string, and since each character in a hex string represents 4 bits, this hexadecimal string is 256 bits (32 bytes long).

Now, delete everything in the text input box except the “F”. The result is a totally different hex string, but it still has 64 characters. This is the “fixed-size” nature of the Keccak265 hashing algorithm.

Now paste back the “FreeCodeCamp” and change any character at all. You could make the “F” lowercase. Or add a space. For each individual change you make, the hash hex string output changes a lot, but the size is constant.

This is an important benefit from hashing algorithms. The slightest change changes the hash substantially. Which means you can always test whether two things are identical (or have not been tampered with at all) by comparing their hashes.

In Solidity, comparing hashes is much more efficient than comparing the primitive data types.

For example, comparing two strings is often done by comparing the hashes of their ABI-encoded (bytes) form. A common helper function to compare two strings in Solidity would look like this:

We’ll address what ABI encoding is in a moment, but note how the result of encodePacked() is a bytes array which is then hashed using the keccak256 algorithm (this is the native hashing algorithm used by Solidity). The hashed outputs (256 bit integers) are compared for equality.

Now let's turn to ABI encoding. First, we recall that ABI (Application Binary Interface) is the interface that specifies how to interact with a deployed smart contract. ABI-encoding is the process of converting a given element from the ABI into bytes so that the EVM can process it.

The EVM runs computation on bits and bytes. So encoding is the process of converting structured input data into bytes so that a computer can operate on it. Decoding is the reverse process of converting bytes back into structured data. Sometimes, encoding is also referred to as “serializing”.

You can read more about the solidity built-in methods provided with the global variable abi that do different types of encoding and decoding here. Methods that encode data convert them to byte arrays (bytes data type). In reverse, methods that decode their inputs expect the bytes data type as input and then convert that into the data types that were encoded.

You can observe this in the following snippet:

I ran the above in Remix, and used the following inputs for encode(): 1981, 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC, [1,2,3,4].

And the bytes I got returned were represented in hexadecimal form as the following:

0x00000000000000000000000000000000000000000000000000000000000007bd0000000000000000000000003c44cdddb6a900fa2b585dd299e03d12fa4293bc000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000030000000000000000000000000000000000000000000000000000000000000004

I fed this as my input into the decode() function and got my original three arguments back.

Thus, the purpose of encoding is to convert data into the bytes data type that the EVM needs to process data. And decoding brings it back into the human readable structured data that we developers can work with.

How to Call Contracts and Use the Fallback Function

Depending on the design of the smart contract and the visibility specifiers present in it, the contract can be interacted with by other smart contracts or by externally owned accounts.

Calling from your wallet via Remix is an example of the latter, as is using Metamask. You can also interact with smart contracts programmatically via libraries like EthersJS and Web3JS, the Hardhat and Truffle toolchains, and so on.

For the purposes of this Solidity handbook, we will use Solidity to interact with another contract.

There are two ways for a smart contract to call other smart contracts. The first way calls the target contract directly, by using interfaces (which we discussed previously). Or, if the Target contract is imported into the scope of the calling contract, it directly calls it.

This approach is illustrated below:

In Remix you can deploy Target first, and call count() to see that the default value for the count variable is 0, as expected. This value will be decremented by 1 if you call the decrement() method.

Then you can deploy TargetCaller and there are two methods you can call, both of which will decrement the value of count in Target.

Note that each of these two methods access the Target contract using a slightly different syntax. When interacting by using the ITarget interface, the first method takes in Target’s address whereas the second method treats Target as a custom type.

This second approach is only possible when the Target contract is declared in, or imported into, the same file as the TargetCaller. Most often, you will interact with smart contracts deployed by third parties, for which they publish ABI interfaces.

Each time you call these methods, the value of count in Target will decrease by 1. This is a very common way to interact with other smart contracts.

The second way to do it is by using the “low level” call syntax that Solidity provides. You use this when you also want to send some ether (value) to the target contract. Will talk about sending value in the next section, but for now just replace the code in Remix with the following:

You’ll note that decrement() now takes an argument, and the interface and the Target contract are updated with this new input data.

Next note that TargetCaller implements a new function that calls decrement() with a new syntax, explained below.

In the next section we will see examples of these low level ways of calling a target smart contract to send Ether to it.

But what happens when you call a contract and it doesn’t actually have the function you tried to call?

This can happen maliciously to exploit how Solidity works on the EVM. Or, more commonly, it can happen accidentally. This occurs when, for example, there is an error in the Interface and the compiler cannot match the function and parameters you sent with any that are actually contained in the contract. What happens then?

For these situations, many contracts employ a special function called the fallback function. The function looks like a normal function but it doesn’t need the function keyword. If you want it to also handle situations where your contract is sent some ether, you must also mark it payable. But this is not the recommended way to enable your contract to receive payments.

Let’s take a look by repurposing our previous Target, ITarget and TargetCaller and adding a fallback function as follows:

Once we deploy a fresh instance of Target, we can call count() and see that it is set to the default value of zero.

Next we can deploy TargetCaller and call the callFallback() method which internally calls nonExistentFunction().

It’s worth noting that the interface says that nonExistentFunction() is available but the actual Target contract does not have any such function. This is why the Target fallback function gets triggered and the value of count is now incremented by 1.

The purpose of the fallback function is to handle calls to the contract where no other function is available to handle it. And if the fallback is marked payable, the fallback function will also enable the smart contract to receive Ether (though that is not the recommended use for fallback). We will cover this in the next section.

How to Send and Receive Ether

To send Ether to a target contract from your smart contract, you need to call the target contract using one of the following three in-built Solidity methods: transfer, send or call.

transfer will throw an exception when it fails, and send and call will return a boolean that you must check before proceeding. Of these three, transfer and send are no longer recommended for security reasons, though you can still use them and they'll work.

Smart Contracts cannot receive Ether except in the following scenarios:

• They implement a payable fallback or payable receive special function, or

• Forcibly when the calling contract calls selfdestruct and forces a target contract to accept all its remaining ether. The calling contract is then deleted from the blockchain. This is a separate topic and is often used maliciously by exploiters.

It is generally recommended that you use a receive() function if you want your smart contract to receive Ether. You can get away by just making your fallback function payable, but recommended practice is to use a receive() function instead.

If you rely only on the fallback function, your compiler will grumble at you with the following message: “Warning: This contract has a payable fallback function, but no receive ether function. Consider adding a receive ether function.”

If you have both receive and fallback, you may legitimately wonder how Solidity decides which function to receive Ether with. This design decision also tells you what these functions are designed to do.

Receive is meant to receive ether. And fallback is meant to handle situations where the contract has been called but, as we discussed in the previous section, there is no matching method in the contract that can handle the call.

Solidity matches the method that was intended to be called by checking the msg.data field in the transaction sent by the caller. If that field is a non-empty value, and that value does not match any other function declared in the called contract, then the fallback method is triggered.

If msg.data is empty, then it will check if there is a receive function that has been implemented. If so, it will use that to accept the Ether. If no receive exists, it will default to the fallback function. The fallback is therefore the...fallback (default) method when nothing else makes sense.

The receive function is the better way to enable your contract to receive Ether. You can use the fallback function for any scenario where your smart contract is called but there is nothing to “handle” that call.

Here is a super handy logic tree that shows what receive and fallback are intended to handle.

(credit: Solidity By Example)

Going back to our example where we explored the fallback function, we can add a receive function to Target as follows:

We already saw how callFallback will change the count value in Target. But if we deploy a fresh instance of Target, we can now send it 10 wei, as shown below, because it now has a payable receive function. Prior to sending 10 wei (or any other amount) Target has a balance of zero, as shown below.

Hitting the Transact button with empty calldata (msg.data) will change the balance as shown in the image below. We can check count to see that it is incremented by 5, which is the logic in the receive function.

Sending Wei to the Target Contract and observing the updated balance

If we call callFallback and give it the address of the new Target instance, we will note that it increments only by 1. If we include some wei, that will increase the balance of Target as well.

So any transfer of Ether to a smart contract would require the receiving smart contract to have payable functions that can receive it. At the very minimum, the receiving smart contract would need a payable fallback function, though a payable receive function is the better approach for receiving Ether payments.

Solidity Libraries

In any programming language, a library refers to a collection of helper and utility functions that are designed to be reusable across multiple code bases. These functions solve specific, recurring programming problems.

In Solidity, libraries serve the same purpose, but have some special attributes.

First, they are stateless - that is, they don't store data (other than constants because these do not change the blockchain’s state). They also can't receive value (which means they cannot have payable receive or fallback functions).

They also cannot inherit from other contracts or libraries, nor can libraries have child (derived) contracts.

All functions declared in a library must not be abstract - that is, they must all have concrete implementations.

Since Solidity libraries are stateless, none of the methods in them can modify the blockchain’s state. This means all methods inside libraries are pure or view functions.

Another interesting attribute of Solidity libraries is that they don't need to be imported into your smart contract. They can be deployed as standalone contracts and then called via their interface in all consuming smart contracts - just as you would an API service in the traditional engineering world.

However, this is true only where the library contains public or external methods. Then that library can be deployed as a standalone contract with its own Ethereum address, and becomes callable to all consuming smart contracts.

If the libraries contain only internal methods, then the EVM simply “embeds” the library code into the smart contract that uses the library (because internal functions cannot be accessed from other smart contracts).

Libraries in Solidity have advantages that go beyond code reuse. Deploying a library one time on the blockchain can save on future gas costs by avoiding repeated deployment or importing of the library's code.

Let's look at a simple library and then dissect the code to understand how to use the library’s code.

This library has two methods that operate on the int data type. The first argument is called self for reasons that will become clear shortly. One method takes a number and then multiplies it by a constant value that is stored in the library’s code. The second method takes in two numbers and adds them.

Now let’s see how we can use this in a consuming smart contract.

The first thing to note is that there are two ways of using the WeirdMath library.

You can use it by either:

1. Invoking the library’s name followed by the function you want to call, or

2. calling the function directly on the data type you want the function to operate on. This data type must be identical to the type of the self parameter in the library’s function.

The first approach is demonstrated by method 1 in the code snippet where we invoke the library with WeirdMath.add(num1, num2);.

The second approach uses the Solidity using keyword. The expression return num1.add(num2); applies the WeirdMath library’s add function to the num1 variable. This is the same as passing it in as self, which is the first argument to the add function.

Events and Logs in Solidity

Smart Contracts can emit events. The events contain pieces of data that you the developer specify.

Events cannot be consumed by other smart contracts. Instead, they are stored on the blockchain as logs, and can be retrieved via the APIs that read from the blockchain.

This means that your application (most commonly your front end application) can “read” logs that contain the event’s data from the blockchain. In this way your user interface can respond to events on the blockchain.

This is how application user interfaces are updated to respond to on-chain events. Since these logs on the blockchain can be queried, logs are a cheap form of storage, as discussed previously in the discussion on storage areas.

Events emitted by a Smart Contract can be inspected using the relevant blockchain explorer, because everything on a public blockchain is publicly viewable. But if the smart contract’s bytecode has not been verified, the event data may not be human readable (it will be encoded). The events of verified smart contracts will be human readable.

Nodes and other blockchain clients can listen for (subscribe to) specific events. At the heart of it, this is how Chainlink Oracles work - decentralized oracle nodes listen to events from smart contracts, and then respond accordingly. They can even pull data off from events, run complex and resource-intensive computations off-chain, and then submit cryptographically verifiable computation results back onto the blockchain.

Other network APIs and indexing services like subgraphs are made possible because of the ability to query blockchain data via the events emitted by smart contracts.

Here is what an Event looks like in Solidity:

An event is first declared, and its arguments and their data types are specified. Any piece of data that has the indexed keyword is indexed by the EVM so that queries on blockchain logs can use the indexed param as a filter. This makes retrieving logs faster.

An event can store up to 4 indexed parameters - depending on whether it is anonymous or non-anonymous. Indexed event parameters are also referred to as “Topics” in the Solidity world.

Most events are non-anonymous, meaning that they include data on the name and arguments of the Event.

Non-anonymous events allow the developer to specify only 3 topics because the first topic is reserved to specify the Event signature in ABI-encoded hexadecimal form. You can read more about anonymous and non-anonymous topics here.

You can also explore Events on the relevant blockchain explorer (like etherscan.io).

You can approach this from one of two entry points. You can look at the contract’s address directly and then go to the Events Tab (which will show you events emitted by that contract only). Or you can go to a transaction hash and examine all the events emitted by all contracts that were touched by that transaction.

For example, below is a screenshot of the Chainlink VRF Coordinator smart contract’s events on Ethereum mainnet.

Inspecting the Chainlink VRF Coordinator Contract's events on etherscan

The contract tab has a green tick mark which means the contract is verified, and so the Event name and arguments are human readable. Take a moment to study this image as it contains a lot of information! If you’d like to study it directly on etherscan, click here.

This Chainlink VRF Coordinator contract responds to requests for cryptographically verifiable random numbers, and supplies the asking smart contract with random numbers (referred to as “random words”).

If you want to learn what the computer science meaning of “word” is, check out my colleague and I addressing this question in this Chainlink 2022 Hackathon video).

When the VRF Coordinator contract fulfills the request for random numbers, it emits a RandomWordsFulfilled event. That event contains 4 pieces of data, of which the first one, requestID, is indexed.

Solidity events contain three categories of data:

1. The address of the contract that emitted the event.

2. The topics (indexed event parameters used for filtering queries of the logs).

3. Non-indexed parameters, referred to as “data”, and they are ABI-encoded and represented in hexadecimal. This data needs to be ABI-decoded, in the way described in the section on ABI encoding and decoding.

When working in Remix you can also inspect the Events in the console as shown below:

Inspecting Event data in the Remix Browser IDE

You can also programmatically access the events using the contract receipts object in EthersJS. Using the code snippet we used above in the SimpleStorage contract, we can access the events using EthersJS and Hardhat using the following JavaScript:

You can also use libraries such as the EtherJs library in your front end application to listen to events and filter historical events. Both of these are useful when your application needs to respond to events on the blockchain.

Time Logic in Solidity

Time in Solidity is specified in relation to each block that gets added to the blockchain.

The global variable block.timestamp refers to the time, in milliseconds, when the block was generated and added to the blockchain. The milliseconds count refers to the number of milliseconds that have passed since the beginning of the Unix Epoch (in computing, this is 1 January 1970).

Unlike Web2 references to timestamps in milliseconds, the value may not increment with every millisecond.

A block often contains several transactions, and since block.timestamp refers to the time at which the block was mined, all transactions in a mined block will have the same timestamp value. So the timestamp really refers to the block’s time, and not so much as to when the caller may have initiated the transaction.

Solidity supports directly referring to the following units of time: seconds, minutes, hours, days, and weeks.

So we could do something like uint lastWeek = block.timestamp - 1 weeks; to calculate the timestamp of exactly 1 week before this current block was mined, down to milliseconds. That value would be the same as block.timestamp - 7 days;.

You can also use this to calculate future expiry dates, where, for example, you may want an operation to be possible between now and next week. You could do this with uint registrationDeadline = block.timestamp + 1 weeks; and then we could use the registrationDeadline as a validation or guard in a function as follows:

In this function we register the voter only if the current block’s timestamp is not past the registration deadline.

This logic is used extensively when we want to make sure certain operations are performed at the right time, or within an interval.

This is also one of the ways in which Chainlink Automation, a decentralized way to automate the execution of your smart contract, can be configured. The Chainlink decentralized oracle network can be configured to automatically trigger your smart contracts, and you can run a wide variety of automations by checking conditions, including time related conditions. These are used extensively for airdrops, promotions, special rewards, earn-outs and so on.

Conclusion and Further Resources

Congrats! You made it through this epic journey. If you’ve invested the time digesting this handbook, and run some of the code in the Remix IDE, you are now trained in Solidity.

From here on, it’s a question of practice, repetition and experience. As you go about building your next awesome decentralized application, remember to revisit the basics and focus on security. Security is especially important in the Web3 space.

You can get good information on best practices from OpenZeppelin’s blogs and the Trail of Bits resources, amongst others.

You can also get more practical hands on experience by doing the full end-to-end full-stack blockchain developer course that my colleague Patrick Collins published on freeCodeCamp (it’s free!).

There are other resources like blockchain.education and freeCodeCamp’s own upcoming Web3 curriculum that can consolidate your learnings.

In any event, this handbook can be your “desktop companion” for that quick refresh on basic concepts, regardless of what level of experience you’re at.

The important thing to remember is that Web3 technology is always evolving. There is a crying need for developers willing to tackle complex challenges, learn new skills, and solve important problems that come with decentralized architecture.

That could (and should) be you! So just follow your curiosity and don’t be afraid to struggle along the way.

And once again, I intend to keep this handbook updated. So if you see anything that’s not quite right, is outdated, or unclear, just mention it in a tweet and tag me and freeCodeCamp - a big shout out to you all for being part of keeping this handbook fresh.

Now…go be awesome!

Post Script

If you are serious about a career change to code, you can learn more about my journey from lawyer to software engineer. Check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.

If you are interested in changing your career and becoming a professional coder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.

The first time I tried to learn blockchain development, I felt overwhelmed.

This tutorial you're reading is what I wish I could send back in time to myself.

This will give you a strong foundation in blockchain development, and set you up for success in coding your own smart contracts.

In in addition to my explanation and code examples, I've included lots of videos you can use to supplement your learning.

Prerequisites

This tutorial assumes that you understand some foundational coding concepts. One of these that will be particularly helpful is the concept of object-oriented programming (OOP).

What is Blockchain?

The Blockchain is a network of transactions or assets called blocks where every block is connected to the others. Everyone here has equal access to the data circulating within the network.

You can see blockchain as a document that holds the details of transactions made by a group of people where everyone has a copy. Everyone must agree upon any updates before they are accepted.

Anyone who tries to mutilate their document without the others' consent is seen as fraudulent and will suffer predefined consequences.

For example, imagine that a group of friends (Njoku, Samson, and Ebere) decides to start a peer-to-peer savings account that must run for a certain period before a withdrawal is possible. The three agree that no one will be the boss, and each person will have equal access to the account to ensure trust. So they open an account.

Each time one of them deposits money, everyone gets a new account history document emailed to them. Whenever they decide to add a new member, the person becomes part of the signatories and gets a copy of the account history.

Everyone must consent before a withdrawal happens outside the proposed date. Not following these terms will incur consequences such as losing all of a person’s savings or leaving the association after paying a fine.

Blockchain is known as a decentralized technology since data and authority are shared equally among everybody in the network. It differs from centralized applications where the company owns the data, and the consumers just hope their data isn’t misused.

Examples of decentralized applications include Bitcoin and Ethereum, while centralized applications include Facebook and Google.

Blockchain technology falls under the category of Web 3 simply because it is the third phase of the internet in which users can read, write, and own data. Web 1 was the stage where users could only read data. Web 2 emerged sometime around the early 2000s and is the phase in which users can read and write data.

How Blockchain Works

In this section, I will explain what happens in a blockchain application behind the scenes.

We will begin by looking at how it works in theory and then how we can replicate it using a programming language that many devs already know – JavaScript.

Theory Behind the Blockchain

A blockchain is a connection of many blocks. So it begins with one block called the genesis block. Among other things, a block contains a hash, the previous block hash, and at least one transaction.

Every block in the blockchain keeps a record of its hash and the previous block’s hash to keep the network safe from hackers.

This implies that for a hacker to gain access and break the network, they need to generate the hashes and match them to the right block without breaking other blocks. Now that sounds really stressful and almost impossible. That is how secure blockchains are.

Next, any user on the network can perform at least one transaction. If the user has completed a set of transactions they need at a time, they can use those transactions to create a block. The block may now be added to the others.

The whole process of adding a new block is known as mining. The process secures and verifies the transactions contained in a block.

The hash of a block gets generated when mining. The process of calculating the hash is known as proof of work.

Blockchain in Practice

Let's use some JavaScript object-oriented programming to demonstrate how blockchain works. We are using the OOP method because blockchain programming uses the same pattern.

But before we start building, let's learn how to generate the hash for every block in a blockchain.

How to generate a block's hash

There are a lot of libraries for generating a block's hash. But we will use the SHA256 library for this tutorial. SHA256 is the most popular and is used by many renowned companies.

The SHA256 library takes any data given to it and returns a 64-character long string. Every string passed to the SHA256 library will always return the same 64-character long string every time.

You can check out https://emn178.github.io/online-tools/sha256.html and play around with the UI to see how it works.

Blockchains do not use just any hash generated because of security reasons. It specifies what the first few characters must look like for the hash to be accepted. This means that the hash will have to be generated several times, and a record of what changes on each iteration will be kept for reference purposes.

For example, a blockchain may specify that the only acceptable hash must contain three zeros at the beginning.

To calculate the hash, we need to add a number known as a nonce to the string being hashed. The nonce usually starts from zero and is incremented every time the hash is generated until a hash beginning with three zeros is found. Then the hash and the nonce will be stored for reference purposes.

The code below will calculate the hash for "man":

SHA256("man").toString()

However, we may run the function several times to get a string with three zeros at the beginning. Since the function will always return the same result, we need to add a number to the string and increment it until we get the hash we want.

The code we'd use for that will look like this:

let hash = "";
let nonce = 0;

while (hash.substring(0, 3) !== "000") {
  nonce++;
  hash = SHA256("man" + nonce).toString();
}

console.log(nonce);
console.log(hash);

This code will produce 000d6575d4670dae39df9944e54c27dc4837beab1db23e2de264a7c1a3f38b1a after 5707 times instead of 48b676e2b107da679512b793d5fd4cc4329f0c7c17a97cf6e0e3d1005b600b03.

This level of security measures taken to build blockchain applications makes them very reliable and acceptable.

Now that we understand how a hash is generated in blockchain, let's get back to demonstrating how blockchain works.

How Blockchain Works Using JavaScript

First, create a directory called intro_to_blockchain. Then open the directory in a terminal.

Run the following command and hit enter for all the prompts to initialize the project:

npm init

Create 2 files: blockchain.js and test.js:

touch blockchain.js test.js

We will use the blockchain.js file to write the code that emulates how blockchain works and use test.js to test the code and see the result.

In the blockchain.js, enter the following code:

class Blockchain {
    constructor () {
        this.chain = [this.createGenesisBlock()];
        this.pendingTransactions = [];    
    }
}

The code above declares a class named Blockchain. The constructor function is used to initialize the chain and pendingTransactions array.

The chain array will contain every block or group of transactions added to the network. The pendingTransactions array will hold all transactions that have not been added to a block.

Remember that a blockchain starts with a genesis block. That is why the chain array is initialized with an array containing a function that creates the genesis block. You may hardcode the genesis block into the chain array, too.

We now need to build the createGenesisBlock function. Use the code below:

  createGenesisBlock() {
    return {
      index: 1,
      timestamp: Date.now(),
      transactions: [],
      nonce: 0,
      hash: "hash",
      previousBlockHash: "previousBlockHash",
    };
  }

The function will only execute once because the constructor function runs only once – at the beginning of the program.

It is also the only time a random uncalculated hash or previousBlockHash is used because it is the first block in the chain and does not carry any transactions.

The next thing to do is to make a function to get the last block. Use the code below:

  getLastBlock() {
    return this.chain[this.chain.length - 1];
  };

This code will enable us to access the details of the most recent block added. Remember that we need to keep track of the previous block's hash.

Let's now add the code to calculate the hash of a block.

generateHash(previousBlockHash, timestamp, pendingTransactions) {
    let hash = "";
    let nonce = 0;

    while (hash.substring(0, 3) !== "000") {
      nonce++;
      hash = SHA256(
        previousBlockHash +
          timestamp +
          JSON.stringify(pendingTransactions) +
          nonce
      ).toString();
    }

    return { hash, nonce };
  }

To ensure that this works, install the SHA256 library using the following command:

npm i sha256

Import it at the top of your blockchain.js file like this:

const SHA256 = require("sha256");

We will now add a function that creates our transactions and adds them to the list of pending transactions. Enter the following code:

  createNewTransaction(amount, sender, recipient) {
    const newTransaction = {
      amount,
      sender,
      recipient,
    };

    this.pendingTransactions.push(newTransaction);
  }

The time has now arrived for us to build the last function – createNewBlock. It will enable us to add the pending transactions to a block, calculate the hash, and add the block to the chain. Type the code below:

  createNewBlock() {
    const timestamp = Date.now();
    const transactions = this.pendingTransactions;
    const previousBlockHash = this.getLastBlock().hash;
    const generateHash = this.generateHash(
      previousBlockHash,
      timestamp,
      transactions
    );

    const newBlock = {
      index: this.chain.length + 1,
      timestamp,
      transactions,
      nonce: generateHash.nonce,
      hash: generateHash.hash,
      previousBlockHash,
    };

    this.pendingTransactions = [];
    this.chain.push(newBlock);

    return newBlock;
  }

The code above uses the getLastBlock function to access the previous block's hash. It calculates the hash of the current block, adds all the detail of the new block in an object, clears the pendingTransactions array, and pushes the new block into the chain.

Let's export the Blockchain class to be able to access it outside the file:

module.exports = Blockchain;

How to Test the Code

We want to test the code we have written so far and see if it works as expected. We will navigate to the test.js file and begin by importing the Blockchain class that we exported a moment ago like this:

const Blockchain = require("./blockchain");

Now that we have the class here, we can make an instance of it and name it bitcoin:

let bitcoin = new Blockchain();

You may call it whatever you see fit, but I will use bitcoin because it is popular.

Let's now see what we have in bitcoin by default. To do that, we will log it to the console like this:

console.log(bitcoin);

We will now open the project in a terminal and run the following command:

node test

It should output the following:

Default Output

In the output above, we have the chain array containing the genesis block and the pendingTransactions array containing nothing.

You will recall that the constructor function contains all those data and it runs once at the beginning of the program.

To add a new transaction, use the code below:

bitcoin.createNewTransaction(
  "100",
  "0xBcd4042DE499D14e55001CcbB24a551F3b954096",
  "0xa0Ee7A142d267C1f36714E4a8F75612F20a79720"
);

The first parameter is the amount, the second is the sender, and the third is the recipient just as we specified while creating the function.

If you run node test again, you should have one item in the pendingTransactions array like this:

One pending transaction added

To create or mine a block, enter the following code:

bitcoin.createNewBlock();

You should get the output below this time:

You will notice that there are now two (2) blocks in the chain and no more transactions in the pendingTransactions array.

Some things to note in the second block are the nonce and the hash. The nonce is 1404. That means it took 1404 iterations to get the correct hash for this block.

To see the transactions in the second block, we use the following code:

console.log("\n");
console.log("Second Block Transactions", bitcoin.chain[1].transactions);

Now we have the result below:

That looks good! It shows that all our functions work as intended. And that is what goes on behind the scenes of many blockchain applications.

You've just learned how blockchain works. But you shouldn’t build a blockchain application solely on this program idea. There is much more to learn to enable you to build real-world DApp. Still, what we have done so far will help you dive more into learning web3.

One of the things you need to learn is a blockchain programming language such as Solidity and other blockchain frontend libraries such as Web3js and Etherjs.

I'll now introduce you to smart contracts using Solidity.

How to Write a Smart Contract

In this section, we will cover all you need to know about smart contracts and the Solidity programming language.

What is a Smart Contract?

A smart contract is a program stored on the blockchain. It holds certain conditions that must be met before it executes.

Smart contracts take after traditional contracts. But they're different because they are run by a computer automatically when the predefined terms are met.

What is Solidity?

Solidity is the main programming language used to build most smart contracts because it is specifically designed for that purpose. It follows the OOP pattern that we demonstrated using JavaScript and borrows the typed nature of TypeScript. So while some syntax might differ from what you already know, it is not too far-fetched to grasp.

We will be learning the basics of Solidity by using it to build a smart contract that enables users to send funds to each other.

Don't worry, you will not have to set up another project. We will use the remix playground to do everything – write the code, compile, debug, and test.

Let's now head over to https://remix.ethereum.org/. You should have the following screen stare at you for a while:

Remix welcome page

Remix is getting everything ready for you. Just be patient 😊

When it's done, you should have the following screen:

This playground provides us with all we need to write our first smart contract.

Let's start by deleting the file created for us by default. To do that, click on the first icon below the remix logo.

Right-click on the file name in the explorer section and select delete:

Click OK in the pop-up menu.

We will now create a new file named Blockchain.sol by clicking the document icon marked red in the image below and type the name of the file in the space provided:

.sol is the extension used for solidity files. The blank space is where we will type our code.

Solidity code always begins with the line below:

// SPDX-License-Identifier: UNLICENSED

Without this code, you will get an error. It is just like saying that you accept the terms and conditions of writing Solidity.

The next thing to do is to state the Solidity version you want to use. I will use the following code:

pragma solidity ^0.8.7;

The caret (^) sign indicates that the program will be compatible with higher versions of solidity. We can now start the program.

The first thing to do is to define a Class named Blockchain. However, the keyword for Class in solidity is contract. So we have:

contract Blockchain {

}

Inside the contract above, we will create a data-type called BlockStruck with the code below:

struct BlockStruck {
    uint256 index;
    uint256 timestamp;
    uint256 amount;
    address sender;
    address recipient;
}

Solidity allows us to create any data-type that we see fit using the struct keyword, which is short for structure.

We define all the keys we expect a value for in the struct. Since solidity is a strongly typed language, we specified a data-type before each key. The struct is similar to Object in JavaScript.

uint indicates that a variable is an integer. Adding a number after it (such as uint256 or uint18) specifies the maximum size it should take, but uint assumes uint256 by default.

address, on the other hand, indicates that a variable is a wallet address. There is also the string data-type.

The next thing that we want to define is an event. An event is usually triggered at the end of a function's execution to send data to the frontend. You can see it like console.log. Some people also use it as a cheap way of storage.

We want to define a BlockEvent that we will trigger after adding a block to the chain. Enter the following code below the BlockStruct:

event BlockEvent(uint256 amount, address sender, address recipient);

Unlike struct, circular braces are used for an event, and their keys are separated by commas (,). Also, notice that struct does not end with a semicolon, but event does.

Now that we have defined the structure of blocks, let's use it to setup an array of blocks called chain like this:

BlockStruck[] chain;

The code above defines the chain to be an array of BlockStruct. As always, we specify the data-type before the variable name.

Next, define a variable to keep track of how many blocks are in the chain:

uint256 chainCount;

You may choose to assign it a value on the same line (uint256 chainCount = 0;) or do it in the constructor function like this:

constructor() {
    chainCount = 0;
}

We will now define three (3) functions: addBlockToChain (to add blocks to the chain), getChain (to return all the blocks added to the chain), and getChainCount (to get the number of blocks added to the chain).

addBlockToChain function

The code below begins the function:

function addBlockToChain(uint256 amount, address payable recipient) public {

}

Like the functions you already know, it begins with the function keyword followed by the name of the function, and the argument it expects in braces.

One of the arguments (recipient) has a flag called payable, indicating that the wallet address is eligible to receive funds. Next to it is the function's visibility flag (public).

Visibility defines who can call a function or variable. It can be public, private, internal, or external.

1. A public function can be called by any contract.
2. private functions can only be called inside the contract where they are defined.
3. Only contracts that inherit internal functions can call them.
4. external functions are only accessible by other contracts.

In the addBlockToChain, we start by incrementing the chainCount by one like this:

chainCount += 1;

Next, add the block of a transaction to the chain like this:

        chain.push(
            BlockStruck(
                chainCount,
                block.timestamp,
                amount,
                msg.sender,
                recipient
            )
        );

The BlockStruct takes values corresponding to the keys set when defining the struct. It is then added to the chain array using the .push method. Now we have a new block in the chain.

Finally, we trigger the BlockEvent we created a while ago:

emit BlockEvent(amount, msg.sender, recipient);

emit is the keyword used to call an event. As with the BlockStruct, the BlockEvent takes the values as they correspond to the keys set when defining the it.

The addBlockToChain function now looks like this:

    function addBlockToChain(uint256 amount, address payable recipient) public {
        chainCount += 1;

        chain.push(
            BlockStruck(
                chainCount,
                block.timestamp,
                amount,
                msg.sender,
                recipient
            )
        );

        emit BlockEvent(amount, msg.sender, recipient);
    }

getChain function

This function takes no argument but returns a BlockStruct. We will use the following code:

    function getChain() public view returns (BlockStruck[] memory) {
        return chain;
    }

The program returns the chain, an array of all blocks.

Something to note in the function above is that we used view to show that this function returns a value. We also indicated the kind of data type we expect to be returned (returns (BlockStruck[] memory)) and the storage type to be used (memory).

There are two main storage types in solidity: Storage and Memory. Storage is the default type of storage used to hold data permanently for a program while Memory is temporary and is less expensive in terms of gas.

Gas is a fee paid to execute smart contracts. Don't worry about that. We have some dummy gas that will enable us to test our program.

getChainCount function

Like the getChain, this function also takes no argument. It returns the number of blocks added to the chain so far. See the code below:

    function getChainCount() public view returns (uint256) {
        return chainCount;
    }

That completes the smart contract that we intended to create. Now the code looks like this:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.7;

contract Blockchain {
    struct BlockStruck {
        uint256 index;
        uint256 timestamp;
        uint256 amount;
        address sender;
        address recipient;
    }

    event BlockEvent(uint256 amount, address sender, address recipient);

    BlockStruck[] chain;
    uint256 chainCount;

    constructor() {
        chainCount = 0;
    }

    function addBlockToChain(uint256 amount, address payable recipient) public {
        chainCount += 1;

        chain.push(
            BlockStruck(
                chainCount,
                block.timestamp,
                amount,
                msg.sender,
                recipient
            )
        );

        emit BlockEvent(amount, msg.sender, recipient);
    }

    function getChain() public view returns (BlockStruck[] memory) {
        return chain;
    }

    function getChainCount() public view returns (uint256) {
        return chainCount;
    }
}

How to Compile the Smart Contract

We need to compile the code to check if there are errors that we need to fix. The steps below will help us do just that.

Click on the third icon on the left side menu of the remix IDE:

Ensure that the solidity version selected matches the one you specified at the beginning of the smart contract. Then click the Compile button:

The compilation was successful since we have no errors. Beautiful 🥰.

How to Deploy the Smart Contract

Now that compilation is successful, let's deploy the contract.

Click on the fourth icon in the side menu:

Select Remix VM (London) for the ENVIRONMENT. It has ten (10) accounts with 100 dummy ethers each that you may use for test purposes. Then click the Deploy button:

Now when you scroll to the bottom, you will find the Blockchain contract under Deployed Contracts. Click the arrow by the deployed contract name to see the functions of the contract that you can interact with.

There are three (3) functions in the image above that match the three (3) functions we defined in our smart contract. Remix automatically creates a UI for you to test your contracts as soon as you deploy them

How to Test the Smart Contract

We will now test the functions we created to see how they respond.

How to test the addBlockToChain function

To test the addBlockToChain function, click the caret (^) icon by the side of the function button and input box. That drops down a form. Fill in 10 for the amount, and fill in one of the ten 10 account addresses for the recipient:

Click the transact button.

Note that you cannot send funds to the same address you used to deploy the contract. You must choose a different account.

How to test the getChain function

Click the getChain button to reveal the blocks in the chain so far:

It returns a tuple, which is a kind of array. Recall that chain is supposed to be an array containing a list of blocks.

How to test the getChainCount function

To get the number of blocks added, click the getChainCount button:

And just as we defined it, it returns a uint. There is just one item in the chain for now, but as you keep adding more blocks, the number will increase.

Walah! Did we come this far? 😳 How Awesome 😍.

Congratulations on sticking to the end of this tutorial!

You are now ready to explore all that you can do with blockchain.

Conclusion

Blockchain is redefining the internet and has come to stay. The difficulty I encountered trying to learn the ropes of this new technology moved me to document this beginner-friendly guide. I hope that it helps everyone still struggling out there.

In this tutorial, you learned what blockchain is, how it works and what goes on behind the scenes. We demonstrated how it works using the OOP pattern of JavaScript and then concluded with a brief introduction to how to build smart contracts using the solidity programming language and remix IDE.

I recommend that you keep learning and getting better at building blockchain applications by creating the following projects in the order they are listed (by increasing difficulty):

Hello World
Simple Storage
Voting Smart Contract
Ether Wallets
Multi Send
Time Lock Smart Contract
ERC20 Token
Token Wallet
Air Drop
ICO

These projects will challenge you to do research and sharpen your blockchain skill.

Happy Chaining!

The technologies usually used for blockchains are purpose-driven, and you can use them for other projects as well.

The examples in this article can readily handle heavy loads and remain responsive and quick to execute user requests.

Because the cryptocurrency industry is growing fast, a lot of countries are setting rules around how everything should be managed. As a result, I will adhere to certain regulations and take into account certain details, such as the characteristics of the blockchain technology.

For instance, you can have overloads and performance problems with blockchain technology. And as the market for cryptocurrencies and blockchain technology expands, new products are more likely to appeal to a wide range of active blockchain technology users.

Because of this, I had to find a way to prevent the program from becoming overloaded in the event of a significant increase in users.

Tutorial Prerequisites

For this walkthrough, these are the following technologies we will be using. You should be familiar with them:

• Node.js (specifically, the NestJS framework) for backend development. Nest.js forces you to use a modular structure where each feature can be isolated and easily connected/disconnected to/from other modules. Nest supports TypeScript out-of-the-box.
• PostgreSQL is the database we'll use to collect data.
• Kafka JS serves incoming loads and establishes communication between microservices.
• Helm charts and Kubernetes (k8s) for deployment. These tools will enable easy deployment of scalable microservices infrastructure on any cloud platform (we will use AWS EKS)

Also, this article assumes you have a decent level of knowledge about Kubernetes, Helm, and Node. Let's dive in.

Development Method

Our primary goal for the first phase is to divide our application into microservices.

In addition to helping with service communication, load balancing with Kafka enables the one-by-one processing of input data. When we have many customers, processing times may increase, but at least the service will continue and be preserved.

Additionally, if the cluster has enough resources, we can spawn extra consumers for the group that manages particular events. This reduces delays and accelerates task processing.

In this situation, we will develop six different microservices:

1. Admin Microservice – We'll use the admin microservice for all administrative panel logic, which should be isolated from user-facing functionality.
2. Core Microservice – Logic pertaining to users and their accounts is contained in the core microservice. Identification, gifts, charts, profiles, and so on. However, this microservice does not carry out the duties of a financial service, such as processing payments and exchanging currency.
3. Payment Microservice – A financial service called a "payment microservice" includes logic for trade, exchange, and withdrawal transactions. There will be integrations with CEX and DeFi solutions.
4. Email and notification service – This microservice is in charge of informing the user of emails, push notifications, and other types of alerts. It contains a separate Kafka queue for requests from other microservices to send users emails or notifications.
5. Cron Tasks – A microservice called Cron Tasks Service transmits predetermined events for task processing. Microservices don't carry out tasks on their own. Holding such a microservice helps prevent skipping cron job iterations when, for instance, the processing service is down due to deployment or a breakdown. The event will remain in a queue as it waits to be executed.
6. Webhooks Microservice – The goal of the webhooks microservice is to prevent any events from external APIs that may be very significant and contain transaction statuses or other vital data from being missed. Such events are processed after being queued up (based on the sender API).

Now let's see how to make these microservices using Nest.js.

For the Kafka messages broker, you'll need to create configuration options. In order to store the shared modules and configurations of all microservices, we will establish a shared resources folder.

Microservices Configuration Options

Production apps must have configuration. The configuration is crucial for understanding what your production application consumes as you build out a microservice application. It is usually recommended practice to keep configuration settings distinct from your code when developing microservices.

import { ClientProviderOptions, Transport } from '@nestjs/microservices';

import CONFIG from '@application-config';

import { ConsumerGroups, ProjectMicroservices } from './microservices.enum';

const { BROKER_HOST, BROKER_PORT } = CONFIG.KAFKA;




export const PRODUCER_CONFIG = (name: ProjectMicroservices): ClientProviderOptions => ({

 name,

 transport: Transport.KAFKA,

 options: {

   client: {

     brokers: [${BROKER_HOST}:${BROKER_PORT}],

   },

 }

});



export const CONSUMER_CONFIG = (groupId: ConsumerGroups) => ({

 transport: Transport.KAFKA,

 options: {

   client: {

     brokers: [${BROKER_HOST}:${BROKER_PORT}],

   },

   consumer: {

     groupId

   }

 }

});

Let's link our microservice for the admin panel to Kafka in consumer mode. We can detect and manage events from topics thanks to it.

Make the app operate in microservice mode so that events can be consumed like this:

app.connectMicroservice(CONSUMER_CONFIG(ConsumerGroups.ADMIN));

 await app.startAllMicroservices();

We can see that groupId is included in the consumer configuration. It's a crucial choice that will enable customers from the same group to get events from topics and share them with one another to process them more quickly.

For instance, we can use autoscaling to launch more pods to divide loading between them and speed up the process double if our microservice receives events more quickly than it can process them.

Consumers must be included in the group for this to work, and after scaling, spawned pods will also be included. They won't have to handle the same subject events from several Kafka partitions because they can share loading.

Let's look at an illustration of how we can use Nest to capture and handle Kafka events.

Consumer Controller

import { Controller } from '@nestjs/common';

import { Ctx, KafkaContext, MessagePattern, EventPattern, Payload } from '@nestjs/microservices';




@Controller('consumer')

export class ConsumerController {

 @MessagePattern('hero')

 readMessage(@Payload() message: any, @Ctx() context: KafkaContext) {

   return message;

 }




 @EventPattern('event-hero')

 sendNotif(data) {

   console.log(data);

 }

}

Customers can operate in two modes. It accepts events, processes them without delivering a response (EventPattern decorator), or, after processing an event, returns the response to the producer (MessagePattern decorator).

Since it doesn't contain any additional source code layers to enable request/response functionality, EventPattern is preferable and you should choose it wherever possible.

Who Are the Producers?

We must supply producer configuration for a module that will be in charge of transmitting events in order to link producers.

Producer Connection

import { Module } from '@nestjs/common';

import DatabaseModule from '@shared/database/database.module';

import { ClientsModule } from '@nestjs/microservices';

import { ProducerController } from './producer.controller';

import { PRODUCER_CONFIG } from '@shared/microservices/microservices.config';

import { ProjectMicroservices } from '@shared/microservices/microservices.enum';




@Module({

 imports: [

   DatabaseModule,

   ClientsModule.register([PRODUCER_CONFIG(ProjectMicroservices.ADMIN)]),

 ],

 controllers: [ProducerController],

 providers: [],

})

export class ProducerModule {}

Event-based producer

import { Controller, Get, Inject } from '@nestjs/common';

import { ClientKafka } from '@nestjs/microservices';

import { ProjectMicroservices } from '@shared/microservices/microservices.enum';




@Controller('producer')

export class ProducerController {

 constructor(

   @Inject(ProjectMicroservices.ADMIN)

   private readonly client: ClientKafka,

 ) {}




 @Get()

 async getHello() {

   this.client.emit('event-hero', { msg: 'Event Based'});

 }

}

Request/response-based producer

import { Controller, Get, Inject } from '@nestjs/common';

import { ClientKafka } from '@nestjs/microservices';

import { ProjectMicroservices } from '@shared/microservices/microservices.enum';




@Controller('producer')

export class ProducerController {

 constructor(

   @Inject(ProjectMicroservices.ADMIN)

   private readonly client: ClientKafka,

 ) {}




 async onModuleInit() {

   // Need to subscribe to a topic

   // to make the response receiving from Kafka microservice possible

   this.client.subscribeToResponseOf('hero');

   await this.client.connect();

 }




 @Get()

 async getHello() {

   const responseBased = this.client.send('hero', { msg: 'Response Based' });

      return responseBased;

 }

}

Each microservice has the option of operating in one of the two modes—producer or consumer—or in both modes simultaneously (mixed).

Microservices typically employ mixed mode for load balancing, producing events to the subject, and consuming them while equally splitting the load.

For each microservice, we'll use a Kubernetes setup based on Helm chart templates.

There are several configuration files in the template:

• Hpa (horizontal pod autoscaler)
• Ingress controller
• Service
• Deployment

We'll examine each configuration file separately (without Helm templating).

How to deploy the admin-API

apiVersion: apps/v1

kind: Deployment

metadata:

 name: admin-api

spec:

 replicas: 1

 selector:

   matchLabels:

     app: admin-api

 template:

   metadata:

     labels:

       app: admin-api

   spec:

     containers:

     - name: admin-api

       Image: xxx208926xxx.dkr.ecr.us-east-1.amazonaws.com/project-name/stage/admin-api

       resources:

         requests:

           cpu: 250m

           memory: 512Mi

         limits:

           cpu: 250m

           memory: 512Mi

       ports:

         - containerPort: 80

       env:

         - name: NODE_ENV

           value: production




         - name: APP_PORT

           value: "80"

You can include more minimal configurations, such as resource limitations, health check configurations, update strategies, and so on in a deployment.

Admin-API service

---

apiVersion: v1

kind: Service

metadata:

 name: admin-api

spec:

 selector:

   app: admin-api

 ports:

   - name: admin-api-port

     port: 80

     targetPort: 80

     protocol: TCP

 type: NodePort

To use this service, we must make it available to the public. Let's utilise SSL setup to leverage a secure HTTPS connection and expose our app via a load balancer.

On our cluster, we must deploy a load balancer controller. The most widely used answer is as follows: Load Balancer Controller for AWS.

Next, we must set up ingress with the following settings:

Admin-API ingress controller

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

 namespace: default

 name: admin-api-ingress

 annotations:

   alb.ingress.kubernetes.io/load-balancer-name: admin-api-alb

   alb.ingress.kubernetes.io/ip-address-type: ipv4

   alb.ingress.kubernetes.io/tags: Environment=production,Kind=application

   alb.ingress.kubernetes.io/scheme: internet-facing

   alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-2:xxxxxxxx:certificate/xxxxxxxxxx

   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'

   alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS

   alb.ingress.kubernetes.io/healthcheck-path: /healthcheck

   alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'

   alb.ingress.kubernetes.io/ssl-redirect: '443'

   alb.ingress.kubernetes.io/group.name: admin-api

spec:

 ingressClassName: alb

 rules:

   - host: example.com

     http:

       paths:

         - path: /*

           pathType: ImplementationSpecific

           backend:

             service:

               name: admin-api

               port:

                 number: 80

Once this configuration has been applied, a new alb load balancer will be formed. We must construct a domain with the name we specified in the 'host' option and direct traffic to our load balancer from this host.

Admin-API autoscaling configuration

apiVersion: autoscaling/v2beta1

kind: HorizontalPodAutoscaler

metadata:

 name: admin-api-hpa

spec:

 scaleTargetRef:

   apiVersion: apps/v1

   kind: Deployment

   name: admin-api

 minReplicas: 1

 maxReplicas: 2

 metrics:

   - type: Resource

     resource:

       name: cpu

       targetAverageUtilization: 90

How Does Helm Come into the Picture?

When we want to make our k8s infrastructure less complex, Helm is quite helpful. Without this tool, running it on a cluster requires writing numerous YML files.

Additionally, we must consider the relationships among applications, labels, names, and so on. Helm, on the other hand, can simplify things. It functions similarly to a package manager, allowing us to make an app template, prepare it using short commands, and then launch it.

Let's create our templates using Helm.

Admin-API deployment (Helm chart)

apiVersion: apps/v1

kind: Deployment

metadata:

 name: {{ .Values.appName }}

spec:

 replicas: {{ .Values.replicas }}

 selector:

   matchLabels:

     app: {{ .Values.appName }}

 template:

   metadata:

     labels:

       app: {{ .Values.appName }}

   spec:

     containers:

     - name: {{ .Values.appName }}

       image: {{ .Values.image.repository }}:{{ .Values.image.tag }}"

       imagePullPolicy: {{ .Values.image.pullPolicy }}

       ports:

       - containerPort: {{ .Values.internalPort }}

       {{- with .Values.env }}

       env: {{ tpl (. | toYaml) $ | nindent 12 }}

       {{- end }}

Admin-API service (Helm chart)

apiVersion: v1

kind: Service

metadata:

 name: {{ .Values.global.appName }}

spec:

 selector:

   app: {{ .Values.global.appName }}

 ports:

   - name: {{ .Values.global.appName }}-port

     port: {{ .Values.externalPort }}

     targetPort: {{ .Values.internalPort }}

     protocol: TCP

 type: NodePort

Admin-API ingress (Helm chart)

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

 namespace: default

 name: ingress

 annotations:

   alb.ingress.kubernetes.io/load-balancer-name: {{ .Values.ingress.loadBalancerName }}

   alb.ingress.kubernetes.io/ip-address-type: ipv4

   alb.ingress.kubernetes.io/tags: {{ .Values.ingress.tags }}

   alb.ingress.kubernetes.io/scheme: internet-facing

   alb.ingress.kubernetes.io/certificate-arn: {{ .Values.ingress.certificateArn }}

   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'

   alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS

   alb.ingress.kubernetes.io/healthcheck-path: {{ .Values.ingress.healthcheckPath }}

   alb.ingress.kubernetes.io/healthcheck-interval-seconds: {{ .Values.ingress.healthcheckIntervalSeconds }}

   alb.ingress.kubernetes.io/ssl-redirect: '443'

   alb.ingress.kubernetes.io/group.name: {{ .Values.ingress.loadBalancerGroup }}

spec:

 ingressClassName: alb

 rules:

   - host: {{ .Values.adminApi.domain }}

     http:

       paths:

         - path: {{ .Values.adminApi.path }}

           pathType: ImplementationSpecific

           backend:

             service:

               name: {{ .Values.adminApi.appName }}

               port:

                 number: {{ .Values.adminApi.externalPort }}

Admin-API autoscaling configuration (Helm chart)

{{- if .Values.autoscaling.enabled }}

apiVersion: autoscaling/v2beta1

kind: HorizontalPodAutoscaler

metadata:

 name: {{ include "ks.fullname" . }}

 labels:

   {{- include "ks.labels" . | nindent 4 }}

spec:

 scaleTargetRef:

   apiVersion: apps/v1

   kind: Deployment

   name: {{ include "ks.fullname" . }}

 minReplicas: {{ .Values.autoscaling.minReplicas }}

 maxReplicas: {{ .Values.autoscaling.maxReplicas }}

 metrics:

 {{- if .Values.autoscaling.targetCPUUtilizationPercentage }}

   - type: Resource

     resource:

       name: cpu

       targetAverageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}

 {{- end }}

 {{- if .Values.autoscaling.targetMemoryUtilizationPercentage }}

   - type: Resource

     resource:

       name: memory

       targetAverageUtilization: {{ .Values.autoscaling.targetMemoryUtilizationPercentage }}

 {{- end }}

{{- end }}

The "values.yml," "values-dev.yml," and "values-stage.yml" files contain the values for the templates. The environment will determine which of them is used.

Let's look at few samples of dev env values.

Admin-API Helm values-stage.yml file

env: stage

appName: admin-api

domain: admin-api.xxxx.com

path: /*

internalPort: '80'

externalPort: '80'




replicas: 1

image:

 repository: xxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/admin-api

 pullPolicy: Always

 tag: latest




ingress:

 loadBalancerName: project-microservices-alb

 tags: Environment=stage,Kind=application

 certificateArn: arn:aws:acm:us-east-2:xxxxxxxxx:certificate/xxxxxx

 healthcheckPath: /healthcheck

 healthcheckIntervalSeconds: '15'

 loadBalancerGroup: project-microservices




autoscaling:

 enabled: false

 minReplicas: 1

 maxReplicas: 100

 targetCPUUtilizationPercentage: 80




env:

 - name: NODE_ENV

   value: stage




 - name: ADMIN_PORT

   value: "80

We must upgrade the chart and restart our deployment in order for the configuration to take effect on the cluster.

Let's investigate the GitHub Actions steps in question.

How to apply Helm configuration in GitHub Actions

GitHub actions are CI/CD services from GitHub. They provide straightforward work processes arranged as Yaml files which run configurable blocks of code based on GitHub events. Since they are integrated into GitHub, they reduce significantly the overhead in getting a CI/CD pipeline setup.

 - name: Admin image build and push

       run: |

         docker build -t project-admin-api -f Dockerfile.admin .

         docker tag project-admin-api ${{ env.AWS_ECR_REGISTRY }}/project/${{ env.ENV }}/admin-api:latest

         docker push ${{ env.AWS_ECR_REGISTRY }}/project/${{ env.ENV }}/admin-api:latest




     - name: Helm upgrade admin-api

       uses: koslib/helm-eks-action@master

       env:

         KUBE_CONFIG_DATA: ${{ env.KUBE_CONFIG_DATA }}

       with:

         command: helm upgrade --install admin-api -n project-${{ env.ENV }} charts/admin-api/ -f charts/admin-api/values-${{ env.ENV }}.yaml




     - name: Deploy admin-api image

       uses: kodermax/kubectl-aws-eks@master

       env:

         KUBE_CONFIG_DATA: ${{ env.KUBE_CONFIG_DATA }}

       with:

         args: rollout restart deployment/admin-api-project-admin-api --namespace=project-${{ env.ENV }}

Summary

In this article, we looked at infrastructure-building and Kubernetes cluster deployment steps for microservices. By using straightforward examples and avoiding further complexity with full configurations, I hope it was relatively easy to grasp.

Connect with me on LinkedIn and Twitter

Hasta la vista!

In this article I will show you three ways you can create a whitelist in a smart contract.

Here's what we'll discuss:

• On-chain whitelists
• Digital signatures
• Merkle trees

All methods are available in the repo here.

A whitelist is useful if you want to restrict access to a certain function or want to grant privileges to a certain group of users.

To compare these methods, I'm going to use very minimalistic smart contracts to reduce the unnecessary spending of gas.

Let's dive into it.

How to Create an On-Chain Whitelist

The main idea is to store all whitelist addresses in the smart contract.

Take a look at this schema:

On-chain whitelist

When user calls the smart contract function, it checks if the address is in the whitelist. If it is, the function executes.

If you want to add or remove addresses from the whitelist, you can do it in the smart contract with additional external functions.

Pros:

• easy to implement
• all addresses are stored in the smart contract and only the owner can edit them

Cons:

• it's the most expensive method
• you have to spend gas to add and remove the addresses

Here's what the smart contract looks like:

contract OnChainWhitelistContract is Ownable {

    mapping(address => bool) public whitelist;

    /**
     * @notice Add to whitelist
     */
    function addToWhitelist(address[] calldata toAddAddresses) 
    external onlyOwner
    {
        for (uint i = 0; i < toAddAddresses.length; i++) {
            whitelist[toAddAddresses[i]] = true;
        }
    }

    /**
     * @notice Remove from whitelist
     */
    function removeFromWhitelist(address[] calldata toRemoveAddresses)
    external onlyOwner
    {
        for (uint i = 0; i < toRemoveAddresses.length; i++) {
            delete whitelist[toRemoveAddresses[i]];
        }
    }

    /**
     * @notice Function with whitelist
     */
    function whitelistFunc() external
    {
        require(whitelist[msg.sender], "NOT_IN_WHITELIST");

        // Do some useful stuff
    }
}

All addresses will be stored in the whitelist variable.

The function addToWhitelist allows the owner to add an array of addresses. Keep in mind that each address in the list will spend about 22904 gas units. To call that function costs 23994 gas units.

The function removeFromWhitelist allows you to remove addresses from the whitelist.

And the function whitelistFunc checks if the address belongs to the whitelist.

Gas spending:

Gas spending for on-chain whitelist

How to Create a Digital Signature Whitelist

The main idea is to create signatures for addresses and check them inside the smart contract.

Digital signature whitelist

You store the whitelist on your server. Before making a call to the smart contract, you should check if the address is in the whitelist or not. If yes, create a signature for the address and pass that signature to the smart contract. Inside the smart contract you have to validate that signature.

Pros:

• No gas for adding or removing addresses from the whitelist.
• No need to interact with the smart contract about the whitelist

Cons:

• Whitelist is located in a database that can be compromised. If the audience trusts the owner of the project, then this is not a problem
• The most expensive price for contract deployment and whitelist validating

Here's the smart contract:

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

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract DigitalSignatureWhitelistContract is Ownable {

    using ECDSA for bytes32;

    /**
     * @notice Used to validate whitelist addresses
               Replace this wallet address to your own!
     */
    address private signerAddress = 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266;

    /**
     * @notice Verify signature
     */
    function verifyAddressSigner(bytes memory signature) private 
    view returns (bool) {
        bytes32 messageHash = keccak256(abi.encodePacked(msg.sender));
        return signerAddress == messageHash.toEthSignedMessageHash().recover(signature);
    }

     /**
     * @notice Function with whitelist
     */
    function whitelistFunc(bytes memory signature) external
    {
        require(verifyAddressSigner(signature), "SIGNATURE_VALIDATION_FAILED");

        // Do some useful stuff
    }
}

How to implement a digital signature

First, you'll need to create a new wallet address. It will be signer address.

ATTENTION: Do not send any funds to that wallet. It will be used only for making signatures.

Let's assume, that the signer wallet address is 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

Specify it in the smart contract here:

address private signerAddress = 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266;

In the root of your web project, create a .env file with private key of that wallet:

SIGNER_PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

Specify only your own public and private keys, because these are publicly known.

Next, create the whitelist database. It can be PostgreSQL, MySQL, MongoDB – any one you want. You can easily add or remove addresses.

Then when it's time to interact with the smart contract, the user clicks a button on your website. You send the request to your server with the user's address.

If the user is in the whitelist, create the signature for the address on your server:

import { ethers } from 'ethers'

export default async function handler() {

  // Whitelist array from you database
  const whitelist = [
    '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
    '0x90F79bf6EB2c4f870365E785982E1f101E93b906',
    '0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65',
    '0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc',
    '0x976EA74026E726554dB657fA54763abd0C3a0aa9',
  ]

  // This variable will contain the signature we need
  let signature = ''

  // Parse params passed to server and get user wallet address
  const userWalletAddress = ''

  if (whitelist.includes(userWalletAddress)) {
    const signer = new ethers.Wallet(process.env.SIGNER_PRIVATE_KEY!)
    const addressHash = ethers.utils.solidityKeccak256(['address'], [userWalletAddress.toLowerCase()])
    const messageBytes = ethers.utils.arrayify(addressHash)
    signature = await signer.signMessage(messageBytes)
  }

  // Return signature to web
}

Then pass the signature to the smart contract function, where verifyAddressSigner will validate it according to the sender's address.

Gas spending:

Gas spending for digital signature whitelist

How to Create a Merkle Tree Whitelist

What is the Merkle tree?

Merkle tree is a tree in which every "leaf" (node) is labelled with the cryptographic hash of a data block, and every node that is not a leaf (called a branch, inner node, or inode) is labelled with the cryptographic hash of the labels of its child nodes. – Source

How does it connect to the whitelist problem?

We will use it to hash all addresses into one root hash.

Merkle tree

This is the schema of work:

Merkle tree whitelist

Like in the digital signature method, you need a database for the whitelisted addresses. When you are ready to start the sale or something else, you need to create the Merkle root hash and save it in the smart contract. This hash will validate all the addresses.

When the user wants to make a request to the smart contract, you need to create a Merkle proof for him, based on the Merkle tree of all addresses. Then you need to send proof to the smart contract. You can store the tree locally.

After editing the whitelist you should update the Merkle root hash and rewrite it to the smart contract. You should also update the local Merkle tree.

Pros:

• Deployment of the smart contract is much cheaper than the digital signature method
• Validating addresses in the smart contract is also cheaper
• No gas for adding or removing addresses from whitelist, until you start a sale

Cons:

• After the sale has started, it will be complicated to change the whitelist. You will need to update the smart contract and Merkle tree each time. Therefore, gas will be spent.
• You need to know how to create a Merkle root and update the smart contact. It's impossible to change the whitelist without interacting with the smart contract.

Here's the smart contract:

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

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";

contract MerkleTreeWhitelistContract is Ownable {

    /**
     * @notice Merkle root hash for whitelist addresses
     */
    bytes32 public merkleRoot = 0x09485889b804a49c9e383c7966a2c480ab28a13a8345c4ebe0886a7478c0b73d;

    /**
     * @notice Change merkle root hash
     */
    function setMerkleRoot(bytes32 merkleRootHash) external onlyOwner
    {
        merkleRoot = merkleRootHash;
    }

    /**
     * @notice Verify merkle proof of the address
     */
    function verifyAddress(bytes32[] calldata _merkleProof) private 
    view returns (bool) {
        bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
        return MerkleProof.verify(_merkleProof, merkleRoot, leaf);
    }

    /**
     * @notice Function with whitelist
     */
    function whitelistFunc(bytes32[] calldata _merkleProof) external
    {
        require(verifyAddress(_merkleProof), "INVALID_PROOF");

        // Do some useful stuff
    }
}

How to implement a Merkle tree on the web

First, create the whitelist database. It can be PostgreSQL, MySQL, MongoDB or any other you want. You can easily add or remove addresses.

When it's time to interact with the smart contract, create a Merkle root hash:

import { ethers } from 'ethers'
import { MerkleTree } from 'merkletreejs'

// Your whitelist from database
const whitelist = [
  '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
  '0x90F79bf6EB2c4f870365E785982E1f101E93b906',
  '0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65',
  '0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc',
  '0x976EA74026E726554dB657fA54763abd0C3a0aa9',
]

const { keccak256 } = ethers.utils
let leaves = whitelist.map((addr) => keccak256(addr))
const merkleTree = new MerkleTree(leaves, keccak256, { sortPairs: true })

// Save this value to smartcontract
const merkleRootHash = merkleTree.getHexRoot()
// 0x09485889b804a49c9e383c7966a2c480ab28a13a8345c4ebe0886a7478c0b73d

Then save the Merkle root hash in the smart contract.

Specify it before the deployment:

bytes32 public merkleRoot = 0x09485889b804a49c9e383c7966a2c480ab28a13a8345c4ebe0886a7478c0b73d;

Or use a function setMerkleRoot for it:

function setMerkleRoot(bytes32 merkleRootHash) external onlyOwner
{
    merkleRoot = merkleRootHash;
}

When the user clicks a button on your website, you send the request to your server with the user's address. If the user is in the whitelist, create the Merkle proof on your server:

import { ethers } from 'ethers'
import { MerkleTree } from 'merkletreejs'

export default async function handler() {

  // Whitelist array from you database
  const whitelist = [
    '0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC',
    '0x90F79bf6EB2c4f870365E785982E1f101E93b906',
    '0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65',
    '0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc',
    '0x976EA74026E726554dB657fA54763abd0C3a0aa9',
  ]

  // This variable will contain the signature we need
  let proof = []

  // Parse params passed to server and get user wallet address
  const userWalletAddress = ''

  if (whitelist.includes(userWalletAddress)) {
    const { keccak256 } = ethers.utils
    let leaves = whitelist.map((addr) => keccak256(addr))
    const merkleTree = new MerkleTree(leaves, keccak256, { sortPairs: true })
    let hashedAddress = keccak256(userWalletAddress)
    proof = merkleTree.getHexProof(hashedAddress)
  }

  // Return proof to web
}

Then pass proof to the smart contract function, where verifyAddress will validate it according to the sender's address.

Gas spending:

Gas spending for Merkle tree whitelist

Summary

Below you will find a comparison table of the gas units these different methods spend:

Long story short:

• An on-chain whitelist easy to implement, but expensive to use. I would not recommend using it.
• A digital signature whitelist is a universal tool that does not require additional interactions with the smart contract. You can easily edit the whitelist at any time. But you have to pay for versatility. Deployment and function with the whitelist are the most expensive. If your addresses change frequently, then use digital signature.

• Merkle tree is the best option if your whitelist addresses will not change after you start presale or whatever you want. For example, it costs nothing to collect addresses and edit them in your database. When the sale starts, you stop editing the whitelist, create the root hash, save it to the smart contract and that's it. In that case the Merkle tree is better than digital signature.

  What exactly to use is up to you!

Finally, I want to show you how to calculate gas price.

How to calculate gas price

Use the following formula:

(gas units) * (gas price per unit) = gas fee in gwei

Use https://ethgasstation.info/ or any other website to find gas price per unit. At the moment of writing this article, gas price is 22.

Gas price per unit

The value can change depending on the time of day.

Let's calculate how much it will cost to deploy a digital signature smart contract.

Deployment = 486 182 * 22 = 10 696 004 gwei = 0,010696004 ETH

Now since the ETH/USD price is $1,324, it means that deployment to the Mainnet will cost about $14.

Maybe you want to convert the comparison table to USD?
Gas price per unit = 22, ETH = $1,324

Thank you for reading! ❤

Over the past 9 months, several of our instructors have been hard at work on a comprehensive NEAR curriculum. This will focus on NEAR's blockchain protocol and the NEAR tool ecosystem.

This curriculum is made possible by NEAR Foundation, who gave our charity a grant to 100% fund development of this curriculum.

What will it contain?

The curriculum will contain at least ten interactive practice projects that will guide you through learning the NEAR protocol and their tools.

You'll learn how to build and deploy your own smart contracts, dApps, work with NEAR command line tools, and much more. There will also be five challenging integrated projects to test your knowledge.

How will it work?

These courses will run in a docker container using VS Code and the freeCodeCamp Courses extension.

Here's a Sample of the first Project

When Will it be Available?

The courses will be released in batches. As we finish creating a group of projects, typically consisting of two interactive practice projects and one integrated project, they will be released for you to complete. The first group is available now! and consists of these projects:

• Learn How to Set Up NEAR by Building a Hello World Smart Contract
• Learn NEAR Smart Contracts by Building a Word Guessing Game
• Build a Sentence Making Smart Contract

How to Run the Courses

Follow the steps below to run the courses

Developer Environment Prerequisites

Before you get started, make sure you have these installed on your computer:

1. Docker Engine
2. VS Code and the Dev Containers extension
3. Git

How to Run the Curriculum in Docker

Follow these instructions to clone the repo and run the courses:

1. Open a terminal and clone the near-curriculum repo with:

   git clone https://github.com/freeCodeCamp/near-curriculum.git
   

2. Navigate to the near-curriculum directory, and open it in a VSCode workspace with:

   code .
   

3. Press Ctrl / Cmd + Shift + P to open the command palette, and run Dev Containers: Rebuild Container and Reopen in Container. VS Code will build the container to run the projects in, it will take a few minutes the first time.

4. Once it's finished, press Ctrl / Cmd + Shift + P again and run freeCodeCamp: Run Course to start the courses. This will also take a moment.
5. The simple browser will open when it's done. If it's a blank white page, use the refresh button to update it and see the courses home page.
6. Click on one of the available projects to start a project.
7. Follow the instructions to complete the project.
8. Have fun!

If you want to switch projects, click the freeCodeCamp logo at the top to get back to the home page.

Sign up for updates

Fill out this google form to sign up to receive updates when new courses are released.

While You're Waiting

While you are waiting for these courses, you can try the Web3 curriculum (also under development). It will teach you many Web3 and blockchain concepts you will want to know for the NEAR curriculum.

Learn more about NEAR Foundation

You can learn more about NEAR Foundation by visiting their website.

Over the past 11 months, we've made considerable progress on our Web3 curriculum. Today I'm thrilled to say that parts of this curriculum are now in open beta. You can try them today.

Before we get into the details, I want to thank the KaijuKingz community, who made a donation to freeCodeCamp that made development of these courses possible. You can read more about their gift to the freeCodeCamp community here.

How to Approach These Web3 Courses

As a prerequisite for this course, we recommend first learning full stack web development. You can do this by working through the first 7 freeCodeCamp certifications and building their projects:

1. Responsive Web Design
2. JavaScript Algorithms and Data Structures
3. Front End Development Libraries
4. Data Visualization
5. Relational Database
6. Back End Development and APIs
7. Quality Assurance

We also recommend you know some knowledge of basic blockchain development concepts. freeCodeCamp has an in-depth 32-hour course that covers this, taught by developer and instructor Patrick Collins.

We also recommend learning some Rust, which you can learn interactively using freeCodeCamp's Rust course.

Again, these prerequisites are just our recommendations. Feel free to just dive in and return to those resources as you see fit.

Right now, we have designed five integrated Web3 projects for you to complete:

1. Build a Video Game Marketplace Blockchain
2. Build a Fundraising Smart Contract
3. Build a Peer-to-Peer Network
4. Build a Web3 Client-Side Package for your dApp
5. Build a Smart Contract in Rust

Each of these projects has its own set of instructions with tasks for you to fulfill, and tests to ensure you've implemented your project correctly. Complete all the tasks and get all the tests to pass to finish each project.

These 5 projects are just the beginning

We are also developing 10 interactive Web3 practice projects.

These will walk you through all the Web3 concepts you need to know to build these 5 integrated projects we're releasing today.

Why are we releasing the hard part (the 5 integrated projects) first? For the die-hard Web3 enthusiasts who don't mind using watching Patrick's course, reading official documentation, and referencing the many other free Web3 tutorials out there.

Soon it will be a smoother ride for anyone to learn these tools and concepts. But we wanted to first get something out there for the hardcore crowd.

Available interactive projects

As of January 2023, the first group of interactive practice projects is now fully available. They will teach you the concepts you need to know to complete the first integrated project. The new courses are:

1. Learn Digital Ledgers by Building a Blockchain
2. Learn Proof of Work Consensus by Building a Block Mining Algorithm
3. Learn Digital Signatures by Building a Wallet

The Web3 Curriculum is in open beta. We welcome your feedback and bug reports.

Note that these are in open beta – meaning that we will continue to refine them with your feedback.

You can help by joining our new Web3 Curriculum Discord server, introducing yourself, and helping other people who get stuck trying to build these 5 integrated projects.

You can also sign up for updates These will make it a lot easier to build these 5 integrated projects So in a way, you actually doing the hardest, most ambiguos part Sign up for updates below for when new courses are released.

How will it work?

The courses will run in a docker container using VS Code and the freeCodeCamp Courses extension.

Here's a sample

How to Run the Courses

Follow the steps below to run the courses

Developer Environment Prerequisites

Before you get started, make sure you have these installed on your computer:

1. Docker Engine
2. VS Code and the Dev Containers extension
3. Git

How to Run the Curriculum in Docker

Follow these instructions to clone the repo and run the courses:

1. Open a terminal and clone the web3-curriculum repo with:

   git clone https://github.com/freeCodeCamp/web3-curriculum.git
   

2. Navigate to the web3-curriculum directory, and open it in a VSCode workspace with:

   code .
   

3. Press Ctrl / Cmd + Shift + P to open the command palette, and run Dev Containers: Rebuild Container and Reopen in Container. VS Code will build the container to run the projects in, it will take a few minutes the first time.

4. Once it's finished, press Ctrl / Cmd + Shift + P again and run freeCodeCamp: Run Course to start the courses. This will also take a moment.
5. The simple browser will open when it's done. If it's a blank white page, use the refresh button to update it and see the courses home page.
6. Click on one of the available projects to start a project.
7. Follow the instructions to complete the project.
8. Have fun!

If you want to switch projects, click the freeCodeCamp logo at the top to get back to the home page.

Sign up for updates

Fill out this google form to receive updates when new courses are released.

Other Courses

We are also creating courses around the Solana and NEAR protocols.

View the Solana announcement article. View the NEAR announcement article.

Or, check out the web3.freecodecamp.org domain where we showcase all the courses.

Learning a new technology often means learning a new framework, programming language, IDE, or deployment method. And the blockchain is no different.

In this tutorial, I am going to show you how to get started with Truffle, a Node.js blockchain framework, in Visual Studio Code.

How to Install Truffle

To install Truffle you need to have Node and NPM along with Python setup on your machine.

If you do not have them already, you can install them from their official websites (Node and Python). Once you're done with that, you are all set to install Truffle.

We will use npm to install Truffle. Enter the following command in your command prompt:

npm install -g truffle

While the installation runs, if you come across the following error, I have got you covered:

gyp ERR! stack Error: Could not find any Visual Studio installation to use

Google shows a bunch of solutions for the above error. What actually worked for me was installing Visual Studio along with 'Desktop Development with C++'.

After you download Visual Studio and run the installer you will see the following screen:

Under the 'Desktop and mobile' section, check 'Desktop Developement with C++' and continue with the installation process.

Once this is done you can run the Truffle installation command again.

To verify if Truffle is installed successfully, run:

truffle version

in your command prompt. You should see an output like the image below:

Congratulations! You have installed Truffle.

How to Use Truffle in Visual Studio Code

Visual Studio Code comes with it's own extension for Truffle. We will install it to make our work easier.

In the marketplace search bar, type "Truffle for VS Code" and click on install (similar to the image below).

VS Code requires you to have other extensions for it to work, so just check the ones you don't have installed and continue the setup:

If you do not see the Truffle logo in the left bar you might have to restart VS Code.

How to Set Up Ganache in VS Code

Ganache comes with the Truffle suite to deploy DApps.

Click on the 'Networks' > 'Create a new network' in Truffle explorer.

From the dropdown box select 'Ganache service'.

Select type 'local' or 'fork'. Since this a local setup I will select 'local'.

Next, you will be asked to enter your 'local project's name'. Enter any name of your choice and hit enter.

Your network setup is complete.

To start the network, right click on the network name and click on 'Start Ganache'.

When you start the Ganache service, you will see a command line output as follows:

The output displays a set of things to speed up. We do not need to worry about them just yet.

How to Start a Tuffle Project

To start a project in Truffle, go into a directory and type the init command.

truffle init

This will create a new Truffle project.

How to Create a Contract in Truffle

The following commands creates a contract in Truffle:

truffle create contract <contract name>

Here we created a contract named 'SimpleStorage'.

How to Run Tests in Truffle

To run test in Truffle, just enter this command:

truffle test

All the tests will be run one by one.

How to Deploy in Truffle

We will use Ganache to deploy in Truffle.

truffle develop

You use the above command to start the deployment process.

Ganache has some accounts and private key ready for this purpose.

In the above image at the bottom you will see truffle (develop)> console.

Type migrate --reset in the console.

You will see that the initial migrations are made and the deployment process starts. In the end you will get a summary (the cost and number of deployments) of the deployment.

Conclusion

We progress more quickly when we can learn from each other's mistake. I have just started learning Blockchain, and it took me a while to get the setup running. So here I am sharing my findings. Happy learning!

We just published a 30-hour course on the freeCodeCamp.org YouTube channel that will help you learn skills related to blockchain, Solidity, and Web3 development.

If you are interested in learning about blockchain development, this is the course for you. You will learn how to implement the concepts and technologies using JavaScript.

Patrick Collins developed this course. He is a veteran software engineer and finance industry developer. He also previously created one of the most popular blockchain courses on the Internet.

This course will give you a full introduction into all of the core concepts related to blockchain, smart contracts, Solidity, full-stack Web3 dapps, decentralized finance (DeFi), Chainlink, and more.

This is one of the most cutting-edge and in-depth Web3 / smart contract tutorials out there.

Here are the sections in this course:

• Blockchain Basics
• Remix and Simple Storage
• Remix Storage Factory
• Ethers.js Simple Storage
• Hardhat Simple Storage
• HTML / Javascript (Full Stack / Front End)
• Hardhat Smart Contract Lottery
• NextJS Smart Contract Lottery (Full Stack / Front End)
• Hardhat Starter Kit
• Hardhat ERC20s
• Hardhat DeFi & Aave
• Hardhat NFTs
• NextJS NFT Marketplace (Full Stack / Front End)
• Hardhat Upgrades
• Hardhat DAOs
• Security & Auditing

Watch the full course below or on the freeCodeCamp.org YouTube channel (32-watch).