From Inscriptions to Smart Contracts: A Comprehensive Analysis of Bitcoin Ecosystem's Technological Evolution
TechFlow Selected TechFlow Selected
From Inscriptions to Smart Contracts: A Comprehensive Analysis of Bitcoin Ecosystem's Technological Evolution
Why switch to Ethereum when we can just rebuild everything on Bitcoin? Because it's Bitcoin.
Navigating Web3 tides with focused insightsAuthor: Cynic, CGV Research
Bitcoin, as the first successful decentralized digital currency, has remained central to the cryptocurrency space since its inception in 2009. As an innovative payment method and store of value, Bitcoin has triggered global interest in cryptocurrencies and blockchain technology. However, as the Bitcoin ecosystem matures and expands, it faces multiple challenges, including transaction speed, scalability, security, and regulatory issues.
Recently, the ordinals-based inscription ecosystem led by BRC20 sparked a market boom, with several inscriptions achieving over 100x gains. This caused severe congestion on the Bitcoin network, pushing average gas fees above 300 sat/vB. At the same time, the Nostr Assets airdrop further attracted market attention, while protocol designs such as BitVM and BitStream were introduced via whitepapers. The Bitcoin ecosystem is still in its early stages but holds significant explosive potential.
The CGV Research team provides a comprehensive review of the current state of the Bitcoin ecosystem, covering technological developments, market dynamics, and regulatory frameworks. Through in-depth analysis of Bitcoin’s technology and examination of market trends, we aim to offer a panoramic view of Bitcoin’s evolution. This article begins by reviewing Bitcoin’s fundamental principles and development history, then explores key technical innovations such as the Lightning Network and Segregated Witness (SegWit), and concludes with predictions about future development.
Asset Issuance: From Colored Coins
The essence of the inscription movement lies in providing ordinary users with low-barrier access to asset issuance, combining simplicity, fairness, and convenience. While inscription protocols on Bitcoin emerged prominently in 2023, the idea of using Bitcoin for asset issuance dates back to 2012 with the concept of "Colored Coins."
Colored Coins: Early Attempts
Colored Coins refer to a set of techniques that use the Bitcoin system to record the creation, ownership, and transfer of assets beyond Bitcoin itself. They can track digital assets or tangible assets held by third parties, enabling ownership transactions through colored coins. "Coloring" involves adding specific information to Bitcoin UTXOs, differentiating them from standard UTXOs and introducing heterogeneity among otherwise fungible bitcoins. Through this technique, issued assets inherit many of Bitcoin's core properties—double-spending prevention, privacy, security, transparency, and censorship resistance—ensuring reliable transactions.
Notably, the protocols defining colored coins are not implemented in standard Bitcoin software, requiring specialized tools to recognize such transactions. Clearly, colored coins only hold value within communities that acknowledge their protocol; otherwise, these differentiated units revert to plain satoshis. On one hand, small communities can leverage Bitcoin’s strengths for asset issuance and circulation. On the other hand, integrating colored coin protocols into the mainstream Bitcoin Core software via soft fork is nearly impossible.
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 an asset ID, ensuring only those holding the corresponding private key can issue identical assets. Metadata is stored in the script using the OP_RETURN opcode, referred to as a "marker output," allowing coloring data to be recorded without polluting the UTXO set. By leveraging Bitcoin’s public-key cryptography, asset issuance can also support multi-signature schemes.
EPOBC
In 2014, ChromaWay introduced the EPOBC (Enhanced, Padded, Order-Based Coloring) protocol, which includes two operations: genesis and transfer. Genesis is used for asset issuance, while transfer handles asset movement. Asset types cannot be explicitly encoded—each genesis transaction creates a new asset with a fixed total supply determined at issuance. EPOBC assets must be transferred via the transfer operation; if used as inputs in non-transfer transactions, the assets are lost.
Additional metadata for EPOBC assets is stored in the nSequence field of Bitcoin transactions. nSequence is a reserved 32-bit field in Bitcoin transactions—the lowest six bits define transaction type, while bits 6–12 handle padding (to meet anti-dust attack requirements). Using nSequence avoids additional storage overhead. Without unique asset IDs, every EPOBC transaction must trace back to its genesis transaction to verify legitimacy and category.
Mastercoin/Omni Layer
Compared to earlier protocols, Mastercoin achieved greater commercial success. In 2013, Mastercoin conducted the first-ever ICO, raising 5,000 BTC and ushering in a new era. USDT, now widely known, was originally issued on Bitcoin via the Omni Layer.
Mastercoin relies less directly on Bitcoin, opting instead to maintain state off-chain while storing minimal data on-chain. Effectively, Mastercoin treats Bitcoin as a decentralized logging system, publishing asset changes through arbitrary Bitcoin transactions. Transaction validity is verified by continuously scanning Bitcoin blocks and maintaining an off-chain database mapping addresses to assets—reusing Bitcoin’s existing address format.
Early colored coin implementations primarily used the OP_RETURN opcode in scripts to store asset metadata. After SegWit and Taproot upgrades, newer derivative protocols gained more options.
SegWit, short for Segregated Witness, separates the witness (input script) from the transaction data. This separation prevents malleability attacks and indirectly increases block capacity by freeing up space for more witness data.
A key feature of Taproot is MAST (Merkleized Abstract Syntax Trees), which allows developers to embed arbitrary asset metadata in outputs via Merkle trees. Schnorr signatures enhance efficiency and scalability, enabling multi-hop transactions over the Lightning Network.
Ordinals & BRC20 and Clones: A Grand Social Experiment
Broadly speaking, Ordinals consist of four components:
-
A BIP defining ordinal numbering for satoshis
-
An indexer using Bitcoin Core Node to track the position (ordinal) of all satoshis
-
A wallet capable of handling ordinal-related transactions
-
A block explorer that identifies ordinal-related transactions
Of course, the core remains the BIP/protocol.
Ordinals introduce a sequencing scheme—assigning each satoshi a number based on mining order starting from zero—giving individual satoshis unique identities and enabling scarcity among otherwise fungible units.
It reuses Bitcoin’s infrastructure—supporting single/multi-sig, timelocks, height locks—with no explicit ordinal creation required, offering good anonymity and no clear on-chain footprint. However, drawbacks are evident: numerous unused small-value UTXOs increase the size of the UTXO set—some call this a form of dust attack. Additionally, indexing requires substantial storage space, and spending a specific satoshi demands proof including:
-
Blockchain headers
-
Merkle path from the blockchain header to the coinbase transaction that created the satoshi
-
The coinbase transaction itself
to prove inclusion of the satoshi in a particular output.
Inscriptions involve embedding arbitrary content onto satoshis, specifically by placing the content into Taproot script-path spend scripts—fully on-chain. The content is serialized according to HTTP response format and pushed into unexecuted script segments called “envelopes” using OP_PUSH. Specifically, inscriptions add OP_FALSE before conditional statements and place JSON-formatted content inside unreachable branches. Inscription size is limited by Taproot script constraints—maximum 520 bytes.
Since Taproot requires an existing Taproot output for script-path spends, inscriptions require a two-step commit-and-reveal process: First, create a Taproot output committing to the inscription content; Second, spend that output using the inscription content and corresponding Merkle path to reveal it on-chain.
Initially designed to bring NFTs to Bitcoin, developers later mimicked ERC-20 to create BRC20, extending Ordinals’ capabilities to fungible tokens. BRC20 supports Deploy, Mint, and Transfer operations, each requiring the two-step commit-and-reveal process, making transactions more complex and costly.
Using real-world data as an example:
The highlighted section shows the inscription content. After deserialization:
ARC20, derived from the Atomicals protocol, reduces transaction complexity by binding each unit of ARC20 token directly to a satoshi, reusing Bitcoin’s transaction framework. After a two-step commit-and-reveal issuance, transfers between ARC20 tokens occur simply by transferring the associated satoshis. ARC20’s design aligns more closely with the literal meaning of “colored coins”—adding new meaning to existing coins, creating new tokens whose value never falls below the underlying bitcoin, much like gold or silver jewelry.
Client-Side Validation and Next-Gen Asset Protocols
Client-Side Validation (CSV), proposed by Peter Todd in 2017 alongside the concept of single-use seals, refers to a model where data is stored off-chain, commitments are made on-chain, and validation occurs client-side. This concept has partial precedents in earlier asset protocols. Current CSV-based asset protocols include RGB and Taproot Assets (Taro).
RGB
Beyond client-side validation, RGB uses Pedersen hashing as a commitment mechanism and supports output blinding. When sending a payment request, recipients do not need to disclose their receiving UTXO—instead, they send a hash, enhancing privacy and censorship resistance. However, when the token is spent, the blinding secret must be revealed to the recipient to validate transaction history.
Additionally, RGB introduces AluVM for enhanced programmability. During client-side validation, users must receive the full transaction history of the token—from the current transaction back to its genesis—to ensure finality. Only after verifying the entire history can the validity of the received asset be confirmed.
Taproot Assets
Developed by Lightning Labs, the team behind the Lightning Network, Taproot Assets enables instant, high-volume, low-cost transfers of assets over the Lightning Network. Designed entirely around the Taproot protocol, it enhances privacy and scalability.
Witness data is stored off-chain and verified on-chain. Off-chain storage can reside locally or in repositories called “Universes” (similar to Git repositories). Verification requires access to all historical data from asset issuance onward, propagated via the Taproot Assets gossip layer. Clients can cross-validate using local copies of the blockchain.
Taproot Assets uses Sparse Merkle Sum Trees to store global asset state—high storage overhead but efficient verification. Proof of inclusion/non-inclusion allows transaction validation without tracing full transaction histories.
Scaling: Bitcoin’s Eternal Challenge
Despite having the highest market cap, security, and stability, Bitcoin is drifting further from its original vision of being “a peer-to-peer electronic cash system.” Limited block capacity results in low TPS, high fees, and long confirmation times, making Bitcoin impractical for frequent, high-volume transactions. Over the past decade, numerous protocols have attempted to solve this.
Payment Channels and Lightning Network: The Bitcoin Purist Approach
The Lightning Network operates by establishing bidirectional payment channels. Any two users can open a channel, and interconnected channels form a network, enabling indirect payments via multi-hop routing.
For instance, if Alice and Bob wish to conduct multiple transactions without recording each on the Bitcoin blockchain, they can open a payment channel. They can transact countless times within this channel, with only two on-chain records: one when opening and another when closing the channel. This drastically reduces confirmation time and eases blockchain congestion.
Currently, the Lightning Network hosts over 14,000 nodes, more than 60,000 channels, and carries over 5,000 BTC in total capacity.
Sidechains: The Ethereum Path Within Bitcoin
Stacks
Stacks positions itself as Bitcoin’s smart contract layer, using its native token (STX) as gas. It employs a microblock mechanism, synchronizing with Bitcoin so both chains confirm blocks simultaneously—a process known as “anchoring.” Each Stacks block corresponds to a single Bitcoin transaction, enabling higher throughput. Since block production is synchronized, Bitcoin acts as a rate limiter for Stacks, protecting against denial-of-service attacks.
Stacks achieves consensus via PoX (Proof of Transfer), a dual-helix mechanism where miners send BTC to STX stakers to compete for block production rights. Winning miners earn STX rewards, while stakers proportionally receive BTC sent by miners. Although native tokens incentivize miners to maintain historical ledgers, such incentives could theoretically exist without them (as seen in RSK).
Transaction data on Stacks is secured on Bitcoin via OP_RETURN, storing hashes of Stacks transactions in Bitcoin scripts. Stacks nodes can retrieve these hashes using Clarity’s built-in functions.
Stacks is almost a Layer-2 chain for Bitcoin, yet cross-chain deposits and withdrawals remain imperfect. After the Nakamoto upgrade, Stacks supports Bitcoin transactions for withdrawals, but complexity prevents on-chain validation, relying instead on a multisig committee for withdrawal verification.
RSK
RSK uses merge-mining, allowing Bitcoin miners to help secure RSK blocks at near-zero cost and earn extra rewards. RSK lacks a native token—BTC (converted to RBTC) serves as gas. It features its own execution engine compatible with the EVM.
Liquid
Liquid is a consortium sidechain of Bitcoin with permissioned node access, where fifteen members are responsible for block production. It uses a lock-and-mint model: assets enter Liquid by sending BTC to a multi-sig address on Bitcoin; exiting involves sending L-BTC to a multi-sig address on the Liquid chain. Security relies on an 11-of-15 multisig threshold.
Focused on financial applications, Liquid offers SDKs tailored for financial services. The current TVL on the Liquid network is approximately 3,000 BTC.
Nostr Assets: Reinforcing Centralization
Originally named NostrSwap, Nostr Assets began as a BRC20 trading platform. On August 3, 2023, it upgraded to the Nostr Assets Protocol, supporting asset transfers across 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 their Nostr public-private keys. Except for deposit and withdrawal operations, all transactions on the Nostr Assets protocol are zero-gas and encrypted. Transaction details are stored on Nostr relays, retrieved quickly and efficiently via IPFS, and support natural language interaction without requiring complex interfaces.
Nostr Assets offers users a simple and convenient way to transfer and trade assets. Leveraging the traffic effect of the Nostr social protocol, it may find broad application in the future. However, fundamentally, it is merely a method of controlling (custodial) wallets via Nostr messages. Users deposit assets into the Nostr Assets relay via Lightning Network transfers—effectively placing funds into a centralized exchange. When users wish to transfer assets within Nostr Assets, they send signed messages via their Nostr keys to the server, which verifies and updates internal ledgers without executing actual transactions on the Lightning Network or mainchain—enabling zero gas fees and high TPS.
BitVM: Programmability and Infinite Scaling
"Any computable function can be verified on Bitcoin"
— Robin Linus, creator of BitVM
Proposed by ZeroSync founder Robin Linus, BitVM uses existing Bitcoin opcodes (OP_BOOLEAN, OP_NOT) to construct NAND logic gates, decomposing programs into combinations of primitive NAND circuits. The root of the complex spend script is embedded in a Taproot transaction, enabling low-cost on-chain storage. According to computation theory, any logic can be built from NAND gates, meaning BitVM could theoretically achieve Turing completeness on Bitcoin—capable of performing any computation—though practical limitations remain.
BitVM retains a peer-to-peer model, borrowing ideas from OP Rollups, with two roles: prover and verifier. They jointly construct a transaction and deposit collateral. The prover submits a result; if the verifier computes a different outcome, they submit a fraud proof on-chain to slash the prover’s bond.
“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
While BitVM improves programmability, how does it relate to scaling? In fact, BitVM was conceived from the start for off-chain computation and on-chain verification—the naming of prover and verifier reveals this intent.
Its ideal use cases are minimally trusted bridges and ZKP-based scaling (ZK Rollups). BitVM emerged out of necessity—given the difficulty of gaining community support to add new opcodes, developers had to work within existing opcode constraints to build new functionality.
BitVM introduces a new scaling paradigm but faces significant real-world challenges:
• Too early: While EVM has a full VM architecture, BitVM currently only validates whether a string is 0 or 1.
• Storage overhead: Constructing programs with NAND gates may require hundreds of MB of data and billions of taptree leaves.
• Peer-to-peer limits: Currently limited to two-party interaction, the prover-challenger model has incentive issues. Efforts are underway to scale to 1-N or N-N models, resembling ideal OP Rollups (single honest party assumption).
Conclusion
From this comprehensive review, it is clear that due to limitations in mainnet processing power and computational capability, Bitcoin must move computation off-chain to cultivate a richer, more diverse ecosystem.
On one hand, client-side validation schemes perform computation and validation off-chain, storing critical data in certain Bitcoin transaction fields. These treat Bitcoin as a distributed log system, leveraging its censorship resistance and reliability to ensure data availability—akin in some ways to sovereign rollups. These solutions don’t require modifying Bitcoin’s protocol layer, enabling flexible protocol construction and offering higher feasibility today, though they cannot fully inherit Bitcoin’s security.
On the other hand, efforts continue toward on-chain verification—attempting to enable arbitrary computation on Bitcoin using existing tools, potentially combining zero-knowledge proofs for efficient scaling. However, these approaches remain highly experimental, with prohibitively high computational costs, unlikely to be viable in the short term.
Some might ask: given that Ethereum and other blockchains already offer high-speed computation, why reinvent the wheel on Bitcoin?
Because It's Bitcoin.
Because it's Bitcoin.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@CGVFOF
