Vitalikが最近の講演で頻繁に言及している「無状態」とは何ですか？

​翻訳：GaryMa、吴说区块链

Vitalikは最近の韓国ブロックチェーンウィーク、シンガポールでの講演、さらにはEthereum実行層のコア開発者会議（ACDE）で、共通の話題として「状態（State）」を挙げており、それに関連するさまざまな解決策の概念、例えば無状態、状態の期限切れ（State Expiry）、履歴データの期限切れ（History Expiry、EIP-4444）、Verkleツリー、さらにはアドレス空間の拡張\圧縮（Address Space Expand\Compression）についても言及しています。もちろん、これは新しいロードマップの調整計画ではなく、Vitalikが昨年11月に発表したEthereumの最新ロードマップにおいて、これらは主にThe VergeとThe Purgeの重要なルートに属しています。

この記事では、これらの2つの重要なルートといくつかの新しいアイデアの挑戦を組み合わせて、Vitalikの考える状態解決ルートを振り返ります。

状態（State）

Ethereumにおける状態とは、すべての外部所有アカウント（EOAs）、それらの残高、スマートコントラクトのデプロイ、および関連するストレージを含む総合的な台帳を指します。この状態は静的ではなく、新しいユーザーの増加や新しいスマートコントラクトのデプロイに伴って常に拡張されます。

現在、フルノードはこの増大するデータセットを保存する必要があり、ブロックを正しく検証し、状態遷移が正しいことを保証するため、検証プロセスは本質的に状態を持つものとなっています。このような増大するストレージ要件は、フルノードを運用するためのハードウェア要件を引き上げ、検証者の中心化を招くことになります。

etherscan.io/のデータによれば、現在、迅速に同期するフルノードを運用するには少なくとも1200Gb（Gethクライアントの例）を必要とし、これはすでに状態の剪定が行われ、以前の状態データが削除され、最近の状態のみが保持されている前提です。アーカイブノード、つまりフルノードがすべての履歴状態を保持する場合、必要な容量は約15,400Gbとなり、将来的にも増大し続けるため、コミュニティがよく言う「状態爆発」が発生します。

これはVitalikが韓国ブロックチェーンウィークで強調したことでもあり、ノードの中心化はEthereumネットワークが直面する最大の問題の一つであり、ノードの運用をより安価で容易にすることで解決すべきだと述べています。

この一連の課題に対処するために、Ethereumコミュニティは改善と最適化の方法を模索しており、冒頭で挙げたさまざまな解決策の概念がその一環です。

状態解決策

無状態（Statelessness）

無状態（Stateless）の核心概念は、状態データを外部化し、各ノードが完全な状態を保存する必要がなくなることです。このモデルでは、ノードはブロックヘッダーと関連する取引情報を維持し、状態証明（State Proofs）を通じて状態を検証し再構築します。

無状態の主な役割と意義は、ノードのストレージ負担を軽減し、ネットワークのスケーラビリティを向上させ、より多くのノードが容易に検証に参加できるようにし、同時にEthereumの非中央集権的な性質を維持することです。

Verkleツリー

現在、EthereumはMerkle-Patriciaツリーを使用して状態データをハッシュ化し圧縮しています。しかし、このツリー構造におけるMerkle証明のサイズは非常に大きくなり、無状態モデルに必要な証明には適さなくなる可能性があります。

この問題を解決するために、EthereumはVerkleツリーへの移行を計画しています。これはより効率的なデータ構造です。Merkle-PatriciaツリーとVerkleツリーは、特定の情報が状態ルートに存在することを簡単に確認できるようにする暗号証明を生成するという重要な能力を共有しています。

Verkleツリーの利点は、より小さな証明サイズを生成する際の効率が高いことです。

履歴データの期限切れ（History Expiry、EIP-4444）

EIP-4444は履歴データの期限切れを実施することを目的としたアップグレードで、ノードがピアツーピアネットワーク上で1年以上の履歴ブロックをホストするのを停止することを要求します。履歴データを削除することで、ノード運営者のディスクスペースの要求が大幅に軽減されます。また、異なるバージョンの履歴ブロックに適応するためのコードの必要性を排除することで、クライアントソフトウェアが簡素化されます。さらに、EIP-4444はPDS（Proto-danksharding）との組み合わせにより、定期的なデータ剪定を確保します；EIP-4444は年に1回剪定を行い、PDSは月に1回データブロックを剪定します。これによりノードのデータストレージ要求が減少しますが、履歴データの保存と復元に関する懸念も引き起こされます。

状態の期限切れ（State Expiry）

無状態性は、検証者がブロックを検証する際に完全な状態を維持する必要性を排除します。しかし、状態は消えず、その持続的な増加はネットワークの長期的な課題です。

この根本的な問題を解決するために、コミュニティは状態の期限切れ（State Expiry）という提案をしました。

状態の期限切れは、変わらない状態部分を自動的に剪定し、例えば1年後にそれらを別のツリー構造に移動し、主要なEthereumプロトコルから削除します。

重要なのは、状態の期限切れはVerkleツリーに移行した後にのみ実現可能になることです。また、Vitalikは韓国ブロックチェーンウィークKBW2023で、無状態とPBSがあれば、状態の期限切れは低優先度である可能性があると述べました。

なぜなら、ブロック提案者と構築者の分離（Proposer-Builder Separation、PBS）が実現した場合、無状態であってもブロック構築者はブロックを作成するために状態にアクセスする必要がありますが、その時点でのブロック構築者は状態の増加を効果的に処理できると予想されているからです。この分野ではある程度の中心化が許容され、構築者のノード性能は自然に要求を満たすことができるでしょう。

現在、プロトコルレベルのPBSはEthereumメインネットには組み込まれていませんが、Mev-Boost PBSの現在の市場分布を理解することで、将来のメインネットのトレンドを概観することができます。mevboost.picsのデータ統計は以下の通りです：

さらに、状態の期限切れ（State Expiry）の実現にはEthereumアドレス形式の変更が関与しており、現在2つの提案があります：アドレス空間の拡張（address space extension）vs アドレス空間の圧縮（address space compression）。前者はアドレスの長さを32バイトに増加させるもので（現在のアドレス形式は20バイト）、後方互換性を持たせるための複雑なロジックが必要で、既存のコントラクトも更新する必要があります。後者は20バイト形式を保持しつつ、最初の6バイトをプレフィックスおよびアドレス周期の識別に使用します。これにより互換性の問題が大幅に減少しますが、アドレスの長さが14バイトに減少し、衝突耐性を失うため、アドレス作成に潜在的な安全問題が生じることになります。これは現在コミュニティが直面している重大な課題でもあります。

まとめ

現在、私たちは上記の技術的解決策の実現の難しさと緊急性に基づいて、前後の優先順位を排除することができます（2\3\4は同等に扱えるかもしれません）：

1. Verkleツリー

2. PBS

3. 無状態

4. 履歴データの期限切れ（EIP-4444）

5. Ethereumアドレス形式の変更（圧縮/拡張）

6. 状態の期限切れ

以上のことから、ノードの運用のハードルを下げ、ノードの非中央集権性を維持し、潜在的な状態爆発の問題を軽減し、状態の増加を最適化してネットワーク通信負荷を軽減することができます。

もちろん、現在もなお道のりは長いです。

参考リンク：

https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

https://public.bnbstatic.com/static/files/research/ethereum-beyond-the-merge-.pdf

https://www.fx168news.com/article/295525