BTC減半在即,解讀Runes協定的底層設計機制與限制

avatar
十四君
5個月前
本文約4230字,閱讀全文需要約6分鐘
POS與MEV-Boost的轉變,從根本上重塑交易生命週期的模式,更精細的環節讓各參數更佳

前言

斷更許久,終於復耕,我十四君又回來了。

在過去半年筆者從ETH 生態完全轉入BTC 生態,從應用層轉入鏈底層,看btc、merlin、babylon、xion 等L2公鏈底層,研究Ordinals、brc 20、atomical、Runealpha、Runes 等銘文符文協議源碼。

有些許沉澱,那就繼續始終輸出吧,筆者將從技術視角為你帶來獨特見解與市場價值。

1、Runes(符文)是什麼?

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

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

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

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

BTC減半在即,解讀Runes協定的底層設計機制與限制

本文,將系統的梳理符文項目的底層欄位變遷,讓大家從根本上理解Runes 與Brc 20、Arc 20 等FT 協定的差異點,對比優缺理性決策參與。

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

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

2.1、蝕刻基礎原理

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

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

BTC減半在即,解讀Runes協定的底層設計機制與限制

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

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

2.2、銘刻基礎原理

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

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

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

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

蝕刻:

  • 優點:邏輯簡單直覺明確,交易成本低,可以不佔用全節點內存池。

  • 缺點:限制於80 字節長度,需要高度壓縮資料編碼。

銘刻:

  • 優點:幾乎不限制大小,有一定隱私保護能力,有多種玩法(時間鎖、工作量證明)等

  • 缺點:交易需要2 次上鍊,導致最終成本較高,commit 存續時間長,對全節點內存池壓力較大。

3、Runes 底層設計解讀

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

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

3.1、Runes 0.11 版本解讀

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

BTC減半在即,解讀Runes協定的底層設計機制與限制

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

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

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

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

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

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

3.2、Runes 0.18 版本解讀

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

BTC減半在即,解讀Runes協定的底層設計機制與限制

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

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

部署資產的方式巨變

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

BTC減半在即,解讀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 的圈子,又進一步引發btc L2 d 熱潮。但銘文協議一開始的粗放,導致劣質資產橫飛,滿大街的盜版和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

原創文章,作者:十四君。轉載/內容合作/尋求報導請聯系 report@odaily.email;違規轉載法律必究。

ODAILY提醒,請廣大讀者樹立正確的貨幣觀念和投資理念,理性看待區塊鏈,切實提高風險意識; 對發現的違法犯罪線索,可積極向有關部門舉報反映。

推薦閱讀
星球精選