Off-chain Transfer The Evolution of Bitcoin Asset Protocols

The Evolution of Bitcoin Asset Protocols Off-Chain Transfers

Author: Ben77, Source: Mirror

Introduction

Asset issuance based on BTC has always been a hot topic. From the early appearance of Colored Coins in 2011 to the recent hype around the Ordinal protocol, the BTC community always manages to bring forth new players and consensus, but only a few manage to survive. However, with the ambitious announcement from Lightling Labs about building a Stable Coin on top of Taproot Assets, and Tether announcing their choice to use RGB for minting USDT on the Bitcoin layer, things are changing.

This represents a shift in the BTC ecosystem, where once popular OmniLayer (Mastercoin) is no longer the biggest player. Client-side validation (CSV) asset protocols are entering the spotlight, bringing with them the added feature of scalability to BTC. But faced with such a variety of asset protocols within the BTC ecosystem, one cannot help but wonder: what are their differences, and how do we choose and find opportunities within this multitude of asset protocols? This article hopes to take everyone on a journey through the history of asset protocols in BTC and explore the future of BTC asset protocol development.

Colored Coins: The Beginning

The idea of Colored Coins was first proposed by Yoni Assia, now CEO of eToro, in an article titled “bitcoin 2.X (aka Colored bitcoin)” written on March 27, 2012. The article acknowledged Bitcoin as a perfect underlying technology, just like HTTP is the foundation of the internet. Therefore, on top of the reusability of BTC, Assia designed the Colored Coins token protocol.

Assia aimed to create an economy for BTC 2.0 where any community could create multiple currencies using this method. This approach, using Bitcoin as a foundational technology for clearing transactions and avoiding double spending, was indeed a bold idea at that time.

Colored Coins, as a protocol for issuing assets based on Bitcoin, involves “coloring” a certain amount of Bitcoin to represent these assets. Functionally, these colored Bitcoins are still Bitcoin, but they also represent another asset or value. But how is this idea implemented on Bitcoin?

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

The end result was as shown in the following image:

This implementation was simple, but it also brought about many problems:

1. Homogeneous tokens and minimum binding value

If a colored coin is bound to 1000 satoshis in the genesis transaction, the minimum divisible unit of that colored coin would be 1 satoshi. This means that the asset or token can be divided or distributed into a maximum of 1000 units (in theory, as a prevention against dust attacks, such as when the satoshis were set at 546 SAT initially, and later increased with ordinal).

2. Validation issue

In order to verify the authenticity and ownership of colored coins, it is necessary to trace the asset’s genesis transaction to the current UTXO. Therefore, a specialized wallet with a matching full node, or even a browser, needs to be developed.

3. Potential miner surveillance risk

Due to the distinctive features of ColoredTransaction, which writes metadata information in the output, it opens up the possibility of miner surveillance.

Colored coins are essentially an asset tracking system that uses Bitcoin’s validation rules to track asset transfers. However, in order to prove that any specific output (txout) represents a certain asset, a complete chain of transfers from the asset’s origin to the present needs to be provided. This means that verifying the legitimacy of a transaction may require a long chain of proofs. To address this issue, there was a proposal for OP_CHECKCOLORVERIFY to directly verify the correctness of Colored Coins transactions on BTC, but it did not pass.

The first ICO in the cryptocurrency industry: Mastercoin

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

Mastercoin conducted an initial token sale in 2013 (which we now refer to as an ICO or Initial Coin Offering) and successfully raised millions of dollars, making it considered the first ICO in history. The most famous application of Mastercoin is Tether (USDT), the most well-known fiat-backed stablecoin, which was initially issued on the Omni Layer.

In fact, the idea of Mastercoin predates Colored Coins, but it is mentioned second here because compared to Colored Coins, MasterCoin is a relatively more complex solution. MasterCoin established a complete node layer, providing more advanced functionalities such as smart contracts, while Colored Coins is simpler and more direct, focusing primarily on “coloring” or tagging Bitcoin UTXOs to represent other assets.

The biggest difference from Colored Coins is that in the Mastercoin chain, various types of transaction behaviors are published, but related asset information is not recorded. In Mastercoin nodes, a state model database is maintained by scanning Bitcoin blocks offline.

Compared to Colored Coins, its logic is more complex. And since it does not record and verify states on the chain, transactions can be non-sequential (continuous coloring).

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

Summary

The biggest difference between Mastercoin and Colored Coins is that it did not choose to maintain all the necessary data for the protocol on the chain, but instead achieved its own transaction publishing and ordering by parasitizing Bitcoin’s consensus system, while maintaining the state in an offline 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 conditional payments and other functionalities. At the same time, OmniBolt is introducing Stark into Omni Layer’s Lightning Network infrastructure.

Client Side Validation Concept

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

Peter Todd is an early researcher in Bitcoin and cryptography, constantly seeking more efficient ways to make Bitcoin work. He developed a more complex concept of client side validation based on the concept of timestamping. In addition, he introduced the concept of “single use seal,” which will be mentioned later.

Now, following Peter Todd’s thinking, let’s first understand what BTC actually solves. In Peter Todd’s view, BTC 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, although she signs a transaction to transfer to Bob, Bob may not physically be aware of the existence of this transaction. Therefore, we need a public place to publish transactions, and everyone can query the transactions from there.

2. Order Consensus

In computer systems, there is no such thing as physical time that we usually perceive. In a distributed system, the time is usually a distributed clock called Lamport clock, which is not a measurement of physical time but a sequence for our transactions.

3. Validation (optional)

Validation on BTC is about signature and BTC transfer amount. However, Peter Todd believes that this validation is unnecessary for building a token system on top of BTC, and it is just an optimization option.

At this point, you might have already thought of the previously mentioned OmniLayer. OmniLayer itself does not delegate the computation of state and validation to BTC, but it reuses the security of BTC. Colored Coins delegates the tracking of state to BTC. The existence of these two has proven 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:

Status (transaction logic validation)
Validity of inputs (preventing double-spending)

It is easy to see that for assets published on BTC, each transaction needs to validate the entire relevant transaction history to ensure that the referenced inputs have not been spent and the state is correct. This is highly impractical, 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 input of a transaction has been published and does not conflict with other inputs. By sorting the inputs in each block and using a Merkle tree, this verification can be done more efficiently, as each verification only requires a small portion of data instead of the entire transaction history of that input.

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

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

But how can we store such a commitment tree on the blockchain? This is where the concept of a single use seal comes into play.

Single Use Seal

The single use seal is one of the core concepts of understanding client verification, similar to the physical, one-time use seals used to protect shipping containers in the real world. The single use seal is a unique object that can only be closed once on a message. In short, the single use seal is an abstract mechanism used to prevent double spending.

For SealProtocol, there are three elements and two actions:

Basic elements:

l: seal
m: message
w: witness

Basic operations:

Close(l, m) → w: closes seal l on message m, generating a witness w.
Verify(l, w, m) → bool: verifies if seal l has been closed on message m.

The implementation of the single use seal ensures that it is not possible for an attacker to find two different messages m1 and m2 and make the Verify function return true for the same seal.

Firstly, a single use seal is a concept that ensures that an asset or data is only used or locked once. In the context of Bitcoin, this usually means that an unspent transaction output (UTXO) can only be spent once. Therefore, the outputs of Bitcoin transactions can be seen as single use seals, and when these outputs are used as inputs 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, in order to validate a Bitcoin transaction, nodes must check if each input of the transaction references a valid and unspent UTXO. If a transaction attempts to double spend a UTXO that has already been used, the consensus rules of Bitcoin and honest nodes in the network will reject that transaction.

Can it be any simpler?

A single use seal treats any blockchain as a database, where we store the commitment of a certain message in a specific way and maintain its state as either consumed or pending.

Yes, it’s that simple.

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

Off-chain data storage: The transaction history, ownership, and other related data of the assets verified by the client are mostly stored off-chain. This greatly reduces the data storage requirements on the blockchain and helps enhance privacy.
Commitment mechanism: Although the asset data is stored off-chain, any changes or transfers of this data are recorded on the blockchain through commitments. These commitments allow blockchain transactions to reference the off-chain state, ensuring the integrity and immutability of off-chain data.
On-chain witnesses (not necessarily BTC): Although most data and verification happen off-chain, the assets verified by the client can still leverage the security of the underlying blockchain (proof of publication, transaction ordering) through embedded commitments on the blockchain.
Verification done on the client-side: Most of the verification work is done on the user’s device. This means that not all nodes in the network need to participate in verifying every transaction. Only the involved parties need to validate the transaction’s validity.

For those using assets verified by clients, there is one thing to note:

When engaging in off-chain transactions and verifying assets verified by clients, not only the private keys for the held assets must be provided but also the complete Merkle path proof corresponding to the assets.

The pioneer of client-side verification (CSV): RGB

The concept of RGB was proposed by a well-known figure in the community, Giacomo Zucco, after 2015. Due to the rise of Ethereum and the proliferation of ICOs, as well as various attempts to do something outside of Bitcoin like the Mastercoin and Colored Coins projects before ICOs.

Giacomo Zucco expressed disappointment with these projects. He believed that they were inferior to Bitcoin, and he also believed that the methods used to implement tokens on Bitcoin before were inappropriate. In this process, he came across Peter Todd and became fascinated with Peter Todd’s idea of client-side validation. This led to the conception of RGB.

In addition to the characteristics mentioned before, RGB’s biggest difference from previous asset protocols is the addition of an executing virtual machine (VM) as a Turing-complete contract execution engine. To ensure the security of contract data, RGB also designed Schemas and Interfaces. Schemas, similar to Ethereum, declare the content and functionality of the contracts, while Interfaces are responsible for the implementation of specific functionalities, similar to interfaces in programming languages.

These schema contracts are responsible for limiting unexpected behavior during VM execution, such as RGB20 and RGB21, which respectively impose certain restrictions on homogeneous tokens and non-fungible tokens in transactions.

RGB’s commitment mechanism: Pedersen Hash

In terms of commitment mechanism, RGB uses Pedersen Hash. Its advantage is that it can commit to a value without revealing it. Using Pedersen Hash to construct a Merkle tree means that you can create a privacy-protecting 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. But perhaps 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-validated asset protocol, but also to extend it to Turing complete virtual machine execution and contract programming. In the early design of RGB, it claimed to use a programming language called Simplicity, which generates an execution proof when executing expressions and makes it easier to formally verify the contracts written in it (to avoid bugs). However, the development of this language was not ideal and it ended up in a dilemma. This ultimately led to the difficulties faced by the entire RGB protocol at that time. Finally, RGB started using a VM called AluVM, developed by Maxim, with the aim of avoiding any undefined behavior, similar to Simplicity. The new AluVM is said to use a programming language called Contractum to replace Rust, which is currently being used.

RGB Layer 2 Scaling Direction: Lightning Network or Sidechains?

Client-validated assets cannot be continuously traded off-chain without ensuring security. Because client-validated assets still depend on L1 for transaction publishing and ordering, without L2 scaling solutions, their transaction speed will still be limited by the block production speed of their L1 witnesses. This means that if RGB transactions are directly conducted on Bitcoin, under strict security requirements, the maximum time interval between two related transactions would be ten minutes (Bitcoin’s block time). Undoubtedly, such transaction speed is often unacceptable.

RGB and Lightning Network

In simple terms, the Lightning Network is a protocol where the parties involved in a transaction sign a set of contracts (commitment transactions) off-chain, which are used to ensure that if either party violates the contract, the aggrieved party can submit the contract (commitment transaction) to settle with Bitcoin, retrieve their funds, and penalize the other party. In other words, the Lightning Network ensures the security of off-chain transactions through protocol and game design.

RGB can build its own Lightning Network infrastructure by designing payment channel contract rules suitable for RGB itself. However, the Lightning Network is highly complex, and building such infrastructure is not an easy task. But compared to Lightning Labs, who have been working in this field for many years and LND occupying over 90% of the market share, it is relatively easier.

RGB’s Sidechain: Prime

As the current maintainer of the RGB protocol, Maxim proposed a client-validated asset scaling solution called Prime in June 2023 and criticized the existing sidechain and Lightning Network scaling solutions for being too complex in terms of development. Maxim stated that besides Prime, other expansion methods include NUCLEUS multi-node Lightning channels and Ark/Enigma channel factories, both of which require over two years of development. But 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. It consists of four parts:

Timestamp service: Finalizes a transaction sequence in as fast as 10 seconds.
Proof: Stored and produced in PMT form along with block headers.
One-time sealing: An abstract single-sealing protocol that ensures prevention of double-spending. If implemented on Bitcoin, it can be bound to UTXOs, similar to the current RGB design.
Smart contract protocol: Sharded contract-RGB (replaceable)

From this, we can actually see that Prime uses a timestamp service to quickly confirm off-chain transactions and include them in blocks in order to solve the issue of confirmation time for RGB transactions. At the same time, the transaction proofs on Prime can be further anchored to BTC in a similar checkpoint manner after being merged through PMT.

Taproot Assets: CSV Asset Protocol based on Taproot

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 high volume, and at low fees through the Lightning Network. The core of Taproot Assets lies in leveraging the security and stability of the Bitcoin network, as well as the speed, scalability, and low fees of the Lightning Network. This protocol was designed and developed by roasbeef, the CTO of Lightning Labs. Roasbeef is possibly the only person on this planet who has personally led the development of both a Bitcoin client (BTCD) and a Lightning Network client (LND), making him extremely knowledgeable about BTC.

Taproot transactions only carry the root hash of asset scripts, making it difficult for external observers to determine if Taproot Assets are involved, as the hash itself is generic and can represent any data. With the Taproot upgrade, Bitcoin gained the ability for smart contracts (TapScript). Based on this, the asset encoding of Taproot Assets is equivalent to creating a token definition similar to ERC20 or ERC721. Therefore, Bitcoin not only has the functionality of asset definition but also the ability to write smart contracts, laying the foundation for token smart contract infrastructure for Bitcoin.

The encoding structure of Taproot Assets is as follows:

Image from Lightning Labs CTO roasbeef

As a CSV asset protocol, Taproot Assets are more streamlined compared to RGB’s design. They make the most of the current progress 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 virtual machine (VM). Taproot Assets use the same TaprootScriptVM as BTC’s native default. In recent years, many infrastructure research projects for BTC have been based on TapScript. However, due to the slow upgrade of BTC, these ideas have not been applied in a short period of time. It can be foreseen that Taproot Assets will be the testing ground for these fresh ideas.

What are the differences between Taproot Assets and RGB?

1. Transaction Verification and Light Node-Friendliness

Due to the implementation of sum tree, Taproot Assets have high verification efficiency and security (verification of state and transaction can be done with only possession proofs, without traversing all input transaction history). RGB’s use of Pedersen commitments makes it inefficient to verify the validity of inputs, requiring RGB to trace the transaction history of inputs, which will become a heavy burden as transactions grow. The design of Merkel sum also allows Taproot Assets to easily achieve light node verification, which is non-existent in previous asset protocols built on BTC.

2. Execution Virtual Machine (VM)

Taproot Assets were born with the Taproot upgrade, and their TaprootScriptVM is the script execution engine native to Bitcoin after the Taproot upgrade. The vPSBT used is a version of Bitcoin’s PSBT, which means that once the Lightning channel mechanism of Taproot Assets is developed, all current LND infrastructure can be immediately reused, as well as previous Lightning Labs products (LND holds over 90% of the Lightning Network’s market share). Moreover, the recent popular BitVM proposal is based on TaprootScript, so theoretically all these improvements can ultimately benefit Taproot Assets.

However, for RGB, its VM and validation rules (SCHEMA) are unique systems in themselves, to some extent creating a relatively closed small ecosystem. RGB constructions can only operate within their own ecosystem, and their relationship with the Bitcoin ecosystem is not as closely intertwined as one might imagine. Taking the example of the Taproot upgrade, the only relationship between RGB and Taproot upgrade is encoding the on-chain commitment data into the TapLeaf of the Witness.

3. Smart Contracts

In the current implementation design of RGB, contracts and VM are heavily emphasized. However, in Taproot Assets, the presence of smart contracts has not been seen temporarily. However, it has not been explained how the synchronization between the modification of the current Global State in RGB and the various independent contract shards (UTXOs) is achieved. Moreover, Pedersen commitments can only guarantee the total number of assets, and there are currently no further explanations on how to ensure the identification of tampering with other states. As for Taproot Assets, although the design is simple, there are currently only asset balances stored as states, without any additional states, so smart contracts cannot be discussed at the moment. However, according to Lightning Labs, Taproot Assets will focus on smart contract design next year.

4. Synchronization Center

From the principles of asset verification mentioned earlier, it can be understood that holding Proof and holding private keys are equally important, but if Proof is constantly stored in the user’s client, it may be easily lost. So what do we do in such cases? In Taproot Assets, we can avoid this problem by using the universe. The universe is a publicly auditable (MS-SMT) structure that covers one or more assets. Unlike ordinary Taproot asset trees, the universe is not used to host Taproot assets. Instead, the universe commits to a subset of the history of one or more assets.

In RGB, Storm is responsible for this part and will synchronize and store off-chain proof data through p2p, but due to the historical reasons of the RGB development team, the proof formats of these teams are currently incompatible with each other. The RGB ecosystem team DIBA currently states that they will develop carbonado to solve this problem, but the progress is not clear yet.

5. Engineering Implementation

All the libs used in Taproot Assets have been well-tested because Lightning Labs has its own Bitcoin client (BTCD), Lightning Network client (LND), and a large number of wallet libs implementations. On the other hand, most of the libs used in RGB implementation are self-defined, and from an industrial standard perspective, the implementation of RGB is still in the experimental stage.

A Brief Discussion on the Future of BTC Scalability

So far, we have realized that asset protocols for client verification have moved beyond the protocol scope and are heading towards computational scalability.

Many people say that in the future, Bitcoin will exist as digital gold, while other chains will build application ecosystems. However, I have a different perspective on this. Just like many discussions on altcoins and their short-lived lives on Bitcoin forums. The rapid demise of these altcoins has turned the capital and efforts once surrounding them into bubbles. We already have Bitcoin, which has a strong consensus foundation, so there is no need to build new L1s for application protocols. What we need to do is to make good use of the strongest infrastructure of Bitcoin and build a longer-lasting decentralized world.

Less On-Chain Computation, More On-Chain Validation

From an application design perspective, Bitcoin chose early on to prioritize validation over on-chain computation, embracing a design philosophy centered around Turing completeness and state for smart contracts. Blockchain is essentially a replicated state machine, and if a chain’s consensus relies on on-chain computation, it becomes difficult to argue that requiring all network nodes to replicate these computations is a reasonable and scalable approach. On the other hand, if validation is prioritized, then a solution that focuses on validating the off-chain transaction’s validity might be the most suitable for scaling BTC.

Where Does Validation Happen? It’s Important!

For protocol developers building on top of Bitcoin, how to use Bitcoin for crucial validation, even placing validation off-chain, and how to design secure solutions are all matters for the protocol designers themselves, and they should not be associated with or dependent on the underlying chain. How to achieve validation will, therefore, give rise to different scalability approaches for BTC.

From the perspective of validation implementation, we have three scaling directions:

On-Chain Validation (OP-ZKP)

If OP-ZKP is directly implemented in TaprootScriptVM, it would mean that BTC itself gains the ability to incorporate ZKP validation. In combination with some Covenant settlement protocols, this could create a Zk-Rollup scalability solution that inherits BTC’s security. However, unlike deploying a validation contract on Ethereum, BTC’s own upgrades are slow, and incorporating non-general and potentially upgrade-requiring op-codes like this proves to be arduous.
Half-On-Chain Validation (BitVM)

The design of BitVM suggests that it is not intended for ordinary transactional logic. Robin Linus also made it clear that BitVM’s future lies in serving as a free cross-chain market for various SideChains. When we say that BitVM’s solution is half-on-chain, it means that most of the time, these validation computations would not occur on-chain but rather off-chain. However, the important reason for designing around BTC’s Taproot is to enable the use of TapScriptVM for computing validation when necessary, thus theoretically inheriting BTC’s security. This process also creates a trust chain for validation, such as requiring only one honest validator among n validators, known as Optimistic Rollups.

BitVM incurs significant on-chain costs, but can ZK fraud proofs be used to improve efficiency? The answer is no because implementing ZK fraud proofs relies on the on-chain capability for ZKP validation, which brings us back to the dilemma of the OP-ZKP solution.
Off-Chain Validation (Client-Side-Validation, Lightning Network)

If validation occurs entirely off-chain, that refers to the previously discussed CSV asset protocols and the Lightning Network. In the previous discussions, we can see that in the design of CSV, it is impossible to completely eliminate the occurrence of collusion and tampering. What we can do is utilize cryptography and protocol design to contain the scope of malicious collusion, making such behavior unprofitable.

The advantages and disadvantages of off-chain validation are apparent. The advantages include minimal resource utilization on-chain and enormous scaling potential. The disadvantages are that it becomes nearly impossible to fully inherit BTC’s security, which significantly restricts the types and methods of off-chain transactions. Moreover, off-chain validation means the data is also off-chain, requiring users to handle their own custody, which imposes higher requirements on software execution environment security and software stability.

Trends in Scalability Evolution

Currently, in the popular Layer2 paradigm of Ethereum, the validity of Layer2 computation is verified through Layer1. In other words, the state computation is pushed down to Layer2, but verification remains on Layer1. In the future, we can also push the verification computation off-chain, further unleashing the performance of the current blockchain infrastructure.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!

BTCLightningPrime TrustRGBTaproot Assets

Was this article helpful?

93 out of 132 found this helpful