イーサリアムがRollup技術を使用する際の安全リスクはどこにありますか？
Infruaを破壊することで、基本的にすべてのRollupを破壊することができます。この記事は、WeChat公式アカウント「白计划」に掲載され、著者はQingzhouです。
イーサリアムはRollupを中心とした2.0のロードマップを確認しました。これにより、Rollupは注目の技術となり、Layer2のスケーリングの主流技術とも言えます。ゼロ知識証明と組み合わせることで、RollupはLayer2技術の解決策の集大成となるでしょう。
しかし、「絶対に安全なシステムは存在しない」という言葉通り、Rollupにも一定の安全リスクが存在します。イーサリアム研究者フォーラムの開発者たちはこの問題について議論を始めています。以下は、白计划チームがイーサリアム開発者「jchancehud」が以前に発表した仮想Rollup攻撃に関する議論を整理し、修正したものです。
Rollupの安全リスクの理由
仮想Rollup攻撃の基本原理は、仮想状態が有効であれば、どのイーサリアムノードもOptimistic Rollupのコーディネーターに対して嘘をつくことができるということです。そして、コーディネーターは取引を送信しようとしたり、イーサリアムプロバイダーを切り替えたりする際（つまり、全ノードの状態を同期する際）にのみ、このことに気づくのです。
Optimistic Rollupは、イーサリアムネットワーク上でcalldataを使用してブロック情報を保存することによって行われます。このプロセスにより、誰でもイーサリアムノードを操作し、Rollupの状態をダウンロードすることができます。しかし実際には、自分のイーサリアムノードを操作しない人もおり、ホスティングソリューション（例えばInfura）に依存しています。
有効性の検証が必要
迅速かつ低コストで有効なRollupチェーンを構築するためには、取引を行い、状態を構築し、それをイーサリアムネットワーク外の他の場所に保存する必要があります。Rollupコーディネーターがイーサリアムノードから状態の履歴を受け取ると、コーディネーターは状態取引をリプレイすることでデータが有効かどうかを確認できます。しかし、コーディネーターはチェーン上にその状態が存在するかどうかを確認できず、最良の方法はイーサリアムノードに問い合わせることです。
人為的攻撃が発生した場合
Untrustという名のイーサリアムノードサービスを想像してみてください。Untrustはイーサリアムのdappに低コストのインフラを提供します。彼らが信頼しないことを選択した場合、特定のRollupを確認し、虚構の履歴を作成することができます。彼らは、いくつかの実際の取引から通信データを抽出し、それを虚構の取引と混ぜることで半虚構の履歴を作成することさえできます。こうして、彼らは全く異なる現在の状態ハッシュを作成しますが、これはUntrustのRollupオペレーターが（チェーン上に）ブロックを提出する場合にのみ発見されます（これは詐欺的です）。
このタイプの攻撃は特に強力ではありません。攻撃者は署名を偽造することはできず、直接資金を盗むこともできませんが、Rollup内で自分の活動について嘘をつくことができます。
Untrustがさらに複雑になることを想像してみてください。彼らはMoneyMoverというRollupを攻撃することを決定しました。
MoneyMoverアドレスへのリクエストを受け取ると、彼らは完全に独立したイーサリアムネットワークを運営するノードから情報を返します。この独立したイーサリアムネットワークでは、Untrustはほとんどの取引をミラーリングし（アカウントの残高を似たように見せ）、必要に応じて自分の（偽の）取引を注入します。
今、UntrustがMoneyMover Rollupで支払いを行うウェブサイトを見つけたとしましょう。そのウェブサイトは独自のMoneyMoverコーディネーターを運営しており、そのコーディネーターはUntrustに接続してイーサリアムネットワークにアクセスします。
Untrustはミラーリングネットワーク内で虚構の取引を作成し、MoneyMoverコーディネーターはそれを有効と解釈します（状態取引が有効であれば）。MoneyMoverコーディネーターはどのピアとも接続していないため、チェーン上に存在するかどうかを確認する唯一の方法はイーサリアムノード（この場合はUntrust）に問い合わせることです。
Untrustはミラーリングネットワーク上で虚構の取引を行い、そのウェブサイトが運営するMoneyMoverコーディネーターはそれを有効な支払いとして検出します。Untrustは今、支払いをせずにそのウェブサイトにアクセスできます。ウェブサイトは、彼らが取引を提出するか、他のイーサリアムプロバイダーに切り替える（つまり、他のノードとデータを同期する）まで、この虚構の支払いに気づくことはありません。
実際に発生する可能性のあるリスク
上記の攻撃は、コーディネーターが自分のイーサリアムノードを運営していない場合にのみ意味があります。問題のある状況がいくつかあります：
- コーディネーターのデータの下流利用者は、受け取ったデータが（チェーン上に）存在するかどうかを知ることができず、利用者は自分でそのノードを運営していないため、コーディネーターが使用しているethノードを信頼できません。
- 詐欺証明者（悪意のある取引を証明する側）は特にこの攻撃に対して脆弱です。なぜなら、彼らは詐欺行為が検出されたときにのみ取引を提出するからです。悪意のあるethノードはブロックチェーンデータから無効な取引を剥ぎ取り、異なる状態ハッシュのみを返すことができます。詐欺証明者は状態ハッシュが虚構であることを知ることができず、詐欺の申し立てを決して提出しません。
- ethノードのオペレーターがRollupコーディネーターに嘘をつき、無効な状態取引を提出させたり、無効な詐欺声明を提出させたりするように誘導します。このようなことが起こると、悪意のあるethノードオペレーターは有効な取引相手として振る舞い、担保資金を集めることができます。
解決策1
プルーフ・オブ・ワークチェーンの文脈では、コーディネーターはブロックデータを要求し、それが十分に困難であるかどうかを確認できます。現在の難易度の少なくとも半分を確認することで、大多数の攻撃は財務的な問題から実現できなくなるはずです。
プルーフ・オブ・ステークチェーンでは、このプロセスは実行不可能になります。なぜなら、悪意のあるethノードが投票していないアドレスから署名を提供できるからです。彼らは、クエリ時に担保金をステークすることでこれを実現できます。
解決策2
あまり優雅ではない解決策は、信頼できるノードに対して継続的に署名し、チェーン上に存在するRollup状態ハッシュのリストを公開することです。このリストはIPFSのようなサービスに公開できます。コーディネーターノードは、信頼できる公共鍵の既知のリスト（Rollup作成者、EFなど）を含めることができます。
次のような場合、コーディネーターはRollupデータが真実であることを知ることができます： - すべての状態取引が有効である。
- すべての状態ハッシュが信頼できるソース（ノード）によって署名されている。
これにより、Rollupデータが有効であり虚構でないことが保証され、Rollupノードは任意のイーサリアムノードを使用してデータを同期することができます。
以上は「jchancehud」が議論したRollupの安全攻撃の可能性です。主にRollupはオフチェーン状態であり、多くの状態で情報の同期が遅れる可能性があるため、「jchancehud」が述べたように、オフチェーン状態が有効であるかどうかを検証する必要がある側は、他のイーサリアム全ノードのデータを同期する必要があり、最終的な安全性を確認する必要があります。これは、多くのプラットフォームがイーサリアムノードを運営する必要があることを意味します。
上記の仮想攻撃方法について、イーサリアムのLayer2ソリューションチームSKALE LabsのCTO「Konstantin Kladko」は、「これは本当に興味深いです！これは、Infuraを破壊することで基本的にすべてのRollupを破壊できることを示していると思います。」と述べています。
もちろん、これはInfuraを通じてイーサリアムと通信する製品を代表しています。Infuraは非常に大規模なイーサリアムノードサービスを担っており、以前からInfuraがイーサリアムネットワークの最大の単一障害点になるのではないかという議論もありました。この単一の安全リスクについては、主に複数のノードによる負荷分散の方法で対処し、回避するよう努めています。
「jchancehud」の議論に対して、最も興味深いのは開発者「adlerjohn」が提起したことで、このような仮想的な「攻撃」はoptimistic Rollupだけでなく、zkRollupにも適用され、実際には任意のスマートコントラクトにも適用されるようです。
この推論は、「情報の非対称性の危険が存在する限り」協力プロセスが「jchancehud」が述べた攻撃リスクに直面することを示唆している可能性が高いです。
したがって、「adlerjohn」はビットコインのホワイトペーパー第8節に、情報の正誤を検証する方法があることを提案しています。つまり、検証者が最長のチェーンを特定し、最長のチェーンを信頼するという方法です。この方法は、Sybilノードが虚偽の情報を提供するのを防ぐために知られている方案を説明しています。これにより、大多数の計算が誠実であることを要求せずに済みます。
ビットコインホワイトペーパー第8節
さらに、「adlerjohn」はRollupの状態ルートがイベントとして発出され、イーサリアムの状態に保存されることもでき、偽造取引のクエリも行えることを提案しています（例えば、ビットコインホワイトペーパー第7節に記載されているように、ブロックヘッダーを検証することで確認できます）。
ビットコインホワイトペーパー第8節
また、「adlerjohn」はoptimistic Rollup方案において、「最小限の実行可能な合意」の設計を含めることができるとも言及しています。この設計は、順序付けられたデータを公開することでデータの可用性を実現し、複数のサイドチェーンやシャーディングを使用できるようにします。
しかし、「adlerjohn」が提案した方法を使用することは、かなりの設計の難しさがあることが予想されます。
議論の最後に、「jchancehud」は「adlerjohn」に対し、この攻撃予測がZKRollupに適用されるかどうかは不明であると返信しました。しかし、ZK証明は生成が難しいため、少なくともより困難になるでしょう。Rollupが広く採用される場合、このようにRollupを考慮することは特に重要です。
Rollupコーディネーターは、ノードを使用する前にノード内のすべてのブロックヘッダーを検証できるという別の潜在的な解決策がありますが、時間と帯域幅が高価です。しかし、ユーザーは信頼できるeth軽ノードを運営する方が良いでしょう。検証の問題が解決されている場合、軽ノードを運営することでイベントをクエリすることもできます。
議論の最後に、私たちは安全性、スケーラビリティ、効率を実現するために、これらの方案がエンジニアリングの観点から試みることができることを発見しますが、実施プロセスは必ず困難であることを理解しています。なぜなら、異なる開発者の議論の思考が最終的にコードに統合され、ネットワーク構造、クライアント、言語、操作インターフェースなどの複数の課題を含むからです。
タイムスタンプは前進し、ブロックは止まらず、私たちは引き続き期待しましょう。
