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

Recently, the script ecosystem, led by BRC20, has taken the market by storm, with various scripts experiencing over a hundredfold increase. Bitcoin on-chain transactions are severely congested, with average Gas reaching over 300 sat/vB. Simultaneously, the airdrop from Nostr Assets further captures market attention, and protocol design whitepapers like BitVM and BitStream are proposed, indicating the burgeoning potential of the Bitcoin ecosystem.

The Aqua Labs Research team, through a comprehensive review of the current state of the Bitcoin ecosystem, covering technological advancements, market dynamics, legal regulations, etc., conducts an in-depth analysis of Bitcoin technology and examines market trends. We aim to provide a panoramic perspective on the development of Bitcoin. The article begins by revisiting the fundamental principles and developmental history of Bitcoin, then delves into the technological innovations of the Bitcoin network, such as the Lightning Network and Segregated Witness, while making predictions about its future development trends.

Asset Issuance: Starting with Colored Coins

The essence of the Script ecosystem lies in providing ordinary individuals with the right to issue assets with low barriers, accompanied by simplicity, fairness, and convenience. The emergence of the script protocol on Bitcoin occurred in 2023, but as early as 2012, there existed the concept of utilizing Bitcoin for asset issuance, known as Colored Coins.

Colored Coins: Early Attempts

Colored Coins refer to a set of technologies using the Bitcoin system to record the creation, ownership, and transfer of assets other than Bitcoin. This technology can be employed 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, distinguishing them from other Bitcoin UTXOs, thereby introducing heterogeneity among homogeneous bitcoins. Through the Colored Coins technology, issued assets possess many characteristics identical to Bitcoin, including prevention of double-spending, privacy, security, transparency, and resistance to censorship, ensuring the reliability of transactions.

It’s worth noting that the protocol defined by Colored Coins is not implemented by typical Bitcoin software. Specific software is required to identify transactions related to Colored Coins. Clearly, Colored Coins only hold value within communities that recognize the Colored Coins protocol; otherwise, the colored attributes of heterogeneous Colored Coins will be lost, reverting 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 almost impossible for the Colored Coins protocol to be merged into the largest consensus Bitcoin-Core software through a soft fork.

Open Assets

In late 2013, Flavien Charlon introduced the Open Assets Protocol as one implementation of Colored Coins. Asset issuers use asymmetric cryptography to calculate asset IDs, ensuring that only users with the private key for the asset ID can issue identical assets. For asset metadata, the OP_RETURN opcode is used to store the metadata in the script, referred to as the “marker output,” which stores colored information without contaminating UTXOs. Since it utilizes Bitcoin’s public-private key cryptographic tools, asset issuance can be performed through multisignature mechanisms.

EPOBC

In 2014, ChromaWay introduced the EPOBC protocol, which stands for Enhanced, Padded, Order-Based Coloring. The protocol comprises two types of operations: genesis and transfer. The genesis operation is used for the issuance of assets, while the transfer operation facilitates the transfer of assets. The asset type cannot be explicitly encoded or differentiated, and each genesis transaction issues a new asset, determining its total quantity during issuance. EPOBC assets must be transferred using the transfer operation, and if an EPOBC asset is used as an input in a non-transfer operation transaction, the asset will be lost.

Additional information about EPOBC assets is stored through the nSequence field in Bitcoin transactions. The nSequence field is a reserved field in Bitcoin transactions consisting of 32 bits. Its lowest six bits are used to determine the transaction type, and bits 6–12 are used for padding to meet the anti-dust attack requirements of the Bitcoin protocol. The advantage of using the nSequence field to store metadata information lies in not requiring additional storage. As there is no asset ID for identification, each transaction involving an EPOBC asset must be traced back to the genesis transaction to determine its category and legitimacy.

Mastercoin/Omni Layer

Compared to the aforementioned protocols, Mastercoin has seen more successful commercial implementation. In 2013, Mastercoin conducted the first-ever ICO in history, raising 5000 BTC and ushering in a new era. The widely known USDT, initially issued on the Bitcoin blockchain, was introduced through the Omni Layer.

Mastercoin exhibits a lower degree of dependency on Bitcoin, opting to maintain most of its state off-chain, with only minimal information stored on-chain. Mastercoin essentially treats Bitcoin as a decentralized log system, using any Bitcoin transaction to broadcast changes in asset operations. The validation of transaction effectiveness involves continuously scanning the Bitcoin blockchain and maintaining an off-chain asset database. This database preserves the mapping relationship between addresses and assets, with addresses reusing the Bitcoin address system.

Early Colored Coins primarily used the OP_RETURN opcode in scripts 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 (transaction input script) from the transaction. The main reason for this separation is to prevent nodes from attacking by modifying the input script. However, it comes with a benefit: effectively increasing block capacity, allowing for more storage of witness data.

Taproot introduces an important feature called MAST, enabling developers to include metadata for any asset in outputs using Merkle Trees. It leverages Schnorr signatures to enhance fungibility and scalability, and supports multi-hop transactions through the Lightning Network.

Ordinals & BRC20 and Simulated Trading: A Grand Social Experiment

In a broad sense, Ordinals consist of four components:

A BIP for sequencing sats An indexer that uses the Bitcoin Core Node to track the position (ordinal) of all satoshis A wallet for handling ordinal-related transactions A block explorer to identify ordinal-related transactions Of course, the core is the BIP/protocol itself. Ordinals define a sorting scheme (starting from 0 based on the order they are mined), assigning numbers to the smallest unit in Bitcoin, Satoshis. This imparts heterogeneity to originally homogeneous Satoshis, introducing scarcity.

It can reuse the infrastructure of BTC, including single signatures, multi-signatures, time locks, height locks, etc., without the need to explicitly create ordinal numbers. It offers good anonymity and leaves no explicit on-chain footprint. However, the drawbacks are evident, as a large number of small and unused UTXOs can increase the size of the UTXO set, potentially leading to what is known as a dust attack. Additionally, the space occupied by the index is significant, requiring specific information each time spending a particular sat:

Blockchain header Merkle path to the coinbase transaction that created that sat Coinbase transaction that created that sat To prove that a specific sat is included in a specific output.

Inscription, in this context, is engraving arbitrary content onto sats. The specific method involves placing the content into the taproot script-path spend scripts, completely on-chain. The inscribed content is serialized according to the HTTP response format, pushed into non-executable scripts in spend scripts, known as “envelopes.” Specifically, inscription involves adding OP_FALSE before conditional statements, placing the inscribed content in a non-executable conditional statement in JSON format. The size of the inscribed content is limited by the taproot script, totaling no more than 520 bytes.

Since taproot spending scripts require existing taproot outputs to be spent, inscription requires two steps: commit and reveal. In the first step, a taproot output committing to the inscribed content is created. In the second step, the inscribed content and the corresponding Merkle Path are used to spend the taproot output from the previous step, revealing the inscribed content on-chain.

The original purpose of inscription was to introduce non-fungible tokens (NFTs) to BTC. However, new developers have created BRC20, mimicking ERC20 on its basis, bringing the ability to issue fungible assets to Ordinals. BRC20 includes operations like Deploy, Mint, Transfer, etc., with each operation requiring both commit and reveal steps. The transaction process is more complex, with higher costs.

Using real data as an example:

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

The ARC20 protocol derived from Atomicals aims to simplify transactions by binding each unit of ARC20 tokens to satoshis, reusing the Bitcoin transaction system. After issuing assets through commit and reveal steps, transfers between ARC20 tokens can be directly accomplished by transferring the corresponding satoshis. The design of ARC20 aligns more with the literal definition of Colored Coins — adding new content to existing tokens to create new tokens, where the value of the new token is no lower than the original token, resembling gold and silver jewelry.

Client-Side Validation (CSV) and Next-Generation Asset Protocols

Client-side validation, proposed by Peter Todd in 2017, involves off-chain data storage, on-chain commitments, and client-side verification. Currently, asset protocols supporting client-side validation include RGB and Taproot Assets (Taro).

RGB

In addition to client-side validation, RGB uses Pedersen hash as a commitment mechanism and supports output blinding. When requesting a payment, the UTXO receiving the token does not need to be publicly disclosed; instead, a hash value is sent, enhancing privacy and resistance to censorship. When spending the token, the blinded value needs to be revealed to the recipient to verify transaction history.

Additionally, RGB introduces AluVM for increased programmability. During client-side validation, users not only verify incoming payment information but also receive all transaction history from the payer, tracing back to the asset’s genesis transaction for finality. Verifying all transaction history ensures the validity of received assets.

Taproot Assets:

Developed by Lightning Labs, Taproot Assets enable the instant, high-volume, low-cost transfer of issued assets on the Lightning Network. Designed entirely around the Taproot protocol, it enhances privacy and scalability.

Witness data is stored off-chain, verified on-chain, and can exist locally or in information repositories called “Universes” (similar to Git repositories). Witness verification requires all historical data from asset issuance, disseminated through the Taproot Assets gossip layer. Clients can cross-verify using a local blockchain copy.

Taproot Assets use the Sparse Merkle Sum Tree to store the global state of assets, incurring high storage costs but offering efficient verification. Proof of inclusion/non-inclusion allows verification of transactions without backtracking asset transaction history.

Scalability: Bitcoin’s Eternal Proposition

Despite having the highest market value, security, and stability, Bitcoin deviates from its initial vision of a “peer-to-peer electronic cash system.” Limited block capacity makes Bitcoin unable to handle large and frequent transactions, prompting various protocols to address this issue over the past decade.

Payment channels and Lightning Network: The Bitcoin Orthodox Solution

The Lightning Network operates by establishing payment channels. Users can create payment channels between any two parties, connect channels to form a more extensive payment channel network, and even make payments indirectly between users without a direct channel. For example, if Alice and Bob want to conduct multiple transactions without recording each on the Bitcoin blockchain, they can open a payment channel between them. They can perform numerous transactions within this channel, only requiring two blockchain recordings: once when opening the channel and another when closing it. This significantly reduces waiting times for blockchain confirmations and alleviates the burden on the blockchain.

Currently, the Lightning Network has over 14,000 nodes, 60,000 channels, and a total capacity exceeding 5000 BTC.

Sidechains: The Ethereum Approach in Bitcoin

Stacks

Stacks positions itself as Bitcoin’s smart contract layer, using its native token as the Gas token. Stacks employs a micro-block mechanism, evolving in sync with Bitcoin, where their blocks are confirmed simultaneously. In Stacks, this is referred to as an “anchored block.” Each Stacks transaction block corresponds to a single Bitcoin transaction, achieving higher transaction throughput. With blocks generated simultaneously, Bitcoin acts as a rate limiter for creating Stacks blocks, preventing denial-of-service attacks on its peer network.

Stacks achieves consensus through the dual-spiral mechanism of Proof of Transfer (PoX). Miners send BTC to STX stakers to compete for the right to mine blocks, and successful miners receive STX rewards after successfully mining a block. During this process, STX stakers receive a proportionate amount of BTC sent by the miner. Stacks aims to incentivize miners to maintain the historical ledger by issuing native tokens, although incentivization can still be achieved without native tokens (as seen in RSK).

For transaction data in the Stacks blockchain, the hash of transaction data is stored in the Bitcoin transaction script using the OP_RETURN bytecode. Stacks nodes can retrieve Stacks transaction data hashes stored in Bitcoin transactions through Clarity’s built-in functionalities.

Stacks can be considered as almost a Layer 2 chain for Bitcoin; however, there are still some flaws in the movement of assets across borders. After the Nakamoto upgrade, Stacks supports sending Bitcoin transactions to complete asset movements, but the complexity of transactions makes them unverifiable on the Bitcoin chain. Asset movements can only be verified through a multisignature committee.

RSK

RSK utilizes a merged-mining algorithm, where Bitcoin miners can assist RSK in block production at almost no cost, earning additional rewards. RSK does not have a native token and continues to use BTC (RBTC) as the Gas Token. RSK has its own execution engine compatible with the Ethereum Virtual Machine (EVM).

Liquid

Liquid is a federated sidechain of Bitcoin with permissioned node access, overseen by fifteen members responsible for block production. Assets are transferred using the lock-and-mint mechanism, where assets are sent to the multisignature address on Liquid using BTC, enabling the assets to enter the Liquid sidechain. To exit, L-BTC is sent to the multisignature address on the Liquid chain. The security of the multisignature address is set at 11 out of 15.

Liquid focuses on financial applications and offers developers an SDK related to financial services. The Total Value Locked (TVL) on the Liquid network is currently approximately 3000 BTC.

Nostr Assets: Centralization Reinforced

Nostr Assets, originally named NostrSwap, serves as a BRC20 trading platform. Upgraded to Nostr Assets Protocol on August 3, 2023, it supports the transfer of all assets within the Nostr ecosystem. Lightning Network handles asset settlement and security. Nostr Assets enables users to send and receive Lightning Network assets using Nostr public and private keys. Transactions on the Nostr Assets protocol, excluding deposits and withdrawals, are gas-free, encrypted, and stored on the Nostr Protocol relay using IPFS for fast and efficient access. It 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, potentially finding significant applications in conjunction with the traffic effects of the Nostr social protocol. However, fundamentally, it is a method of controlling (custody) wallets using Nostr messages. Users deposit assets into the Nostr Assets relay by transferring them on the Lightning Network, akin to depositing assets into a centralized exchange. When users want to transfer and trade assets within Nostr Assets, they send messages signed with Nostr keys to the server. After verification, the server records the transactions internally, bypassing execution on the Lightning Network or the mainnet, achieving zero gas fees and high TPS.

BitVM: Programmability and Infinite Scaling

“Any computable function can be verified on Bitcoin.”

— Robin Linus, creator of BitVM

BitVM, proposed by Robin Linus, the founder of ZeroSync, utilizes existing Bitcoin OP Codes (OP_BOOLEAN, OP_NOT) to form AND and NOT gate circuits, breaking down programs into primitive AND and NOT gate circuits. It places the root of the spend script into Taproot transactions for low-cost on-chain storage. According to computational theory, all logical computations can be constructed using AND and NOT gate circuits, theoretically making BitVM Turing complete and capable of performing all computations on Bitcoin. However, there are many practical limitations.

BitVM operates in a P2P mode, following the concept of OP Rollup. There are two roles: prover and verifier. In each transaction, both prover and verifier collaboratively build a transaction, depositing collateral. The prover provides results, and if the verifier calculates different results, they submit a fraud proof to the chain to penalize the prover. BitVM’s primary use case is for minimal trust bridges and ZKP scaling (ZK Rollup). BitVM’s proposal is a compromise due to the difficulty of gaining support in the Bitcoin community for increasing OP_CODE complexity. It utilizes existing OP_CODEs to implement new functionalities.

BitVM introduces a new paradigm for scaling, but there are numerous challenges in practice:

• Too Early: While EVM has a comprehensive VM architecture, BitVM has only one function to verify if a string is 0 or 1.

• Storage Overhead: Constructing programs with NAND gates may require hundreds of megabytes of data, with billions of taproot leaves.

• P2P: The current model involves interactions between two parties, and the prover-challenger structure has incentive issues. There are considerations to extend to 1-N or N-N, similar to the ideal OP Rollup (single honest assumption).

After the discussion on BitVM, we can shift our focus to the one-stop BRC20 tool solution.

The one-stop BRC20 tool solution

1. Fair Launch

The multitude of assets in the BRC20 space can be overwhelming, making effective management crucial for users. Hence, the one-stop BRC20 tool has gained popularity by swiftly obtaining valuable inscriptions for users in a low-gas manner, thereby achieving a fairer launch for BRC assets.

1. Unlocking Liquidity: Innovative Signature Solution Breaks BRC Asset Liquidity Bottlenecks

Due to the unique nature of BRC assets, liquidity has consistently been a challenge for the entire industry. The one-stop BRC20 tool, through its innovative signature solution, successfully completes BRC asset transactions via swap, providing users with a more flexible and efficient solution to effectively unlock liquidity.

1. Fair Sales: Addressing Issuance Challenges

The one-stop BRC20 tool not only facilitates one-click publication of inscriptions and batch transfer of inscriptions but also addresses industry pain points by rapidly locking inscriptions and completing inscription on-chain processes with low gas. All of these efforts are geared towards providing users with a fairer and more efficient sales experience.

Conclusion

A comprehensive review of the text indicates that due to the limitations in processing and computing power of the Bitcoin mainnet, Bitcoin must move computations off-chain to foster a more thriving and diverse ecosystem. Currently, there are two main solutions:

On one hand, off-chain computing and client-side verification solutions leverage certain fields in Bitcoin transactions to store crucial information, treating the Bitcoin mainnet as a distributed log system to ensure the availability of key data, similar to Sovereign Rollups. While this approach doesn’t require modifications to Bitcoin’s protocol layer and provides higher feasibility, it cannot fully inherit Bitcoin’s security.

On the other hand, some teams are working on on-chain verification, attempting to implement arbitrary computations on Bitcoin using existing tools and efficiently scale with zero-knowledge proof technology. However, these solutions are still in early stages, with high computation costs and unlikely short-term implementation.

Against this backdrop, the one-stop BRC tool becomes a notable solution. By offering a low-gas method to swiftly acquire valid inscriptions, facilitating fair launches of BRC assets, and addressing liquidity challenges and fair sales through innovative signature schemes, the one-stop BRC tool demonstrates its value in the current ecosystem. Despite the technical challenges facing the Bitcoin ecosystem, the one-stop BRC tool provides users with a more flexible and efficient trading experience, contributing a unique solution to Bitcoin’s development.

Of course, some may wonder why not turn to Ethereum, as Ethereum and other blockchains possess high computing power similar to Bitcoin. Why go through the process of re-implementing transactions on Bitcoin?

Because it is Bitcoin.

Reference：

https://wizardforcel.gitbooks.io/masterbitcoin2cn/content/appdx8.html https://github.com/chromaway/ngcccbase/wiki/EPOBC_simple https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki https://twitter.com/LNstats https://twitter.com/robin_linus/status/1723472140270174528 https://github.com/fiksn/bitvm-explained https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork https://mirror.xyz/0x5CCF44ACd0D19a97ad5aF0da492AC0388469DfE9/_k3vtpI7a5cQn5iISH7-riECpyudfI4BTeeeBMwNYDQ

Support Partner： CGV

Disclaimer: This post is for general informational purposes only and does not constitute investment advice, recommendations, or a solicitation to buy or sell any securities. It should not be used as the basis for making any investment decision and should not be relied upon for accounting, legal, tax advice, or investment recommendations. You are encouraged to consult your own advisers regarding legal, business, tax, or other related matters concerning any investment decisions. Certain information included here may have been obtained from third-party sources, including portfolio companies of funds managed by Aquarius. The opinions expressed in this post are those of the authors and do not necessarily reflect the views of Aquarius or its affiliates. These opinions are subject to change without notice and may not be updated.