Author: Fu Shaoqing, SatoshiLab, ThreeDAO BTC Studio

Preface Multi-level and multi-perspective

1. Three perspectives

• 1.1. Business perspective - distributed ledger

• 1.2. Abstract computing perspective - state machine

• 1.3. Technical implementation perspective - block + chain structure

• 1.4. Basic characteristics of blockchain and characteristics of three Layer2 construction structures

2. Re-examining the design and development of Bitcoin's second layer from the perspective of state machine

• 2.1. Basic knowledge of state and state machine in graph theory

• 2.2. State machine and distributed system

• 2.3. State machine and blockchain system

• 2.4. State machine and centralized system

3. What should the structure of Web3 application look like

• 3.1. Classification of common applications

• 3.2. Requirements for Web3.0 applications

• 3.3. What should the architecture that meets the large-scale application of Web3.0 look like

• 3.4. Feasible construction path

References

Reading notes:

(1) This article is a bit obscure because it involves some underlying principles of the system, and the author himself has limited theoretical and practical experience in distributed systems. General readers can directly read the conclusion, that is, the architecture of large-scale applications of web3.0 in Section 3.3.

(2) For the classification of the second-layer construction, refer to the article "Summarizes the basic knowledge system of Bitcoin Layer2 construction". According to the system structure classification in the reference article, the second layer of Bitcoin Layer 2 is divided into three types: blockchain structure, distributed system structure, and centralized system structure.

(3) Observing the second-layer construction of Bitcoin from the perspective of the state machine, it will be found that the principle of the state machine is applicable to all three system structures (blockchain system, distributed system, and centralized system), but the implementation method is limited by the structure of the system.

(4) Three observation angles: distributed ledger, state machine, block + chain structure

Preface Multi-level and multi-perspective

Observing things from multiple levels and perspective belongs to the comprehensive analysis methodology. Its advantages are reflected in several aspects: comprehensiveness, in-depth understanding, comprehensiveness, accuracy, and ease of execution. The advantages of the comprehensive analysis methodology make it have strong application value in complex and changing problems, and can provide more comprehensive, in-depth and accurate analysis results, providing strong support for solving problems and promoting development.

(1) Multi-level

Multi-level can generally be macro, meso, and micro, or it can be observed from the perspective of time cycle, short-term, medium-term, and long-term. In the development of the Bitcoin ecosystem, we observe from the short-term, medium-term, and long-term levels to obtain a more comprehensive, in-depth, and accurate understanding of the Bitcoin ecosystem.

Here I would like to borrow the summary of Professor Dashan: "The Bitcoin ecosystem is divided into three opportunities: short-term, medium-term and long-term: the short-term opportunity of the Bitcoin ecosystem is the inscription track represented by BRC-20; the medium-term opportunity is the Bitcoin Layer 2 track and the Nostr + Lightning Network track; the long-term opportunity is the off-chain solution track represented by the RGB protocol and BitVM. The four tracks included here are: the inscription track; the Layer 2 track; the Nostr plus Lightning Network track; and the off-chain track (represented by RGB and BitVM)"

—— Jademont

In Section 3.4, this article also classifies the early stage of the second-layer construction based on the chain in the Layer as a short-term opportunity. The reason is introduced in Section 3.4.

(2) Multiple perspective

At the same time, for the Bitcoin ecosystem, we observe from multiple perspective, which can bring comprehensive, objective, in-depth, flexible and innovative advantages. This multi-perspective observation helps us better understanding things, which is conducive to innovation.

We look at this from multiple perspectives, from the business perspective - distributed ledger (helps to understand the business), from the abstract computing perspective - state machine (helps to understand the implementation of blockchain + distributed system), and from the technical implementation perspective - block + chain structure (helps to understand the blockchain part of the ecosystem).

1. Three perspectives

In the Ethereum document "Ethereum EVM illustrated", it is introduced that there are three perspectives for observing the block structure of Ethereum (distributed ledger, state machine, blockchain). This observation is also applicable to Bitcoin, and is more suitable for observing the ecological architecture of Bitcoin. In the following introduction, we will have different gains from understanding from these three perspectives.

Understanding from the perspective of the state machine, it is not only easy to understand the state and state processing on the blockchain, but also easier to understand the state, state channel, and state transition in the distributed system. At the same time, combined with the structure of the distributed system, it is easy to understand the routing problem and the directed acyclic graph requirements of the state transition. The state machine is based on the underlying abstract computing principle of graph theory. Based on these principles and the specific implementation structure (blockchain, distributed, centralized), we will understand the specific problems that need to be solved and the ideas of solutions.

Secondly, from the business perspective, we will easily understand why the blockchain can process trust data and why the data on the blockchain can be used as digital currency, which makes the blockchain system more like a ledger. We will understand why the distributed system is not a ledger and needs to cooperate with the ledger. At the same time, we will understand how the distributed system handles the data and flow on the ledger in cooperation with the ledger.

From the perspective of technical implementation, we will understand that the Blockchain system is a block+chain structure, and the advantages and disadvantages of this technical structure are also easy to summarize.

For the structure of the Bitcoin ecosystem, from the perspective of the ledger and state machine, we can better understand the advantages and disadvantages of each structure, as well as how to use three optional structures to build the second layer of Bitcoin, or even how to build the entire architecture of Web3.0 applications.

When reading the Ethereum document "Ethereum EVM illustrated", I have a feeling. Observing things that can be analogized to Ethereum from three different perspectives provides us with some thinking ideas and processing experience references for solving Ethereum. For example, when Ethereum is regarded as a state-based automaton, the theory and algorithm of the state machine in the computer field can be used in Ethereum through modification. When Ethereum is regarded as a database based on the ledger, some theories in the database can be used in Ethereum-such as the idea of sharding in the database. This feeling is also applicable to the Bitcoin ecosystem, and it will be mixed in the three major system structures for use, which will be more flexible.

1.1. Business perspective - distributed ledger

From the perspective of the ledger, the blockchain is a group of transactions, just like pages of data written on the ledger.

From the perspective of the ledger, it is easy for us to understand its business capabilities, and it is also easier to understand its role in currency and finance. This is also the role of the ledger in the overall architecture of Web3.0 applications.

From the perspective of the ledger, it is also easy for us to understand the second-layer construction of the chain. The accounts of different businesses can be recorded in different ledgers, and these sub-ledgers can be aggregated to the general ledger.

From the perspective of ledger + distribution, we can understand that when a digital currency is given to the participants, how to deal with it specifically and how to divide the accounts, the participants can negotiate and deal with it by themselves, and finally record it in the ledger.

1.2. Abstract computing perspective - state machine

Here we focus on the state machine, because this perspective can well understand the blockchain system and distributed system. And we can understand the difference between the processing of data (or state) in the blockchain system and in the distributed system.

From the perspective of state, the blockchain is a transaction-based state machine. A transaction is a trigger condition that causes an original state σt to change to the next state σt+1 under the action of the transaction.

A group of transactions packaged into a blockchain is a data packet, which causes all the states associated with this group of data to change.

So from this perspective, the blockchain is a state chain (in a distributed system, it is a state channel). From the perspective of state, the blockchain system can be regarded as a state-based automaton.

From the perspective of state, we observe the blockchain + distributed system, which will make it easier to understand the rules of state transmission and change in the two systems. Both systems are actually state-based automatons.

When the blockchain is regarded as a state-based automaton, the theory and algorithm of the state machine in the computer field graph theory can be applied to the blockchain. Similarly, if the technical structure implemented is not a blockchain structure, but a distributed structure, we can also use the theory of state machines. Technologies such as finite acyclic graphs (DAGs) (to avoid double spending), state channels, and one-time seals are all needed to process states in distributed systems.

1.3. Technical implementation perspective - block + chain structure

From the perspective of technical implementation, systems such as Bitcoin and Ethereum are a blockchain. The scattered data is linked together by the data block and the hash pointer inside.

This is just a technical implementation structure to operate a system like blockchain. The data and calculations on the blockchain are all global, and only this structure can complete the function of the ledger. When connecting with external systems, it is necessary to consider the implementation details and applicability of this structure.

This block + chain technical implementation structure is easy for us to understand its characteristics and calculate performance indicators. For example, the block of the Bitcoin network is 1M (the theoretical maximum is 4M after supporting SegWit), and the number of transactions it supports can be completely calculated.

The calculation formula is: (block size/average size of transactions)/average time interval between blocks. Generally speaking, each Bitcoin block can accommodate about 2000-3000 transactions, that is, 3-7 TPS.

1.4. Basic characteristics of blockchain and characteristics of three Layer2 construction structures

Refer to the three classifications of Bitcoin's second-layer construction: blockchain structure, distributed system structure, and centralized system structure. Comparing some basic characteristics of Bitcoin's first-layer and second-layer construction, we can clearly see the differences between them. As shown in the following table. Later, we will compare the application requirements in Section 3.2 to select a suitable architecture construction combination from these basic system structures.

Through the above table, we can roughly summarize the characteristics of blockchain structure, distributed system structure, and centralized structure.

(1) Blockchain structure

The biggest advantage of blockchain structure is that it solves trust-related problems and can record the change process of data (state transition), so that data and computing rules become trusted data and trusted computing. These trusted data are either basic raw data (expressed as currency) or instruction sets for processing data (expressed as code and smart contracts).

The biggest problem with blockchain structure is poor performance. There are two reasons for this. First, the blockchain structure cannot remove some computing scenarios and processes all requests in a full computing manner. For example, partial computing and global computing, local data and global data, temporary data and permanent data. Second, the blockchain structure has a clear performance ceiling. If the second-layer expansion is performed through the chain, the number of transactions supported is also limited. A simple calculation is as follows:

The upper limit of a blockchain system is the maximum number of transactions that a single block can accommodate. The upper limit of a multi-level blockchain is the sum of the number of transactions in each layer of the block capacity. For example, the first layer of Bitcoin has 7 TPS per second, and the processing capacity of a second layer chain is 100 TPS. If there are 10 such second layers, then the structure combined together is 1000 TPS. (There was a calculation error in the early article, which was calculated by product.)

In order to expand the performance of the blockchain structure, multi-layer construction is required and it needs to be used in combination with heterogeneous systems. For the work that must be completed in the blockchain system, only the data that needs to be saved and calculated globally needs to be recorded. Other non-global data can be assigned to other layers for processing, so that the processed data and code are only related to the relevant parties as much as possible.

From the above table, only the blockchain structure can realize the trustless ledger function, so if a system wants to realize the trustless ledger function, it must include the blockchain system. However, the performance requirements of large-scale applications require the blockchain system to be combined with other systems to meet the requirements.

(2) Distributed system

In the above table, we can see the obvious advantages of distributed systems: decentralization, performance, and scalability are all excellent, but the function implementation is relatively complex. In addition, distributed systems do not have the ability of the trustless ledger.

So if it is possible to use a distributed system in the second-layer construction based on the first-layer ledger function of Bitcoin, theoretically, it is possible to maintain the basic characteristics of the blockchain while achieving unlimited performance expansion. The case in this regard is represented by Bitcoin + Lightning Network. The performance of this combination is Bitcoin's 7TPS * ∞.

The reason for achieving Turing completeness in a distributed system is that the cost of recording and running smart contracts in a blockchain system is very high because it is global data and global code. Therefore, smart contracts are also suitable for layered theory, limiting the code storage and execution of smart contracts to participants. This is also the scenario generated by client verification in a distributed system. Only trusted data (status, one-time sealing) between stakeholders is required to participate in the calculation, and Turing complete calculations are only performed locally. This is often referred to as the consensus of the entire network and the consensus of participants in a distributed system.

The biggest difficulty in building the second layer with a distributed system structure is that the technical implementation is relatively complex. Networks that simply solve payment problems, such as the Lightning Network, have developed slowly and have many imperfections. If Turing complete calculations are implemented on a distributed system, it will be even more challenging. The slow development and slow version update of RGB is a reference case.

The biggest cost of solving complexity is the high threshold for security issues and development. To implement Turing complete smart contract functions on a distributed system, not only the development cycle of the underlying platform is long and difficult, but also there are often contract code vulnerabilities and continuous hacker attacks.

(3) Centralized system

In the table above, we can see that the advantage of centralized systems is that the engineering implementation is relatively simple, which is due to the simple internal logic control and simple calculation. Similarly, centralized systems do not have the ability of the trustless ledger. The advantages of centralized systems are not prominent. If it is to process small-scale data, or to process temporary data and temporary calculations, it will be relatively suitable.

The second-layer construction of centralized systems can be used as a supplement or transitional solution to the other two methods.

(4) Comprehensive analysis

In the era of value, through the above content, we can see that it is difficult to achieve the effect of meeting the needs by relying on a single system. This is also a practical demand for the development of the second layer of the Bitcoin ecosystem. However, how to combine these three systems requires a lot of exploration. Let us first analyze it theoretically. In the face of different needs, there will be different combination structures.

First of all, from the design idea of protocol layering, the Bitcoin network does not need Turing completeness. It is a global trust machine that only needs to save these data that require global trust and the trajectory of data changes. According to this most basic requirement, the instruction set of Bitcoin can be reduced to a minimum. Other functions are left to the upper layer to complete. In addition to meeting the functional requirements of this layer, the connection technology between the first layer of Bitcoin and the upper layer network needs to be further developed and improved. Moreover, this connection technology, under the premise of meeting the functions, occupies as little data space as possible on Bitcoin.

General small applications can be completed on a single blockchain. Slightly larger systems are suitable for completion on the second layer of blockchain + blockchain. But for large-scale applications, the preferred solution is to use blockchain system + distributed system. From a performance perspective, the upper limit of distributed systems is theoretically infinite, so such a combination is Bitcoin's 7TPS * ∞. In engineering implementation, it will also be limited by some specific factors. Usually, the upper limit of such a system is limited by the routing capability of the distributed system, the processing capability of the directed acyclic graph of state changes, and other specific technical implementation links. Later, in the typical application architecture of Web3.0, you can also see a combination diagram of multiple systems.

Through the combination of multiple system structures, the limitations of the basic theory of a single system can be broken. For example, the blockchain system is limited by the limitations of the DSS impossible triangle, but if the blockchain system + distributed system is used, the impossible triangle of decentralization D, security S, and scalability S can be solved. Other combinations, blockchain + centralized system, can also solve the scalability problem to a certain extent. Distributed system + centralized system can solve the limitation of CAP triangle in distributed system.

In the history of technology development, there are also some cases of combined use. For example, when the centralized database is limited in capacity, it adopts master-slave structure, then divides the database into sub-tables, and then distributes the database, which is a case of using centralized system and distributed system.

This combination also reflects a philosophical idea: the solution to a problem cannot be answered at the level where the problem arises, but it can be solved at a higher level. It is not particularly easy to understand this sentence clearly. I think of a metaphor in "Zen and the Art of Motorcycle Maintenance": We cannot lift ourselves up by pulling our hair. This tells us that we cannot rely on the system itself to solve our own problems, and we must rely on external systems to solve them.

2. Re-examining the design and development of Bitcoin's second layer from the perspective of state machine

State and state machine exist in all three types of two-layer construction, but the names are slightly different, so most people don't pay attention to this observation perspective.

If we look at it from the perspective of state and state machine, the three two-layer structures are all state machines that process state, but the principles are slightly different. When these three systems are used in combination, it is necessary to ensure that the concept of "state" is consistent in the three systems, and the state machine of each system can handle state changes, but cannot destroy the consistency of the state.

From the perspective of state machine, the application architecture of Bitcoin ecology or Web3.0 is to complete the processing of state transformation with the help of these systems, thereby completing the processing of business logic.

Using this idea of state machine, we look at the construction of Bitcoin's two-layer network again, and we can see that each layer of the architecture has a division of labor suitable for its characteristics.

2.1. Basic knowledge of state and state machine in graph theory

In graph theory, the basic knowledge of state and state machine includes the following:

State: A state refers to a node or vertex in graph theory. In a directed graph, a state can be represented as a node; in an undirected graph, a state can be represented as a vertex.

State Transition: A state transition refers to the process from one state to another. In a directed graph, a state transition can be represented as a directed edge; in an undirected graph, a state transition can be represented as an undirected edge.

State Machine: A state machine is an abstract computational model used to describe a series of states and transition rules between states. A state machine consists of a state set, an initial state, a transition function, and a terminal state.

Directed Graph: A directed graph is a graph structure consisting of vertices and directed edges, where a directed edge points from one vertex to another, indicating the transition relationship between states.

Undirected Graph: An undirected graph is a graph structure consisting of vertices and undirected edges, where an undirected edge connects two vertices, indicating the association relationship between states.

Topological Sorting: Topological sorting refers to the linear sorting of the vertices of a directed acyclic graph (DAG), so that for any two vertices u and v, if there is an edge (u, v), then u appears before v in the sorting.

Directed Acyclic Graph (DAG): A directed acyclic graph is a directed graph in which there is no cycle that can return to a vertex after passing through several edges.

Shortest Path: The shortest path refers to the path in the graph that connects two vertices with the smallest sum of edge weights.

Minimum Spanning Tree: The minimum spanning tree refers to finding a tree containing all vertices in a connected graph so that the sum of the weights of the edges of the tree is the smallest.

These basics are the core concepts in graph theory, which are used to describe and analyze the relationship and transition rules between states. Related knowledge and graphics can be learned in depth in professional books.

Although it seems that this knowledge is a bit abstract and boring, it is easy to understand if we convert this knowledge into some frequently encountered blockchain concepts. For example, some scenarios require a directed acyclic graph to avoid the problem of double spending; one-time encapsulation is to transform the state in the blockchain into the state in the distributed system; the routing algorithm is the calculation to find the shortest path in the distributed system; the route with the lowest payment cost in the lightning network is the minimum spanning tree problem; client verification can also be seen as a form of state machine.

2.2. State machine and distributed system

Here we use several distributed networks to introduce:

(1) Lightning Network

In the Lightning Network, the knowledge points that can reflect the state and state machine are:

The Lightning Network is a second-layer solution for Bitcoin based on state channel technology. The payment channel in the Lightning Network is a two-way state channel. Participants can conduct multiple transactions in the channel and achieve fast and low-cost payments by updating the channel state.

The transactions (i.e., states) in the Lightning Network are implemented based on Hash Time Lock Contracts (HTLCs). Participants can use this contract to lock funds (to achieve state transfer between Bitcoin and the Lightning Network) and conduct secure transactions in the channel (simple state processing).

Routing in the Lightning Network: In order to achieve cross-channel payments, the Lightning Network uses a mechanism called routing, where participants can make payments by finding a trusted path.

Relay nodes in the Lightning Network: Relay nodes refer to nodes that can forward payment requests. They can help achieve cross-channel payments.

Bidirectional payments in the Lightning Network: The Lightning Network allows participants to make bidirectional payments in the payment channel, that is, they can not only pay to each other, but also accept payments from each other.

Payment privacy of the Lightning Network: Since transactions in the Lightning Network are conducted within the channel, it is not necessary to write all transactions into the blockchain, thus improving the privacy of payments.

Limitations of the Lightning Network (mostly limitations of state and state machine implementation technology): The Lightning Network still has some limitations, such as channel viability, fund lock time, etc. These limitations need to be considered comprehensively to design a suitable payment channel.

(2) In RGB, the knowledge points related to state, state machine, and state channel are:

RGB is based on LNP and BP protocol. There is a discussion about whether RGB is a second-layer or a third-layer. If RGB is directly calculated based on BP, it directly expands the Turing complete function of Bitcoin and belongs to the second layer. This method has limited performance expansion. If RGB is calculated based on LNP, it belongs to the third layer (because LNP is the second layer of Bitcoin). This method can expand both performance and Turing complete computing power, but it has a certain complexity in technical implementation. Usually, a combination of methods can expand computing power, performance, and reduce implementation complexity.

RGB is based on the state channel technology in Bitcoin or the Lightning Network. The state channel in RGB refers to a communication channel between two or more parties built on LNP and BP, which can perform multiple transactions and status updates within the channel, reducing the number of transactions and fees on the blockchain.

The state channel in RGB uses a Bitcoin-based multi-signature script to lock funds and uses a special transaction type to update the state of the channel.

The state channel in RGB can be applied to various scenarios, such as payment channels, decentralized exchanges, asset issuance, etc., to improve transaction efficiency and user experience.

The state channel in RGB realizes payment and asset transfer by updating the channel state. Transactions within the channel do not need to be written to the blockchain, only the final state will be written to the blockchain.

The state channel in RGB can also realize more complex functions, such as atomic swaps, payment routing, etc., through smart contracts and multi-signature scripts.

The state channel in RGB can be used in combination with other technologies and protocols, such as Lightning Network, LNURL, etc., to provide richer functions and better user experience.

The design and implementation of the state channel in RGB needs to consider factors such as security, privacy, and scalability to ensure the reliability and availability of the system.

(3) In Nostr, concepts related to state, state machine, and state channel.

In Nostr, because what is transmitted is information, the concepts of state (trusted data, digital currency) and state machine are not yet embodied. However, it is believed that if the distributed structure of Nostr is slightly modified and the processing of state is added, a system similar to the Lightning Network will be formed. Such a system can not only transmit information but also deliver value. The application architecture diagram of Web3.0 in Section 3.3 also describes the possibility of this information-based distributed system gradually transforming into a distributed system that includes value processing.

A brief introduction to the current Nostr: There are two main components in Nostr, the client and the relay. Each user runs a client and communicates with others through the relay. Each user is identified by a public key. Each post published by the user has a signature. Each client verifies these signatures. Clients obtain data from the relay of their choice and publish data to the relay of their choice. Relays do not communicate with each other, but only communicate directly with users.

(4) In distributed systems, the knowledge points related to state machines are:

State machine model: A state machine is a mathematical model used to describe the transition and behavior of a system between different states. In distributed systems, state machine models are often used to describe the behavior and state changes of a system.

Finite state machine (FSM): Finite state machine is the most basic state machine model, which contains a set of finite states and a set of transition rules between states. In distributed systems, finite state machines can describe various states of the system and transitions between states.

State transition: State transition refers to the process of a system moving from one state to another. In distributed systems, state transitions may be triggered by various events or conditions, such as receiving a message, timeout, etc.

Behavior of state machine: State machines can define different behaviors in different states. In distributed systems, the behavior of state machines can include processing messages, performing operations, sending messages, etc.

State consistency: In a distributed system, multiple nodes may have different states. State consistency refers to keeping the states of various nodes in the system coordinated and consistent with each other.

Distributed state machine (DSM): Distributed state machine refers to a technology that applies the state machine model to distributed systems. It can distribute the state and state transitions of the system on multiple nodes and ensure the state consistency between nodes.

Atomic state machine (ASM): Atomic state machine refers to a state machine that maintains atomicity during state transitions. In distributed systems, atomic state machines can ensure the consistency and reliability of the system during state transitions.

Consistency protocol: A consistency protocol is a protocol used to ensure state consistency in a distributed system. Common consistency protocols include Paxos, Raft, ZAB, etc.

Fault tolerance: A distributed state machine needs to be fault-tolerant, that is, the system can still maintain the correct state and behavior in the event of node failure or message loss.

Scalability: A distributed state machine needs to be scalable, that is, it can maintain efficient state transitions and consistency when the system scales up.

2.3. State machine and blockchain system

According to Ethereum's document "Ethereum EVM illustrated", each block is a set of triggered states, and the entire Ethereum system is a state processor. In 1.2, we introduced the state machine content in the blockchain system. There are also many descriptions of state machines in the Ethereum white paper.

Although the state machine has strong processing capabilities, the upper limit is the ceiling of the blockchain structure.

For the interconnected combination application of blockchains based on the UTXO model and the account model (like EVM), the implementation methods of the state and the state machine are quite different. The blockchain based on the UTXO model is easier to combine with the distributed system because the states in the two systems are based on UTXO, there is no conversion or only a simple conversion is required, which is easier to implement. The chain based on the account model needs further encapsulation and conversion between its state and the state of the external distributed system, and the implementation is complex, which is also part of the reason why the development of the Raiden Network on Ethereum is not smooth.

2.4. State machine and centralized system

Examples of using blockchain + centralized systems include Ordinals and centralized exchanges CEX.

Such systems are relatively simple, and some do not have state transfer at all, such as Ordinals, which only use centralized indexes to complete statistical work.

Like centralized exchanges, the state transfer is completely dependent on the rules set by the centralized system, and the state machine inside is also a state processor composed of centralized system programs, without complex concepts. In a centralized system, the changes in the state machine are almost not limited by the system organization.

In the future application of Web3.0, there should be more cases of using blockchain + centralized systems.

3. What should the structure of Web3 application look like

From the previous content of the article, we know that a more complex structural design can be completed through the combination of three Bitcoin second-layer architectures, thereby obtaining the required feature requirements. And from a business perspective, if the underlying logic of the application can be decomposed into states and state machines, the combination of the three systems can be used to complete the entire business logic of the upper layer.

So what are these common combinations? What factors will determine the structure of the combination? We speculate on the structure of large-scale applications that meet Web3.0 from common application classifications and application requirements.

3.1. Classification of common applications

We use the application statistics in the 48th "Statistical Report on the Development of China's Internet" as a reference, hereinafter referred to as the statistical report. Because Web2.0 has matured and does not affect the analysis of application classification and user scale, the application reference data we use is the old data of 2020 and 2021. One thing to note is that this is only the statistical data of China's Internet. In the Web3.0 stage, many applications are global, and the scale and performance requirements of users are higher.

In the statistical report, it can be seen that the applications in Web2.0 are already very rich and have a huge user base. These applications include: instant messaging, online video, short video, online payment, online shopping, search engines, online news, online music, online live broadcast, online games, online food delivery, online literature, online car-hailing, online office, online travel reservation, online education, online medical care,..., almost covering all areas of people's lives. In addition to these consumer Internet contents, there are also many applications in the industrial Internet.

If all Web2.0 applications are migrated to Web3.0, most of them will have very high performance requirements. Taking Visa payment as an example, the performance requirement during peak hours is: 65,000 TPS. Such performance indicators can only be supported by distributed systems. For example, the current Lightning Network has a performance of 40 million transactions per second, and the performance of the Lightning Network has no theoretical upper limit.

In addition, taking common games as an example, the current full-chain game with the highest TPS on the blockchain can achieve a peak of around several thousand TPS, which is a huge gap from the traditional Web2 3A games with hundreds of thousands of TPS. If all games are to be migrated to Web3.0, the required infrastructure performance will be a big challenge.

Moreover, games are just one type of application in the common application classification, and other applications have more performance and specific requirements.

3.2. Requirements for Web3.0 applications

To understand the needs of applications, it is more direct to use the indicator of revenue structure. We refer to the report "Token Terminal, curated by FutureMoney Research 2022 Q2". Although this report is a little early, applications such as payment and other applications are still in the early stages and do not affect the main analysis results. So the author was lazy here and used the data when I wrote the Web3.0 book. If there were data from Q4 2023, it would be more accurate.

(1) Demand analysis through revenue report

The revenue classification in the report better represents the current core product composition of Web3.0. As shown in the figure.

• 1）Layer1 (the basic main chain in the blockchain) has a revenue of 48%, accounting for nearly half of the total revenue, and its business model can be understood as "selling block space";

• 2）NFT trading platform revenue accounts for 22%, and its business model can be understood as royalty commission or marketing activity monetization;

• 3）Dex revenue in DeFi accounts for 15%, and its business model is transaction fees and liquidity market making income;

• 4）Staking revenue in DeFi accounts for 8%, and its business model is asset management commission or interest rate spread;

• 5）Gamefi accounts for 5%, and its business model is royalty commission, transfer fee, sales of NFT, etc.;

• 6）Lending revenue in DeFi accounts for about 1%, and its business model is interest rate spread;

• 7）Tooling revenue accounts for about 1%, and its business model is service fee, which will also include traffic monetization fee in the future;

Other industries related to Web3.0 are not Web3.0 applications, are not considered as core industries of Web3.0, and are not included. For example: Web3.0 media, research organizations, training organizations, etc.

From the income structure, we can see that the current application needs of the BTC ecosystem can basically be solved by blockchain and its second-layer system, and there is no need for a complex system architecture. However, Gamefi and SocialFi are developing rapidly. Using the game examples in the references, we can see that large-scale games have already had higher and clearer requirements for system structure.

From the income structure, we can see the current application needs of the BTC ecosystem. It is worth redoing all the products in the Ethereum ecosystem. By slightly modifying the chain-based second-layer construction technology in the Ethereum ecosystem and building a new second layer on Bitcoin, these primary needs can be met relatively well, but there are certain compromises in the degree of decentralization, security, privacy, and anti-censorship. In "Summarizes the basic knowledge system of Bitcoin Layer2 construction", the new EVM-based second-layer construction is an example of this situation.

(2) Analysis of game cases for applications with high performance requirements

In the article "The Impossible Becomes Possible: Making Full-Chain Game Development on the Lightning Network a Reality", great requirements are put forward for both functions and performance. The true architecture of Web3.0 applications is gradually emerging.

Problem description in the article: On the basis of ensuring security, privacy and decentralization, the full-chain game has never found the optimal solution for scalability. For example, the most popular full-chain game engines Mud and Dojo are committed to helping full-chain games achieve higher TPS, but players still need more than 2 seconds of buffering for each operation. In fact, the full-chain game with the highest TPS on the current blockchain can achieve a peak of about several thousand TPS, which is a huge gap from the traditional Web2 3A games with hundreds of thousands of TPS. Under the premise of pursuing the advantages of blockchain without losing them, the full-chain game can overcome the scalability.

In the solution discussed in the following technology, the lightning network and RGB are used to expand performance, and the concepts of temporary chains and dedicated chains are also proposed.

Ephemeral chain

Temporary blockchains can be defined as blockchains that will not exist forever. Once the purpose of the blockchain is achieved (such as recording transactions), or once its state is permanently stored elsewhere, they will be destroyed. The termination state stored by the temporary chain is only data about the termination facts related to the temporary chain, so everything is compressed by a considerable order of magnitude. Temporary chains are mainly limited by transaction latency and throughput on the blockchain.

Temporary chain VS state channel

In the case of temporary chains, we will eventually have a large number of users because of the state on the public chain. The state that needs to be inserted into the public chain is reduced in size through pruning/compression/difference extraction, and then saved on the public chain regularly rather than irregularly. The setting of RGB state channels has the potential to bypass the performance constraints of temporary chains and achieve the same functions as temporary chains.

App-specific blockchains

Application-specific blockchains are blockchains created to run a single decentralized application (dapp). Instead of building on an existing blockchain, developers build a new blockchain from scratch using a custom virtual machine (VM) that executes transactions for users to interact with the application. Developers can also customize different elements of the blockchain network stack - consensus, network, and execution - to meet specific design requirements. Improving the execution speed of smart contracts and solving computing resource limitations can help specific application blockchains land. Allowing developers to customize infrastructure for different use cases makes development easier. At the same time, it allows web3 developers to build powerful value models and expand their dapps to meet exponential growth needs, stimulating more innovation.

Through this game case, combined with our analysis of several previous architectures, we can roughly determine the architecture of future large-scale applications.

3.3. What should the architecture that meets the large-scale application of Web3.0 look like

In the previous content, we learned about the common application classifications in Web2.0. The upgrade of these applications to Web3.0 is the sign of entering the Web3.0 era. What kind of architecture can meet the above many applications?

(1) The difference between the simple Web2.0 and Web3.0 architectures

Web2.0 application architecture and early Web3.0 architecture

Here is a reference to the article "The Architecture of a Web 3.0 application" written by blockchain goddess Preethi Kasireddy. The structural description of Web3.0 applications here is a very simple structure that only relies on the blockchain system to complete. However, this structure is too simple and does not reflect the second-layer construction. It is not competent in large-scale applications.

Comparing the differences between the technical implementation of traditional centralized products and the technical implementation cases of Web3.0 products will make it easier to understand the differences between the two in technical implementation. Combined with Gavin Wood's description of the vision of the Web3.0 technology stack, we can see that the biggest difference in the technical implementation of Web3.0 is in the background, and the difference in the user experience layer is relatively small.

(2) System architecture of large-scale applications in the Web3.0

In the era without blockchain, applications were built on centralized systems and distributed systems. For example, shopping malls, IM, video and other applications built on centralized systems, and Thunder download built on distributed systems.

After the blockchain system, we entered the Web3.0 era. The applications of this period are a complex architecture built on blockchain systems, distributed systems and centralized systems. Among them, the blockchain system and its second-layer extension complete the transmission and processing of value, and the distributed system and centralized system complete the transmission and processing of information.

As shown in the figure below,

The specific content is described as follows:

(1) The Bitcoin main network and the second-layer construction are the center of all values, and most of the value is built on this network.

• In the construction of Bitcoin's second-layer, the second-layer based on the chain completes the performance expansion and processing of value, and processes the full amount of ledger data.

• In the construction of Bitcoin's second-layer, the second-layer construction based on the distributed system completes the performance expansion, and processes local related data, using the consensus of stakeholders, but the final calculation results need to be implemented in the blockchain system.

• In the construction of Bitcoin's second layer, the second layer construction based on the centralized system directly provides services for upper-layer applications.

(2) RGB-like systems will also need some temporary chains or intermediate chains to complete the settlement function of the ledger, as shown by the blue line in the figure. The game case in Reference 1 describes this scenario. It has not yet appeared on a large scale because the construction of RGB-like systems is complex and has not yet reached maturity.

(3) In addition to the Bitcoin ecosystem, there are other blockchain system ecosystems that meet the needs of different business scenarios. As described in our article on the second-layer infrastructure, there will be many projects based on the second layer of the chain, and the same is true for chains that are not in the Bitcoin ecosystem. Other blockchain systems and the second layer can also enter the lightning network and RGB. This situation will gradually appear as the technology matures.

(4) In the Web3.0 ecosystem, centralized systems will also have a place, but it will no longer be as large as in Web2.0. Centralized systems have many advantages.

(5) In actual applications, the internal connections in the above figure will become more complicated. Some do not need to use the second layer, but directly operate on the first layer network, such as when RGB uses the BP protocol. Other blockchains may also use distributed systems, such as the Raiden Network on Ethereum. Although it is immature, if there is a demand scenario, it will also have a usage scenario by modifying some basic features. The above figure is a simplified description of the Web3.0 application architecture.

3.4. Feasible construction path

From the income structure, we can see the current application demand of the BTC ecosystem. From the classification of commonly used applications, we can see the demand for full entry into Web3.0 in the future. This will be a long road. Therefore, for things with a relatively long construction cycle, they need to be handled in stages.

The three stages here are very similar to what Professor Dashan said about short-term, medium-term, and long-term. It’s just that the simple stage of the second-layer construction based on the chain is also included in the first stage of construction.

(1) The first stage is the early stage of the second-layer construction based on inscriptions and chains

Since the second-layer construction based on inscriptions and chains is relatively easy, many applications have emerged. Whether it is brc20, src20, arc20, inscriptions and other applications, or those second-layer construction projects based on chains, they are very rich.

This stage of construction is relatively simple, most of them are financial applications, and with the experience of transforming and imitating the second layer of Ethereum, it is easier and faster. Although it is relatively simple, this process is indispensable and very important. They help prosper the ecosystem, attract traffic and funds, test cross-chain connection technology, test stablecoins, and test various possibilities.

This stage is mainly to complete various verifications of functional feasibility.

(2) The second stage is the mid-to-late stage of chain-based second-layer construction and the second-layer construction based on distributed systems

In this stage, the second-layer construction based on the chain is also involved, which is the advanced stage of chain-based construction. In addition, the second stage focuses on testing and improving various distributed second-layer constructions. The Lightning Network will become more mature, the RGB function and stability will be greatly improved, and the application scenarios will be richer. RGB-like competitors will gradually emerge and mature, such as BitVM. At the same time, distributed systems such as Nostr will also incorporate value functions.

This stage is mainly to complete various verifications of functional and performance feasibility.

(3) Large-scale construction based on the Bitcoin ecosystem

The last stage is the mature stage. In this stage, Web3.0 begins to be built in large quantities and gradually matures. The common applications described in 3.1 are beginning to enter the Web3.0 era.

Perhaps this stage will take a long time to arrive, or perhaps there will be an inflection point event that can drive a large number of Web2.0 users to enter, and the time may not be so long.

No matter what, when the real Web3.0 era comes, it will be very different, with greater functions and output value than the current PC Internet + mobile Internet. It may be like the emergence of Sora in the AI field, which is very amazing and shocking, but the process is not so sudden.

References

(1) Reference was made to Professor Dashan’s articles and course content on the short-term, medium-term and long-term development of the Bitcoin ecosystem.

(2) “Impossible becomes possible: making full-chain game development on the Lightning Network a reality”

(3) The three observation perspective mainly refer to “Ethereum EVM illustrated”, Takenobu T., 2018.3

(4) Preethi Kasireddy. The Architecture of a Web 3.0 application.

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

(5) For content related to application classification, the author mainly refers to “Web3.0: Building the Digital Future of the Metaverse” written in 2022.

(6) Reference was made to the graph theory knowledge in university digital logic.

(7) Reference was made to the content of some articles on distributed systems.