深入解讀Runes協議的底層設計機制與局限性

1. Runes(符文)概述

過去一年，web3領域最受關注的熱點無疑是銘文生態的爆發。其起源可追溯至Ordinals協議，該技術爲比特幣上的每個聰賦予唯一序號。Ordinals的核心開發者casey早在去年9月就提交了Runes協議的基礎代碼，但一直未正式上線。這導致一些項目提前分叉該代碼，發行了如RunesAlpha等協議。盡管存在爭議，但短短數月內數億美元的市值增長也展現了Runes協議的巨大潛力。

官方版本的Runes協議預計將於2024年4月20日左右在比特幣主網正式上線。這意味着項目方、錢包提供商以及NFT/FT交易平台將面臨一個重大挑戰：如何在沒有測試網的情況下直接適配主網。

本文將系統梳理Runes項目的底層字段演變，幫助讀者從根本上理解Runes與Brc20、Arc20等FT協議的區別，以便理性評估和參與。

2. 比特幣鏈上數據記錄方式

比特幣上主要有兩種將鏈下數據附加到鏈上的方案：銘刻和蝕刻。

2.1 蝕刻基礎原理

Runes採用的是蝕刻技術，這是一種直接將信息記錄到鏈上的方法。具體來說，是將數據寫入比特幣UTXO（未花費交易輸出）的op-return字段中。這一功能始於2014年Bitcoin Core客戶端0.9版本。OP_RETURN創建了一種可驗證但不可消費的輸出，允許數據存儲在區塊鏈上。

在比特幣區塊瀏覽器中，可以輕鬆看到交易中附加的op-return信息。例如，一個交易的輸出#3可能是一個封閉的圓形矩形，表示它不能被再次轉移或消費。這就像交易的備注區，永久保存在比特幣的存儲空間中，可通過交易哈希索引找到。

2.2 銘刻基礎原理

Ordinals/brc20等協議將元數據嵌入到交易的見證數據中。這一過程通過隔離見證和"向Taproot支付"（P2TR）方式實現，包括提交和揭露兩個階段，需要兩筆交易完成。

P2TR是比特幣2021年Taproot升級引入的交易輸出類型，允許更私密地存儲不同交易條件。具體來說，P2TR地址使用腳本哈希生成，在花費時提供真實腳本（包含銘文數據）。因此，上傳銘文數據需要先生成一個支付到此腳本生成的P2TR地址的UTXO（提交交易），然後在花費這個UTXO時，在見證腳本中提供真實腳本，從而將銘文數據上傳到鏈上（揭露交易）。

Ordinals協議規定，銘文在完成這兩筆交易後，綁定到第一個輸入的第一個聰上。

2.3 兩種數據上鏈方案對比

蝕刻：

• 優點：邏輯簡單直觀，交易成本低，不佔用全節點內存池。
• 缺點：受80字節長度限制，需高度壓縮數據編碼。

銘刻：

• 優點：幾乎不限制大小，具有一定隱私保護能力，支持多種玩法（如時間鎖、工作量證明）。
• 缺點：需要兩次上鏈交易，最終成本較高，對全節點內存池壓力大。

3. Runes底層設計解析

3.1 Runes 0.11版本

早期Runes協議字段分爲三部分：edicts（資產轉移信息）、etching（資產部署信息）和burn（銷毀）。

當op_Return中的信息解碼後呈現正確格式的edicts信息時，鏈下解析器會計算用戶資產的轉移情況，output字段指定轉移目標。

etching內容定義了資產部署的主要信息。與ERC721相比，主要區別在於limit和term字段限制了鑄造數量和可鑄造區間。這反映了銘文、符文項目與以太坊智能合約發行資產的根本差異。由於缺乏鏈上智能合約驗證，銘文協議統一定義了資產發行和用戶參與鑄造的方式，以實現公平發射。

3.2 Runes 0.18版本

最新版Runes協議字段分爲四個方面：

1. edicts：定義資產轉移方向，新增pointer參數用於修改默認轉移方向，以適應多種Runes資產同時轉出的情況，降低編碼量和交易成本。

2. Mint：新增字段，限制一筆交易只能鑄造一個資產，平衡了技術型和普通用戶的起跑線。

3. etching：資產部署方式發生重大變化。主要改動包括：

   • 資產ID改爲字符串形式，節省編碼空間。
   • terms字段引入height和offset參數，允許發行方指定鑄造起止點。
   • cap參數控制總鑄造次數。
   • 引入名字長度釋放規則，控制稀缺資源。
   • 採用銘刻技術（commit和reveal）進行部署，提供隱私保護。

4. turbo：新增字段，爲未來協議層變更預留。

4. Runes新版協議評價

優點：

• 貼合市場需求，解決了銘文生態中劣質資產橫行的問題。
• 嵌入Ordinals協議，具備現成用戶基礎。
• 作爲FT協議，彌補了Ordinals在市場運作方面的不足。
• 採用op_Return記錄鏈上數據，提供靈活的帳本能力和較高安全性。

缺點：

• 市場時機存在挑戰，緊張的開發時間可能影響生態初期發展。
• 規則復雜，資產名稱長度問題可能增加用戶被釣魚的風險。
• 未來兼容性存在疑慮，相比其他協議在L2或BVM方面的布局略顯滯後。