Original author: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio
1. Main explorations and conflicts of Bitcoin’s original technology
The original technology of Bitcoin has always had a conflict between large-scale applications and the capabilities that Bitcoin should have. Do large-scale applications and transaction scale mean more complex transaction instructions and larger transaction space? Does it mean that all functions must be implemented on the single Bitcoin system? In the early days, when the Bitcoin ecosystem technology was not well developed, these phenomena seemed to be problems of Bitcoin itself. With the development of technology, many questions will get clearer answers.
This article lists some related issues, as well as the process of generating and solving these issues. Through this article, you can see the correlation between these issues and technology, as well as the changes in the Bitcoin main chain and related "test chains". Bitcoin technology has been explored by different projects and teams (including Ethereum, which is an exploration of the imperfections of Bitcoin), but the changes on the Bitcoin main network have not been obvious enough until the emergence of technologies such as Taproot, which promoted the emergence of protocols such as the Ordinals protocol, and re-entered a new development climax.
Looking at these development processes and the related technologies that have emerged as a whole, we can see the connections between them and infer more development directions and overall architecture.
1.1. Bitcoin scripting language and several deletion instructions
Bitcoin's programming language is a reverse Polish scripting language without loop statements and conditional control statements (Taproot & Taproot Script will expand this capability later). Therefore, people often say that Bitcoin's scripting language is not Turing complete, which leads to certain limitations of Bitcoin's scripting language.
Of course, due to these limitations, hackers cannot use this scripting language to write some infinite loops (which will cause network paralysis) or some malicious code that can cause DOS attacks, thus preventing the Bitcoin network from being attacked by DOS. Bitcoin developers also believe that the core blockchain should not have Turing completeness to avoid some attacks and network congestion.
However, it is precisely because of these limitations that the Bitcoin network cannot run other complex programs and cannot complete some "useful" functions. Some blockchain systems developed later directly changed this in order 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. For example: OP_ 0, OP_FALSE
2. Process control. Such as: OP_IF, OP_NOTIF, OP_ELSE, ...
3. Stack. For example: OP_TOALTSTACK (push the input into the item of the auxiliary stack and delete it from the main stack), ...
4. Strings. For example: OP_CAT (concatenate two strings, disabled), OP_SIZE (push the length of the string at the top of the stack into the stack (no need to pop the element))
5. Bit logic. Such as: OP_AND, OP_OR, OP_XOR
6. Arithmetic logic. For example: OP_ 1 ADD (input value plus 1), OP_ 1 SUB (input value minus 1)
7. Encryption. For example: OP_SHA 1 (input uses SHA-1 algorithm HASH.), OP_CHECKSIG()
8. Pseudo Keywords
9. Reserved Keywords
Common types of Bitcoin script instructions:
script:
1. Standard transaction paying to a Bitcoin address (pay-to-pubkey-hash)
2. Standard Bitcoin Generate Transaction (pay-to-pubkey)
3. Provably Unspendable/Deletable Outputs
4. Anyone-Can-Spend Output
5. Guessing Trading
The five standard types of transaction scripts include: Pay to Public Key Hash (P2P KH), Pay to Public Key, Multi-Signature (limited to up to 15 keys), Pay to Script Hash (P 2 SH), and Data Output (OP_RETURN).
There is a detailed description on the webpage: https://en.bitcoin.it/wiki/Script.
Remove Bitcoin support instructions
There have been many cases of deleting instructions in the history of Bitcoin. In the chart below, the red part is the instruction that has been deleted.
String Operations
(3) Arithmetic operations
Why do we need to delete instructions? Security is only one aspect of the consideration. If we look at deleting instructions from the perspective of layered design, we will understand its rationality. Doing so can make the underlying protocol more basic and stable. Perhaps Satoshi Nakamoto was aware of this problem from the beginning, otherwise he would not have taken the initiative to delete instructions. Our ordinary thinking is to build a small system that directly meets the needs of users and has perfect instructions and system functions, rather than a large protocol that requires collaboration.
This has led to the fact that only Bitcoin is suitable as a layer 1 network. I have analyzed this phenomenon in the article "Bitcoin's high price will promote the emergence of a new alternative chain". From the perspective of economics and technology, there is a possibility of the emergence of a Bitcoin alternative chain. However, from the perspective of Bitcoin's basic characteristics and layered design, almost only Bitcoin can be used as a layer 1 network infrastructure. Even if there is an alternative chain, it is a 1.5 layer product. At the level of the layer 1 network, the only authentic product is Bitcoin, and the chains that can have some alternative functions are at most A goods.
1.2. Bitcoin fork history, causes and significance
In the history of Bitcoin development, in addition to the issue of deleting instructions, there is also the dispute over block size, which often causes Bitcoin hard forks.
When BTC was first created, there was no limit on the block size so that the number of transactions could be processed at the same time. However, when the price of BTC was very low in the early days, the cost of malicious transactions was also very low. In order to solve this problem, Satoshi Nakamoto hosted a soft fork on September 12, 2010, adding a limit of 1 MB for the block size. Satoshi Nakamoto pointed out that this limit was temporary, and the block limit could be increased in a controllable and gradual manner in the future to meet the needs of capacity expansion.
The following figure shows the history of Bitcoin forks:
As Bitcoin became more popular, the problems of network transaction congestion and increased confirmation time 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 limit to 8 MB. However, core developers such as Greg Maxell, Luke Jr, and Pieter Wuille opposed it, believing that this approach would increase the threshold for running a full node and bring uncontrollable effects. The debate eventually expanded in terms of topics and scope of participation.
From the above content, we can see that Satoshi Nakamoto also expressed that "the block size limit is temporary, and the block limit can be increased in a controllable and gradual manner in the future to meet the needs of expansion." But when will the fork support larger blocks? Can a separate chain to support large blocks solve the problem? In the constant controversy, many cases have also been generated. For example, the BCH block size is 8M, and later increased to 32M. The BSV block size is 128M. In addition to BCH (and the later BSV), many other BTC fork coins appeared during this period. According to BitMEXResearch, at least 50 new fork coins appeared within a year after the BCH fork.
We will see later that Segwit and Taproot on the Bitcoin mainnet have also increased the block size from 1M to 4M to a certain extent.
The fork of Bitcoin is a development exploration, trying to support more needs through its own changes, including user needs, miner needs, investor needs, developer needs, etc.
1.3. Several Typical Explorations in the Development of Bitcoin
After Satoshi Nakamoto left, his successor Gavin Andresen led the establishment of Bitcoin Core and the Bitcoin Foundation. During this period, the exploration of BTC's scalability has always existed, especially in the field of asset issuance.
Colored Coins
eToro CEO Yoni Assia first proposed colored coins in an article published on March 27, 2012. The idea continued to develop, and on forums such as Bitcointalk, the concept of colored coins began to take shape and gain traction. Eventually, Meni Rosenfeld published a white paper detailing colored coins on December 4, 2012.
The idea of colored coins is to represent a wider range of assets and values by adding special annotations (i.e., coloring) to specific parts of Bitcoin. There are a series of entities in the implementation of colored coins, which can be roughly divided into two categories:
1) Based on OP_RETURN: For example, Open Assets proposed by Flavien Charlon in 2013 uses OP_RETURN (proposed in Bitcoin v 0.9.0, which can be used to store small amounts of data on Bitcoin, with an initial limit of 40 bytes, later increased to 80 bytes). The opcode is stored in the script and is read by the outside world to complete the "coloring" and transaction. (This model is similar to Ordinals relying on external indexes to determine the legitimacy of assets).
2) Based on OP_RETURN: A typical example is the EPOBC Protocol proposed by ChromaWay in 2014. The additional information of EPOBC assets is stored in the nSequence field in Bitcoin transactions. The category and legitimacy of each EPOBC asset needs 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 Second Bitcoin White Paper". In July 2013, the project was officially launched through ICO, and 5,120 BTC (worth $500,000 at the time) were eventually raised. The difference between MasterCoin and Colored Coins is that it establishes a complete node layer, which maintains the state model database by scanning Bitcoin blocks, and the database resides in nodes outside the blockchain. This design can provide more complex functions than Colored Coins, such as creating new assets, decentralized exchanges, automated price feedback, etc. In 2014, Tether also launched a stablecoin on Bitcoin through the Mastercoin protocol, which is the well-known 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 UTXO. Instead, information is loaded through OP_RETURN to indicate the transfer of assets. When an asset holder uses the holding address to sign a transaction with special data, the asset is transferred. In this way, Counterparty can realize the issuance and trading of assets and a platform compatible with Ethereum smart contracts.
In addition, there is also a view that Ethereum, Ripple and BitShares also belong to the broader "Bitcoin 2.0".
1.4. Bitcoin’s Imperfections and Layered Protocols
The imperfections (or limitations) of the Bitcoin system are mainly manifested in several aspects (the imperfections in this article are based on the summary in the Ethereum white paper and are not real imperfections.
1. Bitcoin’s Account System UTXO
In current blockchain projects, there are two main ways of keeping records: one is the account/balance model, and the other is the UTXO model. Bitcoin uses the UTXO model, while Ethereum, EOS, etc. use the account/balance model.
In a Bitcoin wallet, we can usually see the account balance, but in the Bitcoin system designed by Satoshi Nakamoto, there is no concept of balance. "Bitcoin balance" is a product derived from the Bitcoin wallet application. UTXO (Unspent Transaction Outputs) is an unspent transaction output, which is a core concept in the generation and verification of Bitcoin transactions. Transactions form a set of chain structures. All legal Bitcoin transactions can be traced back to the output of one or more previous transactions. The source of these chains is mining rewards, and the end is the current unspent transaction output.
Therefore, there is no Bitcoin in the real world, only UTXO. Bitcoin transactions consist of transaction inputs and transaction outputs. Each transaction spends an input and generates an output, and the output generated is the "unspent transaction output", or UTXO.
If you want to implement smart contracts, the UTXO account model has a very big problem. Gavin Wood, the designer of the Ethereum Yellow Paper, has a deep understanding of UTXO. The biggest new feature of Ethereum is smart contracts. Because of 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, and each transaction will be recorded on the corresponding account (nonce++). In order to facilitate account management, a global state is introduced, and each transaction will change this global state. This corresponds to the real world, and every tiny change will change the world. Therefore, Ethereum uses an account system, and later public chains are basically implemented based on various types of account systems.
Another serious flaw of UTXO is that it cannot provide fine-grained control over the withdrawal amount of an account. This is explained in the Ethereum white paper.
2. Bitcoin’s scripting language is not Turing complete
Although the Bitcoin scripting language can support a variety of calculations, it cannot support all calculations. The main missing part is that the Bitcoin scripting language does not have loop statements and conditional control statements. Therefore, we say that the Bitcoin scripting language is not Turing complete. This leads to certain limitations in the Bitcoin scripting language. Of course, due to these limitations, hackers cannot use this scripting language to write some infinite loops (which will cause network paralysis) or some malicious code that can cause DOS attacks, thus avoiding DOS attacks on the Bitcoin network. Bitcoin developers also believe that the core blockchain should not have Turing completeness to avoid some attacks and network congestion. However, it is precisely because of these limitations that the Bitcoin network cannot run its complex programs. The purpose of not supporting loop statements is to avoid infinite loops when confirming transactions.
There is no good reason not to support Turing completeness for security reasons, and there are limits to what non-Turing complete languages can do.
3. Other imperfections of Bitcoin: security and scalability
The problem of centralization in mining. The Bitcoin mining algorithm basically has miners slightly modify the block header thousands of times until eventually a node's modified version of the hash is less than the target value. However, this mining algorithm is vulnerable to two forms of centralization attacks. First, the mining ecosystem is controlled by ASICs (application-specific integrated circuits) and computer chips that are specially designed and thus thousands of times more efficient at the specific task of Bitcoin mining. This means that Bitcoin mining is no longer highly decentralized and egalitarian, but requires huge amounts of capital to participate effectively. Second, most Bitcoin miners no longer actually complete block verification locally; instead, they rely on centralized mining pools to provide block headers. This problem can be said to be serious: currently, the top three mining pools indirectly control about 50% of the processing power in the Bitcoin network.
The scalability issue is an important issue for Bitcoin. With Bitcoin, it grows by about 1 MB per hour. If the Bitcoin network processes 2,000 Visa transactions per second, it will grow by 1 MB every three seconds (1 GB per hour, 8 TB per year). The lower number of transactions has also caused controversy in the Bitcoin community. Although a large blockchain can improve performance, the problem is the risk of centralization.
From the perspective of the product life cycle, some minor imperfections of Bitcoin can be improved in its own system, and 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 ignored. Since a new blockchain system is to be built, these minor functional improvements should also be designed and upgraded when designing the new system.
Layered design
Hierarchical design is a means and methodology for humans to deal with complex systems. It divides the system into multiple hierarchical structures and defines the relationships and functions between layers to achieve modularity, maintainability and scalability of the system, thereby improving the design efficiency and reliability of the system.
For a wide and large protocol system, using layers will have obvious benefits. This makes it easier for people to understand, easier to implement by division of labor, and easier to improve by modules. For example, the seven-layer model design of ISO/OSI in computer networks, but in specific implementations, some layers can be merged. For example, the specific network protocol TCP/IP is a four-layer protocol. Specifically, the advantages of protocol layering are: each layer is independent, flexible, separable in structure, easy to implement and maintain, and can promote standardization.
From the perspective of layered protocols, since Bitcoin is at the most basic bottom layer, its UTXO, non-Turing completeness, long block time, small block capacity, disappearance of the founder, etc. are not disadvantages, but rather characteristics that a layer of the network should have.
Note: The author has a more detailed explanation of protocol layering in "A Basic Knowledge System for Bitcoin Layer 2 Construction V1.5".
2. Important new technologies in the development of Bitcoin (block expansion and capacity expansion)
In the previous section, we discussed the main conflicts and exploration cases of Bitcoin's original technology, but many of them led to hard forks or the creation of new heterogeneous chains. On the Bitcoin blockchain itself, this exploration has also produced many results, which are essentially the expansion of blocks and capabilities. They are mainly manifested in the following aspects.
OP_RETURN
Bitcoin developers have always wanted to expand Bitcoin's capabilities, which can be seen in several aspects:
Use of OP_RETURN
OP_RETURN is a script opcode that terminates the script and returns the value at the top of the stack. This opcode is similar to the return function in programming languages. The functionality of the OP_RETURN opcode has been modified many times in Bitcoin's history, and it is now mainly used as a method of storing data on the ledger. The functionality of the OP_RETURN opcode has changed significantly in the past, and it is now an important mechanism that allows us to store arbitrary data on the chain.
OP_RETURN was originally used to return to the script execution prematurely, and the result of the execution will be presented as the top item of the stack. This opcode originally had an easily exploitable vulnerability, but Satoshi Nakamoto quickly patched the vulnerability.
Further changes to OP_RETURN functionality
In the Bitcoin Core v0.9.0 upgrade, the "OP_RETURN output" script was made into a standard output type, allowing users to append data to "unspendable transaction outputs". The upper limit of the amount of data available in such scripts was initially limited to 40 bytes, and then increased to 80 bytes.
Storing data on the blockchain:
Changing OP_RETURN to always return false had an interesting consequence. Since no opcode or data is evaluated after OP_RETURN, network users began using this opcode to store data in arbitrary formats.
During the Bitcoin Cash (BCH) period, from August 1, 2017 to November 15, 2018, the length of data that could be attached to the OP_RETURN output was extended to 220 bytes. Larger data can promote innovative applications on the blockchain, such as publishing content on blockchain social media.
On BSV, the 220-byte limit remained for a short while. Then, in January 2019, because the OP_RETURN opcode terminates the script in a way that nodes do not validate any subsequent opcodes, nodes do not check if the script is within the maximum script size limit of 520 bytes. As a result, node operators on the network decided to increase the maximum transaction size to 100 KB, giving developers more freedom to innovate applications that can put larger and more complex data into the Bitcoin ledger. There was an application example at that time where someone put an entire website into the BSV ledger.
Although OP_RETURN has some functional extensions, its overall capabilities are still limited. This is why the technology of segregated witness was born.
Segwit
Segregated Witness (SegWit) was first proposed by Pieter Wuile (Bitcoin core developer and co-founder of Blockstream) in December 2015, and later formed Bitcoin BIP 141. Segregated Witness slightly modifies the data structure of transactions in Bitcoin blocks to solve the following problems:
1) Transaction malleability issue.
2) The signature of the transaction transmitted in the SPV proof becomes optional, which can reduce the amount of data transmitted by the Merkle proof.
3) Increase block capacity in disguised form.
The first two items are mainly to increase security and performance, and the third one has the greatest impact on the new technology. It increases the capacity of the block (see the concept of Block weight below), thus laying the foundation for the expansion of Bitcoin's capabilities, so that Taproot (the second version of Segregated Witness) can be further strengthened later.
Although monetization has expanded the block capacity, isolated witness is also subject to the block size limit. Bitcoin's block size limit is 1 M bytes. Since witness data is not included in this limit, in order to prevent witness data from being abused, the total block size is still limited. A new concept called block weight is introduced.
Block weight = Base size * 3 + Total size
Base size is the block size excluding witness data
Total size is the block size (in bytes) of the serialized transaction as described in BIP 144, including base data and witness data.
Segregated witness limits Block weight <= 4M.
Segregated Witness also technically enables the use of the Lightning Network for Bitcoin expansion, but this part will not be introduced in detail here.
Taproot Segregated Witness V2
If you use the word Taproot directly, many people will think it is a new concept, but if you tell you that it is the second version of Segregated Witness, most people will understand the connection. The BIPs related to Taproot are 340, 341, and 342. Their names are: BIP 340 (Schnorr Signatures for secp 256 k 1), 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 is a combination of BIP 340, BIP 341 and BIP 342. BIP 340 introduced Schnorr signatures that can verify multiple transactions at the same time, replacing the elliptic curve digital signature algorithm (ECDSA), once again expanding network capacity and speeding up the processing of batch transactions, making it possible to deploy complex smart contracts; BIP 341 implemented the Merkle Abstract Syntax Tree (MAST) to optimize the storage of transaction data on the blockchain; BIP 342 (Tapscript) uses Bitcoin's script coding language to expand the shortcomings of Bitcoin's native scripting capabilities.
The expansion of the space of Segregated Witness (Segwit) and Taproot has led to the emergence of Schnorr, MAST tree, and Taproot Scripts. Their mission is to expand the functionality of the Bitcoin mainnet.
2.2. Schnorr, MAT, Taproot Scripts
Through Section 2.1, we have seen Bitcoin’s continuous exploration of expansion and capacity. It was not until the emergence of Taproot technology and several related important technologies Schnorr, MAST, and Taproot Scripts that Bitcoin’s capabilities were truly opened up.
Schnorr Signatures
The development of Taproot, while expanding its capabilities, has certain requirements for signature algorithms, so Schnorr signatures began to appear and were used to replace the Elliptic Curve Digital Signature Algorithm (ECDSA). Schnorr signature is a digital signature scheme that can sign transactions and messages efficiently and securely. It was first described by Claus Schnorr in a 1991 paper. Schnorr is praised for its simplicity, provable security, and linearity.
Advantages of Schnorr signatures:
1) Schnorr signatures have multiple advantages, including efficiency, enhanced privacy, while retaining all the features 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 enables multiple parties to generate a signature that is valid for the sum of their public keys. Signature aggregation allows signatures from multiple signers to be combined into a single signature.
Key aggregation can reduce transaction fees and improve underlying scalability, as electronic signatures from multi-signature setups take up the same space in a block as signatures from single-party transactions. This feature of Schnorr can be used to reduce the size of multi-signature payments and other multi-signature-related transactions, such as Lightning Network channel transactions.
3) Another important feature of Schnorr signature is its immutability.
4) Schnorr also provides a lot of privacy advantages. It can make multi-signature schemes indistinguishable from traditional single public keys from the outside, and Schnorr makes it more difficult for observers to distinguish between multi-signature spending and single-signature spending in on-chain activities. In addition, in n-of-m multi-signature settings, Schnorr makes it more difficult for external observers to determine which participants signed a transaction and which did not by looking at the on-chain information.
Schnorr signatures were implemented in BIP-340 as part of the Taproot soft fork upgrade and activated on November 14, 2021 at block height 709,632. Schnorr makes BTC's digital signatures faster, more secure, and easier to process. It is worth noting that Schnorr signatures are backwards compatible with BTC's cryptographic algorithm, so they can be introduced through a soft fork upgrade.
MAST Abstract Syntax Tree
There is a little ambiguity in the abbreviations of MAST in Chinese and English. The official BIP (BIP 114) and some articles use the abbreviation of MAST: Merklized Abstract Syntax Tree. Some other materials use Merklized Alternative Script Trees (MAST) translated into Chinese Merklized Alternative Script Tree (MAST). In the book "Mastering Bitcoin", and in an article, this abbreviation is used: https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade.
The Merkle Abstract Syntax Tree and the Merklized Alternative Script Tree (MAST) look the same in terms of functionality. From a translation perspective, I personally feel that I should keep the usage in the official Bitcoin BIP protocol.
The concept behind MAST comes from two concepts, abstract semantic tree and Merkle tree.
Abstract semantic tree (AST) belongs to the knowledge field of compilation theory and formal linguistics in computer science. Abstract semantic tree is an intermediate representation in the compilation process, which is used to represent the semantic structure of source code. It converts the source code into a tree structure, in which each node represents a semantic unit and the edge represents the relationship between them. Abstract semantic tree plays an important role in the lexical analysis and syntax analysis stages of the compiler, helping the compiler understand the meaning of the source code and perform subsequent optimization and target code generation. In layman's terms, abstract semantic tree (AST) is a method of describing a program by dividing it into independent small pieces, which makes the program easier to analyze and optimize. In order to generate an AST, all equations and their premises need to be connected with arrows until all premises are found. The figure below is the AST of a script.
On the other hand, the Merkle tree can be used to verify whether an element belongs to a set without knowing the entire set. For example, Bitcoin's Simplified Payment Verification Wallet (SPV wallet) uses the Merkle tree to verify whether a transaction exists in a block, which does not require downloading the entire block and saves bandwidth.
To generate a Merkle tree, each element is first hashed once to generate its own unique identifier; then these identifiers are paired and hashed again to generate the identifier of this pair of identifiers; this is repeated until only one identifier is left, called the "Merkle root", which is a short and concise identifier that marks the entire set.
When verifying whether an element belongs to a set, someone who owns the entire set can provide you with all the identifiers on the path from that element to the Merkle root. This proves that the element is indeed in the set.
In short, the technology behind AST allows you to split a program into multiple small pieces, and the Merkle tree allows us to verify that these small pieces are indeed part of a complete program without having to expose the entire program. This is the basic principle of MAST, which allows spenders to replace conditions that are not used in a single transaction with a Merkle proof. The advantages are: reducing transaction size, improving privacy, and supporting larger contracts.
There are many specific MAST tree examples on the Internet. People who understand program development can understand the relevant logic by sorting out a MAST process.
Now that we have the MAST abstract syntax tree, we need to expand the capabilities of Bitcoin's native syntax, so Taproot Scripts came into being.
Taproot Scripts
Tapscript script was added to the BIP 342 protocol. Taprootscript is an upgraded version of the original Bitcoin script. It can also be called a language, but it is actually a collection of opcodes with commands that facilitate 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 subsequent birth of Oridnals, because the Ordinals protocol uses Taproot's script-path spend scripts to implement additional data). For more information, please visit the official website:
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
Currently, the capabilities of TaprootScript have not been fully utilized, and more construction in the future will reflect its power. For example, the connection technology between the first layer and the second layer of Bitcoin network should use more Taproot, MAST and TaprootScripts.
2.3. Ordinals, Inscriptions, BRC 20 and other agreements
With the basic tools such as Segwit, Taproot, Schnorr, MAST, and Taproot Scripts in the Bitcoin ecosystem, new applications have begun to emerge. The applications in the initial stage are lightweight and simple applications.
Ordinals, Inscriptions, BRC 20
The birth of the Ordinals protocol is highly related to the concept of sats. The protocol proposes the concepts of ordinals and inscriptions. Ordinals refer to a numbering scheme that assigns a number to each Satoshi (Satoshi) on the Bitcoin network in the order of mining. In the protocol, no matter how sats are transferred between different wallets, their ordinal identification remains unchanged. Bitcoin full nodes running the Rodarmor open source software ORD can track these numbered Satoshis. This provides a mechanism for people to accurately track each Satoshi and conduct independent verification.
Inscriptions are information burned on Satoshi. By combining SegWit and Taproot, the Ordinals protocol can burn a file of less than 4 MB for each Satoshi on the Bitcoin block, which is the inscription. Inscriptions can contain various forms of information, such as text, pictures, videos, etc. The following is a screenshot of a sample inscription.
Simply put, the ordinal numbering scheme provides each Satoshi with a unique traceable number, which makes Satoshi non-homogeneous. Inscriptions can add indivisible data information to the ordinal, similar to artistic creation on a blank piece of paper. The combination of the two gives Bitcoin a new NFT standard. The essence of Ordinals is actually very simple. It is more like an NFT protocol. However, unlike ETH or other public chains, where the NFT metadata (MetaData) is mostly stored in IPFS or centralized servers, the metadata of Ordinals is embedded in the witness field (Witness Data) of the transaction, just like being "engraved" on a specific Satoshi. This is also the origin of the word inscription.
BRC-20: Inspired by the Ordinals protocol, Twitter user @domodata created the Bitcoin experimental alternative token standard BRC-20 on March 8, 2023. The Ordinals protocol creates BTC network NFTs by giving different "attributes" to each satoshi, while BRC-20 creates FTs on BTC by giving a unified "format" and "attributes", that is, homogeneous tokens.
BRC-20 writes a JSON text into the BTC inscription through the Ordinals protocol to deploy token contracts, mint and transfer tokens (Depoly, Mint, Transfer). The key to deployment lies in the token name, total supply, maximum single minting amount, etc. For transfers or buy/sell transactions, additional NFTs will be engraved to track the off-chain balance. The "first come, first served" minting mechanism brings fair issuance and participation opportunities; at the same time, due to the relatively imperfect BTC ecological infrastructure, there is a certain learning threshold, and low liquidity makes BRC-20 tokens can be easily pulled up, ordi, sats, rats and other BRC 20 tokens have opened a wave of wealth creation myths.
Other protocols - Atomicals, ARC 20
The birth of the Atomicals protocol was quite dramatic. When the Ordinals protocol was first released, founder Arthur wanted to develop a DID project on it, but during the development process, he found that the Ordinals protocol had many limitations and was not conducive to supporting some of the features he wanted to achieve. So, on May 29, 2023, Arthur posted the first tweet on Twitter about the conception of the Atomicals protocol. After several months of development, the Atomicals protocol was launched on September 17, 2023. Later, the Atomicals protocol derived four major concepts, including Dmint, Bitwork, ARC-20, and RNS. In the future, AVM and split plans will also be launched.
Similar to Ordinals and BRC 20, deploying homogeneous tokens on top of Atomicals forms ARC 20. For readers interested in ARC 20, you can read further.
https://docs.atomicals.xyz/arc20-tokens
Other protocols - Rune
As the development progressed, Casey Rodarmor, the founder of Ordinals, published an article pointing out that BRC-20 tokens have the "adverse consequences of UTXO proliferation" and suggested Runes as an alternative based on UTXO. Existing protocols generally have problems such as complex protocol implementation, poor user experience, garbage unspent transaction outputs (UTXO), and the need for native tokens for operations.
Runes are transferred using OP_RETURN, and the first data output in the protocol message is decoded into a sequence of integers, which are interpreted as a sequence of (ID, OUTPUT, AMOUNT) tuples. If the number of decoded integers is not a multiple of three, the protocol message is invalid. ID is the Token ID to be transferred, OUTPUT is the output index to be assigned (that is, the output to which it is assigned), and AMOUNT is the amount of Runes to be assigned. After all tuple assignments are processed, any unassigned Runes Tokens will be assigned to the first non-OP_RETURN output, and the rest can be burned by assigning the Runes protocol to the OP_RETURN output containing the protocol message.
Runes issuance: UTXO-based homogeneous token tracking. If the protocol message has a second data push, it is an issuance transaction. The second data push is decoded into two integers, SYMBOL, DECIMALS. If there are any other remaining integers, the protocol message is invalid. SYMBOL is a base 26-bit readable symbol similar to the symbols used in the names of Ordinals, and the only valid characters are A to Z at the moment. DECIMALS is the number of digits after the decimal point that should be used when showing the issuance of Runes. If SYMBOL has not been assigned, the Runes Token will be assigned an ID value (starting at 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. Instead of linking the balance record to the wallet address, it puts the record in the UTXO itself.
The new Runes Token starts with an issuance transaction that specifies the supply, symbol, and number of decimal places, and assigns that supply to a specific UTXO. A UTXO can contain any number of Rune tokens, regardless of their size. UTXOs are only used to track balances. The transfer function then uses that UTXO, splits it into multiple new UTXOs of any size, containing different numbers of runes, and sends the record to others. Compared to BRC-20, Runes reduces one layer of server consensus, becomes simpler, and does not rely on off-chain data, has no native tokens, and is very suitable for Bitcoin's native UTXO model.
Other protocols - BTC stamps, SRC 20, SRC 721
The Bitcoin Stamps system was launched by Mike In Space in March 2023 as a proof-of-concept project on Counterparty (a Bitcoin L2 that has existed since 2014). Stamps has fully pivoted to Bitcoin due to an update to its underlying protocol, now known as SRC-20, last summer. Founder Mike originally envisioned Stamps as a way to mint permanent Bitcoin NFTs. However, the protocol has expanded to replicate BRC-20, a mass fungible token that has flourished on Bitcoin since Casey Rodarmor launched Ordinals in January 2023, thanks to the rise of the inscription craze.
The main difference between Stamps and Ordinals is in the architecture. This is because Stamps store their metadata in a multi-signature unspent transaction output (UTXO), while Ordinals store their metadata in the "witness" portion of a Bitcoin transaction. This difference in design reveals a trade-off made by the developers. That is, the UTXO approach of Stamps makes them non-prunable and therefore seemingly permanent, even though they are more expensive to produce than Ordinals. Conversely, the way Ordinals use witness data ultimately makes them prunable, and they are cheaper to produce than Stamps.
So while Ordinals may offer the best permanence-to-cost ratio for NFTs in crypto today (on-chain NFTs can also be obtained on Ethereum, but they are relatively more expensive to build than Ordinals), Stamps currently appear to offer the best direct permanence guarantee.
After BTC stamps were created, SRC 20 and SRC 721 were created, and their principles are similar to BRC 20. BRC-20 is based on the Ordinals protocol, while SRC-20 is based on BTC STAMPS. Interested readers can read more about SRC 20 and SRC 721.
https://docs.openstamp.io/introduction/src20-protocol
https://docs.openstamp.io/introduction/src721-protocol
So far, the important new technologies of Bitcoin on the first layer network have been introduced. In the future expansion and capacity expansion, Bitcoin's upper layer facilities, such as Bitcoin's Layer 2 or higher layers such as RGB, which are implemented with the help of the Lightning Network, are used. For articles on this topic, it is recommended to read "A Basic Knowledge System for Bitcoin Layer 2 Construction V1.5" and "Observing Bitcoin Layer 2 from the Perspective of State Machine, You Can See the Architecture and Construction Path of Future Web3.0 Applications", or other articles on Bitcoin Layer 2 construction or architecture design.
3. How to use new technologies and what needs to be developed in the future
Through the content of Section 2, we can see that the technological development of the Bitcoin ecosystem has laid the foundation for larger-scale applications. However, because development requires a process and some related technologies are immature, there is still a big difference between the current popular applications and the final common applications.
3.1. How to use new technologies
From the previous two sections, we can see that the development of Bitcoin technology is essentially the expansion of blocks and capabilities.
In terms of block expansion, segregated witness has led to de facto block expansion. Although there are various proposals to cut out the witness part, the probability of this happening is not high, especially after the witness part is given more meaning.
In terms of expansion capabilities, Taproot, Schnorr, MAST, Taproot Scripts, and other technologies have given Bitcoin more capabilities. In particular, MAST+Taproot Scripts will expand the capabilities of Bitcoin's native scripting language, and several other technologies will expand the ability of Bitcoin language to handle complex scenarios. However, these capacity expansions will also increase the difficulty of Bitcoin development and understanding, after all, these Scripts development is not a high-level language. And this part of the capacity expansion will lag behind the user's understanding and learning speed of block capacity expansion.
Because it is simple to use block expansion, but complex to use capacity expansion, this is the reason why users first write those small picture NFTs into the Bitcoin mainnet and why applications such as BRC 20 are created. Currently, many applications on the Bitcoin mainnet are almost all exploring applications after block expansion. A small number of applications have begun to explore capacity expansion. For example, the first and second layer connection of BEVM is representative, and more functions built with the above basic elements are used. Its BTC L2 solution of Shnorr signature + MAST contract + Bitcoin light node network is a good case for learning to connect the first and second layers. There will be more cases of capacity expansion in the future.
Where should the boundaries of capability expansion be? We can judge from the perspective of layered design. If these capability expansions are more of a connection technology between Bitcoin’s first and second layers, then the capability expansion should not be too complicated. However, based on our rich creativity and the strong appeal of asset issuance and management, some teams or individuals will explore more cases of capability expansion scenarios.
3.2. Future development needs
The most direct reason for the emergence of blockchain technology is digital currency, so asset issuance and asset management applications are the most direct needs in the field of Bitcoin or blockchain. Whether it is the exploration of colored coins to applications such as BRC 20 and ARC 20, or ICO and IDO on Ethereum, they are all exploring asset issuance. Applications such as Uniswap, Lending, and AMM are all asset management applications. These applications have been maturely developed on networks such as Ethereum. With the development of Bitcoin ecological technology, these asset management applications will be transferred to the Bitcoin ecosystem, and more should be carried out on the second layer of Bitcoin.
Only when the needs of issuing and managing assets are met, will there be energy and time to develop large-scale applications in the Web3.0 era (also known as the value era). I have described the system architecture of large-scale applications in the future Web3.0 era in "Observing Bitcoin Layer 2 from the perspective of the state machine, we can see the architecture and construction path of future Web3.0 applications".
The construction path is a process of continuously meeting needs, which can be divided into three stages: short-term, medium-term, and long-term. In the short term, it is a simple stage of applications generated by new technologies on the Bitcoin main network and second-layer construction based on the chain. The generated applications complete the main capacity expansion and meet various financial applications. In the medium term, the middle and late stages of the second-layer construction based on the chain and the second-layer construction based on the distributed system meet various financial applications and trust applications. In the long term, it is a large-scale construction based on the Bitcoin ecosystem to complete the construction of the real Web3.0 era.
References
ABCDE Research Report [ABCDELabs]: Bitcoin’s Past, Present and Future
https://en.bitcoin.it/wiki/Script
https://en.bitcoin.it/wiki/Segregated_Witness
https://en.bitcoin.it/wiki/Taproot_activation_proposals
"Super Detailed Explanation of Segregation Witness", https://blog.csdn.net/t46414704152abc/article/details/105638788
"Questions and Answers: What is Bitcoin's Merkle Abstract Syntax Tree?", https://baijiahao.baidu.com/s?id=1709873918363821702
https://github.com/bitcoin/bips
https://bitcoinops.org/en/topics/tapscript/
