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屬性來實現的，也就顯得大衕小異。
總結
本篇文章我們討論了多條鏈上的銘文實現原理。總結來説，介紹的銘文都是利用一些公鏈繫統特性，將線下信息按照規定的標準保存在區塊鏈，併通過線下服務器進行識別展示的過程。介紹的這些銘文都未使用智能合約，用戶在參與的時候可以減少大量的交易額外費用，但用戶需充分理解銘文協議的實現方式，避免誤轉賬或誤燃燒銘文，造成資産損失。
聲明：
- 本文轉載自[PANews]，著作權歸屬原作者[Beosin]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
Artigos relacionados
如何質押 ETH？
