Web3 application architecture (DApp application architecture)

Application (DApp) Architecture in the Web 3.0 Era

Applications in the Web 2.0 Era

Web 3.0 applications (or "DApps") are architected quite differently than Web 2.0 applications

Take Medium, for example, a simple blogging site that lets users post their own content and interact with other people's content.

As a Web 2.0 application, it may sound simple, but in Medium's architecture, many things are needed to make it possible.

• First, there has to be a place to store basic data like users, posts, tags, comments, likes, etc. This requires a constantly updated database.

• Second, the backend code (written in a language such as Node.js, Java, or Python) must define Medium's business logic. For example, what happens when a new user signs up, publishes a new blog, or comments on someone else's blog?

• Third, front-end code (usually written in JavaScript, HTML, and CSS) must define Medium's user logic. For example, what does the website look like, and what happens when users interact with each element on the page?

Putting it all together, when you write a blog post on Medium, you interact with its front end, which interacts with its back end, which communicates data with the database. All of these codes are hosted on centralized servers and sent to users through their internet browsers. This is a good summary of how most Web 2.0 applications work today.

But everything is changing.

Blockchain technology unlocks an exciting new direction for Web 3.0 applications. In this post, we will focus on what the Ethereum blockchain brings to the table.

What makes Web 3.0 different?

Unlike Web 2.0 applications such as Medium, Web 3.0 eliminates the middle man. There is no centralized database to store the state of business programs, and no centralized web server to store back-end logic.

Instead, you can use the blockchain to build applications on a decentralized state machine maintained by anonymous nodes on the Internet.

By "state machine" I mean a machine that maintains some given program state and future states allowed on that machine. A blockchain is a state machine that is instantiated into a genesis state and has very strict rules (i.e. consensus) that define how that state transitions.

Even better, no single entity controls this decentralized state machine – it is collectively maintained by everyone in the network.

What about the backend server? Unlike Medium's back-end control approach, in Web 3.0 you can write smart contracts that define the logic of your application and deploy it to a decentralized state machine. This means that everyone who wants to build a blockchain application will deploy their code on this shared state machine.

What about the front end? It remains pretty much the same, with a few exceptions, which we'll cover later.

Here's what the schema looks like.

close observation

Now let's take a deeper look at what makes this possible.

(1) Blockchain

The Ethereum blockchain is often touted as the "world computer". This is because it is a globally accessible, deterministic state machine maintained by a peer-to-peer network of nodes. State changes on this state machine are governed by consensus rules followed by peers in the network.

So, in other words, it is designed to be a state machine that anyone in the world can access and write to. Therefore, this machine is not owned by any single entity – it is owned jointly by everyone in the network.

One more thing to know: data intelligence is written to the Ethereum blockchain – you can never update existing data.

(2) Smart contract

A smart contract is a program that runs on the Ethereum blockchain and defines the logic behind state changes that occur on the blockchain. Smart contracts are written in high-level languages ​​such as Solidity or Vyper.

Since the smart contract code is stored on the Ethereum blockchain, anyone can inspect the application logic of all smart contracts on the network.

(3) Ethereum Virtual Machine (EVM)

Next, you have the Ethereum Virtual Machine, which executes the logic defined in the smart contract and handles state changes that occur on this globally accessible state machine.

EVM does not understand high-level languages ​​like Solidity and Vyper, which are used to write smart contracts. Instead, you have to compile the high-level language into bytecode, which the EVM can then execute.

(4) front end

Finally, we have the front desk. As we mentioned before, it defines the user interface logic, but the front end also communicates with the application logic defined in the smart contract.

The communication between the frontend and the smart contract is a bit more complicated than what is shown in the diagram above. Let's take a closer look next.

How does the front-end code communicate with the smart contract on Ethereum?

We want our front end to communicate with our smart contracts so they can call functions, but to recap, Ethereum is a decentralized network. Each node in the Ethereum network keeps a copy of all states on the Ethereum state machine, including the code and data related to each smart contract.

When we interact with data and code on the blockchain, we need to interact with one of these nodes. This is because any node can broadcast a request to execute a transaction on the EVM. Miners will then execute that transaction and propagate the resulting state change to the rest of the network.

There are two ways to broadcast a new transaction.

• 1. Build your own node and run the Ethereum blockchain software

• Use nodes provided by third-party services such as Infura, Alchemy, and Quicknode

If you use a third-party service, you don't have to deal with all the headaches of running a full node yourself. After all, setting up a new Ethereum node on your own server can take days. (There's a lot of data to sync - it can even take up more bandwidth and storage than the average laptop can handle).

Also, as your DApp scales up, the cost of storing the full Ethereum blockchain rises, and you need to add more nodes to expand your infrastructure. That's why, as your infrastructure becomes more complex, you need full-time DevOps engineers. They will help you maintain your infrastructure to ensure reliable uptime and fast response times.

Taken together, avoiding these hassles is why many DApps choose to use services like Infura or Alchemy to manage their node infrastructure for them. Of course, this comes at a cost, as this creates a centralized choke point, but let's save that bunny diagram for another day. )

Moving on, let's talk about providers. When you need to interact with the blockchain, the node you connect to (whether you set it up yourself or use an existing node from a third-party service) is often called a "provider".

Every Ethereum client (i.e. provider) is based on the JSON-RPC specification. This ensures that when front-end applications want to interact with the blockchain, there is a unified approach. If you understand the introductory knowledge of JSON-PRC, it is a stateless, lightweight remote procedure call (RPC) protocol that defines several data structures and their processing rules. It's transport-agnostic, so the concepts can be used in the same process, over sockets, over HTTP, or in many different messaging environments. It uses JSON (RFC 4627) as a data format.

Once you are connected to the blockchain through a provider, you can read the state stored on the blockchain. But if you want to write to the state, there is one more thing you need to do before committing the transaction to the blockchain - "sign" the transaction with your private key.

For example, imagine we have a DApp that lets users read or post blog posts to the blockchain. You might have a button in the frontend that allows anyone to look up blog posts written by a particular user. (To recap, reading from the blockchain does not require the user to sign the transaction.)

However, when a user wants to publish a new post on the chain, our DApp will ask the user to "sign" that transaction with their private key - only then will the DApp forward the transaction onto the blockchain. Otherwise, the node will not accept the transaction.

This is where Metamask usually comes in when this transaction is "signed".

Metamask is a tool that enables applications to easily handle key management and transaction signing. Metamask also provides a connection to the blockchain (as a "provider") since it already has a connection to a node provided by Infura as it needs it to sign transactions. In this way, Metamaks is both a provider and a signer.

storage on the blockchain

Of course, if you are building an application where all smart contracts and data are done on the Ethereum blockchain, this architecture makes sense. But anyone who has built an application on Ethereum knows that storing everything on the blockchain can get very expensive.

Remember that with Ethereum, users pay every time new data is added to the blockchain. This is because adding states to a decentralized state machine increases the cost of nodes maintaining that state machine.

Requiring users to pay extra to use your DApp every time a user's transaction requires adding a new state is not the best user experience. One solution to this problem is to use a decentralized off-chain storage solution such as IPFS or Swarm.

IPFS is a distributed file system for storing and accessing data. Therefore, instead of storing data in a centralized database, the IPFS system distributes and stores data in a peer-to-peer network. This makes it easy to retrieve it when you need it.

IPFS also has an incentive layer called "Filecoin". This layer incentivizes nodes around the world to store and retrieve this data. You can use something like Infura (provides you with an IPFS node) or Pinata (provides an easy-to-use service where you "pin" your files to IPFS and take the IPFS hash and store it in a block on-chain) such suppliers.

Swarm is similar as well, it is a decentralized storage network, with one distinct difference. Filecoin is a self-contained system, while Swarm's incentive system for storing and retrieving data is built-in and enforced through smart contracts on the Ethereum blockchain.

So now with IPFS or Swarm, our application architecture looks like this.

You may also notice that in the image below, the code for the front end is not stored on the blockchain. We could host this code on AWS like we would normally do in Web 2.0, but this creates a centralized node for your DApp. What if AWS goes down? What if it reviews your app?

This is why, if you want to build a truly decentralized application, you will probably choose to host your front end on a decentralized storage solution such as IPFS or Swarm.

So now your application architecture looks more like this.

Query the blockchain

So far we've talked about writing to the blockchain by deploying a transaction and then sending it to the blockchain. But what about reading data from a smart contract on the blockchain? There are two main ways to do this.

1) Smart contract events

You can use the Web3.js library to query and listen to smart contract events. You can listen for specific events and specify a callback every time the event is fired. For example, if you have a smart contract that sends a continuous stream of payments from person A to person B every block, you can emit an event every time a new payment is made to person B. Your front-end code can listen to events emitted by smart contracts and perform specific actions based on them.

2) Chart

The above approach works, but it has some limitations. For example, what if you deploy a smart contract and later discover that you need an event that was not included initially? Unfortunately, you have to redeploy a new smart contract with that event and data. Also using callbacks to handle various UI logic can quickly become very complex.

That's what "charts" are for.

Graph is an off-chain indexing solution that makes it easier to query data on the Ethereum blockchain. Graph allows you to define which smart contracts need to be indexed, which events and function calls need to be listened to, and how to convert incoming events into entities that your front-end logic (or something using the API) can consume. It uses GraphQL as a query language, which is preferred by many front-end engineers because of its expressive power compared to traditional REST APIs.

By indexing blockchain data, The Graph allows us to query on-chain data with low latency in application logic.

Now, your DApp architecture looks like this.

We're almost done, but we still have one major topic: scaling.

Extend your DApp

As you may have heard, Ethereum doesn’t scale – at least not yet.



Clearly, we have a problem here. Building a DApp on Ethereum with high gas fees and full blocks can lead to a very poor user experience. Thankfully, there are solutions in development.

A popular scaling solution is Polygon, which is a secondary scaling solution. Instead of executing transactions on the main blockchain, Polygon has "sidechains" to process and execute transactions. A sidechain is a secondary blockchain that interfaces with the main chain. Every once in a while, the sidechain submits a summary of its most recent blocks to the mainchain.
Other examples of L2 solutions are optimistic rolling and zkRollups. The idea here is similar: we use a "rolling" smart contract to batch transactions off-chain, and then commit those transactions to the main chain.

Our thinking is this. Secondary solutions perform transaction execution (i.e. the slow part) off-chain and only store transaction data on-chain. This allows us to scale the blockchain because we don't need to execute every transaction on the chain. This also makes transactions faster and cheaper – and they can still communicate with the main Ethereum blockchain if necessary.

piece it all together

If all of this is making your head spin, you're not alone. Piecing all these tools together is complicated and can lead to a painful developer experience. But don't worry - we're starting to see new developer frameworks that really improve the developer experience.

For example, Hardhat is a developer framework that makes it easier for Ethereum developers to build, deploy and test their smart contracts. Hardhat provides the "Hardhat Network" that developers can use to deploy their smart contracts onto a local network - without having to deal with a live environment. Even better, it offers a great ecosystem of plugins to make life easier for developers. Hardhat also provides a console.log() function, similar to javascript, for debugging purposes.

Of course, this is just the beginning. I hope we continue to see better developer tools in the future.

Original webpage: https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application