歴史的成長とは何ですか？

イーサリアムの歴史には、生涯にわたって実行されたすべてのブロックと取引が含まれます。このデータは、ジェネシスブロックから現在の状態までチェーンを同期させるために必要です。歴史的成長とは、時間の経過とともに新しいブロックと取引が蓄積されることを指します。

図1は、歴史的成長、さまざまなプロトコルメトリクス、およびイーサリアムノードのハードウェア制限との関係を示しています。状態の成長とは異なり、歴史的成長は異なるハードウェア制限によって制約されています。この成長は、ネットワークI/Oに圧力をかけます。なぜなら、新しいブロックとトランザクションはネットワークを介して送信されなければならないからです。また、各イーサリアムノードが歴史記録の完全なコピーを保存しているため、ノードのストレージスペースも圧迫されます。歴史的成長がこれらのハードウェア制限を上回ると、ノードはもはや同僚との安定した合意に達することができなくなります。状態の成長とその他のスケーリングのボトルネックの概要については、参照してください。部分 1このシリーズの.

図1：イーサリアム拡張ボトルネック

最近まで、各ノードのネットワークスループットのほとんどは、過去の記録（例えば、新しいブロックや取引など）の送信に使用されていました。これは、ブロブの導入によって変わりました。Dencunハードフォーク。 ブロブは現在、ノードネットワークアクティビティの重要な部分を構成しています。 ただし、ブロブは歴史的記録の一部とは見なされていません。なぜなら、1）ノードはブロブを2週間だけ保存してから破棄し、2）ジェネシスからのチェーンリプレイには必要ないためです。 （1）のため、ブロブは各Ethereumノードに対するストレージ負担を大幅に増やしません。 この記事では後ほど、ブロブについて詳しく説明します。

この記事では、歴史データの成長と状態成長との関係に焦点を当てます。状態と歴史的成長はいくつかのハードウェア制約を共有しているため、相互に関連している問題です。一つを対処することで他を緩和するのに役立ちます。

歴史はどれくらい速く発展しますか？

図2は、イーサリアムの創世以来の歴史的成長率を示しています。各垂直バーは1か月分の成長を表しています。Y軸はその月に履歴に追加されたGB数を表しています。トランザクションは「宛先アドレス」によって分類され、そのサイズはそれらのRLPバイト表現。簡単に識別できない契約は「不明」として分類されます。「その他」のカテゴリには、インフラストラクチャやゲームなど、多くの小さなカテゴリが含まれています。

このチャートからいくつかの重要な結論を導くことができます。

1. 歴史的成長率は州の成長よりも約6〜8倍速い：歴史的成長は最近36.0 GiB/月にピークを迎え、現在は19.3 GiB/月です。州の成長は最大で約6.0 GiB/月に達し、現在は2.5 GiB/月です。歴史的成長と州の成長の両方について、速度と累積サイズの比較がこの記事の後で見つけることができます。
2. Dencunの前に歴史的成長率が急速に加速していました：州の成長は年々ほぼ直線的でしたPart 1を参照してください)、歴史的な成長は超線形でした。線形成長は全体のサイズを二次的に増加させますが、超線形成長は二次よりも速い増加をもたらします。この加速はデンカンの後に突然停止し、イーサリアムの歴史的成長における初めての大きな減速を示しました。
3. 最近の歴史的成長は主にロールアップから来ています：各L2は、取引のコピーをメインネットに戻し、過去1年間の歴史データのかなりの部分を生成しているため、ロールアップは過去1年間で最も歴史的成長の貢献者となっています。ただし、DencunはL2が取引データを投稿するために過去の記録の代わりにブロブを使用することを許可しているため、ロールアップはもはやイーサリアムのほとんどの歴史的記録を生成しません。この記事では後でロールアップを詳しく調査します。

イーサリアムの歴史に最も貢献したものは何ですか？

各契約カテゴリーが生成した歴史データの量は、時間の経過とともにイーサリアムの使用パターンがどのように進化してきたかを示しています。図3は、さまざまな契約カテゴリーの寄与度を示しています。これは、図2と同じデータを100%に正規化したものです。

データは、イーサリアムの使用パターンの4つの異なる時代を明らかにしています:

初期時代（パープル）：イーサリアムの初期の数年間、オンチェーンの活動は最小限でした。これら初期の契約のほとんどは現在特定するのが難しく、「unknown」としてラベル付けされています。

ERC-20エラ（グリーン）：ERC-20標準2015年末に最終決定されましたが、2017年と2018年まで大きな注目を集めませんでした。2019年には、ERC-20契約が歴史的成長において最大のカテゴリとなりました。

DEX/DeFi時代（ブラウン）：DEXおよびDeFi契約は2016年にオンチェーン上に現れ、2017年に注目を集め始めました。しかし、彼らは最大の歴史的カテゴリにはなりませんでした2020年のDeFiサマーまでDeFiおよびDEX契約は、2021年および2022年のさまざまな時点で、歴史的な成長の50%以上を記録しました。

ロールアップ時代（グレー）：2023年初頭、L2ロールアップが一貫して実行を開始しましたメインネットよりも取引が多い。これは、彼らの契約が大量の過去データを生成しており、Dencunの直前の数ヶ月でイーサリアムの過去成長の約三分の二を占めていることと一致しています。

各時代は、イーサリアム上でのますます複雑な使用パターンを表しています。時間の経過とともに、この複雑さは、単純な指標である秒間取引数で捉えられないイーサリアムのスケーリングの一形態と見なすことができます。

最新のデータ（2024年4月）によると、ロールアップはもはや過去の記録の大部分を生成していません。将来の歴史的成長がDEXやDeFiによって支配されるか、新しい利用パターンが現れるかは不明です。

ブロブについてはどうですか？

Dencunハードフォークでのブロブの導入は、歴史的成長のダイナミクスを大幅に変え、ロールアップが安価なブロブを使用してデータを投稿できるようにしました。図4は、Dencunアップグレードの日付周辺の歴史的成長率を拡大したものです。このチャートは図2に似ていますが、各垂直バーは1か月ではなく1日を表しています。

このチャートからいくつかの重要な結論が導かれます。

ロールアップからの歴史的成長は、デンカン以降約3分の2減少しています：ほとんどのロールアップは、コールデータからブロブの使用に移行し、生成される歴史データの量を大幅に減らしました。ただし、2024年4月現在、一部のロールアップまだコールデータからブロブに切り替えていません。

Dencun 以降、総合的な歴史的成長は、ロールアップから大幅に減少しました。他の契約カテゴリからの歴史的成長はわずかに増加しました。Dencun 以降も、歴史的成長は状態成長の約8倍になります（詳細は次のセクションで説明します）。

歴史的成長の減少にもかかわらず、ブロブはイーサリアムへの新しい追加です。現在、ブロブの存在下で歴史的成長がどこで安定するかはまだ明確ではありません。

歴史的な成長はどれくらい受け入れ可能ですか？

ガスリミットを増やすと、過去の成長率が上昇します。したがって、ガスリミットを引き上げる提案は（Pump the Gasのようなもの)各ノードにおける歴史的成長とハードウェアのボトルネックの関係を考慮する必要があります。

適切な歴史的成長率を決定するには、まず現代のノードネットワークとストレージノードハードウェアが現在の状態をどれだけ維持できるかを調査することが役立ちます。 ネットワークハードウェアは、歴史的成長率がガスリミットの増加前のレベルに戻る可能性が低いため、永続的に現状を維持できるかもしれません。 ただし、歴史的記録のストレージ負担は時間とともに増加します。 現在のストレージポリシーによると、各ノードのストレージドライブは最終的に履歴でいっぱいになるでしょう。

図5は、時間の経過とともにEthereumノードの保存負担を示しており、また、この負担が今後3年間でどのように増大するかも予測しています。予測は2024年4月の成長率を使用して行われています。この率は将来、使用パターンやガス制限の変更により増減する可能性があります。

このチャートからはいくつかの重要な結論が導かれます。

履歴に使用されるストレージスペースは、状態の約3倍です：この格差は、履歴の成長率が状態の約8倍であるため、時間の経過とともに増加します。

1.8 TiB前後の臨界点：この時点で多くのノードがストレージドライブをアップグレードすることを余儀なくされるでしょう。一般的な2TBドライブは、利用可能な容量が1.8 TiBしか提供していません。TB（テラバイト）とTiB（テビバイト、= 1024^4バイト）は異なる単位であることに注意してください。多くのノードオペレータにとって、「実際の」臨界点は、マージ後にバリデータが実行クライアントと共にコンセンサスクライアントを実行する必要があるため、さらに低くなる可能性があります。

2〜3年でしきい値に達する： ガスリミットの増加はこのタイムラインを加速させます。このしきい値に達することは、ノードオペレーターに重要なメンテナンス負担を強い、追加のハードウェアの購入が必要になります。たとえば、$300 NVME ドライブ。

歴史データの別個の保存: 状態データとは異なり、歴史データは追記専用であり、アクセス頻度が低いため、理論的には状態データとは別の、より安価な保存媒体に保存することができます。一部のクライアントは、Geth, 既にこの分離をサポートしています。

ネットワークIOはハードウェアの制約の1つです：ストレージ容量に加えて、ネットワークIOは歴史的な成長にとってもう1つの主要なハードウェア制約です。ストレージ容量とは異なり、ネットワークIOの制限はノードに直ちに問題を引き起こすことはありませんが、将来のガスリミットの増加にとって重要となります。

典型的なEthereumノードのネットワーク容量がサポートできる歴史的成長の量を理解するには、歴史的成長と再編成率、スロットミス、最終性の欠如、欠落アテステーション、同期委員会ミス、およびブロック提案の遅延など、さまざまなネットワーク健康メトリクスとの関係を説明する必要があります。これらのメトリクスの分析は、この記事の範囲外ですが、以前の合意レイヤーの健康に関する調査で見つけることができます [1] [2] [3]4]. また、イーサリアム財団の@ethpandaops/xatu-overview">Xatuプロジェクトは、このような分析を容易にするための公開データセットの構築に取り組んできました。

歴史的成長を解決する方法は？

歴史的成長は、状態の成長よりも解決しやすい問題です。提案されたEIP-4444ほぼ完全にこの問題を解決します。このEIPは、各ノードの要件をイーサリアムの全履歴を保持することから、履歴を1年分だけ保持することに変更します。EIP-4444が実装されると、長期的にガスリミットが大幅に増加しても、データストレージはもはやイーサリアムのスケーリングのボトルネックではありません。EIP-4444はネットワークの長期的な持続可能性にとって不可欠であり、それ以外の場合、歴史データは十分に速く成長して、ネットワークノードの定期的なハードウェアのアップグレードが必要になります。

図6は、EIP-4444が次の3年間に各ノードのストレージ負担にどのように影響するかを示しています。これは、図4と同じで、EIP-4444の実装後のストレージ負担を表す細かい線が追加されています。

このチャートからいくつかの重要な結論を導くことができます。

EIP-4444は現在のストレージ負担を半減させます：ストレージ負担は1.2 TiBから633 GiBに減少します。

EIP-4444は歴史的なストレージ負担を安定化させます: 歴史的成長率が一定であると仮定すると、歴史データは生成される速度と同じ速度で破棄されます。

EIP-4444の後、今日のレベルに達するまでには多くの年月がかかるでしょう。これは、歴史的な成長よりも遅いステートの成長が、ストレージ負担を増やす唯一の要因となるためです。

EIP-4444は、1年分の履歴データを引き続き保持するため、依然として一定のストレージ負担が発生します。ただし、この負担はイーサリアムがグローバルにスケールする場合でも管理可能です。履歴データの取り扱い方法が信頼性のあるものとして証明されれば、EIP-4444の1年間の保持期間は数か月、数週間、またはそれ以下に短縮される可能性があります。

イーサリアムの歴史を保存する方法は？

EIP-4444 raises the question: if Ethereum nodes themselves do not preserve the history, how should it be preserved? History is crucial for Ethereum’s verification, accounting, and analysis, so it must be preserved. Fortunately, preserving history is straightforward, requiring only 1/n honest data providers, compared to the state consensus problem, which needs 1/3 to 2/3 honest participants. Node operators can verify the authenticity of any historical dataset by: 1) replaying all transactions from Genesis; and 2) checking if these transactions reproduce the same state root as the current chain tip.

歴史を保存するための複数の方法があり、それぞれが並行して展開されるべきです。保存の可能性を最大限に引き出すために。

トレント / P2P: トレント最もシンプルで堅牢な方法です。イーサリアムノードは、定期的に履歴の一部をパッケージ化し、それらを公開トレントファイルとして共有することができます。たとえば、ノードは、100,000ブロックごとに新しい履歴トレントファイルを作成することがあります。Erigonのような一部のノードクライアントは、既にこのプロセスを非標準化の方法で実行しています。このプロセスを標準化するためには、すべてのノードクライアントが同じデータ形式、パラメータ、およびP2Pネットワークを使用する必要があります。ノードは、自身のストレージと帯域幅の容量に基づいて、このネットワークへの参加を選択することができます。トレントの利点は、大規模なデータツールエコシステムによってサポートされる成熟したオープンスタンダードの使用です。

ポータルネットワーク：ポータルネットワークPortal Networkは、イーサリアムデータをホストするために専門に設計された新しいネットワークです。このアプローチはトレントに似ていますが、データ検証を容易にするための追加機能が提供されています。Portal Networkの利点は、これらの追加の検証レイヤーが、軽量クライアントに対して効率的な検証とクエリユーティリティを提供し、共有データセットに対して容易な検証を行うことです。

クラウドホスティング：AWSなどのクラウドストレージサービスS3またはCloudflareR2歴史を保存するための安価で高性能なオプションを提供します。 ただし、この方法には、これらのクラウドサービスが常に仮想通貨データをホストすることを望んでいないか、できない場合があるため、より多くの法的および事業運営リスクが伴います。

残りの実装上の課題は技術的なものよりもむしろ社会的なものです。イーサリアムコミュニティは特定の実装の詳細について調整する必要があります。これにより、すべてのノードクライアントに直接統合できるようになります。特に、スナップショット同期ではなくジェネシスから完全に同期するには、イーサリアムノードではなく歴史的データプロバイダから履歴を取得する必要があります。これらの変更にはハードフォークは必要ありませんし、Pectraの次のハードフォーク前に実装することができます。

L2はこれらすべての方法を使用して、メインネットに公開するblobデータを保存することもできます。blobの保存は1）合計データ量が大きいためより困難であり、2）blobはメインネットの履歴を再生するために必要ではないため、より重要ではありません。ただし、blobの保存は、各L2が独自の履歴を再生するために必要です。したがって、blobの保存のある形式は、Ethereumエコシステム全体にとって重要です。さらに、L2が堅牢なblobストレージインフラを開発すると、L1の履歴データも簡単に保存できます。

EIP-4444の前後にさまざまなノード構成で保存されているデータセットを直接比較することは役立ちます。図7は、Ethereumノードタイプのストレージ負担を示しています。ステートデータにはアカウントとコントラクトが含まれ、履歴データにはブロックとトランザクションが含まれ、アーカイブデータはオプションのデータインデックスのセットです。表のバイト数は最近のrethスナップショットに基づいていますが、他のノードクライアント全体でも大体同じです。

図7: イーサリアムノードタイプのストレージ負担

言語において、

1. アーカイブノードは、状態データ、履歴データ、アーカイブデータを保存します。歴史的なチェーンの状態を簡単にクエリする必要がある場合に使用されます。
2. フルノードは、過去のデータと状態データのみを保存します。ほとんどのノードは今日、フルノードです。フルノードの保存負担はアーカイブノードの約半分です。
3. EIP-4444の後、フルノードは状態データと前年の履歴データのみを保存します。これにより、ストレージ負担が1.2 TiBから633 GiBに削減され、履歴データのストレージ使用量が安定します。
4. 状態を持たないノード、または「軽量ノード」としても知られるノードは、これらのデータセットを保存せず、チェーンの先端で即座に検証することができます。この種のノードは、一度に可能になりますVerkle triesまたは他の状態コミットメントスキームがイーサリアムに追加されます。

最終的に、現在の速度に適応するだけでなく、歴史的成長率を制限することを目指す追加のエコシステム提案があります。これらは、長期的にはネットワークIO制限を維持するのに役立ち、長期的にはストレージ制限を維持するのに役立ちます。EIP-4444はネットワークの長期的な持続可能性にとって不可欠ですが、これらの他のEIPは将来のイーサリアムの効率的なスケーリングを支援します。

EIP-7623: この提案は、コールデータの価格設定を変更して、過剰なコールデータを含む取引がより高価になるよう提案しています。これらの使用パターンをより高価にすることで、一部の人々がコールデータからブロブに切り替えることを促し、これにより歴史的な成長率が低下します。

EIP-4488この提案は、各ブロックに含めることができるコールデータの総量に制限を設け、歴史的成長のペースに厳しい制御を適用します。

これらのEIPは、EIP-4444よりも実装が簡単であり、EIP-4444が本番向けに準備されるまでの暫定的な手段として機能することができます。

結論

この記事の目標は、歴史的な成長がどのように機能し、この問題にどのように対処するかについて、データに基づいた理解を提供することです。この記事で提示される多くのデータは従来アクセスが困難でしたので、歴史的成長の問題に新しい見識を提供することを目指しています。

イーサリアムのスケーラビリティのボトルネックとしての歴史的成長は、十分な注意を受けていませんでした。現在の実践では、ガスリミットを増やさなくても、イーサリアムの履歴を保持することが多くのノードにハードウェアのアップグレードを数年以内に必要とするでしょう。幸いにも、これは解決すべき問題ではありません。EIP-4444で明確な解決策が示されています。将来のガスリミットの増加に備えるために、このEIPの実装を加速させるべきだと考えています。

イーサリアムのスケーラビリティ研究に興味がある場合は、お問い合わせくださいstorm@paradigm.xyzそしてgeorgios@paradigm.xyz.この問題についてのあなたの見解を聞かせていただき、潜在的な協力を探りたいと考えています。この記事で使用されているデータとコードは、見つかりましたGithub.

謝辞

大きな感謝トーマス・ティエリー、ベイコ チーム、Toni Wahrstaetter、オリバー・ノードベリそしてRoman Krasiuk彼らのレビューとフィードバックをお待ちしております。ありがとうございますアチャル・スリニバサン図1および図7に示された数字について

免責事項：

1. この記事は[から転載されましたマーズビット]. すべての著作権は元の著者に帰属します [ストーム・スリブコフ、ゲオルギオス・コンスタントプロス]. If there are objections to this reprint, please contact the Gate Learnチームがすぐに対処します。
2. 責任の免責事項: この記事で表現されている見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。