What is the Commit Reveal Scheme?

The commit-reveal scheme is a type of commitment scheme that can be used to store values in a smart contract and keep them secret until you choose to reveal them later.

One common example of this is Delayed reveal NFT collections; where users mint NFTs, but the underlying data (such as the image, name, traits, etc.) of those NFTs are not revealed until later.

In this post, we'll use the popular rock paper scissors game as an example of how and why you might want to implement this paradigm into your smart contracts.

How Does the Commit Reveal Scheme Work?

As the name suggests, the commit reveal scheme uses a two-step process:

1. Commit: write the data to the smart contract, but keep it hidden; by hashing the data itself along combined with a secret phrase, i.e. hash(data, secret).

2. Reveal: later, reveal the data by providing the same data and secret values. If the hash of the newly provided data and secret value is equal to the hash of the original data and secret value, then the data is revealed.

For example, in a game of rock paper scissors, we want to submit our move inside a transaction without the other player knowing what move we made; otherwise, they could easily win every game by inspecting the move from our transaction.

Instead, we create a secret key or password and hash the combination of these two values. Using solidity, we can achieve this by using keccak256 and abi.encodePacked:

// Generate a hash of the combination of the data and secret
bytes32 hash = keccak256(
    abi.encodePacked(
        "scissors" // Our move
        bytes32("player1-secret") // Our secret key or password
    )
);

Now, we can safely store this information inside of the smart contract. Other people will be able to see the hash value, however, they won't be able to decode it; as they don't know our secret value.

Only users who know both our original move and our secret key will be able to reveal our commitment at a later time; since the hash output of data and secret will always be the same value.

This also means we cannot change our data later; for example, we can't change our move from scissors to paper, since the output of hash(paper,secret) will be different to hash(scissors,secret); i.e. we "committed" to our answer.

Later, for example, when both players have committed their move in rock paper scissors, we can safely reveal our commitment; by providing both the original data and the secret key to produce the same hash, for example:

// Produce a new hash by providing the value and secret we did originally
bytes32 newHash = keccak256(
  abi.encodePacked(newMove, newSecret)
);

// If hash(newMove, newSecret) == hash(originalMove, originalSecret), reveal!
require(
  hash == newHash, "Wrong move or wrong pasword: Hashes do not match."
);

At this point, if the two hashes match, the move provided in the reveal phase (newMove in the code snippet above) is the "revealed" data; the user has decoded their hash by proving that they know the secret as well as the original move.

To summarise, the commit-reveal scheme is a two-step process effective for storing data in a smart contract in a hidden manner that can be revealed later using hashing:

1. Commit: Store a hash of a combination of the data + a secret key

2. Reveal: Provide the data and the secret key to recompute a new hash. If the hash is the same as the hash from the commit phase, the data is revealed.

Wrapping Up

That's a quick introduction to the commit-reveal scheme. For a full code example in Solidity, check out the repository below:

For any questions, feel free to reach out to me on Twitter @jarrodwattsdev.

1. Connect to your application via Coinbase Smart Wallet.

2. Perform transactions from their newly created wallet.

3. Pay no gas fees! Thanks to the power of paymasters to cover user's gas fees.

Below is a quick demo video of what we'll build:

If it sounds like you're in the right place, great! Let's get started!

Setting Up the Project

If you prefer to start from the complete code, the full source code is available on GitHub below, with instructions in the README on how to get started locally.

For those starting from scratch, create a simple Next.js app using npx create next-app:

pnpm create next-app@latest coinbase-smart-wallet-demo --typescript --tailwind --eslint

Next, install the thirdweb React SDK which includes the ConnectButton component:

# Ensure you run the command from the coinbase-smart-wallet-demo directory
pnpm i thirdweb

thirdweb API Key

To instantiate the thirdweb React SDK, you'll need a thirdweb API key To get one:

1. Head to the Settings tab on the thirdweb dashboard.

2. Click + Create API Key.

3. Give your key a name and set the allowed domains.

4. Click Next and copy your app's Client ID.

To keep things brief for the tutorial, I'll store my thirdweb client ID in plain text, however, you should keep the values safe, using environment variables.

Nice! All our setup is done. This gives us everything we need to build our app.

Integrating Coinbase Smart Wallet

We'll break down the Coinbase Smart Wallet integration into three steps:

1. Wrapping our application in the ThirdwebProvider.

2. Adding the ConnectButton component.

3. Showcasing a simple test transaction with a TransactionButton component.

Wrapping the App in the ThirdwebProvider

The thirdweb SDK uses a provider pattern, meaning we wrap our application with a ThirdwebProvider component to use thirdweb SDK features throughout our code.

First, wrap your application in the ThirdwebProvider component like so:

// File: src/app/layout.tsx
import { ThirdwebProvider } from "thirdweb/react";

export default function RootLayout({ children }) {
  return (
      <ThirdwebProvider>
        <body>{children}</body>
      </ThirdwebProvider>
  );
}

Adding the Connect Wallet Button

The thirdweb SDK includes a ConnectButton component that opens a modal and allows users to connect their wallets. We'll use it to show the Coinbase Smart Wallet prompt.

Using the code below, we can render a "Connect Wallet" button that prompts the user to connect to our application using Coinbase Smart Wallet, by:

1. Importing what chain we want to use from the thirdweb/chains package.

2. Rendering the ConnectButton from the thirdweb SDK.

   • Providing your thirdweb client ID to the createThirdwebClient function.

   • Calling the createWallet function with com.coinbase.wallet (Coinbase Wallet).

   • Setting smartWalletOnly to disable the Coinbase Wallet Browser Extension.

// File: /src/app/page.tsx
"use client"; // thirdweb SDK doesn't support server-side rendering yet.

import { createThirdwebClient } from "thirdweb"; // Create the thirdweb client with your client ID
import { ConnectButton } from "thirdweb/react"; // The component we can prompt the user to connect their wallet with
import { createWallet } from "thirdweb/wallets"; // Function to specify we want to use Coinbase smart wallet
import { polygon } from "thirdweb/chains"; // Import the the blockchain you want to use

export default function Home() {
  return (
    <>
      <ConnectButton
        client={createThirdwebClient({
          clientId: "your-thirdweb-client-id-goes-here",
        })}
        wallets={[
          createWallet("com.coinbase.wallet", {
            walletConfig: {
              // Specify we do not want coinbase wallet browser extension support, just smart wallet
              options: "smartWalletOnly",
            },
            chains: [polygon],
          }),
        ]}
      />
    </>
  );
}

That's all we need for our Coinbase Smart Wallet integration! 🎉 To see it in action, run pnpm run dev and visit http://localhost:3000/ in your browser and try it out:

Submitting Transactions from Coinbase Smart Wallet

Next, let's showcase a simple smart contract interaction with this connected wallet.

For this tutorial, I've deployed a simple Edition Drop smart contract using the thirdweb dashboard. This ERC-1155 NFT smart contract (deployed here) allows users to mint NFTs for free; perfect for us to showcase Coinbase Smart Wallet.

If you want to follow the same steps, you can:

1. Deploy an Edition Drop smart contract.

2. Select the NFTs tab and lazy mint metadata for an NFT.

3. Set up a free, public claim phase for your NFT.

Beneath our ConnectButton, let's add a TransactionButton so users can submit the transaction of minting an NFT from the drop from their Coinbase Smart Wallet.

First, import some relevant functions and components we'll be using from thirdweb:

import { TransactionButton, useActiveAccount } from "thirdweb/react";
import { claimTo } from "thirdweb/extensions/erc1155";
import { getContract } from "thirdweb";

Let's also abstract out the chain and thirdweb client into variables:

// You can safely place these *outside* of the component
const thirdwebClient = createThirdwebClient({
  clientId: "your-thirdweb-client-id-goes-here",
});

const chainToUse = polygon;

Get the address of the connected Coinbase Smart Wallet using useActiveAccount:

// Place this *within* the component
const account = useActiveAccount();

Then, render the TransactionButton component beneath the existing ConnectButton component. We can use the getContract function to connect to our smart contract, and call the claimTo function to claim/mint an NFT from the drop:

<TransactionButton
  transaction={() =>
    claimTo({
      contract: getContract({
        client: thirdwebClient,
        chain: chainToUse,
        address: "0x-your-smart-contract-address-goes-here",
      }),
      quantity: BigInt(1), // Mint 1 NFT
      to: account?.address, // To the connected Coinbase Smart Wallet address
      tokenId: BigInt(0), // Of NFT with token ID of 0
    })
  }
  payModal={false} // Disable the FIAT on-ramp dialogue (optional)
>
  Mint NFT
</TransactionButton>

Let's test out this transaction button on http://localhost:3000/ now:

😱 Oh no! Our users don't have any funds in their wallets to pay for these gas fees... if only there was a way to cover our user's gas fees somehow! 😉

Sponsoring User Gas Fees with a Paymaster

Paymasters are a feature of ERC-4337 account abstraction, which is how Coinbase Smart Wallet works under the hood (a topic for another blog post).

They allow the gas fee of a transaction to be "sponsored" (paid for) by a different wallet than the one submitting the transaction; typically, the developer of the application sponsors the gas fees of user transactions.

The thirdweb SDK provides specific EIP-5792 hooks for us to accomplish this sponsorship. Let's first import the one we're going to use, useSendCalls:

import { useSendCalls } from "thirdweb/wallets/eip5792";

Then, let's refactor the claiming code we wrote previously into a new, separate function, so we can include some paymaster logic:

async function sendSponsoredTransaction() {

  // Our existing claim code placed here in a claimTx variable
  const claimTx = claimTo({
    contract: getContract({
      client: thirdwebClient,
      chain: chainToUse,
      address: "0x-your-smart-contract-address-goes-here",
    }),
    quantity: BigInt(1),
    to: account?.address,
    tokenId: BigInt(0),
  });
  // End existing code

  return await sendCalls({
    calls: [claimTx], // We can even put multiple transactions here
    capabilities: {
      // We cover the gas fees of the transaction for the user!
      paymasterService: {
        // Docs: https://portal.thirdweb.com/connect/account-abstraction/infrastructure
        url: `https://${chainToUse.id}.bundler.thirdweb.com/${thirdwebClient.clientId}`,
      },
    },
  });
}

Finally, modify the TransactionButton from earlier to call the sendSponderedTransaction function, instead of directly calling the claimTo function, like so:

<TransactionButton transaction={() => sendSponsoredTransaction()}>
  Mint NFT
</TransactionButton>

Sponsoring Transactions on Mainnet

On testnets such as Base Sepolia (baseSepoliain the thirdweb chains package), it's free to cover the gas fees of users with the thirdweb SDK.

To sponsor transactions on mainnet environments, however, real funds are being used. Therefore, you need to provide a credit card on the billing tab of the thirdweb dashboard to pay for these fees. Note: you don't need to upgrade to the growth tier.

You can read more details on thirdweb's bundler documentation.

Configuring Sponsorship Rules

When dealing with real funds (if you're using mainnet), you want to ensure you are only covering the fees of specific transactions that you want to sponsor, not just any transaction!

Thankfully, thirdweb makes this easy to configure from the dashboard within the account abstraction configuration section. This allows you to specify exactly what chains, smart contracts, and wallets you want to cover the gas fees for.

For example, I configured my sponsorship rules to:

• Only sponsor transactions on the Polygon chain.

• Only sponsor transactions interacting with my NFT smart contract.

Alright! We're finally done! Let's see the final demo in action:

Wrapping Up

That's it! We've built a simple application where anybody can mint an NFT for free; without setting up a wallet, writing down seed phrases, or paying any gas fees!

Got questions or feedback? Reach out to me on Twitter @jarrodwattsdev

But, with great power, comes great responsibility, and with the blockchain trilemma in mind, these L2 scalability gains currently come at the cost of weaker decentralization and security, along with added complexity.

In this post, we'll cover a key component of rollups called sequencers, how they work, the pros and cons of different kinds of sequencers, and finally explore a relatively new concept called shared sequencers. Let's dive in.

What is a Sequencer?

If you clicked on this post I'm going to assume you're already familiar with L2s, rollups, sequencers, and all the rest. But just so we're on the same page, let's do a quick definition of what we're talking about here.

If you're interested in a deep dive into a specific L2 and each of its components, check out my previous blog on zkEVMs:

Rollups consist of several components. While each of them is slightly different, each of them shares key components, such as the:

• Sequencer: Picks up transactions from the L2 mempool, decides whether to execute or discard them and broadcasts this information to other nodes.

• Layer 1 Rollup Contract: A smart contract living on Ethereum, that receives batches of transaction data that occurred on L2. It also receives proofs (either fault proofs for optimistic rollups, or ZK proofs for ZK rollups) to verify batches.

The above diagram is a simplified version of a rollup's architecture. At a high level, it's how rollups operate; arguably the most important component of the entire system is the sequencer, because of its two critical responsibilities:

1. Read transactions from the mempool and execute or discard them. Without the sequencer, none of the rollup's transactions would be handled at all.

2. Batch transactions up together, and ship them to Ethereum. Without the sequencer, there would be no "rolling up"; it is responsible for sending all of the transaction data that occurred on L2 to Ethereum.

Next, let's look closer at how these sequencers work in today's rollup landscape.

Different Kinds of Sequencers

Sequencers come in different shapes and sizes. Each rollup (Polygon zkEVM, Linea, Base, Optimism, etc.) utilizes its own unique sequencer. In this section, we're going to explore the different implementations of sequencers that exist today.

Centralized Sequencers

Centralized sequencers are the most common kind of sequencer that rollups use today. They're used by Optimism, Abritrum One, Base, zkSync Era, Linea, Polygon zkEVM, Scroll, and more.

To simplify things, a centralized sequence is software that fetches transactions from the mempool, checks if they're valid, and then puts valid ones into a batch to send to Ethereum. This type of sequencer is labelled "centralized" because it:

1. Is usually maintained by the core devs of the rollup team

2. Likely operates on a centralized server

3. Uses a single account to post batches to Ethereum

The Benefits of Centralized Sequencers

Unlike blockchains or other decentralized systems, a centralized sequencer's only real concern is the efficiency of its software, and the hardware it's running on; it has no concern for how decentralized it is.

While "centralized" comes with negative connotations, a centralized sequencer provides the highest performance by providing users near-instant finality at the L2 level in a consistent manner and reliably submitting valid batches of transactions to Ethereum.

This arguably provides the best experience for users. It provides the fastest way to approve user transactions (which is a high priority for most people) and enables users to withdraw their funds more quickly from L2s in the case of zkEVMs; as the batches submitted by the trusted sequencer are likely going to be valid ones.

While centralized sequencers may provide a great UX, some people believe it undermines the benefits of building decentralized applications. If such an important component is centralized, then why even use a decentralized system in the first place?

The Downsides to Centralized Sequencers

With high scalability, comes the delicate balancing of decentralization and security, or something like that... As you can imagine, maxing out your scalability skill leaves you vulnerable to other downsides.

If a centralized sequencer goes down, the rollup effectively stops doing its job entirely. It stops handling transactions from users on the L2 and also stops sending batch data back to Ethereum.

This isn't a wild "what if" scenario either. This happened recently during the Inscriptions craze on Arbitrum's L2. The sequencer "stalled", and the network suffered 78 minutes of downtime because of the centralized sequencer setup.

In addition, because the centralized sequencer handles all of a rollup's transactions, it's up to the centralized sequencer to determine what MEV is extracted and in what ways it benefits itself with the information of these incoming transactions (such as frontrunning for example).

With this level of power, you might also wonder what's stopping a sequencer from censoring transactions it doesn't want to go through. Most rollups have a mechanism that allows users to bypass the sequencer and "force" their transaction, however, at this point, these mechanisms are often disabled while the systems mature.

Decentralized Sequencers

The distinction between centralized sequencers and decentralized sequencers is comparable to centralized networks and decentralized ones like blockchains (which you've probably heard thousands of times by now).

As the name suggests, a decentralized sequencer uses a decentralized network of nodes to perform the responsibilities of the sequencer we discussed in the previous section.

An example of a layer 2 blockchain that implements a decentralized pool of sequencer nodes is Metis. Metis implements this by tapping into its existing decentralized P2P validators and block producer network and randomly selecting and rotating what sequencer node performs these responsibilities.

Without being too verbose, this essentially has the reverse effects of centralized sequencers. Where centralized sequencers shine is where decentralized sequencers lack, and vice versa.

It is more time-consuming, less consistent, and likely more expensive to call upon a decentralized network of nodes to act as a sequencer, but does not have the single point of failure that centralized sequencers do.

Shared Sequencers

Shared sequencers such as Espresso and Astria allow multiple rollups to share a single decentralized network of sequencers.

Shared sequencers are a network that sits in the middle between L2 and Ethereum L1 that anyone can permissionlessly utilize as a decentralized sequencer for their rollup. They're almost like a decentralized sequencer as a service.

A key differentiator here between decentralized sequencers and shared sequencers is that shared sequencers serve multiple blockchains rather than just one and shared sequencers are actually blockchain networks themselves.

For example, the Astria Shared Sequencer describes itself as "a decentralized network of nodes utilizing CometBFT that come to a consensus on an ordered set of transactions (ie. it is a blockchain)". Source ↗

A key selling point for shared sequencers is that they introduce interoperability advantages between rollups, providing additional value to users using rollups that opt-in to a decentralized shared sequencing layer.

For example, Espresso describes how users can express atomic dependencies between transactions across different rollups, enabling many new use cases such as cross-rollup DEX arbitrage.

Based Rollups

Rollups such as Taiko are implementing an alternative strategy for decentralized sequencing which Justin Drake coined "based" (not to be confused with the Base rollup) in this post.

Based rollups or L1-sequenced rollups utilize Ethereum's decentralization by rolling up multiple transactions off-chain (as any L2 does) and sending them as a single transaction to Ethereum.

Imagine decentralized sequencing, but instead of a separate blockchain, it relies just uses Ethereum to handle both the secure recording of transaction data and the enforcement of consensus rules.

The downside to this approach is that most of the limitations that the L1 has, such as transaction confirmation delays (with caveats via restaking), block times, transaction ordering, and data availability throughput are all inherited as limitations in the based rollup.

So, What's The Best...?

TLDR: It's up to you. As either a user or developer (or both), you're going to have different preferences from others.

Some developers want their users to have the fast experiences that rollups like Base or Polygon zkEVM currently offer by utilizing centralized sequencers, whereas others may prefer to have stronger decentralization at the cost of speed.

In general, my opinion is that we're always going to see a trend where these solutions start by sacrificing decentralization for performance, and then over time become more decentralized while maintaining that level of performance. This is true more broadly in web3 than for just sequencers too.

It's valuable to know the tradeoffs that are being made to power your experience in the L2 world and make your own decisions based on your preferences.

Want more content like this?

I usually post stuff like this on my Twitter first. If you enjoyed this content check out my Twitter @jarrodwattsdev for more educational web3 content.

By the end, you'll have a Docker container running Kafka that captures all blockchain events that you specify, along with references for how to transform and consume this data inside applications!

Let's do this!

How It Works

The architecture of the Chain Indexer Framework can be broken up into three parts:

1. Block Producers: Scan the blockchain and publish raw block data into Kafka.

2. Transformers: Shape the raw data from Kafka into meaningful events.

3. Consumers: Read the transformed data for various use cases such as from a frontend application or an API endpoint.

We're going to first set up our Kafka instance inside a Docker container, then run one script written in TypeScript for each of the three components.

Architecture Diagram

The producer reads data from the specified blockchain and publishes it into our Kafka instance running in a Docker container. At the same time, it also keeps the most recent blocks inside Mongo DB in case of reorgs.

Once it's stored in Kafka, we're able to transform it into more meaningful data, and also make it available for any consumer(s) to read; such as applications.

Setting Up the Backend Infrastructure

Before we create each of the three services (producer, transformer, consumer), we need to set up the infrastructure required to connect to the blockchain and store data. In this section, we'll set up the following services:

1. An RPC to connect to the blockchain

2. A Docker container running Kafka to store raw data

3. A Mongo database for storing the most recent blocks.

Let's first create a new directory to contain all of the work we're about to do:

# Create our base directory
mkdir chain-indexer-framework-guide

# Change into this new directory
cd chain-indexer-framework-guide

# Open in VS Code
code .

Creating the Docker Compose File

Now we're here, let's set up our Docker container by creating a Docker Compose file.

The Docker Compose file allows us to define our app's environment. To create one, let's create a docker-compose.yml file within this current directory.

Within docker-compose.yml, set up the following compose file:

---
version: "3"
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.0.0
    hostname: zookeeper
    container_name: zookeeper
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000

  broker:
    image: confluentinc/cp-kafka:7.0.0
    container_name: broker
    ports:
      - "9092:9092"
    depends_on:
      - zookeeper
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: "zookeeper:2181"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_INTERNAL:PLAINTEXT
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092,PLAINTEXT_INTERNAL://broker:29092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1

We won't cover all of the fields in this guide (learn more about compose files), but this file will allow us to run a Docker container with Apache ZooKeeper for maintaining configuration information and Apache Kafka to store our raw data.

Running the Docker Container

Now we've defined our compose file, let's run the Docker container.

Use Docker Compose's "up" command with the -d flag to run the container in detached mode.

docker-compose up -d

Run the docker ps command to view the status of all containers:

You can also run Docker Desktop to see the container running:

Now our Kafka instance is up and running, we're ready to store raw data from the blockchain. However, to read blockchain data, we'll need a way of connecting to the chain itself; so let's create a new RPC node next.

Creating the RPC Node

There are many solution providers that provide RPC connections to blockchains. In this guide, we'll use a popular RPC provider, Alchemy as our RPC provider as they provide a generous free tier.

To get started, head to the Apps page of your Alchemy Dashboard and click Create New App:

Select the chain and network you want to read data from and click Create app:

We'll come back to this later to grab our RPC URL when we write the producer.

Creating A Mongo DB

Next, let's set up a database to do TODO.

In this guide, we'll use Mongo DB, as the Chain Indexer Framework's Producer has a mongoUrl property we can easily plug this database into.

Sign up to Mongo DB if you haven't already, and deploy a new database.

Below are the options that I chose; but you can customize this to your preferences:

Once your database is provisioned, complete the setup process.

First, add an authentication method; in this guide, we're using a simple username and password that is auto-generated for us.

Second, configure who can access your database. In this guide, we're simply adding our current machine's IP address. Finally, click Finish and Close.

Finally, the infrastructure setup is complete! 🎉

Setting up Node.js + TypeScript

Now we're ready to set up the three components of the Chain Indexer Framework.

Set up a simple TypeScript + Node.js project by running the following command:

npm init -y

To add TypeScript, create a tsconfig.json file with the following contents:

{
  "compilerOptions": {
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "esModuleInterop": true,
    "target": "ES2020",
    "sourceMap": true,
    "strict": true,
    "outDir": "dist",
    "declaration": true
  },
  "include": ["src/**/*"]
}

Set the package.json file to the following:

{
  "name": "producer",
  "version": "1.0.0",
  "type": "module",
  "main": "index.js",
  "scripts": {
    "build": "tsc",
    "start-producer": "npm run build && node --experimental-import-meta-resolve --trace-warnings dist/producer.js",
    "start-transformer": "npm run build && node --experimental-import-meta-resolve --trace-warnings dist/transformer.js",
    "start-consumer": "npm run build && node --experimental-import-meta-resolve --trace-warnings dist/consumer.js"
  },
}

Install the required TypeScript dependencies:

npm install -D typescript @types/node

Before installing further dependencies, you'll need to follow the installation instructions of node-gyp as a pre-requisite to installing the @maticnetwork/chain-indexer-framework package. If you're on Windows, this includes installing a current version of Python and the Visual C++ Build Environment in Visual Studio.

Next, install the @maticnetwork/chain-indexer-framework package by running the following:

npm install @maticnetwork/chain-indexer-framework

Finally, create a src folder, containing three files:

• producer.ts

• transformer.ts

• consumer.ts

Now we're ready to go. Let's start with the producer.

Creating the Producer

Inside the producer.ts file, we're going to connect to the blockchain you selected in the RPC step and write raw data to Kafka.

Below is the barebones code to start storing raw data in Kafka. Mongo DB is used to store the most recent number of blocks (specified in the maxReOrgDepth field) before they become permanent inside Kafka.

import { BlockPollerProducer } from "@maticnetwork/chain-indexer-framework/block_producers/block_polling_producer";
import { produce } from "@maticnetwork/chain-indexer-framework/kafka/producer/produce";

const producer = produce<BlockPollerProducer>({
  startBlock: 50689834, // Pick any start block you want
  rpcWsEndpoints: ["<your-alchemy-rpc-url-here>",],
  blockPollingTimeout: 20000,
  topic: "polygon.1442.blocks",
  maxReOrgDepth: 256, // Maximum reorg depth on Polygon is 256
  maxRetries: 5,
  mongoUrl: "mongodb+srv://<your-mongo-username>:<your-mongo-password>@chain-indexer.0ymaemb.mongodb.net/",
  "bootstrap.servers": "localhost:9092",
  "security.protocol": "plaintext",
  type: "blocks:polling",
});

producer.on("blockProducer.fatalError", (error: any) => {
  process.exit(1); //Exiting process on fatal error. Process manager needs to restart the process.
});

Importantly, you need to:

• Add your HTTPS Alchemy RPC URL in the rpcsWsEndpoints field.

• Add your Mongo URL connection string as the mongoUrl.

• Optionally, configure the other properties to your preferences.

When you're ready, you can run the following command to start the producer:

npm run start-producer

If everything's working as expected, you should begin to see some data appear in Mongo DB, which you can find in the Database > Collections section:

Adding Logging

The Chain Indexer Framework also comes with logging capabilities to see what's happening behind the scenes. To add it to your producer, first import the Logger:

import { Logger } from "@maticnetwork/chain-indexer-framework/logger";

And optionally add logs to any events emitted by the producer, for example:

producer.on("blockProducer.fatalError", (error: any) => {
  Logger.error(`Block producer exited. ${error.message}`);
  process.exit(1); //Exiting process on fatal error. Process manager needs to restart the process.
});

Transforming & Consuming Data

Now we have raw data available inside our Kafka instance! You're ready to begin transforming and consuming data in your applications.

Although there's a decent chunk of code to get started with these steps, we've already layed the foundation for everything, so it should be relatively simple!

Rather than dumping all the code for you to copy & paste, we've made a few open-source examples of how to setup different kinds of transformers and producers on GitHub linked below.

• MATIC Transfer Example

• NFT Balance Example

If you're unfamiliar with ZK proofs or Validiums, I have also written blogs previously that will help you understand these topics in more depth, linked below:

• How do ZK Proofs and ZK-EVMs work?

• What are Validiums?

By the end of this guide, you'll be operating your very own chain, including a faucet, block explorer, RPC, bridge, and more; powered by Polygon CDK.

As a bonus, I'll also showcase the process of deploying a smart contract to the chain, and finally, creating an application to interact with your smart contracts.

Let's do this!

What is Polygon CDK?

Polygon Chain Development Kit (CDK) enables you to build your own ZK-powered Layer 2 blockchain that is custom-fitted to your needs. It provides a way for you to easily create and operate your own "app chain" (application-specific chain).

The fastest way to do this is by using an implementation provider; a platform that provides interfaces built on top of the CDK to help you configure and deploy a chain. In this guide, we'll use an IP called Presto to easily ship our own chain.

Polygon CDK is already powering a number of companies by providing the infrastructure to launch ZK-powered L2s; including Canto, Immutable, Palm, Astar, and more.

As part of the Polygon 2.0 vision, the chains launched via the CDK will be connected via the interop layer, tapping into the existing ecosystems and liquidity available of all the other CDK-powered chains, including Polygon PoS and Polygon zkEVM.

Learn More ↗

Deploying The Rollup

In this guide, we'll use Presto, a RaaS (rollup-as-a-service) platform utilizing Polygon CDK under the hood to deploy our chain with infrastructure deployed to AWS.

To get started, head to Presto and sign up.

Once onboarded, Presto will take you to the dashboard page, where you can click "Add new" to kickstart the process of configuring and deploying your chain.

At the time of writing, the only available option is to deploy the ZK-Validium. However, CDK will soon support zkEVM rollups too! For now, let's select "Private zk-Validium":

Next, we need to decide how/where we want to deploy the infrastructure (such as the nodes, prover, aggregator, sequencer, etc.).

In this guide, we'll use the pre-configured option, "Stockholm", which handles all of the deployment steps for us and runs on AWS.

The deployment process can take up to a few hours to fully complete; in the background, all of the infrastructure and compute resources are being deployed to AWS.

RPC, Bridge, Block Explorer, Faucet, and More

All of the developer tooling required to utilize your rollup is also deployed for you! The RPC, chain ID, bridge, block explorer, and even a faucet are all deployed for you out of the box; making it super simple to get started developing on it.

You can also view the smart contracts that get deployed for data availability (DA), and the rollup smart contract where batches of transactions are sequenced and verified on Ethereum (layer 1).

That's it for the deployment step!

Now, let's deploy our first smart contract to our newly created validium.

Deploy a Smart Contract to Your Custom Chain

A big benefit of the CDK is that it allows you to create chains that are EVM-compatible; meaning you can use all of the methods you're already familiar with to develop your smart contracts, such as Hardhat, Solidity, MetaMask, etc.

The Presto dashboard provides you with the chain ID and RPC URL that you can connect your wallet with and deploy smart contracts to. If you've ever deployed to Polygon before, you're likely already equipped with the skills to deploy to your rollup.

In this guide, I'll show you my favourite way to deploy Solidity smart contracts, using thirdweb from a Hardhat project.

Create a New Solidity Project

First, let's create a new Solidity project by running the following command from the terminal:

npx thirdweb@latest create contract

This command allows you to configure and instantiate a new project with your preferences of tooling, such as Forge or Hardhat and sets us up with a simple smart contract to deploy. Below are the options I selected for the project:

Inside the project, you'll find a Contract.sol file that you can modify. For this guide, I've written a simple Greeter smart contract with the following contents:

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

contract Greeter {
    string private greeting;

    constructor(string memory _greeting) {
        greeting = _greeting;
    }

    function greet() public view returns (string memory) {
        return greeting;
    }

    function setGreeting(string memory _greeting) public {
        greeting = _greeting;
    }
}

Deploy the Smart Contract

Let's go ahead and deploy this smart contract to the validium we just created. To do that, let's run the command below from the directory of our smart contract:

npx thirdweb@latest deploy

This will first prompt you to link your device to your thirdweb account, and then open a URL for you to configure the constructor parameters of your smart contract:

We need to change the chain we're deploying on to be the validium we just deployed. Click on the network name (e.g. Mumbai) to open up the network modal and click Add Custom Network:

This will allow you to add your validium's network details into the thirdweb dashboard. Map up the chain ID, URL and network name to the corresponding fields. In the screenshot below, I've color-coded each field to help you out:

Ensure you set your custom network as the chain you'd like to deploy to, which will subsequently prompt your wallet to switch across to this network:

We'll also need some funds on our validium so we can cover the gas fees of deploying our smart contract. On the Presto dashboard, you should see a URL for a faucet, where you can send funds to test with to your wallet:

Open up the faucet website and paste your wallet address into the field like so:

Finally, click Deploy Now on the thirdweb dashboard to deploy your smart contract:

That's it! 🥳 We just shipped our smart contract! We can even use our own block explorer to confirm it. Go ahead and copy the address of our smart contract:

Open up the block explorer that was deployed for us from the Presto dashboard:

And we can indeed see our contract was deployed successfully! 🚢🎉

Creating a dApp on your Custom Chain

Now we've deployed our smart contract, let's see how we can create an application that interacts with the smart contract we just deployed.

You can use any tools you like to do this, but in this guide, we'll use the thirdweb React SDK to easily connect to our custom chain from a front-end environment.

To create a new application with the thirdweb React SDK pre-configured, run the following command, (from a new directory):

npx thirdweb@latest create app

This command allows you to interactively choose the frontend language and framework you prefer. Below are the options I selected for my app:

Setting Up the thirdweb API Key

To use thirdweb's RPC infrastructure, you'll need to get a thirdweb API key from the Settings tab of the thirdweb dashboard. Click Create API Key to get started (free):

In the root of your project, create a new environment variables file (.env.local) and add the following:

NEXT_PUBLIC_TEMPLATE_CLIENT_ID=your-api-key-client-id-here

Connect to your Custom Chain

Now we've got our API key set, we can connect to our custom chain via the RPC.

Inside the _app.tsx file, you can see the active chain is currently set to ethereum:

// This is the chain your dApp will work on.
const activeChain = "ethereum"; // <------- Let's change this!

We need to change this to be set to our own custom network details, which we can do by following the custom EVM chains section of the thirdweb docs. Let's change ethereum to a new object containing our network details, like so:

const activeChain = {
  // Chain id from Presto
  chainId: 1571747963,
  // RPC URL from Presto
  rpc: ["https://cranegeode-rpc.eu-north-2.gateway.fm"],
  // Name of your rollup in various forms that you want it to appear
  shortName: "cranegeode",
  slug: "cranegeode",
  chain: "cranegeode",
  name: "Crane Geode",
  // Testnet flag, set this to true!
  testnet: true,
  // Details of the token used for gas on your chain.
  nativeCurrency: {
    name: "Ether",
    symbol: "ETH",
    decimals: 18,
  },
  // Optional, the block explorer for wallets to view transactions.
  explorers: [
    {
      name: "blockscout",
      // Block Explorer, Explorer URL from Presto
      url: "https://cranegeode-blockscout.eu-north-2.gateway.fm/",
      standard: "EIP3091",
    },
  ],
};

Now our application can interact with smart contracts deployed to our custom chain!

Reading & Writing Data on the Smart Contract

Finally, we can demo interacting with the smart contract we deployed. On the homepage, (index.tsx), we can use the Web3Button component to:

1. Prompt users to connect their wallet

2. Prompt users to add & connect to our custom chain

3. Call a function on our smart contract from the user's wallet.

Below is some simple demo code to read and write data from the smart contract:

import { Web3Button, useContract, useContractRead } from "@thirdweb-dev/react";

// Your smart contract address (from the thirdweb dashboard)
const contractAddress = "0x33341719456e9d506bcFDbC3afcC5A6882230566";

const Home = () => {
  // Connect to your contract via the contract address
  const { contract } = useContract(contractAddress);
  // Read the current greeting on the smart contract
  const { data, isLoading } = useContractRead(contract, "greet");

  return (
    <>
      {isLoading ? ( <p>Loading...</p> ) : ( <h1>{data}</h1> )}

      <Web3Button
        contractAddress={contractAddress}
        action={(contract) =>contract.call("setGreeting", ["Hey!"])}
      >
        Set Greeting
      </Web3Button>
    </>
  );
};

export default Home;

Run npm run dev and visit localhost:3000 to preview your demo application:

Voilà! 💅You just built a full-stack application on your own layer 2 blockchain.

Wrapping Up

Polygon CDK allows anyone to launch their own L2 chain, powered by the industry-leading ZK technology of Polygon.

In this guide, we've walked through the process of:

• Launching our own ZK-Validium L2 blockchain

• Deploying a smart contract to our own custom chain

• Building a dApp to interact with our custom chain smart contracts

You can access the full source code of this demo on GitHub, and follow me on Twitter for more content like this!

But how exactly does that work? What information gets sent back to Ethereum? And how does this enable Polygon zkEVM to inherit the security of Ethereum?

In this post, we'll take a closer look at exactly what is happening under the hood, covering how transactions:

1. Get submitted to Polygon zkEVM.

2. Are executed almost instantly.

3. Are batched together using data encryption methods.

4. Get sequenced and sent to Ethereum L1.

5. Achieve consolidated finality on L1 with the power of ZK proofs.

Let's do this!

Submitting Transactions

As we explored in the previous post, users are constantly submitting their L2 transactions to the trusted sequencer's node via JSON-RPC interface (typically through wallets like MetaMask).

This allows the Polygon zkEVM to look and feel exactly like Ethereum from the user's perspective when interacting with dApps. Example below:

From the user's perspective, the transactions go through almost instantly, allowing them to continue using dApps immediately after submitting the transaction. This powerful UX benefit is possible because the state of the zkEVM is updated without any information being sent to Ethereum (L1) at first.

However, if users want to bridge funds from L2 (zkEVM) to L1 (Ethereum), essentially performing a withdrawal, the full transaction life-cycle needs to be complete. This requires the PolygonZkEVM smart contract to:

1. Receive the batches from the sequencer (know what transactions to prove).

2. Receive the validity proof from the aggregator (prove the transactions).

See the flow of data in a zkEVM diagram.

From the user's POV at this point, the simplified flow looks like this:

Executing Transactions

After being submitted, the transactions are stored in a pending transactions pool, where they await the sequencer's selection for either execution or discard.

The sequencer makes a few checks to see if it can discard a transaction, based on:

1. If the sender has enough funds to cover the transaction.

2. If the smart contract called exists and has valid/correct bytecode.

3. If the transaction isn't a duplicate.

4. If the transaction isn't a "double-spend", to ensure the sender's funds haven't already been spent in another transaction.

Once the transaction is considered to be valid, the sequencer updates the Polygon zkEVM state, at which point the user experiences the transaction going through almost instantly.

If we modify our diagram to explore under the hood, here's how it looks:

At this point in time, the user continues to interact with the state of the L2. Every step after this is related to posting transaction data back to Ethereum L1; which is only relevant to the user if they want to bridge funds back to Ethereum.

Batching Transactions

After being added to the L2 state, the transaction gets broadcast to all other zkEVM nodes on the network and is ready to be batched up with other transactions.

To batch transactions together, they are concatenated into a single set of bytes in binary form. On the PolygonZkEVM smart contract, a Solidity struct is defined, named BatchData.

Within this struct, a transactions field of type bytes is defined, that contains the encoded batch of transactions concatenated together.

/**
 * @notice Struct which will be used to call sequenceBatches
 * @param transactions L2 ethereum transactions EIP-155 or pre-EIP-155 with signature:
 * EIP-155: rlp(nonce, gasprice, gasLimit, to, value, data, chainid, 0, 0,) || v || r || s
 * pre-EIP-155: rlp(nonce, gasprice, gasLimit, to, value, data) || v || r || s
 * @param globalExitRoot Global exit root of the batch
 * @param timestamp Sequenced timestamp of the batch
 * @param minForcedTimestamp Minimum timestamp of the force batch data, empty when non forced batch
 */
struct BatchData {
    bytes transactions;
    bytes32 globalExitRoot;
    uint64 timestamp;
    uint64 minForcedTimestamp;
}

As you can see in the comments above, the transactions are encoded using "RLP", and can be either EIP-155 or pre-EIP-155 transactions.

• EIP-155 was a proposal created in 2016 by Vitalik to prevent replay attacks. It adds a chainId value to avoid transactions intended for one chain to also work on other chains.

• rlp stands for Recursive-Length Prefix Serialization. It's a data serialization method that Ethereum uses to encode the structure of any arbitrarily nested arrays of data into binary.

As for the other three fields:

1. globalExitRoot: The root of the global exit (Merkle) tree that stores information about asset transfers between L1 and L2. Learn more.

2. timestamp: The time the batch was created.

3. minForcedTimestamp: Only relevant if the user is not using the trusted sequencer (helpful for censorship resistance). Typically set to 0. Learn more.

To update our diagram, let's zoom out and see what the sequencer is up to:

Multiple of these batches get created, according to some size rules that we'll define in the next section as defined on the L1 smart contract. So, let's see what happens with these batches next.

Sequencing Batches of Transactions

Once we have batches of transactions, they're ready to be "sequenced". To do this, the sequencer calls the PolygonZkEVM smart contract's sequenceBatches function (on L1) and provides it with multiple batches of transactions.

This transaction is an example of a sequenceBatch transaction on Ethereum mainnet. By inspecting the input data, we can see the 52 batches of transactions that got included in this particular function call:

Each batch also contains the transactions field that we saw earlier (the concatenated bytes), which concatenates as many RLP encoded transactions as it can fit:

The PolygonZkEVM smart contract has a constant value called _MAX_TRANSACTIONS_BYTE_LENGTH that determines how many transactions can be concatenated together in that field. Source code:

// Max transactions bytes that can be added in a single batch
// Max keccaks circuit = (2**23 / 155286) * 44 = 2376
// Bytes per keccak = 136
// Minimum Static keccaks batch = 2
// Max bytes allowed = (2376 - 2) * 136 = 322864 bytes - 1 byte padding
// Rounded to 300000 bytes
// In order to process the transaction, the data is approximately hashed twice for ecrecover:
// 300000 bytes / 2 = 150000 bytes
// Since geth pool currently only accepts at maximum 128kb transactions:
// https://github.com/ethereum/go-ethereum/blob/master/core/txpool/txpool.go#L54
// We will limit this length to be compliant with the geth restrictions since our node will use it
// We let 8kb as a sanity margin
uint256 internal constant _MAX_TRANSACTIONS_BYTE_LENGTH = 120000;

Similarly, there is a limit to how many batches can be sent as one transaction too, in a constant variable called _MAX_VERIFY_BATCHES. Source code:

// Maximum batches that can be verified in one call. It depends on our current metrics
// This should be a protection against someone that tries to generate huge chunk of invalid batches, and we can't prove otherwise before the pending timeout expires
uint64 internal constant _MAX_VERIFY_BATCHES = 1000;

These batches are provided into a function called sequenceBatches, which accepts:

1. An array of BatchData structs called batches.

2. An address that fees for sequencing batches are sent called l2Coinbase.

function sequenceBatches(
    BatchData[] calldata batches,
    address l2Coinbase
) external ifNotEmergencyState onlyTrustedSequencer {
  ...
}

This function iterates over each batch and ensures they are valid, before updating the virtual state on the L1 smart contract inside a mapping called sequencedBatches:

// Queue of batches that defines the virtual state
// SequenceBatchNum --> SequencedBatchData
mapping(uint64 => SequencedBatchData) public sequencedBatches;

In our diagram, here's where we are at:

The Three Finality States

Now's a good time to introduce the different states a transaction can be in in the Polygon zkEVM. There are different phases of finality that transactions go through:

1. Trusted State: The state is updated on L2. Has not yet reached L1.

   • Most of the time, this is what state users interact with.

2. Virtual State: Batches have been sequenced and data is available on L1.

   • At this point, data is available on L1 for anyone to prove, but is not yet proven.

3. Consolidated State: A ZK proof has been posted on L1.

   • At this point, the data is proven and inherits Ethereum's security.

Learn More ↗

So far, we've talked about the process up to trusted and virtual states, so let's jump into the final phase now, where ZK proofs of computational integrity are submitted to L1.

Aggregating Sequenced Batches

Once all of the sequenced batches have reached L1, the final step is to generate a ZK proof that verifies the validity of these transactions.

Aggregator nodes take the sequenced batches and provide them to the ZK prover, which produces a final SNARK using fflonk protocol. (Quick summary below):

The end result is the aggregator receives a ZK proof that is succinct enough that it can be stored on the Ethereum L1. A simplified diagram of this flow is below:

Once the aggregator node has the proof, it calls the PolygonZkEVM smart contract's verifyBatchesTrustedAggregator function, providing the proof it just received to the function, among other parameters, source code:

/**
 * @notice Allows an aggregator to verify multiple batches
 * @param pendingStateNum Init pending state, 0 if consolidated state is used
 * @param initNumBatch Batch which the aggregator starts the verification
 * @param finalNewBatch Last batch aggregator intends to verify
 * @param newLocalExitRoot  New local exit root once the batch is processed
 * @param newStateRoot New State root once the batch is processed
 * @param proof fflonk proof
 */
function verifyBatchesTrustedAggregator(
    uint64 pendingStateNum,
    uint64 initNumBatch,
    uint64 finalNewBatch,
    bytes32 newLocalExitRoot,
    bytes32 newStateRoot,
    bytes calldata proof
) external onlyTrustedAggregator {
  ...
}

Let's inspect an example transaction again to see how this looks in the real world.

This transaction comes from the trusted aggregator and calls the verifyBatchesTrustedAggregator on the PolygonZkEVM smart contract with the proof:

Details on the other parameters can be found here.

Within this function, another contract called the rollupVerifier has a function verifyProof that gets called. This function is provided with the proof as well as an inputSnark; which is a cryptographic representation of all the L2 transactions of a specific L2 State transition.

// Verify proof
if (!rollupVerifier.verifyProof(proof, [inputSnark])) {
    revert InvalidProof();
}

If the proof is valid, various states are updated like the global exit root and the batchNumToStateRoot mapping containing the consolidated L2 state roots:

// State root mapping
// BatchNum --> state root
mapping(uint64 => bytes32) public batchNumToStateRoot;

Posting and verifying this proof on L1, in this example, took ~350K gas:

With one final update to our diagram, we have achieved a consolidated state on L1!

At this point, the batches of transactions are in the final "consolidated" state, and this is how Polygon zkEVM inherits the security of Ethereum; by posting and proving all transaction data back to Ethereum L1.

Wrapping Up

When interacting with the Polygon zkEVM from a user perspective, transactions are confirmed almost instantaneously, while simultaneously inheriting the security of Ethereum as this entire process occurs under the hood.

This approach provides the best of both worlds, where users have both low gas fees and fast transaction speeds within seconds and can also bridge funds back to Ethereum within ~1 hour using the power of ZK proofs.

In this blog, we've covered the full life cycle of a transaction from the Polygon zkEVM, all the way through to being proved using zero-knowledge on Ethereum L1.

If you enjoyed this content, consider giving me a follow on Twitter!

• What is Polygon dApp Store Kit?

• Why was dApp Store Kit created?

• How to create a web application built on top of the dApp Store Kit.

By the end of the guide, we'll create a fully customizable decentralized app store with our own rules (demo screenshot below). Let's do it!

What Is dApp Store Kit?

dApp Store Kit is an open-source development stack built by Polygon that uses Meroku under the hood; a decentralized app store protocol that acts as a registry for devs to create decentralized app stores on top of.

The registry comes with over 900 decentralized applications out of the box, meaning builders don't have to source and evaluate applications for their store but can instead filter and curate the ones within the registry.

Why dApp Store Kit?

Developers in web3 face a common challenge; it's difficult to have your dApp distributed and discovered by potential users/customers.

This is partially due to the restrictions that today's primary distribution channels have placed on blockchain-based applications and technology. Including:

• Steam: Valve has placed a ban on selling blockchain-based games.

• Apple: Purchases must be made through the in-app purchase system.

Although recent strides have been made in this space including Google Play Store announcing support for NFTs just last month (July 2023), distribution is a pain point for the web3 world.

Rather than release a centralized app store, Polygon created the dApp store kit as a protocol that allows anyone to freely create their own customized decentralized app stores that serve different purposes and have different incentives.

Creating A Decentralized App Store

To create our decentralized app store, we're going to use Next.js; a React framework for creating full-stack web applications, and the @merokudao/storekit-sdk package to use the Polygon dApp store kit.

To keep it short and sweet, I'll cut out the styles and fluff from this guide, but you can view the full source code for the project on GitHub linked below if you prefer.

Creating the Project

To get started, create a new Next.js project using the create-next-app CLI:

npx create-next-app@latest

Below are the options that I chose, however, you can customize these as you prefer:

√ What is your project named? ... dapp-store
√ Would you like to use TypeScript? ... No / Yes
√ Would you like to use ESLint? ... No / Yes
√ Would you like to use Tailwind CSS? ... No / Yes
√ Would you like to use `src/` directory? ... No / Yes
√ Would you like to use App Router? (recommended) ... No / Yes
√ Would you like to customize the default import alias? ... No / Yes

Next, change directories into your newly created project and install the dApp store kit npm package:

# First, change directories:
cd dapp-store

# Install the dApp store kit package
npm i @merokudao/storekit-sdk

Open the project in your text editor, run npm run dev and visit http://localhost:3000/ to preview your application.

Getting Featured dApps

On our homepage, we're going to fetch the featured decentralized applications from the protocol and display them on the homepage. To do this, we'll:

1. Instantiate the DAppRegistryApi from the @merokudao/storekit-sdk package.

2. Call the getDAppV1 method on the DAppRegistryApi to get back an array of dApps.

3. Iterate over the returned array to display each dApp on the UI.

Below is the code to achieve this:

import { useEffect, useState } from "react";
import { DAppRegistryApi, Dapp } from "@merokudao/storekit-sdk";

export default function Home() {
  // State to store the list of dApps
  const [dapps, setDapps] = useState<Dapp[]>();

  // useEffect to fetch the list of dApps and store them in the state
  useEffect(() => {
    (async () => {
      // Base URL for the mainnet API
      const baseURL = "https://api-a.meroku.store";

      // Instantiate the dApp Registry API
      const dAppRegistryAPI = new DAppRegistryApi({
        basePath: baseURL,
      });

      // Get the dApps list, and store it in the state
      const dAppsRequest = await dAppRegistryAPI.getDAppV1();
      const dApps = dAppsRequest.data.response;
      setDapps(dApps);
    })();
  }, []);

  // Display each dApp we stored in state
  return (
    <div>
      {dapps?.map((dapp) => (
        <div key={dapp.dappId}>
          <img src={dapp.images?.logo?.toString() || ""} alt={dapp.name} />
          <p>{dapp.name}</p>
        </div>
      ))}
    </div>
  );
}

With some added styles and some decoration, here's the application so far:

Each dApp returned from the method includes properties such as name, categories, description, images, appUrl, chains, and more. Using each of these properties, you can create fully customizable interfaces for your app store, such as mine below.

(You can copy the source code for this screenshot from the GitHub repo).

The getDAppV1 method also comes with a large number of parameters that allow you to customize what dApps you want to serve in your application:

getDAppV1(
   page?: number,  
   limit?: number,  
   search?: string,  
   isListed?: boolean,  
   chainId?: number,  
   language?: string,  
   availableOnPlatform?: Array<string>,  
   matureForAudience?: boolean,  
   minAge?: number,  
   listedOnOrAfter?: string,  
   listedOnOrBefore?: string,  
   allowedInCountries?: Array<string>,  
   blockedInCountries?: Array<string>,  
   categories?: Array<Array<string>>,  
   orderBy?: string,  
   subCategory?: Array<Array<string>>,  
   options?: AxiosRequestConfig
): Promise<AxiosResponse<InlineResponse200>>;

For example, if we want to limit what dApps we fetch to only show games only built on the Polygon chain, we could add the games filter to the categories parameter and 137 as the chain ID like so:

// Get the dApps list, and store it in the state
const dAppsRequest = await dAppRegistryAPI.getDAppV1(
  1, // page
  10, // page size
  undefined, // search term
  true, // is dapp listed
  137, // Polygon chain ID
  undefined, // language
  undefined, // availableOnPlatform
  undefined, // matureForAudience
  undefined, // minAge
  undefined, // listedOnOrAfter
  undefined, // listedOnOrBefore
  undefined, // allowedInCountries
  undefined, // blockedInCountries
  [["games"]] // categories
);

This changes what dApps come back from the registry allowing us to fully customize our app store experience, for example, we now have a Polygon games store:

Let's convert each of these into a Link that points to the /dapps/[id] dynamic route so that when the user clicks on each dApp it takes them to the page for that dApp:

{dapps?.map((dapp) => (
  <Link href={`/dapps/${dapp.dappId}`} key={dapp.dappId}>
    ...
  </Link>
))}

Creating Individual dApp Pages

Create a new dynamic route using Next.js by creating a new file at /pages/dapps/[dappId].tsx that renders each dApp in more detail.

Using a similar pattern as previously, we can call the apiV1DappSearchDappIdGet method on the DAppRegistryApi class to fetch a specific dApp using its ID, and render it on the UI. Below is a basic example:

import { DAppRegistryApi, Dapp } from "@merokudao/storekit-sdk";
import { useRouter } from "next/router";
import React, { useEffect, useState } from "react";

export default function DappPage() {
  // Get the dApp ID from the URL using Next router.
  const router = useRouter();
  const { dappId } = router.query;

  const [dapp, setDapp] = useState<Dapp>();

  // useEffect to fetch the list of dApps and store them in the state
  useEffect(() => {
    (async () => {
      if (!dappId) return;

      // Base URL for the mainnet API
      const baseURL = "https://api-a.meroku.store";

      // Instantiate the dApp Registry API
      const dAppRegistryAPI = new DAppRegistryApi({
        basePath: baseURL,
      });

      // Get dApp info by ID
      const response = await dAppRegistryAPI.apiV1DappSearchDappIdGet(
        dappId as string
      );

      // Get the dApp out of the response
      const result = response?.data?.data?.[0];

      // Store the dApp in the state
      setDapp(result);
    })();
  }, [dappId]);

  // Render dApp information
  return (
    <main className="container flex flex-col align-middle w-full min-h-screen py-2 pt-20">
      <h1>{dapp?.name}</h1>
      <p>{dapp?.description}</p>
    </main>
  );
}

Utilizing the metadata available and adding some styles, we can create an elegant page for each individual dApp like so (source code):

That's it! We've created a discovery page and a detail page where users can find out more information and the URL to each app we curated on the home page.

Wrapping Up

In this guide, we've covered the basics of understanding and getting started with Polygon's dApp store kit. Below, you'll find further resources to help you dive deeper into creating your own projects:

• dApp Store Kit API documentation

• Source code from this guide

• Polygon Developer Discord

As a developer, there are now several different options you have to create and deploy smart contracts onto a ZK-EVM, each with unique implementations, benefits, and drawbacks.

In this post, we'll cover the different kinds of ZK-EVMs as defined by Vitalik, the pros and cons of each, discuss which companies are working on them, and deploy smart contracts to each one.

Let's dive into it!

Recap: What Is A ZK-EVM?

If you're reading this and you aren't already familiar with zero-knowledge proofs or ZK-EVMs, I'd encourage you to read two of my previous posts linked below.

First, a basic understanding of ZK-EVMs:

If you want to go deeper, I also made a post covering how zero-knowledge proofs work, without any of the math:

TLDR: ZK-EVMs are Ethereum rollups that batch transactions together and post a "validity proof" of that batch back to the Ethereum blockchain + they're EVM-compatible, meaning you don't need specialized tools to work with them.

The EVM, Opcodes & Bytecode

The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts on Ethereum. Ethereum not only stores all accounts and balances similarly to Bitcoin but additionally stores what's called a "machine state".

The machine state is stored in a trie data structure, and changes from block to block after executing the transactions contained within that block.

The EVM is deterministic, meaning a set of instructions performed on any given state will result in the same new state every time. A simple analogy for this is to imagine a game of chess.

The chess board (Ethereum) has a large (in Ethereum, infinite) number of states the game can be in. The game has rules on what moves (transactions) can be performed, and restrictions on who can perform what actions (using accounts, signatures, etc.).

Just like Ethereum, players make moves (submit transactions), and the game (Ethereum) dictates what rules are allowed, and executes them, resulting in a new board (world) state after each move (block).

The Ethereum documentation describes this as a mathematical function:

Given an input, it produces a deterministic output. It therefore is quite helpful to more formally describe Ethereum as having a state transition function:

Y(S, T)= S'2

Given an old valid state (S) and a new set of valid transactions (T), the Ethereum state transition function Y(S, T) produces a new valid output state S'

High-Level Languages & Bytecode Compilation

As a developer on Ethereum, or any other EVM-compatible blockchain you're usually writing smart contracts in Solidity (although other languages like Vyper and Yul exist).

As with all other high-level languages, they're intended to be easily readable for humans, so we don't have to worry about the hard stuff like registers, memory addresses, and call stacks, and instead focus on usability.

However, machines don't understand this Solidity nonsense; the EVM included. The EVM understands bytecode, which is binary; machine-readable code.

The bytecode represents a series of EVM opcodes, each of which performs a specific operation in the EVM; sometimes these opcodes are concerned with stack operations like PUSH (add to the stack), or POP (remove from the stack) but also handles blockchain-specific operations like ADDRESS and BALANCE.

Each item is a 256-bit word, which was chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures).

As developers, this means we need a way to convert our smart contract code from Solidity → Opcodes → Bytecode in order for it to be executable by the EVM.

Luckily for us, there are compilers that do this for us.

Compiling Smart Contracts

Let's look at an example. I've got a very basic smart contract written in Solidity:

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

contract Greeter {
    // Internal state to the contract
    string private greeting;

    // Constructor - run when contract is deployed
    constructor(string memory _greeting) {
        greeting = _greeting;
    }

    // Read function (can be called without a transaction)
    function greet() public view returns (string memory) {
        return greeting;
    }

    // Write function (requires a transaction to be called)
    function setGreeting(string memory _greeting) public {
        greeting = _greeting;

        emit GreetingChanged(_greeting);
    }

    event GreetingChanged(string newGreeting);
}

But, I have a problem. The EVM can't understand this Solidity! It needs bytecode... So, I'm going to use a compiler to help me out here; more specifically, for example, I can use the built-in compiler in the Remix IDE to help me.

After I compile it, I can inspect the opcodes that get compiled, reflecting the contents of my smart contract.

Opcode:

I can also inspect the bytecode that gets compiled from those opcodes.

Bytecode:

60806040523480156200001157600080fd5b5060405162000c2938038062000c298339818101604052810190620000379190620001e3565b80600090816200004891906200047f565b505062000566565b6000604051905090565b600080fd5b600080fd5b600080fd5b600080fd5b6000601f19601f8301169050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052604160045260246000fd5b620000b9826200006e565b810181811067ffffffffffffffff82111715620000db57620000da6200007f565b5b80604052505050565b6000620000f062000050565b9050620000fe8282620000ae565b919050565b600067ffffffffffffffff8211156200012157620001206200007f565b5b6200012c826200006e565b9050602081019050919050565b60005b83811015620001595780820151818401526020810190506200013c565b60008484015250505050565b60006200017c620001768462000103565b620000e4565b9050828152602081018484840111156200019b576200019a62000069565b5b620001a884828562000139565b509392505050565b600082601f830112620001c857620001c762000064565b5b8151620001da84826020860162000165565b91505092915050565b600060208284031215620001fc57620001fb6200005a565b5b600082015167ffffffffffffffff8111156200021d576200021c6200005f565b5b6200022b84828501620001b0565b91505092915050565b600081519050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052602260045260246000fd5b600060028204905060018216806200028757607f821691505b6020821081036200029d576200029c6200023f565b5b50919050565b60008190508160005260206000209050919050565b60006020601f8301049050919050565b600082821b905092915050565b600060088302620003077fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff82620002c8565b620003138683620002c8565b95508019841693508086168417925050509392505050565b6000819050919050565b6000819050919050565b6000620003606200035a62000354846200032b565b62000335565b6200032b565b9050919050565b6000819050919050565b6200037c836200033f565b620003946200038b8262000367565b848454620002d5565b825550505050565b600090565b620003ab6200039c565b620003b881848462000371565b505050565b5b81811015620003e057620003d4600082620003a1565b600181019050620003be565b5050565b601f8211156200042f57620003f981620002a3565b6200040484620002b8565b8101602085101562000414578190505b6200042c6200042385620002b8565b830182620003bd565b50505b505050565b600082821c905092915050565b6000620004546000198460080262000434565b1980831691505092915050565b60006200046f838362000441565b9150826002028217905092915050565b6200048a8262000234565b67ffffffffffffffff811115620004a657620004a56200007f565b5b620004b282546200026e565b620004bf828285620003e4565b600060209050601f831160018114620004f75760008415620004e2578287015190505b620004ee858262000461565b8655506200055e565b601f1984166200050786620002a3565b60005b8281101562000531578489015182556001820191506020850194506020810190506200050a565b868310156200055157848901516200054d601f89168262000441565b8355505b6001600288020188555050505b505050505050565b6106b380620005766000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c8063a41368621461003b578063cfae321714610057575b600080fd5b610055600480360381019061005091906102ab565b610075565b005b61005f6100bf565b60405161006c9190610373565b60405180910390f35b806000908161008491906105ab565b507f58c1144814f1df01a80f7347f945437a37cd818e027f87b0ade6db623ec41b57816040516100b49190610373565b60405180910390a150565b6060600080546100ce906103c4565b80601f01602080910402602001604051908101604052809291908181526020018280546100fa906103c4565b80156101475780601f1061011c57610100808354040283529160200191610147565b820191906000526020600020905b81548152906001019060200180831161012a57829003601f168201915b5050505050905090565b6000604051905090565b600080fd5b600080fd5b600080fd5b600080fd5b6000601f19601f8301169050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052604160045260246000fd5b6101b88261016f565b810181811067ffffffffffffffff821117156101d7576101d6610180565b5b80604052505050565b60006101ea610151565b90506101f682826101af565b919050565b600067ffffffffffffffff82111561021657610215610180565b5b61021f8261016f565b9050602081019050919050565b82818337600083830152505050565b600061024e610249846101fb565b6101e0565b90508281526020810184848401111561026a5761026961016a565b5b61027584828561022c565b509392505050565b600082601f83011261029257610291610165565b5b81356102a284826020860161023b565b91505092915050565b6000602082840312156102c1576102c061015b565b5b600082013567ffffffffffffffff8111156102df576102de610160565b5b6102eb8482850161027d565b91505092915050565b600081519050919050565b600082825260208201905092915050565b60005b8381101561032e578082015181840152602081019050610313565b60008484015250505050565b6000610345826102f4565b61034f81856102ff565b935061035f818560208601610310565b6103688161016f565b840191505092915050565b6000602082019050818103600083015261038d818461033a565b905092915050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052602260045260246000fd5b600060028204905060018216806103dc57607f821691505b6020821081036103ef576103ee610395565b5b50919050565b60008190508160005260206000209050919050565b60006020601f8301049050919050565b600082821b905092915050565b6000600883026104577fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8261041a565b610461868361041a565b95508019841693508086168417925050509392505050565b6000819050919050565b6000819050919050565b60006104a86104a361049e84610479565b610483565b610479565b9050919050565b6000819050919050565b6104c28361048d565b6104d66104ce826104af565b848454610427565b825550505050565b600090565b6104eb6104de565b6104f68184846104b9565b505050565b5b8181101561051a5761050f6000826104e3565b6001810190506104fc565b5050565b601f82111561055f57610530816103f5565b6105398461040a565b81016020851015610548578190505b61055c6105548561040a565b8301826104fb565b50505b505050565b600082821c905092915050565b600061058260001984600802610564565b1980831691505092915050565b600061059b8383610571565b9150826002028217905092915050565b6105b4826102f4565b67ffffffffffffffff8111156105cd576105cc610180565b5b6105d782546103c4565b6105e282828561051e565b600060209050601f8311600181146106155760008415610603578287015190505b61060d858261058f565b865550610675565b601f198416610623866103f5565b60005b8281101561064b57848901518255600182019150602085019450602081019050610626565b868310156106685784890151610664601f891682610571565b8355505b6001600288020188555050505b50505050505056fea2646970667358221220a1f816fe7c07bf6a147b15ff4e1b591d0b43aca9fc57c8ddaecce27d5fe6f5fa64736f6c63430008120033

The final bytecode you see there is what would be understood by the EVM. So you can imagine why developers want to use high-level languages rather than write the bytecode themselves.

What we can do now is actually match up exactly what's happening in the bytecode to the opcodes. Let's take a look at the first three opcodes, PUSH 80, PUSH 40, and MSTORE.

I've matched up the first 10 hexadecimal values of the byte code to the first 3 opcodes we see below:

1. PUSH 80 / 6080: Pushes the value 80 (hexadecimal) onto the stack.

2. PUSH 40 / 6040: Pushes the value 40 (hexadecimal) onto the stack.

3. MSTORE / 52: Stores the second stack item (40) at the memory location specified by the first stack item (80).

We can do this matching process because Ethereum documents each opcode corresponding to its bytecode value:

Why do Opcodes or the EVM Matter?

The challenge of building an EVM-compatible rollup is that Ethereum was not originally designed around ZK-friendliness, so there are many parts of the Ethereum protocol that take a large amount of computation to ZK-prove.

Specific opcodes executed by an EVM are more "ZK-unfriendly" than others, and this had led to variance in the level of EVM-compatibility companies have chosen to adopt in their ZK-EVM products.

For example, some have opted for full equivalency for every EVM opcode, some have slight modifications to some opcodes, and some actually embrace producing completely different bytecode while maintaining high-level-language equivalence.

Below, I'll explore the different approaches each ZK-EVM has made and the tradeoffs each of them makes between performance (how fast they can generate ZK proofs) and their level of EVM compatibility.

Different Kinds of ZK-EVMs

Vitalik made a blog post in August 2022 categorizing ZK-EVMs into four (and a half) different categories, titled "The different kinds of zkEVMs". I'll be summarising this information below, but I'd recommend reading the full post too.

In the post, Vitalik charts the different types according to their EVM compatibility and ZK-proof generation times (performance). View original image:

To simplify this, in my opinion, we can place ZK-EVMs on a single line:

According to Vitalik, ZK-EVMs come in 4.5 different categorizations:

• Type 1: Fully Ethereum equivalent, i.e. they do not change any part of the Ethereum system to make it easier to generate proofs. ZK proofs take several hours to generate in this kind of system.

• Type 2: Fully EVM-equivalent, but changes some different internal representations like how they store the state of the chain, for the purpose of improving ZK-proof generation times.

• Type 2.5: Fully EVM-equivalent, except they increase the gas costs of some operations to "significantly improve worst-case prover times".

• Type 3: Almost EVM-equivalent ZK-EVMs make sacrifices in exact equivalence to further enhance prover times and simplify EVM development.

• Type 4: High-level language equivalent ZK-EVMs compile smart contract source code written in a high-level language to a ZK-SNARK-friendly language, resulting in faster prover times but potentially introducing incompatibilities and limitations.

Companies Building ZK-EVMs

Below, I'll show you the current landscape of all the different types of ZK-EVMs being built by various companies; including Taiko, Linea, Polygon, Scroll, and zkSync (plus a special bonus guest). I'll also be trying out each of the ZK-EVMs from a developer perspective.

For a fair test, I'll be using EVM Kit as my starting point for each; a full-stack boilerplate setup for creating web3 applications (learn more), including both smart contracts and web apps.

From a new EVM Kit project, I'll first deploy a basic smart contract written in Solidity & built in a Hardhat environment to each of the different ZK-EVMs we have explored to review the developer experience of writing smart contracts.

Second, I'll deploy an NFT collection smart contract to each, and mint some NFTs to see the gas price of interacting with common EIP standards on each chain as well.

We'll go through each in order of their "type", starting from type 1 and working our way up to type 4.

First up, we have Taiko at type 1.

Taiko

Note: Taiko is currently in the testnet phase.

Taiko is a type 1 ZK-EVM, meaning it replicates all of Ethereum's behaviour exactly the same, using the same hash functions, gas prices, encryption algorithms, etc. except Taiko currently handles two Ethereum Improvement Proposals differently.

The primary benefits of this architecture are:

• The development process is identical to using Ethereum.

• Taiko re-uses a lot of Ethereum infrastructure such as the node client software, making it very familiar to Ethereum users.

• There are no changes to hash functions or gas costs.

Taiko's approach is to fully optimize for EVM-equivalency, which comes at the cost of a large time to generate ZK proofs that get posted back to Ethereum.

The Taiko L2 uses the same rules of Ethereum to determine the new state of the rollup; immediately and deterministically after a block is proposed.

The drawback to this is slow ZK proof generation time, which is required to give certainty about the execution that happened on the rollup to bridges; meaning you won't be able to bridge funds back to Ethereum L1 until that proof is generated.

Deploying to Taiko ZK-EVM (Testnet)

Since Taiko has not released their mainnet at the time of writing this, I'll be using the "Taiko Alpha-3 Testnet" throughout this process. First, I got myself some testnet funds from the Sepolia Faucet and sent funds over to Taiko using Taiko's Bridge:

Once I'm across the bridge, the development process is identical to using Ethereum. The only change I make is to transform my RPC from an Ethereum RPC to the Taiko RPC. Below is the information about the chain ID and RPC I used for this process:

I was easily able to deploy my basic Solidity smart contract and perform both read and write operations on it as seen from the Taiko block explorer:

The process of deploying an NFT collection and minting my first Taiko NFT was also seamless, and worked exactly as I'd expect when working with Ethereum:

As I mentioned previously, the drawback of Taiko is that the ZK proof generation process is very lengthy, which means I am unable to bridge my ETH back to Ethereum L1 for several hours:

Your asset [my ETH] is not ready to be claimed. Taiko => Sepolia bridging can take several hours before being ready.

Below is the summary of my interactions with Taiko:

Keep in mind, these were all on Taiko's testnet and these numbers will be different than when Taiko launches their mainnet in the future.

Linea (Consensys ZK-EVM)

Note: Linea is in the process of releasing their mainnet later this month (July 2023)!

Linea's original announcement planned to release a type 2 ZK-EVM, however, their current release is a type 3 ZK-EVM working towards a type 2. As outlined in their risk disclosure documentation, Linea does not currently prove all EVM opcodes:

The validity proofs used to verify the computation of Linea batches do not prove 100% of EVM opcodes and precompiles

In addition, their documentation states the "proofs of computation for all EVM opcodes and precompiles" will come in phase 1 of their improvements as outlined in their roadmap:

Linea also deviates from Ethereum in how it represents the state of the chain. For instance, keccak, a hashing function used by Ethereum has been changed for a more ZK-friendly alternative. Despite this internal difference, you're deploying the same smart contract bytecode to Linea that you would deploy if you were using Ethereum.

Deploying to Linea (Testnet)

Once I secured myself some Goerli testnet ETH (which was a slight mission), I headed over to the Linea bridge to bridge ETH to the Linea testnet.

Once I successfully bridge my funds across, the development process is the same as Ethereum. Everything worked as expected with my Greeter smart contract:

And I was easily able to deploy the NFT collection and mint my first Linea NFT:

The bridge UI from Linea isn't currently available, but you can call the sendMessage function on their bridge smart contract directly. According to the Linea documentation, the bridging of ETH from L2 back to L1 takes ~15 minutes, but it took several hours during my testing.

Below is the summary of my interactions with Linea:

These were all very similar prices to Taiko; but again, are testnet values!

Polygon zkEVM

Disclaimer: At the time of writing this, I currently work at Polygon Labs. There may be some unconscious bias for this reason.

Polygon zkEVM is currently a type 3 ZK-EVM, with a small number of changes required before transforming into a type 2 ZK-EVM. You can view the opcodes, precompiled contracts, and other minor differences Polygon zkEVM transparently lists in the documentation that are different from the EVM's behaviour.

With these tradeoffs in equivalency to the EVM's behaviour, Polygon zkEVM is able to generate and post ZK proofs in just a few minutes; allowing you to bridge your funds back to Ethereum L1 in around ~30 minutes after interacting with the zkEVM.

With Polygon zkEVM, you're deploying the same bytecode as you would with Ethereum, however, the interpretation process of this bytecode is slightly different.

EVM Bytecodes are interpreted using a zero-knowledge Assembly language (zkASM), specially developed by the Polygon zkEVM team. In Vitalik's blog post, he mentions this:

Polygon has a unique design where they are ZK-verifying their own internal language called zkASM, and they interpret ZK-EVM code using the zkASM implementation. Despite this implementation detail, I would still call this a genuine Type 3 ZK-EVM; it can still verify EVM code, it just uses some different internal logic to do it.

The polygon engineering team has also stated they'll complete the remaining precompiles to become type 2 in addition to improving the proof generation & withdrawal times very soon.

Deploying to Polygon zkEVM

Polygon zkEVM mainnet beta launched in March 2023, so I'll be using mainnet funds for this process. First, I used the Polygon bridge to ship my funds across to the zkEVM. The gas fee for this process was around $5 USD and took ~5 minutes for the funds to arrive on the L2.

Just like the previous two chains, it's seamless and behaves as I'd expect Ethereum to. I was easily able to deploy my Greeter smart contract and call the functions on it as well as deploy an NFT Collection & mint an NFT:

The bridging process back to Ethereum L1 took ~60 minutes and was another $5 to claim my funds back into Ethereum mainnet.

If you're looking to build on the Polygon zkEVM, consider checking out my guide below taking you through the full process in less than 10 minutes:

Scroll

Note: Scroll is currently in the testnet phase.

Similar to Polygon zkEVM, Scroll is currently a type 3 ZK-EVM working towards being a type 2, with transparent documentation on the opcodes, precompiles, and other differences from Ethereum defined in their documentation. The scroll docs outline:

For the average Solidity developer, these details won't affect your development experience.

On the Scroll blog, they have also listed the exact work remaining to release their mainnet - see Scroll zkEVM next steps.

Deploying to Scroll

Just like the previous chains we've explored so far, Scroll is able to execute the same native bytecode that you would deploy to Ethereum, meaning there's no change in the development process.

I'm easily able to bridge funds to the Scroll testnet via their bridge UI:

The estimated time to bridge funds to the L2 is between 8-14 minutes, and it took 10 minutes for me to be able to use them on the L2.

Everything acts the same way as I'd expect Ethereum to, and I was easily able to deploy my Greeter smart contract and my NFT collection again:

Bridging funds back to Ethereum L1 is estimated to take between 10 minutes to a few hours according to the Scroll documentation (unfortunately I missed exactly how long it took in my case).

Below is the summary of my transactions on the Scroll testnet. During my testing, the gas fees seemed to be significantly cheaper than the previous chains we explored, although I'm not sure of the exact reason for why this was the case:

zkSync Era

zkSync Era is a type 4 ZK-EVM, and the experience is quite different from the other products we've explored so far.

Era embraces the fact that the smart contract bytecode that gets deployed for their zkEVM is not the same as Ethereum; and this large difference enables their product to have unique offerings, such as native account abstraction.

These base changes in capability come with differences in developer experience, but as Vitalik defined; still allows you to work with the same high-level languages such as Solidity.

Era comes with a set of best practices and considerations for where you might run into different behaviours than when interacting with Ethereum and requires some slight adjustments in your development setup.

For example, I needed to install an additional Hardhat extension and add one additional flag to my Hardhat configuration to compile the required bytecode for the chain:

In the compilation process, the bytecode that gets generated for you to work with zkSync is different than the bytecode that gets generated by default:

Existing deploy tooling like thirdweb deploy (used in EVM Kit) has support for this bytecode by providing the --zksync flag to the deploy command.

Overall, it's quite a small amount of changes required to use Solidity and my standard development environment to cooperate with zkSync.

Deploying to zkSync Era

Using zkSync's bridge, it's estimated about ~15 minutes for the funds to arrive on L2.

After this point, the process is the same! I'm able to deploy my Greeter smart contract, as well as my usual NFT collection with an NFT minted:

Currently, bridging funds back to Ethereum L1 from zkSync Era has a 24-hour delay:

To ensure security in the first days of the protocol, there is a 24 hour delay on withdrawals from zkSync Era (L2) to Ethereum (L1). See our blog post for more details.

Here's the summary of my interactions on zkSync Era:

Bonus Guest: Kakarot

Just last month, a new zkEVM called Kakarot written in Cairo was announced, which aims to bring EVM compatibility to Starknet as a type 2.5 ZK-EVM, however, is considered a type 3 in its current state.

While it does has a very cool name and landing page, it also received funding from Vitalik himself, among others including Starkware.

The testnet has not yet been released but is planned to release later in 2023, and their development team has provided the following update:

The Kakarot team achieved an impressive milestone (with the support of the Starknet Foundation and the collaborative efforts of over 40 unique contributors) by implementing 100% of EVM opcodes and 8 out of 9 EVM precompiles in just six months and with less than 5,000 lines of code!

What's the future? Will One Chain Win?

Rather than it being a battle about which chain is the best, it's overall good for the improvement of Ethereum and web3 that so many different approaches are being explored; each with their own pros and cons.

Vitalik also has explained his "multi-prover theory", where rollups could potentially collaborate together to enhance the security of the whole ecosystem, among other alternatives to the future of ZK-EVMs.

Wrapping Up

That's the landscape of ZK-EVMs today, at least as I understand it!

You can find the summary below of the companies working in the space, and the types of ZK-EVM their respective products currently are:

If you're looking to build on ZK-EVMs, consider checking out my guide to creating full-stack applications on the Polygon zkEVM below:

Thanks for reading! Follow me on Twitter for more!

In one sentence: ZK proofs allow you to prove something without revealing the thing itself. This has several real-world applications, such as verifying your age without providing your full license/passport information.

But how does this actually work? What's happening behind the scenes to make this possible? In this post, I'll cover everything you need to know about ZK proofs, but leave out the math.

Let's do it!

How Does a ZK Proof Work?

To prove the validity of a statement without revealing the statement itself, there are two parties involved:

1. The Prover: the person trying to prove something.

2. The Verifier: the person trying to validate the claim is "real".

Sometimes, there is a third party involved, an issuer, who grants the prover a certificate (such as a license) to the prover, whom the verifier trusts as a source of information.

Let's look at an example... I'd like to prove to a website that I am above the age of 18, without uploading a picture of my passport. In this situation, there are:

• The Prover: Me, the individual trying to prove I am of legal age.

• The Verifier: The website owner, trying to verify that I am of legal age.

• The Issuer: The government, that provides me with a passport; a document that the website owner trusts to prove my age.

Typically, I'd need to upload screenshots of my entire passport to the website, (something I really don't want to do), just to prove that I'm over 18.

A fun example made by Steph is applying this to Spongebob. Spongebob wants to prove that his name is in fact Spongebob, but in order to do that, he needs to provide his full license to the verifier (the police officer... or I guess, police fish).

His license contains sensitive information like his DOB, address, gender, and more; all of which isn't necessary to prove his name; but, alas, he has no other choice.

It would be so much better if Spongebob could prove his name, or if I could somehow prove that I'm over 18, without needing to hand over so much sensitive information.

This is a prime example of how ZK proofs provide real value to the world. With ZK proofs, I am now able to prove a part of my identity (or anything else) to a verifier without providing any aspect of my identity, or any supporting documents to prove that fact.

This way, I never transfer sensitive personal information to a third party to be stored in a database; vulnerable to attacks and leaks; something we currently risk almost every time we sign up for a website.

This all sounds great. But how do you prove something without revealing anything about it? For this, we can dive deeper into what ZK proofs are.

What Makes Up A ZK Proof?

So, we want to prove something, without revealing how we know that thing, or what that thing even is. How is that possible?

Before we can answer that, ZK proofs come in two broad categories:

1. Interactive

2. Non-interactive

The ones we care about in web3 are non-interactive, but let's quickly touch on what "interactivity" refers to in the context of ZK.

Interactive ZK Proofs

Imagine that there's a ring-shaped cave with a gate inside that requires a secret password to enter through.

Your goal, as the prover is to prove to your friend, the verifier that you know the secret password, called the "witness", without telling them the actual password.

You don't want to tell your friend the password, so instead, you are going to prove you know it; by first, going into one side of the cave randomly; without them seeing.

At this point, your friend doesn't know which side you're on. But as a challenge, they shout out either "A!" or "B!"; requesting you to exit on either side A or side B.

In this simple example, this can lead to two outcomes:

1. You entered side A, so you need the password to get through the gate to side B:

1. You entered side B, so you don't need the password; you can just walk back out:

This is called the Ali Baba Cave Story, for reference.

This is a simple example because it's 50/50 whether or not you require the password to satisfy your friend's challenge; thus, doing this challenge only once is not enough to prove with certainty that you know the password.

This means you'd need to complete more iterations of the challenge, correctly exiting either side A or B until your friend is satisfied; or in the theoretical world, until it's impossible for you to have faked knowledge of the witness (the secret code).

Hence, this is interactive; you (the prover) and your friend (the verifier) interact back and forth. Your friend creates a challenge, and you create a response. This cycle repeats until the verifier is satisfied, at which point, the verifier has proven knowledge of the witness.

This makes up the three parts of an interactive ZK proof:

1. Witness: The secret information the prover wants to prove their knowledge of.

2. Challenge: The question that only someone with knowledge of the witness would likely be capable of answering; although could be a lucky guess.

3. Response: The prover's response to the challenge; containing the (hopefully) correct answer.

Steps 2 and 3 are repeated until the verifier is satisfied.

Eventually, once the verifier is satisfied, the cycle breaks; and instead of generating another challenge, the verifier accepts that the prover has knowledge of the witness.

While this process works, it requires many rounds of communication between the prover and verifier; something that is inefficient and doesn't particularly work well in the context of blockchains.

Interactive proofs also have another big limitation; even after the verifier is satisfied, the proof would be unavailable for independent verification; meaning only the party who verified it can trust it, not anyone else.

For these reasons, non-interactive ZK proofs were made.

Non-Interactive ZK Proofs

Non-interactive ZK proofs require only one round of communication from the prover to the verifier. The prover uses an algorithm to compute a ZK proof and sends it to the verifier, who also uses another algorithm to check it.

Another benefit to non-interactive ZK proofs is that they're available for anyone else to verify as well; meaning it's not just proven from the verifier's POV, but available for everyone to verify themselves; suitable for blockchains.

What are these "algorithms" that are capable of proving information and verifying proofs? Well, the answer is; it depends. There are quite a number of them, but two ZKP systems are typically used in the context of blockchain; ZK-SNARKs and ZK-STARKs.

What Are ZK-SNARKs?

ZK-SNARK means Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.

• ZK: hopefully by now you can guess what this means (zero-knowledge).

• Succinct: they're small, and quickly verifiable by the verifier.

• Non-interactive: we discussed this previously. Only one round of communication between the prover and the verifier is required.

• Argument: It's theoretically extremely unlikely to be able to "fool" the system.

• (Of) Knowledge: It cannot be constructed without access to the secret information (the witness).

They use a cryptographic primitive called elliptic curve pairing as their method of creating and verifying these proofs (we won't go into the math here).

One key thing to note about ZK-SNARKs is that during the initial setup phase, the prover and the verifier must agree to use a "shared key", known as the Common Reference String (CRS). Anyone with access to this shared key can verify the proofs.

This shared key is what makes ZK-SNARKs possible; although this is also arguably their biggest drawback because it creates what is known as a "trusted environment".

The values used to create the CRS, sometimes called "toxic waste" need to be destroyed after the CRS is generated. If they are not, the entire system is at risk; as dishonest provers would be able to compute false proofs; hence, the users must trust that the value is destroyed.

Something also worth mentioning about ZK SNARKs is that they are not "quantum-resistant"; meaning they are vulnerable to attacks by quantum computers in the future; although they could potentially be upgraded in the future to become quantum-resistant.

What Are ZK-STARKs?

ZK-STARK means Zero-Knowledge Scalable Transparent Argument of Knowledge.

• Scalable: Rather than being "succinct", they're scalable; meaning they generate and verify proofs with larger witnesses more efficiently than ZK-SNARKs.

• Transparent: There's no trusted setup required. They rely on publicly verifiable randomness to generate the shared key.

This improvement in transparency usually comes with a tradeoff of generating much larger proofs than the size of ZK-SNARKs; except when dealing with very large datasets. The size of a proof goes up from 288 bytes to a few hundred kilobytes.

Rather than using elliptic curves, they use polynomials; something I am definitely not qualified to tell you about. Vitalik has a three-part series on this topic: 1, 2, 3.

ZK STARKs address both of the concerns we discussed with ZK-SNARKs, they:

1. Don't require a "trusted environment".

2. Are plausibly post-quantum secure; meaning they won't be vulnerable to attacks from quantum computers in the future.

ZK-STARKS are newer than ZK-SNARKs, and Vitalik calls them their "newer, shinier cousin"! 🤠 So, as a quick recap:

How Does A zkEVM Work?

Now that we've covered how zero-knowledge proofs work and the two common forms of ZKPs that appear in the web3 world, let's explore one of the recent innovations powered by ZKPs; the zkEVM (zero-knowledge Ethereum Virtual Machine).

zkEVMs come in a few different forms; as Vitalik outlines in his blog post "The different types of ZK-EVMs". The one I'll be referencing in this post is the Polygon zkEVM.

The goal of the zkEVM is to improve the scalability of the Ethereum blockchain while remaining secure, decentralized and EVM-compatible.

The details are complicated, but the core principles are the same as what we've discussed so far. As in all ZKP systems, there are:

1. A Prover: Generates validity proofs representing the truthfulness of a batch of transactions submitted by users.

   • First, it creates multiple ZK-STARK proofs.

   • It bundles the ZK-STARKs together using STARK Recursion, to create a single ZK-STARK.

   • This ZK-STARK is big, so it goes through the CIRCOM component which outputs to the SNARK builder.

   • As the name suggests, the SNARK builder generates a ZK-SNARK validity proof; this helps in reducing gas costs from 5M to 350K.

2. A Verifier: The PolygonZkEVM smart contract deployed on Ethereum is the verifier of the ZK proofs.

Flow Of Data In A zkEVM

Below, is a simplified flowchart of data in the Polygon zkEVM.

I've broken it up into chronological sections to help it be more digestible.

Submitting Transactions

As a user, you submit transactions as you would normally with any other EVM chain such as Ethereum; by signing transactions and sending them through JSON RPC.

A sequencer node running zkEVM software picks these transactions up and decides which ones it wants to process, with some incentive mechanisms in place for doing so correctly.

Batching Transactions

The sequencer batches transactions together into one and submits them to the PolygonZkEvm smart contract, which is stored on Ethereum Mainnet (and a separate instance on Ethereum Goerli testnet).

These batches aren't necessarily correct or verified at this point.

Verifying Transactions

Using ZKPs, the PolygonZkEVM smart contract is acting as the verifier in this setup. It wants to verify that the batch it just received is valid; it does so by sending the batch to an aggregator node.

Generating & Verifying ZK Proofs / Validity Proofs

The PolygonZkEVM smart contract sends the batch it just received to an aggregator node, which is another machine running zkEVM software that communicates with a ZK prover. The flow is as follows:

• The aggregator receives the batch from smart contract

• The Aggregator sends the batch to ZK Prover

• The ZK Prover creates multiple ZK-STARKs -> a single ZK-STARK -> a ZK-SNARK

• The ZK-SNARK (the validity proof) gets sent back to the aggregator

• The aggregator sends back the validity proof to the PolygonZkEVM smart contract

• The PolygonZkEVM Smart contract verifies the validity proof

  • If the validity proof is valid, accept it.

  • If it is not valid, reject it.

Reading The ZK EVM

In order for the ZK EVM to be useful, decentralized applications (dApps) need to read information from it; which is where the synchronizer comes into play.

It reads in events from the Ethereum smart contract(s), storing knowledge of both the ZK validity proofs from the aggregator and the batches submitted from the sequencer.

This way, applications can easily get a view of the state of the rollup via JSON RPC.

Wrapping Up

Zero-knowledge proofs are real-world applications of cryptography that could be the foundation of a more privacy-oriented future; demonstrated in products like Polygon ID.

In the context of blockchain, ZKPs are being utilized to improve the scalability of Ethereum in products like Polygon's zkEVM, by providing a new way to verify batches of transactions without the typical loss of security or EVM compatibility we see today with other rollup solutions.

In this post, we've covered:

• What ZK Proofs are, and why they're important.

• How ZK proofs work, including ZK-SNARKs and ZK-STARKs.

• How these proofs are being used in the blockchain world.

If you'd like to learn how you can apply these concepts, I have a previous blog post covering how to build your first smart contract and decentralized application on Polygon zkEVM below:

That's it for this post! Follow me on Twitter to keep up to date with more educational content like this every week: My Twitter.

The first announcement in the roadmap is a proposal to upgrade the Polygon PoS (proof-of-stake) chain we know and love to become a zkEVM Validium.

I must admit... when I read that, I thought "wtf is a zkEVM Validium?"!

If you thought something similar, you're in the right place. I've done the research so you don't have to, and in this post, we're going to cover:

• What's changing about Polygon PoS?

• What are Validiums? Why is Polygon PoS becoming one?

• What about Polygon zkEVM? What's the difference between PoS and that?

Let's do this!🫡👇

Recap: Sidechains, rollups, and scaling

As a quick refresher, let's quickly explore why any of these scaling solutions exist in the first place. You can safely skip this part if you're already a pro.

On Ethereum, users pay fees that validator nodes take as an incentive to include users' transactions in new blocks. Over time, Ethereum has reached "certain capability limitations".

As the demand to write information to Ethereum, such as the desire to mint NFTs or transfer ETH rose, the fee required to have your transaction included in a block became very expensive (sometimes hundreds of dollars per transaction).

This has led to many different scaling solutions developed by talented groups of people across the world, each with a unique way of accomplishing more scalability on Ethereum; including companies like Polygon, Optimism, and Arbitrum.

These companies created implementations of sidechains, rollups, plasma chains, and more, to address the scalability problem that the Ethereum mainnet faces, and enable users to more easily create and experience decentralized applications.

You can learn more in-depth about each of these solutions in my previous blog post:

So that's why Polygon PoS was created initially, and more recently, Polygon zkEVM was also released. So why is Polygon PoS changing?

What's changing about Polygon PoS?

Polygon PoS (proof-of-stake) is, in its current state, a sidechain.

The main benefit of a sidechain is increased scalability; higher transactions per second and significantly lower gas fees per transaction.

Since Polygon PoS is EVM-compatible, you can perform the exact same development process you would if you were developing for Ethereum, and deploy to Polygon PoS instead, immediately granting your users a massively improved experience when interacting with your smart contracts, with no extra effort.

The downside to sidechains is that because they don't post back state changes or transaction data to Ethereum, they therefore don't inherit all of Ethereum's security properties; essentially making the tradeoff of more scalability for less security; as outlined in Ethereum's scalability trilemma.

Polygon PoS powers the most popular brand web3 efforts in the world, like Reddit, Stripe, Starbucks, Bulgari, and more; giving it a powerful ecosystem and strong incentive for developers to launch their projects using this network.

However, Polygon's broader vision with Polygon 2.0 is to use the latest innovations in zero-knowledge proofs to power all of their scaling solutions to Ethereum, and Polygon PoS in its current state is secured by its own validators; not by ZK proofs.

That's what's going to change; the proposal suggests Polygon PoS should upgrade to use ZK proofs to provide even more scalability and stronger security to the chain.

With this upgrade, Polygon PoS would become a zkEVM validium:

• ZK: Utilizes zero-knowledge proofs to prove the result of transactions.

• EVM: It's Ethereum Virtual Machine (EVM) compatible, meaning it works out of the box with existing developer tools and user-facing apps such as wallets.

• Validium: This is a bit more complex; we'll explore this below.

What are Validiums?

By using zero-knowledge proofs instead of purely relying on validators to execute transactions, Polygon PoS is becoming a validium, and will no longer be a sidechain.

The proposal means that Polygon PoS will use zero-knowledge proofs to guarantee and verify the validity of batches of transactions, which are both executed and stored off-chain; leading to lead massive improvements in scalability.

According to Ethereum's documentation, validiums can process ~9,000 transactions, or more, per second; compared to Ethereum's roughly ~15 transactions per second.

Validiums are different from rollups and sidechains because they only post the validity proof (containing verified proof of the result of the transactions) back to Ethereum, not the actual transaction data of the executed transactions.

The way this works is by having a verifier smart contract deployed to Ethereum, which the validium submits validity proofs to. The validity proofs are zero-knowledge proofs that contain the result of the transactions, but not the data within them.

The verifier smart contract determines if the validity proof is valid, and if it's not, the batch submitted from the Validium is rejected and not stored on Ethereum.

The tradeoff to this process is that Validiums utilize an off-chain data availability model; transaction data is not stored on Ethereum, so the validators of the network must attest to data availability; which comes with its own set of potential risks.

Why is this better for Polygon PoS?

Compared to sidechains, validiums are better in two key aspects:

1. Scalability: The amount to which rollups and sidechains can scale is limited by the data bandwidth on Ethereum Mainnet. Since validiums reduce the amount of data Ethereum has to process, they greatly extend throughput on Ethereum.

2. Security: The use of validity proofs gives validiums higher security guarantees than sidechains.

Typically, the downside to validiums is that they are not EVM-compatible, making them only suitable for simple applications like transferring tokens or minting NFTs, due to the considerable overhead of proving EVM instructions in a zero-knowledge proof circuit.

Over the past eighteen months, Polygon Labs has built "the fastest ZK proving system in the industry and launched the only EVM-equivalent zkEVM on mainnet" to overcome this obstacle, meaning that a validium doesn't have to come with this limitation.

Creating an EVM-compatible validium is the best of both worlds; as it is flexible enough to perform all EVM operations and use all existing tools and applications in the EVM world, while also providing greater scalability and security to Polygon PoS; which has a massive community already.

Using zero-knowledge proofs for this process is the cherry on top; by proving the transactions upfront, it means there are no other limitations such as a challenge period that come with other scaling solutions.

What about Polygon zkEVM?

You might be asking, didn't Polygon just release a zkEVM? What happened to that?

Polygon PoS and Polygon zkEVM currently co-exist as two separate chains, and they will continue to be separate chains moving forward; although Polygon 2.0's future announcements will include improved unity between the two.

The key difference here is that Polygon zkEVM is a zero-knowledge rollup, whereas Polygon PoS will become a zero-knowledge validium.

• Polygon zkEVM does post transaction data back to Ethereum mainnet. Meaning it will be comparatively less scalable, and more secure, making it suitable for projects such as high-value DeFi applications.

• Polygon PoS (when upgraded) does not post transaction data back to Ethereum. Meaning it will be comparatively more scalable, and less secure, making it suitable for projects that have high transaction volume and require low transaction fees, e.g. gaming, social, and micro DeFi.

Link to image ↗

Wrapping Up

TLDR: the big words are intimidating, but the proposed change to Polygon PoS will provide improvements to both the scalability and security of the chain.

Polygon's zkEVM will coexist, and be more suited to apps that require higher levels of security. Whereas Polygon PoS will be more suited towards apps demanding higher throughput; such as social apps built on Lens Protocol.

It's clear to see the investments Polygon has made in zero-knowledge technology are powering massive innovations throughout its product suite, and I'm excited to see how this technology can be used more broadly.

Follow me on Twitter for more updates like this one!

Within the next 5 years, the majority of gamers won't play games unless they are being properly valued for that time. The model is called "play-to-earn" and it will become standard for video games in the future.

Of course, this gathered the usual "scam", "crypto-bro", and "death of the industry" comments. It's an easy tweet to dunk on; and overall, felt very out of touch with what we've experienced in this space.

Despite working in web3 for a while now, I have to agree that it's completely delusional to think this is where gaming is headed ever; let alone in the next 5 years.

People don't play games to earn money and the play-to-earn games we've seen so far have been terrible, unfun messes that usually die out within months.

However, I don't believe this is the death of NFTs in gaming, and I encourage you to try to read this with an open mind as I discuss points both for and against blockchain usage in gaming. I'll be talking about the following:

1. Why do people actually play games?

2. Why web3 Gaming has (mostly) failed so far

3. Actual use-cases for the blockchain in gaming

Why Do People Actually Play Games?

One of the quotes from this Twitter thread was as follows:

Why would you keep playing the game for free when you could get paid for it?

For many of us, working to make money is something we do to pay the bills and stay alive. This doesn't mean I don't enjoy work or that I am not a productive member of society; I take pride in my work and am consistently trying to improve my craft.

Gaming acts as an escape from this grind; and while I do think there are some deeper psychological natures of why games are played so often; I think I speak for a large percentage of the community when I say that I don't want gaming to become a thing I do to earn money, especially after spending most of my day doing something else for money.

I play games to dissociate from the other things going on in life; to relax, have fun, play with my friends, be competitive, improve and express my skill, and be part of an interactive story-telling experience.

Play-to-earn ignores this and replaces it with a monotonous grind of implementing the most optimized strategy to earn in-game currency in the hopes of making money.

I'm not jumping on Discord with the squad to earn digital currency to buy other digital assets in the game and hoping that someday I can retire from selling these to other players.

Why Web3 Gaming Has Failed (so far)

Let's not sugarcoat it. Web3 games are (mostly) just not fun.

When your objective as a game developer is to pump the price of a digital token you printed in hopes of cashing out, your game's core mechanics revolve around getting players aligned with that same objective; so they too can "earn" by playing.

Let's look at another quote from the Twitter thread:

Companies like @AxieInfinity are already leading the way by letting players easily earn crypto and sell their in-game characters as NFTs.

Bruh. Really... Axie Infinity is the one you're going with. Alright...

Axie Infinity

Axie Infinity is a game where you battle cute little "Axie" NFTs against each other to earn cryptocurrency called Smooth Love Potion (SLP).

Initially, you invest X amount of money to actually be able to play the game by purchasing a team of Axies, and over time, cash out the cryptocurrency you earned from playing the game to make a profit.

Since there is a limited supply of Axies, new players need to buy them from existing players in order to play the game, almost in a suspicious-looking triangle structure of onboarding new users. 🤔

The value of the Axie NFTs and the $SLP token you earn for playing the game depends on how much a new investor player is willing to spend to buy it; in hopes of earning a profit themselves.

Over time, it evolved into a dystopian capitalistic nightmare where people who could actually afford to buy the NFTs necessary to play the game outsourced the "fun" to people in the Philippines and Indonesia to actually play the game for them...

For Filipinos, it was a way to make a living through the pandemic, and for crypto-bros, an investment opportunity.

Source of image: PLAY-TO-EARN | NFT Gaming in the Philippines

As you'd expect, as the potential to earn money from Axie Infinity diminished, so did the player base. The price of the in-game token ($SLP) has dropped nearly 99% from its all-time high:

This has led to a similar, sad-looking chart in activity on the game:

The problem here is simple... when games are designed to make you money (which usually actually means making the developers money), it turns out they're usually not that fun. The developers aren't building it for fun, and people aren't playing it for fun.

This isn't to say there aren't any good games out there that incorporate NFTs; games built on chains like ImmutableX such as Gods Unchained and Cross The Ages have real, human players that are playing the game for fun and trading their in-game assets as part of the game's economy.

The Problem with Crypto-based Gaming

Blockchains, digital collectables, cryptocurrencies, and "true ownership" aren't game mechanics. You can't make a game out of these concepts because they are inherently unfun.

Most of the games we've seen that integrate these ideas use them as the core feature of the game itself; not something secondary to an actual fun game. Differing from the structure we see in popular games today like CS:GO or League of Legends.

This creates an environment where the only people interested in playing the game are those who want to do so to earn money, and once that opportunity is gone, the players leave too.

This is true in an even broader sense outside of just gaming. If you encourage any kind of behaviour with the reward of money, people are probably going to do that thing until that action is no longer worthwhile.

We see this in other parts of web3; with people performing on-chain actions to farm token airdrops, people engaging in Discord activity in the hopes of being whitelisted or scrawling Twitter "drop your ENS" posts in the hopes of hitting the next big project.

This strategy works because both developers and users benefit from the usage of their token, as it gathers the attention of other potential users to get on board.

So... we've dunked on web3 gaming a lot, let's quickly recap and shift tones a bit now.

Quick Recap

• Web3 games often aren't even intended to be played for fun

• Blockchain features are not something you can make a fun game around

• There's little to no demand for "play-to-earn" in the gaming community

So, with all this in mind, do NFTs have a place in gaming? Let's take a look.

Why Blockchain?

Despite the common saying that "blockchain is a solution looking for a problem", I think there is a pretty clear use case for where blockchain shines.

A blockchain is ideal for where there is some benefit for the data being separate from the application. Using a blockchain as the mechanism of data storage unlocks a way to give everyone read-level access to information while still controlling the rules of what can occur within that system.

That description is intentionally a little vague to cover all kinds of different use cases, so let's dive into what I think this looks like specifically in gaming.

To me, there is a clear trend that we see today in games. The game itself, and then the game's assets. Games usually have some kind of separate economies to them where players use in-game currencies to purchase in-game items, for example:

• League of Legends: Use RP to buy champion skins, emotes, chromas, etc.

• CS:GO: Use dollars to buy weapon skins, stickers, cases, keys, etc.

• Fortnite: Use V-Bucks to buy skins, vehicle & weapon wraps, and more.

Blockchains are not suitable to power the core features of fun games. Instead, it's these economies where a blockchain can provide value for both players and game developers, in the form of three different unique use cases:

1. Access to in-game information outside of the game

2. Enabling of trading, buying, and selling of in-game items

3. Capability to use a shared identity across games and platforms

In the following sections, I'll provide real scenarios where these could be used and the benefits of doing so for both game developers and players.

Accessing In-Game Information Outside the Game

If you're a gamer you're likely on several different platforms related to that game:

1. The game itself

2. A community like Discord or Reddit to communicate with others about the game

3. Social platforms like Twitter, Twitch, and YouTube to view content of the game

While these systems may have created integrations like Prime Gaming to communicate with each other, external platforms outside of the games ecosystem don't have access to information about your profile in-game* (\we'll talk about APIs shortly).*

Without a shared data layer to store in-game information such as what skins you own, or even taking it a step further to store information about your rank, your achievements, or your unique accomplishments, it's not possible to build seamless integrations across different platforms that read this information.

This affects two key parties in different ways; players and developers.

For Players...

As a player, I'm proud of the accomplishments I've made in-game. I'm proud that I made it to Legend rank in Hearthstone, or got to Diamond rank in League, or that I have a high ranking for specific characters in my server.

For players, it's a flex to own the OG John Wick skin in Fortnite, and it's cool to own the Dragon Lore skin on your AWP in CS: GO.

If this information was on a shared storage of data such as a blockchain, any external application would be able to pull in this information and utilize it on their platform outside of the game.

If I could showcase my in-game rank, or a rare item I own in social settings like Twitch, Discord, and Reddit, that brings added value to me as a player.

I'm passionate about being good at the games I play and I want other people to know that I am good at them. As a player, information being stored on the blockchain makes it available to any other platform that wishes to read this information; allowing me to show off my items, or even verify the accomplishments that I've made.

Some examples of this might be:

• On Twitter, setting my profile image as my Riot-issued Challenger NFT to show off and verify that I was one of the highest-ranked players on the server.

  • Twitter already has built-in NFT integrations to verify the legitimacy of NFT profile pictures. Instagram recently shut down support for this, however.

• Opting into displaying a badge NFT next to my name in Twitch Chat that shows my rank or shows some item from my in-game profile.

• Granting me restricted access to a Discord server where only the top players of a certain character are allowed to enter.

For Developers...

A number of tools exist outside of the game's ecosystem that rely on in-game information. Some examples:

• League of Legends: op.gg for in-game stats and rank progress

• Hearthstone: hsreplay.net for the best decks and meta reports

• Warzone: cod.tracker.gg for your game history and rank

These applications are powered by the game developer's API, such as the Riot API, and are essentially full-time businesses that are at the mercy of the company behind that API.

In recent months alone, we've seen several instances of why this structure (where one company owns the data, and it is not public on a system like a blockchain) is problematic:

• Twitter raised its API price to $42,000 per month, killing many small businesses and third-party applications in the process.

• Reddit forcing third-party apps such as "Apollo" to pay $20 million per year to keep running as-is.

More specifically, in the gaming industry, Activision issued a cease-and-desist for the application "Warzone SBMM"; an example of an application dependent on one of these APIs.

By using a decentralized data layer such as a blockchain, access to that data is granted to everyone out of the box. There's no requirement for the development team to maintain an API or built dedicated integrations with partners.

As a third-party developer, this setup would mean that you don't have a single point of failure (the API) in your business, as the data is available without having to trust anyone.

Trading, Buying, & Selling In-Game Items

My most played game is League of Legends; a game I have spent hundreds of dollars on to purchase the in-game currency "RP" (Riot Points) I use to buy skins that make my characters look cooler in the game.

I spent this money because I get joy out of it, I can gift my friends skins for special occasions, or because I wanted to be involved in special events that Riot puts on. I didn't spend this money in the hopes of getting anything monetary in return.

When I buy skins in League, that money I spent is essentially gone and locked up in the ecosystem of League; I cannot do anything with the skin except use them in my games, and this is something I've accepted.

However, as a player, there are benefits for me if there were a method where I could buy, sell, and trade my in-game items to other players; so that I could sell my old skins I don't want, sell skins for characters I don't play, or buy a rare skin from another player that is no longer available from the store for my favourite character.

Having in-game items stored on the blockchain would enable this buying and selling of skins out of the box; allowing me to more actively participate in the game's economy; buying rare skins for my favourite champs, and selling ones that I don't want to other players. Something I can't currently do.

There's demand for this already. You can easily find (illegal) sites that sell League accounts with rare skins on them; a process that Riot (League's game developer) does not benefit from at all, and is actively trying to prevent.

For users, these websites are extremely sketchy and since you're performing something against the terms of service, there is no safety when it comes to buying them.

Above: An example of accounts for sale with very rare skins on a third-party app

It's a lose-lose environment for both game developers and players, and something that a blockchain could be used to provide a potential solution.

By using NFTs to represent in-game items; they would come with standard features like being able to be transferred/sold on marketplaces, enabling third-party websites that already exist such as OpenSea to be used as a trusted environment for players to buy and sell these in-game items without additional effort from Riot (if they made them NFTs from the start, which is not the case.)

All of this would be possible without any dedicated development to create or maintain this marketplace/economy; as these capabilities are standard features of tokens within smart contracts.

Why would a game developer like Riot do this?

Money! Companies want money. Implementing this would help them get more money.

1. As a player, I'm more willing to put money into the game's economy if I can get money out of it (anecdotal).

2. Game developers can take a percentage of the sales made between players in both royalty fees and platform fees whenever a skin is bought/sold/traded.

An example of a game with an economy with a marketplace today is Counter Strike Global Offensive (CS:GO). Which has a centralized marketplace run by Valve; the creator of the game and of Steam.

Despite playing CS:GO significantly less than I do League of Legends, I've spent a solid chunk of money buying skins in this game; because of this marketplace where I can sell these skins to other players willing to buy them.

Immediately, this creates a mindset shift; instead of "sinking money" into the game, I'm buying assets that I can later sell when I no longer want them, or trade for other skins if I don't get the ones I want.

Above: One example listing of an in-game CS:GO item on the Steam marketplace.

This marketplace proves there is a demand to buy & sell in-game items between players, and there is a benefit for both the player and the game developer.

• Players: Opportunity to buy skins that I want on my favourite weapons from other players that are not available for direct purchase, and potentially make a profit from selling/trading my own rare skins.

• Developers: Money. Steam takes a 10% fee of any CS:GO item transaction on their marketplace.

It's no easy task to hire a team of developers to build a marketplace that is almost a separate entity from your actual game, and this may be one of the reasons why Riot or other game developers choose to not build this infrastructure for their community.

The nature of the blockchain and standardized tokens such as NFTs enable this behaviour from the get-go, providing infrastructure to perform actions such as those that take place on the Steam marketplace both in and outside of the game.

By implementing this, game developers such as Riot could unlock an entirely new revenue stream for their business whenever players trade their League skins, Valorant skins, TFT Little Legends, and LoR cards.

Players would be able to purchase skins that are not directly available for sale anymore from other players; providing further reason for them to purchase the in-game currency in the process.

Anecdotally, as a player, this would also give my skins "value", as my skins in League are currently worth nothing other than personal joy, whereas my CS:GO skins also give me joy, but at the same time are exchangeable for actual money.

It's important to revisit the fact that these economies are completely separate from the fun, addictive games that these companies have developed. Players choose to opt-in to these economies and can still perform every action of the game without ever becoming involved with it.

Ok but... You can do this without the blockchain already?

A valid argument against this point is "this is already possible without the blockchain".

This is true! As we just saw, Steam has already been enabling the buying & selling of in-game items for over a decade; without ever touching the blockchain.

There are two counter-points I have to this:

1) By relying on a service such as Steam to facilitate this marketplace, Steam is the one profiting; not you (the developer).

There are incentives for the developer to control both the way that the assets work and the marketplace's conditions. For example, by implementing blockchain standard features such as royalty fees and platform fees, the game developer can ensure they are profiting whenever a buy/sell occurs from their community.

2) Building a marketplace takes time, effort, and money

For some game development companies, creating a marketplace from scratch is likely, not feasible; so the choice is either to use Steam or to not implement a marketplace at all; neither of which is beneficial to the development company.

That doesn't really answer the question though. Why wouldn't the game development company could just create their own marketplace without the blockchain?

I don't really have a good answer to this question.

Why would a company that can afford to create a marketplace for their game(s) opt to use the blockchain instead of a more traditional solution?

Realistically, for the company, it's more beneficial for them to have 100% control over the marketplace and the in-game items. Look at Steam, taking a 10% cut of every CS:GO transaction is crazy; but as players, there is no other option for us. It's either use the Steam marketplace or don't trade the items at all.

So really, it's up to us as players to set the expectations from companies. The benefits of using NFTs for in-game assets actually benefits us as a player, by providing us more freedom in what we can use them for, and how we can trade them amongst each other.

Maybe, with the features and benefits of NFTs that we've described earlier, gamers will start to perceive in-game items as more valuable if they can access them outside the game; slowly enticing game developers to follow suit.

Maybe, the success of a game implementing these strategies like Midnight Society will encourage other game developers to explore NFTs & blockchains as an option.

Maybe, some other web3 game uses the outside-of-the-game features to create an epic marketing campaign that game developers see and want to mimic.

Maybe, this never happens and NFTs are never widely adopted in gaming.

These are all possible realities, and the truth is no one knows what's going to happen in the next 5 years of gaming. However, the sentiment that NFTs are scams for crypto bros closes avenues that might benefit us as gamers, and I think shuts down some of the cool opportunities that this can enable for us.

Let's move on to one more use case before wrapping up; identity.

Sharing Identity Across Games & Platforms

Something central to blockchains is the concept of accounts.

An account is your profile for the blockchain. It is capable of storing fungible tokens such as cryptocurrencies which can represent in-game currencies, and non-fungible tokens (NFTS) which can represent in-game items.

The great thing about this is that you can use this wallet identity as your account for all applications on a blockchain. Allowing you to bring your account and the data within it along with you to whichever applications you want to use.

This is relevant for games too, meaning you could carry over your identity such as your gamer tag, profile picture, and bio with you to any game platform; Steam, Origin, EA, Riot, or any other individual game.

This would allow you to verify the authenticity of your account across any game you choose to play; valuable to you as a player for several reasons:

• Other players know it's the real you with on-chain verification

• Other players can view your items/accomplishments from other games

• You can tie your on-chain identity with your in-game information

By linking your blockchain account with your in-game account, you could use this blockchain account to then sign into any other web3 application that supports connecting wallets; and have your in-game information available on these platforms too.

This is a built-in benefit of using blockchain infrastructure that we can already see today; for example, social applications built on the blockchain allows me to bring my profile and audience between applications; using the same profile for different apps like Lenster and Orb.

Wrapping Up

Overall, people, including myself love playing games for many reasons.

Earning money isn't anywhere near the top of that list... and I strongly disagree with the idea that that is going to change within the next five years.

This doesn't mean NFTs are dead, a scam, or something to shy away from. Blockchain technology has some real use cases that would add value to our lives and create deeper connections to the games we play.

With the right intentions, NFTs and other blockchain technologies have the potential to benefit both players and game developers alike.

Looking forward, I'm excited to see games like Midnight Society integrate these ideas in a way that considers what gamers want first, and the in-game economy second.

I'll walk through how to:

• Create a smart wallet factory contract (using EIP-4337 account abstraction)

• Create new smart wallets on-demand for users from the factory

• Allow users to interact with a smart contract from their created smart wallets

• Bonus: generate EOA wallets for users under the hood - for a signless UX!

Let's dive into it.

Recap: what's account abstraction again?

If you aren't already familiar with account abstraction or EIP-4337 in particular, check out my previous blog post for a beginner-friendly introduction:

TLDR: EIP-4337 adds several important features to better support smart wallets:

1. UserOperation: A new, special kind of operation that gets sent to a new mempool (a waiting zone to be picked up by nodes) called the "alt mempool".

2. Bundlers: Nodes that bundle together UserOperations from the alt mempool, and send them to a Entry Point smart contract for them to be executed.

3. Entry Point: A smart contract responsible for executing bundles of UserOperations that were submitted by bundlers.

Implementing Account Abstraction

All this sounds great, but how do we implement this in a real-world application?

That's what we're going to cover in this guide, we'll break it into two parts:

1. Creating & deploying the smart wallet factory contract.

2. Building a web3 application that creates wallets for users under the hood and allows them to interact with our app from their generated wallets!

Let's get started.

Creating a Smart Wallet Factory Contract

The first thing we'll do is create a factory contract, responsible for the creation of new smart wallet contracts. By using a factory, we can deploy new smart wallets for users on demand; simply by asking the factory to create a new one.

To create a factory smart contract, head to the thirdweb Explore page, and scroll down to the "Smart Wallet" section:

Select the Simple Wallet Factory smart contract, and click Deploy now:

Leave the default value for the _entrypoint parameter, and click Deploy Now again!

Deploy to one of the smart wallet supported chains such as Mumbai or Goerli.

In the future, all EVM chains will be supported, but currently, only 6 have the smart wallet infrastructure available to use.

Once deployed, you'll be taken to the dashboard for your smart contract:

Woo! 🥳 That's step one complete, we now have our own smart wallet factory contract deployed to the blockchain.

How the Wallet Factory Works

For those curious about how this smart contract works, this section is for you.

If you head to the Sources tab on your contract dashboard, you can see that the AccountFactory.sol contract inherits the BaseAccountFactory.sol contract; which is what provides us with the core functionality.

This contract includes features such as:

• createAccount: To produce a new smart wallet contract.

• addSigner and removeSigner: To control which signers can act on behalf of a smart wallet.

Each time createAccount is called, a new Account contract is deployed and initialized.

The Account.sol smart contract is the contract that gets produced by the factory.

It contains the functions required to be an EIP-4337 compatible smart wallet such as validateUserOp to confirm the validity of the operation, and execute to run the logic defined in the operation.

Why's this Matter?

What we're going to do with this factory is generate smart wallets for users under the hood. We'll perform a two-step process to easily onboard users into the application:

1. Generate a new EOA wallet for the user and store it on their machine

2. Generate a smart wallet for the user, using the wallet from step 1's signer as a valid signer for the smart wallet.

This way, the user will interact with our application from their generated smart wallet. By using the signer of the generated EOA to approve transactions, we can hide any prompts or approvals from the user.

Creating the Application

We'll be creating a Next.js + TypeScript application with the thirdweb React SDK installed to add our web3 features and capabilities.

To get started, create a new project with the SDK pre-configured by running the following command from your terminal:

npx thirdweb create app --evm --next --ts

You don't have to use Next.js or TypeScript, these are just my personal preferences.

Once the project is created, we're ready to start adding the connect wallet UI and integrate our account factory smart contract.

Get a thirdweb Developer API Key

From the thirdweb dashboard, connect your wallet and sign a message to get an API key; we'll need it for the next step.

Add Smart Wallet Support

Back in our application, head to the _app.tsx page and change the activeChain to be mumbai, or one of the other currently supported chains.

import { ThirdwebProvider } from "@thirdweb-dev/react";
import type { AppProps } from "next/app";
import "../styles/globals.css";

const activeChain = "mumbai";

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <ThirdwebProvider activeChain={activeChain}>
      <Component {...pageProps} />
    </ThirdwebProvider>
  );
}

export default MyApp;

The ThirdwebProvider component allows us to define a supportedWallets prop; to specify which wallets we want to support in the application. For us, we're going to specify that we want to support smart wallets.

Your code should now looks like this:

import type { AppProps } from "next/app";
import { smartWallet, ThirdwebProvider } from "@thirdweb-dev/react";
import "../styles/globals.css";

const activeChain = "mumbai";

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <ThirdwebProvider
      activeChain={activeChain}
      supportedWallets={[
        smartWallet({
          factoryAddress: "xxx", // Address of your account factory smart contract
          thirdwebApiKey: "xxx", // The API key you got from the previous step
          gasless: true,
        }),
      ]}
    >
      <Component {...pageProps} />
    </ThirdwebProvider>
  );
}

export default MyApp;

Create the Connect Wallet Button

On the index.tsx page, let's display a connect wallet button now. The thirdweb React SDK includes a ConnectWallet component, which reads the supportedWallets we just defined, and displays all of the supported options in a modal.

Simply import and render the ConnectWallet component on the home page:

import { ConnectWallet } from "@thirdweb-dev/react";
import type { NextPage } from "next";

const Home: NextPage = () => {
  return <ConnectWallet />;
};

export default Home;

Now let's preview our homepage by running npm run dev and visiting localhost:3000.

Voilà! Once we connect with a personal wallet (an EOA), we are connected to a smart wallet account. The address you see from the connect wallet button is the wallet address of your smart wallet account:

Note: This is a deterministic address; meaning this will be the address of the smart contract for this EOA/signer, but the actual contract is not deployed by the factory until a transaction is initiated by this smart wallet. We know the contract address ahead of time by using the predictDeterministicAddress function.

We can now interact with any smart contract such as an NFT drop directly from our smart contract wallet, and it will go through the full EIP-4337 flow.

I'll demo that process in the final section of this guide; showing you how our UserOperation gets picked up by the bundler, and sent to the entry point smart contract.

But first, let's talk about onboarding. With this setup, we still ask the user to provide an EOA before generating a smart wallet for them. Let's see how we can fix this.

Improving the Onboarding Experience

You might be saying something like "Isn't the point of account abstraction to improve onboarding? If users still need to have an EOA like MetaMask, what's the point of all this?"

The app we've built so far allows users to interact with our application using a smart wallet that gets generated for them. However, we still require users to connect a personal wallet / EOA beforehand.

This is because smart wallets still require a signature from one of the smart wallet's approved signers to confirm the action taking place on the smart contract.

Rather than asking users to provide their own wallet to act as a signer for the smart wallet we generate, let's also generate an EOA wallet, and use that generated wallet's signer as a signer for the smart wallet!

Introducing... local wallets!

Local Wallets

The local wallet is a non-custodial solution that creates wallets for users under the hood and stores the wallet's private key on the device.

This way, as the app developer, we are creating wallets for the user under the hood without them knowing, and storing the wallet's private key on the user's device.

By combining the local wallet with the smart wallet, we can provide a smoother experience, that looks like this:

1. We generate an EOA wallet for the user under the hood.

2. We then generate a smart wallet for the user under the hood (again, it is not actually deployed until it is required).

3. The generated EOA is a signer for the generated smart wallet.

4. The user interacts with our app without ever signing messages or approving transactions since we (the app developer) have access to their local wallet signer.

To replace the personal wallet step with this local wallet flow, we simply add an array of personalWallets to the smartWallet we set up earlier in the _app.tsx page, like so:

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <ThirdwebProvider
      activeChain={activeChain}
      supportedWallets={[
        smartWallet({
          factoryAddress: "xxx",
          thirdwebApiKey: "xxx",
          gasless: true,
          // Local wallet as the only option for EOA
          personalWallets: [
            localWallet({
              persist: true,
            }),
          ],
        }),
      ]}
    >
      <Component {...pageProps} />
    </ThirdwebProvider>
  );
}

Here, we're saying that the only option users have to connect with a personal wallet is a local wallet; one that we're going to generate for them.

On the UI, this shows the "Continue as guest" option to our users; which asks them to set up a password to secure their wallet on the device.

Users can re-enter this password next time they want to interact with our application to access the same wallet:

Now, we generate both the EOA and the smart wallet for the user. 🔥

When users interact with our contracts from within the application, they never see a "sign message" or "approve transaction" prompt!

The actions of the smart contract wallet are automatically signed by the generated EOA under the hood! Let's take a look.

Final Demo

View the demo: https://twitter.com/jarrodWattsDev/status/1655460223413522434

To showcase this process, I deployed a simple NFT Drop smart contract to view how users can now interact with our app and perform an action such as minting an NFT without ever connecting a wallet or signing/approving a transaction.

Let's view the full flow from a user perspective.

1. I click "Connect Wallet", type in a password, and the application generates an EOA wallet for me. Meaning I don't need to set up any browser extension/wallet.

2. A smart wallet gets generated for me under the hood. My EOA from step one is a valid signer for this smart wallet.

3. I click "Mint NFT", acting on behalf of my smart wallet.

   • The app uses my generated EOA to sign the message under the hood.

   • This approves the transaction for the smart wallet (since my EOA signer is a valid signer for the smart wallet).

From here, we kick off the EIP-4337 account abstraction flow.

1. After our EOA signs the message under the hood, a UserOperation is submitted to the alt mempool, containing the information that we want to mint an NFT to the smart wallet.

2. The bundler picks up this UserOperation, batches them together with other ones, and submits them to the entry point smart contract.

3. The entry point smart contract runs its handleOps function, which runs two functions on our smart wallet contract:

   • validateUserOps: Does this have a valid signature from one of my signers? (Yes, our app signs the message under the hood)

   • execute: Since this looks legit, let's actually run the code.

But... How is it Gasless?

After the execute function is run by the smart wallet, typically this is the point that the smart wallet contract would pay the gas fee for the transaction to take place.

However, since we set the gasless flag to be true in our application, this enables thirdweb's paymaster infrastructure to be utilized. Paymasters are smart contracts that can sponsor transactions for other users; AKA, pay the gas fee.

This allows our smart wallet to execute valid transactions without being pre-loaded with funds, and have the paymaster smart contract handle the gas fees; without using a centralized service such as a relayer!

You can view the full IPaymaster.sol interface on thirdweb's GitHub.

Wrapping Up

We've covered a lot in this guide, from generating EOA's, smart wallet factories, and EIP-4337 paymasters. I believe these will be important concepts for us to know in the coming months as we start to create better onboarding experiences for our users.

The bar to enter web3 applications is too high, and account abstraction offers a solution that is available to us now. It's up to us as developers to lower these gates and take the pain away from users by handling these complexities under the hood.

All of the resources I've referenced in this are open source and can be found below.

If you enjoy this kind of content, please consider following my blog for more written content and follow me on Twitter for video and short-form stuff.

Thank you for reading!

Links & Resources

Smart Contracts

• thirdweb AccountFactory.sol

• thirdweb Account.sol

• thirdweb IPaymaster.sol

Application

• thirdweb React SDK

• thirdweb Wallet SDK

Other Tools

• thirdweb CLI

• Set up our wallet to connect to the Polygon zkEVM

• Create and deploy a smart contract to the Polygon zkEVM

• Build a React application to connect and interact with the smart contract

Let's get started!

What is the Polygon zkEVM?

If you're not already familiar, Polygon zkEVM is an EVM-compatible zero-knowledge rollup. This means it acts as a scaling solution to the Ethereum blockchain; improving its scalability by enabling more transactions per second and significantly cheaper gas fees.

As developers, an important component of the Polygon zkEVM is its EVM compatibility, which means we can use the same tooling we know and love such as Solidity to build smart contracts and deploy them to the network; something that was previously not possible with ZK rollups.

Now we've got the basics down, let's dive into the building.

Setting Up the Polygon zkEVM

The Polygon zkEVM uses a bridge to transfer ETH from Ethereum to the Polygon zkEVM rollup.

In this guide, we'll be using the testnet to demonstrate the process, however the process is the same on mainnet, except you are dealing with real funds; I'll provide you with resources for both testnet and mainnet options.

Before we begin the bridging process, you'll need a wallet setup with some test (or real) ETH loaded in. I won't cover these topics as I'm assuming you likely already have this setup. Just in case you don't, below are some resources to help you:

1. Getting started with MetaMask

2. How to get testnet ETH using a faucet

Bridge Funds to the Polygon zkEVM Network

With a wallet setup and either real ETH or testnet ETH in it, you're ready to begin the bridging process. Head over to the bridge URL below to get started (pick either testnet or mainnet depending on which one you want):

• Testnet bridge

• Mainnet bridge

On the bridge, click the "Add to MetaMask" button to add the network information about the zkEVM to your wallet. Click "Approve" and "Switch Network" as the prompts appear.

Next, connect your wallet to the bridge by clicking on the button below:

Select the Ethereum network as the "From" network; to specify you are bridging funds from Ethereum to the zkEVM.

Enter the amount of ETH you want to bridge, e.g. 0.005 ETH, and click "Continue", and "Bridge" in the confirmation step.

Approve the transaction to initiate the bridging process.

Finally, click "Finalise" and approve the transaction to complete the bridging process.

Once completed, you should see the funds available in your wallet:

Nice! Now we've got some funds to use on the zkEVM. Remember you can send funds back to Ethereum through the bridge at any time; one of the awesome benefits of ZK rollups!

Creating a Smart Contract on Polygon zkEVM

Now we've got some funds setup, we're ready to start building! First, we're going to create a smart contract. In this guide, we'll build a simple ERC721 NFT smart contract; but you can create anything you like.

Creating the Hardhat project

We'll use Hardhat in this guide to keep it simple, but this process will also work for Foundry/Forge too.

To begin, let's create a new Solidity project by using the thirdweb CLI.

Run the following command in your terminal to get started:

npx thirdweb create contract

This command kicks off an interactive set of questions to create your Solidity project with the framework and standards of your choice.

Below, I'm using Hardhat with a basic ERC721 NFT smart contract as a starting point:

Creating the NFT Collection smart contract

If we open this project in our text editor, we can see we have a barebones Hardhat project with a smart contract in the /contracts/MyContract.sol file, containing the following code:

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

import "@thirdweb-dev/contracts/base/ERC721Base.sol";

contract Contract is ERC721Base {
    constructor(
        string memory _name,
        string memory _symbol,
        address _royaltyRecipient,
        uint128 _royaltyBps
    ) ERC721Base(_name, _symbol, _royaltyRecipient, _royaltyBps) {}
}

This is using thirdweb's ERC721 base contract which provides code for us to implement all the features of the ERC721 NFT standard, along with the ERC721A optimization to the standard.

Feel free to customize, override, or add any features you want to; or of course, build a completely different smart contract!

Deploying a Smart Contract to Polygon zkEVM

Now you've created the smart contract, you're ready to ship it to the zkEVM. To do this, we'll use thirdweb deploy.

Run the following command (from the same directory as your smart contract) to begin the deployment flow:

npx thirdweb deploy

This command completes all the steps required to prepare our contract:

• Compiles the smart contract using Hardhat

• Uploads the smart contract ABI to IPFS.

• Opens the thirdweb dashboard to deploy from your connected wallet.

No private key, RPC URLs, or config required!

Once this process is complete, open the URL that gets printed at the end of the command to be taken to the thirdweb dashboard.

Populate the Contract's Constructor Parameters

Connect your wallet to the dashboard, and provide values for any of your smart contract's constructor parameters. If you're following along with the NFT collection contract, the parameters are outlined below:

• Name: the name of your smart contract

• Symbol: Ticker symbol for each token in the contract, e.g. ETH or BAYC

• Royalty Recipient: Wallet address that receives funds from royalty fees

• Royalty Bps: What percentage royalty fee to take, e.g. 500 = 5%

Select the Polygon zkEVM Network

To specify that we want to deploy to the Polygon zkEVM, click "Configure Networks":

Search for "Polygon zkEVM", and you'll see options for both the Polygon zkEVM Testnet and Polygon zkEVM Mainnet:

Select the network and click "Add Network" to add the zkEVM as a deployment option. Close the modal and head back to the deploy page, and click "Deploy Now":

Finally, approve the "Contract Deployment" transaction.

Nice! You just deployed a smart contract to the zkEVM! 🥳 Feel free to explore the dashboard, where you can view and execute all the functionality of your smart contract from the UI.

Creating A Web3 App on Polygon zkEVM

Now we've shipped our smart contract, let's create an application that can connect to users' wallets, and have them interact with our smart contract.

To do that, we'll again use the thirdweb CLI to create a frontend application with the thirdweb React SDK installed.

Run the following command in your terminal to get started:

npx thirdweb create app

This will ask you a series of questions about the framework and languages you want to use to create your front-end application. In this guide, we'll use Next.js and JavaScript; but feel free to use what you're comfortable with!

Open up the newly created application in your text editor.

Connect the App to Polygon zkEVM

The first thing we'll need to do is configure the ThirdwebProvider to use the Polygon zkEVM network. We'll use the @thirdweb-dev/chains package to manage this connection for us.

From within your application, run the following command:

npm install @thirdweb-dev/chains@nightly

This package has over 700 chains for us to use and connect to, including the Polygon zkEVM testnet and mainnet.

Next, within the _app.js file, (or Index.js file for CRA/vite), import the PolygonZkevmTestnet from the chains package and set it as the activeChain prop:

import { ThirdwebProvider } from "@thirdweb-dev/react";
// Import the Polygon zkeVM chain and set it as the activeChain
// PolygonZkevmTestnet = testnet
// PolygonZkevmBeta = mainnet
import { PolygonZkevmTestnet, PolygonZkevmBeta } from "@thirdweb-dev/chains";
import "../styles/globals.css";

function MyApp({ Component, pageProps }) {
  return (
    <ThirdwebProvider activeChain={PolygonZkevmTestnet}>
      <Component {...pageProps} />
    </ThirdwebProvider>
  );
}

export default MyApp;

This manages our connection to the blockchain with a free RPC URL out of the box.

Connect to the Smart Contract

Head to the home page at index.js (or App.js) and connect to the smart contract you deployed using its contract address via the useContract hook.

Hint: you can get the contract address from the thirdweb dashboard.

Here's how our code looks so far:

import { useContract } from "@thirdweb-dev/react";

// Place your smart contract address here!
const contractAddress = "0x66CC8aB6a3bFD1e1510d4ED2115b26E2f13fdcfC";

export default function Home() {
  // Connect to your smart contract with the useContract hook
  const { contract } = useContract(contractAddress);

  return <div>Hello world!</div>;
}

To add the capability to connect to users' wallets, we could use the ConnectWallet UI component, but we're going to use the Web3Button UI Component instead, to allow the contract admin to mint an NFT after they've connected.

Mint An NFT Using the React SDK

The Web3Button connects to the user's wallets, switches them to the correct network (polygon zkeVM), and then calls some functionality on our smart contract when clicked.

First, import the button component from the @thirdweb-dev/react package, then provide the contractAddress and action props. The action is what occurs when the button is clicked; i.e. where we're going to mint our NFT.

import { useContract, Web3Button } from "@thirdweb-dev/react";

const contractAddress = "0x66CC8aB6a3bFD1e1510d4ED2115b26E2f13fdcfC";

export default function Home() {
  const { contract } = useContract(contractAddress);

  return (
    <Web3Button
      contractAddress={contractAddress}
      action={async (contract) => {
        return await contract.erc721.mint({
          name: "My zkEVM NFT",
          description: "I just minted an NFT on the Polygon zkEVM!",
          image: "your-image-url-here",
        });
      }}
    >
      Mint NFT
    </Web3Button>
  );
}

Here, we provide the metadata of the NFT we want to mint and use the mint function to upload and pin the metadata to IPFS before minting the NFT into the smart contract.

Run your application on your localhost to see the result, using npm run dev and visiting http://localhost:3000/. Click the button and accept the transaction to mint your first NFT!

On your contract dashboard, you can now see an NFT has been minted into the smart contract with the metadata you provided:

Awesome 🔥 we now have our very own NFT collection minted onto the polygon zkEVM network.

Displaying NFTs in the App

Finally, we can use the thirdweb React SDK to read information from our smart contract too. In this example, we'll use the useNFT hook to read the metadata of the NFT we just minted, and the NFT Renderer component to display it on the UI.

import { ThirdwebNftMedia, useContract, useNFT } from "@thirdweb-dev/react";

const contractAddress = "0x66CC8aB6a3bFD1e1510d4ED2115b26E2f13fdcfC";

export default function Home() {
  const { contract } = useContract(contractAddress);
  const { data: nft, isLoading } = useNFT(contract);

  return isLoading ? (
    <p>Loading...</p>
  ) : (
    <div>
      <ThirdwebNftMedia metadata={nft.metadata} />
      <h2>{nft.metadata.name}</h2>
      <p>{nft.metadata.description}</p>
    </div>
  );
}

Using a ternary operator, we now display a loading state while the metadata loads from IPFS, and show the metadata of the NFT on the UI once it's loaded:

Wrapping Up

That's it! We've covered everything you need to know when it comes to creating a full-stack application built on top of Polygon's new zkEVM; from setting up the network in your wallet to creating an app that allows users to connect their wallets and mint NFTs.

• Polygon announced the launch date for their zkEVM mainnet

• zkSync launched their zkEVM mainnet (just two days later!)

Why's this happening? WTF is a zkEVM? How do I use one?

Let's dive into it.

Wait, what's wrong with Ethereum?

Ethereum Mainnet is able to process roughly 15 transactions per second. We all know what this means; huge gas prices and long finality times, leading to a grim user experience.

Depending on how deep down the rabbit hole you are at this point, you may already be familiar with solutions to address this; sidechains, layer 2s, rollups... all that good stuff.

These were all built because Ethereum is currently too popular for what it is capable of handling. Despite this, the Ethereum Foundation has agreed they are not going to sacrifice security/decentralization to improve scalability.

This balance between decentralization, security, and scalability is known as the scalability trilemma. The long-term vision of Ethereum is to achieve all three of these qualities.

Why should we improve scalability?

Scalability refers to how well Ethereum can handle the demand for transactions to be processed. If more transactions can be processed faster, two things happen:

1. Gas prices go down

2. Finality (how fast your transactions are finalized) gets faster

So, if we're not going to sacrifice decentralization, how do we make Ethereum more scalable? There are multiple different solutions that are either already being used today, in the research/testing phase, or recently shipped to mainnet 😉.

Let's explore some of the existing solutions first, why they have problems of their own, and then dive into ZK EVMs as the potential "final boss" of scaling solutions.

What's been built to address this so far?

Most solutions built to address the scalability of Ethereum usually come with some kind of sacrifice in the other two qualities in the scalability trilemma.

"it scales better... buuuuuut <insert downside here>", is usually how it goes.

Let's take a closer look at each of them.

Sidechains

A sidechain is a completely separate blockchain from Ethereum, with different histories, roadmaps, and even consensus algorithms.

In order for a side-chain to actually be a side-chain, it is required to have a two-way bridge connecting it with Ethereum Mainnet, where data can be transferred between the two chains.

Polygon's PoS (proof-of-stake) is the most popular example of a sidechain.

Polygon PoS boasts a ~10,000x lower gas fee per transaction, and ~450x increase in transactions per second than Ethereum. Polygon PoS is awesome. Some of the biggest brands in the world have chosen Polygon as their partner; Adidas, Meta, Stripe, Reddit, and more.

However, sidechains sacrifice some measure of decentralization or security to achieve this higher throughput.

You can dive deeper into the risk assessment of scaling solutions on sites such as L2BEAT. For example, if we take a look at Polygon PoS, we can see this:

In addition, despite these sacrifices, Polygon PoS has had struggles with scalability several times in the past.

For example, in 2022, a play-to-earn game called Sunflower Farmers sent gas prices skyrocketing after the game took up over 40% of the network's gas fees.

More recently, transactions were failing from users' wallets due to incorrect gas estimations, as a result of the high demand on Polygon PoS.

Rollups

Rollups are different from sidechains in the sense that they're not "separate" from Ethereum. Instead, they publish transaction results onto Ethereum mainnet; allowing them to derive the full benefits of Ethereum's security in the process.

Rollups work by allowing operators to bundle multiple off-chain transactions together outside the main EVM, and then submit them all together to Ethereum; achieving 10 to 100 times improvements in terms of scalability.

On a technical level, these batches are submitted to a "rollup" smart contract that is stored on Ethereum mainnet; which keeps track of the rollup's state.

There are two kinds of rollups that exist today:

1. Optimistic rollups

2. Zero Knowledge (ZK) Rollups

A bridge allows you to transfer funds or data between Ethereum mainnet and a rollup.

Optimistic Rollups

Optimistic rollups such as Optimism and Arbitrum One are called "optimistic" because they assume the transactions that they roll up are valid by default.

They don't post any proof that the transactions are valid to Ethereum. Instead, transactions are "innocent until proven guilty", which includes a fraud-proving scheme that enables the detection of invalid transactions.

A "challenge period" is available for parties to contest the results of a rollup transaction by submitting a fraud-proof that can see whether or not a fraudulent transaction took place in that rollup.

If one is detected, the transactions are re-executed and the state of the rollup is updated. The party who submits the fraudulent transactions incur a penalty, creating an incentive mechanism within the ecosystem.

Okay, this sounds great. What's the downside?

Because of this challenge period, (usually around 7 days), you must wait until the challenge period is over before you can perform this withdrawal to Ethereum mainnet over the bridge.

There's also some level of reliance that at least one honest person is checking for fraudulent transactions to challenge the state of the rollup.

ZK Rollups

Alright, we're almost at the juicy part.

ZK rollups, unlike optimistic rollups, do post validity proofs to prove the correctness of the changes they post to Ethereum mainnet.

These validity proofs are "zero-knowledge proofs"; meaning the details of the statement that the rollup provides can be proven as true, without revealing the actual contents of that statement, using either zk-SNARKs or zk-STARKs.

Learn more about how validity proofs work in zk-rollups.

This removes the requirement for a challenge period, as the transactions are provably true as soon as the rollup contract verifies the validity proof. This means you can withdraw funds from ZK rollups to Ethereum mainnet without waiting!

Awesome, but what's the catch?

Unlike the other solutions we've talked about so far, ZK Rollups are not compatible with the EVM. This means you can't just point your Solidity contract at a ZK Rollup and ship it, which you can do with all of the other solutions we've described.

Whereas, with other solutions, you can simply change the URL of your deployment script and deploy the exact same code to Ethereum, Polygon PoS, Optimism, Arbitrum, etc.

That's the catch. You cannot do this with ZK Rollups... Until now!

Enter, zkEVMs.

What is a zkEVM?

The main reason ZK rollups are not utilized is that they have not been EVM-compatible in the past, making it extremely difficult to actually build anything on them.

If I've done a good job explaining things so far, the name "zkEVM" is hopefully self-explanatory to you... A zkEVM is a zero-knowledge rollup, that is EVM compatible.

zkEVMs enable all the benefits of a ZK Rollup, with the same developer experience of building on any other EVM chain like Polygon or Ethereum. Combining the best of both worlds, and potentially providing an answer to the scalability trilemma.

This technology unlocks all existing web3 dapps to simply change their deployment scripts to a different RPC URL and ship directly to the zkEVM, exactly the same way they do now.

zkEVMs handle the batching of transaction execution and post cryptographic proof that the result of those transactions is correct to Ethereum mainnet, all while maintaining EVM compatibility.

This means that every smart contract on Ethereum or Polygon PoS can now also be deployed to a zkEVM. Drastically improving the scalability of the smart contracts and the dapps that use them.

"In the medium to long term, ZK rollups will win out in all use cases as ZK-SNARK technology improves." - Vitalik Buterin

How do I build on a ZK EVM?

With all of the hype and releases of ZK EVMs, how do you actually build on one?

At thirdweb (where I currently work), we just shipped support for any EVM chain, including all the zkEVMs such as Polygon zkEVM, zkSync, Scroll and more.

Consider checking out the below guide I helped review by my awesome colleague and friend Avneesh Agarwal, which shows you how to:

• Add a ZK EVM network to your wallet

• Bridge funds from Ethereum to the ZK Rollup

• Deploy your Solidity smart contract to a ZK EVM

Or check out this 3-minute video to shipping an NFT collection on Polygon's zkEVM:

Wrapping Up

That's it! I've tried my best to condense the past few weeks of reading about Ethereum scaling solutions into a 5 minute read for you :)

What do you think? Are zkEVMs the holy grail for scaling Ethereum? Or are we just getting started? Let me know!

If you enjoyed this article, there'll be many more just like it coming soon. Consider following me to get notified when those are released!

The reality is, a poor UX is a significant drawback to building your application in a decentralized manner. While there are many solutions actively being worked on to address the issues, account abstraction is arguably the most promising.

It's an exciting paradigm that will allow anybody to interact with dapps; not just web3 enthusiasts, and is coming to reality with the latest Ethereum Improvement Proposal EIP-4337.

Let's dive into it!

Ethereum Accounts & Transactions Recap

Let's get through the boring stuff first. To understand account abstraction, we first need to understand what an account actually is when talking about Ethereum.

What Are Ethereum Accounts?

Ethereum has two different types of "accounts":

1. Contract Accounts

2. Externally Owned Accounts (EOAs)

You can think of a contract account as code (smart contracts) living on the blockchain that defines how the account behaves, and think of EOAs as a person (although a person could have many EOAs).

You probably are already familiar with EOAs. Your MetaMask wallet is an EOA. EOAs are made up of a cryptographic pair of keys: public and private keys that control account activities.

Contract accounts, however, don't have a private key. They're smart contracts that are controlled by the logic of the code within them; they're not controlled by a user.

The key takeaway here is that code defines what contract accounts do, and users control what EOAs do. This matters because smart contracts have the capability to do anything you can write in code, whereas EOAs can basically just sign transactions.

What Are Ethereum Transactions?

Alright, so that's accounts. What about transactions?

Every time you want to write information to the blockchain, such as transfer tokens, or mint an NFT, a transaction needs to occur. Transactions need to be signed by an EOA, and an EOA also has to pay the associated gas fees.

A transaction is initiated by an EOA, and can be sent to either:

• Another EOA, for example, an EOA transferring ETH to another EOA.

• A contract account, for example, minting an NFT from a drop.

How Web3 Works Today: EOAs & A Poor UX

Performing actions on the blockchain today is typically slow and tedious. Every time you want to write new information to the blockchain, you sign a transaction from your EOA to do so.

Once you're familiar with the process, this becomes the standard experience.

For new users, however, it's a nightmare.

The process of starting from scratch and interacting with a web3 application for the very first time is enough to put anyone off from entering the space, and that's just the beginning.

Here's a step-by-step experience that a new user goes through to perform their first action on a decentralized application from a fresh EOA:

This experience is brutal for any new user, tech-savvy or not. But it doesn't stop there, the initial setup is just the beginning of the user's concerns when using EOAs.

EOAs Are Extremely Risky

You're likely already familiar with somebody you know losing access to their EOA by either accidentally sharing or losing access to their private key. Some examples:

• Millions of dollars of cryptocurrency 'lost' after man dies with only password

• Man owns $321M in bitcoin but he can't access it because he lost his password

• Guy locks phone with potentially $6 million in crypto

The level of responsibility you have with traditional EOAs is dangerously high.

There's even a saying for it: "not your keys, not your crypto"; referring to the fact that if somebody else ever has your private key at any point (such as a centralized exchange), they have the power to control your funds; this point has been proven countless times in the past.

The harsh reality is that private keys are easy to lose and impossible to recover.

EOAs Have Limited Capabilities

As we touched on earlier, EOAs are very limited in their capabilities.

From your EOA, you're usually performing one of two typical actions:

1. Submitting a transaction to transfer tokens to another EOA

2. Submitting a transaction that executes a function on a contract account

Whoever has the private key can sign messages and initiate any transactions the EOA can handle. Knowing the private key of an EOA gives you the power to perform everything that an EOA is capable of. It's all or nothing.

EOAs Will Never Enable Mainstream Adoption

In the real world, losing your credit card doesn't mean you are completely doomed.

There are rules in place that allow you to do things like set payment limits, stop transactions, detect fraud, change funds to a new account, only allow funds to be transferred under certain conditions, etc.

In web3, if you make one mistake, your entire account is compromised and unrecoverable. EOAs even compared to centralized stores of currency is... 💩.

We've dunked on EOAs enough, let's finally discuss the solution.

What Is Account Abstraction?

Account abstraction is the proposal to allow users to use smart contract wallets instead of EOAs. This completely removes any need for users to use EOAs in order to perform transactions.

But why? What do contract accounts do that EOAs can't?

Smart contracts are infinitely more flexible in their capabilities than EOAs. Each smart contract can define different rules and configurations within its code.

Some examples of use cases can be seen below:

These are just a few of the capabilities that contract accounts offer over traditional EOAs. The key thing is; contract accounts are code.

This means anything you can write in code is therefore possible in a contract account.

History of Account Abstraction Proposals

Okay, this sounds great. Why aren't we already doing this today? Before we answer that, let's quickly give a brief overview of the history of account abstraction proposals dating back to 2016, and explore why EIP-4337 is different.

2016: EIP-86 - Proposal allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

2020: EIP-2938 - Proposal to create a new transaction with type AA_TX_TYPE. Transactions of this type are referred to as “AA transactions”.

2020: EIP-3074 - Proposal allowing users to delegate control of their EOA to a smart contract. Would allow any EOA to act like a smart contract wallet without deploying a contract.

None of these proposals have been merged into Ethereum. They are all currently in the "stagnant" category; meaning they have been inactive for a period of 6 months or greater.

Part of the reason for these proposals not being merged is that they require consensus-layer protocol changes to the Ethereum network.

Until 2021, when EIP-4337 was proposed; account abstraction on Ethereum without a consensus layer change required!

EIP-4337: Account Abstraction Using Alt Mempool

EIP-4337 introduces a "pseudo-transaction" object called a UserOperation; a structure that describes a transaction to be sent on behalf of a user.

User Operations go into an "alt mempool"; which is essentially a waiting room for storing information on unconfirmed transactions.

Nodes on the Ethereum network can choose to act as a "bundler". Bundlers pick up user operations from the mempool, and package multiple user operations into a single transaction known as a "bundle transaction".

Once they create a bundle transaction, they send it to a global "singleton" smart contract known as the "EntryPoint". There is only one EntryPoint smart contract on the entire blockchain. The bundler calls a function on the EntryPoint smart contract called handleOps.

This function receives the bundle transaction, and calls a special function on each account: `validateUserOp` . Each smart contract wallet must implement this function.

`validateUserOp` should verify the operation’s signature, and pay the fee if the account considers the operation valid, before continuing to execute the operation.

Each smart contract wallet also must implement a second function: expected to be called "execute" to actually perform the operation that is sent in by the EntryPoint contract.

A simplified flow of this can be seen below:

Why Does This Matter?

Contract accounts are the next evolution of wallets required to provide a much-needed improvement to the UX of web3.

The possibilities are really endless for what this change enables:

• Creating wallets for your users under the hood when they sign up for your app

• Session keys for web3 games (allow any X transaction for Y amount of time without the need for signatures on each transaction)

• Team wallets to use decentralized applications with tiered permissions

A grandma could be collecting NFTs and not even know what the blockchain is. Account abstraction enables everybody to use web3; not just tech enthusiasts.

Wrapping Up

In this post, we've outlined:

• The fundamental concepts of accounts and transactions on Ethereum.

• How EOAs fall short in terms of web3 user experience.

• What account abstraction does to solve it and how it works under the hood.

Account abstraction is a game changer for web3 and bringing decentralized applications to a mainstream audience.

The power to use smart contracts as your wallet brings endless possibilities and EIP-4337 is the latest proposal of account abstraction that doesn't require a consensus-layer change.

Thanks For Reading!

I appreciate you making it this far! 🙏

If you enjoyed this content, consider following me on Hashnode for more!

I'll outline the exact steps that I personally took to land a role as a developer relations engineer at thirdweb; a suite of developer tools for building in web3.

Unlike other roadmaps, I'm not going to give you 300 things to learn and get you stuck in tutorial hell. This is an actionable, sequence of technologies for you to learn, including the exact resources I found most helpful throughout my journey.

Let's dive into it! Below is a preview of each layer of the stack we'll be covering.

Important Disclaimer (READ THIS)

Consuming resources alone will never teach you how to become a developer.

Every dev has to constantly fight their own battles on the journey to understanding how to code, and put together the pieces of the gigantic puzzle along the way.

As soon as you know how to START building, exit the roadmap and go at it alone. Just try to build something. It's going to suck. And that's the point!

Come back to the resources to fill in the gaps in your knowledge as you get stuck; learn what tools are available for you to use that solve your problems with the resources in this guide.

Every project you make will be better than the last, and you'll soon be embarrassed by your old code.

DO NOT just consume these resources, they are only there to help point you in the right direction in a logical order as you actually build your own projects.

It's not going to be easy, but it is worth it. Buckle up and let's get started!

The Roadmap

We're going to cover a lot of topics in this roadmap, and I'll provide you with resources that I personally used to develop my understanding at each step of the way. Here's a quick preview of some of the tools we'll cover:

The Fundamentals: HTML & CSS

Every website consists of three things:

HTML: Structure of elements on the page

CSS: Style of elements on the page

JavaScript: Interactivity of elements on the page

Any application you build, no matter what technology you use, is eventually transformed into these three languages and served to a user on a web page.

Hence it's an important foundational piece of knowledge to understand the very basics of HTML and CSS first before diving into any "programming" (adding interactivity or logic to your application).

HTML & CSS

CS50 is Harvard's introductory course to computer science. It's an outstanding resource taught by the best lecturers in the world. I have taken multiple of their free online courses including their previous years' CS50 course and cannot recommend it enough.

Below is lecture number nine (starting at index 0) of the course that focuses on HTML, CSS and JavaScript. It teaches you the fundamentals of how web pages work and introduces how the three languages work together to create interactive websites.

Even if you already know HTML and CSS, you'll be surprised at how much you learn from these lectures by going back to basics and gaining a deeper understanding of the fundamentals.

JavaScript

Picking up the basics of HTML and CSS is significantly easier than learning JavaScript; which is a behemoth in comparison; but also a lot more fun!

First, you need to learn the absolute basics of programming before diving deeper into JavaScript itself. This includes concepts key to any programming language; variables, functions, loops, and data structures.

A relatively concise resource that will teach you these basic fundamentals is the below video, "JavaScript Tutorial For Beginners".

The video above is just an example of beginner-friendly content to understand the basics of JavaScript. There are plenty of others out there and I encourage you to learn as much as you need before advancing further into this roadmap.

Here are some more great interactive resources that you can use to learn as a beginner:

• Free Code Camp: Full JavaScript Course for Beginners

• The Odin Project

• Wes Bos - JavaScript30

• MDN Documentation

Optional (For Now): Computer Science Fundamentals

JavaScript is beginner-friendly and abstracts away many complexities of programming; it's designed so that you can hit the ground running quickly.

If you are willing to spend significantly more time learning the fundamentals of computer science, consider watching the full playlist of lectures for CS50 2022; which is ~20 hours total.

My personal opinion is that it's better to come back to these fundamentals later and start building something as soon as possible.

I personally didn't learn these computer science fundamentals in detail until 1-2 years into working as a professional software engineer (which might sound crazy, I know). Again, these are my personal opinions and others will disagree with this.

Advanced JavaScript

Here's where the learning curve reached a steep point for me.

The resources I'm about to share may feel overwhelming at first; it took me several re-watches and many, many pages of notes to start to understand these concepts.

How JavaScript Really Works

The below video goes deep into the nuances of JavaScript and how the magic of the language works under the hood! 🧙

Topics like scope, closures, and prototypical inheritance are funnily enough the topics I've been asked about several times in job interviews over the past few years.

This is another CS50 lecture from 2018, and is still one of my personal favourite resources for learning JavaScript to this day!

Asynchronous JavaScript

The subsequent lecture in this playlist is also quite complex but covers incredibly important topics for understanding JavaScript at a deeper level. You'll be introduced to some of the more modern features of JavaScript introduced in ES6 such as callbacks, promises, and asynchronous functions.

(Optional) Paid Course: "ES6 for Everyone!" by Wes Bos

An additional resource I recommend (if you can afford it) is the "ES6 for Everyone!" course by Wes Bos. It's an excellent interactive course that teaches you a variety of super helpful syntactic sugar that are part of the later releases of ECMAScript.

It's not essential, but Wes is a great teacher and the course is a fun way to learn the more efficient ways of doing things in JavaScript.

This course is very beginner friendly and will help you write more modern Javascript.

(VERY Optional) Paid Course: Master the Coding Interview

As you're on your journey and are building your projects, some code you write is not going to be as efficient as it could be.

A paid course that taught me a tremendous amount about writing better code is the "Master the Coding Interview: Big Tech (FAANG) Interviews" course by Andrei Neagoie.

The title of the course is a bit clickbaity, but it teaches you almost everything there is to learn about data structures and algorithms; with 30 interactive questions for you to go through; all in JavaScript!

For me, this was extremely hard and took me many months to get through; which is why I put the "very optional" tag on this course. It's an amazing resource that I recommend you take at some point on your journey, but if you're a beginner it's likely going to be too hard for you.

React - Building User Interfaces

If you've started building your project by this point, you've probably realised that it is difficult to build an application by writing HTML, CSS, and JS alone.

Developers have come up with many different libraries and frameworks to address these issues over the past decade; jQuery, Angular, Svelte, Vue... the list goes on!

One library has come out on top; React, which is:

• The most used frontend JS framework of 2022.

• The framework that most developers "want" to use in 2022.

• The most in-demand frontend framework for landing a job (too lazy to get a source for this stat, so... "probably" 😄).

React uses a syntax called JSX to combine writing your UI structure and design with your "interactivity" in the same location:

A great resource to understand the "why" of React is this CS50W lecture on user interfaces:

This lecture outlines the problems of building applications without a framework or library and introduces React as the solution to some of the problems you might already be running into.

Diving Deeper Into React

The React core team have been iteratively releasing its new "beta" documentation over the past few months (or years).

This new documentation is excellent and I strongly recommend you go through their Quick Start to learn all of the core concepts of React on one simple page.

You'll learn about the most common patterns of React like creating components, displaying data, and responding to events.

Before you dive too deep into building with React alone, I'll introduce you to another layer of abstraction on top of React, called Next.js; which takes things to the next level.

Next.js - Making React WAY Better

I'll save you a lot of struggle: completely skip Create React App (CRA) and arguably even Vite. Start by using Next.js right from the get-go.

Below is a great three-minute explainer of why CRA is no longer ideal for new projects using React:

Get Started with Next.js

Next.js documentation is absolutely brilliant. Lee Robinson and his team of DX engineers have written fantastic, interactive documentation to help you learn Next.js and quiz your knowledge along the way.

For this reason, I recommend running through the interactive documentation first; and then diving into creating your first Next.js application with their CLI.

TypeScript

Another hot take on this article 🌶️: Start using TypeScript ASAP! JavaScript is a great language for beginners, but this is a double-edged sword. Part of the reason it's good for beginners is that it gives you a lot of freedom to write 💩 code and it doesn't complain about it!

TypeScript can be a real pain in the 🍑 at first, but once it clicks, you'll never want to go back. More and more developers and developer tools are defaulting to TypeScript and for good reason; type safety makes your code significantly less likely to have bugs!

My suggestion: turn strict mode off at the beginning. Use the any type whenever you get completely stuck and don't know what to do. These are bad practices in reality, but will help you onboard to TypeScript without wanting to break your keyboard.

As you write more and more code with TypeScript and pick up more tricks, you'll feel comfortable enabling strict mode and using the any type more sparingly; until you eventually have complete type safety in your codebase and look at JavaScript in disgust!

Styling

There are a number of options for you to build out more beautiful applications that are ultimately just different ways of abstracting CSS so that it's ... well basically CSS but easier.

The general consensus going into 2023 is that Tailwind CSS is the gold standard for adding styles to your application. I personally like to use a tool called Material UI that comes with pre-built components; however, most people don't agree with me on this.

A great video weighing up the different options available and their pros and cons is "The Best of CSS" by Theo:

Short answer: If you don't already know and love a UI library, pick Tailwind CSS.

Blockchain Fundamentals

If you don't already have knowledge of what a blockchain or smart contract is, a helpful resource for beginners is Patrick Collins' blockchain course.

I suggest you watch the first 2 hours of the 32-hour course which introduces the core concepts of blockchain, smart contracts and web3. You can pick and choose the other areas of the course that interest you as you wish!

Understanding the Web3 Stack

An introductory video I recommend watching is "Defining the Web3 Stack", by Nader Dabit; which outlines the equivalent web3 tech stack compared to a traditional "web2" application.

As an updated graphic to Nader's talk in 2021, I have provided my thoughts on the tech stack of a web3 application below:

There are a lot of moving pieces to consider when building a web3 application. There are a plethora of tools available to help you build different aspects of your decentralized application, and it's up to you to learn what you like best.

Of course, I'll provide my recommendations here that I have come to after experimenting with a number of these tools in the past year.

Building a full stack web3 app "the hard way"

Arguably the best resource I consumed when I was entering the web3 space was Nader Dabit's "Full Stack NFT Marketplace" video tutorial. You'll learn how to build almost every aspect of a full-stack web3 application at a rapid pace, including:

• NFT Collection smart contract

• NFT marketplace smart contract

• Smart contract development environment and testing

• IPFS file uploads and downloads

• Frontend technologies & Next.js to build a web3 application

• RPC nodes and IPFS Gateways

This might feel like quite the jump from the previous step, and you might not understand everything in this video immediately, and that's okay!

This resource taught me a tremendous amount about how the pieces of the web3 stack fit together and teach you how to build an epic project with modern technologies.

Extending Nader's Project

Something that really made me understand what was happening was adding more functionality to Nader's NFT marketplace project; specifically, adding a function to get an individual listing's information on the marketplace smart contract.

Adding this capability to the project might sound easy, but it tests to see if you really understand how the project is functioning; and is a great step to add on top of the build itself.

Why is this "the hard way"?

This resource introduces you to what I'd argue is a low-level abstraction of building a full-stack web3 app; it shows you every step of the process which is super important to understand.

However, I'd argue that the purpose of the video isn't to build a "production-ready" application in 2023. I say this because there are a large number of tools that have been released since mid-2021 (the time this video was made), that has abstracted away the complexity of building full-stack web3 applications significantly.

Let's quickly cover a few other core concepts and then dive into the more modern tools available to build web3 apps with.

RPC Nodes

To communicate to and from the blockchain, you need to use a node. Unless you want to run your own Node, you need to use a service provider such as Alchemy, Coinbase, or Moralis, (or thirdweb as we'll explain in the next section) to do so.

Below is a great resource outlining what an RPC Node is and why it's required to build web3 applications.

Interesting Project: Lava Network

A project I am excited to see in 2023 is Lava Network; which offers a decentralized alternative to the RPC Nodes. Check it out if you are interested!

Decentralized Storage Solutions

Not all information needs to be stored on the blockchain. Storing data on the blockchain itself costs gas fees and has a significant storage limit; for this reason, a common pattern is to store your information "off-chain" and store the URL of that data on the blockchain instead.

Storage solutions exist that aren't stored "on-chain" but are still not controlled by a centralized service such as AWS or Google Cloud. The two prominent decentalized storage solutions solutions in 2023 are:

1. IPFS

2. Arweave

IPFS

Below is a concise summary of what IPFS is, how it works, and how you can integrate it into your applications using thirdweb (we'll talk more about this next).

To access data stored on IPFS on most browsers such as Google Chrome, you'll need to use an IPFS Gateway. There are a couple of options available for you here:

1. Public gateway (available for everyone, not very reliable)

2. Private gateways - using services such as Pinata or nft.storage for faster speed and higher availability, (again, or just use thirdweb as we discuss next).

Arweave

Another excellent video by Nader Dabit is available for you to understand Arweave and other aspects of the Arweave ecosystem such as Smartweave and Warp.

I should mention a lot of these technologies such as Arweave have grant programs if you are building with them; if you're looking for some funding this might be interesting to you.

thirdweb

Full disclosure: I work on the thirdweb team!

I used Nader's NFT marketplace video as a starting point for a freelancing project I was working on as I began to increase my skills in web3 development. I came to the realisation that building smart contracts is HARD!

I didn't have the confidence at this point to write a fully-featured, gas-optimized, bug-free marketplace smart contract for my clients' requirements; so I started to ask myself: "someone must have done this and open-sourced it somewhere RIGHT!?"

Well, turns out I was right!

I stumbled upon thirdweb shortly after it was released and discovered they had open-source smart contracts for NFT collections, marketplaces, and more.

I basically planned to just copy-paste their solidity smart contracts into my existing project and carry on my way 😂! Here's proof (don't tell Furqan):

But as I explored the product more, I discovered they had an SDK! I didn't have to use ethers anymore! They also have tools to connect users' wallets, and manage my IPFS storage for me! I didn't even need my smart contract code in my project anymore as they had a dashboard I could deploy it with.

I was able to remove SO MUCH of the code I wrote for my marketplace project and replace them with thirdweb tools that I ended up falling in love with the product; and applied for my current position at thirdweb a few months after completing my freelance work!

So, while I do get paid to advocate thirdweb's products, I do it from my heart, not from my ... wallet? 🥲 I was really out here using their tools before I joined the team.

Learning thirdweb

I've spent a lot of time refining the Getting Started flow of the thirdweb documentation to get you up and running from building a smart contract to building a front-end Next.js application in no time! So, my recommendation is to start there!

Alternatively, there is a getting started video that covers the same content:

Once you get the power of thirdweb's stack, you won't want to go back! 🤠 Since I joined, we have shipped even more features that make the web3 building process simpler:

• Free IPFS gateway and IPFS rendering components in the SDK.

• Free RPC included directly in the SDK (which can be overridden).

• IPFS upload and downloads in React hooks with Storage.

• React hooks for everything you can imagine on the frontend; for both user wallets and interacting with smart contracts.

• Full Solidity SDK called "ContractKit" which is similar to OpenZeppelin.

• An Explore page; for you to deploy the most popular smart contract standards.

• Much more!

Deploy a smart contract with thirdweb and connect to it in your Next.js application and I promise you'll never want to go back to your old stack.

Other Web3 Frontend Libraries

So that I'm not completely biased, I'll also recommend you some of the other modern libraries available for you to build more robust frontends for your web3 apps.

wagmi

wagmi is a library of React Hooks for building EVM frontends. Much like the thirdweb React SDK, it has hooks for pretty much everything you can imagine and is significantly better than using ethers or web3.js alone.

The documentation is a great starting point for you to understand how to use it in your Next.js/React apps.

Rainbow Kit

RainbowKit is an excellent library for adding connect wallet capabilities into your application and supporting a variety of different connection options for your users.

Their documentation is concise and includes helpful short videos to get you up and running quickly.

Indexing Solutions

Some web3 applications require information that isn't directly available from any smart contract; such as what NFTs a wallet owns, or how many times an NFT has been transferred.

When it comes to indexing solutions, you can use The Graph; a decentralized solution, and again use Nader's resources to learn how to get started:

You might prefer to use SDKs or API endpoints to get your indexed information, and there are a number of popular solutions you can use, each with helpful resources and videos on their documentation:

• Alchemy

• Coinbase Cloud

• Moralis

These tools have similar capabilities with various pros and cons, you can use their documentation to explore which tool is right for you.

Smart Contracts

This might seem crazy that the smart contracts section is all the way down here. 🤯

The reason I placed smart contracts after learning the full frontend tech stack is that you are often going to be building on top of smart contracts that other people have deployed already; such as Lens Protocol, or deploying gas-optimized, audited smart contracts that suit your needs such as those available on thirdweb Explore.

To land a job in web3 you don't need to be an expert in writing your own smart contracts. At thirdweb, we have a team that is dedicated to writing Solidity smart contracts and building out our Solidity SDK; the rest of our engineers understand the Solidity code; but aren't actively writing smart contracts on a daily basis.

This might be a hot take 🌶️🥵 but you should learn the details of building smart contracts after learning how to actually build stuff people interact with; which usually means you need some kind of frontend application skills.

Some people will disagree with that; as almost everything in web3 depends on the foundational layer of decentralized applications; which is smart contracts. I'm not saying it's correct, this is just the path that I personally took to learn web3.

There are many resources you can use to learn Solidity itself, such as:

• CryptoZombies (interactive course)

• Literally, just read the Solidity documentation 🥸

Object Oriented Programming

OOP. more like oof, am I right? 😑

Solidity is an object-oriented programming language to build your own smart contracts. If you know OOP principles you are already most of the way there to be able to write basic Solidity.

Usually, you don't see JavaScript used for object-oriented programming; other languages like Java, C#, or Python are better suited for this style of writing code.

To get the basics of OOP down, I recommend you consume as many resources as you need to to get the basic principles down. Below is an introduction to OOP in JavaScript that will help you get the core concepts:

OOP In Solidity

Once you know what OOP is, I recommend you return back to Patrick's video at this timestamp (chapter 3), to see how inheritance and overrides work in Solidity:

Using OSS Smart Contracts

Usually, you'll want to build some variety of ERC standards such as ERC20 fungible tokens, ERC721 NFTs, or marketplaces, with a twist that makes your project unique.

Now that you know how to utilize inheritance in Solidity, you can make use of libraries such as OpenZeppelin Contracts and thirdweb ContractKit to import core chunks of logic into your smart contracts; and customize them as you wish!

ContractKit

thirdweb's ContractKit has a vast array of plug-and-play smart contracts for you to extend, customize, and include in your own smart contracts; including ERC721, ERC1155, ERC20, staking, airdrop, and more 🤠!

Smart Contract Security

It is important to know the most common vulnerabilities of smart contracts, which again Patrick covers thoroughly in his 32-hour Solidity course in Chapter 18 at this timestamp.

There is also a detailed open-source repository outlining common attack vectors for smart contracts and historical exploits using these attacks:

Conclusion

That's it! These are the resources I personally used to develop my knowledge in web3 and land a job as a developer relations engineer at thirdweb!

I'd like to reiterate that tutorials and resources alone will never be enough to become a dev. You need to get your hands dirty ASAP, come back to these resources as you run into problems in your project, and constantly fight battles on your own over many years to come.

The goal of this article isn't to give you months of resources to consume, it's here so you can come back to trusted sources of high-quality information as you build your own projects alone! 🦸

If you want to join a community of devs on your journey, jump into my community Discord server and introduce yourself! 👋

By the end, you'll have a cross-platform app that looks like this:

Let's get started! 🤠

Create A React Native App

We'll be using Expo, a platform for making mobile applications written in React Native to build our application.

Create a Project with the Expo CLI

To get started, first, install the Expo CLI globally:

npm install --global expo-cli

Then, run the command below to create a new React Native project:

npx create-expo-app lens-react-native

Change directories into the newly created project and open it up in your text editor!

cd lens-react-native # Change directories into your newly created project
code . # Open your project in Visual Studio Code

Optional: Add Web Support

If you want to preview your application on your browser rather than your phone during development, run the command below:

npx expo install react-native-web@~0.18.9 react-dom@18.1.0 @expo/webpack-config@^0.17.2

This allows us to run npm run web to preview our application on localhost like so:

Setting Up Lens Protocol

We'll use the React Native Lens UI Kit to integrate decentralized social media functionality into our app. The Lens UI Kit is a set of pre-made components that allow you to read data from the blockchain within a React Native app.

Install the UI Kit by running the following command:

npm install @lens-protocol/react-native-lens-ui-kit

I'll show you how to add a feed and a profile page, however, you can explore all of the components available in the README file if you wish to explore further!

Adding Navigation

To allow navigation between pages, we'll install two more packages in our project:

npm i @react-navigation/native @react-navigation/native-stack

In your App.js file, create a NavigationContainer containing a Native Stack Navigator with two screens; one for our home page and one for a user's profile:

import { NavigationContainer } from "@react-navigation/native";
import { createNativeStackNavigator } from "@react-navigation/native-stack";

import Feed from "./Feed";
import Profile from "./Profile";

const Stack = createNativeStackNavigator();

export default function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen name="Home" component={Feed} />
        <Stack.Screen name="Profile" component={Profile} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

Feed Page

Create a new file at the root of your project called Feed.js.

We'll use the Feed component provided by the Lens UI Kit to show a feed of the latest posts on Lens:

import { Feed } from "@lens-protocol/react-native-lens-ui-kit";

export default function FeedPage({ navigation }) {
  return (
    <Feed
      onProfileImagePress={(press) =>
        navigation.navigate("Profile", { profile: press.profile })
      }
    />
  );
}

Here, we provide the onProfileImagePress prop, which navigates the user to the Profile page when they click one of the user's profile pictures on a post (example circled below).

This component creates a chronological order of posts for us like so:

Profile Page

Using the onProfileImagePress prop, we navigate the user to that user's profile page.

Create another new file at the root of your project called Profile.js and populate it with the following code:

import { Profile } from "@lens-protocol/react-native-lens-ui-kit";

export default function ProfilePage({ route }) {
  return <Profile profile={route.params.profile} />;
}

Here, we use the Profile component provided by Lens to render a feed of posts made by that user as well as their profile information:

Demo

Run your application using one of the following commands to get a preview:

npm run web # Open in your browser
npm run ios # Open on your iPhone
npm run android # Open on your Android phone

Final Thoughts

The React Native Lens UI Kit is an incredible way to get started building social media apps on top of the Lens Protocol.

Currently, the kit is in an alpha release, meaning there are a lot of new features to come, outlined in their beta roadmap, such as:

• Authentication (signing in with Lens)

• Custom styling and components

• Support for GIFs and videos

Most importantly 😉 TypeScript support is coming in their V1 release! 🎉

This guide will cover why React Query is an excellent tool to take your code to the next level when building full-stack applications.

Recently, I joined thirdweb and the React SDK uses React Query all over the place! But Why? What's all the hype about?

This guide will cover:

• Why use React Query
• Reading data with React Query queries
• Writing data using React Query mutations
• Using React Query in a Next.js project

Why use React Query?

If you've ever built an application that involves some kind of API or requesting data before, you're probably familiar with this pattern:

1. Create some stateful variables using useState, like data, isLoading, isError.
2. A useEffect hook that fetches some data from an API, and updates these stateful variables accordingly
3. On the UI, show a loading state while the loading flag is true, or show the data or an error when it is available.
4. Another useEffect, that listens for updates and keeps the state variables up-to-date.

Before you know it, you've got 50-100 lines of React code just to keep track of data for one page!

This still hasn't taken into account caching, memoization or performance optimizations like pagination!

What if you could use one hook, useQuery that handles all of this for you? And another hook, useMutation to keep your read and write operations in sync!

React Query is designed to help resolve these issues, and claims to "defeat and overcome the tricky challenges and hurdles of server state".

Let's explore it together and learn how we can improve our apps with this helpful library!

Installation

For this project I'll be using Next.js and TypeScript:

npx create-next-app@latest --ts

Then I'll install the react-query library

yarn add react-query

Making Queries

Querying refers to the process of fetching or "reading" data.

In React Query, a query is defined as:

A declarative dependency on an asynchronous source of data that is tied to a unique key.

To break that sentence down:

1. A query uses an asynchronous function that fetches some data, (e.g. fetchPosts)
2. Each query has a unique key that identifies itself, which is used for re-fetching and caching, (e.g. posts)

For example, in step 1, you might have a function that fetches a list of todos from your database called fetchTodoList.

In step 2, you can use any name you like to define this query, let's say todos is the key to fetch all todos.

Combining them together, you end up with this:

const result = useQuery('todos', fetchTodoList)

Here, the result value contains a tonne of info, which you can de-structure as you please. It contains:

Flags:

• isLoading
• isError
• isSuccess
• isIdle
• isFetching

Data

• error
• data 👈If your data fetching function ran successfully, the result is in here.

Typically you might de-structure this result to look like this:

const { isLoading, isError, data, error } = useQuery('todos', fetchTodoList)

And to take it a step further, you can re-name the data variable to be something meaningful:

const { data: todos } = useQuery('todos', fetchTodoList)

Then, you can reflect all of these states on the UI, and show the data once it's loaded:

 function Todos() {
   const { isLoading, isError, data, error } = useQuery('todos', fetchTodoList)

   if (isLoading) {
     return <span>Loading...</span>
   }

   if (isError) {
     return <span>Error: {error.message}</span>
   }

   // We can assume by this point that `isSuccess === true`
   return (
     <ul>
       {data.map(todo => (
         <li key={todo.id}>{todo.title}</li>
       ))}
     </ul>
   )
 }

Query Keys

Okay, but why did we need that key called todos? Couldn't we have just used the function itself?

Here's where caching comes into play.

React Query is essentially building an object that contains a key-value pair for each query you make.

The key is the name of the query you made, todos.

The value is the result of that query (the data).

Let's break it down step-by-step and see why this is useful:

1. You make a query to fetch all of your todos using the fetchTodoList function. Let's say you get two todos back in the result of this function.
2. React Query creates an entry into its mapping, saying "todo" is equal to those two queries.
3. Next time you need this todos data, you run the exact same query, using fetchTodoList, and the same key, todos.
4. React Query checks its mapping to see if it knows about this todos key, because if it does, then it can just return the data it kept knowledge of in step 2, rather than re-running the query again.

This saves your application from re-fetching data that has already been calculated, because that data has been stored in a cache.

Now let's imagine the query to get fetch todos takes 2 seconds.

Your app just got a whole lot faster, saving 2 seconds every time you would have re-fetched these todos from the database.

Technically...

But wait, there's more!

Now let's imagine you have multiple users in your application.

The result of the todos query will be different for each user, this is why you can define the key to be an array, rather than just a string.

For example, currently, the key to identify our query is just "todos".

Behind the scenes, React query is actually converting this key to an array: ['todos'].

If we wanted to have different cached results for different user we can use an array as a key instead:

User One:

useQuery(['todos', 1], fetchTodoListForUser(1))

User Two:

useQuery(['todos', 2], fetchTodoListForUser(2))

The array value here is serialized and used as the key value of the cache. The result? Different cached values for different users.

Dependent Queries

Often in our applications, we might have this pattern:

1. Fetch some info
2. Fetch more info, but info that depends on info from step 1

For example:

1. Fetch a post by its ID
2. Fetch the user info for the user who posted this, using the result of step 1

Without React Query, you'd likely:

1. Fetch the post
2. Store it in a state variable, along with some loading and error flags,
3. Create a useEffect to listen for when that post has been loaded
4. If that post data came back successfully, and has a userId field, then, inside another useEffect; fetch the user.
5. Store the user in another state field (again, with loading and error flags)

By this point, you've easily got 50 lines of code for two read operations!

Let's compare that to React Query's Dependent Queries:

 // Get the post by it's id
 const { data: post } = useQuery(['post', id], getUserByPost()

// Get the user id of the user that posted this post
 const userId = post?.ownerId

 // Then get the user information
 const { isIdle, data: user } = useQuery(
   ['user', userId],
   getUser,
   {
     // The query will not execute until the userId is available
     enabled: !!userId,
   }
 )

We've converted it down to less than 10 lines of code, gained caching, re-fetching, and a more error-safe way of reading multiple data sources just by implementing React Query!

Mutations

Mutations are "write" operations (as opposed to "read" operations).

They're used to create, update, or delete data.

The real power of React Query's mutations comes with the onSuccess operation.

In a real-world application (without React Query), you might do something like this:

1. Call a function that adds a piece of data
2. Once that function ran (if it succeeded), manually update the state with the new data
3. Let React re-render the page with the updated state

Let's take a look at how we can solve this pattern using React Query.

A typical mutation in React Query looks like this:

const mutation = useMutation(postTodo)

Nothing special, but again, we can de-structure mutation to get meaningful flags and information about how our write operation is performing and where it's at.

• isIdle
• isLoading
• isError
• isSuccess
• error
• data

Let's say we have a function that allows a user to create a todo in the database called addTodo.

Whenever they add a todo, we need to update the query we have that fetches those todos, to let it know that there are new todos to fetch and that the result it currently has is invalid now.

To achieve this, we can combine:

• useQueryClient
• invalidateQueries
• the mutation's onSuccess event.

 import { useMutation, useQueryClient } from 'react-query'

 const queryClient = useQueryClient()

 // When this mutation succeeds, invalidate any queries with the `todos` query key
 const mutation = useMutation(addTodo, {
   onSuccess: () => {
     queryClient.invalidateQueries('todos')
   },
 })

That's one way to do it. But this way, we're re-fetching ALL of that data again, when we really just want to let the query know that one new thing was added, so it's pretty inefficient.

For this case, we can use setQueryData instead, to tell our query that there has been an update, rather than telling it that the whole thing is invalid and re-fetch.

 const queryClient = useQueryClient()

 const mutation = useMutation(editTodo, {
   onSuccess: data => {
     queryClient.setQueryData(['todo', { id: 5 }], data)
   }
 })

 mutation.mutate({
   id: 5,
   name: 'Do the laundry',
 })

 // The query below will be updated with the response from the
 // successful mutation
 const { status, data, error } = useQuery(['todo', { id: 5 }], fetchTodoById)

Using Next.js

We've only talked about client-side querying so far.

What about server-side rendering and static site generation?

Should you use React Query for that?

Short answer: yes!

Long answer: Yes, using prefetchQuery, dehydrate, and wrapping your application inside a QueryClientProvider a Hydrate components.

Wrapping your _app.tsx file:

import React, { useState } from "react";
import { Hydrate, QueryClient, QueryClientProvider } from "react-query";
import type { AppProps } from "next/app";
import "../styles/globals.css";

function MyApp({ Component, pageProps }: AppProps) {
  const [queryClient] = useState(() => new QueryClient());

  return (
    <QueryClientProvider client={queryClient}>
      <Hydrate state={pageProps.dehydratedState}>
        <Component {...pageProps} />
      </Hydrate>
    </QueryClientProvider>
  );
}

export default MyApp;

Fetch some data on the server-side

 // pages/posts.jsx
 import { dehydrate, QueryClient, useQuery } from 'react-query';

 export async function getStaticProps() {
   const queryClient = new QueryClient()

   await queryClient.prefetchQuery('posts', getPosts)

   return {
     props: {
       dehydratedState: dehydrate(queryClient),
     },
   }
 }

Hydrate the data on the client-side:

const Home: NextPage = () => {
  // This useQuery could just as well happen in some deeper child to
  // the "Posts"-page, data will be available immediately either way
  const { data } = useQuery("posts", getPosts);

  console.log("Data:", data);

  return <div>hello world</div>;
};

This uses some intimidating terms like dehydrate and prefetch, but let's break it down.

Next.js pre-renders the DOM so that the user can view the information on the page quickly, without having to wait for the query to run (we do that at build-time when we statically generate the page).

At this point in time, we have a "dehydrated" state for React Query.

dehydrate creates a frozen representation of a cache that can later be hydrated with Hydrate, useHydrate, or hydrate. This is useful for passing prefetched queries from server to client or persisting queries to localStorage or other persistent locations. It only includes currently successful queries by default.

You'll notice we are returning a dehydratedState variable on the server-side as props to our component. This is important for the next step.

We hydrate the query on the client-side, using the queries inside of the dehydratedState variable, and hydrate them.

hydrate adds a previously dehydrated state into a cache. If the queries included in dehydration already exist in the queryCache, hydrate does not overwrite them.

This way, we get all the benefits of the React Query library, like caching and re-fetching, but with data that originally came from the server-side.

Conclusion

If you find yourself using useState and useEffect to manage your data, I'd suggest checking out this amazing tool, React Query!

React Query is an exciting, easy-to-implement library with excellent documentation to match.

It achieves its goal of overcoming the tricky challenges and hurdles of managing state on both client and server, and I will be integrating it into all of my projects going forward!

This guide discusses the basics of React Query and why you might want to use it, including:

• Why use React Query
• Reading data using React Query's queries
• Writing data using React Query's mutations
• Real-world examples of server-side rendering and client-side hydration.

Follow Me

If you enjoyed this article, follow me on Twitter for more thoughts on full-stack development particularly in the web3 space!

In this guide, we will create:

1. An ERC-721 NFT Drop smart contract with lazy minted NFTs users can mint
2. Your own ERC-20 token smart contract
3. An NFT Staking Smart Contract where users can stake their NFTs, and earn tokens for doing so!

By the end, we'll have a full stack web application where users can see which NFTs they own, stake them onto the smart contract, and claim their rewards!

Let's do this!

What We'll Build

You can check out a demo of the finished product below:

https://nft-staking-contract.thirdweb-example.com/

Source Code

You can access the full source code from here:

Let's get started!

Creating the NFT Drop Smart Contract

Our objective with the NFT Drop is to upload all of our NFT metadata, and then allow users to come to our website and mint a random NFT from our collection.

We can do this using thirdweb's Pre-built NFT Drop Contract!

thirdweb's drop contracts lazy mint your NFTs and makes them available to be claimed by your users.

That's exactly what we need! Alright, let's go ahead and create our NFT Drop!

Creating the NFT Drop Contract

Head to the thirdweb dashboard and connect your wallet.

Then click on Deploy New Contract.

What we want is the NFT Drop contract, lets click Deploy Now on this one!

You can configure the Name, Symbol, Description, Image, and Royalty information in the settings before you deploy your NFT Drop.

I'll call my NFT Drop Colored Shapes and stick with the default values for the rest of the fields, but feel free to go wild and configure this to your liking!

Once you're happy, let's deploy this NFT Drop onto the Mumbai (MATIC) Test network.

This will prompt you to accept a transaction in MetaMask (or whatever wallet you connected with), and deploy your smart contract onto the Mumbai Test network!

You might notice that the MetaMask transaction is requesting we Deploy Proxy. What on earth does that mean? Let's quickly explore what happens when we deploy a pre-built contract on thirdweb.

Pre-built contracts and deploying a proxy

thirdweb v2 introduced Proxy Contracts. For a full breakdown, you can check out the documentation on how thirdweb pre-built contracts work.

In a nutshell, the bulk of the smart contract logic has been created and deployed by thirdweb; you're just deploying a Proxy Contract, that stores information specific to YOUR smart contract. Such as the name, description, symbol, owner, and royalty configuration.

Since all of the NFT Contracts deployed on thirdweb have the same logic for things like minting and burning NFTs, we can simply delegate these function calls to the thirdweb base contracts; where the "real" logic lives.

This way, it is around 10 times cheaper to deploy our smart contracts, since we deploy a lot less code, and let the thirdweb base contracts handle all the logic for us.

Here is a simple diagram to explain how this works:

Alright, now we know what we're deploying, lets's Confirm that transaction and continue!

Setting Claim Phases

Claim Phases are conditions we can configure that define when and how users can claim NFTs from our collection.

A popular claim phase pattern is to have one claim phase where allow-listed wallets can claim, then another phase where any wallet can claim.

From the thirdweb dashboard, let's click Set Claim Phase and configure a simple claim phase where anyone can mint/claim our NFTs.

Click on Add Phase, and configure it to your liking!

I'm going to change the How many NFTs can be claimed per transaction? to be 1, and accept the default values for the other fields.

Once you're happy with your claim phase(s), click Update Claim Phases

Lazy Minting NFTs

Awesome, now we have a claim phase set up, users can start claiming NFTs from our collection! So let's create those NFTs now.

thirdweb's Drop contracts Lazy Mint your NFTs. That means the user who claims the NFT is the one who actually does the minting of the NFT they claim.

When you add NFTs to your drop contract, they are not minted at this point. You prepare everything for your users so that they can mint the NFT(s). This means the user who claims the NFT is the one who mints it, and it is minted into their wallet. By default, the user is the one who pays the gas fees.

So now all we need to do is upload the metadata for our NFTs, such as the images, names, and descriptions of each NFT.

How to Batch Upload NFT Metadata

If you don't already have NFTs that you want to upload, you can use thirdweb's example files to create a dummy NFT Collection. You can access either of those via the links below:

• Example CSV File
• Example JSON File

Upload your metadata file along with your images into the drag-n-drop area, and voilà!

Your NFTs will be ready for you to upload:

Make sure you're happy with how everything looks, then scroll to the bottom and click Next!

You'll then be given the option to add a Delayed Reveal, which is up to you! For the purpose of this guide, I will choose Reveal upon mint.

Then I'll hit Upload 30 NFTs!

We're again prompted to approve a transaction, this time the name is a bit more obvious - we're Lazy Minting the NFTs we just uploaded, so I'll click Confirm.

Once the transaction is confirmed, we can see all of our NFTs that we just uploaded in the Overview tab of the NFT Drop.

Awesome! Now our users are ready to start minting the NFTs from our collection.

Before we set that up, let's create our very own ERC-20 token too.

Creating the ERC-20 Token

Creating our token is even easier than creating our NFT Drop, we'll follow the same path of clicking Deploy New Contract and Deploy Now, except this time we'll deploy a Token contract rather than an NFT Drop.

I'll configure my Token with these settings, and click Deploy Now, once again deploying onto the Mumbai (MATIC) test network.

Once we've created our token, let's mint the initial supply so that we can reward users later on for staking their NFTs. We can easily do that on the dashboard by clicking the Mint button.

For simplicity, I'll initially create 100 of these tokens by clicking Mint Tokens, and approve the Mint To transaction in MetaMask.

Great! Now we have 100 tokens! In the next step, we'll be able to transfer these to our staking smart contract so that they can be sent out as rewards by the contract.

Let's build our Staking smart contract now!

Building the Staking Contract

The purpose of our staking contract is to store users' NFTs from our NFT Drop contract and reward them with tokens from our token contract.

The longer the user stakes their NFT, the more tokens they will be rewarded.

To give credit where it's due, most of this code for this staking contract comes from this repo:

But we'll go through step by step how to build and understand the functions of this contract, and add thirdweb deploy to the contract so that we can:

• Configure and deploy it via the thirdweb dashboard
• Generate TypeScript functions to interact with our contract
• Use the thirdweb React and TypeScript SDKs to easily use the contract & the blockchain.

Creating the Project

For this guide, I'll be using Next.js & TypeScript to set up the project, and we'll create the smart contract directly in the project for simplicity.

Feel free to use the tools you're comfortable with, or follow along with the steps in this guide to end up with the same result!

Initializing the Next.JS Project with thirdweb

To create a new project using Next.JS, TypeScript and thirdweb, we can use thirdweb's create-thirdweb-dapp CLI tool:

npx create-thirdweb-dapp --next --ts

Change directory into the newly cloned repo:

cd .\nft-staking-app\

Now we have a basic example of Next.JS + thirdweb + Typescript setup, where we can connect, disconnect, and view our MetaMask wallet on the homepage, using thirdweb's helpful hooks.

Writing The Staking Contract

We'll be using some of the [OpenZeppelin contracts] inside of our contract, so we'll need to install the @openzeppelin/contracts package into our project:

npm install @openzeppelin/contracts

To begin with, let's create a new file at the root of our project called StakingContract.sol, which is a Solidity file.

If you're new to Solidity, I'd recommend you install an Extension that provides syntax highlighting such as this one called solidity to make it a lot easier to read.

Let's define our license, imports, and contract in this file:

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

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/token/ERC721/IERC721.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract ERC721Staking is ReentrancyGuard {

}

Now let's walk through how the staking contract is structured, and write it together step by step!

Firstly, let's make some variables for where we're going to store the contract address of the NFT Collection and Token that we created previously:

// We do this so we can use the safeTransfer function
using SafeERC20 for IERC20;

// Interfaces for ERC20 and ERC721
IERC20 public immutable rewardsToken;
IERC721 public immutable nftCollection;

We can use a struct to store information about a staked token:

    struct StakedToken {
        address staker;
        uint256 tokenId;
    }

Now let's make a struct called Staker, which represents the information we need about a wallet that is going to stake its NFTs on our contract:

    // Staker info
    struct Staker {
        // Amount of tokens staked by the staker
        uint256 amountStaked;

        // Staked token ids
        StakedToken[] stakedTokens;

        // Last time of the rewards were calculated for this user
        uint256 timeOfLastUpdate;

        // Calculated, but unclaimed rewards for the User. The rewards are
        // calculated each time the user writes to the Smart Contract
        uint256 unclaimedRewards;
    }

Next up, we'll configure how many tokens we want to reward per hour the NFT has been staked:

    // Rewards per hour per token deposited in wei.
    uint256 private rewardsPerHour = 100000;

Some mappings to store knowledge of:

• Wallet address to Staker (so we know which wallet is which staker)
• Token ID to wallet address (so we know which NFT is staked by which wallet)

    // Mapping of User Address to Staker info
    mapping(address => Staker) public stakers;

    // Mapping of Token Id to staker. Made for the SC to remeber
    // who to send back the ERC721 Token to.
    mapping(uint256 => address) public stakerAddress;

The constructor, which allows us to set the value of the NFT Collection contract address and the token contract address when we deploy the contract (we'll do this on the thirdweb dashboard);

    // Constructor function to set the rewards token and the NFT collection addresses
    constructor(IERC721 _nftCollection, IERC20 _rewardsToken) {
        nftCollection = _nftCollection;
        rewardsToken = _rewardsToken;
    }

Now to the functions!

First up, is a function that allows the user to stake their NFT.

This function also needs to store knowledge of which wallet address is staking which token IDs in the mappings we created:

    // If address already has ERC721 Token/s staked, calculate the rewards.
    // Increment the amountStaked and map msg.sender to the Token Id of the staked
    // Token to later send back on withdrawal. Finally give timeOfLastUpdate the
    // value of now.
    function stake(uint256 _tokenId) external nonReentrant {
        // If wallet has tokens staked, calculate the rewards before adding the new token
        if (stakers[msg.sender].amountStaked > 0) {
            uint256 rewards = calculateRewards(msg.sender);
            stakers[msg.sender].unclaimedRewards += rewards;
        }

        // Wallet must own the token they are trying to stake
        require(
            nftCollection.ownerOf(_tokenId) == msg.sender,
            "You don't own this token!"
        );

        // Transfer the token from the wallet to the Smart contract
        nftCollection.transferFrom(msg.sender, address(this), _tokenId);

        // Create StakedToken
        StakedToken memory stakedToken = StakedToken(msg.sender, _tokenId);

        // Add the token to the stakedTokens array
        stakers[msg.sender].stakedTokens.push(stakedToken);

        // Increment the amount staked for this wallet
        stakers[msg.sender].amountStaked++;

        // Update the mapping of the tokenId to the staker's address
        stakerAddress[_tokenId] = msg.sender;

        // Update the timeOfLastUpdate for the staker   
        stakers[msg.sender].timeOfLastUpdate = block.timestamp;
    }

A function that allows the user to withdraw the NFTs they have staked:

    // Check if user has any ERC721 Tokens Staked and if they tried to withdraw,
    // calculate the rewards and store them in the unclaimedRewards
    // decrement the amountStaked of the user and transfer the ERC721 token back to them
    function withdraw(uint256 _tokenId) external nonReentrant {
        // Make sure the user has at least one token staked before withdrawing
        require(
            stakers[msg.sender].amountStaked > 0,
            "You have no tokens staked"
        );

        // Wallet must own the token they are trying to withdraw
        require(stakerAddress[_tokenId] == msg.sender, "You don't own this token!");

        // Update the rewards for this user, as the amount of rewards decreases with less tokens.
        uint256 rewards = calculateRewards(msg.sender);
        stakers[msg.sender].unclaimedRewards += rewards;

        // Find the index of this token id in the stakedTokens array
        uint256 index = 0;
        for (uint256 i = 0; i < stakers[msg.sender].stakedTokens.length; i++) {
            if (stakers[msg.sender].stakedTokens[i].tokenId == _tokenId
                &&
                stakers[msg.sender].stakedTokens[i].staker != address(0)
            ) {
                index = i;
                break;
            }
        }

        // Set this token's .staker to be address 0 to mark it as no longer staked
        stakers[msg.sender].stakedTokens[index].staker = address(0);

        // Decrement the amount staked for this wallet
        stakers[msg.sender].amountStaked--;

        // Update the mapping of the tokenId to the be address(0) to indicate that the token is no longer staked
        stakerAddress[_tokenId] = address(0);

        // Transfer the token back to the withdrawer
        nftCollection.transferFrom(address(this), msg.sender, _tokenId);

        // Update the timeOfLastUpdate for the withdrawer   
        stakers[msg.sender].timeOfLastUpdate = block.timestamp;
    }

Finally, we have a function for the user to claimRewards so that they can be rewarded with the tokens we created for staking their NFT:

    // Calculate rewards for the msg.sender, check if there are any rewards
    // claim, set unclaimedRewards to 0 and transfer the ERC20 Reward token
    // to the user.
    function claimRewards() external {
        uint256 rewards = calculateRewards(msg.sender) +
            stakers[msg.sender].unclaimedRewards;
        require(rewards > 0, "You have no rewards to claim");
        stakers[msg.sender].timeOfLastUpdate = block.timestamp;
        stakers[msg.sender].unclaimedRewards = 0;
        rewardsToken.safeTransfer(msg.sender, rewards);
    }

These are the core pieces of our contract, but you might have noticed there is a function that we call named calculateRewards.

This function calculates the time that has passed since the contract last checked this Staker's calculated rewards.

This function is internal, meaning it is not accessible by the public, only by other functions within this smart contract.

    // Calculate rewards for param _staker by calculating the time passed
    // since last update in hours and mulitplying it to ERC721 Tokens Staked
    // and rewardsPerHour.
    function calculateRewards(address _staker)
        internal
        view
        returns (uint256 _rewards)
    {
        return (((
            ((block.timestamp - stakers[_staker].timeOfLastUpdate) *
                stakers[_staker].amountStaked)
        ) * rewardsPerHour) / 3600);
    }

Amazing work! That's all the logic of our contract, now we just need to add some views so that we can retrieve that information.

We'll add a view to read the token IDs a user currently has staked:

    function getStakedTokens(address _user) public view returns (StakedToken[] memory) {
        // Check if we know this user
        if (stakers[_user].amountStaked > 0) {
            // Return all the tokens in the stakedToken Array for this user that are not -1
            StakedToken[] memory _stakedTokens = new StakedToken[](stakers[_user].amountStaked);
            uint256 _index = 0;

            for (uint256 j = 0; j < stakers[_user].stakedTokens.length; j++) {
                if (stakers[_user].stakedTokens[j].staker != (address(0))) {
                    _stakedTokens[_index] = stakers[_user].stakedTokens[j];
                    _index++;
                }
            }

            return _stakedTokens;
        }

        // Otherwise, return empty array
        else {
            return new StakedToken[](0);
        }
    }

Another to read the available rewards a user has:

    function availableRewards(address _staker) public view returns (uint256) {
        uint256 rewards = calculateRewards(_staker) +
            stakers[_staker].unclaimedRewards;
        return rewards;
    }

That's it! Now we're ready to upload our contract to the thirdweb dashboard using thirdweb deploy.

Uploading the contract with thirdweb deploy

Now we're ready to upload our contract to thirdweb.

From the command line, let's run:

npx thirdweb deploy

The result you see should look like this:

💎 thirdweb-cli v0.4.53💎

WARN Unable to detect project type, falling back to solc compilation
INFO  Detected thirdweb contracts: "ERC721Staking"
INFO  Project compiled successfully
INFO  Uploading contract data...
INFO  Upload successful
INFO  Open this link to deploy your contracts:

https://thirdweb.com/contracts/deploy?ipfs=<your-ipfs-url-here>

If everything was successful, you can open that URL in your browser, which will take you to a page where you can deploy your contract. No private key is required!

Let's click on Deploy Now and deploy our staking contract onto the Mumbai (MATIC) test network.

Here, we'll need to populate the required fields we defined in our constructor.

If you go back to the dashboard you can access the contract addresses of your NFT Collection and your Token contracts, and paste them into the contract parameters here:

You've just deployed your very own custom smart contract with the click of a few buttons!

Let's see how we can integrate it into our application now!

Our Generated SDK

If you take a look at the Code tab now on the thirdweb dashboard, you'll see a fully generated list of functions that we can interact with, just by simply using the thirdweb SDK!

You can see all of the functions we wrote like stake, withdraw, and claimRewards.

The best part is, we don't have to use any other tools to interact with our smart contract, we can just use TypeScript! The thirdweb SDK's handle the rest.

Now let's build out the front-end of this application, so our users can claim and stake their NFTs, and start earning rewards!

Creating the front-end application

In this guide, I'll be using CSS modules to style the app, if you want to use the same styles as I am, feel free to create a file in styles/Home.module.css and styles/globals.css and use the files provided in this example repository.

Remember to import these files wherever necessary.

To begin with, lets head to _app.tsx and configure the activeChainId to be set to ChainId.Mumbai;, like so:

const activeChainId = ChainId.Mumbai;

Then let's head over to our homepage at index.tsx, and create a simple page where users can navigate to two different pages:

1. The /mint route, where they can use our NFT Collection contract to mint one of our lazy minted NFTs from the collection.
2. The /stake route, where they can view which NFTs they own from this collection, stake their NFT onto the contract, and claim their rewards.

Here's how the code looks for this, with styling removed for simplicity:

import { useRouter } from "next/router";

const Home = () => {
  const router = useRouter();

  return (
    <div>
      <h1>thirdweb Deploy - Custom Staking Contract</h1>

         <div onClick={() => router.push(`/mint`)}>
          <h2>Mint a new NFT</h2>
          <p>
            Use the NFT Drop Contract to claim an NFT from the collection.
          </p>
         </div>

        <div onClick={() => router.push(`/stake`)}>
          <img src={`/icons/token.webp`} alt="drop" />
          <h2>Stake Your NFTs</h2>
          <p>
            Use the custom staking contract deployed via <b>thirdweb Deploy</b>{" "}
            to stake your NFTs, and earn tokens from the <b>Token</b> contract.
          </p>
        </div>
    </div>
  );
};

export default Home;

With some added styling and images, here's how it looks:

Now we'll need to create these pages. In your pages folder, create two new files called mint.tsx and stake.tsx, these will be separate routes where we can handle the logic for minting and staking.

Mint Page

The mint page will show the user a button where they can claim the next available NFT in our NFT Drop. Since we lazy minted these NFTs, the user will be the one who mints the NFT and pay the gas fee for minting.

Let's walk through the pieces of this claiming page now!

First up, let's create a functional component and import the necessary parts of the SDK to make this work:

import { useAddress, useMetamask, useNFTDrop } from "@thirdweb-dev/react";
import { useRouter } from "next/router";

const Mint = () => {
  const router = useRouter();

  return (
    <div>
    </div>
  );
};

export default Mint;

Then, let's import the helpful hooks from the @thirdweb-dev/react package:

  // Get the currently connected wallet's address
  const address = useAddress();

  // Function to connect to the user's Metamask wallet
  const connectWithMetamask = useMetamask();

  // Get the NFT Collection contract
  const nftDropContract = useNFTDrop(
    "<your-NFT-Drop-contract-address-here"
  );

Now we have our NFT Drop contract stored in our nftDropContract variable, just by using one line of code! How cool is that!

We'll need a function to allow users to claim an NFT from our collection. This function will show an alert when the claim is successful, or if something goes wrong inside the catch block. Once the user closes the successful alert, we'll navigate them to the /stake route so they can stake their NFT if they choose to!

  async function claimNft() {
    try {
      const tx = await nftDropContract?.claim(1);
      console.log(tx);
      alert("NFT Claimed!");
      router.push(`/stake`);
    } catch (error) {
      console.error(error);
      alert(error);
    }
  }

Now for the UI! We'll need to ensure the user is connected to the site with their wallet before they mint; otherwise the function won't work because there is no connected wallet.

To do this, we'll use a ternary operator to show a Connect Wallet button if there is no connected wallet (using address), or show a Claim An NFT button if there is a connected wallet:

    <>
      {!address ? (
        <button onClick={connectWithMetamask}
        >
          Connect Wallet
        </button>
      ) : (
          <button onClick={() => claimNft()}>
            Claim An NFT
          </button>
      )}
    </div>

Great! Now with some added styling, we can see both the Connect Wallet view:

And the Claim An NFT view:

When we click Connect Wallet, we'll be prompted to connect our MetaMask wallet with this website, and then be able to claim an NFT, and taken to the /stake route after approving the claim transaction.

Now we're on the /stake route, let's code this part up!

Stake Page

The stake page is going to have three sections:

1. Information about the Token
2. Staked NFTs
3. Unstaked NFTs

Let's firstly import all of the required functionality for this page:

import {
  ThirdwebNftMedia,
  useAddress,
  useMetamask,
  useNFTDrop,
  useToken,
  useTokenBalance,
  useOwnedNFTs,
  useContract,
} from "@thirdweb-dev/react";
import { BigNumber, ethers } from "ethers";
import type { NextPage } from "next";
import { useEffect, useState } from "react";
import styles from "../styles/Home.module.css";

And we'll create some variables for our contract addresses so we can easily access them throughout this file:

const nftDropContractAddress = "<your-nft-drop-contract-address>";
const tokenContractAddress = "<your-token-contract-address>";
const stakingContractAddress = "<your-staking-contract-address>";

Now let's create the same structure using useAddress and useMetamask to ensure the user has their wallet connected before we attempt to fetch any information:

const Stake: NextPage = () => {
  // Wallet Connection Hooks
  const address = useAddress();
  const connectWithMetamask = useMetamask();

Connect to all of our contracts:

  // Contract Hooks
  const nftDropContract = useNFTDrop(nftDropContractAddress);
  const tokenContract = useToken(tokenContractAddress);
  const { contract, isLoading } = useContract(stakingContractAddress);

Utilise some helpful hooks to load the :

1. Balance this user has of this token
2. The NFTs they have from this NFT collection:

  // Load Balance of Token
  const { data: tokenBalance } = useTokenBalance(tokenContract, address);

  // Load Unstaked NFTs
  const { data: ownedNfts } = useOwnedNFTs(nftDropContract, address);

You'll notice that we use the .call function to call any of the functions we wrote on the custom contract.

Load this user's staked NFTs if there is a connected wallet:

const [stakedNfts, setStakedNfts] = useState<any[]>([]);

useEffect(() => {
    if (!contract) return;

    async function loadStakedNfts() {
      const stakedTokens = await contract?.call("getStakedTokens", address);

      // For each staked token, fetch metadata for the NFT 
      const stakedNfts = await Promise.all(
        stakedTokens?.map(
          async (stakedToken: { staker: string; tokenId: BigNumber }) => {
            const nft = await nftDropContract?.get(stakedToken.tokenId);
            return nft;
          }
        )
      );

      setStakedNfts(stakedNfts);
      console.log("setStakedNfts", stakedNfts);
    }

    if (address) {
      loadStakedNfts();
    }
  }, [address, contract, nftDropContract]);

Load the available rewards for this user, again using .call:

  const [claimableRewards, setClaimableRewards] = useState<BigNumber>();

  useEffect(() => {
    if (!contract || !address) return;

    async function loadClaimableRewards() {
      const cr = await contract?.call("availableRewards", address);
      setClaimableRewards(cr);
    }

    loadClaimableRewards();
  }, [address, contract]);

Stake function call:

In order for the contract to transfer our NFTs, it needs to have the approval to do so.

Inside the stake function, we check to see if the smart contract has approval, and call setApprovalForAll if it doesn't already have the approval to transfer NFTs from this wallet for this collection.

  async function stakeNft(id: BigNumber) {
    if (!address) return;

    const isApproved = await nftDropContract?.isApproved(
      address,
      stakingContractAddress
    );
    // If not approved, request approval
    if (!isApproved) {
      await nftDropContract?.setApprovalForAll(stakingContractAddress, true);
    }
    const stake = await contract?.call("stake", id);
  }

Withdraw function using .call:

  async function withdraw(id: BigNumber) {
    const withdraw = await contract?.call("withdraw", id);
  }

Claim Rewards function using .call:

  async function withdraw(id: BigNumber) {
    const withdraw = await contract?.call("withdraw", id);
  }

Now we can show all of the information we have fetched on the UI!

Loading state:

  if (isLoading) {
    return <div>Loading</div>;
  }

Show a connect wallet button if there is no address:

return (
    <div className={styles.container}>
      <h1 className={styles.h1}>Stake Your NFTs</h1>

      <hr className={`${styles.divider} ${styles.spacerTop}`} />

      {!address ? (
        <button className={styles.mainButton} onClick={connectWithMetamask}>
          Connect Wallet
        </button>
      ) : (
        <>
          // ... next code blocks go here
        </>
      )}
    </div>
  );

Show connected wallet's claimable rewards and token balance

          <h2>Your Tokens</h2>

          <div className={styles.tokenGrid}>
            <div className={styles.tokenItem}>
              <h3 className={styles.tokenLabel}>Claimable Rewards</h3>
              <p className={styles.tokenValue}>
                <b>
                  {!claimableRewards
                    ? "Loading..."
                    : ethers.utils.formatUnits(claimableRewards, 18)}
                </b>{" "}
                {tokenBalance?.symbol}
              </p>
            </div>
            <div className={styles.tokenItem}>
              <h3 className={styles.tokenLabel}>Current Balance</h3>
              <p className={styles.tokenValue}>
                <b>{tokenBalance?.displayValue}</b> {tokenBalance?.symbol}
              </p>
            </div>
          </div>

Button for users to claim their available rewards:

          <button
            className={`${styles.mainButton} ${styles.spacerTop}`}
            onClick={() => claimRewards()}
          >
            Claim Rewards
          </button>

View all of their staked NFTs:

Each mapped div contains a Withdraw button to call the withdraw function and pass in the token ID of this item.

          <h2>Your Staked NFTs</h2>
          <div className={styles.nftBoxGrid}>
            {stakedNfts?.map((nft) => (
              <div className={styles.nftBox} key={nft.metadata.id.toString()}>
                <ThirdwebNftMedia
                  metadata={nft.metadata}
                  className={styles.nftMedia}
                />
                <h3>{nft.metadata.name}</h3>
                <button
                  className={`${styles.mainButton} ${styles.spacerBottom}`}
                  onClick={() => withdraw(nft.metadata.id)}
                >
                  Withdraw
                </button>
              </div>
            ))}
          </div>

View all of their owned NFTs (NFTs from this collection that are not staked in the contract):

Each mapped div contains a button for the user to call the stakeNft function, again passing in the token ID as a parameter.

          <h2>Your Unstaked NFTs</h2>

          <div className={styles.nftBoxGrid}>
            {ownedNfts?.map((nft) => (
              <div className={styles.nftBox} key={nft.metadata.id.toString()}>
                <ThirdwebNftMedia
                  metadata={nft.metadata}
                  className={styles.nftMedia}
                />
                <h3>{nft.metadata.name}</h3>
                <button
                  className={`${styles.mainButton} ${styles.spacerBottom}`}
                  onClick={() => stakeNft(nft.metadata.id)}
                >
                  Stake
                </button>
              </div>
            ))}
          </div>

You will also notice we are utilising the ThirdwebNftMedia component, which renders the media asset of the NFT differently depending on what kind of file type is resolved from the NFT.

That's it! Now users will be able to see any of the NFTs they claimed from the /mint route, click the stake button, and start earning rewards!

Giving the staking contract some funds

One last thing, we'll need to transfer the NFT staking contract some of our tokens so that it can distribute them as rewards.

We can do this via the thirdweb CLI by going to our Token contract, and clicking on the Transfer button:

Then paste in your staking contract's address and send it some tokens!

Now it is capable of transferring tokens whenever somebody tries to call the claimRewards function!

🥳🎉

Conclusion

In this guide, we've made three smart contracts and combined them together to create a project that rewards users for holding the NFTs.

We have created all of this:

• ERC-721 NFT Drop contract
• ERC-20 Token contract
• An NFT Staking contract rewarding stakers with ERC-20 tokens

Disclaimer: This staking contract has not been audited and should not be trusted for use in production environments! Please do your own research and use it at your own risk.