The Full Guide to Web3 Architecture

While Blockchain is the core aspect of Web3, in my mind, Web3 represents the interplay between the Web and Blockchain. It is a holistic, all-encompassing term for all sorts of apps built on the Web that interact with the Blockchain.
Some of them can be completely Blockchain-based, with only an interface to interact with them; others can be regular Web2 apps that talk to a single Smart Contract for gated access, and the rest can be anywhere in-between.

What is Web3 Architecture

Web3 Architecture is a collection of services that support your Smart Contracts and are responsible for providing a better user experience, detecting and handling unexpected errors, executing off-chain business logic, caching, indexing, and much more.

The following 4 major components make up the Web3 Architecture:

• Smart Contracts
• User Interface
• Event detection and Indexing
• Off-chain Business Logic

1. Smart Contracts

This is what we’re all here for, Smart Contracts are the foundation that makes Web3 exciting and valuable. They allow us to represent almost any real-world interaction in terms of code, and we can be sure it will get executed no matter what: Code is Law.
Smart Contracts can be written on almost any blockchain these days like Ethereum, Fantom, Solana, Cardano, Polkadot, even Bitcoin is getting some version of smart contracts with the Stacks project.

I won’t spend any more time on the specifics of Smart Contracts here because that’s what my whole blog is about.

2. User Interface

The User Interface (or the Frontend) is how your end users interact with your Smart Contract. Web3 is new, and it introduces new concepts like wallets, transactions, and signing messages, all of these are potential leaks of customers because they are so new.

It is the responsibility of your UI to provide a good user experience to people despite having all these new elements they’ve never seen before.

Mainly, there are two web3 interactions done through the UI: Connecting to wallets and interacting with Smart Contracts.

2.1 Connecting to wallets

Wallets hold the private/public key pairs of our users. We use these to identify the users on the blockchain and send transactions, which is basically taking actions on the behalf of the end user. The most popular wallet is obviously Metamask, which is used as a browser extension and is very easy to connect to your app.

There are a few libraries that can help you connect your front end with almost any crypto wallet; I’ll mention a few: Web3 Onboard, ConnectKit, Wagmi.

2.2 Interacting with the Blockchain

In simple terms, interacting with Blockchains means reading or writing data to Smart Contracts. You can manually encode the function call into raw bytes, but I would rather pull my hair out.

Instead, we use libraries like Ethers, Web3.js, Web3.py.
These libraries need to know the contract ABI, contract address and to have a wallet connection. Using the ABI, they allow us to interact with the contract just as we would call methods from a normal class.

3. Event detection and indexing

Events are one of the most useful features of blockchains. They allow us to log information without taking up space on the blockchain. They can be queried and retrieved by block range but within limits. It isn’t practically at all to retrieve the full event history every time there is a new user on your dApp. So it makes sense to store and index them for faster retrieval and to improve the user experience. There are a few ways to do this.

3.1 DIY Solution

A simple do-it-yourself solution is to have a blockchain WebSocket listener that will detect your smart contract events in real-time, then store and index them in your own database and server through your own API.
This way, a user can, for example, view their subscriptions, without you having to store a list of active user subscriptions on-chain.

3.2 Alchemy Web3 Notifications

There’s a new notifications service from Alchemy where they listen the blockchain for you. You just need to configure which contract and events to be listened to.
This is a big help, but you still need to have an API that is always online and listens to the webhook notifications from Alchemy.

3.3 The Graph | The Decentralized Way

The Graph has a network of Graph Nodes that process every block in a decentralized manner. You simply configure how you want your smart contract events to be processed and stored, and the nodes do the rest.
Also you can fetch the data whenever you want, because they detect it, index it, store it and you can query it whenever via their GraphQL API.

Also, their code is open-source, so you can run your own Graph Node that will only take care of indexing your own contract’s events. This is useful if they don’t support a certain EVM based chain. This way you can run your own Graph node and index your own contract on any EVM chain you like.

4. Off-chain Business Logic

Not all logic can or is supposed to be run by Smart Contracts. The Blockchain should be used mainly for the critical parts of your system that requires maximum transparency, trust and verifiability. But your app has extra business logic that needs to be processed, or maybe the smart contracts need data from the real world, how do we handle that?

4.1 Decentralized node networks

Depending on the project, some need to be more transparent because of the nature of the app, and others don’t because it’s easy to verify on-chain.
Those that do need 100% transparency for off-chain business logic, for example Oracles, they tend to develop decentralized node networks.

This is a network of nodes, similar to the blockchain network actually, where anyone can run a node, but the node is built by a specific protocol and these nodes help the protocol operate. I’ll give you a few examples:

Chainlink Oracle nodes

Chainlink is an Oracle provider, they have smart contracts that can provide your smart contracts with real-world information like USD/EUR exchange rate that changes every minute.
But their smart contracts receive this information from their decentralized node network. They have many nodes that are preconfigured to fetch certain data and feed it to their oracle contracts. This data must be 100% correct and that’s why consensus is required before these nodes can feed data to the smart contracts.

Request Network nodes

Request Network is a blockchain payment protocol that allow you to create payment requests that you want to be paid in certain currency and this whole process needs to be transparent. One of the main features of the project is that it stores a timeline of the status of the request, it can be accepted, rejected etc.
This data needs to be stored permanently on IPFS, but Smart Contracts can’t do that.
That is why they have Request nodes that are run off-chain but they listen to request changes on the Blockchain and store the data on IPFS. This node doesn’t require consensus because the data is easily verifiable on-chain if necessary.

4.2 Centralized business logic

While your protocol or dApp is in the early stages, it’s normal to do everything yourself. That means running your own business logic on your own server. There is nothing wrong with this if you provide a way for end-users to verify that what you’re doing is correct.

Summary

The main component to Web3 is and always will be the Blockchain and Smart Contracts. However, a lot of other moving parts are necessary for detecting and reacting to what’s happening on the blockchain. When developing a new app, my suggestion is to start with UI and Smart Contract as an MVP, and then add the extra necessary parts as needed. Start with Event detection after that, so you can notify the users of whatever si happening on-chain and provide better UX. And finally, add in the necessary extra business logic to have a complete production-ready application.