Merlin技術方案の解説：それは一体どのように動作しているのか？
TechFlow厳選深潮セレクト
Merlin技術方案の解説：それは一体どのように動作しているのか？
より多くの人々にMerlinの概要的な動作プロセスを理解してもらい、そのセキュリティモデルについてより明確な認識を持ってもらうこと。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Faust、Geek web3
2023年のインスクリプションの夏から現在まで、ビットコインLayer2は一貫してWeb3全体の注目を浴びてきた。この分野の台頭はイーサリアムLayer2に比べて遅れたものの、POWの独自の魅力と現物ETFの順調な導入により、証券化リスクを気にする必要のないビットコインはわずか半年で、Layer2という派生分野に数十億ドル規模の資本関心を集めた。
ビットコインLayer2の分野において、数十億ドルのTVLを持つMerlinは、間違いなく規模が最も大きく、最も注目されている存在である。明確なステーキング報酬と魅力的なリターン率により、Merlinは数ヶ月のうちに突如として台頭し、Blastをも凌ぐエコロジーマイフを築き上げた。Merlinの人気が高まるにつれ、その技術的アプローチについての議論も多くの人々の関心を集めている。
本稿では、Geek 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拡張方式を採用している。
Geek 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の原理図、出典：Geek web3）
上記のプロセスにより、チェーン外ノードが提供するデータがLayer1上の「手がかり」と関連付けられ、DA層による虚偽データの悪意ある提供を防ぐことができる。しかし、ここで非常に重要な悪意行為シナリオが存在する。データの起点であるSequencerが、datahashに対応するdata自体を一切配布せず、datahashだけをビットコインチェーンに送信し、意図的にdataを誰にも読ませないように隠匿する場合、どうすればよいだろうか？
類似のケースには、ZK-ProofとStateRootだけを公開し、対応するDAデータ（state diffやトランザクションデータ）を公開しないことが含まれる。ユーザーはZKProofを検証することで、Prev_StaterootからNew_Staterootへの計算が正しく行われたことを確認できるが、どのアカウントのstate（状態）が変化したかはわからない。この場合、ユーザーの資産は安全だが、ネットワークの実際の状態が不明となり、どのトランザクションがブロックに組み込まれたか、どのコントラクトの状態が更新されたかも分からない。このような状態のLayer2は事実上停止しているのと同じである。
これはまさに「データ保持（Data Withholding）」の問題であり、イーサリアム財団のDankradは2023年8月、Twitter上で同様の問題について簡単に言及している。ただし彼の議論は、ある「DAC」と呼ばれる仕組みに主に焦点を当てていた。
チェーン外DA方式を採用する多くのイーサリアムLayer2では、特殊な権限を持つ少数のノードが委員会を形成し、これをData Availability Committee（DAC）と呼ぶ。このDAC委員会は保証人のような役割を果たし、「Sequencerは確かにチェーン外に完全なDAデータ（トランザクションデータまたはstate diff）を公開した」と外部に宣言する。その後、DACノードが共同でマルチシグネチャを生成し、閾値（例えば2/4）を満たせば、Layer1上の関連スマートコントラクトは、SequencerがDAC委員会のチェックを通過し、チェーン外に完全なDAデータを正確に公開したとみなす。
イーサリアムLayer2のDAC委員会は基本的にPOA方式を採用しており、KYC済みまたは公式指定の少数ノードのみが参加を許可される。これにより、DACは「中央集権的」「コンソーシアムチェーン」の代名詞となった。さらに、一部のDAC方式を採用するイーサリアムLayer2では、SequencerがDAデータをDACメンバーのノードにしか送信せず、他の場所にはほとんどデータをアップロードしないため、DAデータを取得したい者は必ずDAC委員会の許可を得る必要があり、コンソーシアムチェーンとの本質的差異はない。
疑いなく、DACは非中央集権化されるべきである。Layer2はDAデータをLayer1に直接アップロードしなくてもよいが、DAC委員会の参加資格は開放されるべきであり、少数による共謀による悪意行為を防ぐ必要がある。（DACの悪意行為シナリオについては、Dankradの過去のTwitter投稿を参照）
Celestiaが以前提唱したBlobStreamは、実質的に中央集権的なDACをCelestiaで代替するものであり、イーサリアムL2のSequencerはDAデータをCelestiaチェーンに発行できる。もしCelestiaノードの2/3以上が署名すれば、イーサリアム上に展開されたLayer2専用コントラクトは、Sequencerが正しくDAデータを発行したと判断する。これは実質的にCelestiaノードを保証人とするものである。Celestiaには数百のバリデーターノードが存在するため、この巨大なDACは比較的非中央集権的であると考えられる。
Merlinが採用するDAソリューションは、CelestiaのBlobStreamに近い。どちらもPOS方式によりDACの参加資格を開放し、非中央集権化を促進する。誰でも必要な資産をステーキングすれば、DACノードを運営できる。Merlinのドキュメントでは、こうしたDACノードをOracleと呼び、BTC、MERL、さらにはBRC-20トークンのステーキングをサポートし、柔軟なステーキングメカニズムを提供するとともに、Lidoのような代理ステーキングも可能としている。（OracleのPOSステーキングプロトコルは、今後のMerlinの主要なストーリーの一つであり、高いステーキング利回りを提供する予定だ）
以下にMerlinの動作プロセスを簡単に説明する（図は下記参照）：
- Sequencerが多数のトランザクションリクエストを受け取ると、それらをまとめてdata batch（データバッチ）を生成し、ProverノードおよびOracleノード（非中央集権DAC）に送信する。
- MerlinのProverノードは非中央集権的であり、lumozのProver as a Serviceサービスを利用している。Proverプールは複数のdata batchを受信後、対応するゼロ知識証明を生成し、その後ZKPをOracleノードに送信して検証させる。
- Oracleノードは、lumozのZKプールから送られてきたZK Proofが、Sequencerから受け取ったdata batchと一致するかを検証する。両者が一致し、そのほかのエラーがない場合、検証を通過する。この過程で、非中央集権的なOracleノード群はしきい値署名によりマルチシグネチャを生成し、外部に宣言する――Sequencerは完全にDAデータを発行し、対応するZKPは有効であり、Oracleノードの検証を通過した。
- SequencerはOracleノードからマルチシグネチャの結果を収集し、署名数が閾値を満たした時点で、これらの署名情報をビットコインチェーンに送信する。同時に、DAデータ（data batch）のdatahashも付加し、外部からの読み取りと確認を可能にする。
（Merlinの動作原理図 出典：Geek web3）
- OracleノードはZK Proofの検証計算プロセスに対して特別な処理を行い、Commitment（コミットメント）を生成してビットコインチェーンに送信する。これにより、誰でもこの「コミットメント」に異議を唱えることが可能となる。このプロセスはbitVMの詐欺証明プロトコルと基本的に同一である。異議が成功した場合、コミットメントを発行したOracleノードは経済的ペナルティを受ける。当然ながら、Oracleがビットコインチェーンに送信するデータには、現在のLayer2状態のハッシュ（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は、出金橋（withdrawal bridge）も詐欺証明プロトコルによって保護されることを確保する必要がある。しかし、現時点ではほぼすべてのビットコイン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を完成させ、報酬を得るためにそれを送信しようとする。他のAggregatorがその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(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ネットワークはまずその内容を解析し、ターゲットチェーン上で実行するトランザクションデータを生成する。その後、Oracle Networkがそのトランザクションに対してMPC署名処理を行い、トランザクションのデジタル署名を生成する。次に、MerlinのRelayerノードがPolygon上でそのトランザクションを送信し、Merlinのターゲットチェーン上EOAアカウント内の資産を使って後続の操作を完了させる。
ユーザーの要求する操作が完了すると、対応する資産は直接ユーザーのターゲットチェーン上のアドレスに転送される。理論的には、直接Merlin Chainに戻すことも可能である。この方式にはいくつかの明確な利点がある：伝統的な資産クロスチェーン時にクロスチェーンブリッジコントラクトが発生させる手数料の損失を回避でき、かつ直接MerlinのOracle Networkによってクロスチェーン操作の安全性が保証されるため、外部インフラに依存する必要がない。ユーザーがMerlin Chainを信頼していれば、このようなクロスチェーン相互運用操作に問題ないと見なすことができる。
まとめ
本稿では、Merlin Chainの主要な技術設計について概要を解説した。これにより、より多くの人々がMerlinの大まかな動作プロセスを理解し、そのセキュリティモデルに対する認識を深められることを期待している。現在のビットコインエコシステムの盛り上がりを考えると、このような技術的啓蒙活動は価値があり、広く求められていると考える。今後もMerlinやbitLayer、B^Squareなどについて長期的に追跡し、より深い技術的分析を提供していくので、ぜひご期待いただきたい。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
