从状态机的角度观察比特币二层，Web3大规模应用的架构是什么样子？

原文作者：付少庆，SatoshiLab ，Bihelix ，万物岛 BTC 工作室

阅读注释：

（1）本文稍显晦涩，因为涉及了一些系统的底层原理，并且作者本人在分布式系统方面的理论与实践经验有限。一般读者可以直接阅读结论，即 3.3 节 web3.0 大规模应用的架构。

（2）对于二层建设的分类，参考文章《一文梳理比特币二层（Layer 2）建设的基础知识体系》。根据参考文章中的系统结构分类，将比特币 Layer 2 的二层分为三种：区块链式结构， 分布式系统结构，中心化系统结构。

（3）从状态机的角度观察比特币的二层建设会发现状态机的原理在三种系统结构（区块链系统、分布式系统、中心化系统）中都适用，只是实现的方式受限于系统的结构。

（4）三种观察角度：分布式账本，状态机，区块+链结构

前言 多层次与多角度

多层次与多角度观察事物属于综合分析方法论。它的优势体现在几个方面：全面性、深 度理解、综合性、精准性、利于执行。综合分析方法论的优势使得它在复杂和多变的问题中 具有较强的应用价值，可以提供更全面、深入和准确的分析结果，为解决问题和推动发展提供有力支持。

（1）多层次

多层次一般可以采用宏观、中观、微观，也可以从时间的周期上，采用短期、中期、长期三个层次上观察。在比特币生态的发展中，我们从短期、中期、长期三个层面观察，可以 获得比特币生态更全面、深入和准确的认识和理解。

这里借用大山老师的总结：“ 比特币生态分成短期、中期、长期的三个机会： 比特币生态短期机会是 BRC-20 为代表的铭文赛道； 中期机会是比特币 Layer 2 赛道和 Nostr 加闪电网络赛道；长期机会是 RGB 协议和 BitVM 为代表的链下解决赛道。这其中包含的四个赛道，铭文赛道；Layer 2 赛道；Nostr 加闪电网络赛道；链下赛道（以 RGB 和 BitVM 为代表）。”

本文在 3.4 节中将 Layer 中基于链的二层建设的前期阶段也划入到短期机会，原因在 3.4 节中介绍。

（2）多角度

同时对于比特币生态，我们从多个角度观察，可以带来全面、客观、深入、灵活和创新的优势。这种多角度的观察有助于我们更好地认识和理解事物，利于创新。

这种多角度，我们从业务角度——分布式账本（利于理解业务），抽象计算角度——状态机（利于理解区块链+分布式系统的实现），技术实现角度—— 区块+链的结构（利于理解 生态中的区块链部分）。 

 1. 三种观察角度

在以太坊的文档《Ethereum EVM illustrated》中，介绍了对于以太坊的区块结构，有三种观察角度（分布式账本、状态机、区块链）。这种观察同样适用于比特币，而且更适合观察比特币的生态架构。在下面的介绍中，我们从这三种角度理解，会有不同的收获。

从状态机的角度理解，不仅容易理解区块链上的状态和状态处理，我们会更容易理解在分布式系统中状态，状态通道，状态转换，同时结合分布式系统的结构，会容易理解路由的 问题，理解状态转换的有向无环图要求。状态机是基于图论的底层抽象计算原理，基于这些 原理与具体的实现结构（区块链、分布式、中心化），会理解需要解决的具体问题与解决方案的思路。

其次是业务的角度，我们会容易理解区块链为什么可以处理信任数据，为什么区块链上面的数据可以作为数字货币，这使得区块链系统更像一个账本。会理解，为什么分布式系统 不是账本，需要与账本合作。同时会理解在与账本的合作中，分布式系统如何处理账本上的 数据与流转。

从技术实现的角度，我们会理解 Blockchain 这种系统是区块链结构，这种技术结构的优缺点也很容易归纳和总结。

对于比特币生态的结构，从账本和状态机的角度我们可以更好的理解每种结构的优缺点，以及如何使用三种可选择的结构来构建比特币的二层，甚至是如果构建 Web3.0 应用的整个架构。

在阅读以太坊的文档《Ethereum EVM illustrated》时，我有一种感受。三种不同的角度观察以太坊可以类比的事物，为我们解决以太坊提供了一些思考思路和处理经验参考。例如， 当把以太坊看成基于状态的自动机时，计算机领域关于状态机的理论和算法通过改造就可以 用于以太坊。当把以太坊看成基于账本的数据库时，数据库里面的一些理论就可以用于以太 坊——如数据库里面的分片思想。这种感触在比特币的生态中同样适用，而且会混合在三种 大的系统结构中使用，灵活性会更强。

1.1. 业务角度—分布式账本

从账本的角度看，区块链是一组组的交易，就像写在账本上面的一页页的数据。

从账本的角度看，我们容易理解其业务能力，也就更容易理解其货币与金融的作用。这 也是在 Web3.0 应用的整体架构中，一定要有账本这种角色。

从账本的角度我们也容易理解链的二层建设，不同业务的账目可以记录到不同的账本上， 这些子账本汇总到总账就可以。

从账本+分布式的角度，我们可以理解，给参与方一笔数字货币，具体怎么处理，怎么分账，参与方去自己协商处理，最后再记录会账本就可以。

1.2. 抽象计算角度—状态机 

在这里我们重点介绍一下状态机，因为这种角度可以很好的理解区块链系统与分布式系统。并且可以理解数据（或状态）在区块链系统中处理过程与在分布式系统中处理的差异。

从状态的角度看，区块链是一个基于交易的状态机。一个交易是触发条件，使得一个原始状态σt ，在交易的作用下，转变到下一个状态σt+ 1 。

一组交易打包到一个区块链中，是一个数据包，使得与这组数据相关联的状态都发生变化。 

于是从这个角度看，区块链是一个状态链（在分布式系统中，是一个个状态通道）。从状态的角度，区块链系统可以看做是一个基于状态的自动机。

从状态的角度，我们观察区块链+分布式系统，会更容易理解状态在两个系统中的传递与变化规则，两个系统其实都是基于状态的自动机。

当把区块链看成基于状态的自动机时，计算机领域图论中关于状态机的理论和算法就可以作用于区块链。同样，如果实现的技术结构不是区块链结构，而是一种分布式结构，我们也可以用状态机的理论。像有限无环图 DAG（避免产生双花），状态通道，一次性密封都是 在分布式系统中处理状态需要使用的技术。

1.3. 技术实现角度—区块+链的结构

从技术实现的角度看，比特币和以太坊等系统是一个区块链。由数据区块和里面的哈希指针将分散的数据联系到一起。

这仅仅是为了运转区块链这样的系统，保持的一种技术实现结构。区块链上面的数据和计算都是采用全局的方式，只有这种结构能够完成账本的功能。在与外部系统连接时，需要 考虑这种结构的实现细节和适用性。

这种块+链的技术实现结构，我们很容易理解其特点，也可以计算性能指标。例如，比特币网络的区块是 1 M（支持隔离见证后理论最大是 4 M） ，其支持的交易数量就完全可以计算出来。

计算公式为：（区块大小/交易的平均尺寸）/ 区块平均时间间隔。一般情况下，比特币每个区块大约可以容纳 2000-3000 笔交易，即 3-7 TPS。

1.4. 区块链的基础特性与三种 Layer 2 建设结构的特点 

参考比特币二层建设的三种分类：区块链式结构，分布式系统结构，中心化系统结构。 对比比特币一层和二层建设的一些基础特性，可以清楚的看到他们之间的差异。如下表所示。 稍后对照 3.2 节中的应用需求，便于我们从这些基础系统结构中选取一个合适的架构构建组合。

通过上表，我们能够大致总结出区块链结构、分布式系统结构、中心化结构的特点。

（1）区块链结构

区块链结构的最大好处是解决信任相关问题，可以记录数据的变化过程（状态转换）, 于是数据和计算规则都变成了可信数据与可信计算。这些可信数据，一种是基础的原始数据 （表现为货币），一种是处理数据的指令集（表现为代码与智能合约）。

区块链结构最大的问题是性能差，这有两个原因，一是区块链结构在于不能去除部分计算的场景，都是以全量计算的方式处理所有请求。如，部分计算与全局计算，局部数据与全 局数据，临时数据与永久数据。二是区块链结构有明显的性能上限。如果是通过链的方式进 行二层扩展，支持的事务数量也很有限。简单计算如下：

区块链系统的上限是单个区块容量能容纳的最大交易数，多级区块链的上限是每一层区块容量交易数量的乘积。例如，一层比特币每秒 7 TPS ，一个二层链的处理能力是 100 TPS ， 那么这两种结构组合在一起就是 700 TPS。

为了扩大包含区块链结构的性能，需要多层建设，并且需要与异构的系统结合使用。对于必须在区块链系统完成的工作，只需要记录需要全局保存和计算的数据，其他的非全局数据都可以分配到其他层来处理，尽可能使得处理的数据与代码只与相关方有联系。

通过上表，只有区块链结构才能实现去信任账本功能，所以一个系统中要想实现去信任账本功能，必须要包含区块链系统。但大规模应用对性能的要求，使得区块链系统一定需要 结合其他系统才能满足需求。

（2）分布式系统

在上表中，我们可以看到分布式系统的明显优点：去中心化、性能、可扩展性都是极好， 只有在功能实现上有比较复杂的特点。此外，分布式系统不具有去信任账本的能力。

于是如果能够基于比特币的一层账本功能，在二层建设中使用分布式系统，理论上可以在保持区块链基础特性的同时，还能实现无限的性能扩展。这方面的案例以比特币+ 闪电网 络为代表，这样组合的性能就是比特币的 7 TPS *  ∞。

在分布式系统中实现图灵完备的原因是：在区块链系统中记录和运行智能合约的代价是很高的，因为是全局数据与全局代码。所以智能合约也适合分层理论，将智能合约的代码存 储与执行局限在参与者之间。这也是分布式系统中的客户端验证产生的场景，只需要相关者 之间的可信数据（状态，一次性密封）参与计算，只在局部进行图灵完备的计算。这就是常说的分布式系统中的全网共识与参与人共识用分布式系统结构建设二层的最大困难是，技术实现上的复杂大比较大。像闪电网络这 样单纯解决支付问题的网络都发展缓慢，有较多不完美。如果在在分布式系统上实现图灵完 备的计算，就更加有挑战。RGB 发展的缓慢和版本更新慢，就是一个参考案例。

解决复杂性的最大代价是容易出现安全问题与开发的门槛较高。在分布式系统上实现图灵完备的智能合约功能，不仅底层平台的开发周期长，开发难度大，并且经常会出现合约代 码漏洞和持续的黑客攻击。

（3）中心化系统

在上表中，我们可以看到中心化系统的好处是工程实现相对简单，这是由于内部的逻辑控制简单，计算简单。同样，中心化系统也不具有去信任账本的能力。中心化系统的优势不 突出，如果是处理规模不大的数据，或者处理临时数据与临时计算会相对比较适合。

中心化系统的二层建设可以作为其他两种方式的补充或过渡性方案。

（4）综合分析

在价值时代，通过上面的内容，我们可以看到单靠一个系统很难到达满足需求的效果。 这也是比特币生态发展二层的一个实际需求。但这个三种系统怎样组合需要很多的探索，我们先从理论上分析，面对不同的需求，会有不同的组合结构。

首先，从协议分层的设计思想看，比特币网络确实不需要图灵完备，它是一个全球的信任机器，只需要保存这些需要全局信任的数据和数据变化的轨迹。根据这个最基本要求，比 特币的指令集可以减少到最低。其他功能，则交给上层的扩展来完成。除了满足本层功能需 求，还需要比特币一层和上层网络的连接技术进一步发展和完善，而且这种连接技术，在满 足功能的前提下，对比特币的数据空间占用越少越好。

一般的小型应用，只需要在单一的区块链上就可以完成。稍大一些的系统适合在区块链 + 区块链的二层建设上完成。但对于大规模的应用，优选的方案是使用区块链系统+分布式系 统。从性能角度，分布式系统上限在理论上是无限的，那么这样的组合就是比特币的 7 TPS * ∞。工程实现中，还会受到一些具体因素的限制，通常这样的系统的上限是受限于分布式系统的路由能力，状态变化的有向无环图的处理能力等具体技术实现环节。后面在 Web3.0 的 典型应用架构中，还可以看到多种系统的组合图示。 

通过多种系统结构的组合，可以突破单一系统基础理论的限制。例如，区块链系统受限于 DSS 不可能三角形的限制，但如果使用区块链系统+分布式系统，就可以解决去中心化 D、 安全性 S、可扩展性 S 的不可能三角形。其他组合，区块链+ 中心化系统，也可以一定程度 上解决扩展性的问题。分布式系统+ 中心化系统，可以解决分布式系统中 CAP 三角形的限制。

在以往的技术发展历史中，也存在一些组合使用的案例。例如，中心化的数据库在能力受限时，采用主从结构，到分库分表，到分布式数据库，就是使用中心化系统与分布式系统 的案例。

这种组合也体现了一个哲学思想：一个问题的解决方法不能在产生问题的层次上得到答案，但可以在更高的层次上解决这个问题。这句话理解清楚不是特别容易，我想到《禅与摩托车维修艺术》有一个比喻特别好：我们不能揪着自己的头发把自己提起来。这是告诉 我们不能依靠系统本身解决自身的问题，一定需要借助外部系统来解决。 

2. 从状态机的角度重新看比特币二层的设计与发展

状态与状态机，在三种二层建设中都存在，只是名称上有些不同，使得多数人不关注这个观察角度。

如果我们从状态与状态机的角度看，三种二层结构都是处理状态的状态机，只是原理稍有不同。这三种系统组合使用的时候，需要保证“状态 ”概念在三个系统中一致，并且每个 系统的状态机能够处理状态变化，但不能破坏状态的一致性。

比特币生态或 Web3.0 的应用架构，我们从状态机的角度看，就是借助这几种系统组合， 完成状态变换的处理，从而完成业务逻辑的处理。

用状态机的这种思想，我们再看比特币的二层网络建设，可以看到架构的每一层有适合其特点的分工。 

2.1. 图论中状态与状态机的基础知识

在图论中，状态与状态机的基础知识包括以下内容：

状态（State） ：状态是指图论中的节点或顶点。在有向图中，状态可以表示为一个节点；在无向图中，状态可以表示为一个顶点。

状态转移（State Transition） ：状态转移是指从一个状态到另一个状态的过程。在有向图中，状态转移可以表示为一条有向边；在无向图中，状态转移可以表示为一条无向边。

状态机（State Machine）：状态机是一个抽象的计算模型，用于描述一系列状态和状态之间的转移规则。状态机由状态集合、初始状态、转移函数和终止状态组成。

有向图（Directed Graph） ：有向图是由顶点和有向边组成的图结构，其中有向边从一个顶点指向另一个顶点，表示状态之间的转移关系。

无向图（Undirected Graph）：无向图是由顶点和无向边组成的图结构，其中无向边连接两个顶点，表示状态之间的关联关系。

拓扑排序（Topological Sorting）：拓扑排序是指对有向无环图（DAG）的顶点进行线性排序，使得对任意两个顶点 u 和 v ，如果存在边 (u, v) ，则 u  在排序中出现在 v 之前。

有向无环图（DAG）：有向无环图是一个有向图，其中不存在从某个顶点出发经过若干条边后能回到该顶点的环。

最短路径（Shortest Path）：最短路径是指在图中找到连接两个顶点的路径中，边的权重之和最小的路径。

最小生成树（Minimum Spanning Tree） ：最小生成树是指在连通图中，找到一个包含所有顶点的树，使得树的边的权重之和最小。

这些基础知识是图论中的核心概念，用于描述和分析状态之间的关系和转移规则。相关的知识和图形在专业的书籍中可以深入学习。

虽然看起来这些知识有些抽象和枯燥，如果我们把这些知识转换成经常遇到的一些区块链概念就很容易理解。例如，一些场景要求是有向无环图就是避免双花的问题；一次性封装 就是将区块链中的状态转变成分布式系统中的状态；路由算法是在分布式系统中寻找最短路 径的计算；闪电网络中支付成本最小的路由就是最小生成树问题；客户端验证也可以看成一 种形式的状态机。 

2.2. 状态机与分布式系统

在这里我们用几种分布式网络来介绍：

（1）闪电网络中

在闪电网络中，能够体现状态、状态机相关的知识点有：

闪电网络是基于状态通道技术的比特币二层解决方案，闪电网络中的支付通道是一种双向的状态通道，参与者可以在通道内进行多次交易，并通过更新通道状态来实现快速、低成 本的支付。

闪电网络中的交易（即状态）是通过基于 Hash 时间锁定合约（HTLC）来实现的，参与者可以通过这种合约来锁定资金（实现状态在比特币与闪电网络两个系统中传递），并在通 道内进行安全的交易（简单的状态处理）。

闪电网络中的路由：为了实现跨通道的支付，闪电网络使用了一个名为路由的机制，参与者可以通过找到一条可信的路径来进行支付。

闪电网络中的中继节点：中继节点是指那些能够转发支付请求的节点，他们可以帮助实现跨通道的支付。

闪电网络的双向支付：闪电网络允许参与者在支付通道中进行双向支付，即不仅可以向对方支付，还可以接受对方的支付。

闪电网络的支付隐私性：由于闪电网络的交易是在通道内进行的，不需要将所有交易都写入区块链，因此可以提高支付的隐私性。

闪电网络的限制（大都是状态与状态机实现技术的限制）：闪电网络还存在一些限制， 如通道的存活性、资金锁定时间等，需要综合考虑这些限制来设计合适的支付通道。

（2）在 RGB 中，与状态，状态机，状态通道相关的知识点有：

RGB 基于 LNP 和 BP 协议。有关于 RGB 是二层还是三层的讨论，如果是基于 BP 直接进行 RGB 的运算，则是直接扩展了比特币的图灵完备功能，属于第二层，这种方式对性能的扩展有限。如果是基于 LNP 进行 RGB 运算，则属于第三层（因为 LNP 是比特币的第二层）， 这种方式既能扩展性能又能扩展图灵完备的计算能力，只是技术实现上有一定的复杂度。通 常用组合的方式，既能扩展计算能力，又能扩展性能，还能降低实现的复杂度。

RGB 基于比特币或闪电网络中的状态通道技术。RGB 中的状态通道是指建立在 LNP 和 BP 之上的双方或多方之间的通信通道，可以在通道内进行多次交易和状态更新，减少了区 块链上的交易数量和费用。

RGB 中的状态通道使用了基于比特币的多签名脚本来锁定资金，并使用了特殊的交易类型来更新通道的状态。

RGB 中的状态通道可以应用于各种场景，如支付渠道、去中心化交易所、资产发行等， 提高了交易效率和用户体验。

RGB 中的状态通道通过更新通道状态来实现支付和资产转移，通道内的交易不需要被写入区块链，只有最终的状态会被写入区块链。

RGB 中的状态通道还可以实现更复杂的功能，如原子交换、支付路由等，通过智能合约和多签名脚本来实现。

RGB 中的状态通道可以与其他技术和协议结合使用，如闪电网络、LNURL 等，提供更丰富的功能和更好的用户体验。

RGB 中的状态通道的设计和实现需要考虑安全性、隐私性、扩展性等因素，以确保系统的可靠性和可用性。

（3）在 Nostr 中，与状态，状态机，和状态通道相关的概念。

在 Nostr 中因为传递的是信息，还没有体现状态（可信数据，数字货币）和状态机的概念。但相信 Nostr 这种分布式结构稍加改造，增加对状态的处理，会形成像闪电网络相似的 系统，这样的系统既可以传递信息，又可以专递价值。在 3.3 节 Web3.0 的应用架构图中也 描述了这种基于信息的分布式系统逐渐向包含价值处理的分布式系统转换的可能性。

当前 Nostr 的简单介绍：Nostr 中有两个主要组件，客户端和中继。每个用户运行一个客户端，通过中继和其他人联系。每个用户都由公钥来标识。用户发布的每个帖子都有签名。 每个客户端都会验证这些签名。客户端从他们选择的中继获取数据并将数据发布到他们选择 的中继。中继之间不相互通信，仅直接与用户通信。

（4）在分布式系统中，与状态机相关的知识点有：

状态机模型：状态机是一种数学模型，用于描述系统在不同状态之间的转换和行为。在分布式系统中，状态机模型常用于描述系统的行为和状态变化。

有限状态机（FSM）：有限状态机是一种最基本的状态机模型，它包含一组有限的状态和一组状态之间的转换规则。在分布式系统中，有限状态机可以描述系统的各种状态和状态 之间的转换。

状态转换：状态转换是指系统从一个状态转移到另一个状态的过程。在分布式系统中， 状态转换可能由各种事件或条件触发，例如接收到消息、超时等。

状态机的行为：状态机在不同的状态下可以定义不同的行为。在分布式系统中，状态机的行为可以包括处理消息、执行操作、发送消息等。

状态一致性：在分布式系统中，多个节点可能具有不同的状态。状态一致性是指在系统中保持各个节点的状态相互协调和一致。

分布式状态机（DSM）：分布式状态机是指将状态机模型应用于分布式系统中的一种技术。它可以将系统的状态和状态转换分布在多个节点上，并确保节点之间的状态一致性。

原子状态机（ASM）：原子状态机是指在状态转换过程中保持原子性的状态机。在分布式系统中，原子状态机可以保证系统在状态转换过程中的一致性和可靠性。

一致性协议：一致性协议是一种用于保证分布式系统中状态一致性的协议。常见的一致性协议有 Paxos、Raft、ZAB 等。

容错性：分布式状态机需要具备容错性，即在节点故障或消息丢失的情况下，系统仍然能够保持正确的状态和行为。

可扩展性：分布式状态机需要具备可扩展性，即能够在系统规模扩大时仍然保持高效的状态转换和一致性。 

2.3. 状态机与区块链系统

通过以太坊的文档《Ethereum EVM illustrated》，每个区块都是一组触发状态，整个以太坊系统都是一个状态处理机。在 1.2 中，我们介绍了区块链系统中的状态机内容。在以太 坊的白皮书中也有很多状态机的描述。

状态机虽然有很强的处理能力，但上限是区块链结构的这个天花板。

对于基于 UTXO 模型和基于账号模型（类 EVM）的区块链互联组合应用时，状态与状态机的实现方式有较大的不同。基于 UTXO 模型的区块链比较容易与分布式系统结合，是因为 中两种系统中的状态都是基于 UTXO ，不存在转换或仅需要简单转换，比较容易实现。基于 账号模型的链，因为其状态与外面分布式系统之间的状态需要进一步的封装与转换，实现有 复杂度，这也是以太坊上雷电网络发展不顺利的部分原因。 

2.4. 状态机与中心化系统 

使用区块链+ 中心化系统的案例有类似 Ordinals ，中心化交易所 CEX。

这样的系统相对简单，有些根本不存在状态传递，类似 Ordinals ，仅仅使用中心化索引完成统计工作。

像中心化交易所，其中的状态传递，完全依赖中心化系统设定的规则，里面的状态机也是中心化系统程序构成的状态处理机，没有复杂的概念。

在未来 Web3.0 的应用中，应该会出现较多使用区块链+ 中心化系统的案例。 

3. Web3 应用的结构应该是什么样子 

通过文章前面的内容，我们知道了通过三种比特币二层架构的组合可以完成更复杂的结构设计，从而得到需要的特性需求。而且从业务角度，如果应用的底层逻辑可以分解成状态与状态机，便可以使用三种系统的组合来完成上层的整个业务逻辑。

那么这些常见的组合会有哪些？哪些因素会决定组合的结构？我们从常见的应用分类和应用需求来推测满足 Web3.0 的大规模应用的结构。

3.1. 常见应用的分类

我们以第 48 次《中国互联网络发展状况统计报告》中的应用统计为参考， 以下简称统计报告。因为 Web2.0 已经发展成熟，不影响应用分类与用户规模的结果分析，我们使用的 应用参考数据是 2020 年与 2021 年的旧数据。需要注意的一点是，这仅仅是中国互联网的统 计数据，在 Web3.0 阶段，很多应用都是在全球范围，用户的规模和性能要求更高。

在统计报告中，可以看到 Web2.0 中的应用已经非常丰富，并且拥有巨大的用户群体。 这些应用包括：即时通讯、网络视频、短视频、网络支付、网络购物、搜索引擎、网络新闻、 网络音乐、网络直播、网络游戏、网上外卖、网络文学、网约车、在线办公、在线旅行预定、 在线教育、在线医疗、… … ，几乎覆盖了人们生活的全部领域。除了这些消费互联网的内容， 在产业互联网中也有很多的应用。 

如果 Web2.0 全部应用都迁移到 Web3.0 ，绝大多数对性能的要求是很高的。以 Visa 支付为例，高峰期的性能需求为： 65000 TPS，这样的性能指标只有分布式系统才能支持，例如， 当前闪电网络每秒 4000 万笔的性能，而且闪电网络的性能在理论上还没有上限。

此外，我们以常见的游戏为例，当前区块链上最高 TPS 的全链游戏可实现峰值在几千 TPS 左右，与数十万级 TPS 的传统 Web2 3A 游戏存在巨大差距。如果要将所有的游戏迁移到 Web3.0 ，需要的基础设施性能会是一个很大的挑战。

何况游戏在常见的应用分类中只是一种应用，其他的应用还有更多的性能与特定需求。 

3.2. Web3.0 应用的需求 

了解应用的需求，使用收入结构这个指标会更直接。我们参考《Token Terminal, curated by FutureMoney Research 2022 Q2》报告，这个报告虽然稍早，但像支付和其他应用都在初 级阶段，不影响主要的分析结果。所以作者在这个地方偷懒了，使用了我写作 Web3.0 图书 时候的数据，如果有 2023 年 Q4 的数据会更准确一些。

（1）通过收入报告的需求分析

报告里面的收入分类比较好的代表了当前 Web3.0 的核心产品构成。如图所示。

1) Layer 1 （区块链中的基础主链）的收入 48% ， 占比接近总收入的一半，其商业模式可以理解为“ 出售区块空间 ”；

2) NFT 交易平台收入占比为 22% ，其商业模式可以理解为版税抽佣或营销活动变现； 

3) DeFi 中的 Dex 收入占比为 15% ，其商业模式是交易手续费和流动性做市收入；

4) DeFi 中的 Staking 类收入占比为 8% ，其商业模式是资产管理的提成或利差； 

5) Gamefi 占比是 5% ，其商业模式是版税抽佣，转账手续费，销售 NFT 等；

6) DeFi 中的 Lending 收入占比约为 1% ，其商业模式是利差；

7) Tooling 的收入占比约为 1% ，其商业模式是服务费，未来还会包含流量变现费用；

其他和 Web3.0 相关的产业，不是 Web3.0 的应用，不算 Web3.0 的核心产业，不记入。 例如：Web3.0 的媒体、研究组织、培训组织等。

从收入结构可以看到当前 BTC 生态的应用需求基本上都可以靠区块链和它的二层系统来解决，还不需要复杂的系统架构。但 Gamefi 和 SocialFi 发展比较快，我们使用参考文献中 的游戏例子，可以看到大型的游戏已经对系统结构有了更高的明确需求。

从收入结构可以看到当前 BTC 生态的应用需求，值得把在以太坊等生态的产品都重做一遍。稍加改造以太坊生态上基于链的二层建设技术，在比特币上建立新二层，能够比较好的 完成这些初级需求，只是在去中心化程度、安全性、隐私性、抗审查性做了一定的妥协。在 《一文梳理比特币二层（Layer 2）建设的基础知识体系》那些新的基于 EVM 类型的二层建 设都是这种情况的案例。

（2）对高性能需求的应用使用游戏案例的分析

在文章《不可能变为可能：让全链游戏开发在闪电网络上的成为现实》，对功能与性能都提出了较大的需求。Web3.0 应用的真正架构也逐渐浮出水面。

文章中的问题描述：全链游戏在保证安全性、隐私性和去中心化的基础上，可扩展性始终没有找到最优解决方案。例如最热门的全链游戏引擎 Mud  和 Dojo ，致力于帮助全链游 戏实现更高的 TPS ，但玩家每次操作仍需要 2 秒以上的缓冲。事实上，当前区块链上最高 TPS 的全链游戏可实现峰值在几千 TPS 左右，与数十万级 TPS 的传统 Web2 3A 游戏存在巨 大差距。在追求不损失区块链优势的前提下，全链游戏以克服的可扩展性。

后面技术讨论的解决方案中，使用闪电网络和 RGB 扩展性能，同时也提出了临时链和专用链的概念。

Ephemeral chain（临时链）

临时区块链可以定义为不会永远存在的区块链，一旦区块链的目的实现（例如记录交易），或者一旦其状态永久存储在其他地方，它们就会被销毁。临时链存储的终止状态只是有关临  时链相关终止事实的数据，因此将所有内容压缩了相当大的数量级。临时链主要受区块链上  交易延迟和吞吐量限制。

临时链 VS  状态通道

就临时链而言，由于公共链上有状态，我们最终将拥有大量用户。需要插入公链的状态会通过剪枝/压缩/差异提取来减小大小，然后定期而不是不定期地保存在公链上。RGB  状态 通道的设置有可能绕过临时链的性能约束，实现和临时链相同的功能。

App-specific blockchains（特定应用程序区块链）

特定于应用程序的区块链是为运行单个去中心化应用程序（dapp）而创建的区块链。 开发人员不是在现有区块链上构建，而是使用自定义虚拟机 (VM)  从头开始构建新的区块链， 该虚拟机执行用户与应用程序交互的交易。开发人员还可以定制区块链网络堆栈的不同元素  — —共识、网络和执行— —以满足特定的设计要求。提升智能合约执行速度，解决计算资源  限制可以帮助特定应用程序区块链落地。允许开发人员为不同的用例定制基础设施，使开发  变得更容易。同时允许 web3 开发人员构建强大的价值模型并扩展其 dapp   以满足指数级  增长的需求，激发更多创新。

通过这个游戏的案例，加上我们前面几种架构的分析，我们可以大致判断未来大规模应用的架构。 

3.3. 满足 Web3.0 大规模应用的架构应该是什么样子

前面内容我们了解了 Web2.0 中的常见应用分类，这些应用都升级到 Web3.0 ，才是全面进入 Web3.0 时代的标志。什么的架构才能满足上面的众多应用呢？

（1）简单的 Web2.0 与 Web3.0 的架构区别

这里参考了区块链女神 Preethi  Kasireddy 写的文章《 The Architecture of a Web 3.0 application》 内容。这里对于 Web3.0 应用的结构描述是一种很简单的，仅依赖于区块链系 统就成完成的结构。但这种结构过于简单，还没有体现二层建设，在大规模应用中不能胜任。

对传统中心化产品技术实现与 Web3.0 产品的技术实现案例，进行差异对比，会更容易理解技术实现上两者的差异。结合 Gavin Wood 对 Web3.0 的技术栈愿景描述，我们可以看 到 Web3.0 的技术实现最大差异在后台，用户的体验层差异比较小。

（2）Web3.0 时代大规模应用的系统架构

在没有区块链的时代，应用是建立在中心化系统和分布式系统之上的。例如，建立在中心化系统上的商城、IM、视频等应用，建立在分布式系统上的迅雷下载。

有了区块链系统后，我们进入 Web3.0 时代，这个时期的应用是建立在区块链系统、分布式系统、中心化系统之上的一个复杂架构。其中区块链系统与其二层扩展完成价值的传递 与处理，分布式系统和中心化系统完成信息的传递与处理。

如下图所示，

 

具体内容描述如下：

（1） 比特币主网与二层建设是所有价值的中心，大部分的价值都建立在这个网络之上。比特币二层建设中，基于链的二层完成价值的性能扩展与处理，处理的都是全量账本数据。比特币二层建设中，基于分布式系统的二层建设完成性能的扩展，处理的都是局部相关数据，使用相关者共识，但最终计算结果需要落地到区块链系统。比特币二层建设中，基于中心化系统的二层建设，直接为上层应用提供服务。

（2）类 RGB 系统还会需要一些临时链或中间链，完成账本的结算功能，如图中的蓝线所示。在参考文献 1 中的游戏案例就有这种场景的描述。还没有大规模出现是因为类 RGB 系统建设复杂，还没有到成熟期。

（3）除了比特币生态，还有其他区块链系统的生态，完成不同业务场景的需求。如我们在二层基础架构的文章中所描述，基于链的二层会存在众多项目，对于非比特币生 态的链也同样适用。其他区块链系统和二层同样可以进入闪电网络与 RGB，随着技术成 熟度上升这种情况就会逐渐出现。

（4）在 Web3.0 生态中，中心化系统也会有一席之地，只是不再像 Web2.0 中的比例那样大。中心化系统有不少的优势。

（5）在实际应用中，上图内部的连线会加复杂，有些不需要使用二层，而直接对一层网络操作，如 RGB 在使用 BP 协议时。其他区块链也可能会使用分布式系统，如以太坊 上的雷电网络，虽然不成熟，如果有需求场景，通过改造一些基础特性也会有使用场景。 上图是对 Web3.0 应用架构的一个简化描述。

3.4. 可行的建设路径

从收入结构可以看到当前 BTC 生态的应用需求，从常用应用的分类，我们可以看到未来完全进入 Web3.0 的需求。这会是一条漫长的道路。所以对于这种建设周期比较长的事物， 都需要分阶段来处理。

这里的三个阶段和大山老师所说的短期、中期、长期非常相似。只是把基于链的二层建设的简单阶段也归纳到了第一阶段建设中。 

（1）第一阶段是基于铭文和基于链的二层建设的前期

基于铭文和基于链的二层建设，因为相对容易，当前出现了众多的应用。不管是 brc 20 ， src 20 ，arc 20 ，铭文等应用，还是那些基于链的二层建设项目方，都很丰富。

这一阶段建设相对简单，多数是金融应用，并且有改造与模仿以太坊二层的经验加持，很更容易更快。虽然相对简单，但这个过程必不可少，而且很重要，他们帮忙繁荣了生态，引来了流量和资金，测试了跨链连接技术，测试了稳定币，测试了各种可能性。这一阶段主要是完成功能可行性的各种验证。

（2）第二阶段是基于链的二层建设的中后期与基于分布式系统的二层建设

在这个阶段，基于链的二层建设也参与其中，是基于链的建设的高级阶段，此外，第二阶段重点是测试和完善多种分布式的二层建设。闪电网络会更加成熟，RGB 功能和稳定性得到较大的改善，应用场景都会更丰富。类 RGB 的竞争者也会逐渐出现与成熟，如 BitVM 。同时像 Nostr 这样的分布式系统也会融入价值功能。这一阶段主要是完成功能和性能可行性的各种验证。 

（3）基于比特币生态的大规模建设

最后一个阶段是成熟阶段，这个阶段 Web3.0 开始大量建设，并逐渐成熟。在 3.1 中描述的常见应用都开始进入 Web3.0 时代。

也许这个阶段要较长时间才能到来，也许遇到一个拐点事件，能够推动大批的 Web2.0 应用者进入，时间也许会不那么长久。

不管如何，真正的 Web3.0 时代来临的时候，一定会有很大的不同，功能与产值比当前 的 PC 互联网+移动互联网的总体还要大，还要辉煌。也许就像 AI 领域 Sora 的出现，非常惊艳，让人震惊，只是过程没有那么突然。 

参考文献说明

（1）参考了大山老师对于比特币生态短期、中期、长期的相关文章与课程内容。 

（2）《不可能变为可能：让全链游戏开发在闪电网络上的成为现实》https://m.jinse.cn/news/blockchain/3667669.html  （受这篇文章的启发与验证作用更大） 

（3）三种观察角度主要参考《Ethereum EVM illustrated》，Takenobu T. ， 2018.3 

（4）应用分类相关内容，主要参考作者 2022 年写作的《Web3.0 ：构建元宇宙的数字未来》。 

（5）参考了大学数字逻辑中的图论知识。

（6）参考了一些分布式系统的文章内容。