Off-Chain Transfer: The Evolutionary Path of Bitcoin Asset Protocols

Introduction

Issuing assets based on BTC has always been a hot topic. From the earliest appearance of Colored Coins in 2011 to the recently popular Ordinal Protocol, the BTC community has always been able to bring forth new players and consensus. However, few have stood the test of time. With the ambitious Lightling Labs announcing their plan to build a Stable Coin on top of Taproot Assets, and Tether declaring its choice of RGB for minting USDT on Bitcoin’s first layer, it’s clear that the once-famous OmniLayer (Mastercoin) is no longer the biggest player in the BTC ecosystem. Client-Side Validation (CSV) asset protocols are starting to gain attention, differing from traditional BTC asset protocols by also incorporating features for Bitcoin’s scalability. But faced with such a multitude of asset protocols in the BTC ecosystem, one must ask: what are their differences? And how should we choose and find our own opportunities among these numerous asset protocols?

This article aims to guide readers in reviewing various asset protocols that have appeared in Bitcoin’s history, delving into the potential trajectory of Bitcoin-based asset protocols in the foreseeable future.

Colored Coins

The idea of Colored Coins was first proposed by Yoni Assia, the current CEO of eToro, in an article written on March 27, 2012, titled “bitcoin 2.X (aka Colored bitcoin).” The article posited that Bitcoin, as an underlying technology, is perfect, much like how HTTP is the foundation of the internet. Therefore, on the basis of reusing BTC, the Colored Coins token protocol was designed.

Yoni Assia aimed to create a BTC 2.0 economy through this method - any community could create a variety of currencies in this way. This approach of using Bitcoin as the underlying technology for clearing transactions and avoiding double-spending was undoubtedly a very bold idea at the time.

As a protocol for issuing assets based on Bitcoin, Colored Coins’ method is to “color” a certain amount of Bitcoin to represent these assets. These marked Bitcoins functionally remain Bitcoins, but they also represent another asset or value. But how could this idea be implemented on Bitcoin?

On July 3, 2014, ChromaWay developed an Enhanced Pay-to-Script-Hash (P2SH) based Colored Coins protocol (EPOBC), which simplified the process for developers to create colored coins. This was the earliest protocol to adopt Bitcoin Script’s OP_RETURN functionality.

The final implementation is shown in the following image:

)

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

Homogenized Tokens and Minimum Binding Value

In the genesis transaction, if a colored coin is bound with 1000 sats, the smallest split unit of this colored coin is 1 sat. This means that the asset or token can be divided or allocated into a maximum of 1000 parts (but this is only theoretical, to prevent dust attacks, for example, the sat used to be set at 546 SAT, and later to ordinal which is higher).

Verification Issues

To ascertain the authenticity and ownership of a colored coin, it’s necessary to trace and verify from the asset’s genesis transaction to the current UTXO. Therefore, it is essential to develop a dedicated wallet and accompanying full node, and even a browser.

Potential Risk of Miner Censorship

Due to the distinct characteristics of ColoredTransaction, which involves writing metadata information into the output, there is a possibility for miner censorship.

Colored coins are essentially an asset tracking system, utilizing Bitcoin’s verification rules to track asset transfers. However, to prove that any specific output (txout) represents a certain asset, an entire transfer chain from the asset’s origin to the present is required. This means that verifying the legitimacy of a transaction may require a long chain of proof. To address this issue, there was a proposal for OP_CHECKCOLORVERIFY to assist in directly verifying the correctness of Colored Coins transactions on BTC, but this proposal was not passed.

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 titled “The Second Bitcoin Whitepaper,” which described the concept of creating new assets or tokens on Bitcoin’s existing blockchain, later known as “MasterCoin.” It was subsequently renamed Omni Layer.

The Mastercoin project conducted an initial token sale (what we today call an ICO or Initial Coin Offering) in 2013, successfully raising millions of dollars. This is considered the first-ever ICO in history. The most notable application of Mastercoin is Tether (USDT), the most well-known fiat stablecoin, which was initially issued on the Omni Layer.

In fact, the concept of Mastercoin predated Colored Coins. The reason it is discussed second here is that, compared to Colored Coins, Mastercoin is a relatively more complex solution. Mastercoin established a complete node layer, thereby offering more complex functionalities (such as smart contracts), while Colored Coins was simpler and more direct, focusing mainly on “coloring” or marking Bitcoin UTXOs to represent other assets.

The key difference from Colored Coins is that Mastercoin only publishes various types of transaction behaviors on the chain, without recording related asset information. In Mastercoin nodes, a state model database is maintained by scanning Bitcoin blocks in off-chain nodes.

Compared to Colored Coins, Mastercoin can execute more complex logic. And because it does not record state and perform validation on the 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 run their own Omni Layer nodes for verification.

In summary:

The primary difference between Mastercoin and Colored Coins is that Mastercoin chose not to maintain all the data required for the protocol on-chain. Instead, it parasitically used BTC’s consensus system to implement its own transaction publication and ordering, while maintaining the 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, which will utilize the Taproot upgrade to encode asset information into tapleaf, enabling functionalities like conditional payments. Meanwhile, OmniBolt is introducing Stark into OmniLayer’s Lightning Network infrastructure.

The concept of Client-Side Validation

To understand the concept of client-side validation, we need to go back 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 does not seem directly related to client-side validation, a careful reading reveals that it contains the earliest enlightenment thoughts on client-side validation.

Peter Todd, an early researcher in Bitcoin and cryptography, has always been searching for a method to make Bitcoin’s operation more efficient. He developed a more complex concept of client-side validation based on the concept of timestamps. In addition, he introduced the concept of “single use seal,” which will be mentioned later.

Following Peter Todd’s thoughts, let’s first understand the problems that BTC (Bitcoin) actually solved. In Peter Todd’s view, BTC solved three problems:

Proof-of-Publication

The essence of proof-of-publication is to solve the double-spending problem. For example, Alice has some bitcoins she wants to transfer to Bob. Although she signs a transaction to transfer to Bob, Bob may not physically know of the transaction’s existence. Hence, there needs to be a public place to publish transactions, where everyone can query them.

Order Consensus

In computer systems, the physical time we usually perceive does not exist. In distributed systems, time is often represented by Lamport timestamps, which do not measure our physical time but order our transactions.

Validation (Optional)

Validation on BTC refers to the verification of signatures and BTC transfer amounts. However, here, Peter Todd believed that this validation is not necessary for building a token system on top of BTC, but rather an optimization option.

At this point, you might think of Ominilayer mentioned earlier. Ominilayer itself does not delegate the calculation and verification of state to BTC but still reuses BTC’s security. Colored Coins, on the other hand, delegate state tracking to BTC. The existence of both demonstrates that validation does not necessarily have to occur on-chain.

So, how does client-side validation effectively validate transactions?

Let’s first see what needs to be validated:

• State (transaction logic validation)

• Input TxIn validity (to prevent double-spending)

It is evident that for assets issued on BTC, each transaction requires verification of the entire related transaction history to ensure that the referenced input has not been spent and the state is correct. This is highly inefficient. So, how can it be improved?

Peter Todd believes that we can simplify this process by changing the focus of validation. Instead of confirming that an output has not been double-spent, this method focuses on confirming that the transaction’s inputs have been published and are not conflicting with other inputs. By ordering the inputs in each block and using a Merkle tree, this type of validation can be done more efficiently, as each validation requires only a small portion of data, not the entire chain history of that input.

Peter Todd proposed the structure of a commitment tree as follows:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

But how do we store such a commitment tree on the 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, one-time use seals used to protect cargo shipping containers in the real world. A single-use seal is a unique object that can precisely close on a message once. In short, a single-use seal is an abstract mechanism used to prevent double-spending.

For SealProtocol, there are three elements and two actions.

Basic elements:

1. l： seal, that is, seal
2. m： message, message
3. In：witness, witness

Basic operations: There are two basic operations:

1. Close(l,m) → w: in messagemupper closing seall, generate a witnessIn。
2. Verify(l,w,m) → bool: Verify seallAre you in the news?mis closed.

The implementation of single use seal is in terms of securityTwo different messages cannot be found by an attackerm1andm2, and causes the Verify function to return the same sealtrueof.

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 (unspent transaction output) can only be spent once. Therefore, the output of a Bitcoin transaction can be considered a one-time seal, and when this output is used as an input to another transaction, the seal is “broken” or “used.”

For CSV assets on BTC, Bitcoin itself acts as a one-time sealed “witness”. This is because, in order to validate a Bitcoin transaction, a node must check that each input to the transaction references a valid and unspent UTXO. If a transaction attempts to double-spend a UTXO that has already been spent, Bitcoin’s consensus rules and honest nodes across the network will reject the transaction.

Can it be simpler?

single use seal That is, any blockchain is regarded as a database. We store the promise of a certain message in this database in some way, and maintain a consumed or to-be-consumed status for it.

Yes, it’s that simple.

To sum up, client-verified assets have the following characteristics:

1. Off-chain data storage: Most of the transaction history, ownership and other related data of client-verified assets are stored off-chain. This greatly reduces on-chain data storage needs and helps improve privacy.
2. Commitment mechanism: Although asset data is stored off-chain, changes or transfers to this data will be recorded on-chain through commitments. These commitments enable on-chain transactions to reference off-chain states, thereby ensuring the integrity and non-tamperability of off-chain data.
3. On-chain witness (not necessarily BTC): While most of the data and verification is off-chain, client-verified assets can still take advantage of the security of the underlying chain (issuance of proofs, ordering of transactions) through commitments embedded on-chain.
4. Verification is done on the client side: Most of the verification work is done on the user’s device. This means that all network nodes do not need to participate in verifying each transaction, only the participants involved need to verify the validity of the transaction.

For those who use client-side verification of assets, there is another point to note:

When trading off-chain and verifying assets verified by the client, you must not only show the private key holding the asset, but also show proof of the complete merkel path of the corresponding asset.

The Pioneer in 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 things outside of Bitcoin, such as Mastercoin and Colored Coins projects. .

Giacomo Zucco expressed disappointment. He believes that these projects are inferior to Bitcoin, and he believes that the previous ways of implementing tokens on Bitcoin are inappropriate. In the process, he met Peter Todd and became fascinated with Peter Todd’s idea of ​​​​Client-Side-Validation. Then he started 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 implement a Turing-complete contract execution engine. In addition, in order to ensure the security of contract data, 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 schemas of these contracts are responsible for restricting behaviors that do not exceed expected behavior when the vm is executed, such as RGB20 and RGB21, which are respectively responsible for some restrictions on the transactions of fungible tokens and non-fungible tokens.

RGB’s Commitment Mechanism: Pedersen Hash

In terms of commitment mechanisms, RGB adopts the Pedersen Hash. Its advantage lies in being able to commit to a value without disclosing it. Using the Pedersen Hash to construct a Merkle tree means that you can create a privacy-protected Merkle tree that hides the values within it. 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: From Simplicity to AluVM

RGB aims not only to implement a client-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. This language is characterized by generating an execution proof while executing expressions, making it easier to formally verify contracts written in it (to avoid bugs). However, the development of this language was not ideal and eventually encountered difficulties. This directly led to the difficult birth of the RGB protocol that year. Ultimately, RGB started using AluVM, developed by Maxim, with the goal of avoiding any undefined behavior, similar to the initial Simplicity. The new AluVM is said to be replaced in the future by a programming language called Contractum, currently using Rust.

RGB’s Layer 2 Expansion Direction: Lightning Network or Sidechain?

Client-validated assets cannot conduct continuous transactions securely off-chain. Because client-validated assets still rely on L1 for transaction publication and sequencing, their transaction speed is limited by the block generation speed of their L1 witness. This means that if RGB transactions are conducted directly on Bitcoin, under strict security requirements, the time between two related transactions needs to be at least ten minutes (BTC’s block time). Undoubtedly, such transaction speed is mostly unacceptable in most cases.

RGB and the Lightning Network

Simply put, the principle of the Lightning Network is that the two parties involved in a transaction sign a bunch of contracts (commitment transactions) off-chain. These ensure that if any party violates the contract, the aggrieved party can submit the contract (commitment transaction) to BTC for settlement, retrieve their funds, and penalize the other party. In other words, the Lightning Network ensures the security of off-chain transactions through protocol design and game theory.

RGB can build its own Lightning Network infrastructure by designing payment channel contract rules suitable for itself, but the complexity of the Lightning Network is extremely high, and building this system is not an easy task. However, in contrast, Lightnling Labs has been cultivating this field for many years, and LND has more than a 90% market share.

RGB’s Sidechain: Prime

LNP-BP, currently maintaining the RGB protocol, with Maxim releasing a proposal called Prime in June 2023, a client-validated asset expansion scheme. In it, he criticized the existing sidechain and Lightning Network expansion schemes as being too complex in development. Maxim indicated that he believes that besides Prime, other expansion methods include 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 publication layer designed for client validation, consisting of four parts:

1. Timestamp Service: Determining a transaction sequence in as fast as 10 seconds.

2. Proof: Stored in PMT format, produced, and published together with the block header.

3. One-time Seal: An abstract one-time seal protocol, ensuring double-spending protection. If implemented on Bitcoin, it can be bound to UTXO, similar to the current RGB design.

4. Smart Contract Protocol: Shardable Contracts - RGB (replaceable).

To solve the issue of RGB transaction confirmation times, Prime uses a timestamp service to quickly confirm off-chain transactions and encapsulate the transactions and IDs into blocks. Simultaneously, the transaction proofs on Prime can be further merged through PMT and then anchored to BTC in a manner similar to checkpoints.

Taproot-Based CSV Asset Protocol: Taproot Assets

Taproot Assets is a CSV asset protocol based on Taproot, used to issue client-validated assets on the Bitcoin blockchain. These assets can be traded instantly, in large volumes, and at low cost through the Lightning Network. The core of Taproot Assets lies in leveraging the security and stability of the Bitcoin network and the speed, scalability, and low cost of the Lightning Network. This protocol was designed and developed by Lightnling Labs’ CTO roasbeef, who may be the only person on this planet who has personally led the development of both a Bitcoin client (BTCD) and a Lightning Network client (LND), and has a profound understanding of BTC.

Taproot transactions only carry the root hash of the asset script, making it difficult for external observers to identify whether they involve Taproot Assets, as the hash itself is generic and can represent any data. With the Taproot upgrade, Bitcoin gained the capability of smart contracts (TapScript). Based on this, the asset coding of Taproot Assets is akin to creating a token definition similar to ERC20 or ERC721. Thus, Bitcoin not only has the function of asset definition but also the ability to write smart contracts, laying the groundwork for the token smart contract infrastructure on Bitcoin.

The coding structure of Taproot Assets is as follows: [The description ends here, indicating the next part of the article likely delves into technical details of the Taproot Assets coding structure.]

Image via Lightning Labs CTO roasbeef

As CSV (CoinSwap) asset protocols, Taproot Assets are designed to be more streamlined compared to RGB. They maximize the use of the current advancements in the BTC ecosystem, such as the Taproot upgrade and PSBT (Partially Signed Bitcoin Transactions). The most significant difference between Taproot Assets and RGB in terms of application extensibility lies in the execution VM (Virtual Machine). Taproot Assets employ TaprootScriptVM, which is the same as the native VM used by BTC. In recent years, many infrastructural studies for BTC have been based on TapScript. However, due to the slow pace of BTC upgrades, these studies have not been quickly implemented, making Taproot Assets a potential testing ground for these new ideas.

Where do Taproot Assets and RGB differ?

1. Transaction Validation and Light Node Friendliness

Due to the implementation of a sum tree, Taproot Assets boast high verification efficiency and security (verification and transaction can be performed simply with a proof of holding, without traversing the entire transaction history). In contrast, RGB’s use of Pedersen commitments hinders effective validation of inputs, requiring RGB to trace back the transaction history, which becomes a significant burden over time. The design of the Merkel sum tree also facilitates light node verification in Taproot Assets, a feature not present in previous asset protocols built on BTC.

1. Execution VM

Taproot Assets emerged following the Taproot upgrade. They utilize TaprootScriptVM, the script execution engine inherent in Bitcoin post-Taproot upgrade, and vPSBT, a variant of BTC’s PSBT. Once the lightning channel mechanism of Taproot Assets is completed, it can immediately reuse all current LND infrastructure and past Lightning Labs products (LND currently dominates over 90% of the lightning network). The recent BitVM proposal, also based on TaprootScript, theoretically supports Taproot Assets. However, RGB’s VM and validation rules (SCHEMA) are self-contained, forming a relatively closed ecosystem. RGB’s development is largely confined within its ecosystem, and its integration with the Bitcoin ecosystem is not as close as one might think. For instance, the only relation of RGB to the Taproot upgrade is encoding chain commitment data into the Witness’s TapLeaf.

1. Smart Contracts

In RGB’s current implementation, contracts and VM are heavily emphasized. However, smart contracts have not yet appeared in Taproot Assets. Currently, RGB does not explain how modifications to the Global State synchronize with individual contract shards (UTXO), nor how Pedersen commitments, which only assure total asset quantity, detect tampering with other states. In contrast, Taproot Assets, with their simpler design, currently only store asset balances and lack extensive state storage, making smart contracts discussion premature. However, Lightning Labs has indicated that Taproot Assets will focus on smart contract design next year.

1. Synchronization Hub

As understood from the basic principles of client-side asset verification, holding the Proof is as important as holding the private key. But what if the Proof is lost on the user’s client side? In Taproot Assets, this issue can be addressed through a ‘universe’. The Universe is a publicly auditable sparse Merkle tree, covering one or more assets. Unlike conventional Taproot asset trees, the Universe does not host Taproot assets. Instead, it commits to a subset of one or more asset histories. In RGB, this role is played by Storm, which synchronizes off-chain proof data via P2P. However, due to historical reasons of RGB’s development teams, these proof formats are currently incompatible. RGB’s ecosystem team, DIBA, is reportedly developing ‘carbonado’ to solve this issue, though progress is unclear.

1. Engineering Implementation

All libraries used by Taproot Assets are time-tested, as Lightning Labs has its own Bitcoin client (BTCD), lightning network client (LND), and numerous wallet lib implementations. In contrast, most libraries used in RGB are self-defined, and from an industrial standard viewpoint, RGB’s implementation is still in the experimental stage.”

A Brief Discussion on the Future of BTC Expansion

As the discussion progresses, it becomes evident that client-side validation of asset protocols has moved beyond the realm of protocol specifications and is venturing towards computational expansion.

Many people believe that Bitcoin will exist as digital gold in the future, with other chains creating the application ecosystem. However, I have a different opinion. As seen in many discussions on BTC forums, they often revolve around various altcoins and their short-lived existence. The rapid demise of these altcoins turns the capital and efforts surrounding them into bubbles. With Bitcoin’s strong consensus foundation, there’s no need to build a new L1 for application protocols. What we need to do is to leverage this robust infrastructure of Bitcoin to build a more long-term decentralized world.

Less on-chain computation, more on-chain validation

From a design perspective, Bitcoin early on chose not to focus on on-chain computation but instead on a validation-centric philosophy (Turing completeness and state for smart contracts). Blockchain is essentially a replicated state machine. If a chain’s consensus is based on on-chain computation, it’s hard to justify the rationale and scalability of having all nodes in the network repeat these computations. If we focus on validation, then validating off-chain transactions’ effectiveness might be the most suitable expansion strategy for BTC.

Where does validation occur? This is important

For protocol developers on top of Bitcoin, how to use Bitcoin for critical validations, or even to place validations off-chain, and how to design security schemes, are matters for the protocol designers themselves. These should not and need not be associated with the chain itself. Therefore, how validation is implemented will lead to different expansion strategies for BTC.

Based on the perspective of validation implementation, we have three directions for expansion:

1. 1.On-chain validation (OP-ZKP)
2. If OP-ZKP is implemented directly in TaprootScriptVM, it means integrating ZKP validation capabilities into BTC itself, coupled with some Covenant designs for settlement protocols, creating a Zk-Rollup expansion plan that inherits BTC’s security. However, unlike deploying a validation contract on Ethereum, BTC’s slow upgrade process, coupled with such a specialized and potentially upgrade-needing op-code, makes it challenging.
4. 2.Semi-on-chain validation (BitVM)
5. The design of BitVM is not meant to serve regular transaction logic. Robin Linus also indicated that BitVM’s future lies in creating a free cross-chain market for various SideChains. BitVM’s approach is considered semi-on-chain because most of these validation computations don’t happen on-chain, but rather off-chain. However, a significant reason for designing around BTC’s Taproot is to utilize TapScriptVM for computational validation when necessary, theoretically inheriting BTC’s security. This process also generates a validation trust chain. For example, it’s sufficient if one of ‘n’ validators is honest, akin to Optimistic Rollups.
6. BitVM’s on-chain costs are high, but can it use ZK fraud proofs for efficiency improvement? The answer is no, because the implementation of ZK fraud proofs is based on the ability to perform ZKP validation on-chain, which brings us back to the dilemma of the OP-ZKP scheme.
8. 3.Off-chain validation (Client-Side-Validation, Lightning Network)
9. With validation occurring entirely off-chain, we return to the previously discussed CSV asset protocols and the Lightning Network. In previous discussions, it was noted that in CSV design, we can’t completely prevent collusive tampering. What we can do is use cryptography and protocol design to keep the malicious collusion damage within a controllable range, making such behavior unprofitable.
10. The pros and cons of off-chain validation are clear. The advantage is minimal use of on-chain resources, with enormous potential for expansion. The downside is that it’s almost impossible to fully leverage BTC’s security, greatly limiting the types and methods of off-chain transactions. Moreover, off-chain validation also means that data is kept off-chain, managed by users, which demands higher requirements for the security of the software execution environment and software stability.

Trend of Expansion Evolution

Currently, the popular Layer2 on Ethereum, in essence, uses Layer1 to validate Layer2’s computational effectiveness. That is, state computations are pushed down to Layer2, but validation remains on Layer1. In the future, we can similarly push down validation computations off-chain, further unleashing the performance of current blockchain infrastructure.

Disclaimer：

1. This article is reprinted from [mirror]. All copyrights belong to the original author [Ben77]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.