技術解讀：Merlin Chain是如何運轉的？

2024-04-19 19:04:08

原文作者：Faust，極客web3

從 2023 年的銘文之夏至今，比特幣 Layer 2 始終都是整個Web3的重頭戲。雖然這一領域的興起遠晚於以太坊 Layer 2 ，但憑借着 POW 的獨特魅力，以及現貨 ETF 的順利落地，無需顧忌“證券化”風險的比特幣在短短半年時間裏，就為 Layer 2 這一衍生賽道吸引了動輒百億美元的資本注意力。

而在比特幣 Layer 2 賽道中，坐擁數十億美元 TVL 的 Merlin，毫無疑問是體量最大、關注者最多的那一個。憑借着明確的質押激勵和可觀的收益率，Merlin 幾乎是在幾個月之內突然拔地而起，打造了一個超越 Blast 的生態神話。隨着 Merlin 的逐漸火熱，關於其技術方案的探討也成為越來越多人關注的話題。

在本文中， 極客web3將聚焦於 Merlin Chain 技術方案，對其已公开的文檔及協議設計思路進行解讀 ，我們致力於讓更多人理解 Merlin 的大致工作流程，對其安全模型有更清晰的認知，讓大家以更直觀的方式來理解這個“頭部比特幣 Layer 2 ”到底是怎么運轉的。

Merlin 的去中心化預言機網絡：开放性的鏈下 DAC 委員會

對於所有的 Layer 2 而言，無論是以太坊 Layer 2 ，還是比特幣 Layer 2 ，DA 與數據發布成本，都是最需要解決的問題之一。由於比特幣網絡本身存在諸多問題，天生不支持較大的數據吞吐量，該如何利用這寸土寸金的 DA 空間，成為了考驗 Layer 2 項目方想象力的難題。

有一個結論是顯而易見的：如果 Layer 2 “直接”把未經處理的的交易數據，發布到比特幣區塊裏，既不能實現高吞吐量，也不能實現低手續費。 最主流的解決方案，要么通過高度壓縮，把數據尺寸壓縮的盡可能小，再上傳到比特幣區塊，要么就把數據直接發布在比特幣鏈下。

採用第一種思路的 Layer 2 中，最出名的可能是 Citrea，它們打算把一段時間內 Layer 2 的狀態變化(state diff)，也就是多個账戶上的狀態變更結果，連同對應的 ZK 證明，一起上傳到比特幣鏈上。這種情況下，任何人都可以從比特幣主網下載 state diff 和 ZKP，進而監測到 Citrea 狀態的變化結果。這種方法可以把上鏈的數據尺寸壓縮 90% 以上。

雖然這可以極大程度壓縮數據尺寸，但瓶頸還是很明顯。如果在短時間內，有大量的账戶發生狀態變更，Layer 2 要把這些個账戶的變更情況，全部匯總上傳到比特幣鏈上，最終的數據發布成本無法壓到很低，這一點在很多以太坊 ZK Rollup 身上可見一斑。

很多比特幣 Layer 2 幹脆走第二種路徑：直接用比特幣鏈下的 DA 解決方案，要么自己搭建一個 DA 層，要么就用 Celestia、EigenDA 等。B^Square、BitLayer 以及本文的主角 Merlin，都沿用了這種鏈下的 DA 擴容方案。

在極客web3此前文章——《解析 B^ 2 新版技術路线圖：比特幣鏈下 DA 與驗證層的必要性》中，我們提到， B^ 2 直接模仿 Celestia，在鏈下搭建了一個支持數據採樣功能的 DA 網絡，名為 B^ 2 Hub。交易數據或 state diff 等“DA 數據”存放於比特幣鏈下，只向比特幣主網上傳 datahash / merkle root 。

這其實是把比特幣當做一個去信任的公告板：任何人都可以從比特幣鏈上讀取 datahash。 當你從鏈下的數據提供者那裏獲取 DA 數據後，可以檢查它和鏈上的 datahash 是否對應 ，即 hash（data 1) == datahash 1 ？。如果兩者之間存在對應關系，說明鏈下的數據提供者給你的數據沒錯。

上述流程可以保證鏈下節點提供給你的數據，與 Layer 1 上的某些“线索”相關聯，防止 DA 層惡意提供虛假數據。但這裏有一個很重要的作惡場景：假如數據的源頭——Sequencer，壓根沒有把 datahash 對應的 data 發出去，只把 datahash 發到了比特幣鏈上，卻故意扣住對應的 data 不讓任何人讀取，這種時候怎么辦？

類似的場景包括但不限於：只把 ZK-Proof 和 StateRoot 發布出來，卻不發布對應的 DA 數據（state diff 或 Transaction data），人們雖然可以驗證 ZKProof，確定 Prev_Stateroot 到 New_Stateroot 的計算過程有效無誤，但卻不知道有哪些账戶的 state（狀態）發生了變化。這種情況下，雖然用戶的資產是安全的，但大家根本不能確定網絡的實際狀態，不知道有哪些交易被打包上鏈，哪些合約的狀態發生了更新，此時的 Layer 2 基本等同於停機。

這其實就是“ 數據扣留 ”，以太坊基金會的 Dankrad 曾經在 2023 年 8 月，於推特上簡單討論了類似的問題，當然他主要針對的是一個名為“DAC”的東西。

很多採用鏈下 DA 方案的以太坊 Layer 2 ，往往會設置 幾個具有特殊權限的節點，組成一個委員會，全稱 Data Availability Committee (DAC) 。這個 DAC 委員會充當了擔保人的角色，對外聲稱：Sequencer 的確在鏈下發布了完整的 DA 數據（transaction data 或 state diff）。然後 DAC 節點集體生成一個多籤，只要多籤滿足閾值要求（比如 2/4），Layer 1 上的相關合約就會默認，Sequencer 通過了 DAC 委員會的檢查，如實的在鏈下發布了完整的 DA 數據。

以太坊 Layer 2 的 DAC 委員會基本都遵循 POA 模式，只允許少數經過 KYC 或官方指定的節點加入 DAC 委員會 ，這使得 DAC 成為了“中心化”、“聯盟鏈”的代名詞。此外，在某些採用 DAC 模式的以太坊 Layer 2 那裏，排序器只把 DA 數據發送給 DAC 成員節點，幾乎不會再往其他地方上傳數據，任何人要獲取 DA 數據，必須得到 DAC 委員會的許可，和聯盟鏈沒有本質區別。

毫無疑問，DAC 應該去中心化，Layer 2 可以不把 DA 數據直接上傳至 Layer 1 ，但 DAC 委員會的准入權限應該對外开放，這樣才能防止少數人串謀作惡。（對於 DAC 作惡場景的討論，可以參考 Dankrad 此前在推特上的發言）

Celestia 此前提出的 BlobStream，本質是用 Celestia 替代中心化的 DAC ，以太坊L2的排序器可以把 DA 數據發布到 Celestia 鏈上，如果有 2/3 的 Celestia 節點為之籤名，以太坊上部署的 Layer 2 專屬合約就認為排序器如實發布了 DA 數據，這實際是讓 Celestia 節點作為擔保人。考慮到 Celestia 有上百號 Validator 節點，我們可以認為這個大號 DAC 是比較去中心化的。

Merlin 採用的 DA 解決方案，其實和 Celestia 的 BlobStream 比較接近，都是通過 POS 的形式开放 DAC 的准入權限，使之趨於去中心化。 任何人只要質押足夠的資產，就可以運行一個 DAC 節點。在 Merlin 的文檔中，將上述 DAC 節點稱為 Oracle，並且指出，將支持 BTC、MERL 甚至是 BRC-20 代幣的資產質押，實現靈活的質押機制，也支持類似於 Lido 的代理質押。（預言機的 POS 質押協議基本是 Merlin 接下來的核心敘事之一，提供的質押利率等都比較高）

在此我們簡述下 Merlin 的工作流程（圖片在下面）：

排序器 Sequencer 接收到大量交易請求後，將其匯總並產生 data batch（數據批次），傳給 Prover 節點，以及 Oracle 節點（去中心化 DAC）。
Merlin 的 Prover 節點是去中心化的，採用了 lumoz 的 Prover as a Service 服務。Prover 礦池在收到多個 data batch 後，會生成對應的零知識證明，之後，ZKP 會發給 Oracle 節點，交由後者去驗證。
Oracle 節點會驗證 Lmuoz 的 ZK 礦池發來的 ZK Proof，能否和 Sequencer 發來的 data Batch 相對應。若兩者可以對應上，且不包含其他錯誤，則通過驗證。在此過程中，去中心化的 Oracle 節點們會通過門限籤名來生成多籤，對外聲明——排序器完整的發出了 DA 數據，且對應的 ZKP 是有效的，通過了 Oracle 節點的驗證。
排序器從 Oracle 節點處收集多籤結果，當籤名數量滿足閾值要求後，就把這些籤名信息發到比特幣鏈上，附帶 DA 數據（data batch）的 datahash，交由外界去讀取並確認。

Oracle 節點對其驗證 ZK Proof 的計算過程進行特殊處理，生成 Commitment 承諾，發送到比特幣鏈上，允許任何人對“承諾”進行挑战，這裏面的流程和 bitVM 的欺詐證明協議基本一致。如果挑战成功，則發布 Commitment 的 Oracle 節點將受到經濟懲罰。當然，Oracle 要發布到比特幣鏈上的數據，還包括當前 Layer 2 狀態的 hash——StateRoot，以及 ZKP 本身，都要發布到比特幣鏈上，讓外界檢測。

這裏面還有幾個需要闡述的細節，首先 Merlin 路线圖中提到，未來會讓 Oracle 把 DA 數據備份到 Celestia 上，這樣一來，Oracle 節點可以適當的淘汰掉本地的歷史數據，不需要把數據永存在本地。同時，Oracle Network 生成的 Commitment，其實是一棵 Merkle Tree 的 root，光對外披露 root 還不行，要把 Commitment 對應的完整數據集全部公开，這就需要尋找一個第三方的 DA 平臺，這個平臺可以是 Celestia 或 EigenDA，也可以是其他的 DA 層。

安全模型分析：樂觀的 ZKRollup+Cobo 的 MPC 服務

上面我們簡述了 Merlin 的工作流程，相信大家已經對其基本構造有所掌握。我們不難看出，Merlin 與 B^Square、BitLayer、Citrea，基本都遵循相同的安全模型——樂觀的 ZK-Rollup。

初讀這個詞，可能讓很多以太坊愛好者感到怪異，什么叫“樂觀的 ZK-Rollup”？在以太坊社區的認知裏，ZK Rollup 的“理論模型”完全建立在密碼學計算的可靠性上，不需要引入信任假設，而樂觀一詞，恰恰就引入了信任假設，這意味着，人們在大多數時候，要樂觀的認為 Rollup 沒有出現錯誤，是可靠的。而一旦出現錯誤，可以通過欺詐證明的方式去懲罰 Rollup 運行者，這就是樂觀 Rollup——Optimistic Rollup，又名 OP Rollup 的命名由來。

對於 Rollup 大本營的以太坊生態而言，樂觀的 ZK-Rollup 可能有些不倫不類，但這恰恰貼合了比特幣 Layer 2 的現狀。由於技術上的限制，比特幣鏈上無法完整的驗證 ZK Proof，只能在特殊情況下驗證 ZKP 的某一步計算過程，在這種前提下，比特幣鏈上實際只能支持欺詐證明協議，人們可以指出 ZKP 在鏈下驗證過程中，某一個計算步驟有錯誤，並通過欺詐證明的方式進行挑战，當然這無法向以太坊式的 ZK Rollup 看齊，但已經是目前比特幣 Layer 2 所能企及的最可靠、最穩妥的安全模型。

在上述樂觀的 ZK-Rollup 方案下，假設 Layer 2 網絡中存在 N 個有權限發起挑战的人，只要這 N 個挑战者中有 1 人是誠實可靠的，隨時能夠檢測出錯誤並發起欺詐證明，Layer 2 的狀態轉換就是安全的。當然，完成度比較高的樂觀 Rollup 需要確保其提款橋也受到欺詐證明協議的保護，而目前幾乎所有的比特幣 Layer 2 都無法實現這個前提，需要依賴於多籤/MPC，那么該如何選用多籤/MPC 方案，就成為了與 Layer 2 安全性息息相關的問題。

Merlin 在橋接方案上選擇了 Cobo 的 MPC 服務，採用冷熱錢包隔離等措施，橋接資產由 Cobo 和 Merlin Chain 共同管理，任何提款行為需要 Cobo 和 Merlin Chain 的 MPC 參與者共同處理，本質上是通過機構的信用背書來保障提款橋的可靠性。當然這只是目前階段的權宜之計，隨着項目的逐漸完善，提款橋可以通過引入 BitVM 與欺詐證明協議來更替為 1/N 信任假設的“樂觀橋”，只是這樣做的落地難度會比較大（目前幾乎所有的 Layer 2 官方橋都依賴於多籤）。

整體來看，我們可以梳理下， Merlin 引入了基於 POS 的 DAC、基於 BitVM 的樂觀 ZK-Rollup、基於 Cobo 的 MPC 資產托管方案 ，通過开放 DAC 權限來解決 DA 問題；通過引入 BitVM 及欺詐證明協議來保障狀態轉換的安全；通過引入知名資產托管平臺 Cobo 的 MPC 服務來保證提款橋的可靠性。

基於 Lumoz 的兩步驗證式 ZKP 提交方案

前面我們梳理了 Merlin 的安全模型，介紹了樂觀 ZK-rollup 的概念。在 Merlin 的技術路线圖中，還談到了去中心化 Prover。衆所周知，Prover 是 ZK-Rollup 架構中的一個核心角色，它負責為 Sequencer 發布的 Batch 生成 ZKProof，而零知識證明的生成過程恰恰是非常消耗硬件資源的，是一個很棘手的問題。

要 加速 ZK 證明的生成，將任務並行化切分處理，是一個最基本的操作 。所謂的並行化，其實就是把 ZK 證明的生成任務切分為不同的部分，由不同的 Prover 來分別完成，最後再由 Aggregator 聚合者把多段 Proof 聚合為一個整體。

為了加速 ZK 證明的生成過程， Merlin 將採用 Lumoz 的 Prover as a service 方案 ，實際上就是把大量的硬件設備聚在一起組建出一個礦池，然後把計算任務分配給不同的設備，並分配對應的激勵，和 POW 挖礦有些類似。

在這種去中心化的 Prover 方案中，存在一類攻擊場景，俗稱搶跑攻擊：假設某個聚合者 Aggregator 組建好了 ZKP，它把 ZKP 發送出去以期獲得獎勵。其他聚合者看到了 ZKP 的內容後，搶跑在他前面發布相同的內容，聲稱這個 ZKP 是自己先生成的，這種情況該怎么解決？

可能大家想到的一個最本能的解決方案，就是給每個 Aggregator 分配指定的任務號碼，比如說，任務 1 只有 Aggregator A 可以接，其他人就算完成了任務 1 也拿不到獎勵。但這種方法存在一個問題，就是不能抵御單點風險。假如 Aggregator A 出現了性能故障或是掉线了，任務 1 就一直卡着沒法完成。而且，這種把任務分配給單一實體的做法，無法以競爭性的激勵機制提升生產效率，不是一個很好的辦法。

Polygon zkEVM 曾在一篇博客中提出名為 Proof of efficiency 的方法 ，其中指出，應該以競爭性的手段促使不同的 Aggregator 之間展开競爭，以先到先得的方式來分配激勵，最先把 ZK-Proof 提交上鏈的 Aggregator 可以獲得獎勵。當然他這裏面沒有提到該怎么解決 MEV 搶跑問題。

Lumoz 採用了兩步驗證的 ZK 證明提交方式，某個 Aggregator 生成了 ZK 證明後，先不用把完整的內容發出去，而只發布 ZKP 的 hash，換言之，發布 hash（ZKP+Aggregator Address）。這樣一來，就算其他人看到了 hash 值，也不知道對應的 ZKP 內容，無法直接搶跑；

如果有人幹脆把整個 hash 復制一份搶先發布出去，也沒有意義，因為 hash 裏面包含了特定聚合者 X 的地址，聚合者 A 就算搶先發布這個 hash，等 hash 的原像被揭露時，大家也會看到其中包含的聚合者地址是 X 的，而不是 A 的。

通過這種兩步驗證式的 ZKP 提交方案，Merlin（Lumoz）可以解決 ZKP 提交過程中存在的搶跑問題，進而實現高度競爭性的零知識證明生成激勵，從而提高 ZKP 的生成速度。

Merlin's Phantom：多鏈互操作

按 照 Merlin 的技術路线圖，他們還會支持 Merlin 與其他 EVM 鏈之間的互操作 ，其實現路徑與此前 Zetachain 的思路基本一致，假如以 Merlin 作為源鏈，其他 EVM 鏈作為目標鏈，當 Merlin 節點感知到用戶發出的跨鏈互操作請求後，會在目標鏈上觸發後續的工作流程。

比如，可以在 Polygon 上部署一個由 Merlin 網絡控制的 EOA 账戶，當用戶在 Merlin Chain 上發布跨鏈互操作指令後，Merlin 網絡先解析其內容，生成一筆在目標鏈上執行的交易數據，再由 Oracle Network 對該筆交易進行 MPC 籤名處理，生成交易的數字籤名。之後 Merlin 的 Relayer 節點在 Polygon 上釋放這筆交易，通過 Merlin 在目標鏈上 EOA 账戶中的資產完成後續操作如。

當用戶要求的操作完成後，對應的資產將直接轉發給用戶在目標鏈上的地址，理論上也可以直接跨到 Merlin Chain 中。這種方案有一些比較明顯的好處：可以避免傳統資產跨鏈時與跨鏈橋合約產生的手續費磨損，而且是直接由 Merlin 的 Oracle Network 保障跨鏈操作的安全性，不需要再依賴於外部的基礎設施。只要用戶信任 Merlin Chain，就可以默認此類跨鏈互操作行為是沒有問題的。

總結

在本文中，我們對 Merlin Chain 大體的技術方案進行了簡要解讀，相信可以讓更多人理解 Merlin 的大致工作流程，對其安全模型有更清晰的認知。考慮到當前比特幣生態的如火如荼，我們認為，此類技術科普行為是有價值且為廣大群衆所需要的， 我們將在日後對 Merlin 及 bitLayer、B^Square 等項目進行長期的跟進 ，對其技術方案進行更為深入的解析，大家敬請期待！