前言

交易是web3的靈魂,注意力是web3最核心的資源,價格是簇擁的起點,價值是時間的終點。

BTC減半已經過去一個月,而眾望所歸的Runes協議也過去一個月,這段期間湧現出十餘家代打平台,交易市場,在減半當天,甚至一筆代打一張Runes資產都需要超過100美金的成本。

本文以Runes資產為例,分析哪一家才是比特幣上資產代打(蝕刻)模型的最佳機制?

1.Runes代打平台GAS排名

下圖是十四君梳理的一覽圖。

以Runes為例,分析比特幣上資產代打(蝕刻)模型的最佳機制

從方案角度排名,核心結論是:

  1. gas成本上「分割+鍊式方案」 < 「鍊式」 < 」分割」 < 」單打“
  2. 中心化程度:鍊式(無中間位址)< 分割(無中間位址) < 鍊式(有中間位址) < 分割(有中間位址)
  3. 資產歸集:鍊式> 拆分+鍊式> 拆分
  4. 批量上鍊速度:拆分= 拆分+鍊式> 鍊式

乍看之下可能有些迷糊,什麼是鍊式,什麼是分割呢?

1.1、Runes蝕刻機制簡述

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資產的部署、鑄造、發行等等寓意。

因此

所謂代打,具體機制總結起來就是:Runes一筆交易只能代打一個資產

那麼所謂交易成本,在BTC中就是交易鏈上資料量的大小來體現,那麼代打平台的設計,就等同於誰可以最小程度的控制交易中出現的utxo數量,就是最優模型。

以下讓我們展開講解拆分模型和鍊式模型

1.2、拆分模型

所謂拆分模型,是在代打過程中先進行一筆交易拆分出多個子交易,每個子交易再進行資產鑄造過程。

例如tools.mempool的代打方案,執行時如下圖所示,

第一筆交易會預估算出每個子交易的手續費消耗,然後預留出546(比特幣常見粉塵值)+手續費金額,進行拆分出多個UTXO,這裡會發現他轉入到某個新的地址。

以Runes為例,分析比特幣上資產代打(蝕刻)模型的最佳機制

第二筆交易則是再從新的地址轉回用戶地址,完成代打,用戶也收攏到Runes資產。

以Runes為例,分析比特幣上資產代打(蝕刻)模型的最佳機制

這種模型顯著的問題就是:

需要先一筆交易拆分,用戶得到的是分散的UTXO。

那麼當用戶想要掛單賣出的時候,要嘛逐一掛單,要嘛先合併再掛單,對於大客戶而言,會增加交易的成本。

且tools.mempool平台在分割交易中並不會為使用者也執行一次代打,所以綜合損耗是分割模型中較高的。

1.3、鍊式模式

所謂鍊式就類似下列結構,用戶最初的有2W個聰,每一個交易都是消費上一個還在內存池的交易,這樣也是多筆交易。

以Runes為例,分析比特幣上資產代打(蝕刻)模型的最佳機制

這裡會發現,這而尾號為s2t4所收取的6144個聰就是平台的代打手續費,對比執行代打所需要本身的手續費3892而言,可以說代打平台的收益是很高的,

該平台,就是之前號稱5天開發完Runes代打+交易市場的Runestone,其實從交易上看該平台早就無人問津,但是在最初的那幾天,還是產生了幾乎3個BTC(150W以上)的手續費收入,對個人開發者而言不可無不高啊。

然而這是其實是毫無意義的費用,已經有多個平台都有開源代打代碼,例如OKX也開源了Runes代碼:完美解決Runes編解碼和代打問題,開發者可以直接引用構建自己的代打工具https ://github.com/okx/js-wallet-sdk 。

回到鍊式,由於他幾乎是首筆進行了手續費收取,後續的每一筆交易都是如下圖一般循環處理,所以他其實本身數據量是比較少的。

以Runes為例,分析比特幣上資產代打(蝕刻)模型的最佳機制

2.Runes最佳代打模型:分割+鍊式

luminex 是目前相對較佳的方案模型,即可做大批量mint,平台附有utxo拆分工具便於使用,採用拆分+鍊式方案。

如下圖所示:

  1. 該平台在拆分就會先給用戶打上一筆資產,一點不浪費。
  2. 並且如果鑄造在25次以內,拆分出足夠鍊式鑄造的gas,然後執行鑄造。
  3. 最後如果鑄造在25次以上,就會拆分出多個鍊式的所需的gas,然後執行鑄造。

雖然這樣基本手續費並不優於鍊式,但是他可以做到至關重要的大批量鑄造,以及他的上鍊效率可以卡在極限2個區塊內完成鑄造。

以Runes為例,分析比特幣上資產代打(蝕刻)模型的最佳機制

2.1.為什麼會有上鍊效率的指標呢?

這是因為BTC節點有個防止Dos攻擊的機制,

在單utxo的vout 被消費以及其被消費的鏈路裡,會限制最多25個交易在記憶體池中。

這就是為什麼大多數大批量Mint多數採用中間位址的原因,目的是解除這樣的限制。對於鍊式而言,資產會疊加起來最終轉給使用者。

因此鍊式模型只有25個交易可以同時在記憶體池中,但是拆分模型則是在拆分的交易上鍊後,可以無限值放到內存池中(因為父交易已經不在內存池,每個utxo的vout都獨立計算25限制)

所以luminex作為最優模型,不只是gas最低,而是即保持gas很低,也還有大批鑄造的能力。

不過,其實也還有比luminex更好的模型。

因為luminex的分拆交易也會單獨代打給用戶,但這個資產其實是不用轉給用戶的,而是可以轉給第二個鍊式交易的utxo裡,因為Runes有資產預設流動機制,這樣可以再luminex的情況下在減少一個utxo的成本。

2.2、BTC手續費優化率對比

講述了半天成本,那成本究竟如何衡量?其實很簡單,使用者平常設定的是單價,也就是類似gasPrice,但BTC其實完全依賴儲存資料作為數量單位即vsize。

所以咱們以taproot地址為例(不同地址手續費不同,taproot地址屬於較低的手續費),此種地址的結構中:

每增加一個input,vsize增加58。

每增加一個output,vsize增加43。

而寫入每個OP_RETURN ,vsize需要30左右。

因此我們可以算出以下優化率

鍊式批量Mint 10筆,成本:i * 10 + o10 +p10 = 1310

分割批量Mint 10筆,成本:i * 10 + o10 +o9 +p*10= 1697

gas優化率:(1697-1310)/1697 = 22.8%

鍊式批量Mint 20筆,成本:i * 20 + o20 +p20= 2620

分割批量Mint 20筆,成本:i * 20 + o20 +o19 +p*20= 3437

gas優化率:(3437-2620)/3437 = 23.8%

看似20%不多,​​但是在單筆鑄造就要消耗100U的巔峰期,10次批量就可以降低200U的成本,細微的成本價差最終映射到成交的心理閾值上。

面對高昂的代打手續費,未來期望在web3圈子里分到最早一杯羹的人,還是需要學會基礎的node js,從而直接運行各家開源代碼(如上文提及的OKX開源的簽名組件)從而直接越過平台收費問題,甚至在下篇交易市場篇中,也可以直接越過多家平台阻攔直接建構跨平台交易,甚至直接監聽內存池,直接搶跑謀取收益。

3、總結

Runes資產協議發行1個月,可惜最終並沒有突破10億美金的門檻,也傳出Ordinals與runes創辦人casey要seppuku的直播趣談。

但歸根究底,還是生態中,代打和市場兩個核心基建不完善,讓散戶參與成本過高,讓機構參與缺乏生態運作。

首先目前出現的平台要嘛收取高額手續費,要嘛功能不齊全。例如Runestone雖然鍊式成本低,但其gas估算不準確,容易導致最後一筆交易的磨損,伴隨上鍊的不確定性,逐步使其退出市場。

還有,目前的代打模型,還是忽略了用戶真實訴求,交易本身。

各個打到的資產,往往需要更快速的轉手出去,但是在市場早期價格波動巨大的情況,並且btc極度擁擠,其實除了專案方自己市場行為之外,並不會有太多的大批量打資產的需求,換言之,有這麼大資金量去打1000筆資產的,也自己有能力去做到,平台的核心用戶是散戶。

因此鍊式雖然成本低,但他並不適合最早期,在高速波動的定價中,在市場缺乏分割工具的情況下,鍊式產生的20多張複合在1筆交易中,會讓交易的掃貨的閾值變高。

最後本文是BTC上資產的代打機製篇,後續還有一份交易市場模型篇,可以適配到(BRC20、Ordinals、Atomical、Runes)等等新資產的交易模式,敬請關注,切勿錯過。

參考資料:

runes拆分代開啟原始碼:https://github.com/okx/js-wallet-sdk

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