Ordinals vs Taro: A Discussion on the Feasibility of Bitcoin Layer 2 Networks - Part 1

Author: 3P Labs

1. Introduction

Bitcoin, as the earliest and most secure blockchain, uses the UTxO account model, which makes it difficult to support smart contract functionalities like those on Ethereum, only allowing for some limited script-based features. Therefore, in the 15 years since Bitcoin's inception, it has not been used to implement the dazzling array of DeFi protocols and NFTs found on Ethereum, and is typically used for peer-to-peer transfers and value storage.

The Ordinals protocol, officially launched on December 14, 2022, changed all of this by embedding the metadata that users need to store on-chain into transaction inputs, and implementing a program based on ordinal theory[\^1] to track and record these "inscriptions." Such "inscriptions" represent 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 facilitate the transfer and trading of these inscriptions.

Subsequently, on March 6, 2023, the BRC-20 protocol based on Ordinals was proposed, which is used to implement fungible tokens on Bitcoin, corresponding to the ERC-20 protocol on Ethereum. The BRC-20 protocol based on Ordinals is quite simple, writing the processes of minting and transferring tokens in JSON format onto inscriptions, with the most vivid metaphor being sheets of paper recording transfer transactions, while the bookkeeping is left to third-party institutions.

The BRC-20 protocol has a certain aesthetic of brutalism and is also a compromise under various factors. Previously, Bitcoin had seen the emergence of colored coins as fungible tokens, which does not disprove that BRC-20 is a failed application, but it seems to indicate that it may not be a long-term protocol. Thus, 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, aimed at helping users save costs and improve efficiency in Bitcoin payment scenarios. The underlying idea of the Lightning Network is quite simple: to construct a pool of funds, which is also referred to as a micropayment channel between the two parties involved in a transaction. More specifically, it involves two core concepts:

• Revocable Sequence Maturity Contract (RSMC): Revocable sequence maturity contract
• Hashed Timelock Contract (HTLC): Hashed time-locked contract

RSMC assumes the existence of a micropayment channel between the two parties, where both parties first deposit a portion of funds into this channel. Initially, the allocation scheme for both parties is based on the amounts deposited. Each time a transaction occurs, both parties need to confirm the resulting allocation after the transaction and invalidate the original allocation scheme. This process involves many concepts and is quite clever; for specifics, refer to [A Dive into Lightning Network (Part One)][\^14]. Its role in the Lightning Network is to construct the payment channel between the two parties.

HTLC is a hash-locked contract with an event, requiring one party to submit the pre-image $m$ of a hash value $h=H(m)$ within a certain time to gain access to a specific UTxO. It is used in the Lightning Network to construct payment routing; 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 it serves as the foundation for the implementation of Taro assets. Here, we explain MAST involved in the implementation of Taro assets:

MAST

BIP-0341 introduces the Merklized Abstract Syntax Tree (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 original P2SH (Pay-to-Script-Hash) and P2PKH (Pay-to-Public-Key-Hash), allowing an output to be spent directly with a private key or by providing a spending script and Merkle proof.

MAST combines the abstract syntax tree and Merkle tree; the Merkle tree is a common data structure in blockchains and will not be elaborated here. An abstract syntax tree (AST) is a method of breaking down a program into independent small pieces to describe the program, making it easier to analyze and optimize; for specifics, refer to [Abstract syntax tree](https://en.wikipedia.org/wiki/Abstractsyntaxtree). MAST incorporates the idea of dividing a program into multiple small pieces from AST, hashing each piece, and using the Merkle hashing tree concept to construct these hash results into a Merkle tree.

Consider a script[\^9]: Alice wants to be able to spend her Bitcoin at any time, but if she does not spend it for three consecutive months, her siblings Bob and Charlie can spend this UTxO. The script implementation is as follows:

OPIF \ OPCheckSig
OPELSE "3 months" OPCSV OPDROP 2 \ \ 2 OPCHECKMULTISIG
OP_ENDIF

Under P2SH, such a script needs to be fully exposed in the transaction when spending; Alice must provide this script along with the public keys of Bob and Charlie when spending this UTxO.

With MAST, the two conditions of the script can be divided, resulting in a simple MAST.

At this point, when Alice spends, she only needs to provide her public key verification script and Hash2 as the Merkle proof, without exposing the specific script under Hash 2; this part of the information will not go on-chain. This further reduces the overhead of similar transactions, which is quite natural, as providing the complete script always results in a smaller data size than providing the hash of the script. Such a structure also provides the possibility for the implementation of smart contracts, similar to how bytecode in the EVM can select the function to be called based on the first four bytes of the input data before execution. The difference is that such script calls require the user to provide the specific script and Merkle proof to prove the script's validity.

4. Taproot Assets

Taproot Assets (hereinafter referred to as Taro)[\^2][\^3][\^5] is a protocol still in the proposal stage that allows for the issuance of assets on Bitcoin. These assets can be transferred through on-chain transactions over the Bitcoin network (the trading and transfer of NFTs have already been implemented by Ordinals). Specifically, fungible Taro assets can be transferred on the Lightning Network with lower fees and greater privacy after being deposited into Lightning channels, similar to the RGB protocol[\^4] that attempts to run smart contracts on the Lightning Network.

Taro can circulate on the Bitcoin mainnet or the second layer Lightning Network. First, consider the situation on the Bitcoin network: Taro is an hashed metadata form attached to transactions, with the purpose of hashing being to reduce the space occupied by transactions to save on fees. This hashed metadata form is the core of Taro; a single hash value can even represent millions of actual transactions, and the principle will be introduced later.

Next, in the context of Taro on the Lightning Network, using the Lightning Network allows fungible Taro assets to achieve faster transaction speeds, similar to how using the Lightning Network can transfer Bitcoin more quickly and at a lower cost. In the proposal for Taro, the Lightning Network itself does not need to change; to execute a transaction for a certain Taro asset, only the first and last channels of the entire payment path need to recognize the Taro asset, while the intermediate routing channels use the normal Lightning Network transfer methods, transferring equivalent Bitcoin, which also leads to Taro assets typically being exchanged at the edges of the network with other assets.

Taro Protocol

Now that we understand the benefits that Taro can bring, the next question is: what is it? And how is it implemented? Just as understanding BRC-20 is akin to a pile of pre-written transfer records that require a third-party institution to keep the books, 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 Tree

The asset tree is a two-level Merkle tree structure in Taro, used to represent Taro assets. The first level is a Merkle tree composed of Taro information as leaf nodes, while the second level is constructed through MS-SMT to represent the tree of assets held by each account. The idea of MS-SMT is quite simple; while the Merkle hash tree forms a tree structure based on hashes, each node also stores the sum of its left and right child nodes (performing a hash operation is also considered a form of summation). This asset tree and MS-SMT tree are used to construct Taro's UTxO.

Asset Leaf is the lowest structure in the asset tree, represented as the light blue nodes in the asset tree diagram. It uses assetScriptKey (which can be likened to the hash of the transaction script in P2SH transactions) as the key. Each asset leaf represents a UTxO of Taro assets, and the optional items contained in the asset leaf can be referenced in [Understanding Taproot Assets Protocol].

MS-SMT

Merkle Sum Sparse Merkle Tree[\^11] is a data structure defined in [bip-tap-ms-smt], which is an enhanced version of the sparse Merkle tree and is currently an unaccepted proposal in BIPs. Since the key is 256 bits long, this MS-SMT has $2^{256}$ leaf nodes, most of which are empty, making it a sparse Merkle tree.

Each leaf contains a quantity, and each branch submits the total from the leaves upward, allowing one to know the total contained in the branch without knowing the contents of each subtree. Like a regular Merkle tree, a pruned tree containing any leaves can provide proof of membership (this is a concept in cryptographic accumulators, which is a "proof" used to confirm that an element is in a set). MS-SMT also supports proof of non-membership (it achieves this by explicitly indicating that the leaves of non-existent keys are None), which proves that such keys do not exist in the tree. This structure can efficiently verify whether the values and distributions stored in the tree have changed.

The following diagram shows a Merkle sum tree and its structure after sending changes, while the Merkle sum sparse tree combines the characteristics of sparse trees, pruning empty element nodes and only storing meaningful information, with empty nodes represented as None.

Taro Asset Issuance

The issuance of Taro assets requires an identifier, just as ERC-20 tokens have an address for their smart contracts. The Taro protocol defines the method for generating identifiers: ID=SHA256(genesisPoint||assetTag||assetMeta), which hashes the transaction output information used to mint the asset, the asset tag (e.g., the hash of the asset name), and the asset's metadata (images, links, or documents) to obtain an identifier.

The transfer script for Taro assets can have inputs and outputs similar to Bitcoin transactions, and the transaction creating the asset does not need to include any inputs of Taro assets. Thus, Taro assets follow the UTxO model of Bitcoin, and the issuance of assets is simply the release of a Taro asset transaction, which has no inputs, only outputs.

The inputs and outputs of Taro are implemented based on the asset tree. As mentioned earlier, the first level of the asset tree represents which Taro assets are stored in this UTxO* (this notation will continue to be used, with * indicating that this structure is within Taro assets rather than Bitcoin), while the MS-SMT corresponding to the Taro asset ID stores the information of the Taro assets output from this UTxO*.

The construction of a Taro asset issuance transaction is illustrated below, using a Bitcoin UTxO as input, outputting a normal Bitcoin UTxO along with an additional Taro asset A's UTxO. This UTxO manifests as a Merkle root on Bitcoin, while it appears as an asset tree off-chain, recording the assetId of Taro asset A and the records in the corresponding MS-SMT.

Taro Asset Transfer

If one can understand the creation of assets in the previous section, then the asset transfer process can be understood more quickly. The transfer of assets is similar to a transaction in Bitcoin, selecting a series of available UTxOs as inputs and then outputting a series of UTxOs. In Taro assets, it involves selecting a series of available UTxOs* as inputs and outputting a series of UTxOs*.

In this transaction, A transfers all of their Taro asset X to B without splitting. When B receives this transaction, they need to verify whether the asset meets the payment conditions and that no excess outputs have been generated to confirm 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 new UTxOs that meet the payment conditions?
• Have the input UTxOs been removed from the updated asset tree of A?
• If there are other outputs in the transaction, do they contain additional asset trees?

This information can be verified through membership/non-membership proofs from the MS-SMT and the pre-images and proofs of the Taproot outputs. The processes of merging and splitting assets will not be elaborated here; they are similar to the asset transfer process, but the output UTxOs* include split proofs or merge proofs.

Taro Universe

The Universe is a service that provides asset holders with information about assets and proofs[\^6], functioning similarly to a Bitcoin block explorer[\^13], but it displays transaction data of Taproot assets stored off-chain with the Taro asset client. The Universe can be operated by the asset issuer themselves or by appointing an operator; one can imagine a community-operated Universe that aggregates information submitted by asset holders.

5. Conclusion

This article has briefly introduced the technologies underlying the implementation of Taro assets and its implementation principles. In the next article, 3P Labs will discuss the current development status of Ordinals and 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 (Part One)]([A Dive into Lightning Network (Part One)]
[\^15]:[Lightning network in depth, part 2: HTLC and payment routing]