セキュリティ課題の概要

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

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

これらの要件のそれぞれが、鍵の漏洩や紛失、急いだ承認や情報不足による承認、またはイーサリアムとのやり取りにおいてユーザーに情報を提供しガイドするために依存しているウォレット・ソフトウェアの侵害といったリスクをもたらします。

1.1 鍵管理

多くのユーザーは、暗号鍵を安全に管理するための備えができていません。

最も広く使用されているソフトウェア・ウォレットは、基盤となる暗号化された秘密鍵を表すシードフレーズをユーザーが安全に保管することに依存しています。そのため、シードフレーズをプレーンテキストで保存したり、クラウドサービスに保存したり、紙に書き留めたりといった、安全でない回避策を使用することがよくあります。

ハードウェア・ウォレットは代替手段であり、ユーザーは専用の物理デバイス内に保存された暗号鍵を管理できます。しかし、ハードウェア・ウォレットにも独自の欠陥や攻撃対象領域があります。ハードウェア・ウォレットは紛失、破損、または盗難に遭う可能性があります。多くのハードウェア・ウォレットはオープンソースではなく、サプライチェーンが不透明である可能性があり、侵害されたデバイスが市場に販売されるサプライチェーン攻撃のリスクを高めます。

鍵がソフトウェア・ウォレットで管理されているかハードウェア・ウォレットで管理されているかにかかわらず、物理的な盗難や襲撃によって侵害される可能性がある場合、多くのユーザーが自己管理(セルフカストディ)に不安を感じるのは当然のことです。

企業や機関のユーザーは、鍵管理においてさらなる課題に直面しています。個々の従業員が鍵を保持している場合(例: マルチシグ・ウォレットの一部として)、組織は時間の経過に伴う人事異動のために、それらを置き換えて新しい鍵を作成できなければなりません。さまざまな業界や管轄区域のコンプライアンス要件により、既存のウォレット・ソフトウェアではサポートされていないカスタムワークフローや監査証跡が必要になる場合があります。場合によっては、企業のユーザーはデジタル資産をサードパーティのカストディアンに委託しますが、これにより考慮すべき別のセキュリティリスクの層が生じる可能性があります。

1.2 ブラインド署名とトランザクションの不確実性

ユーザーは日常的に、自分が何をしているのかを理解せずに「盲目的に」トランザクションを承認しています。ウォレットは多くの場合、生の16進数データ、切り捨てられたコントラクトのアドレス、またはユーザーが特定のトランザクションの結果を理解するのに十分ではないその他の情報を提示します。これにより、あらゆる種類のユーザーが悪意のあるスマート・コントラクト、フィッシング、詐欺、なりすましインターフェース、フロントエンドの侵害、および基本的なユーザーエラーに対して脆弱になります。

1.3 承認と権限の管理

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

これらの承認には金額の制限を設けることができますが、多くのウォレットではデフォルトで有効期限のない無制限の承認が付与されます。ほとんどのウォレット内から、ユーザーが未処理の承認を管理または確認する方法はありません。

多くのユーザーのデフォルトのパターンは、資金を流出させるために使用される可能性のある無制限の承認を付与することであるため、これによりユーザーは悪意のあるアプリや侵害されたフロントエンドにさらされる可能性があります。ユーザーが正当なスマート・コントラクトに承認を付与した場合でも、承認が有効なままそのコントラクトが後で侵害された場合、侵害されたコントラクトがユーザーの資金を流出させる可能性があります。

これは組織のユーザーにとっても同様にリスクとなります。たとえば、組織が運用の利便性のためにDEXルーターに無制限のUSDCアローワンスを付与することを選択した場合、ルーターのコントラクトがアップグレードされるとリスクにさらされることになります。

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

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

これらのフロントエンドは、DNSハイジャック、悪意のあるJavaScriptインジェクション、安全でないホスティング、またはさまざまなサードパーティの依存関係など、よく知られた手段による攻撃に対して脆弱になる可能性があります。侵害されたアプリのUXは、あらゆる種類のユーザーを悪意のあるスマート・コントラクトにリダイレクトしたり、誤解を招くトランザクションに署名させたりする可能性があります。

1.5 プライバシー

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

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

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

1.6 断片化

トランザクションの表示、承認の処理、コントラクトのラベル付けなどのコアな動作を、異なるウォレットがどのように処理するかについて一貫性が欠如しています。このユーザーエクスペリエンスの断片化は、ユーザーがウォレットを安全に使用する方法を学ぶ能力に摩擦をもたらし、リスクを増大させます。

たとえば、フィッシングやなりすましから身を守るためのUXの手がかりはウォレット間で異なるため、ユーザーは一貫した手がかりに頼ることができません。各ツールが異なる機能を持つ場合、ユーザーはイーサリアムがどのように機能するかについて信頼できる期待を形成することができません。

スマート・コントラクトのセキュリティは、イーサリアムの歴史の中で飛躍的に向上しました。The DAOハックのような初期のセキュリティインシデントは、コードがオンチェーンにデプロイされるまでのソフトウェア・ライフサイクル全体にわたって、エコシステムが専門化し、安全対策を改善する動機となりました。主な進歩には以下のものがあります。

• セキュリティ監査が標準的な慣行となり、いくつかのセキュリティ企業がエコシステムに参入し、専門知識を開発しました。
• ツール、テスト、および静的解析システムが成熟し、標準的な慣行となりました。
• 事前監査済みの共通コンポーネントのライブラリにより、開発者はデフォルトで安全なビルディングブロックを利用できるようになりました。
• 特にブリッジ、ステーキング・システム、および高価値のコントラクトにおいて、形式的検証の手法が採用されました。
• エコシステムのセキュリティ文化とベストプラクティスが向上しました。
• アプリ層を強化する大規模なバウンティプログラムが創設されました。

しかし、この分野には依然として弱点や改善の余地が残されています。

2.1 コントラクトの脆弱性

スマート・コントラクトのセキュリティの進歩にもかかわらず、重大なセキュリティ問題につながる可能性のある脆弱性が依然として存在します。これには以下が含まれます。

• コントラクトのアップグレードリスク. 一部のコントラクトは、開発チームがアプリケーションの更新と改善を継続できるように、デプロイ後に変更可能に設計されています。しかし、これはリスクをもたらします。アップグレードによって新たな脆弱性が生じたり、悪意のあるアップグレードの場合にはユーザーの資金が完全に失われたりする可能性があります。
• リエントランシー (再入可能性), コントラクト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のパフォーマンスとセキュリティを評価および比較する詳細なフレームワークと監視ダッシュボードについては、L2BEAT (opens in a new tab)を参照してください。

3.2 RPCおよびノードインフラ

イーサリアムのアプリケーションは、RPCアクセス、API、およびノードサービスにおいて少数のインフラプロバイダーに依存しています。これには、暗号資産特有のインフラプロバイダーだけでなく、ノードのホストに一般的に使用される従来のクラウドサービス（AWS、Cloudflare、Hetznerなど）も含まれます。

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

3.3 DNSレベルの脆弱性

ドメインネームシステム（DNS）はインターネットの基盤となるレイヤーですが、中央集権的であり、侵害される可能性もあります。多くのユーザーはウェブドメインを通じてアプリにアクセスしますが、これらは以下の影響を受けやすいです。

• 攻撃者が悪意のある偽のフロントエンドを挿入する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、プロポーザー・ビルダー分離 (PBS)、またはリキッド・ステーキングの設計におけるエッジケースのインセンティブの悪用。アクターは、過大な報酬を得るために稀なプロトコルの条件を操作する可能性があります。

4.6 量子リスク

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

耐量子暗号技術への移行パス（耐量子署名スキームなどを経由）は、必要になる何年も前に設計、テストされ、場合によってはプロトコルに組み込まれる必要があります。イーサリアム財団を含むイーサリアムのエコシステム全体の組織は、これらの選択肢を積極的に模索し、リスクを監視しています。

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

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

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

6.1 ステークの中央集権化

大量のステークが中央集権化することは、そのステークを管理する事業体が共謀した場合、イーサリアム全体にリスクをもたらす可能性があります。
この経済的な中央集権化は、ソーシャルガバナンスの掌握の可能性を生み出します。少数のバリデータのグループがステークのスーパーマジョリティを支配した場合、彼らは以下のことを行う可能性があります。

• フォークの調整または抵抗。
• 特定のトランザクションやコントラクトの検閲。
• エグジットや反対を脅かしてコミュニティのコンセンサスを弱体化させる。

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

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

イーサリアムはかなりの量のリアル・ワールド・アセット (RWA) をホストしており、資産は銀行口座やその他の預金としてオフチェーンで保持され、オフチェーン資産に対する請求権を表すトークンを介してオンチェーンで取引されます。例えば、多くの大規模なステーブルコインはこのように機能します。

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

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

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

6.4 組織によるガバナンスの掌握

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

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