一文瞭解銘文協定用例、實現方式與資產安全

封面:Photo by Laurin Steffens on Unsplash

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 代币的记账本,根据该文本数据可以解析出代币持有以及转移情况。主要包含以下内容:

{“p”:”brc-20”,“op”:”deploy”,“tick”:”ordi”,“max”:”21000000”,“lim”:”1000”}
{“p”:”brc-20”,“op”:”mint”,“tick”:”ordi”,“amt”:”1000”}
{“p”:”brc-20”,“op”:”transfer”,“tick”:”ordi”,“amt”:”1000”,}

以上是 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 區塊鏈的銘文

对于 BSC Chain、以太坊、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 屬性來實現的,也就顯得大同小異。

總結

本篇文章我們討論了多條鏈上的銘文實現原理。 總結來說,介紹的銘文都是利用一些公鏈系統特性,將線下資訊按照規定的標準保存在區塊鏈,並通過線下伺服器進行識別展示的過程。  介紹的這些銘文都未使用智慧合約,用戶在參與的時候可以減少大量的交易額外費用,但使用者需充分理解銘文協議的實現方式,避免誤轉帳或誤燃燒銘文,造成資產損失。

免責聲明:作為區塊鏈資訊平臺,本站所發佈文章僅代表作者及嘉賓個人觀點,與 Web3Caff 立場無關。 文章內的資訊僅供參考,均不構成任何投資建議及要約,並請您遵守所在國家或地區的相關法律法規。