作者：@hicaptainz

最近一周我在研究BTC生態(tài)和各種銘文項(xiàng)目的時(shí)候，發(fā)現(xiàn)很少有文章能夠清晰地把原理和技術(shù)細(xì)節(jié)介紹的清楚：比如銘文在鑄造的時(shí)候，交易是如何發(fā)起的，UTXO里面的sats是怎么被追蹤的，銘刻的內(nèi)容到底是放在腳本什么地方，以及BRC20在轉(zhuǎn)動(dòng)的時(shí)候?yàn)楹涡枰獌纱尾僮鳎课野l(fā)現(xiàn)不了解這些技術(shù)細(xì)節(jié)，就很難弄明白BRC20，BRC420，原子，郵票、符文Runes這些各種協(xié)??議的區(qū)別，本文將深入到BTC區(qū)塊鏈的基礎(chǔ)知識(shí)，嘗試回答上述問題。

BTC的區(qū)塊結(jié)構(gòu)

區(qū)塊鏈本質(zhì)上是一種多用戶賬戶記技術(shù)，用計(jì)算機(jī)科學(xué)術(shù)語來說，是一個(gè)數(shù)據(jù)庫，每個(gè)時(shí)期內(nèi)的記錄（賬戶目）組成一個(gè)塊，然后根據(jù)時(shí)間順序進(jìn)行賬戶本擴(kuò)展。

我們用excel做了表格來說明區(qū)塊鏈的工作原理。一個(gè)excel文件代表了一個(gè)區(qū)塊鏈，其中每一個(gè)表格代表了一個(gè)區(qū)塊，按照區(qū)塊時(shí)間順序從560331，560332最新。的560336。 560336會(huì)在區(qū)塊內(nèi)預(yù)留最近的交易。區(qū)塊內(nèi)部主體部分就是我們?cè)跁?huì)計(jì)領(lǐng)域最常見的復(fù)式記賬法，一邊地址記做借出（借方）就是輸入，另一邊地址記做貸入（信用）就是輸出到。數(shù)值對(duì)應(yīng)對(duì)應(yīng)地址的BTC數(shù)量。輸入的幣數(shù)會(huì)大于輸出幣的數(shù)量，差額就是用戶層面的轉(zhuǎn)賬費(fèi)用，也是礦工（記賬人）所取得的手續(xù)費(fèi)。獲取上一個(gè)區(qū)塊的高度，上一個(gè)區(qū)塊的哈希值，本區(qū)塊的建立時(shí)間（時(shí)間），和隨機(jī)數(shù)。然后做為去中心化的記賬技術(shù)，到底是誰來搶到下一個(gè)靠的就是這個(gè)隨機(jī)數(shù)和對(duì)應(yīng)的哈希值。擁有算力的礦工通過對(duì)當(dāng)前區(qū)塊的隨機(jī)數(shù)進(jìn)行哈希計(jì)算，最先得到符合條件的哈希值的礦工擁有下一個(gè)區(qū)塊的記賬權(quán)并獲得區(qū)塊獎(jiǎng)勵(lì)和獎(jiǎng)金。最后是腳本區(qū)域，可以用來做一些擴(kuò)展應(yīng)用，比如腳本op_return可以當(dāng)做附加言欄。需要注意的是，在實(shí)際的區(qū)域塊中，腳本區(qū)被指定在輸入和輸出信息中的，而不是真的另外一個(gè)區(qū)域。比如指定在輸入的腳本是解鎖腳本（ScriptSig），需要錢包地址進(jìn)行私鑰簽名授權(quán)允許轉(zhuǎn)出，而涂抹在輸出的腳本是鎖定腳本（ScriptPubKey），用于設(shè)置收到該BTC的解鎖條件（一般情況條件就是“有相應(yīng)私鑰的人才能消費(fèi)”）。

上面兩張圖是原始的輸入和輸出的數(shù)據(jù)結(jié)構(gòu)表，在執(zhí)行劇本中，獲取交易信息的相關(guān)參數(shù)，其中解鎖腳本（ScriptSig）因?yàn)樾枰借€授權(quán)，也被稱為“見證數(shù)據(jù)”（見證人）數(shù)據(jù)）。

隔離見證和主根

盡管比特幣網(wǎng)絡(luò)已經(jīng)運(yùn)行了超過 10 年，沒有發(fā)生過什么顯著的事件，但曾多次出現(xiàn)交易成本上升到不再可用的高點(diǎn)。因此，比特幣的開發(fā)人員一直在討論如何最好地?cái)U(kuò)展網(wǎng)絡(luò)，以處理未來不斷增長(zhǎng)的交易量。

2017年，大象論壇達(dá)到巔峰，比特幣開發(fā)社區(qū)分裂成兩派，一派是支持使用名為SegWit的功能的軟分叉實(shí)施，另一派是支持直接區(qū)塊擴(kuò)容的“大區(qū)塊”派。

我們?cè)谇懊嫣岬降乃薪怄i腳本都需要使用私鑰授權(quán)生成“見證數(shù)據(jù)”，那么是不是可以把這個(gè)見證數(shù)據(jù)從區(qū)塊中分離出來，從而變相增加區(qū)塊可承載的交易數(shù)據(jù)呢？ （隔離見證）于2017年8月激活正式激活。它的實(shí)現(xiàn)方式是將所有的交易數(shù)據(jù)分為兩部分，一部分是交易的基本信息（交易數(shù)據(jù)），另一部分是交易的簽名信息（見證數(shù)據(jù)） ），并把簽名信息保存在一個(gè)新的數(shù)據(jù)結(jié)構(gòu)中，被稱為“隔離見證（witness）”的新區(qū)塊中，并與原始交易分開傳輸。

在技??術(shù)上，SegWit的實(shí)施意味著交易不再需要包括見證數(shù)據(jù)（不會(huì)占用比特幣不知道為區(qū)塊安排的1MB空間）。取而代之，在一個(gè)區(qū)塊的費(fèi)用中，為見證數(shù)據(jù)創(chuàng)建了一個(gè)額外的獨(dú)立的空間。它支持任意的數(shù)據(jù)循環(huán)，并有一個(gè)減少的“區(qū)塊重量（blockweight）”，避免了將大量的數(shù)據(jù)保持在比特幣的區(qū)塊大小內(nèi)，分區(qū)硬分叉的需要這樣，比特幣交易的交易數(shù)據(jù)大小提高了上限，同時(shí)降低了簽名數(shù)據(jù)的交易費(fèi)用。在SegWit升級(jí)之前，比特幣的容量上限為1MB，而SegWit之后，雖然強(qiáng)制交易的容量上限又恢復(fù)為1M，但隔離見證空間的大小達(dá)到了4MB。

Taproot于2021年11月實(shí)施，由3項(xiàng)不同的比特幣改進(jìn)提案（BIP）組成，其中包括：Taproot、Tapscript及其名為「Schnorr Signature」的全新數(shù)字簽名方案。Taproot旨在為比特幣用戶帶來了一個(gè)好處，例如提升交易操作性并降低交易費(fèi)用。通過讓比特幣執(zhí)行一些更復(fù)雜的交易，從而拓寬應(yīng)用場(chǎng)景（新增加了代碼操作碼）。

這些更新是 Ordinals NFT 的關(guān)鍵推動(dòng)因素，將會(huì)使 NFT 數(shù)據(jù)存儲(chǔ)在 Taproot 腳本中占用腳本（花費(fèi)腳本）中（見證數(shù)據(jù)空間）。升級(jí)使得構(gòu)造和存儲(chǔ)任何的見證數(shù)據(jù)更加容易，為“ord”標(biāo)準(zhǔn)奠定了基礎(chǔ)。隨著數(shù)據(jù)要求的放寬，假設(shè)一個(gè)交易可以用其交易和見證數(shù)據(jù)填滿整個(gè)區(qū)塊——達(dá)到4MB的區(qū)塊大小（見證數(shù)據(jù)空間）限制——極大地?cái)U(kuò)展了可以放置鏈上的媒體類型。

有人會(huì)問，既然在腳本中放入了一些字符串，那對(duì)這些字符串沒有限制條件嗎？萬一真的執(zhí)行這些腳本呢？如果隨便放內(nèi)容，那會(huì)不會(huì)出現(xiàn)錯(cuò)誤代碼拒絕出塊呢？這需要提到OP_FALSE指令。OP_FALSE（以比特幣腳本中也表示為“0”）確保腳本語言中的執(zhí)行路徑永遠(yuǎn)不會(huì)進(jìn)入OP_IF分支，并保持未執(zhí)行狀態(tài)。它相當(dāng)于腳本中的占位符或空操作（No Operation），類似于高級(jí)語言中的“注釋”，來保證后續(xù)的代碼不被執(zhí)行。

UTXO轉(zhuǎn)賬模型

以上都是從計(jì)算機(jī)數(shù)據(jù)結(jié)構(gòu)方面來研究BTC的基本原理，我們?cè)購慕鹑谀Ｐ头矫鎭碛懻撘幌耈TXO模型。

UTXO 是 Unspent Transaction Outputs 的縮寫，中文翻譯是“沒有花掉的交易輸出”，實(shí)際上可以理解為在一周時(shí)間內(nèi)剩下沒有轉(zhuǎn)出的資金。那比特幣為啥要使用這么一個(gè)概念呢？這就是從賬戶記賬方法來看，賬戶交易模型和賬戶余額模型表示不安。

因?yàn)槲覀冊(cè)谥行幕捏w系待的太久了，已經(jīng)非常習(xí)慣賬戶余額模型的記賬方式。當(dāng)用戶A給用戶B轉(zhuǎn)100塊錢時(shí)，銀行會(huì)先檢查A的銀行賬戶上是否有100元，如果就從A的賬戶里過去100元再在B的賬戶上加上100元，這樣一筆轉(zhuǎn)賬就完成了。

然而，比特幣的記賬算法里并沒有余額這個(gè)概念。在區(qū)塊鏈的記賬本上記錄的只有記筆的交易，并不會(huì)直接記錄一個(gè)賬戶當(dāng)前余額是多少（記錄余額一般需要專門的）假設(shè)當(dāng)前用戶A余額是1000元，如果用戶A給用戶B轉(zhuǎn)100元，剛才轉(zhuǎn)賬會(huì)被記錄成：

交易1 用戶A給用戶B轉(zhuǎn)賬100元

交易2 用戶A給用戶A自己轉(zhuǎn)賬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)

這筆交易（屬于父子交易）在兩個(gè)鑄造時(shí)會(huì)同時(shí)由錢包提交給內(nèi)存池，所以只占用支出gas，也很大一部分是進(jìn)入同一個(gè)區(qū)塊中被礦工記錄和廣播（以上例子中）的交易同時(shí)存在于區(qū)塊790468中。)。礦工和節(jié)點(diǎn)通過檢查揭示交易中的輸入所提供的Schnorr簽名以及16個(gè)分區(qū)圖片的哈希值與提交交易中的輸出鎖定腳本中的16張圖片哈希值進(jìn)行驗(yàn)證。如果兩者相同，交易被視為有效，這個(gè)比特幣的UTXO可能會(huì)被占用，那么這兩個(gè)交易自然就會(huì)被永久記錄在BTC的區(qū)塊鏈數(shù)據(jù)庫中， NFT的圖片也自然被保存下來并顯示出來。如果兩個(gè)哈希值不同，兩個(gè)交易就會(huì)被取消，銘刻失敗。

BRC20協(xié)議與索引器

對(duì)于Ordinal協(xié)議，我們銘刻，它就是文字NFT（對(duì)應(yīng)以太坊上的Loot），銘刻一張圖片，它就是圖片NFT（對(duì)應(yīng)以太坊上的PFP），銘刻一段音樂，它就是文本音頻NFT。那如果我們銘刻一段代碼，并且假設(shè)代碼是一段“釋放 FT 同質(zhì)化代幣”的代碼呢？

BRC20正是通過利用Ordinal協(xié)議將inscriptions（銘文）設(shè)置為JSON數(shù)據(jù)格式來部署、鑄造和增量Token，JSON包含一些代碼片段，描述Token的各種屬性，例如其供應(yīng)量、最大鑄造單位和唯一代碼。我們?cè)谏弦黄恼轮幸呀?jīng)講過，BRC20代幣的本質(zhì)是半同質(zhì)化代幣SFT，因而，在某些情況下它可以當(dāng)做NFT交易，可以在某些情況下當(dāng)做FT交易，這種對(duì)“不同情況”的控制是如何辦到的？答案是索引器。

索引器其實(shí)是一個(gè)記賬人，用來把接收到的信息分門別類的記錄在數(shù)據(jù)庫里。在序數(shù)協(xié)議中，索引器通過對(duì)輸入和輸出的追蹤，來確定排序這些sats在不同地址中的變化在BRC-20協(xié)議里，索引器有一個(gè)功能：記錄銘文中代幣余額在不同地址的變化。

所以我們可以從記賬人的第一個(gè)角度來看到不同的代幣存在形式：BRC20協(xié)議代幣其實(shí)存在于一個(gè)三個(gè)重?cái)?shù)據(jù)庫中。重第1層，記賬人是BTC礦工，數(shù)據(jù)庫類型是“鏈?zhǔn)綌?shù)據(jù)庫” ”，產(chǎn)生的BTC是FT資產(chǎn)。第二重層2，記賬人是序數(shù)索引器，數(shù)據(jù)庫類型是“關(guān)系型數(shù)據(jù)庫”，產(chǎn)生的帶序號(hào)的sats是NFT資產(chǎn)。第三重層3，記人是BRC20索引器，數(shù)據(jù)庫類型是“關(guān)系型數(shù)據(jù)庫”，產(chǎn)生的BRC20資產(chǎn)是FT資產(chǎn)。當(dāng)我們把BRC20“張”來算的時(shí)候，站的角度是序數(shù)索引器（由該索引器記錄），它按照自然就是NFT；當(dāng)我們把BRC20按照分拆好的“個(gè)”來思考的時(shí)候（尤其是充值到中心化交易所之后），站的角度就是BRC20索引器（由該索引器記錄或者是中心化交易）所的服務(wù)器記錄），它自然是FT。由此我們可以得到一個(gè)結(jié)論，半同質(zhì)化代幣SFT的存在是因?yàn)橛胁煌w系的記賬人導(dǎo)致的。

區(qū)塊鏈不就是一個(gè)數(shù)據(jù)庫嘛，所以有了礦工這個(gè)記賬人群來共同維護(hù)這個(gè)“鏈?zhǔn)綌?shù)據(jù)庫”（因?yàn)橹挥墟準(zhǔn)綌?shù)據(jù)庫才能實(shí)現(xiàn)真正的去中心化）。但兜兜轉(zhuǎn)轉(zhuǎn)，我們還是回到了中心化的“關(guān)系型數(shù)據(jù)庫”的老路。這也是為何前段時(shí)間Ordinal協(xié)議發(fā)起人，BRC20協(xié)議發(fā)起人，unisat錢包為了索引器是否要升級(jí)炒的不可開交的本質(zhì)原因--記賬本人們意見不一致啦。

但行業(yè)經(jīng)過十幾年的發(fā)展，還是積累了輝煌的“去中心化”的經(jīng)驗(yàn)，索引器可不可以用“鏈?zhǔn)綌?shù)據(jù)庫”替代關(guān)系型數(shù)據(jù)庫？中心化？比特幣生態(tài)的DA需求會(huì)不會(huì)溢出到其他的DA從而促進(jìn)多鏈生態(tài)繁榮和融合？我似乎看到了更多的可能性。

熱點(diǎn)：協(xié)議