jakiro
作者：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等項目進行長期的跟進 ，對其技術方案進行更為深入的解析，大家敬請期待！
