Observing Bitcoin Layer 2 from the perspective of the state machine, what does the architecture of large-scale Web3 applications look like?

Original author: Fu Shaoqing, SatoshiLab, Bihelix, Wanwudao BTC Studio

Read the comments:

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

(2) For the classification of the second layer construction, please refer to the article “A Basic Knowledge System for Bitcoin Second Layer (Layer 2) Construction”. According to the system structure classification in the reference article, 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 can be found that the principle of the state machine is applicable to the three system structures (blockchain system, distributed system, and centralized system), but the implementation method is limited by the structure of the system.

(4) Three perspectives: distributed ledger, state machine, and block + chain structure

Preface Multi-level and multi-angle

Observing things from multiple levels and angles 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 changeable problems, and can provide more comprehensive, in-depth and accurate analysis results, providing strong support for solving problems and promoting development.

(1) Multi-level

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

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 plus Lightning Network track; the long-term opportunity is the off-chain solution track represented by the RGB protocol and BitVM. The four tracks included are the inscription track; the Layer 2 track; the Nostr plus Lightning Network track; and the off-chain track (represented by RGB and BitVM).”

In Section 3.4, this article also classifies the early stages of chain-based second-layer construction in Layer as short-term opportunities. The reasons are introduced in Section 3.4.

(2) Multiple angles

At the same time, we observe the Bitcoin ecosystem from multiple angles, which can bring comprehensive, objective, in-depth, flexible and innovative advantages. This multi-angle observation helps us better understand things and 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 viewing angles

In the Ethereum document “Ethereum EVM illustrated”, it is introduced that there are three perspectives on 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 understand from these three perspectives and gain different results.

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

Secondly, from the business perspective, we can easily understand why blockchain can process trust data and why data on blockchain can be used as digital currency, which makes the blockchain system more like a ledger. We can understand why distributed systems are not ledgers and need to cooperate with ledgers. At the same time, we can understand how distributed systems handle data and flows on ledgers in cooperation with ledgers.

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

Regarding the structure of the Bitcoin ecosystem, from the perspective of 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 had a feeling. Observing things that can be compared to Ethereum from three different perspectives provides us with some thinking ideas and experience references for solving Ethereum. For example, when Ethereum is regarded as a state-based automaton, the theory and algorithm of state machines in the computer field can be used in Ethereum through modification. When Ethereum is regarded as a database based on ledgers, 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 in a ledger.

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

From the perspective of the ledger, it is 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 summarized into the general ledger.

From the perspective of ledger + distribution, we can understand that when a sum of digital currency is given to the participants, the participants can negotiate on how to handle it and how to divide the accounts, and then record it in the ledger.

1.2. Abstract computing perspective - state machine

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

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

A set of transactions is packaged into a blockchain, which is a data packet that causes all states associated with this set 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 seen as a state-based automaton.

When we observe blockchain + distributed systems from the perspective of state, it will be easier for us to understand the rules of state transmission and change in the two systems. In fact, both systems are state-based automata.

When the blockchain is viewed as a state-based automaton, the theory and algorithm of state machines in computer graph theory can be applied to the blockchain. Similarly, if the technical structure to be 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 technologies that need to be used 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, in which scattered data is linked together by data blocks and hash pointers 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, the implementation details and applicability of this structure need to be considered.

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

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

1.4. Basic characteristics of blockchain and features of three Layer 2 construction structures

Refer to the three classifications of Bitcoin’s second-layer construction: blockchain structure, distributed system structure, and centralized system structure. By 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 help us 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 benefit of the blockchain structure is that it solves trust-related issues and can record the data change process (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 the blockchain structure is poor performance. There are two reasons for this. First, the blockchain structure cannot remove some of the scenarios in which calculations are performed. All requests are processed in a full-volume calculation manner. For example, partial calculations and global calculations, 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 the blockchain system is the maximum number of transactions that a single block can accommodate. The upper limit of a multi-level blockchain is the product of the number of transactions per block. For example, if the first layer of Bitcoin has 7 TPS per second and the processing capacity of a second layer chain is 100 TPS, then the combination of these two structures is 700 TPS.

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, and 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 that the blockchain system must be combined with other systems to meet the needs.

(2) Distributed Systems

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

Therefore, if we can use a distributed system in the second-layer construction based on the first-layer ledger function of Bitcoin, theoretically, we can achieve unlimited performance expansion while maintaining the basic characteristics of the blockchain. Bitcoin + Lightning Network is a representative example of this. The performance of this combination is Bitcoin’s 7 TPS * ∞.

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 the layered theory, which limits the code storage and execution of smart contracts to participants. This is also the scenario generated by client verification in a distributed system. Only the trusted data (state, one-time seal) between the stakeholders is required to participate in the calculation, and Turing complete calculations are only performed locally. This is what is often called 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 security issues and development threshold. Implementing Turing-complete smart contract functions on distributed systems not only takes a long development cycle and is difficult for the underlying platform, but also often leads to contract code vulnerabilities and continuous hacker attacks.

(3) Centralized system

In the table above, we can see that the advantage of a centralized system is that the engineering implementation is relatively simple, which is due to the simple internal logic control and simple calculation. Similarly, a centralized system does not have the ability to trust the ledger. The advantages of a centralized system are not prominent, and it is relatively suitable for processing small-scale data, or processing temporary data and temporary calculations.

The second-layer construction of the centralized system can serve 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 meet the needs of 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’s first analyze it theoretically. In the face of different needs, there will be different combination structures.

First of all, from the perspective of the design concept of protocol layering, the Bitcoin network does not need to be Turing complete. It is a global trust machine that only needs to save data that requires global trust and the track of data changes. According to this most basic requirement, the instruction set of Bitcoin can be reduced to a minimum. Other functions are completed by the upper-layer extension. In addition to meeting the functional requirements of this layer, the connection technology between the Bitcoin layer and the upper-layer network needs to be further developed and improved. Moreover, this connection technology, while meeting the functional requirements, should occupy as little Bitcoin data space as possible.

For general small applications, only a single blockchain is needed. Slightly larger systems are suitable for blockchain + blockchain layer 2 construction. However, for large-scale applications, the preferred solution is to use blockchain system + distributed system. From a performance perspective, the upper limit of a distributed system is theoretically infinite, so such a combination is Bitcoin’s 7 TPS * ∞. 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 through. For example, the blockchain system is limited by 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 limitations of the CAP triangle in the distributed system.

In the history of technological development, there are also some cases of combined use. For example, when the centralized database is limited in capacity, it adopts a master-slave structure, then a separate database and table, and then a distributed database. This is an example of using a centralized system and a distributed system.

This combination also reflects a philosophical thought: **The solution to a problem cannot be found at the level where the problem is created, but it can be solved at a higher level. **It is not particularly easy to understand this sentence clearly. I think of a particularly good metaphor in “Zen and the Art of Motorcycle Maintenance”: We cannot lift ourselves up by 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 the state machine

States and state machines exist in all three types of two-layer construction, but the names are slightly different, which makes most people not pay attention to this observation angle.

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 that the state machine of each system can handle state changes without destroying the consistency of the state.

From the perspective of the state machine, the Bitcoin ecosystem or the application architecture of Web3.0 relies on a combination of these systems to complete the processing of state changes and thus complete the processing of business logic.

Using the idea of state machine, we look at the construction of Bitcoin’s second-layer network and see that each layer of the architecture has a division of labor that suits its characteristics.

2.1. Basic knowledge of states and state machines in graph theory

In graph theory, the basics of states and state machines include 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: State transition refers to the process from one state to another. In a directed graph, state transition can be represented as a directed edge; in an undirected graph, state transition can be represented as an undirected edge.

State Machine: A state machine is an abstract computing model that describes a series of states and the 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 transfer 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 and represents the association relationship between states.

Topological Sorting: Topological sorting refers to the linear ordering 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 sort.

Directed Acyclic Graph (DAG): A directed acyclic graph is a directed graph in which there is no cycle that starts from a vertex and returns to the vertex after passing through a certain number of edges.

Shortest Path: The shortest path is the path connecting two vertices in a graph with the smallest sum of edge weights.

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

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

Although this knowledge seems a bit abstract and boring, it is easy to understand if we convert it into some commonly encountered blockchain concepts. For example, some scenarios require directed acyclic graphs 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 Systems

Here we use several distributed networks to introduce:

(1) In the 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 within the channel and achieve fast and low-cost payments by updating the channel status.

Transactions (i.e., states) in the Lightning Network are implemented through Hash-based Time Lock Contracts (HTLCs), through which participants can lock funds (to achieve state transfer between the Bitcoin and Lightning Network systems) and conduct secure transactions within the channel (simple state processing).

Routing in Lightning Network: To enable cross-channel payments, 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 are nodes that can forward payment requests. They can help realize cross-channel payments.

Two-way payment of Lightning Network: Lightning Network allows participants to make two-way 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 on the Lightning Network are conducted within the channel, there is no need to write all transactions to 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 survivability, fund lock-up 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 protocols. 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 degree of complexity in technical implementation. Usually, a combination of methods can expand computing power, performance, and reduce the complexity of implementation.

RGB is based on the state channel technology in Bitcoin or 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 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., improving transaction efficiency and user experience.

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

The state channels in RGB can also implement 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 state channels in RGB need 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 with a slight modification of the distributed structure of Nostr and the addition of state processing, a system similar to the Lightning Network will be formed, which can transmit information and deliver value. The possibility of this information-based distributed system gradually transforming into a distributed system that includes value processing is also described in the application architecture diagram of Web3.0 in Section 3.3.

A brief introduction to Nostr today: There are two main components in Nostr, clients and relays. Each user runs a client and communicates with others through relays. Each user is identified by a public key. Each post made by a user is signed. Each client verifies these signatures. Clients get data from and post data to relays of their choice. Relays do not communicate with each other, only 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): A finite state machine is a basic state machine model that contains a finite set of states and a set of transition rules between states. In a distributed system, a finite state machine can describe the various states of the system and the transitions between states.

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

Behavior of the state machine: The state machine can define different behaviors in different states. In a distributed system, the behavior of the state machine 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 each node in the system coordinated and consistent.

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 transition of the system across 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 transition. In a distributed system, atomic state machine can ensure the consistency and reliability of the system during state transition.

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

Fault tolerance: Distributed state machines need 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: Distributed state machines need to be scalable, that is, they need to be able to 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 trigger states, and the entire Ethereum system is a state processing machine. 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, its upper limit is the ceiling of the blockchain structure.

When the UTXO-based and account-based (EVM-like) blockchains are interconnected and combined, the implementation methods of the state and state machine are quite different. The UTXO-based blockchain is easier to combine with the distributed system because the states in both systems are based on UTXO, and there is no conversion or only a simple conversion is required, which is easier to implement. The chain based on the account model has complexity in implementation because its state needs further encapsulation and conversion with the state of the external distributed system, 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, similar to Ordinals, which only use centralized indexes to complete statistical work.

Like centralized exchanges, the state transfer therein completely relies on the rules set by the centralized system. The state machine inside is also a state processor composed of centralized system programs. There is no complicated concept.

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

3. What should the structure of a 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 the 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 determine the structure of the combination? We speculate on the structure of large-scale applications that meet Web3.0 based on 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 Internet in China” 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 old data from 2020 and 2021. One thing to note is that this is only the statistical data of the Chinese Internet. In the Web3.0 stage, many applications are global, and the scale and performance requirements of users are higher.

In the statistical report, we can see 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, etc., covering almost 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. Take 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 games with the highest TPS on the blockchain can achieve a peak of around a few 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.

What’s more, games are just one type of application in common application categories, 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 earlier, applications like 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 is data from Q4 2023, it will be more accurate.

(1) Demand analysis through income reporting

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

1. Layer 1 (the basic main chain in the blockchain) has 48% of revenue, accounting for nearly half of the total revenue. 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 income in DeFi accounts for 8%, and its business model is the commission or spread of asset management;

5. Gamefi accounts for 5%, and its business model is royalties, transfer fees, sales of NFTs, etc.;

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

7. Tooling’s revenue accounts for about 1%. Its business model is service fee, which will also include traffic monetization fees in the future;

Other industries related to Web3.0 that are not Web3.0 applications and are not considered core industries of Web3.0 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 “One article to sort out the basic knowledge system of Bitcoin second-layer (Layer 2) 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 Lightning Network a Reality”, great demands are made on both functionality and performance. The true architecture of Web3.0 applications is also 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 around 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 technical solutions discussed later, 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 do not exist forever, and are destroyed once the purpose of the blockchain is fulfilled (e.g. recording transactions), or once its state is permanently stored elsewhere. The final state stored by a temporary chain is only data about the facts related to the temporary chain’s termination, thus compressing everything by a considerable order of magnitude. Temporary chains are mainly limited by transaction latency and throughput on the blockchain.

Temporary Chain VS State Channel

As far as temporary chains are concerned, we will eventually have a large number of users due to the presence of 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 the RGB state channel has the potential to bypass the performance constraints of the temporary chain and achieve the same functions as the temporary chain.

App-specific blockchains

An application-specific blockchain is a blockchain 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 scale their dapps to meet exponential growth needs, inspiring 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 look like to meet the needs of large-scale Web3.0 applications?

In the previous content, we have 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 needs of the above applications?

(1) The architectural differences between simple Web2.0 and Web3.0

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, and is not competent in large-scale applications.

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

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

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

With the blockchain system, we have entered the Web3.0 era. The applications of this period are a complex architecture built on the blockchain system, distributed system, and centralized system. 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 below,

The specific contents are described as follows:

(1) The Bitcoin mainnet and the second-layer construction are the center of all value, 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 all the ledger data. In the construction of Bitcoin’s second-layer, the second-layer construction based on the distributed system completes the performance expansion, processes local related data, and uses 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 require 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. The reason why it has not appeared on a large scale is that 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 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 applies to chains that are not part of the Bitcoin ecosystem. Other blockchain systems and the second layer can also enter the Lightning Network and RGB, and this situation will gradually emerge as the technology matures.

(4) In the Web3.0 ecosystem, centralized systems will also have a place, but the proportion 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 diagram will be more complicated. Some do not need to use the second layer, but directly operate on the first layer network, such as RGB when using 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 diagram is a simplified description of the Web3.0 application architecture.

3.4. Feasible construction paths

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 just includes the simple stage of the second-layer construction based on the chain into the first stage of construction.

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

Because the second-layer construction based on inscriptions and chains is relatively easy, many applications have emerged. Whether it is brc 20, src 20, arc 20, inscriptions and other applications, or those second-layer construction projects based on chains, they are very rich.

The construction in this phase is relatively simple, most of which are financial applications, and with the experience of transforming and imitating Ethereum’s second layer, it is easier and faster. Although relatively simple, this process is essential and important. They help prosper the ecosystem, attract traffic and funds, test cross-chain connection technology, test stablecoins, and test various possibilities. This phase is mainly to complete various verifications of functional feasibility.

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

At this stage, the second-layer construction based on the chain is also involved, which is the advanced stage of the chain-based construction. In addition, the second stage focuses on testing and improving various distributed second-layer constructions. The lightning network will be 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 like Nostr will also integrate value functions. This stage is mainly to complete various verifications of functional and performance feasibility.

(3) Large-scale construction based on Bitcoin ecology

The last stage is the mature stage, during which 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 will drive a large number of Web2.0 users to enter, and the time may not be that long.

No matter what, when the real Web3.0 era comes, it will be very different, with functions and output value greater and more brilliant than the current PC Internet + mobile Internet. Maybe it will 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 developments in the Bitcoin ecosystem.

(2) “The Impossible Becomes Possible: Making Full-Chain Game Development on the Lightning Network a Reality” (This article was more inspiring and verified)

(3) The three observation angles are mainly referenced in “Ethereum EVM illustrated”, Takenobu T., 2018.3

(4) For content related to application classification, please refer mainly to the author’s 2022 book “Web3.0: Building the Digital Future of the Metaverse”.

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

(6) References to some articles on distributed systems.