Feasibility Study of Bitcoin Layer 2 Network (Part 2) Ordinals vs Taro

Bitcoin Layer 2 Network Feasibility Study (Part 2) Ordinals vs Taro

Introduction

In the previous article of the Ordinals vs Taro series, we briefly introduced the theoretical implementation of minting and transferring Taro assets in the Taro protocol. Here, we will review the implementation theory of Ordinals and Colored Coin for comparison, and further introduce the implementation and progress of Taro to explore the feasibility of the second-layer network implementation of Bitcoin at a deeper level.

The article will be divided into the following four parts: Bitcoin Homogeneous Token Origin Colored Coin, Ordinals and Sequential Theory, Taro Implementation and Progress, Further Reading: Atomicals Protocol.

Review: Origin of Colored Coin

Colored Coin is a new token generated on the Bitcoin network proposed by Yoni Assia, Vitalik Buterin, and others in 2012 [1] [2]. Colored Coin is the precursor to the commonly used ERC-20 tokens today. It was used to represent assets and conduct voting, similar to the functions supported by ERC-20 tokens today. On the former Colored Coin browser Coinprism, we can still see a series of assets issued by people in 2015, as shown in the snapshot of the webpage left in 2015: Coinprism Snapshot – archive.org.

• Solana RWA Market Landscape and Future Opportunities
• BitVM whitepaper released, how do senior developers view the vision of computing any content on Bitcoin?
• NFT market frozen to the freezing point, can Yuga Labs regain its glory through gaming?

Coinprism Snapshot

Principle

Colored Coin distinguishes a group of bitcoins from other bitcoins through “coloring”. There are two ways to implement Colored Coin: the EPOBC protocol proposed by ChromaWay and Open Assets that use OP_RETURN to store metadata. Here, we will briefly introduce the implementation principle of Open Assets, which is also mentioned by Yoni and others in the Colored Coins white paper [3].

OP_RETURN was proposed in Bitcoin v0.9.0 and can be used to store a small amount of data on Bitcoin [4]. Initially, it had a limit of storing data with a length of 40 bytes, which was later increased to 80 bytes. The Colored Coins white paper (2013) used an encoding with a length of 40 bytes to achieve coloring, while the Colored Coin protocol specification in 2016 [5] used a specification with a length of 80 bytes. The Colored Coin protocol specification in 2016 is more complex and involves the mini-script language of Colored Coin, which will not be further discussed here. The original idea of Colored Coin was to use OP_RETURN to store specific encoding information in the output script of a transaction and rely on off-chain indexing programs to identify the validity of these transactions (similar to the Ordinals that appeared at the end of 2022).

Creating Assets

In the original Colored Coins white paper, the data encoding for creating assets is shown as follows

Encoding format in the Colored Coins white paper

The encoded data starts with 0x0043438000 (“CCP”) to indicate that this is a colored coin genesis transaction, followed by two bytes representing the current protocol version. The next two bytes are for additional issuance instructions, with all zeros indicating that the asset cannot be further issued and all ones indicating that the asset can be infinitely issued. The last 31 bytes are used to store information about coloring. An example of an asset genesis transaction described in the white paper is as follows

The encoded data in the output OP_RETURN indicates that this transaction is the genesis transaction of an asset. According to the encoding rules, the asset created by this transaction can be infinitely issued by the wallet with the address 17zt…sSrb (because the first address in the inputs is this address, and according to the protocol, it can be used as an issuance address). The addresses before the OP_RETURN output can be identified as the addresses receiving the genesis asset. The first three addresses will receive 9,900,000 units of the asset, while the last address will receive 19,900,000 units of the asset. Therefore, it can be seen that each satoshi in the colored coin corresponds to a colored asset.

Why is the received asset quantity reduced by 10,000? This is because the protocol defines a default padding of 10,000 (LianGuaidding), which ensures that 10,000 satoshis are not colored to avoid dust transactions.

Asset Transfer

Asset transfers can be designed to be more complex, such as transferring multiple colored tokens of different colors in a single transaction. However, for the convenience of representing the transfer process, it is assumed here that the transfer is for a single colored token. And the transfer involves the input sequence number (sequence, which is a field in the Bitcoin transaction input and is usually visible as the nSequence field in the browser), which in binary represents which output the token will be transferred to. For example, 6 (110b) means that the token will be output to the first and second outputs, not the 0th or other outputs. An example of a token transfer transaction is shown below, with the input and output address information omitted. The dark color in the diagram indicates that the input or output has been colored.

Colored Transfer Transaction

Representing it as the transfer status of a colored coin, that is, removing LianGuaidding and converting the sequence number in binary to a readable form, the initial status can be obtained as shown below, and the colored markers in the output are directly marked.

Colored Coin Transfer Status Illustration

Starting from input 0, traverse the sequence number to perform the state transition. The transition process is shown in the following figure:

Transfer State Change

• Transfer 5 colored assets from input 0 to output 1. At this time, subtract 5 from sLianGuaice in output 0 and 1. Since it is transferred to 1 and input 0 is a colored asset, the colored value in output 1 increases by 5;
• Transfer 10 colored assets from input 1 to output 1. At this time, subtract min(5, 10) = 5 from output 1. Since it is transferred to 1 and input 1 is a colored asset, the colored value (cvalue) increases by 5;
• Transfer 10 colored assets from input 1 to output 2. At this time, subtract min(5, 10) = 5 from output 2. Since it is transferred to 2 and input 1 is a colored asset, the colored value (cvalue) increases by 5;
• Transfer 20 colored assets from input 2 to input 1. Subtract min(0, 20) = 0 from their sLianGuaice, but since input 2 is not colored, there is no change in cvalue in output 0;

Through this process, it can be seen that the transfer rules of colored coins are relatively complicated. The off-chain indexing program needs to implement a UTxO calculation for the transfer of colored coins based on the Bitcoin UTxO according to a series of rules. The colored coins whitepaper in 2012 also mentioned the technology of decentralized exchanges, which completes the exchange of colored coins in a transaction. Unfortunately, the partial signature transaction technology (PSBTs – BIP0174) required for this technology was not included in the BIP until 2017, so at that time a centralized platform was needed to identify and implement it through an order book (so is it still decentralized?).

Dex in the colored coins whitepaper

Furthermore, in the v2 version of the colored coins protocol specification in 2016, the bytecode, transfer address, and verification rules required for colored coins were further designed. Unfortunately, due to the limitations of Bitcoin’s functionality at that time, this set of rules did not develop further. Moreover, the emergence of Ethereum in 2015 further made this design seem redundant, and colored coins ended its development here. Some people also say that the reason for the failure of colored coins is that it is coupled with native btc and can be mistakenly sent out as btc in some cases, resulting in a decrease. However, the author believes that the reason for its failure is the inconvenience of circulation and the limited application scenarios.

Ordinal Theory: Ordinals

Time comes to December 2022. Thanks to segregated witness and partial signature transaction technology in 2017, as well as the activation of the Taproot upgrade in 2021, Casey Rodarmor invented ordinal theory[7]: Ordinals are a numbering scheme for Bitcoin, making it possible to track and transfer individual sats[6]. They are numbered according to the order in which each bitcoin is mined and according to the first-in-first-out rule when transactions occur.

The representation of ordinals:

• Integer notation: 2099994106992659. This serial number is assigned based on the order of the mined coinbase transactions.
• Decimal notation: 3891094.16797. The first number is the block height of the mined coinbase transaction, and the second number is the offset within the block.
• Degree notation: 3°111094′214″16797‴. The specific degree notation principle is explained in the Ordinal Theory Manual.
• Percentage notation: 99.99971949060254%. Represents the position of a sat in the bitcoin supply as a percentage.
• Name notation: satoshi. Encodes the serial number using the characters a to z.

Inscription

Ordinal theory is more about tracing the smallest unit of Bitcoin, sat. The rules it designs make each sat have a unique number. Based on ordinal theory, some unique data on the chain can be associated with these sats, that is, “inscribing” the inscription. The inscription is stored in the taproot script. The taproot script has few restrictions on content and can obtain additional witness discounts, making the storage of the inscription more economical. The taproot script format for the inscription is similar to:

It is stored in the witness script of the Reveal transaction and is identified and exposed by the off-chain indexing node (ord) when traversing the blocks.

However, due to the limitations of indexing and the inability to perform operations on the chain, when Inscription needs to implement other additional functions, it can only be achieved through the openness of ord, such as recent parent-child inscriptions and curse inscription indexes several months ago. The basic idea of ​​inscriptions is very similar to Colored Coins. They store data in transactions and index them by off-chain programs. The difference is that inscriptions store data in the Taproot script of inputs, while Colored Coins store encoded data in an output.

So far, the Bitcoin ecosystem has developed, allowing people to mint NFTs on the chain, and thanks to partial transaction signature technology, a trading market has also emerged. The technology of inscriptions itself is very similar to colored coins. They both store data on the chain and index them with off-chain indexing tools. However, due to different times and different targeted functions, colored coins were limited by the functional limitations of Bitcoin at that time and did not develop further. What should have allowed Ordinals to develop and explode is its lower engraving cost (compared to the early competitor bitcoin stamp[8]) and the market that has emerged due to the benefits of partial signature transaction technology, which makes it convenient for people to trade inscriptions.

BRC-20

Subsequently, the inscription-based BRC-20 protocol also appeared in March 2023. As mentioned in the previous article, this homogenized token implementation method has a sense of violent aesthetics. The process of minting and transferring tokens is written on paper, and the rest is handed over to the BRC-20 indexer, which is an additional index on top of the Bitcoin indexer Inscription. Of course, in actual implementation, the BRC-20 indexer can ignore other NFT minting and only focus on the minting and transfer of BRC-20.

And BRC-20 now looks a bit like Bitcoin’s second layer network: the second layer network handles a series of transactions, communicates with the main chain regularly, submits transactions for bundling to ensure decentralization. In BRC-20, it is reflected in the indexer indexing the user’s account balance to ensure the validity of certain BRC-20 inscriptions (process transactions), and the process of transfer and minting is implemented by the user themselves (submitting transactions to the main chain).

Interestingly, in the photos released by the Ordinals Summit not long ago, in a PPT of brc20-swap displayed by domo, the founder of BRC-20, two concepts were mentioned: Inscription-Based Virtual Machines and Rollup, which seems to suggest that BRC-20 will also enter the second layer network in the future.

Taro Implementation and Progress

In the previous article, the principle of how Taro assets are minted and transferred on the chain was introduced. So how is it actually implemented? Compared to the introduction of the principle in the previous article, here we will introduce the current implementation method and the latest progress of Taro.

Taro Implementation Details

Due to well-known reasons, it is not possible to join the test network with a local lightning network node set up for testing. Here, we will use the testing process of Understanding Taproot Assets Protocol #2 to explain.

Asset Minting

As mentioned in the previous section, asset minting requires selecting the input UTxO and recording the root node information of a new Merkle Sum Tree (MS-SMT) in the asset tree.

After completing the asset minting process, you can obtain information about the asset:

{

"assets": [

{

"version": 0,

"asset_genesis": {

"genesis_point": "ba779153a792a1d49433fd18e56311f8d212992e7d1405cb14af8dffb34e88ce:0",

"name": "fantasycoin",

"meta_hash": "04e552053fd4c8e2c01bc14cb9a0ce00f07d4ffdffff68fe455c70b934b22a43",

"asset_id": "20cecdb6626705bf26ad036084f7423082db6114f0de84046ebf2e84f6852874",

"output_index": 0,

"version": 0

},

"asset_type": "NORMAL",

"amount": "100",

"lock_time": 0,

"relative_lock_time": 0,

"script_version": 0,

"script_key": "02b4c71447e74672f8cd5b50a6b430fc73b3caff7866dc905a502fe8adefad3b31",

"script_key_is_local": true,

"asset_group": null,

"chain_anchor": {

"anchor_tx": "02000000000101ce884eb3ff....",

"anchor_txid": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356",

"anchor_block_hash": "0000000000000000000000000000000000000000000000000000000000000000",

"anchor_outpoint": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356:0",

"internal_key": "03d9f42daae1b7832d77d3ec83ddbb62e71266f6aedf6bcceb944e9672177c9301",

"merkle_root": "634ff6d86b8889f119f505a9bcba38fe4c6bda4b5a40a439fce37184badff63f",

"tapscript_sibling": null

},

"prev_witnesses": [

      ],

      "is_spent": false

    }

  ]

}

This output contains three important fields: asset_genesis, script_key, and chain_anchor

• asset_genesis: describes the creation information of the asset, such as the metadata hash value, input UTxO number, and asset ID
• script_key: similar to ScriptPubKey in P2TR transactions, the witness script that meets the conditions is required to spend this UTxO representing the asset (as mentioned in the previous article, UTxO*)
• chain_anchor: describes the transaction information of the asset anchored on the current chain, storing the transaction, transaction hash value, hash value of the block where the transaction is located, and the output UTxO of the asset transfer

Similarly, in the genesis transaction ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356, corresponding outputs are also generated, and the output ScriptPubKey needs to be unlocked by the script (using a private key or path) to be used in the next transaction. Moreover, the next transaction also needs to meet the requirements of the internal script_key when conducting Taro asset transfer.

One problem here is: how to ensure that this UTxO can be used to spend Taro assets normally? Perhaps the way to unlock the private key path can be removed (under P2TR, the UTxO can be unlocked by the private key or input script), so that users can only spend Taro assets through the script path. Due to limited information available, the solution to this problem is not reflected, perhaps this is also a problem that the Lightning Labs team is addressing, as they said on their Github page: the current code does not yet support running on the mainnet, which may cause users to lose Taro assets and UTxOs containing BTC.

In addition, there is no available information on the implementation details of the witness script. If a deeper understanding is needed, one can only refer to the source code, which requires more time. Therefore, a detailed explanation will not be provided here.

Asset Transfer

In Taro Asset, asset transfer requires both parties involved in the transfer to synchronize their universes. As mentioned in the previous article, Taro Universe stores the metadata of Taro assets and can be considered as a database that stores this series of transaction information. Transactions are only sent to Bitcoin when there is a need to prove that these transactions and minting actions have indeed occurred (this also seems to serve as a mechanism of restriction, such as the discussion on ensuring that UTxO is inevitably used as Taro asset spending in the previous section). Therefore, before the transaction, the parties involved need to synchronize information to ensure the validity of the transaction. Afterward, sending Taro assets to another address will generate a transfer information similar to a transaction:

{

  "transfer": {

"transfer_timestamp": "1684836471",

"anchor_tx_hash": "e4efa1c3272009193e961f383b29c1bc84cf6ed8eb0806bf94056a41387835b3",

"anchor_tx_height_hint": 2434958,

"anchor_tx_chain_fees": "12725",

"inputs": [

{

"anchor_point": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356:0",

"asset_id": "20cecdb6626705bf26ad036084f7423082db6114f0de84046ebf2e84f6852874",

"script_key": "02b4c71447e74672f8cd5b50a6b430fc73b3caff7866dc905a502fe8adefad3b31",

"amount": "100"

}

],

"outputs": [

{

"anchor": {

"outpoint": "b3357838416a0594bf0608ebd86ecf84bcc1293b381f963e19092027c3a1efe4:0",

"value": "1000",

"internal_key": "024a3cb06616bb1545d3a25417a3fa5ccc70c5fbe9ceed8666410ed83745bbe968",

"taproot_asset_root": "42ac8c2338032a0b0ea9b96916da31a8798eef30cbef2a80b8c6d60249e4698d",

"merkle_root": "42ac8c2338032a0b0ea9b96916da31a8798eef30cbef2a80b8c6d60249e4698d",

"tapscript_sibling": null,

"num_LianGuaissive_assets": 0

},

"script_key": "02258420ed4cf219965908102c6f8498da274c251a3463880763ba118c2d946c62",

"script_key_is_local": true,

"amount": "79",

"new_proof_blob": "00245663d6bf6a1...",

"split_commit_root_hash": "fdee0a27d560e5223b5e06b7a61d3df5b405942d21cf887fc96b16088874546a",

"output_type": "OUTPUT_TYPE_SPLIT_ROOT"

},

{

"anchor": {

"outpoint": "b3357838416a0594bf0608ebd86ecf84bcc1293b381f963e19092027c3a1efe4:1",

"value": "1000",

"internal_key": "033e42d7bdc3c5161c2dc440667b0f4fca4c4a7d32d13efac12a71994651b048ce",

"taproot_asset_root": "8aada842f74c2b11e9b5a0a716baa0c453855ab6ea316222a8a28e7e79506f41",

"merkle_root": "8aada842f74c2b11e9b5a0a716baa0c453855ab6ea316222a8a28e7e79506f41",

"tapscript_sibling": null,

"num_LianGuaissive_assets": 0

},

"script_key": "0225357fc148c441fbd5c5ea533fd6c33686697967a1cf8c493628788a535f433c",

"script_key_is_local": true,

"amount": "21",

"new_proof_blob": "00245663d6bf6a1de069c4562620f...",

"split_commit_root_hash": null,

"output_type": "OUTPUT_TYPE_SIMPLE"

}

The user who mints the asset uses the corresponding UTxO that anchors the asset as input and generates two outputs to two addresses. The information in the outputs facilitates the recipient to verify whether the received UTxO is valid, and also provides the recipient with the information needed to generate a valid witness script for the next transfer, ensuring that this UTxO can be spent normally. Combining the previous discussion on asset trees and Taro asset transfer, asset_id can be used to index the leaf node representing the asset in the asset tree, and the leaf node also stores the total amount of the asset, which is stored in Taro Universe and can be seen as an off-chain indexing program. Through script_key, the corresponding balance of the asset that can be spent can be queried in the corresponding MS-SMT of the asset. Wallets that meet the spending conditions can use these outputs as inputs for the next transaction.

The above “transfer” is a “split” process (100 -> ), so the output type to itself is OUTPUT_TYPE_SPLIT_ROOT. Similarly, there is a merge operation, which merges assets under different script_key that can be spent by a wallet into one.

These operations involving Taro assets are only reflected on the blockchain in the form of a LianGuaiy-To-Taproot (P2TR), and the main asset transfer process still occurs off-chain. From this perspective, Taro Asset can be seen as a second-layer network of Bitcoin.

Recent Progress

In the Taproot-Asset page, you can see the functionalities that have been implemented so far:

• Asset minting
• Synchronization of Taro Universe
• Sending/receiving assets
• Import/export asset proofs
• Create and manage CLI configuration files

From the latest version, v0.2.3, Lightning Labs team is still fixing legacy issues and improving the original program logic, such as adding block height to the minting proof of assets. However, it is mentioned on the program’s GitHub page that the code is not suitable for the mainnet and may result in the loss of Taro assets and BTC. Developers also mentioned in the official Slack discussion that Lightning Network does not yet support Taro assets.

The v0.2.0 version that meets the asset minting requirements was officially released in May this year. This version has implemented asset minting/transfer/receive functions. The remaining tasks may include refining transaction rules (as mentioned earlier) and fixing existing bugs. Therefore, Taro assets still have a long way to go and currently cannot meet the requirements for operation on the mainnet. I believe that in the next one or two years, there may be hope to witness the formal operation of Taro assets.

Expansion: Atomicals Protocol

Between the completion of the previous article in this series and the writing of this article, another competitor of Ordinals has emerged – Atomicals Protocol10, which is similar to Ordinals Inscription in terms of minting. Both require a commit transaction as input and write “envelope” in the witness script before performing reveal. The data format is also very similar:

OP_FALSEOP_IF 0x0461746F6D // Push "atom" 4 bytes // Followed by a single push to denote the operation type // LianGuaiyload (CBOR encoded) for the operationOP_ENDIF

ARC-20

ARC-20 is a homogeneous token based on the Atomicals Protocol, which has completely different minting and transfer rules from BRC-20.

Minting: Minting ARC-20 also requires pre-deployment of tokens, which is done by sending Atomicals formatted transactions. The deployment needs to specify the token’s name, minting height, associated image, minting quantity, and other information. After being indexed by the indexer, others can obtain the token’s information through the indexer and perform minting. ARC-20 also designed a minting method similar to mining. The deployer can specify the collision prefix of the commit tx and reveal tx. If these prefixes are set, the minters need to choose a nonce to change the hash of the commit tx and reveal tx to select a prefix that meets the conditions (there is currently no requirement for collision of reveal tx, but the source code has this functionality). After the user finds a nonce that meets the conditions, they will send the minted token name and the nonce that meets the conditions to the encoded atomic protocol transaction to complete the minting on the Bitcoin chain, while the balance information is indexed by the indexer.

Transfer: The transfer of ARC-20 is very similar to colored coins but much simpler. ARC-20 is bound to Satoshis, so if the UTxOs of these tokens are used as inputs, the i-th input will flow to the i-th output. If there are not enough outputs, i.e., the number of inputs is greater than the number of outputs, these tokens will flow to the first output.

Atomic Protocol

The advantage of this transfer method is that it avoids the need for minting a transfer inscription, as required by BRC-20, in order to conduct transactions. This makes the transaction of homogeneous tokens more convenient. If partial signature technology is used, token-to-BTC exchanges can be completed by integrating transactions, or even exchanges between different types of tokens. The disadvantage is that this implementation makes it too easy for users to lose tokens, especially when receiving multiple copies of the same kind of tokens. After consolidating UTxOs, these UTxOs representing tokens can be easily spent as gas, even during the process of minting other tokens.

In addition, the atomic protocol also includes the design of NFT and domain names (independent of NFT). There are also unfinished contracts and events in the document, so it is not possible to continue with a more in-depth introduction due to the lack of official documentation.

Protocol Comparison

In this case, it is necessary to compare Taro assets, Ordinals’ BRC-20 tokens, and the atomic protocol. They are similar in that the minting and transfer of tokens are tracked and recorded by off-chain programs, but the rules and manifestations of the records are different.

Comparison of Protocols

Conclusion

Finally, after introducing these technologies, let’s discuss the possibilities of Bitcoin implementation: in common Layer 2 network implementations, a separate blockchain network is usually built to execute transactions, and these executed proofs are then placed on the Layer 1 main chain, which is the basic principle of Rollup. Lightning Network, as a Layer 2 payment network for Bitcoin, also implements similar Rollup technology. After establishing a channel, the two parties engage in a series of interactions, and when confirming, they close the channel and provide proofs on the chain.

Taro assets are designed in a similar way to UTxO to complete the minting and transfer of assets. Perhaps the purpose is to be compatible with the Lightning Network, so that such exchange patterns can also be effective in the Lightning Network. Both parties only need to use patterns similar to the Lightning Network to exchange assets, and finally, when returning to Bitcoin, they submit proof transactions to prove that these assets have been realized in the Layer 2 network. If the implementation process of these assets is all done on Bitcoin, then it can be seen as proof that each transaction has been submitted on Bitcoin, ensuring that the off-chain asset proofs are valid. However, this implementation method is highly dependent on the off-chain Taro Universe index. If the metadata is lost, it is likely to result in the loss of user assets. These indexes are very decentralized. Perhaps they can be combined into a P2P network to form a distributed storage similar to IPFS. The advantage of this is that it facilitates the circulation of homogeneous token-like assets, but the disadvantage is that non-fungible token assets become meaningless (just as someone might ask, why not use ERC721 directly?).

On the other hand, BRC-20 violently records the minting and transfer data, and the indexer indexes the ledger information. Its drawbacks are obvious. Users need to engrave the transfer inscription before they can make transfers, and this is a condition that it has to satisfy relying on Ordinals. If BRC-20 does not rely on Ordinals and instead designs a system similar to Ordinals to implement, it may achieve better liquidity. However, this may prevent it from taking advantage of Ordinals’ popularity. Of course, the benefit of this is that the indexing method is simple and does not require storing too much additional metadata (compared to the metadata information stored by Taro assets), but it also limits its scalability. Ordinals, as an NFT, can demonstrate good functionality. Its data is stored on-chain and can be indexed (although miners can discard this witness data), showing a different approach from ERC-721. Ordinals itself cannot be considered a Layer 2 network, but after the existence of BRC-20, it shows the appearance of a Layer 2 network. However, the data changes are manifested on Bitcoin, not in this Layer 2 network (indexer). Its purpose is only to ensure accurate bookkeeping.

From this, it can be seen that both Taro assets and Ordinals have their own highlights, especially in the implementation of fungible tokens and non-fungible tokens. Taro considers the implementation of fungible tokens by using Taproot to compress transactions, allowing for the exchange of large amounts of assets in a single transaction, as well as using UTxO-like transaction methods to meet the compatibility of the Lightning Network. However, its implementation of NFTs is somewhat lackluster, compared to Ordinals’ on-chain data storage for distinguishing and highlighting the differences from ERC-721. Moreover, the interaction in Taro assets based on its implemented BRC-20 protocol appears cumbersome during user transactions, but users are not aware of this. Such opposition clearly demonstrates the differences between fungible tokens and non-fungible tokens, especially on a blockchain like Bitcoin that is based on UTxO, where the underlying design choices made by the protocol are particularly important.

References

1. Colored Coins – wikipedia

2. bitcoin 2.X (aka Colored Bitcoin) – initial specs

3. Colored Coins whiteLianGuaiper

4. NULL DATA – learn me a bitcoin

5. Coloring Scheme – Github

6. Overview – Ordinals Theory Handbook

7. The Rise of Ordinals, the Cambrian Explosion of the BTC Ecosystem

8. Bitcoin Stamps

9. Atomicals Protocol

10. Taproot Assets Protocol

11. Understanding Taproot Assets Protocol #2

We will continue to update Blocking; if you have any questions or suggestions, please contact us!