Off-chain Transfer: The Evolution of Bitcoin Asset Protocols
This article aims to explore the future development of BTC asset protocols by reviewing the asset protocols that have appeared in BTC's history.Author: Ben77
Introduction
Issuing assets based on BTC has always been a hot topic. From the Colored Coins that emerged in 2011 to the recent popularity of the Ordinal protocol, the BTC community has consistently seen new players and consensus arise, but very few have remained. However, with the ambitious announcement from Lightning Labs regarding their plan to build a Stable Coin on Taproot Assets, Tether also announced that it would choose RGB for the issuance of USDT on the Bitcoin layer.
This signifies that the once-renowned OmniLayer (Mastercoin) is no longer the largest player in the BTC ecosystem. The Client Side Validation (CSV) asset protocol has entered the public eye, differing from traditional BTC asset protocols by incorporating attributes for BTC scaling. Yet, faced with such a multitude of asset protocols in the BTC ecosystem, one cannot help but ask: what are their differences, and how should we choose among them to find our own opportunities? This article aims to guide you through a review of the asset protocols that have appeared in BTC's history while exploring the future development of BTC asset protocols.
Colored Coins
The idea of Colored Coins was first proposed by Yoni Assia, the current CEO of eToro, in an article titled "Bitcoin 2.X (aka Colored Bitcoin)" written on March 27, 2012. The article posited that Bitcoin, as a foundational technology, is perfect, much like HTTP is the backbone of the web. Thus, Colored Coins was designed as a token protocol that reuses BTC.
Yoni Assia hoped to create a BTC 2.0 economy through this method—any community could create multiple currencies in this way. The approach of using Bitcoin as a foundational technology for settling transactions and preventing double spending was undoubtedly a bold idea at the time.
As a protocol for issuing assets based on Bitcoin, Colored Coins works by "coloring" a certain amount of Bitcoin to represent these assets. These marked Bitcoins still function as Bitcoin, 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 Proof of Burn Colored Coin (EPOBC) protocol, which simplified the process for developers to create colored coins. This was one of the earliest protocols to utilize Bitcoin Script's OP_RETURN functionality.
The final implementation is shown in the image below:
This implementation is very straightforward, but it also brought many issues:
1. Homogeneous Tokens and Minimum Binding Value
If a colored coin is bound to 1000 sat in the genesis transaction, then the minimum divisible unit of that colored coin is 1 sat. This means that the asset or token can be split or allocated into a maximum of 1000 parts (though this is theoretical; to prevent dust attacks, for example, the minimum sat was set at 546 SAT back then, and later higher for ordinals).
2. Verification Issues
To determine the authenticity and ownership of colored coins, one needs to trace back from the asset's genesis transaction to the current UTXO. Therefore, specialized wallets and supporting full nodes, even browsers, need to be developed.
3. Potential Miner Censorship Risks
Due to the distinctive characteristics of Colored Transactions, which write metadata information in the output, there is a possibility of miner censorship.
Colored Coins are essentially an asset tracking system that uses Bitcoin's verification rules to track asset transfers. However, to prove that any specific output (txout) represents a particular asset, a complete chain of transfers 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, there was a proposal for OP_CHECKCOLORVERIFY to help verify the correctness of Colored Coins transactions directly on BTC, but this proposal did not pass.
The First ICO in the Crypto Industry: Mastercoin
The initial concept of Mastercoin was proposed by J.R. Willett. In 2012, he published a white paper titled "The Second Bitcoin Whitepaper," describing the concept of creating new assets or tokens on Bitcoin's existing blockchain, which later became known as "MasterCoin." It was subsequently renamed Omni Layer.
The Mastercoin project conducted an initial token sale in 2013 (what we now call 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 was initially issued on Omni Layer as the most well-known fiat stablecoin.
In fact, the idea of Mastercoin predates that of Colored Coins. The reason it is discussed second here is that, compared to Colored Coins, MasterCoin is a relatively heavier solution. MasterCoin established a complete node layer, providing more complex functions (such as smart contracts), while Colored Coins are simpler and more direct, primarily focusing on "coloring" 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-chain and does not record related asset information. In Mastercoin's nodes, a state model database is maintained off-chain by scanning Bitcoin blocks.
Compared to Colored Coins, the logic it can accomplish is more complex. Additionally, since it does not record state and verification on-chain, its transactions do not require continuity (continuous coloring).
However, to implement Mastercoin's complex logic, users need to trust the state in the off-chain database of the nodes or allow Omni Layer nodes to perform verification.
Summary
The biggest difference between Mastercoin and Colored Coins is that it chose not to maintain all the data required for the protocol on-chain but instead leveraged BTC's consensus system to achieve its transaction publishing and ordering, while maintaining state in an off-chain database.
According to information provided by OmniBolt: Omni Layer is proposing a new UBA (UTXO Based Asset) asset protocol to Tether, utilizing the Taproot upgrade to embed asset information into tapleaf, thereby enabling conditional payments and other functions. Meanwhile, OmniBolt is introducing Stark into the OmniLayer's Lightning Network facilities.
Client Side Validation (CSV) Concept
To understand the concept of Client Side Validation, we need to rewind to the year following the emergence of Colored Coins and Mastercoin, which is 2013. In that year, Peter Todd published an article: Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation. Although the title of the article seems unrelated to client-side validation, a careful reading reveals that it contains the earliest ideas about client-side validation.
Peter Todd is an early researcher in Bitcoin and cryptography, always seeking a more efficient way for Bitcoin to operate. He developed a more complex concept of client-side validation based on the idea of timestamps. Additionally, he proposed the concept of a "single use seal," which will be mentioned later.
Now, let’s follow Peter Todd's thoughts to understand what problems BTC actually solves. According to Peter Todd, BTC solves three main problems:
1. Proof of Publication
Proof of publication essentially addresses the double-spending problem. For example, if Alice wants to transfer some Bitcoin to Bob, although she signs a transaction to transfer to Bob, Bob may not physically know that such a transfer exists. Therefore, we need a public place to publish transactions, where everyone can query the transactions.
2. Transaction Ordering Consensus
In computer systems, there is no physical time as we usually perceive it. In distributed systems, this time is usually represented by the distributed clock Lamport, which does not measure our physical time but orders our transactions.
3. Transaction Validation (Optional)
Validation on BTC is about verifying signatures and the amount of BTC transferred. However, Peter Todd believes that this validation is unnecessary for building a token system on BTC; it is merely an optimization option.
At this point, one can already think of the previously mentioned OmniLayer. OmniLayer itself does not delegate state computation and validation to BTC, but it also reuses BTC's security. Colored Coins, on the other hand, entrust state tracking to BTC. The existence of these two has already proven that validation does not necessarily have to occur on-chain.
So how does client-side validation effectively verify transactions?
First, let's look at what needs to be verified:
State (transaction logic validation)
Input TxIn validity (to prevent double spending)
It is easy to see that for assets published on BTC, each transaction needs to verify the entire history of related transactions to ensure that the referenced input has not been consumed and that the state is correct. This is very unreasonable; so how can we improve it?
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 method focuses on confirming that the transaction's input has been published and does not conflict with other inputs. By sorting inputs in each block and using Merkle trees, this verification can be performed more efficiently, as each verification only requires a small portion of the data rather than the entire historical chain of that input.
The commitment tree structure proposed by Peter Todd is as follows:
CTxIn -> CTxOut ->
But how do we store such a commitment tree on-chain? This leads us to the concept of a single-use seal.
Single Use Seal
The single-use seal is one of the core concepts for understanding client-side validation, similar to the physical, single-use seals used to protect shipping containers in the real world. A single-use seal is a unique object that can be closed on a message exactly once. In simple terms, a single-use seal is an abstract mechanism to prevent double spending.
For the Seal Protocol, there are three elements and two actions.
Basic Elements:
l: seal, which is the seal
m: message
w: witness
Basic Operations: There are two basic operations:
Close(l,m) → w: Close the seal l on message m, producing a witness w.
Verify(l,w,m) → bool: Verify whether the seal l has been closed on message m.
The implementation of a single-use seal is secure against an attacker finding two different messages m1 and m2 such that the Verify function returns true for the same seal.
First, a 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 (Unspent Transaction Output) can only be consumed once. Therefore, the outputs of Bitcoin transactions can be seen as single-use seals, 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 the "witness" for the single-use seal. This is because, to verify a Bitcoin transaction, nodes must check whether each input references a valid and unspent UTXO. If a transaction attempts to double-spend an already used UTXO, Bitcoin's consensus rules and the honest nodes across the network will reject that transaction.
Can it be simpler?
Single-use seal treats any blockchain as a database where we store a commitment of a message in some way and maintain a consumed or unconsumed state for it.
Yes, it is that simple.
In summary, client-side validated assets have the following characteristics:
Off-chain Data Storage: The transaction history, ownership, and other related data of client-side validated assets are mostly stored off-chain. This greatly reduces the on-chain data storage requirements and helps improve privacy.
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.
On-chain Witnesses (not necessarily BTC): While most data and validation occur off-chain, client-side validated assets can still leverage the security of the underlying chain (proof of publication, transaction ordering) through commitments embedded on-chain.
Validation Work Done on the Client Side: Most validation work is done on the user's device. This means that not all nodes in the network need to participate in validating each transaction; only the involved participants need to verify the validity of the transaction.
For those using client-side validated assets, there is one more point to note:
When conducting off-chain transactions and validating client-side validated assets, one must not only present the private key of the asset but also provide a complete proof of the corresponding asset's Merkle path.
Pioneer of Client Side Validation (CSV): RGB
The concept of RGB was proposed after 2015 by well-known community figure Giacomo Zucco. Due to the rise of Ethereum and the proliferation of ICOs, many people attempted to do things outside of Bitcoin, such as the Mastercoin and Colored Coins projects.
Giacomo Zucco expressed disappointment with these projects. He believed that they were inferior to Bitcoin and that the previous methods of implementing tokens on Bitcoin were inappropriate. During this process, he encountered Peter Todd and became fascinated with Peter Todd's ideas on Client-Side Validation. Thus, he began to propose the idea of RGB.
The biggest difference between RGB and previous asset protocols, in addition to the characteristics of client-side validated assets mentioned earlier, is the addition of an execution VM for Turing-complete contract execution. Additionally, to ensure the security of contract data, Schema and Interface were designed. Schema is similar to Ethereum, declaring the content and functionality of contracts, while Interface is responsible for the implementation of specific functions, akin to interfaces in programming languages.
These contract schemas are responsible for limiting unexpected behaviors during VM execution, such as RGB20 and RGB21, which impose certain restrictions on the trading of fungible and non-fungible tokens, respectively.
RGB's Commitment Mechanism: PerdersenHash
From the perspective of the commitment mechanism, RGB uses the Pedersen hash. Its advantage lies in the ability to commit to a value without disclosing it. Using Pedersen hash to construct a Merkle tree means you can create a privacy-preserving Merkle tree that can hide its values. This structure can be used in certain specific privacy protection protocols, such as some anonymous cryptocurrency projects. However, it may not be suitable for CSV assets, which will be mentioned later in the comparison with Taproot Assets.
RGB's Virtual Machine Design: Simplicity → AluVM
The goal of RGB is not only to implement a client-side validated asset protocol but also to extend 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 expressions and making it easier to perform formal verification of the contracts written (to avoid bugs). However, the development of this language was not ideal and ultimately fell into difficulties. This directly led to the difficulties faced by the RGB protocol at that time. RGB eventually began using a VM called AluVM, developed by Maxim, aiming to avoid any undefined behavior, similar to the original Simplicity. The new AluVM is said to eventually replace the current Rust implementation with a programming language called Contractum.
RGB Layer 2 Scaling Direction: Lightning Network or Sidechains?
Client-side validated assets cannot guarantee continuous transactions off-chain without security. Since client-side validated assets still rely on L1 for transaction publishing and ordering, without an L2 scaling solution, their transaction speed will still be limited by the block speed of their L1 witnesses. This means that if RGB transactions are conducted directly on Bitcoin, under strict security requirements, the time between two related transactions could be as long as ten minutes (the BTC block time). Undoubtedly, such transaction speeds are often unacceptable.
RGB and the Lightning Network
The principle of the Lightning Network is simple: a series of contracts (commitment transactions) are signed off-chain between the two parties to ensure that if either party breaches the contract, the aggrieved party can submit the contract (commitment transaction) to BTC for settlement, reclaiming their funds and punishing the other party. In other words, the Lightning Network ensures the security of off-chain transactions through protocol and game design.
RGB can design its own payment channel contract details suitable for its own Lightning Network facilities, but the complexity of the Lightning Network is extremely high, and building this infrastructure is not an easy task. However, Lightning Labs has been working in this field for many years, and LND holds over 90% of the market share.
RGB's Sidechain: Prime
As the current maintainer of the RGB protocol, Maxim released a proposal called Prime in June 2023, which is a client-side validated asset scaling solution. In it, he criticized existing sidechain and Lightning Network scaling solutions for being too complex in development. Maxim stated that he believes that aside from Prime, other scaling methods like NUCLEUS multi-node Lightning channels and Ark/Enigma channel factories would require over two years of development. However, Prime can be completed in just one year.
Prime is not a traditional blockchain design but a modular proof-of-publication layer designed for client-side validation, consisting of four parts:
Timestamp Service
Finalizes a transaction sequence in as fast as 10 seconds.Proof
Stored in PMT form and produced and published alongside the block header.Single Use Seal
An abstract single-use seal protocol that ensures double spending prevention. When implemented on Bitcoin, it can be bound to UTXO, similar to the current RGB design.Smart Contract Protocol
Sharded contracts - RGB (replaceable)
From this, it can be seen that to solve the transaction confirmation time issue for RGB, Prime employs a timestamp service to quickly confirm off-chain transactions and embeds the transaction and ID into the block. At the same time, the transaction proofs on Prime can be further merged through PMT and anchored to BTC in a checkpoint-like manner.
Taproot-Based CSV Asset Protocol: Taproot Assets
Taproot Assets is a CSV asset protocol based on Taproot, designed for issuing client-side validated assets on the Bitcoin blockchain, which can be traded instantly, in large volumes, and at low fees through the Lightning Network. The core of Taproot Assets is to leverage the security and stability of the Bitcoin network along with the speed, scalability, and low fees of the Lightning Network. This protocol was designed and developed by roasbeef, the CTO of Lightning Labs, who may be the only person on the planet to have personally led the development of both the Bitcoin client (BTCD) and the Lightning Network client (LND), possessing a deep understanding of BTC.
Taproot transactions only carry the root hash of the asset script, making it difficult for external observers to discern whether Taproot Assets are involved, as the hash itself is generic and can represent any data. With the Taproot upgrade, Bitcoin gained the capability for smart contracts (TapScript). On this basis, the asset encoding of Taproot Assets is equivalent to creating a token definition similar to ERC20 or ERC721. Thus, Bitcoin not only gained the functionality of asset definition but also the ability to write smart contracts, laying the groundwork for the token smart contract infrastructure on Bitcoin.
The encoding structure of Taproot Assets is as follows:
Image from Lightning Labs CTO roasbeef
As a CSV asset protocol, Taproot Assets is designed to be more straightforward compared to RGB. It maximally utilizes the current advancements in the BTC ecosystem, such as the Taproot upgrade and PSBT. The biggest difference in application scalability between Taproot Assets and RGB lies in the execution VM; Taproot Assets uses the same TaprootScriptVM as Bitcoin's native default. In recent years, much of the foundational infrastructure research for BTC has been based on TapScript, but due to the slow pace of BTC upgrades, it has not been applied in the short term. It is foreseeable that Taproot Assets will be a testing ground for these new ideas in the future.
What Are the Differences Between Taproot Assets and RGB?
1. Transaction Verification and Light Node Friendliness
Due to the implementation of the sum tree, Taproot Assets have high verification efficiency and security (the state can be verified and transactions can be conducted solely through possession proof, without needing to traverse the entire transaction history of inputs). The Pedersen commitment used by RGB leads to its inability to effectively verify the validity of inputs, requiring RGB to backtrack through the transaction history of inputs, which will become a heavy burden as transactions evolve. The design of the Merkle sum also allows Taproot Assets to easily achieve light node verification, which is absent in previous asset protocols on BTC.
2. Execution VM
Taproot Assets were born in response to the Taproot upgrade, using the TaprootScriptVM, which is the script execution engine that comes with Bitcoin after the Taproot upgrade, and the vPSBT is a replica of BTC's PSBT. This means that once the Lightning channel mechanism for Taproot Assets is developed, all current LND infrastructure can be immediately reused, along with previous products from Lightning Labs (LND currently holds over 90% market share in the Lightning Network). Additionally, the recently popular BitVM proposal is based on TaprootScript, theoretically allowing all these improvements to ultimately benefit Taproot Assets.
However, for RGB, its VM and verification rules (SCHEMA) are self-contained, forming a relatively closed small ecosystem. The construction based on RGB can only operate within its own ecosystem, and its relationship with the Bitcoin ecosystem is not as close as one might imagine. Taking the follow-up of the Taproot upgrade as an example, the only relationship between RGB and the Taproot upgrade is the encoding of on-chain commitment data into the Witness's TapLeaf.
3. Smart Contracts
In the current implementation design of RGB, contracts and VMs are heavily emphasized. However, in Taproot Assets, smart contracts have not yet been observed. Moreover, RGB has not explained how modifications to the current Global State will synchronize with various independent contract shards (UTXOs). The Pedersen commitment can only guarantee the total number of assets, and there seems to be no further explanation on how to ensure that other states are recognized as tampered. For Taproot Assets, while the design is simple, the current state storage only includes asset balances, with no further states, making it impossible to discuss smart contracts at this time. However, Lightning Labs has revealed that Taproot Assets will focus on smart contract design next year.
4. Synchronization Center
From the basic principles of client-side validated assets mentioned earlier, it can be understood that holding Proof and holding private keys are equally important. However, if Proof remains on the user's client, it may be easily lost. So what can be done? In Taproot Assets, we can avoid this issue through the universe. The universe is a publicly auditable (MS-SMT) entity covering one or more assets. Unlike ordinary Taproot asset trees, the universe is not used to host Taproot assets. Instead, it commits to a subset of the historical data of one or more assets.
In RGB, this part is handled by Storm, which synchronizes off-chain proof data through P2P storage. However, due to historical reasons related to the RGB development team, the proof formats of these teams are currently incompatible. The RGB ecosystem team DIBA has stated that they will develop carbonado to solve this issue, but the progress is still unclear.
5. Engineering Implementation
All the libraries used by Taproot Assets are well-tested, as Lightning Labs has its own Bitcoin client (BTCD), Lightning Network client (LND), and a large number of wallet library implementations. In contrast, most of the libraries used in RGB implementations are self-defined, and from an industrial standard perspective, RGB's implementation is still in the experimental stage.
A Brief Discussion on the Future of BTC Scaling
At this point in the discussion, it becomes clear that client-side validated asset protocols have moved beyond the realm of protocols and are beginning to head towards computational scaling.
Many people say that Bitcoin will exist as digital gold in the future, while other chains will build application ecosystems. However, I have a different view. Just like many discussions on BTC forums revolve around various altcoins and their brief existences, the rapid demise of these altcoins has turned the capital and efforts surrounding them into bubbles. We already have a strong consensus foundation with Bitcoin, and there is no need to build new L1s for application protocols. What we need to do is to effectively utilize Bitcoin as the strongest infrastructure to build a more long-term decentralized world.
Less On-chain Computation, More On-chain Verification
From an application design perspective, Bitcoin early on chose not to focus on on-chain computation but rather on a design philosophy centered around verification (Turing completeness and state for smart contracts). A blockchain is essentially a replicated state machine; if the consensus of a chain is based on on-chain computation, it is difficult to argue that having all nodes in the network repeat these computations is a reasonable and scalable approach. If the focus is on verification, then verifying the validity of off-chain transactions may be the most suitable solution for BTC scaling.
Where Does Verification Occur? This Matters
For developers of protocols on Bitcoin, how to use Bitcoin for key verification, or even to place verification off-chain, and how to design secure solutions, are matters for protocol designers themselves. They do not need to be, nor should they be, related to the chain itself. Thus, how verification is implemented will give rise to different scaling solutions for BTC.
From the perspective of verification implementation, we have three scaling directions:
1. Verification Occurs On-chain (OP-ZKP)
If OP-ZKP is implemented directly in TaprootScriptVM, it would essentially give BTC itself the capability for ZKP verification, allowing for the creation of a Zk-Rollup scaling solution that inherits BTC's security by combining it with some Covenant design settlement protocols. However, unlike deploying a verification contract on Ethereum, BTC's upgrades are inherently slow, and adding such non-general op-codes that may require subsequent upgrades is bound to be challenging.
2. Verification Occurs Semi-On-chain (BitVM)
The design of BitVM ensures that it will not serve ordinary transaction logic. Robin Linus has also indicated that the future of BitVM is to create a free cross-chain market for various SideChains. The reason BitVM's solution is considered semi-on-chain is that most of the time, these verification computations will not occur on-chain but rather off-chain. However, the important reason for designing around BTC's Taproot is to ensure that when necessary, TapScriptVM can be utilized for computational verification, thereby theoretically inheriting BTC's security. In this process, a verification trust chain is also generated, meaning that as long as one of the n verifiers is honest, it suffices, which is the essence of Optimistic Rollups.
The on-chain overhead of BitVM is enormous, but can efficiency be improved using ZK fraud proofs? The answer is no, because the implementation of ZK fraud proofs is based on the premise that ZKP verification can occur on-chain, which brings us back to the predicament of the OP-ZKP solution.
3. Verification Occurs Off-chain (Client-Side-Validation, Lightning Network)
Verification occurring entirely off-chain refers to the previously discussed CSV asset protocols and the Lightning Network. In the previous discussions, it was noted that in the design of CSV, we cannot completely eliminate the occurrence of collusion and tampering. What we can do is use cryptography and protocol design to keep the scope of malicious collusion within controllable limits, making such behavior unprofitable.
The advantages and disadvantages of off-chain verification are also very clear. The advantage lies in minimal resource consumption on-chain, with enormous scaling potential. The disadvantage is that it is nearly impossible to fully reuse BTC's security, which greatly limits the types and methods of off-chain transactions that can be conducted. Additionally, off-chain verification also means that all data is kept off-chain, requiring users to manage it themselves, which places higher demands on the security of the software execution environment and the stability of the software.
Trends in Scaling Evolution
Currently, the popular Layer 2 solutions on Ethereum, from a paradigm perspective, verify the computational validity of Layer 2 through Layer 1, effectively pushing state computation down to Layer 2 while retaining verification on Layer 1. In the future, we can similarly push verification computation down to off-chain, further releasing the performance of the current blockchain infrastructure.
