“Web3: The Next Generation of the Internet and Its Architecture and Tech Stack”

K Deepak
10 min readApr 13, 2023

When I encountered the blockchain a few months back, I found myself rather confused: I had no idea which technologies developed from Web2 to Web3. Furthermore, regardless of what options people say to choose towards this transition, most tech-check question responses also comprises of nontechnical marketing jargon — rendering me even more clueless where and how to begin. This is why this post appears from the student’s perclient: one who just ended exactly journey on learning all thats being relevantly redesigned and What is Web3?

My friend wasn’t entirely correct in his assessment of Web3 as simply being a extra name for the blockchain system. The fundamental basis of Web3 does surround blockchain, but when you get more into its development it’s clear that blockchain is only one aspect of it. To demonstrate this, the role of a blockchain in an application tied to Web3 would have a comparable purpose to how one might use a database with web app built on Web2 technology.

Web1 = the internet of information; i.e., The HTML CSS websites you cannot interact with.

Web2 = the internet of interactions; i.e., Modern platforms like Facebook, Twitter, etc., that allow you to be connected end to end with others.

Web3 = the new internet of value, i.e., the internet where centralization of information is eliminated.

So if we try to define Web3, we can say that it is the concept that aids the development of decentralized applications(dApps). Yes — the same decentralized internet we heard from Richard in Silicon Valley!

However, we do not have a compression engine platform like what he had built to build this. Instead, we have a range of protocols and platforms that enable this development system. These protocols are a set of rules that govern how your application works, while multiple platforms facilitate the creation of your application.

Okay, fine, but why do we need dApps in the first place?

The most significant benefit of creating a dApp is Ownership and Identity. Ownership of data, content, literally everything with your self-identity — a concept that got blurred with the coming of age of these top institutions like Google and Facebook.

Another significant benefits people talk about is Composability, one of the central pillars of Web3.

All software firms in existence at the present time are concentrating on acquiring consumer information,the leading asset which provides them with a unique identity over their competition. Possession of consumer records rather than the product they makes companies that vie against each other , that share comparably equal user interface and operational procedures, simultaneously significant in courtesy of it exclusive “data” issued.

This is what Web3 will disrupt, making every application composable by sharing & consuming their data between different applications. Think about a metaverse where you can buy things from Meta and use them in the Microsoft ecosystem. This is the most exciting and interesting aspect of Web3. It is making the web genuinely composable!

But that’s not all; with the high amount of trust and reliability these applications bring in, the possibilities are endless; we haven’t even imagined what the future might look like with dApps being omnipresent. I feel Web3 might start the same revolution that open-source brought into the developer ecosystem.

Understanding the Web3 Architecture

Now that we have defined Web3, we need to understand how these protocols and platforms work together to help us build these dApps.

When we imagine a general web app, we envision an architecture constituting the follows:

Although I’ve not depicted things like caches, queues, etc., a general over-the-top architecture looks like this.

For a Web3 app, The frontend will remain the same, but some exciting changes start to happen on the backend side of things. Let’s see how that works:

If we compare Web2 and Web3, the Blockchain Node is doing the heavy lifting and managing our data, which is decentralized into a network of blockchains. Since it is expensive to store directly on the chain, we have some off-chain File Storage and a P2P Database facilitating data storage. Finally, to build a secure layer, we have a Wallet or a Private Key-based Authentication to verify the individual’s identity.

Please note that this is just an over-the-top depiction of the architecture. In reality, we have much more complex applications and need architectural parameters from both Web2 and Web3.

The Web3 Tech Stack

So far, we have learned what a Web3 architecture generally looks like. Now, let’s deep dive into each of these components to better understand the tech stack.

So let’s start from the bottom:

Blockchain

If I talk about selecting a blockchain to build upon, it is one of the most challenging tasks one needs to decide on. There are many factors at play here; decentralization, transaction throughput, gas fees, ecosystem/interoperability, and many more, and we won’t be debating them all as it’ll never end. It is like choosing your programming language. Every single one works; a few are better in specific cases and others for other use cases.

Although, as a beginner, I might recommend starting with Ethereum Virtual Machine (EVM) with Solidity. This is because of the massively present developer community around it.

EVM acts as the virtual machine, the bedrock of Ethereum’s entire operating structure. Ethereum brought in the concept of smart contracts and is the most used blockchain out there. Solidity is the language used to make smart contracts. It is very similar to JavaScript in syntax, which might be helpful if you’re a Web2 developer. Under the hood, Solidity is compiled into low-level instructions called opcodes for the EVM to interpret.

When you’ve learned this, it will be easier to understand the concepts of other technologies in the ecosystem, like:

  • Solana: Another blockchain like Ethereum focuses on providing faster transaction times and cheaper fees. The smart contracts can be written in Rust, C, and C++.
  • Layer 2’s (L2): L2 refers to a secondary protocol built over an existing blockchain system, generally Ethereum, borrowing the main chain’s consensus security. There are many options here, but the top ones remain Polygon, Arbitrium, StarkEx & StarkNet, Optimism, etc.
  • Application Chains: Although you won’t require this as a newbie, I feel this is the most exciting option out there. You can build your own blockchain/consensus system with platforms like Tendermint/Cosmos, Polkadot, etc.

Blockchain Node

For deploying an application in production, you need a server. A blockchain node does this job for blockchains. Blockchain nodes are network stakeholders or devices running the “blockchain software”. Hence, they are authorized to keep track of the distributed ledger, serving as communication hubs for the network tasks. A P2P (Peer to Peer) protocol allows nodes to communicate within the network and transfer information about transactions and new blocks.

You can self-run blockchain nodes or get a Node service provider like Quicknode, Moralis, Infura, etc., that offer APIs to create automated flows. For self-hosting, AWS Cloud and Azure have images for you to spin up for the more popular chains. Otherwise, most chains make it easy for you to run your nodes/validators. The only thing that can be a hassle is to ensure uptime and maintenance, which depends on your network.

P2P Database

The first question that anybody would ask here is: Why do we need a database when we’re using blockchain in the first place? Additionally, will it not hinder our idea of a dApp?

As a simple answer to that, storing data on a blockchain is slow and expensive. We need an additional database to access data off-chain, ensuring that we’re not accessing the chain again and again. To have that decentralization part of it, we use peer-to-peer or P2P databases that store and host all of the data in streams to eliminate centralized database servers, blockchains, or local storage. Think about how your torrents get downloaded!

The Ceramic network is the most common decentralized database provider out there, as I know of personally.

Decentralized File Storage

Like every other application, we need a dedicated file storage system (similar to Amazon S3 for Web2 applications). Databases essentially are tabular data, while file storage is that folder-based data you need to store your large media files. IPFS is the most common P2P file system protocol with excellent community support. Arweave is another option focused on keeping data permanently. You can use platforms like Filecoin, Skynet, Storj, and 0Chain to host these file storage systems.

Authentication in Web3

In my honest opinion, authentication is one of the most essential aspects of Web3. Without logging in users into the smart contract, one cannot access their wallets and make the most straightforward transactions. You should note that signing a transaction enables every interaction with a blockchain.

Looking at traditional login methods in the Web2 world, we have a simple form structure where the user details are stored in a database and cross-checked for verification. Additionally, services like Google & Facebook offer OAuth, enabling access to some basic information to the app directly, making the process seamless. Although this approach is convenient, this cannot be now used in a dApp since you need a private key to sign a transaction.

In Web3, we do not have the user’s data, but actually, we have wallets (which are essentially a wrapper around a private key), wherein cryptographic signatures are used to prove ownership of those blockchain addresses. It is essential to know how to access and interact with a user’s address and private key as a Web3 developer.

The fascinating aspect of owning a blockchain wallet is that once a user loses their private key to the wallet address, no one can recover it for them. This is useful and scary at the same time. There are plenty of stories of crypto millionaires who have lost it all by storing their private keys in a lost hard drive.

Many projects have tried different ways to go around this and help users recover that key, the most common of them being Seed Phrases. The most famous wallet out there, MetaMask, uses the concept of 12 word Mnemonic Phrases, which goes through a BIP39 Algorithm to generate the array of unique wallet addresses and private keys for you stored in your MetaMask account. But then again, remembering 12 randomly generated words in proper order for each wallet account group a user owns is difficult.

While trying to figure out a solution to a lousy UX like this, I encountered Web3Auth, and interestingly enough, I ended up joining them within the next two months. Web3Auth is one of the most popular solutions for new users, bridging the Web2 and Web3 worlds. A simple auth infrastructure that gives those OAuth capabilities to Web3 applications in a self-custodial way for the user. By self custodial, we mean that the user has custody of the key and not the application or Web3Auth. This is done through a unique MPC architecture, and hence the private key is never stored in a single server/ node or method with complete access. Read more about the infrastructure here.

I think it can be a massive thing for a project onboarding process. I would recommend checking it out.

Implementing the Frontend

Many developers might not know, but the frontend technologies for Web3 and Web2 are the same. The only difference is where you need to reimagine the UX of the application because the authentication, processing in the blockchain, and general flow of the application are slightly different from Web2 applications.

I would recommend going on with React & Next.js since most developers are currently using this in the Web3 world. I might be biased, but almost every other project presently features a React integration. If you’re using Webpack 5, make sure that there are certain polyfills you need to take care of while developing an application; the rest of everything is generally the same.

For the client-side backend, things get a bit different. Here is where you need to understand how to interact with the blockchain you’ve created. Web3 Interaction libraries help you with that, but you need to know how they work and interact with the blockchain properly.

Blockchain Interaction (Web3) Libraries and development tools:

Web3 libraries allow you to interact with nodes using HTTP, IPC, or WebSocket. These libraries help developers write intuitive, one-line methods to initialize the JSON RPC requests (under the hood) that interact with whichever chain you’ve chosen.

On Ethereum, some of the Web3 Libraries are Web3.js, Ethers.js, and Light.js. On top of that, many chains have developer tools that provide features that allow for much faster iteration than public testnets. Tools like Ganache, Truffle, Hardhat, and Brownie are examples here.

For starting up with Ethereum development, I’d highly recommend checking out the Remix IDE — it is the best place for a beginner to learn Solidity and Ethereum concepts. You can easily directly interact and test out your code without setting up all these libraries.

Wrapping up

In all, I believe Web3 comes with an exciting opportunity for new developers out there to try out something different and break away from the traditional aspects of software development. At the same time, drawing this comparison and understanding where to start is extremely necessary for anyone looking to build decentralized applications since there will always be a combination of both in the world.

Web3 is here to stay, but this does not mean that the concepts of Web2 are dead. Learning the new tech stack while understanding its key usage and characteristics is the only way a developer can pioneer this new industry.

I hope this blog might have helped you understand some key aspects of how a Web3 app is put together. Please do let me know if I’ve missed or messed something up because I’m still a learner trying out different stuff in this new world :)

Cheers!

--

--