著者: ファウスト、オタクweb32023年の碑文の夏から現在まで、ビットコイン レイヤー2は常にWeb3全体のハイライトとなっています。 この分野の上昇はイーサリアム年のレイヤー2に比べるとかなり遅いものの、POWならではの魅力と現物 ETFのスムーズな上陸により、「証券化」のリスクを考慮しないビットコインは、わずか半年でレイヤー2のデリバティブトラックに数百億ドルの資金を集めました。ビットコイン レイヤー2トラックでは、数十億ドルのTVLを持つマーリンが、間違いなく最大の出来高と最もロングフォロワーを持つマーリンです。 明確なステーキングインセンティブとそれなりの利回りにより、マーリンはほぼ数ヶ月で誕生し、ブラストを超越した生態学的神話を生み出しました。 Merlinの人気が高まるにつれて、その技術的ソリューションの議論はますますロングトピックになっています。この記事では、Geek Web3がMerlin Chainの技術ソリューションに焦点を当て、公開されているドキュメントを解釈し、設計アイデアプロトコル、より多くのロング人々がMerlinの一般的なワークフローを理解し、そのセキュリティモデルをより明確に理解できるようにすることで、この「ヘッドビットコイン レイヤー2」がより直感的な方法でどのように機能するかを誰もが理解できるようにすることを約束します。### マーリンの分散型オラクルネットワーク:オープンオフチェーンDAC評議会イーサリアム レイヤー2かビットコイン レイヤー2かにかかわらず、すべてのレイヤー2において、DAとデータパブリッシングのコストは解決すべき最も重要な問題の1つです。 本質的に大きなデータスループットをサポートしないビットコインネットワーク自体の最も長い問題のために、このDAショートをどのように使用するかは、レイヤー2プロジェクトの想像力をテストするための難しい問題になっています。1つの結論は明らかです:レイヤー2が未処理のトランザクションデータをビットコイン ブロックに「直接」公開した場合、高いスループットや低い手数料を達成することはできません。 最も一般的な解決策は、データサイズを高圧縮でできるだけ小さく圧縮してビットコイン ブロックにアップロードするか、データを直接ビットコイン オフチェーンに公開することです。 **おそらく、最初のアプローチを採用しているレイヤー2レイヤーの中で最もよく知られているのはCitreaで、一定期間にわたるレイヤー2の状態差分、つまり、ロング アカウントの状態変化の結果を、対応するZKプルーフとともにビットコイン オンチェーンにアップロードする予定です。 この場合、誰でもビットコイン メインネットから状態差分とZKPをダウンロードして、Citreaの状態変更の結果を監視できます。 この方法では、チェーン上のデータのサイズを90%以上削減できます。これにより、データのサイズを大幅に削減できますが、ボトルネックは依然として重要です。 ショート期間に多数のアカウント状態変更が発生した場合、レイヤー2これらのアカウントのすべての変更を要約してビットコイン オンチェーンにアップロードする必要があり、最終的なデータリリースコストを非常にロング イーサリアム低く抑えることはできません。ビットコイン オフチェーン DAソリューションを直接使用するか、DAレイヤーを単独で構築するか、Celestia、EigenDAなどを使用するという2番目のパスを取るのは非常にロング ビットコイン レイヤー2です。 この記事の主人公であるB ^ Square、BitLayer、およびMerlinはすべて、このオフチェーンDAスケーリングスキームに従います。Geek web3の以前の記事「新バージョンのB^2技術ロードマップの分析:ビットコイン オフチェーンDAと検証レイヤーの必要性」では、**B^2がCelestiaを直接模倣し、B^2 Hubと名付けたオフチェーンでデータサンプリング機能をサポートするDAネットワークを構築していることを紹介しました。 トランザクションデータや状態差分などの「DAデータ」はビットコイン オフチェーンに格納され、datahash/マークルルートのみがビットコイン メインネットにアップロードされます。 **それは本当にビットコイントラストレス掲示板として扱っています:誰でもビットコイン オンチェーンからdatahashを読むことができます。 **オフチェーンデータプロバイダーからDAデータを取得すると、それがオンチェーンデータハッシュ**、つまりハッシュ(data1)==データハッシュ1?に対応しているかどうかを確認できます。 両者の間に対応関係がある場合は、オフチェーンのデータプロバイダーが適切なデータを提供したことを意味します。上記のプロセスにより、オフチェーン ノードから提供されたデータがレイヤー1の特定の「手がかり」に関連付けられていることが保証され、DAレイヤーが悪意を持って虚偽のデータを提供するのを防ぐことができます。 しかし、ここには非常に重要なピン シナリオがあります: データのソースである Sequencer が、データハッシュの対応するデータをまったく送信せず、データハッシュをビットコイン オンチェーンに送信するだけで、対応するデータを意図的に誰にも読ませないようにした場合はどうなるでしょうか。同様のシナリオには、ZKProofの計算プロセスが有効であることを検証し、Prev\_StaterootからNew\_Staterootへの計算プロセスが有効であることを確認できますが、どのアカウント状態(状態)が変更されたかはわかりませんが、ZK-ProofとStateRootのみを公開し、対応するDAデータ(状態差分またはトランザクションデータ)を公開しないことが含まれますが、これらに限定されません。 この場合、ユーザーの資産は安全ですが、ネットワークの実際の状態をまったく判断できず、どのトランザクションがチェーンにパッケージ化され、どのコントラクトが更新されたかがわかりません。これは実際には**「データ源泉徴収**」であり、イーサリアム財団のDankradは2023年8月にTwitterで同様の問題について簡単に議論しましたが、もちろん、彼は主に「DAC」と呼ばれるものの長い芯のローソクです。オフチェーンDAソリューションを採用している最長のイーサリアムレイヤー2は、多くの場合、データ可用性委員会(DAC)の正式名称である委員会を形成するために、特別な権限を持ついくつかのノードを設定します。 このDAC委員会は保証人として機能し、シーケンサーが完全なDAデータ(トランザクションデータまたは状態差分)をオフチェーンで公開すると主張しています。 次に、DACノードは、最長がしきい値要件(2/4など)を満たすロングのロングをまとめて生成し、レイヤー1の関連するコントラクトがデフォルトになり、シーケンサーはDAC委員会の検査に合格し、完全なDAデータをオフチェーンで正直にリリースしました。イーサリアム レイヤー2のDAC委員会は基本的にPOAモデルに従っており、DAC委員会に参加できるのは少数のKYCまたは公式に指定されたノードのみであるため、DACは「中央集権型」および「コンソーシアムブロックチェーン」と同義です。 また、DACモデルを採用している一部のイーサリアム レイヤー2では、シーケンサはDACメンバーノードにDAデータを送信するだけで、他のノードにデータをアップロードすることはほとんどなく、DAデータを取得しようとする者はDAC委員会の許可を得る必要があり、コンソーシアムブロックチェーンと根本的には変わらない。DACは分散化されるべきであり、レイヤー2はDAデータをレイヤー1に直接アップロードすることはできませんが、DAC委員会のアクセス権限は、少数の人々が共謀して悪を行うのを防ぐために外部に公開する必要があります。 (DACのいたずらシナリオの議論については、Dankradの以前のTwitterでの声明を参照してください)**セレスティアが以前に提案したBlobStreamは、本質的に中央集権型DACをセレスティアに置き換えるためのものであり、**イーサリアムL2シーケンサーはDAデータをセレスティアオンチェーンに公開でき、セレスティアノードの2/3が署名した場合、イーサリアムに展開されたレイヤー2専用コントラクトは、シーケンサーがDAデータを正直にリリースすると信じており、実際にはセレスティアノードを保証人として機能させるためです。 Celestiaには何百ものバリデータノードがあることを考えると、この大きなDACは比較的分散化されていると考えることができます。**Merlinが使用しているDAソリューションは、実際にはCelestiaのBlobStreamに近く、DACのアクセス権をPOSの形で開放し、分散化の傾向にあります。 誰でも十分な資産をステークするのと同じくらいロングのDACノードを実行できます。 Merlinのドキュメントでは、上記のDACノードはOracleと呼ばれ、BTC、MERL、さらにはBRC-20トークンのアセットステーキングがサポートされ、柔軟なステーキングメカニズムとLidoと同様のプロキシステーキングが可能になると指摘されています。 (オラクルマシンのPOSステーク プロトコルは基本的にマーリンの次のコアナラティブの1つであり、提供されるステーク 金利は比較的高いです)**Merlinのワークフローの簡単な説明(下の写真):**1. 多数のトランザクション要求を受信した後、シーケンサーはそれらを集約してデータバッチを生成し、それを証明ノードとオラクルノード(分散化DAC)に渡します。2. MerlinのProver ノードは、LumozのProver as a Serviceサービスを使用した分散化です。 最も長いデータバッチを受信すると、Proverマイニングプールは対応するzk-SNARKsを生成し、その後、ZKPが検証のためにOracle ノードに送信されます。3. Oracle ノードは、Lmuoz の ZK マイニングプールによって送信された ZK 証明が、シーケンサーによって送信されたデータ バッチに対応しているかどうかを検証します。 この 2 つが対応でき、他にエラーがない場合は検証されます。 このプロセスでは、分散化Oracleノードはしきい値署名を介してロング署名を生成し、外部で宣言します-シーケンサーはDAデータを完全に出力し、対応するZKPは有効であり、Oracle ノードの検証に合格しています。4.シーケンサーは、Oracle ノードからロング署名結果を収集し、署名の数がしきい値要件を満たすと、DAデータバッチのデータハッシュを使用して署名情報をビットコイン オンチェーンに送信し、外部に渡して読み取りと確認を行います。オラクルノードZK Proofを検証し、コミットメントコミットメントを生成してビットコイン オンチェーンに送信し、誰でも「コミットメント」に異議を唱えることができるようにするための計算プロセスの特別な処理を行っており、このプロセスのプロセスは基本的にbitVMの詐欺証明 プロトコルと同じです。 チャレンジが成功した場合、コミットメントを公開するOracle ノードに金銭的なペナルティが課せられます。 もちろん、Oracleがビットコイン オンチェーンに公開するデータ(現在のレイヤー2状態(StateRoot)のハッシュやZKP自体など)は、外部が検出できるようにビットコイン オンチェーンに公開する必要があります。まず、Merlinのロードマップには、将来的にOracleがDAデータをCelestiaにバックアップし、Oracle ノードがローカルの履歴データを適切に削除し、データを永久にローカルに保持する必要がないと記載されています。 同時に、Oracle Networkによって生成されたコミットメントは実際にはメークルツリーのルートであり、ルートを外部に開示するだけでは不十分ですが、コミットメントに対応するすべての完全なデータセットを開示するには、Celestia、EigenDA、またはその他のDAレイヤーであるサードパーティのDAプラットフォームを見つける必要があります。### セキュリティモデル分析: 楽観的な ZKRollup+Cobo の MPC サービス以上、Merlinのワークフローについて簡単に説明しましたが、その基本構造はすでによく理解していると思います。 Merlinが基本的にB^Square、BitLayer、Citreaと同じセキュリティモデル(楽観的なZK-Rollup)に従っていることは理解に難くありません。この言葉を最初に読んだとき、多くのロング イーサリアム愛好家は奇妙に感じるかもしれませんが、「楽観的なZKロールアップ」とは何ですか? イーサリアムコミュニティの認識では、ZK Rollupの「理論モデル」は完全に暗号技術計算の信頼性に基づいており、信頼の仮定を導入する必要はなく、楽観主義という言葉は正確に信頼の仮定を導入しているため、人々はロールアップが間違っていず、何度もロングしても信頼できると楽観的であるべきです。 また、エラーが発生すると、ロールアップ演算子は、OPロールアップとしても知られるオプティミスティックロールアップの名前の由来である詐欺証明によって罰せられる可能性があります。Rollupの本拠地のイーサリアムエコシステムにとって、楽観的なZK-Rollupは少し珍しいかもしれませんが、これはまさに現在のビットコイン レイヤー2状況と一致しています。 技術的な制限により、ビットコイン オンチェーンZKプルーフを完全に検証することはできません、特別な状況下でZKP計算プロセスの特定のステップのみを検証できます、この前提の下で、ビットコイン オンチェーン実際にサポート 詐欺証明 プロトコルすることしかできません、人々はオフチェーン検証プロセスでZKPを指摘することができます、特定の計算ステップにエラーがあり詐欺証明、もちろん、これはイーサリアムスタイルのZKロールアップと比較することはできませんが、ビットコインすでに最も信頼性が高く、 最も堅牢なセキュリティモデル。上記の楽観的なZK-Rollupスキームでは、レイヤー2ネットワーク内にN個の認可されたチャレンジャーがいると仮定し、これらのN個のチャレンジャーのうちの1つが正直で信頼性が高く、エラーを検出していつでも詐欺証明を開始できるロング、レイヤー2の状態遷移は安全です。 勿論、完成度が比較的高い楽観的なロールアップは、撤退ブリッジも詐欺証明 プロトコルで保護する必要があり、現状では、ほとんどのビットコイン レイヤー2がこの前提を達成できず、ロング署名/MPCに頼る必要があるため、ロング署名/MPCソリューションをどのように選択するかが、レイヤー2のセキュリティに密接に関連する問題になっています。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ベースの2段階認証ZKP提出スキーム以前、Merlinのセキュリティモデルをくまなく調べ、楽観的なZKロールアップの概念を紹介しました。 Merlinの技術ロードマップでは、分散化証明者についても議論されています。 ご存知のように、ProverはZK-Rollupアーキテクチャの中核的な役割であり、シーケンサーによってリリースされたバッチのZKProofの生成を担当し、zk-SNARKsの生成プロセスは非常にハードウェアリソースを大量に消費し、非常にトリッキーな問題です。ZKプルーフの生成を高速化するために、タスクの並列化は最も基本的な操作の1つです。 **いわゆる並列化は、実際にはZKプルーフ生成タスクを異なる部分に分割し、異なるプルーバーによって個別に完了し、最終的にアグリゲーターアグリゲーターが最も長いプルーフを全体に集約することです。ZKプルーフの生成プロセスを高速化するための注文では、MerlinはLumozのProoverをサービスソリューションとして使用し、実際には多数のハードウェアデバイスを集めてマイニングプールを形成し、POWマイニングと同様に、コンピューティングタスクをさまざまなデバイスに割り当て、対応するインセンティブを割り当てます。この分散化証明スキームには、一般にフロントランニング攻撃として知られている攻撃シナリオのクラスがあります:アグリゲーターアグリゲーターがZKPを形成し、報酬を受け取ることを期待してZKPを送信するとします。 他のアグリゲーターがZKPのコンテンツを見た後、彼らは急いで彼の前に同じコンテンツを投稿し、このZKPは自分の夫によって作られたと主張しましたが、この状況をどのように解決しますか?頭に浮かぶかもしれない最も本能的な解決策の1つは、各アグリゲーターに特定のタスク番号を割り当てることです、例えば、アグリゲーターAだけがタスク1を取ることができ、他の全員がタスク1を完了しても報酬を得ることはできません。 しかし、このアプローチの問題の 1 つは、単一のリスク ポイントから保護されないことです。 アグリゲーター A でパフォーマンス障害が発生したり、接続が切断されたりした場合、タスク 1 はスタックし、完了できません。 さらに、タスクを 1 つのエンティティに割り当てるというこの慣行は、競争力のあるインセンティブで生産性を向上させる良い方法ではありません。Polygon zkEVMはブログ記事で「Proof of efficiency」という手法を提案しており、異なるアグリゲーターをプロモートして互いに競争し、インセンティブは先着順で分配し、チェーンにZK-Proofを最初に提出したアグリゲーターが報酬を受け取ることができると述べています。 もちろん、彼はMEVのフロントランニングの問題を解決する方法については言及しませんでした。Lumozは2段階検証ZKプルーフ送信方法を使用しており、アグリゲーターがZKプルーフを生成した後、完全なコンテンツを送信する必要はなく、ZKPのハッシュのみを公開、つまりハッシュ(ZKP +アグリゲーターアドレス)を公開します。 このように、他の人がハッシュ値を見ても、対応するZKPコンテンツを知らず、直接急ぐことはできません。誰かが単にハッシュ全体をコピーして最初に公開した場合、ハッシュには特定のアグリゲーターXのアドレスが含まれており、アグリゲーターAが最初にハッシュを公開した場合でも、ハッシュの元の画像が明らかになると、そこに含まれるアグリゲーターアドレスはAではなくXであることが誰にでもわかります。この2段階検証ZKP提出スキームを通じて、Merlin(Lumoz)はZKP提出プロセスのフロントランニング問題を解決し、競争力の高いzk-SNARKs生成インセンティブを実現し、それによってZKPの生成速度を向上させることができます。### Merlin's Phantom: 最長チェーンの相互運用性Merlinの技術ロードマップによると、Merlinと他のEVMチェーン間の相互運用性もサポートし、その実装パスは基本的に以前のZetachainのアイデアと同じであり、Merlinがソースチェーンとして使用され、他のEVMチェーンがターゲットチェーンとして使用される場合、Merlinノードがユーザーによって行われたクロスチェーン相互運用性要求を認識すると、ターゲットオンチェーンで後続のワークフローをトリガーします。たとえば、Merlin ネットワークによって制御される EOA アカウントを Polygon にデプロイできます。 **ユーザーがMerlinチェーンでクロスチェーン相互運用性命令を発行すると、Merlinネットワークは最初にそのコンテンツを解析し、ターゲットオンチェーンで実行されるトランザクションデータを生成し、次にトランザクションのOracle Network MPC署名処理がトランザクションのデジタル署名を生成します。 次に、MerlinのRelayerノードは、Polygonでトランザクション**を解放し、ターゲットオンチェーン上のEOAアカウントにあるMerlinの資産を介して後続の操作を完了します。ユーザーが必要とする操作が完了すると、対応する資産はターゲットオンチェーン上のユーザーのアドレスに直接転送され、理論的にはマーリンチェーンに直接クロスすることもできます。 このソリューションにはいくつかの明らかな利点があります:従来の資産クロスチェーンおよびクロスチェーンブリッジ契約によって発生する手数料の損耗を回避でき、クロスチェーン操作のセキュリティを確保するためにMerlinのOracle Networkによって直接保証され、ロングは外部インフラストラクチャに依存する必要はありません。 ユーザーがMerlin Chainを信頼しているのと同じくらいロングですが、そのようなクロスチェーンの相互運用性をデフォルトにしても問題はありません。### まとめこの記事では、より多くのロングの人々がMerlinの一般的なワークフローを理解し、そのセキュリティモデルをより明確に理解するのに役立つと考えられているMerlin Chainの一般的な技術的ソリューションについて簡単に説明します。 現在のビットコインの生態学が本格化していることを考えると、この種の技術科学の普及行動は一般の人々にとって価値があり、必要とされていると信じています。 **今後、MerlinやbitLayer、B^Squareなどのプロジェクトについてロングのフォローアップを行い、その技術的ソリューションのより詳細な分析を行いますので、ご期待ください!
Merlinの動作メカニズムの技術的解釈
著者: ファウスト、オタクweb3
2023年の碑文の夏から現在まで、ビットコイン レイヤー2は常にWeb3全体のハイライトとなっています。 この分野の上昇はイーサリアム年のレイヤー2に比べるとかなり遅いものの、POWならではの魅力と現物 ETFのスムーズな上陸により、「証券化」のリスクを考慮しないビットコインは、わずか半年でレイヤー2のデリバティブトラックに数百億ドルの資金を集めました。
ビットコイン レイヤー2トラックでは、数十億ドルのTVLを持つマーリンが、間違いなく最大の出来高と最もロングフォロワーを持つマーリンです。 明確なステーキングインセンティブとそれなりの利回りにより、マーリンはほぼ数ヶ月で誕生し、ブラストを超越した生態学的神話を生み出しました。 Merlinの人気が高まるにつれて、その技術的ソリューションの議論はますますロングトピックになっています。
この記事では、Geek Web3がMerlin Chainの技術ソリューションに焦点を当て、公開されているドキュメントを解釈し、設計アイデアプロトコル、より多くのロング人々がMerlinの一般的なワークフローを理解し、そのセキュリティモデルをより明確に理解できるようにすることで、この「ヘッドビットコイン レイヤー2」がより直感的な方法でどのように機能するかを誰もが理解できるようにすることを約束します。
マーリンの分散型オラクルネットワーク:オープンオフチェーンDAC評議会
イーサリアム レイヤー2かビットコイン レイヤー2かにかかわらず、すべてのレイヤー2において、DAとデータパブリッシングのコストは解決すべき最も重要な問題の1つです。 本質的に大きなデータスループットをサポートしないビットコインネットワーク自体の最も長い問題のために、このDAショートをどのように使用するかは、レイヤー2プロジェクトの想像力をテストするための難しい問題になっています。
1つの結論は明らかです:レイヤー2が未処理のトランザクションデータをビットコイン ブロックに「直接」公開した場合、高いスループットや低い手数料を達成することはできません。 最も一般的な解決策は、データサイズを高圧縮でできるだけ小さく圧縮してビットコイン ブロックにアップロードするか、データを直接ビットコイン オフチェーンに公開することです。 **
おそらく、最初のアプローチを採用しているレイヤー2レイヤーの中で最もよく知られているのはCitreaで、一定期間にわたるレイヤー2の状態差分、つまり、ロング アカウントの状態変化の結果を、対応するZKプルーフとともにビットコイン オンチェーンにアップロードする予定です。 この場合、誰でもビットコイン メインネットから状態差分とZKPをダウンロードして、Citreaの状態変更の結果を監視できます。 この方法では、チェーン上のデータのサイズを90%以上削減できます。
これにより、データのサイズを大幅に削減できますが、ボトルネックは依然として重要です。 ショート期間に多数のアカウント状態変更が発生した場合、レイヤー2これらのアカウントのすべての変更を要約してビットコイン オンチェーンにアップロードする必要があり、最終的なデータリリースコストを非常にロング イーサリアム低く抑えることはできません。
ビットコイン オフチェーン DAソリューションを直接使用するか、DAレイヤーを単独で構築するか、Celestia、EigenDAなどを使用するという2番目のパスを取るのは非常にロング ビットコイン レイヤー2です。 この記事の主人公であるB ^ Square、BitLayer、およびMerlinはすべて、このオフチェーンDAスケーリングスキームに従います。
Geek web3の以前の記事「新バージョンのB^2技術ロードマップの分析:ビットコイン オフチェーンDAと検証レイヤーの必要性」では、**B^2がCelestiaを直接模倣し、B^2 Hubと名付けたオフチェーンでデータサンプリング機能をサポートするDAネットワークを構築していることを紹介しました。 トランザクションデータや状態差分などの「DAデータ」はビットコイン オフチェーンに格納され、datahash/マークルルートのみがビットコイン メインネットにアップロードされます。 **
それは本当にビットコイントラストレス掲示板として扱っています:誰でもビットコイン オンチェーンからdatahashを読むことができます。 オフチェーンデータプロバイダーからDAデータを取得すると、それがオンチェーンデータハッシュ、つまりハッシュ(data1)==データハッシュ1?に対応しているかどうかを確認できます。 両者の間に対応関係がある場合は、オフチェーンのデータプロバイダーが適切なデータを提供したことを意味します。
上記のプロセスにより、オフチェーン ノードから提供されたデータがレイヤー1の特定の「手がかり」に関連付けられていることが保証され、DAレイヤーが悪意を持って虚偽のデータを提供するのを防ぐことができます。 しかし、ここには非常に重要なピン シナリオがあります: データのソースである Sequencer が、データハッシュの対応するデータをまったく送信せず、データハッシュをビットコイン オンチェーンに送信するだけで、対応するデータを意図的に誰にも読ませないようにした場合はどうなるでしょうか。
同様のシナリオには、ZKProofの計算プロセスが有効であることを検証し、Prev_StaterootからNew_Staterootへの計算プロセスが有効であることを確認できますが、どのアカウント状態(状態)が変更されたかはわかりませんが、ZK-ProofとStateRootのみを公開し、対応するDAデータ(状態差分またはトランザクションデータ)を公開しないことが含まれますが、これらに限定されません。 この場合、ユーザーの資産は安全ですが、ネットワークの実際の状態をまったく判断できず、どのトランザクションがチェーンにパッケージ化され、どのコントラクトが更新されたかがわかりません。
これは実際には**「データ源泉徴収**」であり、イーサリアム財団のDankradは2023年8月にTwitterで同様の問題について簡単に議論しましたが、もちろん、彼は主に「DAC」と呼ばれるものの長い芯のローソクです。
オフチェーンDAソリューションを採用している最長のイーサリアムレイヤー2は、多くの場合、データ可用性委員会(DAC)の正式名称である委員会を形成するために、特別な権限を持ついくつかのノードを設定します。 このDAC委員会は保証人として機能し、シーケンサーが完全なDAデータ(トランザクションデータまたは状態差分)をオフチェーンで公開すると主張しています。 次に、DACノードは、最長がしきい値要件(2/4など)を満たすロングのロングをまとめて生成し、レイヤー1の関連するコントラクトがデフォルトになり、シーケンサーはDAC委員会の検査に合格し、完全なDAデータをオフチェーンで正直にリリースしました。
イーサリアム レイヤー2のDAC委員会は基本的にPOAモデルに従っており、DAC委員会に参加できるのは少数のKYCまたは公式に指定されたノードのみであるため、DACは「中央集権型」および「コンソーシアムブロックチェーン」と同義です。 また、DACモデルを採用している一部のイーサリアム レイヤー2では、シーケンサはDACメンバーノードにDAデータを送信するだけで、他のノードにデータをアップロードすることはほとんどなく、DAデータを取得しようとする者はDAC委員会の許可を得る必要があり、コンソーシアムブロックチェーンと根本的には変わらない。
DACは分散化されるべきであり、レイヤー2はDAデータをレイヤー1に直接アップロードすることはできませんが、DAC委員会のアクセス権限は、少数の人々が共謀して悪を行うのを防ぐために外部に公開する必要があります。 (DACのいたずらシナリオの議論については、Dankradの以前のTwitterでの声明を参照してください)
**セレスティアが以前に提案したBlobStreamは、本質的に中央集権型DACをセレスティアに置き換えるためのものであり、**イーサリアムL2シーケンサーはDAデータをセレスティアオンチェーンに公開でき、セレスティアノードの2/3が署名した場合、イーサリアムに展開されたレイヤー2専用コントラクトは、シーケンサーがDAデータを正直にリリースすると信じており、実際にはセレスティアノードを保証人として機能させるためです。 Celestiaには何百ものバリデータノードがあることを考えると、この大きなDACは比較的分散化されていると考えることができます。
**Merlinが使用しているDAソリューションは、実際にはCelestiaのBlobStreamに近く、DACのアクセス権をPOSの形で開放し、分散化の傾向にあります。 誰でも十分な資産をステークするのと同じくらいロングのDACノードを実行できます。 Merlinのドキュメントでは、上記のDACノードはOracleと呼ばれ、BTC、MERL、さらにはBRC-20トークンのアセットステーキングがサポートされ、柔軟なステーキングメカニズムとLidoと同様のプロキシステーキングが可能になると指摘されています。 (オラクルマシンのPOSステーク プロトコルは基本的にマーリンの次のコアナラティブの1つであり、提供されるステーク 金利は比較的高いです)
Merlinのワークフローの簡単な説明(下の写真):
オラクルノードZK Proofを検証し、コミットメントコミットメントを生成してビットコイン オンチェーンに送信し、誰でも「コミットメント」に異議を唱えることができるようにするための計算プロセスの特別な処理を行っており、このプロセスのプロセスは基本的にbitVMの詐欺証明 プロトコルと同じです。 チャレンジが成功した場合、コミットメントを公開するOracle ノードに金銭的なペナルティが課せられます。 もちろん、Oracleがビットコイン オンチェーンに公開するデータ(現在のレイヤー2状態(StateRoot)のハッシュやZKP自体など)は、外部が検出できるようにビットコイン オンチェーンに公開する必要があります。
まず、Merlinのロードマップには、将来的にOracleがDAデータをCelestiaにバックアップし、Oracle ノードがローカルの履歴データを適切に削除し、データを永久にローカルに保持する必要がないと記載されています。 同時に、Oracle Networkによって生成されたコミットメントは実際にはメークルツリーのルートであり、ルートを外部に開示するだけでは不十分ですが、コミットメントに対応するすべての完全なデータセットを開示するには、Celestia、EigenDA、またはその他のDAレイヤーであるサードパーティのDAプラットフォームを見つける必要があります。
セキュリティモデル分析: 楽観的な ZKRollup+Cobo の MPC サービス
以上、Merlinのワークフローについて簡単に説明しましたが、その基本構造はすでによく理解していると思います。 Merlinが基本的にB^Square、BitLayer、Citreaと同じセキュリティモデル(楽観的なZK-Rollup)に従っていることは理解に難くありません。
この言葉を最初に読んだとき、多くのロング イーサリアム愛好家は奇妙に感じるかもしれませんが、「楽観的なZKロールアップ」とは何ですか? イーサリアムコミュニティの認識では、ZK Rollupの「理論モデル」は完全に暗号技術計算の信頼性に基づいており、信頼の仮定を導入する必要はなく、楽観主義という言葉は正確に信頼の仮定を導入しているため、人々はロールアップが間違っていず、何度もロングしても信頼できると楽観的であるべきです。 また、エラーが発生すると、ロールアップ演算子は、OPロールアップとしても知られるオプティミスティックロールアップの名前の由来である詐欺証明によって罰せられる可能性があります。
Rollupの本拠地のイーサリアムエコシステムにとって、楽観的なZK-Rollupは少し珍しいかもしれませんが、これはまさに現在のビットコイン レイヤー2状況と一致しています。 技術的な制限により、ビットコイン オンチェーンZKプルーフを完全に検証することはできません、特別な状況下でZKP計算プロセスの特定のステップのみを検証できます、この前提の下で、ビットコイン オンチェーン実際にサポート 詐欺証明 プロトコルすることしかできません、人々はオフチェーン検証プロセスでZKPを指摘することができます、特定の計算ステップにエラーがあり詐欺証明、もちろん、これはイーサリアムスタイルのZKロールアップと比較することはできませんが、ビットコインすでに最も信頼性が高く、 最も堅牢なセキュリティモデル。
上記の楽観的なZK-Rollupスキームでは、レイヤー2ネットワーク内にN個の認可されたチャレンジャーがいると仮定し、これらのN個のチャレンジャーのうちの1つが正直で信頼性が高く、エラーを検出していつでも詐欺証明を開始できるロング、レイヤー2の状態遷移は安全です。 勿論、完成度が比較的高い楽観的なロールアップは、撤退ブリッジも詐欺証明 プロトコルで保護する必要があり、現状では、ほとんどのビットコイン レイヤー2がこの前提を達成できず、ロング署名/MPCに頼る必要があるため、ロング署名/MPCソリューションをどのように選択するかが、レイヤー2のセキュリティに密接に関連する問題になっています。
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ベースの2段階認証ZKP提出スキーム
以前、Merlinのセキュリティモデルをくまなく調べ、楽観的なZKロールアップの概念を紹介しました。 Merlinの技術ロードマップでは、分散化証明者についても議論されています。 ご存知のように、ProverはZK-Rollupアーキテクチャの中核的な役割であり、シーケンサーによってリリースされたバッチのZKProofの生成を担当し、zk-SNARKsの生成プロセスは非常にハードウェアリソースを大量に消費し、非常にトリッキーな問題です。
ZKプルーフの生成を高速化するために、タスクの並列化は最も基本的な操作の1つです。 **いわゆる並列化は、実際にはZKプルーフ生成タスクを異なる部分に分割し、異なるプルーバーによって個別に完了し、最終的にアグリゲーターアグリゲーターが最も長いプルーフを全体に集約することです。
ZKプルーフの生成プロセスを高速化するための注文では、MerlinはLumozのProoverをサービスソリューションとして使用し、実際には多数のハードウェアデバイスを集めてマイニングプールを形成し、POWマイニングと同様に、コンピューティングタスクをさまざまなデバイスに割り当て、対応するインセンティブを割り当てます。
この分散化証明スキームには、一般にフロントランニング攻撃として知られている攻撃シナリオのクラスがあります:アグリゲーターアグリゲーターがZKPを形成し、報酬を受け取ることを期待してZKPを送信するとします。 他のアグリゲーターがZKPのコンテンツを見た後、彼らは急いで彼の前に同じコンテンツを投稿し、このZKPは自分の夫によって作られたと主張しましたが、この状況をどのように解決しますか?
頭に浮かぶかもしれない最も本能的な解決策の1つは、各アグリゲーターに特定のタスク番号を割り当てることです、例えば、アグリゲーターAだけがタスク1を取ることができ、他の全員がタスク1を完了しても報酬を得ることはできません。 しかし、このアプローチの問題の 1 つは、単一のリスク ポイントから保護されないことです。 アグリゲーター A でパフォーマンス障害が発生したり、接続が切断されたりした場合、タスク 1 はスタックし、完了できません。 さらに、タスクを 1 つのエンティティに割り当てるというこの慣行は、競争力のあるインセンティブで生産性を向上させる良い方法ではありません。
Polygon zkEVMはブログ記事で「Proof of efficiency」という手法を提案しており、異なるアグリゲーターをプロモートして互いに競争し、インセンティブは先着順で分配し、チェーンにZK-Proofを最初に提出したアグリゲーターが報酬を受け取ることができると述べています。 もちろん、彼はMEVのフロントランニングの問題を解決する方法については言及しませんでした。
Lumozは2段階検証ZKプルーフ送信方法を使用しており、アグリゲーターがZKプルーフを生成した後、完全なコンテンツを送信する必要はなく、ZKPのハッシュのみを公開、つまりハッシュ(ZKP +アグリゲーターアドレス)を公開します。 このように、他の人がハッシュ値を見ても、対応するZKPコンテンツを知らず、直接急ぐことはできません。
誰かが単にハッシュ全体をコピーして最初に公開した場合、ハッシュには特定のアグリゲーターXのアドレスが含まれており、アグリゲーターAが最初にハッシュを公開した場合でも、ハッシュの元の画像が明らかになると、そこに含まれるアグリゲーターアドレスはAではなくXであることが誰にでもわかります。
この2段階検証ZKP提出スキームを通じて、Merlin(Lumoz)はZKP提出プロセスのフロントランニング問題を解決し、競争力の高いzk-SNARKs生成インセンティブを実現し、それによってZKPの生成速度を向上させることができます。
Merlin's Phantom: 最長チェーンの相互運用性
Merlinの技術ロードマップによると、Merlinと他のEVMチェーン間の相互運用性もサポートし、その実装パスは基本的に以前のZetachainのアイデアと同じであり、Merlinがソースチェーンとして使用され、他のEVMチェーンがターゲットチェーンとして使用される場合、Merlinノードがユーザーによって行われたクロスチェーン相互運用性要求を認識すると、ターゲットオンチェーンで後続のワークフローをトリガーします。
たとえば、Merlin ネットワークによって制御される EOA アカウントを Polygon にデプロイできます。 ユーザーがMerlinチェーンでクロスチェーン相互運用性命令を発行すると、Merlinネットワークは最初にそのコンテンツを解析し、ターゲットオンチェーンで実行されるトランザクションデータを生成し、次にトランザクションのOracle Network MPC署名処理がトランザクションのデジタル署名を生成します。 次に、MerlinのRelayerノードは、Polygonでトランザクションを解放し、ターゲットオンチェーン上のEOAアカウントにあるMerlinの資産を介して後続の操作を完了します。
ユーザーが必要とする操作が完了すると、対応する資産はターゲットオンチェーン上のユーザーのアドレスに直接転送され、理論的にはマーリンチェーンに直接クロスすることもできます。 このソリューションにはいくつかの明らかな利点があります:従来の資産クロスチェーンおよびクロスチェーンブリッジ契約によって発生する手数料の損耗を回避でき、クロスチェーン操作のセキュリティを確保するためにMerlinのOracle Networkによって直接保証され、ロングは外部インフラストラクチャに依存する必要はありません。 ユーザーがMerlin Chainを信頼しているのと同じくらいロングですが、そのようなクロスチェーンの相互運用性をデフォルトにしても問題はありません。
まとめ
この記事では、より多くのロングの人々がMerlinの一般的なワークフローを理解し、そのセキュリティモデルをより明確に理解するのに役立つと考えられているMerlin Chainの一般的な技術的ソリューションについて簡単に説明します。 現在のビットコインの生態学が本格化していることを考えると、この種の技術科学の普及行動は一般の人々にとって価値があり、必要とされていると信じています。 **今後、MerlinやbitLayer、B^Squareなどのプロジェクトについてロングのフォローアップを行い、その技術的ソリューションのより詳細な分析を行いますので、ご期待ください!