Paradigm：イーサリアムのステート増加に関する課題と解決策
TechFlow厳選深潮セレクト
Paradigm：イーサリアムのステート増加に関する課題と解決策
イーサリアムは現在の状態の成長率を長年にわたり維持できる可能性がある。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Storm Slivkoff、Georgios Konstantopoulos
翻訳：Luffy、Foresight News
イーサリアムの状態増加とガス制限との関係は広く誤解されている。多くの人々は、状態の増加がイーサリアムの主要なスケーリングボトルネックであると考えている。しかし、状態増加に関する議論は、しばしば用語の不正確さや詳細な定量的証拠の欠如により妨げられている。
データ駆動型のアプローチを採用することで、状態増加の問題をより明確にすることができる。本稿では、高解像度のデータセットを活用して、状態増加の規模と形状について理解を深める。この過程で、我々は驚くべき結論に達した：現代のコンシューマー向けハードウェアは、現在の状態増加率を少なくとも10年間維持できるということだ。さらに、ソフトウェアとハードウェアの継続的な改善を考慮すれば、この期間は無期限に延長される可能性がある。
我々は、イーサリアムには明確なロードマップがあると考えている。1）状態増加をスケーリングボトルネックとして完全に排除すること、2）世界的な規模の分散型金融システムを支えるレベルまでガス制限を引き上げること。本シリーズの目的は、こうしたスケーリングロードマップを理解し策定するための科学的手法を開発することである。
本稿は、イーサリアムのスケーリングに関するシリーズの第1部であり、主に状態増加について扱う。第2部は履歴の増加、第3部は状態アクセス、第4部はガス制限について述べる予定である。
状態増加とは何か？
「状態増加」という言葉は、一般的に、イーサリアムノードのハードウェア容量を超えるデータサイズに関連するあらゆるスケーリングボトルネックを包括的に表すために使われる。しかし、状態増加はこのような単一の方法で考えるべきではない。イーサリアムのデータには複数の種類があり、それぞれがノードの基盤となるハードウェアコンポーネントと独特の関係を持っている。したがって、それぞれの異なるスケーリングボトルネックを説明するために正確な用語を使用することは極めて重要である。
状態とは、新しいイーサリアムブロックを構築・検証するために必要な一連のデータのことである。状態は、コントラクトバイトコード、コントラクトストレージ、アカウント残高、アカウントnonceから構成される。履歴とは、ノードがジェネシスブロックから最新ブロックまで同期するために必要なデータセットのことである。履歴はブロックとトランザクションからなる。状態と履歴は重ならないデータセットである。これらの定義から、少なくとも3つの異なる現象がノードのハードウェアに大きな負荷を与えていることがわかる：
-
状態増加：新しいアカウント、新しいコントラクトバイトコード、新しいコントラクトストレージの蓄積。
-
履歴増加：新しいブロックと新しいトランザクションの蓄積。
-
状態アクセス：ブロックの構築と検証に使用される一連の読み書き操作。
各ボトルネックは、ノードのハードウェア制限と独自の関係を持っている。特に重要な4つのハードウェア制限は以下の通りである：
-
ネットワークI/O：ノードがピアノードと安定した合意に達するために維持しなければならないアップロードおよびダウンロード速度。
-
ストレージ容量：ノードがブロックを構築・検証・配布するために永続ストレージに保持しなければならないデータ量。
-
メモリ容量：ノードがブロックチェーンの先端と同期するためにメモリ内にキャッシュしなければならないデータ量。
-
ストレージI/O：ノードがブロックチェーンの先端と同期するために毎秒実行しなければならない読み書き操作の量。
これらのボトルネックとハードウェア制限の関係を図1に示す。
図1：イーサリアムのスケーリングボトルネック
図の上部から見ていくと、イーサリアムがトランザクションを実行するたびに、そのトランザクションで使用されるすべてのリソースはガスによって価格付けされる。したがって、イーサリアムのガス制限は、すべての形式のオンチェーン活動をレート制限する一次元の量である。ガス制限の下流には、ブロックサイズと各ブロックの操作がある。各ブロックのバイト数が多いほど、履歴は速く増加する。各ブロックのI/O操作が多いほど、状態アクセス率が大きくなり、通常は状態増加率も大きくなる。
したがって、スケーリングボトルネックはノードのハードウェア制約と次のように関連している：
-
大量の状態増加をサポートするためには、ノードは十分なストレージとメモリ容量を持っていなければならない。状態が大きすぎると、ストレージに収まらなくなるか、頻繁にアクセスされる部分がメモリに収まらず、パフォーマンスが低下する。
-
大量の履歴増加をサポートするためには、ノードは大量のブロックデータを共有するのに十分なネットワーク帯域幅と、そのデータを保存するのに十分なストレージ容量を持っていなければならない。
-
大量の状態アクセスをサポートするためには、ノードはホットな状態をキャッシュするのに十分なメモリと、十分な読み書き操作をサポートするのに十分なストレージI/Oを持っていなければならない。
特に状態増加に関しては、状態の規模の成長速度が消費者用ハードウェアの継続的な進歩を上回らないようにすることが主な課題である。ノードのメモリとストレージは有限なリソースであるため、状態の増加が止まるか、ハードウェアが定期的にアップグレードされない限り、最終的にはボトルネックに達する。幸運にも、メモリとストレージのハードウェアは長年にわたり着実に改善されてきた。それでも、これらの改善の正確な予測は不確かであり、急速な成長が無期限に続くと考えるべきではない。
今後導入予定のEIP-4844によるデータblobは、これらのスケーリング関係にいくつかの変化をもたらすことに注意されたい。EIP-4844以降、ディスク上に蓄積される履歴は大幅に減少すると予想されるが、大量のBlobデータを転送する際のネットワークI/Oは著しく増加する可能性がある。
本稿では、メモリ容量や状態アクセスパターンではなく、主に状態サイズと状態増加率に焦点を当てる。他のテーマについては、今後の研究で取り上げる予定である。
イーサリアム状態の構成
状態増加を理解する次のステップは、状態の総規模と各構成要素の寄与度を調べることである。現在、イーサリアムの状態データ量は約245.5GBである。この数値はrethノードで測定されたものだが、各ノードクライアントでの数値は表に示すようにおおむね比較可能である。アカウント、コントラクトバイトコード、コントラクトストレージはそれぞれ状態の14.1%、4.3%、81.7%を占めている。
図2は、さまざまなスマートコントラクトプロトコルがどれだけの状態容量を占有しているかを示している。以下の図では、各コントラクトカテゴリのサイズは、そのストレージスロットとバイトコードが占めるバイト数を表している。
図2：イーサリアムの状態分布
図2の数値は、ノードクライアントがディスク上に保存しなければならない総バイト数を示している。これにはインデックスに使用されるデータやその他のストレージオーバーヘッドが含まれる。各アカウントおよび各ストレージスロットの平均ストレージサイズはそれぞれ133.6バイトおよび191.3バイトである。
以下は図2から得られる最も重要な情報のいくつかである：
-
トークンが状態の最大の要因である。イーサリアムの状態において最も大きな貢献をしているのはERC-20とERC-721トークンであり、それぞれ状態の27.2%と21.6%を占めている。トークンがこれほど多くの状態を占める理由は、各トークンの各ユーザー残高を個別の32バイトのストレージスロットに別々に保存しなければならないためである。したがって、イーサリアムの状態サイズの半分は、イーサリアムのユーザー総数と各ユーザーが保有するトークンの総数に比例している。
-
イーサリアムの状態の少なくとも7.4%は休眠状態にある。イーサリアム状態の中でも最大級のコントラクトのいくつかは、もはやアクティブではない。これらは、ブロックスペースや状態スペースが現在よりもはるかに安価だった時代にリリースされたもので、ゲーム、ギャンブル、詐欺カテゴリーの大多数のプロトコルに加え、IDEX、Etherdelta、Oasisなど多くの非アクティブなDEXが含まれる。これらのプロトコルは合わせてイーサリアム状態の少なくとも7.4%を構成している。実際の休眠状態の割合はこれより高いはずであり、ERC-20、ERC-721、その他のカテゴリーにおけるロングテールのプロジェクトも含まれる。
-
L2クロスチェーンブリッジはイーサリアム状態の2%未満を占めている。圧縮、ZK証明、改良されたエンコーディングなどの技術を利用することで、L2のトランザクションはメインネットよりも効率的に状態を利用している。L2はメインネットの状態のわずか2%しか占めていないにもかかわらず、L2の1秒あたりの取引総数はメインネットの5倍以上である。
イーサリアムの状態はどのくらいの速さで増加しているか？
状態増加において最も重要な側面は、時間とともに変化する状態増加率である。この比率は、状態問題の深刻さとその傾向を明らかにする。
図3は、2015年のイーサリアム創設以来の状態増加率を示している。これらの増加率は、各コントラクトカテゴリ内のコントラクトバイトコードとコントラクトストレージを合計して計算されたものである。
図3：時間経過に伴うイーサリアムの状態増加
以下は図3から得られる最も重要な情報のいくつかである：
-
現在、状態は月間約2.62GB増加しており、過去のピークである月間5.99GBを下回っている。これらの数字から予測すると、5年後の状態総量は396GBから606GBの間になる。現在の増加率を年率12.8%と表現する人もいるかもしれないが、状態が継続的に増加する一方で、絶対的な増加率は低下しており、単純な指数関数的成長モデルは適切ではない可能性がある。
-
最近の状態増加の減少は、主にNFT活動の減少によるものである。さまざまなネットワーク活動の間に一定程度の相関関係があることを期待するかもしれないが、個々の状態寄与者間には驚くほど独立性がある。たとえば、ここ数年の総状態増加率は低下しているが、2020年以降、ERC-20の状態増加率は実際には年々増加している。
-
状態増加は2021年以来の最低水準に達している。この減少はかなり意外であるが、状態が主に新しいトークン残高に比例していることを考えれば理にかなっている。もし状態増加率が低下し続けているのであれば、イーサリアムはより高いガス制限をサポートできる能力を持っていると思われる。それは事実かもしれないが、以下の点を覚えておくことは重要である。1）現在のガス価格モデルでは、新たな急増を阻止するものは何もない。2）状態はガス制限の下流にある唯一のボトルネックではない。
許容可能な状態増加の値とは？
ここで我々は、イーサリアムの状態の1）規模、2）構成、3）増加率を知った。では、許容可能な状態増加の範囲をどのように決定すればよいだろうか？この問題は複雑である。なぜなら、それは予測不可能な市場の力と、イーサリアムがどのようなトレードオフを行うべきかという哲学的選択の両方に依存しているからである。
最も単純なモデルから始めよう。将来のハードウェア改善がないと仮定して、現在の状態増加レベルが一般のコンシューマーハードウェア上でどれだけ持続可能かを検討する。図3に示すように、近年の状態の年間増加は31GB/年から72GB/年の間にある。現在、一般的なコンシューマーハードウェアの最大ストレージ容量は約4TB、メモリ容量は約64GBである。これにより、単純なストレージとメモリの需要予測モデルを作成できる：
-
ストレージ：ノードは現在、約1TBの状態データを保存する必要がある。実際には、多くのノードが少なくとも2TBのディスクを使用していることを意味する。単純化のため、将来的な履歴増加を無視しよう。あたかも我々がEIP-4444後の世界にいると仮定する。将来の稼働時間を（残りストレージ容量）÷（状態増加率）で計算できる。表に示すように、ノードのストレージハードウェアは、2TBの空き容量を使い果たすことなく、10年以上にわたり現在の状態増加速度をサポートできる。現在の状態増加率では、4TBでほぼ半世紀にわたって運用が可能である。
-
メモリ：Ethereum-on-armのユーザーレポートによると、イーサリアムノードを動作させる最小限の実用的メモリは約16GBである。メモリ需要が状態サイズに比例して増加すると仮定すれば、年間30GB～72GBの状態増加は、年間2GB～4.7GBの追加メモリ需要に換算される。したがって、現在のガスレートでは、32GBのRAMがあれば3年から8年は十分である。64GBのRAMであれば、10年から23年は十分である。
これは多くの仮定を含む単純化されたモデルである。このモデルの拡張条件としては、1）履歴増加、2）メモリ需要の非線形的拡大、3）ハードウェアコストの低下、4）ガス制限の引き上げ、5）オペコードガスの再価格設定、6）将来のイーサリアムアーキテクチャの改善などが考えられる。これらの要素はそれぞれ非線形に相互作用し、時間とともに変化する可能性がある。これらのモデル拡張については、今後の研究で探求する予定である。
長期的な持続可能性が望ましいことは強調されなければならない。現代のハードウェアが数年にわたって運用をサポートできても、稼働期間を短縮することを軽視すべきではない。状態増加を加速するあらゆる計画には、ハードウェアやソフトウェア環境の予測不可能な変化に対応するための十分なバッファが必要である。
状態増加問題をどう解決するか？
状態増加問題を解決するために、多くの異なる提案がなされている。イーサリアムアーキテクチャの三つの改善が特に目立っている：Rollup、Verkle Trie、状態の期限切れである。まとめて言えば、これらは短期的、中期的、長期的な状態増加問題を解決する包括的なロードマップを構成している。
短期的：Rollupは状態増加問題を直接解決しないが、ネットワークロードを軽減する。図2および図3に示すように、Rollupはメインネットよりも効率的に状態を利用することができる。アクティビティをL2に移行するには、ユーザーの退出をサポートするためにメインネットに一定量の状態を保存する必要がある。しかし、L2トランザクションの状態フットプリントは、メインネットのトランザクションよりもはるかに小さい。したがって、Rollupはエコシステム内の総活動をより持続可能に増加させることができる。今後導入予定のEIP-4844により、Rollupの採用はさらに増加すると予想され、blobによりRollupはより安価になる。
中期的：Verkle Trieは検証者ノードの状態増加問題を解決するが、新しいトランザクションを構築するノードの問題は解決しない。Verkle Trieはイーサリアム状態の新しいデータ構造である。より効率的なライトクライアントと「ステートレス」ノードをサポートする。これらのノードは、既存の状態値を知らなくても新しいブロックを検証できるようになる。これにより、検証者ノードの状態増加問題が解消される。新しいトランザクションの構築には依然として状態の保存とアクセスが必要だが、これは今日の状況よりも持続可能である。なぜなら、トランザクションの構築は多数のマシンに容易に分散できるタスクだからである。範囲としては、Verkle Trieの実装には数年かかる可能性のある大規模な工学的取り組みである。
長期的：状態の期限切れはすべてのノードの状態増加問題を解決するが、追加のインフラが必要である。状態の期限切れにより、ノードは図2のように状態の非アクティブな部分を破棄できる。なお、「状態休眠」という用語の方が適切かもしれない。なぜなら、既存のほとんどの提案では、「期限切れ」状態を証明によって復元できるからである。時間が経つにつれて期限切れ状態が失われるという懸念については、履歴（ブロックおよびトランザクションデータ）が利用可能である限り、状態は再構築できる。したがって、EIP-4444の履歴保存問題に対して開発されるどんな解決策も、状態保存問題も同時に解決する。ただし、Verkle Trieが目標を達成すれば、状態の期限切れは不要になるかもしれない。
状態増加問題の解決策は他にもあり、状態レンタルやシャーディングなどがあるが、過去にはこれらがユーザーエクスペリエンスや健全性に影響を与える可能性があるとされていた。遠い将来の究極の解決策を実現するには、これらの解決策を他のものと組み合わせる必要があるかもしれない。
まとめ
状態増加はイーサリアムのスケーリングにおける重要な課題ではあるが、解決可能な問題であると我々は信じている。我々のデータ解釈によれば、イーサリアムは現在の状態増加レベルを長年にわたり維持でき、アーキテクチャのアップグレードに十分な余裕を持つことができる。
我々は、経験的手法がイーサリアムのガス制限の設計と、最終的なスケーリングソリューションへの道筋を導く上で極めて重要だと信じている。本稿はその目標に向けた一歩にすぎない。状態を超える他のタイプのデータもあり、それぞれがイーサリアムノードとイーサリアムのガス制限に負担をかけている。今後の研究では、こうした他のボトルネックを探求したい。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Paradigm
