Understand these and become a Web3.0 developer

Want to build on web3? Nader Dabit points out the building blocks of the web3 technology stack in an introductory guide

In the next chapter of “Building on web3,” Edge & Node developer relations engineer Nader Dabit explains the web3 stack and how developers conceptualize all aspects of building on web3.

I transitioned to web3 in April 2021. Before that, I had been a traditional full-stack developer for about 10 years. While studying all these new technologies and ideas with great concentration, the first thing I want to know is “What is a web3 stack?”.

When building a traditional web or mobile application, I often rely on a few building blocks to complete the work:

  • API/application server (REST or GraphQL)
  • Verification layer (managed or manual)
  • database
  • Client frameworks, platforms and libraries
  • File storage

Using these core components, I can build most types of applications I want, or at least achieve most of the purposes. So, what does this look like in web3?

It turns out that the answer to this question is not so straightforward, because:

  • This paradigm is completely different in many ways
  • The tools, technology and ecosystem of web3 are not as mature as web2

It is also more difficult for me to understand how to start, run, and build web3 applications because I deal with problems in the same way as in the web2 world.

In the past 8 months or so, after work, research, experimentation and construction, I would like to share my experience with you.

What is web3?

Before we define the web3 stack, let’s try to define web3:

Web3 is a protocol stack that implements completely decentralized applications.

With this decentralized technology stack, we can start to build decentralized applications, which have their own meaning and characteristics.

Some features of web3 are:

  • Decentralized network infrastructure
  • Ownership (data, content and platform)
  • Local digital payment
  • Autonomous identity
  • Distributed, trustless, and powerful infrastructure
  • Open, public, composable backend

Although some applications built on the decentralized technology stack will replace their predecessors, the new source language enabled by the blockchain also makes new application paradigms possible.

Native digital payments and public back-end infrastructure—such as machine learning, mobile devices, virtual reality, and other technology sources, platforms, and building blocks—enable the creation of entirely new types of applications, some of which have not yet been imagined.

Does this mean that everything will be replaced by web3? uncertain. Although I think that for some types of applications, building on a decentralized technology stack is a better choice-just like almost any technology decision, it depends on what you want to build.

Now let us start to understand the web3 stack in depth, divided into the following categories:

  • Blockchain
  • Blockchain development environment
  • File storage
  • P2P database
  • API (index and query)
  • identity
  • Client (framework and library)
  • Other agreements


There are countless blockchains that you can choose to build on. No one is the “best”, on the contrary, you should consider the various trade-offs between them.

When learning new things, one thing is often important to me, and that is to apply the Pareto principle to what I have learned. In other words, what is the most effective way to obtain the result of that amount of time and effort. Following this idea, I can gain maximum traction and motivation while learning new things in the shortest time.

In the field of blockchain, learning Solidity and EVM (or Ethereum virtual machine) may be the best choice for getting started as a blockchain developer. Using this skill (and technology stack), you can build not only for Ethereum, but also for other Ethereum second layers, side chains, and even other blockchains (such as Avalanche, Fantom, and Celo).

In other words, Rust is becoming more and more popular in the blockchain field, and Solana, NEAR, Polkadot, etc. all have first-class Rust support. You may not make a mistake in learning these two languages, but for beginners, if someone asks me today, I will say that Solidity will still be a better choice.

In addition to these suggestions, here is an incomplete blockchain sample that has a solid combination of technology, practicality, community, momentum, and future feasibility:

  • Ethereum–original smart contract platform
  • ZKrollups: ZKSync, Starknet, Hermez-high-throughput Ethereum layer 2 but not natively compatible with EVM
  • Optimistic rollups: Arbitrum & Optimism-Ethereum layer 2, compatible with EVM (learn more about the difference between Optimistic rollups and ZKrollups here).
  • Polygon-Ethereum sidechain
  • Solana-high throughput, low transaction cost, fast block time, but harder to learn than EVM (Rust)
  • NEAR-the underlying blockchain, you can use Rust or Assemblyscript to write smart contracts
  • Cosmos-an interoperable blockchain ecosystem
  • Polkadot-a blockchain-based computing platform that enables the blockchain built on it to execute transactions between them, creating an interconnected blockchain internet
  • Fantom-EVM compatible underlying blockchain
  • Avalanche-EVM compatible underlying blockchain
  • Celo-EVM compatible underlying blockchain, designed to make it easy for anyone with a smartphone to send, receive and store encrypted currency
  • Tezos-Non-EVM compatible underlying blockchain, many NFT projects are using it

Blockchain development environment

For EVM development, there are several good development environments that can be used:

Hardhat (JavaScript) is a newer option, but it is gaining more and more favor. Their documentation is very good, tools and developer experience is very good, I personally have been using it to build decentralized applications.

Truffle (JavaScript) is a set of tools for building and developing applications on the EVM. It is very mature, tested in actual combat, and has very good documentation. It has been around for a while, and many developers are using it.

Foundry is a new Solidity development environment from Paradigm, showing great prospects. Its main features are the ability to write tests in Solidity, support for fuzzing, and speed (it is written in Rust). I wrote a separate introduction about it here.

Brownie is a Python-based smart contract development and testing framework for Solidity/EVM development.

For Solana development, Anchor is quickly becoming the entry point for new developers. It provides a CLI, a scaffold for building and testing Solana programs, and a client library that you can use to build the front end. It also includes a DSL that can abstract many complex problems that developers often encounter when they start to develop with Solana and Rust.

File storage

Where do we store pictures, videos and other files in web3? Storing such large files on the chain is usually very expensive, so we may not want to store them there.

Instead, we can use one of a few file storage protocols:

IPFS-Point-to-Point File System Protocol

Advantages: it is reliable, has good documentation, and has a huge ecosystem

Disadvantage: If the data is not fixed, it will be lost.

Arweave-allows you to store data permanently, and only pay a transaction fee. I am a fan of Arweave and wrote a blog post about it here.

Filecoin-from Protocol Labs, also the team that established IPFS, it is a protocol designed to provide a durable data storage system. There are some ways for developers to build on Filecoin, including web3.storage, which is great.

Skynet-I haven’t used it in production, but I have tried it and it seems to work very well. The API here looks great. I have some questions, such as how long the data persists, and the interoperability of Skynet with other protocols.

P2P database

In addition to file storage and on-chain storage, you may also need to store data off-chain. You can use these types of solutions, similar to the way you use databases in a traditional technology stack, but they are replicated on N nodes on a decentralized network and are therefore more reliable (at least in theory).

A few options are:

Ceramic Network-a decentralized open source platform for creating, hosting and sharing data. Ceramic also has a good identity agreement, which I will talk about later. Probably my favorite off-chain storage solution at the moment. There is a pretty good demo here.

Textile ThreadDB-a multi-party database built on IPFS and Libp2p. If I understand correctly, it may currently be undergoing a major API change. I tried it and it shows some prospects, but the documentation and DX need some improvement.

GunDB-a decentralized, peer-to-peer database. Gun has been around for quite a long time, and some quite interesting applications have been built with it.

In terms of maturity, my opinion is that the ecosystem of off-chain storage solutions has not yet reached the level required to establish more advanced use cases that some developers might want. Some of the challenges here are real-time data, conflict detection and conflict resolution, write authorization, documentation, and general developer experience.

Combining off-chain data solutions with blockchain protocols is one of the last big obstacles we need to overcome before we have a fully decentralized protocol stack that can support any type of application.

API (index and query)

The way we interact with and build on the blockchain is different from the database in the traditional technology stack. For blockchain, data is not stored in a format that can be efficiently or easily consumed directly from other applications or front-ends.

The blockchain is optimized for write operations. You often hear innovations centered on transaction volume per second, block time, and transaction costs. Blockchain data is written in blocks within a period of time, making it impossible except for basic read operations.

In most applications, you need functions like relational data, sorting, filtering, full-text search, paging and many other types of queries. In order to do this, the data needs to be indexed and organized for effective retrieval.

Traditionally, this is what the database does in a centralized technology stack, but the index layer is missing in the web3 stack.

The Graph is a protocol for indexing and querying blockchain data. It makes this process easier and provides a decentralized solution for doing so. Anyone can create and publish open GraphQL APIs, called subgraphs, to make blockchain data easy to query.

To learn more about The Graph, please check the documentation here (https://thegraph.com/docs/) or my tutorial here (https://dev.to/dabit3/building-graphql-apis- on-ethereum-4poa).


In web3, identity authentication is a completely different paradigm. In web2, authentication is almost always based on the user’s personal information. This information is usually collected through a form or OAuth provider, and users are required to hand over this information in exchange for access to the application.

In web3, identification is completely revolving around the concepts of wallet and public key cryptography.

Although the name “wallet” has its effect, I found that people who are new to web3 find this term confusing because it is related to authentication and identity. I hope that in the future we can come up with some other ways to express what a wallet is, because it combines not only all aspects of finance, but also identity and credibility.

As a developer, you will need to understand how to access and interact with users’ wallets and addresses in various ways.

At a very basic level (and a very common requirement), you may want to request access to the user’s wallet. To do this, you can usually access the user’s wallet in a windowed environment (web browser), or use a wallet adapter like WalletConnect or Solana.

For example, if they have an Ethereum wallet available, you will be able to access window.ethereum. The same is true for Solana (window.solana), Arweave (window.arweaveWallet) and a few other wallets. WalletConnect is suitable for mobile web and React Native because it allows users to use their mobile wallet for authorization directly from the device. 

If you want to handle the authentication yourself, you can let the user sign the transaction and then decode it somewhere to authenticate the user, but this usually requires a server. Here is an example of using EVM wallet, and here is an example of using Solana / Phantom.

How about managing user information in a decentralized way? Ceramic Network provides the most powerful protocol and tool suite for managing decentralized identities. They recently published a blog post outlining some of their recent updates and giving some guidelines on how all tools work together. I want to start from there, then explore their documentation to gain an understanding of how to start building, and consider checking out my example project using Ceramic self.id here.

If you want to get a user’s ENS text record, the ensjs library provides a good API to get user data:

1. const ens = new ENS({ provider, ensAddress: getEnsAddress('1') })2, const content = await ens.name('sha.eth').getText('avatar')

SpruceID is also a promising thing, but I haven’t tried it yet.

Both Ceramic and Spruce have implemented W3C’s DID specification, which in itself is also an integral part of web3 in my opinion. In this case, any centralized implementation of DID violates the concept that the specification attempts to achieve.


As far as the JavaScript framework is concerned, you can really build it with anything you want, because the client-side blockchain SDK is mostly framework-independent. In other words, most of the projects and examples are built in React. There are also libraries like Solana Wallet Adapter that provide additional tools for React, so I said it might be a wise move to learn or be familiar with React.

For the client SDK of Ethereum, there are web3.js and ethers.js. For me, Ethers is more accessible and has better documentation, even though web3.js has been around for longer.

In Solana, you might use @solana/web3.js and/or Anchor. I found that the Anchor client library is my first choice for building Solana applications, because I am also using the Anchor framework anyway, and I find it easier to understand than @solana/web3.js.

Other agreements

Radicle is a decentralized code collaboration protocol built on Git. It can be considered a decentralized version of GitHub.

Livepeer is a decentralized video streaming network. It is very mature and widely used. There are more than 70,000 GPU live broadcasts on the Internet.

Chainlink is an oracle that can access real-world data and off-chain calculations while maintaining the inherent security and reliability guarantees of blockchain technology.


This article will be a dynamic document that I keep up with as I learn, experiment, and collect feedback from web3 developers.

If you have any feedback or thoughts about what I have missed here, please share your thoughts with me. It’s exciting to see all the activities happening around web3, because developers are eager to participate. Although the infrastructure is still evolving, the vision of establishing a truly decentralized protocol and application is very important. It allows people to coordinate without having to give power and control to large companies. We are close to realizing this vision .

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/understand-these-and-become-a-web3-0-developer/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.