比特幣跨鏈為何致符文離奇丟失？談符文丟失帶來的一些警示

訪客 2年前 (2023-12-28) 閱讀數 417 #區塊鏈

文章標簽前沿文章

本篇技術研報由 ScaleBit?研究團隊的 Leon?撰寫

TL;DR

本文就近期 BEVM 跨鏈操作中出現的一些符文“丟失”現象進行了深度分析，同時提出了避免此類問題再次發生的安全建議。

近期，我們注意到 BEVM 跨鏈操作中出現的一些符文“丟失”現象，引起了社區的關注和疑慮。本文將對這一問題進行深度分析，旨在為用戶提供更全面的了解該問題，同時也借著這個話題給大家說說最近火熱的銘文和符文使用過程中的一點注意事項。

背景

北京時間 2023 年 12 月 23 日，一些 BEVM 跨鏈交易用戶發現賬戶中持有的部分 COOK、PSBTS 在不知情的情況下被轉移到跨鏈橋，隨后該部分用戶向 BEVM 團隊提出質疑。接著 BEVM 官方推特發出聲明，稱由于該部分符文不被主流錢包比如?Unisat?支持，所以在跨鏈到?BEVM?的時候，該類非主流的銘文會被當做普通的 UTXO 轉到 BEVM 地址。

ScaleBit 安全團隊注意到此事以后，隨即進行了調研。經過 ScaleBit 團隊的研究，確認該部分符文確實是在同一筆跨鏈交易中被當做普通的 UTXO 轉移，而非?BEVM“盜取”。

正文

援引 BEVM 官網信息介紹，BEVM 是一個以 BTC 為 Gas 且兼容 EVM 的 BTC Layer2，核心目標是拓展比特幣的智能合約場景，幫助 BTC 突破比特幣區塊鏈非圖靈完備、不支持智能合約的束縛，讓 BTC 可以在 BEVM 這個 Layer2 上構建以 BTC 為原生 Gas 的去中心化應用。

近來隨著 BEVM 奧德賽活動的開啟，很多用戶開始將 BTC 跨鏈到 BEVM 進行交互，以期望能夠在未來 BEVM 生態參與搶占先機。但是在跨鏈過程中，部分用戶發現所持有部分 COOK、PSBTS 丟失，根據區塊鏈瀏覽器，查到該部分符文被轉移到了 BEVM 跨鏈橋，于是有了前面提到的情況。

接下來，就跟我們一起看看到底發生了什么。

首先，我們通過?BEVM?瀏覽器（https://scan.bevm.io/stats）找到了一些跨鏈交易信息，通過分析，我們找到跨鏈橋的接收地址為：

bc1p43kqxnf7yxcz5gacmqu98cr2r5gndtauzrwpypdzmsgp7n3lssgs5wruvy。

隨后，我們在 Rune Alpha（支持 COOK 和 PSBTS 等 RUNES 協議的通用瀏覽器和服務）上查看，其地址上持有包括 11 萬多的 COOK 和 28 萬多的 PSBTS 在內的大量各種符文。

我們隨即對該部分符文相關交易進行了研究和分析。

我們拿其中的某一筆交易舉例：

https://runealpha.xyz/txs/c1bf015ce01a3610b436fb2e418685855cd7a37143cd52a4d1858a53e610b5f2

其交易內容如圖所示：

我們可以看到，該筆交易的輸入有兩個，分別為?0.00000546 BTC（包含 1000 COOK）和?0.02169031 BTC，輸出是?0.02 BTC（包含 1000 COOK）和?0.00148377 BTC。

作為對比，我們找了一筆不是跟跨鏈橋交易的 COOK 的交易，其輸出如下圖：

可以看到，不管是輸入還是輸出，都包含一個?0.00000546 BTC 的 UTXO。

為什么會這樣呢？這里我們就需要了解一些相關的知識了。

UTXO

首先，我們了解一下什么是 UTXO。

UTXO，全稱為?Unspent Transaction Output，直譯即未花費交易輸出，這是比特幣的核心知識點。在比特幣的交易中，每筆交易都有輸入和輸出，別人付給你的錢是“交易輸入”，你收到的錢是“交易輸出”。

UTXO 的核心設計思路是無狀態，它記錄的是交易事件，而不記錄最終狀態，也就是說只記錄變更事件，用戶需要根據歷史記錄自行計算余額。因此，比特幣的交易模型和我們平時使用的銀行賬號有所不同，它并沒有賬戶這個說法，比特幣只有 UTXO。一個 UTXO 可以想象成一個任意金額的“硬幣”。

UTXO 湊輸入和找零

UTXO，就是跟硬幣一樣，不能掰開用，那么交易過程中如何湊夠輸入金額，又如何找零的呢？

比如小明給小剛轉賬 1 BTC。整個過程是這樣的，小明要收集足夠的輸入，比如小明的地址對應的以往交易中，找到了一個面值為?0.9 的 UTXO，不夠 1 BTC，好在交易中是允許有多個輸入的，所以小明又找到了一個面值?0.2 的 UTXO，這樣在這次轉賬的交易中，就會有兩個輸入。同時輸出也會有兩個，一個是指向小剛地址，面值是 1 BTC。另一個指向小明的地址，面值是約 0.1 BTC，這個輸出就是找零了。

在比特幣轉賬過程中，湊輸入沒有固定的算法，取決于錢包的實現。

比特幣銘文和符文

其次，我們需要了解什么是銘文和符文。比特幣銘文和符文是比特幣生態中的兩個重要概念。

比特幣銘文主要的代表是 Ordinals 協議。Ordinals 誕生于 2022 年 12 月，內容完全在鏈上，由 Casey Rodarmor 開發。該協議利用了 Sat 編號系統，Ordinals 通過賦予每個聰序列號，在交易中追蹤它們，同時用戶可以通過 Ordinals 附加額外的數據（圖像、視頻、文本等）在比特幣區塊鏈上，使得每個聰都獨一無二，從而具有 NFT 的性質。BRC-20?就是基于該協議創建。

Runes 協議，也被稱為符文協議。隨著 BRC-20 的火爆，BRC-20 相關代幣的交易占據了 Ordinals 協議的大部分比例。2023 年 9 月 26 日，Casey Rodarmor 重新開發了一個名為 Runes 的協議（也就是大家現在提到的符文協議），作為 BRC-20 的替代品。該協議是一個簡單的、基于 UTXO（未使用的交易輸出）的、能使比特幣使用者具有使用良好體驗的 FT（Fungible Token、可替代代幣）協議。符文主要的代表就是我們提到 COOK 和 PSBTS。

比特幣銘文和符文的載體都是 UTXO，比特幣銘文（Inscription）與符文（Rune）的一個關鍵區別在于，銘文是刻在隔離見證數據里，而符文是刻在?OP_RETURN 里。OP_RETURN 能存儲的數據大小非常有限，但是用于發幣綽綽有余，這個也并非什么新技術。

對于用戶鑄造銘文或者符文，本質上都是發送符合金額的比特幣給協議，協議返給你一個帶有銘文或者符文的 UTXO，一般是一個?0.00000546 BTC 的 UTXO。這里說下為什么是 0.00000546, 這個是比特幣設置最低交易金額。

轉移銘文，也是因為這些錢包識別了這些 UTXO 的特殊格式, 錢包通過對應的協議，將這些 UTXO 作為輸入，并支付額外手續費，轉給了對方。

為什么用戶丟了“符文”？

對于用戶丟失符文，由于它本質上還是 UTXO，在用戶使用 UniSat 進行比特幣跨鏈操作的時候，由于 UniSat 不識別該部分含符文的 UTXO ，并當做了普通的 UTXO 進行了處理，湊輸入發送給了跨鏈橋。

實際上，不僅是跨鏈操作，用戶在不支持符文的錢包中進行其他比特幣轉賬操作，也有可能丟失符文。在 12 月 7 日就有用戶在 Unisat 上進行 BRC-20 swap 操作丟失了 15, 000 COOK。

還有一個比較有意思的事情，在 Runes Alpha 上鑄造符文的時候，也是有可能把用戶的銘文的當成 Gas 轉走的。

為什么沒有人反饋丟銘文？

我們通過 BEVM 的官方文檔，發現 BEVM 跨鏈是支持銘文跨鏈的，只需要用戶通過 BSwap，即可將自己的銘文跨鏈到 BEVM 上。而跨鏈使用的錢包是 UniSat 錢包。這是一款用于 BTC 生態的 Chrome 插件錢包，幫助用戶存儲、鑄造和傳輸 BRC-20?代幣。它能夠識別用戶的銘文，從而避免將該部分 UTXO 進行合并，只有用戶主動交易銘文的時候，才會被轉移。

由于?Unisat?目前還不支持符文協議，這就是為什么用戶跨鏈會“丟失”符文而不丟失銘文的原因。如果換做其他不支持符文的錢包，也會發生類似的情況。

符文還可以找回嗎？

既然符文被轉移到跨鏈橋了，用戶還可以拿回該部分符文嗎？

我們查閱了?BEVM?白皮書，BEVM?的資產跨鏈方案是基于比特幣的?Taproot?技術構建的，是融合了?Schnorr 簽名?+?Mast?合約?+?1000?BTC?輕節點組成的 POS 網絡來實現資產的去中心化跨鏈和管理，BTC- BEVM 的雙向跨鏈是完全基于鏈上的節點共識來管理的，實現了完全的代碼化和去信任化，而非依賴多簽或者人為管理，這讓 BTC 及比特幣資產的跨鏈安全做到和 BFT POS 一樣去中心化和安全，因此，BEVM 官方也無法發起單獨的轉賬交易來取出用戶的“符文資產”。

由于 BEVM 不支持符文協議，該部分符文被轉出的概率是完全隨機的，當托管合約執行交易時，這些“符文資產”可能會被當作普通的 UTXO 被轉出，但是整個過程是完全隨機的，不受人為控制的，如果要強制取出，必須徹底改變 BEVM 整個鏈的共識，這無疑于將 BEVM 硬分叉。

總的來說，該事件是由于多個原因造成的：

跨鏈操作所使用的錢包不支持符文。

BEVM 是分布式去中心化的的托管資產，無法人工取出。

用戶對于符文協議的不熟悉。

如何避免此類問題再次發生？

對于普通用戶，如何避免該類問題再次發生呢？在做交互操作時候，我們建議用戶做好以下幾點：

確保使用的錢包支持銘文或者銘文協議。

確保要交互的協議（比如跨鏈橋）是否支持銘文符文協議。

使用協議之前，先研究是否有用戶操作過程中出現問題。

使用多個錢包管理不同資產。

同時也提醒開發者，在開發設計的時候，需要進行充分考慮和準備，從代碼層面上解決可能出現的協議不兼容問題。如果不能，要在上線之前做好調研并做出明確提醒，避免引起不必要的質疑和麻煩。