撰文：Faust，極客web3
從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 ？ 。如果兩者之間存在對應關係，表示鏈下的資料提供者給你的資料沒錯。
（DA 層存在於比特幣鏈下的Layer2 原理圖，圖源：極客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，交由外界去讀取並確認。
（Merlin 工作原理圖來源：極客web3）
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 等項目進行長期的跟進，對其技術方案進行更深入的解析，大家敬請期待！
聲明：本內容為作者獨立觀點，不代表0x财经 立場，且不構成投資建議，請謹慎對待，如需通報或加入交流群，請聯絡微信：VOICE-V。
來源： 極客Web3
