Preface

Issuing assets based on BTC has always been a hot topic. From Colored Coins, which first appeared in 2011, to the recently popular Ordinal protocol, BTC Community其实总能涌现出新的玩家和共识，但是能留下的寥寥无几。但随着野心勃勃的 Lightling Labs 宣布自己在 Taproot Assets 至上构建 Stable Coin 的计划，Tether 也宣布将选择 RGB 进行 USDT 在比特币一层的铸造。

This means that the once famous OmniLayer (Mastercoin) is no longer the largest player in the BTC ecosystem. Client Verification (CSV) asset protocols have begun to enter everyone's field of vision. The difference from traditional BTC asset protocols is that they also have the attribute of expanding BTC. However, in the face of so many asset protocols in the BTC ecosystem, people can't help but ask, what are the differences between them? In the face of so many asset protocols, how can we choose and find our own opportunities. This article hopes to take everyone to review the asset protocols that have appeared in the history of BTC and explore the future development of BTC asset protocols.

Colored Coins

The idea of Colored Coins was first proposed by Yoni Assia, now CEO of eToro, in a paper titledbitcoin 2.X (aka Colored bitcoin)The article proposes that Bitcoin is perfect as the underlying technology, just like HTTP is the foundation of the Internet. Therefore, Colored Coins was designed based on the reuse of BTC.Tokenprotocol.

Yoni Assia hopes to create a BTC2.0 economy in this form - anyCommunityMultiple currencies can be created in this way. Using Bitcoin as the underlying technology to settle transactions and avoid double payments was undoubtedly a very bold idea at the time.

Colored Coins is a protocol for issuing assets based on Bitcoin. The approach is to "color" a certain number of Bitcoins to represent these assets. These marked Bitcoins are still Bitcoins in function, but they also represent another asset or value. But how can such an idea be implemented on Bitcoin?

On July 3, 2014, ChromaWay developed the Enhanced Fill Order-Based Coloring Protocol (EPOBC), which simplified the process for developers to create colored coins. This is the earliest use of Bitcoin Script.OP_RETURNFunctional protocol.

The final effect is shown in the figure below:

This implementation is very concise, but it also brings many problems:

1. HomogenizationTokenWith minimum binding value

在创世交易中为某个染色币绑定了1000 sat，则该染色币的最小分裂单位为1 sat。这意味着该资产或代币可以被切分或分配为最多1000份（但是仅为理论上的，为了防止粉尘攻击，比如当年的sat都定在546 SAT，后面到ordinal则是更高）。

2. Verification issues

In order to determine the authenticity and ownership of colored coins, it is necessary to trace and verify from the genesis transaction of the asset to the current UTXO. Therefore, a special developmentwalletWith matching full nodes and even browsers.

3. Potential risk of miner censorship

Because the characteristics of ColoredTransaction are more obvious, that is, metadata information is written in the output, which makes it possible for miners to review it.

Colored coins are actually an asset tracking system that uses Bitcoin's verification rules to track asset transfers. However, in order to prove that any specific output (txout) represents a specific asset, a whole chain of transfers from the origin of the asset to the present is required. This means that verifying the legitimacy of a transaction may require a long chain of proofs. In order to solve this problem, someone originally proposedOP_CHECKCOLORVERIFY来帮助在BTC上直接对Colored Coins的交易正确性进行验证，但是该提案也并没有通过。

The first ICO in the crypto industry: Mastercoin

The original concept of Mastercoin was proposed by JR Willett. In 2012, he released a paper called “The Second Bitcoin Whitepaper"The white paper describes the currentBlockchainThe concept of creating new assets or tokens on top of the blockchain was later called "MasterCoin". Later it was renamed Omni Layer.

The Mastercoin project conducted an initial token sale (today we call it an ICO or initial token sale) in 2013 and successfully raised millions of dollars, which is considered the first ICO in history. The most famous application of Mastercoin is Tether (USDT), the most well-known fiat stablecoin, which was originally issued on the Omni Layer.

In fact, the idea of Mastercoin appeared earlier than Colored Coins. The reason why it is mentioned second here is that compared with Colored Coins, MasterCoin is a relatively heavier solution. MasterCoin has established a complete node layer, thus providing more complex functions (such as smartcontract), Colored Coins is simpler and more direct, focusing primarily on “dying” or marking Bitcoin UTXOs to represent other assets.

The biggest difference from Colored Coins is that Mastercoin only publishes various types of transaction behaviors on the chain, but does not record related asset information. In the Mastercoin node, a state model database is maintained in the node off the chain by scanning the Bitcoin block.

Compared with Colored Coins, the logic it can accomplish is more complex. And because the status is not recorded and verified on the chain, there is no requirement for continuity (continuous dyeing) between transactions.

However, in order to implement the complex logic of Mastercoin, users need to trust the status of the off-chain database in the node, or allow the Omni Layer node to verify it themselves.

Summarize:

The biggest difference between Mastercoin and Colored Coins is that Mastercoin does not choose to maintain all the data required for the protocol on the chain, but instead parasitizes the BTC consensus system to achieve its own transaction publishing and sorting, and then maintains the status in the off-chain database.

According to information provided by OmniBolt: Omni Layer is proposing a new UBA (UTXO Based Asset) asset protocol to Tether, and will use Taproot to upgrade and compile asset information into tapeleaf, so as to achieve functions such as conditional payment. At the same time, OmniBolt is introducing Stark into OmniLayer's lightning network facilities.

Client Side Validation Idea

If we want to understand the concept of client verification, we have to go back to the second year after Colored Coins and Mastercoin appeared, which was 2013. Peter Todd published an article in this year:Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and ValidationAlthough the title of the article seems to have nothing to do with client-side validation, a careful reading will reveal that this is the earliest enlightenment idea about client-side validation.

Peter Todd was an early researcher in Bitcoin and cryptography who was looking for a way to make the way Bitcoin works more efficient. He developed a more sophisticated client verification concept based on the concept of timestamps. In addition, he proposed the “single use seal", which will be mentioned later.

Now let's follow Peter Todd's thoughts and first understand what kind of problems BTC actually solves. In Peter Todd's view, BTC solves three problems in total:

1. Proof-of-publication

   The essence of publishing proofs is to solve the double-spending problem. For example, Alice wants to transfer some bitcoins to Bob. Although she has signed a transaction to transfer the bitcoins to Bob, Bob does not necessarily know that such a transaction exists. Therefore, we need a public place to publish transactions, and everyone can query the transactions from it.

2. Order consensus

   In computer systems, there is no physical time as we usually feel. In distributed systems, this time is usually a distributed clock Lamport, which does not provide a measure for our physical time, but rather sequences our transactions.

3. Transaction Validation (Optional)

   The verification on BTC is about the verification of signatures and BTC transfer amounts. However, Peter Todd believes that this verification is not necessary for building a token system on top of BTC, but is just an optimization option.

When you see this, you will think of the Ominilayer mentioned earlier. OminiLayer itself does not hand over the calculation and verification of the state to BTC, but it also reuses BTC.SafetyColored Coins leaves the tracking of the status to BTC. The existence of these two has proved that verification does not necessarily have to happen on the chain.

So how does client-side verification effectively verify transactions?

First, let's take a look at what needs to be verified:

1. Status (transaction logic verification)

2. Is the input TxIn valid (to prevent double spending)

It is easy to find that for assets released on BTC, each transaction needs to verify the entire history of related transactions to ensure that the referenced input has not been consumed and the status is correct. This is very unreasonable, so how can it be improved?

Peter Todd believes that we can simplify this process by changing the focus of verification. Instead of confirming that an output has not been double-spent, this approach focuses on confirming that the input of the transaction has been published and does not conflict with other inputs. By sorting the inputs in each block and using Merkle trees, this verification can be done more efficiently because each verification only requires a small portion of data, rather than the entire on-chain history of that input.

The commitment tree structure proposed by Peter Todd is as follows:

CTxIn -> CTxOut -> -> CTransaction -> -> CT= xIn

But how do we store such a commitment tree on the chain? So here we can introduce the concept of single use seal.

Single Use Seal

The Single Use Seal is one of the core concepts in understanding client-side authentication, which is similar to the real-world seal used to protect goods.Xiaobai NavigationA single use seal is similar to a physical, single-use seal on a shipping container. A single use seal is a unique object that can be closed exactly once on a message. In short, a one-time seal is an abstract mechanism for preventing double spending.

For SealProtocol, there are three elements and two actions.

Basic elements:

• l： seal, that is, seal

• m： message, message

• w：witness

Basic Operation: There are two basic operations:

• Close(l,m) → w: Closes seal l on message m, producing a witness w.

• Verify(l,w,m) → bool : Verifies that seal l was closed on message m.

The implementation of single use seal isSafetySexuallyIt is impossible for an attacker to find two different messages m1 and m2 and make the Verify function return true for the same sealof.

First of all, Single-Use Seal is a concept that ensures that a certain asset or data is only used or locked once. In the context of Bitcoin, this usually means that a UTXO (unused transaction output) can only be consumed once. Therefore, the output of a Bitcoin transaction can be regarded as a one-time seal, and when this output is used as an input for another transaction, the seal is "broken" or "used".

For CSV assets on BTC, Bitcoin itself acts as a single-seal "witness". This is because, in order to verify a Bitcoin transaction, a node must check whether each input of the transaction references a valid and unspent UTXO. If a transaction attempts to double-spend a UTXO that has already been used, then Bitcoin's consensus rules and honest nodes across the network will reject the transaction.

Can it be simpler?

single use sealJust put any oneBlockchainAs a database, we store the promise of a message in this database in some way and maintain a consumed or to-be-consumed state for it.

Yes, it's that simple.

In summary, client-verified assets have the following characteristics:

1. Off-chain data storage：The transaction history, ownership, and other relevant data of the assets verified by the client are mostly stored off-chain. This greatly reduces the data storage requirements on the chain and helps improve privacy.

2. Commitment Mechanism：Although asset data is stored off-chain, changes or transfers to this data are recorded on-chain through commitments. These commitments enable transactions on the chain to reference off-chain states, thereby ensuring the integrity and immutability of off-chain data.

3. On-chain witnesses (not necessarily BTC)：While most of the data and verification is off-chain, through commitments embedded on-chain, assets verified by clients can still take advantage of the underlying chainSafetyThe nature of the protocol (publication of proofs, ordering of transactions).

4. Verification is done on the client side：Most of the verification work is done on the user's device. This means that it is not necessary for all nodes in the network to participate in verifying each transaction, only the participants involved need to verify the validity of the transaction.

For those who use the client to verify assets, there is one more thing to note:

When conducting off-chain transactions and verifying client-verified assets, it is necessary not only to present the private key holding the asset, but also to present proof of the complete Merkel path of the corresponding asset.

The pioneer of client-side validation (CSV): RGB

The concept of RGB was proposed by Giacomo Zucco, a well-known figure in the community, after 2015. Due to the rise of Ethereum and the proliferation of ICOs, and before ICOs, many people tried to do something outside of Bitcoin, such as Mastercoin and Colored Coins projects.

Giacomo Zucco was disappointed. He thought that these projects were not as good as Bitcoin, and he thought that the previous ways of implementing tokens on Bitcoin were inappropriate. In the process, he met Peter Todd and became fascinated by Peter Todd's ideas on client-side validation. He began to proposeRGBidea.

The biggest difference between RGB and previous asset protocols is that in addition to the previously mentioned features of client-side asset verification, it also adds an execution VM to perform Turing-completecontract执行引擎。此外为了保证contract数据的SafetyIn addition to the features, Schema and Interface are also designed. Schema is similar to Ethereum, declaring the content and functions of the contract, while Interface is responsible for the implementation of specific functions, just like the interface in programming languages.

The schema of these contracts is responsible for limiting expected behavior when the VM is executed. For example, RGB20 and RGB21 are responsible for some restrictions on transactions of homogeneous tokens and non-homogeneous tokens respectively.

RGB's commitment mechanism PerdersenHash

From the perspective of commitment mechanism, RGB uses Pedersen hash. Its advantage is that it can commit to a value without disclosing it. Using Pedersen hash to build a Merkle tree means that you can create a privacy-preserving Merkle tree that can hide the value in it. This structure can be used in certain privacy-preserving protocols, such as some anonymouscryptocurrencyHowever, it may not be applicable to CSV assets, which will be mentioned later in the comparison with Taproot Assets.

RGB's virtual machine design Simplicity → AluVM

RGB's goal is not only to implement a client-verified asset protocol, but also to expand to Turing-complete virtual machine execution and contract programming. In the early design of RGB, it claimed to use a programming language called Simplicity, which is characterized by generating an execution proof when executing an expression, and making it easier to formally verify the contracts it writes (to avoid bugs). However, the development of the language was not ideal and finally got into trouble. This ultimately led directly to the failure of the entire RGB protocol that year. In the end, RGB began to use a VM called AluVM, developed by Maxim, with the goal of avoiding any undefined behavior, which is similar to the original Simplicity. The new AluVM is said to use a programming language called Contractum in the future to replace the currently used Rust.

RGB layer2 expansion direction: Lightning Network or side chain?

客户端验证资产没有办法在链下保证Safety的情况下连续交易的。因为客户端验证的资产还是依赖L1去进行交易发布和定序，所以在没有L2When implementing the expansion plan, the transaction speed will still be limited by the block speed of its L1 witness. This means that if RGB transactions are conducted directly on Bitcoin, under strict security requirements, the maximum interval between two related transactions must be ten minutes (BTC block time). There is no doubt that such a transaction speed is unacceptable most of the time.

RGB and Lightning Network

The principle of the Lightning Network is that the two parties to the transaction will sign a bunch of contracts (commitment transactions) off-chain to ensure that if either party violates the contract, the aggrieved party can submit the contract (commitment transaction) to BTC for settlement, retrieve its own funds and punish the other party. In other words, the Lightning Network ensures the security of off-chain transactions through the design of protocols and games.

RGB can build its own lightning network facilities by designing the contract details of the payment channel suitable for RGB itself, but the lightning network is extremely complex and it is not easy to build this set of facilities. However, compared with Lightnling labs' many years of cultivation in this field, LND has a market share of more than 90%.

RGB Sidechain Prime

LNP-BPAs the maintainer of the current RGB protocol, Maxim published a proposal in June 2023 calledPrime**'s client-verified asset expansion plan, in which it criticized the existing side chain and lightning network expansion plans for being too complicated in development.MaximHe said that he believes that other expansion methods besides Prime include NUCLEUS multi-node lightning channels and Ark/Enigma channel factories, both of which require more than two years of development. However, Prime only takes one year to complete.

Prime is not a traditionalBlockchainThe design is a modular proof issuance layer designed for client verification, which consists of four parts:

1. Timestamp service
   A transaction sequence can be finalized in as fast as 10 seconds.

2. prove
   It is produced and released together with the block header in the form of PMT storage.

3. One-time seal
   An abstract one-time sealing protocol is sufficient to prevent double spending. If implemented on Bitcoin, it can be bound to UTXO, similar to the current RGB design.

4. Smart Contract Protocol
   Shard Contract-RGB (replaceable)

From this, we can see that in order to solve the problem of RGB transaction confirmation time, Prime uses a timestamp service to quickly confirm transactions off-chain and load transactions and IDs into blocks. At the same time, the transaction proof on Prime can be further merged through PMT and then anchored to BTC in a similar way to checkpoint.

Taproot-based CSV asset protocol: Taproot Assets

Taproot Assets is a CSV asset protocol based on Taproot forBlockchainClient-verified assets are issued on the Lightning Network, which can be traded instantly, at high volumes, and at low costs through the Lightning Network. The core of Taproot Assets is to leverage the security and stability of the Bitcoin network and the speed, scalability, and low costs of the Lightning Network. The protocol was designed and developed by roasbeef, CTO of Lightnling labs. Roasbeef may be the only person on the planet who has personally led the development of Bitcoin clients (BTCD) and Lightning Network clients (LND), and has a deep understanding of BTC.

Taproot transactions only carry the root hash of the asset script, making it difficult for external observers to identify whether Taproot Assets are involved, because the hash itself is universal and can represent any data. With the Taproot upgrade, Bitcoin gained the ability of smart contracts (TapScript). On this basis, the asset encoding of Taproot Assets is equivalent to creating a token definition similar to ERC20 or ERC721. In this way, Bitcoin not only has the function of asset definition, but also has the ability to write smart contracts, thus laying the foundation for the prototype of the token smart contract infrastructure for Bitcoin.

The Taproot Assets encoding structure is as follows:

Image from Lightning Labs CTO roasbeef

As a CSV asset protocol, Taproot Assets is more concise in design than RGB. And it makes the most of the progress of the current BTC ecosystem, such as Taproot upgrades, PSBT, etc. The biggest difference between Taproot Assets and RGB in terms of application scalability is the execution VM. Taproot Assets uses the same TaprootScriptVM as the native default of BTC. In recent years, many infrastructure studies on BTC have been conducted based on TapScript, but due to the slow upgrade of BTC, it cannot be applied in a short time. It is foreseeable that Taproot Assets will be a test field for these new ideas in the future.

What is the difference between Taproot Assets and RGB?

1. Transaction verification and light node friendliness

Taproot Assets has high verification efficiency and security due to the implementation of sum tree (status can be verified and transactions can be conducted only by holding proof, without traversing all transaction history of input). The Pedersen commitment used by RGB makes it impossible to effectively verify the validity of the input, which requires RGB to trace back the transaction history of the input. The transaction derivation will be a very heavy burden in the later stage. The design of Merkel sum also allows Taproot Assets to easily implement light node verification, which does not exist in previous asset protocols on BTC.

2. Execute VM

Taproot Assets was born in response to the Taproot upgrade. The TaprootScriptVM it uses is the script execution engine that comes with Bitcoin after the Taproot upgrade, and the vPSBT it uses is a replica of BTC's PSBT. This means that once the lightning channel mechanism of Taproot Assets is developed, all current LND infrastructure and previous Lightning labs products can be reused immediately (LND currently has a share of more than 90% in the lightning network). In addition, the recent popular BitVM proposals are all based on TaprootScript. In theory, all these improvements can eventually help Taproot Assets.

However, for RGB, its VM and verification rules (SCHEMA) are self-contained, and to some extent, it is a relatively closed ecosystem. The construction based on RGB can only operate in its own ecosystem, and its relationship with the Bitcoin ecosystem is not as close as everyone imagines. Taking the follow-up of Taproot upgrade as an example, the only relationship between RGB and Taproot upgrade is to encode the on-chain commitment data into the Witness's TapLeaf.

3. Smart Contracts

In the current implementation design of RGB, contracts and VM are a part that has been highlighted. However, in Taproot Assets, there is no sign of smart contracts for the time being. However, it has not yet been explained how the current modification of RGB in the Global State will be synchronized with each independent contract shard (UTXO). Moreover, Pedersen promised that it can only guarantee the total number of assets, and there seems to be no more explanation for how to ensure that tampering of other states is identified. As for Taproot Assets, although the design is simple, the current storage of states only includes asset balances, and there are no more states, so smart contracts cannot be discussed for the time being. However, according to Lightning Labs, Taproot Assets will focus on smart contract design next year.

4. Sync Center

From the basic principles of assets verified on the client mentioned earlier, we can understand that holding Proof is as important as holding a private key, but Proof is always on the user's client and may be easy to lose, so what should we do? In Taproot Assets, we can avoid such problems through universe. Universe is a publicly auditable (MS-SMT) covering one or more assets. Unlike ordinary Taproot asset trees, Universe is not used to host Taproot assets. Instead, Universe promises a subset of one or more asset histories.

Storm is responsible for this part in RGB, which will synchronize and store the proof data off the chain through p2p. However, due to the history of RGB's development team, the proof formats of these teams are currently incompatible. RGB's ecological team DIBA currently stated that it will developcarbonadoto solve this problem, but the progress is unclear.

5. Engineering Implementation

All the libs used by Taproot Assets are time-tested, because Lightning labs has its own Bitcoin client (BTCD), Lightning Network client (LND), and a large number ofwallet libOn the other hand, most of the libs used for RGB implementation are self-defined, and from the perspective of industrial standards, the implementation of RGB is still in the laboratory stage.

A brief discussion on the future of BTC expansion

At this point in the discussion, everyone has discovered that the asset protocol verified by the client has gone beyond the scope of the protocol and has begun to move towards computing expansion.

Many people say that Bitcoin will exist as digital gold in the future, while other chains will build the application ecosystem. But I have a different view on this. Just like many discussions on the BTC forum are about various alt-coins and their short lives. The rapid demise of these alt-coins has turned the capital and efforts that once surrounded them into bubbles. We already have a strong consensus foundation like Bitcoin, so there is no need to build a new L1 for application protocols. What we need to do is to make good use of Bitcoin, the strongest infrastructure, to build a more long-term decentralized world.

Less on-chain computation, more on-chain verification

From the perspective of application design, Bitcoin has long chosen a design philosophy that is verification-based rather than on-chain computing.Turing completeness and state for smart contracts).BlockchainIt is essentially a replicated state machine. If the consensus of a chain is calculated on the chain, then it is difficult to say whether it is a reasonable and scalable approach to let all nodes in the network repeat these calculations. If verification is the main focus, then verifying the validity of off-chain transactions may be the most suitable solution for BTC expansion.

Where does validation happen? It's important

For protocol developers on top of Bitcoin, how to use Bitcoin for key verification, or even put verification off-chain, and how to design security solutions are actually the work of protocol designers themselves, and do not need to be related to the chain itself. So how to implement verification will lead to different expansion plans for BTC.

From the perspective of verification implementation, we have three directions for expansion:

1. Verification happens on-chain (OP-ZKP)

   If OP-ZKP is implemented directly in TaprootScriptVM, it is equivalent to adding ZKP verification capabilities to BTC itself, and then combined with some Covenant settlement protocols, a Zk-Rollup expansion solution that can inherit the security of BTC can be created. However, unlike deploying a verification contract on Ethereum, BTC upgrades are slow in themselves, and adding such non-universal op-codes that may require subsequent upgrades is destined to be difficult.

2. Verification happens on half-chain (BitVM)

   The design of BitVM is destined not to serve ordinary transaction logic. Robin Linus also stated that the future of BitVM is to create a free cross-chain market for various SideChains. The reason why BitVM's solution takes place on the semi-chain is that most of the time these verification calculations do not occur on the chain, but off the chain. However, the important reason for designing around BTC's Taproot is to be able to use TapScriptVM for calculation verification when necessary, so as to theoretically inherit BTC's security. In this process, a verification trust chain is also generated. For example, as long as one of the n validators is honest, that is,Optimistic Rollups.

   BitVM has huge on-chain overhead, but can ZK fraud proofs be used to improve efficiency? The answer is no, because the implementation of ZK fraud proofs is based on the verification of ZKP on the chain, which brings us back to the dilemma of the OP-ZKP solution.

3. Validation happens off-chain (Client-Side-Validation, Lightning Network)

   Verification happens completely off-chain, which is what we have discussed before, such as the CSV asset protocol and the Lightning Network. In the previous discussion, we can see that in the design of CSV, we have no way to completely prevent collusion and tampering. What we can do is to use cryptography and protocol design to keep the scope of this malicious collusion damage within a controllable range, making this behavior unprofitable.

   The advantages and disadvantages of off-chain verification are also very obvious. The advantage is that it takes up very little resources on the chain and has great potential for expansion. The disadvantage is that it is almost impossible to fully reuse the security of BTC, which greatly limits the types and methods of off-chain transactions that can be carried out. In addition, off-chain verification also means that the data is off-chain and kept by the user, which puts higher requirements on the security of the software execution environment and the stability of the software.

Trends in expansion and evolution

At present, the popular Layer2 in Ethereum verifies the validity of Layer2 calculations through Layer1, that is, the state calculation is pushed down to Layer2, but the verification is still retained on Layer1. In the future, we can also push the verification calculation down to the chain, further unleashing the performance of the current blockchain infrastructure.

The article comes from the Internet:Off-chain transfers: The evolution of the Bitcoin Asset Protocol

Related recommendation: BTC surges, what are the reasons driving the rise?

This article will analyze the reasons for the recent BTC rally and the subsequent trend.DAO Bitcoin prices have reached a 17-month high, the highest level since May 2022. This rally caught many people off guard, and with this "cryptocurrencyThe steady rise of the "King of Bitcoin" has brought a bullish atmosphere to the crypto market. That…