このデプロイ集中度は「イーサリアムのネットワーク自体が分散化されているかどうか」と同じ話なのか？
同じ話ではなく、これがこの研究で最も誤読されやすい点だ。イーサリアムのコンセンサス層——誰がブロックを提案し、誰がトランザクションを検証できるか——は現在、数十万の独立したバリデーターによって維持されており、この層の分散化度合いはコントラクトデプロイの集中度とは無関係である。この研究が明らかにしているのは、アプリケーション層における別種の集中である——スマートコントラクトを「誰でもデプロイできる」ことと、「実際には少数の主体が大量にデプロイし支配している」ことは、まったく別の2つの問題だ。前者はプロトコルのルールであり、後者はそのルールを使った結果として形成される実際のエコシステムの姿である。両者は互いに矛盾することなく同時に成立しうる——イーサリアムの基盤層は高度に分散化されたまま、コントラクトアプリケーション層の支配権は高度に集中している。これこそが研究チームが強調しようとしたギャップである。
なぜこのような状態になったのか？単一主体が過剰にコントラクトをデプロイすることを制限する仕組みはないのか？
イーサリアムのプロトコル自体にはそうした制限は存在せず、設ける意図もない——コントラクトのデプロイコストはガス代のみであり、理論上は誰でも無制限にデプロイできる。これは「許可不要」という設計思想の一部であり、デプロイ数を制限することはこの中核原則に反することになる。集中度が生じるのは本質的に経済的インセンティブによる自然な結果だ——ファクトリーコントラクトのパターンは、単一の開発チームが一度のコード記述で数百万のユーザーに規模を持ってサービスを提供できるようにする（NFTの一括ミント、トークンの一括発行サービスなど）。これは効率性の観点であり、意図的な独占行為ではない。
本当に注視すべきは「デプロイ数が制限されているかどうか」ではなく、「透明性が十分かどうか」だ。研究では、上位10のデプロイヤーコントラクトのうち6個は公開検証済みのソースコードを持っていたが、未検証の4個のコントラクトが合計478万件の子コントラクトを支配していた——これこそがガバナンス面で本当に補強すべきギャップである。大量デプロイを禁止することではなく、大量デプロイヤーのコードを公開検証可能にすることが求められている。
一般ユーザーは、あるコントラクトがプロキシパターンかどうか、支配権が過度に集中していないかを自分で確認するにはどうすればよいか？
最も直接的な第一歩は、Etherscanで該当コントラクトアドレスを検索し、「Contract」タブ内の「Read as Proxy」または「Is this a proxy?」の表示を確認することだ——Etherscanが自動的にプロキシと検出した場合、通常は対応する実装コントラクトアドレスが表示され、さらにその実装コントラクトのデプロイヤーや直近のアップグレード履歴を追跡できる。第二段階は、コントラクトの「Code」タブでソースコードが検証済み（Verified）かどうかを確認することだ。未検証のコントラクトはコンパイル済みのバイトコードしか見えず、ロジックを直接読み取れないため、リスク評価の難易度が大幅に上がる。
第三段階、そして最も見落とされがちなのが、アップグレード権限を誰が握っているかを確認することだ——支配アドレスが一般的な外部所有アカウント（EOA）であり、マルチシグウォレットでない場合、アップグレードの決定は理論上、単一の秘密鍵だけで実行できることを意味する。これは、複数の署名者による共同承認が必要なマルチシグガバナンスのコントラクトとはリスクレベルがまったく異なる。これらの情報は通常、Etherscan上でコントラクトの「Read Contract」機能と過去のトランザクション履歴を突き合わせて初めて把握できるものであり、「このコントラクトは安全か危険か」を直接教えてくれる単一のページは存在しない。
利用しているプロトコルが大量の未文書化コントラクトに依存していることが分かった場合、何をすべきか、あるいは何をすべきでないか？
即座にパニック的に資産を引き出す必要はないが、この発見を無視するのではなく「もう一段階の調査をすべき」というシグナルとして扱う価値はある。第一に、これらの未文書化コントラクトのソースコードが検証済みかどうかを確認する——検証済みであれば、少なくともロジックは公開され検証可能であり、完全にブラックボックスの未検証コントラクトよりもリスクははるかに低い。第二に、このプロトコルが過去にセキュリティインシデントを起こしたことがあるか、監査報告書がこれらの周辺コントラクトをカバーしているか、それとも公式文書に記載された中核コントラクトのみを監査対象としているかを確認する——監査範囲が実際の依存コントラクトリストより明らかに狭い場合、あなたが実際に負っているリスクは、監査報告書が表面的に示す安全レベルよりも高い可能性がある。
第三に、これはプロキシパターンやファクトリーコントラクトを使用するすべてのプロトコルを完全に避けるべきだという話ではない——実際、主流のDeFiプロトコルのほとんどがこれらのパターンを使用しており、完全な回避は現実的ではない。より実践的なアプローチは、「このプロトコルの中核コントラクトの支配権が単一の鍵に集中していないか」という問いを、すでにチェックしているであろう「TVLの規模」「監査回数」と同じチェックリストに加えることであり、後者2つだけに頼らないことだ。
イーサリアムはしばしば「許可不要、誰でもデプロイ可能」な分散型プラットフォームと表現される。これは技術的には正しい——実際、誰でもスマートコントラクトをデプロイできる。しかし「これらのコントラクトを実際に誰が支配しているか」という角度から切り込むと、オンチェーンデータは別の物語を語る。2024年末時点で、イーサリアムメインネットには4,119万9,800件の存続中のスマートコントラクトが存在し、そのうちわずか11個のデプロイヤーアドレスが2,050万件、ちょうど50%を直接デプロイしていた。上位100デプロイヤーまで範囲を広げると、この数字は80%を超える。これはKTH王立工科大学の研究チームによる、4,100万件超のコントラクトと110億回のコントラクト間相互作用を対象とした大規模実証分析によるもので、イーサリアムのコントラクトデプロイ集中度に関する現時点で最大級の公開研究の一つである。
この規模の集中度を可能にしているのは「ファクトリーコントラクト」パターンである——1つのコントラクトがCREATEまたはCREATE2オペコードを通じて、手動でトランザクションを起こすことなく、数千もの子コントラクトをプログラム的にデプロイできる。研究によると、上位100デプロイヤーのうち83個はEOA（人間が管理するアカウント）ではなくコントラクト自体であり、最も多産な単一ファクトリーコントラクトは430万件の子コントラクトをデプロイし、これは存続コントラクト全体の10%に相当する。これが「コントラクト数が膨大であること」と「開発者・運営者数が膨大であること」がまったく別の話である理由だ——膨大な数のコントラクトの背後には、ごく少数の運営主体しか存在しない場合がある。
上位10デプロイヤーのうち8個は主に「プロキシコントラクト」をデプロイしている——この設計では、子コントラクトはDELEGATECALLオペコードを通じて実行ロジックを中央集権的な実装コントラクトに委任し、自らはロジックを保持しない。この方式の利点はアップグレードの容易さにある——実装コントラクトを更新するだけで、すべての子コントラクトの挙動が同期して変わり、個別に移行する必要がない。しかしその代償は集中化された支配権だ——デプロイヤーの鍵や権限が侵害されれば、攻撃者は理論上、この実装コントラクトに依存するすべての子コントラクトを一度に操作できる。これは理論上の話ではない。2025年のZothプロトコル事件では、攻撃者が侵害されたデプロイヤーウォレットのプロキシコントラクトに対する管理権限を悪用し、悪意ある委任ロジックをデプロイしたことで、840万ドル相当の資産が盗まれた。
研究チームはまた、2つの主要なDeFiプロトコル——UniswapとLido——について、公式ドキュメントで開示されているコントラクトアドレスが、実際にオンチェーンで相互作用しているコントラクトアドレスと一致しているかを検証した。結果はこうだ——Uniswapの公式ドキュメントに記載されたコントラクトが実際に相互作用する外部コントラクトのうち、18件が「プロトコル内であるがドキュメントに記載されていない」ものだった。Lidoの状況はさらに顕著で、関連する依存コントラクト78件のうち25件が公式ドキュメントに現れていなかった。つまり、ユーザーの信頼度が高く監査記録も充実している主要プロトコルであっても、オンチェーン上の実際のコントラクト依存関係は、公式ドキュメントが示すよりも複雑で不透明である可能性がある。
もしあなたの資産が特定のDeFiプロトコルに預けられているなら、あなたが信頼しているのはそのプロトコル自体のコードだけでなく、それが依存しているすべての基盤コントラクトでもある——そしてこれらの依存関係は、プロトコル自身の公式ドキュメントですら完全に開示していない可能性がある。資産をどのプロトコルに預ける前でも、監査を受けているかどうかを確認するだけでなく、より鋭い問いを投げかける価値がある——このプロトコルの中核コントラクトはアップグレード可能なプロキシなのか？もしそうなら、アップグレード権限を管理しているのは誰か——単一の鍵か、マルチシグか？これらの答えは通常、Etherscanのコントラクトページの「Contract」タブで確認でき、単に「これはイーサリアム上のコントラクトか」よりも、あるプロトコルがどれだけ分散化されているかを判断する上でより的確な問いとなる。