原文來源：歐科雲鏈研究院
原文作者：Jason Jiang
原文來源：歐科雲鏈研究院
原文作者：Jason Jiang
原文來源：歐科雲鏈研究院
原文作者：Jason Jiang
原文來源：歐科雲鏈研究院
原文作者：Jason Jiang
在Web 3 世界，鏈上活動所產生的數據直接對應著價值流動，掌握鏈上數據就能發現更多Alpha。加上近年加密市場頻繁遭遇風險事件，個人和機構用戶對鏈上數據也愈加敏感。鏈上數據已成為洞悉加密世界必不可少的“利器”。但面對近來風頭正盛的BRC 20 交易，我們對其進行地址標籤分析時，卻發現此前的BTC-UTXO 模型卻似乎並不完全適用。那問題究竟出在哪兒？又該如何解決？
BRC 20 交易與PSBT
分析問題前，首先要了解BRC 20 基本情況。 2023 年1 月，比特幣核心貢獻者Casey Rodarmor 提出“序數理論”（Ordinals Theory），允許用戶在比特幣最小單位“聰”上寫入任意文件（不超過4 MB 的圖像、文本、視頻等） 。隨後，匿名分析師@domodata 基於Ordinals 協議創建BRC 20 代幣標準。這是一種實驗性代幣標準，允許任何人在比特幣網絡發行代幣。
Ordinals 協議和BRC 20 標準給比特幣生態創造了價值轉移之外的全新用例，使其在減半之後有了另一種極具吸引力的敘事邏輯。作為最古老的區塊鏈生態，比特幣因此煥發無限活力，BRC 20 代幣也在2023 年上半年成為廣受關注的賽道：截至2023 年6 月29 日，BRC 20 相關代幣已超過6000種，市值超過6 億美元。
但與以太坊ERC 20 部署智能合約後可立即發行和傳輸代幣不同，BRC 20 並不是實際意義上的代幣，而是記錄特定文本的“聰”，因此需要單獨索引器來了解BRC 20 代幣的狀態或餘額。同時，BRC 20 是以公鑰腳本中的JSON 數據包為承載體，相關代幣合約部署以及代幣鑄造、轉移都需要利用Ordinals 協議將銘文設置為JSON 數據格式來實現。
由於比特幣公鑰腳本只存儲數據，並不支持智能合約指令執行程序，所以BRC 20 代幣也無法構建相關協議實現自動交割，理論上只能通過集中託管或OTC 完成交易。這些方式不論交易效率和信任程度都不盡如人意，於是PSBT（Partially Signed Bitcoin Transactions，部分簽名比特幣交易）開始被用於BRC 20 相關交易中。
這是因為，如今我們在對比特幣地址標籤進行解析時，主要基於UTXO 特性的Common Spending 和One-Time-Change 等原則進行追溯。其中，Common Spending 原則是指，如果一筆BTC 交易同時有多個輸入地址，那麼可認定這些input 地址屬於同一個實體，因為只有他/它有所有的私鑰才能將這些地址放在同一交易中。
圖片描述
圖片描述
圖片描述
圖片描述
圖片描述
（ordi 的deploy 交易-代幣轉賬）
圖片描述
（ordi 的deploy 交易-BTC 轉賬）
（2）在BRC 20 代幣的Transfer 過程中，Input 地址通常會有多個，我們可以通過查看交易的代幣轉賬來辨別本次交易的買方和賣方地址。例如，在下面這筆ordi 的Transfer 交易（https://www.oklink.com/cn/btc/tx/bc2ac0be40b33cfaf0dedf7bafc97de113ce56e2e6dc7caf67c116f00d1dc849）中，代幣發送方（bc1p...hdjn）為交易的賣方，代幣接收方（bc1p...wftk）為交易的買方。"OP_CHECKMULTISIG"但在BTC 轉賬交易的Input 裡會存在多個地址，其中有賣方地址，也可能會有買方地址和疑似第三方平台的地址："OP_CHECKMULTISIGVERIFY"綜上，BRC 20 交易的特殊性主要體現在：在Deploy 和Mint 過程中最多只會出現一個input 地址，無法滿足“Common Spending”原則的前提條件。在Transfer 過程中，由於input 地址中有可能包含多種角色，如果用基於“Common Spending”原則的UTXO 模型對交易地址進行標籤拓展，可能會將買方、賣方和第三方平台打上相同標籤，導致標籤錯誤，從而會誤導其他主體對BRC 20 市場的判斷，甚至會影響比特幣地址標籤的整體準確性和可信性。
或
如何消除BRC 20 對UTXO 標籤模型的影響？
為了消除BRC-20 交易帶來的負面影響，在拓展BTC-UTXO 標籤模型的過程中，我們可以選擇通過特定篩選機制識別和剔除相關交易，以保證整個BTC- UTXO 標籤庫的準確性。同時考慮到，多重簽名對基於“Common Spending”原則的BTC-UTXO 標籤拓展模型的影響，我們也需要對相關交易的input 和output 腳本進行解析，以過濾多簽地址，從而在理論上支持UTXO 標籤拓展不受影響。
其中，識別多簽主要是通過查看其鎖定腳本中是否包含多個公鑰和對應的簽名條件。多簽鎖定腳本通常包含類似於
或
的操作碼，並且需要滿足多個簽名條件才能解鎖資金。如果在輸出腳本中發現包含多個公鑰和對應簽名條件，那麼這個輸出就是一個多重簽名輸出。同樣地，如果輸入腳本包含了多個簽名，那麼這個輸入就是一個多重簽名輸入。
需要注意的是，在進行腳本類型解析時，我們首先要判斷交易是否為隔離見證交易。如果是隔離見證交易則需要對Witness 信息進行解析。以下為常見的非隔離見證交易腳本和隔離見證交易腳本列表：
以非隔離見證交易腳本Pay-to-Public-Key-Hash (P 2 P KH)為例。這是最常見的比特幣交易類型之一。在P 2 P KH 交易中，發送方需要提供接收方的公鑰哈希作為交易輸出腳本。接收方需要提供與該公鑰相對應的私鑰來解鎖輸出。在對P 2 P KH 進行解析時，主要規則為：
輸入腳本：包含簽名信息以及公鑰；script.getChunks().size() == 2 ；
輸出腳本：OP_DUP + OP_HASH 160 + pubkeyHash + OP_EQUALVERIFY + OP_CHECKSIG；判斷是否以OP_DUP 開頭並且以OP_CHECKSIG 結尾。
（https://www.oklink.com/cn/btc/tx/cbb6bbd6a828b15afe01ec77eab3e96a83be3d5ff56d99caf8185af79c3d1b53）
Address:bc1pd6pd4pdzx2an8w8pg8dlst8329ck8t8a6ehqqatglfstqmf3f9yss9yz7y
Winess：["1b003b4099402cde95be79ab7f4b488c74058c0f620cf4cbeb37a90ca871c4a499334a1262f24fdbe484d7511a54a04aa0d693b02159b603021942cb74f55e9d83"]
在隔離見證交易中，以P 2 WPKH 為例。這是一種使用隔離見證技術的交易類型，它可以提高交易的效率和安全性。在P 2 WPKH 交易中，發送方需要提供接收方的公鑰哈希作為輸出腳本。在對這類交易進行解析時，其規則為：
輸入腳本：EMPTY
witness：簽名+ pubkey；判斷時首先獲取input script 是否為EMPTY，然後判斷witness.getPushCount() == 2
輸出腳本： 0 + 20 byte witness program；判斷時首先判斷是否以0 開頭，之後判斷witness program 長度是否為20 byte。 （注：P 2 WPKH 的output script 中witness program 長度規定為20 byte。）
除了依據不同交易的輸入輸出腳本特徵對多簽地址進行識別，我們也可以根據相關特徵對BRC 20 交易進行篩選。根據調研，BRC 20 交易採用PSBT 技術通過線下簽名的形式完成，其隔離見證類型為Witness 里以83 為結尾的半簽名。
就如同下面這筆交易：
Witness 裡有以83 結尾的半簽名，所以理應將其視為BRC 20 相關交易。
