ポータルネットワーク
最終編集者: @HiroyukiNaito(opens in a new tab), 2024年10月3日
イーサリアムは、イーサリアムクライアントソフトウェアを実行するコンピュータによって構成されるネットワークです。 これらの各コンピュータは、「ノード」と呼ばれます。 クライアントソフトウェアは、イーサリアムネットワーク上でデータの送受信を行い、イーサリアムプロトコルのルールに従ってデータを検証します。 ノードは、自身のディスクストレージ内に大量の履歴データを保存し、ネットワーク上にある他のノードからブロックとして知られる新しいパケット情報を受信すると、その履歴データに追加します。 このデータは、ノードが他のネットワークと一貫した情報を持っていることを常時確認するために必要となります。 つまり、ノードの実行には大量のディスクスペースが必要ということになります。 また、一部のノードの操作では、大量のRAMが必要になる場合があります。
そこで、このディスクストレージに関する問題を回避するために、すべての情報をクライアント自身に保存する代わりに、フルノードへ情報をリクエストする「ライト」ノードが開発されました。 しかし、ライトノードは自分で情報を検証できないため、代わりに別のノードを信用する必要があります。 つまり、ライトノードに情報を提供するために、フルノードが追加の処理を行う必要があるということになります。
ポータルネットワークは、イーサリアムにおける新たなネットワーク設計です。フルノードを信頼することなく、余計な負担をかけずに、必要なデータをネットワーク全体で小さな塊に分けて共有することで、「ライト」ノードのデータ可用性問題を解決することを目指しています。
ポータルネットワークが必要な理由
イーサリアムノードは、イーサリアムブロックチェーンの全部または一部のコピーを保存します。 このローカルコピーを使って、トランザクションを検証し、ノードが正しいチェーンに進むよう徹底します。 また、このローカルに保存したデータにより、受信データが有効かつ正当であることを、他のエンティティを信頼せずに独立して検証できます。
ブロックチェーンのローカルコピーや、それに関連付いた状態およびレシートデータなどは、ノードのハードディスク容量を大量に消費します。 例えば、コンセンサスクライアントをペアにしたGeth(opens in a new tab)ノードを立ち上げるには、2 TBのハードディスクが推奨されています。 スナップ同期を使用すると、比較的最近のブロックのセットがもつチェーンデータのみを保存しますが、Gethでは一般的に、約650 GBのディスク容量を使います。また、一週間で約14 GB増加します(ノードを定期的に650 GBへプルーニングできます)。
イーサリアムでは大容量のディスクスペースを必要とするため、ノードを立ち上げるには高額な費用がかかる可能性があります。 一方、履歴の有効期限、状態の有効期限、ステートレスなど、この問題に対するいくつかの解決策がイーサリアムのロードマップに記載されています。 しかし、これらの解決策の実装には数年を要すると考えられています。 また、チェーンデータのコピーを自身で保存せず、必要なデータをフルノードへリクエストするライトノードがあります。 ただし、ライトノードは正直なデータを提供するためにフルノードを信頼する必要があり、フルノードはライトノードが必要とするデータを提供しなければならないため負荷がかかります。
ポータルネットワークは、ライトノードがデータを取得する代替方法を提供することを目指しています。この方法では、フルノードを信頼する必要がなく、フルノードで実行する処理を大幅に追加する必要もありません。 イーサリアムノードがネットワーク全体でデータを共有する新たな方法を導入することで、これを実現します。
ポータルネットワークの仕組み
厳密なプロトコルによって、イーサリアムノードが相互に通信する方法が定義されています。 実行クライアントは、DevP2Pと呼ばれるサブプロトコルのセットを使用して通信します。一方、コンセンサスクライアントは、libP2Pと呼ばれる別のサブプロトコルのスタックを使用します。 これらのプロトコルは、ノード間で受け渡せるデータのタイプを定義します。
ノードは、JSON-RPC APIを通して特定のデータを提供することもできます。このAPIにより、アプリやウォレットは、イーサリアムノードと情報を交換できます。 しかし、ライトクライアントへデータを提供する理想的なプロトコルは存在していません。
現状では、ライトクライアントは、DevP2PまたはlibP2pを使って、特定のチェーンデータの一部分をリクエストすることができません。これらのプロトコルは、チェーンの同期、ブロックとトランザクションのゴシップのみを目的に設計されているからです。 ライトクライアントがこの情報をダウンロードすると、クライアントが「ライト」でなくなるため、適切ではありません。
JSON-RPC APIは、ライトクライアントのデータリクエストに理想的な選択肢ではありません。データを提供する特定のフルノードまたは集中型のRPCプロバイダーへの接続に依存しているためです。 これでは、ライトクライアントは、特定のノードもしくはプロバイダーが正直であることを信頼する必要があります。また、フルノードは、多数のライトクライアントから来る大量のリクエストを処理する必要があります。これでは、通信帯域要件が増えてしまいます。
ポータルネットワークのポイントとしては、既存のイーサリアムクライアントの設計制約を除き、全体を再設計し、軽量化に焦点を合わせて構築することです。
ポータルネットワークのコアとなるアイデアは、現在のネットワークスタックの最良の部分を活用することです。これを実現するには、DHT(opens in a new tab)(Bittorrentと類似)を使って、履歴データや現在のチェーンヘッドのアイデンティティを軽量のDevP2P形式のピアツーピア分散型ネットワークを介して提供し、ライトクライアントによって必要とされる情報を有効化します。
このアイデアは、各ノードにイーサリアム全体の履歴データの一部を割り当て、特定の具体的な役割を追加することです。 その結果、リクエストされた特定のデータが保存されているノードを探し出し、そのデータを取得して提供することができます。
ライトノードは、これまでは1つのノードに大量のデータをフィルタリングしてもらっていました。しかし、今後は、ライトノードのネットワーク全体で素早くフィルタリングを行うことで、各ノードのデータ処理量を小さくしていきます。
目標は、ライトウェイトポータルクライアントの分散ネットワークで次のことを可能にすることです。
- チェーンヘッドの追跡
- 直近と過去のチェーンデータの同期
- 状態データの検索
- トランザクションのブロードキャスト
- EVMを使ったトランザクションの実行
このネットワーク設計による利点は、次の通りです。
- 集中化したプロバイダーへの依存が減る
- インターネット帯域使用量が減る
- 同期が短くなる、または同期が不要になる
- リソースが限られたデバイス (1GB未満のRAM、100MB未満のディスクスペース、1つのCPU) でもアクセス可能です。
以下の図は、ポータルネットワークでやり取りできる現行のクライアントの機能を示しています。ユーザーは、非常に少ないリソースのデバイスでも、これらの機能にアクセスできます。
デフォルトのクライアント多様性
ポータルネットワークのデベロッパーは、最初から3種類のポータルネットワーククライアントを構築することを決めていました。
ポータルネットワークのクライアントは、以下の通りです。
- Trin(opens in a new tab): Rustで開発
- Fluffy(opens in a new tab): Nimで開発
- Ultralight(opens in a new tab): Typescriptで開発
- Shisui(opens in a new tab): Go言語で開発
依存しないクライアント実装が複数存在することで、イーサリアムネットワークの回復力と分散化が強化されます。
1つのクライアントに問題や脆弱性が生じても、他のクライアントは通常通り運用を続けられるため、単一障害点を防ぐことができます。 また、多様なクライアントの実装により、イノベーションと競争が促進されるだけでなく、エコシステム内の改善が促進され、単一文化によるリスクが軽減されます。