Author: Cynic, CGV Research

Why not turn to Ethereum, and instead have to start over on Bitcoin? Because this is Bitcoin.

Bitcoin, as the first successful decentralized digital currency, has been at the core of the cryptocurrency field since its inception in 2009. As an innovative payment method and store of value, 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 set off the market, with multiple inscriptions achieving over a hundredfold increase, severe congestion in Bitcoin on-chain transactions, and an average Gas price exceeding 300 sat/vB. At the same time, the airdrop of Nostr Assets further attracted market attention, and protocol design whitepapers such as BitVM and BitStream were proposed. The Bitcoin ecosystem is thriving and harbors the potential for an outbreak.

The CGV research team has conducted a comprehensive assessment of the current state of the Bitcoin ecosystem, covering technological advancements, market dynamics, legal regulations, etc., and has conducted an in-depth analysis of Bitcoin technology and examined market trends. We hope to provide a panoramic view of the development of Bitcoin. The article first reviews the basic principles and development history of Bitcoin, and then delves into the technological innovations of 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 fire of inscriptions lies in its provision of the right for ordinary people to issue assets with low barriers, while enjoying simplicity, fairness, and convenience. The inception of the inscription protocol on Bitcoin occurred in 2023, but as early as 2012, there was a concept of using Bitcoin to issue assets, known as Colored Coins.

Colored Coins: Early Attempts

Colored Coins refers to a set of technologies that use the Bitcoin system to record the creation, ownership, and transfer of assets other than Bitcoin, which can be used to track digital assets and tangible assets held by third parties, and to conduct ownership transactions through colored coins. The term "colored" refers to the addition of specific information to Bitcoin UTXO, distinguishing it from other Bitcoin UTXO, thus introducing heterogeneity among homogeneous bitcoins. Through colored coin technology, the issued assets possess many of the same characteristics as Bitcoin, including prevention of double spending, privacy, security, transparency, and resistance to censorship, ensuring the reliability of transactions.

It is worth noting that the protocol defined by colored coins is not implemented by general Bitcoin software, so specific software is required to identify transactions related to colored coins. Obviously, colored coins only have value within a group that recognizes the colored coin protocol; otherwise, heterogeneous colored coins will lose their coloring properties and revert to pure satoshis. On the one hand, colored coins recognized by small communities can leverage the many advantages of Bitcoin for asset issuance and circulation; on the other hand, it is almost impossible for the colored coin protocol to be merged into the largest consensus 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 calculate asset IDs, ensuring that only users holding the asset ID private key can issue the same asset. For the metadata of the asset, it is stored in the script using the OP_RETURN opcode, referred to as the marker output, which stores colored information without contaminating UTXO. Since public-private key cryptography tools of Bitcoin are used, asset issuance can be done 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, and transfer is used for asset transfer. The type of asset cannot be explicitly encoded, and each genesis transaction issues a new asset, determining the total amount at issuance. EPOBC assets must be transferred through the transfer operation, and if EPOBC assets are used as inputs for 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 bits 6-12 used to determine padding (to meet the anti-dust attack requirements of the Bitcoin protocol). Storing metadata information using nSequence has the advantage of not requiring additional storage. Since there is no asset ID for identification, each transaction of an EPOBC asset must be traced back to the genesis transaction to determine its category and legitimacy.

Mastercoin/Omni Layer

Compared to the above 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, now well-known, was initially issued on Bitcoin through the Omni Layer.

Mastercoin has a lower dependence on Bitcoin and chooses to maintain the state off-chain more, with minimal information stored on-chain. It can be considered that Mastercoin views Bitcoin as a decentralized logging system, using any Bitcoin transaction to publish asset changes. The validation of transaction validity is done by continuously scanning Bitcoin blocks to maintain an off-chain asset database, which stores the mapping relationship between addresses and assets, with addresses reusing the Bitcoin address system.

Early colored coins basically used the OP_RETURN opcode of the script to store metadata about the asset. 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) from the transaction. The main reason for separation is to prevent nodes from attacking by modifying the input script, but it also has the benefit of effectively increasing the block's capacity, allowing for more witness data to be stored.

An important feature of Taproot is MAST, which allows developers to include metadata for any asset in the output using a Merkle Tree, using Schnorr signatures to enhance privacy, scalability, and enabling multi-hop transactions through the Lightning Network.

Ordinals&BRC20 and Simulated Trading: Grand Social Experiment

From a broad perspective, Ordinals consist of four components:

• A BIP for sequencing sats

• An indexer that uses the Bitcoin Core Node to track the position (sequence number) of all satoshis

• A wallet for ordinal-related transactions

• A block explorer to identify ordinal-related transactions

Of course, the core is still the BIP/protocol.

Ordinals assigns a sequence number to the smallest unit of Bitcoin, Satoshi, based on the order in which they are mined, starting from 0, giving the originally homogeneous Satoshis heterogeneous properties, bringing scarcity.

It can reuse the basic infrastructure of BTC, such as single signatures, multi-money, time locks, height locks, and does not need to explicitly create ordinal numbers, has good anonymity, and no explicit on-chain footprint. The disadvantages are also obvious, as a large number of small and unused UTXOs will increase the size of the UTXO set, and more seriously, it can be called a dust attack. In addition, the space occupied by the index is large, and each time a specific sat is spent, it needs to provide

• Blockchain header

• Merkle path to the coinbase transaction that created the sat

• The coinbase transaction that created the sat

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

Inscriptions, is to inscribe arbitrary content on sats, the specific way is to put the content into the taproot script-path spend scripts, completely on-chain. The inscription content is serialized according to the http response format, put into the unexecutable script of the spend scripts by OP_PUSH, and called "envelopes". Specifically, before the conditional statement, OP_FALSE is added to place the inscription content in a non-executable conditional statement in JSON format. The size of the inscription content is limited by the taproot script and cannot exceed a total of 520 bytes.

Since the taproot payment script requires existing taproot outputs to be used, inscriptions require a commit & reveal two-step operation to complete. The first step is to create a taproot output that commits to the inscription content; the second step is to spend the taproot output from the previous step using the inscription content and the corresponding Merkle Path, and reveal the inscription content on-chain.

The original purpose of inscriptions was to introduce non-fungible tokens (NFT) to BTC, but new developers have created BRC20, an imitation of ERC20, which brings the ability to issue homogeneous assets to Ordinals. BRC20 has operations such as Deploy, Mint, Transfer, etc., and each operation requires 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 inscription content, and the result after deserialization is as follows:

ARC20, derived from the Atomicals protocol, reduces the complexity of transactions in its design, binding each unit of ARC20 tokens to satoshis, reusing the Bitcoin transaction system. After issuing assets through commit & reveal, the transfer of ARC20 tokens can be directly completed by transferring the corresponding satoshis. The design of ARC20 may be more in line with the literal definition of colored coins, adding new content to existing tokens to make them capable of becoming new tokens, and the value of the new tokens will not be lower than that of the original tokens, 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, along with the concept of single-use seals. In simple terms, the CSV mechanism involves off-chain data storage, on-chain commitment, and client-side validation. Some aspects of this idea are also reflected in previous asset protocols. The current asset protocols for client-side validation include RGB and Taproot Assets (Taro).

RGB

In addition to the characteristics of client-side validation, RGB uses Perdersen hash as the commitment mechanism and also supports output blinding. When sending payment requests, there is no need to publicly disclose the UTXO receiving the tokens, instead, a hash value is sent, providing stronger privacy and resistance to censorship. However, when the tokens are spent, the blinded value needs to be disclosed to the recipient to verify transaction history.

In addition, RGB adds AluVM to achieve greater programmability. When users perform client-side validation, they not only verify the payment information sent, but also need to receive all transaction history of the tokens from the payer, all the way back to the genesis transaction of the asset issuance, to ensure the finality of the transaction. Verifying all transaction history is necessary to ensure the validity of the received assets.

Taproot Assets

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

Witness data is stored off-chain and verified on-chain. The off-chain storage can be local or in an information repository (called "Universes," similar to a git repository). Verification of the witness requires all historical data from the issuance of the asset, which is propagated through the Taproot Assets gossip layer. Clients can perform cross-verification using a local copy of the blockchain.

Taproot Assets uses Sparse Merkle Sum Tree to store the global state of assets, which incurs high storage costs but has high verification efficiency. It can verify transactions through proof of inclusion/non-inclusion without needing to trace the transaction history of the assets.

Scalability: The Eternal Proposition of Bitcoin

Although Bitcoin has the highest market value, highest security, and highest stability, it is increasingly moving away from its original vision of "a peer-to-peer electronic cash system." Due to the limited capacity of blocks, the TPS, fees, and confirmation times of transactions make it impossible for Bitcoin to handle a large volume of frequent transactions, and for over a decade, various protocols have attempted to solve this problem.

Payment Channels and Lightning Network: The Original Bitcoin Solution

The Lightning Network works by establishing payment channels. Any two users can establish a payment channel between them, and these channels can be connected to each other, forming a more connected network of payment channels, and users who do not have a direct channel can also make payments through multiple hops.

For example, if Alice and Bob want to make 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 twice on the blockchain: once when the channel is opened, and once when it is closed. This greatly reduces the waiting time for blockchain confirmations and reduces the burden on the blockchain.

Currently, there are over 14,000 Lightning Network nodes, over 60,000 channels, and the total capacity in the network exceeds 5000 BTC.

Sidechains: The Ethereum Route in Bitcoin

Stacks

Stacks positions itself as the smart contract layer for Bitcoin, using its own issued token as the Gas token. Stacks uses a micro-block mechanism, and Bitcoin and Stacks develop synchronously, with their blocks being confirmed simultaneously. In Stacks, this is called the "anchor block." The entire Stacks transaction block corresponds to a single Bitcoin transaction, achieving higher transaction throughput. Because blocks are generated 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 the dual spiral mechanism of PoX, where miners send BTC to STX stakers to compete for block production eligibility. Miners who successfully win block production eligibility can receive STX rewards after successfully producing a block. During this process, STX stakers can receive BTC sent by miners in proportion. Stacks aims to incentivize miners to maintain the historical ledger by issuing native tokens, but in reality, incentives can be achieved without native tokens (see RSK).

For transaction data in the Stacks blockchain, the transaction data hash is stored in the Bitcoin transaction script using the OP_RETURN bytecode. Stacks nodes can read the Stacks transaction data hash stored in Bitcoin using the built-in functionality of Clarity.

Stacks can be considered as a Layer 2 chain for Bitcoin, but 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 the transactions prevents verification on the Bitcoin chain, and asset transfers can only be verified through a multi-signature committee.

RSK

RSK uses the merge-mining algorithm, where Bitcoin miners can help RSK produce blocks at almost no cost and receive 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 compatible with EVM.

Liquid

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

Liquid focuses on financial applications and provides developers with an SDK related to financial services. The current TVL of the Liquid network is approximately 3000 BTC.

Nostr Assets: Further Centralization

Nostr Assets, originally named NostrSwap, is a BRC20 trading platform. On August 3, 2023, it was upgraded to the Nostr Assets Protocol, which supports the transfer and settlement of all assets in the Nostr ecosystem, with asset security handled by the Lightning Network.

Nostr Assets allows Nostr users to send and receive Lightning Network assets using Nostr public and private keys. Except for deposit and withdrawal, transactions on the Nostr Assets protocol are gas-free and encrypted, with transaction details stored on the Nostr Protocol's relay using IPFS for fast and efficient access. It also supports natural language interaction, eliminating the need for complex interfaces.

Nostr Assets provides users with a simple and convenient way to transfer and trade assets, combined with the traffic effect of the Nostr social protocol, which may have significant future applications. However, fundamentally, it is just a method of controlling (custody) wallets using Nostr messages. Users deposit assets into the Nostr Assets relay by transferring them in the Lightning Network, which is equivalent to depositing assets into a centralized exchange. When users want to transfer and trade assets in Nostr Assets, they send messages signed with Nostr keys to the server, and after verification, the server only needs to record the transaction in the internal ledger without executing it on the Lightning Network or the mainnet, enabling zero gas and high TPS.

BitVM: Programmability and Unlimited Scalability

"Any computable function can be verified on Bitcoin"

——Robin Linus, creator of BitVM

BitVM, proposed by Robin Linus, the founder of ZeroSync, uses existing Bitcoin OP Codes (OP_BOOLEAN, OP_NOT) to form AND and NOT gate circuits, decomposing programs into primitive AND and NOT gate circuits, and places the spend script root of the complex program into Taproot transactions for low-cost on-chain storage. According to computational theory, all computational logic can be constructed using AND and NOT gate circuits, so theoretically, BitVM can achieve Turing completeness on Bitcoin and perform all computations, but there are still many limitations in practice.

BitVM still operates in a P2P mode, following the idea of OP Rollup, with two roles, prover and verifier. Each time, the prover and verifier jointly construct a transaction, deposit collateral, and the prover provides the result. If the verifier calculates a different result, they submit a fraud proof to the 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 provides better programmability, but how does it relate to scalability? In fact, BitVM has been serving for off-chain computation and on-chain verification from the beginning, as can be seen from the naming of prover and verifier.

The best use case for BitVM is actually minimizing trust bridges and ZKP scalability (ZK Rollup). The proposal of BitVM was actually a last resort to gain support in the Bitcoin community, as increasing the difficulty of adding OP_CODE through proposals was too high, so the only option was to use existing OP_CODE to implement new functionality.

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

• 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 cost: Constructing a program using NAND gates may require data of several hundred MB, with billions of taptree leaves.

• P2P: Currently, it is still a two-party interaction, and the prover-challenger architecture has incentive issues. There is consideration to expand to 1-N or N-N, similar to the ideal OP Rollup (single honest assumption).

Conclusion

A comprehensive review of the entire text makes it clear that due to the limitations of the mainnet processing capacity and the lack of computational power, if Bitcoin wants to cultivate a more prosperous and diverse ecosystem, it must move computation off-chain.

On the one hand, off-chain computation and off-chain client-side verification solutions use certain fields in Bitcoin transactions to store critical information, treating the Bitcoin mainnet as a distributed log system, leveraging its censorship resistance and reliability to ensure the availability of critical data, somewhat similar to Sovereign Rollup in a sense. This approach does not require modification of the Bitcoin protocol layer and allows for the construction of the required protocols freely, making it more feasible at present, but it cannot fully inherit the security of Bitcoin.

On the other hand, there are also efforts to advance on-chain verification, attempting to achieve arbitrary computation on Bitcoin using existing tools, and then using zero-knowledge proof technology to achieve efficient scalability. However, the current approach is still very early, with high computational costs, and is not expected to be implemented in the short term.

Of course, some may ask, why not turn to Ethereum and other blockchains with high computational capabilities, instead of redoing things on Bitcoin?

Because It's Bitcoin.

Follow us

Twitter: https://twitter.com/WuBlockchain

Telegram: https://t.me/wublockchainenglish