Web3の「理論上の分散化」と「実運用上の分散化」
対象： Ethereum、L2、DeFi、DAO、Web3インフラ
調査日： 2026年8月13日（JST）
対象依存： Cloud、RPC、validator、sequencer、bridge、token ownership、governance、front-end、stablecoin、oracle
要旨
EthereumやDeFiを「分散化している」と呼べるかは、どの機能について問うかで答えが変わる。Ethereum L1は、公開ルールに従うフルノード検証と複数validatorによる合意を可能にするという意味で、理論上は高い分散性を持つ。[1] しかし通常の利用者が触れる経路は、front-end、DNS/CDN、RPC、Cloud、wallet UI、L2 sequencer、bridge、stablecoin発行体、oracle、DAOの委任・管理鍵を介する。したがって、状態検証の無許可性と、利用・順序付け・外部データ・資産償還・設定変更からの独立性を同一視してはならない。
本調査の結論は、「Web3は中央集権的である」でも「分散化している」でもない。より正確には、コアの状態検証は比較的分散され得る一方、通常のアクセス、取引順序、クロスチェーン移転、外部データ、法定通貨連動資産、アップグレード、実効ガバナンスには、少数主体へ集中しやすい依存が残るということである。[2] [3] この差は、検閲、停止、誤価格、出金遅延、凍結、アップグレード、流動性・投票権の捕捉が起きたときに表面化する。
重要な区別： 「単一主体が状態を恣意的に書き換えられない」ことは、ユーザーが「少数サービスに依存せずに到達・送信・回復・償還・意思決定できる」ことを保証しない。
1. 評価の枠組み
本報告では、理論上の分散化を、仕様上は複数の独立主体が参加・検証・退出でき、単一主体が状態を一方的に変更できない性質と定義する。実運用上の分散化は、通常の利用者が少数企業・団体・鍵保持者・クラウド・発行体に依存せず、アクセス、送信、検証、回復、償還、異議申立てを現実的なコストで行える状態と定義する。
| 評価軸 | 中心となる問い | 分散していても残り得る集中依存 |
|---|---|---|
| 制御 | 誰が設定変更、停止、アップグレード、資金移動を決めるか | multisig、upgrade key、緊急権限、財団、delegate |
| 実行 | 誰が取引を順序付け、検証し、状態を作るか | block builder、relay、sequencer、bridge validator |
| アクセス | ユーザーはどの窓口を通るか | RPC、API key、DNS、CDN、gateway、wallet UI |
| 経済 | 誰が担保、流動性、投票権、MEVを支配するか | whale、exchange、treasury、LP、staking operator |
| 真実性 | 外部データ、資産状態、本人属性を誰が確定するか | oracle、データベンダー、保管者、stablecoin発行体 |
| 回復 | 停止・検閲・不正時にユーザーは代替経路で回復できるか | force inclusion、escape hatch、自己ノード、代替UI、償還請求 |
2. 依存関係図
図の読み方： 緑はプロトコル上比較的分散可能な要素、黄は分散性が設計・導入状況に依存する要素、赤は通常運用で集中依存が残りやすい要素を表す。赤は不正・脆弱性を意味しない。むしろ、停止・検閲・誤作動・規制介入・運営変更の影響が少数主体へ集まりやすい箇所を表す。
図が示す最重要点は、Cloud、RPC、front-end、sequencer、bridge、oracle、stablecoin、governanceが別々の問題ではないことである。たとえば、L2上のDeFi利用は通常、wallet UI → DNS/CDN → RPC → sequencer → DA → L1 → oracle/stablecoin → DeFi contractという連鎖を通る。contractが無許可であっても、この連鎖の一部が止まれば、通常利用、価格評価、資金移動、回復のいずれかが阻害される。
3. レイヤー別の比較
| レイヤー | 理論上の分散化 | 実運用で残る集中依存 | 主な影響 | 総合評価 |
|---|---|---|---|---|
| Cloud・ノード運用 | 誰でもノード・validatorを運用できる | 同一Cloud、リージョン、運用自動化、クライアントの相関 | 相関停止、遅延、同一障害ドメイン | 条件付き |
| RPC | 自前ノードへ無許可接続できる | Node-as-a-Service、APIキー、DNS、レート制限 | 読取・送信・wallet接続・DApp可用性の停止 | アクセスは高リスク |
| validator・client・PBS | 複数validatorが状態を検証できる | staking operator、client、host、builder、relay | liveness、取引順序、検閲、MEV、相関バグ | コアは分散可能、順序付けは条件付き |
| L2 sequencer・DA | L1への状態コミットメントと回復経路を設計できる | 単一sequencer、DAC、upgrade key、運営インフラ | 取引停止、検閲、出金遅延、状態再構築不能 | 実用回復性が鍵 |
| bridge | 複数チェーン間を検証して移転できる | signer、validator set、relayer、保管、admin key | 資産凍結、不正鋳造、メッセージ停止 | 非常に高リスク |
| token ownership・DAO | 保有者が提案・投票で制御する | whale、取引所、treasury、delegate、提案権、multisig | 実効支配、更新、資金移動、パラメータ変更 | 投票形式だけでは不十分 |
| front-end・DNS・CDN | contractを直接呼び出し、コンテンツを分散保存できる | ドメイン、CDN、gateway、署名済み配布、wallet UI | 通常入口の停止、改竄、地域検閲、フィッシング | アクセスは高リスク |
| stablecoin | 一部はオンチェーン担保・ルールベース発行を目指す | issuer、銀行、custodian、reserve、凍結、償還、oracle | 決済・担保・流動性・清算への波及 | 非常に高リスク |
| oracle | 複数ノード・集計で分散提供できる | データソース、node operator、集計式、更新、鍵、ガバナンス | 誤価格、清算、担保評価、RWA状態誤認 | 非常に高リスク |
3.1 Ethereum：合意の分散性と「最終マイル」の集中
Ethereumのフルノードはブロック本体と状態データを取得・検証するため、利用者または組織が自前ノードを運用すれば、RPC事業者の返す状態を独自に確認できる。[1] ただし、これは一般利用者が自前ノードを運用していることを意味しない。RPC／Node-as-a-Service研究はこの層を「ブロックチェーンのlast mile」と捉え、DNS攻撃によるサービス混乱の例も扱う。[4] したがってRPC集中は、通常はL1状態を直接書き換える支配ではないが、ユーザーの見える情報、送信経路、速度、可用性、検閲可能性に影響するアクセス層の集中である。
validator数の多さも十分な指標ではない。集中制御を測る研究は、Ethereumのモジュラー化後にはvalidatorだけでなく、stake、client、host、relay、builder、ガバナンスを分けて観察する必要を示す。[2] PBS下では、validatorが多数であってもblock builderやrelayが取引順序とMEVに強い影響を持ち得る。builder市場の分散化研究と、relayを除去するDPaaS提案は、このプロトコル外の中間層が残す集中依存を明示している。[3] [5]
3.2 L2：L1アンカーと回復可能性は同義ではない
L2はL1にstate commitmentを投稿できるため、しばしば「Ethereumの安全性を継承する」と説明される。しかしDA研究は、状態検証に必要なデータが利用できず、悪意ある運用者が存在する場合、利用者はL1から資金を引き出せない可能性があると整理する。[6] つまり実態的な分散性は、L1へ投稿しているかではなく、sequencerが止まった／検閲したときに強制包含できるか、DAが失われたときに状態を再構築できるか、アップグレード権限が誰にあるかで評価する必要がある。
L2BEATのStagesとRisk Analysisは、少数主体が制御する段階と、escape hatch・分散sequencer setを明示的に区別する。[7] この評価は、単一sequencerを持つL2を直ちに無価値とみなすものではない。代わりに、通常の高速な経路が中央集権的であっても、緊急時の無許可回復がどの程度機能するかを問う。bridgeはさらに独立の信頼境界であり、中央型bridgeが単一主体または主体群により資産移転を管理・制御するという研究整理は、L2の安全性がbridgeの安全性を自動的に継承しないことを示す。[8]
3.3 DeFi・stablecoin・oracle：コードの分散性と経済状態の集中
DeFi contractは公開され、誰でも相互作用できる場合がある。しかしDeFiの経済的状態は、token ownership、流動性、oracle、stablecoin、bridge、ガバナンスに依存する。586のDeFi tokenを対象とする研究は、富の集中がもたらすリスクを分析しており、保有の分散と実効支配を同一視できないことを示す。[9] DAOの委任投票研究も、委任が参加を補う一方で、少数delegateに影響力を集中させ得ることを示唆する。[10]
stablecoinは特に横断的な依存である。一部のstablecoinでは発行体がアドレスを凍結できるため、トークンはon-chainで移転可能でも、利用可能性は発行体の権限・コンプライアンス・準備資産・償還窓口に依存し得る。[11] DeFiの担保・決済・LPがこのようなassetに大きく依存する場合、発行体の判断は複数の無許可contractへ経済的に伝播する。
oracleも同じ構造を持つ。oracle研究は、DeFi DAppが中央化または安全でないデータソースに依存すると、投下資本がリスクにさらされると論じる。[12] 分散oracle networkであっても、データベンダー、node operator、集計式、更新頻度、キー管理、ガバナンスが集中していれば、価格・担保価値・清算閾値の「真実性」は少数の運用・情報源に依存する。stablecoinの価格oracle測定研究も、オンチェーン担保型stablecoinが担保価値を決めるためにprice oracleへ依存することを前提に精度とガバナンス堅牢性を検証している。[13]
3.4 DAO：形式的な投票と実効支配の差
DAOの理論上の分散性は、公開提案・オンチェーン投票・timelock・透明なtreasuryにある。しかし実効支配は、保有集中、取引所・custody口座、委任、提案能力、情報優位、投票参加率、delegate報酬、core team、multisig、upgrade keyへ分散している。したがって「投票が存在する」ことは「統治が分散している」ことを意味しない。2026年の研究がDAOのガバナンス集中を体系的に記録することを目的にしている点は、実効支配の測定が依然として主要課題であることを示す。[14]
DAOでは、投票、直接管理鍵、緊急権限を分ける必要がある。投票で変更される規則は広く正当化され得るが、危機時に少数multisigが即時停止・資金移動・アップグレードを行える場合、短期の運用回復力と長期の権限集中がトレードオフになる。このトレードオフは隠すべき「例外」ではなく、期限、権限範囲、監査ログ、解除条件、fork／退出可能性を用いて測るべき設計変数である。
4. 集中依存の障害伝播
| 連鎖 | 典型的な起点 | 伝播の仕組み | ユーザーへの結果 |
|---|---|---|---|
| アクセス停止連鎖 | DNS、CDN、wallet UI、RPC、Cloud | 通常入口と送信経路が止まり、正しいcontract状態へ到達できなくなる | 「オンチェーンは稼働中だが使えない」。代替UI・自前RPCの準備がない利用者は実質停止。 |
| 順序付け・検閲連鎖 | builder/relay、sequencer、MEVの集中 | 取引順序、包含、遅延が少数実行者に依存する | サンドイッチ、優先取引、取引遅延、L2検閲、強制包含待機。 |
| 回復不能連鎖 | sequencer停止、DA欠落、upgrade key | 状態再構築、proof、強制退出、bridgeメッセージの一部が機能しない | 出金遅延・停止、L2資産の流動性分断、bridge依存の資産が拘束。 |
| 経済状態連鎖 | oracle誤価格、stablecoin凍結／償還問題 | 価格、担保率、清算、LP、RWA評価が同じ外部真実性に依存する | 清算、担保不足、取引停止、複数DeFi protocolへの同時波及。 |
| ガバナンス捕捉連鎖 | token集中、delegate集中、multisig・管理鍵 | 提案、投票、資金、upgradeが同一少数主体に集まる | ルール変更、手数料・担保条件変更、資金移動、検閲方針の集中。 |
5. 何をもって「より実態的に分散化した」と判断するか
実態的な改善は、単にvalidator数やtoken holder数を増やすことではない。次の5つのテストを同時に満たす度合いで評価すべきである。
| テスト | 実務上の確認事項 |
|---|---|
| 独立到達性 | 主要front-end、DNS、RPCが停止しても、ユーザーは公開情報だけで代替UI・代替RPC・自前ノードへ到達できるか。 |
| 独立検証性 | ユーザーまたは第三者が、単一API・oracle・発行体の主張ではなく、状態・proof・データ来歴を検証できるか。 |
| 独立回復性 | sequencer、bridge、issuer、管理者が停止・悪意化しても、合理的な期間と費用で資産・状態を回復できるか。 |
| 実効支配の分散 | token保有者数ではなく、提案、委任、投票、管理鍵、upgrade、流動性、情報アクセスの集中を測っているか。 |
| 相関障害への耐性 | Cloud、client、RPC、oracle、stablecoin、bridgeの共通依存が同時に失敗したときの耐性をテストしているか。 |
6. 結論
Ethereum、DeFi、DAO、Web3 infrastructureを評価する際は、「分散化」という一語を分解しなければならない。Ethereum L1の無許可検証は重要な土台だが、それだけではユーザーのアクセス、取引順序、外部データ、法定資産償還、L2回復、ガバナンスが少数主体から独立していることを意味しない。最も重要な研究・監査上の問いは、少数の主体が停止・検閲・誤作動・方針変更を行った場合に、どの状態遷移が止まり、誰が代替し、ユーザーがどのコストで回復できるかである。
今後の実証は、単一の「分散化スコア」よりも、アクセス、制御、実行、経済、情報、回復の6軸を結ぶ依存グラフと、障害注入テストを中心にすべきである。これにより、プロトコル上の分散性を否定せず、実運用で残る集中依存を測定・比較・低減できる。
参考文献
[1] Ethereum Foundation, Nodes and Clients
[2] Brown et al. (2023), Measuring the Concentration of Control in Contemporary Ethereum
[3] Decentralization of Ethereum's Builder Market (2025)
[4] Luo, Murukutla, & Kate (2022), Last Mile of Blockchains: RPC and Node-as-a-Service
[5] Liu et al. (2025), DPaaS: Improving Decentralization by Removing Relays in Ethereum PBS
[6] Saif, Migliorini, & Spoto (2024), A Survey on Data Availability in Layer 2 Blockchain Rollups
[7] L2BEAT, Stages L2BEAT, Risk Analysis
[8] Blockchain Cross-Chain Bridge Security: Challenges, Solutions and Future Outlook (2024)
[9] DeFi: Mirage or Reality? Unveiling Wealth Centralization Risk in Decentralized Finance (2025)
[10] Weidener et al. (2025), Delegated Voting in Decentralized Autonomous Organizations
[11] Chainlink, Stablecoins
[12] Caldarelli et al. (2022), Overview of Blockchain Oracle Research
[13] Gu et al. (2021), Empirical Measurements on Pricing Oracles and Decentralized Governance for Stablecoins
[14] Centralized Governance in Decentralized Organizations (2026)