パラダイム：イーサリアムの状態成長の課題と解決策

執筆：Storm Slivkoff、Georgios Konstantopoulos

編纂：Luffy，Foresight News

イーサリアムの状態成長とそのガス制限との関係は広く誤解されています。一般的に、状態成長はイーサリアムの主要なスケーリングボトルネックであると考えられています。しかし、状態成長に関する議論は、用語の不正確さや詳細な定量的証拠の欠如によってしばしば妨げられます。

データ駆動型のアプローチを採用することで、状態成長の問題はより明確になります。本稿では、高解像度のデータセットを利用して、状態成長の大きさと形状を理解します。この過程で、驚くべき結論に達しました：現代の消費者ハードウェアは、現在の状態成長率を少なくとも10年間維持できる可能性があります。さらに、ソフトウェアとハードウェアの継続的な改善を考慮すると、この道は無期限に延長される可能性があります。

私たちは、イーサリアムには明確なロードマップがあると信じています：1）状態成長をスケーリングボトルネックとして完全に排除すること；2）ガス制限を、グローバル規模の分散型金融システムを支えるレベルに引き上げること。本シリーズの目的は、このスケーリングロードマップを理解し、策定するための科学的アプローチを開発することです。

本稿は、イーサリアムのスケーリングに関するシリーズ記事の第1部であり、主に状態成長について説明します。第2部は歴史的成長について、第3部は状態アクセスについて、第4部はガス制限についてです。

状態成長とは何ですか？

「状態成長」という用語は、一般的にイーサリアムのスケーリングボトルネックを概括するために使用されます。つまり、データのサイズがイーサリアムノードのハードウェアの容量を超えることです。しかし、状態成長はこの単一の方法で考えるべきではありません。イーサリアムデータにはさまざまなタイプがあり、それぞれがノードの基盤となるハードウェアコンポーネントと独自の関係を持っています。したがって、各異なるスケーリングボトルネックを説明するために正確な用語を使用することが重要です。

状態は、新しいイーサリアムブロックを構築し、検証するために必要なデータのセットです。状態は、コントラクトのバイトコード、コントラクトストレージ、アカウントの残高、およびアカウントのランダムな配列で構成されています。歴史は、ノードが創世ブロックから最新のブロックに同期するために必要なデータセットです。歴史はブロックとトランザクションで構成されています。状態と歴史は重複しないデータセットです。これらの定義から見ると、少なくとも3つの異なる現象がノードのハードウェアに大きな負担をかけています：

• 状態成長：新しいアカウント、新しいコントラクトのバイトコード、新しいコントラクトストレージの蓄積。
• 歴史成長：新しいブロックと新しいトランザクションの蓄積。
• 状態アクセス：ブロックを構築し、検証するための一連の読み書き操作。

各ボトルネックは、ノードのハードウェア制限と独自の関係を持っています。最も関連性の高い4つのハードウェア制限は次のとおりです：

• ネットワークIOは、ノードがピアノードと安定した合意に達するために維持しなければならないアップロードおよびダウンロード速度の量です。
• ストレージサイズは、ノードがブロックを構築、検証、および配布するために永久ストレージに保存しなければならないデータの量です。
• メモリサイズは、ノードがブロックチェーンの末端と同期を保つためにメモリにキャッシュしなければならないデータの量です。
• ストレージIOは、ノードがブロックチェーンの末端と同期を保つために毎秒実行しなければならない読み書き操作の量です。

これらのボトルネックとハードウェア制限の関係は図1に示されています。

図1：イーサリアムのスケーリングボトルネック

図の上部から始めると、イーサリアムがトランザクションを実行するたびに、そのトランザクションで使用されるすべてのリソースはガスで価格付けされます。したがって、イーサリアムのガス制限は単一の次元の量であり、すべての形式のオンチェーン活動に対してレート制限を行います。ガス制限の下流は、ブロックサイズと各ブロックの操作です。各ブロックのバイト数が多いほど、歴史の成長が速くなります。各ブロックのIO操作が多いほど、状態アクセス率が高くなり、（通常）状態成長率も高くなります。

したがって、スケーリングボトルネックはノードのハードウェア制約に関連しています：

• 大量の状態成長をサポートするために、ノードは十分なストレージとメモリスペースを持っている必要があります。状態が大きくなりすぎると、ストレージに収容できなくなるか、状態の頻繁にアクセスされる部分がメモリに含まれなくなり、パフォーマンスが低下します。
• 大量の歴史成長をサポートするために、ノードは大量のブロックデータを共有するための十分なネットワーク帯域幅と、そのデータを保存するための十分なストレージ容量を持っている必要があります。
• 大量の状態アクセスをサポートするために、ノードはホット状態をキャッシュするための大量のメモリと、十分な読み書き操作をサポートするための大量のストレージIOを持っている必要があります。

特に状態成長に関して、主な課題は、状態の規模の成長速度が消費者ハードウェアの継続的な改善を超えないようにすることです。ノードのメモリとストレージは限られたリソースであるため、状態が成長し続けるか、ハードウェアが定期的にアップグレードされない限り、最終的にはボトルネックに達します。幸いなことに、メモリとストレージハードウェアは何年にもわたって改善されてきました。それでも、これらの改善に対する正確な予測は依然として不確実であり、急速な成長が無期限に続くと考えるべきではありません。

今後導入されるEIP-4844によって導入されるデータブロブは、これらのスケーリング関係にいくつかの変化をもたらすでしょう。EIP-4844以降、ディスク上に蓄積される歴史ははるかに少なくなると予想されており、大量のBlobデータを転送する際のネットワークIOは大幅に増加する可能性があります。

本稿では、主に状態のサイズと状態成長率に焦点を当て、メモリサイズや状態アクセスパターンについては触れません。今後の作業で他のテーマを探求します。

イーサリアム状態の構成

状態成長を理解するための次のステップは、状態の総規模と各状態の寄与の大きさを調べることです。現在、イーサリアムの状態データ量は約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%の状態は休眠状態にあります。イーサリアム状態の中で最も大きなコントラクトのいくつかはもはやアクティブではありません。これらのプロトコルは、現在よりもはるかに安価なブロックスペースと状態スペースでリリースされており、ゲーム、ギャンブル、詐欺カテゴリのほとんどのプロトコルや、もはやアクティブでないDEX（IDEX、Etherdelta、Oasisなど）を含んでいます。これらのプロトコルは、イーサリアム状態の少なくとも7.4%を構成しています。休眠状態の実際のレベルはさらに高く、ERC-20、ERC-721、およびその他のカテゴリのロングテールプロジェクトも含まれます。
• L2クロスチェーンブリッジはイーサリアム状態の2%未満を占めています。圧縮、ZK証明、改善されたコーディングなどの技術を利用することで、L2トランザクションはメインネットよりも状態をより効率的に利用します。L2はメインネット状態の2%しか占めていませんが、L2の総トランザクション数はメインネットの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以降の世界にいるかのように考えます。将来の稼働時間は次のように計算できます：（残りのストレージ容量）/（状態成長率）、表に示されています。したがって、ノードのストレージハードウェアは、現在の状態成長速度を10年以上サポートでき、2TBのスペースを使い果たすことはありません。現在の状態成長レベルに従えば、4TBは近半世紀の運用をサポートするのに十分です。
• メモリ：Ethereum-on-armユーザーは、イーサリアムノードを実行するための最小限の実行可能メモリは約16GBであると報告しています。メモリの需要が状態サイズに比例して増加すると仮定すると、年間30GBから72GBの状態成長は、年間2GBから4.7GBの追加メモリを必要とします。したがって、現在のガス率に従えば、32GBのRAMは3年から8年の使用に十分であり、64GBのRAMは10年から23年の使用に十分です。

これは多くの仮定条件を伴う簡略化されたモデルです。このモデルの可能な拡張条件には、1) 歴史的成長、2) メモリ需要の非線形拡張、3) ハードウェアコストの低下、4) ガス制限の増加、5) オペコードガスの再価格設定、6) 将来のイーサリアムアーキテクチャの改善が含まれます。これらの要因はそれぞれ非線形に相互作用し、時間とともに進化する可能性があります。今後の作業でこれらのモデルの拡張を探求します。

長期的な持続可能性は良いことを強調する必要があります。現代のハードウェアが数年間の運用をサポートできるとしても、運用時間を短縮することを軽視すべきではありません。状態成長を加速する計画には、ハードウェアやソフトウェア環境の予測不可能な変化に対処するための重要なバッファが含まれるべきです。

状態成長問題をどのように解決するか？

状態成長問題を解決するために、多くの異なる提案がなされています。イーサリアムアーキテクチャの3つの改善が非常に目立ちます：ロールアップ、ヴェルクル試行、状態の期限切れ。要するに、これらは短期、中期、長期の状態成長問題を解決するための包括的なロードマップを構成しています。

短期：ロールアップは状態成長問題を解決することはできませんが、ネットワークの負担を軽減します。図2と図3に示されているように、ロールアップはメインネットよりも状態をより効率的に使用できます。活動をL2に移行するには、ユーザーの退出をサポートするためにメインネット上に一定量の状態を保存する必要があります。ただし、L2トランザクションの状態フットプリントは、メインネット上のトランザクションのフットプリントよりもはるかに少ないです。したがって、ロールアップはエコシステム内の総活動をより持続可能に増加させることができます。今後のEIP-4844により、ロールアップの採用は増加すると予想されており、Blobはロールアップをより安価にします。

中期：ヴェルクル試行は、バリデータノードの状態成長問題を解決しようとしますが、新しいトランザクションを構築する必要があるノードの問題は解決しません。ヴェルクル試行は、イーサリアム状態の新しいデータ構造です。これにより、より効率的なライトクライアントと「無状態」ノードがサポートされます。これらのノードは、既存の状態値を知らなくても新しいブロックを検証できるようになります。これにより、バリデータノードの状態成長問題が解消されます。新しいトランザクションの構築には状態の保存とアクセスが依然として必要ですが、これは今日の状況よりも持続可能です。トランザクションの構築は、多くのマシンに簡単に分散できるタスクだからです。範囲に関して、ヴェルクル試行は、実施に数年を要する可能性のある重要なエンジニアリングを表しています。

長期：状態の期限切れは、すべてのノードの状態成長問題を解決しますが、追加のインフラストラクチャが必要です。状態の期限切れにより、ノードは状態の非アクティブ部分を破棄できます（図2参照）。「状態休眠」という用語の方が適切かもしれません。なぜなら、ほとんどの既存の提案は「期限切れ」状態を証明によって復元することを許可するからです。時間の経過とともに期限切れの状態が失われることへの懸念は、歴史（ブロックとトランザクションデータ）が利用可能であれば、状態を再構築できるため、解消されます。したがって、EIP-4444の歴史保存問題に対して開発される解決策は、状態保存問題も解決します。しかし、ヴェルクル試行がその目標を成功裏に実現すれば、状態の期限切れは不要になるかもしれません。

状態成長問題の解決策は他にもあり、状態のレンタルやシャーディングなども含まれますが、歴史的に見て、これらはユーザー体験や健全性に影響を与える可能性があります。より遠い将来に最終的な解決策を実現するためには、これらの解決策を他の解決策と組み合わせる必要があるかもしれません。

まとめ

状態成長はイーサリアムのスケーリングにおける重要な課題ですが、私たちはこれは解決可能な問題であると信じています。私たちのデータの解釈によれば、イーサリアムは現在の状態成長レベルを何年も維持でき、アーキテクチャのアップグレードに対して快適なバッファを提供します。

私たちは、経験的アプローチがイーサリアムのガス制限を設計し、イーサリアムを最終的なスケーリング解決策へと導くために重要であると信じています。本稿はこの目標を達成するための一歩に過ぎません。状態を超えた他のタイプのデータも存在し、それぞれがイーサリアムノードとイーサリアムのガス制限に負担をかけています。今後の作業でこれらの他のボトルネックを探求したいと考えています。