以 Runes 為例，分析比特幣上資產代打（蝕刻）模型的最佳機制
作者：十四君
封面： Photo by Shubham's Web3 on Unsplash
前言
交易是 web3 的靈魂，注意力是 web3 最核心的資源，價格是簇擁的起點，價值是時間的終點。
BTC 減半已經過去一個月，而眾望所歸的 Runes 協議也過去一個月，這段期間湧現出十餘家代打平台，交易市場，在減半當天，甚至一筆代打一張 Runes 資產都需要超過 100 美金的成本。
本文以 Runes 資產為例，分析哪一家才是比特幣上資產代打（蝕刻）模型的最佳機制？
1、Runes 代打平台 GAS 排名
下圖是十四君梳理的一覽圖。
從方案角度排名，核心結論是：
- gas 成本上「分割+鍊式方案」< “鍊式” < ” 拆分” < ” 單打 “
- 中心化程度：鍊式（無中間位址）< 分割（無中間位址）< 鍊式（有中間位址）< 分割（有中間位址）
- 資產歸集：鍊式> 拆分+鍊式> 拆分
- 批量上鍊速度：拆分= 拆分+鍊式> 鍊式
乍看之下可能有些迷糊，什麼是鍊式，什麼是分割呢？
這就要回歸到 Runes 協定本身了，建議拓展閱讀：《BTC 減半在即，解讀 Runes 協定的底層設計機制與限制》
1.1、Runes 蝕刻機制簡述
Runes 使用的是蝕刻技術，是一種簡單直觀記錄資訊到鏈上的方式：即寫入 bitc 中 UTXO（未花費交易）的 op-return 欄位內，從功能在 Bitcoin Core 用戶端 0.9 版中開始啟用的 (14 年），OP-RETURN 會創造了一種明確的可驗證不可消費型輸出，讓資料存在區塊鏈上，類似 utxo 的輸出，但並不可被消費。
在 btc 的區塊鏈瀏覽器中可以輕鬆看到，該筆交易就附著了一個 op-return 的訊息，例如下圖：
可以看到，這裡的輸出 #3，其實是遊離的，雖然他佔據的一個該筆 utxo 的 output 的輸出位置，但是他是一個閉環的圓矩形，這就說明他是不能被再次轉移消費的，所以他就像是一個交易的備註區一樣，就留在了比特幣的儲存空間上，透過交易哈希區索引找到他。
細心的你可能會發現， 為什麼 OP_RETURN 的後面有一個 RUNE_TEST 這就是將具體內容解碼後的結果，點開明細按鈕後，就可以找到 52554e455f544553544 的編碼串，其實一串十六進位編碼數據，解碼後來就可以得到 RUNE_TEST，同理，明細裡還有其他的編碼，最終解碼後會成為一串字符串，大概是 json 的格式，從而體現出 Runes 資產的部署、鑄造、發行等等寓意。
因此
所謂代打，具體機制總結起來就是：Runes 一筆交易只能代打一個資產那麼所謂交易成本，在 BTC 中就是交易鏈上資料量的大小來體現，
那麼代打平台的設計，就等於誰可以最小程度的控制交易中出現的 utxo 數量，就是最優模型。
以下讓我們展開講解拆分模型和鍊式模型
1.2、拆分模型
所謂拆分模型，是在代打過程中先進行一筆交易拆分出多個子交易，每個子交易再進行資產鑄造過程。
例如 tools.mempool 的代打方案，執行時如下圖所示，
第一筆交易會預估算出每個子交易的手續費消耗，然後預留出 546（比特幣常見粉塵值）+手續費金額，進行拆分出多個 UTXO，這裡會發現他轉入到某個新的地址。
第二筆交易則是再從新的地址轉回使用者地址，完成代打，用戶也收攏到 Runes 資產。
這個模型顯著的問題就是：需要先一筆交易拆分，而用戶得到的是分散的 UTXO。
那麼當用戶想要掛單賣出的時候，要嘛逐一掛單，要嘛先合併再掛單，對於大客戶而言，會增加交易的成本。
且 tools.mempool 平台在分割交易中並不會為使用者也執行一次代打，所以綜合損耗是分割模型中較高的。
1.3、鍊式模式
所謂鍊式就類似下列結構，用戶最初的有 2W 個聰，每一個交易都是消費上一個還在內存池的交易，這樣也是多筆交易。
這裡會發現，這而尾號為 s2t4 所收取的 6144 個聰就是平台的代打手續費，對比執行代打所需要本身的手續費 3892 而言，可以說代打平台的收益是很高的，
該平台，就是之前號稱 5 天開發完 Runes 代打+交易市場的 Runestone，其實從交易上看該平台早就無人問津，但是在最初的那幾天，還是產生了幾乎 3 個 BTC（150W 以上）的手續費收入，對個人開發者而言不可無不高啊。
然而這是其實是毫無意義的費用，已經有多個平台都有開源代打代碼，例如 OKX 也開源了 Runes 代碼：完美解決 Runes 編解碼和代打問題，開發者可以直接引用構建自己的代打工具 https ://github.com/okx/js-wallet-sdk 。
回到鍊式，由於他幾乎是首筆進行了手續費收取，後續的每一筆交易都是如下圖一般循環處理，所以他其實本身數據量是比較少的。
2、Runes 最佳代打模型：分割+鍊式
luminex 是目前相對較佳的方案模型，即可做大批量 mint，平台帶有 utxo 拆分工具便於使用，採用拆分+鍊式方案。如下圖所示：
- 該平台在拆分就會先給用戶打上一筆資產，一點不浪費。
- 並且如果鑄造在 25 次以內，拆分出足夠鍊式鑄造的 gas，然後執行鑄造。
- 最後如果鑄造在 25 次以上，就會拆分出多個鍊式的所需的 gas，然後執行鑄造。
雖然這樣基本手續費並不優於鍊式，但是他可以做到至關重要的大批量鑄造，以及他的上鍊效率可以卡在極限 2 個區塊內完成鑄造。
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 + o 10 +p 10 = 1310
分割批量 Mint 10 筆，成本：i * 10 + o 10 +o 9 +p*10= 1697gas
最佳化率：(1697-1310)/1697 = 22.8%
鍊式批量 Mint 20 筆，成本：i * 20 + o 20 +p 20= 2620
分割批量 Mint 20 筆，成本：i * 20 + o 20 +o 19 +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
免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
