Author: Fu Shaoqing, SatoshiLab, Everything Island BTC Studio

1. Introduction

When the author was learning Bitcoin technology, they found that understanding the three concepts of SegWit, Taproot, and TaprootAssets from the perspective of the development history of segregated witness made it easier to learn and grasp their development patterns. This also allows for a better understanding of the Taproot Assets protocol from the Lightning Network Labs, the role of Universe, and the functionalities that the TaprootAssets protocol can achieve, as well as its potential future developments. With these understandings, it becomes easier to design related products for users.

Reading this article also requires two important perspectives: Bitcoin's scalability and Bitcoin's capability expansion.

Scalability refers to expanding the data capacity that Bitcoin can use and manage. Initially, it was limited to the size of the block capacity, but later it encompassed all data capabilities that could be managed by Bitcoin. The limit of scalability is managing infinite data space;

Capability expansion refers to enhancing the ability of Bitcoin's script instructions to implement functionalities, with the limit of capability expansion being the realization of Turing completeness in programming.

The entire development history of Bitcoin is a history of scalability and capability expansion, including various Bitcoin fork chains, as well as explorations on OP_RETURN and three version changes of segregated witness.

The detailed principle diagrams in the three versions can mostly be ignored by readers; they are included by the author for a deeper understanding of the relevant technology and do not affect the reading experience.

The author has marked the time for the BIP protocols mentioned in the article, allowing readers to feel the time cycle from the conception of a technology to its production environment launch, thus gaining a sense of the difficulty of implementing this technology. More importantly, the timestamps of the three segregated witness version protocols can clearly illustrate the broader development patterns of this phenomenon, making it easier to predict future developments. This serves as a good reference for teams developing products based on these technologies and protocols, facilitating the choice of participation timing. Early participation in a new phenomenon often leads to becoming a "martyr" due to immature supporting technologies; late participation results in losing the first-mover advantage and becoming a "bystander." The author believes that entering just before the "usable period" is a better timing. This judgment of "approaching the usable period" often relies on time assessments and technical detail evaluations.

1.1. Early Transactions (Without Segregated Witness)

Transactions defined in the white paper (simplest transaction model)

The most basic early Bitcoin transaction allows for multiple inputs and two outputs. One output is the change returned to oneself, and the other output is the transfer to an external party. (Note: The difference between total inputs and total outputs is the transaction fee.)

Most transactions have two outputs, but there are indeed scenarios with only one output, summarized as follows:

To better illustrate the differences, we use a diagram with 2 inputs and 2 outputs. (Another main reason is that the reference material I consulted provided this 2-input and 2-output image, so I didn't need to redraw it. Just being lazy ^_^)

Isn't it easier to understand with such a comparison diagram?

Comparison of traditional transaction example diagram and segregated witness Segwit transaction schematic

1.2. Exploration on OP_RETURN

Why discuss OP_RETURN when talking about segregated witness? Because it is an earlier exploration than segregated witness, which helps to better understand the reasons for the emergence of segregated witness.

OPRETURN is a script opcode used to terminate a script and return the value at the top of the stack. This opcode is similar to a return function in programming languages. Throughout Bitcoin's history, the functionality of the OPRETURN opcode has been modified multiple times, and it is now primarily used as a method for storing data on the ledger. The functionality of the OP_RETURN opcode has undergone significant changes in the past, and it is now an important mechanism that allows us to store arbitrary data on-chain.

Initially, OP_RETURN was used for early termination of script execution, with the execution result presented as the top stack item. This opcode initially had a vulnerability that could be exploited, but Satoshi quickly patched that vulnerability.

Further Changes to OP_RETURN Functionality

In the Bitcoin Core v0.9.0 upgrade, the "OP_RETURN output" script was made a standard output type, allowing users to attach data to "unspendable transaction outputs." The initial limit on the amount of data that could be used in such scripts was set to 40 bytes, later increased to 80 bytes.

Storing Data on the Blockchain

Changing OPRETURN to always return false resulted in interesting outcomes. Since no opcodes or data are evaluated after OPRETURN, network users began using this opcode to store data in any format.

During the period of Bitcoin Cash (BCH), from August 1, 2017, to November 15, 2018, the length of data that could be attached to OP_RETURN outputs was expanded to 220 bytes, allowing for larger data to facilitate innovative applications on the blockchain, such as posting content on blockchain social media.

In BSV, the 220-byte limit was retained for a short time. Subsequently, in January 2019, due to the OP_RETURN opcode terminating scripts in a way that nodes do not validate any subsequent opcodes, nodes also did not check whether the script was within the maximum script size limit of 520 bytes. As a result, node operators on the network decided to increase the maximum transaction size to 100KB, granting developers more freedom for application innovation, allowing new applications to place larger and more complex data into the Bitcoin ledger. At that time, there was an example of an application where someone placed an entire website into the BSV ledger.

Although OPRETURN has certain functional expansions, its overall capabilities remain limited. Moreover, improvements on OPRETURN do not lead to more technological evolution architecturally (still confined to 1M blocks), which led to the development of the segregated witness technology. Its three version upgrades better illustrate the correctness of segregated witness in terms of scalability and capability expansion, as well as the powerful effects it produces.

1.3. Comparison Diagram of Early Transactions and Three Version Changes of Segregated Witness

To help everyone better understand the entire history of Bitcoin with segregated witness, we present a comparison diagram of the four stages at the beginning of the article.

2. The First Version of Segregated Witness Segwit

2.1. Introduction and Related Protocols

Segregated Witness, abbreviated as SegWit, was first proposed by Pieter Wuille (Bitcoin Core developer and co-founder of Blockstream) in December 2015, later forming Bitcoin BIP141. Segregated witness primarily addresses three issues (as explained later), with the first two mainly enhancing security and performance, while the third significantly impacts new technology by indirectly increasing block capacity (see the concept of Block weight below), thus laying the foundation for Bitcoin's capability expansion, leading to further enhancements in the subsequent Taproot (the second version of segregated witness).

Related Protocols:

BIP-141: Segregated Witness (Consensus layer) / 2015-12-21

BIP-143: Transaction Signature Verification for Version 0 Witness Program / 2016-01-03

BIP-144: Segregated Witness (Peer Services) / 2016-01-08

2.2. Causes and Effects

The main issues addressed by segregated witness are:

1) Transaction malleability.

2) The transmission of transaction signatures in SPV proofs becomes optional, reducing the amount of data transmitted in Merkle proofs.

3) Indirectly increases block capacity.

The first two mainly enhance security and performance, while the third significantly impacts new technology by indirectly increasing block capacity, thus laying the foundation for Bitcoin's capability expansion, leading to further enhancements in the subsequent Taproot.

Although it indirectly expanded block capacity, segregated witness is still subject to block size limits. The block size limit for Bitcoin is 1M bytes, and since witness data is not included in this limit, there are still restrictions on the total block size to prevent the misuse of witness data. A new concept called block weight was introduced.

Block weight = Base size * 3 + Total size

Base size is the block size excluding witness data.

Total size is the size of the serialized transaction as described in BIP144 (in bytes), including base data and witness data.

Segregated witness limits Block weight = 4M.

Segregated witness also technically enables Bitcoin's scalability to utilize the Lightning Network, which will not be detailed here.

2.3. Detailed Principle Analysis

The Bitcoin Segregated Witness SegWit technology led to three significant changes:

• Changes in transaction structure;
• Increase in block size;
• A new Bitcoin address format.

(1) The transaction structure is shown in the diagram below:

By comparing the above diagram with the original Bitcoin transaction diagram, the Witness section has been added, which contains the unlocking code. Moreover, the data in the Witness section is stored in an extended data area outside of the 1M limit.

A more detailed schematic of SegWit transaction data is as follows:

Detailed SegWit Transaction Diagram

(2) Introduction to Transaction Size

Increased Block Size

Through the introduction of the changes in the signed transaction structure and the content of BIP-141, we can see that the maximum block size of Bitcoin can actually be expanded to 4M, where the original 1M is the basic transaction data area, and the additional 3M is the Witness data area.

(3) Address Format of Segregated Witness

Bitcoin Segregated Witness SegWit uses two new locking scripts, P2WPKH and P2WSH, resulting in new Bech32 encoded addresses.

The Bech32 address encoding format is defined as follows:

The formats for the locking scripts P2WPKH and P2WSH are described below, and examples of addresses for the second version of segregated witness, Taproot, are also included.

Locking Script

P2WPKH

The 20-byte public key hash here is actually the initial form of the Bitcoin address in the algorithm.

P2WSH

wTXID Commitment

All transaction IDs (wTXID) in the witness area will form a root hash submitted to the coinbase through a hash tree, with the specific value combinations shown in the diagram.

Schematic Diagram of the Formation Principle of a Single Witness Transaction ID (wTXID)

wTXID

2.4. Development Status and Summary

The segregated witness technology was proposed in December 2015 and was officially activated in 2017 at block height 481824.

The block viewing link is as follows:

https://mempool.space/zh/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893

Detailed learning and breakdown introduction is as follows:

https://learnmeabitcoin.com/explorer/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893

The segregated witness technology is a significant change in Bitcoin's history, opening a glorious development history of Bitcoin's scalability and capability expansion. From the perspective of scalability and capability expansion, segregated witness mainly accomplished the scalability function. Therefore, following this direction of thought, the next version's development will be capability expansion.

3. The Second Version of Segregated Witness: Taproot

From the perspective of scalability and capability expansion, we should be able to predict the functionalities of the second version of segregated witness.

3.1. Introduction and Related Protocols

If one directly uses the term Taproot, many people might think it is a new concept, but if you tell them it is the second version of segregated witness SegWit, most will understand the connection. The BIPs related to Taproot are 340, 341, and 342, with their names being: BIP340 (Schnorr Signatures for secp256k1), BIP341 (Taproot: SegWit version 1 spending rules), BIP342 (Validation of Taproot Scripts).

Related Protocols:

BIP-341: Taproot: SegWit version 1 spending rules / 2020-1-9

BIP-342: Validation of Taproot Scripts / 2020-1-19

BIP-340: Schnorr Signatures for secp256k1 / 2020-1-19

In November 2021, Taproot officially took effect as a soft fork. This upgrade was a combination of BIP340, BIP341, and BIP342. Among them, BIP340 introduced Schnorr signatures, which can simultaneously verify multiple transactions, replacing the Elliptic Curve Digital Signature Algorithm (ECDSA), further expanding network capacity and speeding up batch transaction processing, providing the possibility for deploying complex smart contracts; BIP341 implemented Merkleized Abstract Syntax Trees (MAST) to optimize transaction data storage on the blockchain; BIP342 (Tapscript) expanded Bitcoin's native scripting capabilities to address deficiencies.

The spatial expansion from segregated witness SegWit and Taproot led to the emergence of Schnorr, MAST trees, and Taproot Scripts, whose mission is to expand the functionalities of the Bitcoin mainnet.

3.2. Causes and Effects

Thanks to the segregated witness SegWit technology, Bitcoin's block capacity has indeed increased. However, SegWit technology still left some issues unresolved:

(1) The underlying cryptographic algorithm in the SegWit version still uses ECDSA. (New developments require better asymmetric encryption algorithms to support richer functionalities and effects. Thus, the new Schnorr signature was adopted.)

(2) While space has increased, the unlocking scripts remain a simple one-to-one structure. (This led to the emergence of complex conditional structures like MAST trees.)

(3) SegWit did not enhance the functionality of Bitcoin scripts. (This resulted in the creation of Tapscript.)

Thus, the second version of segregated witness, Taproot technology, effectively resolved the above issues, allowing for better development of segregated witness technology and enabling more functionalities. BIP340 addressed the issue in (1); BIP341 implemented Merkleized Abstract Syntax Trees (MAST) to solve the issue in (2); BIP342 (Tapscript) expanded Bitcoin's scripting language to address the deficiencies in (3).

3.3. Detailed Principle Analysis

Several important new features of Taproot technology:

• Introduction of Schnorr signatures
• Two locking scripts for P2TR: Key Path Spend (similar to P2WPKH); Script Path Spend (similar to P2WSH)
• Script Trees (MAST Merkle Abstract Syntax Trees)
• Taproot Script

1. Schnorr Signatures

The development of Taproot, while expanding capabilities, also placed certain requirements on the signature algorithm, leading to the emergence of Schnorr signatures, which replaced the Elliptic Curve Digital Signature Algorithm (ECDSA). Schnorr signatures are a digital signature scheme that can efficiently and securely sign transactions and messages. It was first described by Claus Schnorr in a paper in 1991. Schnorr is praised for its simplicity, provable security, and linearity.

Advantages of Schnorr Signatures:

Schnorr signatures have multiple advantages, including efficiency, enhanced privacy, while retaining all the functionalities and security assumptions of ECDSA. Schnorr signatures can achieve smaller signature sizes, faster verification times, and improved resistance to certain types of attacks.

The most notable advantage of Schnorr signatures is key aggregation, which allows multiple signatures to be aggregated into a single signature that is valid for the sum of their keys. In other words, Schnorr enables multiple parties to generate a signature that is valid for the total sum of their public keys. Signature aggregation allows the signatures of multiple signers to be combined into a single signature. Key aggregation can reduce transaction fees and improve underlying scalability, as electronic signatures from multi-signature setups occupy the same space in a block as those from single-party transactions. This feature of Schnorr can be used to reduce the size of multi-signature payments and other transactions related to multi-signatures, such as Lightning Network channel transactions.

Another important feature of Schnorr signatures is non-repudiation.

Schnorr also provides many privacy advantages. It allows multi-signature schemes to be indistinguishable from traditional single public keys from an external perspective. Schnorr makes it more difficult for observers to differentiate between multi-signature expenditures and single-signature expenditures in on-chain activities. Additionally, in an n-of-m multi-signature setup, Schnorr makes it harder for external observers to determine which participants signed the transaction and which did not by looking at on-chain information.

Schnorr signatures were implemented in BIP-340 as part of the Taproot soft fork upgrade and were activated on November 14, 2021, at block height 709,632. Schnorr makes BTC digital signatures faster, more secure, and easier to handle. Notably, Schnorr signatures are backward compatible with BTC's cryptographic algorithms, allowing them to be introduced through a soft fork upgrade.

2. Basic Principle Diagram and Key Path Spend, Script Path Spend

3. MAST Merkle Abstract Syntax Tree

Understanding the above Key Path Spend and Script Path Spend, the most important aspect is that these scripts can be organized into a tree structure.

This tree is an integration of the Abstract Syntax Tree (AST) and the Merkle tree. As shown in the diagram below:

AST Tree

Constructing the above semantic tree into a Merkle tree, as follows:

4. Taproot Scripts

In the BIP342 protocol, Tapscript is introduced. Taproot script is an upgraded version of the original Bitcoin script and can also be referred to as a language, but it is essentially a collection of opcodes with commands that facilitate the implementation of the other two BIPs. Tapscript also removes the 10,000-byte script size limit, providing a better environment for creating smart contracts on the Bitcoin network. (This upgrade also laid the foundation for the later emergence of Ordinals, as the Ordinals protocol utilizes Taproot's script-path spend scripts to implement additional data.) Detailed information can be found on the official website:

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

The current capabilities of TaprootScript have not been fully realized, and more developments in the future will showcase its power. For example, the connection technology between Bitcoin's layer one and layer two networks should increasingly utilize Taproot, MAST, and Taproot Scripts.

Note: In fact, at the Taproot layer, the capabilities of TaprootScript are still somewhat limited because it requires Bitcoin's virtual machine for support. In the third version of segregated witness, the TaprootAssets protocol has a dedicated virtual machine, TAP-VM, specifically for TaprootScript, which enhances its capabilities and better isolates it from the Bitcoin mainnet's operating environment.

3.4. Development Status and Summary

The Taproot technology was proposed in January 2020 and officially took effect as a soft fork in November 2021. With the introduction of Taproot technology into the Bitcoin ecosystem, new applications began to emerge. The initial applications were lightweight and simple.

Typical applications include:

(1) Ordinals protocol, inscriptions, BRC20

(2) Other protocols - Atomicals, ARC20

(3) Other protocols - Rune

SegWit and Taproot technologies completed the first exploration of scalability and capability expansion, but this expansion and enhancement are limited within the existing structure.

The first expansion of Bitcoin achieved an increase from 1M blocks to 4M blocks. If this line of thought continues for further expansion, even with technical support, will it not lead to blocks becoming excessively large like other Bitcoin fork chains? This could lead to serious issues such as the centralization of Bitcoin, undermining the security of the blockchain. Therefore, the next step in expansion requires a different technical implementation principle.

Although Taproot technology completed the first capability expansion of Bitcoin, this expansion also has certain limitations. In the Bitcoin mainnet, the virtual machine executing BTCScript and the virtual machine for TapScript are the same (Bitcoin's stack computation). This limits the expansion and may affect the stability and security of the original Bitcoin mainnet. A more reasonable development approach would be to isolate the new capability expansion from the Bitcoin mainnet's virtual machine, forming an independent virtual machine that works alongside the Bitcoin mainnet's virtual machine in accordance with a layered protocol. This isolated virtual machine could potentially evolve from non-Turing complete to Turing complete.

4. The Third Version of Segregated Witness: TaprootAssets Protocol

With the first scalability and capability expansion technology in the Bitcoin mainnet, it provides a very good technical reference and implementation idea for future expansions. The next foreseeable development of Bitcoin should primarily address further scalability issues. Of course, it would be better if both scalability and capability expansion could be addressed together, but simultaneously supporting two major changes is very risky and would significantly increase the difficulty of implementation. Thus, a new scalability technology for the Bitcoin mainnet has emerged (along with some smaller capability expansion technologies).

4.1. Causes and Effects

The development of Taproot has opened up more possibilities for the Bitcoin ecosystem. These possibilities manifest in several aspects:

(1) Is it possible to achieve further segregated witness without occupying Bitcoin's block space, meaning that the data storage of the witness area exists outside of Bitcoin blocks, only storing proofs on the Bitcoin mainnet?

(2) Can the data in the witness area have a richer structure to meet more business functionalities?

(3) Further expand the capabilities of TaprootScript by using a separate virtual machine to perform related computations.

If the above goals can be achieved while fully ensuring the characteristics of the Bitcoin mainnet, it could enable very rich functionalities.

Does the second version of segregated witness Taproot technology satisfy the development of Bitcoin technology? Is there still room for further upgrades and expansions?

4.2. Introduction and Related Protocols

The Lightning Network Labs developed the Taproot Assets protocol at the end of 2021, based on the reasons and background mentioned above. The Taproot Assets protocol (formerly known as "Taro") has more powerful capabilities than Taproot, and its design structure is very sophisticated. (Special thanks to the protocol's designer, Olaoluwa Osuntokun, CTO of Lightning Network Labs.)

The Taproot Assets protocol consists of seven important BIPs (which have not yet received BIP numbers):

BIP-TAP-ADDR: Taproot Asset On Chain Addresses Draft/2021-12-10

BIP-TAP-MS-SMT: Merkle Sum Sparse Merkle Trees Draft/2021-12-10

BIP-TAP-PROOF: Taproot Asset Flat File Proof Format Draft/2021-12-10

BIP-TAP-PSBT: Taproot Assets PSBT Draft/2023-02-24

BIP-TAP-UNIVERSE: Taproot Asset Universes Draft/2021-12-10

BIP-TAP-VM: Taproot Asset Script v1 Draft/2021-12-10

BIP-TAP: TAP: Taproot Assets Protocol Draft/2021-12-10

The TaprootAssets protocol has nearly maximized Bitcoin's scalability and capability expansion. The space is virtually unlimited due to the existence of Universes (theoretically infinite space); the upper limit of capability is defined by the scripting capabilities of TaprootScript and the characteristics of its VM. (Currently, the TAP VM is not Turing complete.)

4.3. Detailed Principle Analysis

Several important new features of the Taproot Assets protocol:

• Data is completely stored outside the Bitcoin mainnet, with proofs of off-chain data existing on the Bitcoin mainnet's blocks;
• Off-chain data has a more complete structure, with a very clever design that offers better scalability;
• Off-chain data has powerful virtual machine (VM) support, and the Bitcoin mainnet's virtual machine is beginning to separate, allowing for more functionalities beyond the Bitcoin mainnet;

1. Storage of Off-Chain Data and On-Chain Proofs

The Taproot Assets protocol uses a method like Universe to store off-chain data, which has significant advantages, allowing for the public sharing of necessary data with visitors while also providing a more private way to store data without making it public.

In the current Taproot Assets protocol, sparse Merkle sum trees are used to address asset-related needs.

This diagram illustrates the issuance of various assets using MS-SMT.

This diagram illustrates the transfer of assets in TaprootAssets and the holding of assets.

2. Complete Data Structure - MS-SMT (Merkle Sum Sparse Merkle Tree)

The Taproot Assets protocol uses the same UTXO model as the Bitcoin mainnet for asset issuance, referred to as vUTXO. The control of the total amount of vUTXO, as well as the operations of splitting, merging, and transferring vUTXO, utilize the MS-SMT sparse Merkle sum tree. The summation ensures that the total amount remains unchanged, and the sparse Merkle tree records the state of all vUTXO.

(How similar the evolutionary path is from Virtual Byte in SegWit to Virtual UTXO in TA!)

The "Sparse Merkle Sum Tree" (hereafter abbreviated as "MS-SMT") is a variant of the Merkle tree defined by bip-tap-ms-smt. Because its key is 256 bits, it has 2^256 leaves, the vast majority of which are empty.

Each leaf contains a quantity, and each branch node commits to the sum of the quantities represented by the leaves in its subtree. Even if the contents of a subtree are unknown, one can determine the total quantity contained in that subtree by checking the branch node. The root of the tree commits to the total quantity represented by all leaves.

Like a general Merkle tree, a trimmed tree containing the target leaves can provide proof of those target leaves in the tree (Merkle proof). However, MS-SMT also supports "non-inclusion proofs." This is achieved through a restriction: the quantity contained in the leaves representing non-existent keys must be explicitly set to a value indicating their non-existence (None), thus proving the existence of "None" constitutes a non-inclusion proof. Therefore, the default MS-SMT will consist of 2^256 leaves representing "None."

Asset Leaves (Asset UTXO)

The lower layer of the asset tree, MS-MST, uses assetscriptkey as the key and asset leaves as the value. Each asset leaf represents a UTXO of that asset (for brevity, it will be referred to as "UTXO" hereafter—not Bitcoin's UTXO), and the following attributes (including one optional) will be serialized in "type-length-value" format.

taprootassetversion

asset_genesis

asset_id

asset_type

amt

lock_time

relativelocktime

prevassetwitnesses

• prevassetid

• asset_witness

• splitcommitmentproof

split_commitment

assetscriptversion

assetscriptkey

assetgroupkey

canonical_universe

assetgenesis is the pre-image that derives assetid.

assetscriptkey serves as both the key for the asset leaf and a Taproot-form public key (defined independently of Bitcoin's tap-vm), and it specifies the conditions for spending the UTXO represented by that asset leaf.

When spending a UTXO, one must first satisfy the (external) Bitcoin spending conditions, followed by the (internal) TAP spending conditions specified by assetscriptkey, which should be satisfied by prevassetid and assetwitness. For example, assetwitness is the signature of the assetscriptkey of the UTXO being spent.

If a UTXO is split during an asset transfer, splitcommitment and splitcommitmentproof are also required. splitcommitment is an MS-SMT that refers to all UTXO after the split (in this sense, the asset tree actually has three layers), and the sum in the root is the total amount being transferred.

splitcommitmentproof is a Merkle proof of split_commitment, proving the existence of a split.

Among all splits, only one will have prevassetid, assetwitness, and splitcommitment. All other splits will only have splitcommitmentproof. All splits share prevassetid and asset_witness.

3. The TAP-VM of the Taproot Assets Protocol

In BIP-TAP-VM: Taproot Asset Script v1, a virtual machine specifically for this protocol is defined. Initially, it is based on a few adjustments to BIP-341 and BIP-342 (the two main BIPs of Taproot), primarily extending BTCScript and TaprootScript slightly.

However, the author believes that under such a design structure, the execution environment of TAP-VM has been separated from the Bitcoin mainnet, allowing for the development of a more powerful virtual machine through the Lightning Network Labs' tapd application. This process is relatively slow due to considerations of security and stability, aligning with the characteristics of Bitcoin ecosystem applications.

TrustlessSwap is a crucial primary function of the TaprootAssets protocol, and this function has already enabled the development of relatively complex Bitcoin-native applications.

In our project team's development, we have already experienced some powerful functionalities. For example, TrustlessSwap can now achieve relatively complex functional designs involving Bitcoin and the assets issued on it.

For a long time to come, with the initial asset issuance being stable and mature, the focus of the TaprootAssets protocol will be on the functional development of TAP-VM.

As a side note: I have a question. If it continues to develop, can TAP-VM evolve into a Turing-complete virtual machine? I judge that if the development time is long enough, it can ultimately achieve Turing completeness. Then there is a second question: in the long run, under the TaprootAssets protocol, is there a need for a Turing-complete virtual machine?

4.4. Development Status and Summary

The Taproot Assets protocol has evolved from the initial document of the protocol's inception at the end of 2021 to the release of the Taro version in 2023, completing the initial exploration phase. However, the Taro version still has many design imperfections, leading to inadequate support for upper-layer applications, causing application development to stagnate for a time. With the release of the tapd0.3.0 version in 2024, the Taproot Assets protocol has seen good exploratory development, and after the release of tapd0.6.0 in June 2025, the protocol entered a stable and usable state. This has laid a good foundation for developing richer applications based on the Taproot Assets protocol.

Compared to the applications generated by protocols such as Ordinals, inscriptions, BRC20, and ARC that emerged after the Taproot technology, the applications generated under the TaprootAssets protocol will be richer, more stable, and more usable than those produced by the second version of segregated witness.

Applications such as TA asset issuance, TA new asset wallets, TrustlessSwap, stablecoins, and more complex BTCFi applications have already become possible and will gradually be realized.

The initial phase of the TaprootAssets protocol primarily completed the scalability of Bitcoin, theoretically expanding the usable space of Bitcoin to infinity through Universe. The TAP VM (Taproot Asset Script v1) has also developed a preliminary model, and importantly, it has produced an isolated, independently developing VM. In foreseeable future developments, Bitcoin will continue to evolve in the direction of capability expansion.

5. Conclusion

Through three major upgrades of the segregated witness technology in the history of Bitcoin development, the Bitcoin mainnet has achieved significant improvements in scalability and capability expansion. In terms of scalability, Universe can theoretically make the space infinitely large, and if combined with the Lightning Network, it should be able to expand the TPS of transactions to infinity; in terms of capability expansion, if TAP-VM can develop to Turing completeness, that too will push capability expansion to the extreme. The maturation of these infrastructures will take a long time.

The three major upgrades of segregated witness have formed a strong protocol and technical foundation for the development of the Bitcoin ecosystem. From SegWit to Taproot to the TaprootAsset protocol, it has almost completed the infrastructure needed for most applications. I believe TaprootAssets will usher in a significant explosion of product ecosystems.

It is important to note that the script language after the three segregated witness upgrades is still non-Turing complete.

These three versions of segregated witness upgrades have fundamentally changed the structure of Bitcoin. What stage will it develop to in the future? The TaprootAsset protocol seems somewhat like Layer 2 technology, but it does not fully meet the Layer 2 standards. It shares many characteristics and mechanisms with Bitcoin layer one but is not a direct development of Bitcoin layer one. The author believes Bitcoin will evolve into the BTC2.0 stage and hopes to exchange relevant ideas with more experts in the future. If the thoughts can be clarified, I will find time later to describe the specific development possibilities and theoretical foundations of BTC2.0.

If it is BTC2.0, would it be better to name the seven BIPs of the TaprootAsset protocol starting with BIP2? Can the review standards and design principles for BTC1.0 and 2.0 protocols be planned more clearly? Moreover, can development resources be better divided and cooperated? The original BitcoinCore team, in addition to maintaining the Bitcoin mainnet of BTC1.0, could also contribute to the development of BTC2.0? Would this allow BTC2.0 to be built faster and better?…

Many thanks to the Lightning Network's YY for providing much feedback and guidance for this article.

References

1. https://mp.weixin.qq.com/s/nllcI-QEJhzxtCBTzi0-Iw

2. https://learnmeabitcoin.com/

3. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki

4. https://docs.lightning.engineering/lightning-network-tools/taproot-assets/

5. https://medium.com/nayuta-engineering-blog-en/understanding-taproot-assets-protocol-e2dfe3fc1e07

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