イーサリアムネットワークが進化し成熟していくにつれて、異なるタイプのノードの概念を理解することがますます重要になってきます。しかし、現実的には、多くのユーザーはノードを実行するために必要な努力を惜しんでおらず、ハードウェア要件は多くの人にとって達成可能です。イーサリアムの開発の「最終段階」では、技術的な知識やリソースをほとんど必要とせずに状態の整合性とデータの可用性をユーザーが検証できることが重要です。検証可能性のないブロックチェーンは、結局のところ非効率なデータベースにすぎません。

この記事では、Ethereumネットワークの将来を形作る3つの主要なノードのタイプについて説明します：ステートレスノード、ステートフルノード、およびフル/アーカイブノード。ステートレスノードがゼロ知識証明を使用して新しいブロックの信頼性のある検証を可能にする方法、ステートフルノードがEthereumの現在の状態に対する迅速で信頼性のあるアクセスを提供する方法、およびフル/アーカイブノードが創世記からのチェーン全体の履歴を保存する方法について検討します。各ノードタイプの役割とトレードオフを理解することで、より分散化された、安全な、スケーラブルなEthereumエコシステムに取り組むことができます。

エンドゲームステートレスノード

今日、私たちはすでに見てきたように、BitcoinとEthereumの両方にとって、ハードウェア要件はそれらのチェーンの多くの重いユーザーにとって達成可能であるにもかかわらず、ほとんどのユーザーはどのタイプのノードを実行するために多くの努力を惜しんでいます。ここでの「重いユーザー」とは、チェーン上の相当量の資産を持つ人物を指します。つまり、ノードを実行するコストがブロッカーにならない任意のユーザーと考えてください。

主な理由はおそらく、ほとんどのユーザーがそれを気にしない、数百ドルをハードウェアに費やすことを望まない、またはそれを実行するための技術的な知識がないという事実の組み合わせです。BitcoinとEthereumの両方が使いやすくするために大きな進歩を遂げているにもかかわらず、非技術的なユーザーにとってはまだかなり複雑なタスクです。

状態のないイーサリアムのビジョン

私は、ブロックチェーンの「エンドゲーム」では、ユーザーが状態の整合性とデータの可用性を確認する必要があり、それらのことが何であるかを必ずしも知らなくてもよいという考えです。 いいニュースは、十分なエンジニアリング（ゼロ知識技術と少しの技術）でこのビジョンを完全に実現できるということです。データ可用性サンプリング)

このエンドゲームでは、基本的に使用する価値のあるすべてのウォレットには、チェーンに追加されたすべての新しいブロックに対して、p2pレイヤー上の任意のフルノードから最新のブロックヘッダーと前のブロックヘッダーからの状態変更が正しく実行されたことを証明するzk-proofをクエリする状態を持たないノードがあります。いくつかのピアからいくつかのランダムなデータサンプルを要求して、すべてのデータ（ブロブと実行ブロックデータ）が公開されており、ネットワークがコンセンサスに達しブロックが最終化されたことを証明するzk-proofを得ることができます。

これを行うための帯域幅/計算は非常に少なく、携帯電話（またはスマートウォッチのような機器でも完全に実行できます@drakefjustin""> @drakefjustinは言及するのが好きです)。上記で言及されたノードのタイプは、ノードが現在の状態をローカルで必要とせず、代わりに新しいブロックを検証できるため、「状態を持たない」ノードの一種として分類されます。ノードは異なる種類の証明を頼りにして新しいブロックを検証できます。

これらの証明はzk-証明である必要はありません。実行のステートレス検証は、私たちがzk-証明を使用して実行のために上記で説明したことを行う前に行われます。実際、ステートレス実行は今日でも行うことができますが、現在のMerkle-Patricia-Tree構造では非常に効率が悪く、証人の証明は実用的であるには大きすぎます。@peter_szilagyi‘sのツイート)。

現在のMerkle-Patriciaツリーでは、この「証人」のサイズを確認してください。このスクリーンショットのブロックの多くは100kb未満であり、状態レス検証を可能にするために必要な証拠は、しばしばブロック自体よりも50倍以上大きくなります。

EthereumのMPT構造

しかし、将来、Ethereumは現在のMerkle-Patricia-Tree構造とは異なる状態ツリー構造にアップグレードする予定です。多くの方がVerkleツリーについて聞いたことがあるかもしれませんが、それは数年前からの計画です（もし聞いたことがなければ、弊社の記事を読んでください -私たちのためのVerkle Trees：パート1). Verkleツリー構造の性質により、非常に小さなウィットネス/証明が可能であり、実用的なステートレスクライアントの作成が可能になります。

マークルツリー vs. バークルツリー

Verkleツリーには1つの大きな問題があります。それは、量子セキュアではないということです。つまり、Verkleツリーは、最良の場合でも、状態ツリー構造の永続的な解決策が十分に成熟したり効率的になるまで、一時的な解決策にすぎません。最終的な解決策はおそらく、STARKで証明されたバイナリハッシュツリーになるでしょう。そして、Verkleツリーがスキップされ、STARKで証明されたバイナリハッシュツリーのいくつかのバリエーションが好まれる可能性が非常に高いです。(関連するミームから @VitalikButerin)

状態を完全に持たないことができる非状態ノードの非常に興味深いオプションの1つは、完全に状態を持たないことができるというオプションです。例えば、クライアントがそのような機能をサポートしている場合、使用する上で関連性のある状態をローカルに保存することが可能です。

複数のアドレス、資産、およびDeFiプロトコルに資産が分散しているとします。その場合、使用に関連するすべての状態をローカルディスクに書き込むことができ、ディスクスペースはわずかな量しか使用しません。複数の大規模なDeFiプロトコルの状態全体を追跡しても、数ギガバイトしか必要としません。基本的にすべての新しい携帯電話には128GB以上のストレージが搭載されているため、ユーザーが役立つと考えるすべての状態をモバイル電話のフラッシュストレージに書き込むことは可能であり、実際には実用的なことです。

(ライトクライアントについてのクイックノート：状態の遷移を効率的に検証し、合意を簡単にするステートレスクライアントが存在する世界では、誠実な多数の前提に依存する従来のライトクライアントのユースケースは実際には存在しないと感じています。)

エンドゲーム状態のノード

Statefulノードは現在と非常に最近の状態のみを保持し、一定の年齢よりも古いすべてを刈り込みます（eip-4444提案）。現在の状態は、ローカルでブロックを構築するために必要であり、状態を持たないノードはそれができません。

ステートフルノードは、将来的にデータが非常に膨大になるため、完全なチェーン履歴を保持しないため、フルノードと混同されるべきではありません。ステートフルノードは、Ethereumの現在の状態にクイックで信頼性の高いアクセスを望むユーザーにとって有用であり、ステートからデータをクエリする、ブロックを構築する、またはステーキングにこのタイプのノードを使用するために使用できます。

コンシューマハードウェア上でステートフルノードを実行する可能性を維持することは、ステートレスノードが非常に軽量で成熟している場合でも、私たちEthereumコミュニティが維持する必要がある非常に重要な目標です。これの主な理由の1つは、すべてのステートレスノードが、新しいブロックのステートレス検証に必要な証人を作成するためにステートフルノードに依存しているためです。

現在の状態にアクセスすることは、メンプールにあるトランザクションが有効かどうかを知るためにも必要です。そのため、ネットワーク上に非常に分散した状態を持つノードが必要であり、ある種のインクルージョンリスト設計で非常に強力な検閲耐性保証を確保できます。

良いニュースは、状態の有効期限があれば、しばらく誰も操作していない状態をノードのディスクから削除できるため、状態を持つノードを実行することが格段に容易になります。有効期限が切れた状態とやり取りしたい場合は、証人（基本的にはMerkle Proof）を持参する必要があります。チェーンの履歴にアクセスできる誰もが、これらのタイプの証明を信頼できる方法で構築して、有効期限が切れた状態を取り戻すことができます。この時点では、Ethereumの状態サイズは300GBに接近しており、状態の有効期限が実装されるまで、状態サイズはより多くまたは少なくとも上昇トレンドを続けるでしょう。

(ここは非常に素晴らしい記事です@パラダイムその話題をさらに深く掘り下げます。州の成長と州の期限切れについて

フル/アーカイブノード

この記事の目的のために、私はバッチフルノードとアーカイブノードを一緒に扱います。なぜなら、通常のフルノードはディスクに書き込まれた情報を使用して、アーカイブノードがディスクに書き込んだデータをすべて計算することができるからです。違いは、フルノードが最新/最新の状態でない状態を剪定することです。通常のフルノードでは「XアカウントのYブロックのETH残高は約5年前に何でしたか？」というクエリを実行することはできませんが、アーカイブノードはそのクエリにミリ秒で答えます。

イーサリアムフルノードとアーカイブノードに関する簡単なガイド @0xZeeve

言い換えると、理論的には、フルノードがディスクに書き込んだデータ（完全なチェーン履歴）からこのクエリの答えを計算することは可能ですが、多くの実行クライアントがこの機能をサポートしていません。10年後、多くのユーザー、たとえそれが熟練したユーザーであっても、完全/アーカイブノードを実行するとは考えられないと思います。この選択肢が合理的なものになるためには、L1のスループットを完全に合理的ではないレベルに制限する必要がありますが、L1では最小限のトレードオフでより多くのスループットを得ることができるため、これは完全に合理的ではありません。ほとんどのユーザーがzk-proofで新しいブロックを簡単に検証できるとき、その利点が非常に大きい場合、これは追求する価値のあるトレードオフだと思います。

おそらく、HDD で効率的に実行でき、アーカイブされた状態を100 TB 以上安価に保存することが実用的になる実行クライアントを入手できるかもしれません。それにより、なんらかの理由でイーサリアムのすべてをアーカイブしたいユーザーがそうすることができ、Erigon の目標の1つは HDD でフルアーカイブノードを実行できるようにすることだと思います。

イーサリアムの新時代

最終的には、Ethereumの未来はそのネットワークを構成するノードによって形作られるでしょう。ほとんどのユーザーにとって最も現実的な選択肢としてステートレスノードを取り入れることで、ネットワーク上にステートフルでフル/アーカイブノードの強力な存在の価値を実現しつつ、分散、セキュリティ、スケーラビリティの完璧なバランスを作り出し、すべてのユーザーに利益をもたらすことができます。

免責事項：

1. この記事は再刊されました[2077 研究)].すべての著作権は原著作者に帰属します[@centauridoteth]. If there are objections to this reprint, please contact the ゲート レアンチームはすぐに対処します。
2. 責任の免責事項：この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. gate Learn チームは記事を他の言語に翻訳しました。翻訳された記事のコピー、配布、または盗作は、特に言及されていない限り禁止されています。