Author: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio

1. 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 ecological technology. With the development of technology, 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 such as Ordinals, leading to a new development climax.

From an overall perspective of these development processes and the related technologies produced, we can see the connections between them and 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 avoiding Bitcoin network being subjected to DOS attacks. Bitcoin's developers also believe that the core blockchain should not have Turing completeness to avoid some attacks and network congestion.

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

Common types of Bitcoin script instructions:

Keywords:

1. Constants, e.g., OP0, OPFALSE
2. Flow control, e.g., OPIF, OPNOTIF, OP_ELSE, …
3. Stack, e.g., OP_TOALTSTACK (pushes the input onto the alternative stack, removing it from the main stack), …
4. Strings, e.g., OPCAT (concatenates two strings, now disabled), OPSIZE (pushes the length of the top element of the stack as an integer, without popping the element)
5. Bitwise logic, e.g., OPAND, OPOR, OP_XOR
6. Arithmetic logic, e.g., OP1ADD (adds 1 to the input value), OP1SUB (subtracts 1 from the input value)
7. Encryption, e.g., OPSHA1 (hashes the input using the SHA-1 algorithm), OPCHECKSIG ()
8. Pseudo-keywords
9. Reserved keywords

Common types of Bitcoin script instructions:

Scripts:

1. Standard transactions paying to a Bitcoin address (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, multi-signature (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 parts in the following chart indicate the instructions that have been removed.

String Operations

(3) Arithmetic Operations

Why reduce instructions? Security is only one aspect of the 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 that directly meets the needs of users, with complete instructions and system functions, rather than a large protocol that requires cooperation.

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 the perspectives of economics and technology, and there is a possibility of creating an alternative chain to Bitcoin. However, from the basic characteristics of Bitcoin and the perspective of layered design, almost only Bitcoin can serve as a basic infrastructure for a layer network. Even if there are alternative chains, they are at most a product of a 1.5 layer. At this level, only Bitcoin is the genuine article, and the chains that can serve as alternatives are at most second-rate goods.

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 solve this problem, Satoshi Nakamoto hosted a soft fork on September 12, 2010, adding a limit that blocks cannot exceed 1 MB in size. Satoshi Nakamoto pointed out that this limit was temporary and that the block limit could be gradually increased in a controllable manner in the future to meet the needs of expansion.

The following figure shows the fork history of Bitcoin:

As Bitcoin became more popular, the problems of network transaction congestion and increasing confirmation times became more serious. 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 8 MB. However, core developers such as Greg Maxwell, Luke Jr, and Pieter Wuille opposed this approach, believing that it would raise the threshold for 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 in the future, the block limit can be gradually increased in a controllable manner to meet the needs of expansion." 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 of ongoing controversy. For example, BCH had a block size of 8 MB, which was later increased to 32 MB. BSV had a block size of 128 MB. 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 in this article, we will see that on the Bitcoin mainnet, Segwit and Taproot have also to some extent increased the block space from 1 MB to 4 MB.

Bitcoin forks are a form of development exploration, attempting to support more needs through their own changes. These needs include user needs, miner needs, investor needs, developer needs, 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.

Colored Coins

The concept of colored coins was first proposed by eToro CEO Yoni Assia in an article published 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 published 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 two main ways:

1) Based on OPRETURN: For example, Open Assets proposed by Flavien Charlon in 2013, which uses OPRETURN (proposed in Bitcoin v 0.9.0) to store a small amount of data on Bitcoin, initially limited to 40 bytes and later increased to 80 bytes. The opcode is stored in the script and the "coloring" and transactions are completed through external reading. (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.

MasterCoin (OMNI)

JR Willett published the concept of MasterCoin on January 6, 2012, and named it the "Bitcoin Second Whitepaper." The project was officially launched through an ICO in July 2013, ultimately raising 5120 BTC (valued at $500,000 at the time). MasterCoin differs from Colored Coins in that it establishes a complete node layer to maintain 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 OPRETURN to store data on the BTC network. However, unlike colored coins, assets in Counterparty do not exist in the form of UTXO, but are transferred through OPRETURN-loaded information. When an asset holder signs a transaction with special data using the holding address, the asset is transferred. 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 fall under the broader category of "Bitcoin 2.0."

1.4. Bitcoin's Imperfections and Layered Protocols

The imperfections (or limitations) of the Bitcoin system mainly manifest 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 concept of "Bitcoin balance" is a derivative of Bitcoin wallet applications. UTXO (Unspent Transaction Outputs) is the core concept of Bitcoin transaction generation and verification. Transactions form a chain structure, and all legitimate Bitcoin transactions can be traced back to the output of one or more previous transactions, with the source of these chains being mining rewards and the end being the current unspent transaction output.

So in the real world, there are no bitcoins, only UTXO. Bitcoin transactions consist of inputs and outputs, and each transaction spends one input and generates one output, which is the "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. Ethereum's major new feature is smart contracts, and due to the consideration of smart contracts, it is difficult to implement Turing-complete smart contracts based on UTXO. The account model is naturally object-oriented, and for each transaction, a corresponding account is recorded (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 limitation 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 the capabilities of Bitcoin's script language. 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 avoiding Bitcoin network being subjected to DOS attacks. Bitcoin's developers also believe that the core blockchain should not have Turing completeness to avoid some attacks and network congestion. However, it is also because of these limitations that the Bitcoin network cannot run more complex programs. The lack of support for 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 problem of mining. The basic Bitcoin mining algorithm is to allow miners to slightly modify the block header millions of times until the hash of the modified version is less than the target value. However, this mining algorithm is susceptible to two forms of centralization attacks. The first is the use of ASICs (Application-Specific Integrated Circuits) and computer chips designed specifically for the task of Bitcoin mining, which can increase efficiency by thousands of times, leading to a more centralized and capital-intensive mining process. The second form of centralization occurs when most Bitcoin miners no longer locally verify blocks but rely on centralized mining pools to provide block headers. 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 Visa's 2000 transactions per second, it would increase by 1 MB every three seconds (1 GB per hour, 8 TB per year). The low transaction throughput has also sparked controversy within the Bitcoin community. While larger blockchains can improve performance, the issue of centralization risk arises.

From the perspective of the product lifecycle, some minor imperfections in Bitcoin can be improved within the existing system, but if these problems can be addressed in a new system, the limitations of the old system can be completely disregarded. Since a new blockchain system is being created, these minor functional improvements can be designed and upgraded as part of the new system.

Layered Design

Layered design is a method and methodology for humans to deal with complex systems by dividing the system into multiple hierarchical structures and defining the relationships and functions between 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 makes it easy to understand, easy to implement, and easy to improve in modules. For example, the ISO/OSI seven-layer model in computer networks, but in specific implementations, some layers can be combined, such as the specific network protocol TCP/IP, which is a four-layer protocol. The advantages of protocol layering include independence between layers, good flexibility, separability in structure, 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, and the disappearance of the founder are not shortcomings, but rather the characteristics that a foundational layer network should have.

Note: The author provides a more detailed explanation of protocol layering in "A Comprehensive Overview of the Basic Knowledge System for Building Bitcoin Layer 2 (Layer 2) 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. On the Bitcoin blockchain itself, this exploration has also produced many results, essentially in the form of block expansion and capacity expansion. They mainly manifest in the following aspects.

2.1. OP_RETURN

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

Use of OP_RETURN

OPRETURN is a script opcode used to terminate the script and return the top value of the stack. This opcode is similar to a return function in programming languages. In Bitcoin's history, the functionality of the OPRETURN 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 blockchain.

Further Changes to the Functionality of OP_RETURN

In the Bitcoin Core v0.9.0 upgrade, "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 and later increased to 80 bytes.

Storing data on the blockchain:

Changing OPRETURN to always return false had interesting results. Since no operations or data are evaluated after OPRETURN, 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 attach larger data to the blockchain facilitated innovative applications, 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 maximum script size limit of 520 bytes. As a result, network operators decided to increase the maximum transaction volume 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.

Segregated Witness (SegWit)

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 BIP 141. SegWit slightly modifies the data structure of transactions in Bitcoin blocks to address the following issues:

1) Transaction malleability problem.

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

3) Indirectly increasing block capacity.

The first two primarily increase security and performance, with the third having the most impact on new technologies, effectively 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 because witness data is not included in this limit, to prevent witness data from being abused, 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 BIP 144, including base data and witness data.

SegWit limits Block weight to 4 MB.

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

Taproot - Segregated Witness V2 Version

If you use the word "Taproot" directly, many people would think it's a new concept, but if I tell you that it's the second version of Segregated Witness, most people will understand the connection. The related BIPs for Taproot are 340, 341, and 342, named as follows: BIP 340 (Schnorr Signatures for secp 256k1), BIP 341 (Taproot: SegWit version 1 spending rules), and BIP 342 (Validation of Taproot Scripts).

In November 2021, Taproot officially took effect in the form of a soft fork. This upgrade was a combination of BIP 340, BIP 341, and BIP 342. BIP 340 introduced Schnorr signatures that can simultaneously verify multiple transactions, replacing the Elliptic Curve Digital Signature Algorithm (ECDSA), once again expanding network capacity and accelerating batch transaction processing, making it possible to deploy complex smart contracts. BIP 341 implemented Merkelized Abstract Syntax Tree (MAST) to optimize transaction data storage on the blockchain. BIP 342 (Tapscript) addressed the limitations of Bitcoin's native script capabilities.

The expansion of space by Segregated Witness (SegWit) and Taproot led to the emergence of Schnorr, MAST 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 of expansion and enhancement until the emergence of Taproot technology and related important technologies such as Schnorr, MAST, and Taproot Scripts, which truly opened up Bitcoin's capabilities.

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 an efficient and secure digital signature scheme for signing transactions and messages. It was first described by Claus Schnorr in a paper in 1991. Schnorr is praised for its 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 signature that is 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 transaction fees and improves underlying scalability, as electronic signatures from multisignature setups occupy the same space in a block as signatures from single-party transactions. This feature of Schnorr can be used to reduce the size of multisignature payments and other transactions related to multisignatures, 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 multisignature schemes indistinguishable from traditional single public key spends, making it more difficult for observers to distinguish multisignature spends from single signature spends on the chain. Additionally, in n-of-m multisignature setups, Schnorr makes it more difficult for external observers to determine which participants signed in a transaction 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 process. It's worth noting that Schnorr signatures are backward compatible with BTC's cryptographic algorithms, allowing them to be introduced through a soft fork upgrade.

MAST - Merkelized Abstract Syntax Tree

The abbreviation MAST has a slight ambiguity in its explanation in both Chinese and English. The official BIP (BIP 114) and some articles use the abbreviation MAST as "Merkelized Abstract Syntax Tree." Other sources use "Merklized Alternative Script Trees" (MAST) translated into Chinese as "Merkelized Alternative Script Trees." Personally, I feel it's best to maintain the usage in the Bitcoin official BIP protocol.

The concept behind MAST comes from two concepts, Abstract Syntax Tree (AST) and Merkle Tree.

AST is a knowledge domain in computer science related to compiler theory and formal language theory. It 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 edges represent their relationships. 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 target code generation processes. In simple terms, 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 the 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 if a transaction exists in a block, without needing to download the entire block, saving bandwidth.

To generate a Merkle tree, each element needs to be 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 is repeated until only one identifier remains, called the "Merkle root," which is a concise identifier marking the entire set.

When verifying whether an element belongs to a set, the owner of 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 short, the technology behind AST allows you to divide a program into multiple small blocks, while the Merkle tree allows 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 developers familiar with programming can clarify the relevant logic by organizing a MAST process.

Since the MAST abstract syntax tree exists, there is a need to expand the capabilities of Bitcoin's native syntax, leading to the creation of Taproot Scripts.

Taproot Scripts

In the BIP 342 protocol, Tapscript is introduced. Taprootscript is an upgraded version of the original Bitcoin script, also referred to as a language. In reality, it is a collection of opcodes with commands that support the implementation of two other BIPs. Taprootscript 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 birth of Ordinals, as the Ordinals protocol uses the script-path spend scripts of Taproot to implement additional data.) For more detailed information, please refer to the official website: BIP-0342.

The current capabilities of TaprootScript have not been fully utilized, and future developments will demonstrate its power. For example, the connection technology between Bitcoin's layer one network and layer two network should make more use of Taproot, MAST, and TaprootScripts.

2.3. Ordinals, Inscriptions, BRC 20, and Other Protocols

With the existence of Segwit, Taproot, Schnorr, MAST, and Taproot Scripts in the Bitcoin ecosystem, these foundational tools have led to the emergence of new applications. The initial applications are lightweight and simple.

Ordinals Protocol, Inscriptions, BRC 20

The birth of the Ordinals protocol is highly related to the concept of "sat." 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. In the protocol, regardless of how sat is transferred between different wallets, its ordinal identifier remains unchanged. A Bitcoin full node 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 on sats. By combining SegWit and Taproot, the Ordinals protocol can engrave a file of less than 4 MB, known as an inscription, for each sat on a Bitcoin block. Inscriptions can contain various forms of information, such as text, images, videos, etc. The image below is a screenshot of a sample inscription.

In simple terms, the numbering scheme 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. The combination of the two allows 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" on a specific sat, hence the origin of the term "inscriptions."

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

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

Other Protocols - Atomicals, ARC 20

The birth of the Atomicals protocol was quite dramatic. The founder, Arthur, initially wanted to develop a DID project on 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 posted the first tweet outlining the concept of the Atomicals protocol, and after several months of development, the Atomicals protocol went live on September 17, 2023. Later, 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 BRC 20, deploying fungible tokens on Atomicals results in ARC 20. Readers interested in ARC 20 can further read about it here.

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 for operations.

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 processing all tuple allocations, any unallocated Runes Tokens will be allocated to the first non-OPRETURN output, and the rest can be engraved with Runes Tokens by allocating the Runes protocol to the OP_RETURN output containing the protocol message.

Issuance of Runes: Homogeneous token tracking based on UTXO. If the protocol message has a second data push, it is an 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 basic 26-bit readable symbol, similar to the symbols used in Ordinals names, and currently, the only valid characters are A to Z. DECIMALS indicates the number of decimal places to be used when issuing Runes. If SYMBOL has not been assigned, the Runes Token will be assigned an ID value (starting from 1). If SYMBOL has already been assigned, or is BITCOIN, BTC, or XBT, no new runes will be created. This is the special feature of the Runes protocol. It does not link balance records to wallet addresses, but rather stores records in the UTXO itself.

New Runes Tokens start from the issuance transaction, specifying the supply, symbol, and decimal places, and allocating that supply to specific UTXOs. UTXOs can contain any number of rune tokens, regardless of their size. UTXOs are only used to track balances. The transfer function then uses this 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, while not relying on off-chain data, having no native tokens, and being very suitable for Bitcoin's native UTXO model.

Other Protocols - BTC Stamps, SRC 20, SRC 721

The Bitcoin Stamps system, released by Mike In Space in March 2023, was initially a concept verification project on Counterparty (an L2 for Bitcoin that has existed since 2014). Due to updates to its underlying protocol, Stamps has fully transitioned to Bitcoin and is now known 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.

The main difference between Stamps and Ordinals lies in their architecture. This is because Stamps stores their metadata in multi-signature unspent transaction outputs (UTXOs), while Ordinals stores their metadata in the "witness" part of Bitcoin transactions. This architectural difference reflects the choices made by developers. Stamps' UTXO approach makes them unprunable, thus appearing permanent, despite their higher manufacturing cost compared to Ordinals minting. In contrast, Ordinals' use of witness data ultimately makes them prunable, with lower manufacturing costs compared to Stamps.

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

After the emergence of BTC Stamps, SRC 20 and SRC 721 have also emerged, with principles similar to BRC 20. BRC-20 is built on the Ordinals protocol, while SRC-20 is built on BTC STAMPS. Readers interested in SRC 20 and SRC 721 can further read the related documents.

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

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

With this introduction, the important new technologies on Bitcoin's layer one network have been presented. In terms of future scalability and capability, it will begin to leverage Bitcoin's upper-layer infrastructure, such as Bitcoin's Layer 2 or Lightning Network, to achieve higher layers, such as RGB. Articles in this area are recommended for further reading, such as "A Comprehensive Overview 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 shows the architecture and construction path for future Web3.0 applications," or other articles on Bitcoin Layer 2 construction or architectural design.

3. Usage Methods of New Technologies and Future Development Needs

From the previous two sections, we can see that the development of Bitcoin technology is essentially about block 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 low, 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 expand the language's ability to handle complex scenarios. However, this capability expansion will also increase the difficulty of Bitcoin development and understanding, as these script developments are not in high-level languages. And this part of the capability expansion will lag behind users' understanding and learning speed for block capacity expansion.

Because block 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 BRC 20 are emerging. Almost all current applications on the Bitcoin mainnet are exploring applications after block 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, using the above basic elements to build functionality. Its Shnorr signature + MAST contract + Bitcoin L2 solution for the BTC L2 network is a good case for learning the connection between the first and second layers. There will be more diverse 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 Bitcoin's first and second layers, then the capability expansion 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 scenarios for capability expansion.

3.2. Future Development Needs

```

The most direct reason for the emergence of blockchain technology is digital currency, so the issuance and management of assets are the most direct needs in the Bitcoin or blockchain field. Whether it's exploring colored coins, BRC 20, ARC 20, or applications like ICO and IDO on Ethereum, they are all exploring asset issuance. Applications like Uniswap, Lending, and AMM are asset management applications, and these applications 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 Layer 2.

Once the needs for asset issuance and management 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 for large-scale applications in the Web3.0 era is described in my article "Observing Bitcoin Layer 2 from the Perspective of State Machines, which shows the architecture and construction path for future Web3.0 applications."

The construction path is a process of continuously meeting needs and can be divided into three stages: short-term, medium-term, and long-term. The short-term is a simple stage of applications generated by new technologies on the Bitcoin mainnet and simple construction based on the chain's Layer 2, completing major capability expansions to meet various financial applications. The medium-term involves the mid-to-late stage of construction based on the chain's Layer 2 and construction based on distributed systems, meeting various financial and trust applications. The long-term involves the completion of large-scale construction based on the Bitcoin ecosystem to truly build the Web3.0 era.

References

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

https://en.bitcoin.it/wiki/Script

https://en.bitcoin.it/wiki/Segregated_Witness

https://en.bitcoin.it/wiki/Taprootactivationproposals

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

"Explanation: What is Bitcoin Merkleized Abstract Syntax Tree?" https://baijiahao.baidu.com/s?id=1709873918363821702

https://github.com/bitcoin/bips

https://bitcoinops.org/en/topics/tapscript/

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