I. Introduction

As the earliest and most secure blockchain, the UTxO account model used by Bitcoin 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 various dazzling DeFi protocols and NFTs like Ethereum, and is usually used for peer-to-peer transfers and value storage.

The Ordinals protocol, which was officially launched on December 14, 2022, changed everything. 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". What such "engraving" achieves is recording static metadata, rather than dynamically executable on-chain programs like Ethereum smart contracts. This also makes "inscription" naturally become an NFT on Bitcoin. Based on ordinal theory, people can also construct transactions to realize the transfer and transaction between these inscriptions.

Afterwards, on March 6, 2023, the BRC-20 protocol based on Ordinals was proposed, which was used to implement homogeneous tokens on Bitcoin, corresponding to the ERC-20 protocol on Ethereum. The protocol based on Ordinals is very simple. The process of minting and transferring the token 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 accounting is left to the third party. The tripartite agencies will do it.

Such a BRC-20 protocol has a rather violent aesthetic and is also a compromise under various factors. Homogenous tokens like colored coins have appeared in Bitcoin before. This does not prove that BRC-20 is a failed application, but it also seems to indicate that it may not be a long-term agreement. At this point, we enter the topic of this article, Taproot Assets based on the Lightning Network.

2. Lightning Network

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 that the Lightning Network relies on is also very simple, that is, building a fund pool. Such a fund pool is also called a micropayment channel for both parties to the transaction. More specifically, it involves two core concepts:

· Revocable Sequence Maturity Contract (RSMC): The group photo can be revoked when the sequence expires

· Hashed Timelock Contract (HTLC): Hashed Timelock Contract

RSMC assumes that there is a micropayment channel between the two parties. Both parties first deposit a part of the funds into this channel. In the initial case, the allocation plan between the two parties is the pre-deposited amount. Every time a transaction occurs, both parties need to confirm the distribution results generated after the transaction, and at the same time invalidate the original distribution plan. This process involves many concepts and is quite clever. For details, please refer to [ A Dive into Lightning Network (Part One) ][^14], and its role in the Lightning Network is to build a payment channel between the two parties.

HTLC is a hash lock with events, which requires a certain party to submit a preimage $m$ of a certain 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 Proposal (BIP) BIP-0340 (Schnorr signature) , BIP-0341 (Taproot) and BIP-0342 (TapScript) . It is also the basis for the realization of Taro assets. Here, the MAST involved in the implementation of Taro assets is explained:

MAST

Merklized Abstract Syntax Tree (MAST) [^7][^8][^9] was introduced in BIP-0341, whose purpose is to hide the spending conditions of UTxO and reduce the size of the information. This is part of the Taproot upgrade. The Taproot upgrade combines the original P2SH (Pay-to-Script-Hash) and P2PKH (Pay-to-Public-Key-Hash), so that a sum can be output directly through the private key. To use, you can also provide scripts and Merkle proofs for spending output.

MAST combines abstract semantic trees and Merkle trees. Merkle trees are a common data structure in blockchains and will not be described in detail here. The Abstract Syntax Tree (AST) is a method of dividing a program into independent small pieces to describe the program. This will make the program easier to analyze and optimize. For details, please refer to [Abstract syntax tree] . MAST combines the idea of ​​AST to divide the program into multiple small blocks, then hashes each small block of the program, and uses the idea of ​​Merkle hash tree to construct these hash results into a Merkle tree.

Consider such a script [^9]: Alice wants to spend her Bitcoins at any time, but if she does not spend for three consecutive months, then her siblings Bob and Charlie can spend the UTxO. The script is implemented as follows:

OP_IF

<Alice's pubkey> OP_CheckSig

OP_ELSE

"3 months" OP_CSV OP_DROP

2 <Bob's pubkey> <Charlie's pubkey> 2

OP_CHECKMULTISIG

OP_ENDIF

Under P2SH, such a script needs to be fully exposed in the transaction when spending it. Alice needs to provide the script and the public keys of Bob and Charlie contained in it when spending the UTxO.

After having MAST, divide the two conditions of the script to get a simple MAST

At this time, Alice only needs to choose to provide her public key verification script and Hash2 as the Merkel proof when spending, without exposing the specific script under Hash 2. This part of the information will not be uploaded to the chain. This also further reduces the overhead of similar transactions. It is natural that providing a complete script always requires less data than providing a hash of the script. Such a structure also provides the possibility for the implementation of smart contracts. In this way, just like the bytecode in the EVM, the function to be called can be selected based on the first 4 bytes of the input data before running. The difference is that such a script call requires the user to provide a specific script and a Merkel certificate to prove that the script is legitimate.

4. Main root assets

Taproot Assets (Taproot Assets, subsequently referred to as Taro) [^2][^3][^5] is a protocol that is still in the proposal stage. It can realize the issuance of assets on Bitcoin. Such assets can be issued through the chain. Transactions are transferred through the Bitcoin network (transactions and transfers 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 into the 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. First consider the situation in the Bitcoin network. Taro is a hashed metadata form attached to the transaction. The purpose of using hashing is to reduce the space occupied by the transaction and save handling fees. This form of hashed metadata 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 the situation of Taro on the Lightning Network. Using the Lightning Network can allow homogeneous Taro assets to achieve faster transaction speeds, which is similar to using the Lightning Network to transfer Bitcoin faster and at lower cost. In Taro's proposal, the Lightning Network itself does not need to be changed. In order to realize a transaction of a certain Taro asset, only the first channel and the last channel of the entire payment path need to be able to identify the Taro asset, and the route in the middle Channels are normal Lightning Network transfer methods. They transfer equivalent Bitcoins, which also results in Taro assets usually being exchanged with other assets at the edge of the network.

Taro protocol

Now that we understand the benefits that Taro can bring, the next thing that needs to be introduced is, what is it? And how to achieve it? Just as you need to understand that BRC-20 is a pile of paper with written transfer records that require third-party institutions to keep accounts, ERC-20 is a string of balance information recorded and maintained by smart contracts. How does Taro realize the issuance and transfer of assets?

Asset tree

Asset tree is a two-level Merkle tree structure in Taro, which is used to represent Taro assets. The first level is a Merkel tree composed of Taro information as leaf nodes, while the second level is a tree composed of MS-SMT that represents the assets owned by each account. The idea of ​​MS-SMT is relatively simple. While the Merkle hash tree forms a tree structure based on hashing, each node also stores the sum of the left and right child nodes (the hash operation itself is also a kind of summation). Such an asset Trees and MS-SMT trees are used to build Taro's UTxO.

Asset Leaf (Aseet Leaft) is the lowest-level structure in the asset tree. It appears as a 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 a Taro asset. The options contained in the asset leaf can be found in [ Understanding Taproot Assets Protocol ].

MS-SMT

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 one of the bips Proposals that remain unaccepted. Since the key is 256 bits long, such 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 commits the total in the leaf upward, so that the sum contained in the branch can be known without knowing the contents of each subtree. Like a regular Merkle tree, a pruned tree containing any leaves can provide a proof of membership (a concept in cryptographic accumulators, which is a "proof" used to prove that an element is in a set middle). MS-SMT also supports member non-existence proof (which is implemented by explicitly indicating that the leaf of a non-existent key is None), that is, proving that such a key is None in the tree to prove that it does not exist. This structure can be efficient Verify whether there are changes to the values ​​and distributions stored in the tree.

The picture below is a Merkle sum tree and the structure after it sends changes. The Merkle sum sparse tree combines the characteristics of sparse trees. It constructs empty element nodes and only stores meaningful information. The empty nodes use None means.

Taro asset issuance

The issuance of Taro assets requires an identifier. Just as the smart contract of ERC-20 tokens will have an address, the Taro protocol defines how the identifier is generated: ID = SHA256(genesisPoint||assetTag||assetMeta), which will mint The transaction output information used by the asset, the asset tag (such as a hash of the asset name), and the asset's metadata (image, link, or document) are hashed to produce an identifier.

The transfer script of Taro assets can have input and output similar to Bitcoin transactions, and the transaction to create assets does not need to include any input of Taro assets. It can be seen that Taro assets follow the UTxO model of Bitcoin, and the issuance of assets is to issue a A transaction of Taro assets 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 UTxO* (this writing method will continue to be used later, * indicates that such a structure is in the Taro asset. What are the Taro assets stored in non-Bitcoin)? What is stored in the MS-SMT corresponding to the Taro asset ID is the information of the Trao asset output by the UTxO*.

The issuance transaction of constructing a Taro asset is as shown in the figure below. It takes a Bitcoin UTxO as input and outputs a normal Bitcoin UTxO and an additional UTxO* of Taro asset A. Such UTxO* appears in the form of a Merkel root on Bitcoin, and it appears in the form of an asset tree off-chain. The asset tree records the assetId of Taro asset A and the record in 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, selecting a series of available UTxO as input, and then outputting a series of UTxO. In Taro assets, a series of available UTxO* are selected as input and a series of UTxO* are output.

In this transaction, A transfers all its Trao assets X to B without splitting them. When B receives the transaction, it needs to verify whether the asset meets the payment conditions and no redundant output is generated to confirm receipt of the asset.

Conditions required to be verified include but are not limited to:

· Does the asset tree created for B contain new UTxOs that meet the payment conditions?

· Has the input UTxO been deleted from the asset tree of A that has been updated?

· If there are other outputs in the transaction, do they contain additional asset trees?

This information can be verified by MS-SMT's membership/non-membership proofs and the preimage and proof output by Trproot. The merger and split of assets will not be described in detail. Their process is similar to the process of asset transfer, but the output UTxO* contains a split certificate or a merger certificate.

Taro Universe

Universe is a service that provides asset holders with information and proofs about assets[^6]. Its function is similar to the Bitcoin block explorer[^13], but it will display the information stored with the Taro asset client. Transaction data of off-chain Taproot assets. The universe can be operated by the issuer of the asset itself, or the issuer can appoint an operator. It is conceivable that the universe operated by the community aggregates the information submitted by the asset holders.

5. Conclusion

So far in the previous article, we have briefly introduced the technology on which Taro asset implementation is based, as well as its own implementation principles. In the next article, we will introduce the current development status of Ordinals and Taro assets.

Data citation:

[^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 ]

3P Labs related links:

Twitter: https://twitter.com/3PDAO

Telegram: https://t.me/Labs_3P

Mirror: https://mirror.xyz/3p-labs.eth

Medium: https://medium.com/@3p-labs