ポータルネットワーク

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

そこで、このディスクストレージに関する問題を回避するために、すべての情報をクライアント自身に保存する代わりに、フルノードへ情報をリクエストする「ライト」ノードが開発されました。 しかし、ライトノードは自分で情報を検証できないため、代わりに別のノードを信用する必要があります。 つまり、ライトノードに情報を提供するために、フルノードが追加の処理を行う必要があるということになります。

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

ノードとクライアントに関する詳細

ポータルネットワークが必要な理由

イーサリアムノードは、イーサリアムブロックチェーンの全部または一部のコピーを保存します。 このローカルコピーを使って、トランザクションを検証し、ノードが正しいチェーンに進むよう徹底します。 また、このローカルに保存したデータにより、受信データが有効かつ正当であることを、他のエンティティを信頼せずに独立して検証できます。

ブロックチェーンのローカルコピーや、それに関連付いた状態およびレシートデータなどは、ノードのハードディスク容量を大量に消費します。 例えば、コンセンサスクライアントとペアリングしたGeth (opens in a new tab)を使用してノードを実行するには、2TBのハードディスクが推奨されます。 スナップ同期を使用すると、比較的最近のブロックのセットがもつチェーンデータのみを保存しますが、Gethでは一般的に、約650 GBのディスク容量を使います。また、一週間で約14 GB増加します(ノードを定期的に650 GBへプルーニングできます)。

イーサリアムでは大容量のディスクスペースを必要とするため、ノードを立ち上げるには高額な費用がかかる可能性があります。 この問題に対しては、イーサリアムのロードマップ上に、履歴の有効期限切れ、ステートの有効期限切れ、ステートレス性など、いくつかの解決策があります。 しかし、これらの解決策の実装には数年を要すると考えられています。 また、自身のチェーンデータのコピーを保存せず、フルノードから必要なデータを要求するライトノードもあります。 ただし、ライトノードは正直なデータを提供するためにフルノードを信頼する必要があり、フルノードはライトノードが必要とするデータを提供しなければならないため負荷がかかります。

ポータルネットワークは、ライトノードがデータを取得する代替方法を提供することを目指しています。この方法では、フルノードを信頼する必要がなく、フルノードで実行する処理を大幅に追加する必要もありません。 イーサリアムノードがネットワーク全体でデータを共有する新たな方法を導入することで、これを実現します。

ポータルネットワークの仕組み

厳密なプロトコルによって、イーサリアムノードが相互に通信する方法が定義されています。 実行クライアントはDevP2Pとして知られるサブプロトコルのセットを使用して通信する一方、コンセンサスクライアントはlibP2Pと呼ばれるサブプロトコルの異なるスタックを使用します。 これらのプロトコルは、ノード間で受け渡せるデータのタイプを定義します。

ノードはJSON-RPC APIを介して特定のデータを提供することもでき、これによってアプリやウォレットはイーサリアムノードと情報を交換します。 しかし、ライトクライアントへデータを提供する理想的なプロトコルは存在していません。

現状では、ライトクライアントは、DevP2PまたはlibP2pを使って、特定のチェーンデータの一部分をリクエストすることができません。これらのプロトコルは、チェーンの同期、ブロックとトランザクションのゴシップのみを目的に設計されているからです。 ライトクライアントがこの情報をダウンロードすると、クライアントが「ライト」でなくなるため、適切ではありません。

JSON-RPC APIは、ライトクライアントのデータリクエストに理想的な選択肢ではありません。データを提供する特定のフルノードまたは集中型のRPCプロバイダーへの接続に依存しているためです。 これでは、ライトクライアントは、特定のノードもしくはプロバイダーが正直であることを信頼する必要があります。また、フルノードは、多数のライトクライアントから来る大量のリクエストを処理する必要があります。これでは、通信帯域要件が増えてしまいます。

ポータルネットワークのポイントとしては、既存のイーサリアムクライアントの設計制約を除き、全体を再設計し、軽量化に焦点を合わせて構築することです。

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

このアイデアは、各ノードにイーサリアム全体の履歴データの一部を割り当て、特定の具体的な役割を追加することです。 その結果、リクエストされた特定のデータが保存されているノードを探し出し、そのデータを取得して提供することができます。

ライトノードは、これまでは1つのノードに大量のデータをフィルタリングしてもらっていました。しかし、今後は、ライトノードのネットワーク全体で素早くフィルタリングを行うことで、各ノードのデータ処理量を小さくしていきます。

目標は、ライトウェイトポータルクライアントの分散ネットワークで次のことを可能にすることです。

• チェーンヘッドの追跡
• 直近と過去のチェーンデータの同期
• 状態データの検索
• トランザクションのブロードキャスト
• EVMを使用してトランザクションを実行

このネットワーク設計による利点は、次の通りです。

• 集中化したプロバイダーへの依存が減る
• インターネット帯域使用量が減る
• 同期が短くなる、または同期が不要になる
• リソースに制約のあるデバイス (<1 GB RAM、<100 MB ディスク容量、1 CPU) でアクセス可能

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

ポータルネットワーク

デフォルトでのクライアントの多様性

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

ポータルネットワークのクライアントは、以下の通りです。

• 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つのクライアントに問題や脆弱性が生じても、他のクライアントは通常通り運用を続けられるため、単一障害点を防ぐことができます。 また、多様なクライアントの実装により、イノベーションと競争が促進されるだけでなく、エコシステム内の改善が促進され、単一文化によるリスクが軽減されます。

参考リンク

• ポータルネットワーク (Devcon BogotaでのPiper Merriam氏による講演) (opens in a new tab)。
• ポータルネットワークのDiscord (opens in a new tab)
• ポータルネットワークのウェブサイト (opens in a new tab)