CGV: A comprehensive overview of the historical context of asset issuance on the Bitcoin network, from colored coins, Mastercoin/Omni to inscriptions

Author: Cynic, CGV Research

Why not turn to Ethereum and instead redo everything on Bitcoin? Because it's Bitcoin.

Bitcoin, as the first successful decentralized digital currency, has been at the core of the digital currency space since its inception in 2009. As an innovative payment method and a means of value storage, Bitcoin has sparked widespread global interest in cryptocurrencies and blockchain technology. However, as the Bitcoin ecosystem continues to mature and expand, it also faces various challenges, including transaction speed, scalability, security, and regulatory issues.

Recently, the inscription ecosystem led by BRC20 has ignited the market, with multiple inscriptions achieving over a hundredfold increase, causing severe congestion on the Bitcoin chain, with average Gas prices exceeding 300 sat/vB. At the same time, the airdrop of Nostr Assets has further attracted market attention, and protocols like BitVM and BitStream have proposed design white papers, indicating that the Bitcoin ecosystem is burgeoning and hiding an explosive potential.

The CGV research team conducts a comprehensive review of the current state of the Bitcoin ecosystem, covering technological advancements, market dynamics, legal regulations, and more, to provide an in-depth analysis of Bitcoin technology and examine market trends. We aim to offer a panoramic view of Bitcoin's development. The article first reviews the basic principles and development history of Bitcoin, followed by an in-depth exploration of technological innovations in the Bitcoin network, such as the Lightning Network and Segregated Witness, while also predicting its future development trends.

Asset Issuance: Starting with Colored Coins

The essence of inscriptions lies in providing ordinary people with the right to issue assets with a low threshold, while enjoying simplicity, fairness, and convenience. The emergence of the inscription protocol on Bitcoin occurred in 2023, but the concept of using Bitcoin for asset issuance, known as Colored Coins, existed as early as 2012.

Colored Coins: Early Attempts

Colored Coins refer to a set of technologies that use the Bitcoin system to record the creation, ownership, and transfer of assets other than Bitcoin. They can be used to track digital assets and tangible assets held by third parties, allowing ownership transactions through Colored Coins. The term "colored" refers to adding specific information to Bitcoin UTXOs to distinguish them from other Bitcoin UTXOs, thus introducing heterogeneity among homogeneous Bitcoins. Through Colored Coin technology, issued assets possess many characteristics similar to Bitcoin, including protection against double spending, privacy, security, transparency, and censorship resistance, ensuring reliable transactions.

It is worth noting that the protocols defined by Colored Coins are not implemented by general Bitcoin software, so specific software is required to recognize Colored Coin-related transactions. Clearly, Colored Coins only hold value within communities that recognize the Colored Coin protocol; otherwise, the heterogeneous Colored Coins will lose their colored attributes and revert to pure satoshis. On one hand, Colored Coins recognized by small-scale communities can leverage many advantages of Bitcoin for asset issuance and circulation; on the other hand, it is nearly impossible for the Colored Coin protocol to merge into the widely accepted Bitcoin-Core software through a soft fork.

Open Assets

At the end of 2013, Flavien Charlon proposed the Open Assets Protocol as an implementation of Colored Coins. Asset issuers use asymmetric cryptography to compute asset IDs, ensuring that only users holding the asset ID private key can issue the same asset. For the asset's metadata, the OP_RETURN opcode is used to store it in the script, referred to as marker output, which stores coloring information without contaminating UTXOs. By utilizing Bitcoin's public-private key cryptography tools, asset issuance can be conducted through multi-signature.

EPOBC

In 2014, ChromaWay proposed the EPOBC (enhanced, padded, order-based coloring) protocol, which includes two types of operations: genesis and transfer. Genesis is used for asset issuance, while transfer is used for asset transfer. The type of asset cannot be displayed through encoding differentiation; each genesis transaction issues a new asset, determining the total supply at issuance. EPOBC assets must be transferred through the transfer operation; if EPOBC assets are used as inputs in non-transfer operation transactions, the assets will be lost.

Additional information about EPOBC assets is stored in the nSequence field of Bitcoin transactions. nSequence is a reserved field in Bitcoin transactions, consisting of 32 bits, with the lowest six bits used to determine the transaction type, and the lower 6-12 bits used to determine padding (to meet Bitcoin protocol's anti-dust attack requirements). The advantage of using nSequence to store metadata is that it does not increase additional storage. Since there is no asset ID for identification, each EPOBC asset transaction must trace back to the genesis transaction to determine its category and legitimacy.

Mastercoin/Omni Layer

Compared to the aforementioned protocols, Mastercoin's commercial implementation has been more successful. In 2013, Mastercoin conducted the first ICO in history, raising 5000 BTC and ushering in a new era. The USDT that people are familiar with today was initially issued on Bitcoin through the Omni Layer.

Mastercoin is less dependent on Bitcoin, opting to maintain state off-chain, with only minimal information stored on-chain. It can be considered that Mastercoin views Bitcoin as a decentralized logging system, publishing asset change operations through any Bitcoin transaction. The validation of transaction validity is conducted by continuously scanning Bitcoin blocks and maintaining an off-chain asset database that stores the mapping of addresses to assets, where addresses reuse Bitcoin's address system.

Early Colored Coins primarily used the OP_RETURN opcode to store metadata about assets. After the SegWit and Taproot upgrades, new derivative protocols have more options.

SegWit is short for Segregated Witness, which simply means separating the Witness (input script in transactions) from the transaction. The main reason for this separation is to prevent nodes from attacking by modifying the input script, but it also has the added benefit of effectively increasing the block capacity, allowing for more witness data to be stored.

One important feature of Taproot is MAST, which allows developers to use Merkle Trees to include arbitrary asset metadata in outputs, enhancing indirectness and scalability with Schnorr signatures, and enabling multi-hop transactions through the Lightning Network.

Ordinals & BRC20 and Clones: A Grand Social Experiment

From a broad perspective, Ordinals consists of four components:

• A BIP for ordering sats
• An indexer that uses Bitcoin Core Node to track the position (serial number) of all satoshis
• A wallet for conducting ordinal-related transactions
• A block explorer to identify ordinal-related transactions

Of course, the core remains the BIP/protocol.

Ordinals assigns a serial number to the smallest unit, Satoshi, by defining a sorting scheme (starting from 0 based on the order of mining), giving originally homogeneous Satoshis heterogeneous attributes and introducing scarcity.

It can reuse BTC's infrastructure, such as single-signature, multi-signature, time locks, and height locks, without explicitly creating ordinal numbers, maintaining good anonymity and leaving no explicit on-chain footprint. The drawbacks are also evident; a large number of small, unused UTXOs will increase the size of the UTXO set, which can be severely described as a dust attack. Additionally, the space occupied by the index is substantial; each time a specific sat is spent, it requires providing:

• The blockchain head
• The Merkle path to the coinbase transaction that created that sat
• The coinbase transaction that created that sat

To prove that a specific sat is included in a specific output.

Inscriptions involve engraving arbitrary content onto sats, specifically by placing the content into taproot script-path spend scripts, fully on-chain. The engraved content is serialized in HTTP response format and placed into the non-executable scripts of spend scripts by OPPUSH, referred to as "envelopes." Specifically, engraving involves adding OPFALSE before the conditional statement and placing the engraved content in JSON format within the inaccessible conditional statement. The size of the engraved content is limited by the taproot script, totaling no more than 520 bytes.

Since taproot payment scripts require existing taproot outputs to be used, inscriptions need to undergo a commit & reveal two-step operation to be completed. The first step is to create a taproot output that commits to the engraved content; the second step is to spend the previous taproot output using the engraved content and the corresponding Merkle Path, revealing the engraved content on-chain.

The original purpose of inscriptions was to introduce non-fungible tokens (NFTs) to BTC; however, new developers have mimicked ERC20 to create BRC20, granting Ordinals the ability to issue fungible assets. BRC20 supports operations such as Deploy, Mint, and Transfer, with each operation requiring a commit & reveal two-step execution, making the transaction process more cumbersome and costly.

Using real data as an example:

The selected part is the engraved content, and after deserialization, the result is as follows:

The ARC20 derived from the Atomicals protocol reduces transaction complexity by binding each unit of ARC20 tokens to satoshis, reusing Bitcoin's transaction system. After issuing assets through the commit & reveal two-step process, the transfer of ARC20 tokens can be completed directly by transferring the corresponding satoshis. The design of ARC20 may align more closely with the literal definition of Colored Coins, adding new content to existing tokens, allowing them to become new tokens, with the new token's value not being lower than that of the original token, similar to gold and silver jewelry.

Client-Side Validation and Next-Generation Asset Protocols

Client-side validation (CSV) is a concept proposed by Peter Todd in 2017, alongside the concept of single-use seals. In simple terms, the CSV mechanism involves off-chain data storage, on-chain commitments, and client-side validation. The idea has been partially reflected in previous asset protocols. Current asset protocols utilizing client-side validation include RGB and Taproot Assets (Taro).

RGB

In addition to the characteristics of client-side validation, RGB uses Pedersen hashes as a commitment mechanism and supports output blinding, allowing payment requests to be sent without publicly disclosing the UTXO receiving the tokens, instead sending a hash value, providing stronger privacy and censorship resistance. However, when the tokens are spent, the blinded secret must be disclosed to the recipient for them to verify the transaction history.

Additionally, RGB incorporates AluVM to achieve stronger programmability. When users perform client-side validation, they must not only validate the payment information received but also obtain the entire transaction history of the token from the payer, tracing back to the genesis transaction of the asset to ensure the finality of the transaction. Validating all transaction history is necessary to guarantee the validity of the received asset.

Taproot Assets

Taproot Assets is another project developed by the Lightning Labs team, which allows issued assets to be transferred instantly, in large quantities, and at low cost on the Lightning Network. Taproot Assets are designed entirely around the Taproot protocol, enhancing privacy and scalability.

Witness data is stored off-chain, verified on-chain, and can exist locally or in information repositories (referred to as "Universes," similar to git repositories). Verification of witnesses requires all historical data from the asset's issuance, which is propagated through the Taproot Assets gossip layer. Clients can cross-verify using local copies of the blockchain.

Taproot Assets utilize Sparse Merkle Sum Trees to store the global state of assets, which incurs high storage overhead but offers high verification efficiency, allowing transactions to be verified through proof of inclusion/non-inclusion without needing to trace back the asset's transaction history.

Scalability: Bitcoin's Eternal Proposition

Despite Bitcoin having the highest market capitalization, security, and stability, it is drifting further away from its original vision of "a peer-to-peer electronic cash system." Due to the limited capacity of blocks, the transaction TPS, fees, and confirmation times prevent Bitcoin from handling large and frequent transactions. Over the past decade, various protocols have attempted to address this issue.

Payment Channels and the Lightning Network: The Bitcoin Fundamentalist Solution

The Lightning Network operates by establishing payment channels. Any two users can create a payment channel, and payment channels can connect to each other, forming a more interconnected payment channel network. Users without direct channels can still make payments through multiple hops.

For example, if Alice and Bob want to conduct multiple transactions without recording each one on the Bitcoin blockchain, they can open a payment channel between them. They can make countless transactions within this channel, and the entire process only needs to be recorded on the blockchain twice: once when opening the channel and once when closing it. This significantly reduces the waiting time for blockchain confirmations and alleviates the burden on the blockchain.

Currently, there are over 14,000 Lightning Network nodes, with more than 60,000 channels, and the total capacity of the network exceeds 5,000 BTC.

Sidechains: The Ethereum Route in Bitcoin

Stacks

Stacks positions itself as the smart contract layer for Bitcoin, using its issued token as a Gas token. Stacks employs a micro-block mechanism, developing Bitcoin and Stacks in a synchronized manner, with their blocks confirmed simultaneously. In Stacks, this is referred to as "anchored blocks." The entire Stacks transaction block corresponds to a single Bitcoin transaction, achieving higher transaction throughput. By producing blocks simultaneously, Bitcoin acts as a rate limiter for creating Stacks blocks, preventing its peer-to-peer network from suffering denial-of-service attacks.

Stacks achieves consensus through a dual-spiral mechanism of PoX, where miners send BTC to STX stakers to compete for block production qualifications. Miners who successfully win the block production qualification can receive STX rewards after successfully completing the block. In this process, STX stakers can proportionally receive the BTC sent by miners. Stacks aims to incentivize miners to maintain historical ledgers through the issuance of a native token, but in reality, incentives can also be achieved without a native token (see RSK).

For transaction data in the Stacks blockchain, the hash of the transaction data is saved to the script of Bitcoin transactions using the OP_RETURN bytecode, allowing Stacks nodes to read the stored Stacks transaction data hash in Bitcoin through Clarity's built-in functions.

Stacks can almost be considered a Layer 2 chain for Bitcoin; however, there are still some flaws in the cross-chain asset transfer. After the Nakamoto upgrade, Stacks supports sending Bitcoin transactions to complete asset transfers, but the complexity of transactions prevents verification on the Bitcoin chain, requiring validation of asset transfers through a multi-signature committee.

RSK

RSK employs a merge-mining algorithm, allowing Bitcoin miners to help RSK produce blocks at almost no cost and earn additional rewards. RSK does not have a native token and still uses BTC (RBTC) as the Gas Token. RSK has its own execution engine and is EVM compatible.

Liquid

Liquid is a federated sidechain of Bitcoin, with permissioned node access, managed by fifteen members responsible for block production. Assets are transferred using a lock & mint method, where assets are sent to a multi-signature address on Liquid to cross into the Liquid sidechain; to cross out, L-BTC is sent to a multi-signature address on the Liquid chain. The security of the multi-signature address is 11/15.

Liquid focuses on financial applications, providing developers with SDKs related to financial services. The current TVL of the Liquid network is approximately 3000 BTC.

Nostr Assets: Further Centralization

Nostr Assets was initially named NostrSwap, a trading platform for BRC20. On August 3, 2023, it was upgraded to the Nostr Assets Protocol, supporting the transfer of all assets within the Nostr ecosystem, with settlement and security handled by the Lightning Network.

Nostr Assets allows Nostr users to send and receive Lightning Network assets using Nostr public and private keys. Apart from deposits and withdrawals, transactions on the Nostr Assets protocol are gas-free and encrypted, with transaction details stored on the Nostr Protocol's relay, accessed quickly and efficiently via IPFS, while supporting natural language interaction without the need for complex pages.

Nostr Assets provides users with a simple and convenient way to transfer and trade assets, and combined with the traffic effects of the Nostr social protocol, it may have significant application scenarios in the future. However, fundamentally, it is merely a method of controlling (hosting) wallets using Nostr messages. Users deposit assets into the Nostr Assets Relay by transferring funds within the Lightning Network, effectively storing assets in a centralized exchange. When users want to transfer and trade assets within Nostr Assets, they will send messages signed with Nostr keys to the server, which will verify and only need to record internally without executing on the Lightning Network or mainnet, thus achieving zero gas and high TPS.

BitVM: Programmability and Infinite Scalability

"Any computable function can be verified on Bitcoin."

--- --- Robin Linus, creator of BitVM

BitVM was proposed by Robin Linus, founder of ZeroSync, using existing Bitcoin OP Codes (OPBOOLEAN, OPNOT) to form NAND gate circuits, decomposing programs into primitive NAND gate circuit combinations, and placing the spend script root of complex programs into Taproot transactions for lower-cost on-chain storage. According to computational theory, all computational logic can be constructed using NAND gate circuits, so theoretically, BitVM can achieve Turing completeness on Bitcoin and perform all computations, but in practice, there are many limitations.

BitVM still adopts a P2P operating model, borrowing from the OP Rollup concept, with two roles: prover and verifier. Each time, the prover and verifier jointly construct a transaction, deposit collateral, and the prover provides a result. If the verifier calculates a different result, they submit a fraud proof on-chain to penalize the prover's funds.

"The real killer app is scaling Bitcoin. [Robin Linus isn't] a big fan of smart contracts. He's not a big fan of increasing Bitcoin's expressivity. He really is interested in making it so that Bitcoin can process millions of transactions per second."

--- --- Super Testnet, BitVM developer

BitVM offers better programmability, but how does it relate to scalability? In fact, BitVM was designed from the beginning to serve off-chain computation and on-chain verification scalability, as indicated by the naming of prover and verifier.

The best use case for BitVM is actually a trust-minimized bridge and ZKP scalability (ZK Rollup). The proposal of BitVM is also a reluctant move to gain support within the Bitcoin community; increasing the difficulty of proposals to add OPCODE is too high, so it can only resort to using existing OPCODE to achieve new functions.

BitVM proposes a new paradigm for scalability, but there are many challenges in reality.

• Too early: EVM has a complete VM architecture, while BitVM only has a function that can verify whether a string is 0 or 1.

• Storage overhead: Building programs with NAND gates may require hundreds of MB of data, with billions of taptree leaves.

• P2P: Currently, it is still a two-party interaction; the prover-challenger structure has incentive issues, and there are considerations to expand to 1-N or N-N, like the ideal OP Rollup (single honest assumption).

Conclusion

From the comprehensive review throughout the text, it is evident that due to the limitations of the mainnet's processing capabilities and the lack of computational power, if Bitcoin wants to cultivate a more prosperous and diverse ecosystem, it must shift computation off-chain.

On one hand, client-side validation solutions for off-chain computation and verification utilize certain fields in Bitcoin transactions to store key information, viewing the Bitcoin mainnet as a distributed logging system, leveraging its censorship resistance and reliability to ensure the availability of key data, somewhat akin to sovereign Rollups. This solution does not require modifications to Bitcoin's protocol layer and allows for the free construction of the necessary protocols, currently being more feasible, but it cannot fully inherit Bitcoin's security.

On the other hand, some are advancing on-chain verification efforts, attempting to utilize existing tools to achieve arbitrary computation on Bitcoin, and then using zero-knowledge proof technology to achieve efficient scalability. However, current solutions are still very early, with excessively high computational costs, and are unlikely to be implemented in the short term.

Of course, some may ask why, with Ethereum leading a host of blockchains possessing high-speed computational capabilities, we do not turn to Ethereum and instead redo everything on Bitcoin?

Because It's Bitcoin.

Because it's Bitcoin.