Author: 3P Labs
I. Introduction
As the earliest and most secure blockchain, Bitcoin uses the UTxO account model, which makes it difficult to support smart contract functions like Ethereum, and can only support some limited scripting language-based functions. Therefore, in the 15 years since the birth of Bitcoin, it has not been used to implement the dazzling DeFi protocols and NFTs on Ethereum, but is usually used for peer-to-peer transfers and value storage.
The Ordinals protocol, which was officially launched on December 14, 2022, changed all this. It puts the metadata that users need to store on the chain into the transaction input, and implements a set of programs based on ordinal theory[^1] to track and record these "inscriptions". Such "inscriptions" record static metadata, rather than dynamically executable on-chain programs like Ethereum smart contracts. This also makes "inscriptions" naturally become NFTs on Bitcoin. Based on ordinal theory, people can also construct transactions to realize the transfer and transaction between these inscriptions.
After that, on March 6, 2023, the BRC-20 protocol based on Ordinals was proposed. It is used to implement homogeneous tokens on Bitcoin, corresponding to the ERC-20 protocol on Ethereum. Such a protocol based on Ordinals is very simple. The process of minting and transferring tokens is written on the inscription in Json format. The most vivid metaphor is a piece of paper with transfer records written on it, and the bookkeeping is left to a third-party organization.
Such a BRC-20 protocol has a sense of violent aesthetics, and is also a compromise under various factors. Previously, Bitcoin also had homogeneous tokens like colored coins. This cannot disprove that BRC-20 is a failed application, but it seems to indicate that it may not be a long-term protocol. So far, we have entered the topic of this article, the taproot assets based on the Lightning Network.
2. Lightning Network
The Lightning Network is a Layer 2 solution built on Bitcoin. Its purpose is to help users save costs and improve efficiency in Bitcoin payment scenarios. The idea behind the Lightning Network is also very simple, that is, to build a capital pool, which is also called a micropayment channel for both parties to the transaction. To be more specific, it involves two core concepts:
* Revocable Sequence Maturity Contract (RSMC): Revocable photo when sequence expires * Hashed Timelock Contract (HTLC): Hashed Timelock Contract
RSMC assumes that there is a micropayment channel between the two parties of the transaction. Both parties first deposit a portion of funds into this channel. Initially, the allocation plan of both parties is the amount deposited in advance. Every time a transaction occurs, both parties need to confirm the allocation result generated after the transaction and invalidate the original allocation plan. This process involves many concepts and is quite clever. For details, please refer to [A Dive into Lightning Network (Part One)][^14]. Its role in the Lightning Network is to build a payment channel between the two parties.
HTLC is a hash lock with an event, which requires a party to submit a preimage $m$ of a hash value $h=H(m)$ within a certain period of time to obtain the right to use a certain UTxO. It is used to build payment routing in the Lightning Network. For the specific implementation process, see [Lightning network in depth, part 2: HTLC and payment routing][^15].
The Lightning Network integrates these two mechanisms, allowing transactions to be completed off-chain between any two nodes in the Lightning Network.
3. Taproot Upgrade
Taproot is a compilation of three Bitcoin Improvement Proposals (BIPs) [BIP-0340 (Schnorr signature)], [BIP-0341 (Taproot)], and [BIP-0342 (TapScript)], and is also the basis for the realization of Taro assets. Here, we explain the MAST involved in the realization of Taro assets:
MAST
BIP-0341 introduces the Merklized Abstract Syntax Tree (MAST)[^7][^8][^9], which aims to hide the spending conditions of UTxO and reduce the size of information. This is part of the Taproot upgrade, which combines the original P2SH (Pay-to-Script-Hash) and P2PKH (Pay-to-Public-Key-Hash) so that a digital output can be used directly through a private key, or by providing a script and Merkle proof of the spending output.
MAST combines the abstract semantic tree and the Merkle tree. As a common data structure in blockchain, the Merkle tree will not be described here. The Abstract Syntax Tree (AST) is a method of dividing a program into independent small blocks to describe the program, which makes the program easier to analyze and optimize. For details, please refer to [Abstract syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree). MAST combines the idea of AST to divide the program into multiple small blocks, and then hash each small block of the program, and use the idea of Merkle hash tree to construct these hash results into Merkle trees.
Consider a script[^9]: Alice wants to be able to spend her bitcoins at any time, but if she does not spend them for three consecutive months, her siblings Bob and Charlie can spend the UTxO. The script is implemented as follows:
OP_IF OP_CheckSig OP_ELSE "3 months" OP_CSV OP_DROP 2 2 OP_CHECKMULTISIG OP_ENDIF
Under P2SH, such a script needs to be fully exposed in the transaction when it is spent. Alice needs to provide the script and the public keys of Bob and Charlie contained in it when spending the UTxO.
After having MAST, we divide the two conditions of the script and get a simple MAST
At this point, when spending, Alice only needs to choose to provide her public key verification script and Hash2 as a Merkle proof, without exposing the specific script under Hash 2, and this part of information will not be uploaded to the chain. This further reduces the overhead of similar transactions, which is natural. Providing a complete script always requires less data than providing the hash value of the script. Such a structure also makes it possible to implement smart contracts. This method is just like the bytecode in EVM. Before running, the function to be called can be selected based on the first 4 bytes of the input data. The difference is that such a script call requires the user to provide a specific script and a Merkle proof to prove that the script is legal.
4. Taproot Assets
Taproot Assets (hereinafter referred to as Taro)[^2][^3][^5] is a protocol that is still in the proposal stage. It can issue assets on Bitcoin. Such assets can be transferred through the Bitcoin network through on-chain transactions (the transaction and transfer of NFTs have been implemented by Ordinals). In particular, homogeneous Taro assets can be transferred on the Lightning Network with lower fees and more privacy after being deposited in a Lightning channel. Similarly, there is the RGB protocol that attempts to run smart contracts on the Lightning Network[^4].
Taro can be circulated on the Bitcoin mainnet or the second-layer lightning network. Considering the situation on the Bitcoin network first, Taro is a hashed metadata form attached to the transaction. The purpose of using hashing is to reduce the space occupied by the transaction to save handling fees. Such a hashed metadata form is the core of Taro. Such a hash value can even represent millions of actual transactions. Its principle will be introduced later.
The second is Taro's situation on the Lightning Network. Using the Lightning Network allows homogeneous Taro assets to achieve faster transaction speeds, which is similar to using the Lightning Network to transfer Bitcoin faster and at a lower cost. In Taro's proposal, the Lightning Network itself does not need to change. In order to realize a transaction of a certain Taro asset, only the first and last channels of the entire payment path need to be able to identify the Taro asset, while the routing channels in the middle are normal Lightning Network transfer methods. They transfer equivalent Bitcoins, which also leads to Taro assets usually being exchanged with other assets at the edge of the network.
Taro Protocol
Now that we know the benefits that Taro can bring, the next thing we need to introduce is, what is it? And how to achieve it? Just as we need to understand that BRC-20 is a pile of paper with transfer records that require a third-party institution to keep accounts, ERC-20 is a string of balance information recorded and maintained by smart contracts. How does Taro achieve the issuance and transfer of assets?
Asset Tree
The asset tree is a two-level Merkle tree structure in Taro, which is used to represent Taro assets. The first level is a Merkle tree composed of Taro information as leaf nodes, and the second level is a tree composed of MS-SMT to represent the assets owned by each account. The idea of MS-SMT is relatively simple. While the Merkle hash tree is based on hashing to form a tree structure, each node also stores the sum of the left and right child nodes to achieve it (the hash operation itself is also a kind of summation). Such asset trees and MS-SMT trees are used to construct Taro's UTxO.
The asset leaf is the bottom structure in the asset tree. It is represented by the light blue node in the asset tree diagram. It uses assetScriptKey (assetScriptKey can be compared to the hash value of the transaction script in P2SH transactions) as the key. Each asset leaf represents a UTxO of the Taro asset. The options contained in the asset leaf can be found in [Understanding Taproot Assets Protocol].
MS-SMT
The Merkle Sum Sparse Merkle Tree[^11] is a data structure defined in [bip-tap-ms-smt]. It is an enhanced version of the sparse Merkle tree and is currently a proposal in bips that has not yet been accepted. Since the key is 256 bits long, such an MS-SMT has $2^{256}$ leaf nodes, most of which are empty, so it is a sparse Merkle tree.
Each leaf contains a quantity, and each branch submits the total amount in the leaf upward, so that the sum contained in the branch can be known without knowing the contents of each subtree. And like a general Merkle tree, a pruned tree containing any leaf can provide proof of membership (a concept in cryptographic accumulators, which is a "proof" used to prove that an element is in a set). MS-SMT also supports proof of non-existence of membership (which is implemented by explicitly indicating that the leaves of non-existent keys are None), that is, proving that such a key is None in the tree to prove that it does not exist. Such a structure can efficiently verify whether there is a change in the values and distribution stored in the tree.
The figure below shows a Merkle sum tree and its changed structure. The Merkle sum sparse tree combines the characteristics of the sparse tree, prunes away empty element nodes, and only stores meaningful information. Empty nodes are represented by None.
Taro Asset Issuance
The issuance of Taro assets requires an identifier. Just as the smart contract of an ERC-20 token has an address, the Taro protocol defines how the identifier is generated: ID=SHA256(genesisPoint||assetTag||assetMeta) It hashes the transaction output information used to mint the asset, the asset tag (such as the hash value of the asset name), and the asset's metadata (images, links, or documents) to obtain an identifier.
The transfer script of Taro assets can have inputs and outputs similar to Bitcoin transactions, and the transaction that creates assets does not need to contain any inputs of Taro assets. It can be seen that Taro assets follow the UTxO model of Bitcoin. The issuance of assets is to publish a transaction of Taro assets, which has no inputs, only outputs.
Taro's input and output are implemented based on the asset tree. As mentioned above, the first level of the asset tree represents the Taro assets stored in the UTxO* (this writing method will continue to be used later, and * indicates that such a structure is in the Taro asset rather than in Bitcoin), and the MS-SMT corresponding to the Taro asset ID stores the information of the Taro asset output by the UTxO*.
The following figure shows how to construct a Taro asset issuance transaction, with a Bitcoin UTxO as input, and outputs a normal Bitcoin UTxO and an additional UTxO* of Taro asset A. **Such an UTxO\* is represented as a Merkle root on Bitcoin**, and it is represented as an asset tree off-chain, which records the assetId of Taro asset A and the records in the MS-SMT corresponding to asset A.
Taro Asset Transfer
If you can understand the creation of assets in the previous section, you can understand the asset transfer process more quickly. The transfer of assets is similar to a transaction in Bitcoin, where a series of available UTxOs are selected as inputs, and then a series of UTxOs are output. In Taro assets, a series of available UTxO*s are selected as inputs, and a series of UTxO*s are output.
In this transaction, A transfers all of his Trao asset X to B without splitting it. When B receives the transaction, he needs to verify whether the asset meets the payment conditions and no extra output is generated to confirm the receipt of the asset.
The conditions that need to be verified include but are not limited to:
* Does the asset tree created for B contain a new UTxO that satisfies the payment conditions? * Has the input UTxO been removed from A’s updated asset tree? * If there are other outputs in the transaction, do they contain additional asset trees?
This information can be verified by the membership/non-membership proof of MS-SMT and the pre-image and proof of Trproot output. The merger and split of assets will not be described in detail. Their process is similar to the asset transfer process, but the split proof or merger proof is included in the output UTxO*.
Taro Universe
Universe is a service that provides asset holders with information and proof of their assets [^6]. It functions similarly to a Bitcoin block explorer [^13], but it displays transaction data for Taproot assets stored off-chain with the Taro asset client. Universe can be operated by the asset issuer itself, or the issuer can appoint an operator. It is conceivable that a community-operated Universe aggregates information submitted by asset holders.
V. Conclusion
So far in the previous article, we have briefly introduced the technology on which Taro Asset is based and its own implementation principle. In the next article, 3P Labs will introduce the current development status of Ordinals and Taro Asset.
资料引用[^1]: [Ordinal Theory Handbook][^2]:[What Is Taro in Bitcoin?][^3]:[Taproot Assets][^4]:[A BRIEF INTRODUCTION TO RGB PROTOCOLS][^5]:[Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning][^6]:[Taproot Assets Protocol][^7]:[Merklized Abstract Syntax Tree][^8]:[Merklized Abstract Syntax Tree][^9]:[What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?][^10]:[Understanding Taproot Assets Protocol][^11]:[bip-tap-ms-smt][^12]:[Fixing The Privacy Gap In Proof Of Liability Protocols]
[^13]:[Blockstream Explorer][^14]:[A Dive into Lightning Network (Part One)]([A Dive into Lightning Network (Part One)][^15]:[Lightning network in depth, part 2: HTLC and payment routing]
