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