セキュリティ課題の概要

ブロックチェーンの特徴的な性質の一つは、トランザクションのアトミック性です。一度更新がブロックチェーンに記録されると、介入や取り消しの機会はありません。これにより一貫性とプロトコルレベルのセキュリティが強力に保証される一方、ユーザーは運用リスクにさらされます。一度のミス、鍵の漏洩、または急いだ承認が、取り返しのつかない損失につながる可能性があります。

その結果、セキュリティの大きな負担がユーザーに課せられます。イーサリアムを安全に使用するには、個人や組織が鍵を安全に保持・管理し、オンチェーンアプリケーションとやり取りし、資産を転送したりイーサリアムのステートを更新したりするために鍵を使ってトランザクションに署名する必要があります。

これらの各要件は、鍵の漏洩や紛失、急いだ承認や不十分な情報に基づく承認、またはユーザーがイーサリアムとのやり取りで情報や案内を頼りにしているウォレットソフトウェアの侵害といったリスクをもたらします。

1.1 鍵管理

多くのユーザーは暗号鍵を安全に管理する準備が整っていません。

最も広く利用されているソフトウェアウォレットは、ユーザーが暗号学的な秘密鍵を表すシードフレーズを安全に保管することに依存しています。しかし、その結果として、多くのユーザーはシードフレーズを平文のまま保存したり、クラウドサービスに置いたり、紙に書き留めたりといった安全でない対処法を取ってしまうことがよくあります。

ハードウェアウォレットは代替手段であり、専用の物理デバイス内に保存された暗号鍵をユーザーが管理できるようにします。しかし、ハードウェアウォレットには固有の欠点や攻撃面があります。ハードウェアウォレットは紛失、破損、盗難のリスクがあります。また、多くのハードウェアウォレットはオープンソースではなく、サプライチェーンが不透明である場合もあり、改ざんされたデバイスが市場に流通するサプライチェーン攻撃のリスクが高まります。

鍵がソフトウェアウォレットで管理されていようとハードウェアウォレットで管理されていようと、物理的な盗難や暴行によって資産が危険に晒される可能性がある以上、多くのユーザーがセルフカストディに不安を感じるのは当然です。

エンタープライズユーザーや機関投資家は、鍵管理においてさらなる課題に直面しています。個々の従業員が鍵を保有している場合 (例：マルチシグウォレットの一部として)、組織は人事異動に伴い、それらを交換し、新しいものを作成できる必要があります。異なる業界や法域のコンプライアンス要件により、既存のウォレットソフトウェアではサポートされていないカスタムワークフローや監査証跡が必要になる場合があります。場合によっては、エンタープライズユーザーはデジタル資産を第三者のカストディアンに委託することもあり、これは考慮すべき別のセキュリティリスクのレイヤーをもたらす可能性があります。

1.2 ブラインドサインとトランザクションの不透明性

ユーザーは、自分が何をしているのか理解しないまま「盲目的に」トランザクションを承認してしまうことが日常的にあります。ウォレットはしばしば生の 16 進データや省略されたコントラクトアドレスなどを表示しますが、これらはユーザーがトランザクションの結果を理解するには不十分です。そのため、あらゆる種類のユーザーが、悪意あるスマートコントラクト、フィッシング、詐欺、偽装インターフェース、フロントエンドの侵害、そして単純なユーザーエラーに対して脆弱な状態に置かれています。

1.3 承認および権限管理

多くのイーサリアムアプリケーションでは、通常の利用プロセスの一部として、ユーザーがアプリケーションに特定の権限を付与することが一般的です。たとえば、ユーザーがトークンを ETH にスワップするために、Uniswap のような分散型取引所に自分のトークンを移動する権限を与える、といったケースがあります。

これらの承認には上限額を設定できる場合もありますが、多くのウォレットは、期限のない無制限の承認をデフォルトで付与します。さらに、ほとんどのウォレットでは、ユーザーが自分の未処理の承認内容を管理・確認する手段がありません。

これにより、ユーザーは悪意のあるアプリや侵害されたフロントエンドに対して脆弱になります。というのも、多くのユーザーは無制限承認をデフォルトで付与してしまうため、その権限が悪用されれば資金を引き出される可能性があるためです。たとえユーザーが正当なスマートコントラクトに承認を与えた場合でも、その承認が残っている間にそのコントラクトが侵害されれば、侵害されたコントラクトによってユーザーの資金が抜き取られる可能性があります。

これは組織ユーザーにとっても同様にリスクとなります。たとえば、ある組織が業務上の利便性から DEX のルーターに無制限の USDC アローワンスを付与した場合、後にそのルーターコントラクトがアップグレードされた際にリスクへとつながる可能性があります。

1.4 侵害された Web インターフェース

ほとんどのユーザーはスマートコントラクトと直接やり取りするのではなく、モバイル端末やウェブブラウザを通じて Web インターフェース経由でアクセスしています。

これらのフロントエンドは、DNS ハイジャック、悪意のある JavaScript の注入、不十分なホスティング、さまざまなサードパーティ依存など、一般的によく知られた手法によって攻撃される可能性があります。侵害されたアプリの UX は、あらゆる種類のユーザーを悪意あるスマートコントラクトへ誘導したり、誤解を招くトランザクションに署名させたりする原因となり得ます。

1.5 プライバシー

プライバシーは、あらゆる種類のユーザーにとってセキュリティリスクを軽減することも、逆に増大させることもあります。

弱いプライバシー保護は、フィッシング、悪用、詐欺、物理的攻撃などのさまざまな標的型の脅威に個々のユーザーをさらします。多くの一般的なUXパターンがユーザーをさらしており、例えばアドレスの再利用、KYCデータ、その他のメタデータ漏洩などがあります。

企業や機関にとって、プライバシーはコンプライアンス上の理由や特定のユースケースにおいて、しばしば基本的なビジネス要件となります。こうした課題に加えて、プライバシーは特有のセキュリティリスクを生み出す可能性もあります。たとえば、イーサリアム上に構築されたサプライチェーンシステムのユーザーは、そのシステムが透明である場合に知的財産が侵害される可能性があるため、強固なプライバシー保証を必要とすることがあります。

1.6 断片化

異なるウォレット間で、トランザクションの表示、承認の処理、コントラクトのラベル付けといったコアとなる動作の処理方法に一貫性がありません。このユーザーエクスペリエンスの断片化は、ユーザーがウォレットを安全に使用する方法を学ぶ能力に障害を加え、リスクを高めています。

たとえば、ウォレットごとに UX の見た目や挙動が異なるため、ユーザーはフィッシングやなりすまし攻撃から身を守るための一貫した手がかりに頼ることができません。各ツールがそれぞれ異なる動作をする場合、ユーザーは「イーサリアムがどのように動作するか」について信頼できる期待値を形成できません。

イーサリアムの歴史の中で、スマートコントラクトのセキュリティは劇的に向上してきました。初期の DAO ハックのようなセキュリティインシデントは、エコシステム全体に専門性の向上と、オンチェーンにコードをデプロイするまでのソフトウェアライフサイクル全体における安全対策の強化を促しました。主な進歩には以下が含まれます：

• セキュリティ監査が標準的な慣行となり、複数のセキュリティ企業がエコシステムに参入し、専門性を高めてきました。
• ツール、テスト、および静的解析システムが成熟し、標準的な手法として定着しました。
• 事前に監査された共通コンポーネントのライブラリが整備され、開発者はデフォルトで安全なビルディングブロックを利用できるようになりました。
• 形式的検証手法が導入され、とくにブリッジ、ステーキングシステム、高価値コントラクトで活用されるようになりました。
• エコシステム全体のセキュリティ文化とベストプラクティスが向上しました。
• アプリレイヤーを強化した重要なバウンティプログラムの創設。

しかし、この領域にはまだ弱点と改善の余地があります。

2.1 コントラクトの脆弱性

スマートコントラクトのセキュリティは進歩していますが、以下のような重大なセキュリティ問題につながる可能性のある脆弱性がまだ存在します。

• コントラクトのアップグレードのリスク. 一部のコントラクトは、開発チームがアプリケーションのアップデートと改善を継続できるように、デプロイ後に変更可能に設計されています。しかし、これにはリスクが伴います。アップグレードによって新たな脆弱性が生じたり、悪意のあるアップグレードの場合にはユーザー資金が完全に失われたりする可能性があります。
• 再帰可能(Re-entrancy), コントラクトAが自身の内部状態を更新する前に外部コントラクトBを呼び出し、最初の呼び出しが終了する前にコントラクトBが元のコントラクトAをコールバックする場合。
• 外部ライブラリの安全でない使用, コントラクトが、監査されていない、悪意のある、またはアップグレード可能な外部ライブラリを呼び出す場合。
• 監査されていないコンポーネント. 監査や標準ライブラリの使用は改善されてきましたが、デベロッパーはアプリケーションで監査されていないコンポーネントに依存することがあります。
• アクセス制御の失敗, 権限が誤って設定されたり、広範に定義されたりして、攻撃者が悪意のあるアクションを取ることが可能になる場合。
• 不正アクセス, コントラクトを制御できる秘密鍵が悪意のある者によって入手される場合。
• ブリッジとクロスチェーンインタラクション. ブリッジとクロスチェーンプロトコルは複雑さを増し、攻撃者はクロスチェーンメッセージの受け渡しや検証方法の弱点を悪用する可能性があります。
• 外部所有アカウント (EOA) の委任または署名の誤用. 悪意のあるアプリケーションは、ユーザーを騙してアカウントの完全な委任を他者に署名させ、盗難を可能にすることがあります。また、悪意のあるアプリケーションは、ユーザーからの署名付きメッセージをリプレイ攻撃などで予期せぬ方法で使用することもあります。
• AIコード生成または自動リファクタリングツールによって導入されるバグの新たなリスク.

2.2 デベロッパーエクスペリエンス、ツール、プログラミング言語

脆弱性は、デベロッパーのエラーの結果としてデプロイされたコードに残ります。改善されたデベロッパーツールにより、安全なスマートコントラクトのデプロイが大幅に容易になりました。しかし、問題は残っています。

• 一般的なフレームワークにおける安全なデフォルト設定の欠如. 一部のツールは、安全性よりも柔軟性や速度を優先し、approve() 関数で無制限のトークン承認などの安全でないデフォルトを設定したり、デフォルトでアクセス制御パターンを含めなかったりします。
• 高度な運用制御のためのカスタムコード. 複雑な運用要件を持つ機関投資家は、必要な機能をゼロから構築する必要があることが多く、脆弱性のリスクが高まります。高度なセキュリティワークフローのための標準化された安全なコンポーネントやフレームワークが不足しています。
• 一貫性のないテストカバレッジ ツールスタック全体で、ファジングや不変チェックなどの実績のある手法の使用に関する規範が欠如しています。
• 形式的検証手法の低い採用率. 形式的検証技術は強力ですが、複雑でコストがかかり、専門的なドメイン知識を必要とし、標準的なデベロッパーのワークフローにうまく統合されていません。仕様段階で安全性を検証するために、ソフトウェア制作のより早い段階で使用できる可能性があります。
• コントラクト検証に関連する問題. ユーザーとデベロッパーは、デプロイされたコントラクトの信頼性、そのセキュリティ検証の範囲 (例：コード監査)、または潜在的なリスクの存在を容易に評価できません。この目的のための解決策は存在しますが、多くの問題が残っています。これらの問題に対処するツールは広く採用されておらず、アプローチを統一する標準は断片化されたままであり、既存のサービスの一部はそれ自体が中央集権的な依存関係にあります。
• コンパイラのリスク. コンパイラ (Solidity のような人間が読めるコードを EVM 自体が使用するバイトコードに変換するソフトウェア) には欠陥があり、スマートコントラクトがデプロイされる前にエラーを導入する可能性があります。現在のイーサリアムエコシステムは主に solc コンパイラに依存しているため、バグが広範囲に影響を及ぼす可能性があります。
• プログラミング言語の多様性と深さ. Solidity には深いツールエコシステムが構築されていますが、一部のデベロッパーは、メモリ安全性のような他のプログラミング言語に見られるより現代的な安全機能を求めています。

2.3 オンチェーンコードのリスク評価

機関や企業は、依存する技術やシステムのセキュリティを評価するための既存のプロセス、標準、および要件を持っています。しかし、既存のフレームワークは、通常、可変コード、中央集権的な変更管理、および明確な説明責任や法的責任の所在を前提としているため、スマートコントラクトにうまく対応できないことがよくあります。スマートコントラクト上に構築されたシステムは、これらの前提を覆すことがあり、組織がイーサリアムを採用し、リスクを適切に管理することを困難にしています。

これらのシステムは、ウォレットとアプリケーションレイヤー (例：ウォレットの RPC エンドポイント) とイーサリアムプロトコル自体の両方にとっての攻撃対象領域となります (例：多くのバリデータがクラウドインフラストラクチャでホストされている)。基盤となるブロックチェーンプロトコルが安全なままであっても、秘密鍵の漏洩、フィッシング、および詳細なアクセス制御の欠如は、大規模な停止、盗難、または不正な変更につながる可能性があります。

3.1 レイヤー2チェーン

レイヤー2チェーン (L2) はイーサリアムの拡張機能として機能し、イーサリアムメインネットの特性的なセキュリティ保証の一部を維持しながら (特定の設計によります)、より高速で低料金の環境を実現します。しかし、これらには独自の攻撃対象領域も存在します。

• マルチホップブリッジ資産の複雑さ. 資産が L1 と複数の L2 の間を移動する場合、それらは複数のコントラクトセットにさらされ、そのすべてが安全でなければなりません。L2 チェーンでの会計の不一致や停止は、攻撃者によって悪用される可能性のある脆弱性を生み出す可能性があります。
• ロールアップL2は、状態更新の正当性を強制するために証明システムに依存しています. これらのシステムのバグや設定ミスは、ファイナライズを停止または妨げる可能性があり、あるいはユーザー資金の損失につながる誤った状態更新のファイナライズを許可する可能性があります。
• セキュリティ評議会は、L2 ソフトウェアをアップグレードしたり、特定の緊急事態に対応したりするための「バックアップ」メカニズムとして機能するキーホルダーのグループです. セキュリティ評議会自体もリスクを伴い、メンバー間の侵害や共謀はユーザーの資金を危険にさらしたり、資産を凍結したりする可能性があります。

L2 のパフォーマンスとセキュリティを評価・比較する詳細なフレームワークと監視ダッシュボードについては、L2Beatopens in a new tab をご覧ください。

3.2 RPC とノードインフラストラクチャ

イーサリアムアプリケーションは、RPC アクセス、API、ノードサービスを少数のインフラプロバイダーに依存しています。これには、暗号通貨特有のインフラプロバイダーのほか、ノードのホスティングによく使用される従来のクラウドサービス (例: AWS, Cloudflare, Hetzner) が含まれます。

これらのインフラプロバイダーがオフラインになったり、アクセスを検閲または制限しようとしたりした場合、多くのユーザーは新しい RPC または他のインフラプロバイダーに移行できるまで、ウォレットやアプリケーションを通じてイーサリアムにアクセスできなくなる可能性があります。これらのプロバイダーの一部は、過去にブロックチェーン活動に関連するアカウントを停止または閉鎖したことがあり、分散型アプリケーションの長期的な信頼性について懸念が生じています。

3.3 DNS レベルの脆弱性

ドメインネームシステム (DNS) はインターネットの基本的なレイヤーですが、中央集権的であり、侵害される可能性があります。多くのユーザーは Web ドメインを介してアプリにアクセスしますが、これらは以下のような影響を受けやすいです。

• 攻撃者が悪意のある偽のフロントエンドを挿入する DNS ハイジャック。
• 政府またはレジストラがドメインを差し押さえることができるドメイン差し押さえ。
• 攻撃者がユーザーを混乱させるためにほぼ同一の名前を登録する、類似ドメインを介したフィッシング。

3.4 ソフトウェアサプライチェーンとライブラリ

イーサリアムのデベロッパーは、npm、crates.io、GitHub などのサービスから直接取得したオープンソースライブラリに依存しています。これらのライブラリが侵害されると、次のような攻撃のベクトルになる可能性があります。

• 悪意のあるパッケージインジェクション, 攻撃者が広く使用されているパッケージを侵害したり、類似の名前で公開したりする場合
• 乗っ取られた依存関係, メンテナーがプロジェクトの制御を失い、悪意のある者が有害なコードを導入する場合
• デベロッパーの侵害, インストールされたパッケージに、攻撃者がデベロッパーのコンピュータを制御できるコードが含まれている場合。

3.5 フロントエンド配信サービスと関連リスク

多くのイーサリアムアプリケーションは、コンテンツ配信ネットワーク (CDN) またはクラウドベースのホスティングプラットフォーム (Vercel、Netlify、Cloudflare など) を介してフロントエンドを提供しています。これらのサービスが侵害された場合、攻撃者が改変されたフロントエンドをユーザーに提供する悪意のある JavaScript インジェクションなどの攻撃のベクトルとなる可能性があります。

3.6 インターネットサービスプロバイダーレベルの検閲

インターネットサービスプロバイダー (ISP) や国家は、基盤となるインターネットインフラストラクチャの制御を利用して、イーサリアムへのアクセスを検閲する可能性があります。例えば、これらの攻撃には次のようなものが含まれます。

• 一般的なイーサリアムポートへのトラフィックのブロックまたは制限
• イーサリアム関連サービスに解決される DNS リクエストのフィルタリング
• 既知のイーサリアムノードに対するジオフェンシングまたは IP 禁止
• イーサリアムプロトコル関連のトラフィックを特定して検閲するためのディープパケットインスペクション

これらの基本的な技術の多くは、今日、世界中の権威主義的な政府によって、情報へのアクセス、抗議ツール、または暗号通貨を抑制するためにすでに使用されています。

イーサリアムのコンセンサスプロトコルは、2015年の最初のローンチ以来、数回のアップグレードを経て、ダウンタイムゼロで、実際には堅牢であることが証明されています。しかし、システムをより回復力があり、安全なものにするためには、長期的な改善の余地が残っています。

4.1 コンセンサスの脆弱性と回復リスク

イーサリアムのフォーク選択とファイナリティのルールは回復力がありますが、無敵ではありません。特定の境界条件 (長引くバリデータの不一致、クライアントのバグ、ネットワークの分断など) の間、コンセンサスが停止したり、一時的に分岐したりする可能性があります。極端な状況では、非アクティブリークやスラッシングによる連鎖的なバリデータペナルティにつながり、さらにバリデータからの資本逃避につながる可能性があります。

4.2 クライアントの多様性

イーサリアムの業界をリードするクライアントの多様性は、単一のクライアントにおけるバグからネットワークを保護します。しかし、これらのリスクをさらに低減するためには、マイノリティクライアントの採用を増やすことで、クライアントの多様性をさらに改善することができます。

4.3 ステーキングの集中化とプールの優位性

バリデータのウェイトの大部分は、リキッドステーキングプロトコル、カストディサービス、および大規模ノードオペレーターに集中しています。この集中は、次のようなリスクにつながる可能性があります。

• ガバナンスの乗っ取りまたは影響力。大量のステークを支配する事業体 (またはそれらの事業体に影響を与える法的権限を持つ事業体) が連携した場合、提案され証明されるブロックに過大な影響力を持ち、ユーザーを検閲したり、プロトコルのアップグレードに影響を与えたりする可能性があります。
• クライアントの選択とインフラストラクチャ設定の均質性。これにより、相関的な障害リスクが高まる可能性があります。

4.4 未定義のソーシャルスラッシングと協調のギャップ

いくつかの極端な障害モードでは、イーサリアムはネットワークを攻撃するために悪意を持って行動したバリデータを罰するために「ソーシャルスラッシング」に依存します (セクション6.1参照)。しかし、この種のスラッシングのためのインフラ、規範、および期待されるプロセスは未発達です。コミュニティがこのプロセスに関与するために使用する確立されたメカニズムはありません。

4.5 経済的およびゲーム理論的な攻撃ベクトル

多くの潜在的な経済的攻撃ベクトルは、以下を含め、まだ十分に研究されていません。

• グリーフィング攻撃またはスラッシュグリーフィング。バリデータは、自身の過失ではなく、攻撃者にとって純費用で他者に危害を加えることのみを目的とした敵対的な行動のために、コストやスラッシングペナルティを被る可能性があります。
• 戦略的な退出または時限的な非アクティブ。バリデータは、利益を最大化したり、最小限のペナルティでコンセンサスを妨害したりするために、重要な時期に意図的にオフラインになったり、退出したりする可能性があります。
• バリデータまたはリレー間の共謀。バリデータ間またはリレーとバリデータ間の協調行動は、分散化を低下させたり、MEVを抽出したりする可能性があります。
• MEV、提案者-構築者分離、またはリキッドステーキング設計における境界的なインセンティブの悪用。行為者は、稀なプロトコル条件を操作して、過大な報酬を得る可能性があります。

4.6 量子リスク

イーサリアムのコア暗号技術 (例：secp256k1 のような楕円曲線署名) は、いつか量子コンピュータによって破られる可能性があります。これは差し迫ったリスクではありませんが、信頼できる脅威があれば、既存のウォレット、コントラクト、ステーキングキーが即座に脆弱になる可能性があります。この将来の課題は、イーサリアムのユーザーに対する長期的な保証を弱めます。

耐量子暗号技術への移行パス (例：ポスト量子署名方式経由) は、必要となる何年も前に設計、テストされ、場合によってはプロトコルに組み込まれる必要があります。イーサリアム・ファウンデーションを含むイーサリアムエコシステム全体の組織は、これらのオプションを積極的に調査し、リスクを監視しています。

理想的なブロックチェーンエコシステムでさえ、リスク、攻撃、脆弱性を抱えています。問題が発生した場合には、緩和、検出、対応するための効果的なシステムが必要です。ここでの課題には、以下が含まれます。

• 影響を受けたチームへの連絡. 侵害されたアプリケーションのチームと連絡を取るのは難しい場合があります。これにより、数時間の遅延が発生し、対応者が資金を回収する能力が制限される可能性があります。
• 関連組織での問題のエスカレーション. 問題がプラットフォーム (ソーシャルネットワークや中央集権型取引所など) に関連する場合、対応者が事前に連絡先を持っていないと、問題をエスカレーションするのが難しいことがあります。
• 対応の調整. 影響を受けたアプリケーションを支援しているインシデント対応チームが何チームあるか不明確なことが多く、グループでの取り組みがより効果的であったかもしれない場合に、誤解や無駄な労力につながります。
• 監視能力の欠如. オンチェーンとオフチェーンの問題を監視することは難しく、これは早期警告を提供し、脅威への迅速な対応を保証するものです。
• 保険へのアクセス. 保険は、お金、金融システム、身元情報、その他の貴重な情報を扱うほとんどの従来のシステムにおいて、損失を軽減するための不可欠なツールです。しかし、今日、従来の金融サービスから暗号通貨エコシステム向けに提供されている保険の選択肢はほとんどありません。

これらのリスクは、より長期的なものであり、個々のユーザーやアプリケーションのセキュリティよりも、イーサリアム全体に関わるものです。

6.1 ステークの集中化

大量のステークが集中化すると、そのステークを管理する事業体が共謀した場合、イーサリアム全体にリスクをもたらす可能性があります。
この経済的な集中化は、社会的なガバナンスの乗っ取りの可能性を生み出します。少数のバリデータグループがステークの過半数を支配した場合、彼らは以下のことが可能です。

• フォークの調整または抵抗。
• 特定のトランザクションやコントラクトの検閲。
• 離脱や反対をちらつかせることで、コミュニティのコンセンサスを損なう。

この極端なシナリオが発生した場合、イーサリアムコミュニティは「ソーシャルスラッシング」が答えになるかもしれないと提案しています。ソーシャルスラッシングとは、オフチェーンの社会的コンセンサスを利用して、不正行為を行ったバリデータをスラッシュすることを決定し、彼らの権力を牽制することです。しかし、そのような措置を実施するための明確な規範、手順、ツールは存在しません (セクション 4.4 参照)。

6.2 オフチェーン資産の集中化

イーサリアムは、オフチェーンの銀行口座やその他の預金で保有され、その後、オフチェーン資産に対する請求権を表すトークンを介してオンチェーンで取引される、相当量の現実世界の資産をホストしています。例えば、多くの大規模なステーブルコインがこの方法で機能しています。

オフチェーンの預金を保有する機関は、イーサリアムエコシステムに影響力を持つ可能性があります。例えば、論争の的となるフォークやネットワークのアップグレードがある極端なシナリオでは、大規模な預金者は、一方のチェーンまたは他方のチェーン上のトークンのみを認識することを選択することで、どのチェーンが広く受け入れられるかに影響を与えることができます。

6.3 規制による攻撃または圧力

政府や規制当局は、イーサリアムスタックの重要なコンポーネントを管理するさまざまな事業体に圧力をかけ、イーサリアムプロトコルを検閲したり、その他の方法で干渉したりする可能性があります。イーサリアムの機関投資家もこれらの圧力の影響を受ける可能性があり、それは彼らのユーザーにさらなる影響を及ぼすでしょう (例：規制上の禁止により特定の暗号資産製品を提供できなくなった銀行)。

6.4 組織によるガバナンスの乗っ取り

イーサリアムのオープンソースのガバナンスと開発プロセスは、コアクライアントソフトウェア、インフラストラクチャ、およびツールを維持する多様でグローバルなチームと企業のセットによって推進されています。

さまざまな形の影響力 (企業買収、資金調達への依存、主要なコントリビューターの雇用、既存の組織内の利益相反) が、イーサリアムのガバナンスの文化と優先順位を徐々に変化させる可能性があります。これは、コミュニティ主導の精神や確立されたロードマップから逸脱した特定の商業的または外部の利益との連携につながり、時間とともにイーサリアムの中立性と回復力を弱める可能性があります。