The OPAQUE Protocol, defined in RFC-9807, is a cryptographic protocol for client-server architectures that allows secure user registration and sign in without ever revealing the client's plain password to the server. In this respect, the OPAQUE Protocol shares similarities with Zero-Knowledge Proofs(ZKP). Furthermore, it enables data to be securely stored without being disclosed to the server by encrypting it with a key known only to the client which derived from the protocol.

I define "semi-decentralization" as a system where data resides on the server(centralized), but the sovereignty over that data rests with the user or community(decentralized). The OPAQUE Protocol embodies this semi-decentralized nature because, while data is stored centrally on the server, access and manipulation rights are exclusively granted to the user.

💪 Can semi-decentralization overcome the inconveniences of Web3?

The current user experience (UX) in Web3 is, admittedly, not as seamless as in Web2. I believe that a semi-decentralized approach offers a crucial interim step to bridge this UX gap.

For instance, Solana has made all its block data accessible via Google Cloud(centralized) for faster access. This data is centrally stored in the cloud, but because it's generated and maintained by the Solana community and accessible to all users(decentralized), I consider it semi-decentralized. Similarly, Hyperliquid employs a comparable method by uploading data to AWS-S3.

Another example is Ethereum Layer 2 solutions. Here, a sequencer processes all transactions(centralized) and records them on the Ethereum mainnet. However, the fact that anyone can verify these transactions and access the data(decentralized) makes this approach semi-decentralized.

As the examples above show, a hybrid model of centralization and decentralization allows us to gain the benefits of throughput and easy access without significantly losing decentralization.

🤿 Deep Dive into Opaque Protocol Step-by-Step

The OPAQUE Protocol primarily consists of two phases, employing the OPRF (Oblivious Pseudorandom Function) protocol to generate unpredictable randomized password:

1. Registration (Sign-up)

2. Online Authenticated Key Exchange (Sign-in)

Before these two phases begin, server setup is required. Let's examine the step-by-step process, from setup through each phase, noting that many details are omitted to make it more intuitive.

0. Server Setup

The server prepares a public/private key pair and an OPRF seed (necessary for using the OPRF protocol).

1. Registration

This phase involves storing the client's randomized password on the server.

Step 1: Registration Request

• The client generates a blind element for the OPRF protocol from their password.

• This blind element is sent to the server along with a user identifier (e.g. username).

Step 2: Registration Response

• The server uses the received blind element from the client and its own OPRF seed to generate an evaluation element.

• The evaluation element and the server's public key are then sent back to the client.

Step 3: Record

Client

• The client uses the password entered in Step 1, the blind element generated in Step 1, and the evaluation element received from the server to obtain the OPRF function's output, which is used as the randomized password. An export key is extracted from this randomized password. The randomized password, along with other supplementary information, is then bundled into an envelope and sent to the server.

Server

• The server stores the received envelope using the user identifier as a key.

 Client                                                       Server
---------------------------------------------------------------------
(user_identifier, blind) = CreateRegistrationRequest(password)
                        Registration Request
           --------------------------------------------->

(server_public_key, evaluation) = CreateRegistrationResponse(server_public_key, blind, oprf_seed)
                        Registration Response
           <---------------------------------------------

(envelope, export_key) = FinalizeRegistrationRequest(password, blind, evaluation)
                               Record
           --------------------------------------------->

2. Online Authenticated Key Exchange

This phase requires going through the OPRF process once more to retrieve the randomized password obtained during registration. It's a process where the server and client exchange and verify each other's keys, subsequently generating an identical session key for future communication. The exchanged ke(key exchange) messages that appear at each step facilitate key exchange and verification between the client and server.

Step 1: AKE Message 1

• Similar to the registration process, a blind element is generated from the password.

• A ke1 message is created.

• The blind element, user identifier, and ke1 message are sent to the server.

Step 2: AKE Message 2

• The server uses the received blind element from the client and its own OPRF seed to generate an evaluation element.

• The server then finds the envelope corresponding to the user identifier.

• A ke2 message is created.

• The server's public key, the evaluation element, the envelope, and the ke2 message are sent to the client.

Step 3: AKE Message 3

Client

• The client uses the password entered in Step 1, the blind element generated in Step 1, and the evaluation element received from the server to obtain the OPRF function's output, which is used as the randomized password.

• The client then uses this randomized password to open the envelope and extract the export key.

• A ke3 message is generated, and during this process, the client's session key is created.

• The ke3 message is sent to the server.

Server

• The server generates its session key from the ke3 message received from the client.

 Client                                               Server
--------------------------------------------------------------
(ke1, blind) = GenerateKE1(password)
                        AKE Message 1
           ---------------------------------------->

(server_public_key, ke2, evaluation, envelope) = GenerateKE2(server_public_key, blind, oprf_seed, ke1, envelope)
                        AKE Message 2           
           <----------------------------------------

(ke3, export_key, session_key) = GenerateKE3(password, blind, evaluation, envelope, ke2)
                       AKE Message 3
           ---------------------------------------->

Ultimately, if the export key from the registration process matches the export key from the login process, and the client's session key matches the server's session key, the OPAQUE Protocol procedure concludes.

Subsequently, the session key is used for encryption and decryption during communication between the client and server. The export key is a key known only to the client and is used to encrypt data before storing it on the server, ensuring the data remains confidential from the server.

Example of session key and export key Usage

• Client encrypts data with export key → Client encrypts with session key → Server decrypts with session key → Server stores data

• Server encrypts with session key → Client decrypts with session key → Client decrypts with export key → Client reads data

🔐 Security Analysis

• By using an unpredictable randomized password derived from the password via the OPRF protocol, pre-computing attacks like rainbow attacks are prevented.

• To prevent client enumeration attacks, the same oprf seed is used for all users, making it impossible to distinguish between unregistered and registered users. However, client enumeration attacks during the registration process cannot be entirely prevented, so applications must implement various restrictions during registration to mitigate this attack.

• Even if the server is compromised and records are leaked, all data is encrypted, thus protecting the information. Furthermore, a Key Stretching Function (KSF) is applied to the OPRF output (randomized password), significantly increasing the cost of an attack.

• The export key should only be used after verifying the authenticity of the server (i.e. after the login process is complete).

• To prevent a fake server from impersonating the legitimate server by stealing records, it's crucial to verify that the server public key obtained during registration matches the one obtained during login. 👉 ShardLab offers an OPAQUE Protocol library that incorporates this functionality using WebAssembly.

🤩 OPAQUE Protocol in Blockchain

Recently, the blockchain domain has seen a growing adoption of semi-decentralized approaches, beyond just Solana, Hyperliquid, and Layer 2 solutions. The OPAQUE protocol, another semi-decentralized method, isn't yet widely adopted in the blockchain domain. However, it's clear that, like other semi-decentralized approaches, the OPAQUE protocol could bring a significantly improved UX in the Web3 user authentication, offering both security and convenience without largely sacrificing decentralization.

“If you are a Web3 developer, why not consider using the OPAQUE Protocol for better security and UX?”

Traditionally, Ethereum accounts are divided into two clear categories:

• Externally Owned Accounts (EOAs): These are typical wallets controlled by private keys—like your MetaMask account—that hold ETH and send transactions. They have balances and nonces but no logic or code execution capability.

• Smart Contract Accounts: These contain executable logic stored on-chain. They can execute complex instructions, manage state, and automate transactions.

But what if you could merge the flexibility and simplicity of EOAs with the powerful logic of smart contracts?

That's exactly what EIP-7702 achieves. It lets an EOA delegate its execution to a smart contract while still maintaining its original identity and control.

Delegation

Here's how EIP-7702 delegation changes the game:

• No Deployment Costs: You don't deploy a new contract; you simply delegate your existing wallet.

• Keep Your Identity: Your EOA address, private keys, balance, and nonce remain unchanged.

• Flexible Logic: You can update or revoke the delegated logic at any time, instantly.

The New Transaction Type: AUTHORIZATION_LIST (EIP-7702 Transaction)

EIP-7702 introduces a brand new transaction type that lets your EOA safely and flexibly delegate code execution.

What is the new transaction?

• Name: Authorization List Transaction

• Format: The transaction includes an authorization_list in its payload, containing one or more signed authorizations. Each authorization specifies which implementation contract to delegate to, and includes a nonce for replay protection.

• Key Fields:

  • sender (the EOA address)

  • authorization_list (array of signed authorizations)

  • Each authorization: {chain_id, address, nonce, y_parity, r, s}

  • to, value, data (optional, for a call in the same tx)

What does this transaction do?

• When submitted, the EOA’s code field is set to a special delegation bytecode:

0xef0100 || <Implementation Address>

• The EVM recognizes this as an instruction to delegate all code execution to the target implementation using DELEGATECALL.

How do you use it?

1. Sign a delegation authorization off-chain (e.g., using MetaMask or your own signing tool), specifying the implementation contract address, a unique nonce, and chain id.

2. Submit the Authorization List Transaction to the network. The transaction updates the EOA’s code (or reverts if invalid/nonce mismatch).

3. Immediately, your EOA begins behaving like a smart contract wallet, forwarding calls to the new implementation.

4. You can update or revoke the delegation at any time by submitting a new signed authorization with a higher nonce, or with impl_address = 0x0 to clear delegation and revert to vanilla EOA behavior.

Example Call:

Suppose your EOA is 0xA...123, and you want to delegate to a BatchExecutor contract at 0xB...456:

• You sign: { address: 0xB...456, nonce: 7, y_parity, r, s }

{
  "sender": "0xA...123",
  "authorization_list": [
    {
      "impl_address": "0xB...456",
      "nonce": 7,
      "v": 27,
      "r": "0x...",
      "s": "0x..."
    }
  ]
}

• After confirmation, all code execution for 0xA...123 is delegated to 0xB...456, using your EOA’s storage and balance.

Whenever your EOA receives a transaction, the EVM forwards the execution (via DELEGATECALL) to the specified implementation contract. All execution happens in your EOA’s context—your balance, your state, your control.

Practical Example: BatchExecutor Contract

Let's take a concrete example: the BatchExecutor contract, designed to showcase EIP-7702 delegation.

With BatchExecutor, your EOA can execute multiple transactions in a single atomic operation. Imagine you need to perform several token transfers or calls across different DeFi protocols simultaneously. Instead of manually submitting each transaction, you simply delegate your EOA to the BatchExecutor contract:

• You sign and authorize a delegation to BatchExecutor.

• Instantly, your EOA can call executeBatch, running multiple operations at once.

• Your EOA balance, nonce, and state remain intact, maintaining all the familiar EOA properties.

For concrete code examples and a hands-on workshop, check out the protocol-camp EIP-7702 repository.

You'll find the BatchExecutor implementation, upgrade scenarios, and all related test cases ready for experimentation.

⚙️ But What About Security and Access Control?

Good question. With great power comes great responsibility—and EIP-7702 makes these patterns possible, but does not mandate a specific access control model. How you implement security is entirely up to your delegated contract logic.

In the BatchExecutor example (which is just one possible use case), we show an access control pattern like:

• Owner Control: Only your EOA can trigger batch operations (if the logic is written that way).

• Guardians: You can designate trusted guardian addresses to act on your behalf—useful for shared wallets or recovery (again, if supported by the contract you delegate to).

• Revocable Delegation: At any moment, you can revoke or change the delegation to another logic contract or revert to a standard EOA behavior (this is a core property of EIP-7702 itself).

EIP-7702 delegation also makes upgrades easy and flexible. Suppose you want to enhance your batch execution logic later. You simply delegate your EOA to a new implementation (e.g., from BatchExecutor to BatchExecutorV2). Your EOA’s state persists across the upgrade.

However, developers must ensure storage compatibility between implementations. If done improperly, storage slot collisions might occur, causing unintended data corruption. This is why following storage best practices, like using namespace-based storage slots (as proposed in EIP-7201), is essential.

⚠️ Remember: EIP-7702 just enables delegation. The actual security, permissioning, and flexibility depend entirely on the implementation contract (like BatchExecutor or your own design). Always review and test the logic you delegate to!

🛠️ Getting Hands-On

Ready to see EIP-7702 in action?

The purpose of this learning module is to make all provided tests pass by modifying the smart contracts as needed. As you work through the failing tests and implement fixes, you’ll encounter and solve various issues that can arise with EIP-7702—including delegation logic, access control, storage collisions, upgrade safety, and more. This hands-on approach ensures you learn not only the mechanics of EIP-7702, but also its important design considerations.

You can find all the example code and test cases here: 👉 protocol-camp EIP-7702 repository

Through these tests, you'll:

• Verify delegation setup and execution behavior.

• Test batch operations, access control, and ether reception.

• Ensure upgrade compatibility and safe storage layouts.

Try it Yourself:

forge install
forge test

Dive into the provided tests, fix intentional issues, and learn by solving each challenge step by step!

🎯 Wrapping Up

EIP-7702 is a major step forward for Ethereum wallet and account design. It unlocks the flexibility of smart contract logic for EOAs—without losing the simplicity and direct control developers are used to.

Through this hands-on module, you’ve not only learned how delegation works, but also tackled real-world problems around code delegation, upgrade safety, and access control. As you modify the smart contracts and pass all tests, you gain direct experience with the subtleties and possibilities of EIP-7702.

Whether you’re building advanced wallets, dApps, or experimenting with new forms of user control, EIP-7702 provides a flexible foundation.

Ready to build the next generation of smart wallets?

Share

In blockchain systems, efficiently and securely storing all account and contract state is critical. The StateTrie is a data structure designed for this purpose. Used in Ethereum and many other blockchains, it organizes accounts, balances, and contract data into a tree structure.

Want to See the Code First?

Most articles about state are conceptual. Here, you can check out real TypeScript code — read, run, and modify it yourself. This isn't just theory: every core idea explained below is directly backed by a working implementation.

• 🔗 Jump straight to the code and tests

• Or, keep reading to see how StateTrie works, step by step.

What sets this guide apart:

• You see not just what a StateTrie is, but exactly how state updates and lookups are done — with actual data flows and visual step-throughs.

• Each major concept is paired with both an intuitive explanation and a concrete code example (see GitHub).

Why Do We Need a StateTrie?

• Integrity of State: With a single root hash, you can verify the entire system state hasn't been tampered with.

• Efficient Partial Updates: When an account changes, only the nodes along that account's path are updated. The rest of the tree remains unchanged and can be reused.

• History and Rollbacks: Every version of the tree (and its nodes) is kept in the database, making it easy to restore or compare any past state. This enables rollbacks and historical proofs.

These properties enable reliable state management, fast verification, and support for time-travel (rollback) features in blockchain systems.

How Does StateTrie Work?

State History and Snapshots

Imagine the StateTrie as a tree whose root hash is like a unique fingerprint for the blockchain’s state at a certain time. Every update (like a transaction) makes a new root hash, just like how every new Git commit makes a new commit hash. Each root hash is a snapshot. You can always go back to any previous root hash and query that exact state—just like checking out a specific commit in Git.

A Step-by-Step Look at Set and Get Operations

The StateTrie organizes blockchain account data using a tree structure, where each path through the tree is determined by the hash of the account’s address. Let’s break down exactly what happens when you store (set) or retrieve (get) account data.

1. Storing Data (set): Inserting or Updating an Account

The set operation is how you add or change the data for an account. Here’s how it works, step by step:

a. Hashing and Path Generation

• The account address (e.g. 0x0001) is hashed (commonly using SHA-256).

• The resulting hash is split into hexadecimal digits (nibbles), e.g.
  4bf5122f3a4554... → [4, b, f, 5, 1, 2, 2, f, 3, ...]

• Each nibble decides which branch to follow at each level of the tree.

b. Tree Traversal and Node Creation

• Starting from the root, the algorithm follows the path specified by the nibbles.

• If a branch does not exist for a given nibble, a new branch node is created.

• When the path is exhausted (all nibbles followed), a new leaf node containing the account and value is created.

c. Updating Parent Branches and Root Hash

• After inserting or updating a leaf, all parent branch nodes along the path are also updated, because each branch’s hash depends on its children.

• Only the nodes along the changed path are new; unchanged branches are reused.

• The new root hash represents the entire new state.

Example:

Suppose you insert three accounts, each with a unique address.

Step 1: Insert 0x0001

Root (Branch)
└── [4] → Leaf (key: 0x0001, value: 100)

Step 2: Insert 0x0002 (different path)

Root (Branch) 
├── [4] → Leaf (key: 0x0001, value: 100) 
└── [d] → Leaf (key: 0x0002, value: 200)

Step 3: Insert 0x0003 (shared prefix, deeper branch)

Root (Branch) 
├── [4] → Branch 
│    └── [b] → Branch 
│         └── [f] → ... 
│               ├── [4] → Leaf (key: 0x0001, value: 100) 
│               └── [a] → Leaf (key: 0x0003, value: 300) 
└── [d] → Leaf (key: 0x0002, value: 200)

Only the path from the root to the changed/inserted leaf needs to be updated; all other paths and nodes are reused, making updates efficient and enabling state history.

Only the path from the root to the changed/inserted leaf needs to be updated; all other paths and nodes are reused, making updates efficient and enabling state history.

What Happens in the Worst and Best Cases?

In the worst case, every account’s key hash is completely different, so each inserted key requires the maximum possible depth—one new branch node for every nibble (hex digit) in the hash. This means the tree can be quite deep (e.g., up to 64 levels for a 256-bit hash).

However, in most real-world cases, many accounts share common prefixes in their hashed keys. This allows multiple accounts to share branch nodes along their path—
only the final part of the path differs, and only that part of the tree is unique to each key. Unchanged “parent paths” are always reused.

Suppose the hashes for two addresses both start with the same nibbles:

Account A: [4, b, f, ...]
Account B: [4, b, f, ...]

Their paths will share the [4], [b], [f] branches. Only when their paths diverge (say at the 7th nibble) does the tree branch out to different leaves. This sharing of paths means the Trie is very space-efficient and minimizes the number of new nodes needed for each operation.

In Ethereum’s Full MPT

The real Merkle Patricia Trie used by Ethereum optimizes shared prefixes even further:

• Extension nodes compress long sequences of branch nodes with a single child into one node, reducing tree depth and database lookups.

• This enables even faster operations and lower storage use for keys with long shared prefixes.

2. Retrieving Data (get): Looking Up an Account

The get operation finds the value for a given key. Here’s how it works:

a. Hashing the Key

• The search key is hashed in the same way as for insertion, producing a nibble path.

b. Traversing the Tree

• Starting at the root, the algorithm follows each nibble as a branch index.

• At each branch node, it checks if the branch exists for the current nibble:

  • If yes, continue following the path.

  • If no, the key does not exist in the trie (return null).

c. Reaching a Leaf

• Once a leaf node is reached, the algorithm checks whether the key stored in the leaf matches the search key.

  • If it matches, return the value.

  • If not, return null.

Example:

Looking for 0x0001

Root
└── [4] → Branch
      └── [b] → Branch
            └── [f] → ...
                  └── [4] → Leaf (key: 0x0001, value: 100)

• Each branch index is determined by a nibble of the hashed key.

• If any part of the path is missing, or the final leaf key does not match, the lookup fails.

Edge Cases

• Missing Branch: The path for the key doesn’t exist in the trie (returns null).

• Mismatched Leaf: The leaf node is reached, but the key in the leaf is different (returns null).

How Is This Used in Blockchains?

Every time the state trie is updated, the root hash changes. This new hash uniquely identifies the blockchain’s state at that exact moment. You can use any previous root hash to "travel back" and query or prove what the state was—just like how you can check out any previous commit in Git to see an old version of your codebase. The StateTrie is thus the engine for both real-time state access and historical, tamper-proof snapshots.

   ...  Root Hash A   →   Root Hash B   →   Root Hash C   ...
         (block 100)      (block 101)       (block 102)
           │                 │                  │
         Trie A           Trie B             Trie C
           │                 │                  │
   [state after      [state after        [state after
    block 100]        block 101]          block 102]

You can always query any past state by starting from its root hash.

Finding an Account’s Value in a Specific State

To find the balance or data for a specific account at a given point in time (a specific block number):

1. Get the root hash of the state you’re interested in (for example, a certain block number).

2. Hash the account’s address to generate the path through the StateTrie.

3. Traverse the tree from the root hash, following each nibble (hex digit) of the hashed key at each branch.

4. When you reach a leaf node:

   • If the leaf’s key matches the account you’re looking for, return the value (such as the account balance).

   • If not, the account does not exist in that state.

At block #123, the state root is: 0xabcdef...
You want to check the balance of address 0x1234... in this state.

1. Use the state root to start the trie traversal.
2. Hash 0x1234... to get the path [4, b, f, ...].
3. Follow this path through the trie, moving from root to each branch node.
4. Reach the leaf node. Check: Is it 0x1234...? If yes, return value. If not, not found.

Final Summary

The StateTrie is how blockchains like Ethereum keep track of all account and contract data — securely and efficiently. It turns the entire state into a hashed tree where each update only touches part of the structure, making writes fast and storage lean. Every change creates a new root hash, giving you an exact snapshot of the system at any block. With just that root, you can verify, query, or roll back to any past state. Whether you're updating balances or digging into history, the StateTrie keeps the state consistent, verifiable, and ready for whatever’s next.

However, in this piece, I’d like to focus more on the knowledge developers need to actually build or integrate with blockchain projects.

“When you’re faced with the situation of having to develop on or connect to a blockchain, what are the minimum essentials you need to know?”

The following sections aim to give you a broad overview.

1. Traditional Server/Client Architecture vs. Blockchain

In typical web or mobile applications, the flow usually looks like this

• Client (Web/App) → Server (Backend) → Database (Data Storage)

• A central server handles most of the logic, and data is stored and retrieved from a database.

Blockchain takes a very different approach:

• Multiple nodes in the blockchain network all share the same ledger (data).

• There’s no central server; instead, these nodes record new transactions via a consensus mechanism.

• Anyone can run a node or access the data, and even if one node goes down, the network as a whole continues to function.

The key point here is that it’s the entire network, not a single server or database, that manages and verifies the data. As a result, changes (transactions) are handled very carefully, ensuring immutability and transparency.

2. So, Is Blockchain a Database?

Blockchain isn’t really a direct replacement for traditional RDB or NoSQL databases. Rather, it’s a specialized data structure designed for transparency and immutability.

• When you add data (write) via a transaction, it must pass network validation and be shared by all nodes.

• Once recorded, it’s very hard to change or delete.

• Large amounts of data can be expensive (due to gas fees), and on-chain storage is not highly efficient.

In practical implementations, crucial data—like ownership or transaction records—goes on-chain, while secondary data (images, logs, metadata, etc.) is stored off-chain (IPFS or a traditional database), then linked via hashes or references.

• Event-based history: When a contract’s state changes, it emits events, which can be indexed for easy retrieval.

• Indexing solutions (e.g., The Graph): They gather events from the blockchain and store them in a more query-friendly form—like a database—for use by your dApp.

The main takeaway is that blockchains are designed for trust and immutability, not for dumping and querying massive data. Often, you run a separate indexer to convert “events → DB,” boosting efficiency and convenience.

3. Blockchain Nodes: Run Your Own or Use a Service?

We noted that a node plays the role of both server and database in a blockchain. But must you operate your own node to interact with a blockchain? Not necessarily.

1) Running your own node

• For major chains like Ethereum, running a full node requires hundreds of gigabytes of storage and a stable network connection.

• Costs, maintenance, and DevOps expertise can be significant.

• However, if you need large-scale on-chain data collection—like analyzing high-frequency transactions, running trading bots, or conducting big data research—operating your own node can be advantageous.

2) Using external node services

• Services like Infura, Alchemy, or QuickNode provide RPC endpoints (URLs), giving you direct access to blockchain functions (submitting transactions, querying data, etc.) without managing infrastructure yourself.

• Many dApp projects rely on these to get up and running quickly.

3) Local development nodes

• Tools like Ganache and Hardhat Network let you spin up a “fake blockchain” locally.

• Perfect for testing, learning, or personal side projects.

In short, you don’t always need to run your own node. You can decide based on your project’s traffic, data needs, and operational resources.

4. User Authentication: “Log In” vs. “Connect Wallet”

In traditional web or mobile apps, we typically use ID/PW, JWT, OAuth, etc. for user authentication.
In blockchain dApps, however, wallets (like MetaMask, Trust Wallet, etc.) handle the concept of “authentication.”

• A wallet stores the user’s private key, enabling them to sign transactions.

• Authentication Flow:

  1. The dApp (client) requests a signature for a specific message (or transaction).

  2. The user’s wallet signs it with their private key and returns the signature.

  3. The dApp verifies that the public key (wallet address) and the signature match, confirming the user’s ownership of that address.

Security Implications

• There is no central server storing your password; instead, users themselves manage their private keys.

• If a private key is lost or compromised, there’s almost no way to recover it (no “reset password” option).

• Familiar features like MFA or password recovery aren’t typically available.

To address these challenges, various solutions are emerging, such as:

• Account Abstraction (AA): where the wallet is a smart contract account, enabling features like social recovery or fee subsidization.

• Seedless logins, smart contract wallets, and other innovations to improve security and user experience.

5. Smart Contracts

A blockchain isn’t just a ledger of data—it allows you to run code (program logic) directly on-chain. We call this code a smart contract.

5.1 What Is a Smart Contract?

• Immutable Code
  Once deployed to the blockchain, the code is difficult (or sometimes impossible) to modify.
  If a bug is discovered in the logic, patching can be extremely difficult. Thorough testing and security audits are critical.

• Decentralized Trust
  Unlike a scenario where you host code on a private server and claim “this is how it works,”
  a blockchain-based contract is openly deployed on the network. Anyone can review the logic and see exactly how it’s executed.
  (For example, by plugging the contract address into a block explorer to verify the source code and transaction history.)

• Deployment Process
  You write code in languages like Solidity or Vyper (for Ethereum), compile it, then send a deploy transaction.
  The contract is assigned a unique address (like a wallet address starting with 0x).
  Once deployed, anyone can interact with it by sending transaction calls to that address. The network executes the logic and records the results on-chain.

5.2 Tokens, NFTs, and DeFi Are Also Smart Contracts

Some of the most prominent uses of smart contracts include tokens (ERC-20), NFTs (ERC-721), and DeFi protocols.

• ERC-20 (Tokens)
  The standard interface for creating interoperable tokens on Ethereum.
  If you implement functions like balanceOf, transfer, and approve, wallets and exchanges automatically recognize your token and enable features like balance checks and transfers.

• ERC-721 (NFTs)
  A standard for non-fungible tokens.
  Each token has a unique ID, allowing ownership of each item to be distinctly tracked—common for artwork, profile pictures, in-game items, memberships, etc.

• DeFi (Decentralized Finance)
  Smart contracts implementing financial services such as lending, staking, swaps, or liquidity pools.
  Anyone can use them under the same conditions, without a central authority.

5.3 Example: Basic ERC-20 Code

Below is a simple example illustrating how an ERC-20 contract might work. (In practice, the standard includes events and more functions, but this showcases the core logic.)

pragma solidity ^0.8.0;

contract MyToken {
    mapping(address => uint256) private _balances;

    string public name = "MyToken";
    string public symbol = "MTK";
    uint8 public decimals = 18;
    uint256 public totalSupply;

    constructor(uint256 initialSupply) {
        _balances[msg.sender] = initialSupply;
        totalSupply = initialSupply;
    }

    function balanceOf(address account) external view returns (uint256) {
        return _balances[account];
    }

    function transfer(address to, uint256 amount) external returns (bool) {
        require(_balances[msg.sender] >= amount, "Not enough balance");
        _balances[msg.sender] -= amount;
        _balances[to] += amount;
        return true;
    }
}

You’ll see it tracks balances in a mapping and uses a transfer function to update them. ERC-721 (NFT) follows a similar model, except each token ID is unique and individually tracked.

In essence, “tokens” or “NFTs” are simply interfaces provided by smart contracts.

6. Transactions & Gas Fees

• Transaction: Any operation that changes blockchain state (like sending funds or calling a contract).

• Gas Fee: The cost paid to the network (in ETH, MATIC, BNB, etc., depending on the chain) for processing each transaction.

As a developer, consider:

• UX

  • Every time a user sends a transaction, they must confirm it in their wallet and pay a gas fee.

  • Frequent transaction prompts may hurt usability. You usually want to design so that on-chain actions happen only when truly necessary.

• Cost

  • Large transaction volumes can drive gas costs up significantly.

  • Each chain has different fees and throughput, so choosing the right chain can greatly affect the business model.

7. ABI (Application Binary Interface)

Once you deploy a smart contract, how do you actually call its functions or access its variables?
Think of how REST APIs require you to know the endpoints, parameters, and methods.
Similarly, a contract needs a description of “which functions exist and what parameters/return types they use.”
That’s exactly what the ABI (Application Binary Interface) is for.

Without the ABI, simply knowing the contract’s address tells you nothing about how to interact with its internal functions. Hence, to use a deployed contract, you must have its ABI.

Example
Suppose an ERC-20 token contract has balanceOf and transfer as part of its ABI:

[
  {
    "type": "function",
    "name": "balanceOf",
    "inputs": [
      { "name": "account", "type": "address" }
    ],
    "outputs": [
      { "type": "uint256" }
    ]
  },
  {
    "type": "function",
    "name": "transfer",
    "inputs": [
      { "name": "to", "type": "address" },
      { "name": "amount", "type": "uint256" }
    ],
    "outputs": [
      { "type": "bool" }
    ]
  }
]

• balanceOf: takes an address and returns a uint256 balance

• transfer: takes a to address and an amount (uint256), returns a bool indicating success

Using this ABI, you can call these contract functions. For instance, in ethers.js:

import { ethers } from "ethers";
import MyTokenABI from "./MyToken.json"; // Precompiled contract ABI

// Deployed contract address
const tokenAddress = "0x123456789ABCDEF...";

// Create contract instance with address + ABI
const tokenContract = new ethers.Contract(tokenAddress, MyTokenABI, signer);

// Example: check balance
const balance = await tokenContract.balanceOf("0xABCD1234...");
console.log(balance.toString());

// Example: transfer tokens
await tokenContract.transfer("0xEFGH5678...", 100);

ABI is effectively the “spec sheet” for function signatures: which parameters they require and what they return. If you’re curious how the actual function call process works, it involves:

1. Calculating a 4-byte function selector (via Keccak-256 of the function signature),

2. Encoding parameters into call data,

3. Sending it to the EVM, which uses the selector + encoded arguments to execute the correct function.

For more details on the encoding rules, check the official documentation.

8. Overlooked Challenges: Security, Cost, and UX

• Security

  • Once deployed, a smart contract is hard to patch. A single bug can lead to massive loss of funds.

  • Projects dealing with large amounts of value usually invest in professional security audits.

• Cost (Gas Fees)

  • A large number of transactions can become expensive and inconvenient for users.

  • Decide how to handle those costs (do users pay or does the platform subsidize?).

• UX

  • Everything from installing a wallet to paying gas and waiting for confirmations differs from typical web apps.

  • Often, it’s best to limit on-chain transactions to only what’s absolutely necessary, lowering user friction.

9. With So Many Blockchains, Which Do You Choose?

Ethereum, Polygon, BNB Chain, Avalanche, Solana… the list continues to grow. Each chain has its own strengths and weaknesses, so choose based on your project’s needs:

• Gas Fees & Throughput

  • Ethereum offers robust security and a vast ecosystem but has relatively high gas fees.

  • Polygon (a Layer 2 solution) provides cheaper, faster transactions, but might involve bridging assets.

• Ecosystem (Wallets, DEX, NFT marketplaces, etc.)

  • A chain that users and developers already widely adopt can reduce friction (e.g., MetaMask support, established markets, etc.).

• Security & Decentralization

  • A chain with fewer nodes or weaker consensus might pose risks to trust and reliability.

Ultimately, factors like gas fees, processing speed, security, and ecosystem support should guide your decision. Your project’s size, goals, and user base will shape the best choice.

Final Thoughts

There’s no need to dive deeply into consensus algorithms, tokenomics, sidechains, or Layer 2 solutions right away. A good starting point is to experiment on a testnet, deploy a basic smart contract, and send transactions from a wallet to get familiar with the flow. This hands-on approach will give you a taste of the UX and security challenges inherent in blockchain-based applications. Later, you can dive deeper into more advanced topics as your project demands.

Share

No matter what domain you’re currently in as a developer, you’ve probably asked yourself at least once:
“Alright, so what makes Smart Contract development different from the kind of development I’m used to (or from general software development)?”

This article is written for those who are wrestling with exactly that question. It is based on the author’s personal experience and opinions.

Blockchain and Smart Contracts

Put very simply, when developing a typical software product (application), we divide it into a front end (web/app) and a back end (server), using a client-server architecture. The server handles business logic, stores critical data in a database (DB), and provides data to the client. The client, in turn, provides a user interface based on this data.

In a Dapp (Decentralized Application), which runs on the blockchain, the logic is written in a Smart Contract and is executed directly on the blockchain.

So, how is this different from the traditional structure? Think of the blockchain as the database (DB), and the Smart Contract as the server’s business logic. Of course, to handle more complex queries or improve performance, you can add a separate indexing server. But fundamentally, the Smart Contract is in charge of the server’s core logic.

Here’s a question you might ask: “Then, is Smart Contract development basically back-end (server) development?” The answer is, no—it’s not quite the same.

What Makes Smart Contract Development Different?

A Deep Understanding of the Blockchain

• Front-end developers need a basic grasp of how browsers work, the DOM structure, and UI event flows.

• Back-end developers need to be comfortable with networking, databases, and request-response structures.

• Likewise, a Smart Contract developer must have a thorough understanding of the blockchain’s architecture and how it operates.

There’s a lot to learn, but at the very least, you should be able to answer questions like:

• How does a transaction get processed and included in a block? (What is a transaction’s life cycle?)

• When a transaction is executed, how does the state change?

• Why do transaction fees occur, and how much do they cost?

Just as a server environment requires CPU, memory, and disk resources to run logic or store data, running a Smart Contract on a blockchain also consumes computational and storage resources from blockchain nodes. Because of this, every transaction you submit incurs a fee (e.g., gas), which can vary greatly depending on how you design your contract. In other words, resource efficiency is directly tied to cost efficiency.

Most importantly, blockchains are fundamentally immutable. Once a contract is deployed, it typically can’t be modified. If you have flawed logic or an inefficient state design, you can’t just fix it with a simple patch.

Moreover, each chain has its own structure and unique characteristics that are crucial to understand.

For instance:

• Ethereum (EVM-based) uses an Account model, with accounts categorized as EOA (Externally Owned Account) or CA (Contract Account). State data is stored in Contract Accounts, managed in a key-value storage format. Logic and state are defined together within a single contract.

• Solana, on the other hand, takes a very different approach. The logic resides in what’s called a Program Account (PA), and the state is stored in a separate account called a Program Derived Address (PDA). The PDA is “owned” by a specific Program Account (PA), and the state data is recorded in the PDA. In other words, logic and state are physically separated, and you, the developer, need to explicitly design how to connect them.

These structural differences go far beyond simple syntax; they alter your entire way of thinking when designing a Smart Contract.

For example, the approach to storing and managing state data, understanding which resources you can access, calculating the associated costs, how complex a single transaction’s logic can be, or whether parallel processing is possible—all of these depend on the specific blockchain’s architecture. Hence, you need to keep each chain’s characteristics and constraints in mind from the very early stages of design.

Ultimately, merely learning the language syntax isn’t enough for proper Smart Contract development. You need a deep understanding of the blockchain as an execution environment. Otherwise, you risk writing contracts that don’t work as intended—or even worse, open the door to catastrophic asset losses.

Blockchain in Smart Contract

Let’s look at how all this impacts your code. We’ll use Solidity—arguably the most popular language on the EVM—to illustrate.

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

contract SimpleWallet {
    mapping(address => uint256) public balances;
    address[] public depositors;

    function deposit() external payable {
        bool exists = false;
        for (uint i = 0; i < depositors.length; i++) {
            if (depositors[i] == msg.sender) {
                exists = true;
                break;
            }
        }
        if (!exists) {
            depositors.push(msg.sender);
        }
        balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        uint256 amount = balances[msg.sender];
        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Transfer failed");
        balances[msg.sender] = 0;
    }
}

Solidity looks a bit like JavaScript, so at first glance it may not seem too difficult to understand. The contract’s functionality is simple: you can deposit ETH, and the contract records the depositor’s address. A depositor can withdraw the exact amount they’ve deposited.

However, this contract has some issues:

1. There’s no receive function.
   To receive ETH in a contract, you need a receive function. Without it, depositing ETH will fail (although depositing 0 ETH might succeed).

2. No consideration for gas fees—list traversal.
   In Solidity, every operation costs gas. As the list of depositors grows, the for-loop runs longer, causing higher gas fees. Excessive gas usage can lead to failed transactions.

3. Vulnerability to reentrancy attacks.

Reentrancy Attacks

A reentrancy (or “re-entry”) attack occurs when one contract calls an external contract (or address), and the called contract (the attacker) calls back into the original contract’s function before the first execution completes. It’s akin to recursion.

Let’s assume we added a receive function:

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

contract SimpleWallet {
	...
	receive() external payable {}
}

There’s a feature in Solidity:

• A contract can call another contract.

• Logic is executed sequentially.

• When ETH is transferred, receive is triggered.

These features allow for a reentrancy attack. With the following exploit contract, an attacker could withdraw more ETH than they originally deposited

contract ReentrancyExploit {
    SimpleWallet public simpleWallet;

    constructor(address _simpleWallet) {
        simpleWallet = SimpleWallet(_simpleWallet);
    }

    // entrancy
    function attack() external payable {
        simpleWallet.deposit{value: msg.value}();
        simpleWallet.withdraw();  
    }

    // reentrancy
    receive() external payable {
        if (address(simpleWallet).balance >= msg.value) {
            simpleWallet.withdraw(); 
        }
    }
}

Here’s how an attack might unfold when attack() is called:

1. simpleWallet.deposit{value: msg.value}() is called.

2. Then simpleWallet.withdraw() is called, which executes a call function inside simpleWallet that sends ETH back to ReentrancyExploit.

3. During this call, ReentrancyExploit’s receive() function is triggered:

(bool sent, ) = msg.sender.call{value: amount}("");

4. The receive() function calls simpleWallet.withdraw() again.

5. Since balances[msg.sender] hasn’t yet been reset to zero, the attacker can continue withdrawing the same amount repeatedly.

Even this simple logic shows how a deeper understanding of the blockchain is necessary to write Smart Contracts.

For more information about reentrancy attacks, see here.

Required Knowledge / Skills

In-depth Blockchain Knowledge

Understanding the transaction life cycle and how transactions are processed is fundamental. You also need to know how each blockchain network’s consensus mechanism and virtual machine (VM) operate.

Moreover, learning about various types of DApps—DeFi, NFTs, and beyond—is extremely helpful when designing and implementing real Smart Contracts.

Although blockchain can be segmented into many areas—DeFi, infrastructure, security, crypto-economics—they’re all interconnected. You should aim for a big-picture understanding that goes beyond a single niche.

Testing and Debugging

Because Smart Contracts run in a blockchain environment, testing and debugging them isn’t as straightforward as in typical applications. The blockchain is immutable, so once a state changes, you can’t roll it back. Transactions are atomic, making state changes mid-execution tough to track, and every state-changing transaction costs money.

This means you can’t rely on some of the standard testing strategies you might use in a typical app—like rolling back a DB to a prior state or stepping through your code with breakpoints in production.

Still, testing and debugging are crucial in Smart Contract development because a single bug can lead directly to asset losses. And once a contract is deployed, it’s nearly impossible to roll back mistakes.

Fortunately, tools like Hardhat, Foundry, and Truffle have emerged to mitigate these challenges. They offer features like console.log debugging, fork testing, and VM-simulated environments. Even so, debugging in a blockchain VM is still difficult, and it ultimately falls on you to implement meticulous logic and thorough tests to ensure everything works as intended.

Adhering to Standards and Tracking Updates

Blockchain has multiple standards that must be understood. They’re tied not only to ecosystem compatibility but also gas optimization and security.

Take ERC20, the most widely used standard for fungible tokens, as an example. Its transfer function must adhere to this interface

function transfer(address to, uint256 value) external returns (bool)

If transfer succeeds, it should return true, otherwise false. What if there’s an ERC20 token that doesn’t actually return a bool?

function withdraw(address token, address to, uint256 amount) external {
   bool isSuccess = IERC20(token).transfer(to, amount);
   require(isSuccess, 'failed to withdraw);
}

In this snippet, transfer is expected to return a bool, but if it doesn’t, decoding fails and the transaction reverts. This scenario can actually happen and cause assets to be stuck (“frozen”).

New standards keep emerging, and existing ones can change via EIPs (Ethereum Improvement Proposals). You need to keep track of these changes and quickly adapt to stay safe and compatible. This ongoing awareness isn’t just academic—it’s vital to real-world development.

Logical Thinking

All of the above ultimately ties back to rigorous logic and problem-solving skills. Because of blockchain’s immutability and difficulty in patching mistakes, Smart Contracts demand more careful condition checks and error handling than typical applications.

For instance, in back-end development, a bug might be fixable by rolling back the DB or manually correcting data. In Smart Contracts, once a transaction has executed and changed state, there’s no going back.

You can design contracts to be upgradeable, but even that approach introduces new complexities and can pose additional security risks. It’s no magic bullet.

Therefore, a Smart Contract developer’s job isn’t just about producing functional code; it’s about anticipating edge cases and eliminating even minor flaws. This level of thoroughness and logical precision is the most crucial trait of a Smart Contract engineer, more so than any specific skill with tools or languages.

The Necessary Tech Stack

Programming Languages

Smart Contracts run on a Virtual Machine, which requires bytecode the VM can understand. We write it in a high-level (human-readable) language that compiles down to that bytecode. On EVM-based platforms, Solidity is the most popular. On Solana (SVM), Rust is the go-to. You’ll need to learn whatever language the platform demands.

Generally, developers stick to Solidity and Rust because of their ecosystems and available tooling. However, these aren’t the only options. For the EVM, there’s also the Python-like Vyper or the low-level Yul language. On Solana, you can even use C/C++. Unless you have a specific need, you’ll likely be most productive with the widely adopted languages and tooling.

Frameworks

Smart Contract development involves compiling, testing, debugging, and deploying. Frameworks exist to streamline each step, boosting your productivity. You can do it all without a framework, but it’s much more cumbersome.

On the EVM side, you can use Hardhat (JavaScript/TypeScript) or Foundry (Solidity native). On Solana, Anchor is widely used. Each has its pros and cons, so choose what suits your needs.

Various Tools and Third-Party Services

It’s a good idea not to limit yourself. Experiment with tools like Tenderly, Etherscan, or node providers like Infura, Alchemy, or QuickNode. All can significantly enhance your development efficiency.

As with any technology, simply knowing one language or framework won’t guarantee a great piece of software. All knowledge is interconnected and should be applied organically.

The Mindset of a Smart Contract Developer

In typical development, you assume some mistakes will happen—patches can be deployed, or a database can be updated. But these “safety nets” can also encourage sloppy work or create technical debt: leaving TODOs scattered around the code, skimping on tests, or ignoring error handling. While this might be acceptable in a traditional project as a trade-off, it’s not advisable in Smart Contract development.

A Smart Contract developer must always keep in mind that you “can’t easily fix things” later. You should strive for perfection from the outset. Mistakes directly translate to financial loss, sometimes in the tens or hundreds of millions of dollars. So you have to prioritize security and caution above all else.

Yes, you can design your contracts to be upgradeable, but this also affects the entire architecture and can expose new vulnerabilities. Upgradeability isn’t a silver bullet.

Conclusion & Learning Module

Smart Contract development is about more than just writing code in a specific language. It requires a deep understanding of blockchain’s unique environment and demands meticulous design for code that can’t simply be edited later.

Every line of code, every choice in variable names or structures, can have huge implications for the assets of countless users. The degree of caution required is on another level compared to traditional software development.

On the flip side, once you overcome these challenges, the reward is immense: you’re creating an immutable, decentralized application that lives on the blockchain. That’s both fascinating and incredibly meaningful. I hope this article has offered some insight to those considering Smart Contract development.

We at [Shard Lab] provide a Learning Module designed to help developers deepen their understanding of blockchain. We aim to make it easy for you to gain experience in various blockchain environments—covering core, application, and tooling aspects across multiple chains. We hope it proves to be a valuable experience for you!

Subscribe now

At its core, the blockchain system is designed with the philosophy that it must be more transparent and fair than any other system. All data must be verifiable, and anyone should be able to reproduce the same results under the same conditions.

However, this very property ironically becomes an obstacle when we try to generate “true randomness,” which must be unpredictable. Verifiability and unpredictability are, in essence, opposing concepts.

So in this article, we’ll be exploring a few key questions:

• Why is randomness such a challenging problem in blockchain?

• How can we produce random numbers that are both unpredictable and tamper-proof?

• What do the main solutions look like under the hood?

• Which approach should we choose when implementing real-world applications?

Defining Randomness

A random number is a value whose outcome cannot be predicted and is statistically uniform in its distribution. In nature, random numbers (e.g., those derived from atmospheric noise or radioactive decay) rely on external physical phenomena, so we can call them “truly random.” However, a computer program fundamentally works in a deterministic manner, making it difficult—if not impossible—to produce “completely random” values purely from internal processes.

There are generally two approaches to generating random numbers on a computer:

1. True Random Number Generator (TRNG)

   • Relies on physical phenomena (like atmospheric noise or radioactive decay) measured by sensors to generate randomness.

   • It’s very hard to predict, but it often requires specialized hardware or sensors, can be expensive to implement, and may be slow.

2. Pseudo-Random Number Generator (PRNG)

   • Uses mathematical algorithms to produce sequences that appear random.

   • A given seed will always generate the same sequence of numbers if the algorithm is repeated.

   • This method is fast and convenient, and it’s used in most software-based random number generators. However, if the seed or internal state is leaked, it’s possible for an attacker to predict the future outputs.

In a decentralized system like a blockchain, transparency and verifiability are crucial. Yet we need a random number that’s unpredictable and still verifiable by every participant. Over the years, various solutions have been proposed, and we’ll walk through a few of the major approaches.

Why Randomness Is Tough on the Blockchain

Deterministic Environment

Because all nodes in a blockchain network must maintain the same state, it’s not feasible to simply call a function like random() arbitrarily. If one node produces a different random value than another node, the network’s consensus would break.

Transparency

Any data stored on-chain is ultimately visible to everyone. Even if you try to keep your random seed hidden, at some point it may become public on the chain. As soon as it’s in a predictable state, attackers could exploit it.

Block Producer (Miner/Validator) Manipulation

Whether a blockchain is PoW (miner-based) or PoS (validator-based), the entity that creates the block can attempt to manipulate certain elements—like re-trying block hashes or rearranging transactions—to get a favorable outcome.

If you rely on block hashes or timestamps alone for randomness, a block producer might simply discard (“orphan”) a block if the resulting hash isn’t what they want. They can keep trying until they get a hash that suits them.

Attempts to Implement Randomness on the Blockchain

Hash-Based Randomness (Block Hash, Tx Hash, etc.)

As mentioned, the blockchain is a deterministic and transparent environment, which makes it tough to achieve true randomness. While values like blockhash, difficulty, or timestamp may look “random,” they’re still produced deterministically by block producers and can be manipulated to some degree.

pragma solidity ^0.8.0;

contract RandomContract {
    function getRandom() public view returns (uint256) {
        bytes32 blockHash = blockhash(block.number - 1);
        uint256 randomValue = uint256(
            keccak256(
                abi.encodePacked(blockHash, msg.sender, block.timestamp)
            )
        );
        return (randomValue % 100) + 1;
    }
}

This doesn’t provide secure randomness. For high-stakes use cases—such as games, lotteries, or anything with real monetary value—this approach is strongly discouraged.

Commit & Reveal

Commit & Reveal is a technique where participants first submit (Commit) a hash of a secret value, and then later reveal (Reveal) the original value. By hashing the secret initially, no one can know the actual input until it’s revealed. This can mitigate third-party manipulation (including by block producers) and help ensure fairness.

• Commit: Each participant chooses a random seed and a secret salt, then submits the hash (e.g., via keccak256) to the blockchain. At this point, nobody knows the actual inputs—only the hash.

• Reveal: After the commit phase, each participant discloses their original data (seed, salt). Other participants verify that the hash matches the committed value.

Below is a simple Solidity example:

pragma solidity ^0.8.0;

contract SimpleLottery {
    mapping(address => bytes32) public commits;
    mapping(address => uint256) public revealedSeed;
    address[] public players;

    /**
     * @dev Commit phase: submit the hash.
     *  - hash = keccak256(abi.encodePacked(seed, salt))
     */
    function commitHash(bytes32 _commit) external {
        require(commits[msg.sender] == 0, "Already committed");
        commits[msg.sender] = _commit;
        players.push(msg.sender);
    }

    /**
     * @dev Reveal phase: disclose the actual seed and salt.
     */
    function revealSeed(uint256 _seed, string memory _salt) external {
        require(commits[msg.sender] != 0, "No commit found");

        bytes32 checkHash = keccak256(abi.encodePacked(_seed, _salt));
        require(checkHash == commits[msg.sender], "Invalid reveal");

        revealedSeed[msg.sender] = _seed;
    }

    /**
     * @dev A simple example of deriving a final random number
     *      by hashing all revealed seeds together.
     */
    function getFinalRandom() external view returns (uint256) {
        uint256 totalSeed;
        for (uint256 i = 0; i < players.length; i++) {
            totalSeed += revealedSeed[players[i]];
        }
        
        return uint256(keccak256(abi.encodePacked(totalSeed)));
    }
}

Here, the final random value depends on the combination of everyone’s revealed seeds. Because the original seeds are hashed beforehand, it’s hard to predict them in advance. However, if certain participants collude, they might influence the final value, and if someone doesn’t reveal, the process can stall. Practical implementations usually require additional safeguards like strict reveal deadlines or penalties.

VRF (Verifiable Random Function)

A VRF uses a secret key (sk) to generate an output (β) from an input (α) in such a way that β looks random, while also producing a proof (π) that β indeed came from α. Anyone can verify this proof using the corresponding public key (pk), but only the holder of the secret key can produce a valid β–π pair.

• Input (α)

• Secret Key (sk)

• Output (β): Pseudorandom-looking result

• Proof (π): Cryptographic proof that β was derived from α

The verification step uses:

• Public Key (pk) corresponding to sk

• α, β, π

• Returns True if valid, False if tampered

VRFs stand out because they provide cryptographic assurance that the random output hasn’t been altered. Thanks to this property, VRFs are widely considered one of the most robust ways to generate randomness on-chain. Chainlink, for instance, offers a VRF service that DApps can use without needing deep cryptographic expertise, making it a popular choice in the blockchain ecosystem.

Aavegotchi, PoolTogether, and others are utilizing Chainlink VRFs to ensure the reliability of their random numbers, especially in the NFT/Gaming space. For more examples, check out the Chainlink Case Study.

VRF in Code

We've prepared a learning module showcasing how to use Chainlink VRF for generating random numbers in a DApp. Through this module, we hope you'll gain a clear understanding of how randomness can be practically applied in the blockchain (DApp) environment.

In this learning module, we expect you to interact with a contract that interfaces with a VRF deployed on a real on-chain (Bsc Testnet) and gain a better understanding of the real case.

Conclusion and Takeaways

• In a blockchain environment, the deterministic and transparent nature makes generating random numbers far more difficult than in traditional computing systems.

• From simpler approaches (like hash-based methods or Commit & Reveal) to cryptographically verifiable techniques (like VRF), each solution has its own strengths and weaknesses. It’s essential to choose the right one based on the dApp’s required level of security, acceptable delay, and implementation complexity.

Subscribe now

🧭 About This Series
As a Tech Lead at ShardLab, I often get asked what it actually means to be a blockchain developer. This post kicks off a new series where I share what I’ve learned from working across different parts of the blockchain stack—mainnets, wallets, smart contracts, DApps, and beyond—along with insights into the roles, skills, and challenges that define blockchain development today.

Subscribe for in-depth interviews with talented builders, code-level examples, and lessons from the field!

👋 How I Got Here

I didn’t fall in love with blockchain because of its philosophy at first. What drew me in was its architecture—the idea of building decentralized systems with new assumptions, new constraints, and new tradeoffs. As an engineer, it was a completely different kind of challenge, and that alone was exciting.

In 2017, I started building blockchain systems—long before I fully understood the broader implications of what I was working on. At the time, I was simply fascinated by the rawness of the ecosystem, the unfamiliar design patterns, and the lack of tooling or documentation. There were almost no tutorials or open-source references—and definitely no ChatGPT to guide you. So I learned the hard way: by building.

It wasn’t until a few years later, around 2020, that things really started to click. I remember looking at something like Uniswap V2 in 2020 and thinking: how is it possible that fewer than ten developers built something moving billions of dollars in value every day? That moment helped me realize blockchain isn’t just a technical innovation—it’s a lens into much bigger and harder questions about governance, economics, politics, incentives, ownership—even art.

What excites me most now is not just the technology, but the opportunity to contribute to systems that are technically demanding and socially meaningful. Blockchain is messy, idealistic, and sometimes contradictory—but that's exactly what makes it worth building.

Over the past 8+ years, I’ve worked on a wide range of systems:

• Developing a mainnet entirely from scratch (no forks, no SDKs)

• Operating and maintaining node services

• Designing and implementing a custom smart contract language

• Building hot & cold wallet infrastructure (B2B and B2C)

• Creating and scaling decentralized applications (DApps)

• (Briefly) auditing smart contracts

"Blockchain development" isn’t one job—it’s an ecosystem of entirely different roles.

Each area demands different skill sets, capabilities, development styles, and even entirely different ways of thinking.

This post offers a personal overview of those areas—what makes them interesting, challenging, and worth exploring if you’re curious about a career in blockchain.

🔍 Overview of Blockchain Development Areas

As the blockchain ecosystem matured, I found myself working across different layers of the stack—not because I set out to do so, but because each phase of the space’s growth brought new technical needs and open questions. And the more I moved between domains, the more I realized how distinct each one really was.

From designing low-level consensus protocols to building UX for everyday users, the skill sets, decision-making logic, and even development cultures differ significantly. Most blockchain developers specialize in one or two of these areas—but understanding the landscape as a whole helps you navigate where your skills might fit and where you might want to go.

Here’s how I personally think about the major domains of blockchain development:

🏗️ 1. Mainnet Development

Mainnet development is perhaps the most foundational and complex area in blockchain engineering. It’s very similar to building a distributed system from the ground up—because that’s essentially what it is. This work typically involves high-performance system programming using languages like Rust, Go, or C++.

At this level, you’re thinking about how to store and retrieve blockchain data efficiently, how nodes communicate and reach consensus quickly, and whether you should design your own virtual machine for executing smart contracts—or adopt an existing one. You’re also often involved in designing the token economy, defining governance mechanisms, and shaping the underlying philosophy and purpose of the chain itself.

💡 Key tradeoffs: decentralization vs. scalability vs. security (a.k.a. the blockchain trilemma). Offering flexibility—such as dynamic validator sets or upgradable modules—can make the protocol more adaptable, but also introduces audit complexity and surface area for bugs.

This domain is filled with low-level concerns and hard tradeoffs. From performance bottlenecks to protocol-level attacks, everything has to be considered. It goes far beyond writing code—it requires thinking about why the chain exists in the first place, what purpose it serves, and what values it needs to uphold.

Fortunately, many components of modern blockchains have become modular. You don’t have to reinvent every piece. Tools like Cosmos SDK, Substrate, or Polygon Edge offer starting points for launching a chain. But if you’re building from scratch—as I did—you quickly realize just how many invisible complexities are involved.

🧠 2. Smart Contract Language & VM Design

This domain sits at the intersection of systems programming, language design, and blockchain execution semantics. It’s one of the most intellectually intense areas I've touched, and something relatively few developers get to experience firsthand.

I worked on an experimental language and virtual machine (VM) as an open-source side project. It wasn’t production-ready, but the experience taught me a lot about how smart contracts actually run at a low level.

When designing a smart contract language or VM, there are several key considerations that shape how it functions and how safely it can be used:

• Determinism: The same input should always produce the same result. Since smart contracts run independently on every node, there can’t be any variation. No randomness. No calls to current time. No I/O from external systems.

• Termination: All smart contracts must eventually halt. Infinite loops or non-terminating calls are unacceptable.

• Sandboxing: The VM must strictly isolate execution—no touching the file system, memory, or network beyond what the protocol permits.

• Gas Metering: Every operation has a cost, paid by the user. Instruction design must consider not just expressiveness but execution safety and cost-efficiency.

The more flexibility a language allows, the more surface area it introduces for misuse or vulnerabilities. That’s why many blockchains introduce purpose-built domain-specific languages (DSLs) like Move or Cadence, while others constrain general-purpose languages like Solidity.

Building a secure, expressive, and efficient execution layer is as much about the philosophy of contract safety as it is about engineering elegance.

🛰️ 3. Node Service Operation

Node operation isn’t always the most glamorous job in blockchain—but it’s one of the most critical. Without well-run, well-synced nodes, everything else on a chain grinds to a halt.

In some cases, teams operate their own dedicated nodes (e.g. for RPC endpoints, validators, or infrastructure services). In others, specialized providers like QuickNode or Alchemy offer scalable node access behind unified APIs.

The core challenges often mirror Web2 infrastructure engineering—but with blockchain-specific constraints:

• Consistency: Because blockchains are constantly growing, different nodes may be a few blocks apart. This can cause inconsistent read results if traffic isn’t routed carefully.

• High-load behavior: Some RPC calls (e.g. eth_call, balance queries) dominate traffic and need caching, rate-limiting, and sometimes precomputed responses.

• Archive data: Serving historical state at any block height (i.e. archive mode) consumes massive storage and is costly to maintain.

As teams scale, operating dozens or even hundreds of nodes reliably becomes a full-time challenge. Failover strategies, logging and monitoring, traffic shaping, and endpoint optimization all come into play.

The invisible work of node infrastructure is what keeps blockchain apps usable. It’s a thankless, backend-heavy task—but an essential one.

🔐 4. Wallet

This is the area I’ve spent the most time in, and it’s far more nuanced than it may appear on the surface. Wallet development spans deeply technical and user-centric challenges that go well beyond sending and receiving crypto. While MetaMask is often used as a familiar reference point, even it is a complex product under the hood.

When designing a wallet—whether for consumers or institutions—you need to consider areas like:

• Key Management: Will the wallet be custodial or non-custodial? This decision impacts whether users manage their own keys or if the service secures them via hardware modules, MPC, or other strategies.

• Signature Schemes & Address Derivation: Each chain uses different cryptographic curves and derivation paths, which affect compatibility and integration.

• Asset Models: Some blockchains use UTXOs (like Bitcoin), while others use account-based balances (like Ethereum), requiring different syncing and transaction logic.

• Token Standards: Even within the same ecosystem, standards like ERC-20, ERC-721, and others may have small variations that impact how transactions and balances are handled.

• User Experience: UX decisions—such as how to handle recovery, transaction previewing, and gas estimation—can deeply affect usability and user trust.

These aren’t just technical details—they shape everything from user onboarding to long-term scalability and security.

Beyond B2C products like MetaMask, there are also enterprise-grade wallet systems—hot, warm, and cold wallets designed for institutions. These systems include policy engines, approval flows, compliance tooling.

In multi-chain environments, another layer of complexity comes from indexing assets, handling network fees in native tokens, and abstracting the different behaviors across chains into a unified experience.

Lately, I’ve been especially excited about Account Abstraction (AA) wallets. These offer programmable account behavior, enabling features like gas sponsorship, social recovery, batched transactions, and session keys. They represent a huge leap forward in UX and security—but also require an entirely new architecture.

What fascinated me most was abstracting all of this complexity into a UX that Web2 users could understand and trust—without hiding the responsibility and security guarantees that make blockchain powerful in the first place.

🌐 5. Decentralized Applications (DApps)

When most people say they want to build something in blockchain, this is usually what they mean. DApps (Decentralized Applications) are products that combine smart contracts, frontend UIs, and indexing layers to deliver blockchain-based functionality to users.

At a high level, DApp development includes:

• Smart Contracts: Core application logic lives on-chain. This can include DeFi logic, NFT minting, DAOs, and more.

• Frontend: Typically built in TypeScript and React, it interacts with wallet providers, reads blockchain data, and triggers transactions.

• Indexers: Since querying on-chain state directly can be slow or limited, DApps often use off-chain indexers like The Graph or custom services to power UIs.

• Backend / Off-chain Logic: Sometimes needed for things like authentication, metadata handling, or signature aggregation.

Unlike traditional apps, blockchain transactions are irreversible and often carry fees. This introduces new engineering considerations that Web2 developers may not be accustomed to:

• You optimize not just for speed, but for gas efficiency—even small changes in contract structure can result in significant cost savings.

• Once deployed, contracts are immutable unless carefully designed with upgradeability in mind—this raises the bar for writing reliable code before launch.

• Error handling and transaction feedback become crucial, since failed transactions cost users money and can’t be undone.

Even DApp architecture itself has changed the way we model products. For example, Uniswap V2 introduced an AMM model that works without an order book, without a matching engine, and without fiat. That wouldn’t have made sense in a centralized world—but makes perfect sense when trustless settlement is the default.

DApps must provide clear value over Web2 in order to justify the added complexity and cost of using blockchain. While the UX and infrastructure still have a long way to go, progress is accelerating—and we’re already seeing some glimpses of what’s possible.

🕵️ 6. Smart Contract Auditing

This is a domain I’ve only brushed against directly, but I’ve had the chance to watch experienced auditors work and learn from several notable hacks and reviews. It’s one of the most critical—and most unforgiving—areas in blockchain development.

At its core, auditing is about identifying weaknesses before attackers do. But it’s not just about reviewing single contracts. It often involves understanding entire systems of contracts, protocol invariants, and external interactions.

Good auditors need:

• Deep EVM-level knowledge: From storage slots and delegate calls, to gas mechanics and precompiled contracts.

• An understanding of common attack vectors: Reentrancy, overflow/underflow, improper access control, faulty logic in upgradability patterns.

• Cross-contract reasoning: Some bugs only emerge when contracts interact in unexpected ways.

• Tool fluency: Tools like Slither, MythX, Foundry, or formal verification frameworks can help—but they don’t replace human judgment.

What I learned is that smart contract auditing isn't about confirming that everything works—it's about assuming that someone will try to break it, and figuring out how. You have to adopt an adversarial mindset and actively look for creative ways contracts might be abused. Especially in DeFi, where huge sums of money are on the line, the motivation for attackers is enormous.

Here are just a few high-profile examples that shaped how the industry thinks about auditing:

• The DAO (2016) — Reentrancy attack that drained ~$60M in ETH and led to Ethereum’s hard fork.

• Parity (2017) — A bug in a shared multisig contract led to 500K ETH being permanently frozen.

• Wormhole (2022) — A Solana bridge was exploited for ~$300M after a signature verification bug.

• Ronin (2022) — Validators were compromised via social engineering, leading to ~$600M in losses.

💼 Industry Role Breakdown

Aside from my own experience, I’ve observed how blockchain developer roles are structured across different teams—startups, protocol foundations, infrastructure providers, and exchanges. The boundaries between roles are often blurry, but there are some broadly recognized categories that help when navigating job descriptions or thinking about career paths.

Smart Contract Engineer

This role is all about writing and maintaining the logic that lives directly on-chain. These engineers work primarily in languages like Solidity, Move, or Rust, and often operate in high-stakes environments like DeFi, NFTs, or DAOs. A strong understanding of smart contract patterns, gas optimization, and security practices—such as guarding against reentrancy or ensuring safe upgradeability—is essential. They collaborate closely with auditors and product teams and often own the testing and deployment pipelines for contract delivery.

Blockchain Protocol Engineer

Protocol engineers focus on the base layer of the blockchain itself. They implement consensus mechanisms, build peer-to-peer networking layers, design transaction propagation rules, and work on the core blockchain clients. Their work involves deep system-level programming, often in Rust, Go, or C++. They typically contribute to Layer 1 or Layer 2 protocols, or ecosystem tools like validators, relayers, and light clients. These engineers think in terms of state transitions, fork choice rules, and performance tradeoffs at the protocol level.

Web3 Frontend/Backend Engineer

This role spans building interfaces and APIs that connect users to smart contracts. On the frontend side, these engineers integrate wallets like MetaMask or WalletConnect, handle transaction flows, and reflect on-chain state in real time. On the backend, they might aggregate indexed blockchain data, manage cache layers, or trigger off-chain processes like queuing or metadata management. Many wallet developers fall into this category as well, since building a wallet often involves combining frontend logic with cryptographic backends.

Infrastructure / DevOps Engineer (Web3 Infra)

Infra engineers handle the operational backbone of blockchain systems. They deploy and monitor RPC nodes, configure archive nodes, set up logs and metrics, and ensure services remain highly available. Their stack usually includes Kubernetes, Docker, Grafana, Prometheus, and cloud providers like AWS or GCP. They may also support developers by maintaining indexers, orchestrating testnets, and managing CI/CD pipelines for protocol or app-level deployments.

Security Engineer / Auditor

Security roles exist both in-house and at specialized firms. These engineers audit smart contracts and blockchain infrastructure, looking for vulnerabilities before attackers do. They read low-level EVM bytecode, fuzz edge cases, simulate exploits, and validate that core protocol invariants hold. Their toolkit may include Slither, Foundry, MythX, or formal verification frameworks. This role requires not only technical depth but also an adversarial mindset and strong understanding of game theory and financial mechanics—especially in the context of DeFi.

These roles often overlap in practice. Smart contract engineers sometimes audit each other’s work; backend engineers often collaborate with infra to tune indexers; and everyone benefits from knowing a little security. Still, these role archetypes provide a useful way to navigate the landscape.

🚀 Final Thoughts: The Road Ahead

“Which part of the blockchain development stack do you want to focus on?”

It’s about building systems that transfer and store value, establish trust without intermediaries, and operate reliably in decentralized environments. Each area demands a different mindset and engineering approach.

It sounds ambitious—and it is. But that’s also what makes this space so intellectually and creatively exciting.

We’re still early in this journey. Despite all the headlines, blockchain hasn’t yet reached the level of mass adoption many of us envision. That’s not because the potential isn’t there—but because there are still so many challenges to solve.

The user experience is often clunky or intimidating. Developer tools are still maturing. Security issues continue to shake trust. And most importantly, many DApps still struggle to deliver clear value beyond what Web2 alternatives already offer. Until blockchain applications can provide a distinctly better or more meaningful experience—whether through ownership, composability, or censorship resistance—most users won’t have a reason to switch.

But that’s also what makes this moment interesting. The space is still being defined, and there’s real opportunity to shape how things evolve. What the ecosystem needs most isn’t just more users—it’s more people willing to build, explore, and contribute in their own way. Whether that’s prototyping new DApps, contributing to infrastructure, improving UX, or writing better docs—there’s no single path, and no permission needed.

If you're reading this and wondering whether there's a place for you: there is.

Whether you're new to Web3 or looking to deepen your expertise, I hope this post gave you a clearer picture of what it means to be a blockchain developer.

In the upcoming posts, I’ll explore each area more deeply—with practical examples, technical insights, and interviews with builders shaping the future.

✨ Stay tuned—and thank you for reading 🙌

Before transactions ever make it on-chain, they pass through a hidden battleground. Validators, traders, and bot operators compete fiercely to reorder transactions in their favor, profiting handsomely in the process.

We call this MEV (Maximal Extractable Value)—the pursuit of maximum profit during block production. While the average user may not notice it, within the industry, MEV is often described as an “invisible tax,” underscoring its growing impact on the blockchain economy.

In this article, we’ll explore the fundamentals of MEV and the challenges it poses. We’ll also introduce a MEV Learning Module, which provides a sandboxed EVM environment for hands-on experience in implementing MEV strategies. Let’s dive in.

How MEV Works

To understand MEV, we first need to look at how transactions are processed on a blockchain. We’ll use Ethereum (EVM) as our example, noting that not all blockchains follow the same exact structure.

1. User
   Most users generate and sign transactions—such as sending ETH or swapping tokens—through wallets like MetaMask.

2. Mempool
   Once created, a transaction doesn’t go straight into a block. Instead, it’s placed in a public Mempool (a waiting area) shared by blockchain nodes:

   • The Mempool holds transactions not yet included in a block.

   • Because the Mempool is public, anyone can see these pending transactions.

3. Miner/Validator

   • In Proof-of-Work, miners; in Proof-of-Stake, validators select transactions from the Mempool to build new blocks.

   • Generally, block producers pick transactions that pay higher gas fees first to maximize their own profit.

4. Blockchain

   • Once a transaction is included in a block, that transaction is considered confirmed.

Because the Mempool is public, it inadvertently becomes a source of MEV opportunities. Anyone who can see pending transactions has a window to reorder, front-run, or otherwise strategize to capture additional profit.

Ethereum is a Dark Forest offers a vivid real-world account of MEV. The author compares Ethereum to a dark forest, where front-running bots lurk like predators waiting to pounce on unsuspecting transactions. This analogy illustrates how transparency can paradoxically enable hidden conflicts. Being able to view pending transactions in real time creates an environment where opportunistic players can exploit that visibility.

MEV Strategies

Below are some of the most common strategies used to extract MEV.

Front-Running

Front-running involves detecting someone else’s transaction in the Mempool and submitting your own transaction first so it executes ahead of theirs.

In the previously mentioned Ethereum is a Dark Forest, we can observe a real-world example of Front Running. To simplify it, let’s assume there’s a contract where a password is entered to access a vault.

contract Vault {
    bytes32 private hashedPassword;

    constructor(bytes32 hashedPassword) {
        hashedPassword = hashedPassword;
    }

    function withdraw(string memory password) public {
        if (keccak256(abi.encodePacked(password)) == hashedPassword) {
            payable(msg.sender).transfer(address(this).balance);
        }
    }
}

If someone who knows the password sends a transaction to withdraw funds, as soon as that transaction appears in the Mempool, an MEV bot could detect it, copy the password, and submit its own transaction first—stealing the funds before the original user’s transaction even executes.

Back-Running

Back-running is the opposite of front-running: you intentionally place your transaction after another transaction.

In a Lending Protocol, there is the concept of liquidation. When the value of a borrower’s collateral falls below the value of the loaned asset, a third party can repay the collateral on behalf of the borrower and acquire the loaned asset at a discount to prevent losses for the Lending Protocol. The example below shows how in AAVE2, USDT (collateral) is repaid on behalf of the borrower, and ETH is acquired at a lower price.

Liquidation occurs when the value of the assets changes. Therefore, Liquidation Transactions follow the transactions that update the Lending Protocol’s prices and trigger liquidation immediately after the update.

Sandwich Attack

A sandwich attack combines front-running and back-running. You insert your transactions both before and after someone else’s transaction, effectively “sandwiching” it.

1. Detect a large swap pending in the Mempool.

2. Place a buy transaction first (front-run) to push the token’s price up.

3. Let the target user’s swap execute at this higher price.

4. Immediately sell (back-run) to cash in on the price difference.

As a result, the victim’s swap faces worse slippage, while the attacker profits from this manipulation. Below is a real example on Etherscan, where the attacker’s front-run and back-run transactions flank the target user’s swap.

Below is an actual example of a sandwich attack on Etherscan:

The attacker detects a pending swap in the Mempool, then places a Front Run Tx to buy and a Back Run Tx to sell, sandwiching the user’s Target Tx in between.

And More…

MEV isn’t limited to front-running and sandwich attacks. There are many other tactics—like arbitrage, NFT minting races, and just-in-time liquidity.

Problems & Future Solutions

MEV brings several challenges:

1. Network trust Erosion

   • If a single block producer consistently monopolizes MEV, it undermines the network’s decentralization and damages user trust in the system.

2. User Harm

   • Attacks like sandwiching directly cause real losses to ordinary users, making the blockchain ecosystem less appealing.

3. Reduced Usability

   • Intense MEV competition often leads to spikes in gas fees or network congestion, diminishing overall usability.

However, some forms of MEV—like arbitrage or liquidations—can improve market efficiency. Even so, negative impacts have spurred efforts to mitigate or manage MEV.

Here are some different ways to solve MEV problems:

1. Application-Level Solutions

   • CoW Swap: Matches users who want to trade opposite sides of the same pair directly, helping to prevent sandwich attacks by eliminating the need for a public on-chain swap.

2. Middleware

   • FlashBots: Bypasses the public Mempool via a private relay.

     

     • Searchers create bundles of transactions designed to extract MEV.

     • A Relay validates these bundles.

     • Miners/Validators then choose the most profitable bundle to include.

     • Although it requires dedicated infrastructure, FlashBots is an example of tackling MEV at the middleware level.

3. Protocol-Level Solutions

   • Proposer-Builder Separation (PBS): Splits block production into two roles—“Builders,” who extract MEV, and “Proposers,” who select which blocks to finalize. Separating responsibilities can help prevent a single entity from unilaterally reordering transactions and monopolizing MEV, thereby supporting network decentralization.

Conclusion

MEV has evolved into a pivotal aspect of blockchain economics. The inherent transparency of blockchains allows creative strategies like front-running, back-running, and sandwich attacks to thrive. However, not all MEV is detrimental; certain forms, such as arbitrage and liquidations, can enhance overall market efficiency.

As MEV grows more complex, the industry is actively pursuing solutions at multiple layers—applications, middleware, and protocols. This MEV Learning Module offers hands-on opportunities to experiment with these strategies in a sandboxed environment. By understanding how MEV works in practice, we can better develop and support safer, more efficient blockchain ecosystems for everyone.

Imagine:

• "I know the solution to this puzzle, but I won’t tell you the answer."

• "I’ve done the computation correctly, but I don’t want to show you the inputs."

That’s the magic of Zero-Knowledge Proofs (ZKPs) — a way to convince someone you know something, without giving away a single clue about what that something is.

This post is your beginner-friendly guide to zk-SNARKs — a powerful type of ZKP — explained with metaphors, light formulas, and grounded examples.

🛠️ What Makes This Guide Different?

There are plenty of articles that explain zk-SNARKs — but very few that actually show you how to implement them step-by-step in code.

That’s what sets this guide apart.

Throughout this post, every concept is directly connected to real, working code that you can read, run, and modify. This isn't just theory — it's an implementation-first approach that is designed to help you truly understand zk-SNARKs by building them yourself.

Here’s what you’ll get that most other resources don’t:

• R1CS not just as equations, but broken down into variable flows and witness vectors — so you can see how each part of the computation maps into constraints.

• Lagrange interpolation implemented in code, so you can build QAP polynomials from constraint matrices, not just read about it.

• The full QAP transformation: from R1CS constraints to polynomial identity checks.

• Pairing-based proof verification using noble-bls12-381 — so you can see how the cryptographic pairing check works under the hood.

This hands-on approach is powered by a complete Learning Module on GitHub that complements this post. You’ll be guided through building a zk-SNARK prover and verifier from scratch — no hidden black boxes.

If you've ever thought, "I kind of get the idea… but I wish someone showed me how to actually code it," this is exactly the guide for you.

🔗 Jump to the Learning Module

Why Should You Care?

zk-SNARKs aren't just cryptographic novelties. They're already being used to solve real problems in privacy, scalability, and verification.

• Privacy: Prove you've made a valid transaction without revealing the sender, receiver, or amount.

• Scalability: Summarize thousands of off-chain transactions into a single on-chain proof (as in zkRollups).

• Selective Disclosure: Prove you're over 18, or a verified user, without revealing anything else about your identity.

• Verifiable Voting: Enable private but auditable election systems.

At a deeper level, zk-SNARKs let us move from trust-based systems to proof-based systems: from "trust me" to "prove it — without showing me how."

How zk-SNARKs Work - An Overview

Before diving into code, let’s map the process from idea to proof — with enough detail to help you truly understand what each stage means and why it matters.

1. Model the computation as an equation
   Let’s say you want to prove you know a number x such that: (x + 2)(x + 3)(x - 1) = 60 You want to prove this without revealing what x is. So the first step is to define this target computation.

2. Convert it into constraints (R1CS)
   We break it into intermediate steps:

   a = x + 2 
   b = x + 3 
   c = a * b 
   d = x - 1 
   out = c * d

3. Create constraints for the multiplication steps:

   c = (x + 2)(x + 3) // Constraint 1
   out = c(x - 1)     // Constraint 2

   Each step becomes a constraint of the form (A · w)(B · w) = (C · w), where w holds all inputs and intermediate values. If all constraints hold, the computation is correct. We'll later convert them into polynomials using Lagrange interpolation.

4. Run a trusted setup (CRS)
   A one-time ceremony generates encrypted references to powers of a secret number au au. These values (the CRS) are shared between the prover and verifier and enable secure computations "in the exponent" without ever revealing au au.

5. Create a proof
   The prover uses their secret witness (the values of xx, aa, bb, etc.) and the CRS to generate a compact zk-SNARK proof. This proof confirms that the prover knows inputs satisfying the constraints, and thus, the original computation.

6. Verify the proof
   Using the CRS and elliptic curve pairings, the verifier checks a single equation involving the committed polynomials. If it holds, the verifier is convinced the prover did the computation correctly — without learning any private data.

Each of these stages is broken down in the following sections — each one comes with real TypeScript code and detailed explanations.

Step 1: Model the Computation as an Equation

The first step in constructing a zk-SNARK is to define what you're trying to prove — without revealing the private input. For example:

(x + 2)(x + 3)(x - 1) = 60

You know some x that satisfies this equation, but you don’t want to reveal x. This step transforms a real-world claim into a formal computation — a statement that can be checked by others.

This is essential because zk-SNARKs can only prove knowledge of satisfying inputs for known computations. So you begin by explicitly expressing the logic you want to prove.

What’s introduced here:

• Encrypted exponentiation: like proving 1 + 2 = 3 using g^1 * g^2 = g^3

• The target statement: a computation we want to prove knowledge of.

• The concept of hiding the witness: x is known only to the prover.

Step 2: Convert to R1CS (Rank-1 Constraint System)

To move toward a verifiable proof, we break down our equation (x + 2)(x + 3)(x - 1) = 60 into small, checkable steps. Why? Because zk-SNARKs need to express logic as a sequence of multiplications, which are non-linear and harder to fake than simple additions:

a = x + 2
b = x + 3
c = a * b
d = x - 1
out = c * d

We now define constraints only for the two multiplication steps:

1. c = a * b

2. out = c * d

Each of these becomes a separate R1CS constraint:

(A · w) * (B · w) = (C · w)

Let’s define our witness vector:

w = [1, x, a, b, c, d, out]

(The 1 is for constant terms.)

Constraint matrices:

• Constraint 1: c = (x + 2)(x + 3)

  • A = [2, 1, 0, 0, 0, 0, 0] → selects x + 2

  • B = [3, 1, 0, 0, 0, 0, 0] → selects x + 3

  • C = [0, 0, 0, 0, 1, 0, 0] → outputs to c

• Constraint 2: out = c * (x - 1)

  • A = [0, 0, 0, 0, 1, 0, 0] → selects c

  • B = [-1, 1, 0, 0, 0, 0, 0] → selects x - 1

  • C = [0, 0, 0, 0, 0, 0, 1] → outputs to out

Why Multiplication Constraints?

Additions are linear and easy to merge — but multiplications are where logic becomes non-trivial. Every interesting computation can be reduced to additions and multiplications, and R1CS tracks each multiplication independently.

By checking that each multiplication constraint is satisfied, we know the entire logic has been executed correctly — this is what makes R1CS powerful:

If all constraints are satisfied, then the full computation is correct.

What’s introduced here:

• The witness vector: holds all inputs and intermediate values.

• The R1CS format: breaks logic into clean multiplication constraints.

• Multiplication as the core of verification.

Step 3: Transform R1CS to QAP (Quadratic Arithmetic Program)

We now want to transform our R1CS constraints into a form that supports efficient proof generation and verification — this is where the Quadratic Arithmetic Program (QAP) comes in.

From Step 2, we had two multiplication constraints represented as R1CS matrices. We now assign each constraint a unique position on the x-axis:

• Constraint 1 → x = 1

• Constraint 2 → x = 2

Then, for each variable in the witness vector ([1, x, a, b, c, d, out]), we extract its role in the constraints to build polynomials:

Let’s take variable x as an example:

• In A matrix: it appears in both constraints → coefficients = [1, 0]

• In B matrix: also in both → coefficients = [1, 1]

• In C matrix: not used directly → coefficients = [0, 0]

We now use Lagrange interpolation to construct a polynomial u_x(x) that satisfies:

u_x(1) = 1   (from constraint 1)
u_x(2) = 0   (from constraint 2)

This gives us:

u_x(x) = (x - 2) / (1 - 2) = -(x - 2)

Similarly, we do this for all variables and all matrices (A, B, C), building sets of polynomials:

• uᵢ(x): left input

• vᵢ(x): right input

• wᵢ(x): output

Using these, we compute the overall identity:

P(x) = (Σ wᵢ * uᵢ(x)) * (Σ wᵢ * vᵢ(x)) - (Σ wᵢ * wᵢ(x))

This polynomial P(x) must evaluate to 0 at all constraint points (x = 1, 2).

To check that without revealing anything, we introduce:

The Vanishing Polynomial t(x)

t(x) = (x - 1)(x - 2)

If P(x) is divisible by t(x), then all constraints are satisfied. So we require:

P(x) = h(x) * t(x)

What’s introduced here:

• Lagrange interpolation: turns discrete constraint coefficients into polynomials

• QAP polynomials (uᵢ, vᵢ, wᵢ): one per witness variable

• P(x): encodes all constraint logic into one equation

• Vanishing polynomial t(x): lets us check all constraints together

This transformation sets us up to prove that the computation is valid — without revealing any of the inputs.

Step 4: Trusted Setup (CRS)

Let’s say you want to prove that 1 + 2 = 3, but without showing any of the actual numbers.

Instead of sharing 1, 2, or 3, you raise a public group generator g to the power of those numbers:

g¹, g², g³

Then the verifier can check:

g¹ · g² = g³

This works because exponentiation in cryptographic groups preserves multiplication:

g¹ · g² = g^(1+2) = g³

Even though the verifier never sees the actual values, they can still check the computation.

This is the intuition behind working in the exponent — we represent computations using group elements like g^x, and the verifier checks relations using elliptic curve pairings. a trusted setup to generate a Common Reference String (CRS) — a set of cryptographic values derived from a secret parameter au au, like:

g¹, gᵗ, gᵗ², gᵗ³, …, g^(t(τ))

These values are generated once and published publicly. Importantly, no one should ever learn the value of au au — otherwise, they could forge proofs.

The CRS enables us to work with polynomials in encrypted form. The prover can commit to their polynomial evaluations at au au using these powers, and the verifier can later check that those commitments satisfy the necessary identity.

What’s introduced here:

• CRS (Common Reference String): shared cryptographic data based on a secret au au

• Commitments to polynomials in exponent: instead of sending raw values, we send elliptic curve points

• Trusted setup ceremonies: often multi-party, to ensure no one knows the full au au

This sets the foundation for zero-knowledge: polynomials are committed without revealing them.

Step 5: Create a Proof

With the CRS and secret witness in hand, the prover builds the zk-SNARK proof. This proof contains cryptographic commitments to the polynomials we built earlier:

• A(τ): evaluation of the left polynomial side

• B(τ): evaluation of the right side

• C(τ): output polynomial

• H(τ): the quotient polynomial where P(x) = H(x) * t(x)

Each is committed using elliptic curve points, e.g.:

A = g^{A(τ)} ∈ G1
B = g^{B(τ)} ∈ G2
C = g^{C(τ)} ∈ G1
H = g^{H(τ)} ∈ G1

Together, these commitments encode the proof that:

• You know a valid witness w

• It satisfies all constraints in R1CS → QAP

• Without revealing any part of w

What’s introduced here:

• Cryptographic commitments to polynomial evaluations

• Quotient polynomial H(x): shows P(x) divides by t(x)

• Structured proof format: allows small, efficient zk-SNARKs

The proof is compact and non-interactive — no need to ask the prover any questions afterward.

Step 6: Verify the Proof

The verifier now uses the CRS and pairing-based cryptography to check a single equation:

e(A, B) = e(C, g) · e(H, g^{t(τ)})

This pairing check validates the main QAP identity in encrypted form:

(A(τ) * B(τ)) - C(τ) = H(τ) * t(τ)

If this identity holds, it means:

• The prover followed the computation logic

• The secret witness satisfied all constraints

• The proof is valid — without revealing the witness

What’s introduced here:

• Pairing checks: special cryptographic operations verifying equations in the exponent

• Soundness via randomness: the prover doesn’t know au au, so they can’t forge false polynomials

• Efficient verification: checking the proof takes constant time, no matter how big the original computation was

In one elegant equation, the verifier confirms the truth of the entire computation.

Theory to Code

Feeling overwhelmed by zk-SNARK papers and slides? We get it. That’s why this guide includes a companion Learning Module — a GitHub repo full of walkthroughs and testable code.

In the repo, you'll find:

• Modular files: cleanly separated logic for R1CS, QAP, CRS, and proofs

• Tests that match theory: each test corresponds to a concept in this guide

• Minimal but modern stack: written in TypeScript, built on noble-bls12-381

🔗 View the zk-SNARK Learning Module on GitHub

Ready to See It in Action?

Now that you've seen how zk-SNARKs work — from constraint modeling to polynomial transformations to cryptographic verification — it’s time to put the theory into code.

Our Learning Module takes everything you’ve just read and turns it into an actual working implementation. You’ll build your own prover and verifier using TypeScript and noble-bls12-381.

Each step — from R1CS generation to QAP polynomials to trusted setup — is covered with clear, testable code. If you're ready to turn ideas into code, dive into the repo and start experimenting.

Appendix: What This Guide Leaves Out — and Why

This guide walks you through a full working version of zk-SNARKs — from R1CS to QAP to pairing-based verification. But it intentionally leaves out a few advanced features found in fully optimized zk-SNARK schemes like Groth16. Here's a quick overview:

1. No Public Inputs Handling

In many real-world use cases, you need to prove something about a public value — like proving that a transaction involves a known address. Groth16 handles this by including public inputs in the proof structure.

To do this, the trusted setup must include terms like:

[g^{α·uᵢ(τ)}], [g^{β·vᵢ(τ)}], [g^{γ}], etc.

And the final proof includes a separate component for public input evaluation.

Why we skipped it: We focused this guide on private inputs only, to simplify the core ideas. Handling public inputs securely introduces extra pairing terms and CRS setup rules that would distract from the fundamentals.

2. No α, β, γ Powers

Groth16 introduces additional secret powers (α, β, γ) into the CRS, which are used to tie the different parts of the proof together and prevent specific types of forgery.

These terms affect how the proof elements like π_A, π_B, π_C are constructed and verified:

e(π_A, π_B) = e(π_C, g) · e(g^{α·β}, g^γ)

Why we skipped it: Our goal was to focus on the structure of the computation and constraint system, not optimizations or tighter zero-knowledge guarantees. Adding α, β, γ increases complexity in both setup and verification.

By leaving these out, we can help you build an end-to-end zk-SNARK from scratch, understand all the intermediate representations, and trace how constraints become provable identities.

Once you're comfortable with the basics, stepping up to Groth16 is just a matter of adding public input handling and adjusting the CRS and pairing logic.

We hope this was useful and provided you with a clear understanding on zk-SNARKs.

🔗 If you have questions or want to discuss about the topic and/or Learning Module, join us on Discord!

Have you ever felt like you kind of understand how blockchain works but struggle to actually build something with it? The gap between knowing the concepts and implementing them in code is real—and that's exactly why we started this newsletter.

Why This, Why Now?

Blockchain development can feel overwhelming. There’s a flood of information out there, but a lot of it stays at the surface level. We wanted to create a space where Web3 builders—whether you're just starting out or already deep in the trenches—can go beyond theory and into actual implementation.

What to Expect

Protocol Newsletter isn’t just another blog or newsletter about blockchain concepts. It’s a hands-on learning resource designed to help you truly build on Web3. Every post will break down complex blockchain technologies, provide real-world coding examples, and explore both foundational concepts and cutting-edge developments.

• Step-by-step breakdowns of blockchain protocols

• Code implementations to help you understand how things work under the hood

• Deep dives into emerging trends so you stay ahead of the curve

Join the Community

This isn’t just about content—it’s about building a space where Web3 developers can learn, experiment, and grow together. Whether you're here to refine your skills or take your first steps into blockchain development, I hope this newsletter becomes a valuable part of your journey.

Hit that Subscribe button and let’s dive into the world of Web3 🚀

Subscribe now