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

Original Author: Ben77

Original Translation: Kate, Mars Finance

Preface

The issuance of assets based on Bitcoin has always been a hot topic. From the earliest Colored Coins in 2011 to the recent popular Ordinal protocol, the BTC community has been able to propose new participants and consensus, but few have persisted. However, the Lightning Labs has announced ambitious plans to develop stablecoins based on Taproot Assets. Tether also announced that it will use the RGB protocol to mint USDT on the first layer of Bitcoin.

This means that the once-famous OmniLayer (formerly Mastercoin) is no longer the biggest player in the BTC ecosystem. Client-side validation (CSV) asset protocols are beginning to enter everyone's field of vision. These protocols both maintain the integrity of traditional Bitcoin asset protocols and enhance scalability. However, a series of asset protocols in the Bitcoin ecosystem have raised related questions: how are they different from each other, and how should people navigate and seize opportunities in this field?

This article aims to guide readers to comprehensively review the various asset protocols that have appeared in the history of Bitcoin. In addition, it also attempts to delve into the potential trajectory of the development of Bitcoin-based asset protocols in the foreseeable future.

Colored Coins

The concept of colored coins was first proposed by eToro's current CEO Yoni Assia in a groundbreaking article "bitcoin 2.X (aka Colored bitcoin)" published on March 27, 2012. This article argued that the underlying technology of Bitcoin is as fundamental and perfect as HTTP on the Internet. Therefore, the colored coin token protocol is designed based on 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 the underlying technology of Bitcoin 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 urgent question is how this idea can be implemented on the Bitcoin network.

On July 3, 2014, ChromaWay took a significant step by developing the Enhanced Colored Coins based on Order-based protocol (EPOBC), greatly 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 concise, but it also brings many problems:

1. The issue of fungibility and minimum binding value is addressed by binding 1000 satoshis to a colored coin in the genesis transaction, making the minimum unit of this colored coin 1 satoshi. This means that the asset or token can theoretically be divided into a maximum of 1000 units (but in practice, it will be lower to prevent dust attacks). For example, the minimum satoshi value was once set at 546 satoshis, 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 are required.

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

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 from the asset source. This means that verifying the validity of transactions may require a long proof chain. To address this issue, proposals such as OP_CHECKCOLORVERIFY have been put forward to help verify colored coin transactions directly on BTC, but this proposal has not been 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 whitepaper titled "The Second Bitcoin Whitepaper," outlining the idea of creating new assets or tokens based on 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, successfully raising millions of dollars. This is considered the first ICO in history. One of the most notable applications of Mastercoin is Tether (USDT), which is a well-known fiat-collateralized stablecoin initially issued on the Omni Layer.

In fact, the idea of Mastercoin predates colored coins. The second reason we discuss it is that, compared to colored coins, MasterCoin is a relatively more comprehensive solution. MasterCoin established a complete node layer, providing more complex features such as smart contracts. In contrast, colored coins are simpler, more direct, and primarily focused 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 and does not store related 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. In addition, because it does not record or verify the state on the blockchain, its transactions do not require continuity (continuous coloring).

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

In summary:

The main difference between Mastercoin and colored coins is that Mastercoin does not maintain all the data required for the protocol on the blockchain. Instead, it relies on Bitcoin's consensus system to manage its own transaction publication and ordering, and then maintains the state in an off-chain database.

Based on the information provided by OmniBolt: Omni Layer is proposing a new UTXO-based asset protocol to Tether, which will utilize the Taproot upgrade. This protocol will embed asset information into Tapleaf, enabling conditional payments and integrating Stark into the Lightning Network infrastructure of the Omni Layer.

Concept of Client-Side Validation

To understand the concept of Client-Side Validation (CSV), we need to go back to the year after the appearance of Colored Coins and Mastercoin, which is 2013. In that year, early Bitcoin and cryptography 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 careful reading reveals that this is one of the earliest articles to introduce this concept.

Peter Todd has been looking for ways to improve the efficiency of Bitcoin operations. He developed a more complex concept of client-side validation based on the idea of timestamps. 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 believed 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 bitcoins to Bob, even though she has signed a transaction to transfer to Bob, Bob may not physically know about the existence of such a transaction. Therefore, we need a public place to publish transactions where everyone can query transactions from.

2. Order consensus: In computer systems, the physical time we experience does not exist. In distributed systems, time is usually Lamport timestamps, which do not provide a measure of our physical time but rather order our transactions.

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

At this point, you may recall our previous discussion of the OmniLayer. The OmniLayer itself does not delegate state computation and validation to Bitcoin, but it does reuse Bitcoin's security. On the other hand, Colored Coins delegates state tracking to Bitcoin. The existence of these two systems has proven that validation does not necessarily have to be done 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)
• Verify that the input (TxIn) is valid to prevent double spending.

It is easy to notice that for assets issued on Bitcoin, every transaction requires validation of the entire related transaction history to ensure that the referenced input has not been spent and the state is correct. This is very impractical. So, how do we improve this?

Peter Todd suggested that we can simplify this process by changing the focus of validation. This approach does not confirm that the output has not been double spent, but instead focuses on ensuring that the transaction's inputs have been published and do not conflict with other inputs. This type of validation can be more efficient by sorting inputs in each block and using a Merkle tree, as it only requires a small amount of data each time, rather than the entire chain history of the input.

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

CTxIn -> CTxOut -> merkle path> -> CTransaction -> merkle path> -> 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 to understand CSV. It is similar to a single-use seal used to secure cargo containers. A single-use seal is a unique object that can precisely close once on a message. In simple terms, a single-use seal is an abstract mechanism used to prevent double spending.

For the SealProtocol, there are three elements and two operations.

Basic elements:

• L: Seal
• M: Message, i.e., information or transaction
• W: Entity or object that can verify the seal

Basic operations: There are two basic actions:

• Close(l, m)→w: Close seal L on message M, producing witness W.
• Verify(l, w, m)→bool: Verify if 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 for which the Verify function returns true for the same seal.

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

For assets on Bitcoin, Bitcoin itself acts as the "witness" for the single-use seal. This is because to validate Bitcoin transactions, nodes must check if each input of the transaction references a valid and unspent UTXO. If a transaction attempts to double spend a UTXO, Bitcoin's consensus rules and the honest node network will reject the transaction.

In simpler terms:

Single-use seals treat any blockchain as a database where we store commitments to a message and maintain its state as used or unused.

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

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

2. Commitment mechanism: Although 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 witness (not necessarily Bitcoin): While most data and validation occur off-chain, assets using client-side validation can still leverage the security of the underlying blockchain (proof of publication, transaction ordering) by embedding commitments on-chain.

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

For those using assets with client-side validation, it is important to note that when conducting asset transactions and validation using client-side off-chain validation, not only the private key holding the asset needs to be provided, but also the complete Merkle path proof for the corresponding asset.

RGB, Pioneer of CSV

The concept of RGB was proposed by the well-known community figure Giacomo Zucco after 2015. This was during the rise of Ethereum, with a surge in Initial Coin Offerings (ICOs), and many people attempting to create projects outside of Bitcoin, such as Mastercoin and Colored Coins.

Giacomo Zucco was disappointed with these developments. He believed that these projects were unable to match the potential of Bitcoin, and the previous attempts to implement tokens on Bitcoin were insufficient. During this time, he encountered 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 Virtual Machine (VM) for Turing-complete contract execution. To ensure the security of contract data, Schemas and Interfaces were designed. Schemas are similar to Ethereum, declaring the content and functionality of contracts, while Interfaces are responsible for implementing specific functionality, similar to interfaces in programming languages.

These contracts' Schemas are responsible for restricting unexpected behavior during VM execution. For example, RGB20 and RGB21 are responsible for imposing certain restrictions on fungible and non-fungible tokens during the transaction process, respectively.

The commitment mechanism used in RGB, Pedersen Hash, has the advantage of being able to commit to value without revealing it publicly. Using Pedersen Hash to construct a Merkle tree means that you can create a privacy-protecting Merkle tree that hides its value. This structure is useful in some privacy-preserving protocols, such as some anonymous cryptocurrency projects. However, it may not be suitable for CSV assets, as will be mentioned later in comparison with Taproot Assets.

The simplified Virtual Machine design in RGB, called AluVM, aims not only to implement a client-side validation 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 the contracts written in it (to avoid errors). However, the development of this language did not proceed as planned, leading to complexity that ultimately hindered the development of the entire RGB protocol. Eventually, RGB began using a virtual machine called AluVM, developed by Maxim, with the goal of avoiding any undefined behavior, similar to the original Simplicity. It is claimed that the new AluVM will be replaced by a programming language called Contractum, instead of the current Rust.

RGB's Layer2 scaling direction: Lightning Network or sidechains?

Assets using client-side validation cannot sustainably conduct off-chain transactions securely, as they still rely on L1 for transaction publication and ordering. This means that without a Layer 2 scaling solution, their transaction speed is still limited by the block production speed of L1 witnesses. This means that if RGB transactions were directly conducted on Bitcoin, under strict security requirements, the time interval between two related transactions would need to be at least ten minutes (BTC's block time), which is often unacceptably slow.

RGB and the Lightning Network

In summary, the Lightning Network operates by having the parties to a transaction sign a series of contracts (commitment transactions) off-chain. These contracts ensure that if any party violates the protocol, the injured party can submit the contract (commitment transaction) to settle with BTC, reclaim their funds, and penalize the violator. In other words, the Lightning Network ensures the security of off-chain transactions through protocol and game theory 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 by the Lightning Labs in this field and LND's over 90% market share.

RGB's sidechain Prime

The maintainers of the RGB protocol, LNP-BP, proposed a client-side validation asset scaling solution called Prime, put forward by Maxim in June 2023. In the article, Maxim criticized the existing sidechain and Lightning Network scaling solutions for being overly complex during development. He believed that, apart from Prime, other scaling methods, including the NUCLEUS multi-node Lightning channel and the Ark/Enigma channel factory, would require more than two years of development. However, Prime could 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 parts:

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 together with block headers.
3. Single-use seals: This is an abstract single-use seal protocol designed to prevent double spending. When implemented on Bitcoin, it can be bound to UTXOs, similar to the current RGB design.
4. Smart contract protocol: RGB shard contracts (replaceable)

It can be seen that to address the transaction confirmation time issue in RGB, Prime uses the 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.

Based on Taproot, CSV asset protocol: Taproot Assets

Taproot Assets is a CSV asset protocol based on Taproot 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 the security and stability of Bitcoin, 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 this planet who has personally led the development of the Bitcoin client (BTCD) and the Lightning Network client (LND), and he has a deep understanding of Bitcoin.

Taproot transactions only carry the root hash of asset scripts, 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). Based on this, the asset encoding of Taproot Assets actually creates a token definition similar to ERC20 or ERC721. Therefore, Bitcoin not only gained the ability to define assets but also gained 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 Lightning Labs

Similarly, as a CSV asset protocol, the design of Taproot Assets is more concise than RGB. The biggest difference between Taproot Assets and RGB in terms of application scalability lies in the execution VM. Taproot Assets use the TaprootScript VM, which is the native default script execution engine that comes with Bitcoin. In recent years, much of the infrastructure research for Bitcoin has been based on TapScript, but due to the slow upgrade of Bitcoin, it cannot be applied in the short term. Therefore, it can be foreseen that Taproot Assets will be the testing ground for these fresh ideas in the future.

Differences between Taproot Assets and RGB

1. Transaction verification and lightweight node friendliness

Taproot Assets, due to the implementation of a sum tree structure, has high verification efficiency and security. It allows for state verification and transactions through proofs without the need to traverse the entire transaction history. In contrast, RGB's use of Pedersen commitments makes it difficult to efficiently verify the validity of inputs. Therefore, RGB needs to trace the transaction history of inputs, which could become a significant burden over time and with the accumulation of transactions. The design of Merkel sum tree allows Taproot Assets to easily facilitate lightweight node verification, a feature that was not available in asset protocols built on top of Bitcoin previously.

2. Execution Virtual Machine

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

However, the operation of RGB is somewhat different. 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 may imagine. For example, the only real interaction of RGB with the Taproot upgrade is encoding commitment data into Witness TapLeaf on the blockchain. This indicates that there is only minimal association between RGB and the Taproot upgrade.

3. Smart contracts

In the current implementation of RGB, contracts and virtual machines are emphasized. However, in Taproot Assets, there seems to be no focus on smart contracts, at least not currently. The current implementation of RGB has not explained how modifications to the global state are synchronized with individual contract shards (UTXOs). Additionally, while Pedersen commitments can ensure the total amount of assets, it is unclear how other states will be protected from tampering, as there is not 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 it too early to discuss smart contracts. However, according to Lightning Labs, they plan to focus on the smart contract design of Taproot Assets next year.

4. Synchronization center

The basic principle mentioned earlier about client-side validation of assets indicates that holding proofs is as important as holding private keys. However, since proofs are stored on the client, there is a risk of loss. How is this problem addressed? In Taproot Assets, this can be avoided by using a "universe." The universe is a publicly auditable sparse Merkle tree that covers one or more assets. Unlike the standard Taproot Assets tree, the universe is not used to custody Taproot Assets. Instead, it commits to a subset of the history 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 associated with the RGB development team, these teams currently use incompatible proof formats. The RGB ecosystem team DIBA has stated that they will develop "carbonado" to address this issue, but its progress is not clear.

5. Engineering implementation

All libraries used by 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 of the libraries used for the RGB implementation are custom. From an industry standard perspective, the implementation of RGB is still in the experimental stage.

Brief introduction to the future of Bitcoin scalability

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

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

Less on-chain computation, more on-chain verification

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

Where does verification take place? This is crucial.

For developers creating protocols on top of Bitcoin, how to use Bitcoin for critical verification, even placing verification off-chain, and how to design secure schemes are the concerns of the protocol designers themselves. They should not and do not need to be associated with the chain itself. How verification 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 verification (OP-ZKP)

Directly implementing OP-ZKP in TaprootScriptVM will give Bitcoin itself the ability to perform ZKP verification. This, along with some contract settlement protocol designs, can create an extension solution of Zk-Rollup that inherits the security of Bitcoin. However, unlike deploying verification contracts on Ethereum, the upgrade of Bitcoin itself is slow, and adding a specialized opcode that may require an upgrade is inevitably challenging.

2. Semi on-chain verification (BitVM)

The design of BitVM ensures that it is not designed for regular transaction logic. Robin Linus 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, as most of the verification computations do not occur on-chain, but rather off-chain. The significant reason for designing around Bitcoin's Taproot is to utilize TapScriptVM for computational verification when necessary, theoretically inheriting the security of Bitcoin. This process also generates a chain of trust for verification, such as requiring only one honest validator out of "n" validators, known as Optimistic Rollups.

BitVM would incur significant on-chain expenses, but can it improve efficiency using ZK fraud proofs? The answer is negative, 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 verification (client-side validation, Lightning Network)

Fully off-chain verification refers to the CSV asset protocol and the Lightning Network discussed earlier. As seen in the previous discussion, we cannot completely prevent collusion in CSV designs. 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 verification are equally apparent. Its advantage is the use of minimal on-chain resources and has enormous potential for scalability. The disadvantage is that it is almost impossible to fully inherit the security of Bitcoin, which greatly limits the types and methods of off-chain transactions that can be conducted. Additionally, off-chain verification also means that data storage is off-chain, managed by the users themselves, which places higher demands on the security and stability of the software execution environment.

Trends in scalability evolution

Currently, popular Layer 2 solutions on Ethereum, in terms of paradigm, all verify Layer 2 computations through Layer 1, which means that state computation is pushed to Layer 2, but verification remains in Layer 1. In the future, we can similarly move verification computations to off-chain computing, further unleashing the performance of the current blockchain infrastructure.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。