Original author: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio

1. The main exploration and conflict of Bitcoin's original technology

There has always been a conflict between the large-scale application of Bitcoin's original technology and the capabilities that Bitcoin should have. Does large-scale application and transaction volume imply more complex transaction instructions and a larger transaction space? Does it mean that all functions must be implemented on a single Bitcoin system? In the early days, these phenomena seemed to be problems inherent to Bitcoin itself in the underdeveloped state of the Bitcoin ecosystem. With technological development, many of these issues will become clearer.

This article lists some related issues and the process of their generation and resolution. Through this article, we can see the correlation between these issues and technology, as well as the changes in the Bitcoin main chain and related "test chains." Bitcoin's technology has always been explored by different projects and teams (including Ethereum, which is an exploration of Bitcoin's imperfections), but the changes produced on the Bitcoin mainnet have not been significant enough until the emergence of technologies such as Taproot, which has driven the emergence of protocols like Ordinals, leading to a new development climax.

From an overall perspective of these development processes and the related technologies produced, we can speculate on more development directions and the overall architecture.

1.1. Bitcoin's script language and several instruction reductions

Bitcoin's programming language is a reverse Polish notation script language, without loop statements and conditional control statements (which were later expanded by Taproot & Taproot Script). Therefore, it is often said that Bitcoin's script language is not Turing complete, which limits its capabilities.

Of course, due to these limitations, hackers cannot use this script language to write some infinite loops (which would cause network paralysis) or malicious code that could lead to DOS attacks, thus preventing the Bitcoin network from being subjected to DOS attacks. Bitcoin's developers also believe that the core blockchain should not have Turing completeness to avoid certain attacks and network congestion.

However, it is precisely because of these limitations that the Bitcoin network cannot run other complex programs or accomplish some "useful" functions. In order to solve specific problems and meet user needs, some later blockchain systems directly changed this. For example, the language used by Ethereum has Turing completeness.

Common types of Bitcoin script instructions:

Keywords:

1. Constants. Such as: OP_0, OP_FALSE

2. Flow control. Such as: OP_IF, OP_NOTIF, OP_ELSE, …

3. Stack. Such as: OP_TOALTSTACK (pushes the input onto the top of the alt stack and removes it from the main stack), …

4. Strings. Such as: OP_CAT (concatenates two strings, now disabled), OP_SIZE (pushes the string length of the top element onto the stack without popping it)

5. Bitwise logic. Such as: OP_AND, OP_OR, OP_XOR

6. Arithmetic logic. Such as: OP_1ADD (input value plus 1), OP_1SUB (input value minus 1)

7. Encryption. Such as: OP_SHA1 (hashes the input with the SHA-1 algorithm), OP_CHECKSIG ()

8. Pseudo-keywords

9. Reserved keywords

Common types of Bitcoin script instructions:

Scripts:

1. Standard transactions paying to Bitcoin addresses (pay-to-pubkey-hash)

2. Standard Bitcoin generation transactions (pay-to-pubkey)

3. Spendable/unspendable outputs

4. Anyone-Can-Spend outputs

5. Puzzle transactions

The five standard types of transaction scripts include: Pay to Public Key Hash (P2PKH), Pay to Public Key, Multisig (limited to a maximum of 15 keys), Pay to Script Hash (P2SH), and Data Output (OP_RETURN).

Detailed explanations can be found at: Bitcoin Script.

Reduction of Bitcoin-supported instructions

There have been multiple instances of instruction reductions in Bitcoin's history. The red portions in the following charts represent the instructions that have been removed.

(1) String operations

(2)

(3) Arithmetic operations

Why reduce instructions? Security is only one aspect of consideration. If we look at the reduction of instructions from a layered design perspective, we can understand its rationality. This approach can make the underlying protocol more basic and stable. Perhaps Satoshi Nakamoto realized this issue from the beginning, otherwise, he would not have actively reduced the instructions. Our common thinking is to build a small system with complete instructions and system functions that directly meet user needs, rather than a large protocol that requires collaboration.

This has also led to a fact that only Bitcoin is suitable as a layer network. I analyzed this phenomenon in the article "High Bitcoin Prices Will Lead to the Emergence of a New Alternative Chain" from an economic and technical perspective, and there is a possibility of creating alternative chains to Bitcoin. However, from the perspective of Bitcoin's basic characteristics and layered design, almost only Bitcoin can serve as a foundational infrastructure for a layer network. Even if there are alternative chains, they are at most a 1.5-layer product. At this level, only Bitcoin is the genuine article, and any chains that can serve as substitutes are at most second-rate.

1.2. Bitcoin fork history, reasons, and significance

In the development history of Bitcoin, in addition to the issue of instruction reduction, another aspect is the debate over block size, which often leads to hard forks in Bitcoin.

At the beginning of BTC's creation, there was no limit on block size in order to process the same number of transactions in the same time. However, when the early BTC price was very low and the cost of malicious transactions was also very low, to address this issue, Satoshi Nakamoto hosted a soft fork on September 12, 2010, adding a limit that blocks cannot exceed 1MB in size. Satoshi Nakamoto pointed out that this limit was temporary and that in the future, the block limit could be gradually increased in a controllable manner to meet the needs of scaling.

The following is the fork history of Bitcoin:

As Bitcoin became more popular, network transaction congestion and increased confirmation times became increasingly severe. In 2015, Gavin Andresen and Mike Hearn announced that they would implement the BIP-101 proposal in the new version of BitcoinXT, hoping to increase the block size limit to 8MB. However, core developers such as Greg Maxwell, Luke Jr, and Pieter Wuille opposed this, believing that this approach would raise the barrier to running full nodes and bring uncontrollable effects. This debate eventually expanded in terms of topics and participants.

From the above content, we can see that Satoshi Nakamoto also expressed that "the block size limit is temporary and can be gradually increased in a controllable manner to meet the needs of scaling." But when to fork to support larger blocks, and whether creating a separate chain to support large blocks can solve the problem, has led to numerous cases in ongoing controversies. For example, BCH had a block size of 8M, which was later increased to 32M. BSV had a block size of 128M. In addition to BCH (and later BSV), many other BTC forked coins appeared during this period. According to BitMEXResearch, at least 50 new forked coins appeared within a year after the BCH fork.

Later on, we will see that Segwit and Taproot on the Bitcoin mainnet have also to some extent increased the block space from 1MB to 4M.

Bitcoin forks are a form of development exploration, attempting to support more needs through its own changes. These needs include user demands, miner demands, investor demands, developer demands, and more.

1.3. Several typical explorations in Bitcoin development

After Satoshi Nakamoto's departure, his successor Gavin Andresen led the establishment of Bitcoin Core and the Bitcoin Foundation. During this period, there has been ongoing exploration of BTC's scalability, especially in the field of asset issuance.

(1) Colored Coins

The concept of colored coins was first proposed by eToro CEO Yoni Assia in an article on March 27, 2012. This idea continued to develop, and the concept of colored coins began to take shape and gain attention on forums such as Bitcointalk. Eventually, Meni Rosenfeld released a detailed whitepaper on colored coins on December 4, 2012.

The concept of colored coins involves adding special annotations (i.e., coloring) to specific parts of Bitcoin to represent broader assets and value. Colored coins have been implemented in a series of entities, roughly divided into two categories:

1) Based on OP_RETURN: For example, Open Assets proposed by Flavien Charlon in 2013, which uses OP_RETURN (proposed in Bitcoin v0.9.0 and can be used to store small amounts of data on Bitcoin, initially limited to 40 bytes, later increased to 80 bytes). The operation code is stored in the script and completed through external reading to achieve "coloring" and transactions. (This model is similar to Ordinals, which relies on external indexing to determine the legitimacy of assets).

2) Based on OP_RETURN: A typical example is the EPOBC Protocol proposed by ChromaWay in 2014, where additional information about EPOBC assets is stored in the nSequence field of Bitcoin transactions, and the category and legitimacy of each EPOBC asset need to be traced back to the genesis transaction to determine.

(2) MasterCoin (OMNI)

JR Willett released the concept of MasterCoin on January 6, 2012, and named it the "Bitcoin Second Whitepaper." In July 2013, the project was officially launched through an ICO, raising 5120 BTC (valued at $500,000 at the time). MasterCoin differs from Colored Coins in that it establishes a complete node layer, maintaining a state model database by scanning Bitcoin blocks, which resides in nodes outside the blockchain. This design can provide more complex functionality than Colored Coins, such as creating new assets, decentralized exchanges, and automated price feedback. In 2014, Tether also launched a stablecoin on Bitcoin using the Mastercoin protocol, known as Tether USD (OMNI).

(3) CounterParty

Counterparty was officially launched in 2014. Counterparty also uses OP_RETURN to store data in the BTC network. However, unlike colored coins, assets in Counterparty do not exist in the form of UTXOs. Instead, assets are transferred through the loading of information via OP_RETURN, and when an asset holder signs a transaction with specific data, the asset transfer is completed. Through this method, Counterparty can issue and trade assets and provide a platform compatible with Ethereum smart contracts.

In addition, some believe that Ethereum, Ripple, and BitShares also belong to a broader category of "Bitcoin 2.0."

1.4. Bitcoin's imperfections and layered protocols

The imperfections of the Bitcoin system are mainly manifested in several aspects (the imperfections mentioned in this article are summarized based on the Ethereum whitepaper and are not actual imperfections).

1. Bitcoin's UTXO account system

In current blockchain projects, there are mainly two ways of recording: the account/balance model and the UTXO model. Bitcoin uses the UTXO model, while Ethereum, EOS, and others use the account/balance model.

In a Bitcoin wallet, we usually see an account balance, but in the Bitcoin system designed by Satoshi Nakamoto, there is no concept of a balance. The "Bitcoin balance" is a derivative of Bitcoin wallet applications. UTXO (Unspent Transaction Outputs) is the core concept of unspent transaction outputs, which is used in the generation and verification of Bitcoin transactions. Transactions form a chain structure, and all legitimate Bitcoin transactions can be traced back to one or more previous transactions, with the source of these chains being mining rewards and the end being the current unspent transaction outputs.

So in the real world, there are no bitcoins, only UTXOs. Bitcoin transactions consist of inputs and outputs, with each transaction spending one input and generating one output, which is an "unspent transaction output," or UTXO.

If smart contracts are to be implemented, the UTXO account model has significant problems. Gavin Wood, the designer of the Ethereum Yellow Paper, has a deep understanding of UTXO. The biggest new feature of Ethereum is smart contracts, and due to the consideration of smart contracts, it is difficult for Gavin Wood to implement Turing-complete smart contracts based on UTXO. The account model is naturally object-oriented, recording each transaction on the corresponding account (nonce++). To manage accounts easily, a global state is introduced, and each transaction changes this global state. This corresponds to the real world, where every small change alters the world. Therefore, Ethereum uses an account system, and most later public chains are based on various types of account systems.

Another serious flaw of UTXO is that it cannot provide fine-grained control over the withdrawal limits of accounts. This is explained in the Ethereum whitepaper.

2. Bitcoin's script language, non-Turing complete

Although Bitcoin's script language can support multiple calculations, it cannot support all calculations. The main missing feature is that Bitcoin's script language does not have loop statements and conditional control statements. Therefore, we say that Bitcoin's script language is not Turing complete. This limits Bitcoin's script language to some extent. Of course, due to these limitations, hackers cannot use this script language to write infinite loops (which would cause network paralysis) or malicious code that could lead to DOS attacks, thus preventing the Bitcoin network from being subjected to DOS attacks. Bitcoin's developers also believe that the core blockchain should not have Turing completeness to avoid certain attacks and network congestion. However, it is precisely because of these limitations that the Bitcoin network cannot run more complex programs. The purpose of not supporting loop statements is to avoid infinite loops during transaction confirmation.

The reason for not supporting Turing completeness for security is not sufficient. Furthermore, non-Turing complete languages have very limited capabilities.

3. Other imperfections of Bitcoin, security, scalability

The centralization issue of mining, Bitcoin's mining algorithm essentially involves miners making slight modifications to the block header thousands of times until the hash of a modified version is less than the target value. However, this mining algorithm is susceptible to two forms of centralization attacks. First, the mining ecosystem is controlled by ASICs (Application-Specific Integrated Circuits) and computer chips specifically designed to increase efficiency in Bitcoin mining by thousands of times, making Bitcoin mining no longer highly decentralized and egalitarian, but requiring significant capital participation. Second, most Bitcoin miners no longer locally complete block verification; instead, they rely on centralized mining pools to provide block headers. This problem is quite serious: currently, the top three mining pools indirectly control about 50% of the processing power in the Bitcoin network.

Scalability is an important issue for Bitcoin. With Bitcoin, the block size increases by about 1 MB per hour. If the Bitcoin network were to process 2,000 Visa transactions per second, it would increase by 1 MB every three seconds (1 GB per hour, 8 TB per year). The lower transaction frequency has also sparked controversy in the Bitcoin community. While larger blockchains can improve performance, the issue of centralization risk arises.

From the perspective of the product lifecycle, some small imperfections in Bitcoin can be improved within the system, but the improvement methods are limited by the current system. However, if these problems can be solved in a new system, the limitations of the old system can be completely disregarded. Since a new blockchain system is to be created, these small functional improvements can be designed and upgraded together.

Layered Design

Layered design is a method and methodology for humans to deal with complex systems. It involves dividing the system into multiple hierarchical structures and defining the relationships and functions between the layers to achieve modularity, maintainability, and scalability, thereby improving the design efficiency and reliability of the system.

For a broad and extensive protocol system, using layers has obvious benefits. This approach makes it easy to understand, facilitates division of labor, and allows for modular improvements. For example, the ISO/OSI seven-layer model in computer networks, although in specific implementations, some layers can be combined, such as the TCP/IP protocol, which is a four-layer protocol. The advantages of protocol layering include: independence between layers, good flexibility, structural divisibility, ease of implementation and maintenance, and promotion of standardization work.

From the perspective of layered protocols, Bitcoin's characteristics such as UTXO, non-Turing completeness, long block generation time, small block capacity, the disappearance of the founder, etc., are not shortcomings, but rather the characteristics that a foundational network layer should have.

Note: The author provides a more detailed explanation of protocol layering in "A Comprehensive Knowledge System for the Construction of Bitcoin Layer 2 (Layer2) V1.5".

2. Important New Technologies in Bitcoin Development (Block Expansion and Capacity Expansion)

In the previous section, we discussed the main conflicts of Bitcoin's original technology and some exploratory cases, many of which led to hard forks or the creation of entirely new heterogeneous chains. However, these explorations on the Bitcoin blockchain itself have also produced many results, essentially in the form of block expansion and capacity expansion. They are mainly manifested in the following aspects.

2.1. OP_RETURN

Bitcoin developers have always wanted to expand Bitcoin's capabilities, which is evident in several aspects:

(1) Use of OP_RETURN

OP_RETURN is a script opcode used to terminate the script and return the top of the stack. This opcode is similar to a return function in programming languages. In Bitcoin's history, the functionality of the OP_RETURN opcode has been modified multiple times, and it is now mainly used as a method to store data in the ledger. The functionality of the OP_RETURN opcode has undergone significant changes in the past, and it is now an important mechanism that allows us to store arbitrary data on the chain.

Further changes to the functionality of OP_RETURN

In the upgrade to Bitcoin Core v0.9.0, "OP_RETURN outputs" scripts were made into standard output types, allowing users to attach data to "unspendable transaction outputs." The amount of data available in these scripts was initially limited to 40 bytes, then increased to 80 bytes.

Storing data on the blockchain:

Changing OP_RETURN to always return false had interesting results. Since no opcodes or data are evaluated after OP_RETURN, network users began using this opcode to store arbitrary data.

During the Bitcoin Cash (BCH) period, from August 1, 2017, to November 15, 2018, the length of data that could be attached to OP_RETURN outputs was extended to 220 bytes. The ability to include larger data facilitated innovative applications on the blockchain, such as publishing content on blockchain-based social media.

On BSV, the 220-byte limit was retained for a short period. Subsequently, in January 2019, because the OP_RETURN opcode terminates the script in a way that nodes do not verify any subsequent opcodes, nodes also do not check whether the script is within the 520-byte maximum script size limit. As a result, network operators decided to increase the maximum transaction size to 100 KB, giving developers more freedom for application innovation, allowing new applications to store larger and more complex data in the Bitcoin ledger. At that time, there was an example where someone stored an entire website in the BSV ledger.

Although OP_RETURN has some functional expansion, its overall capabilities are still limited. This led to the development of Segregated Witness (SegWit) technology.

(2) SegWit (Segregated Witness)

Segregated Witness, or SegWit, was first proposed by Pieter Wuille (a Bitcoin Core developer and co-founder of Blockstream) in December 2015, and later became Bitcoin BIP141. SegWit slightly modifies the data structure of transactions in Bitcoin blocks to address the following issues:

1) Transaction malleability problem.

2) Making the transmission of transaction signatures optional in SPV proofs, reducing the amount of data transmitted in Merkle proofs.

3) Indirectly increasing block capacity.

The first two items primarily increase security and performance, with the third item having the most impact on new technologies, indirectly increasing block capacity (see the concept of Block weight below), laying the foundation for Bitcoin's capacity expansion, and further strengthening with the subsequent Taproot (the second version of SegWit).

Although SegWit increases block capacity, it is still subject to block size limits. Bitcoin's block size limit is 1 MB, and to prevent abuse of witness data, there are still restrictions on the total block size. A new concept called block weight was introduced.

Block weight = Base size * 3 + Total size

Base size is the block size without witness data.

Total size is the serialized transaction block size (in bytes) as described in BIP144, including base data and witness data.

SegWit limits the Block weight to 4M.

SegWit also technically enables Bitcoin's capacity expansion to use the Lightning Network, which is not detailed here.

(3) Taproot (SegWit V2)

If the word "Taproot" is used directly, many people would think it is a new concept. However, if you were told that this is the second version of SegWit, most people would understand the connection. The BIPs related to Taproot are 340, 341, and 342, named: BIP340 (Schnorr Signatures for secp256k1), BIP341 (Taproot: SegWit version 1 spending rules), and BIP342 (Validation of Taproot Scripts).

In November 2021, Taproot officially took effect in the form of a soft fork. This upgrade was a combination of BIP340, BIP341, and BIP342. BIP340 introduced Schnorr signatures that can simultaneously verify multiple transactions, replacing the elliptic curve digital signature algorithm (ECDSA), once again expanding network capacity and speeding up batch transaction processing, making it possible to deploy complex smart contracts. BIP341 implemented Merkelized Abstract Syntax Trees (MAST) to optimize transaction data storage on the blockchain. BIP342 (Tapscript) addressed the shortcomings of Bitcoin's native script capabilities by extending the Bitcoin script encoding language.

The space expansion brought about by Segregated Witness (SegWit) and Taproot has led to the emergence of Schnorr, MAST (Merklized Abstract Syntax Tree), and Taproot Scripts, all of which are intended to expand the functionality of the Bitcoin mainnet.

2.2. Schnorr, MAST, Taproot Scripts

In Section 2.1, we saw Bitcoin's continuous exploration in terms of scalability and capacity expansion, leading to the development of Taproot technology and several related important technologies, including Schnorr, MAST, and Taproot Scripts, which truly opened up the landscape of Bitcoin's capabilities.

(1) Schnorr Signatures

With the development of Taproot, there were certain requirements for signature algorithms, leading to the emergence of Schnorr signatures to replace the Elliptic Curve Digital Signature Algorithm (ECDSA). Schnorr signatures are a type of digital signature scheme that efficiently and securely signs transactions and messages. It was first described by Claus Schnorr in a paper in 1991. Schnorr signatures are praised for their simplicity, provable security, and linearity.

Advantages of Schnorr Signatures:

1) Schnorr signatures have several advantages, including efficiency, enhanced privacy, while retaining all the functionality and security assumptions of ECDSA. Schnorr signatures can achieve smaller signature sizes, faster verification times, and improved resistance to certain types of attacks.

2) The most significant advantage of Schnorr signatures is key aggregation, which aggregates multiple signatures into one, making the signature valid for the sum of their keys. In other words, Schnorr allows multiple parties to generate a single signature that is valid for the sum of their public keys. Signature aggregation reduces the space occupied in a block by electronic signatures from a multi-signature setup, making it the same as signatures from single-party transactions. This feature of Schnorr can be used to reduce the size of multi-signature payments and other transactions related to multi-signatures, such as Lightning Network channel transactions.

3) Another important feature of Schnorr signatures is their tamper resistance.

4) Schnorr also provides many privacy advantages. It makes it difficult for observers to distinguish multi-signature schemes from traditional single public key spends on the chain. Additionally, in n-of-m multi-signature setups, Schnorr makes it harder for external observers to determine which participants signed in a transaction and which did not by viewing on-chain information.

Schnorr signatures were implemented in BIP-340 as part of the Taproot soft fork upgrade and were activated on block height 709,632 on November 14, 2021. Schnorr makes BTC's digital signatures faster, more secure, and easier to handle. It is worth noting that Schnorr signatures are backward compatible with BTC's cryptographic algorithms, allowing them to be introduced through a soft fork upgrade.

(2) MAST (Merklized Abstract Syntax Tree)

The concept behind MAST comes from two concepts, abstract syntax trees and Merkle trees.

Abstract syntax trees (AST) belong to the knowledge domain of compiler theory and formal language theory in computer science. An abstract syntax tree is an intermediate representation used in the compilation process to represent the semantic structure of source code. It transforms source code into a tree structure, where each node represents a semantic unit, and the edges represent the relationships between them. AST plays an important role in the lexical analysis and syntax analysis stages of a compiler, helping the compiler understand the meaning of the source code and carry out subsequent optimization and code generation processes. In simple terms, an abstract syntax tree (AST) is a method of describing a program by dividing it into independent small blocks, making it easier to analyze and optimize. To generate an AST, all equations and their premises need to be connected with arrows until all premises are found. The image below shows an AST of a script.

On the other hand, a Merkle tree can be used to verify whether an element belongs to a set without needing to know the entire set. For example, Bitcoin's Simplified Payment Verification (SPV) wallet uses Merkle trees to verify whether a transaction exists in a block without downloading the entire block, saving bandwidth.

To generate a Merkle tree, each element is hashed individually to generate a unique identifier for each; then these identifiers are paired and hashed again to generate an identifier for this pair of identifiers; this process continues until only one identifier remains, known as the "Merkle root," which is a concise identifier marking the entire set.

When verifying whether an element belongs to a set, someone with the entire set can provide you with all the identifiers from that element to the Merkle root path. This can prove that the element is indeed in the set.

In summary, the technology behind AST allows you to divide a program into multiple small blocks, while Merkle trees allow us to verify that these small blocks are indeed part of a complete program without exposing the entire program. This is the basic principle of MAST, which allows spenders to replace conditions not used in a single transaction with a Merkle proof, with the advantages of reducing transaction volume, increasing privacy, and supporting larger contracts.

There are many examples of specific MAST trees online, and those familiar with program development can clearly understand the related logic by outlining a MAST process.

Since we have MAST abstract syntax trees, there is a need to expand the capabilities of Bitcoin's native syntax, leading to the emergence of Taproot Scripts.

(3) Taproot Scripts

The BIP342 protocol introduces Tapscript, which is an upgraded version of the original Bitcoin script and can also be referred to as a language. However, it is actually a collection of opcodes with commands that support the implementation of two other BIPs. Tapscript also removes the 10,000-byte script size limit, providing a better environment for creating smart contracts on the Bitcoin network. (This upgrade also laid the foundation for the later development of Oridnals, as the Oridnals protocol uses Taproot's script-path spend scripts to implement additional data). Detailed information can be found on the official website.

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

The current capabilities of TaprootScript have not been fully utilized, and more construction in the future will demonstrate its power. For example, the connection technology between the Bitcoin base layer and the second layer network should make more use of Taproot, MAST, and Taproot Scripts.

2.3. Ordinals, Inscriptions, BRC20, and Other Protocols

With the development of Bitcoin's ecosystem, including SegWit, Taproot, Schnorr, MAST, and Taproot Scripts, these foundational tools have led to the emergence of new applications. The initial applications are lightweight and simple.

(1) Ordinals Protocol, Inscriptions, BRC20

The birth of the Ordinals protocol is highly related to the concept of satoshis. The protocol introduces the concepts of ordinals and inscriptions. Ordinals refer to a numbering scheme that assigns a number to each Satoshi (sat) on the Bitcoin network according to the order of mining. Regardless of how sats are transferred between different wallets, their ordinal identifiers remain unchanged. Bitcoin full nodes running the open-source software ORD by Rodarmor can track these numbered sats, providing a mechanism for precise tracking of each sat and independent verification.

Inscriptions involve engraving information onto sats. By combining SegWit and Taproot, the Ordinals protocol can engrave a file of less than 4MB onto each sat in a Bitcoin block, which is an inscription. Inscriptions can contain various forms of information, such as text, images, and videos. The image below is a screenshot of a sample inscription.

In essence, the numbering scheme of ordinals provides each sat with a unique and traceable number, giving sats non-fungible characteristics. Inscriptions can add inseparable data information to ordinals, similar to creating art on a blank piece of paper. Together, they allow Bitcoin to have a new NFT standard. The essence of Ordinals is actually quite simple; it is more like an NFT protocol, but unlike the metadata of NFTs on Ethereum or other public chains, which are mostly stored on IPFS or centralized servers, the metadata of Ordinals is embedded in the witness data of transactions, as if it were "engraved" onto a specific sat, hence the origin of the term "inscriptions."

BRC-20: Inspired by the Ordinals protocol, Twitter user @domodata created the experimental Bitcoin alternative token standard BRC-20 on March 8, 2023. While the Ordinals protocol creates BTC network NFTs by assigning different "attributes" to each sat, BRC-20 creates fungible tokens on BTC by providing a unified "format" and "attributes."

BRC-20 writes a JSON text into BTC inscriptions using the Ordinals protocol to deploy token contracts, mint tokens, and transfer tokens (Deploy, Mint, Transfer). The key to deployment includes the token name, total supply, and maximum minting amount per transaction. For transfers or buy/sell transactions, additional NFTs are engraved to track off-chain balances. The "first come, first served" minting mechanism has brought about fair issuance and participation opportunities. However, due to the relatively incomplete infrastructure of the BTC ecosystem and a certain learning curve, low liquidity has made BRC-20 tokens easily pumped. Tokens such as ordi, sats, and rats have sparked a wave of wealth creation.

(2) Other Protocols - Atomicals, ARC20

The birth of the Atomicals protocol was quite dramatic. The founder, Arthur, initially wanted to develop a DID project on top of the Ordinals protocol, but during the development process, he found that the Ordinals protocol had many limitations that were not conducive to supporting some of the features he wanted to implement. Therefore, on May 29, 2023, Arthur tweeted the first concept of the Atomicals protocol, and after several months of development, the Atomicals protocol went live on September 17, 2023. Subsequently, the Atomicals protocol gave rise to four major concepts: Dmint, Bitwork, ARC-20, and RNS, and will also introduce AVM and a splitting scheme in the future.

Similar to Ordinals and BRC20, the deployment of fungible tokens on top of Atomicals forms ARC20. Readers interested in ARC20 can further read at https://docs.atomicals.xyz/arc20-tokens.

(3) Other Protocols - Rune

As development progressed, Casey Rodarmor, the founder of Ordinals, published an article pointing out that BRC-20 tokens have "adverse consequences of UTXO diffusion" and suggested using Runes as an alternative based on UTXO. Existing protocols generally suffer from complex protocol implementation, poor user experience, unspent transaction outputs (UTXO) clutter, and the need for native tokens.

The transfer of Runes uses OPRETURN, where the first data output in the protocol message is decoded as a sequence of integers, which are interpreted as (ID, OUTPUT, AMOUNT) tuple sequences. If the decoded number of integers is not a multiple of three, the protocol message is invalid. ID is the Token ID for the transfer, OUTPUT is the output index to be allocated (i.e., which output to allocate to), and AMOUNT is the amount to be allocated. After all tuple allocations are processed, any unallocated Runes tokens will be allocated to the first non-OPRETURN output, while the rest can be engraved onto Runes tokens by including the protocol message in the OP_RETURN output.

Issuance of Runes: Tracking of UTXO-based fungible tokens. If the protocol message has a second data push, it is a issuance transaction. The second data push is decoded as two integers, SYMBOL and DECIMALS. If there are any remaining integers, the protocol message is invalid. SYMBOL is a 26-character readable symbol, similar to the symbols used in Ordinals names, with the only valid characters currently being A to Z. DECIMALS indicates the number of decimal places to be used when issuing Runes. If the SYMBOL has not been allocated, the Runes token will be assigned an ID value (starting from 1). If the SYMBOL has already been allocated, or is BITCOIN, BTC, or XBT, no new runes will be created. This is a special feature of the Runes protocol. It does not link balance records to wallet addresses, but rather stores them in the UTXO itself.

New Runes tokens start from the issuance transaction, specifying the supply, symbol, and decimal places, and allocate the supply to specific UTXOs. UTXOs can contain any number of runes tokens, regardless of their size. UTXOs are only used to track balances. The transfer function then uses the UTXO, splitting it into multiple new UTXOs of arbitrary sizes, containing different amounts of runes, and sends the records to others. Compared to BRC-20, Runes reduces a layer of server consensus, making it simpler, and does not rely on off-chain data, making it suitable for Bitcoin's native UTXO model.

(4) Other Protocols - BTC Stamps, SRC20, SRC721

The Bitcoin Stamps system was released by Mike In Space in March 2023. It was initially a concept validation project on Counterparty (a Bitcoin L2 that has existed since 2014). Due to updates to its underlying protocol, Stamps has fully transitioned to Bitcoin and is now referred to as SRC-20. Founder Mike initially envisioned Stamps as a way to mint permanent Bitcoin NFTs. However, the protocol has expanded to replicate BRC-20, a batch fungible token, which has flourished on Bitcoin due to the rise of inscriptions since Casey Rodarmor introduced Ordinals in January 2023.

The main difference between Stamps and Ordinals lies in their architecture. This is because Stamps stores their metadata in Unspent Transaction Outputs (UTXO) with multi-signatures, while Ordinals stores their metadata in the "witness" part of Bitcoin transactions. This architectural difference reflects the trade-offs made by developers. Stamps' UTXO method makes them unprunable, thus appearing permanent, despite their higher manufacturing cost compared to Ordinals minting. Conversely, Ordinals' use of witness data ultimately makes them prunable, with a lower manufacturing cost compared to Stamps.

Therefore, while Ordinals may provide the best cost for persistence of NFTs in today's crypto field (and can also obtain on-chain NFTs on Ethereum, but their construction cost is relatively higher than Ordinals), Stamps currently seems to offer the best direct guarantee of permanence.

After the emergence of BTC Stamps, SRC20 and SRC721 began to emerge, with principles similar to BRC20. BRC-20 is built on the Ordinals protocol, while SRC-20 is built on BTC Stamps. Readers interested in SRC20 and SRC721 can further read the related documentation.

https://docs.openstamp.io/introduction/src20-protocol

https://docs.openstamp.io/introduction/src721-protocol

Up to this point, the important new technologies on the Bitcoin base layer have been introduced. In terms of future scalability and capability expansion, it is now beginning to leverage higher layers of Bitcoin's infrastructure, such as Bitcoin's Layer 2 or the Lightning Network, to achieve higher layers, such as RGB. Articles in this area are recommended to read "A Comprehensive Summary of the Basic Knowledge System for Bitcoin Layer 2 (Layer 2) Construction V1.5" and "Observing Bitcoin Layer 2 from the Perspective of State Machines, which can see the architecture and construction path of future Web3.0 applications," or other articles on Bitcoin Layer 2 construction or architectural design.

3. Methods of Using New Technologies and Future Development Needs

From the previous two sections, we can see that the development of Bitcoin technology is essentially about block expansion and capability expansion.

In terms of block expansion, Segregated Witness has led to practical block expansion. Although there are various proposals to prune the witness part, the probability of this happening is small, especially after the witness part has been given more meaning.

In terms of capability expansion, technologies such as Taproot, Schnorr, MAST, and Taproot Scripts have given Bitcoin more capabilities. In particular, MAST+Taproot Scripts will expand the capabilities of Bitcoin's native script language, along with several other technologies that will enhance Bitcoin's ability to handle complex scenarios. However, this capability expansion will also increase the difficulty of Bitcoin development and understanding, as these scripts are not high-level languages. And this part of the capability expansion will lag behind the user's understanding and learning speed of block capacity expansion.

Because block capacity expansion is simple to use and capability expansion is complex, this is why users are starting to write small image NFTs onto the Bitcoin mainnet and why applications like BRC20 are emerging. Almost all current applications on the Bitcoin mainnet are exploring applications after block capacity expansion. A small number of applications are beginning to explore capability expansion, such as the first and second layer connection of BEVM, which is a representative example that uses the above basic elements to build functionality. Its Shnorr signature + MAST contract + Bitcoin L2 solution for the BTC light node network is a good case study for learning to connect the first and second layers. There will be more rich examples of capability expansion in the future.

Where should the boundary of capability expansion be? We can judge from the perspective of layered design. If these capability expansions are more about connecting the first and second layers of Bitcoin, then they should not be overly complex. However, due to our rich creativity and the strong attraction of asset issuance and management, some teams or individuals will explore more examples of capability expansion scenarios.

3.2. Future Development Needs

The most direct reason for the emergence of blockchain technology is digital currency, so applications for issuing and managing assets are a direct need in the Bitcoin or blockchain field. Whether it's from the exploration of colored coins to applications like BRC20 and ARC20, or ICOs and IDOs on Ethereum, they are all exploring asset issuance. Applications like Uniswap, Lending, and AMM are asset management applications that have matured on networks like Ethereum. With the development of Bitcoin's ecosystem technology, these asset management applications will transition to the Bitcoin ecosystem, mostly on the Bitcoin second layer.

Once the needs for issuing and managing assets are met, there will be the energy and time to develop large-scale applications belonging to the Web3.0 era (also known as the value era). The system architecture of large-scale applications in the future Web3.0 era is described in my article "Observing Bitcoin Layer 2 from the Perspective of State Machines, which can see the architecture and construction path of future Web3.0 applications."

The path of construction is a process of continuously meeting needs, which can be divided into short-term, medium-term, and long-term stages. The short term is a simple stage of applications generated by new technologies on the Bitcoin mainnet and the construction of simple stages based on-chain. The applications generated in this stage complete the main capability expansion and meet various financial applications. The medium term is the mid-to-late stage of on-chain construction and the construction based on distributed systems, meeting various financial and trust applications. The long term is the completion of large-scale construction based on the Bitcoin ecosystem, completing the construction of the Web3.0 era.

References

(1) ABCDE Research Report "[ABCDELabs]: The Past, Present, and Future of Bitcoin"

(2) https://en.bitcoin.it/wiki/Script

(3) https://en.bitcoin.it/wiki/Segregated_Witness

(4) https://en.bitcoin.it/wiki/Taproot_activation_proposals

(5) "Super Detailed Explanation of Segregated Witness," https://blog.csdn.net/t46414704152abc/article/details/105638788

(6) "Clarification: What is the Bitcoin Merkleized Abstract Syntax Tree?" https://baijiahao.baidu.com/s?id=1709873918363821702

(7) https://github.com/bitcoin/bips

(8) https://bitcoinops.org/en/topics/tapscript/

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