Fluffy クライアント: イーサリアムの非常に軽量なクライアント
クライアントがネットワークに少量のデータを提供するだけで済み、ネットワーク全体 (これらの提供) が多くの意味を持つようにネットワークを設計するにはどうすればよいでしょうか?
—— Piper Merriam
Nimbus が、ポータル ネットワークの立ち上げクライアントの 1 つとしてイーサリアム財団の「ポータル ネットワーク」チームに加わることを発表できることを嬉しく思います。
一文の要約: 「ポータル ネットワーク」は、イーサリアムのライト クライアントを再考し、使いやすく実用的なライト クライアント エクスペリエンスを開発するために開発中のクロスクライアント プロジェクトです。
仕様を直接引用するには:
「ポータル ネットワーク」は、リソースが限られているデバイスがプロトコルに軽量にアクセスできるようにするために開発中のプロジェクトです。
「ゲートウェイ」という用語は、これらのネットワークがプロトコルの動作の現状を観察できるが、コアのイーサリアム プロトコルの動作には無関心であることを意味します。
ポータル ネットワークは、標準の JSON-RPC API を公開するために必要なデータと機能を集合的に提供する 1 つ以上の分散型ピアツーピア ネットワークで構成されます。
これらのネットワークは、クライアントが参加するために最小限のネットワーク帯域幅、CPU、RAM、および機械的ハード ディスク リソースを支払うだけで済むように特別に設計されています。
「ポータル ネットワーク」という用語は、これらのネットワークに参加し、標準の JSPN-PRC API を公開するソフトウェアを記述するのにも使用されます。
特に、私たちの目標は、EF と協力して、既存のイーサリアム プロトコルを中心とした新しいイーサリアム プロトコルのセットを開発し、特にイーサリアム データにアクセスするこの新しい方法に対応できるようにすることです。
全体的な目標は、完全な状態をリアルタイムで追跡する (現在のクライアントが行っていることである) のではなく、一般的な使用パターンに対応できるイーサリアムのオペレーティング モデルを提供することです。
私たちが議論しているのは、ウォレットに最適なクライアント、つまりネットワークに貢献できるが、ブロックチェーンの同期を必要としない非常に軽量なクライアントを開発することです (つまり、オフライン後に再起動でき、インストール後にすぐに利用できる)。
それは思っているほど難しくありません。ほとんどのウォレットにはライトクライアントが直接埋め込まれていると思います。たとえば、@ethstatus は @ethnimbus ライトクライアントを統合します。そのため、ほとんどのユーザーが気付かないうちに軽量クライアントを実行し始めるという状況が発生する可能性があります。
May 24, 2021
したがって、私たちの最終的な目標の 1 つは、この種のクライアントを Status アプリに直接ノックインさせることです。
背景
背景
ポータル ネットワークは、開発者 Piper Merriam と Trinity チームの当初の目標、つまり既存のネットワーク上に軽量クライアントを開発することに根ざしています。これは、既存のネットワークが彼らが思い描いたタイプのクライアントに対して十分な柔軟性がないと認識したために誕生しました。
パイパーの言葉では次のようになります。
Trinity クライアントの開発を開始したとき、私たちの目標は軽量クライアントを開発することでした。しかし、3 年近くかけてプロトコルを深く理解し、思い描いたクライアントを開発する方法を模索した結果、最終的には既存のネットワークでは実現できないという結論に達しました。
これがポータル ネットワークの本来の目的です。クライアントがどうあるべきかに立ち戻り、クライアントが動作するために必要なネットワーク機能を設計します。
最初のレベルのタイトル
動機 (ライトクライアントの視点)
既存の DevP2P LES ネットワークは、クライアント/サーバー アーキテクチャで設計されており、ライト クライアントがクライアント、フル ノードがサーバーとなります (これまでのところ、「ライト クライアント」という用語は、ネットワークのクライアントである既存の DevP2P LES を指します)。
このアーキテクチャではすべての負荷がフル ノードに割り当てられ、フル ノードの運用コストがすでに高くなっているため、ノード オペレータはこの機能を有効にすることに消極的です。
したがって、現在のネットワーク設計は当初の目標をうまく達成していますが、ライト クライアントの観点から見ると大きく失敗しています。
この問題をどうやって解決すればよいでしょうか? Piper の Trinity チームが発見したように、現実はこの問題に対する簡単な解決策がないことを示しています。既存のネットワークは、効率的なライト クライアント設計に十分な柔軟性がありません。
最初のレベルのタイトル
デザイン
ライトクライアントフレンドリーなネットワークは、各ノードに高い負荷を負担させるのではなく、少量のストレージスペースと少量の作業のみでノードがネットワークに参加し、ネットワークに貢献できるように設計する必要があります。 : in ブロックチェーンの完全な履歴はメモリに保存されます)。
言い換えれば、このようなネットワークでは、追加のクライアントがネットワークに参加するたびにネットワークの容量が増加するように、ライト クライアントが実際にネットワークに貢献できるようにする必要があります。
具体的には、散発的に要求されるデータの検証オーバーヘッドを削減し、ネットワーク上でメッセージを渡す際の根本的なオーバーヘッドを削減するネットワーク設計を考案することを意味します。
ポータル ネットワークは、イーサリアム プロトコルの全体構造を、ゴシップ (トランザクションとブロック) 状態と履歴という 3 つの別々のネットワークに分割することでこれを実現することを目的としており、初期開発の焦点は状態ネットワークにあります。
これらのネットワークは ETH プロトコルと共存しますが、ETH プロトコルとは異なり、完全に無敵である必要はありませんが、ほぼノンストップで動作できる必要があります。
これらの新しいネットワークが、時間の経過とともに既存のネットワークとより緊密に統合されることが期待されています。例として、フル機能のクライアントが履歴ポータルのネットワークを使用して、ブロックチェーン全体 (200 MB を超える) ではなく、関心のある履歴 (おそらく 200 MB) のみを保存する追加オプションをノード オペレーターに提供できる世界を想像できます。 GB）。ステータスデータも同様です。
全体として、このモジュラー アーキテクチャでは、データ (状態とブロックチェーン履歴) が P2P 方式で共有され、トランザクションとブロックはゴシップ経由で伝播されますが、ライト クライアントは、データと履歴データを保存/提供する状態の量を選択できます。
最初のレベルのタイトル
JSON RPC のメモ
中国語翻訳中国語翻訳): 私たちのウォレットを含むほとんどのウォレットは、JSON RPC API で標準化されています。
Status ウォレットが正しく機能するには、次の JSON RPC エンドポイントが必要です。
eth_blockNumber はチェーンの先頭を追跡するために使用されます
eth_getBalance と eth_getTransactionCount はアカウント情報を取得するために使用されます
eth_call はコントラクト情報を読み取るために使用されます
eth_estimateGas と eth_gasPrice はガス料金の見積もりに使用されます
eth_sendRawTransaction はユーザーのトランザクションを送信するために使用されます
eth_getTransactionReceipt トランザクションがオンチェーンになった後にレシートを取得します
ウォレット機能を実現するために必要なコンポーネントをさらに整理すると、次の下位レベルの要件が得られます。
サポートするアカウントおよびコントラクトのストレージ項目 (状態) にアクセスします: eth_call、eth_estimateGas、eth_getBalance、および eth_getTransactionCount
ゴシップ ネットワーク (Gossip) にアクセスして、チェーンの先頭と eth_sendRawTransaction をたどります。
eth_getTransactionReceipt に使用されるアクセス チェーンの履歴 (history)
ポータル ネットワークは、状態、ゴシップ、歴史への軽量アクセスを可能にし、ブロックチェーンを同期したり、プライバシーやセキュリティを犠牲にしたりすることなく、これらのニーズを満たすことができるウォレットに埋め込み可能なライト クライアントへの扉を開きます。
最初のレベルのタイトル
プロジェクトのステータス
私たちは、当初は nlpn という名前でしたが、現在は Fluffy という名前に変更された Nimbus の動作モードの開発を開始しました。これは、Ethereum 1 クライアントと一緒に存在して実行されます。
ふわふわにより、nimbus-eth1 クライアントはネットワーク内で非常に軽量なクライアント ノードとして動作できるようになります。
初期の作業は、Node Discovery v5.1 プロトコルの上に構築された二次プロトコルである Portal Wire プロトコルを開発することでした。
次のステップ
次のステップ
次のステップは、Portal Wire プロトコルを介してデータを転送することです。私たちは状態データを扱っています。
これには、ポータル ネットワークの状態データを入力する「ブリッジ ノード」が必要です。現在のアプローチは、Nethermind クライアント プラグインをカスタム JSON-PRC API として使用し、ブリッジ ノードとして機能するポータル ノードにデータを提供することです。この作業はすでに始まっています (仕様草案はこちら)。
最初のレベルのタイトル
リソース
Nimbus Portal Network Client (nlpn) は、nimbus-eth1 リポジトリにあります: https://github.com/status-im/nimbus-eth1/tree/master/fluffy
Portal Wire プロトコルが、ノード検出プロトコル v5.1 のセカンダリ プロトコルとして nim-eth コードベースに追加されました: https://github.com/status-im/nim-eth
仕様: https://github.com/ethereum/stateless-ethereum-specs/
ウェブサイト: https://www.ethportal.net/
ddht と trin を使用した最初の Portal Wire プロトコル テストに関するいくつかの内容: https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53
Piper Merriam によるブログ シリーズ: 機能的なライト クライアントへの曲がりくねった道
トピックに関するビデオ講義
注: 便利なことに、機能的なライト クライアントの実装に必要なすべてのインフラストラクチャは、当然ステートレス クライアントにも拡張されるため、ステートレス イーサリアムと重複する部分が多くなります。実際、ステートレス クライアントがほとんどの JSON-PRC API を提供できるようにすることが、ポータル ネットワークの中心的な動機の 1 つです。
