技術解釈：Merlin Chain はどのように運営されていますか？

原文作者：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に対応するデータを全く送信せず、datahashだけをビットコインチェーンに送信し、対応するデータを誰にも読み取らせないように故意に保持した場合、どうすればよいのでしょうか？

類似のシナリオには、ZK-ProofとStateRootだけを公開し、対応するDAデータ（state diffまたはTransaction data）を公開しないことが含まれます。人々はZKProofを検証し、PrevStaterootからNewStaterootへの計算プロセスが有効であることを確認できますが、どのアカウントのstate（状態）が変更されたのかはわかりません。この場合、ユーザーの資産は安全ですが、ネットワークの実際の状態を確認できず、どの取引がチェーンにパッケージされ、どのコントラクトの状態が更新されたのかもわかりません。この時点でLayer 2は基本的に停止状態と同じです。

これは実際に「データの保持」です。イーサリアム財団のDankradは、2023年8月にTwitterで類似の問題について簡単に議論しましたが、彼は主に「DAC」と呼ばれるものに焦点を当てていました。

多くのチェーン外DAソリューションを採用しているイーサリアムLayer 2は、しばしば特別な権限を持ついくつかのノードを設定し、Data Availability Committee（DAC）と呼ばれる委員会を構成します。このDAC委員会は保証人の役割を果たし、Sequencerが確かにチェーン外で完全なDAデータ（取引データまたはstate diff）を公開したと外部に主張します。その後、DACノードは集団でマルチシグを生成し、マルチシグが閾値要件（例えば2/4）を満たす限り、Layer 1上の関連コントラクトはSequencerがDAC委員会の検査を通過し、実際にチェーン外で完全なDAデータを公開したと見なします。

イーサリアムLayer 2のDAC委員会は基本的にPOAモデルに従い、少数のKYCまたは公式に指定されたノードのみがDAC委員会に参加することを許可します。これにより、DACは「中央集権的」または「コンソーシアムチェーン」の代名詞となります。さらに、DACモデルを採用しているいくつかのイーサリアムLayer 2では、SequencerはDAデータをDACメンバーのノードにのみ送信し、他の場所にはほとんどデータをアップロードしません。DAデータを取得するにはDAC委員会の許可が必要であり、コンソーシアムチェーンと本質的に変わりません。

DACは間違いなく非中央集権的であるべきです。Layer 2はDAデータを直接Layer 1にアップロードする必要はありませんが、DAC委員会の参加権限は外部に開放されるべきです。そうすることで、少数の人々が共謀して悪事を働くのを防ぐことができます。（DACの悪用シナリオについての議論は、Dankradの以前のTwitterの発言を参考にしてください）

Celestiaが以前提案したBlobStreamは、本質的にCelestiaを中央集権的なDACの代わりに使用するものです。イーサリアムL2のSequencerはDAデータをCelestiaチェーンに公開でき、2/3のCelestiaノードがそれに署名すれば、イーサリアム上にデプロイされたLayer 2専用コントラクトはSequencerがDAデータを正確に公開したと見なします。これは実際にCelestiaノードを保証人として機能させることを意味します。Celestiaには数百のバリデータノードがあるため、この大規模なDACは比較的非中央集権的であると考えられます。

Merlinが採用しているDAソリューションは、実際にはCelestiaのBlobStreamに非常に近く、POSの形式でDACの参加権限を開放し、非中央集権化を目指しています。誰でも十分な資産をステーキングすれば、DACノードを運営できます。Merlinの文書では、上記のDACノードをオラクルと呼び、BTC、MERL、さらにはBRC-20トークンの資産をステーキングすることをサポートし、柔軟なステーキングメカニズムを実現するとともに、Lidoのような代理ステーキングもサポートしています。（オラクルのPOSステーキングプロトコルは、Merlinの今後の核心的なストーリーの一つであり、提供されるステーキング利率などは非常に高いです）

ここでMerlinの作業フローを簡単に説明します（画像は下にあります）：

• Sequencerは大量の取引リクエストを受け取った後、それを集約し、data batch（データバッチ）を生成し、Proverノードおよびオラクルノード（非中央集権DAC）に送信します。

• MerlinのProverノードは非中央集権的で、lumozのProver as a Serviceサービスを採用しています。Proverマイニングプールは複数のdata batchを受け取った後、対応するゼロ知識証明を生成し、その後、ZKPはオラクルノードに送信され、後者が検証を行います。

• オラクルノードはLmuozのZKマイニングプールから送られたZK ProofがSequencerから送られたdata Batchと対応しているかどうかを検証します。もし両者が対応し、他のエラーを含まない場合、検証に合格します。このプロセス中、非中央集権的なオラクルノードは閾値署名を通じてマルチシグを生成し、外部に対してSequencerが完全にDAデータを公開し、対応するZKPが有効であり、オラクルノードの検証を通過したことを宣言します。

• Sequencerはオラクルノードからマルチシグの結果を収集し、署名の数が閾値要件を満たすと、これらの署名情報をビットコインチェーンに送信し、DAデータ（data batch）のdatahashを添付して外部に読み取らせ、確認させます。

オラクルノードはZK Proofの検証計算プロセスを特別に処理し、コミットメントを生成してビットコインチェーンに送信します。これにより、誰でも「コミットメント」に対して挑戦することができます。このプロセスはbitVMの詐欺証明プロトコルと基本的に一致します。もし挑戦が成功すれば、コミットメントを公開したオラクルノードは経済的な罰を受けます。もちろん、オラクルがビットコインチェーンに公開するデータには、現在のLayer 2状態のハッシュ------StateRootやZKP自体も含まれ、外部に検証させるために公開されます。

ここにはいくつかの説明が必要な詳細があります。まず、Merlinのロードマップには、将来的にオラクルがDAデータをCelestiaにバックアップすることが記載されています。これにより、オラクルノードはローカルの履歴データを適切に削除でき、データをローカルに永続的に保存する必要がなくなります。また、オラクルネットワークが生成するコミットメントは、実際にはMerkle Treeのルートであり、ルートを外部に公開するだけでは不十分で、コミットメントに対応する完全なデータセットをすべて公開する必要があります。これには第三者の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が公開したバッチに対してZKProofを生成する責任がありますが、ゼロ知識証明の生成プロセスは非常にハードウェアリソースを消費し、非常に厄介な問題です。

ZK証明の生成を加速するためには、タスクを並行処理に分割することが最も基本的な操作です。いわゆる並行処理とは、ZK証明の生成タスクを異なる部分に分割し、異なるProverがそれぞれを完了し、最後にAggregatorが複数のProofを統合して一つの全体にすることです。

ZK証明の生成プロセスを加速するために、MerlinはLumozのProver as a serviceソリューションを採用します。これは実際には大量のハードウェアデバイスを集めてマイニングプールを構築し、計算タスクを異なるデバイスに割り当て、対応するインセンティブを分配することを意味します。POWマイニングに似ています。

この非中央集権的なProverソリューションには、いわゆる「先行攻撃」と呼ばれる攻撃シナリオが存在します。例えば、あるAggregatorがZKPを構築し、それを送信して報酬を得ようとします。他のAggregatorがZKPの内容を見て、先に同じ内容を公開し、このZKPは自分が最初に生成したものだと主張する場合、どうすればよいのでしょうか？

おそらく皆さんが考える最も本能的な解決策は、各Aggregatorに特定のタスク番号を割り当てることです。例えば、タスク1はAggregator Aのみが受け取ることができ、他の人がタスク1を完了しても報酬を得られないようにします。しかし、この方法には単一障害リスクを防ぐことができないという問題があります。もしAggregator Aが性能障害を起こしたり、接続が切れたりした場合、タスク1はずっと完了できません。また、タスクを単一の実体に割り当てるこの方法では、競争的なインセンティブメカニズムを通じて生産効率を向上させることができず、あまり良い方法ではありません。

Polygon zkEVMは以前のブログで「効率の証明」と呼ばれる方法を提案しました。その中で、異なるAggregator間の競争を促進し、先着順で報酬を分配するべきだと指摘しています。最初にZK-Proofをチェーンに提出したAggregatorが報酬を得ることができます。もちろん、彼はMEVの先行問題をどう解決するかについては言及していません。

Lumozは二段階検証型のZK証明提出方式を採用しています。あるAggregatorがZK証明を生成した後、まず完全な内容を送信するのではなく、ZKPのハッシュのみを公開します。言い換えれば、hash（ZKP+Aggregator Address）を公開します。こうすることで、他の人がハッシュ値を見ても、対応するZKPの内容はわからず、直接先行することはできません。

もし誰かがそのハッシュをコピーして先に公開したとしても、意味はありません。なぜなら、ハッシュには特定のAggregator Xのアドレスが含まれているからです。Aggregator Aがこのハッシュを先に公開しても、ハッシュの原像が明らかになると、皆はその中に含まれるAggregatorアドレスがXであり、Aではないことを確認できます。

この二段階検証型のZKP提出方式を通じて、Merlin（Lumoz）はZKP提出プロセスにおける先行問題を解決し、高度な競争的なゼロ知識証明生成インセンティブを実現し、ZKPの生成速度を向上させることができます。

Merlin's Phantom：マルチチェーン相互運用性

Merlinの技術ロードマップによれば、彼らはMerlinと他のEVMチェーン間の相互運用性もサポートする予定です。その実現パスは以前のZetachainの考え方と基本的に一致しています。Merlinをソースチェーン、他のEVMチェーンをターゲットチェーンとした場合、Merlinノードがユーザーからのクロスチェーン相互運用リクエストを感知すると、ターゲットチェーン上で後続の作業フローをトリガーします。

例えば、Polygon上にMerlinネットワークが制御するEOAアカウントをデプロイし、ユーザーがMerlin Chain上でクロスチェーン相互運用指令を発行すると、Merlinネットワークはその内容を解析し、ターゲットチェーン上で実行される取引データを生成し、その後オラクルネットワークがその取引に対してMPC署名処理を行い、取引のデジタル署名を生成します。その後、MerlinのRelayerノードがPolygon上でこの取引を公開します。Merlinのターゲットチェーン上のEOAアカウント内の資産を通じて後続の操作を完了します。

ユーザーが要求した操作が完了すると、対応する資産は直接ユーザーのターゲットチェーン上のアドレスに転送され、理論的にはMerlin Chainに直接クロスすることも可能です。このソリューションにはいくつかの明らかな利点があります：従来の資産のクロスチェーン時に発生する手数料の摩耗を回避でき、Merlinのオラクルネットワークがクロスチェーン操作の安全性を直接保証します。外部のインフラに依存する必要はありません。ユーザーがMerlin Chainを信頼すれば、このようなクロスチェーン相互運用行為は問題ないと見なすことができます。

まとめ

この記事では、Merlin Chainの大まかな技術提案を簡単に解読しました。これにより、より多くの人々がMerlinの大まかな作業フローを理解し、その安全モデルについてより明確な認識を持つことができると信じています。現在のビットコインエコシステムの盛況を考慮すると、このような技術普及活動は価値があり、多くの人々に必要とされていると考えています。私たちは今後、MerlinやbitLayer、B^Squareなどのプロジェクトを長期的にフォローし、その技術提案をより深く解析していく予定ですので、皆さんご期待ください！