Evolution and Development Trajectory of Bitcoin Asset Protocol

Original Title: "Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols"

Original Author: Ben77

Original Compiler: Kate, Mars Finance

Introduction

Issuing assets based on Bitcoin has always been a hot topic. From the earliest Colored Coins in 2011 to the recently popular Ordinal protocol, the BTC community has consistently introduced new participants and consensus, but few have persisted. However, Lightning Labs has announced an ambitious plan to develop stablecoins based on Taproot Assets. Tether has also announced plans to mint USDT on Bitcoin's first layer using the RGB protocol.

This means that the once-prominent OmniLayer (formerly Mastercoin) is no longer the largest player in the BTC ecosystem. Client-side validation (CSV) asset protocols are beginning to enter everyone's view. These protocols maintain the integrity of traditional Bitcoin asset protocols while enhancing scalability. However, a series of asset protocols in the Bitcoin ecosystem raise relevant questions: How do they differ from each other, and how should people navigate and seize opportunities in this field?

This article aims to guide readers through a comprehensive review of the various asset protocols that have emerged in Bitcoin's history. Additionally, it seeks to explore the potential trajectory of Bitcoin-based asset protocol development in the foreseeable future.

Colored Coins

The concept of Colored Coins was first proposed by Yoni Assia, the current CEO of eToro, in a groundbreaking article titled "bitcoin 2.X (aka Colored bitcoin)" published on March 27, 2012. The article argued that Bitcoin's underlying technology is as fundamental and perfect as the internet's HTTP. Thus, the Colored Coins token protocol was designed on the basis of BTC.

Yoni Assia envisioned creating a BTC 2.0 economy through this innovation, allowing any community to generate multiple currencies in this way. At the time, using Bitcoin's underlying technology for transaction settlement and preventing double spending was a groundbreaking idea.

Colored Coins are a protocol for issuing assets on the Bitcoin blockchain. It represents other assets by "coloring" specific parts of Bitcoin. These marked Bitcoins still retain their original functionality, but they also represent another asset or value. However, the pressing question is how this idea can be realized on the Bitcoin network.

On July 3, 2014, ChromaWay took an important step by developing the Enhanced Colored Coins Based on Orders Protocol (EPOBC), significantly simplifying the process for developers to create Colored Coins. This was the first protocol to use the Bitcoin script OP_RETURN function.

The result is as follows:

This implementation is very straightforward but also brings many issues:

1. The issue of fungibility and minimum binding value: By binding 1000 sat to a Colored Coin in the genesis transaction, the minimum unit of that Colored Coin becomes 1 sat. This means that the asset or token can theoretically be divided into up to 1000 units (but in practice, it would be lower to prevent dust attacks). For example, the minimum satoshi value was once set at 546 sat, and for Ordinals, it is even higher.

2. To determine the authenticity and ownership of Colored Coins, it is necessary to trace their transaction history and verify from the genesis transaction to the current UTXO. Therefore, dedicated wallets, full nodes, and even scanners need to be developed.

3. Potential miner censorship risk: ColoredTransaction has distinct characteristics, such as writing metadata in the output, which brings the possibility of miner censorship.

Colored Coins are essentially an asset tracking system that uses Bitcoin's validation rules to track asset transfers. However, to prove that any specific output (txout) represents a specific asset, you need to provide the entire transfer chain starting from the asset's source. This means that validating the validity of a transaction may require a long proof chain. To address this issue, proposals like OP_CHECKCOLORVERIFY were put forward to help directly validate Colored Coin transactions on BTC, but the proposal was not adopted.

The First ICO in the Crypto Space: Mastercoin

The concept of Mastercoin was initially proposed by J.R. Willett. In 2012, he published a white paper titled "The Second Bitcoin Whitepaper" outlining the idea of creating new assets or tokens on top of the existing Bitcoin blockchain. This concept eventually became known as "MasterCoin," later renamed Omni Layer.

In 2013, the Mastercoin project conducted an early version of what we now call an ICO (Initial Coin Offering), successfully raising millions of dollars. This is considered the first ICO in history. One of the most notable applications of Mastercoin is Tether (USDT), a well-known fiat-collateralized stablecoin that was originally issued on the Omni Layer.

In fact, the idea of Mastercoin predates Colored Coins. We discuss it second because, compared to Colored Coins, MasterCoin is a relatively more comprehensive solution. MasterCoin established a complete node layer that provides more complex functionalities, such as smart contracts. In contrast, Colored Coins are simpler and more straightforward, primarily focusing on "coloring" or marking Bitcoin UTXOs to represent other assets.

The key difference between the two is that on the blockchain, Mastercoin only records various transaction behaviors without storing relevant asset information. In Mastercoin's nodes, the state model database is maintained by scanning Bitcoin blocks, residing in nodes outside the blockchain.

Compared to Colored Coins, Mastercoin can execute more complex logic. Additionally, since it does not record or validate the state on the blockchain, its transactions do not require continuity (continuous coloring).

However, to implement Mastercoin's complex logic, users need to trust the state maintained in the off-chain database of the nodes or run their own Omni Layer nodes for validation.

In summary:

The main difference between Mastercoin and Colored Coins is that Mastercoin does not maintain all the data required by the protocol on the blockchain. Instead, it relies on Bitcoin's consensus system to manage its transaction publication 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 that will leverage the Taproot upgrade. This protocol will embed asset information into Tapleaf, enabling conditional payments and Stark integration into the Omni Layer's Lightning Network infrastructure.

The Concept of Client-Side Validation

To understand the concept of client-side validation (CSV), we need to go back to the year after the emergence of Colored Coins and Mastercoin, which is 2013. That year, early Bitcoin and cryptographic researcher Peter Todd published an article titled "Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation." Although the title does not explicitly mention client-side validation, a close reading reveals that this is one of the earliest articles introducing the concept.

Peter Todd has been looking for ways to improve the efficiency of Bitcoin operations. He developed a more complex client-side validation concept based on timestamping ideas. Additionally, he introduced the concept of "single-use seals," which will be mentioned later.

To follow Peter Todd's ideas, we first need to understand what problems Bitcoin actually solves. Peter Todd believes that Bitcoin solves three problems:

1. Proof of Publication: The essence of proof of publication is to solve the double spending problem. For example, if Alice wants to transfer some Bitcoin to Bob, even though she has signed a transaction to transfer to Bob, Bob may not physically know of the existence of such a transaction. Therefore, we need a public place to publish transactions, where everyone can query the transactions.

2. Order Consensus: In computer systems, the physical time we usually experience does not exist. In distributed systems, time is often represented by Lamport timestamps, which do not provide a measure of our physical time but serve to order our transactions.

3. Validation (Optional): Bitcoin's validation includes verifying the signatures and transfer amounts in Bitcoin transactions. However, Peter Todd believes that this validation is unnecessary for building token systems on top of Bitcoin; it is merely an optimization option.

At this point, you might recall our earlier discussion about OmniLayer. OmniLayer itself does not delegate state computation and validation to Bitcoin, but it does reuse Bitcoin's security. On the other hand, Colored Coins delegate state tracking to Bitcoin. The existence of these two systems has proven that validation does not necessarily have to occur on the blockchain.

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

First, let's look at what needs to be validated:

• State (transaction logic validation)

• Validate whether the input (TxIn) is valid to prevent double spending.

It is easy to notice that for assets issued on Bitcoin, every transaction needs to validate the entire relevant transaction history to ensure that the referenced inputs have not been spent and that the state is correct. This is very impractical. So how can we improve this?

Peter Todd suggests that we can simplify this process by changing the focus of validation. This approach does not confirm that outputs have not been double spent but instead focuses on ensuring that the inputs of the transaction have been published and do not conflict with other inputs. By sorting inputs in each block and using Merkle trees, this type of validation can be performed more efficiently, as it only requires a small portion of data each time, rather than the entire chain history of the inputs.

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

CTxIn -> CTxOut -> -> CTransaction -> -> CTxIn

But how do we store such a commitment tree on the blockchain? This is where we can introduce the concept of "single-use seals."

Single Use Seals

"Single Use Seal" is one of the core concepts for understanding CSV. It is similar to a single-use seal used to protect cargo containers. A single-use seal is a unique object that can precisely seal a message once. In simple terms, a single-use seal is an abstract mechanism used to prevent double spending.

For the Seal Protocol, there are three elements and two operations.

Basic elements:

• L: Seal

• M: Message, i.e., information or transaction

• W: The verifier of the seal

Basic operations: There are two basic actions:

• Close(l, m)→w: Close the seal L on message M, producing witness W.

• Verify(l, w, m)→bool: Verify whether the seal L on message M has been closed.

The security achieved by single-use seals means that an attacker cannot find two different messages m1 and m2 such that the Verify function returns true for the same seal.

In short, a single-use seal ensures that a particular asset or data block is only used or locked once. In the context of Bitcoin, this usually means that a UTXO can only be spent once. Therefore, Bitcoin transaction outputs can be viewed as single-use seals, and when an output is used as an input for another transaction, that seal is "broken" or "used."

For assets on Bitcoin, Bitcoin itself acts as the "witness" (w) for the single-use seal. This is because, to validate a Bitcoin transaction, nodes must check whether each input of the transaction references a valid and unused UTXO. If a transaction attempts to double spend an already used UTXO, Bitcoin's consensus rules and the honest node network will reject that transaction.

In simpler terms:

A single-use seal treats any blockchain as a database where we store a commitment to a message and maintain its state as used or unused.

In summary, assets using client-side validation have the following characteristics:

1. Off-chain data storage: The transaction history, ownership, and other relevant data of assets using client-side validation are primarily stored off-chain. This greatly reduces the demand for on-chain data storage and helps enhance privacy.

2. Commitment mechanism: While asset data is stored off-chain, changes or transfers of 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.

3. On-chain witnesses (not necessarily Bitcoin): Although most data and validation occur off-chain, assets using client-side validation can still leverage the underlying blockchain's security by embedding commitments on-chain (proof of publication, transaction ordering).

4. Validation work completed on the client side: Most validation work is done on the user's device. This means that not every node in the network needs to participate in validating each transaction; only the relevant parties need to verify the validity of the transaction.

For those using client-side validated assets, one more point to note:

When conducting asset transactions and validations using client-side off-chain validation, it is necessary to provide not only the private key holding the asset but also the complete Merkle path proof for the corresponding asset.

RGB, The Pioneer of CSV

The concept of RGB was proposed by community figure Giacomo Zucco after 2015. This was a time when Ethereum was rising, ICOs (Initial Coin Offerings) were surging, and many were trying to create projects outside of Bitcoin, such as Mastercoin and Colored Coins.

Giacomo Zucco was disappointed with these developments. He believed that these projects could not match Bitcoin's potential, and previous attempts to implement tokens on Bitcoin were insufficient. During this period, he met Peter Todd and became fascinated by Todd's ideas about client-side validation (CSV). This led him to propose the concept of RGB.

In addition to the characteristics of assets using client-side validation mentioned earlier, the main difference between RGB and early asset protocols is the addition of an execution VM (Virtual Machine) for Turing-complete contract execution. To ensure the security of contract data, Schema and Interface were designed. Schema is similar to Ethereum, declaring the content and functionality of the contract, while Interface is responsible for implementing specific functions, similar to interfaces in programming languages.

The Schema of these contracts is responsible for limiting unexpected behavior during VM execution. For example, RGB20 and RGB21 impose certain restrictions on fungible and non-fungible tokens during transactions.

The commitment mechanism used in RGB, Pedersen Hash

Its advantage lies in the ability to commit value without disclosure. Using Pedersen Hash to construct Merkle trees means you can create a privacy-preserving Merkle tree that can hide its value. This structure is useful in certain privacy-preserving protocols, such as some anonymous cryptocurrency projects. However, it may not be suitable for CSV assets, which will be mentioned later in comparison with Taproot Assets.

Simplified VM Design of RGB → AluVM

RGB's goal is not only to implement a client-side validated asset protocol but also to extend to Turing-complete virtual machine execution and contract programming. Initially, RGB claimed to use a programming language called Simplicity, which generates execution proofs and allows formal verification of contracts written within it (to avoid errors). However, the development of this language did not proceed as planned, leading to complexity that ultimately hindered the overall development of the RGB protocol. Eventually, RGB began using a virtual machine called AluVM, developed by Maxim, which aims to avoid any undefined behavior, similar to the original Simplicity. It is claimed that the new AluVM will eventually be replaced by a programming language called Contractum, rather than the currently used Rust.

RGB Layer2 Scaling Direction: Lightning Network or Sidechains?

Client-side validated assets cannot continuously and securely conduct off-chain transactions because they still rely on L1 for transaction publication and ordering. This means that without a second-layer scaling solution, their transaction speed remains limited by the block production speed of L1 witnesses. This implies that if RGB transactions are conducted directly on Bitcoin, under strict security requirements, the time interval between two related transactions must be at least ten minutes (the BTC block time), which is often unacceptably slow.

RGB and the Lightning Network

In short, the way the Lightning Network operates is by allowing transaction parties to sign a series of contracts (commitment transactions) off-chain. These contracts ensure that if any party violates the agreement, the affected party can submit the contract (commitment transaction) to BTC for settlement, reclaiming their funds and penalizing the violator. In other words, the Lightning Network ensures the security of off-chain transactions through protocol and game-theoretic design.

RGB can build its own Lightning Network infrastructure by designing payment channel contract details suitable for RGB itself. However, due to the high complexity of the Lightning Network, building such infrastructure is not easy, especially considering the years of work Lightning Labs has put into this field and LND's market share of over 90%.

RGB's Sidechain Prime

Currently, the maintainer of the RGB protocol, LNP-BP, released a proposal in June 2023 for a client-side validated asset scaling solution called Prime, proposed by Maxim. Maxim criticized existing sidechain and Lightning Network scaling solutions for being overly complex in the development process. He believes that, apart from Prime, other scaling methods, including NUCLEUS multi-node Lightning channels and Ark/Enigma channel factories, require over two years of development time. However, Prime can be completed within a year.

Prime is not designed as a traditional blockchain. Instead, it is a modular proof publication layer specifically created for client-side validation. It consists of four main components:

1. Timestamp Service: This service can complete a series of transactions in just 10 seconds.

2. Proofs: They are stored in the form of Partial Merkle Trees (PMT) and generated and published along with the block header.

3. Single Use Seals: This is an abstract single-use seal protocol designed to prevent double spending. When implemented on Bitcoin, it can bind to UTXOs, similar to the current RGB design.

4. Smart Contract Protocol: RGB Shard Contracts (fungible)

It can be seen that to address the transaction confirmation time issue in RGB, Prime utilizes a timestamp service to quickly confirm off-chain transactions and packages them with IDs into blocks. At the same time, transaction proofs on Prime can be further integrated through PMT and then anchored on BTC in a checkpoint-like manner.

Taproot-Based CSV Asset Protocol: Taproot Assets

Taproot Assets is a Taproot-based CSV asset protocol for issuing 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 is to leverage Bitcoin's security and stability, as well as the speed, scalability, and low cost of the Lightning Network. The protocol was designed and developed by Roasbeef, the Chief Technology Officer of Lightning 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), with a profound understanding of Bitcoin.

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 ability to execute smart contracts (TapScript). On this basis, the asset encoding of Taproot Assets effectively creates a token definition similar to ERC20 or ERC721. Therefore, Bitcoin not only gained the ability to define assets but also the ability to write smart contracts, laying the foundation for Bitcoin's token smart contract infrastructure.

The encoding structure of Taproot Assets is as follows:

Author: Roasbeef, Chief Technology Officer of Lighting Labs

As a CSV asset protocol, the design of Taproot Assets is simpler than RGB. The biggest difference between Taproot Assets and RGB in terms of application scalability is the execution VM; Taproot Assets uses the same TaprootScript VM as the native default of BTC. In recent years, much of the infrastructure research targeting BTC has been based on TapScript, but due to the slow upgrades of BTC, it cannot be applied in the short term. Therefore, it is foreseeable that Taproot Assets will be a testing ground for these fresh ideas in the future.

Differences Between Taproot Assets and RGB

1. Transaction Validation and Light Node Friendliness

Taproot Assets have high validation efficiency and security due to the implementation of a sum tree structure. It allows for state validation and transactions through possession of proofs without traversing the entire transaction history. In contrast, RGB uses Pedersen commitments, making it difficult to effectively validate the validity of inputs. Therefore, RGB needs to trace the transaction history of inputs, which can become a significant burden over time as transactions accumulate. The design of Merkle and sum trees also enables Taproot Assets to easily facilitate light node validation, a feature that was not available in previously built asset protocols on Bitcoin.

2. Execution Virtual Machine

Taproot Assets were developed for the Taproot upgrade of the Bitcoin network. It utilizes the TaprootScriptVM, which is the script execution engine that came with Bitcoin after the Taproot upgrade. Additionally, it uses a variant of Bitcoin PSBT called vPSBT, indicating that once the Taproot Assets Lightning channel mechanism is developed, it can immediately reuse all existing infrastructure of LND (Lightning Network Daemon), as well as previous products from Lightning Labs (LND currently holds over 90% market share in the Lightning Network). Furthermore, the recently popular BitVM proposal is based on TaprootScript, theoretically meaning that all these improvements will ultimately benefit Taproot Assets.

However, RGB operates somewhat differently. Its virtual machine and validation rules (SCHEMA) are part of an independent system, forming a somewhat closed ecosystem. RGB operates within its own ecosystem, and its relationship with the broader Bitcoin ecosystem is not as closely intertwined as some might imagine. For example, regarding the Taproot upgrade, RGB's only real interaction is to encode submission data into the Witness TapLeaf on the blockchain. This indicates that RGB and the Taproot upgrade only have a minimal degree of association.

3. Smart Contracts

In the current implementation of RGB, contracts and virtual machines are heavily emphasized. However, in Taproot Assets, there seems to be no focus on smart contracts, at least not yet. The current RGB implementation has not explained how modifications to the global state synchronize with individual contract shards (UTXOs). Additionally, while Pedersen commitments can ensure the total amount of assets, it remains unclear how other states will be protected from tampering, as there has not been much explanation on this.

On the other hand, the design of Taproot Assets is simpler, but currently only stores asset balances and does not handle more complex states, making discussions about smart contracts premature. However, according to Lightning Labs, they plan to focus on the smart contract design of Taproot Assets next year.

4. Synchronization Center

The previously mentioned fundamental principles regarding assets using client-side validation indicate that proof of possession is as important as holding the private key. However, since proofs are stored on the client side, there is a risk of loss. How can this issue be addressed? In Taproot Assets, this problem can be avoided by using a "universe." The universe is a publicly auditable sparse Merkle tree that covers one or more assets. Unlike standard Taproot Assets trees, the universe is not used to safeguard Taproot Assets. Instead, it submits a subset of the historical records of one or more assets.

In the RGB system, this role is fulfilled by Storm, which synchronizes off-chain proof data through a peer-to-peer (p2p) network. However, due to historical reasons related to the RGB development team, these teams currently use incompatible proof formats. The RGB ecosystem team DIBA has stated that it will develop "carbonado" to address this issue, but progress remains unclear.

5. Engineering Implementation

All libraries used in Taproot Assets have been well-tested, as Lightning Labs has its own Bitcoin client (BTCD), Lightning Network client (LND), and various wallet library implementations. In contrast, most libraries used for RGB implementation are custom-built. From an industry standards perspective, the implementation of RGB is still in the experimental stage.

A Brief Overview of the Future of Bitcoin Scaling

Continuing the discussion, it is clear that client-side validated asset protocols have surpassed the scope of traditional protocols and are now moving towards computational scaling.

Many claim that in the future, Bitcoin will exist as "digital gold," while other blockchains will create application ecosystems. However, I have a different perspective. As seen in many discussions on Bitcoin forums, there is much talk about various altcoins and their fleeting lifespans. The rapid demise of these altcoins has turned the capital and efforts surrounding them into bubbles. We already have Bitcoin as a solid foundation of consensus, and there is no need to build new first-layer (L1) solutions for application protocols. What we should do is leverage Bitcoin's powerful infrastructure to establish a more long-term decentralized world.

Less On-Chain Computation, More On-Chain Validation

From an application design perspective, the early chosen philosophy of Bitcoin is not computation-centric but validation-centric (the Turing completeness and state of smart contracts). The essence of a blockchain is a replicated state machine. If the consensus of the blockchain is focused on on-chain computation, it is hard to argue that having every node in the network repeat these computations is a reasonable or scalable approach. If the focus is on validation, then validating off-chain transactions may be the most suitable method for Bitcoin scalability.

Where does validation take place? This is crucial.

For developers creating protocols on top of Bitcoin, how to use Bitcoin for key validations, even placing validations off-chain, and how to design secure schemes are issues for protocol designers themselves. They should not and need not be associated with the chain itself. How validation is implemented will lead to different scaling solutions for BTC.

From the perspective of verification-based implementations, we have three scaling directions:

1. On-Chain Validation (OP-ZKP)

Implementing OP-ZKP directly in TaprootScriptVM would give Bitcoin itself the ability to perform ZKP verification. This, combined with some contract design settlement protocols, could create a Zk-Rollup scaling solution inheriting Bitcoin's security. However, unlike deploying verification contracts on Ethereum, Bitcoin's upgrades are inherently slow, and adding such a specialized opcode that may require upgrades is bound to be challenging.

2. Semi-On-Chain Validation (BitVM)

The design of BitVM ensures that it is not designed for ordinary transaction logic. Robin Linus has also stated that the future of BitVM lies in creating a free cross-chain market for various sidechains. The approach of BitVM is considered semi-on-chain because most verification computations do not occur on-chain but off-chain. The important reason for designing around Bitcoin's Taproot is to leverage TapScriptVM for computational verification when necessary, theoretically inheriting Bitcoin's security. This process also generates a verification trust chain, such that only one honest verifier is needed among "n" verifiers, known as optimistic rollups.

BitVM will generate significant on-chain overhead, but can it use ZK fraud proofs to improve efficiency? The answer is no, as the implementation of ZK fraud proofs relies on the ability to perform ZKP verification on-chain, which brings us back to the challenges of the OP-ZKP approach.

3. Off-Chain Validation (Client-Side Validation, Lightning Network)

Fully off-chain validation refers to the CSV asset protocols and Lightning Network discussed earlier. As seen in the previous discussion, we cannot completely prevent collusion in the CSV design. What we can do is use cryptography and protocol design to control the damage caused by malicious collusion within manageable limits, making such behavior unprofitable.

The advantages and disadvantages of off-chain validation are equally evident. Its advantage is that it uses minimal on-chain resources and has tremendous scalability potential. The downside is that it is nearly impossible to fully inherit Bitcoin's security, which greatly limits the types and methods of off-chain transactions that can be conducted. Additionally, off-chain validation also means that data preservation is off-chain, managed by users themselves, which raises higher requirements for the security of the software execution environment and the stability of the software.

Trends in Scaling Evolution

Currently popular Layer 2 solutions on Ethereum, from a paradigm perspective, all verify Layer 2 computations through Layer 1, meaning that state computations are pushed to Layer 2, but validation remains on Layer 1. In the future, we can similarly place verification computations into off-chain calculations, further releasing the performance of the current blockchain infrastructure.