Ordinal铭文协议的原理与技术细节讨论

作者：@hicaptainz

最近一周我在研究BTC生态和各种铭文项目的时候，发现很少有文章能够清晰地把原理和技术细节介绍的清楚：比如铭文在铸造的时候，交易是如何发起的，UTXO里面的sats是怎么被追踪的，铭刻的内容到底是放在脚本什么地方，以及BRC20在转动的时候为何需要两次操作？我发现不了解这些技术细节，就很难弄明白BRC20，BRC420，原子，邮票、符文Runes这些各种协​​议的区别，本文将深入到BTC区块链的基础知识，尝试回答上述问题。

BTC的区块结构

区块链本质上是一种多用户账户记技术，用计算机科学术语来说，是一个数据库，每个时期内的记录（账户目）组成一个块，然后根据时间顺序进行账户本扩展。

我们用excel做了表格来说明区块链的工作原理。一个excel文件代表了一个区块链，其中每一个表格代表了一个区块，按照区块时间顺序从560331，560332最新。的560336。 560336会在区块内预留最近的交易。区块内部主体部分就是我们在会计领域最常见的复式记账法，一边地址记做借出（借方）就是输入，另一边地址记做贷入（信用）就是输出到。数值对应对应地址的BTC数量。输入的币数会大于输出币的数量，差额就是用户层面的转账费用，也是矿工（记账人）所取得的手续费。获取上一个区块的高度，上一个区块的哈希值，本区块的建立时间（时间），和随机数。然后做为去中心化的记账技术，到底是谁来抢到下一个靠的就是这个随机数和对应的哈希值。拥有算力的矿工通过对当前区块的随机数进行哈希计算，最先得到符合条件的哈希值的矿工拥有下一个区块的记账权并获得区块奖励和奖金。最后是脚本区域，可以用来做一些扩展应用，比如脚本op_return可以当做附加言栏。需要注意的是，在实际的区域块中，脚本区被指定在输入和输出信息中的，而不是真的另外一个区域。比如指定在输入的脚本是解锁脚本（ScriptSig），需要钱包地址进行私钥签名授权允许转出，而涂抹在输出的脚本是锁定脚本（ScriptPubKey），用于设置收到该BTC的解锁条件（一般情况条件就是“有相应私钥的人才能消费”）。

上面两张图是原始的输入和输出的数据结构表，在执行剧本中，获取交易信息的相关参数，其中解锁脚本（ScriptSig）因为需要私钥授权，也被称为“见证数据”（见证人）数据）。

隔离见证和主根

尽管比特币网络已经运行了超过 10 年，没有发生过什么显着的事件，但曾多次出现交易成本上升到不再可用的高点。因此，比特币的开发人员一直在讨论如何最好地扩展网络，以处理未来不断增长的交易量。

2017年，大象论坛达到巅峰，比特币开发社区分裂成两派，一派是支持使用名为SegWit的功能的软分叉实施，另一派是支持直接区块扩容的“大区块”派。

我们在前面提到的所有解锁脚本都需要使用私钥授权生成“见证数据”，那么是不是可以把这个见证数据从区块中分离出来，从而变相增加区块可承载的交易数据呢？ （隔离见证）于2017年8月激活正式激活。它的实现方式是将所有的交易数据分为两部分，一部分是交易的基本信息（交易数据），另一部分是交易的签名信息（见证数据） ），并把签名信息保存在一个新的数据结构中，被称为“隔离见证（witness）”的新区块中，并与原始交易分开传输。

在技​​术上，SegWit的实施意味着交易不再需要包括见证数据（不会占用比特币不知道为区块安排的1MB空间）。取而代之，在一个区块的费用中，为见证数据创建了一个额外的独立的空间。它支持任意的数据循环，并有一个减少的“区块重量（blockweight）”，避免了将大量的数据保持在比特币的区块大小内，分区硬分叉的需要这样，比特币交易的交易数据大小提高了上限，同时降低了签名数据的交易费用。在SegWit升级之前，比特币的容量上限为1MB，而SegWit之后，虽然强制交易的容量上限又恢复为1M，但隔离见证空间的大小达到了4MB。

Taproot于2021年11月实施，由3项不同的比特币改进提案（BIP）组成，其中包括：Taproot、Tapscript及其名为「Schnorr Signature」的全新数字签名方案。Taproot旨在为比特币用户带来了一个好处，例如提升交易操作性并降低交易费用。通过让比特币执行一些更复杂的交易，从而拓宽应用场景（新增加了代码操作码）。

这些更新是 Ordinals NFT 的关键推动因素，将会使 NFT 数据存储在 Taproot 脚本中占用脚本（花费脚本）中（见证数据空间）。升级使得构造和存储任何的见证数据更加容易，为“ord”标准奠定了基础。随着数据要求的放宽，假设一个交易可以用其交易和见证数据填满整个区块——达到4MB的区块大小（见证数据空间）限制——极大地扩展了可以放置链上的媒体类型。

有人会问，既然在脚本中放入了一些字符串，那对这些字符串没有限制条件吗？万一真的执行这些脚本呢？如果随便放内容，那会不会出现错误代码拒绝出块呢？这需要提到OP_FALSE指令。OP_FALSE（以比特币脚本中也表示为“0”）确保脚本语言中的执行路径永远不会进入OP_IF分支，并保持未执行状态。它相当于脚本中的占位符或空操作（No Operation），类似于高级语言中的“注释”，来保证后续的代码不被执行。

UTXO转账模型

以上都是从计算机数据结构方面来研究BTC的基本原理，我们再从金融模型方面来讨论一下UTXO模型。

UTXO 是 Unspent Transaction Outputs 的缩写，中文翻译是“没有花掉的交易输出”，实际上可以理解为在一周时间内剩下没有转出的资金。那比特币为啥要使用这么一个概念呢？这就是从账户记账方法来看，账户交易模型和账户余额模型表示不安。

因为我们在中心化的体系待的太久了，已经非常习惯账户余额模型的记账方式。当用户A给用户B转100块钱时，银行会先检查A的银行账户上是否有100元，如果就从A的账户里过去100元再在B的账户上加上100元，这样一笔转账就完成了。

然而，比特币的记账算法里并没有余额这个概念。在区块链的记账本上记录的只有记笔的交易，并不会直接记录一个账户当前余额是多少（记录余额一般需要专门的）假设当前用户A余额是1000元，如果用户A给用户B转100元，刚才转账会被记录成：

交易1 用户A给用户B转账100元

交易2 用户A给用户A自己转账900元 （UTXO）

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.

So 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 adding up 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.

One characteristic of UTXO is that, like coins, it cannot be broken up and used. So how do you get the input amount together during the transaction, and how do you get change? We can make an analogy with coins (in fact, it is better to automatically translate it to "coin" every time you see the word UTXO).

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 to hand these two coins to Xiao Gang at the same time. Zero 0.1 is given to Xiao Ming. Therefore, the essence of this accounting model is to avoid "calculating balances" through the action of "making change".

Ordering system of Ordinal protocol

The Ordinal protocol can be said to be the source of this round of BTC ecological explosion. It breaks down the homogenized BTC into the smallest unit sat, and then marks 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 BTCs or the smallest unit sat, they are all typical Fungible token FT. We now try to assign an ordinal number 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 because the block reward is BTC generated out of thin air, there is 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.

The Ordinal protocol stipulates as follows:

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

2. Transfer: Transfer from the input to the output of the transaction according to the first-in-first-out rule

The first rule is relatively simple, it determines that the number can only be generated by coinbase transactions in mining rewards. 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, each satoshi in this UTXO looks the same. How to sort them? This is actually determined by the second rule. Let’s give a simple example:

Let me first assume that the minimum division unit of BTC is 1, a total of 10 blocks have been produced, and the block reward of 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 10 BTC number of the block is (90-99). Because there is no cost and no output, we can only assign a number range to every 10 BTC.

Assume that two outputs are added to the second block, one is 3 BTC, and the other is "change" 7 BTC, which corresponds to transferring 3 BTC to others and giving 7 BTC in change to yourself. At this time, in the transaction list of the block, assume that the 7 BTC given to yourself in change are ranked first (the corresponding number is 10-16), and the 3 BTC given to others are ranked second (the corresponding number is 17-19). This confirms the sequential set of sats contained in a certain UTXO by transferring the output.

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

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

After sats have a unified serial number, you can consider inscription. As we mentioned above, you can upload any data type file in the 4M space of the witness data area, whether it is text, pictures or videos. After uploading, the file 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 number of the first satoshi of the first output), such as (17-19 ), the UTXO of sats with number 17 is directly used to replace this set and bind the inscribed content.

Minting and transfer of Ordinal assets

Ordinal NFT obviously uploads various files to the script in the segregated witness area and binds 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 both the input unlocking script and the output locking script. So which script should the content be 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 choices or bid prices), 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 matches a previously submitted hash. 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 an output in the block, so it must be attached to the output locking script. However, BTC's full nodes need to locally maintain and transmit all UTXO sets in the entire network. Imagine that if there are 10,000 4M video files directly uploaded to 10,000 UTXO locking scripts, then all full nodes need to have 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.

Therefore, the casting of Ordinal assets needs to be divided into two steps (the wallet merges these two steps. When constructing the transaction, it also constructs the commit-reveal parent-child transaction. The user experience will feel that there is only one step and save gas. fee).

In the casting phase, the user first needs to upload the hash value of a certain file to the locking script in the UTXO in the commit transaction (their A address transfers money to his or her B address). Because it is a hash value, it does not occupy too much of the full node. UTXO database space. 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 to the recipient, similar to ordinary BTC transfers. 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 of the transfer transaction is similar to an ordinary Ordinal NFT transfer, directly transferring the BRC20 assets bound to a 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 display the content (the original content). This father-son trading pair jointly completed the minting of NFT.

P2TR with an example

The above technical discussion about casting is not over 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 two addresses AB 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.

• Spend Bitcoin

When a user wants to spend Bitcoin, they can use their single public key (if the spending conditions are met), or reveal 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 and 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 maintain a high level of privacy. 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.

Using the blockchain browser https://www.blockchain.com/ we will study the minting process of an Ordinal image NFT, including the previous commit-reveal 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 contains the hash value of the 16-mechanism image file), and there is no relevant inscription information on the web page. This output (bc1p4mtc....) address is actually a temporary address generated through the "tweaking" process (the public key representing the script unlocking conditions), 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 It is to send this NFT to your own 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 serial number remains unchanged. So, we can find the satoshi where this inscription is located in (sat 1893640468329373).

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

这笔交易（属于父子交易）在两个铸造时会同时由钱包提交给内存池，所以只占用支出gas，也很大一部分是进入同一个区块中被矿工记录和广播（以上例子中）的交易同时存在于区块790468中。)。矿工和节点通过检查揭示交易中的输入所提供的Schnorr签名以及16个分区图片的哈希值与提交交易中的输出锁定脚本中的16张图片哈希值进行验证。如果两者相同，交易被视为有效，这个比特币的UTXO可能会被占用，那么这两个交易自然就会被永久记录在BTC的区块链数据库中， NFT的图片也自然被保存下来并显示出来。如果两个哈希值不同，两个交易就会被取消，铭刻失败。

BRC20协议与索引器

对于Ordinal协议，我们铭刻，它就是文字NFT（对应以太坊上的Loot），铭刻一张图片，它就是图片NFT（对应以太坊上的PFP），铭刻一段音乐，它就是文本音频NFT。那如果我们铭刻一段代码，并且假设代码是一段“释放 FT 同质化代币”的代码呢？

BRC20正是通过利用Ordinal协议将inscriptions（铭文）设置为JSON数据格式来部署、铸造和增量Token，JSON包含一些代码片段，描述Token的各种属性，例如其供应量、最大铸造单位和唯一代码。我们在上一篇文章中已经讲过，BRC20代币的本质是半同质化代币SFT，因而，在某些情况下它可以当做NFT交易，可以在某些情况下当做FT交易，这种对“不同情况”的控制是如何办到的？答案是索引器。

索引器其实是一个记账人，用来把接收到的信息分门别类的记录在数据库里。在序数协议中，索引器通过对输入和输出的追踪，来确定排序这些sats在不同地址中的变化在BRC-20协议里，索引器有一个功能：记录铭文中代币余额在不同地址的变化。

所以我们可以从记账人的第一个角度来看到不同的代币存在形式：BRC20协议代币其实存在于一个三个重数据库中。重第1层，记账人是BTC矿工，数据库类型是“链式数据库” ”，产生的BTC是FT资产。第二重层2，记账人是序数索引器，数据库类型是“关系型数据库”，产生的带序号的sats是NFT资产。第三重层3，记人是BRC20索引器，数据库类型是“关系型数据库”，产生的BRC20资产是FT资产。当我们把BRC20“张”来算的时候，站的角度是序数索引器（由该索引器记录），它按照自然就是NFT；当我们把BRC20按照分拆好的“个”来思考的时候（尤其是充值到中心化交易所之后），站的角度就是BRC20索引器（由该索引器记录或者是中心化交易）所的服务器记录），它自然是FT。由此我们可以得到一个结论，半同质化代币SFT的存在是因为有不同体系的记账人导致的。

区块链不就是一个数据库嘛，所以有了矿工这个记账人群来共同维护这个“链式数据库”（因为只有链式数据库才能实现真正的去中心化）。但兜兜转转，我们还是回到了中心化的“关系型数据库”的老路。这也是为何前段时间Ordinal协议发起人，BRC20协议发起人，unisat钱包为了索引器是否要升级炒的不可开交的本质原因--记账本人们意见不一致啦。

但行业经过十几年的发展，还是积累了辉煌的“去中心化”的经验，索引器可不可以用“链式数据库”替代关系型数据库？中心化？比特币生态的DA需求会不会溢出到其他的DA从而促进多链生态繁荣和融合？我似乎看到了更多的可能性。

热点：协议