最近兩週我在研究 BTC 生態和各種銘文項目的時候，發現很少有文章能夠清晰地把原理和技術細節介紹的清楚：比如銘文在鑄造的時候，交易是如何發起的，UTXO 裡面的 sats 到底是怎麼被追蹤的，銘刻的內容到底是放在腳本什麼地方，以及 BRC20 在轉帳的時候為何需要兩次操作？我發現不了解這些技術細節，就很難搞明白 BRC20,BRC420,atomicals, stamps, 符文 Runes 這些各種協議的區別，本文將深入到 BTC 區塊鏈的基礎知識，試著回答上述問題。
BTC 的區塊結構#
區塊鏈本質是一種多用戶記帳技術，用計算機科學術語來說，是一種分佈式數據庫，每一段時間內的記錄（帳目）組成一個區塊，然後根據時間先後順序進行帳本擴展。
我們用 excel 做了表格來說明區塊鏈的工作原理。一份 excel 文件代表了一個區塊鏈，其中每一個單獨表格表示一個個區塊，區塊按照時間順序從 560331，560332. 一直到最新的 560336. 560336 會在區塊內打包最近的交易。區塊內部主體部分就是我們在會計領域最常見的複式記帳法，一邊地址記做借出（debit）就是 inputs from，另一邊地址記做貸入（credit）就是 outputs to。Value 對應相應地址的 BTC 數量。Inputs 的幣的數量會大於 Outputs 幣的數量，差額就是用戶層面的轉帳費，也是礦工（記帳人）的取得的手續費。區塊頭部會獲取上個區塊高度，上個區塊的哈希值，本區塊的建立時間（時間戳），和隨機數。那麼作為去中心化的記帳技術，到底是誰來搶到下一個區塊的記帳權呢？靠的就是這個隨機數和與之對應的哈希值。擁有算力的礦工通過對當前區塊的隨機數進行哈希計算，最先得到符合條件哈希值的礦工擁有下一個區塊的記帳權並且贏得區塊獎勵和轉帳費。最後是腳本區域，可以用來做一些擴展應用，比如腳本 op_return 可以當做附言欄。需要注意的是，在實際的區塊中，腳本區是附著在 input 和 output 信息中的，而不是真的另外單獨一個區域。比如附著在 input 的腳本是解鎖腳本（ScriptSig），需要錢包地址進行私鑰簽名授權允許轉出，而附著在 output 的腳本是鎖定腳本（ScriptPubKey），用來設置收到該 BTC 的解鎖條件（一般情況條件就是 “有相應私鑰的人才能消費”）。
上面兩張圖是原始的 input 和 output 的數據結構表，在執行層面，腳本表現為交易信息的附帶參數，其中解鎖腳本（ScriptSig）因為需要私鑰授權，也被稱為 “見證數據”（witness data）。
隔離見證和 Taproot#
儘管比特幣網絡已經運行了超過 10 年，沒有發生過什麼顯著的事件，但曾多次出現交易成本飆升到不再可行的高點。因此，比特幣的開發人員一直在討論如何最好地擴展網絡，以處理未來不斷增長的交易量。
2017 年，這場辯論達到高潮，比特幣開發社區分裂成兩派，一派是支持使用軟分叉實施名為 SegWit 的功能，另一派是支持直接區塊擴容的 “大區塊” 派。
我們在上文提到了解鎖腳本需要用到私鑰授權生成 “見證數據”，那麼是不是可以把這個見證數據從區塊中分離，從而變相增加每個區塊可容納的交易數呢？隔離見證（Segregated Witness）在 2017 年 8 月正式激活。它的實現方式正是將所有的交易數據分為兩部分，一部分是交易的基本信息（Transaction Data），另一部分是交易的簽名信息（Witness Data），並把簽名信息保存在一個新的數據結構中，是被稱為 “隔離見證（witness）” 的新區塊中，並與原始交易分開傳輸。
在技術上，SegWit 的實施意味著交易不再需要包括見證數據（不會佔用比特幣原本為區塊安排的 1MB 空間）。取而代之的是，在一個區塊的末尾，為見證數據創建了一個額外獨立的空間。它支持任意的數據轉帳，並有一個折扣的 "區塊重量（block weight）"，巧妙地將大量的數據保持在比特幣的區塊大小限制內，以避免硬分叉的需要。這樣，比特幣交易的交易數據大小提高了上限，同時降低了簽名數據的交易費用。在 SegWit 升級之前，比特幣的容量上限是 1 MB，而 SegWit 之後，雖然單純交易的容量上限仍舊是 1M，但隔離見證空間的大小達到了 4 MB。
Taproot 於 2021 年 11 月實施，由 3 項不同的比特幣改進提案 (BIP) 組成，其中包括：Taproot、Tapscript 及其名為「Schnorr 簽名」的全新數字簽名方案。Taproot 旨在為比特幣用戶帶來諸多好處，例如提升交易私密性和降低交易費用。還將讓比特幣執行更多複雜的交易，從而拓寬應用場景（新增加了一些操作碼 opcodes）。
這些更新是 Ordinals NFT 的關鍵推動因素，它將 NFT 數據存儲在 Taproot 腳本路徑的花費腳本（spent script）中（見證數據空間）。這次升級使得結構化和存儲任意的見證數據變得更加容易，為 "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）
這裡的交易 2 雖然是一筆交易，但從功能上來說他擔當了賬戶餘額的作用，表示在完成這筆 100 元轉帳後 A 的賬戶上還剩餘 900 元。
那麼問題來了，為啥非要造一個這樣的 UTXO 呢？因為在 BTC 區塊鏈上只能記錄交易，沒法記錄賬戶餘額。如果沒有這個 UTXO 的話，要計算餘額需要把一個賬戶的所有交易的入帳和出帳全部累加一遍，這是一個非常消耗時間和計算資源的事情。而 UTXO 的出現巧妙的避免了在計算餘額時要回溯所有交易的痛點問題。
UTXO 有個特點，就是跟硬幣一樣，不能掰開用，那麼交易過程中如何湊夠輸入金額，又如何找零的呢？我們可以用硬幣來做類比（實際上每次當你看到 UTXO 這個單詞的時候請自動翻譯成 “硬幣” 比較好）。
小明給小剛轉帳 1 比特幣。整個過程是這樣的，小明要收集足夠的 input，比如小明的地址對應的以往交易中，找到了一个面值為 0.9 的 UTXO，不夠 1 比特幣，好在交易中是允許有多個輸入的，所以小明又找到了一个面值 0.2 的 UTXO，這樣在這次轉帳的交易中，就會有兩個輸入。同時輸出也會有兩個，一個是指向小剛地址，面值是 1 比特幣。另一個指向小明自己的地址，面值是 0.1 比特幣，這個輸出就是找零了（這個例子忽略了 gas）。
換句話說，小明口袋裡面有兩個硬幣，一個面值 0.9，另一個面值 0.2，此時小明需要支付面值 1 的硬幣，就需要同時把這兩個硬幣遞給小剛，小剛收到後找零 0.1 給小明。所以這個記帳模型的本質就是通過 “找零” 的動作來避免了 “計算餘額”。
Ordinal 協議的排序系統#
Ordinal 協議可以說是本輪 BTC 生態爆發的源頭，是把同質化的 BTC 分解成最小單位 sat，然後對每一個 sat 標記一個序號。那是怎麼做的呢？
我們知道，BTC 的總量是 2100 萬枚，一枚 BTC 最小可以拆分到一億份（sat），所以 BTC 的最小單位就是 sat，這些 BTC 也好，最小單位 sat 也好，都是典型的同質化代幣 FT。我們現在試著給這些 sats 分配一個序號（ordinal）。
前面在談到區塊數據結構的時候，我們提到交易信息需要注明 input 的地址和數額以及 output 的地址和數額。而每個區塊是包含了兩部分交易：BTC 出塊獎勵和轉帳的手續費。手續費交易必然有 input 和 output，但出塊獎勵因為是憑空生成的 BTC，無 input 地址，所以這個 “input from” 的字段是空白的，也叫做 “coinbase 交易”。BTC 總量的 2100 萬枚都是來源於這個 coinbase 交易，也是所有區塊中交易列表排列在第一位的。
Ordinal 協議規定如下：
- 編號：每一個 sat 以他們被開採出來的順序進行編號
- 轉移：按照先進先出規則，從交易的輸入轉移到輸出
第一條規則相對簡單，它決定了編號只能由挖礦獎勵中的 coinbase 交易生成。例如，若第一個區塊的挖礦獎勵為 50 個 BTC，則第一個區塊會分配出 [0;1;2;...;4,999,999,999] 範圍的 sats；第二個區塊獎勵也為 50 BTC 時，則第二個區塊會分配出 [5,000,000,000;5,000,000,001;...;9,999,999,999] 範圍的 sats。
這裡比較難理解的部分在於，由於 UTXO 實際上包含很多個聰，那麼這個 UTXO 中的每一個聰看起來都一樣，怎麼給他們排序呢？這個實際上是第二條規則決定的，舉一個簡單的例子吧：
我先假設 BTC 的最小分割單位是 1，總共出了 10 個區塊，每個區塊的出塊獎勵是 10 個 BTC，即總量是 100 個。我們直接可以給這 100 個 BTC 賦予一個（0-99）的序號。如果沒有任何轉帳情況，那我們只知道第一個區塊的 10 個 BTC 編號是（0-9），第二個區塊的 10 個 BTC 編號是（10-19），一直到第十個區塊的 10 個 BTC 編號是（90-99）。這其中因為沒有任何花費，也就沒有任何 output，我們就只能給每 10 個 BTC 賦予一個編號範圍。
假設在第二個區塊中加入兩個支出（output），一個是 3BTC，一個是 “找零” 的 7 BTC，對應於給別人轉帳了 3 個 BTC，再給自己找零 7 個 BTC。此時在區塊的交易列表中，假設給自己找零的 7 個 BTC 排名第一 (對應的編號是 10-16)，給別人的 3BTC 排第二（對應的編號是 17-19）。這就通過對 output 的的轉移確認了某個 UTXO 所包含 sats 的順序集合。
注意是每一個 sat 不是 UTXO! 由於 UTXO 是不可再分的最小交易單元，因此 sat 只能存在於 UTXO 中，且 UTXO 包含了一定範圍的 sats，且只能在花費某一 UTXO 後產生新的輸出中對 sats 編號進行拆分。
至於用什麼方式來表達這個 “編號”，Ordinal 支持多種形式，比如上面提到的 “整數法”，其他還有十進制小數法，度數法，百分比法，純字母命名法。
sats 有了統一的序號之後，就可以考慮銘刻了（inscription）了。我們在上文中提到，可以在見證數據區域 4M 大小的空間上傳任意數據類型的文件，不管是文本，還是圖片和視頻，上傳之後，文件會自動轉為 16 進制存放在的 taproot 腳本區。所以是，1 個 UTXO，對應 1 個 Taproot 腳本區，而這 1 個 UTXO 會同時包含很多 sats（整體是一個 sats 序列集合，為了防止粉塵攻擊，限制單個 UTXO 中的比特幣數量不可少於 546 聰。）。Ordinal 協議為了方便記錄，人為地規定 “使用這個序列集合的第一個 sat 編號來代表綁定關係”（白皮書原話是第一個 output 的第一個聰的編號），比如包含（17-19）號 sats 的 UTXO 就直接用 17 號來代替這個集合和銘刻內容綁定。
Ordinal 資產的鑄造和轉移#
Ordinal NFT 很顯然就是把各種文件上傳到隔離見證區的腳本中並與之綁定一個 sats 序列集合，從而實現了在 BTC 鏈上發行 NFT 資產。但是這裡還有一個問題，隔離見證區的腳本即包含 input 的解鎖腳本，又包含 output 的鎖定腳本，那麼內容是放在哪個腳本中呢？正確的答案是兩者都有。這裡不得不提到區塊鏈技術中的 commit-reveal 機制。
區塊鏈中的 Commit-Reveal 機制是一種用於確保信息公平和透明處理的協議。這個機制通常用在需要提交隱藏信息（如投票或競標），然後在以後的某個時間點揭示這些信息的場景中。Commit-Reveal 機制分為兩個階段：提交（Commit）階段和揭示（Reveal）階段。
-
提交（Commit）階段：在這個階段，用戶提交他們的信息（如投票選擇或競標價格），但這個信息是加密的。通常，用戶會生成這個信息的哈希值（即信息的加密摘要），然後將這個哈希值發送到區塊鏈上。由於哈希函數的特性，它們可以生成一個獨特的輸出（哈希值），這個輸出對於原始信息來說是不可逆的。這意味著無法從哈希值推斷出原始信息。這個過程確保了信息在提交時的保密性。
-
揭示（Reveal）階段：在一個預定的以後時間，用戶必須揭示他們的原始信息，並證明它與之前提交的哈希值相匹配。這通常是通過提交原始信息以及用於生成哈希值的任何附加數據（如隨機數或 “鹽”）來完成的。網絡然後驗證這個原始信息的哈希值是否與之前提交的哈希值相同。如果匹配，則原始信息被接受為有效。
我們前面講過，銘刻的內容是需要和 UTXO 包含的 sats 序列集合綁定一起，UTXO 在區塊中是一個 output，所以必須附著在 output 的鎖定腳本中。但是 BTC 的全節點需要在本地維護和傳輸全網絡所有的 UTXO 集合。想象一下，要是有 1 萬個 4M 的視頻文件直接上傳到 1 萬個 UTXO 的鎖定腳本，那所有的全節點需要有超高的存儲空間和超快的網速，可以說整個鏈直接就崩了。因此，唯一的解決方法是把內容放到 input 中的解鎖腳本，然後再讓這個內容 “指向” 到另一個 output。
所以說 Ordinal 資產的鑄造是需要分為兩步（錢包是把這兩步進行合併處理了，在構造交易時，同時構造 commit-reveal 這個父子交易，用戶體驗上會感覺只有一個步驟並且節省了 gas 費）。
在鑄造階段，用戶首先需要上傳某個文件的哈希值到 commit 交易中（自己 A 地址給自己 B 地址轉帳）的 UTXO 中的鎖定腳本，因為是哈希值，所以不佔用過多全節點的 UTXO 數據庫空間。其次，用戶再構造一個新的交易（自己 B 地址給自己 A 地址轉帳），稱之為 reveal 交易，此時的 input 需要使用上一步 commit 交易中含有文件哈希值的那個 UTXO，並且該 input 的解鎖腳本必須包含原始銘刻文件。用白皮書中的原話描述，就是 “首先，在 commit 中，創建一個提交到包含銘文內容的腳本的 taproot 輸出。 其次，在 reveal 交易中，使用 commit 交易產生的輸出，來顯示鏈上的銘文內容。”
在轉移階段，Ordinal NFT 和 BRC20 稍有不同，Ordinal NFT 因為是整體轉移，只需要把綁定某個 UTXO 的 NFT 直接轉給接收者即可，類似於普通的 BTC 轉帳。但 BRC20 因為牽扯到自定義數額轉帳，同樣分為兩步，第一步叫銘刻 “交易”（Inscribe "TRANSFER"），第二步叫轉帳 “交易”(Transfer "TRANSFER")，第一步的銘刻交易實際類似於一個 Ordinal NFT 的鑄造過程，暗含了 commit-reveral 父子交易對，第二步轉帳交易類似於一個普通的 Ordinal NFT 的轉帳，把綁定某個 UTXO 的 BRC20 資產直接轉給接收者。有的錢包會把這三個交易（父子孫三代交易）同時構建，從而節省時間和 gas。
總結來說，commit 交易用來把銘刻內容（原始內容的哈希值）和帶序號的 sats（UTXO）綁定，reveal 交易用來把內容顯示出來（原始內容）。這個父子交易對共同完成了對於 NFT 的鑄造。
P2TR 與一個例子#
上面關於鑄造的技術討論還沒完結，因為有人會好奇，reveal 交易到底是如何驗證 commit 交易中的銘文信息呢？為啥構造交易的時候需要自己的 AB 兩個地址互相轉帳呢？打銘文的時候也沒看到需要準備兩個錢包啊。這裡就需要講到 Taproot 的重大升級之一 P2TR 了。
P2TR （Pay-to-Taproot）是由 Taproot 升級引入的一種新類型的比特幣交易。P2TR 交易通過允許用戶使用單一公鑰或更複雜的腳本（如多重簽名錢包或智能合約）來花費比特幣，實現了更高的隱私和靈活性。這是通過使用 Merkleized Abstract Syntax Trees（MAST）和 Schnorr 簽名來實現的，這些技術使得可以在單個交易中有效地編碼多種花費條件。
-
創建花費條件
要創建一個 P2TR 交易，用戶首先定義一個花費條件，例如單一公鑰或更複雜的腳本，指定了花費比特幣的要求（例如，多重簽名錢包或智能合約）。 -
生成 Taproot 輸出
然後，用戶生成一個 Taproot 輸出，其中包括一個單一公鑰（公鑰代表花費條件）。這個公鑰是從用戶的公鑰和腳本的哈希的組合中派生出來的，使用一種稱為 “tweaking” 的過程。這確保了輸出看起來像一個標準的公鑰，使其在區塊鏈上與其他交易難以區分。 -
花費比特幣
當用戶想要花費比特幣時，他們可以使用他們的單一公鑰（如果花費條件被滿足），或者透露原始腳本並提供必要的簽名或數據以滿足花費條件。這是通過使用 Tapscript 來完成的，它允許更高效和靈活地執行花費條件。 -
驗證交易
礦工和節點隨後通過檢查所提供的 Schnorr 簽名和數據與花費條件進行驗證交易。如果條件被滿足，交易被視為有效，比特幣可以被花費。 -
增強的隱私和靈活性
因為 P2TR 交易只在花費比特幣時透露必要的花費條件，所以它們保持了高水平的隱私。此外，使用 MAST 和 Schnorr 簽名使得能夠高效地編碼多個花費條件，允許更複雜和靈活的交易，而不會增加交易的總體大小。
以上就是 commit-reveal 機制在 P2TR 中的應用方式，我們以一個實際案例來做說明。
使用區塊鏈瀏覽器https://www.blockchain.com/ 我們來研究一個 Ordinal 圖片 NFT 的鑄造過程，包括了之前的 commit-reveal 兩個階段。
首先，我們看到 commit 交易的 Hash ID 是（2ddf90ddf7c929c8038888fc2b7591fb999c3ba3c3c7b49d54d01f8db4af585c）。可以注意到，這筆交易的輸出不包含銘文數據（實際上放的是 16 機制圖片文件的哈希值），網頁中也沒有相關的銘文信息。這個輸出的 (bc1p4mtc.....) 地址其實是通過 “tweaking” 過程產生的臨時地址（代表了腳本解鎖條件的公鑰），和 taproot 主地址（bc1pg2mp...）共享一個私鑰。此交易中的第二個 UTXO 屬於返還的 “找零” 操作。如是就實現了銘文內容與第一個 UTXO 包含的 sats 的綁定。
接著，我們查看 reveal 交易的記錄，其 Hash ID 是（e7454db518ca3910d2f17f41c7b215d6cba00f29bd186ae77d4fcd7f0ba7c0e1）。在這裡，我們可以看到 Ordinals inscription 的信息。這筆交易的 input 地址正是前一個交易產生的臨時輸出地址（bc1p4mtc.....），input 的解鎖腳本則包含了原始圖片的 16 進制文件，而輸出的 0.00000546BTC（546 聰）則是將這個 NFT 發送到自己的 taproot 主地址（bc1pg2mp...）。基於 First in First Out 原則以及 “綁定的是第一個 output 的第一個聰的編號”，雖然前後兩個 UTXO 包含的 sats 的數量有變化，但是綁定的 sat 序號不變。所以，我們可以在（sat 1893640468329373）中找到這個銘文所在的聰。
（https://ordinals.com/sat/1893640468329373）
這兩個交易（屬於父子交易）在鑄造時會同時由錢包提交給內存池，所以只需要花費一筆 gas，也很大幾率是進入到同一個區塊中被礦工記錄並廣播 (以上例子中的兩個交易正是同時存在於區塊 790468 中。)。礦工和節點隨後通過檢查 reveal 交易中的 input 所提供的 Schnorr 簽名以及 16 進制圖片的哈希值與 commit 交易中的 output 鎖定腳本中的 16 進制圖片哈希值進行驗證。如果兩者相同，交易被視為有效，這個比特幣的 UTXO 可以被花費，那麼這兩個交易自然就被永久記錄在 BTC 的區塊鏈數據庫中，NFT 的圖片也自然被保存下來並顯示出來。如果兩個哈希值不同，兩個交易會被取消，銘刻失敗。
BRC20 協議與索引器#
對於 Ordinal 協議，我們銘刻一段文本，它就是文字 NFT（對應以太坊上的 Loot），銘刻一張圖片，它就是圖片 NFT（對應於以太坊上的 PFP），銘刻一段音樂，它就是音頻 NFT。那如果我們銘刻一段代碼，並且這段代碼是一段 “發行 FT 同質化代幣” 的代碼呢？
BRC20 正是通過利用 Ordinal 協議將 inscriptions（銘文）設置為 JSON 數據格式來部署、鑄造和轉移 Token，JSON 包含一些代碼片段，描述 Token 的各種屬性，例如其供應量、最大鑄造單位和唯一代碼。我們在上一篇文章中已經講過，BRC20 代幣的本質是半同質化代幣 SFT，也就是說，在某些情況它可以當做 NFT 交易，某些情況可以當做 FT 交易，這種對 “不同情況” 的控制是如何辦到的呢？答案是索引器。
索引器其實是一個記帳人，用來把接收到的信息分門別類的記錄在數據庫裡。在 Ordinal 協議中，索引器通過對 input 和 output 的追蹤，來確定排序好的 sats 在不同地址中的變化。在 BRC-20 協議裡，索引器多了一個功能：記錄銘文中代幣餘額在不同地址的變化。
所以我們可以從記帳人的視角來看到不同的代幣存在形式：BRC20 協議代幣其實存在於一個三重數據庫中。第一重 Layer1，記帳人是 BTC 礦工，數據庫類型是 “鏈式數據庫”，產生的 BTC 是 FT 資產。第二重 layer2，記帳人是 Ordinal 索引器，數據庫類型是 “關係型數據庫”，產生的帶序號的 sats 是 NFT 資產。第三重 layer3，記帳人是 BRC20 索引器，數據庫類型是 “關係型數據庫”，產生的 BRC20 資產是 FT 資產。當我們把 BRC20 按照 “張” 來算的時候，站的角度是 ordinal 索引器（由該索引器記錄），它自然是 NFT；當我們把 BRC20 按照分拆好的 “個” 來思考的時候（尤其是充值到中心化交易所之後），站的角度是 BRC20 索引器（由該索引器記錄或者是中心化交易所的伺服器記錄），它自然是 FT。由此我們可以得到一個結論，半同質化代幣 SFT 的存在是因為有不同層級的記帳人導致的。
區塊鏈不就是一個分佈式數據庫嘛，所以才有了礦工這個記帳人群體來共同維護這個 “鏈式數據庫”（因為只有鏈式數據庫才能做到真正的去中心化）。但兜兜轉轉，我們還是回到了中心化的 “關係型數據庫” 的老路。這也是為何前段時間 Ordinal 協議發起人，BRC20 協議發起人，unisat 錢包為了索引器是否要升級炒的不可開交的本質原因 -- 記帳人意見不一致啦。
但是行業經過了十幾年的發展，還是積攢了不少 “去中心化” 的經驗，索引器可不可以用 “鏈式數據庫” 替代關係型數據庫？能不能採用欺詐證明或者 ZKP 來保證安全和去中心化？比特幣生態的 DA 需求會不會溢出到其他的 DA 從而促進多鏈生態繁榮和融合？我似乎看到了更多的可能性。
本文由 @hicaptainz 原創
關注作者，web3 不迷路
參考資料
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