原文作者：付少庆，SatoshiLab，万物岛 BTC 工作室
1. 前言
当我写完了《彻底理解比特币“隔离见证”技术与它的三个版本升级》那篇文章，引起了我的深度思考。
比特币从诞生以来就一直在扩容与扩能两个方向上在不断探索。直到 TAP（TaprootAssets Protocol）协议的出现，应该是为比特币的扩容与扩能打下了坚实的架构基础和可行路线。当前 TAP 可以让扩容发展到无限数据空间，那么扩能是否也可以达到无限，即图灵完备呢？我们从理论和现实可以探索的路径上做一些分析。如果比特币可以实现完全的扩容与扩能，那么万链归一的情况就会出现。这个过程会是持续、漫长、并充满挑战的，需要众人的智慧与实践。欢迎感兴趣的朋友一起讨论这个问题，并参与其中的建设。
2. 第三次隔离见证打开了新大门
先给出一个简单的结论：第三次隔离见证打开的新大门是，可以使用的无限数据空间，可以发展出图灵完备的虚拟机 VM。
我们先回顾第三次隔离见证技术产生的重要变化，再从分层协议的角度看待比特币的进一步发展。
2.1. TaprootAssets 协议打下了哪些基础？
从我写作的上一篇文章《彻底理解比特币“隔离见证”技术与它的三个版本升级》中，可以看到早期的 OP_RETURN 探索，以及后面的三次隔离见证版本变化。如下图所示：
我们会看到隔离见证的第三次升级 TAP 协议产生了两个重要的变化：
1. 已经在扩容上可以达到极限——使用无限的数据空间。
2. 在架构上将 BTCscript 的 VM 与 TAP 的 VM 进行了分离，这为今后功能的发展打下了良好的架构基础。
可以在不影响比特币主网的情况下，独立的探索在比特币网络上实现图灵完备的可能性，并且这种探索可以循序渐进的方式进行。
本文会沿着比特币的扩能可能性进行分析，如果在 TAP 技术的支持下，比特币的扩容与扩能都可以达到终极目标，就会为比特币的广泛应用打下坚实的基础。
2.2. 比特币的发展需要分层协议设计思想
比特币如果想要有全球的影响力，那么它一定要有巨大的应用场景，形成一个庞大的生态。对于这样的大型系统和复杂系统，我们人类已经有相关的经验与方法论，也就是分层设计思想。如 TCP/IP 这样的协议中，已经有非常好的应用案例与参考经验。
在我写作的《一文梳理比特币二层（Layer2）建设的基础知识体系 V2.0 版》文章中有对分层协议的更详细描述。分层设计是一种人类处理复杂系统的手段和方法论，通过将系统划分为多个层次结构并定义各层之间的关系和功能，以实现系统的模块化、可维护性和可扩展性，从而提高系统的设计效率和可靠性。
协议分层的优点： 各层次之间是独立的、灵活性好、结构上可分割开、易于实现和维护、能促进标准化工作 。
分层模块化设计思想是技术领域对待一项功能庞大，需要多人协作，并不断改进工程项目的常见处理方法，并且是经过实践检验，行之有效的方法。人类历史上成功的大型分层协议代表是 TCP/IP 协议，它使得整个互联网都在这个协议基础上建立。
未来 web3.0（也可以成为价值互联网）将会在比特币为一层网络的基础上建立。比特币的分层设计思想已经有了初步的发展。现在已经有了多种探索的二层案例，其中典型的是基于链的二层和基于分布式系统的二层（如闪电网络），还有基于 LNP/BP 协议的 RGB，当 RGB 基于 BP 协议时，它是一个二层，当 RGB 基于 LNP 协议时，它是一个三层。
但这次 TAP 给带来的变化，并没有那么像分层协议，更像一个事物的 1.0 与 2.0 的发展。原因是 TAP 协议和比特币主网是那么的相似与连接紧密，表现为如下几点：
1. 在数据的结构上 TAP 也采用和主网一样的 UTXO 结构，称为 vUTXO。这些 vUTXO 的创建、转移、合并、拆分都与比特币主网保持一致，并且可以与主网的 UTXO 进行去中心化的 Swap。从 SegWit 中的 vByte，到 TAP 中的 vUTXO，是同一种设计思想的延续发展。
2. 在地址类型和执行的脚本指令方面，TAP 也与比特币主网保持高度的相似性，并且架构上留下了扩展的空间。不仅可以恢复比特币主网放弃的指令，还可以根据需求增加新指令。并且这些指令在一个独立的虚拟机 VM 中执行。
3. 使用比特币主网的共识协议。TAP 虽然在扩容与扩能上做出了很多突破，但它并不是一个独立的区块链，也不是一个独立的外部系统，它的所有变化需要使用比特币主网的共识协议，是依靠比特币主网运行的扩展部分。
所以在设计 TAP 相关的功能时候我们采用分层协议的方法论来看待 TAP 协议和处理组织分工，但从事物进化的角度，我们将这次变化看待成 BTC2.0 的发展会更容易保持两者之间的紧密关系和依赖关系，而且容易协调与安排 BTC2.0 发展需要的资源。
如果从上面的三个角度分析 RGB 协议，我们能看到明星的区别。RGB 协议完全不具有 1，2 两个特点，只有在使用比特币主网的共识协议方面有相似性，这决定了 RGB 是一个完全的分层协议，而不是比特币主网的延续发展。
3. BTC1.0 与 BTC2.0
TAP 协议带来的巨大变化，为比特币的新发展提供了一个很好的基础与开端。从上一节的分析，可以看出比特币主网与 TAP 的紧密依赖关系，在本文中我使用 BTC1.0 与 BTC2.0 来区分比特币主网，以及 TAP 产生后带来比特币网络的扩展变化。
3.1. 基础定义
在这里我们将 BTC1.0 定义成在比特币主网上的发展，所有在比特币主网上的变更与探索都是 BTC1.0 的范围。在 TAP 技术出现之前，几乎所有的探索都是基于 BTC1.0 的探索。包括比特币的各种分叉链，也是为了验证 BTC1.0 的某些可能性。
BTC2.0 定义为在比特币主网之外，特别是像 TAP 这样协议的探索（也许以后还会有其他类似的协议）。这一范围不涉及比特币主网的变动，主要是在比特币主网之外，进行的扩容与扩能的探索，但又非常依赖比特币主网的共识协议与基础特征，它与比特币主网关系极其紧密，很难用独立的概念来划分出去的比特币发展。
3.2. 如何区分
BTC1.0 的发展原则是保持比特币一层主网的基础特性，如去中心化能力，抗审查能力，隐私性等，保证比特币主网安全稳定的运行。如果从这个发展原则没有描述清楚或明显区分，要从分层协议的角度看最底层协议应该具有的特性。从最底层协议的特点考虑，几乎所有期望扩充指令，完成图灵完备的计算都不符合 BTC1.0 的发展原则。也可以从编译原理的角度，看所有期望将一个虚拟机发展到第二阶段（引入状态和条件分支）等努力都是不符合原则的。并且从这个标准看，比特币历史上的删减指令，是保持更严格的 BTC1.0 标准。
BTC2.0 的发展原则是满足所有想在比特币一层主网上期望做的改动需求，但又违反 BTC1.0 发展原则的部分。例如，扩展 OP_CAT 指令；期望把比特币主网发展成为图灵完备的系统等需求。也可以描述成所有不适合在比特币主网做的扩容与扩能需求，都可以在 BTC2.0 来发展。
在 TAP 协议中，已经通过 universe 将空间扩充到了无限，那么只剩下是否将 TAP-VM 发展成图灵完备这个问题。在下一节内容中我们主要分析 TAP-VM 发展成图灵完备的可能性与可能分成哪几个阶段。
注释：TAP 是一个完整的协议，包括 TAP-VM，所以后续内容都使用 TAP 这个词语。
- TAP 发展成图灵完备的几个阶段
讨论 TAP 要发展成图灵完备是一个非常专业的问题，它涉及了编程语言和虚拟机设计的核心知识。从编译原理的理论和编译器的发展历史来看，一个虚拟机（VM）从非图灵完备发展到图灵完备，通常会经历一个 由简到繁、由安全到强大、由专用到通用 的演化过程。（这句话将在本文中重复多次）
从编译原理的理论分析看，一个虚拟机肯定是可以从非图灵完备发展到图灵完备的。这样就只剩下个问题 TAP 是否有发展成图灵完备系统的必要性？（这个问题不在本文中讨论）
如果 TAP 一定要发展到图灵完备，那么它的发展过程有哪些可以遵循与借鉴的过程与方法？
4.1. 从编译原理看图灵完备
图灵完备：一切可计算的问题都能计算，这样的虚拟机或者编程语言称为图灵完备的。一个能计算出每个图灵可计算函数（Turing-computable function）的计算系统被称为图灵完备的。一个语言是图灵完备的，意味着该语言的计算能力与一个通用图灵机 （Universal Turing Machine）相当，这也是现代计算机语言所能拥有的最高能力。
在可计算理论中，当一组数据操作的规则（一组指令集，编程语言，或者元胞自动机）满足任意数据按照一定的顺序可以计算出结果，被称为图灵完备（turing complete）。一个有图灵完备指令集的设备被定义为通用计算机。如果是图灵完备的，它（计算机设备）有能力执行条件跳转（“if” 和 “goto”语句）以及改变内存数据。如果某个东西展现出了图灵完备，它就有能力表现出可以模拟原始计算机，而即使最简单的计算机也能模拟出最复杂的计算机。所有的通用编程语言和现代计算机的指令集都是图灵完备的（C++ template 就是图灵完备的），都能解决内存有限的问题。图灵完备的机器都被定义有无限内存，但是机器指令集却通常定义为只工作在特定的，有限数量的 RAM 上。
一个虚拟机（VM）从非图灵完备发展到图灵完备，通常会经历一个由简到繁、由安全到强大、由专用到通用的演化过程。这包含两个主要问题：
1.为什么要从非图灵完备开始？ 为了安全和可靠性。非图灵完备的系统可以保证所有程序都会终止（Halting Problem 可判定），不会有无限循环，这对于诸如智能合约、配置语言、模板引擎等场景至关重要。
2.为什么要向图灵完备发展？ 为了表现力和功能性。只有图灵完备的系统才能实现各种复杂的逻辑和算法，成为一个通用的编程平台。
因此，一个 VM 从非图灵完备发展到图灵完备， 本质上是其设计目标从“绝对安全可控”向“强大通用”扩展的过程 。而现代 VM 的最高追求，是尝试同时兼具两者：即在提供图灵完备的强大能力的同时，通过精巧的设计最大限度地保留安全性和可控性。
4.2. 一个 VM 从非图灵完备发展到图灵完备的几个明显阶段
一个虚拟机（VM）从非图灵完备发展到图灵完备，通常会经历一个由简到繁、由安全到强大、由专用到通用的演化过程。我们可以将其概括为以下几个典型的阶段：
1. 阶段一：纯粹计算器（非图灵完备）
特征：只有基本的表达式计算能力，无状态、无控制流。
- 能力：支持基本的算术运算（加减乘除）、逻辑运算、位运算等。它像一个高级计算器，每次计算都是独立的，不依赖于之前的状态。
- 无状态性：没有内存的概念，或者内存是只读的，无法修改。无法定义和修改变量。
- 无控制流：没有条件分支（if/else）、循环（for/while）或跳转指令。指令只能顺序执行。
- 为何非图灵完备：无法实现循环或条件判断，无法模拟图灵机无限长的纸带和状态转换。
- 历史实例：最早的某些极其简单的配置或表达式求值引擎。
2. 阶段二：引入状态和条件分支（迈向完备的关键一步）
特征：增加了可变状态（内存）和简单的条件判断，但缺乏真正的循环。
能力：
(1) 状态（State）：引入了可读写的内存（如栈、寄存器、堆），可以定义和修改变量。这使得计算可以依赖于历史，而不再是孤立的。
(2) 条件分支（Conditional Branching）：引入了基于条件的跳转指令（如 if_eq, if_lt, jmp 到指定偏移量）。这是实现逻辑判断的关键。
- 为何仍可能非图灵完备：如果该 VM 的指令集或设计刻意禁止了向后跳转（backward jump），即只能跳转到后续的指令（向前跳转），那么它就无法形成循环。没有循环，就无法实现图灵完备所要求的“无限计算”潜力（尽管物理上是有限的，但理论模型上是无限的）。
- 历史/现代实例：比特币的脚本语言（Bitcoin Script）在早期就是一个经典的例子。它被刻意设计为无循环，只有条件分支和向前跳转，以防止无限循环代码阻塞网络，从而保证了脚本一定能在有限步骤内执行完毕。
注释：我个人认为比特币的脚本语言主要功能都处于阶段一，有一小部分阶段二的特征。如果用比例来说明，大致是阶段一占比大于 90%，阶段二占比小于 10%。像后来在 Taproot 中引入的 MAST（默克尔抽象语法树），在比特币主网并不能很好的发挥作用，反而会在 TAP 中发挥强大的作用。很大的原因也是比特币主网要尽量保持虚拟机限制在阶段一的能力范围内。
3. 阶段三：引入循环或递归（实现图灵完备）
特征： 提供了形成循环结构的能力。
能力：
(1) 向后跳转（Backward Jump）： 允许跳转指令跳回到之前的指令地址。这直接可以形成循环。
(2) 循环指令： 提供专门的循环指令（如 loop）。
(3) 间接跳转/函数调用： 通过支持函数调用和递归，同样可以实现循环的效果。因为递归可以等价地替代循环。
- 为何此时图灵完备：一旦拥有了条件分支和向后跳转/循环/递归的能力，这个 VM 就具备了实现条件判断和重复执行的能力。这两者结合，理论上就可以模拟任何图灵机的计算过程，从而达到了图灵完备。
- 历史实例：几乎所有通用语言的虚拟机（如 JVM, Python VM, .NET CLR）从诞生之初就是图灵完备的，因为它们的设计目标就是运行通用编程语言。它们的演进更多是性能和安全特性的增强。
4. 阶段四：在图灵完备基础上增强（安全、性能、特性）
一旦达到图灵完备，VM 的发展重点就不再是计算能力，而是其他方面：
- 性能：引入 JIT（即时编译）、AOT（预先编译）、优化编译器、更高效的垃圾回收算法等。
- 安全性：强化沙箱机制、引入能力系统（Capability System）、更精细的内存隔离和控制。WebAssembly 是一个绝佳的现代例子，它在提供图灵完备能力的同时，通过线性内存、结构化控制流和沙箱环境等手段，极大地增强了安全性和确定性。
- 特性：支持协程（Coroutine）、异步/等待（Async/Await）、泛型、反射等高级语言特性。
- 确定性：对于一些区块链虚拟机（如 Ethereum EVM 的后继者），在图灵完备的基础上，追求执行结果的确定性（所有节点结果一致）和可终止性（通过 Gas 机制限制实际执行步骤）成为重点。
从编译原理的的专业知识，我们可以看到 VM 发展的四个阶段。参考这个发展路线，我们也可以大致看到 TAP 发展的几个阶段（也就是 BTC2.0 发展的几个阶段）。
4.3. TAP 的第一阶段：轻度探索扩展 BTCScript 的指令
前面我们提到早期比特币主网指令超出了它能力的范围，已经部分像通用 VM 的第二个阶段能力范围，这导致了后面的删减指令行为。精简指令后的比特币主网上的 BTCScript 指令满足了编译原理中的第一阶段能力要求，这些都是为了保证比特币主网的安全性与稳定性。
既然 TAP 是 BTC2.0 的开端，从编译原理的阶段区分看，当前的 TAP-VM 应该向通用 VM 的第二阶段发展。TAP-VM 在探索这个阶段的时候，可以适当的扩展 BTCScript 的指令，恢复到原来删除的 BTCScript 指令，如，开始逐渐添加类似 OP_CAT 这样的大众期望的指令。每增加一个指令都需要较多的应用来检测其功能与安全性。这个阶段可以完成像 TrustlessSwap 这样的简单操作。还可以增加对 Taproot 中技术的使用场景，如，使用更功能多样的 MAST 树。
这一阶段应该会满足初级的 BTCFi 的功能，如，简单的去中心化交易，简单的借贷功能，简单的质押功能。目前通过 TrustlessSwap 以及部分 Tapscript 可以实现这些功能。
4.4. TAP 的第二阶段：构建满足去中心化的 BTCFi 指令集
TAP-VM 发展到支持大部分的金融应用，需要增加多少指令，需要从编译原理和应用两个方向推导。但这个阶段肯定不需要图灵完备。这个阶段需要满足常见的 BTCFi 应用，如 Lending，Staking，Mint StableCoin，更复杂的 Swap 等功能。
这个阶段很接近通用 VM 的第二个阶段，需要引入状态与条件分支。在 MAST 抽象语法树中，就是引入了这样的状态与条件分支。虽然在 BTC1.0 的 Taproot 技术中就有了这样的 MAST 树，但只有当比特币主网的 BTC-VM 与独立的 TAP-VM 分离后，这些条件语句才能有更好发挥出作用。
4.5. TAP 的第三阶段：更加丰富的指令集与初步图灵完备
TAP-VM 发展到支持金融应用之上的更复杂的应用，这依赖于应用对 TAP-VM 的推动作用，这个阶段会逐渐接近图灵完备或初步的图灵完备。
在这个阶段，从编译原理的角度看，会发展到通用 VM 的阶段三，开始引入循环和递归等特性，能够实现向后跳转与间接跳转，专门的循环指令，甚至出现函数功能。加上阶段二能够支持的条件与分支功能，此时的 TAP-VM 理论上就可以模拟所有的计算，从而达到图灵完备。或者因为发展的过程原因，处于图灵完备的前期，但其已经具有丰富的指令集，能够完成复杂的功能。
但即使 TAP-VM 在这个阶段能发展到图灵完备，和 RGB 的图灵完备也有明显的区别。大概会像 C++与 Java 之类的语言对比，5.1 中我们有更详细的对比。
4.6. TAP 的第四阶段：成熟的图灵完备+丰富的 Lib 库
TAP-VM 发展到这个阶段，不仅完成了图灵完备，并且开始有丰富的类库（或函数库）理论上能完成所有的应用功能，并具有比较丰富的案例。因为有了丰富的应用案例与类库支持，开发者更容易开发出大量的应用。
这个阶段的 TAP-VM，就像通用 VM 的第四阶段任务一样，其发展重点已经不是计算能力，而是性能、安全性、确定性等更高的虚拟机指标。这会不会是一个比较遥远的过程？
发展到这个阶段，TAP 的功能因为非常强大，会出现很多与 RGB 交叠的领域。很多应用既可以用 TAP 来实现，也可以用 RGB 来实现。这种交叠部分主要集中在金融应用部分，尤其是基于比特币主网发行的资产。但 TAP 与 RGB 在大的应用场景下，依然有很大的区别。我们在下一节来大致分析一下这种区别。
5. 图灵完备的系统也有不同的应用场景
在 BTC 的生态中，我们主要参考两种图灵完备的系统对比：TAP 与 RGB，从而说明适合不同的应用场景，或者更好的说明 TAP 的应用场景。
根据 web2 领域的经验和关于 VM 的丰富数据，C/C++开发语言+运行环境可以很好的与 Java 开发语言+运行环境形成对比。这种对比，与 TAP 与 RGB 的对比有一定的参考性。
5.1. C/C++ 与 Java 的应用场景对比
核心特性对比表
应用场景总结
1. C/C++ 的主场（需要直接操作硬件或极致性能）
(1) 系统级软件/基础设施开发
- 操作系统（如 Linux、Windows 内核）
- 数据库管理系统（如 MySQL、PostgreSQL）
- 编译器/解释器（如 GCC、JVM 自身其实是用 C++写的）
- Web 服务器/高性能网络框架（如 Nginx、Node.js 底层）
(2) 硬件驱动与嵌入式系统
- 设备驱动程序：需要直接与硬件寄存器交互。
- 嵌入式/物联网（IoT）设备：资源极度受限（如单片机 MCU），需要精确控制内存和功耗，无法承担 JVM 的开销。
(3) 高性能计算与游戏开发
- 游戏引擎（如 Unreal, Unity 的底层）：需要榨干硬件性能，进行复杂的图形和物理计算。
- 科学计算/金融交易系统：微秒级的延迟都至关重要。
- 图形/图像/音视频处理：如 Photoshop、FFmpeg。
(4) 需要精细控制内存和资源的场景
在某些场景下，手动管理内存比垃圾回收更可预测，可以避免 GC 带来的延迟抖动。
2. Java 的主场（需要高开发效率、跨平台和企业级可靠性）
(1) 大型企业级应用后端开发
- Web 应用后端：Spring Boot 框架是 Java 在企业级开发中的绝对霸主，用于构建大型、分布式、高并发的后端服务。
- 微服务架构：大量基于 Java 和 JVM 的微服务框架（如 Spring Cloud）。
- 分布式系统：如大数据领域的 Hadoop、消息队列 Kafka。
(2) Android 应用开发
Android 官方历史首选语言（虽然现在 Kotlin 已成为首选，但底层大量代码和生态仍是 Java）。
(3) 大数据与云计算
Hadoop、Spark、Flink 等大数据处理框架的核心组件大多用 Java 或 Scala（JVM 语言）编写。
(4) 需要高可靠性、长生命周期的系统
银行、金融、电商等核心系统，其健壮性、安全性和强大的社区生态支持至关重要。
(5) 跨平台桌面应用
虽然不如 Web 流行，但 Swing/JavaFX 仍可用于开发跨平台的 GUI 程序。
3. 如何选择？
- 选择 C/C++ 当：
性能是绝对第一要求（游戏、交易系统）。
你需要直接与操作系统或硬件交互（驱动、嵌入式）。
资源极其有限，无法承受 JVM 的内存和 CPU 开销。
你对程序的行为需要有绝对的控制力（内存布局、执行流程）。
- 选择 Java 当：
你要开发大型、复杂的企业级应用（Web 后端、微服务）。
开发效率、可维护性和团队协作比极致的性能更重要。
你需要强大的跨平台能力，且不希望为每个平台单独编译。
你希望避免内存管理错误，享受丰富的开源库和框架生态。
项目要求高可靠性和长期稳定的运行。
简单总结：C/C++是适合更接近于底层，硬件层或操作系统层；Java 更适合接近业务层与应用层。
5.2. TAP 与 RGB 的应用场景对比
核心特性对比表（希望今后借助大家的力量逐渐完善这个对比表）
应用场景总结（以下均为根据特性的推测，因为 TAP-VM 还没有完全发展，RGB 还没有更多的应用案例）
1. TAP 的主场（需要比特币特性的基础功能）
(1) 现金模型的资产发行
(2) 比特币网络上的 BTCFi
(3) 去中心化的底层协议
2. RGB 的主场（几乎适合所有的 Dapp 类型）
(1) 比特币网络上的智能合约应用
(2) 更高级，更复杂的资产发行与 DeFi 应用
(3) 更高级别的 web3 应用，如去中心化身份、DAO 治理等应用
(4) 其他更广泛的 web3 应用
3. 如何选择？
- 选择 TAP-VM：
直接与比特币 UTXO 进行的交互。
现金模型的资产发行。
直接扩展比特币脚本类型的功能。
去中心化的比特币金融应用。
- 选择 RGB：
需要复杂逻辑的智能合约。
更高级级别更复杂的 DeFi。
非金融的 Web3 应用。
简单总结：TAP-VM 更接近比特币主网的应用，或基于比特币主网的直接扩展应用；RGB 适合逻辑功能复杂，更贴近用户层的应用。
6. 如何能更好的发展 BTC2.0
本节内容更多地凭借个人的主观判断来做的一些描述，主要来自于作者以往的工作经验和项目工程化经验。所以一定会有不足与偏差，希望能够听到更多的声音，来完善这种预测与判断，尤其是期望听到在这个领域开发产品项目方的意见。
通过前面的讨论，如果我们可以将比特币分为 BTC1.0 阶段和 BTC2.0 阶段，还会带来一些明显的优势。
6.1. 清晰的分工和规范
这种阶段划分的另一个好处是能够明确分工与职责。
1. 有了判断与决策的参考原则。这样就容易从设计者的角度，将符合 BTC1.0 原则的功能设计到比特币主网中，将符合 BTC2.0 设计原则的功能设计到 TAP 协议中。不仅能够降低争议，还能够带来更好的组织间的协作。
BTC2.0 还可以参考编译原理和其他成熟产品的发展过程，将 TAP 的发展做更清晰的阶段规划。
2. 一些协议和标准也能更好的命名和制定评审标准。如 TAP 的 7 个协议，当前命名是：
- BIP-TAP-ADDR：Taproot Asset On Chain Addresses Draft
- BIP-TAP-MS-SMT：Merkle Sum Sparse Merkle Trees Draft
- BIP-TAP-PROOF：Taproot Asset Flat File Proof Format Draft
- BIP-TAP-PSBT：Taproot Assets PSBT Draft
- BIP-TAP-UNIVERSE：Taproot Asset Universes Draft
- BIP-TAP-VM：Taproot Asset Script v1 Draft
- BIP-TAP：TAP: Taproot Assets Protocol Draft
如果 BTC2.0 的分类方式被大家接受，完全可以命名成 BIP2 开头：
- BIP2：Taproot Asset On Chain Addresses Draft
- BIP2：TAP Merkle Sum Sparse Merkle Trees Draft
- BIP2：Taproot Asset Flat File Proof Format Draft
- BIP2：Taproot Assets PSBT Draft
- BIP2：Taproot Asset Universes Draft
- BIP2：Taproot Asset Script v1 Draft
- BIP2：TAP: Taproot Assets Protocol Draft
6.2. 资源的整合与组织再规划
当前比特币的主网主要由 Bitcoin Core 团队在负责（截止 2025 年 6 月份全网 90%在使用 Bitcoin Core）。TAP 协议由闪电网络实验室在负责。
当前 BitcoinCore 软件已经运行超过了 15 年，核心功能已经趋于稳定，后面再大幅增加功能的场景应该不多，或者如果需要大幅的改动，大概率都会发生在 TAP 协议之上。TAP 协议当前刚刚发展，如果按照可预测的规划，还有很长的路要走，需要大量的开发资源。如果可以将原有的开发资源很好的复用，将会极大的推动 BTC2.0 的发展。更加重要的是这些比特币主网的开发人员在开发环境、语言类型上，都与 TAP 的开发有这非常大的共同特点，主要的区别仅仅在于开发的指导原则产生了变化。
当然这样会面临很大的挑战，因为 TAP 当前是闪电网络中的一个协议，并不是闪电网络的全部工作。是否能够将 TAP 独立成 BTC2.0 项目，再规划发展和整合资源都是需要很多的协调工作。
如果 TAP 一定会发展成 BTC2.0，那么比特币主网项目（BTC1.0），新的 BTC2.0，闪电网络会是三个比较独立又紧密相连的项目。BTC2.0 部分会和闪电网络有更加深入的功能集成，基于 BTC2.0 的新特性，闪电网络也将会有更大的发展。
6.3. 发展与竞争
前面第 5 节描述了 TAP 与直接竞争者的一些特性对比，也可以看作是 BTC2.0 与外部分层协议的对比。在当前发展阶段，RGB 与 TAP 会产生很多的直接竞争。表现在几个领域：资产的发行、资产的交易、更广泛的 BTCFi。虽然在与比特币主网紧密关联的部分，TAP 优于很多协议，但如果 TAP 不能尽快的完成阶段一的发展，图灵完备的 RGB 将会首先占领这个领域。RGB 仅凭依赖比特币主网共识协议一个特性，就能吸引无数的比特币原生主义的爱好者，毕竟功能实现更吸引人。如果 TAP 不能完成或落后第二阶段的发展，TAP 也将落后于 RGB。
TAP 是否会发展成 BTC2.0？发展过程是什么情况？最终会是什么样的格局，依赖于很多外部情况。这些比特币领域可能的发展充满了想象空间，充满了挑战，但不管过程如何，TAP 都为我们打开了一扇大门。
写在最后：如果 TAP 是 BTC2.0 的发展，那么 TaprootAssets Protocol 的名称是不是过于具体和代表当前，是不是升级为另外一个名称才能更好的代表 BTC2.0 的发展？
参考文献
注释说明：因为本文是对 TAP 的综合预测与分析，很多内容是一些知识的概括总结，不具体到某篇文章。本文的一些内容使用了 AI 助手，并且内容根据作者的行业经验判断，认为是比较准确后，才引入到了文章中。其中包括：C/C++与 Java 的应用场景对比。
编译原理部分参考了高校计算机专业的课本材料与零散的网络文章。
其他具体相关的参考文章如下：
1. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki ，Taproot Assets Protocol 相关的 7 个协议
2. 《彻底理解比特币“隔离见证”技术与它的三个版本升级》，
3. 《一文梳理比特币二层（Layer2）建设的基础知识体系 V2.0 版》，
