Former partner of a16z: Viewing the difference between Web2.0 and Web3.0 applications from the perspective of architecture

Everyone is familiar with terms such as blockchain, smart contract, IPFS, wallet, node, etc., and probably understand what they all do, but how they are linked together What about the ones that serve the construction of Web3.0 decentralized applications?

What we see is only the front end of the application, it is difficult for us to Get a peek into what's actually going on behind the scenes. Every component in the application architecture determines the underlying attributes of the application. If we really want to understand the essential differences between Web2.0 and Web3.0 applications, we need to start with the application architecture.

The author of this article, Preethi Kasireddy, was a partner at a16z from 2013 to 2015, and then in 2016 Joined Coinbase as a software engineer and was active in the Ethereum network as a smart contract engineer during the same period. This paper conducts an in-depth analysis of Web3.0 applications from the perspective of application framework. Rhythm BlockBeats translated the full text:

Web 3.0 Application Architecture

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

Take Medium, a simple blog site as an example. Medium allows users to post their own content and interact with other people's content.

Medium is a web 2.0 application with a simple-sounding architecture. But actually in Medium's architecture, a lot of work is needed to make this possible.

First, Medium needs a place to store things like users, posts, tags , Basic data such as comments and likes. These jobs require constant updating of the database.

Secondly, like Node.js, Java, or Python backend code Language determines the business logic of medium. For example, what happens when a new user signs up, publishes a new blog, or comments on someone else's blog?

Also, front-end like JavaScript, HTML, and CSS The code language determines the UI logic of Medium. For example, what does the website look like, and what happens when users interact with each element on the page?

When you blog on Medium, all these things will Integrate and link. You interact with its front end, the front end interacts with the back end, and the back end interacts with its database. All of these codes are hosted on centralized servers and sent to users via internet browsers. This is a high-level summary of how most Web 2.0 applications work today.

Now all that has changed.

Blockchain technology opens up exciting opportunities for Web 3.0 applications New Direction. In this article, we will focus on the changes brought about by Ethereum.

What makes Web 3.0 so different?

Different from web2.0 programs such as Medium, Web3.0 removes the middle layer. There is no centralized database for storing application state, and there is no centralized web server for storing back-end logic.

you You can use the blockchain construction program to build applications in a decentralized state machine, which is maintained by anonymous nodes on the Internet.

The state machine refers to A "machine" that maintains program state and allows new state to be written. A blockchain is a virtual machine, exemplified by a genesis state, which is then transformed according to specific rules.

More importantly, there is no single entity controlling this decentralized state machine, it is jointly maintained by everyone in the network.

In Web 3.0, you can write smart contracts to define the logic of your application and deploy them to a decentralized state machine. This means that everyone who wants to build a blockchain application deploys their code on this shared state machine. This is very different from Medium's backend.

The front end of Web3.0 is basically the same as that of Web2.0, and there are some special cases that we will explain later.

The following figure is the architecture of Web3.0

In-depth analysis

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

Ethereum is a point-to-point deterministic state machine that can be maintained globally, which makes Ethereum often touted as the "world computer". State changes on the state machine are controlled by nodes in the network that follow consensus rules.

In other words, it was designed to be practically anyone in the world A state machine that can both be accessed and written to. Therefore, this machine is not owned by any single entity, but is jointly owned by everyone in the network.

One more thing to know: Data can only be written to Ethereum With blockchain, you can never update existing data.

2) Smart Contract

Smart contracts are programs that run on the Ethereum blockchain and define what happens on the blockchain The logic behind the change. Smart contracts are usually written in high-level languages such as Solidity or Vyper.

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

3) Ethereum Virtual Machine (EVM)

The virtual machine is used to execute the logic defined in the smart contract and process the state that occurs on the state machine Variety.

Ethereum virtual machine does not understand such high first-order language. You need to compile these high-level languages into bytecodes that the Ethereum Virtual Machine can execute.

4) Front end

As we mentioned before, the front end defines the UI logic, but the front end also interacts with the application logic defined in the smart contract to interact.

The interaction between the front end and the smart contract is more than shown in the above figure It's a little more complicated. Let's elaborate on this part next.

How the front-end code on Ethereum interacts with smart contracts

We want to trigger specific functions of the program when the front end interacts with the smart contract, but don’t forget that Ethereum is a decentralized network of. Every Ethereum node needs to keep a copy of all the states on the Ethereum state machine. This copy includes all code and data related to the smart contract.

When we want to interact with the data and codes on the blockchain When , we need to communicate with a certain node in the blockchain. Because any node can broadcast a request to make a transaction on the Ethereum Virtual Machine. After this the miner will execute the transaction and broadcast the resulting state change to the rest of the network.

There are two ways to broadcast a new transaction:

1. Set up a node running the Ethereum program by yourself

2. Use Infura or Alchemy node provided by a third party

Using a third-party node saves you the hassle of running a full node yourself. Because of the large amount of data that needs to be synchronized, it usually takes several days to set up an Ethereum node. And the bandwidth and storage capacity required for synchronization exceeds the processing power of the average laptop, so you also need a powerful device.

Furthermore, the cost of storing the full Ethereum blockchain increases with DApp As the capacity increases, you need to add more nodes to expand your infrastructure. When your infrastructure becomes complex enough, you will need a full-time DevOps engineer (programmable operation and maintenance engineer). They will help you maintain your infrastructure to ensure reliable uptime and fast response times for your infrastructure.

To sum up, in order to avoid these troubles, many DApps choose to use Providers like Infura or Alchemy manage their nodes. But everything has advantages and disadvantages, which also creates a centralized choke point. But let's leave that aside for now.

Whether you set it up yourself or use a node from a third-party service, These nodes are often referred to as "Providers". Let's talk about these "providers" next.

Each Ethereum client (provider) implements the JSON-RPC specification. This ensures that front-end applications have a uniform set of methods when they want to interact with the blockchain. JSON-RPC is a stateless, lightweight remote application call (RPC) protocol that defines several data structures and their processing rules. Because it's transport-agnostic, these concepts can be used in the same process, across sockets, HTTP, or many different messaging environments. It uses JSON (RFC 4627) as the data format.

When you connect to the blockchain through the provider, you will The state stored on the blockchain can be read. However, if you want to write to the state, you need to "sign" the transaction with your private key before committing it to the blockchain.

For example, suppose we run a DApp that allows Users read or publish blog posts to the blockchain. You set up a button on the front end that allows anyone to query blog posts written by a specific user. But remember, reading an article in the blockchain does not require the user to sign the transaction.

However, when users want to publish new At the time of the article, DApps would require users to "sign" transactions with their private keys, only then would the DApp propagate the transaction to the blockchain. Otherwise the node will not accept the transaction.

The link of signing a transaction usually requires the use of Metamask (little fox).

Metamask is a tool that allows applications to easily handle key management and transaction signing. Its principle is very simple, Metamask stores the user's private key in the browser, and whenever the front end needs the user to sign a transaction, it will call Metamask.

Metamask will also link with the blockchain as a provider. Because Metamask needs to sign transactions, it establishes a connection with a node provided by Infura. In a way, Metamask is both a provider and a signer.

Store on the blockchain

Of course, if all the smart contracts and data in the application you build are stored on Ethereum, then this architecture is still reasonable. However, as anyone who has built an application on Ethereum knows, storage on the blockchain is quick and expensive.

We need to understand, Users are charged every time new data is added to Ethereum. This is because the decentralized state machine is maintained by nodes, and every new state added to the state machine will increase the cost of the node.  

If you If the DApp requires users to pay an additional fee every time they need to add a new state to a transaction, then the user experience is very poor. However, using a decentralized off-chain storage solution such as IPFS or Swarm can solve this problem.

IPFS is a A distributed file system for storing and accessing data. In other words, the IPFS system does not store data in a centralized database, but distributes data in a P2P network, allowing you to retrieve data at any time.

"Filecoin" is  The incentive layer of IPFS, its role is to incentivize nodes around the world to store and retrieve this data. You can use a provider like Infura or Pinata, because Infura gives you an IPFS node, and Pinata lets you "locate" a file in IPFS, and then get the IPFS hash and store it in a block On the chain, and the whole operation process is quite simple.

Swarm is a go The centralized storage network has many similarities with IPFS, but there is also an obvious difference between the two. That is, the Filecoin system is relatively independent, and Swarm's incentive system is built-in and executed by smart contracts on Ethereum for data storage and retrieval.  

So now , with IPFS or Swarm, our application architecture will look like this:

In the picture below, you may notice that the front-end code is not stored in the block chain. In fact, we can store the code on AWS as we did in Web 2.0, but doing so also means that your DApp will be subject to centralization constraints. For example, what if AWS goes down? What if it reviews your app?  

This also That's why, if you want to build a truly decentralized application, you will choose a decentralized storage solution like IPFS or Swarm to store the front end.  

So now Your application architecture will look like this:

In the area query on the blockchain

So far we have discussed how Writing transactions is done by signing them and sending them to the blockchain. But what about reading data from a smart contract on the blockchain? There are two main ways:

1) Smart contract events

You can use the Web3.js library to query and listen to smart contract events. You can also use Web3.js to listen to specific events and specify a callback function to be called every time the event is triggered. For example, now suppose you have a smart contract that sends a continuous stream of payments between sender and receiver every block, then every time a payment is made to the receiver, you can emit a smart contract event. Front-end code can listen to events triggered by smart contracts and take corresponding actions accordingly.

2) The Graph

The above method is indeed feasible , but it also has certain shortcomings. For example, you may only find out after the smart contract is deployed that the event you want to send is not included in the contract. What should you do? Unfortunately, you can only redeploy a new smart contract and put the event and related data into the new contract. Not only that, callback functions are also difficult to handle different UI logic.  

At this time It's time for "The Graph" to play.

The Graph is a The off-chain data indexing scheme can facilitate people to query data on Ethereum. In The Graph, you can define which smart contracts need to be indexed, which events and function calls need to be listened to, and you can also specify how to convert incoming events into entities that can be processed by the front-end logic (or any program that is using the API). It uses GraphQL as the query language, which is loved by front-end engineers because it conveys more information than a traditional REST API.

By indexing blockchain data, The Graph allows us to query on-chain data in application logic with almost no delay Condition.

Now, your The DApp structure is roughly like this:

Now there is only one last important issue: expansion.

DApp expansion

As you may have heard, Ethereum is not scalable, at least not yet.

Ethereum Gas Average Price

Average transaction fee

average block size

Obviously, the problem is that the gas fee on Ethereum is high and the blocks are almost saturated. Building a DApp on it will bring users Very bad experience. Fortunately, however, some related solutions are under development.

Polygon is a popular L2 Expansion plan. In Polygon, the processing and execution of transactions is done by "side chains" rather than the main chain. These sidechains are secondary blockchains connected to the main chain. Every so often, the sidechain aggregates its most recent blocks and submits them to the mainchain.

Similarly, Optimistic Rollup and zkRollup are also L2 solutions, and their working principles are similar: they use the "Rollup" smart contract to bundle a large number of transactions off-chain, and then submit these transactions to the main chain.  

We need What you know is: the L2 solution is to put the execution of the transaction (that is, the slower part) off the chain, and only store the transaction data on the chain. In this way, the blockchain can scale because we no longer have to execute every transaction on the chain. At the same time, this also speeds up the transaction process and reduces costs, and when necessary, the L2 solution can also communicate with the Ethereum main chain.

Overview

It's normal to feel dizzy and confused by this point, because putting all these tools together is inherently complex and overwhelming for developers. But don't worry, the continuous advent of development frameworks will actually improve the developer's work experience.  

For example , Hardhat is a development framework that facilitates Ethereum developers to build, deploy and test smart contracts. Hardhat has a built-in "Hardhat Network", and developers can use this network to deploy smart contracts to the local network without having to deal with the real-time environment. Not only that, but it also comes with a powerful plugin ecosystem that can provide developers with greater convenience. At the same time, Hardhat also has the console.log() function, which can be used for debugging just like javascript.

Of course, this is only It's just the beginning, and I hope developer tools get better in the future.

Summary

It took a lot of people months to figure out what a utility blockchain is, so if you are an entry-level DApp developer, then I hope This article can save you some time. That being the case, let's start building the DApp!

If you are right about building If you are interested in Web 3.0 applications, please sign up for our next Ethereum Development Bootcamp (Ethereum bootcamp), where you will learn how to build and deploy your first DApp on Ethereum.

As usual, If you have any questions or find any mistakes in this article, welcome to communicate with me in the comment area!

< /p>

Original text Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia