Discussion of the principles and technical details of the Ordinal inscription protocol

Author: CaptainZ, former GametaverseDAO researcher Source: X, @hiCaptainZ

When I was studying the BTC ecology and various inscription projects in the past two weeks, I found that there were very few articles that could clearly introduce the principles and technical details: for example, when the inscription is being cast, How is the transaction initiated, how are the sats in UTXO tracked, where is the engraved content placed in the script, and why does BRC20 require two operations when transferring money? I find that without understanding these technical details, it is difficult to understand the differences between various protocols such as BRC20, BRC420, atomicals, stamps, and Runes. This article will go into the basic knowledge of the BTC blockchain and try to answer the above questions.

BTC block structure

The essence of the blockchain is a multi-user accounting Technology, in computer science terms, is a distributed database. The records (accounts) in each period of time form a block, and then the ledger is expanded according to chronological order.

We used excel to make a table to explain how the blockchain works. An excel file represents a blockchain, in which each separate table represents a block. The blocks are in chronological order from 560331, 560332. to the latest 560336. 560336 will package the latest transactions in the block. The main part of the block is the most common double-entry accounting method in the accounting field. The address on one side is recorded as debit (debit), which is inputs from, and the address on the other side is recorded as credit (credit), which is outputs to. Value corresponds to the BTC amount of the corresponding address. The number of Inputs coins will be greater than the number of Outputs coins, and the difference is the transfer fee at the user level and the handling fee obtained by the miners (bookkeepers). The block header will obtain the height of the previous block, the hash value of the previous block, the creation time (timestamp) of this block, and a random number. So as a decentralized accounting technology, who will grab the accounting rights of the next block? It relies on this random number and its corresponding hash value. Miners with computing power perform a hash calculation on the random number of the current block. The miner who first obtains the hash value that meets the conditions has the accounting rights of the next block and wins the block reward and transfer fee. Finally, there is the script area, which can be used to make some extended applications. For example, the script op_return can be used as a postscript column. It should be noted that in the actual block, the script area is attached to the input and output information, not really another separate area. For example, the script attached to the input is an unlocking script (ScriptSig), which requires the wallet address for private key signature authorization to allow transfer, while the script attached to the output is a locking script (ScriptPubKey), which is used to set the unlocking conditions for receiving the BTC (generally The condition is "only those with the corresponding private key can consume").

The above two pictures are the original input and output data structure tables. At the execution level, the script appears as the incidental parameters of the transaction information. The unlocking script (ScriptSig) needs to be private. Key authorization, also known as "witness data".

SegWit and Taproot#

Although the Bitcoin network has been running for over 10 years, There have been no notable incidents, but there have been times when transaction costs soared to highs that were no longer feasible. As a result, Bitcoin’s developers have been discussing how best to scale the network to handle growing transaction volumes in the future.

This debate came to a head in 2017, when the Bitcoin development community split into two groups, those supporting the use of soft forks to implement a feature called SegWit, and those supporting the use of soft forks to implement a feature called SegWit. One faction is the “big block” faction that supports direct block expansion.

We mentioned above that the unlocking script needs to use private key authorization to generate "witness data", so can this witness data be separated from the block? , thereby increasing the number of transactions that each block can accommodate in disguise? Segregated Witness was officially activated in August 2017. Its implementation is to divide all transaction data into two parts, one part is the basic information of the transaction (Transaction Data), the other part is the signature information of the transaction (Witness Data), and save the signature information in a new data structure , is in a new block called "segregated witness (witness)" and is transmitted separately from the original transaction.

Technically, the implementation of SegWit means that transactions no longer need to include witness data (it will not occupy the 1MB space originally arranged by Bitcoin for blocks). Instead, at the end of a block, an additional separate space is created for witness data. It supports arbitrary data transfers and has a discounted "block weight" that cleverly keeps large amounts of data within Bitcoin's block size limits to avoid the need for a hard fork. In this way, the upper limit of the transaction data size of Bitcoin transactions is increased, while the transaction fee of signature data is reduced. Before the SegWit upgrade, the upper limit of Bitcoin's capacity was 1 MB. After SegWit , although the upper limit of pure transaction capacity was still 1M, the size of the Segregated Witness space reached 4 MB .

Taproot was implemented in November 2021 and consists of 3 different Bitcoin Improvement Proposals (BIPs), including: Taproot, Tapscript and its A new digital signature scheme called "Schnorr Signature". Taproot is designed to bring many benefits to Bitcoin users, such as increased transaction privacy and lower transaction fees. It will also allow Bitcoin to perform more complex transactions, thereby broadening application scenarios (some new opcodes have been added).

These updates are a key enabler for Ordinals NFT, which stores NFT data in a spend script in the Taproot script path (witness data space). This upgrade makes it easier to structure and store arbitrary witness data, laying the foundation for the "ord" standard. As data requirements are relaxed, it is assumed that a transaction can fill an entire block with its transaction and witness data - reaching the 4MB block size (witness data space) limit - greatly expanding the types of media that can be placed on the chain. .

Some people may ask, since some strings are put in the script, are there no restrictions on these strings? What if these scripts are actually executed? If you put the content casually, will there be an error code that refuses to produce a block? This brings up the OP_FALSE instruction. OP_FALSE (also represented as "0" in Bitcoin Script) ensures that the execution path in the scripting language never enters the OP_IF branch and remains unexecuted. It acts as a placeholder or no operation (No Operation) in the script, similar to a "comment" in a high-level language, to ensure that subsequent code is not executed.

UTXO transfer model

The above are the basic principles of studying BTC from the perspective of computer data structure. Let’s discuss the UTXO model from the perspective of financial model.

UTXO is the abbreviation of Unspent Transaction Outputs. The Chinese translation is "unspent transaction output". It can actually be understood as the remaining unspent transaction output during a transfer. funds. So why does Bitcoin use such a concept? This starts with the account transaction model and account balance model of the accounting method.

Because we have been in the centralized system for too long, we have become very accustomed to the accounting method of the account balance model. When user A transfers 100 yuan to user B, the bank will first check whether there is 100 yuan in A's bank account. If so, it will deduct 100 yuan from A's account and then add 100 yuan to B's account. In this way The transfer is completed.

However, there is no concept of balance in Bitcoin's accounting algorithm. Only one transaction is recorded on the distributed ledger of the blockchain, and the current balance of an account is not directly recorded (recording the balance generally requires a dedicated server node to record, which is centralized). Assume that the current balance of user A is 1,000 yuan. If user A transfers 100 yuan to user B, the transfer will be recorded as:

Transaction 1 User A to user B transfers 100 yuan

Transaction 2 User A transfers 900 yuan (UTXO) to user A himself

Although transaction 2 here is a transaction, functionally it serves as the account balance, indicating that after completing the transfer of 100 yuan, there is still 900 yuan left in A's account.

Then the question is, why do we have to create such a UTXO? Because only transactions can be recorded on the BTC blockchain, account balances cannot be recorded. Without this UTXO, calculating the balance requires accumulating all the incoming and outgoing transactions of an account, which is very time-consuming and computationally resource-consuming. The emergence of UTXO cleverly avoids the pain point of backtracking all transactions when calculating balances.

UTXO has a special feature, that is, like coins, it cannot be broken and used. So how do you get the input amount together during the transaction, and how do you get change? We can use a coin analogy (in fact, whenever you see the word UTXO, please automatically translate it to "coin").

Xiao Ming transfers 1 Bitcoin to Xiao Gang. The whole process is like this. Xiao Ming needs to collect enough inputs. For example, in the previous transaction corresponding to Xiao Ming's address, he found a UTXO with a face value of 0.9, which is not enough for 1 Bitcoin. Fortunately, multiple inputs are allowed in the transaction, so Xiao Ming found another UTXO with a face value of 0.2, so there will be two inputs in this transfer transaction. There will also be two outputs at the same time, one pointing to Xiaogang's address, with a face value of 1 Bitcoin. The other points to Xiao Ming's own address, with a face value of 0.1 Bitcoin. This output is the change (gas is ignored in this example).

In other words, there are two coins in Xiao Ming's pocket, one with a face value of 0.9 and the other with a face value of 0.2. At this time, Xiao Ming needs to pay the coin with a face value of 1, so he needs At the same time, he handed the two coins to Xiaogang. After Xiaogang received them, he gave Xiaoming 0.1 in change. Therefore, the essence of this accounting model is to avoid "calculating balances" through the action of "making change".

Ordinal protocol's sorting system

Ordinal protocol can be said to be the explosion of this round of BTC ecology The source is to decompose the homogeneous BTC into the smallest unit sat, and then mark each sat with a serial number. How is that done?

We know that the total amount of BTC is 21 million, and one BTC can be split into at least 100 million parts (sat), so the smallest unit of BTC is Sat, whether these BTC or the smallest unit sat, are all typical homogeneous tokens FT. We now try to assign an ordinal to these sats.

When talking about the block data structure earlier, we mentioned that the transaction information needs to indicate the address and amount of the input and the address and amount of the output. Each block contains two parts of transactions: BTC block reward and transfer fee. Fee transactions must have input and output, but the block reward is BTC generated out of thin air and has no input address, so the "input from" field is blank, also called "coinbase transaction". The total 21 million BTCs come from this coinbase transaction, which is also ranked first in the transaction list among all blocks.

Ordinal protocol stipulates as follows:

1. Numbering: Each sat is numbered in the order in which they were mined

2. Transfer: according to the first-in-first-out rule, Moving from the input to the output of the transaction
   The first rule is relatively simple, it determines that the number can only be generated by the coinbase transaction in the mining reward. For example, if the mining reward of the first block is 50 BTC, the first block will be allocated sats in the range of [0;1;2;...;4,999,999,999]; the second block reward will also be When it is 50 BTC, the second block will allocate sats in the range of [5,000,000,000;5,000,000,001;...;9,999,999,999].

The difficult part to understand here is that since UTXO actually contains many satoshis, then each satoshi in this UTXO looks like They are all the same, how to rank them? This is actually determined by the second rule. Let’s give a simple example:

I first assume that the minimum division unit of BTC is 1, and a total of 10 blocks, the block reward for each block is 10 BTC, that is, the total amount is 100. We can directly assign a serial number (0-99) to these 100 BTC. If there is no transfer, then we only know that the 10 BTC numbers in the first block are (0-9), the 10 BTC numbers in the second block are (10-19), until the tenth area The block number of 10 BTC is (90-99). Because there is no cost and no output, we can only assign a number range to every 10 BTC.

Suppose two expenditures (outputs) are added to the second block, one is 3 BTC, and the other is "change" 7 BTC, corresponding to the Someone else transferred 3 BTC and gave me 7 BTC in change. At this time, in the transaction list of the block, assume that the 7 BTC given to oneself in change ranks first (the corresponding number is 10-16), and the 3 BTC given to others ranks second (the corresponding number is 17-19). This confirms the sequential set of sats contained in a certain UTXO through the transfer of output.

Note that each sat is not UTXO! Since UTXO is the smallest transaction unit that cannot be subdivided, sat only Can exist in UTXO , and UTXO contains a certain range of sats, and the sats number can only be split in a new output generated after spending a certain UTXO .

As for how to express this "number", Ordinal supports multiple forms, such as the "integer method" mentioned above, and other decimal methods. , degree method, percentage method, pure letter nomenclature.

After sats has a unified serial number, it can be considered for inscription. As we mentioned above, you can upload files of any data type in the 4M space of the witness data area, whether it is text, pictures or videos. After uploading, the files will be automatically converted to hexadecimal and stored in the taproot script area. So, 1 UTXO corresponds to 1 Taproot script area, and this 1 UTXO will contain many sats at the same time (the whole is a set of sats sequences. In order to prevent dust attacks, the number of Bitcoins in a single UTXO is limited to no less than 546 satoshis. .). In order to facilitate recording, the Ordinal protocol artificially stipulates "use the first sat number of this sequence set to represent the binding relationship" (the original words of the white paper are the first sat number of the first output), for example, it contains (17-19 ) The UTXO of sats with number 17 is directly used to replace this set and bind the inscribed content.

Ordinal asset casting and transfer#

Ordinal NFT obviously means to convert various files Upload it to the script in the Segregated Witness Zone and bind a sats sequence set to it, thereby realizing the issuance of NFT assets on the BTC chain. But there is another problem here. The script in the Segregated Witness Zone contains the unlocking script of input and the locking script of output. So which script is the content placed in? The correct answer is both. I have to mention the commit-reveal mechanism in blockchain technology here.

The Commit-Reveal mechanism in the blockchain is a protocol used to ensure fair and transparent processing of information. This mechanism is often used in scenarios where hidden information needs to be submitted (such as a vote or bid) and then revealed at a later point in time. The Commit-Reveal mechanism is divided into two phases: Commit phase and Reveal phase.

1. Commit phase: In this phase, users submit their information (such as voting selection or bid price), but this information is encrypted. Typically, the user generates a hash of this message (i.e., a cryptographic digest of the message) and then sends this hash to the blockchain. Due to the properties of hash functions, they can generate a unique output (hash value) that is irreversible from the original message. This means that the original information cannot be inferred from the hash value. This process ensures the confidentiality of information at the time of submission.

2. Reveal phase: At a predetermined later time, users must reveal their original information and prove that it is consistent with the previous The submitted hash matches. This is usually done by submitting the original information along with any additional data (such as a nonce or "salt") used to generate the hash value. The network then verifies that the hash of this original message is the same as the previously submitted hash. If there is a match, the original message is accepted as valid.

As we said before, the engraved content needs to be bound to the sats sequence set contained in UTXO. UTXO is in the block is an output, so it must be attached to the output's locking script. However, BTC full nodes need to locally maintain and transmit all UTXO sets of the entire network. Imagine that if 10,000 4M video files are directly uploaded to 10,000 UTXO locking scripts, then all full nodes will need ultra-high storage space and ultra-fast network speeds. It can be said that the entire chain will collapse directly. . Therefore, the only solution is to put the content in the unlocking script of the input, and then let this content "point" to another output.

So the casting of Ordinal assets needs to be divided into two steps (the wallet merges these two steps, and when constructing the transaction, commit- reveal this father-son transaction, the user experience will feel that there is only one step and save gas fees).

In the casting phase, the user first needs to upload the hash value of a certain file to the UTXO in the commit transaction (their A address transfers to his B address) The locking script, because it is a hash value, does not occupy too much UTXO database space of the full node. Secondly, the user constructs a new transaction (their B address transfers money to his A address), which is called a reveal transaction. The input at this time needs to use the UTXO containing the file hash value in the previous commit transaction, and the input The unlocking script must contain the original engraving file. To use the original words in the white paper, it is “First, in commit, create a taproot output that is submitted to the script containing the inscription content. Secondly, in the reveal transaction, use the output generated by the commit transaction to display the inscription content on the chain. ."

In the transfer stage, Ordinal NFT is slightly different from BRC20. Because Ordinal NFT is an overall transfer, you only need to transfer the NFT bound to a certain UTXO directly. Just give it to the recipient, similar to a normal BTC transfer. However, because BRC20 involves a custom amount transfer, it is also divided into two steps. The first step is called Inscribe "TRANSFER", and the second step is called Transfer "TRANSFER". The engraving transaction is actually similar to the casting process of an Ordinal NFT, implying a commit-reveral father-son transaction pair. The second step transfer transaction is similar to an ordinary Ordinal NFT transfer, directly transferring the BRC20 assets bound to a certain UTXO to the recipient. . Some wallets will construct these three transactions (transactions between father, son, and three generations) at the same time to save time and gas.

In summary, the commit transaction is used to bind the engraved content (the hash value of the original content) and the serialized sats (UTXO), and the reveal transaction is used to bind The content is displayed (original content). This father-son trading pair worked together to complete the minting of NFT.

P2TR and an example#

The above technical discussion about casting is not finished yet, because Some people may be curious, how does the reveal transaction verify the inscription information in the commit transaction? Why do we need our own AB addresses to transfer funds to each other when structuring a transaction? I didn’t see the need to prepare two wallets when I was making the inscription. Here we need to talk about one of Taproot’s major upgrades, P2TR.

P2TR (Pay-to-Taproot) is a new type of Bitcoin transaction introduced by the Taproot upgrade. P2TR transactions enable greater privacy and flexibility by allowing users to spend Bitcoin using a single public key or more complex scripts such as multi-signature wallets or smart contracts. This is achieved through the use of Merkleized Abstract Syntax Trees (MAST) and Schnorr signatures, techniques that make it possible to efficiently encode multiple spending conditions in a single transaction.

• Create spending conditions
  To create a P2TR transaction, the user first defines a spending condition , such as a single public key or a more complex script that specifies the requirements for spending Bitcoins (e.g., a multi-signature wallet or smart contract).

• Generate Taproot output
  The user then generates a Taproot output that includes a single public key (the public key represents the spending condition ). This public key is derived from a combination of the user's public key and the script's hash, using a process called "tweaking." This ensures that the output looks like a standard public key, making it indistinguishable from other transactions on the blockchain.

• Spending Bitcoin
  When a user wants to spend Bitcoin, they can use their single public key (if spending conditions are met), or disclose the original script and provide the necessary signatures or data to satisfy the spending conditions. This is accomplished using Tapscript, which allows for more efficient and flexible execution of spending conditions.

• Verify transaction
  Miners and nodes then verify the transaction by checking the provided Schnorr signature and data with spending conditions. If the conditions are met, the transaction is considered valid and the Bitcoins can be spent.

• Enhanced Privacy and Flexibility
  Because P2TR transactions only reveal the necessary spending conditions when spending Bitcoin, they A high level of privacy is maintained. Additionally, the use of MAST and Schnorr signatures enables efficient encoding of multiple spending conditions, allowing for more complex and flexible transactions without increasing the overall size of the transaction.

The above is how the commit-reveal mechanism is applied in P2TR. We will illustrate it with a practical case.

Use the blockchain browser https://www.blockchain.com/  Let’s study the casting process of an Ordinal image NFT, including the previous commit-reveal two stages.

First, we see that the Hash ID of the commit transaction is (2ddf90ddf7c929c8038888fc2b7591fb999c3ba3c3c7b49d54d01f8db4af585c). It can be noted that the output of this transaction does not contain inscription data (actually it is the hash value of the 16-mechanism image file), and there is no relevant inscription information in the web page. This output (bc1p4mtc....) address is actually a temporary address generated through the "tweaking" process (representing the public key of the script unlocking condition), and shares a private key with the taproot main address (bc1pg2mp...). The second UTXO in this transaction belongs to the returned "change" operation. In this way, the binding of the inscription content to the sats contained in the first UTXO is achieved.

Next, we check the record of the reveal transaction, and its Hash ID is (e7454db518ca3910d2f17f41c7b215d6cba00f29bd186ae77d4fcd7f0ba7c0e1). Here we can see the Ordinals inscription information. The input address of this transaction is the temporary output address generated by the previous transaction (bc1p4mtc....). The input unlocking script contains the hexadecimal file of the original image, and the output 0.00000546BTC (546 Satoshi) is Send this NFT to your taproot main address (bc1pg2mp...). Based on the First in First Out principle and "the number of the first satoshi of the first output is bound", although the number of sats contained in the two UTXOs before and after changes, the bound sat sequence number remains unchanged. So, we can find the Satoshi where this inscription is located in (sat 1893640468329373).

（https://ordinals.com/sat/1893640468329373)

These two transactions ( Belonging to a father-son transaction) will be submitted to the memory pool by the wallet at the same time when minting, so it only costs one gas, and there is a high probability that it will enter the same block and be recorded and broadcast by the miners (the two transactions in the above example are is also present in block 790468.). Miners and nodes then verify by checking the Schnorr signature and hexadecimal image hash provided in the input in the reveal transaction against the hexadecimal image hash in the output lock script in the commit transaction. If the two are the same, the transaction is considered valid and the Bitcoin UTXO can be spent. Then these two transactions will naturally be permanently recorded in the BTC blockchain database, and the NFT image will naturally be saved and displayed. . If the two hashes are different, both transactions will be canceled and the inscription will fail.

BRC20 protocol and indexer

For the Ordinal protocol, we engrave a piece of text, which is Text NFT (corresponding to Loot on Ethereum), if a picture is engraved, it is a picture NFT (corresponding to PFP on Ethereum), if a piece of music is engraved, it is an audio NFT. So what if we engrave a piece of code, and this code is a piece of code to "issue FT fungible tokens"?

BRC20 deploys, mints and transfers Token by using the Ordinal protocol to set inscriptions into JSON data format. JSON contains some code snippets to describe the Token. various properties such as its supply, maximum minting unit, and unique code. We have already mentioned in the previous article that the essence of the BRC20 token is a semi-fungible token SFT, that is to say, in some cases it can be used as an NFT transaction, and in some cases it can be used as an FT transaction. This kind of pairing How is the control of "different situations" achieved? The answer is indexers.

The indexer is actually a bookkeeper, used to record the received information into categories in the database. In the Ordinal protocol, the indexer determines the changes in sorted sats in different addresses by tracking input and output. In the BRC-20 protocol, the indexer has an additional function: recording changes in the token balance in the inscription at different addresses.

So we can see different forms of token existence from the perspective of the bookkeeper: BRC20 protocol tokens actually exist in a triple database. In the first Layer1, the bookkeeper is a BTC miner, the database type is "chained database", and the BTC generated is an FT asset. In the second layer 2, the bookkeeper is the Ordinal indexer, the database type is "relational database", and the generated sats with serial numbers are NFT assets. In the third layer3, the bookkeeper is the BRC20 indexer, the database type is "relational database", and the BRC20 assets generated are FT assets. When we count BRC20 in terms of "pieces", the point of view is the ordinal indexer (recorded by this indexer), which is naturally an NFT; when we think of BRC20 in terms of split "pieces" ( Especially after recharging to a centralized exchange), the station's perspective is the BRC20 indexer (recorded by the indexer or the server of the centralized exchange), which is naturally FT. From this we can draw a conclusion that the existence of the semi-fungible token SFT is due to the different levels of bookkeepers.

Isn't the blockchain just a distributed database, so there is a group of bookkeepers such as miners to jointly maintain this "chained database" (because only Only chained databases can achieve true decentralization). But after going round and round, we are still back to the old path of centralized "relational databases". This is also the essential reason why some time ago, the initiators of the Ordinal protocol, the initiator of the BRC20 protocol, and the unisat wallet were so excited about whether to upgrade the indexer - the bookkeepers had different opinions.

However, after more than ten years of development, the industry has still accumulated a lot of "decentralization" experience. Can the indexer use "chained database" Replacement for relational database? Can fraud proofs or ZKP be used to ensure security and decentralization? Will the demand for DA in the Bitcoin ecosystem spill over to other DAs, thereby promoting the prosperity and integration of multi-chain ecosystems? I seem to see more possibilities.

Reference materials

https://www.aixinzhijie.com/books/261/ master_bitcoin/_book/

https://learnblockchain.cn/article/5717

https ://zhuanlan.zhihu.com/p/361854961

https://www.odaily.news/post/5187233

https://learnblockchain.cn/article/5376

https://www.panewslab.com/zh/articledetails /1301r1ibp79c.html

https://docs.ordinals.com/inscriptions.html

https://thebitcoinmanual.com/articles/pay-to-taproot-p2tr/