Original author: Fu Shaoqing, SatoshiLab, Bihelix, All Things Island BTC Studio
Read the notes:
(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 Architecture of large-scale web3.0 applications.
(2) For the classification of second-layer construction, refer to the article An article summarizing the basic knowledge system of Bitcoins second-layer (Layer 2) 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 a state machine, you will find that the principle of the state machine is applicable to all three system structures (blockchain system, distributed system, centralized system), but the implementation method is limited. on the structure of the system.
(4) Three viewing angles: distributed ledger, state machine, block + chain structure
Preface: Multiple levels and perspectives
Observing things at 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 comprehensive analysis methodology make it have strong application value in complex and changeable problems. It can provide more comprehensive, in-depth and accurate analysis results, and provide strong support for solving problems and promoting development.
(1)Multiple levels
Multi-levels can generally be observed at macro, meso and micro levels, or from the perspective of time cycles, short-term, mid-term and long-term levels can be used for observation. In the development of the Bitcoin ecosystem, we can gain a more comprehensive, in-depth and accurate knowledge and understanding of the Bitcoin ecosystem by observing it from three levels: short-term, medium-term and long-term.
Here is a summary from Teacher Dashan: “The Bitcoin ecosystem is divided into three opportunities: short-term, medium-term, and long-term: The short-term opportunity for the Bitcoin ecosystem is the Inscription track represented by BRC-20; the medium-term opportunity is the Bitcoin Layer 2 track and Nostr Plus. Lightning Network track; the long-term opportunity is the off-chain solution track represented by the RGB protocol and BitVM. This includes four tracks, the Inscription track; the Layer 2 track; the Nostr plus Lightning Network track; the off-chain track (Represented by RGB and BitVM).”
In Section 3.4 of this article, the early stage of chain-based second-layer construction in Layer is also classified as a short-term opportunity. 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 kind of multi-angle observation helps us better know and understand things, and is conducive to innovation.
From this multiple perspectives, we start from the business perspective - distributed ledger (conducive to understanding the business), the abstract computing perspective - state machine (conducive to understanding the implementation of blockchain + distributed systems), and the technical implementation perspective - block + chain structure (conducive to understanding the blockchain part of the ecosystem).
1. Three viewing angles
In the Ethereum document Ethereum EVM illustrated, it is introduced that there are three viewing angles for the block structure of Ethereum (Distributed ledger, state machine, blockchain). This observation also applies to Bitcoin, and is more suitable for observing Bitcoin’s ecological structure. In the following introduction, we understand from these three perspectives and there will be different gains.
From the perspective of a state machine, it is not only easy to understand the status and status processing on the blockchain, but also easier to understand the status, status channels, and status transitions in the distributed system. At the same time, combined with the structure of the distributed system, it will be easier to understand routing. The problem is to understand the requirements of the directed acyclic graph of state transitions. State machines are based on the underlying abstract computing principles of graph theory. Based on these principles and specific implementation structures (blockchain, distributed, centralized), you will understand the specific problems that need to be solved and the ideas for solutions.
Secondly, from a business perspective, we will easily understand why the blockchain can handle trust data and why the data on the blockchain can be used as digital currency, which makes the blockchain system more like a ledger. You will understand why the distributed system is not a ledger and needs to cooperate with the ledger. At the same time, you will understand how the distributed system handles data and flows on the ledger in cooperation with the ledger.
From the perspective of technical implementation, we will understand that a system like Blockchain is a blockchain structure. The advantages and disadvantages of this technical structure can also be easily summarized and summarized.
Regarding the structure of the Bitcoin ecosystem, from the perspective of ledgers and state machines, we can better understand the advantages and disadvantages of each structure, and how to use three alternative structures to build the second layer of Bitcoin, even if we build Web3. 0 The entire architecture of the application.
I had a feeling when reading Ethereums documentation Ethereum EVM illustrated. Observing things that can be compared to Ethereum from three different angles provides us with some thinking ideas and processing experience references for solving Ethereum. For example, when Ethereum is viewed as a state-based automaton, the theories and algorithms on state machines in the computer field can be applied to Ethereum through transformation. When considering Ethereum as a ledger-based database, some theories in the database can be applied to Ethereum - such as the idea of sharding in the database. This feeling also applies to the Bitcoin ecosystem, and will be mixed and used in three large system structures, making the flexibility even greater.
1.1. Business perspective—distributed ledger
From the perspective of a ledger, a blockchain is a group of transactions, just like pages of data written on a ledger.
From the perspective of ledgers, it is easier for us to understand its business capabilities and its monetary and financial functions. This is also the role of a ledger in the overall architecture of Web3.0 applications.
From the perspective of ledgers, we can easily understand the second-layer construction of the chain. 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 if a participant is given a digital currency, how to deal with it and how to divide the accounts, the participants can negotiate and deal with it themselves, and finally record it in the ledger.
1.2. Abstract computing perspective—state machine
Here we focus on state machines, because this perspective can provide a good understanding of blockchain systems and distributed systems. And you can understand the difference between how data (or state) is processed in a blockchain system and how it is processed in a distributed system.
From a state perspective, the 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 package, causing the status 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 a state perspective, the blockchain system can be viewed as a state-based automaton.
From the perspective of state, when we observe the blockchain + distributed system, it will be easier to understand the rules of state transmission and change in the two systems. Both systems are actually state-based automata.
When the blockchain is viewed as a state-based automaton, the theories and algorithms about state machines in graph theory in the computer field 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 state machine theory. Like finite acyclic graph DAG (avoiding double flowers), state channels, and one-time sealing are all technologies that need to be used to handle states in distributed systems.
1.3. Technical implementation perspective—block + chain structure
From a technical implementation perspective, systems such as Bitcoin and Ethereum are a blockchain. The scattered data are linked together by the data block and the hash pointer inside.
This is just a technical implementation structure maintained to operate a system like blockchain. The data and calculations on the blockchain adopt a global approach, and only this structure can complete the function of the ledger. The implementation details and applicability of this structure need to be considered when interfacing with external systems.
We can easily understand the characteristics of this block + chain technology implementation structure and can also calculate performance indicators. For example, the block size of the Bitcoin network is 1 M (the theoretical maximum is 4 M after supporting Segregated Witness), and the number of transactions it supports can be fully calculated.
The calculation formula is: (block size/average size of transactions)/average block time interval. Typically, Bitcoin can accommodate approximately 2,000-3,000 transactions per block, or 3-7 TPS.
1.4. Basic characteristics of blockchain and characteristics of three Layer 2 construction structures
Refer to the three classifications of Bitcoins second-layer construction: blockchain structure, distributed system structure, and centralized system structure. Comparing some basic characteristics of Bitcoins first- and second-layer construction, we can clearly see the differences between them. As shown in the table below. 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 the data and calculation rules become trusted data and trusted calculations. One of these trusted data is the basic original data (expressed as currency), and the other is the instruction set for processing data (expressed as code and smart contracts).
The biggest problem of the blockchain structure is poor performance. There are two reasons for this. First, the blockchain structure cannot remove partial calculation scenarios, and all requests are processed in a full calculation manner. For example, partial calculation and global calculation, local data and global data, temporary data and permanent data. Second, the blockchain structure has an obvious performance upper limit. If the second-layer expansion is performed through the chain, the number of supported transactions is also very limited. A simple calculation is as follows:
The upper limit of a blockchain system is the maximum number of transactions that can be accommodated by a single block capacity. The upper limit of a multi-level blockchain is the product of the number of transactions in each layers block capacity. For example, if a layer of Bitcoin has 7 TPS per second and a layer 2 chain has a processing capacity of 100 TPS, then the two structures combined will result in 700 TPS.
In order to expand the performance of blockchain-containing structures, multi-layer construction is required and it needs to be used in conjunction with heterogeneous systems. For work that must be completed in the blockchain system, only data that needs to be globally saved and calculated 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 relevant parties as much as possible. .
From the above table, only the blockchain structure can realize the trustless ledger function. Therefore, if a system wants to realize the trustless ledger function, it must include a blockchain system. However, due to the performance requirements of large-scale applications, the blockchain system must be combined with other systems to meet the needs.
(2) Distributed system
In the above table, we can see the obvious advantages of distributed systems: decentralization, performance, and scalability are all excellent, but there are more complex features in function implementation. In addition, distributed systems do not have the ability to trust the ledger.
Therefore, if we can use the distributed system in the second-layer construction based on the first-layer ledger function of Bitcoin, we can theoretically achieve unlimited performance expansion while maintaining the basic characteristics of the blockchain. A case in this area is represented by Bitcoin + Lightning Network. 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 hierarchical theory, which limits the code storage and execution of smart contracts to participants. This is also the scenario where client-side verification occurs in distributed systems. Only trusted data (state, one-time seal) between relevant parties is required to participate in the calculation, and Turing-complete calculations are only performed locally. This is what is often said about the network-wide consensus and participant consensus in distributed systems. The biggest difficulty in building the second layer with a distributed system structure is that the technical implementation is relatively complex. Networks like the Lightning Network that simply solve payment problems are developing slowly and have many imperfections. It is even more challenging to implement Turing-complete computing on a distributed system. The slow development and slow version updates of RGB are a reference case.
The biggest cost of solving complexity is the vulnerability to security issues and the high threshold for development. Implementing Turing-complete smart contract functions on a distributed system not only requires a long development cycle of the underlying platform and is difficult to develop, but also often leads to contract code vulnerabilities and continuous hacker attacks.
(3) Centralized system
In the above table, we can see that the benefit of the centralized system is that the engineering implementation is relatively simple. This is due to the simple internal logic control and simple calculation. Similarly, centralized systems do not have the ability to trust ledgers. The advantages of the centralized system are not outstanding. If it is processing small-scale data, or processing temporary data and temporary calculations, it will be relatively suitable.
The second-floor construction of the centralized system can be used as a supplementary or transitional solution to the other two methods.
(4) Comprehensive analysis
In the value era, through the above content, we can see that it is difficult to achieve the effect of meeting needs by relying on one system alone. This is also a practical need for the second layer of Bitcoin ecological development. But how to combine these three systems requires a lot of exploration. Let’s analyze it theoretically first. Faced with 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 require Turing completeness. It is a global trust machine and only needs to save the data and data changes that require global trust. Based on this most basic requirement, Bitcoins instruction set can be reduced to a minimum. Other functions are left to the upper-layer extensions 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 also needs to be further developed and improved. Moreover, this connection technology, on the premise of meeting the functions, takes up as little data space of Bitcoin as possible.
Generally, small applications only need to be completed on a single blockchain. Slightly larger systems are suitable for completion on the second-layer construction of blockchain + blockchain. But for large-scale applications, the preferred solution is to use a blockchain system + distributed system. From a performance perspective, the upper limit of the distributed system is theoretically unlimited, so such a combination is Bitcoins 7 TPS * ∞. Engineering implementation will also be limited by some specific factors. Usually the upper limit of such a system is limited by the routing capabilities of the distributed system, the processing capabilities of directed acyclic graphs of state changes, and other specific technical implementation links. Later, in the typical application architecture of Web3.0, you can also see the combination diagram of various 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 a 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 distributed systems.
In the history of technological development in the past, there were also some cases of combined use. For example, when the centralized database has limited capabilities, it adopts a master-slave structure, then moves to sub-databases and sub-tables, to distributed databases, which are examples of using centralized systems and distributed systems.
This combination also embodies a philosophical idea:A solution to a problem does not provide an answer at the level that created the problem, but it solves the problem 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, but must use external systems to solve them.
2. Revisit the design and development of the second layer of Bitcoin from the perspective of state machine
States and state machines exist in the three two-story buildings, 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 states and state machines, the three two-layer structures are all state machines that process states, 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, but cannot destroy the consistency of the state.
From the perspective of the state machine, the application architecture of the Bitcoin ecosystem or Web3.0 uses the combination of these systems to complete the processing of state transformations, thereby completing the processing of business logic.
Using the idea of state machines, we look at the two-layer network construction of Bitcoin, and we can see that each layer of the architecture has a division of labor suitable for its characteristics.
2.1. Basic knowledge of states and state machines in graph theory
In graph theory, the basic knowledge of states and state machines includes the following:
State: A state refers to a node or vertex in graph theory. In a directed graph, the state can be represented as a node; in an undirected graph, the state can be represented as a vertex.
State Transition: State transition refers to the process from one state to another state. 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 used to describe a series of states and transition rules between states. The state machine consists of a state set, an initial state, a transition function and a termination state.
Directed Graph: A directed graph is a graph structure composed of vertices and directed edges, where the directed edges point from one vertex to another, representing the transition relationship between states.
Undirected Graph: An undirected graph is a graph structure composed of vertices and undirected edges. The undirected edges connect two vertices and represent the association between states.
Topological Sorting: Topological sorting refers to linearly sorting the vertices of a directed acyclic graph (DAG) so that for any two vertices u and v, if there is an edge (u, v), 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 starts from a vertex and returns to the vertex after passing through several edges.
Shortest Path: The shortest path refers to the path connecting two vertices in the graph with the smallest sum of edge weights.
Minimum Spanning Tree: Minimum spanning tree refers to finding a tree containing all vertices in a connected graph such that the sum of the weights of the edges of the tree is minimum.
These basic knowledge are core concepts in graph theory and are used to describe and analyze the relationships and transition rules between states. Relevant knowledge and graphics 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 this knowledge into some blockchain concepts that we often encounter. 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 to find the shortest path in the distributed system. Calculation; the route with the smallest payment cost in the Lightning Network is the minimum spanning tree problem; client verification can also be regarded as a form of state machine.
2.2. State machine and distributed system
Here we use several distributed networks to introduce:
(1) In the Lightning Network
In the Lightning Network, knowledge points related to states and state machines 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 update the channel status to achieve fast and low-cost transactions. Payment of costs.
Transactions (i.e., states) in the Lightning Network are implemented through Hash-based time-locked contracts (HTLC), through which participants can lock funds (the state is transferred between the Bitcoin and Lightning Network systems), and Conduct secure transactions within channels (simple state handling).
Routing in the Lightning Network: To enable 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 are nodes that can forward payment requests, and they can help realize cross-channel payments.
Two-way payment on the Lightning Network: The Lightning Network allows participants to make two-way payments in the payment channel, that is, they can not only pay to the other party, but also accept the other partys payment.
Payment privacy of the Lightning Network: Since transactions on the Lightning Network are conducted within the channel, all transactions do not need to be written to the blockchain, so the privacy of payments can be improved.
Limitations of Lightning Network (mostly limitations of state and state machine implementation technology): Lightning Network also has some limitations, such as channel survivability, fund locking 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 second or third layer. If RGB is directly calculated based on BP, it directly extends the Turing complete function of Bitcoin and belongs to the second layer. This method has limited expansion of performance. If the RGB calculation is 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 there is a certain complexity in technical implementation. Spend. Usually in combination, it can not only expand computing power, but also expand performance and reduce implementation complexity.
RGB is based on state channel technology in Bitcoin or the Lightning Network. The status channel in RGB refers to the communication channel between two or more parties built on LNP and BP. Multiple transactions and status updates can be performed within the channel, reducing the number of transactions and fees on the blockchain.
State channels in RGB use Bitcoin-based multi-signature scripts to lock funds and use special transaction types 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 in 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 implement more complex functions, such as atomic swaps, payment routing, etc., through smart contracts and multi-signature scripts.
State channels in RGB can be combined with other technologies and protocols, such as Lightning Network, LNURL, etc., to provide richer functionality and better user experience.
The design and implementation of state channels in RGB need to consider factors such as security, privacy, scalability, etc. to ensure the reliability and availability of the system.
(3) In Nostr, concepts related to states, state machines, and state channels.
In Nostr, because it is transmitting information, the concepts of state (trusted data, digital currency) and state machine have not yet been reflected. However, I believe that if the distributed structure of Nostr is slightly modified and the processing of status is increased, a system similar to the Lightning Network will be formed. Such a system can both transmit information and deliver value. The application architecture diagram of Web3.0 in Section 3.3 also describes the possibility of gradually transforming this information-based distributed system into a distributed system that includes value processing.
A brief introduction to current Nostr: 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. Every post a user makes is signed. Each client verifies these signatures. Clients get data from and publish data to the relay of their choice. Relays do not communicate with each other, only directly with users.
(4) In distributed systems, knowledge points related to state machines include:
State machine model: A state machine is a mathematical model that describes the transitions 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 the system.
Finite state machine (FSM): Finite state machine is the most basic state machine model, which contains a finite set of 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 the system moving from one state to another. In a distributed system, state transitions may be triggered by various events or conditions, such as message receipt, timeout, etc.
Behavior of state machine: State machine can define different behaviors in different states. In a distributed system, the behavior of a 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 various nodes in the system coordinated and consistent with each other.
Distributed state machine (DSM): Distributed state machine refers to a technology that applies state machine models to distributed systems. It can distribute the systems state and state transitions across multiple nodes and ensure state consistency between nodes.
Atomic state machine (ASM): An 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 consensus protocols include Paxos, Raft, ZAB, etc.
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 must be able to maintain efficient state transitions and consistency as the system scale increases.
2.3. State machine and blockchain system
According to Ethereums document Ethereum EVM illustrated, each block is a set of trigger 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, its upper limit is the ceiling of the blockchain structure.
For the combined application of blockchain interconnection based on UTXO model and account model (like EVM), the implementation methods of state and state machine are quite different. Blockchains based on the UTXO model are easier to combine with distributed systems because the states in both systems are based on UTXO, and there is no conversion or only simple conversion, which is easier to implement. The chain based on the account model requires further encapsulation and conversion between its state and the state of the external distributed system, which is complex to implement. This 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 exchange CEX.
Such systems are relatively simple, and some have no state transfer at all, like Ordinals, which only use centralized indexes to complete statistical work.
Like a centralized exchange, the state transfer in it completely relies on the rules set by the centralized system. The state machine inside is also a state processor composed of centralized system programs, and there are no complicated concepts.
In future Web3.0 applications, there should be more cases of using blockchain + centralized systems.
3. What should the structure of a Web3 application look like?
Through the previous content of the article, we know that through the combination of three Bitcoin two-layer architectures, more complex structural designs can be completed to obtain the required feature requirements. And from a business perspective, if the underlying logic of the application can be decomposed into states and state machines, a combination of the three systems can be used to complete the entire upper-layer business logic.
So what are these common combinations? What factors will determine the structure of the portfolio? 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 Chinas Internet Development as a reference, hereafter referred to as the statistical report. Because Web2.0 has matured and does not affect the analysis of application classification and user scale results, the application reference data we use is old data from 2020 and 2021. One thing to note is that this is only the statistics of Chinas Internet. In the Web3.0 stage, many applications are global, and users have higher scale and performance requirements.
In the statistical report, we can see that the applications in Web2.0 are already very rich and have a huge user group. These applications include: instant messaging, online video, short video, online payment, online shopping, search engine, online news, online music, online live broadcast, online games, online takeout, online literature, online ride-hailing, online office, and online travel booking. , online education, online medical care,... covering almost all areas of peoples 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 peak performance requirement is: 65,000 TPS. Such performance indicators can only be supported by distributed systems. For example, the current performance of the Lightning Network is 40 million transactions per second, and the performance of the Lightning Network is not theoretically sufficient. upper limit.
In addition, let’s take common games as an example. The current full-chain game with the highest TPS on the blockchain can achieve a peak of around a few thousand TPS, which is a huge gap from traditional Web2 3A games with hundreds of thousands of TPS. If you want to migrate all games to Web3.0, the required infrastructure performance will be a big challenge.
Whats more, games are just one 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 the application, it will be more direct to use the revenue structure as an indicator. We refer to the Token Terminal, curated by FutureMoney Research 2022 Q2 report. Although this report is earlier, payment and other applications are in the preliminary stage and will 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 Q4 data in 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 the picture shows.
1) The revenue of Layer 1 (the basic main chain in the blockchain) is 48%, accounting for nearly half of the total revenue. Its business model can be understood as “selling block space”;
2) The revenue of the NFT trading platform accounts for 22%, and its business model can be understood as royalties or marketing activities;
3) Dex revenue in DeFi accounts for 15%, and its business model is transaction fees and liquidity market making revenue;
4) Staking income in DeFi accounts for 8%, and its business model is commission or interest spread from asset management;
5) Gamefi accounts for 5%, and its business model is royalties, transfer fees, sales of NFT, etc.;
6) Lending revenue in DeFi accounts for about 1%, and its business model is interest spread;
7) Tooling’s revenue accounts for about 1%, and its business model is service fees, which will also include traffic monetization fees in the future;
Other industries related to Web3.0 are not Web3.0 applications and are not counted as core industries of Web3.0 and will not be included. For example: Web3.0 media, research organizations, training organizations, etc.
From the revenue structure, we can see that the current application needs of the BTC ecosystem can basically be solved by the blockchain and its second-layer system, without the need for complex system architecture. However, Gamefi and SocialFi are developing relatively quickly. Using the game examples in the reference literature, we can see that large-scale games have higher and clear requirements for system structure.
From the income structure, we can see the application needs of the current BTC ecosystem. It is worth redoing all the products in Ethereum and other ecosystems. Slightly transforming the chain-based second-layer construction technology in the Ethereum ecosystem and establishing a new second-layer on Bitcoin can better meet these primary needs, but only in the degree of decentralization, security, privacy, and censorship resistance. A certain compromise was made. In An article reviewing the basic knowledge system of Bitcoins second-layer (Layer 2) construction, the new second-layer construction based on the EVM type are all cases of this situation.
(2) Analysis of game cases for applications requiring high performance
In the article The Impossible Becomes Possible: Making Full-Chain Game Development a Reality on the Lightning Network, there is a greater demand for both functionality and performance. The real architecture of Web3.0 applications is gradually emerging.
Problem description in the article: On the basis of ensuring security, privacy and decentralization, full-chain games have 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 current full-chain game with the highest TPS on the blockchain can achieve a peak of around a few thousand TPS, which is a huge gap from traditional Web2 3A games with hundreds of thousands of TPS. While pursuing the premise of not losing the advantages of blockchain, full-chain games can overcome the scalability.
In the solution discussed later in the technical discussion, Lightning Network and RGB are used to expand performance, and the concepts of temporary chains and dedicated chains are also proposed.
Ephemeral chain (temporary chain)
Ephemeral blockchains can be defined as blockchains that do not last forever and are destroyed once the blockchains purpose is fulfilled (such as recording transactions) or once its state is permanently stored elsewhere. The termination status stored by the temporary chain is only data about the termination facts related to the temporary chain, thus compressing everything by a considerable order of magnitude. Temporary chains are mainly limited by transaction delays and throughput on the blockchain.
Temporary chain VS state channel
As far as temporary chains are concerned, we will end up with a large number of users due to the state on the public chain. The state that needs to be inserted into the public chain will be reduced in size through pruning/compression/difference extraction, and then saved on the public chain regularly instead of irregularly. The setting of the RGB status channel may bypass the performance constraints of the temporary chain and achieve the same function as the temporary chain.
App-specific blockchains
Application-specific blockchains are blockchains created to run a single decentralized application (dapp). Rather than 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 constraints can help the implementation of blockchain for specific applications. Allowing developers to customize the infrastructure for different use cases makes development easier. At the same time, it allows web3 developers to build powerful value models and extend their dapps to meet exponential growth needs and inspire more innovation.
Through the case of this game, coupled with our previous analysis of several architectures, we can roughly judge the architecture of future large-scale applications.
3.3. What should the architecture that meets the needs of large-scale Web3.0 applications look like?
In the previous content, we learned about the common application categories in Web2.0. All these applications have been upgraded to Web3.0, which is a sign of fully entering the Web3.0 era. What kind of architecture can satisfy the many applications above?
(1) Simple architectural differences between Web2.0 and Web3.0
Here we refer to the content of the article The Architecture of a Web 3.0 application written by the blockchain goddess Preethi Kasireddy. The structural description of Web3.0 applications here is a very simple structure that only relies on the blockchain system. However, this structure is too simple, does not reflect the second-layer construction, and is not competent in large-scale applications.
By comparing the technical implementation cases of traditional centralized products and those of Web3.0 products, it will be easier to understand the differences in technical implementation. Combined with Gavin Woods description of the technology stack vision of Web3.0, 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 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, applications such as shopping malls, IM, and videos are built on centralized systems, and Thunder downloads are built on distributed systems.
With the blockchain system, we have entered the Web3.0 era. The applications in this period are a complex architecture built on the blockchain system, distributed system, and centralized system. 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 below,
The specific content is described as follows:
(1) The Bitcoin main network and second-layer construction are the center of all value, and most of the value is built on this network. In the second-layer construction of Bitcoin, the chain-based second layer completes the performance expansion and processing of value, and processes all ledger data. In the second-layer construction of Bitcoin, the second-layer construction based on the distributed system completes the expansion of performance. It processes local relevant data and uses the consensus of relevant parties, but the final calculation results need to be implemented in the blockchain system. In the second-layer construction of Bitcoin, the second-layer construction based on the centralized system directly provides services for upper-layer applications.
(2) The RGB-like system 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 example in Reference 1 describes this scenario. It has not appeared on a large scale because the construction of RGB-like systems is complicated and has not yet reached maturity.
(3) In addition to the Bitcoin ecosystem, there are also other blockchain system ecosystems to meet the needs of different business scenarios. As we described in the article on the second-layer infrastructure, there will be many projects on the second-layer based on the chain, and it is also applicable to non-Bitcoin ecological chains. Other blockchain systems and second layers can also enter the Lightning Network and RGB, and this will gradually occur 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 wiring in the above figure will become more complicated. Some do not need to use the second layer, but directly operate 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 are demand scenarios, there will be usage scenarios by transforming some basic features. The above figure is a simplified description of Web3.0 application architecture.
3.4. Feasible construction paths
From the income structure, we can see the current application needs of the BTC ecosystem, and from the classification of commonly used applications, we can see the need to fully enter Web3.0 in the future. Its going to be a long road. Therefore, things with a relatively long construction period need to be dealt with in stages.
The three stages here are very similar to the short-term, medium-term, and long-term mentioned by Teacher Dashan. It just summarizes the simple stage of chain-based second-layer construction into the first stage of construction.
(1) The first phase is the early stage of the two-layer construction based on inscriptions and chains
Inscription-based and chain-based two-layer construction are relatively easy and currently have many applications. Whether it is brc 20, src 20, arc 20, inscription and other applications, or those chain-based second-layer construction project parties, they are all abundant.
The construction at this stage is relatively simple, most of them are financial applications, and with the support of experience in transforming and imitating the second layer of Ethereum, it is easier and faster. Although relatively simple, this process is essential and important. They helped prosper the ecology, attracted traffic and funds, tested cross-chain connection technology, tested stablecoins, and tested various possibilities. This stage is mainly to complete various verifications of functional feasibility.
(2) The second stage is the middle and late stages of the chain-based second-tier construction and the distributed system-based second-tier construction.
At this stage, chain-based second-layer construction is also involved, which is an advanced stage of chain-based construction. In addition, the second phase focuses on testing and improving a variety of distributed second-layer construction. The Lightning Network will become more mature, its RGB functions and stability will be greatly improved, and its 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 incorporate 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 maturity stage. In this stage, Web3.0 begins to be built in large quantities and gradually matures. The common applications described in 3.1 have begun to enter the Web3.0 era.
Maybe this stage will take a longer time to arrive. Maybe there will be an inflection point event that can promote the entry of a large number of Web2.0 applications, and the time may not be so long.
No matter what, when the real Web3.0 era comes, it will definitely be very different. The functions and production value will be greater and more brilliant than the current PC Internet + mobile Internet as a whole. Perhaps it is like the emergence of Sora in the AI field, which is very amazing and shocking, but the process is not so sudden.
Reference description
(1) Refer to Mr. Dashan’s articles and course content on the short-term, medium-term and long-term aspects of Bitcoin ecology.
(2) The Impossible Becomes Possible: Making Full-Chain Game Development a Reality on the Lightning Networkhttps://m.jinse.cn/news/blockchain/3667669.html(It will be more inspired and verified by this article)
(3) The three observation angles mainly refer to Ethereum EVM illustrated, Takenobu T., 2018.3
(4) For content related to application classification, mainly refer to Web3.0: Building a Digital Future for the Metaverse written by the author in 2022.
(5) Refer to the graph theory knowledge in university digital logic.
(6) Reference is made to some articles on distributed systems.
