Ethereumエコシステムの全体像

Mar 29, 2026

Ethereumはブロックチェーンの一つだが、その上に構築されたエコシステムは広い。EVM、ウォレット、ノード、Layer 2、開発ツール——それぞれが何を担っていて、どう繋がっているのかを整理する。

全体像

graph TB
    User[ユーザー]

    subgraph アプリケーション層
        DApp["DApps（フロントエンド）<br/>Uniswap / Aave / OpenSea"]
        Wallet[ウォレット<br/>MetaMask / Rabby]
        Lib[ライブラリ<br/>ethers.js / viem / wagmi]
    end

    subgraph インフラ層
        RPC[RPCプロバイダ<br/>Alchemy / Infura / QuickNode]
        Node[ノード<br/>Geth / Nethermind]
    end

    subgraph プロトコル層
        EVM[EVM<br/>スマートコントラクト実行]
        Consensus[コンセンサス<br/>Proof of Stake]
        Storage[ステート<br/>アカウント / ストレージ]
    end

    subgraph Layer2["Layer 2"]
        L2[Rollup<br/>Arbitrum / Optimism / Base]
        Bridge[ブリッジ<br/>L1 ⇔ L2 資産移動]
    end

    subgraph 開発ツール
        Foundry[Foundry<br/>forge / cast / anvil]
        Hardhat[Hardhat]
        Explorer[ブロックエクスプローラ<br/>Etherscan / Blockscout]
    end

    User -->|操作| DApp
    DApp -->|署名リクエスト| Wallet
    Wallet -->|署名済みTx送信| RPC
    DApp --> Lib
    Lib -->|JSON-RPC| RPC
    RPC --> Node
    Node --> EVM
    EVM --> Consensus
    EVM --> Storage

    L2 -->|データ投稿・証明| Node
    Bridge --> L2
    Bridge --> Node

    Foundry -->|テスト・デプロイ| RPC
    Hardhat -->|テスト・デプロイ| RPC
    Explorer -->|読み取り| Node

アプリケーション層

DApps

DApps（分散型アプリケーション）はスマートコントラクトをバックエンドとするアプリケーション。ユーザーから見える部分は通常のWebアプリと変わらないが、コアのロジックとデータがブロックチェーン上にある。フロントエンドは一般的なWeb技術（React、Next.jsなど）で構築され、ブロックチェーンとの通信にはethers.js、viem、wagmiといったライブラリを使い、JSON-RPCプロトコルでノードとやり取りする。

ウォレット

ユーザーがEthereumと接続するための入口。秘密鍵の管理、トランザクションへの署名、残高の表示を担う。

ウォレット自体はブロックチェーン上に存在するわけではない。秘密鍵をローカル（ブラウザ拡張、モバイルアプリ、ハードウェアデバイス）に保持し、ユーザーの操作に応じて署名を生成するクライアントサイドのソフトウェア。DAppsのフロントエンドから署名リクエストを受け取り、ユーザーが承認すると署名済みのトランザクションをRPCプロバイダに送信する。

MetaMask: ブラウザ拡張型ウォレットの代表格。Chrome、Firefox、モバイルに対応
Rabby: マルチチェーン対応。トランザクションのシミュレーション表示が特徴
Ledger / Trezor: ハードウェアウォレット。秘密鍵がデバイス外に出ない設計

sequenceDiagram
    actor User as ユーザー
    participant FE as フロントエンド
    participant Wallet as ウォレット
    participant RPC as RPCプロバイダ
    participant Node as ノード
    participant EVM as EVM

    User->>FE: 「Swap」ボタンをクリック
    FE->>Wallet: 署名リクエスト
    Wallet->>User: トランザクション内容を表示
    User->>Wallet: 承認
    Wallet->>RPC: 署名済みトランザクション送信
    RPC->>Node: トランザクション転送
    Node->>EVM: コントラクト実行
    EVM->>Node: 実行結果
    Node->>RPC: トランザクションレシート
    RPC->>FE: レシート返却
    FE->>User: 結果を画面に表示

インフラ層

ノード

Ethereumネットワークを構成する個々のコンピュータ。ブロックチェーンのデータを保持し、トランザクションを検証・実行する。

実行クライアント（Geth、Nethermind、Besu）: トランザクションの実行とステート管理を担当
コンセンサスクライアント（Prysm、Lighthouse、Teku）: Proof of Stakeによるブロック生成と合意形成を担当

Ethereumでは2022年のThe Merge以降、実行クライアントとコンセンサスクライアントの両方を動かす必要がある。

RPCプロバイダ

自前でノードを運用せずにEthereumにアクセスするためのサービス。DAppsやウォレットからのJSON-RPCリクエストを受け付け、背後のノードで処理して結果を返す。

Alchemy: 開発者ツール（デバッグAPI、Webhook）が充実
Infura: ConsenSys（MetaMaskの開発元）が運営。歴史が長い
QuickNode: マルチチェーン対応。高速なレスポンスが特徴

RPCプロバイダへの依存は、分散性とのトレードオフになっている。多くのDAppsがAlchemyやInfuraに依存しており、これらのサービスが停止するとDAppsも動かなくなるリスクがある。

プロトコル層

EVM（Ethereum Virtual Machine）

スマートコントラクトを実行するための仮想マシン。詳細はEVMの用語ページを参照。

コンセンサス（Proof of Stake）

ネットワーク参加者がどのブロックを正しいと認めるかの合意形成の仕組み。バリデータが32 ETHをステーキングし、ブロックの提案と検証を行う。不正な行為にはスラッシング（ステーキングの没収）というペナルティがある。

ステート

Ethereumの「現在の状態」を表すデータ。すべてのアカウントの残高、コントラクトのストレージ、ノンスなどが含まれる。トランザクションが実行されるたびにステートが更新され、その結果がブロックに記録される。

Layer 2

Ethereumのスケーラビリティ問題を解決するために、メインチェーン（Layer 1）の外でトランザクションを処理し、結果だけをL1に記録するアプローチ。

graph LR
    subgraph L1["Layer 1 - Ethereum"]
        L1Node[Ethereum Mainnet]
    end

    subgraph L2["Layer 2"]
        Arbitrum[Arbitrum]
        Optimism[Optimism]
        Base[Base]
    end

    subgraph Users["ユーザー"]
        U1[低手数料で取引]
    end

    U1 --> Arbitrum
    U1 --> Optimism
    U1 --> Base
    Arbitrum -->|データ投稿| L1Node
    Optimism -->|データ投稿| L1Node
    Base -->|データ投稿| L1Node

Optimistic Rollup

トランザクションを「正しい」と仮定して処理し、一定期間（通常7日間）の異議申し立て期間を設ける方式。Arbitrum、Optimism、Baseが採用している。

ZK Rollup

ゼロ知識証明を使ってトランザクションの正当性を数学的に証明する方式。異議申し立て期間が不要なため、L1への確定が速い。zkSync、StarkNetなどが採用している。

ブリッジ

Layer 1とLayer 2の間、またはLayer 2同士の間で資産を移動するための仕組み。L1にトークンをロックし、L2で対応するトークンを発行する、というパターンが一般的。ブリッジのスマートコントラクトに大量の資産がロックされるため、攻撃対象になりやすい。

開発ツール

Foundry

Rust製の開発ツールチェーン。コンパイル・テスト・デプロイ・チェーンとの対話をCLIで完結できる。

forge: コンパイルとテスト
cast: トランザクション送信やデータ読み取り
anvil: ローカルテストノード

Hardhat

JavaScript / TypeScript製の開発環境。プラグインエコシステムが豊富で、フロントエンド開発者にとって馴染みやすい。

ブロックエクスプローラ

ブロックチェーン上のトランザクション、アドレス、コントラクトを検索・閲覧するためのWebサービス。

Etherscan: Ethereum最大のエクスプローラ。コントラクトのソースコード検証機能も提供している
Blockscout: オープンソースのエクスプローラ。多くのL2チェーンで採用されている

エコシステムの全体感

ここまで見てきた各層は独立しているようで、密接に依存し合っている。

ユーザーはウォレットを通じてDAppsにアクセスし、DAppsはライブラリを通じてRPCプロバイダに接続し、RPCプロバイダはノードに問い合わせ、ノードはEVMでコントラクトを実行する。Layer 2はこのスタックと並列に動きながら、最終的にはLayer 1に依存している。

どの層が欠けてもエコシステムは機能しない。そして各層にそれぞれの課題が残っている。

ウォレットのUX

秘密鍵やシードフレーズの管理がユーザーに委ねられており、紛失すると資産を永久に復元できない。承認画面には16進数のアドレスやガス設定が並び、「何が起きるのか」を直感的に把握しにくい。アカウント抽象化（ERC-4337）による改善が進みつつあるが、銀行アプリのように「何も考えなくても安全に使える」状態にはまだ遠い。

RPCプロバイダへの中央集権的な依存

Ethereumのノードは分散しているが、ほとんどのDAppsとウォレットはAlchemyやInfuraといった少数のRPCプロバイダ経由でアクセスしている。2020年にInfuraが障害を起こした際、MetaMaskを含む多数のサービスが影響を受けた。ブロックチェーン自体は正常だったが、アクセス経路の集中が単一障害点を生んでいる。

Layer 2間の断片化

Arbitrum、Optimism、Baseなど複数のL2が存在し、流動性やユーザーがチェーンごとに分散している。L2間の資産移動にはブリッジが必要で、手数料・時間・セキュリティリスクが伴う。ユーザーが「自分の資産がどのチェーンにあるか」を意識しなければならない時点で、体験としては銀行に劣る。

これら3つの課題は、根底で「分散化と使いやすさのトレードオフ」という同じ構造を共有している。