技術的な解釈: マーリンチェーンはどのように機能しますか?
原作者：ファウスト、オタクweb3
2023 年の夏から現在まで、ビットコイン レイヤー 2 は常に Web3 全体のハイライトでした。この分野の立ち上がりはイーサリアムのレイヤー2に比べてかなり遅いですが、POWならではの魅力とスポットETFのスムーズな導入により、「証券化」のリスクを気にする必要のないビットコインがレイヤー2として定着しました。この派生トラックは数百億ドル相当の資本の注目を集めました。
ビットコイン レイヤー 2 トラックでは、TVL で数十億ドルを保有するマーリンが、間違いなく最大のボリュームと最も多くのフォロワーを抱えています。明確な賭けのインセンティブとかなりの収益により、マーリンは数カ月以内にほとんど突然地面から立ち上がり、ブラストを超える生態学的神話を生み出しました。 Merlin の人気が高まるにつれて、その技術的ソリューションに関する議論がますます多くの人々の関心事となっています。
この記事では、 Geek Web3 は Merlin Chain の技術ソリューションに焦点を当て、その公開ドキュメントとプロトコル設計のアイデアを解釈し、より多くの人に Merlin の一般的なワークフローを理解してもらい、そのセキュリティ モデルをより明確に理解してもらえるように取り組んでいます。この「Head Bitcoin Layer 2」がより直感的な方法でどのように動作するか。
Merlin の分散型オラクル ネットワーク: オープンなオフチェーン DAC 委員会
イーサリアム レイヤ 2 であろうとビットコイン レイヤ 2 であろうと、すべてのレイヤ 2 にとって、DA とデータ リリースのコストは解決すべき最も重要な問題の 1 つです。ビットコインネットワーク自体には多くの問題があり、大規模なデータスループットを自然にサポートしていないため、この貴重な DA スペースをどのように活用するかが、レイヤー 2 プロジェクトの想像力を試す難しい問題となっています。
結論の 1 つは明らかです。レイヤー 2 が未処理のトランザクション データをビットコイン ブロックに「直接」公開した場合、高いスループットも低い手数料も達成できません。最も主流のソリューションは、高圧縮によってデータ サイズを可能な限り小さく圧縮してからビットコイン ブロックにアップロードするか、データをビットコイン チェーンに直接公開するかのいずれかです。
最初のアイデアを採用したレイヤー 2 の中で最も有名なものは、おそらく Citrea です。彼らは、一定期間にわたるレイヤー 2 の状態変化 (状態差分)、つまり複数のアカウントの状態変化の結果を比較することを計画しています。対応する ZK プルーフと一緒にビットコインチェーンにアップロードされます。この場合、誰でもビットコインのメインネットから状態差分と ZKP をダウンロードして、Citrea の状態の変化を監視できます。この方法では、チェーン上のデータ サイズを 90% 以上圧縮できます。
これによりデータ サイズを大幅に圧縮できますが、ボトルネックは依然として明らかです。短期間に多数のアカウントのステータスが変更された場合、レイヤー 2 はこれらのアカウントのすべての変更を要約してビットコイン チェーンにアップロードする必要があり、これは多くのイーサリアムに当てはまります。これは ZK ロールアップで確認できます。
多くのビットコイン レイヤー 2 は単純に 2 番目のパスを選択します。つまり、ビットコイン チェーンから DA ソリューションを直接使用するか、自分で DA レイヤーを構築するか、Celestia、EigenDA などを使用します。 B^Square、BitLayer、そしてこの記事の主人公である Merlin はすべて、このオフチェーン DA 拡張ソリューションを使用しています。
Geekweb3 の以前の記事「B^ 2 の新しい技術ロードマップの分析: ビットコインチェーン下の DA と検証層の必要性」では、 B^ 2 が Celestia を直接模倣し、オフチェーンのサポートを構築するデータサンプリング機能を備えた DA ネットワークについて述べました。は B^2 ハブと呼ばれます。トランザクションデータや状態差分などの「DAデータ」はビットコインチェーンの下に保存され、データハッシュ/マークルルートのみがビットコインメインネットにアップロードされます。
これは基本的にビットコインを信頼できない掲示板として扱います。誰でもビットコイン チェーンからデータハッシュを読み取ることができます。オフチェーン データ プロバイダーから DA データを取得した後、それがオンチェーン datahash に対応するかどうか、つまり hash (data 1) == datahash 1? を確認できます。 。 2 つの間に一致がある場合は、オフチェーン データ プロバイダーから提供されたデータが正しいことを意味します。
上記のプロセスにより、オフチェーン ノードによって提供されるデータがレイヤー 1 上の特定の「手がかり」に関連付けられていることを確認し、DA レイヤーが悪意を持って偽のデータを提供するのを防ぐことができます。しかし、ここに非常に重要な邪悪なシナリオがあります。データのソースであるシーケンサーは、データハッシュに対応するデータをまったく送信せず、データハッシュをビットコインチェーンに送信するだけですが、誰かがアクセスするのを防ぐために、対応するデータを意図的に差し控えるとします。それを読んで、私はこのとき何をすべきですか？
同様のシナリオには、ZK-Proof と StateRoot のみをリリースし、対応する DA データ (状態差分またはトランザクション データ) をリリースしないことが含まれますが、ZKProof を検証して、Prev_Stateroot から New_Stateroot までの計算プロセスが有効であることを確認できます。しかし、どのアカウントの状態が変化したかはわかりません。この場合、ユーザーの資産は安全ですが、現時点でどのトランザクションがチェーン上にパッケージ化されているか、どのコントラクト ステータスが更新されているかを誰もが知ることができません。基本的にはシャットダウンと同じです。
これは実際には「データの源泉徴収」です。イーサリアム財団のダンクラッド氏は、2023 年 8 月に同様の問題を Twitter で簡単に議論しました。もちろん、彼は主に「DAC」と呼ばれるものをターゲットにしていました。
オフチェーン DA ソリューションを使用する多くのイーサリアム レイヤ 2 は、多くの場合、委員会を形成するための特別な権限を持つ複数のノードをセットアップします。委員会の正式名は、データ可用性委員会 (DAC) です。この DAC 委員会は保証人として機能し、Sequencer が実際に完全な DA データ (トランザクション データまたは状態の差分) をオフチェーンにリリースしたことを外部の世界に主張します。次に、DAC ノードが集合的にマルチシグネチャを生成します。マルチシグネチャがしきい値要件 (2/4 など) を満たしている限り、シーケンサーは DAC 委員会の検査に合格し、真実になります。完全な DA オフチェーン データを解放します。
イーサリアムレイヤー2のDAC委員会は基本的にPOAモデルに従い、KYCまたは正式な指定を経た少数のノードのみがDAC委員会に参加することを許可します。これにより、DACは「集中化」および「アライアンスチェーン」と同義になります。また、DACモードを採用する一部のイーサリアムレイヤー2では、シーケンサーはDACメンバーノードにのみDAデータを送信し、他の場所にデータをアップロードすることはほとんどありません。DAデータを取得したい場合はDAC委員会の許可を得る必要があります。アライアンスチェーンと本質的な違いはありません。
DAC が分散化されるべきであることに疑いの余地はありません。レイヤー 2 が DA データをレイヤー 1 に直接アップロードする必要はありません。ただし、少数の人々が共謀して悪事を働くことを防ぐために、DAC 委員会のアクセス権は外部に公開されるべきです。 。 (DAC の邪悪なシーンについては、Twitter でのダンクラッドの以前の発言を参照してください)
Celestia によって以前に提案された BlobStream は、基本的に集中型 DAC を置き換えるために Celestia を使用します。Ethereum L2 シーケンサーは、Celestia ノードの 2/3 がそれに署名した場合、Ethereum 2 にデプロイされたレイヤーで DA データを公開できます。ソーターが DA データを真実に公開したことにより、実際に Celestia ノードが保証人として機能できるようになります。 Celestia に数百の Validator ノードがあることを考慮すると、この大規模な DAC は比較的分散化されていると考えることができます。
Merlin が採用した DA ソリューションは、実際には Celestia の BlobStream に比較的近く、どちらも POS を介して DAC にアクセスできるため、より分散化されています。十分な資産をステークしている人は誰でも DAC ノードを実行できます。 Merlin のドキュメントでは、上記の DAC ノードは Oracle と呼ばれており、柔軟なプレッジ メカニズムを実装するために BTC、MERL、さらには BRC-20 トークンの資産プレッジをサポートし、Lido と同様のプロキシプレッジもサポートすると述べられています。 (オラクルの POS 誓約契約は基本的にマーリンの次の中核となる物語の 1 つであり、提供される誓約金利は比較的高いです)
ここでは、Merlin のワークフローを簡単に説明します (下の図)。
シーケンサーは大量のトランザクション リクエストを受信すると、それらを集約してデータ バッチを生成し、Prover ノードと Oracle ノード (分散型 DAC) に渡します。
Merlin の Prover ノードは分散型であり、lumoz の Prover as a Service サービスを使用します。複数のデータ バッチを受信した後、証明者マイニング プールは対応するゼロ知識証明を生成し、その後、ZKP が検証のために Oracle ノードに送信されます。
Oracle ノードは、Lmuoz の ZK マイニング プールによって送信された ZK Proof がシーケンサーによって送信されたデータ バッチに対応するかどうかを検証します。 2 つが一致し、他のエラーが含まれていない場合、検証は合格となります。このプロセス中に、分散型 Oracle ノードはしきい値署名を通じてマルチ署名を生成し、シーケンサーが DA データを完全に送信し、対応する ZKP が有効で Oracle ノードの検証に合格したことを外部に宣言します。
シーケンサはOracleノードからマルチ署名結果を収集し、署名数が閾値要件を満たした場合、署名情報はDAデータのデータハッシュ（データバッチ）とともにビットコインチェーンに送信され、外部に引き渡されます。読んで確認するための世界。
OracleノードはZK Proofを検証する計算プロセスに特別な処理を実行し、Commitmentコミットメントを生成してビットコインチェーンに送信することで、誰でも「コミットメント」に挑戦できるようにします。ここでのプロセスは基本的にbitVMの不正防止プロトコルと同じです。チャレンジが成功した場合、コミットメントを発行した Oracle ノードは経済的に罰せられます。もちろん、Oracle がビットコイン チェーンに公開しようとしているデータには、現在のレイヤー 2 状態のハッシュである StateRoot と、外部検出のためにビットコイン チェーンに公開する必要がある ZKP 自体も含まれています。
ここで詳しく説明する必要がある詳細がいくつかあります。まず、Merlin ロードマップでは、Oracle が将来的に DA データを Celestia にバックアップする予定であると述べています。これにより、Oracle ノードはデータを保持する必要がなく、ローカルの履歴データを適切に削除できるようになります。地元で。同時に、Oracle Network によって生成されたコミットメントは、実際にはマークル ツリーのルートです。そのルートを外部に公開するだけでは不十分です。これには、コミットメントに対応する完全なデータ セットを公開する必要があります。サードパーティの DA プラットフォーム。このプラットフォームには Celestia、EigenDA、またはその他の DA レイヤーを使用できます。
セキュリティモデル分析: Optimistic ZKRollup+Cobo の MPC サービス
以上、Merlin のワークフローを簡単に説明しましたが、すでにその基本的な構造は習得できたと思います。 Merlin、B^Square、BitLayer、および Citrea が基本的に同じセキュリティ モデル、つまり楽観的な ZK-Rollup に従っていることを理解するのは難しくありません。
この言葉を初めて読むと、多くのイーサリアム愛好家は奇妙に感じるかもしれません。「楽観的な ZK ロールアップ」とは何ですか?イーサリアムコミュニティの理解では、ZKロールアップの「理論モデル」は暗号計算の信頼性に完全に基づいており、信頼の仮定の導入を必要としません。「楽観主義」という言葉は正確に信頼の仮定を導入しており、これは人々のほとんどのことを意味します。現時点では、Rollup にはエラーがなく、信頼できると楽観的に考えてください。エラーが発生すると、ロールアップ オペレータは不正行為の証拠によって処罰される可能性があります。これが、オプティミスティック ロールアップ (OP ロールアップとも呼ばれます) という名前の由来です。
Rollup のベースとなる Ethereum エコシステムにとって、楽観的な ZK-Rollup は少し平凡かもしれませんが、これは Bitcoin Layer 2 の現在の状況と正確に一致しています。技術的な制限により、ビットコイン チェーンは ZK プルーフを完全に検証することはできず、特別な状況下でのみ ZKP 計算プロセスの特定のステップを検証することができます。この前提の下では、ビットコイン チェーンは実際には不正防止プロトコルのみをサポートできます。オフチェーン検証プロセスにおけるZKPの特定の計算ステップに誤りがあることを指摘し、不正証明を通じて異議を唱えました。もちろん、これはイーサリアムスタイルのZKロールアップと比較することはできませんが、すでに射程内にあります。ビットコイン レイヤ 2 の最も信頼性が高く安全なセキュリティ モデル。
上記の楽観的な ZK ロールアップ スキームでは、レイヤー 2 ネットワーク内にチャレンジを開始する権限を持つ人が N 人いると仮定すると、N 人のチャレンジ者の 1 人が正直で信頼できる限り、エラーが検出され、不正証明が開始されます。レイヤ 2 の状態遷移はいつでも安全です。もちろん、比較的完成度の高いオプティミスティック ロールアップは、引き出しブリッジも不正防止プロトコルによって保護されることを保証する必要がありますが、現在、ほとんどすべてのビットコイン レイヤ 2 はこの前提を達成できず、複数のプロトコルに依存する必要があります。マルチシグネチャ/MPC ソリューションは、レイヤー 2 セキュリティに密接に関係する問題になっています。
マーリンはブリッジング ソリューションとして Cobo の MPC サービスを選択し、ホット ウォレットとコールド ウォレットの分離などの措置を採用しました。ブリッジング資産は Cobo と Merlin Chain によって共同管理され、出金行為は Cobo と Merlin Chain の MPC 参加者によって共同で処理される必要があります。これは基本的に、金融機関の信用承認によって引き出しブリッジの信頼性が保証されます。もちろん、これは現段階では一時しのぎの措置にすぎませんが、プロジェクトが徐々に改善されるにつれて、BitVM と不正防止プロトコルを導入することで、撤退ブリッジを 1/N の信頼を前提とした「楽観的ブリッジ」に置き換えることができます。これを実装するのはさらに困難になります (現在、ほとんどすべての公式レイヤ 2 ブリッジはマルチシグネチャに依存しています)。
全体として、 Merlin は、POS ベースの DAC、BitVM ベースのオプティミスティック ZK-Rollup、および Cobo ベースの MPC 資産保管ソリューションを導入し、 BitVM と不正防止プロトコルを導入することで DAC 権限を開放し、DA 問題を解決したと整理できます。状態遷移のセキュリティ。有名な資産保管プラットフォーム Cobo の MPC サービスを導入することで、引き出しブリッジの信頼性を確保します。
Lumoz に基づく 2 段階認証 ZKP 提出ソリューション
先ほど、Merlin のセキュリティ モデルを整理し、楽観的な ZK ロールアップの概念を紹介しました。 Merlin のテクノロジー ロードマップでは、分散型 Prover についても取り上げられています。ご存知のとおり、Prover は ZK-Rollup アーキテクチャの中核的な役割を果たし、Sequencer によってリリースされたバッチの ZKProof を生成します。ただし、ゼロ知識証明の生成プロセスはハードウェア リソースを非常に消費し、非常に手間がかかります。厄介な問題。
ZK 証明の生成を高速化するには、タスクの並列化と分割が最も基本的な操作です。いわゆる並列化とは、実際には、ZK 証明生成タスクを複数の部分に分割し、それぞれを異なる証明者が完了することを意味します。最後に、アグリゲーターは複数の証明を 1 つに集約します。
ZK プルーフの生成プロセスを高速化するために、 Merlin は Lumoz の Prover をサービス ソリューションとして採用します。これは、実際に多数のハードウェア デバイスをまとめてマイニング プールを形成し、コンピューティング タスクをさまざまなデバイスに割り当て、対応するインセンティブは捕虜の採掘に似ています。
この分散型 Prover ソリューションには、一般にフロントランニング攻撃として知られる一種の攻撃シナリオがあります。アグリゲーターである Aggregator が ZKP を確立し、報酬を受け取ることを期待して ZKP を送信すると仮定します。他のアグリゲーターが ZKP のコンテンツを見た後、彼が最初に ZKP を生成したと主張して、同じコンテンツを公開します。
おそらく誰もが考える最も直感的な解決策は、指定されたタスク番号を各アグリゲーターに割り当てることです。たとえば、アグリゲーター A だけがタスク 1 を引き受けることができ、他の人はタスク 1 を完了しても報酬を受け取ることができません。しかし、このアプローチには問題があり、それは単一点リスクに対抗できないことです。アグリゲーター A にパフォーマンス障害が発生したか、切断された場合、タスク 1 はスタックして完了できなくなります。さらに、単一のエンティティにタスクを割り当てるこの方法は、競争的なインセンティブメカニズムを通じて生産効率を向上させることができず、良いアプローチではありません。
Polygon zkEVM はかつてブログで「効率性の証明」と呼ばれる手法を提案し、異なるアグリゲーター間の競争を促進するには競争手段を使用する必要があり、インセンティブは先着順で割り当てられるべきであると指摘しました。 first -Proof は、アグリゲーターをチェーンに送信することで報酬を得ることができます。もちろん、MEVの最前線の問題を解決する方法については言及しなかった。
Lumoz は 2 段階検証の ZK 証明送信方法を採用しており、アグリゲーターが ZK 証明を生成した後、最初に完全なコンテンツを送信する必要はなく、ZKP ハッシュのみを公開します。つまり、ハッシュ (ZKP+アグリゲーター) を公開します。住所）。このように、他の人がハッシュ値を見たとしても、対応する ZKP コンテンツを知らないため、直接先に進むことはできません。
誰かが単純にハッシュ全体をコピーして最初に公開しても、ハッシュには特定のアグリゲータ X のアドレスが含まれているため、意味がありません。たとえアグリゲータ A が最初にハッシュを公開したとしても、ハッシュの元のイメージが公開されると、誰もがそのハッシュを公開します。これに含まれるアグリゲータ アドレスが A ではなく X であることを確認してください。
この 2 段階検証の ZKP 提出スキームを通じて、Merlin (Lumoz) は ZKP 提出プロセスに存在する最前線の問題を解決し、それによって競争力の高いゼロ知識証明生成インセンティブを達成し、それによって ZKP 生成の速度を向上させることができます。
Merlin's Phantom: マルチチェーンの相互運用性
Merlin の技術ロードマップによれば、Merlin と他の EVM チェーン間の相互運用性もサポートされます。Merlin がソース チェーンとして使用され、他の EVM チェーンがターゲット チェーンとして使用される場合、実装パスは基本的に以前の Zetachain のアイデアと同じです。 Merlin ノードがユーザーによって発行されたクロスチェーン相互運用リクエストを感知した後、ターゲット チェーン上で後続のワークフローをトリガーします。
たとえば、Merlin ネットワークによって制御される EOA アカウントを Polygon にデプロイできます。ユーザーが Merlin チェーン上でクロスチェーン相互運用性命令を発行すると、Merlin ネットワークはまずそのコンテンツを解析し、ターゲット上で実行されるトランザクション データを生成します。チェーンに含めると、Oracle Network はトランザクションに対して MPC 署名処理を実行し、トランザクションのデジタル署名を生成します。その後、Merlin の Relayer ノードは Polygon 上でトランザクションを解放し、ターゲット チェーン上の EOA アカウント内の Merlin のアセットを通じてその後の操作を完了します。
ユーザーが要求した操作が完了すると、対応するアセットはターゲット チェーン上のユーザーのアドレスに直接転送され、理論的には Merlin チェーンに直接転送することもできます。このソリューションには明らかな利点がいくつかあります。従来の資産がクロスチェーンするときにクロスチェーンのブリッジ契約によって引き起こされる手数料や損耗を回避でき、クロスチェーン操作のセキュリティは Merlin の Oracle ネットワークによって直接保証されます。外部のインフラに依存する必要はありません。ユーザーが Merlin Chain を信頼している限り、このようなクロスチェーン相互運用性の動作は問題ないと想定できます。
要約する
この記事では、Merlin Chain の一般的な技術ソリューションについて簡単に説明します。これにより、より多くの人が Merlin の一般的なワークフローを理解し、そのセキュリティ モデルをより明確に理解できるようになると考えられます。現在のビットコインエコシステムが本格化していることを考慮すると、このような技術科学の普及は価値があり、一般社会に必要とされていると考えており、Merlin、bitLayer、B^Squareなどのプロジェクトについて長期的なフォローアップを行っていきます。将来的には、技術的なソリューションについてさらに詳細な分析を提供する予定ですので、ご期待ください。
