From Inscriptions to Smart Contracts: A Comprehensive Analysis of the Evolution of Bitcoin Ecosystem Technology

Author: Cynic, CGV Research
Bitcoin, as the first successful decentralized digital currency, has been at the core of the digital currency field since its inception in 2009. As an innovative payment method and a means of value storage, Bitcoin has sparked widespread global attention towards 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 in Bitcoin on-chain transactions, with average Gas fees exceeding 300 sat/vB. At the same time, the airdrop of Nostr Assets has further attracted market attention, and design white papers for protocols like BitVM and BitStream have been proposed. The Bitcoin ecosystem is flourishing, with hidden potential for explosive growth. The CGV research team conducts a comprehensive review of the current state of the Bitcoin ecosystem, covering technological advancements, market dynamics, legal regulations, etc., to provide an in-depth analysis of Bitcoin technology and examine market trends, aiming 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 discussion 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 inscription protocol on Bitcoin emerged 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, facilitating 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, the issued assets possess many characteristics similar to Bitcoin, including prevention of double spending, privacy, security, transparency, and censorship resistance, ensuring the reliability of 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 maximum consensus of 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 utilize asymmetric cryptography to compute asset IDs, ensuring that only users holding the private key of the asset ID can issue the same asset. For asset metadata, it is stored in the script using the OP_RETURN opcode, referred to as marker output, which stores colored information without contaminating the UTXO. By utilizing Bitcoin's public-private key cryptographic 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; 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 using the nSequence field in 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 dust attack resistance 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 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, known today, was originally issued on Bitcoin through the Omni Layer. Mastercoin relies less 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 arbitrary Bitcoin transactions. The verification of transaction validity is conducted by continuously scanning Bitcoin blocks to maintain 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, short for Segregated Witness, essentially separates 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 benefit of effectively increasing the block capacity, allowing for more witness data. One important feature of Taproot is MAST, which allows developers to use Merkle Trees to include any asset's metadata in outputs, enhancing indirectness and scalability through Schnorr signatures, and enabling multi-hop transactions via the Lightning Network.

Ordinals & BRC20 and Clones: A Grand Social Experiment

From a broad perspective, Ordinals consist of four components:

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

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

Ordinals define a sorting scheme (starting from 0 based on the order of mining) that assigns a sequence number to the smallest unit, Satoshi, giving originally homogeneous Satoshis heterogeneous attributes, thus introducing scarcity.

It can reuse BTC's infrastructure, such as single-signature, multi-signature, time locks, height locks, etc., and does not require explicit creation of ordinal numbers, maintaining good anonymity without explicit on-chain footprints. The drawbacks are also evident; a large number of small and unused UTXOs will increase the size of the UTXO set, which can be severely termed 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 header
• 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 according to the HTTP response format and pushed into the non-executable scripts of spend scripts using 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, with a total maximum of 520 bytes. Since taproot payment scripts require existing taproot outputs to be used, inscriptions need to be completed in two steps: commit & reveal. The first step is to create a taproot output that commits the engraved content; the second step is to spend the previous taproot output using the engraved content and the corresponding Merkle Path to reveal 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, bringing the ability to issue fungible assets to Ordinals. BRC20 includes operations such as Deploy, Mint, and Transfer, with each operation requiring the 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 the complexity of transactions 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 better align 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 with 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 the sender to send a hash value instead of publicly revealing the UTXO receiving the tokens when sending payment requests, providing stronger privacy and censorship resistance. Of course, 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 verify 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. Verifying all transaction history is necessary to guarantee the validity of the received assets. 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 entirely designed around the Taproot protocol, enhancing privacy and scalability. Witness data is stored off-chain, verified on-chain, and can be stored 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 a local copy of the blockchain. Taproot Assets utilize Sparse Merkle Sum Trees to store the global state of assets, resulting in high storage overhead but efficient verification, allowing for transaction validation 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 value, security, and stability, it is increasingly distant from its original vision of "a peer-to-peer electronic cash system." Due to the limited capacity of blocks, transaction TPS, fees, and confirmation times prevent Bitcoin from handling a large number of 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 establish a payment channel, and payment channels can connect to each other, forming a more interconnected payment channel network. Users without direct channels can also 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 conduct countless transactions within this channel, with only two records on the blockchain: one when opening the channel and another 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, more than 60,000 channels, and a total network capacity exceeding 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 being confirmed simultaneously. In Stacks, this is referred to as "anchored blocks." Each Stacks transaction block corresponds to a single Bitcoin transaction, achieving higher transaction throughput. Since blocks are produced simultaneously, Bitcoin acts as the 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 produce blocks can earn STX rewards after 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 by issuing native tokens, but in reality, incentives can also be achieved without native tokens (see RSK).

For transaction data on 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 Clarity's built-in functions. Stacks can almost be considered a Layer 2 chain for Bitcoin; however, there are still some flaws in asset transfer in and out. 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 consortium 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 the 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. Currently, the 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. Aside from deposits and withdrawals, transactions on the Nostr Assets protocol are zero gas and encrypted, with transaction details stored on the Nostr Protocol relay, accessed quickly and efficiently via IPFS, while supporting natural language interaction without complex pages. Nostr Assets provides users with a simple and convenient way to transfer and trade assets, and combined with the traffic effect 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 them within the Lightning Network, equivalent to depositing assets into a centralized exchange. When users wish to transfer and trade assets within Nostr Assets, they will send signed messages using Nostr keys to the server, which only needs to record them in the internal ledger without executing them 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, utilizing existing Bitcoin OP Codes (OPBOOLEAN, OPNOT) to form NAND gate circuits, breaking down programs into primitive NAND gate circuit combinations, 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 NAND 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 adopts a P2P operational model, borrowing the idea of OP Rollup, with two roles: prover and verifier. Each time, the prover and verifier collaboratively construct a transaction, deposit collateral, and the prover provides the result. If the verifier computes 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 outset 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 was also a reluctant move; gaining support within the Bitcoin community to increase OPCODE difficulty is too high, so it can only resort to utilizing existing OPCODEs to achieve new functions. BitVM proposes a new paradigm for scalability, but there are many challenges in reality.
• Too early: EVM has a complete set of 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 architecture has incentive issues, and there are considerations to expand to 1-N or N-N, similar to the ideal OP Rollup (single honest assumption).

Conclusion

From the review throughout the text, it is evident that due to the limitations of the mainnet's processing capacity 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, off-chain computation and client-side validation solutions 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 necessary protocols, currently 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 use zero-knowledge proof technology for efficient scalability. However, current solutions are still very early, with excessively high computational costs, and are expected to be unfeasible in the short term. Of course, some may ask why a host of blockchains led by Ethereum, which possess high-speed computational capabilities, are not turned to Ethereum, and why the need to redo things on Bitcoin? Because It's Bitcoin.