作者:十四君

1、Runes(符文)是什麼?

過去一年,web3最大的敘事莫過於銘文生態的爆發,最初的起點便是Ordinals,是一種為btc上每個聰給予唯一性序號的技術,可拓展閱讀:解讀比特幣Oridinals協議與BRC20標準原理創新與局限

其核心創始人casey,在去年9月就提交了基礎版的Runes代碼,但是一直遲遲沒有發布主網上線,因此在9月的銘文熱潮中,runeAlpha等項目便提前fork了該代碼,單獨發行了RunesAlpha等協議,雖然有一定抄襲的說法,但是短短數月數億的總市值增長也讓人看到Runes協議的無窮潛力。

那麼由Ordinals協議的創始人casey所設計的,官方正版的Runes協議也將在2024.4.20號左右正式官宣上線。且直接上線btc主網,因此各路項目方想要發行Runes資產,各路錢包、NFT/FT交易市場想要支持Runes都將面臨區塊鏈行業最難的挑戰之一,如何在沒有測試網的情況直接衝刺主網!

而官方的Twitter發言更是高度自信~順帶學新單字:Seppuku

深入解讀Runes協定的底層設計機制與限制

本文,將會系統的梳理符文專案的底層場域變遷,讓大家從根本上理解Runes與Brc20、Arc20等FT協定的差異點,對比優缺理性決策參與。

2、比特幣上是如何記錄額外資訊的?

比特幣上有兩種主流的鏈下數據附著在鏈上的方案,銘刻與蝕刻

2.1、蝕刻基礎原理

Runes使用的是蝕刻技術,是一種簡單直觀記錄資訊到鏈上的方式:即寫入bitc中UTXO(未花費交易)的op-return字段內,從功能在Bitcoin Core 用戶端0.9 版中開始啟用的(14年),OP-RETURN 會創造了一種明確的可驗證不可消費型輸出,讓資料存在區塊鏈上,類似utxo的輸出,但並不可被消費。

在btc的區塊鏈瀏覽器中可以輕鬆看到,該筆交易就附著了一個op-return的訊息,例如下圖:

深入解讀Runes協定的底層設計機制與限制

可以看到,這裡的輸出#3,其實是遊離的,雖然他佔據的一個該筆utxo的output的輸出位置,但是他是一個閉環的圓矩形,這就說明他是不能被再次轉移消費的,所以他就像是一個交易的備註區一樣,就留在了比特幣的儲存空間上,透過交易哈希區索引找到他。

細心的你可能會發現, 為什麼OP_RETURN的後面有一個RUNE_TEST 這就是將具體內容解碼後的結果,點開明細按鈕後,就可以找到52554e455f54455354 這樣的編碼串,其實一串十六進位編碼數據,解碼後來就可以得到RUNE_TEST,同理,明細裡還有其他的編碼,最終解碼後會成為一串字符串,大概是json的格式,從而體現出Runes資產的部署、鑄造、發行等等寓意。

2.2、銘刻基礎原理

其實Ordinals/brc20等協議中,要嵌入元資料到鏈上,都是寫到交易的見證資料(witness data, witness field)中,這一銘刻銘文過程透過隔離見證(Segregated Witness, SegWit)和「向Taproot支付」(Pay-to-Taproot, P2TR)的方式實現,其中包含了提交(commit)和揭露(reveal)兩個階段也就是最終2筆交易來完成。

其實P2TR是比特幣的交易輸出類型,它是在2021年進行的Taproot升級中引入的,它使得不同的交易條件可以更「隱私」地儲存在區塊鏈中,之所以提升隱私是因為只有在揭示的時候,才能看到具體完整內容。具體來說產生p2tr地址使用的是腳本hash,在花費時提供真正腳本(包含銘文數據),所以為了上傳銘文數據,需要先生成一個支付到此腳本生成的p2tr地址的utxo(commit交易),然後花費這個utxo時,需要在見證腳本中提供真正腳本,也就把銘文資料上傳到了鏈上(reveal交易)。

其實Ordinals協議非常好理解,就是在完成這個銘文過程(commit、reveal)兩筆交易都上鍊後,ordinals協議則定義規定此銘文綁定到了第一個輸入的第一個sat上。所以,綁定的過程就是銘刻,綁定到結果就是銘文。

2.3、比較兩者數據上鍊方案

蝕刻:

  • 優點:邏輯簡單直覺明確,交易成本低,可以不佔用全節點記憶體池。
  • 缺點:限制於80位元組長度,需要高度壓縮資料編碼。

銘刻:

  • 優點:幾乎不限制大小,有一定隱私保護能力,有多種玩法(時間鎖、工作量證明)等
  • 缺點:交易需要2次上鍊,導致最終成本較高,commit存續時間長,對全節點記憶體池壓力較大。

3、Runes底層設計解讀

Runes協議最初的程式碼是casey發佈在Ordinals 0.11.版本上,而最新的Ordinals 已經演進到0.18版本,巨大的版本變化,也讓我們有機會步入一個頂級協議的設計過程中,就像十四君曾經解讀的ERC721/ERC3525/ERC3475等標準,擴展閱讀:

我們不妨也踏入Runes的起點和終點兩個版本的場域變化,來解讀Runes的價值依規。

3.1、Runes 0.11版本解讀

最初的Runes整體的欄位分成3個部分,edicts( 資產轉移資訊),etching( 資產部署資訊),burn(銷毀)。

深入解讀Runes協定的底層設計機制與限制

具體來說,當一筆交易的op_Return裡,訊息解碼之後能夠呈現edicts 的訊息,且格式正確,那麼鏈下的解析器,就會計算出該用戶的資產發生了轉移,其中的output就是轉移的目標地。

同理etching 的內容也直接呈現了部署資產的主要訊息,我們可以和ERC721對比,最大的差別在於limit和term 限制了mint的數量和可mint的區間。而這點也就是銘文、符文項目與以太坊智能合約發行資產的根本性差別,由於鏈上缺乏智能合約的驗證,這就少了實時驗證的能力,如果某個項目方發行鏈上的資產還自己運行一套新的銘文協議來定制自己的白名單Mint、代幣經濟學釋放速率,版稅繳納等等功能,都將會缺乏共識,就沒有人來參與這個項目了,所以銘文協議( brc20、atomical、Runes)等都是統一定義了資產發行的方式,也統一了用戶參與mint的方式,以公平發射的理念,完全開放用戶參與,進一步杜絕了項目方過度幹預資產市場認知的情況。

即使是專案方才透過掃貨累計資產來控制市場,也需要付出龐大的gas代價,這個過程裡可被使用者感知到並且自由選擇。

那最初版本的Runes協議設計,其實已經挺完善了,因此演變出的runealpha,哪怕是山寨的也佔據不少的市場規模,累計82W的交易筆數,僅手續費就消耗掉312個BTC。

使用者可以輕易的使用rune欄位本身的設計實現資產的複合、拆分,甚至一旦Runes資產與Ordinals、atomical等資產跨協議複合了,也可以藉助op_Return多樣的語言表達性,從而實現拆分。

那最新的Runes 協定在0.18中實現了什麼,又是怎樣的考慮從而要有這樣的欄位呢?

3.2、Runes 0.18版本解讀

要看懂Runes 0.18十分艱難,因為缺乏測試網,基本上都只能從casey的源代碼裡看邏輯,最終梳理出來字段分4個方面:

深入解讀Runes協定的底層設計機制與限制

首先edicts還是定義資產轉移方向方面的定義,與runeAlpha基本上一致,差別的是多了一個pointer的參數,這是用來修改資產預設轉移方向的,原本的預設轉移是第0位,有了這個參數後,可以設定為1或其他,設計理念是為了適配多種Runes資產同時轉出的時候,降低op_Return編碼量的作用,最終可以降低用戶的交易成本。

其次,新增了Mint字段,由於他的mint放在了和edicts等同級別的物件裡,這也意味著一筆交易只能mint一個資產,這與之前RunesAlpha的時候不同,那時刻意的設計可以實現一筆交易mint大量新資產,這樣一來平衡了技術打資產和普通用戶打資產的起跑線,大家都要靠爭gas來獲取了。

部署資產的方式巨變

最後比較重要的改變是etching也就是部署資產的細節設計,完全欄位內容如下:

深入解讀Runes協定的底層設計機制與限制

基本上看暈了吧,確實是非常複雜的部署新資產方式,讓我們詳細道來~

首先較大的改動點是為了降低op_Return編碼量的設計,畢竟op_Return限制80位元組的長度每一個編碼空間都要珍惜。因此casey做了資產id的變化,從單純的區塊高度+交易序號產生的唯一id值變化為字串形式的區塊高度+冒號+交易序號,由於比特幣主網也才80多w的區塊高度,所以最終的id編碼節約了一半,可別小瞧,在批量Mint,批量轉移場景就成倍的降低成本了。

其次是保障參與者公平性的terms字段,現在部署資產開始Mint不再是runealpha那樣,依據部署資產協議的交易上鏈的區塊高度開始,而是發行方指定的height和offset作為起終點。這樣一來,用戶即使不時時刻刻盯著內存池,從而挖掘最新可以被mint的機會,也不用太擔心誤入釣魚山寨項目中。畢竟專案方可以提前先部署好資產,然後在進行一系列的營運宣發活動,最終讓用戶參與,除了區間高度作為參與時間的衡量外還有cap,作為總mint次數,進一步控制了資產發行的規模,不再是無極限mint,而是限定發行,先到先得。

作為資產發行協議,那麼如何控制發行方的規模和權益便是一大挑戰,對於銘文而言,最重要的就是資產名字,那麼Runes裡名字就是稀缺資源,有一個伴隨減半週期的Runes名字長度釋放規則,一開始只能部署較長的名字,時間越久才越能部署少字數的名字。

可以想像,每當一個名字長度釋放週期,那麼就會持續的掀起類似域名那樣的搶注潮流,那如何避免項目方被搶注呢?

這便引入了Runes這次部署的最重大變化,部署的流程,不再只是一筆op_Return的交易,而是一次銘刻,前文有提及,銘刻技術透過commit和reveal可以進行一定的隱私保護,那麼新版的premine就是承擔了這個作用,要求commit和reveal兩筆交易有一定的間隔,然後被揭示出來的時候市場才知道發行方要使用的名字,這時候,即使其他黑客要想製作釣魚資產,即使是高手在記憶體池已經看到了這個名字,要仿冒,也過不去這個提前量的限制,今兒保護發行方對名字的掌控力。

在18版最後也新增了turbo字段,這暫時還沒有明確的公開作用,寓意為參與後面的其他協定層變更。

4.如何評價Runes新版協議

透過上文對底層欄位的解讀,十四君也不禁感慨,casey對資產發行的玩法真是見解獨到,短短2個月的時間,設計並實現如此貼合市場需求痛點的協議內容。

這是一個看價格來衡量價值的市場,銘文協議一開始作為完全差異化智能合約的模式,打開了很多的想像空間,真正的公平mint也讓大量用戶真正進入btc的圈子,又進一步引發btcL2d熱潮。但銘文協議一開始的粗放,導致劣質資產橫飛,滿大街的盜版和rug讓銘文生態蒙塵。符文的出現,更高程度客製化的發行管理將會讓市場變得有秩序。

而Runes協定是嵌入在Ordinals協議本身當中,借助Ordinals本身的用戶基礎,讓Runes協議的發行從一開始就站在巨人的肩膀上。作為FT協議的定位彌補了原先Ordinals只作為NFT 缺乏市場運作玩法的窘境。

最後,採用op_Return的方式記錄鏈上數據,幾乎可以讓Runes資產擁有任何機構和復現帳本的能力,其中心化程度進一步降低也就可以讓Runes資產具備了與btc相等的一定安全性能。

Runes協議有什麼缺點呢?確實有

首先是市場時機問題,雖然casey選定在btc減半期同步上線,但是高度緊張的開發時間,甚至在昨天還在變更協議的內容, 這也讓市場上能第一時間接入Runes協議的機構越來越少,這樣一來協議生態也就需要更多的時間來發酵。

其次是規則複雜性,對於發行管理的規則已經很複雜,但是名字的變化讓發行方一開始可選的是較長的名字選擇,結合特殊的點符號,讓Runes協議的名字最大長度甚至變成:

B•C•G•D•E•N•L•Q•R•Q•W•D•S•L•R•U•G•S•N•L•B•T•M•F•I• J•A•V

幾乎55位的長度,這樣變相放大了用戶被釣魚的風險,而且移動端插件端等介面也很難完整展示出來。

最後是未來相容性問題,同樣市場火熱的atomical協議,現在佈局已經走向AVM階段,讓銘文擺脫單純的代幣炒作階段,進一步走向btc L2或者BVM的敘事中,這點不得不說casey稍有落後,也局限了符文項目只作為發行層面的玩法。

本文內容參考資料:

runes協議編解碼分析:https://github.com/okx/js-wallet-sdk

ruens協議官方原始碼:https://github.com/ordinals/ord