1. Introduction
Bitcoin, as the earliest and most secure blockchain, uses the UTxO account model, which makes it difficult to support smart contract functions like Ethereum, and can only support limited functions based on scripting languages. Therefore, in the 15 years since Bitcoin was born, it has not been used to implement various dazzling DeFi protocols and NFTs like Ethereum, but is usually used for peer-to-peer transfers and value storage.
The Ordinals protocol, officially launched on December 14, 2022, changes all of this. It puts the metadata that users need to store on the chain into transaction inputs and implements a set of programs based on ordinal theory[^1] to track and record these “inscriptions”. The “inscription” realized in this way records static metadata, rather than dynamic executable on-chain programs like Ethereum smart contracts. This also makes “inscriptions” a natural NFT on Bitcoin. And based on ordinal theory, people can also construct transactions to transfer and trade these inscriptions.
Afterwards, on March 6, 2023, the Ordinals-based BRC-20 protocol was proposed, which is used to implement homogenous tokens on Bitcoin, corresponding to the ERC-20 protocol on Ethereum. This protocol based on Ordinals is very simple, and the process of token minting and transfer is written on the inscriptions 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 institution.
This BRC-20 protocol has a strong aesthetic appeal and is a compromise under various factors. Previously, Bitcoin had also seen homogenous tokens like colored coins, so this cannot prove that BRC-20 is a failed application, but it seems to indicate that it may not be a long-lasting protocol. So, we enter the main topic of this article, Taproot Assets based on the Lightning Network.
2. Lightning Network
The Lightning Network is a Layer 2 solution built on Bitcoin, aiming to help users save costs and improve efficiency in Bitcoin payment scenarios. The idea behind the Lightning Network is also simple, which is to build a fund pool, also known as a micro-payment channel between the two parties in a transaction. More specifically, it involves two core concepts:
· Revocable Sequence Maturity Contract (RSMC)
· Hashed Timelock Contract (HTLC)
RSMC assumes that there is a micro-payment channel between the two parties in a transaction. The two parties first deposit a certain amount of funds into this channel, and the initial allocation scheme is the pre-deposited amount. In each transaction, both parties need to confirm the resulting allocation and invalidate the original allocation scheme. This process involves multiple concepts and is quite ingenious. For more details, please refer to [A Dive into Lightning Network (LianGuairt One)][^14]. Its role in the Lightning Network is to build a payment channel between the two parties.
HTLC is a hash time-locked contract that requires one party to submit the preimage $m$ of a hash value $h=H(m)$ within a certain period of time to obtain the right to use a UTxO. It is used in the Lightning Network to construct payment routes, and the specific implementation process can be found in [Lightning network in depth, LianGuairt 2: HTLC and LianGuaiyment routing][^15].
The Lightning Network integrates these two mechanisms, allowing transactions to be completed off-chain between any two nodes in the Lightning Network.
III. Taproot Upgrade
Taproot is an assembly of three Bitcoin Improvement Proposals (BIPs): BIP-0340 (Schnorr signatures), BIP-0341 (Taproot), and BIP-0342 (TapScript). It also forms the basis for Taro assets’ implementation. Here, we explain MAST, which is involved in the implementation of Taro assets:
MAST
BIP-0341 introduces Merklized Abstract Syntax Trees (MAST) [^7][^8][^9], which aims to hide the spending conditions of UTxOs and reduce the size of information. This is part of the Taproot upgrade, which combines the existing P2SH (Pay-to-Script-Hash) and P2PKH (Pay-to-Public-Key-Hash) to allow a single output to be spent directly with a private key, or using a script and Merkle proof for spending outputs.
MAST combines abstract syntax trees (AST) and Merkle trees. Merkle trees are a common data structure in blockchains and will not be further elaborated here. An abstract syntax tree (AST) is a way to divide a program into independent blocks to describe the program, making it easier to analyze and optimize the program. For more details, please refer to [Abstract syntax tree]. MAST combines the idea of dividing a program into multiple small blocks using AST and hashes each small block. It then constructs a Merkle tree using the Merkle tree concept.
Consider the following script [^9]: Alice wants to be able to spend her bitcoins at any time, but if she doesn’t spend them for three consecutive months, 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. Alice needs to provide this script and the public keys of Bob and Charlie embedded in it when spending this UTxO.
With MAST, the two conditions of this script can be divided, resulting in a simplified MAST:
At this time, when Alice spends, she only needs to choose her public key verification script and Hash2 as the Merkel proof, without exposing the specific script under Hash2. This information will not be stored on the chain. This also further reduces the cost of similar transactions, which is natural because providing the complete script is always less data than providing the hash value of the script. This structure also provides possibilities for the implementation of smart contracts, similar to bytecode in EVM, where the function to be called can be selected based on the first 4 bytes of the input data before execution. The difference is that such script calls require users to provide specific scripts and Merkel proof to prove that the scripts are valid.
IV. Taproot Assets
Taproot Assets (referred to as Taro for short) [^2] [^3] [^5] is a proposed protocol that enables the issuance of assets on Bitcoin. Such assets can be transferred through the Bitcoin network via on-chain transactions (transactions and transfers of NFTs have been implemented by Ordinals). Specifically, fungible Taro assets can be transferred with lower fees and more privacy on the Lightning Network after being deposited into a Lightning channel. A similar attempt is the RGB protocol, which aims to run smart contracts on the Lightning Network [^4].
Taro can circulate on the Bitcoin mainnet or the Layer 2 Lightning Network. First, consider the case on the Bitcoin network. Taro is attached to transactions in the form of hashed metadata, with the purpose of reducing transaction size to save fees. Such hashed metadata is the core of Taro, and a single hash value can represent millions of actual transactions. Its principle will be introduced in the following sections.
Next is the case of Taro on the Lightning Network. Using the Lightning Network allows for faster transaction speeds for fungible Taro assets, similar to using the Lightning Network for faster and lower-cost Bitcoin transfers. In the proposal for Taro, the Lightning Network itself does not need to change. To execute a transaction of a certain Taro asset, only the first and last channels of the entire payment path need to recognize the Taro asset, while the routing channels in between operate as normal Lightning Network transfers, which are equivalent in transferring Bitcoin. This also leads to Taro assets typically being exchanged on the edges of the network with other assets.
Taro Protocol
Now that we understand the benefits brought by Taro, the next step is to introduce what it is and how it is implemented. Just as understanding BRC-20 means a stack of paper records that require a third-party institution to keep accounts, and 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 Trees
Asset trees are a two-level Merkle tree structure in Taro, used to represent Taro assets. The first level consists of Taro information as leaf nodes to form a Merkle tree, and the second level is a tree representing the assets each account holds, constructed using MS-SMT. The idea behind MS-SMT is relatively simple. While constructing the Merkle hash tree based on hashes, each node also stores the sum of its left and right child nodes to achieve the sum (hash calculation itself can be considered a form of summation). These asset trees and MS-SMT trees are used to construct Taro’s UTxO.
The Asset Leaf is the bottom layer structure in the asset tree, represented by a light blue node in the asset tree diagram. It uses the assetScriptKey (which can be compared to the hash value of the transaction script in a P2SH transaction) as the key. Each asset leaf represents a UTxO of Taro assets, and the optional items included in the asset leaf can be referred to in [Understanding Taproot Assets Protocol].
MS-SMT
The Merkle Sum Sparse Tree (Merkle Sum SLianGuairse 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 an unreceived proposal in the BIPs. Since the key is 256 bits long, there are $2^{256}$ leaf nodes in such an MS-SMT, most of which are empty, making it a sparse Merkle tree.
Each leaf contains a quantity, and each branch submits the total amount in the leaves upwards, so that the total amount in the branch can be known without knowing the content of each subtree. Like a regular Merkle tree, a pruned tree containing any leaf can provide a proof of membership (this is a concept in cryptographic accumulators, a kind of “proof” to confirm that an element exists in a set). The MS-SMT also supports proofs of non-membership (it achieves this by explicitly indicating that the leaf of the non-existent key is None), i.e., it proves that such a key is None in the tree to confirm its non-existence. This structure can efficiently verify whether the stored values and distributions on the tree have changed.
The following figure shows a Merkle sum tree and its changed structure, while the Merkle sum sparse tree combines the characteristics of a sparse tree, pruning off empty element nodes and only storing meaningful information, with empty nodes represented by None.
Taro Asset Issuance
Issuing a Taro asset requires an identifier. Just as the smart contract of an ERC-20 token has an address, the Taro protocol defines the generation method of the identifier: 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 metadata (image, link, or document) to obtain an identifier.
The transfer script of a Taro asset can have inputs and outputs similar to a Bitcoin transaction, and the transaction for creating an asset does not need to include any inputs of Taro assets. Therefore, it can be seen that Taro assets follow the UTxO model of Bitcoin, and asset issuance is a transaction that issues a Taro asset, which has no inputs, only outputs.
Taro’s inputs and outputs are implemented based on the asset tree. As mentioned earlier, the first level of the asset tree represents the Taro assets held in the UTxO* (this notation will continue to be used later, with * indicating that such a structure is in Taro assets rather than Bitcoin), and the MS-SMT corresponding to the Taro asset ID stores information about the Taro assets output in that UTxO*.
The construction of a Taro asset issuance transaction is shown in the diagram below. It takes a Bitcoin UTxO as input and outputs a normal Bitcoin UTxO as well as an additional UTxO* for the Taro asset A. Such UTxO* appears as a Merkle root on Bitcoin, while it appears as an asset tree off-chain, which records the assetId of Taro asset A and the corresponding record in the MS-SMT of asset A.
Taro Asset Transfer
If one can understand the creation of assets in the previous section, one can quickly understand the process of asset transfer. Asset transfer is similar to a transaction in Bitcoin, selecting a series of available UTxOs as inputs, and then outputting a series of UTxOs. In the case of 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 its Trao asset X to B without splitting. When B receives the transaction, it needs to verify that the asset meets the payment conditions and that no excess outputs have been generated to confirm receipt of the asset.
The conditions 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 removed from the updated asset tree of A?
· If there are other outputs in the transaction, do they contain additional asset trees?
These pieces of information can be verified by the member/non-member proofs of the MS-SMT, as well as the pre-image and proofs output by Trproot. The merging and splitting of assets will not be further elaborated, as their processes are similar to the process of asset transfer, but the output UTxO*s contain splitting or merging proofs.
Taro Universe
Universe is a service that provides asset holders with information and proofs about assets [^6]. Its function is similar to a Bitcoin block explorer [^13], but it displays transaction data of Taproot assets stored off-chain together with the Taro asset client. Universe can be operated by the issuer of the asset himself or appointed by the issuer, and it can be imagined that a Universe operated by the community aggregates the information submitted by asset holders.
5. Conclusion
In this article, we have briefly introduced the technology on which Taro assets are based and their implementation principles. In the next article, we will introduce Ordinals and the current development status of Taro assets.
References:
[^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 (LianGuairt One)](A Dive into Lightning Network (LianGuairt One))
[^15]: [Lightning network in depth, LianGuairt 2: HTLC and LianGuaiyment routing]
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
