讓更多人理解 Merlin 的大致工作流程，對其安全模型有更清晰的認知
從 2023 年的銘文之夏至今，比特幣 Layer2 始終都是整個 Web3 的重頭戲。雖然這一領域的興起遠晚於以太坊 Layer2，但憑藉著 POW 的獨特魅力，以及現貨 ETF 的順利落地，無需顧忌 “證券化” 風險的比特幣在短短半年時間裡，就為 Layer2 這一衍生賽道吸引了動輒百億美元的資本注意力。而在比特幣 Layer2 賽道中，坐擁數十億美元 TVL 的 Merlin，毫無疑問是體量最大、追蹤者最多的那一個。憑藉著明確的質押激勵和可觀的收益率，Merlin 幾乎在幾個月之內突然拔地而起，創造了一個超越 Blast 的生態神話。隨著 Merlin 的逐漸火熱，關於其技術方案的探討也成為越來越多人關注的議題。在本文中，極客 web3 將聚焦於 Merlin Chain 技術方案，對其已公開的文件及協議設計思路進行解讀，我們致力於讓更多人理解 Merlin 的大致工作流程，對其安全模型有更清晰的認知，讓大家以更直覺的方式來理解這個「頭部比特幣 Layer2」到底是怎麼運作的。
Merlin 的去中心化預言機網絡：開放性的鏈下 DAC 委員會
對於所有的 Layer2 而言，無論是以太坊 Layer2，還是比特幣 Layer2，DA 與數據發布成本，都是最需要解決的問題之一。由於比特幣網路本身存在諸多問題，天生不支援較大的資料吞吐量，該如何利用這寸土寸金的 DA 空間，成為了考驗 Layer2 專案方想像力的難題。
有一個結論是顯而易見的：如果 Layer2「直接」把未經處理的的交易數據，發佈到比特幣區塊裡，既不能實現高吞吐量，也不能實現低手續費。最主流的解決方案，要嘛透過高度壓縮，把資料尺寸壓縮的盡可能小，再上傳到比特幣區塊，要嘛就把資料直接發佈在比特幣鏈下。
在採用第一個想法的 Layer2 中，最出名的可能是 Citrea，它們打算把一段時間內 Layer2 的狀態變化 (state diff)，也就是多個帳戶上的狀態變更結果，連同對應的 ZK 證明，一起上傳到比特幣鏈上。在這種情況下，任何人都可以從比特幣主網下載 state diff 和 ZKP，進而監控到 Citrea 狀態的變化結果。這種方法可以把上鍊的資料尺寸壓縮 90% 以上。
雖然這可以極大程度壓縮資料尺寸，但瓶頸還是很明顯。如果在短時間內，有大量的帳戶發生狀態變更，Layer2 要把這些個帳戶的變更情況，全部匯總上傳到比特幣鏈上，最終的數據發布成本無法壓到很低，這一點在很多以太坊 ZK Rollup 身上可見一斑。
很多比特幣 Layer2 乾脆走第二種路徑：直接用比特幣鏈下的 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（data1) == datahash1 ？ 。如果兩者之間存在對應關係，表示鏈下的資料提供者給你的資料沒錯。
來源：極客 web3）
上述流程可以保證鏈下節點提供給你的數據，與 Layer1 上的某些「線索」相關聯，防止 DA 層惡意提供虛假數據。但這裡有一個很重要的作惡場景：假如資料的源頭－Sequencer，壓根沒有把 datahash 對應的 data 發出去，只把 datahash 發到了比特幣鏈上，卻故意扣住對應的 data 不讓任何人讀取，這種時候怎麼辦？
類似的場景包括但不限於：只把 ZK-Proof 和 StateRoot 發佈出來，卻不發布對應的 DA 資料（state diff 或 Transaction data），人們雖然可以驗證 ZKProof，確定 Prev_Stateroot 到 New_Stateroot 的計算過程有效無誤，但卻不知道有哪些帳戶的 state（狀態）發生了變化。在這種情況下，雖然使用者的資產是安全的，但大家根本無法確定網路的實際狀態，不知道有哪些交易被打包上鍊，哪些合約的狀態發生了更新，此時的 Layer2 基本上等同於停機。
這其實就是 「資料扣留」，以太坊基金會的 Dankrad 曾經在 2023 年 8 月，於推特上簡單討論了類似的問題，當然他主要針對的是一個名為「DAC」的東西。
許多採用鏈下 DA 方案的以太坊 Layer2，往往會設置幾個具有特殊權限的節點，組成一個委員會，全名為 Data Availability Committee (DAC) 。這個 DAC 委員會扮演了擔保人的角色，對外聲稱：Sequencer 的確在鏈下發布了完整的 DA 資料（transaction data 或 state diff）。然後 DAC 節點集體產生一個多簽，只要多簽滿足閾值要求（例如 2/4），Layer1 上的相關合約就會默認，Sequencer 通過了 DAC 委員會的檢查，如實的在鏈下發布了完整的 DA 數據。
以太坊 Layer2 的 DAC 委員會基本上都遵循 POA 模式，只允許少數經過 KYC 或官方指定的節點加入 DAC 委員會，這使得 DAC 成為了「中心化」、「聯盟鏈」的代名詞。此外，在某些採用 DAC 模式的以太坊 Layer2 那裡，排序器只把 DA 數據發送給 DAC 成員節點，幾乎不會再往其他地方上傳數據，任何人要獲取 DA 數據，必須得到 DAC 委員會的許可，和聯盟鏈沒有本質區別。
毫無疑問，DAC 應該去中心化，Layer2 可以不把 DA 資料直接上傳至 Layer1，但 DAC 委員會的准入權限應該對外開放，這樣才能防止少數人串謀作惡。（關於 DAC 作惡場景的討論，可以參考 Dankrad 先前在推特上的發言）
Celestia 先前提出的 BlobStream，本質是用 Celestia 取代中心化的 DAC，以太坊 L2 的排序器可以把 DA 資料發佈到 Celestia 鏈上，如果有 2/3 的 Celestia 節點為之簽名，以太坊上部署的 Layer2 專屬合約就認為排序器如實發布了 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 要發佈到比特幣鏈上的數據，還包括當前 Layer2 狀態的 hash——StateRoot，以及 ZKP 本身，都要發佈到比特幣鏈上，讓外界檢測。
參考資料：《極簡解讀 BitVM：如何在 BTC 鏈上驗證詐欺證明》
這裡面還有幾個需要闡述的細節，首先 Merlin 路線圖中提到，未來會讓 Oracle 把 DA 數據備份到 Celestia 上，這樣一來，Oracle 節點可以適當的淘汰掉本地的歷史數據，不需要把數據永存在本地。同時，Oracle Network 產生的 Commitment，其實是一棵 Merkle Tree 的 root，光對外披露 root 還不行，要把 Commitment 對應的完整資料集全部公開，這就需要尋找一個第三方的 DA 平台，這個平台可以是 Celestia 或 EigenDA，也可以是其他的 DA 層。
參考資料：《解析 B^2 新版技術路線圖：比特幣鏈下 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 或許有些不倫不類，但這正好貼合了比特幣 Layer2 的現狀。由於技術上的限制，比特幣鏈上無法完整的驗證 ZK Proof，只能在特殊情況下驗證 ZKP 的某一步計算過程，在這種前提下，比特幣鏈上實際只能支持欺詐證明協議，人們可以指出 ZKP 在鏈下驗證過程中，某一個計算步驟有錯誤，並透過詐欺證明的方式進行挑戰，當然這無法向以太坊式的 ZK Rollup 看齊，但已經是目前比特幣 Layer2 所能企及的最可靠、最穩健的安全模型。
在上述樂觀的 ZK-Rollup 方案下，假設 Layer2 網路中存在 N 個有權限發起挑戰的人，只要這 N 個挑戰者中有 1 人是誠實可靠的，隨時能夠檢測出錯誤並發起欺詐證明，Layer2 的狀態轉換就是安全的。當然，完成度比較高的樂觀 Rollup 需要確保其提款橋也受到欺詐證明協議的保護，而目前幾乎所有的比特幣 Layer2 都無法實現這個前提，需要依賴多簽/MPC，那麼該如何選用多簽/MPC 方案，就成為了與 Layer2 安全性息息相關的問題。
Merlin 在橋接方案上選擇了 Cobo 的 MPC 服務，採用冷熱錢包隔離等措施，橋接資產由 Cobo 和 Merlin Chain 共同管理，任何提款行為需要 Cobo 和 Merlin Chain 的 MPC 參與者共同處理，本質上是通過機構的信用背書來保障提款橋的可靠性。當然這只是目前階段的權宜之計，隨著項目的逐漸完善，提款橋可以通過引入 BitVM 與欺詐證明協議來更替為 1/N 信任假設的 “樂觀橋”，只是這樣做的落地難度會比較大（目前幾乎所有的 Layer2 官方橋都依賴多簽）。
整體來看，我們可以梳理下，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 等項目進行長期的跟進，對其技術方案進行更深入的解析，大家敬請期待！
免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
