Web 3.0 is currently receiving worldwide attention for the core reason that it’s a scenario for the implementation of decentralized applications. It is also an important step of decentralized technology moving from the geek community to professional and public users. But as there are so many projects under the banner of Web 3.0, how can we distinguish the status quo and potential of these projects? We need a relatively complete set of assessment and judgment criteria.
Because Web 3.0 applications need to be aimed at both professional and public users, it is necessary to design the judgment criteria from the perspective of decentralized applications, and therefore it needs to be viewed from three dimensions:
1. Performance and user experience
3. Degree of decentralization
The first two are prerequisites for current applications to compete with each other, and the third is a prerequisite for Web 3.0 applications to be able to outperform similar Web 2.0 applications.
Analysis of Classification Criteria
Analysis of User Experience Criteria
For different applications, the requirements of user experience are different. For example, in a streaming application such as YouTube, it’s acceptable to buffer a video for a few seconds after clicking on it, but it’s unacceptable for it to be intermittent during playback. Uniswap, for example, is a DEFI application on Ethereum, and currently it’s mainly targeted at cryptocurrency users. Among these users, it can be tolerable that a transfer takes a few minutes to arrive. But even so, Uniswap is making transactions to be completed in a single block through technical means, and by increasing Gas fees it facilitates miners to pack the Uniswap transactions quickly.
User experience is seen on the user side, and what is hidden behind the user experience is the performance of the system. For example, the most important user experience for YouTube streaming media is the playback smoothness, which is seen by the users as the playback smoothness of this application, while in reality it is the content distribution performance of the system under certain concurrency conditions. For instant messaging software like Telegram, the most important user experience is connecting to the server as well as sending and receiving messages. For the system, it means the number of concurrent connections and the message forwarding performance. For non-real-time social media, when we open a page, it can display the followed/unfollowed aggregated information, including graphics and videos, so the speed at which the aggregated pages are opened is the core user experience.
Therefore, we can define different performance evaluation criteria for different kinds of applications:
- For DeFi finance, the speed of transaction and the type of tradable tokens are the most important user experience.
- For streaming media, the smoothness of playback is the most important user experience.
- For instant messaging, the connection and the message forwarding speed are the most important user experience.
- For non-real-time social media, the speed at which aggregated information pages are opened/switched is the most important user experience.
Standard Analysis of Cost
There are two dimensions of cost, namely the cost paid by users and the cost of system operation. In Web 2.0, users are generally divided into free users and paid users. Free users pay nothing but the basic network fees, while paid users get additional services by paying extra fees.
The infrastructure platforms (decentralized transactions, storage, traffic or computation, etc.) in Web 3.0 are created by global miners, who provide storage, traffic or computation services for the most basic purpose of generating revenue. In Web 3.0, applications are implemented by open-source code and open organizations (DAOs), which may then be operated by additional operators and made available to users. Both of them need to pay appropriate fees to access resources on the Web 3.0 infrastructure platforms.
In the early days of Web 3.0, the primary purpose for miners to provide their services was to receive rewards, which was the only way to leverage the financial nature of blockchain to provide dividends to early participants and to create the infrastructure platforms in a decentralized manner. However, the ultimate competition between different infrastructure platforms will come down to the actual cost of the services, and in the long run, the platforms with low cost for the service providers will inevitably defeat the platforms with high cost.
The operating costs of the underlying platform consist of two components — the cost of providing the service itself and the billing and validation of this service. The definition of cost is different for different functions:
For the modules with transaction functions:
the cost of providing services refers to the cost of generating, transmitting and storing transactions. The cost of billing and validation refers to the checking result of each node.
Obviously: Decentralized Transaction Cost = Transaction Generation Cost + (Transaction Validation + Storage + Transmission Cost) * Number of Nodes on Chain
For the modules with storage functions:
The cost of providing services refers to the cost of bandwidth per byte for storage and transmission. The cost of computation and verification refers to the cost of computation and bandwidth for verifying whether a node stores data.
For on-chain storage like ArWeave, computation and verification means simply copying the data to each node: Total Cost = (Storage Cost + Transmission Bandwidth Cost) * Number of Nodes
For the off-chain storage FileCoin, the on-chain verification scheme: Total Cost = Storage Cost per Node + (Transmission Cost of Hash + Verification Cost of Zero-knowledge Proof) + Number of Nodes
Obviously, the actual cost of FileCoin’s services is much lower than the cost of on-chain storage like ArWeave. And users can choose how many storage nodes to use to balance the security and cost of storage.
For the modules with traffic functions:
The cost of providing services refers the cost per byte for transmission. The cost of billing and verification refers to the cost of billing and verifying the transmission.
Obviously, due to the low value of traffic cost (basically 0.001$/GB), the frequency of billing and the cost spent are particularly important in this system.
For computation, it’s the cost of computation + the cost of billing verification. Since computation is a general concept, such as GPU rendering, CPU numerical operations are included in this category, there is no general solution for computation. Furthermore, since this will not be applied within the first phase of Web 3.0, it will not be explored in detail here.
Analysis of Decentralization Criteria
The three most fundamental cores of decentralization are: “Open-source”, “Trustless”, and “Permissionless”. In the process of application, even for the permissionless systems, the requirements for the devices to be added can also form a hidden threshold. Therefore, we define the full score for decentralization as being accessible by using an ordinary home computer and home bandwidth in addition to the three conditions mentioned above.
We refine the decentralization criteria so that within each of the following levels, it can be divided into 4 low grades with a total score difference of 2 points and a score difference of 0.5 points for each small grade:
Level 0: It conforms to the following two characteristics: A) The code is not open-source or the data is all stored on the project party’s devices; B) the data can only be accessed externally through a single entry point, where the single entry point is an IP/domain name, etc. The traditional Web 2.0 systems are compliant with these criteria. Or: Use a dedicated device that is not open-source. Level 0 projects are scored from 0 to 1.5 points
Level 1: At level 0, the data is stored on the project party’s devices, and the code is open-source or not but can be accessed through P2P. This level actually adds the anti-censorship and anti-blocking features to Level 0. Level 1 projects are scored from 2 to 3.5 points
Level 2: On the basis of Level 1, the code is open-source and the data is stored on the devices of multiple project parties which are not related to each other (not the same major shareholder), but there is a DAO operating organization that allows which devices are accessible (with permissions). This level is also where the Alliance Chain is located. Level 2 projects are inherently unable to reward minings, which means they cannot reward the devices that provide system resources in a decentralized manner, so most of the tokens are pre-sold. Level 2 projects are scored from 4 to 5.5 points
Level 3: On the basis of Level 2, devices can be added without permissions and rewarded according to the services they provide in a decentralized manner. However, there are high-performance requirements for the devices to be accessed, where the performance refers to CPU, storage and bandwidth. Level 3 projects are scored from 6 to 7.5 points
Level 4: Compared to Level 3, there are no performance requirements for the devices accessed, and machines of different performance can receive equal rewards according to their own performance. Bitcoin/Ethereum/other Pow public chain projects belong to this level, and the score difference of this level is determined based on two conditions: Whether Asic chipfication can be inhibited, and whether the generation of large mining pools can be inhibited. If both of them are met, an additional 0.5 points can be added. Level 4 projects are scored from 8 to 10 points
Weighting Analysis of Classification
Different categories can have different weights. In Web 3.0, decentralization should be weighted a bit higher. From one perspective, it is appropriate to sacrifice part of the user experience and cost for decentralization at this stage. From another perspective, if the degree of decentralization is 0, then the project has no prospects for Web 3.0, so its competitors are not Web 3.0 applications, but other existing Web 2.0 applications, at which point it makes no sense to use the Web 3.0 maturity model for evaluation. For example, even a complete replica of Youtube’s application is called an application model of Web 3.0, it doesn’t make any sense.
The above approach is slightly different for the public chain projects, because the public chain is the decentralized transaction basis for future Web 3.0 applications. Since the performance and cost of the current public chain (Ethereum) cannot meet the needs of real applications, the current centralized public chain can be seen as a simulation of the future decentralized public chain, which can be used to evaluate: if the performance and cost problems of the public chain have been solved, what should the Web 3.0 applications look like? Therefore, if a public chain project is not decentralized, but still provides high-performance services externally with smart contracts, it still has some value.
According to the above analysis, the following conventions are made to implement the maturity model:
1. Degree of Decentralization (DD): The score ranges from 0 to 10 points
2. Service Cost (SC): The score ranges from 0 to 5 points
3. User Experience/Performance (UE): The score ranges from 0 to 5 points
Therefore, a Web 3.0 project has an overall score from 0 to 20 points, normalized on a ten-point system, and all the points are added up and divided by 2 to get the maturity degree of the Web 3.0 project, from 0 to 10 points. Project Maturity (M):
Comprehensive Scoring Scheme for Projects
A Web 3.0 project may consist of multiple technical modules. For example, a Web 3.0 streaming media application requires the use of multiple technical modules such as decentralized transaction, storage, traffic, and database, each of which can choose a different technical solution. Then, the Web 3.0 maturity module should be evaluated from each technical module. So the total maturity of this project (M):
For example, in the above streaming media application:
1. Comprehensive Scores of Decentralized Transaction Module: DD = 8, SC = 3, UE = 3
2. Comprehensive Scores of Decentralized Storage Module: DD = 8, SC = 4, UE = 2
3. Comprehensive Scores of Decentralized Traffic Module: DD = 6, SC = 4, UE = 4
4. Comprehensive Scores of Decentralized Database Module: DD = 1, SC = 5, UE = 5
5. Scores of APP User Side: DD=10, SC=5, UE=4. The reason why DD and SC are both full scores here is that the APP side does not care about the implementation detail and considers them all to be the requirements to satisfy Web 3.0. Then the total comprehensive score for this project should be:
For the project that uses only one module, it’s the effect of technical module and application used by this project. Take the famous Uniswap for example, the V1 version of Uniswap only uses Ethereum, so:
1. Comprehensive Scores of Decentralized Transaction Module: DD = 8, SC = 1, UE = 1
2. Score of APP User Side: DD=10, SC=5, UE=2
The total comprehensive score for Uniswap V1 should be
When Uniswap V3 uses Layer 2, its degree of decentralization is almost 0, but the user experience goes up, so:
1. Comprehensive Scores of Decentralized Transaction Module: DD = 1, SC = 3, UE = 4
2. Score of APP User Side: DD=10, SC=5, UE=4
The total comprehensive score for Uniswap V3 should be
So we’re seeing a decline in application maturity instead, why? It’s because Uniswap V3 adopts a Layer 2 solution, which abandons the original decentralized conditions and becomes a centralized project, while the centralized solution can implement the Uniswap functionality, or even implement far more than Uniswap’s implementations — the most typical example is an Exchange. Therefore, the ingenuity of the Uniswap system is far less significant to Web 3.0 than it was when V1 was launched. On the other hand, the launch of Uniswap V3 doesn’t bring Uniswap projects to the next level, but at best it keeps some of the clouts. In the future, Uniswap will slowly become less and less valuable than MetaMask, which is native and can perform coin exchanges across multiple chains.
This paper proposes a scheme to evaluate the maturity of any Web 3.0 application by quantifying the three dimensions of decentralization, service cost and user experience. Through this scheme, we can evaluate the maturity of different projects and plan the direction and steps of project development in view of the current situation that Web 3.0 is still in a rapid development period stage.
Gauss Aurora Lab
Gold Coast, Australia, 2022