パラダイム: イーサリアム国家の成長に向けた課題と解決策
原作者: ストーム・スリヴコフ、ゲオルギオス・コンスタントプロス
オリジナル編集：ルフィ、フォーサイトニュース
イーサリアム状態の成長とガス制限との関係は広く誤解されています。状態の成長がイーサリアムのスケーリングの主なボトルネックであると広く考えられています。しかし、国家の成長に関する議論は、用語の不正確さや詳細な定量的証拠の欠如によって妨げられることがよくあります。
データ主導のアプローチを採用すると、状態の拡大の問題がより明確になります。この論文では、高解像度のデータセットを活用して、状態の成長のサイズと形状を理解します。その過程で、私たちは驚くべき結論に達しました。それは、現代の消費者向けハードウェアは、少なくとも 10 年間は現在の成長状態を維持できるということです。さらに、ソフトウェアとハードウェアの継続的な改善により、この滑走路は無期限に延長される可能性があります。
私たちは、イーサリアムには明確なロードマップがあると信じています: 1) スケーリングのボトルネックとしての国家の成長を完全に排除する; 2) 世界規模の分散型金融システムをサポートするレベルまでガス制限を引き上げる。この記事シリーズの目標は、この拡張のロードマップを理解し、開発するための科学的アプローチを開発することです。
この記事はイーサリアムの拡張に関する一連の記事の第 1 部であり、主に状態の成長について紹介し、第 2 部は歴史的成長について、第 3 部は州へのアクセスについて、第 4 部はガス制限についてです。
国家の成長とは何ですか?
「状態の増加」という用語は、データ サイズがイーサリアム ノード ハードウェアの容量を超えるイーサリアム スケーリングのボトルネックを要約するためによく使用されます。ただし、国家の成長をこのような特異な方法で考えるべきではありません。 Ethereum データには多くの種類があり、それぞれがノードの基礎となるハードウェア コンポーネントと独自の関係を持っています。したがって、正確な用語を使用して、さまざまなスケーリングのボトルネックをそれぞれ説明することが重要です。
状態は、新しいイーサリアム ブロックを構築および検証するために必要なデータのセットです。状態は、コントラクト バイトコード、コントラクト ストレージ、アカウント残高、アカウント乱数で構成されます。履歴は、ノードがジェネシス ブロックから最新のブロックまで同期する必要があるデータのセットです。履歴はブロックとトランザクションで構成されます。状態と履歴は重複しないデータ セットです。これらの定義から、ノードのハードウェアに多大な負荷をかける少なくとも 3 つの異なる現象が存在します。
状態の増加: 新しいアカウント、新しいコントラクト バイトコード、および新しいコントラクト ストレージの蓄積。
歴史的な成長: 新しいブロックと新しいトランザクションの蓄積。
状態アクセス: ブロックの構築と検証に使用される一連の読み取りおよび書き込み操作。
各ボトルネックは、ノードのハードウェア制限と固有の関係があります。最も関連性の高いハードウェア制限は次の 4 つです。
ネットワーク IO は、ノードがピアと安定した合意に達するために維持する必要があるアップロードおよびダウンロードの速度の量です。
ストレージ サイズは、ブロックを構築、検証、配布するためにノードが永続ストレージに保持する必要があるデータの量です。
メモリ サイズは、ブロックチェーンの末端との同期を保つためにノードがメモリにキャッシュする必要があるデータの量です。
ストレージ IO は、ブロックチェーンの末端との同期を保つためにノードが実行する必要がある 1 秒あたりの読み取りおよび書き込み操作の量です。
これらのボトルネックとハードウェア制限の関係を図 1 に示します。
図 1: イーサリアム拡張のボトルネック
図の一番上から見てみると、イーサリアムがトランザクションを実行するたびに、そのトランザクションで使用されるすべてのリソースの価格がGasで計算されます。したがって、イーサリアムのガス制限は、あらゆる形式のオンチェーンアクティビティをレート制限する一次元の量です。ガス制限の下流には、ブロック サイズとブロックごとの操作があります。ブロックあたりのバイト数が多いほど、履歴の増大は速くなります。ブロックあたりの IO 操作が多いほど、状態アクセス速度が向上し、(通常は) 状態の増加速度も大きくなります。
したがって、スケーリングのボトルネックは、次のようにノードのハードウェア制約に関連しています。
大量の状態の増加をサポートするには、ノードに十分なストレージとメモリ領域が必要です。状態が大きくなりすぎると、ストレージに収まらないか、状態の頻繁にアクセスされる部分がメモリに収まらなくなり、パフォーマンスが低下します。
歴史的な大規模な成長をサポートするには、ノードには大量のブロック データを共有するのに十分なネットワーク帯域幅と、そのデータを保存するのに十分なストレージ容量が必要です。
多数の状態アクセスをサポートするには、ノードにはホット ステートをキャッシュするための大量のメモリと、十分な読み取りおよび書き込み操作をサポートするための大量のストレージ IO が必要です。
特に状態の成長に関しては、主な課題は、消費者向けハードウェアの継続的な改善よりも早く状態のサイズが増大しないようにすることです。ノードのメモリとストレージは有限のリソースであるため、状態の増大が止まるか、ハードウェアが定期的にアップグレードされない限り、最終的にボトルネックに達します。幸いなことに、メモリとストレージのハードウェアは長年にわたり改良され続けています。それでも、これらの改善の正確な予測は不確実であり、その急速な成長が無期限に続くと想定すべきではありません。
今後の EIP-4844 によって導入されるデータ BLOB は、これらの拡張された関係にいくつかの変更をもたらすことに注意してください。 EIP-4844 以降は、ディスク上に蓄積される履歴が大幅に減少すると予想され、大量の BLOB データを転送するときにネットワーク IO が大幅に増加する可能性があります。
この記事では、メモリ サイズや状態のアクセス パターンではなく、主に状態のサイズと状態の増加率に焦点を当てます。今後の作業で他のトピックも調査していきます。
イーサリアム状態の構成
州の成長を理解するための次のステップは、州の合計サイズと各州の貢献のサイズを調べることです。現在、イーサリアムの状態データの量は約 245.5 GB です。この数は 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 など、現在はアクティブではない多くの DEX が含まれています。 、オアシス。これらのプロトコルを合わせると、イーサリアムの状態の少なくとも 7.4% を構成します。 ERC-20、ERC-721、その他のカテゴリのロングテール プロジェクトも含まれるため、実際の休眠レベルはさらに高くなります。
L2 クロスチェーン ブリッジがイーサリアム状態の 2% 未満を占めています。圧縮、ZK 証明、改善されたエンコーディングなどのテクノロジーを活用することで、L2 トランザクションはメインネットよりも効率的に状態を利用します。 L2 はメインネットの状態の 2% しか占めていませんが、L2 の 1 秒あたりの合計トランザクション数はメインネットの 5 倍です。
イーサリアムの状態はどれくらいの速さで成長していますか?
州の成長の最も重要な側面は、時間の経過に伴う州の成長率です。この比率は、州の問題の深刻さとその変化する傾向を明らかにします。
図 3 は、2015 年のイーサリアム開始以来の状態の成長率を示しています。これらの増加率は、各契約カテゴリ内の契約バイトコードと契約ストレージを合計することによって計算されます。
図 3: 時間の経過に伴うイーサリアム状態の増加
図 3 から得られる最も重要な情報の一部を次に示します。
現在、ステータスは月あたり約 2.62 GB で増加しており、ピーク時の月あたり 5.99 GB から減少しています。これらの数字は、5 年以内の州の合計サイズが 396 GB ～ 606 GB になると予測します。現在の成長率を年間 12.8% と説明する人もいるかもしれませんが、州が成長を続ける一方で絶対的な成長率は低下しているため、単純な指数関数的成長は適切なモデルではない可能性があります。
最近の州の成長の低下は主に NFT 活動の減少によるものです。さまざまなタイプのネットワーク活動の間にはある程度の相関関係があると予想されるかもしれませんが、個々のステータスの寄与者の間には驚くべき独立性があります。たとえば、州全体の成長率は過去数年間で減少していますが、ERC-20 州の成長率は実際には 2020 年以降毎年増加しています。
州の成長率は２０２１年以来の低水準に達した。この減少は非常に驚くべきことですが、ステータスが主に新しいトークンの残高に比例することを考慮すると、それは理にかなっています。状態の成長率が低下し続ける場合、イーサリアムにはより高いガス制限をサポートする能力があると考える人もいるかもしれません。これは真実かもしれませんが、次のことを覚えておくことが重要です。1) 現在のガス価格モデルの下では、新たな成長率の急上昇を妨げるものは何もなく、2) ガス制限の下流におけるボトルネックはステータスだけではありません。
ステータス成長の許容値はどれくらいですか?
現在、イーサリアムの状態の 1) サイズ、2) 構成、3) 成長率がわかっています。許容可能な状態成長値の範囲はどのように決定すればよいでしょうか?この問題は、予測できない市場の力と、イーサリアムがどのようなトレードオフを行うべきかについての哲学的な選択の両方に依存するため、複雑です。
将来のハードウェアに改善がないと仮定して、平均的な消費者向けハードウェアで現状の成長レベルがどのくらいの期間維持できるかという、最も単純なモデルから始めましょう。図 3 に示すように、近年の州の年間成長率は 31 GB/年から 72 GB/年の間です。現在、一般的な民生用ハードウェアの最大ストレージ容量は約 4 TB、メモリ容量は約 64 GB です。これから、単純なストレージとメモリの要件予測モデルを作成できます。
ストレージ: ノードは現在、合計で約 1 TB の状態データを保存する必要があります。実際には、これは多くのノードが少なくとも 2 TB のサイズのディスクを使用していることを意味します。話を簡単にするために、将来の歴史的な成長を無視し、あたかも EIP-4444 後の世界にいるかのように行動しましょう。将来の実行時間は、(残りのストレージ容量)/(状態の増加率) として計算できます。たとえば、シート示されています。したがって、ノード ストレージ ハードウェアは、2 TB のスペースを使い果たすことなく、現在の状態の増加率を 10 年以上サポートできます。現在の成長レベルでは、4 TB で半世紀近くの運用をサポートできます。
メモリ: Ethereum-on-arm ユーザーは、Ethereum ノードを実行するために実行可能な最小メモリは約 16 GB であると報告しています。メモリ要件が状態のサイズに比例して増加すると仮定すると、年間 30 GB ～ 72 GB の状態の増加は、年間 2 GB ～ 4.7 GB の追加メモリ要件に相当します。したがって、現在のガス料金では、32 GB RAM で 3 ～ 8 年間十分に使用できます。 64 GB の RAM は 10 ～ 23 年間使用するには十分です。
これは多くの仮定を含む単純化されたモデルです。このモデルの可能な拡張条件には、1) 歴史的な成長、2) メモリ要件の非線形拡張、3) ハードウェア コストの削減、4) ガス制限の増加、5) オペコード ガスの価格変更、6) 将来のイーサリアム アーキテクチャの改善が含まれます。これらの各要因は非線形に相互作用し、時間の経過とともに進化する可能性があります。今後の作業では、これらのモデル拡張を検討していきます。
長期的な持続可能性は良いことであることを強調することが重要です。最新のハードウェアが長年の動作をサポートできるとしても、実行時間の短縮を軽視すべきではありません。状態の成長を加速する計画には、ハードウェアまたはソフトウェア環境の予測不可能な変化に対応するための大幅なバッファーを含める必要があります。
国家の成長問題をどう解決するか?
状態の成長の問題を解決するために、さまざまな解決策が提案されています。イーサリアム アーキテクチャの 3 つの改善点は、ロールアップ、Verkle 試行、状態有効期限の 3 つが際立っています。これらを総合すると、短期、中期、長期の州の成長問題に対処するための包括的なロードマップを構成します。
短期的: ロールアップは状態の増大の問題を解決しませんが、ネットワークの負担は軽減します。図 2 と 3 に示すように、ロールアップはメインネットよりも効率的に状態を使用できます。アクティビティを L2 に移動するには、ユーザー出口をサポートするために、ある程度の量の状態をメインネットに保存する必要があります。ただし、L2 トランザクションのステート フットプリントは、メインネット トランザクションのステート フットプリントよりもはるかに小さいです。したがって、ロールアップはエコシステム内の総活動をより持続的に増加させることができます。 EIP-4844 の今後のリリースにより、ロールアップの採用はさらに拡大すると予想されており、BLOB によってロールアップはさらに手頃な価格になります。
中期: Verkle はバリデーター ノードの状態の増大の問題を解決しようとしていますが、新しいトランザクションを構築する必要があるノードの問題は解決していません。 Verkle の試みは、イーサリアム状態の新しいデータ構造です。これらは、より効率的な軽量クライアントと「ステートレス」ノードをサポートします。これらのノードは、既存の状態値を知らなくても新しいブロックを検証できます。これにより、バリデーターノードの状態の増大の問題が解消されます。新しいトランザクションの構築には依然として状態の保存とアクセスが必要ですが、トランザクションの構築は多くのマシンに簡単に分散できるタスクであるため、これは現在よりも持続可能です。範囲の観点から見ると、Verkle の試みは、実装までに何年もかかる可能性がある大規模な取り組みです。
長期: 状態の有効期限により、すべてのノードの状態増加の問題は解決されますが、追加のインフラストラクチャが必要になります。図 2 に示すように、状態の有効期限が切れると、ノードは状態の非アクティブな部分を破棄できるようになります。ほとんどの既存の提案では証明を通じて「期限切れ」状態の復元が許可されているため、「状態休止状態」という用語の方が適切な名前である可能性があることに注意してください。期限切れの状態が時間の経過とともに失われるという懸念については、履歴 (ブロックおよびトランザクション データ) が利用可能な限り、状態を再構築できます。したがって、EIP-4444 の履歴保存問題に対して開発されたソリューションは、状態保存問題も解決することになります。しかし、Verkle がその目標をうまく達成しようとしているのであれば、状態の有効期限は必要ないかもしれません。
州の成長の問題には他にも多くの解決策があり、州の賃貸料やシャーディングなどもありますが、歴史的にはこれらはユーザー エクスペリエンスや健全性に影響を与えてきた可能性があります。より遠い将来に最終的な解決策を達成するには、これらの解決策を他の解決策と組み合わせる必要があるかもしれません。
要約する
状態の成長はイーサリアムを拡張する上での重要な課題ですが、私たちはそれが解決可能な問題であると信じています。データの私たちの解釈は、イーサリアムが現在の状態の成長レベルを長年維持し、アーキテクチャのアップグレードに快適なクッションを提供できることを示唆しています。
私たちは、イーサリアムのガス制限を設計し、イーサリアムを究極のスケーリング ソリューションに導くには、経験に基づくアプローチが重要であると信じています。この記事はその目標に向けた一歩にすぎません。状態を超越する他のタイプのデータがあり、それぞれがイーサリアムのノードとイーサリアムのガス制限に負担をかけます。今後の作業では、これらの他のボトルネックも調査していきたいと考えています。
