2月1日，幣安Web3皮夾正式推出銘文市場，支援BRC-20、EVM等多種銘文協議。幾天前，OKX也宣布支持ARC-20、Runes、Doginals等銘文協議，引發整個市場對銘文的關注。在此背景下，由於銘文協議的複雜性和新穎性，各種安全問題頻出。這不僅威脅到使用者的資產安全，也對整個銘文生態的健康發展產生了負面影響。
針對此，Beosin安全團隊對主流銘文協議進行了梳理，幫助用戶了解銘文協議的用途、實現方式以及如何保護銘文資產。
銘文簡介
區塊鏈上所謂的銘文，就是透過區塊鏈的某些特性，在區塊鏈上記錄一些特定的且有意義的資訊。一旦資訊記錄到區塊鏈之上，便將永久保存在區塊鏈上，並且難以篡改。記錄到區塊鏈的資訊可以是多種類型，例如簡單的文字訊息，複雜的程式碼、圖像等都可以寫入區塊鏈，這樣一來，我們便可以使用一套標準來實現數位資產的功能。
銘文現狀
從最初BRC-20等比特幣公鏈銘文的出現，到現在銘文生態中幾乎每天都有層出不窮的銘文新協議以及新項目出現，銘文的發展可以說是突飛猛進。各個常見的公鏈也都加入了銘文生態圈，例如ETH公鏈上的Ethscription協議、BTC公鏈上的ARC-20協議、BSC公鏈上的BSC-20等協議、Polygon公鏈上的PRC- 20等協議......。這些協議都是為了在其公鏈上發布銘文所產生的，接下來的內容我們將介紹各種協議的實現方式以及用例。
銘文詳解
讓我們來介紹一下目前市場關注度較高的協議，來比較一下各公鏈的銘文協議到底有何共同點與不同點。
1. BRC-20
想講清楚BRC-20，首先要介紹UTXO與Ordinals。
BTC採用的是UTXO 模型，交易是以UTXO 為單位進行轉帳的。 UTXO 是Unspent Transaction Output 的縮寫，意思是未花費的交易輸出。 UTXO 模型不同於以太坊等公鏈的帳戶模型，它記錄交易事件，而不記錄最終狀態。計算某個用戶有多少比特幣，就需要將其地址的所有UTXO 求和，得到結果就是該用戶的持幣數量。
Ordinals是一個為比特幣最小單位聰（sats）進行編號的一個系統協議，可以為每個UTXO裡（包含了若干個聰）的每一個聰分配一個唯一的編號。 Ordinals也支援文字、圖片、音訊、視訊等寫入聰的功能，從而使得每個聰都具有獨特性，就類似於大家熟悉的以太坊非同質化代幣NFT，而我們將其稱之為比特幣NFT。
而BRC-20創始者則是基於Ordinals協議，想出了另外一套理念。既然Ordinals協議可以透過給予每個聰不同的「屬性」來創造比特幣NFT，那麼也可以透過給定一個統一的「格式」以及「屬性」來創造比特幣FT，也就是同質化代幣。
BRC-20透過Ordinals協議，將統一的JSON格式的文字資料寫入聰，該文字資料便是BRC-20代幣的記帳本，根據該文字資料可以解析出代幣持有以及轉移情況。主要包含以下內容：
以上是BRC-20的三種標準，其中，op字段表示的是需要執行的操作，包括deploy（部署）、mint（鑄造）以及transfer（轉移），tick表示的是需要執行操作的代幣名稱， max表示代幣發行總量，lim表示每份代幣最大鑄幣數量，amt表示需要操作的代幣數量，在transfer標準中，還存在“to”等字段，但這不是必須的，transfer是通過將該銘文發送給目標位址來實現餘額變化，如下圖所示：
link:https://twitter.com/blockpunk2077/status/1725513817982136617
2. ARC-20
ARC-20依然是比特幣公鏈上的銘文協議，和BRC-20協議一樣，都是在UTXO裡面寫入標準的數據來實現，但不同的是ARC-20協議不用在數據中指定ARC-20代幣的數量，而是使用該UTXO中的sats（聰，比特幣最小單位）來表示ARC-20代幣的數量，規則是1 sat=1 ARC-20 token。
ARC-20協議與BRC-20協議一樣，也分為部署、鑄造、轉移三個步驟，其中部署階段，需要向UTXO中填入標準的代幣名稱、代幣總量、鑄造限制、區塊信息、圖像資訊等；鑄造階段，需要用戶將代幣的名稱填入UTXO，而該UTXO的sats數量便為ARC-20代幣的鑄造數量，並非和代幣名稱一起填入UTXO；當用戶鑄造了ARC-20代幣，便可以將代幣發送給其他地址，在發送代幣時，用戶不需要再向UTXO裡面填入任何數據，而是直接將持有該代幣的UTXO轉移給其他地址。
link:https://twitter.com/blockpunk2077/status/1725513817982136617
查詢ARC-20代幣時，只需要一個索引，線下索引伺服器便可以讀取取代幣註冊資訊以及鑄造和轉移交易，不需要伺服器去計算資金轉移關係，查詢地址所擁有的ARC-20代幣數量，直接讀取持有該代幣的UTXO的sats數量便可以得到。
在了解了BRC-20和ARC-20之後，大家應該知道為什麼有些會誤將銘文資產轉到其它地址或是「燃燒」掉了。
由於BRC-20和ARC-20這類BTC銘文協議是基於UTXO交易的，因此銘文交易實際上是附加在BTC交易中的，用戶可能會在不完全理解銘文的情況下進行普通的BTC轉賬操作，將其現在的UTXO和其他UTXO進行融合拆分後發送給非預想的地址，從而導致銘文資產被誤轉或是被“燃燒”，造成不可逆轉的損失。
3. Ethscription
Ethscription是以太坊上創建和共享數據的協議，某些銘文便是使用該協議從而替代智能合約實現代幣發行的方案，使用銘文可以將用戶的成本降至極低。
以太坊在發送交易時，提供了一個calldata的資料塊，一般情況下普通ETH轉帳該資料塊會留白，如果是調用智能合約，則該資料塊將指定為調用函數的簽章以及各個參數資料。 Ethscription協議便是利用了calldata這一數據塊，在發送普通ETH轉帳的情況下，添加一些標準的數據，從而賦予相關的含義。
Ethscription是如何規定這些標準的資料呢？
首先如果想要創建一個Ethscription，其內容為圖像數據，則需要將圖像（圖像大小限制在96KB）轉換為Base64編碼數據的URI，格式為(data:image/png;base64,...)；接下來將該URI轉換為16進位字串；透過以太坊向目標地址發送一筆普通轉帳交易，並且將上述的16進位字串填入calldata，如下圖：
這樣一來，0xf1bf地址便擁有了該Ethscription，並且在之後創建的相同calldata的Ethscription將被視為無效。
如果想要轉移該Ethscription，就需要Ethscription擁有者向接收地址發送一筆普通轉賬，並且在calldata中填入創建該Ethscription的交易哈希，則接收地址便擁有了該Ethscription，如下圖：
4. EVM區塊鏈的銘文
對於BSCChain、以太坊、polygon等EVM區塊鏈，有一套共有的銘文刻錄方法，就是利用calldata數據塊存儲固定的格式數據，與上述保存圖像數據不同，該方式是向calldata中寫入標準格式的文字資料。
在BSC Chain上刻錄銘文，其銘刻格式與BRC20銘刻格式類似，例如銘刻格式為：data:,{"p":"_","op":"_","tick":"_"," amt":"_"}，則其中p字段所代表的是協議名稱，如bsc-20、bnbs-20、ltc-20、bep-20、drc-20、nrc-20、src-20等等； op字段所代表的是操作，一般為”mint”；tick字段所代表的是代幣名稱；amt字段所代表的是代幣數量。
這裡用以bnbs代幣為例，我們可以看到，只要向目標地址發送一筆普通轉賬，在calldata中填入data:,{"p":"bsc-20","op":"mint" ,"tick":"bnbs","amt":"1000"}便完成了bnbs代幣鑄造操作，如下圖。此時，0x22ef地址便擁有了1000枚bnbs代幣。
接下來需要轉移代幣，和上述一樣，需要向接收地址發送一筆普通轉賬，並將創建該bnbs代幣的交易哈希填入calldata，則接收地址便擁有了bnbs代幣，如下圖：
以太坊、polygon等鏈上也基本相同，但需要注意一點，上述BSC Chain的內容並不是evm鏈上創建銘文的唯一情況，不同evm鍊或不同協議之間填入的文本數據字段可能存在區別，轉移代幣的方式也可能有差異。但對於這類方式來說，都是利用了EVM鏈中的calldata屬性來實現的，也就顯得大同小異。
總結
本篇文章我們討論了多條鏈上的銘文實現原理。總結來說，介紹的銘文都是利用一些公鏈系統特性，將線下資訊依照規定的標準保存在區塊鏈，並透過線下伺服器進行識別展示的過程。介紹的這些銘文都未使用智能合約，用戶在參與的時候可以減少大量的交易額外費用，但用戶需充分理解銘文協議的實現方式，避免誤轉帳或誤燃燒銘文，造成資產損失。
APP 
