メインコンテンツへスキップ
Change page

ポータル・ネットワーク

ページを編集 (opens in a new tab)

イーサリアムは、イーサリアムのクライアントソフトウェアを実行するコンピュータで構成されるネットワークです。これらのコンピュータはそれぞれ「ノード」と呼ばれます。クライアントソフトウェアにより、ノードはイーサリアム・ネットワーク上でデータを送受信し、イーサリアムのプロトコルルールに照らしてデータを検証することができます。ノードはディスクストレージに大量の履歴データを保持しており、ネットワーク上の他のノードからブロックと呼ばれる新しい情報のパケットを受け取ると、それを追加します。これは、ノードがネットワークの他の部分と一貫した情報を持っていることを常に確認するために必要です。つまり、ノードを実行するには大量のディスク容量が必要になる場合があります。一部のノード操作では、大量のRAMも必要になる場合があります。

このディスクストレージの問題を回避するために、すべての情報を自分で保存するのではなく、フル・ノードに情報を要求する「ライト」ノードが開発されました。しかし、これはライト・ノードが情報を独立して検証しておらず、代わりに別のノードを信頼していることを意味します。また、フル・ノードはこれらのライト・ノードにサービスを提供するために追加の作業を引き受ける必要があることも意味します。

ポータル・ネットワークは、必要なデータを小さなチャンクに分割してネットワーク全体で共有することにより、フル・ノードを信頼したり余分な負担をかけたりすることなく、「ライト」ノードのデータ可用性の問題を解決することを目的とした、イーサリアムの新しいネットワーキング設計です。

ノードとクライアントの詳細

なぜポータル・ネットワークが必要なのか

イーサリアムのノードは、イーサリアムのブロックチェーンの完全または部分的なコピーを独自に保存します。このローカルコピーは、トランザクションを検証し、ノードが正しいチェーンに従っていることを確認するために使用されます。このローカルに保存されたデータにより、ノードは他のエンティティを信頼することなく、受信したデータが有効で正しいことを独立して検証できます。

ブロックチェーンのこのローカルコピーと、関連する状態およびレシートデータは、ノードのハードディスク上の多くのスペースを占有します。たとえば、コンセンサス・クライアントとペアになったGeth (opens in a new tab)を使用してノードを実行するには、2TBのハードディスクが推奨されます。比較的最近のブロックセットからのチェーンデータのみを保存するスナップ同期を使用すると、Gethは通常約650GBのディスク容量を占有しますが、週に約14GBのペースで増加します（定期的にノードをプルーニングして650GBまで減らすことができます）。

つまり、大量のディスク容量をイーサリアム専用にする必要があるため、ノードの実行にはコストがかかる可能性があります。イーサリアムのロードマップには、履歴の失効、ステート失効、ステートレス性など、この問題に対するいくつかの解決策があります。ただし、これらが実装されるまでには数年かかる可能性があります。また、チェーンデータの独自のコピーを保存せず、必要なデータをフル・ノードに要求するライト・ノードもあります。しかし、これはライト・ノードが正直なデータを提供するためにフル・ノードを信頼しなければならないことを意味し、またライト・ノードが必要とするデータを提供しなければならないフル・ノードにストレスを与えます。

ポータル・ネットワークは、フル・ノードを信頼したり、フル・ノードが行わなければならない作業を大幅に増やしたりすることなく、ライト・ノードがデータを取得するための代替方法を提供することを目的としています。これを行う方法は、イーサリアムのノードがネットワーク全体でデータを共有するための新しい方法を導入することです。

ポータル・ネットワークはどのように機能するのか？

イーサリアムのノードには、互いに通信する方法を定義する厳格なプロトコルがあります。実行クライアントはdevp2pとして知られるサブプロトコルのセットを使用して通信しますが、コンセンサス・クライアントはlibp2pと呼ばれる異なるサブプロトコルのスタックを使用します。これらは、ノード間で渡すことができるデータの種類を定義します。

devP2P and libP2P

ノードはJSON-RPC APIを介して特定のデータを提供することもできます。これは、アプリやウォレットがイーサリアムのノードと情報をスワップする方法です。ただし、これらはいずれもライト・クライアントにデータを提供するための理想的なプロトコルではありません。

ライト・クライアントは現在、devp2pやlibp2pを介して特定のチェーンデータを要求することはできません。これらのプロトコルは、チェーンの同期と、ブロックおよびトランザクションのゴシップを可能にするようにのみ設計されているためです。ライト・クライアントはこの情報をダウンロードしたくありません。なぜなら、そうすると「ライト」ではなくなってしまうからです。

JSON-RPC APIも、ライト・クライアントのデータ要求にとって理想的な選択肢ではありません。なぜなら、データを提供できる特定のフル・ノードまたは中央集権型のRPCプロバイダーへの接続に依存しているからです。これは、ライト・クライアントがその特定のノード/プロバイダーが正直であると信頼しなければならないことを意味し、またフル・ノードは多くのライト・クライアントからの多数の要求を処理しなければならない可能性があり、帯域幅の要件が増加します。

ポータル・ネットワークのポイントは、既存のイーサリアムクライアントの設計上の制約にとらわれず、特に軽量化のために構築された設計全体を再考することです。

ポータル・ネットワークの核となるアイデアは、DHT (opens in a new tab)（BitTorrentに似ています）を使用した軽量のdevp2pスタイルのピア・ツー・ピア分散型ネットワークを通じて、履歴データやチェーンの現在のヘッドのIDなど、ライト・クライアントが必要とする情報を提供できるようにすることで、現在のネットワーキングスタックの優れた部分を取り入れることです。

そのアイデアは、イーサリアムの全履歴データの小さな部分と、いくつかの特定のノードの責任を各ノードに追加することです。そして、要求された特定のデータを保存しているノードを探し出し、そこからデータを取得することで、要求が処理されます。

これは、ライト・ノードが単一のノードを見つけ、大量のデータをフィルタリングして提供するように要求するという通常のモデルを反転させます。代わりに、それぞれが少量のデータを処理するノードの大規模なネットワークをすばやくフィルタリングします。

目標は、軽量のポータルクライアントの分散型ネットワークが以下を行えるようにすることです。

  • チェーンのヘッドを追跡する
  • 最近および過去のチェーンデータを同期する
  • 状態データを取得する
  • トランザクションをブロードキャストする
  • EVMを使用してトランザクションを実行する

このネットワーク設計の利点は次のとおりです。

  • 中央集権型プロバイダーへの依存を減らす
  • インターネットの帯域幅の使用量を減らす
  • 同期を最小限に抑えるか、ゼロにする
  • リソースに制約のあるデバイス（1GB未満のRAM、100MB未満のディスク容量、1CPU）からアクセス可能

以下の表は、ポータル・ネットワークによって提供できる既存のクライアントの機能を示しており、ユーザーは非常にリソースの少ないデバイスでこれらの機能にアクセスできるようになります。

ポータル・ネットワーク

ビーコン・ライト・クライアント状態ネットワークトランザクション・ゴシップ履歴ネットワーク正規トランザクション・インデックス
ビーコンチェーン・ライトアカウントとコントラクトのストレージ軽量メンプールヘッダーTxHash > ハッシュ、インデックス
プロトコルデータブロックボディ
レシート

デフォルトでのクライアント・ダイバーシティ

ポータル・ネットワークの開発者はまた、初日から4つの別々のポータル・ネットワーククライアントを構築するという設計上の選択を行いました。

ポータル・ネットワーククライアントは次のとおりです。

複数の独立したクライアント実装を持つことで、イーサリアム・ネットワークの回復力と分散化が強化されます。

1つのクライアントで問題や脆弱性が発生した場合でも、他のクライアントはスムーズに動作し続けることができ、単一障害点を防ぐことができます。さらに、多様なクライアント実装はイノベーションと競争を促進し、エコシステム内の改善を推進し、モノカルチャーのリスクを軽減します。

参考文献

ページの最終更新: 2026年4月9日

HiroyukiNaitoH (opens in a new tab)
de_gardend (opens in a new tab)
jadijadij (opens in a new tab)
+14