jakiro
著者: Wei Han Ng、Carlos Pérez、無国籍コンセンサス研究チーム。翻訳: @bitchainvisionxiaozou
イーサリアムは、小規模な実験的なネットワークから、世界的なインフラストラクチャの重要なコンポーネントに成長しました。毎日の決済額で数十億ドルを決済し、数千のアプリケーションを調整し、レイヤー 2 ネットワーク (L2) エコシステム全体をサポートします。
すべては最終的に 1 つのコアとなる基礎コンポーネントである state (状態）。
1、何ですか」ステータス」そしてその重要性
ユーザーの残高はウォレットには保存されず、イーサリアムの状態に保存されます。状態は、アカウント、コントラクト ストレージ (コントラクトによって書き込まれたすべてのデータ)、バイトコード (スマート コントラクトを使用するときに実行されるロジック) など、「イーサリアムが現在知っているすべてのもの」として大まかに理解できます。
状態は、ほぼすべての機能の基礎です。
ウォレットはこれを利用して残高や過去の操作記録を表示します。
分散型アプリケーション (Dapps) は、既存のポジション、注文、またはメッセージを知るためにクエリを実行します。
インフラストラクチャ (ブロック エクスプローラー、クロスチェーン ブリッジ、インデクサーなど) は継続的に状態を読み取り、その上でサービスを提供します。
国家が大きくなりすぎたり、集中化しすぎたり、サービスを提供することが困難になったりすると、上記のすべての層がより脆弱になり、より高価になり、分散化がより困難になります。
2、L1拡大には影響も伴う
イーサリアムは、第 2 層ネットワーク、EIP-4844、ガス制限の引き上げ、ガス料金の再価格設定、および組み込みのプロポーザーとビルダーの分離メカニズムを通じて、ネットワークの拡張に長年取り組み続けてきました。各ステップでネットワーク処理能力は向上しましたが、新たな課題も生じました。
課題 1: ステータスは拡大し続ける
イーサリアムの状態規模は拡大するばかりです。新しいアカウント、ストレージ操作、およびバイトコードの書き込みが行われるたびに、ネットワークが保持する必要があるデータの量が永続的に増加します。
これにより、具体的なコストが発生します。
バリデーターとフルノードはより多くのデータを保存する必要があります。状態のスケールが大きくなるにつれて、データベースは追加のワークロードを処理する必要があり、効率が低下します。
RPC サービス プロバイダーは、完全にアクセス可能な状態を維持し、アカウントや保存されたデータがいつでもクエリできるようにする必要があります。
ステータスが増加すると、ノードの同期が遅くなり、安定性が低下します。
ガス制限を増やすと、各ブロックがより多くの書き込み操作に対応できるようになるため、状態の肥大化が増加します。この問題は他のパブリックチェーンでもすでに発生しています。州の規模が拡大するにつれて、一般のユーザーがフルノードを実行することが困難になり、その結果、州データが少数の大規模なサービスプロバイダーの手に集中することになります。
イーサリアムでは、ほとんどのブロックはプロのビルダーによって作成されています。中心的な懸念は、重要な瞬間に、どれだけの独立した事業体がエンドツーエンドのブロック構築を完了できるかということです。非常に少数の参加者だけが完全な状態を保存して提供できる場合、検閲への耐性と信頼できる中立性が損なわれます。検閲されたトランザクションを含むブロックを構築できるプリンシパルが少なくなるためです。
プラスの要因の一部は、FOCIL や VOPS などのメカニズムが、プロのビルダー エコシステムにおける検閲耐性を確保するように設計されていることです。しかし、その有効性は依然として、手頃なコストで状態データにアクセス、保存、提供できるノードの健全なエコシステムに依存しています。したがって、状態の成長を制御することは必須の前提条件であり、オプションの最適化ではありません。
問題の臨界点を特定するために、私たちはストレス テストを積極的に実施しています。
状態の成長がスケーリングのボトルネックになるのはどのようなときですか?
状態の規模によってノードがチェーン ヘッドに従うことが困難になるのはどのような場合ですか。
クライアントの実装が極端な状態スケールで失敗した場合。
課題 2: ステートレス アーキテクチャでは、状態の保存と提供は誰が担当しますか?
たとえイーサリアムが現在のガスキャップを永続的に維持したとしても、最終的には状態インフレの問題に遭遇するでしょう。同時に、コミュニティは明らかにスループットの向上を期待しています。
ステートレス スキームは重要な制限を取り除きます。バリデーターはブロックを検証するために完全な状態を保持する必要はなく、証明のみを保持する必要があります。これは、コミュニティのより高いスループットのニーズに対処するとともに、状態ストレージが各バリデーターに結び付けられるのではなく、独立したより専門化された機能に進化できるというかつて隠されていた事実を明らかにする重要なスケーラビリティのブレークスルーです。
その時点で、ほとんどの状態は次の方法でのみ保存できます。
ブロックビルダー。
RPC サービスプロバイダー。
その他の専門オペレーター (MEV サーチャーやブロック エクスプローラーなど)。
言い換えれば、国家はより中央集権的になるだろう。
これには次のような複数の影響があります。
同期の難しさの増加: 集中型サービス プロバイダーがステータスへのアクセスを制限し始める可能性があり、新しいサービス プロバイダーの開始が困難になります。
検閲への耐性の弱体化: 検閲済みステータスデータを取得できない場合、FOCIL などの反検閲メカニズムが機能しない可能性があります。
システム復元力のリスク: 少数のエンティティだけが完全なステータスを保存して提供している場合、サービスの中断や外部からの圧力により、エコシステムのほとんどのコンポーネントへのアクセスがすぐに遮断されてしまいます。
多くの企業が状態を保存しているにもかかわらず、企業が実際にサービスを提供していることを検証する効果的な方法はなく、既存のインセンティブは不十分です。スナップショット同期はデフォルトで広くサポートされていますが、RPC サービスはサポートされていません。国家サービスのコストを削減し、その普遍的な魅力を高めなければ、ネットワークが独自の国家にアクセスできる能力は少数のサービス プロバイダーに限定されてしまいます。
この問題はレイヤー 2 ネットワークにも影響します。ユーザーがパッケージ化されたトランザクションを強制できるかどうかは、L1 上のロールアップ コントラクト状態への信頼できるアクセスに依存します。L1 状態へのアクセスが脆弱になるか、高度に集中化されると、これらの安全弁機構を実際のアプリケーションで動作させることが困難になります。
3、私たちが見ている3つの主要な方向性
(1) ステータスの有効期間
すべての状態データが同じように永続的に重要であるわけではありません。私たちの最近の分析では、州データの約 80% が 1 年以上アクセスされていないことがわかりました。ただし、ノードはこの状態を永続的に保存するコストを負担します。
状態有効性メカニズムの中心的な考え方は、「アクティブ セット」から非アクティブな状態を一時的に削除し、必要に応じて何らかの形式の証明を通じてそれを復元することです。大まかに言うと、次の 2 つの主要なカテゴリに分類できます。
カテゴリ 1: マーク、無効化、復活
このプロトコルは、すべての状態を永続的にアクティブとして扱うのではなく、めったに使用されない状態を非アクティブとしてマークし、各ノードによって維持されるアクティブ セットには保持されなくなりますが、歴史的な存在証明を通じて将来復元できるようにします。実際の効果としては、一般的に使用される契約と残高はアクティブなままであり、アクセスコストが低い一方で、長い間忘れられていた状態は各ノードで継続的に保持される必要がなく、誰かが再度必要になったときに呼び出すことができるということです。
カテゴリ 2: 複数サイクルの故障メカニズム
複数期間の設計では、個々のエントリを無効にするのではなく、状態を定期的に期間に分割します (たとえば、1 期間 = 1 年)。現在のサイクルはより小さく、完全にアクティブになり、古いサイクルはリアルタイム実行の観点から凍結され、新しい状態が現在のサイクルに書き込まれます。古い状態は、前のサイクルでの存在を証明することによってのみ復元できます。
通常、マーク無効化復活メカニズムはより洗練されており、復活プロセスはより単純ですが、マーキングプロセスには追加のメタデータを保存する必要があります。マルチサイクル障害は概念的に単純で、より自然にアーカイブ メカニズムと統合されますが、復活の証明はより複雑で大規模になる傾向があります。
最終的に、これら 2 つのアプローチは同じ目標を共有します。つまり、非アクティブな部分を一時的に削除することでアクティブな状態を維持しながら、復活への道を提供します。ただし、複雑さ、ユーザー エクスペリエンス、およびクライアントとインフラストラクチャへの作業の割り当てにおいて、異なるトレードオフが生じます。
(2) ステータスアーカイブ
ステータス アーカイブは、ステータスをコールド ステータスとホット ステータスに分割します。
ホットステートは、頻繁なアクセスを必要とするネットワークの部分です。
コールドステートは、歴史と検証可能性にとって依然として重要ですが、ほとんど触れられていない部分です。
ステート アーカイブ設計では、ノードは最近頻繁に使用されたホット ステートと履歴データを個別に明示的に保存します。全体的な状態が拡大し続けても、迅速にアクセスする必要がある部分 (ホット データ セット) のサイズは制限されたままになる可能性があります。実際には、これは、ノードの実行パフォーマンス、特に状態にアクセスするための I/O コストが、チェーンが古くなっても低下することなく、時間が経っても基本的に安定した状態を維持できることを意味します。
(3) 状態ストレージとサービスのしきい値を下げる
明らかな疑問は、保持するデータを減らしながら目標を達成できるかということです。言い換えれば、完全な状態を永続的に保存する必要がなく、有効な参加者として機能するノードとウォレットを設計できるでしょうか?
有望な方向性の 1 つは、部分的にステートレスなソリューションです。
ノードは部分的な状態 (特定のユーザーまたはアプリケーションに関連するデータなど) のみを保存および提供します。
ウォレットとライト クライアントは、少数の大規模な RPC サービス プロバイダーに完全に依存するのではなく、必要な状態フラグメントの保存とキャッシュにおいてより積極的な役割を果たします。ストレージをウォレットや「ニッチ」ノードに安全に分散できれば、個々のオペレーターの負担は軽減され、国家保有者のグループはより多様になります。
もう 1 つの方向は、有用なインフラストラクチャを実行するための障壁を下げることです。
状態の一部のみにサービスを提供する RPC ノードをデプロイするプロセスを簡素化します。
ウォレットとアプリケーションが、単一の完全な RPC エンドポイントに依存するのではなく、複数のローカル データ ソースを検出して統合できるようにするプロトコルとツールを設計します。
4、今後の方向性
イーサリアムの状態は、密かにプロトコルの将来に関するいくつかの中核的な問題の鍵となりつつあります。
州の規模が拡大すると、参加の障壁となるのはどの程度ですか?
バリデーターが状態を必要とせずにブロックを安全に検証できる場合、誰が状態を保存するのでしょうか?
ユーザーにステータス サービスを提供するのは誰ですか?インセンティブは何ですか？
いくつかの問題はまだ決定されていませんが、パフォーマンスに対する状態の制約を軽減し、ストレージコストを削減し、サービスのアクセシビリティを向上させるという方向性は明確です。
私たちが現在重点を置いているのは、低リスク、高収益の仕事を進めることです。
アーカイブスキーム
私たちは、履歴データを保存するアーカイブ ソリューションに依存しながら、アクティブな状態のサイズを制御するプロトコル外のソリューションを試みています。これにより、パフォーマンス、ユーザー エクスペリエンス、運用の複雑さに関する実際のデータが提供されます。検証が有効な場合は、必要に応じてプロトコル内アップグレードに昇格できます。
一部のステートレス ノードと RPC の機能強化
ほとんどのユーザーとアプリケーションは、集中型 RPC サービス プロバイダーを通じてイーサリアムと対話します。私たちは次の改善に取り組んでいます。
ノードがすべての状態を保存していない場合でも、ノードの実行の困難さとコストを軽減します。
複数のノードが連携して完全な状態サービスを提供できるようにします。
RPC サービス プロバイダーの多様性を高め、単一点のボトルネックを回避します。
これらのプロジェクトは、即時的な実用性と将来を見据えた互換性を考慮して慎重に選択されています。これらは両方とも、イーサリアムの現在の健全性を強化し、将来のより深いプロトコル アップグレードの基礎を築きます。
