Author: Cynic, CGV Research

Why not turn to Ethereum, but insist on redoing things 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 means of payment and 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 ecology led by BRC20 has set off the market, with multiple inscriptions achieving over a hundredfold increase. The Bitcoin chain transactions are severely congested, with the average Gas exceeding 300sat/vB. At the same time, the airdrop of Nostr Assets further attracted market attention, and protocol design white papers such as BitVM and BitStream were proposed. The Bitcoin ecosystem is thriving and harbors the potential for an outbreak.

The CGV research team comprehensively inventoried the current state of the Bitcoin ecosystem, covering technological advancements, market dynamics, laws and regulations, and conducted in-depth analysis of Bitcoin technology, examining 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, Segregated Witness, and predicts its future development trends.

Asset Issuance: Starting with Colored Coins

The essence of the inscription craze lies in its provision of the right for ordinary people to issue assets at a low threshold, while enjoying simplicity, fairness, and convenience. The emergence of the inscription protocol on Bitcoin dates back to 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 similar technology that uses 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 trade ownership through colored coins. The so-called "coloring" refers to adding specific information to the Bitcoin UTXO, distinguishing it from other Bitcoin UTXOs, thus bringing heterogeneity to homogeneous bitcoins. Through the colored coin technology, the issued assets possess many of the same characteristics as Bitcoin, including preventing 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 the community 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 issue and circulate assets using the many advantages of Bitcoin; 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 the coloring information without contaminating UTXO. Since asset issuance can be done using multi-signature through the use of Bitcoin's public-private key cryptographic tools.

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 the time of issuance. EPOBC assets must be transferred through the transfer operation. If EPOBC assets are used as inputs for non-transfer operations, the assets will be lost.

The 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 adding 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, 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 change operations. 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 assets. After the SegWit and Taproot upgrades, new derivative protocols have more options.

SegWit is short for Segregated Witness. Simply put, it separates the Witness (input script in transactions) from the transaction. The main reason for separation is to prevent nodes from attacking by modifying the input script, but it also comes with a benefit, effectively increasing the block's capacity to store more witness data.

An important feature of Taproot is MAST, which allows developers to include metadata of any asset in the output using Merkle Tree, using Schnorr signatures to enhance indirection, 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 set of sorting schemes (starting from 0 based on the order of being mined) to give the smallest unit of Bitcoin, Satoshi, a sequence number, giving originally homogeneous Satoshis heterogeneous properties, bringing scarcity.

It can reuse the basic infrastructure of BTC, such as single signature, multi-money, time lock, height lock, and does not need to explicitly create ordinal numbers, has good anonymity, and no explicit on-chain footprint. The disadvantages are also obvious, 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 is necessary to provide

• Blockchain header
• 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, on the other hand, engrave arbitrary content on sats by placing the content in the taproot script-path spend scripts, completely on-chain. The engraved content is serialized according to the http response format, placed into unexecutable scripts in the spend scripts using OP_PUSH, and called "envelopes". Specifically, engraving adds OP_FALSE before the conditional statement, places the engraved content in the unenterable conditional statement in JSON format. The size of the engraved 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 two-step commit&reveal 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 previous taproot output using the inscription content and the corresponding Merkle Path, revealing 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, based on it, giving Ordinals the ability to issue fungible assets. BRC20 has operations such as Deploy, Mint, Transfer, and each operation requires a two-step commit&reveal execution, making the transaction process more cumbersome and costly.

Using real data as an example:

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

ARC20, derived from the Atomicals protocol, reduces the complexity of transactions in design, binding each unit of ARC20 tokens to satoshis, reusing the Bitcoin transaction system. After issuing assets through a commit&reveal two-step process, the transfer of ARC20 tokens can be completed directly 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 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 of the ideas in previous asset protocols also reflect the current client-side validation asset protocols, such as 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 Lightning Labs, the development team of 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, with high storage costs but high verification efficiency. It can verify transactions through proof of inclusion/non-inclusion without the need to trace the transaction history of the assets.

Scalability: The Eternal Proposition of Bitcoin

Despite having the highest market value, highest security, and highest stability, Bitcoin 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 and frequent number of transactions, and for over a decade, various protocols have attempted to solve this problem.

Payment Channels and Lightning Network: The Originalist Solution for Bitcoin

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, the Lightning Network has over 14,000 nodes, over 60,000 channels, and a total capacity of over 5000 BTC.

Sidechains: The Ethereum Route in Bitcoin

Stacks

Stacks positions itself as the smart contract layer of 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 "anchoring block". The entire Stacks transaction block corresponds to a single Bitcoin transaction, achieving higher transaction throughput. By generating 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 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 blocks. 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 hash of the transaction data is saved to the Bitcoin transaction script using the OP_RETURN bytecode. Stacks nodes can read the stored Stacks transaction data hash in Bitcoin through the built-in functionality of Clarity.

Stacks can be considered as a Layer2 chain of Bitcoin, but there are still some flaws in the cross-entry and exit of assets. After the Nakamoto upgrade, Stacks supports sending Bitcoin transactions to complete asset exits, but the complexity of transactions makes it impossible to verify on the Bitcoin chain, and asset exits can only be verified through a multi-signature committee.

RSK

RSK uses the Merge-Mine algorithm, allowing Bitcoin miners to almost costlessly help RSK produce blocks 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, compatible with EVM.

Liquid

Liquid is a federated sidechain of Bitcoin, with permissioned node access, and is responsible for block production by fifteen members. Assets are locked and minted by sending assets to the multi-signature address on Liquid from BTC for asset entry into the Liquid sidechain; 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 2023-08-03, it was upgraded to the Nostr Assets Protocol, supporting the transfer of all assets in the Nostr ecosystem, with asset 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. 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, while also 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, 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 with Nostr messages. By transferring assets into the Nostr Assets Relay in the Lightning Network, users are essentially 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 actually executing it on the Lightning Network or the mainnet, thus achieving 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 placing the spend script root of complex programs 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 in practice, there are still many limitations.

BitVM still operates in a P2P mode, borrowing the idea of OP Rollup, with two roles, prover and verifier, jointly constructing a transaction each time, depositing collateral, with the prover providing the result, and if the verifier calculates a different result, submitting 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 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 a trust-minimized bridge and ZKP scalability (ZK Rollup). The proposal of BitVM is actually a last resort, seeking support in the Bitcoin community. It is too difficult to increase the difficulty of OP_CODE through proposals, so the only option is 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: Building a program with NAND gates may require hundreds of MB of data, 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's processing power and the lack of computational capabilities, 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 verification client-side verification schemes use certain fields in Bitcoin transactions to store critical information, treating the Bitcoin mainnet as a distributed log system, using 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, some are advancing on-chain verification work, 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.

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