Author: Fu Shaoqing, SatoshiLab, Everything Island BTC Studio

This article has a total of 11,944 words, estimated reading time: 45 minutes.

Main Text

01 Introduction

After I finished writing the article "Thoroughly Understanding Bitcoin's 'Segregated Witness' Technology and Its Three Version Upgrades," it sparked deep reflection.

Since its inception, Bitcoin has been continuously exploring both scaling and capacity expansion. The emergence of the TAP (TaprootAssets Protocol) should lay a solid architectural foundation and feasible route for Bitcoin's scaling and capacity expansion. Currently, TAP allows scaling to an infinite data space; can capacity expansion also reach infinity, i.e., be Turing complete? We can analyze some paths that can be explored from both theoretical and practical perspectives. If Bitcoin can achieve complete scaling and capacity expansion, a situation where all chains converge into one will occur. This process will be continuous, lengthy, and full of challenges, requiring the wisdom and practice of many. Friends interested in this issue are welcome to discuss and participate in the construction.

02 The Third Segregated Witness Opens a New Door

Let’s start with a simple conclusion: the new door opened by the third Segregated Witness is the usable infinite data space, which can develop a Turing complete virtual machine (VM).

First, we will review the significant changes brought about by the third Segregated Witness technology, and then look at Bitcoin's further development from the perspective of layered protocols.

2.1. What Foundations Has the TaprootAssets Protocol Laid?

From my previous article "Thoroughly Understanding Bitcoin's 'Segregated Witness' Technology and Its Three Version Upgrades," we can see the early explorations of OP_RETURN and the subsequent three version changes of Segregated Witness. As shown in the figure below:

We will see that the third upgrade of Segregated Witness, the TAP protocol, has brought about two significant changes:

1. It has reached the limit of scaling — using infinite data space.

2. Architecturally, it has separated the BTCscript VM from the TAP VM, laying a good architectural foundation for future functional development.

This allows for independent exploration of the possibility of achieving Turing completeness on the Bitcoin network without affecting the Bitcoin mainnet, and this exploration can be conducted in a gradual manner.

This article will analyze the potential for Bitcoin's capacity expansion. If, supported by TAP technology, both Bitcoin's scaling and capacity expansion can reach their ultimate goals, it will lay a solid foundation for the widespread application of Bitcoin.

2.2. Bitcoin's Development Requires Layered Protocol Design Thinking

If Bitcoin wants to have a global impact, it must have vast application scenarios, forming a large ecosystem. For such large and complex systems, humanity already has relevant experience and methodologies, namely layered design thinking. Protocols like TCP/IP have very good application cases and reference experiences.

In my article "A Comprehensive Overview of the Basic Knowledge System for Bitcoin Layer 2 (Layer 2) Construction V 2.0," there is a more detailed description of layered protocols. Layered design is a means and methodology for humans to handle complex systems by dividing the system into multiple hierarchical structures and defining the relationships and functions between each layer, thereby achieving modularity, maintainability, and scalability of the system, thus improving design efficiency and reliability.

Advantages of protocol layering: Each layer is independent, flexible, structurally separable, easy to implement and maintain, and can promote standardization.

The layered modular design thinking is a common approach in the technical field for handling large functions that require collaboration among many people and continuous improvement of engineering projects, and it is a method that has been validated by practice. A successful large layered protocol in human history is the TCP/IP protocol, which established the entire internet on this protocol foundation.

The future web 3.0 (which can also be called the value internet) will be built on Bitcoin as a layer one network. The layered design thinking of Bitcoin has already seen preliminary development. There are now various exploratory Layer 2 cases, among which the typical ones are chain-based Layer 2 and distributed system-based Layer 2 (such as the Lightning Network), as well as RGB based on the LNP/BP protocol. When RGB is based on the BP protocol, it is a Layer 2; when RGB is based on the LNP protocol, it is a Layer 3.

However, the changes brought by TAP do not resemble a layered protocol; they are more like the evolution from version 1.0 to 2.0 of a thing. The reason is that the TAP protocol is so similar and closely connected to the Bitcoin mainnet, manifested in the following points:

1. In terms of data structure, TAP also adopts the same UTXO structure as the mainnet, called vUTXO. The creation, transfer, merging, and splitting of these vUTXOs are consistent with the Bitcoin mainnet and can perform decentralized swaps with the mainnet's UTXOs. From the vByte in SegWit to the vUTXO in TAP, it is a continuation of the same design philosophy.

2. In terms of address types and executed script instructions, TAP also maintains a high degree of similarity with the Bitcoin mainnet, leaving room for architectural expansion. Not only can it restore instructions abandoned by the Bitcoin mainnet, but it can also add new instructions as needed. These instructions are executed in an independent virtual machine (VM).

3. It uses the consensus protocol of the Bitcoin mainnet. Although TAP has made many breakthroughs in scaling and capacity expansion, it is not an independent blockchain or an independent external system; all its changes require the use of the consensus protocol of the Bitcoin mainnet and rely on the Bitcoin mainnet to operate as an extension.

Therefore, when designing TAP-related functions, we adopt the methodology of layered protocols to view the TAP protocol and handle organizational division of labor. However, from the perspective of the evolution of things, viewing this change as the development of BTC 2.0 will more easily maintain the close relationship and dependency between the two, and it will be easier to coordinate and arrange the resources needed for the development of BTC 2.0.

If we analyze the RGB protocol from the three perspectives above, we can see the stark differences. The RGB protocol does not possess the first two characteristics at all; it only shares similarities in using the consensus protocol of the Bitcoin mainnet, which determines that RGB is a complete layered protocol, rather than a continuation of the Bitcoin mainnet.

03 BTC 1.0 and BTC 2.0

The significant changes brought by the TAP protocol provide a good foundation and starting point for Bitcoin's new development. From the analysis in the previous section, we can see the close dependency relationship between the Bitcoin mainnet and TAP. In this article, I use BTC 1.0 and BTC 2.0 to distinguish between the Bitcoin mainnet and the expansion changes brought to the Bitcoin network after the emergence of TAP.

3.1. Basic Definitions

Here, we define BTC 1.0 as the development on the Bitcoin mainnet; all changes and explorations on the Bitcoin mainnet fall within the scope of BTC 1.0. Before the emergence of TAP technology, almost all explorations were based on BTC 1.0. This includes various forked chains of Bitcoin, which were also aimed at verifying certain possibilities of BTC 1.0.

BTC 2.0 is defined as explorations outside the Bitcoin mainnet, particularly protocols like TAP (and perhaps other similar protocols in the future). This scope does not involve changes to the Bitcoin mainnet but focuses on explorations of scaling and capacity expansion conducted outside the Bitcoin mainnet, while being highly dependent on the consensus protocol and foundational characteristics of the Bitcoin mainnet. It is closely related to the Bitcoin mainnet, making it difficult to delineate Bitcoin's development using an independent concept.

3.2. How to Distinguish

The development principle of BTC 1.0 is to maintain the foundational characteristics of the Bitcoin layer one mainnet, such as decentralization, censorship resistance, and privacy, ensuring the secure and stable operation of the Bitcoin mainnet. If this development principle is not clearly described or distinctly differentiated, we should look at the characteristics that the lowest layer protocol should possess from the perspective of layered protocols. Considering the characteristics of the lowest layer protocol, almost all expectations to expand instructions and achieve Turing complete computation do not conform to the development principles of BTC 1.0. From the perspective of compilation principles, all efforts to develop a virtual machine to the second stage (introducing state and conditional branching) are also inconsistent with the principles. Moreover, from this standard, the historical removal of instructions in Bitcoin has maintained a stricter BTC 1.0 standard.

The development principle of BTC 2.0 is to meet all the demands for changes that one wishes to make on the Bitcoin layer one mainnet, but which violate certain aspects of the BTC 1.0 development principles. For example, extending the OP_CAT instruction; the desire to develop the Bitcoin mainnet into a Turing complete system, etc. It can also be described as all scaling and capacity expansion demands that are not suitable for the Bitcoin mainnet can be developed in BTC 2.0.

In the TAP protocol, the space has already been expanded to infinity through the universe, so the only remaining question is whether to develop TAP-VM into a Turing complete system. In the next section, we will mainly analyze the possibility of TAP-VM developing into Turing completeness and the potential stages it may go through.

Note: TAP is a complete protocol, including TAP-VM, so the subsequent content will use the term TAP.

04 Stages of TAP Developing into Turing Completeness

Discussing the development of TAP into Turing completeness is a highly specialized issue, involving core knowledge of programming languages and virtual machine design. From the theory of compilation principles and the historical development of compilers, a virtual machine (VM) typically undergoes an evolutionary process from non-Turing complete to Turing complete, usually moving from simple to complex, from secure to powerful, and from specialized to general-purpose. (This sentence will be repeated multiple times in this article.)

From the theoretical analysis of compilation principles, a virtual machine can definitely evolve from non-Turing complete to Turing complete. Thus, the only remaining question is whether there is a necessity for TAP to develop into a Turing complete system. (This question will not be discussed in this article.)

If TAP must develop into Turing completeness, what processes and methods can it follow and learn from?

4.1. Turing Completeness from the Perspective of Compilation Principles

Turing Completeness: A virtual machine or programming language is said to be Turing complete if it can compute any computable problem. A computational system that can compute every Turing-computable function is referred to as Turing complete. A language being Turing complete means that its computational power is equivalent to that of a Universal Turing Machine, which represents the highest capability that modern programming languages can possess.

In computability theory, when a set of rules for data operations (a set of instructions, programming language, or cellular automaton) can compute results for any data in a certain order, it is called Turing complete. A device with a Turing complete instruction set is defined as a universal computer. If it is Turing complete, it has the ability to perform conditional jumps (such as "if" and "goto" statements) and modify memory data. If something exhibits Turing completeness, it can simulate an original computer, and even the simplest computer can simulate the most complex ones. All general-purpose programming languages and modern computer instruction sets are Turing complete (C++ templates are Turing complete) and can solve problems with limited memory. Turing complete machines are defined as having infinite memory, but the machine instruction sets are usually defined to operate only on a specific, limited amount of RAM.

A virtual machine (VM) typically undergoes an evolutionary process from non-Turing complete to Turing complete, moving from simple to complex, from secure to powerful, and from specialized to general-purpose. This involves two main questions:

1. Why start from non-Turing complete? For safety and reliability. Non-Turing complete systems can guarantee that all programs will terminate (the Halting Problem is decidable) and will not enter infinite loops, which is crucial for scenarios such as smart contracts, configuration languages, and template engines.

2. Why develop towards Turing completeness? For expressiveness and functionality. Only Turing complete systems can implement various complex logic and algorithms, becoming a general programming platform.

Therefore, the evolution of a VM from non-Turing complete to Turing complete is essentially a process of expanding its design goals from "absolutely safe and controllable" to "powerful and general." The highest pursuit of modern VMs is to attempt to achieve both: providing Turing complete capabilities while maximizing safety and controllability through clever design.

4.2. Obvious Stages of a VM Evolving from Non-Turing Complete to Turing Complete

A virtual machine (VM) typically undergoes an evolutionary process from non-Turing complete to Turing complete, moving from simple to complex, from secure to powerful, and from specialized to general-purpose. We can summarize this into the following typical stages:

1. Stage One: Pure Calculator (Non-Turing Complete)

   Characteristics: Only basic expression calculation capabilities, no state, no control flow.

• Capabilities: Supports basic arithmetic operations (addition, subtraction, multiplication, division), logical operations, bitwise operations, etc. It functions like a high-level calculator, where each calculation is independent and does not rely on previous states.
• Statelessness: There is no concept of memory, or memory is read-only and cannot be modified. Variables cannot be defined or modified.
• No Control Flow: There are no conditional branches (if/else), loops (for/while), or jump instructions. Instructions can only be executed sequentially.
• Why Non-Turing Complete: It cannot implement loops or conditional judgments, and cannot simulate the infinite tape and state transitions of a Turing machine.
• Historical Examples: Some of the earliest extremely simple configuration or expression evaluation engines.

1. Stage Two: Introduction of State and Conditional Branching (A Key Step Towards Completeness)

   Characteristics: Introduces mutable state (memory) and simple conditional judgments, but lacks true loops.

• Capabilities:

  1. State: Introduces writable memory (such as stack, registers, heap), allowing for the definition and modification of variables. This enables calculations to depend on history rather than being isolated.
  2. Conditional Branching: Introduces condition-based jump instructions (such as ifeq, iflt, jmp to a specified offset). This is key to implementing logical judgments.

• Why Still Possibly Non-Turing Complete: If the VM's instruction set or design deliberately prohibits backward jumps (backward jump), meaning it can only jump to subsequent instructions (forward jump), then it cannot form loops. Without loops, it cannot achieve the "infinite computation" potential required for Turing completeness (though physically limited, the theoretical model is infinite).

• Historical/Modern Examples: Bitcoin's scripting language (Bitcoin Script) was a classic example in its early days. It was deliberately designed to have no loops, only conditional branches and forward jumps, to prevent infinite loop code from blocking the network, thus ensuring that scripts would complete execution in a finite number of steps.

  Note: I personally believe that the main functions of Bitcoin's scripting language are primarily at stage one, with a small portion exhibiting characteristics of stage two. If expressed in proportions, it is roughly over 90% stage one and less than 10% stage two. Features like the MAST (Merkle Abstract Syntax Tree) introduced later in Taproot do not perform well on the Bitcoin mainnet but will play a powerful role in TAP. A significant reason is that the Bitcoin mainnet aims to keep the virtual machine's capabilities limited to stage one.

1. Stage Three: Introduction of Loops or Recursion (Achieving Turing Completeness)

   Characteristics: Provides the ability to form loop structures.

• Capabilities:
  1. Backward Jump: Allows jump instructions to return to previous instruction addresses, directly forming loops.
  2. Loop Instructions: Provides dedicated loop instructions (such as loop).
  3. Indirect Jumps / Function Calls: By supporting function calls and recursion, it can also achieve the effect of loops, as recursion can equivalently replace loops.
• Why Turing Complete at This Point: Once it has the ability for conditional branching and backward jumps/loops/recursion, this VM can implement conditional judgments and repeated executions. The combination of these two theoretically allows it to simulate any Turing machine's computation process, thus achieving Turing completeness.
• Historical Examples: Almost all general-purpose language VMs (such as JVM, Python VM, .NET CLR) have been Turing complete since their inception, as their design goal is to run general programming languages. Their evolution has focused more on enhancing performance and security features.

1. Stage Four: Enhancements on the Basis of Turing Completeness (Safety, Performance, Features)

   Once Turing completeness is achieved, the focus of VM development shifts from computational capability to other aspects:

• Performance: Introduces JIT (Just-In-Time compilation), AOT (Ahead-Of-Time compilation), optimized compilers, more efficient garbage collection algorithms, etc.
• Security: Strengthens sandbox mechanisms, introduces capability systems, and provides finer memory isolation and control. WebAssembly is an excellent modern example, as it provides Turing complete capabilities while greatly enhancing security and determinism through linear memory, structured control flow, and sandbox environments.
• Features: Supports advanced language features such as coroutines, async/await, generics, reflection, etc.
• Determinism: For some blockchain VMs (such as successors to Ethereum EVM), pursuing determinism in execution results (consistent results across all nodes) and termination (limiting actual execution steps through a Gas mechanism) becomes a focus on the basis of Turing completeness.

From the professional knowledge of compilation principles, we can see the four stages of VM development. Referring to this development path, we can also roughly see the several stages of TAP development (which is also the several stages of BTC 2.0 development).

4.3. The First Stage of TAP: Mild Exploration to Expand BTCScript Instructions

Earlier, we mentioned that the early Bitcoin mainnet instructions exceeded its capability range, partially resembling the capabilities of a general VM's second stage, which led to subsequent instruction reduction behaviors. The streamlined instructions of BTCScript on the Bitcoin mainnet meet the first stage capability requirements in compilation principles, all aimed at ensuring the security and stability of the Bitcoin mainnet.

Since TAP is the beginning of BTC 2.0, from the perspective of compilation principles, the current TAP-VM should develop towards the second stage of a general VM. During this exploration stage, TAP-VM can appropriately expand BTCScript instructions, restoring previously deleted BTCScript instructions, such as gradually adding widely desired instructions like OP_CAT. Each added instruction requires substantial application testing for its functionality and security. This stage can accomplish simple operations like TrustlessSwap. It can also increase the use cases for technologies in Taproot, such as utilizing more versatile MAST trees.

This stage should meet the basic functionalities of BTCFi, such as simple decentralized trading, basic lending functions, and simple staking functions. Currently, these functionalities can be achieved through TrustlessSwap and some Tapscript.

4.4. The Second Stage of TAP: Building a BTCFi Instruction Set for Decentralization

For TAP-VM to develop to support most financial applications, it needs to derive how many instructions to add from both compilation principles and application perspectives. However, this stage certainly does not require Turing completeness. This stage needs to meet common BTCFi applications, such as lending, staking, minting stablecoins, and more complex swaps.

This stage is very close to the second stage of a general VM, requiring the introduction of state and conditional branching. In the MAST abstract syntax tree, such states and conditional branching are introduced. Although such MAST trees existed in the Taproot technology of BTC 1.0, these conditional statements can only play a better role once the BTC-VM of the Bitcoin mainnet is separated from the independent TAP-VM.

4.5. The Third Stage of TAP: A Richer Instruction Set and Preliminary Turing Completeness

TAP-VM develops to support more complex applications on top of financial applications, relying on the push from applications towards TAP-VM. This stage will gradually approach Turing completeness or preliminary Turing completeness.

At this stage, from the perspective of compilation principles, it will evolve to the third stage of a general VM, beginning to introduce features such as loops and recursion, enabling backward jumps and indirect jumps, dedicated loop instructions, and even function capabilities. Coupled with the conditional and branching functionalities supported in stage two, the TAP-VM at this point can theoretically simulate all computations, thus achieving Turing completeness. Alternatively, due to the developmental process, it may be in the early stages of Turing completeness, but it already possesses a rich instruction set capable of completing complex functionalities.

However, even if TAP-VM can develop to Turing completeness at this stage, there will be significant differences compared to the Turing completeness of RGB. It will likely resemble the comparison between languages like C++ and Java, which we will detail further in section 5.1.

4.6. The Fourth Stage of TAP: Mature Turing Completeness + Rich Library

At this stage, TAP-VM not only achieves Turing completeness but also begins to have a rich library (or function library) that can theoretically fulfill all application functionalities and has a variety of use cases. With a wealth of application cases and library support, developers find it easier to create a multitude of applications.

The TAP-VM at this stage, like the fourth stage tasks of a general VM, shifts its focus from computational capability to higher virtual machine metrics such as performance, security, and determinism. Will this be a relatively distant process?

As TAP reaches this stage, its functionalities become very powerful, leading to many overlapping areas with RGB. Many applications can be implemented using either TAP or RGB. This overlapping part mainly focuses on financial applications, especially assets issued on the Bitcoin mainnet. However, TAP and RGB still have significant differences in larger application scenarios. We will analyze these differences in the next section.

05 Different Application Scenarios for Turing Complete Systems

In the BTC ecosystem, we mainly refer to two Turing complete systems for comparison: TAP and RGB, to illustrate their suitability for different application scenarios or to better explain the application scenarios of TAP.

Based on experiences in the web 2 domain and rich data on VMs, the comparison between C/C++ development languages + runtime environments and Java development languages + runtime environments can serve as a good reference for comparing TAP and RGB.

5.1. Comparison of Application Scenarios for C/C++ and Java

Core Feature Comparison Table

Feature Dimension

Summary of Application Scenarios

1. C/C++'s Main Arena (Requires Direct Hardware Interaction or Extreme Performance)

(1) System-Level Software / Infrastructure Development

• Operating Systems (e.g., Linux, Windows kernel)
• Database Management Systems (e.g., MySQL, PostgreSQL)
• Compilers / Interpreters (e.g., GCC, JVM itself is actually written in C++)
• Web Servers / High-Performance Network Frameworks (e.g., Nginx, Node.js backend)

(2) Hardware Drivers and Embedded Systems

• Device Drivers: Need to interact directly with hardware registers.
• Embedded / IoT Devices: Extremely resource-constrained (e.g., microcontroller MCU), requiring precise control over memory and power consumption, unable to bear the overhead of JVM.

(3) High-Performance Computing and Game Development

• Game Engines (e.g., Unreal, Unity backend): Need to squeeze hardware performance for complex graphics and physics calculations.
• Scientific Computing / Financial Trading Systems: Microsecond-level latency is crucial.
• Graphics / Image / Audio-Video Processing: Such as Photoshop, FFmpeg.

(4) Scenarios Requiring Fine Control Over Memory and Resources

• In certain scenarios, manual memory management can be more predictable than garbage collection, avoiding latency jitter caused by GC.

1. Java's Main Arena (Requires High Development Efficiency, Cross-Platform, and Enterprise-Level Reliability)

(1) Large Enterprise-Level Application Backend Development

• Web Application Backend: The Spring Boot framework is the absolute leader in enterprise-level Java development, used to build large, distributed, high-concurrency backend services.
• Microservices Architecture: A large number of microservices frameworks based on Java and JVM (e.g., Spring Cloud).
• Distributed Systems: Such as Hadoop in the big data field, message queue Kafka.

(2) Android Application Development

• Officially the historical preferred language for Android (although Kotlin has now become the preferred language, a large amount of underlying code and ecosystem is still Java).

(3) Big Data and Cloud Computing

• Core components of big data processing frameworks like Hadoop, Spark, and Flink are mostly written in Java or Scala (JVM languages).

(4) Systems Requiring High Reliability and Long Lifecycles

• Core systems in banking, finance, e-commerce, etc., where robustness, security, and strong community ecosystem support are crucial.

(5) Cross-Platform Desktop Applications

• Although not as popular as web applications, Swing/JavaFX can still be used to develop cross-platform GUI programs.

1. How to Choose?

• Choose C/C++ when:

Performance is the absolute top requirement (games, trading systems).

You need to interact directly with the operating system or hardware (drivers, embedded).

Resources are extremely limited, unable to bear the memory and CPU overhead of JVM.

You need absolute control over the program's behavior (memory layout, execution flow).

• Choose Java when:

You are developing large, complex enterprise-level applications (web backend, microservices).

Development efficiency, maintainability, and team collaboration are more important than extreme performance.

You need strong cross-platform capabilities and do not want to compile separately for each platform.

You want to avoid memory management errors and enjoy a rich ecosystem of open-source libraries and frameworks.

The project requires high reliability and long-term stable operation.

In summary: C/C++ is suitable for closer to the hardware or operating system layer; Java is more suitable for the business layer and application layer.

5.2. Comparison of Application Scenarios for TAP and RGB

Core Feature Comparison Table (Hoping to gradually improve this comparison table with everyone's help in the future)

Summary of Application Scenarios (The following are speculations based on features, as TAP-VM has not fully developed, and RGB does not have more application cases yet)

1. TAP's Main Arena (Requires Basic Functions Based on Bitcoin Characteristics)

(1) Asset Issuance of Cash Model

(2) BTCFi on the Bitcoin Network

(3) Decentralized Underlying Protocols

2. RGB's Main Arena (Almost Suitable for All Types of Dapps)

(1) Smart Contract Applications on the Bitcoin Network

(2) More Advanced and Complex Asset Issuance and DeFi Applications

(3) Higher-Level Web 3 Applications, such as Decentralized Identity, DAO Governance, etc.

(4) Other Broader Web 3 Applications

3. How to Choose?

• Choose TAP-VM:

Direct interaction with Bitcoin UTXO.

Asset issuance of cash model.

Directly extending the functionality of Bitcoin script types.

Decentralized Bitcoin financial applications.

• Choose RGB:

Smart contracts requiring complex logic.

More advanced and complex DeFi.

Non-financial Web 3 applications.

In summary: TAP-VM is closer to applications on the Bitcoin mainnet or directly extending applications based on the Bitcoin mainnet; RGB is suitable for applications with complex logical functions that are closer to the user layer.

06 How to Better Develop BTC 2.0

The content of this section is more based on personal subjective judgments and descriptions, mainly derived from the author's past work experience and project engineering experience. Therefore, there will certainly be shortcomings and deviations, and I hope to hear more voices to improve this prediction and judgment, especially from product project parties developing in this field.

Through the previous discussions, if we can divide Bitcoin into BTC 1.0 and BTC 2.0 stages, it will bring some obvious advantages.

6.1. Clear Division of Labor and Standards

Another benefit of this stage division is the ability to clarify roles and responsibilities.

1. With reference principles for judgment and decision-making, it becomes easier from the designer's perspective to design functionalities that align with BTC 1.0 principles into the Bitcoin mainnet and functionalities that align with BTC 2.0 design principles into the TAP protocol. This not only reduces disputes but also fosters better collaboration between organizations.

BTC 2.0 can also refer to the development processes of compilation principles and other mature products to make clearer stage planning for TAP's development.

2. Some protocols and standards can also be better named and reviewed. For example, the seven protocols of TAP are currently named:

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 v 1 Draft

BIP-TAP: TAP: Taproot Assets Protocol Draft

If the classification method of BTC 2.0 is accepted by everyone, it can be completely named starting with BIP 2:

BIP 2: Taproot Asset On Chain Addresses Draft

BIP 2: TAP Merkle Sum Sparse Merkle Trees Draft

BIP 2: Taproot Asset Flat File Proof Format Draft

BIP 2: Taproot Assets PSBT Draft

BIP 2: Taproot Asset Universes Draft

BIP 2: Taproot Asset Script v 1 Draft

BIP 2: TAP: Taproot Assets Protocol Draft

6.2. Resource Integration and Organizational Replanning

Currently, the Bitcoin mainnet is primarily managed by the Bitcoin Core team (as of June 2025, 90% of the network is using Bitcoin Core). The TAP protocol is managed by the Lightning Network Labs.

The current Bitcoin Core software has been running for over 15 years, and its core functionalities have stabilized. There should be few scenarios for significant feature additions in the future, or if major changes are needed, they are likely to occur on top of the TAP protocol. The TAP protocol is still in its early development stage, and according to predictable planning, there is a long way to go, requiring substantial development resources. If existing development resources can be effectively reused, it will greatly promote the development of BTC 2.0. More importantly, these Bitcoin mainnet developers share many common characteristics in their development environment and language types with TAP development, with the main difference being the change in guiding principles for development.

Of course, this will face significant challenges, as TAP is currently one protocol within the Lightning Network and not the entirety of its work. Whether TAP can be established as an independent BTC 2.0 project, along with planning for development and resource integration, requires a lot of coordination.

If TAP is destined to evolve into BTC 2.0, then the Bitcoin mainnet project (BTC 1.0), the new BTC 2.0, and the Lightning Network will be three relatively independent yet closely connected projects. The BTC 2.0 portion will have deeper functional integration with the Lightning Network, and based on the new features of BTC 2.0, the Lightning Network will also see greater development.

6.3. Development and Competition

Section 5 previously described some feature comparisons between TAP and its direct competitors, which can also be seen as a comparison between BTC 2.0 and external layer protocols. At the current stage of development, RGB and TAP will have a lot of direct competition. This is reflected in several areas: asset issuance, asset trading, and broader BTCFi. Although TAP excels in many protocols closely related to the Bitcoin mainnet, if TAP cannot quickly complete the development of Phase One, the Turing complete RGB will likely dominate this field first. RGB, relying solely on the consensus protocol of the Bitcoin mainnet, can attract countless Bitcoin maximalists, as functional implementation is more appealing. If TAP cannot complete or falls behind in the development of Phase Two, it will also lag behind RGB.

Will TAP evolve into BTC 2.0? What will the development process look like? What will the final landscape be? This depends on many external factors. The potential developments in the Bitcoin space are full of imaginative possibilities and challenges, but regardless of the process, TAP has opened a significant door for us.

In conclusion: If TAP is the development of BTC 2.0, is the name "Taproot Assets Protocol" too specific and representative of the current state? Should it be upgraded to another name to better represent the development of BTC 2.0?

References

Notes: This article is a comprehensive prediction and analysis of TAP, with many contents being summaries of knowledge and not specific to any particular article. Some content in this article utilized AI assistance, and the information was included after being deemed relatively accurate based on the author's industry experience. This includes the comparison of application scenarios between C/C++ and Java.

The section on compilation principles references textbook materials from university computer science programs and scattered online articles.

Other specific related reference articles are as follows:

1. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki, 7 protocols related to the Taproot Assets Protocol

2. "Thoroughly Understanding Bitcoin's 'Segregated Witness' Technology and Its Three Version Upgrades"

3. "A Comprehensive Overview of the Basic Knowledge System for Bitcoin Layer 2 Construction V 2.0"

A special thanks to all contributors and participants who have enriched my knowledge system.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。