イーサネット財団：イーサネットの進化経路と今後の課題

ステータスは、ほぼすべての機能の基盤です。

財布は残高と過去の操作を表示するためにステータスに依存しています。

非中央集権アプリ（Dapps）は、自分が知っていることを知るためにステータスに問い合わせます。(

インフラ（ブロックブラウザー、クロスチェーンブリッジ、インデクサーなど）は継続的に状態を読み取り、その上でサービスを提供します。

ステートが大きくなりすぎたり、中央集権化されすぎたり、サービスが難しくなりすぎたりすると、上記のレイヤーはすべて壊れやすくなり、コストが高くなり、分散化しにくくなります。

2, L1のスケーリングは結果をもたらす

レイヤー2ネットワーク、EIP-48ネットワーク、EIP-48ネットワークを通じて、長年にわたってネットワークのスケーリングに持続的に取り組んできました。レイヤー2ネットワーク、EIP-4844、ガス・キャップの引き上げ、ガス料金の再値上げ、提案者と建設業者の分離メカニズムの組み込み。それぞれのステップによって、ネットワークの処理能力は向上しているが、同時に新たな課題も生じている。

課題その1：膨張し続ける状態

イーサの状態サイズは大きくなる一方です。すべての新しいアカウント、ストレージ操作、バイトコードの書き込みは、ネットワークが保持しなければならないデータ量を恒久的に増加させます。

このため、特定のコストが発生します。

検証者とフルノードは、より多くのデータを保存しなければなりません。状態がスケールアップすると、データベースはさらなる作業負荷を処理しなければならず、その結果、効率が低下します。

RPCサービスプロバイダは、アカウントまたは保存されたデータがいつでも照会できるように、完全な状態にアクセス可能にしておく必要があります。

ステートの増加はノードの同期を遅くし、安定性を低下させます。

ガス上限を増やすと、ブロックあたりにより多くの書き込み操作を収容できるため、状態の肥大化を悪化させる可能性があります。他のパブリック・チェーンはすでにこの問題を経験している。状態がスケールアップするにつれて、平均的なユーザーがフルノードを実行することが難しくなり、少数の大規模なサービスプロバイダーの手に状態データが集中することになります。

イーサでは、ほとんどのブロックがすでに専門業者によって製造されています。核心的な懸念は、重要な瞬間にエンドツーエンドのブロック構築を行える独立したプレーヤーがまだどれだけいるかということです。ごく少数の参加者だけが完全な状態を保存して提供できるのであれば、検閲への耐性と信頼された中立性が損なわれることになります。

FOCILやVOPSのようなメカニズムが、専門化された構築者のエコシステムにおいて検閲耐性を保護するように設計されていることは、ポジティブな点の一部である。しかし、その有効性は、手頃なコストで状態データにアクセスし、保存し、提供できる必要があるノードの健全な生態系に依存している。したがって、状態の成長を制御することは、オプションの最適化ではなく、必要な前提条件なのです。

私たちは、問題のある転換点を特定するために、積極的にストレステストを行っています。

ノードがチェーンヘッドに従うことが困難になる場合。

極端なステートサイズでクライアントの実装が失敗する場合。

課題その2: ステートレスアーキテクチャにおいて、誰がステートの保存と提供に責任を持つのか？

イーサリアムが恒久的に現在のガス上限を維持するとしても、いずれは状態のインフレが起こるでしょう。その間、コミュニティは明らかに高いスループットを期待しています。

ステートレス方式は、検証者がブロックを検証するために完全な状態を保持する必要がなく、検証の証明のみを保持すればよいという大きな制限を取り除きます。これは、より高いスループットに対するコミュニティのニーズを満たすと同時に、かつては暗黙の了解であった真実、つまり、状態の保存は、各バリデータに結び付けられるのではなく、別個のより専門的な機能へと進化させることができるということを明らかにする、重要なスケーラビリティのブレークスルーです。

その時点で、ほとんどの状態は、

ブロック構築者

RPCサービスプロバイダー

によってのみ保存されるかもしれません。

その他の専門化されたオペレーター（MEVサーチャーやブロックブラウザなど）。

言い換えれば、国家はより中央集権的になるということです。

これは複数の結果をもたらす可能性があります。

同期の難しさの増大：中央集権的なサービスプロバイダーが状態へのアクセスを制限し始める可能性があり、新しいプロバイダーが始めるのが難しくなります。

同期の難しさの増大：中央集権的なサービスプロバイダーが状態へのアクセスを制限し始める可能性があり、新しいプロバイダーが始めるのが難しくなります。

検閲への耐性が弱まる：検閲された状態データが利用できない場合、FOCILのような反検閲メカニズムが機能しなくなる可能性がある。

システムの回復力のリスク：完全な状態を保存し提供するエンティティが少数である場合、そのサービスの中断や外部からの圧力により、エコシステムのコンポーネントの大部分へのアクセスがすぐに遮断される。

エコシステムの構成要素の大部分へのアクセスを遮断する。

たとえ多くのエンティティが状態を保存していたとしても、それらが実際にサービスを提供していることを検証する効果的な方法が不足しており、既存のインセンティブでは不十分です。スナップショット同期はデフォルトで広くサポートされているが、RPCサービスはサポートされていない。コストを下げ、状態サービスの一般的な魅力を高めなければ、ネットワークが自身の状態にアクセスする能力は、少数のサービス プロバイダーによって制限されるでしょう。

この問題はレイヤー2ネットワークにも及びます。パッケージ化されたトランザクションを強制するユーザーの能力は、L1上のロールアップ契約の状態への信頼できるアクセスに依存しています。L1の状態アクセスが脆弱になったり、高度に中央集権化されたりすると、これらの安全弁メカニズムを実際に運用することは難しくなります。

3, 私たちが見る3つの主な方向性

(1) 状態の有効性

すべての状態データが永久的に同じ重要性を持つわけではない。私たちの最近の分析によると、約80%の状態データは1年以上アクセスされていません。しかし、ノードは依然としてこの状態を永久に保存するコストを負担している。

状態失効メカニズムの中核となる考え方は、「アクティブセット」から非アクティブな状態を一時的に削除し、必要なときに何らかの形で証明して復元することです。

最初のカテゴリ: mark, expire, resurrect

プロトコルは、もはやすべての状態を永続的にアクティブであるとは見なしませんが、その代わりに、めったに使用されない状態を非アクティブとしてマークし、何らかの証明によって復元できるようにします。状態を非アクティブとしてマークすることで、各ノードが保持するアクティブ・セットにはもはや存在しないが、歴史的な存在証明によって将来的に復元できるようにする。現実的な効果としては、一般的に使用される契約や残高はアクティブなままであり、安価にアクセスできる一方、長い間忘れられていた状態は各ノードによって継続的にホストされる必要はなく、誰かが再び必要としたときに呼び出すことができます。

タイプ2：マルチサイクル故障メカニズム

マルチサイクル設計では、個々のエントリーを故障させる代わりに、状態を周期的に分割します（たとえば、1周期＝1年）。1サイクル＝1年）。現在のサイクルは小さく、完全にアクティブであり、古いサイクルはリアルタイム実行の観点から凍結され、新しい状態は現在のサイクルに書き込まれる。古い状態は、以前のサイクルでの存在を証明することによってのみ復元できる。

マーク-フェイル-リザレクトメカニズムは、一般的により粒度が細かく、リザレクトプロセスはより簡単ですが、マークプロセスには追加のメタデータの保存が必要です。マルチサイクル失敗は概念的に単純で、アーカイブ機構とより自然に統合されていますが、復活証明はより複雑で膨大になる傾向があります。

結局のところ、どちらのタイプのシナリオも、一時的に非アクティブな部分を削除することでアクティブな状態を維持し、復活へのパスを提供することで合理化するという同じ目標を持っています。しかし、複雑さ、ユーザーエクスペリエンス、クライアントとインフラへの作業の割り当てという点では、より複雑です。

(2)状態アーカイブ

状態アーカイブは、コールド状態とホット状態を区別します。

ホットな状態とは、頻繁にアクセスする必要があるネットワークの部分です。

コールドな状態とは、履歴と検証可能性のためにまだ重要ですが、ほとんど触れられないネットワークの部分です。

ステートアーカイブ設計では、ノードは、最近頻繁に使用されたホットステートを、履歴データとは別に明示的に保存します。状態全体が増え続けても、素早くアクセスする必要がある部分（ホットデータセット）のサイズは制限されたままです。実際には、これはノードの実行性能（特に、状態へのアクセスにかかるI/Oコスト）が、チェーンが古くなっても劣化することなく、長期間にわたってほぼ安定した状態を維持できることを意味します。

(3)状態の保存とサーブの障壁を下げる

明らかな疑問は、より少ないデータを保持しながら目標を達成できるかということです。言い換えれば、ノードとウォレットは、完全な状態を永久に保存する必要がなく、まだアクティブな参加者として機能できるように設計できるでしょうか？

1つの有望な方向性は、部分的にステートレスなスキームです。

ノードはそのステートの一部のみを保存し、利用可能にします（たとえば、特定のユーザーやアプリケーションに関連するデータ）;

ノードはそのステートの一部のみを保存し、利用可能にします;ウォレットとライトクライアントは、一握りの大規模なRPCプロバイダーだけに依存するのではなく、必要な状態の一部を保存してキャッシュすることで、より積極的な役割を果たします。ストレージをウォレットと「ニッチ」ノードに安全に分散させることで、個々のオペレータの負担は軽減され、ステートホルダーコミュニティはより多様になります。

もう1つの方向性は、有用なインフラを運用するための障壁を低くすることです。

国家のごく一部にしかサービスを提供しないRPCノードの展開プロセスを簡素化する。

ウォレットやアプリが単一の完全なRPCエンドポイントに依存するのではなく、複数の部分的なデータソースを検出し、統合できるようにするプロトコルとツールを設計する。

4, 将来の方向性

イーサの状態は、プロトコルの将来のための多くの核心的な問題の鍵に静かになりつつあります:

参加への障壁となるために、状態はどの程度まで大きくなるのでしょうか？

検証者が状態なしでブロックを安全に検証できるようになったら、誰が状態を保存するのでしょうか？

誰がユーザーにステートサービスを提供するのでしょうか？彼らのインセンティブは？

これらの質問のいくつかはまだ未解決ですが、方向性は明確です：ステートのパフォーマンス制約を減らし、ストレージのコストを削減し、サービスへのアクセシビリティを向上させます。

私たちの現在の焦点は、ローリスクでハイリターンの仕事を進めることです：

アーカイブソリューション

過去のデータを保存するアーカイブ・ソリューションに依存しながら、アクティブな状態のサイズを制御するプロトコル外のソリューションを実験しています。これにより、パフォーマンス、ユーザーエクスペリエンス、O&Mの複雑性に関する実世界のデータが得られる。検証されれば、必要に応じてプロトコル内でのアップグレードに進めることができます。

RPCを強化したステートレス・ノード

ユーザーとアプリケーションの大部分は、集中型のRPCサービス・プロバイダーを介してEtherとやり取りします。

完全な状態を保存しない場合でも、ノードを実行する難易度とコストを削減します。

複数のノードが協力して完全な状態のサービスを提供できるようにします。

RPCサービスプロバイダの多様性を高め、シングルポイントのボトルネックを回避する。

これらのプロジェクトは、即時の有用性と将来的な互換性の組み合わせのために慎重に選ばれました。