introduction
Inthe first article of the Ordinals vs Taro series, we briefly introduced the theoretical implementation of the minting and transfer operations of Taro assets in the Taro protocol. Here, we will review the implementation theories of Ordinals and Colored Coin for comparison, and further introduce Taro's implementation and existing progress to deeply explore the feasibility of Bitcoin's two-layer network implementation.
The article will be divided into the following four parts: the origin of Bitcoin’s homogeneous token Colored Coin, ordinal theory and Ordinals, Taro implementation and progress, and extended reading: Atomics Protocol.
Review: The Origin of All Things 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 coins should be the prototype of the currently common ERC-20 tokens. They were used to represent assets and conduct voting at the time, which is similar to the functions carried by ERC-20 today. On the former colored coin browser Coinprism, we can also see a series of assets issued by people in 2015. The picture is taken from the snapshot left by the web page in 2015: Coinprism Snapshoot - archive.org.
Coinprism Snapshoot
principle
Colored coins distinguish a group of Bitcoins from other Bitcoins through "coloring". There are two ways to implement colored coins: the EPOBC protocol proposed by ChromaWay and Open Assets (Open Assets) that uses OP_RETURN to store metadata. Here, we briefly introduce the implementation principle of open assets, which is also a method mentioned by Yoni et al. 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]. The initial limit was to store 40 bytes of data, which was later increased to 80 bytes. The Colored Coin White Paper (2013) used a 40-byte length encoding to implement coloring, while the 2016 Colored Coin Protocol Specification [5] used an 80-byte length specification. The 2016 colored coin protocol specification is relatively complex, which also involves the mini script language of colored coins, which will not be introduced here. The original idea of colored coins is to use OP_RETURN to store specific encoding information in the output script of a transaction, and then rely on the off-chain indexing program to identify the legitimacy of these transactions (as Ordinals will appear at the end of 2022).
Create assets
In the original colored coin white paper, the data encoding for creating the asset is as follows
Encoding format in the Colored Coin White Paper
The encoded data begins with 0x0043438000 ("CCP") to identify this as a colored coin genesis transaction, followed by two bytes indicating the current protocol version. The next two bytes are additional issuance instructions. All 0s indicate that the asset cannot be additionally issued, and all 1 indicate that the asset can be issued unlimitedly. The last 31 bytes are used to store information about dyeing. An asset creation transaction described in the white paper is as follows
The encoded data in the output OP_RETURN indicates that this transaction is the creation transaction of the asset. According to the encoding rules, the assets created by this transaction can be issued infinitely by the wallet with the address 17zt...sSrb (because the first input This address is the address (according to the protocol, it can be used as an additional issuance address), and the address before the OP_RETURN output can be identified as the address that receives the creation asset. The first three addresses will receive 9,900,000 of the asset, and the last address will receive 19,900,000 this asset. It can be seen from this that each satoshi dyed in the colored coins corresponds to a certain dyed asset.
Why is the amount of assets received reduced by 10,000? This is due to the default padding of 10,000 defined in the protocol, which allows 10,000 satoshis to be undyed to avoid dust transactions.
Asset transfer
The transfer of assets can be designed to be more complex, such as transferring multiple tokens of different dyes in one transaction. However, in order to facilitate the representation of the transfer process, it is assumed that a single dyed token is transferred. And the transfer involves the input sequence number (sequence, which is a field in the input of the Bitcoin transaction, usually you can see the nSequence field in the browser), and its binary representation represents which output the input will output the token to. middle. For example, 6 (110b) means outputting to the 1st and 2nd outputs, not the 0th or other outputs. A token transfer transaction is shown below, where the input and output address information is omitted. Dark colors in the figure indicate that the input or output is colored.
Color transfer transactions
Representing it as the transfer state of the colored coin, that is, removing the padding and converting the binary of the serial number into an easy-to-read form, the initial state can be obtained as follows. The output coloring mark is represented by the final state, which is marked directly here.
Colored coin transfer status indication
Starting from the 0th input, it traverses the sequence number to transfer the state. The transfer process is as shown in the figure below.
Transfer status changes
1. Transfer 5 colored assets from input 0 to output 1. At this time, the spaces in output 0 and 1 are both subtracted by 5. Since they are transferred to 1, and input 0 is a colored asset, the colored value of output 1 (colored value) plus 5;
2. Input 1 to transfer 10 dye assets to output 1. At this time, min(5, 10) = 5 is subtracted from output 1 and transferred to 1, and input 1 is a dye asset, so the cvalue is increased by 5;
3. Enter 1 to transfer 10 dye assets to output 2. At this time, min(5, 10) = 5 is subtracted from output 2 and transferred to 2. Input 1 is a dye asset, so the cvalue is increased by 5;
4. Input 2 transfers 20 dyed assets to input 1, and subtracts min(0, 20) = 0 from their spaces. However, input 2 is not dyed, so 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 Bitcoin's UTxO according to a series of rules. In the 2012 colored coin white paper, decentralized exchange technology was also mentioned to complete the exchange of colored coins in one transaction. It is a pity that the partially signed transaction technology (PSBTs - BIP0174) required by this technology was only incorporated into BIP in 2017. At that time, this required a centralized platform to identify and implement it through the order book (so, Is this still centralized?).
Dex in Colored Coin White Paper
Moreover, the v2 version of the colored coin protocol specification in 2016 further designed the bytecode, transfer address, and verification rules required for colored coins. It is a pity that this set of rules did not develop further due to the functional limitations of Bitcoin at the time, and the emergence of Ethereum in 2015 further made such a design useless, and colored coins ended here. development of. Some people also say that the reason for the failure of colored coins is that they are coupled with the native BTC, and in some cases they will be sent out as BTC and reduced. But the author believes that the reason for its failure is the inconvenience of circulation and the lack of application scenarios.
Ordinal Theory: Ordinals
Time comes to December 2022. Thanks to Segregated Witness and partial signature transaction technology in 2017, and the activation of Taproot upgrade in 2021, Casey Rodarmor invented the ordinal number theory [7]: ordinal number is a numbering scheme of Bitcoin. This makes it possible to track and transfer individual sats [6], which are numbered according to the order in which each bitcoin was mined and according to the first-in, first-out rule when transactions were made.
Ordinal number representation:
1. Integer symbol: 2099994106992659 This serial number is assigned according to the order of mining Satoshi.
2. Decimal notation: 3891094.16797, the first number is the block height of mining Satoshi, and the second number is the offset of Satoshi within the block.
3. Degree symbol: 3°111094′214″16797‴. For the specific principle of degree representation, see the Ordinal Number Theory Manual
4. Percent symbol: 99.99971949060254%. Expresses Satoshi's position in the Bitcoin supply as a percentage.
5. Name: satoshi. The sequence number is encoded using the characters a through z.
Inscription
The ordinal number theory is more about tracing the smallest unit of Bitcoin, sat. The rules it designs make each sat have its own unique number. Based on the ordinal theory, some unique data on the chain can be associated with these sats, which is called "engraved" inscriptions. Inscriptions are stored in taproot scripts, which have few restrictions on content and receive additional witness discounts, making the storage of inscriptions economical. The Taproot script format for Inscription is similar to:
It is stored in the input witness script of the Reveal transaction and is recognized and exposed by the off-chain index node (ord) when traversing the block.
Due to the limitation of indexing and the inability to operate on the chain, Inscription needs to implement other additional functions that can only be achieved by the opening of ord, such as the recent father and son inscription, and the curse inscription index a few months ago. The basic idea of inscription is very similar to Colored Coin. They store data in transactions and index it by off-chain programs. The difference is that inscription stores data in the input Taproot script, while Colored Coin encodes it. The data is stored in an output.
At this point, the Bitcoin ecosystem has developed, people can mint NFTs on the chain, and thanks to some transaction signature technologies, a trading market has emerged. The technology of inscription itself is very similar to that of colored coins. They both store data on the chain and are indexed by off-chain indexing tools. However, due to different times and different functions, colored coins were limited by the functional shortcomings of Bitcoin at the time and did not develop further. What enabled the development and explosion of Ordinals should be its lower inscription fee (compared to the early competing product bitcoin stamp [8]), and the market that emerged thanks to partial signature transaction technology, allowing people to easily trade inscriptions.
BRC-20
Later, the BRC-20 protocol based on inscriptions also appeared in March 2023. As mentioned in the previous article, such a homogeneous token implementation method has a violent aesthetics, and the token casting and transfer process is written on paper. , and the rest is left to the BRC-20 indexer, which is equivalent to adding an index on top of Bitcoin's index Inscription. Of course, in actual implementation, the BRC-20 indexer can directly ignore other NFT castings and only care about the casting and transfer of BRC-20.
BRC-20 now looks a bit like Bitcoin's second-layer network: the second-layer network processes a series of transactions, regularly communicates with the main chain, and submits transactions for bundling to ensure decentralization. In BRC-20, it is reflected as an indexer indexing the user's account balance to ensure whether certain BRC-20 inscriptions are valid (processing transactions), and the process of transfer and casting is implemented by the user himself (submitting transactions to the main chain).
Interestingly, in the photos released by Ordinals Summit not long ago, a PPT of brc20-swap shown by domo, the founder of BRC-20, mentioned these two concepts: Inscription-Based Virtual Machines and Rollup, which seems to It indicates that BRC-20 will also enter the second layer network in the future.
Taro implementation and progress
In the previous article, we introduced the principle of Taro assets being minted and transferred on the chain, but how is it implemented in practice? Compared with the introduction of the principles in the previous article, here we will introduce the current implementation and latest progress of Taro.
Taro specific implementation
Due to well-known reasons, the Lightning Network node used for testing locally cannot be added to the test network normally. This will be explained here through the testing process of Understanding Taproot Assets Protocol #2.
Asset casting
As mentioned in the previous article, the casting of assets requires selecting the input UTxO and recording the root node information of a new Merkle Sum-Merkle Tree (MS-SMT) in the asset tree.
After completing the casting of the asset, you can obtain the asset information:
asset_genesis: Describes the creation information of the asset, such as metadata hash value, input UTxO number, asset id
script_key: Similar to ScriptPubKey in P2TR transactions, a witness script that meets the conditions is required to spend the UTxO representing the asset (as mentioned in the previous article UTxO*)
chain_anchor: Describes the transaction information of the asset on the currently anchored chain. It stores the transaction, transaction hash value, the hash value of the block in which the transaction is located, and the output UTxO of the asset transfer.
Similarly, the corresponding output is also generated in the genesis transaction ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356 . A script that meets the output ScriptPubKey (via private key or path) is required to unlock this UTxO and use it for the next transaction. Furthermore, the next transaction needs to meet internal script_key requirements when used to transfer Taro assets.
Asset transfer
In Taro Asset, the transfer of assets requires both parties to the transfer to synchronize their universes. As mentioned in the previous article, Taro Universe stores the meta-information of Taro assets and can be regarded as a database that stores this series of transaction information. Transactions will only be sent to Bitcoin when it is necessary to prove that these transactions and minting behaviors have indeed occurred (this seems to also be used as a restriction mechanism, such as the discussion in the previous section to ensure that UTxO must be spent as a Taro asset) . Therefore, before a transaction, both parties to the transaction need to synchronize information to ensure the validity of the transaction. Afterwards, send the Taro asset to another address, which will generate a transfer message similar to the transaction:
A user who mints an asset takes as input the UTxO corresponding to the anchored asset, and produces two outputs to two addresses. The information in outputs is convenient for the recipient to verify whether the UTxO he received is legal. At the same time, the information in outputs also provides the recipient with the information needed to generate the next transfer, which is used to generate a legal witness script to ensure that this UTxO can be consumed normally. Combining the previous process of asset tree and Taro asset transfer, asset_id can be used to index into the leaf node representing the asset in the asset tree. The leaf node also stores the total amount of the asset, and this information is stored in Taro Universe and can be It is viewed as an off-chain indexing program. Through script_key, the balance of the corresponding spendable assets can be queried in the MS-SMT of the corresponding assets. Wallets that meet the spendability conditions can use these outputs as inputs for the next transaction to conduct transactions.
The above "transfer" is a "split" process (100 -> <79, 21>), so the output type to itself is OUTPUT_TYPE_SPLIT_ROOT. Similar to the merge operation, the different script_keys that a certain wallet can consume are merged. assets are combined into one.
These operations involved in Taro Asset are only reflected in the form of a Pay-To-Taproot (P2TR) on the blockchain. The main asset transfer process still occurs off-chain, so from this perspective, Taro Asset can be regarded as a bit A second-layer network of coins.
recent developments
In the Taproot-Asset page, you can see that the functions that have been implemented so far are:
1. Asset casting
2. Synchronization of Taro Universe
3. Send/receive assets
4. Import/export asset certificates
5. Create and manage CLI configuration files
Judging from the latest v0.2.3 version, the Lightning Labs team is still repairing the remaining issues of the Taro program and improving the original program logic, such as adding the block height to the minting proof of the asset. Under the Github page of the program, it is also written that the code is not suitable for the mainnet and may lead to the loss of Taro assets and BTC. Under the official discussion on Slack, the developer also mentioned that the Lightning Network does not yet support Taro assets.
The v0.2.0 version that meets the requirements of asset casting was only officially released in May this year. This version has already implemented the asset casting/transfer/reception functions. The rest may be to refine the transaction rules (as mentioned above), correct Bugs in the program. Therefore, Taro assets still have a long way to go. It currently cannot meet the requirements for running on the mainnet. The author believes that there may be hope to witness the official operation of Taro assets in the next one or two years.
Extension: Atomics Protocol
In the two weeks since the author completed the first part of this series and wrote this article, another competing product of Ordinals appeared - Atomics Protocol 10 (atomic protocol). It is very similar to the casting of Ordinals Inscription, both of which require a commit. The transaction is used as input, and the "envelope" is written in the witness script and then revealed, and the data format is particularly similar:
OP_FALSE
OP_IF
0x0461746F6D // Push "atom" 4 bytes
<Operation> // Followed by a single push to denote the operation type
<Payload> // Payload (CBOR encoded) for the operation
OP_ENDIF
ARC-20
ARC-20 is a fungible token based on the atomic protocol. It has completely different minting and transfer rules from BRC-20.
Minting : The minting of ARC-20 also requires pre-deployment of tokens. The method of deployment is to send transactions in Atomics format. Deployment requires specifying the name of the token, minting height, associated image, minting quantity and other information, which is indexed in the indexer. After arriving, others can get the token information through the indexer and mint it. ARC-20 also designed a casting method similar to mining. The deployer can specify the collision prefix of commit tx and the collision prefix of reveal tx. If these prefix information are set, the minter needs to select a nonce to change the commit during casting. tx and the hash of reveal tx to select a prefix that satisfies the condition (as of now there is no requirement for reveal tx collision, but the functionality is available in the source code). After the user finds a nonce that meets the conditions, the minted token name and the nonce that meet the conditions will be sent to the encoded atomic protocol transaction to the Bitcoin chain to complete the minting, and the balance information will be indexed by the indexer.
Transfer : The transfer of ARC-20 is very similar to colored coins, but much simpler. ARC-20 is bound to Satoshi. If the UTxO of these tokens is used as input, then the i-th input will flow to the i-th Output, if there are not enough outputs, that is, if 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 process like BRC-20 that requires the transfer inscription to be minted before trading, making the transaction of homogeneous tokens more convenient. If partial signature technology is used, it can be done by integrating transactions. Complete the exchange of tokens and BTC within a single transaction, or even the exchange of multiple different tokens. The disadvantage is that such an implementation makes it too easy for users to lose tokens. Especially when users receive multiple copies of the same tokens and integrate UTxO, these UTxOs representing tokens can easily be spent as gas, or even Spend it in the process of minting other tokens.
In addition, the Atomic Agreement also includes the design of NFT and domain names (independent of NFT). There are also unfinished contracts and events in the document. Due to the lack of official documents, it cannot be introduced in depth.
Protocol comparison
Here we need 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 recorded rules are different from those on the chain. The manifestations are different.
Comparison of protocols
Conclusion
Finally, after introducing these technologies, let’s discuss the possibility of Bitcoin implementation: In common two-layer network implementations, an additional blockchain network is usually built to execute transactions, and then these executed proofs are placed in Layer 1. In the main chain, this is also the basic principle of Rollup, and proofs are submitted to the main chain regularly. As a second-layer payment network of Bitcoin, the Lightning Network is implemented similarly to Rollup technology. After establishing a channel, the two parties conduct a series of interactions, close the channel upon final confirmation, and then provide proof to the chain.
Taro assets are designed in a way similar to UTxO to complete the casting and transfer of assets. The purpose may be to be compatible with the Lightning Network, so that such an exchange model can also take effect in the Lightning Network. Both parties only need to use a model similar to the Lightning Network to exchange assets, and finally need to submit a certification transaction when returning to Bitcoin to prove that these assets have been implemented in the second-layer network. If the implementation process of these assets is implemented on Bitcoin, then it can be seen that each transaction is certified on Bitcoin, ensuring that the asset certification off the chain is valid. However, this implementation relies heavily on the off-chain Taro Universe index. If metadata is lost, it is likely to cause the loss of user assets. These indexes are very dispersed. Perhaps these universes can be formed 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 assets for users. The disadvantage is that non-fungible token assets are meaningless (as some people may ask, why not use ERC721 directly?).
BRC-20 violently records minting and transfer data, and the indexer indexes ledger information. Its shortcomings are obvious. Users need to engrave a transfer inscription before they can make a transfer. This is a condition that it has to meet because it relies on Ordinals implementation. If BRC-20 does not rely on the implementation of Ordinals but designs a design similar to Ordinals, it may be able to meet better liquidity, but it may not be able to take advantage of the popularity of Ordinals and become popular. Of course, the advantage of this is that the indexing method is very simple and there is no need to store too much additional metadata (compared to the metadata information stored in Taro assets), which also limits its scalability. The function of Ordinals as NFT is very good. Its data is stored on the chain and can be indexed (although miners can discard this part of witness data), which shows a different approach from ERC-721. Ordinals itself cannot be regarded as a second-layer network, but after the introduction of BRC-20, it behaves like a second-layer network, but data changes are reflected in Bitcoin, not in this second-layer network (indexer) , it itself is only to ensure the accuracy of accounting.
It can be seen that Taro assets and Ordinals have their own highlights, especially under the implementation of homogeneous tokens and non-fungible tokens. Taro has considered a lot about the implementation of homogeneous tokens and considered Taproot to Compressed transactions allow a large amount of assets to be exchanged in one transaction, and UTxO-like transaction methods are used to meet the compatibility of the Lightning Network. However, its implementation of NFT is particularly tasteless. Compared with Ordinals inscription, the on-chain data storage is different from ERC-721 and becomes a highlight. The BRC-20 implemented based on it is cumbersome in the user transaction process, and the interaction in Taro assets will not allow users to perceive all this. From this confrontation, it is obvious that the difference between fungible tokens and non-fungible tokens can be felt. Especially on a UTxO-based blockchain like Bitcoin, the underlying design method adopted by the protocol is particularly important.
Data citation
