安全なクロスチェーン相互運用性のための共有セキュリティの活用

ブロックチェーン ブリッジへの攻撃が数十億ドルの損失につながる中、クロスチェーン セキュリティに関する議論がしばしば激しい論争を巻き起こすのは当然のことです。しかし、私たちはより実用的なアプローチ、つまり、安全な相互運用性の問題を第一原理から分析し、クロスチェーン アプリケーションとそのユーザーの安全性の保証を高めるメカニズムを設計することの重要性を信じています。 この記事では、 の概念について説明し、共有セキュリティ設計 (ラグランジュ状態委員会など) によって相互運用性プロトコルの重要な安全性プロパティのブートストラップ コストを削減できる方法について説明します。クロスチェーン通信プロトコルの共有セキュリティに焦点を当てていますが、ユース ケースに関係なく、分散型アプリケーションであれば、この新しいテクノロジを活用して、過度の運用オーバーヘッドを発生させることなく、十分な分散化と信頼の最小化を実現できます。 共有セキュリティ 共有セキュリティの非公式な紹介 「共有セキュリティ」とは、プロトコルが外部ソースから得るセキュリティを指します。共有セキュリティ スキームでは、1 つのプロトコルの参加者がプールしたリソース (資本や計算能力など) が、別のプロトコルの経済的セキュリティを作成するために使用されます。共有セキュリティは、各ネットワークがセキュリティの責任を負う標準モデルとは異なります。 たとえば、ビットコインやイーサリアムなどのパブリックブロックチェーンは、コンセンサスアルゴリズムとシビル耐性メカニズム（プルーフオブワークやプルーフオブステークなど）を組み合わせて、ライブネスを保証すると同時に敵対的攻撃（ 、 、 攻撃、 、 など）のコストを増大させます。 シビル攻撃 長距離攻撃 エクリプス タイムバンディット攻撃 賄賂攻撃 共有セキュリティ スキームはそれぞれ動作が異なりますが、目標は通常、次の 2 つの目的を中心に展開されます。 追加のリスク（リスクの積み重ね）を発生させたり、追加のセキュリティの仮定を導入したりすることなく、ブロックチェーン ネットワークの資本効率を向上させます。 無効な状態遷移、再編成、検閲耐性、およびプロトコルの活性と安全性に対するその他の攻撃から防御するためのブロックチェーン ネットワーク (特に新しいプロトコル) の能力の向上。 共有セキュリティは、まったく新しい概念ではありません。たとえば、 2011年に導入され、マイナーが同じ暗号化プルーフオブワーク（PoW）を使用して、 を実装する2つ（またはそれ以上）の異なるPoWチェーン上にブロックを作成できるようになりました。これにより、ネイティブトークンがマイナーから大きな関心を引くほどの価値を獲得していなかった新しいPoWベースのプロトコル（NamecoinやRootstockなど）は、ビットコインネットワークのセキュリティ保護専用の計算リソースを再利用して新しいプロトコル上のブロックの難易度を上げることで、セキュリティを共有できるようになりました。 マージマイニングは ナカモトコンセンサス とはいえ、マージマイニングは、説明責任のある安全性が欠如しているため、分散型ネットワークの経済的セキュリティとしては弱い形態であると考えられています。学術文献では、説明責任のある安全性とは、プロトコルのルールに違反する（証明可能な）ノードを検出し、悪意のある行為を罰するプロトコルの能力を反映しています。たとえば、Proof of Stake ベースのプロトコルでは、ノードはコンセンサスに参加する前に担保をロックする（プロトコルのネイティブトークンをステーキングする）必要があり、バリデーターの不正行為の証拠が現れた場合は、この担保を破壊/凍結（「スラッシュ」）できます。 マージマイニングの場合、マージマイニングされたチェーン上の無効なブロックを故意に受け入れるノードを確実に検出することはできません。さらに、そのようなノードを処罰することは不可能です (たとえ特定できたとしても)。そのためには、マイニングハードウェアを燃やしたり破壊したりするといった思い切った手段が必要になるからです。マージマイニングされたチェーンのトークンがセキュリティ攻撃によって価値を失うという脅威は、ビザンチン行為を阻止するのに十分であるように思われますが、元のチェーン (例: ビットコイン) の価値が影響を受ける可能性は低いため、悪意のあるマイナーが失うものは少なくなります。 現代の共有セキュリティの概念は、説明責任のある安全性を組み込むように進化しただけでなく、共有セキュリティの基盤として別の投資単位である資本を使用するようにも変化しました。この設計では、その上に構築された他の PoS プロトコルにセキュリティを提供する基本プロトコルがあります。ノードは、セカンダリ ネットワークのセキュリティ保護に参加する前に、まずプライマリ ネットワークに参加します (ネットワークのネイティブ トークンをステークとしてロックすることにより)。 このデザインはさまざまな形式を取ることができます: バリデータはプライマリネットワークとセカンダリネットワークに 参加します 同時に バリデーターのサブセット（プライマリネットワークから）がランダムにサンプリングされ、セカンダリネットワークを検証して保護します。 セカンダリネットワークは、プライマリネットワークに結合された独立したバリデーターのセットによって保護されています。 プライマリネットワークのバリデーターは、セカンダリネットワークのバリデーターにステークされた資本を再委任する。 実装の詳細にかかわらず、上記の共有セキュリティ スキームの重要な詳細は、ベース プロトコルに、セカンダリ ネットワーク上で悪意を持って行動するバリデーターを処罰する手段がなければならないということです。セカンダリ ネットワークを保護する資本が少ないため、悪意のある多数派がプロトコルを乗っ取る可能性が現実的な懸念事項です。 解決策は、1 人以上の正直な参加者 (少数派) が紛争を開始し、プロトコル違反行為の証拠をベース レイヤーに公開することで、多数派に責任を負わせられるようにすることです。ベース プロトコル (「裁判官」として機能) がその証拠を受け入れた場合、不正な当事者はプライマリ ネットワーク上の担保 (債券として提供) を削減することで罰せられます。重要なのは、ベース レイヤーは紛争を解決する前に、提供された証拠を検証するだけでよく、追加のコンセンサスを実行する必要がないことです。これにより、調整のオーバーヘッドが削減されます。 より微妙な点は、スラッシング メカニズムが効果を発揮するには、不正行為が何らかの当事者に 必要があるということです。PoS ベースのネットワークでは、バリデーターは、コンセンサス プロトコル内で一意の暗号化 ID として機能する公開鍵と秘密鍵のペアを生成する必要があります。ブロックの提案やブロックの有効性の証明などの日常業務では、バリデーターはブロック データに秘密鍵で署名し、事実上その選択に結び付けます。 起因する これにより、プロトコルの安全性や活性（場合によってはその両方）に対する攻撃と解釈されるさまざまなアクションに対してバリデーターを削減することが可能になります。 同じ期間に矛盾する2つのブロックに署名する（正式には「二重表記」と呼ばれる） 無効なブロックに署名する（提案中または認証中） 1つ以上のトランザクションの検閲 ブロックのデータの一部または全部を非表示にする 最初の 2 つの違反は同じ方法 (バリデーターの署名から公開鍵を復元する) で検出できますが、後の 2 つには や などの他のメカニズムが必要です。いずれの場合も、暗号化を使用すると、検閲への耐性やトランザクションの有効性など、プロトコルの特定の望ましいセキュリティ特性を低下させる可能性のある悪意のある動作を確実に検出して処罰することができます。これは、「暗号経済的セキュリティ」の意味に関するコンテキストを提供します。これは、暗号化メカニズムと経済的インセンティブを組み合わせて分散型ネットワークを保護することを意味します。 包含リスト 消去コード この考え方を説明し、マージマイニングと比較するには、Ethereum のセキュリティを共有する新しい PoS ブロックチェーンの例を使用します。このおもちゃのプロトコルには、次の特性があります (説明のために過度に単純化された例を使用していることに注意してください)。 ノードオペレーターは、PoSネットワークのバリデーターとして登録する前に、指定された量のETHトークンをイーサリアムスマートコントラクトの担保として預ける必要があります。 エポック中、PoSプロトコルのブロック提案者は、ブロックヘッダーのハッシュ（バリデーターの署名を含む）をスマートコントラクトに保存してイーサリアムに送信します。 セキュリティは に基づいています。親チェーン（イーサリアム）は状態遷移を検証しませんが、特定の状態遷移が無効であることを示す反例を検証できます。 不正証明 特定の状態遷移が1つ以上の当事者によって争われている場合、オンチェーンスラッシングメカニズムがアクティブになります。 ここで、セカンダリ ネットワーク上の悪意のあるノードの大多数が共謀して無効なブロックを確定し、ブリッジ コントラクトに預けられた資金を盗んだとします。このシナリオでは、正直なバリデーターが不正証明を公開し、プロトコルに違反しているバリデーターを特定することで、Ethereum のオンチェーン スラッシング メカニズムを起動します。プロトコル ルールでバリデーターのステーク全体をスラッシングすることが許可されている場合、PoS チェーンを破損するコストは、バリデーターの大多数がステークした金額に比例します。 この例は、説明責任のある安全性が共有セキュリティ設計の基盤となり、大規模なプロトコルによって小規模なネットワークを効果的に保護し、大幅な経済的安全性を確保し、より高いレベルの分散化と信頼性のなさを誇っていることを示しています。また、Proof-of-Stake メカニズムは、マージマイニング (計算能力を経済的安全性の基盤として使用) と比較して、安全性の概念がより強い共有セキュリティ設計につながることもわかります。 さらに、この論文では、別のネットワークのトークンをステーキングに使用する新しいプロトコルのアイデアを紹介し、「ブートストラッピング問題」（新しいブロックチェーン プロトコルのトークンが十分な価値を獲得していないため、経済的セキュリティが低い）を軽減します。ブートストラッピング問題は、ハードウェア投資を経済的セキュリティの単位として使用するマージ マイニングなどのアプローチで解決できますが、このタイプの共有セキュリティは、特定の理由（そのいくつかは以前に特定した理由）により最適ではありません。 資本投資は、ノードを検証するための悪意のある行為に対して多大なコストを課すはずであり、 あり、経済的セキュリティのために活用することが困難です。PoW マージマイニングの場合、資本投資を明示的にするには、悪意のある行為が行われた可能性がある場合にマイニングハードウェアを破壊するなどの抜本的な対策が必要になりますが、これは現実の世界では非現実的であり、活用することが困難です。 暗黙的で マージマイニング（またはコンセンサスへの参加が実行中のインフラストラクチャに結び付けられている共有セキュリティ設計）は、スケーリングが困難です。たとえば、マイナーの ROI が減少し始める前に、同時にマージマイニングできる PoW チェーンの数には上限があります。 対照的に、投資単位として資本投資を使用する PoS ベースの共有セキュリティ スキームには、新しいネットワークを効率的かつ効果的にブートストラップする問題を解決するのに役立つ特定の特性があります。 資本投資は明示的であり（ステーカーは担保要件を満たすためにトークンの購入に資本を投資します）、経済的安全性の強力で具体的な保証に活用できます。たとえば、0.9 ETH 相当のステークで 1 ETH 相当のトランザクションを保護する場合よりも、1 ETH 相当のステークで 0.9 ETH 相当のトランザクションを保護する場合の方がプロトコルの安全性が高くなることは容易に想像できます。 コンセンサスへの参加は「純粋な」資本投資に結びついているため、経済的セキュリティを拡大し、過度の調整オーバーヘッドを発生させることなくバリデーターが複数のプロトコルを保護できるようにすることが容易になります（特にハードウェア要件が低い場合）。 それでも、すべてのアプローチには欠点があり、ステーキングによるセキュリティ共有も例外ではありません。たとえば、PoS プロトコルにバリデーターがどれだけの担保を入れるべきかを決定することは、解決が難しい問題です。前の段落の次の記述を検討することで、これを文脈に当てはめてみましょう。「 」 1 ETH 相当のステークで 0.9 ETH 相当のトランザクションを保護する方が、0.9 ETH 相当のステークで 1 ETH 相当のトランザクションを保護するよりもプロトコルのセキュリティが高くなる可能性が高いことは容易に想像できます。 この発言は合理的に思えますが、より深い分析をすると、最適な債券要件を選択することが難しいことがわかります。 0.9 ETH 相当の資産を確保するためにバリデーターから 1 ETH を要求すると、資本効率が低下し、過剰担保が発生します。 1 ETH 相当のステークで 2 ETH 相当のトランザクションを保護すると、PoS ブロックチェーンの (または「レバレッジ」) が減少し、担保不足に陥ります。 経済的帯域幅 理想的なシナリオでは、プロトコル設計者は 1 ETH のステークで 1 ETH 相当のトランザクションを確保することを望みます。しかし、さまざまな理由から、現実世界の状況ではそのような均衡を達成するのは困難です。たとえば、単位時間あたりに確保する資本の量 (ブロック/エポックあたりのトランザクションの限界値の関数) は動的です。このため、PoS システムで理想的な結合を設定することは非常に難しいメカニズムの問題であり、ステークベースの共有セキュリティ スキーム (再ステーキングなど) にとって重要な考慮事項となります (次のセクションで説明します)。 再ステーキングとチェックポイントによるセキュリティの共有 再ステーキング 再担保は、従来の金融慣行である に由来しています。再担保とは、貸し手が資産（借り手が以前に担保として提供したもの）を担保として利用し、新しいローンを確保することです。この場合、新しい相手方は元の担保資産に対する権利を引き継ぎ、新しいローンを組んだ主体が返済不能になった場合に、資産を競売にかけて資金を回収することができます。 再担保 再担保は、適切に実施すれば、役に立ちます。まず、休眠状態になる資産を再利用して、利益を生み出す活動のための短期資金を確保することで、資本効率と流動性が向上します。ローンの借り入れによる利益が再担保された担保の価値を超えた場合、関係するすべての当事者 (元の借り手、貸し手、貸し手の貸し手) が利益を得ます。 再担保には多大なリスクが伴います (これが、この慣行が TradFi 機関の間でほとんど好まれなくなった理由の 1 つです)。特に、清算が発生したときに資産に対する権利を失う可能性がある元の借り手にとってはリスクが高くなります。担保を再利用する貸し手もリスクを負いますが、ローンの不履行により新しい相手方が預けた担保を没収した後に借り手に返済する必要がある場合は、さらにリスクが高まります。 もう 1 つのリスクは、以前に簡単に説明したもので、過剰担保と不足担保のトレードオフに関係しています。前に強調した例では、銀行 B (ジョンの銀行) が過剰レバレッジのポジション (ジョンの担保の価値を超える金額を借り入れる) に入り、損失を被ると、銀行 B からのローンの返済 (またはジョンの資産の返却) が困難になります。銀行 B は、銀行 A (ジョンの銀行) にジョンの担保の価値よりも少ない金額を借り入れるように依頼することで、このエッジ ケースから保護できますが、これにより銀行 A の資本の非効率性が高まり、そもそもジョンの担保を再担保することによる利益が減少します。 同じ長所と短所は、再ステーキングにも当てはまります。先に進む前に、重要な詳細を明確にしておくことが重要です。再ステーキング者のステーキングは、常に最初に基本プロトコルを通過します。たとえば、Ethereum の再ステーキング者は、 または のどちらが使用されているかに応じて、32 ETH を Beacon Chain コントラクトに預けるか、ステーキング サービスによって運営されるバリデーターに ETH を委任する必要があります。 ネイティブの再ステーキング リキッド再ステーキング 大まかに言えば、イーサリアムの場合の再ステーキングは次のようになります。 #1: ステークされたETHに対する所有権（または請求権）を再ステーキングプロトコルに付与する ネイティブの再ステーキングでは、バリデーターは、再ステーキング プロトコルによって管理されるスマート コントラクトへの引き出しアドレスを変更する必要があります。したがって、資金がビーコン チェーンを出た後にバリデーターに直接送られるのではなく、ステークはバリデーターに到達する前に、まず再ステーキング プロトコルを通過します (なぜそうなるのかはすぐにわかります)。 ステーキングされた ETH の代替可能な表現 (派生商品) を、再ステーキング プロトコルのスマート コントラクトに預けることもできます (liquid 再ステーキング)。「liquid ステーキング トークン」と呼ばれるこのようなトークンは、ステーキング サービス オペレーター (例: RocketPool、Lido、Coinbase など) によって発行され、バリデーターによってステーキングされた ETH の一部 (報酬からの利回りを含む) に対する権利を表し、ネイティブ ETH トークンと 1:1 の比率で交換できます。 #2: 再ステーキングプロトコルによって強制される追加のスラッシュ条件に同意する 再ステーキング プロトコルは通常、さまざまな分散型ネットワークやアプリケーションが経済的セキュリティのためにプラグインできる「ミドルウェア」として機能します。これらには通常、一連の当事者 (たとえば、オラクル ネットワーク) による何らかの形式の検証を必要とするプロトコルが含まれますが、そのネイティブ トークンは、Proof of Stake 設定で使用するのに十分な価値を蓄積していません。 このようなアプリケーションは、新しいバリデータ セットを一から構築する代わりに、再ステーキング プロトコルを通じて既存のバリデータのサービスを利用できます。サービスは、バリデータの 担保に対して固有の削減条件を指定できます。再ステーキング プロトコルはバリデータの引き出しを制御するため、この条件を強制することができ、経済的安全性の障壁が低くなります。 再担保された 重要な注意: AVS スラッシング条件は、Ethereum の Beacon Chain コンセンサスによって強制されるスラッシング条件とは独立しているため、バリデーターの ETH ステークは、Ethereum 自体でスラッシング可能な違反を犯していなくてもスラッシングされる可能性があります。これは、いわゆる「リスクスタッキング」につながる可能性があります。つまり、資本効率の向上と引き換えに、プライマリネットワークは、そうでない場合よりも追加のリスクを継承します。(リスクスタッキングは、後で説明するように、コア EigenLayer プロトコル自体にも影響を及ぼします。) #3: 追加の報酬を受け取る 再ステーキングには大きなリスクを負う必要があります (例: 再ステーキングされたバリデータは、オンチェーン スラッシング メカニズムのバグにより誤ってスラッシングされる可能性があります)。しかし、再担保によって TradFi の流動性が解放されるのと同様に、再ステーキングによって PoS エコシステムの資本効率が向上し、ステーカーに平均以上の利回りがもたらされます。 これは、セキュリティのために再ステークされた資本を使用したサービスが、そのサービスに対してバリデーターに報酬を支払う必要があるという事実に基づいています。たとえば、オラクル ネットワークに参加している再ステークされたバリデーターは、オラクルの更新を検証するための料金を受け取ります。支払いは、オラクルのサービスに依存する他のサードパーティ アプリケーションから行われます。バリデーターは引き続きビーコン チェーンから報酬を受け取るため、再ステークにより、新しいエコシステムに新しい資本を再配置することなく、複数の PoS プロトコルから収入を得ることができます。 この例では Ethereum の再ステーキングに焦点を当てていますが、他の Proof of Stake プロトコルでも、同様の目的 (新しいプロトコル/アプリケーションの起動コストの削減、資本効率の向上、経済的セキュリティの拡張) を達成するために、再ステーキングのバリエーションが実装されています。実際、次のセクションでは、他のエコシステムでの再ステーキングについて説明する前に、Ethereum の主要な再ステーキング プロトコルである EigenLayer について説明します。 固有レイヤー EigenLayer は、Ethereum の経済的セキュリティを拡張して、新しい分散アプリケーション、ネットワーク、プロトコル (総称して「Actively Validated Services」または略して AVS) を保護するために作成された再ステーキング プロトコルです。Ethereum での再ステーキングの例を説明した前のセクションを読んでいれば、EigenLayer の操作をすでに大まかに理解していることになりますが、コンテキストのためにさらに詳細を説明します。 ETH を再ステーキングした後 (バリデーターに関連付けられた引き出し認証情報を EigenLayer によって制御されるスマート コントラクトにポイントすることにより)、バリデーターは操作する AVS によって指定されたタスクを実行する必要があります。たとえば、AVS がサイドチェーンである場合、再ステーキングされたバリデーターは、サイドチェーンがトランザクションを実行してブロックを検証するためにクライアント ソフトウェアを実行する必要があり、これらのタスクを正しく実行することで報酬を獲得します。より広い意味では、タスクは AVS の性質に応じて異なる場合があります。 ネットワークにデータを保存する データ可用性 クロスチェーンブリッジの入金および出金取引の承認、またはクロスチェーンメッセージングプロトコルのメッセージの承認 プライバシー重視のアプリケーションや保護された支払いネットワークのゼロ知識証明の生成と検証 ブロックヘッダーの保存と検証、およびクロスチェーン相互運用プロトコルのリレーヤー/オラクルの実行 賢明な読者なら、次の 2 つの点に気付くでしょう。(a) AVS によって指定されるタスクは、かなり恣意的である可能性がある (b) AVS で指定されるタスクによって、必要な投資と労力のレベルが異なる。後者の点を説明すると、クロスチェーン プロトコルでブロック ヘッダーを格納すると、データ可用性ネットワークでデータを格納してプロビジョニングする場合と比べて、必要なディスク/メモリ領域が少なくなると考えられます ( などの手法によって、個々のノードのストレージ負荷が軽減される場合でも)。 データ可用性サンプリング これは、EigenLayer が、再ステークされたバリデーターが AVS 指定のタスクの実行を 当事者 (オペレーター) に委任し、その当事者が AVS から獲得した報酬をバリデーターと共有することを許可している理由の 1 つです。このアプローチでは、オペレーターが AVS タスクを正しく実行できなかった場合に発生する可能性のあるスラッシングの負担が、再ステークされたバリデーターとサードパーティのオペレーターの間でどの程度共有されるかに応じて、再ステークされたバリデーターに対するリスクのレベルが異なります。 別の 各 AVS は、EigenLayer 再ステーカーのステークを削減できる一連の条件を指定します。たとえば、Proof of Space/Storage メカニズムを実装するデータ可用性ネットワークは、合意された期間にデータを保存できなかったオペレーターを削減できます。削減により、EigenLayer 内でオペレーターが凍結され、アクティブに検証された 1 つ以上のサービスへのさらなる参加が防止され、最終的にバリデーターの ETH 残高が減少します。 スラッシングが発生するには、違反行為が証明可能でなければなりません。これが、基本プロトコル (この場合は Ethereum) が紛争を裁定し、不正な当事者を罰することを可能にするものです。Ethereum の現在の設計では、バリデーターのステーク (16 ETH) の最大 50% のスラッシングが許可されており、オペレーターがタスクの実行中に AVS で指定されたルールに違反した場合、EigenLayer には残りの 50% (16 ETH) をスラッシングする権利があります。 EigenLayer のスラッシング メカニズムは、再ステーキングの微妙なリスクも示唆しています。1 つのサービスによってスラッシングされると、EigenLayer スマート コントラクトと Ethereum のビーコン チェーンにおけるバリデーターの全体的な残高が減少します。ただし、重要なのは、特定の AVS のスラッシング ロジックのバグが原因でスラッシングが発生し、証明可能な違反の結果ではない場合に、エッジ ケース シナリオが発生することです。この場合、メインの Ethereum チェーンの検証による報酬の損失 (AVS の検証による報酬よりも高いと想定されます) により、バリデーターの観点からは再ステーキングの ROI が最適ではなくなります。 EigenLayer スタイルの再ステーキングに伴うもう 1 つのリスクは、バリデーターの過剰担保と不足担保のリスク、およびリスク スタッキングの概念です。前述の再担保の例から、担保を再担保する当事者は、最初の借り手 (その担保は新しいローンを組むために使用される) とチェーンの最後の貸し手 (元の借り手が差し出した担保に対する請求権を持つ) に同時に負債を負う可能性があることがわかります。 再ステーキングされたバリデーターが（故意にまたは意図的に）イーサリアムのビーコン チェーンと 1 つ以上の AVS に対して同時にスラッシュ可能な違反を犯した場合、EigenLayer のような再ステーキング構造でも同様のダイナミクスが発生する可能性があります。最初のスラッシュが発生する場所によっては、他の AVS にはスラッシュできるステークが残っていない可能性があり、EigenLayer によって保護されているアプリケーションに対するリスクのない攻撃が事実上可能になります。 EigenLayer チームはこの攻撃ベクトルを認識しており ( ペーパーの付録 B: 暗号経済リスク分析を参照)、このリスクに対処するためにいくつかの措置を講じています。これには、AVS におけるステーカーの担保不足と担保過剰を評価するための正式なヒューリスティックの提供や、ローンチ時にリスク管理ダッシュボードを介して AVS 開発者にアドバイス情報を提供する計画の提示などが含まれます。 EigenLayer ホワイト ポルカドットパラチェーン 、異種ブロックチェーン間の相互運用性を実現することで知られていますが、共有セキュリティに大きく依存しています。実際、共有セキュリティのおかげで、Polkadot のエコシステム内のさまざまなチェーンは、信頼の前提を導入したりセキュリティ リスクを負ったりすることなくメッセージを交換できます。 Polkadot は Polkadot では、バリデーターのサブセット (リレー チェーンに DOT トークンをステークしている) がパラチェーン (「子チェーン」と考えてください) にランダムに割り当てられ、各パラチェーンのコレーターによって生成されたブロック (および関連する有効性の証明 (PoV)) を検証します。コレーターは、パラチェーンのトランザクションを実行するノードであり、検証のためにパラチェーンのバリデーター グループに送信される「パラブロック」を作成します。 ブロックの PoV の検証は計算集約的であるため、パラバリデータ (パラチェーンに割り当てられたバリデータの名前) はこの任務に対して追加の報酬を受け取ります。パラバリデータによって承認されたブロック (より正確には、それらのブロックに対する暗号化コミットメント) は、リレー チェーン (「親チェーン」と考えてください) に追加するために送信されます。パラチェーン ブロックは、それを参照するブロックがリレー チェーン上の残りのバリデータ セットの過半数によって承認された場合に最終的なものになります。 最後のポイントは非常に重要です。各パラチェーンのバリデーターの数が少ないため (シャードあたり約 5 つのバリデーター)、個々のシャードを破損するコストは低くなります。このような攻撃から守るために、Polkadot プロトコルでは、パラブロックがランダムに選択された別のノード グループによる二次チェックを受ける必要があります。 ブロックが無効または利用できないことが判明した場合 (つまり、データの一部が欠落している場合)、正直なノードはメインのリレー チェーンで紛争を開始できます。この場合、 リレー チェーン バリデーターは紛争中のブロックを再実行する必要があります。紛争は、バリデーターの 2/3 の過半数が紛争のいずれかの側に投票すると終了し、再実行によってスラッシュの要求が裏付けられると、違反したバリデーターはチェーン上でスラッシュされます。 すべての このメカニズムにより、各シャードに設定されたバリデータのサイズに関係なく、Polkadot プロトコルのすべてのパラチェーンが同じレベルのセキュリティを共有することが保証されます。さらに、パラチェーンは同じソースからセキュリティを導出するため (すべてのパラブロックはリレー チェーンによって承認されます)、リモート シャードから発信されたメッセージの有効性を信頼できます (後者のコンセンサスや状態の詳細を必ずしも知る必要はありません)。 インターチェーンセキュリティ インターチェーン セキュリティは、Cosmos の再ステーキングに対する回答として説明されており、Polkadot の共有セキュリティ モデルと類似しています。Polkadot のリレー チェーンとパラチェーンの関係と同様に、 ハブ アンド スポーク モデルを採用しており、複数のチェーン (「Cosmos Zones」) がメイン チェーン (「Cosmos Hub」) に接続し、そこからセキュリティを引き出します。その原理も Polkadot と似ています。つまり、信頼できるバリデータ セットをゼロからブートストラップする (かなり難しい作業) ことなく、新しいチェーンのセキュリティを維持し、代わりに単一レイヤーにプールされた経済的セキュリティを他のチェーンと共有できるようにするのです。 Cosmos は 現在のイテレーションでは、インターチェーン セキュリティでは、バリデーター (ATOM トークンをステークしている) が Cosmos Hub とそれに接続されているすべてのコンシューマー チェーンの両方を検証する必要があります。コンシューマー チェーンで悪意を持って行動するバリデーターは、プロバイダー チェーン (この場合は Cosmos Hub) でのステークをスラッシングによって失うリスクがあります。 違反しているバリデーターをスラッシングするには、通常、プロバイダ チェーンとコンシューマ チェーン間の IBC (Inter-Blockchain Communication) チャネルを介して、スラッシング可能な動作の証拠を含むパケットを中継する必要があります。したがって、インターチェーン セキュリティは再ステーキングの一形態と見なすことができます。さらに、Cosmos エコシステムでアプリケーション固有のブロックチェーンを簡単に起動できるようにするという重要な目的も達成します。 これまで、主権ブロックチェーンを作成しようとするプロジェクトは、ステーキング用のネイティブ トークンを作成し、十分な数のバリデーターを集めて、新規ユーザーに最低限の安全性を保証する必要がありました。しかし、インターチェーン セキュリティにより、Cosmos Hub のセキュリティ (執筆時点で約 25 億ドルのステーキングで保護) を拡張して、Cosmo の既存のバリデーター セットのサイズを拡大することなく、新しい低価値チェーンを保護できるようになります。 : 。 注 Cosmos の Interchain Security の現在のバージョンでは、コンシューマー チェーンによって中継されるパケットのみに基づくスラッシングが無効になっています。これは、コンシューマー チェーン上の悪意のあるコードが偽のスラッシング パケットの送信をトリガーし、正当なバリデータをスラッシングするリスクがあるためです。代わりに、二重投票 (同じ高さの 2 つのブロックに署名する) などの違反は、ガバナンスによるソーシャル スラッシングの対象となります。ただし、ソーシャル スラッシングには独自のリスクが伴います。これは、 に見られます (これは、共有セキュリティ プロトコルを構築する際の複雑さの一部も示唆しています) コンシューマー チェーンでの二重署名に対するバリデータをスラッシングすることに関する最近の議論 、インターチェーン セキュリティの代替手段であり、インターチェーン セキュリティの欠点のいくつかを改善することを目的としています。プロバイダー チェーンとコンシューマー チェーンの両方でソフトウェアを実行する代わりに、プロバイダー チェーンにステークされたバリデータは、コンシューマー チェーンのバリデータにステークを委任できます。これにより、ガバナンスとコンセンサスに参加して 2 つのチェーンを同時に検証する負担が軽減され、再ステークされたバリデータのオーバーヘッドが削減されます (例: ハードウェア要件の削減)。 メッシュ セキュリティは EigenLayer (Ethereum バリデーターがオペレーターに 1 つ以上のセカンダリ プロトコル (AVS) を代理で検証させる) と同様に、 コンシューマー チェーンを検証するためにステークを行う必要はありません。デリゲート バリデーターが職務を正しく遂行できなかった場合 (ダウンタイムが発生したり、無効なブロックを作成/投票したりした場合など)、 プロトコルのルールに従ってコンシューマー チェーンから排除されます。 デリゲート バリデーターは デリゲートは メッシュ セキュリティは、コンシューマー チェーンが複数のプロバイダー チェーンからセキュリティをリースできる (Cosmos Hub に制限されるのではなく) ことと、バリデーターがステークを委任するチェーンを選択できるという点で、インターチェーン セキュリティとは異なります。後者の機能は ICS v2 ロールアウトの一部として計画されていますが、前者は実装される可能性は低いです (ただし、より説得力があると言えます)。 イーサリアムの同期委員会 Ethereum の 最終的なビーコン ブロック ヘッダーを承認する責任を負う 512 人のバリデーターのグループです。新しい同期委員会は 256 エポック (約 27 時間) ごとに再構成され、メンバーはビーコン チェーンの既存のバリデーター セットから選出されます。メンバーは同期委員会に参加している間も、通常のバリデーターの職務 (認証およびブロック提案を含む) を継続することが求められます。 同期委員会は、 同期委員会は、ビーコン チェーンの Altair フォーク中に初めて実装され、軽量クライアントが新しいブロックを検証 (完全なバリデータ セットを知らなくても) し、Ethereum の状態の変更を追跡できるようにしました。同期委員会に参加するには、ビーコン チェーンのコンセンサスに参加するだけよりも多くの労力が必要なため、メンバーは (ビーコン チェーンの義務を完了したことに対する通常の報酬に加えて) 少額の報酬を受け取ります。 ただし、無効なブロック ヘッダーにサインオフしたメンバーは、ビーコン チェーンとは異なり、スラッシングの対象にはなりません。Ethereum のコア開発者は、悪意のある同期委員会メンバーをスラッシングすると複雑さが増すと述べてこの設計を擁護しましたが、同期委員会メンバーの 2/3 超多数による共謀の難しさ (ライト クライアントを騙して不正なブロック ヘッダーを受け入れさせるのに必要なこと) を示唆する人もいます。 しかし、クロスチェーン通信プロトコルなどの高価値アプリケーションでは、軽量クライアントに依存してイーサリアムの状態を追跡するため、無効なブロック ヘッダーに署名する同期委員会のスラッシングという話題が新たな関心を集めています ( を参照)。スラッシングが実装されると、同期委員会への参加が再ステーキングの形式に変わり、バリデーターは追加のスラッシング条件を選択し、ブロック ヘッダーに署名するという二次的なサービスに対して追加の報酬を受け取ることになります。 Nimbus クライアント チームによる進行中の提案 たとえば、同期委員会にいる間にプロトコル ルールに違反した場合、たとえビーコン チェーンのコンセンサスに参加している間は正直に行動していたとしても、バリデーターは最大残高まで削減される可能性があります。同期委員会は、Polkadot のパラチェーン システムや、大規模なブロックチェーン ネットワーク内のサブプロトコルを検証するためにノードのサブセットをランダムにサンプリングするその他の共有セキュリティ形式 (Lagrange State Committees、Avalanche のサブネット、Algorand の State Proofs プロトコルなど) と比較することもできます。 チェックポイント チェックポイントに基づく共有セキュリティ スキームでは、 一定間隔で、 に最新の状態に対する暗号化コミットメントを投稿することがよくあります。たとえば、ブロック提案者は、ブロックが確定する前に、最新のブロック ヘッダーのハッシュを親チェーンに投稿する必要がある場合があります。 セキュリティを消費するチェーンが、 セキュリティを提供するチェーン これらのコミットメントは、親チェーンがその時点までの子チェーンの履歴の不可逆性を保証するため、「チェックポイント」と呼ばれます。言い換えると、親チェーンは子チェーンの (標準的な) 時間順序を保証および強制し、ブロックの再編成や競合するフォークの作成 (古いトランザクションを元に戻して二重支払いを実行するなど) の試みから子チェーンを保護します。 親チェーンは、特にブロック ヘッダーに特定のブロックを誰が証明/生成したかに関する情報が含まれている場合、子チェーンの有効性を保証することもできます。ブロックが無効であることが判明した場合、正直なノードは親チェーンでチャレンジを開始し (親チェーンが紛争を仲裁します)、子チェーンの状態のロールバックをトリガーできます。 また、バリデーターのステークを管理するメカニズム (スマート コントラクトなど) が親チェーンに実装されている場合、不正の有効な証明がチェーン上で受け入れられた後、プロトコルに違反するバリデーターを削減することで、説明責任のある安全性を強制することが可能になります。親チェーンが子チェーンの正規の履歴を保証することは、ノードが履歴を書き換えて (ブロックを削除して) 悪意のある動作の証拠を隠すことを防ぐため、ここで重要です。 コミット サイドチェーン (Polygon PoS)、オプティミアム (Arbitrum Nova/Metis)、ロールアップ、 などのチェックポイント プロトコルと統合されたチェーンは、この形式の共有セキュリティを実装します。いずれの場合も、プロトコルは外部ブロックチェーン チェーンを決済レイヤー (ブロックのファイナライズを担当) として使用することで、外部ブロックチェーン チェーンから経済的セキュリティを取得します。コンテキストとして、Polygon PoS と Arbitrum Nova/Metis はヘッダーを Ethereum のオンチェーン コントラクトに保存しますが、Babylon は接続された Cosmos Zones から Bitcoin にヘッダーをストリーミングします。 Babylon 同様のメカニズム (ブロック ルートをレイヤー 1 ブロックチェーンに投稿) を利用しますが、重要な違いがあります。ロールアップのブロックを再作成するために必要なデータも決済レイヤーで公開されます。つまり、決済レイヤーはロールアップのセキュリティを (最終的には) 完全に保証します。対照的に、コミット サイドチェーンまたは楽観的チェーンの状態を再構築するために必要なデータは、特に悪意のあるシーケンサーまたはバリデータ セットがデータ保留攻撃を実行している場合は、利用できない可能性があります。 レイヤー 2 (L2) ロールアップは、 クロスチェーン相互運用プロトコルの共有セキュリティ 共有セキュリティの意味と進化について広範な背景情報を提供したので、共有セキュリティ設計の新たな領域を掘り下げていきます。そのような研究領域の 1 つが です。これは、プールされた (経済的な) セキュリティの利点を活用して、ブロックチェーン間のメッセージングとブリッジングに対する現在のアプローチを強化することを目指しています。 、クロスチェーン プロトコルの共有セキュリティ この定義により、読者の心に次のような疑問が浮かぶかもしれません。 相互運用性プロトコルに明確に焦点を当てるのはなぜですか? 相互運用性プロトコルは、共有セキュリティ テクノロジと統合することでどのような利点が得られますか? Lagrange Labs は、クロスチェーン状態の信頼度が最小化された証明へのアクセスを必要とするプロトコル用の共有セキュリティ ソリューションである 構築しています。(State Committees は、Lagrange の 証明システムと EigenLayer の再ステーキング インフラストラクチャを組み合わせて、クロスチェーン相互運用性プロトコル用の共有セキュリティ ゾーンを作成します。) そのため、これまでの質問のそれぞれを分析し、その過程で、ブリッジング、インデックス作成、およびメッセージング アプリケーションを State Committee インフラストラクチャと統合することの必要性を主張する必要があると感じています。 Lagrange State Committees を ZK Big Data 相互運用性プロトコルの簡単な入門 では、サイロ化されたブロックチェーンを接続し、ブロックチェーン アプリケーション (およびそのユーザー) の流動性と状態の断片化に関する問題を軽減するには、相互運用性プロトコルが重要であることを説明しました。その記事で言及されている重要な例には次のものがあります。 「モジュラー ブロックチェーンの相互運用性: ラグランジュのテーゼ」 ロックアンドミントまたはバーンアンドミントのメカニズムを実装し、ネイティブブロックチェーン（発行元）から非ネイティブブロックチェーンで使用するために資産を転送することを許可するブリッジ 単一の真実のソースを共有せず、互いの状態を検証できないブロックチェーン間で、ユーザーが安全に情報を中継（データパケット経由）できるようにするメッセージングプロトコル また、さまざまな種類の の価値も強調しました。たとえば、ブリッジを使用すると、ユーザーは異なるエコシステム間をシームレスに移動し、より多くのアプリケーションにアクセスし、資産の効率を高めることができます（他のブロックチェーンに存在する収益創出の機会を利用することにより）。メッセージングプロトコルは、さまざまなドメイン間での情報（ポジションや負債プロファイルなど）の転送に依存するクロスチェーンレンディング、クロスチェーンアービトラージ、クロスチェーンおよびクロスチェーンマージンなどのより高度なユースケースも可能にします。 ブロックチェーン相互運用性ソリューション さまざまな相互運用性ソリューションはそれぞれ異なる目的で設計されていますが、基本的な特性は共通しています。最も重要なのは、クロスチェーン トランザクション/操作に関係するブロックチェーンに関する情報 (ユーザーまたはアプリケーションによって提供される) が正しいかどうかを検証するメカニズムです。これは通常、特定の状態 (スマート コントラクトのストレージに保存されている値、アカウントの残高、または最後に確定したブロックなど) が存在する、または別のチェーンでトランザクションが発生したという主張です。 Ethereum と NEAR 間のブリッジを例に挙げると、ブリッジのオペレーターは、ユーザーが資産 (DAI など) をブリッジするときに、各チェーンの状態に関する次の情報を検証する必要があります。 ユーザーのNEARアドレスにnearDAIトークンを発行する前に、ブリッジオペレーターは、そのユーザーがEthereum上のブリッジの契約にDAIを預けたことを証明する必要がある。 元のDAIデポジットをリリースする前に（NEARからEthereumにブリッジする場合）、ブリッジオペレーターは、そのユーザーがNEARでnearDAIトークンをバーンし、必要な「バーン証明」の領収書をNEARのブリッジの契約に送信したことの証明が必要です。 前述のチェーン間のメッセージング プロトコルには、類似していますが、わずかに異なる要件があります。Ethereum ユーザーがクロスチェーン トランザクションの実行を要求した場合 (「NEAR で X コントラクトを呼び出す」)、プロトコルは、メッセージ要求が元々 Ethereum 上に配置されていることを確認する必要があります (通常はオンチェーン コントラクトを呼び出すことによって)。 クロスチェーン トランザクションに関するクレームを検証する簡単な方法は、問題のチェーンのフル ノードを実行することです。各ブロックからトランザクションをダウンロードし、チェーンの最新の状態を同期する前に再実行するフル ノードは、通常、どのブロックチェーンでも状態遷移を検証する最も信頼性の低い方法です。ただし、フル ノードを実行するのは困難であり、不必要です。困難であるのは、フル ノードに高いハードウェア要件が必要であるためです。また、クロスチェーン プロトコルには、トランザクションと契約の一部のセットに関連する情報のみが必要であるため、不必要です。 幸いなことに、 フル ノードの実行を必要とせずに、イベントや状態の変化を追跡する簡単で効果的な方法を提供します。ライト クライアントの設計を信頼できれば、ブロック ヘッダーをダウンロードするだけで、ブリッジでの入金/出金の発生やメッセージング プロトコルでのメッセージ要求/実行のステータスなどの特定の情報を確認できます。 ライト クライアントは、 2 つのチェーン (チェーン A とチェーン B と呼ぶ) 間の通信を可能にするために、相互運用性プロトコルはチェーン B のブロック ヘッダーを保存するチェーン B 上でチェーン A の軽量クライアントを実行します (逆も同様)。これにより、ユーザー (またはサードパーティ) によってソース チェーン上のアプリケーションから宛先チェーン上の別のアプリケーションに渡される状態/ストレージのさまざまな証明 (ブロック ヘッダー、Merkle 証明など) を検証できます。軽量クライアントは、次の図に示すように、2 つのブロックチェーンの状態に関する情報のソース (「オラクル」) として機能します。 しかし、クロスチェーン状態の有効性を検証するこのアプローチは、信頼の問題に直面します。Vitalik Buterin 氏の記事「 では、信頼の簡潔な定義が提供されています。「 」この記事では、信頼性の欠如の概念も定義されています (ただし、注意が必要です)。 信頼モデル」 信頼とは、他の人の行動に関する仮定を使用することです。 多くのブロックチェーン アプリケーションで最も価値のある特性の 1 つは、トラストレスです。これは、特定のアクターが特定の方法で行動することに依存することなく、アプリケーションが期待どおりに動作し続ける能力です。たとえ、そのアクターの関心が変化し、将来的に予期しない方法で行動するよう促される可能性があったとしてもです。ブロックチェーン アプリケーションは完全にトラストレスになることはありませんが、一部のアプリケーションは他のアプリケーションよりもトラストレスに近いです。— Vitalik Buterin 私たちのコンテキスト (ブロックチェーンの相互運用性) では、2 つ以上のチェーンの状態が互いに独立して検証される場合、信頼は不可欠になります。チェーン A 上のボブのアプリケーションが、アリスがメッセージを開始したことの証明 (「チェーン B で 5 ETH をロックし、チェーン A で 5 Wrapped ETH (WETH) を発行する」) を受信するシナリオを考えてみましょう。メッセージの証明は、アリスのトランザクションがブロックに含まれていることを示す であり、ボブはチェーン B のオンチェーン ライト クライアントを実行しているため、有効なチェーン B ブロックのヘッダーから派生したトランザクションのマークル ルートと証明を比較することでこれを検証できます。 マークル証明 ただし、ブロックのコンテキストにおける「有効」は、次のようなさまざまな意味を持つ場合があります。(a)「ブロック ヘッダーは、ソース チェーンのバリデーターの過半数によって承認されたブロックに属します。」 (b)「ブロック ヘッダーは、ソース チェーンのトランザクション有効性ルールに従ってトランザクションが有効であるブロックに属します。」 ボブは #1 をブロックの有効性の具体的な証明として扱うことができますが、これはソース チェーン上のバリデータに関する仮定に基づいています。 「 」 チェーン A のバリデーターの大多数は正直であり、1 つ以上の無効なトランザクションを含むブロックを承認しません。 「 」 チェーン A のバリデーターの大多数は経済的に合理的な行動者であり、無効なトランザクションを含むブロックを承認するインセンティブは低い。 ここで、これらの仮定のいずれか (または両方) がどこで崩れるかは簡単にわかります。たとえば、 (たとえば、不正なトランザクションによってブリッジから盗まれる可能性のある量) の場合、攻撃による利益がコストを上回るため、バリデーターは無効なブロックを確定するインセンティブを持ちます。たとえそれがスラッシュを意味するとしてもです。 ステークの量 < チェーン A のトランザクションの価値 一般に、クロスチェーン状態を検証するためのすべてのメカニズムは、信頼の仮定に従います (これらの信頼の仮定のいくつかについては、後で詳しく説明します)。主な目的は、クロスチェーン通信の信頼を、相互運用性に重点を置いたアプリケーションにとってさまざまな信頼の仮定が大きなセキュリティ リスクをもたらさないレベルまで最小限に抑えることです (これはこの記事全体で繰り返されるテーマです)。 これは重要な目標です。なぜなら、異なるブロックチェーンをリンクするための相互運用性プロトコルを構築し、境界の片側で実行されているアプリケーションが、もう片側で何らかの任意のイベントが発生したという誤った主張を受け入れると、悪いこと、本当に悪いことが起こる可能性があるからです。たとえば、バグによって、抜け目のないハッカーが 、ソースチェーンに担保を預けることなく宛先チェーンでトークンを発行できたために、ブリッジエクスプロイトが発生しました。 存在しないメッセージ要求の（偽の）証明を転送し 既存のクロスチェーンセキュリティメカニズムの分析 それ以来、プロトコル設計者は、クロスチェーン通信における情報の検証の問題に対する解決策を考案してきました。最も一般的なのは、クロスチェーン トランザクションの存在/有効性を検証するために第三者を使用することです。理論的根拠は単純です。チェーン A 上のアプリケーションはチェーン B の状態を検証できない可能性がありますが、(何らかのメカニズムを通じて信頼または正直であると期待される) 人々のグループがチェーン B の状態を参照する情報 (またはクレーム) を検証したことを検証できます。 これは「外部検証」と呼ばれます。ブロックチェーンの 別の当事者がオンチェーン イベントの真実のソースとして機能し、（通常は）ソース チェーンのブロック ヘッダーに署名を実行する 1 人以上の検証者が関与するためです。宛先チェーン上のアプリケーションがこの署名済みヘッダーを受信すると、ユーザーが提供するさまざまな状態証明（残高、イベント、入出金など）をそれに対して検証できます。 外部の ある程度のフォールト トレランスを確立するために、一部の相互運用性プロトコルでは、署名の有効性を証明するために最小限の数の秘密鍵を必要とするしきい値署名方式を使用しています (マルチ署名ウォレットやマルチパーティ (MPC) ウォレットが一般的な例です)。ただし、複数 ( の ) の検証者がクロスチェーン状態を証明することは、特に検証者の数が少ない場合は、セキュリティの万能薬とは言えません。 n k たとえば、誰かがマルチシグ方式で十分な数の署名者を危険にさらし、クロスチェーン ブリッジからの不正な引き出しを承認する可能性があります。MPC 設定は若干安全ですが (承認しきい値を変更でき、キーシェアをより頻繁にローテーションできます)、依然として攻撃を受けやすい状態です (特に、一方の当事者がキーシェアの過半数を制御する場合)。 ステーキング 相互運用性プロトコルの信頼の前提を減らし、クロスチェーン通信の安全性を高める方法の 1 つは、検証義務を引き受ける前に、外部の検証者に担保を債券としてステークさせることです。ステークにより、特に検証ノードが無効なブロック ヘッダーに署名を実行したり、無効なクロスチェーン トランザクションを承認したりした場合に、担保が削減される可能性があるため、外部で検証されたシステムのセキュリティが確保されます。 しかし、このアプローチでも、ステーキングが許可制か許可なしかによって問題が生じます。許可制システム（バリデーターをホワイトリストに登録する必要がある）は、多くの場合、事前に承認された少数のエンティティに制限されており、開発が容易です。特にバリデーターが公に知られており、評判を維持するために誠実に行動するインセンティブがある場合は、大規模なインセンティブ設計に投資する必要はありません。また、合意に達するために必要なコミュニケーションが、すでにお互いを知っている少数の当事者間で行われるため、効率的です。 もちろん、参加者が識別可能な許可制システムでは、敵対的攻撃の扉が開かれます。たとえば、攻撃者はこれらのバリデーターの一部になりすましたり、賄賂を渡したりして、過半数のコントロールを奪取する可能性があります。さらに悪いことに、バリデータが実際にはステークされていない（単に任命されている）Proof of Authority（PoA）システムでは、システム攻撃のコストがゼロになります（たとえば、攻撃者はソーシャルエンジニアリングスキームを通じてPoAバリデーターを侵害し、システムをハイジャックするだけです）。 許可のないステーキング システムでは、適切な資本を持つあらゆる関係者がクロスチェーン操作の検証を開始できるため、システムを破損するコストが増加します。ブロック ヘッダーの証明に 2/3 以上の多数を必要とするコンセンサス プロトコルと組み合わせると、システムを破損するコストは、システム内の検証者の過半数を破損するために必要な最小額と実質的に等しくなります。さらに、ユーザーの信頼の前提が少なくなり (検証者を削減できます)、動的な検証者セットにより、ソーシャル エンジニアリングなどの手法で特定のノードを侵害することが難しくなります。 何が問題になるのでしょうか? 実際には、多くの問題があります。まず、システムを保護するためのステークの量は、セキュリティ インシデント (相互運用性プロトコルの安全性または活性の低下) が発生した場合にリスクにさらされる資産の合計価値と同等かそれ以上である必要があります。逆の場合 ( )、システムを破損することによる利益が破損のコストを上回るため、スラッシングの脅威でさえセキュリティを保証する効果がなくなります。 システムを保護するためのステークの合計 < リスクにさらされる合計価値 さらに、前述のセキュリティ特性を実装しようとすると、将来のバリデーターに対してより高いステーク要件を設定する必要がある可能性があります。これにより、セキュリティはバリデーターノードが次の 2 つのことを実行することに依存するため、資本の非効率性の問題が発生します。 検証業務に参加する前に、多額の資金を前払い（ステークとして）預ける 長期間にわたってお金を使わないままにしておくこと（安全のため、PoSプロトコルは引き出しに長い遅延（数週間または数か月に及ぶ場合もあります）を課し、バリデータがスラッシュ可能な違反を犯し、スラッシュによる資金の損失を避けるためにすぐに引き出しを試みるという極端なケースを防止します） 言及していないもう 1 つの点は、不正行為を阻止し、プロトコルのトークンの複雑なステーキング機能を設計するための暗号経済的インセンティブについて検討しなければならない開発者の負担です。製品開発やコミュニティの関与など、より重要な活動への注意をそらすだけでなく、相互運用性インフラストラクチャを構築するチームの開発サイクルの複雑さと認知的オーバーヘッドも増加します。 楽観的な検証 「楽観的検証」は、クロスチェーン セキュリティの問題に対する別のアプローチです。信頼できる当事者またはグループにクロスチェーンの状態の証明を依頼するのではなく、 証明できるようにします。重要なのは、クライアント相互運用性アプリケーション (通常は「リレー」と呼ばれます) に対してクロスチェーンの状態に関する主張を行う当事者は、証明された状態が有効であることの証明を提供する必要がないことです。これは、リレーが誠実に行動し、クロスチェーンの状態について有効な主張のみを行うという「楽観的」な仮定から来ています。 誰でも しかし、もちろん、1 人か 2 人 (またはそれ以上) のリレーヤーが不正行為をすることは十分に予想されます。そのため、楽観的に検証されたシステムでは、リレーヤーが状態証明を提出する前に少額の保証金を預ける必要があります。トランザクション (リレーヤーによって報告されたクロスチェーン状態を参照するトランザクション) の実行も、システムを監視しているすべての人に、 期間内に無効なクレームに異議を申し立てる十分な時間を与えるために遅延されます。リレーヤーのクレームが無効であることが判明した場合、預けられた保証金は削減され、その一部がチャレンジャーに渡されます。 チャレンジ 楽観的検証は、多数 ( ) または多数 ( ) の検証者を信頼しなければならないという問題を、1 人の検証者 ( ) が正直に行動することを信頼するという問題に変えます。楽観的に検証されたプロトコルが安全であるためには、遅延期間内に不正なトランザクションに異議を唱えるための を作成し、トランザクションを再実行するための十分な状態データを持つ 1 人のアクターがいれば十分です (したがって、 セキュリティ仮定)。 n のうち k n のうち m n のうち 1 人 不正証明 1 of n これにより、システムは単一のリレーで正しく動作できるため、オーバーヘッドが削減されます (ただし、ライブ性を確保するには 2 つ以上必要になる場合があります)。また、セキュリティに必要なステークの量も削減され、ステークのアンボンディング時間をより速く設定できるようになります (遅延期間が経過すると、ボンディングされた担保を引き出すことができます)。 さらに、楽観的検証に基づく相互運用性プロトコルは、「基盤となるブロックチェーンのセキュリティを継承する」と説明されています。これは、基盤となるブロックチェーンが稼働しており、不正の証拠を検閲していない場合、悪意のある中継者は不正行為を逃れることができないという考えに基づいています。さらに、プロトコルを攻撃するには、ブロックチェーン自体を攻撃する必要があります。これは、長期間にわたって取引を検閲するには、ネットワーク内のノードの過半数、さらにはステーク/マイニングパワーを制御する必要があるためです。 しかし、楽観的検証にも固有の欠点があります。たとえば、ブリッジング トランザクションまたはメッセージ リクエストの確定と実行に遅延を課すと、レイテンシが増加し、全体的なユーザー エクスペリエンスが低下します。このタイプのクロスチェーン セキュリティには、セキュリティに影響を与える微妙な「落とし穴」もいくつかあります。たとえば、悪意のある当事者が トランザクションに異議を唱えて正直なリレーヤーを「困らせ」、ある種の DDoS 攻撃を実行する可能性があります。 有効な 不正証明は本質的に（ほとんど）インタラクティブであるため、無効なチャレンジは正直な中継者にリソース（オンチェーントランザクションのガス料金に費やされた資金を含む）を無駄にする原因となります。その結果、正直な中継者はクロスチェーン情報を中継するインセンティブを失い、 中継者にクロスチェーン情報を中継する機会を与える可能性があります。チャレンジャーに最低入金額を要求すると、荒らし行為を抑止できますが、最低入金額が高すぎると、 ウォッチャー（資金がない）が無効な状態更新にチャレンジする意欲をなくす可能性があります。 不正な 正直な 一部のプロトコルでは、チャレンジを許可された監視者グループに制限することでこの問題を回避していますが、そうすると、システムのセキュリティを確保するために少数の (信頼できる) 参加者がいるという当初の問題に戻ってしまいます。このアプローチでは、監視ノード間の共謀の障壁が減り、攻撃者がシステムを監視しているノードの大部分を破壊できる可能性が高まるなど、いくつかの意図しない結果が生じる可能性もあります。 暗号検証 ここで検討するクロスチェーン相互運用性プロトコルのセキュリティ保護の最後のアプローチは、暗号証明の領域から来ています。アイデアはシンプルです。クロスチェーンの状態を検証するために人間を信頼する代わりに (前のセクションで特定のケースでは危険であることが示されました)、暗号検証メカニズムを使用して、信頼の前提を最小限に抑えることができます。 ここでは、1 人以上のアクターが、相互運用性アプリケーション内で使用するチェーンの (有効な) 状態の 証明を生成します。これらの証明は であり、ブロック ヘッダーから導出されたものなど、チェーン間の状態の暗号証明を取得し、その有効性を確認できます。また、これらは もあります。単一の当事者によって生成された証明は、通信相手なしで の異なる当事者によって検証できます (対話型不正証明とは異なります)。このように設計された相互運用性プロトコルは、基盤となる証明システムが健全である限り、信頼の前提が最も低いことがよくあります (つまり、敵対者は、無視できる可能性を除いて、無効な主張に対して有効な証明を作成できません)。 SNARK (簡潔な非対話型知識論証) 検証可能 非対話型で n つ このようなプロトコルは、特に暗号証明によって各ブロックがチェーンのコンセンサス プロトコルに従って正しいことが検証される場合、外部検証システムとも異なります。そのため、クロスチェーン状態の暗号証明を使用して相互運用性プロトコルを破壊するには、攻撃者がソース チェーンのバリデータ セットの過半数 (無効なブロックを確定するために必要なもの) を制御する必要があります。 このアプローチにより、前述のクロスチェーン セキュリティ メカニズムに関連するいくつかの欠点がどのように解消されるかが簡単にわかります。 : zkSNARK を使用してクロスチェーンの状態を検証すると、ステーキング/ボンディング メカニズムの必要性がなくなり、トークンをロックアップ期間にさらすことによる非効率性がなくなります。同様に、リレーヤーは、クロスチェーン トランザクションに関するクレームを行う前にボンドを預ける必要がありません (楽観的検証とは異なります)。これは、付随する証明によってクレームが 検証されるためです。 資本の非効率性ゼロ 簡潔に : 遅延期間を実装する必要がなく、タイムリーな不正証明を可能にするため、相互運用性プロトコルは、それを保護する SNARK 証明が検証されると、クロスチェーン メッセージまたはブリッジ操作を実行できます。ただし、証明の生成は通常、計算集約型であるため、外部で検証されたシステムは、SNARK ベースの相互運用性プロトコルと比較して、より効率的である可能性があります。 低レイテンシ 「暗号的に検証された」相互運用性ソリューションのセキュリティを評価する際には、クロスチェーンの状態に関するどのような情報が実際に証明され、検証されているかを詳しく調べることが重要です。ゼロ知識証明は、プロトコルの根底にある実際の信頼の前提を難読化するために、多くのプロトコルが注目する流行語になっています。 たとえば、zkSNARK 回路で Ethereum バリデータ セット ( ) 全体の署名をすべて検証するのはコストがかかる可能性があるため、一部のプロトコルではこれまで、Ethereum の状態の証明を導出する他の手段を採用してきました。一例として、「 」ブリッジ (X は任意のブロックチェーン) が挙げられます。このブリッジは、ブロック ヘッダーが Ethereum の同期委員会 (前に紹介しました) の過半数によって署名されたことの証明を生成します。 現在の数字では 925,000 を超えるバリデータ Ethereum to X これは、ブロックを証明した何千ものバリデータの公開鍵を検証するよりも、より実現可能なアプローチです。しかし、前述のように、Sync Committee のバリデータは、誤ったブロック ヘッダーに署名しても削減されません。そのため、Sync Committee メンバーの過半数が共謀したり、賄賂を受け取ったりしてライト クライアントを欺き、Sync Committee の情報に依存するブリッジ/メッセージング プロトコルのセキュリティを事実上危険にさらす可能性が無視できません。 さらに、 で説明したように、悪意のある同期委員会が削減される可能性がある理想的な世界では、経済的安全性は削減可能な最大額に制限されると説明しました。文脈のために、その投稿からの抜粋をいくつか示します。 ラグランジュ状態委員会を紹介した元の記事 ライト クライアント ブリッジ、ZK ブリッジ、同期委員会証明のセキュリティはすべて、イーサリアム ライト クライアント同期委員会の署名の検証に基づいています。同期委員会のサイズは固定されているため、それを支える経済的セキュリティも 27 時間の枠に制限されます。イーサリアム同期委員会に最終的にスラッシングが実装されると、経済的セキュリティは次のように制限されます。 Sync Committeeの経済的安全性 = 512ノード * 32 Eth * $1650 USD/ETH = $27,033,600 同期委員会を妥協するための閾値 = $27,033,600 * 2/3 = $18,022,400 ライト クライアント ブリッジと ZK ライト クライアント ブリッジは、チェーン間の相互運用性のゴールド スタンダードと考えられていますが、ランダム同期委員会で保護できる資産の量は厳しく制限されています。前述のように、共謀ノードがすべての Ethereum ライト クライアント ブリッジと ZK ライト クライアント ブリッジを同時に侵害するために燃やさなければならない担保の量は、1,800 万ドルに制限されています。 すべてのライト クライアント ブリッジと ZK ライト クライアント ブリッジによって保護されているすべての資産の価値の合計が k である状況を考えてみましょう。k 2,700 万ドルになると、同期委員会の悪意のある行為者のグループが悪意のあるブロックを証明して保護されている資産を危険にさらすことが利益になります。 クロスチェーン状態の証明を導き出すためにランダム同期委員会に依存することに関する問題についての詳細な背景を知るために、記事全体、特に Ethereum の の制限に関するセクションを読むことをお勧めします。また、 Polyhedra Network の取り組みに従うこともお勧めします。 軽量クライアント ブリッジ ZK 回路で完全な Ethereum PoS コンセンサスを証明する ラグランジュ状態委員会: クロスチェーン通信プロトコルのための共有セキュリティ・アズ・ア・サービス この記事の導入の大部分は共有セキュリティについて触れているため、Lagrange Labs で取り組んでいる共有セキュリティ ソリューションである を紹介するのは当然のことです。このセクションでは、Lagrange State Committee ネットワークの内部の仕組みを探り、Lagrange の ZK Big Data スタックとのつながりと、チェーン上およびチェーン間で安全かつ 状態アクセスを可能にするツールを構築するという目標を理解します。 Lagrange State Committees 表現力豊かな ラグランジュ状態委員会とは何ですか? Lagrange State Committee (LSC) ネットワークは、Ethereum で動作する楽観的ロールアップ (ORU) (Optimism、Arbitrum、Base、Mantle など) 用のシンプルで効率的な ZK 軽量クライアント プロトコルです。LSC は概念的には Ethereum の Sync Committee に似ており、過度の信頼仮定をせずに楽観的ロールアップの状態を使用したいブリッジやチェーン間メッセージ レイヤーなどの軽量クライアント ベースのアプリケーションをサポートします。 ラグランジュ状態委員会は、EigenLayer を介して Ethereum に 32 ETH 相当の担保を再ステークしたクライアント ノードのグループです。言い換えると、ラグランジュ状態委員会ネットワークは AVS ( ) です。各ラグランジュ状態委員会は、関連するトランザクション バッチがデータ可用性 (DA) レイヤーで確定されると、特定の楽観的ロールアップのブロックの確定性を証明します。これらの証明は、状態証明を生成するために使用され、アプリケーションはこれを特定の楽観的ロールアップの状態の真実のソースとして扱うことができます。 Actively Validated Service Ethereum の Sync Committee は 512 ノードに制限されていますが、各 Lagrange State Committee ネットワークは無制限のノード セットをサポートします。これにより、経済的セキュリティが人為的に制限されることがなくなり、楽観的なロールアップの状態を証明するノードの数を拡張できるため、Lagrange State 証明の背後にある経済的セキュリティが動的に向上します。 ラグランジュ国家委員会ネットワークはどのように機能しますか? ラグランジュ状態委員会プロトコルの 2 つの主要コンポーネントは、シーケンサーとクライアント ノードです (「クライアント ノード」は、ラグランジュ状態委員会に登録されているバリデーターの別名です)。シーケンサーは、ラグランジュ状態委員会ネットワーク内の証明を調整し、状態証明を生成する証明者に証明を提供する中心的な存在です。シーケンサー ノードは、実際には、 、 、 異なる機能を持つ 3 つのモジュールの組み合わせです。 Sequencer Consensus Governance シーケンサー モジュールは、特定の間隔で、DA レイヤーに書き込まれたトランザクションのバッチの実行から生じるブロックをロールアップするために、クライアント ノードからのアテステーションを要求します。すべての楽観的なロールアップ ブロックに対してこのルーチンを実行する代わりに、ブロック メッセージの各要素の簡単な分析を以下に示します。 (1). : 確定したオプティミスティックロールアップ(ORU)ブロックのヘッダー。ここでの「ファイナリティ」とは、特定のDAレイヤーで確定したトランザクションデータからロールアップノードによって導出されたブロックを意味します。例えば、ファイナリティは、Optimism/OPスタックロールアップの場合は によって定義され、ArbitrumおよびArbitrum Orbitチェーンの場合は を持つL2ブロックによって定義されます。(ロールアップファイナリティの詳細については、 をご覧ください。) Block_header 安全なL2ヘッド Ethereumと同等のファイナリティ こちらの記事 （2） ：ブロックbに署名することを許可されたクライアントノードに関連付けられた公開鍵のセットに対する暗号化コミットメント。クライアントノードは、すべてのアクティブな委員会メンバーの公開鍵を葉で表したMerkleツリーを構築し、BLS12-381キーを使用してMerkleツリーのルートに署名することが期待されます。 current_committee (3). : 次のブロック(b+1)に署名することを許可されたノードに関連付けられた公開鍵のセットに対する暗号化コミットメント。状態委員会を脱退したいノードは、認証期間の終了時に、状態委員会AVSにおけるオペレータの登録と登録解除を処理するEthereum上の コントラクトにトランザクションを送信する必要があります。 next_committee Lagrange Service 各認証期間の終了時に、次の認証期間が始まる前にオペレータが脱退または参加を要求した場合、委員会ノードのセットが変更されることがあります。クライアント ノードは、Lagrange サービス コントラクトから各委員会に登録されている現在のノード セットを取得して、 の を構築することが求められます。 next_committee Merkle ツリー ELI5: 状態証明とは何ですか? は、ブロックチェーンの状態の暗号証明です。ソース チェーン (チェーン A) のブロック ヘッダーの証明であり、特定のトランザクションなどのソース チェーンの状態の存在を宛先チェーンに証明するために使用できます。言い換えると、状態証明は、指定されたブロックの高さでのソース チェーンの状態の証明を表します。 状態証明 前の例を使って説明すると、ソース チェーン (チェーン A) のブロック ヘッダーは、宛先チェーン (チェーン B) のボブのアプリケーションがアリスのブリッジ トランザクションの存在を確認するために使用する状態証明です。これは、前のブロックと現在のブロック間のソース チェーンの状態の変更の概要を表します。アリスの Merkle 証明がチェーン A のブロック ヘッダーに格納されているトランザクション ツリー ルートに対して検証された場合、状態証明が元のチェーンでのアリスのメッセージ要求の実行を証明するため、ボブはチェーン B (宛先チェーン) のブリッジ トランザクションを自信を持って承認できます。 ラグランジュ状態委員会ネットワークは、イーサリアムによって保護された楽観的ロールアップの状態証明を生成するように設計されています。状態証明は、状態委員会の少なくとも 3 分の 2 のノードから、前述のタプル ( 、 、 ) の BL12–381 署名を集約することによって生成されます。その後、状態証明は、特定のブロック ヘッダーを証明する署名の集合的な重みに基づいて、SNARK 回路によって生成されます。 block_header prev_committee next_committee 認証者に現在の状態委員会と次の状態委員会へのコミットを要求するアプローチは、Ethereum Sync Committee プロトコルに似ており、同様の目標を達成します。つまり、軽量クライアントが楽観的なロールアップ ブロック ヘッダーの有効性を効率的かつ安全に検証できるようにすることです。各状態証明は、どのノードが次のブロックに署名すべきかを示す一連の コミットメントによって暗号的にリンクされています。したがって、認証ノードによって署名されたブロック オブジェクト内の次の再帰プロパティを証明する SNARK 証明を検証するだけで十分です。 next_committee 状態委員会のn個のノードのうち少なくとも2/3がブロックヘッダーbに署名しました。 ブロック b の 、ブロック b-1 の ツリーに等しくなります。 current_committee next_committee ブロック b-1 は、ジェネシス ブロックであるか、またはこれら 3 つの条件に関して有効です。 相互運用性プロトコルや、高速なファイナリティを備えた安全で楽観的なロールアップ状態を必要とするその他のアプリケーション (クロスチェーン ブリッジやメッセージング プロトコルなど) は、信頼の仮定を最小限に抑えて、ラグランジュ状態委員会の状態証明を使用できます。重要なことは、ラグランジュ状態委員会ネットワークが、悪意のある認証者の と 実装することで、状態証明のセキュリティを保証できることです。 決定論的削減 帰納的有効性証明を Lagrange State Committee ネットワークは ZK Big Data Stack とどのように相互運用しますか? Lagrange の製品スイートに関するシリーズの最初の投稿では、 のさまざまな部分 (Lagrange 状態委員会、Recproofs、zkMapReduce、Lagrange コプロセッサ) の関係について説明しました。これらの各コンポーネントを組み合わせると、安全で効率的な状態へのアクセスと、状態データに対する表現力豊かで動的な計算が総合的に提供されます。 ZK ビッグ データ スタック #1. ラグランジュ状態委員会ネットワークは、ZKビッグデータスタックの他のコンポーネントと統合してパフォーマンスを向上させます 私たちは、Recproofs と zkMapReduce を使用して、州委員会向けに更新可能な集約公開鍵 (APK) 証明を作成します。これにより、新しい集約署名を作成する必要があるたびに、非署名者の公開鍵を分解して再集約するというコストと時間のかかるプロセスを回避できます。 ラグランジュ状態委員会 AVS のオペレータの BLS 公開鍵の効率的な集約により、状態委員会ノードからの証明を検証するための計算コストを増やす AVS への参加率を高めることができます。これが、ラグランジュ状態委員会が潜在的に無制限のノード セットをサポートし、状態委員会に資金がプールされるにつれて超線形セキュリティを発揮できる理由です。このプロパティの詳細については、 に関する投稿をご覧ください。 ことなく、 ZK Big Data を使用した EigenLayer でのプログラム可能な信頼のスケーリング ラグランジュ状態委員会を ZK ビッグデータ スタックに統合すると、ラグランジュ状態証明を活用するクライアント アプリケーションにも直接的なメリットがもたらされます。たとえば、ラグランジュ コプロセッサの zkMapReduce 機能を使用して、n 個の楽観的ロールアップ チェーンからの複数の状態証明を 1 つの に結合できます。これにより、「ネストされた検証」が可能になり、単一のオンチェーン トランザクションで複数の楽観的ロールアップの状態を同時に検証し、クライアント サービスの検証コストを削減できます。 マルチチェーン状態証明 #2: ラグランジュコプロセッサはラグランジュ状態委員会ネットワークと統合され、信頼できないオフチェーン計算を実現します。 ラグランジュ コプロセッサ (これについては、後続の記事で詳しく分析します) は、オフチェーンで計算を実行することで、オンチェーン データに対する安価でスケーラブルな計算をサポートします。ラグランジュ状態委員会と統合するクロスチェーン相互運用性プロトコルも、ラグランジュ コプロセッサと統合して、クロスチェーン オファリングを拡張し、検証可能な計算を含めることができます。 たとえば、マルチチェーン融資アプリケーションを構築する開発者は、 異なるロールアップにわたってユーザーが預けた担保の合計を計算したい場合があります。当社の親切な開発者は、クロスチェーン プロトコルが既に依存しているブロック ヘッダー ソースを使用して、ラグランジュ コプロセッサを活用してこの値を計算できます。 n ラグランジュの州委員会ネットワークが楽観的ロールアップの相互運用性に革命をもたらす理由 楽観的なロールアップ ライト クライアント向けの共有スーパーリニア セキュリティ 現在、楽観的ロールアップ チェーン間のブリッジングをサポートする相互運用性プロトコルは、ソース チェーンの状態を検証する責任を個別に負っています。これらの相互運用性プロトコルのセキュリティは、ブロック ヘッダーが正しいことを検証するメカニズムに依存します。 一部のクロスチェーン通信プロトコルは、ネイティブステーキングを実装し、ソースチェーンのブロックヘッダーを証明する前に検証者セットに担保を預けることで、信頼の前提を減らそうとします。ただし、各プロトコルの検証セットのサブセット ( ) を破損するコストが低くなるため、これにより、異なるクロスチェーンプロトコル間で経済的セキュリティが断片化されます。 n のうちの k 対照的に、ラグランジュ状態委員会は、複数のクロスチェーン プロトコルが、無制限のサイズに拡張可能な 動的バリデータ セットからセキュリティを引き出すことを可能にします。これにより、各相互運用性プロトコルがクロスチェーン状態の正確性を検証する責任を個別に負う現状が、複数のアプリケーションが単一のソースからクロスチェーン状態を使用できる現状に変わります。 単一の 他の軽量クライアント プロトコルとは異なり、Lagrange の State Committee ネットワークは、動的で無制限の証明ノード セットをサポートします。したがって、各証明を保護する署名の経済的重みは、より多くのステークが State Committee にプールされるにつれて動的に拡大できます。これにより、セキュリティが超線形に向上し、統合されたクロスチェーン プロトコルを単独で攻撃することが難しくなります。 これにより、ラグランジュ状態委員会は事実上、あらゆるクロスチェーン プロトコル (サイズに関係なく) が最大限のセキュリティを確保するために接続できる「共有セキュリティ ゾーン」になります。これは、Polkadot のリレー チェーンと Cosmos の Cosmos Hub がマルチチェーン エコシステムのセカンダリ ネットワークを保護する方法に似ています。さらに、EigenLayer の再ステーキング ミドルウェアと統合することで、ラグランジュ状態委員会ネットワークは Ethereum の経済的セキュリティを拡張し、任意の数の下流のクロスチェーン通信プロトコルを保護することができます。 クロスチェーン製品開発チームのオーバーヘッドを削減 現在、クロスチェーン相互運用性プロトコルを構築する開発者は、サポートするすべてのオプティミスティック ロールアップの状態を確認するためにウォッチャーを独立して実行するためのインフラストラクチャを開発する必要があります。統合されたオプティミスティック ロールアップの数が増えると、各オリジン チェーン全体でセキュリティを管理するためのインフラストラクチャのオーバーヘッドが増加します。 ラグランジュ状態委員会と統合することで、開発者はセキュリティをアウトソーシングし、代わりに製品機能の最適化にリソースを集中させることができます。これを文脈に当てはめると、各ラグランジュ状態証明は、EVM 互換チェーン上で効率的に検証できるほど軽量です。 既存の相互運用性プロトコルに対する追加のセキュリティ ラグランジュ状態証明は、1 つ以上の宛先チェーンに転送するために使用されるトランスポート層に依存しないため、相互運用性アプリケーションは、ラグランジュ状態証明を既存のセキュリティ メカニズムとシームレスにスタックできます。たとえば、独立した検証セットを備えたクロスチェーン オラクルまたはクロスチェーン メッセージング プロトコルは、オプティミスティック ロールアップからのクロスチェーン メッセージ要求を中継する前に、追加のセキュリティ対策としてラグランジュ状態証明を検証できます。 さらに、既存の相互運用性プロトコルは、ラグランジュ状態委員会ネットワークと統合されると、バリデーターが監視するチェーンの数を増やすことなく、楽観的なロールアップのサポートを追加できます。ラグランジュ状態委員会ネットワークの状態証明を使用することで、バリデーターはロールアップ間でメッセージ要求を中継するだけで済みます。宛先チェーンのゲートウェイ コントラクトは、ラグランジュ状態証明を検証することで、中継者によって渡されたメッセージの存在を検証できます。 ラグランジュ状態委員会ネットワークは、他のクロスチェーンセキュリティメカニズムと比べてどうですか? ラグランジュ状態委員会は、ボンドステーキング/スラッシング、許可された検証、楽観的検証メカニズムなどを利用してクロスチェーン状態証明のセキュリティを強化する既存の相互運用性インフラストラクチャと比較して優れています。以下にいくつかの比較を示します。 許可のないバリデータによる外部検証 ラグランジュの再ステーキング モデルは、セキュリティのために純粋な PoS ステーキングを実装するクロスチェーン セキュリティ メカニズムにおける重要な問題であるリスクの を軽減します。たとえば、バリデーターがボンディング期間中にプロトコルのネイティブ トークンを購入してロックする必要があるクロスチェーン プロトコルを考えてみましょう。クロスチェーン プロトコルのネイティブ トークンの人気が変化すると、資産価格の変動性がネットワーク全体の経済的セキュリティに影響を及ぼします。 積み重ね ラグランジュ状態委員会ネットワークでは、委員会ノードのセキュリティが EigenLayer を通じて再ステークされた担保に基づいているため、価格変動はそれほど問題になりません。さらに、再ステークされた担保により、将来のバリデーターの機会費用が削減され、状態委員会への参加が増え、相互運用性プロトコルの経済的セキュリティのレベルが向上します。ユーザーにとって、これは、セキュリティを独自にブートストラップする相互運用性プロトコルと比較して、手数料が安くなり、セキュリティが向上することを意味します。 また、従来の Proof-of-Stake で使用されるコンセンサス プロトコルでは、バリデーターの数に制限があり (例: Tendermint BFT では参加バリデーターの数が 100 ～ 200 に制限される)、従来の PoS プロトコルでは必要な頻度で経済的セキュリティを拡張できないことにも注意してください。一方、Lagrange State Committee ネットワークでは、コンセンサスに参加するノードの潜在的に無制限のセットをサポートする証明メカニズムを使用します。これにより、ネットワークは証明者の数を動的に増やすことができ、ひいてはクライアント アプリケーションの経済的セキュリティをより堅牢に保証できます。 許可された検証者による外部検証 権限証明 (PoA) ベースのクロスチェーン プロトコルは、認証を利用して、許可された少数のノードからのヘッダーをブロックします。これらのアプローチは、 (7 つのバリデータのうち 5 つが侵害された) や (5 つのバリデータのうち 2 つが侵害された) などの有名なインシデントにより、これまで安全でないことが証明されています。 Ronin ハッキング Harmony One ブリッジ ハッキング ラグランジュ状態委員会ネットワークのような許可なしで検証されたシステムを使用すると、中央のオペレーターや検証者が署名ヘッダーを設定する場合に比べて、効率がいくらか低下します。しかし、リスクの大きさを考えると、これは妥当なトレードオフであると考えられます。許可なしで検証されたシステムは、許可されたシステムで大多数の検証者を実行することになる企業にとって、攻撃対象領域も減少させます。 標準的なブリッジング ラグランジュ状態委員会ネットワークは、楽観的ロールアップからのクロスチェーン メッセージの送信の遅延を排除します。各 LSC は、チャレンジ ウィンドウを待たずに楽観的ロールアップからブリッジしたいユーザーにとって、ブリッジおよびメッセージング プロトコルの「高速モード」として機能します。楽観的ロールアップは、L2 ユーザーにとって重要な UX の問題点を解決するため、LSC の高速ファイナリティ プロパティから直接恩恵を受けます。 この保証は、(a) スラッシング メカニズムは敵対的行動のコストを引き上げる目的で設計されており、(b) ステークの引き出しにはさまざまな時間遅延があるため、LSC 内の共謀ノードのスラッシングはオンチェーンで で発生する可能性があるという観察から生まれます。要約すると、LSC の参加者には常に正しいクロスチェーン状態を証明するインセンティブがあり、これによりクロスチェーン アプリケーションは、ロールアップの によって裏付けられた最小限の信頼仮定で、LSC からの状態証明を即座に使用できるようになります。 スロー モード 標準ブリッジ 結論 この記事は非常に広範囲に渡って取り上げられており、相互運用性分野の開発者、投資家、愛好家、ユーザーにとって、有益な情報であったと期待しています。この記事では、共有セキュリティの定義、安全なプロトコルの設計における共有セキュリティの意味、共有セキュリティ インフラストラクチャとの統合によってチェーン間の相互運用性にどのようなメリットがもたらされるかを検討しました。 また、クロスチェーン通信プロトコルを念頭に設計された共有セキュリティ・アズ・ア・サービス・ソリューションである Lagrange State Committees についても調査しました。Lagrange State Committees は、安全で信頼性が最小限に抑えられた効率的な相互運用性を実現するという当社のビジョンの一部であり、開発者がユーザー向けに強力なクロスチェーン アプリケーションを構築できるようにする、より大きなスタックの一部となります。 マルチチェーンの未来は避けられず、ユーザーがセキュリティを大幅に損なうことなく、1 つのチェーンから 10,000 のチェーンに移行できることが重要です。ラグランジュ状態委員会などのソリューション (およびクロスチェーン セキュリティのその他の進歩) は、この目標達成に不可欠です。相互運用性がこれまで以上に注目を集める中、チェーン間の移動が安全かつ効率的である世界は、世界中の暗号通貨ユーザーにとって手の届くところにあります。 謝辞 この記事には、 ( )、 ( )、 ( )、 ( ) が協力しました。Emmanuel は、この記事の執筆をサポートするために Lagrange Labs と契約しました。 Emmanuel Awosika 2077 Research Omar Yehia Lagrange Labs Ismael Hishon-Rezaizadeh Lagrange Labs Amir Rezaizadeh Lagrange Labs この記事のバージョンは以前 公開されました。 こちらで