Original Title: "Off-chain Transfer: The Evolution of Bitcoin Asset Protocols"

Original Source: Ben77, Starknet & Taproot Assets contributor

I am a practitioner in the encryption industry. Please translate the following Chinese text into English without considering the context or industry-specific terms and names. Do not omit any English words or phrases, including capitalized ones such as ZKS, STARK, and SCROLL. If there are English characters in an tag, do not translate them and return the tag as is. If the content consists only of punctuation marks, return them as is. Do not translate HTML tags such as

, , , and

. If an HTML tag contains English characters, omit the translation and return the tag as is. Please preserve the content within tags. Do not translate any Chinese characters. The text to be translated is:

Foreword

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, the BTC community always manages to produce new players and consensus, but few can stay. However, with the ambitious announcement from Lightning Labs to build a stablecoin on Taproot Assets, and Tether's announcement to choose RGB for the issuance of USDT on the Bitcoin layer, the landscape may be changing.

This means that the once-famous OmniLayer (Mastercoin) is no longer the biggest player in the BTC ecosystem. The Client-Side Validation (CSV) asset protocol has entered everyone's field of vision, and the difference from traditional BTC asset protocols is that they also have properties for BTC expansion. However, faced with such a wide variety of asset protocols in the BTC ecosystem, people can't help but ask, what are their differences, and how can we choose and find our own opportunities among so many asset protocols? This article hopes to take everyone through a review of the asset protocols that have appeared in BTC's history, and also explore the future development of BTC asset protocols.

Colored Coins

The idea of Colored Coins was first proposed by Yoni Assia, now the CEO of eToro, in an article titled "bitcoin 2.X (aka Colored bitcoin)" on March 27, 2012. The article argued that Bitcoin was a perfect underlying technology, much like HTTP is to the internet. Therefore, the Colored Coins token protocol was designed based on the reuse of BTC.

Yoni Assia hopes to create BTC2.0's economy through this form - any community can create multiple currencies in this way. This way of using Bitcoin as underlying technology for clearing transactions and avoiding double payments was undoubtedly a very bold idea at the time.

Colored Coins is a protocol based on Bitcoin for issuing assets. The approach is to "color" a certain amount of Bitcoin to represent these assets. The tagged Bitcoin still functions as Bitcoin, but it also represents another asset or value. But how can this idea be implemented on Bitcoin?

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

The final implementation effect is shown in the following figure:

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

1. Homogeneous tokens and minimum binding values.

If 1000 satoshis are bound to a certain colored coin in the genesis transaction, then the minimum divisible unit of that colored coin is 1 satoshi. This means that the asset or token can be split or distributed into up to 1000 parts (although this is only theoretical, as to prevent dust attacks, for example, satoshis were set at 546 SAT in the past, and later increased to ordinal).

2. Verification Question

To verify the authenticity and ownership of the colored coins, it is necessary to trace the asset's genesis transaction to the current UTXO. Therefore, a dedicated wallet and matching full node, or even a browser, need to be developed.

3. Potential miner review risks.

Because the characteristics of ColoredTransaction are more obvious, that is, metadata information is written in the output, which brings the possibility of review by miners.

Colored coins are actually an asset tracking system that uses Bitcoin's validation rules to track asset transfers. However, to prove that any specific output (txout) represents a particular asset, a complete transfer chain from the asset's origin to the present must be provided. This means that verifying the legitimacy of a transaction may require a long proof chain. To address this issue, someone proposed OP_CHECKCOLORVERIFY to help verify the correctness of Colored Coins transactions directly on BTC, but the proposal did not pass.

The first ICO in the cryptocurrency industry: Mastercoin

The initial concept of Mastercoin was proposed by J.R. Willett. In 2012, he published a whitepaper called "The Second Bitcoin Whitepaper", which described the concept of creating new assets or tokens on the existing blockchain of Bitcoin, which later became known as "MasterCoin". Later on, it was renamed as Omni Layer.

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

Actually, the idea of Mastercoin appeared earlier than Colored Coins. However, I am discussing it secondly here because compared to Colored Coins, MasterCoin is a relatively heavier solution. MasterCoin has established a complete node layer, providing more complex functions such as smart contracts. On the other hand, Colored Coins is simpler and more direct, mainly focusing on "coloring" or marking Bitcoin UTXO to represent other assets.

The biggest difference between Mastercoin and Colored Coins is that on-chain, Mastercoin only publishes various types of transaction behaviors, without recording related asset information. In Mastercoin nodes, a state model database is maintained by scanning the Bitcoin blockchain, while off-chain nodes do not record any information on the blockchain.

Compared to Colored Coins, its logic is more complex. And because it does not record and verify states on the chain, its transactions do not need to be continuous (continuous coloring).

However, in order to implement the complex logic of Mastercoin, users need to trust the state of the off-chain database in the nodes, or allow Omni Layer nodes to perform verification themselves.

Summary:

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 achieves its own transaction publishing and sorting by parasitizing BTC's consensus system, and then maintains the state in the off-chain database.

According to the information provided by OmniBolt, the Omni Layer is proposing a new UBA (UTXO Based Asset) asset protocol to Tether, which will utilize the Taproot upgrade to encode asset information into tapleaf, enabling conditional payments and other functions. At the same time, OmniBolt is introducing Stark into the OmniLayer's Lightning Network infrastructure.

Client Side Validation Concept

If we want to understand the concept of client-side validation, we need to go back to the second year of the appearance of Colored Coins and Mastercoin, which was in 2013. Peter Todd published an article in that year titled "Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation". Although the title of the article may not seem related to client-side validation, careful reading reveals that it is actually the earliest enlightenment idea about client-side validation.

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn

Basic Elements:

m: message, message

Verify(l,w,m) → bool: Verify whether the seal l is closed on the message m.

For CSV assets on BTC, Bitcoin itself acts as a single-sealed "witness". This is because, in order to verify a Bitcoin transaction, nodes 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, Bitcoin's consensus rules and honest nodes on the network will reject the transaction.

Yes, that's just how simple it is.

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

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

Verification work client completed: Most of the verification work is completed on the user's device. This means that not all nodes on the network need to participate in verifying each transaction, only the involved parties need to verify the validity of the transaction.

For those who use client-side validation for assets, there is one thing to note:

When verifying assets through off-chain transactions and client validation, not only must the private key of the held asset be presented, but also the complete proof of the corresponding asset's merkle path must be presented.

Client-side Verification (CSV) Pioneer: RGB

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

Giacomo Zucco expressed disappointment with these projects. He believes that they are not as good as Bitcoin, and he thinks that the way tokens were implemented on Bitcoin in the past was inappropriate. During this process, he met Peter Todd and became fascinated with Peter Todd's idea of Client-Side-Validation. He then began proposing the idea of RGB.

The biggest difference between the RGB asset protocol and the previous one is the addition of a VM for Turing-complete contract execution engine, in addition to the client-side validation of assets mentioned earlier. In order to ensure the security of contract data, Schema and Interface are also designed. Schema is similar to Ethereum, declaring the content and functionality of the contract, while Interface is responsible for the implementation of specific functions, similar to the interface in programming languages.

These contract schemas are responsible for limiting unexpected behavior during VM execution, such as RGB20 and RGB21, which respectively limit certain transactions involving homogeneous and non-homogeneous tokens.

RGB's commitment mechanism PerdersenHash

From the perspective of commitment mechanisms, RGB uses Perdersen hash. Its advantage is that it can commit to a value without revealing it. Using Pedersen hash to construct a Merkle tree means that you can create a privacy-preserving Merkle tree that can hide its values. This structure can be used in certain specific privacy-preserving protocols, such as some anonymous cryptocurrency projects. However, it may not be suitable for CSV assets, which will be discussed later in comparison with Taproot Assets.

RGB's virtual machine design Simplicity → AluVM

RGB's goal is not only to implement an asset protocol for client-side verification, 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 generates an execution proof when executing expressions and makes it easier to formally verify the contracts it writes (to avoid bugs). However, the development of this language was not ideal and eventually fell into trouble. This directly led to the difficulty of the entire RGB protocol at that time. Finally, RGB began to use a VM called AluVM developed by Maxim, which aims to avoid any undefined behavior, similar to the original Simplicity. The new AluVM is said to use a programming language called Contractum to replace Rust, which is currently used in the future.

RGB layer2 expansion direction: Lightning Network or sidechain?

The client-side validation of assets cannot ensure the security of continuous transactions off-chain. Because the client-side validated assets still rely on L1 for transaction publishing and sequencing, the transaction speed will still be limited by the L1 witnesses' block generation speed without an L2 expansion plan. This means that if RGB transactions are directly conducted on Bitcoin, under strict security requirements, the time interval between two related transactions needs to be at least ten minutes (BTC's block generation time). Undoubtedly, in most cases, such transaction speed is unacceptable.

RGB and Lightning Network

The principle of the Lightning Network is simple. In essence, the two parties involved in a transaction will sign a bunch of contracts (commitment transactions) off-chain to ensure that if either party violates the contract, the injured party can submit the contract (commitment transaction) to BTC for settlement, retrieve their funds, and punish the other party. In other words, the Lightning Network ensures the security of off-chain transactions through protocol and game design.

RGB can build its own lightning network infrastructure by designing payment channel contract rules suitable for RGB, but the complexity of the lightning network is extremely high, and building this infrastructure is not an easy task. However, compared to Lightnling labs, which has been working in this field for many years and LND has a market share of over 90%.

RGB's Sidechain Prime

LNP-BP, as the maintainer of the current RGB protocol, Maxim proposed a client-side validation asset expansion plan called **Prime** in June 2023, criticizing the existing sidechain and Lightning Network expansion plans for being too complex in development. Maxim believes that in addition to Prime, there are also NUCLEUS multi-node Lightning channels and Ark/Enigma channel factories, both of which require more than two years of development. However, Prime can be completed in just one year.

Prime is not a traditional blockchain design, but a modular proof publishing layer designed for client verification. It consists of four parts:

Timestamp service: Finalizes a transaction sequence in as fast as 10 seconds.

Proof: Produced and published through PMT storage along with the block header.

One-time sealing: An abstract single-sealing protocol that guarantees anti-double-spending. When implemented on Bitcoin, it can be bound to UTXO, similar to the current RGB design.

5. Engineering Implementation

Discussion on the Future of BTC Scalability

From the perspective of application design, Bitcoin chose a design philosophy that focuses on verification rather than on-chain computation early on (Turing completeness and state for smart contract). The essence of blockchain is a replicated state machine. If the consensus of a chain is based on on-chain computation, it is difficult to say that it is a reasonable and scalable approach to make all nodes in the network repeat these computations in the end. If the focus is on verification, then verifying the validity of off-chain transactions may be the most suitable solution for BTC's scalability.

Where does the verification occur? This is important.

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

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

2. Verification occurs on the semi-chain (BitVM).

BitVM has a huge on-chain cost, but can efficiency be improved using ZK fraud proof? The answer is no, because the implementation of ZK fraud proof is based on the premise that on-chain ZKP verification is possible, which brings us back to the dilemma of the OP-ZKP scheme.

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

Validation occurs entirely off-chain, which was previously discussed in relation to the asset protocol for CSV and the Lightning Network. As discussed earlier, in the design of CSV, we cannot completely eliminate the possibility of collusion and tampering. What we can do is use cryptography and protocol design to limit the scope of malicious collusion and make such behavior unprofitable.

The advantages and disadvantages of off-chain verification are equally obvious. The advantage is that it minimizes the use of on-chain resources and has huge 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 performed. Additionally, off-chain verification also means that the data is stored off-chain and must be managed by the user, which places higher demands on the security and stability of the software execution environment.

The trend of capacity expansion and evolution.

Currently, in the popular Layer2 paradigm of Ethereum, the validity of calculations in Layer2 is verified through Layer1, which pushes the state calculation down to Layer2, but the verification is still retained in Layer1. In the future, we can also push the verification calculation down to off-chain, further releasing the performance of the current blockchain infrastructure.

References

Assia, Y. (n.d.). Colored Bitcoin. Retrieved from https://yoniassia.com/coloredbitcoin/

CryptoAdventure. (n.d.). A Brief History of Colored Coins: What Made Them Special. Retrieved from https://cryptoadventure.com/a-brief-history-of-colored-coins-what-made-them-special/

Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from https://bitcoil.co.il/BitcoinX.pdf

Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html

Livera, S. (n.d.). Episode 501. Retrieved from https://stephanlivera.com/episode/501/

Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/

Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d

Burtey, N. (n.d.). Twitter Post. Retrieved from https://twitter.com/nicolasburtey/status/1703705962664669225

Burtey, N. (n.d.). Twitter Post. Retrieved from https://x.com/nicolasburtey/status/1703710347889127585?s=20

Bosworth, A. (n.d.). Twitter Post. Retrieved from https://twitter.com/alexbosworth/status/1703423563288473769

BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from https://www.youtube.com/watch?v=9fz34ef5GSk&ab_channel=BitcoinShooter

Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin

Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE

Todd, P. (2016). OpenTimestamps Announcement. Retrieved from https://petertodd.org/2016/opentimestamps-announcement

Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from https://bitcoinops.org/en/topics/client-side-validation/

Todd, P. (2016). Commitments and Single-Use Seals. Retrieved from https://petertodd.org/2016/commitments-and-single-use-seals

Todd, P. (2014). Setting the Record: Proof of Publication. Retrieved from https://petertodd.org/2014/setting-the-record-proof-of-publication

Bitcoin Magazine. (n.d.). The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality. Retrieved from https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality

Linux Foundation. (2015). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59

Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/

Linux Foundation. (2023). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html

Salvatoshi. (n.d.). Twitter Profile. Retrieved from https://twitter.com/salvatoshi

Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from https://merkle.fun/

Muneeb. (n.d.). Twitter Post. Retrieved from https://twitter.com/muneeb/status/1712853971948229042

Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/

Todd, P. (2013). Disentangling Crypto Coin Mining. Retrieved from https://petertodd.org/2013/disentangling-crypto-coin-mining

Original Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia