原作者:ストーム・スリフコフ、ゲオルギオス・コンスタントプロス

オリジナルコンピレーション:ルフィ、フォーサイトニュース

歴史の上昇成長は現在、イーサリアムの拡張における最大のボトルネックです。 驚いたことに、歴史的な上昇は州の上昇よりも大きな問題になっています。 数年以内に、履歴データはロング イーサリアム ノードストレージ容量を超えます。

ここで朗報です。

*歴史的な上昇は、州の上昇よりもはるかに簡単に解決できる問題です。

• このソリューションは、すでに活発に開発されています。 *歴史的な上昇に取り組むことは、州の上昇の問題を緩和するでしょう。

この投稿では、パート1のイーサリアム スケーリング問題を引き続き見ていきますが、今度は州の上昇から歴史的な上昇に注意を向けます。 粒度の細かいデータセットを使用して、1)イーサリアムのスケーリングのボトルネックを技術的に理解し、2)イーサリアムのガス制限に対する最適なソリューションに関する議論を開くのに役立つことを目標としています。

ヒストリカル上昇とは?

履歴は、イーサリアムがその生涯を通じて実行したすべてのブロックとトランザクションのコレクションであり、ジェネシスブロックから現在のブロックまでのすべてのデータです。 過去の成長とは、時間の経過に伴う新しいブロックと新しいトランザクションの上昇です。

図 1 は、履歴上昇とさまざまなプロトコルメトリックおよびイーサリアム ノードハードウェアの制約との関係を示しています。 状態上昇と比較すると、履歴上昇は異なるハードウェア制約のセットによって制限されます。 履歴の上昇は、新しいブロックとトランザクションをネットワーク全体に送信する必要があるため、ネットワークIOに圧力をかけます。 履歴上昇は、各イーサリアム ノードが履歴の完全なコピーを保存するため、ノードストレージショートに圧力をかける可能性もあります。 過去の上昇率がこれらのハードウェア制限を超えるほど速い場合、ノードはロングノードで安定したコンセンサスに到達できません。 状態の上昇とその他のスケーリングのボトルネックの概要については、このシリーズの第 1 部を参照してください。

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

最近まで、ノードあたりのネットワークスループットのほとんどは、履歴(新しいブロックやトランザクションなど)の転送に使用されていました。 これは、デンクンハードフォークにブロブが導入されたことで変わりました。 BLOB は、ノード ネットワーク アクティビティの大部分のアカウントになりました。 ただし、BLOBは、1)ノードによって2週間のみ保存され、その後破棄され、2)イーサリアムの開始からデータを繰り返す必要がないため、履歴の一部とは見なされません。 (1) のため、BLOB によってイーサリアム ノードあたりのストレージ負荷が大幅に増加することはありません。 BLOB については、この記事の後半で説明します。

この記事では、歴史的な上昇に焦点を当て、歴史と国家の関係について説明します。 状態上昇と履歴上昇には重複するハードウェア制約があるため、これらは関連する問題であり、1 つの問題を解決するともう 1 つの問題を解決するのに役立ちます。

歴史上昇 ロングどれくらいの速さですか?

図2は、イーサリアムの作成以来の過去の上昇率を示しています。 各縦線は月の上昇を表します。 Y 軸は、その月の過去の上昇の千エクサバイト数を表します。 トランザクションは「宛先アドレス」によって分類され、RLP() バイトを使用してサイズを示します。 容易に識別できない契約は「不明」に分類されます。 「その他」カテゴリには、インフラストラクチャやゲームなど、さまざまなサブカテゴリが含まれます。

図2:イーサリアムの過去の上昇率の推移

上のグラフからいくつかの重要なポイントを抜粋します。

*過去の上昇率は州の上昇の6〜8倍速いです:過去の上昇率は最近36.0 GiB /月でピークに達し、現在は19.3 GiB /月です。 州の上昇率は約6.0 GiB /月でピークに達し、現在は2.5 GiB /月です。 上昇と累積サイズの観点からの履歴と状態の比較については、この記事の後半で説明します。 *Decun以前は、歴史的な上昇率は加速していました:状態はロング年間ほぼ線形上昇していましたが(パート1を参照)、歴史は超線形上昇でした。 線形上昇の上昇率が全体のスケールの二次上昇をもたらすことを考えると、超線形上昇の上昇率は、全体のサイズが二次上昇を超えることになります。 この加速は、デンクンを過ぎると突然止まります。 イーサリアムが歴史的な上昇率で大幅なドロップを経験したのはこれが初めてです。 *最近の歴史的な上昇の大部分はロールアップから来ています:各L2はそのトランザクションのコピーをメインネットに公開します。 これにより、大量の歴史的な上昇が発生し、ロールアップが過去1年間の歴史的な成長に最も大きく貢献しました。 ただし、Dencunでは、L2が履歴ではなくBLOBを使用してトランザクションデータを公開できるため、ロールアップロングイーサリアム履歴のほとんどを生成しません。 ロールアップについては、この記事の後半で詳しく説明します。

イーサリアムの歴史的な上昇の最大の貢献者は誰ですか?

生成されたさまざまなコントラクトクラスの履歴数は、イーサリアムの使用パターンが時間の経過とともにどのように進化してきたかを明らかにしています。 図3は、さまざまな契約カテゴリの相対的な貢献度を示しています。 これは、図 2 と同じデータに正規化されます。

図3:過去の上昇に対するさまざまな契約クラスの貢献

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

*初期(紫):イーサリアムの最初の数年間はオンチェーン活動がほとんどありませんでした。 これらの初期の契約の大きなロングは現在、識別が困難であり、チャートで「不明」とマークされています。

• ERC-20時代(緑):ERC-20規格は2015年末に最終決定されましたが、2017年と2018年まで大きな発展を遂げませんでした。 ERC-20契約は、2019年に歴史的な上昇の最大の源となりました。
• DEX/分散型金融時代(ブラウン):DEXおよび分散型金融契約は、2016年には早くもオンチェーンに登場し、2017年に勢いを増し始めました。 しかし、分散型金融2020年の夏まで、それらが史上最大の上昇カテゴリーになりました。 分散型金融とDEX契約は、2021年と2022年の一部の史上上昇の50%以上を占めました。 *ロールアップ時代(灰色):2023年初頭、L2ロールアップはメインネットよりもロングトランザクションの実行を開始しました。 デンクンまでの数ヶ月のリーディングで、彼らはイーサリアムの歴史の約2/3を生成しました。

各時代は、これまで以上にイーサリアムを使用するより複雑なパターンを表しています。 時間が経つにつれて、複雑さはイーサリアムスケーリングの一形態と見なすことができ、毎秒のトランザクションなどの単純なメトリックでは測定できません。

最新のデータ月(2024年4月)では、ロールアップは履歴のほとんどをロング生成しません。 将来の歴史がDEXと分散型金融に由来するのか、それともいくつかの新しい使用パターンが出現するのかは不明です。

BLOB はどうですか?

デンクンハードフォークは、ブロブを導入することで歴史的な上昇ダイナミクスを劇的に変え、ロールアップが履歴の代わりに安価なブロブを使用してデータを公開できるようにしました。 図4は、デンクンのアップグレード前後の過去の上昇を増幅したものです。 グラフは図 2 と似ていますが、各縦線が月ではなく日を表している点が異なります。

図4 :Dエンクンが歴史的上昇に及ぼす影響

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

• Dencun以降、ロールアップの履歴上昇が約2/3に減少しました:大きなロング ロールアップが呼び出しデータからブロブに変換され、生成される履歴の量が大幅に減少しました。 ただし、2024 年 4 月現在、呼び出しデータから BLOB にまだ変換されていないロールアップがまだいくつかあります。 *デンクン以来、史上上昇の合計は約1/3減少しました:デンクンはロールアップの史上最高の上昇のみをドロップしました。 他の契約カテゴリーの過去の上昇がわずかに増加しました。 デンクンの後でも、歴史的な上昇は依然として州の上昇の8倍です(詳細については、次のセクションを参照してください)。

ブロブは歴史的な上昇速度をドロップしていますが、それでもイーサリアムの新機能です。 ブロブの存在下で過去の上昇速度がどのレベルで安定するかは不明です。

ロング高速ヒストリカル上昇は許容されますか?

ガスキャップを増やすと、過去の上昇率が増加します。 したがって、ガスを汲み上げるなどのガスキャップを増やす提案では、過去の上昇と各ノードのハードウェアボトルネックとの関係をアカウントに入れる必要があります。

許容可能な履歴上昇レートを決定するには、まず、現在の ノード ハードウェアがネットワークとストレージの観点からロングロングをどの程度維持できるかを理解する必要があります。 ネットワーク化されたハードウェアは、ガス制限が引き上げられるまで、過去の成長率がデンクン以前のピークに戻る上昇可能性は低いため、現状を無期限に維持できる可能性があります。 ただし、履歴のストレージの負担は時間の経過とともに増加します。 現在のストレージ戦略では、各ノードのストレージディスクが最終的に履歴でいっぱいになることは避けられません。

図5はイーサリアム ノード経時的な保管負担を示し、今後3年間の保管負担の上昇を予測しています。 予測は2024年4月の上昇率に基づいています。 この上昇率は、将来の使用パターンやガス制限の変更に応じて上昇または減少する可能性があります。

図 5: 履歴のサイズ、状態、およびノード全体のストレージ負荷

このグラフから、いくつかの重要な結論を導き出すことができます。

*歴史は、国家のストレージ不足の約3倍を占めています。 また、この差は時間の経過とともに拡大し、過去の成長率は州の約 8 倍の速さです。

• 1.8 TiB は、Xu ロング ノード がストレージドライブのアップグレードを余儀なくされる臨界しきい値です。 2 TB は一般的なストレージ ハード ドライブ サイズであり、使用可能な短絡はわずか 1.8 TiB です。 TB (1 兆バイト) は TiB (= 1024^4 バイト) とは異なる単位であることに注意してください。 Xu ロング ノード演算子の場合、マージ後のバリデーターは実行クライアントと一緒に実行する必要があるため、「真の」クリティカルしきい値コンセンサスさらに低くなります。 *臨界閾値は2〜3年で到達します。 ガスリミットを少しでも上げると、それに応じて時間が短縮されます。 このしきい値に達すると、ノードオペレータに多大なメンテナンス負担がかかり、追加のハードウェア(300ドルのNVMEドライブなど)を購入する必要があります。

ステータス・データとは異なり、履歴データは追加専用であり、アクセス頻度は長くなります。 したがって、理論的には、履歴データを状態データとは別に、より安価な記憶媒体に格納することが可能です。 これは、Gethなどの一部のクライアントで実現できます。

ストレージ容量に加えて、ネットワークIOは歴史的な上昇のもう一つの大きな制限です。 ストレージ容量とは異なり、ネットワーク IO の制限は短期的にはノードに問題を引き起こしませんが、これらの制限は将来的にガス制限を増やすために重要になります。

一般的なイーサリアム ノードのネットワーク容量がいくつかの履歴上昇をどのようにサポート ロングかを理解するには、履歴上昇と、再編成率、スロット ミス、ファイナル ミス、プルーフ ミス、同期委員会のミス、ブロックコミット レイテンシーなど、さまざまなネットワーク健全性メトリックとの関係を知ることが重要です。 これらのメトリックの分析はこの記事の範囲を超えていますが、コンセンサス レイヤーの正常性に関する以前の調査で、より多くのロング情報を見つけることができます。 さらに、イーサリアム財団のXatuプロジェクトは、そのような分析を高速化するために公開データセットを構築しています。

歴史的な上昇問題を解決するには?

ヒストリカル・ライジングは、ステート・ライジングよりもはるかに簡単に解決できる問題です。 これは、候補提案EIP-4444によってほぼ完全に対処できます。 このEIPは、各ノードがイーサリアムの履歴データ全体を保持することから、1年分の履歴データのみに変更します。 EIP-4444の実装後、データストレージはロングがイーサリアムスケーリングのボトルネックにならず、ロングランでは、ガスリミットの増加は制約されません。 EIP-4444は、ネットワークのロング長期的な持続可能性のために必要であり、そうでなければ、過去の上昇率が速くなり、ネットワークノードのハードウェアを定期的に更新する必要があります。

図 6 は、今後 3 年間の各ノードのストレージ負荷に対する EIP-4444 の影響を示しています。 これは図 4 と同じですが、EIP-4444 の実装後のストレージの負荷を示すために、より浅い線が追加されています。

図6:EIP-4444がイーサリアム ノードストレージの負荷に与える影響

このグラフから、いくつかの重要な結論がわかります。

• EIP-4444は、現在のストレージの負担を半減期します。 ストレージの負荷は 1.2 TiB から 633 GiB に削減されます。
• EIP-4444は、履歴ストレージの負担を安定させます。 履歴上昇率が一定であると仮定すると、履歴データは生成された速度で破棄されます。
• EIP-4444以降、ノードストレージの負荷が現在の状態に達するまでには最も長い年月がかかります。 これは、状態の上昇がストレージの負担を増加させる唯一の要因であり、状態の上昇は過去の上昇よりも遅いためです。

EIP-4444が実装された後も、ノードは1年分の履歴履歴を保存するため、履歴の上昇によってある程度のストレージ負荷が発生します。 しかし、イーサリアムが世界規模に到達したとしても、この負担の解決は難しくありません。 履歴保持方法の信頼性が証明されると、EIP-4444の1年間の有効期限は、数か月、数週間、またはそれ以下に短縮される可能性があります。

イーサリアムの履歴を保存するにはどうすればよいですか?

EIP-4444は、歴史がイーサリアム ノード自身によって保存されないのであれば、どのように保存すべきかという疑問を提起します。 歴史はイーサリアムの検証、会計、分析において中心的な役割を果たすため、歴史を保存することが重要です。 幸いなことに、履歴の保持は単純な問題であり、1/nの正直なデータプロバイダーのみを必要とします。 これは、参加者の1/3から2/3が正直であることを必要とする州のコンセンサスの問題とは対照的です。 ノードオペレーターは、1)ジェネシスブロック以降のすべてのトランザクションを再生し、2)これらのトランザクションが現在のブロックチェーン側と同じ状態ルートを再現するかどうかを確認することで、履歴データセットの信頼性を検証できます。

履歴を保存するには、最も長い方法があります。

*トレント/ P2P:トレントは最も簡単で信頼性の高い方法です。 イーサリアム ノード定期的に履歴の一部をパッケージ化し、パブリックトレントファイルとして共有できます。 たとえば、ノードは100, 000ブロックごとに新しい履歴トレントファイルを作成する場合があります。 erigonsのようなノードクライアントは、すでにこのプロセスをやや標準化されていない方法で実行しています。 このプロセスを標準化するには、すべてのノードクライアントが同じデータ形式、同じパラメータ、および同じP2Pネットワークを使用する必要があります。 ノードは、ストレージと帯域幅の機能に基づいて、このネットワークに参加するかどうかを選択できます。 Torrentsの利点は、すでに多数のデータツールでサポートされている高度なオープンスタンダードを使用していることです。 *ポータルネットワーク:ポータルネットワークは、イーサリアムデータをホストするために特別に設計された新しいネットワークです。 これはTorrentに似たアプローチですが、データ検証を容易にするいくつかの追加機能も提供します。 Portal Network の利点は、これらの追加の検証レイヤーが、共有データセットを効率的に検証および照会するためのユーティリティーをライト・クライアントに提供することです。 *クラウドホスティング:AWSのS 3やCloudflareのR 2などのクラウドストレージサービスは、履歴を保持するための安価で高性能なオプションを提供します。 ただし、このアプローチでは、これらのクラウドサービスが常に暗号資産データをホストできるという保証がないため、よりロングの法的および運用上のリスクが発生します。

残りの実装上の課題は、技術的な課題よりもロングソーシャルな課題です。 イーサリアムコミュニティは、注文で特定の実装の詳細を調整して、各ノードクライアントに直接統合する必要があります。 特に、ジェネシスブロックから (スナップショット同期ではなく) 完全同期を実行するには、イーサリアム ノードではなく履歴プロバイダーから履歴を取得する必要があります。 これらの変更は技術的にはハードフォークを必要としないため、イーサリアムの次のハードフォークであるPectraよりも早く実装できます。

これらの履歴保持方法はすべて、L2がメインネットに公開するBLOBデータを保持するためにも使用できます。 履歴の保存と比較して、BLOB の保存 1) は、データの総量がロングであるため、より困難です。 2)メインネットの履歴を再生するためにブロブは必要ないため、それほど重要ではありません。 ただし、各 L2 が独自の履歴を再生するには、BLOB の保持が必要です。 したがって、イーサリアムエコシステム全体にとって、何らかの形のブロブ保存が重要です。 さらに、L2 が堅牢な BLOB ストレージ インフラストラクチャを開発すれば、L1 の履歴データを簡単に格納できる場合もあります。

EIP-4444の前後のさまざまなノード構成によって格納されたデータセットを直接比較すると便利です。 図 7 は、さまざまなイーサリアム ノードの種類のストレージ負荷を示しています。 状態データはアカウントとコントラクト、履歴データはブロックとトランザクション、アーカイブ データはデータ インデックスのオプションのセットです。 この表のバイト数は最新のレス・スナップショットに基づいていますが、他のノード・クライアントのバイト数はほぼ同じです。

図7:イーサリアム ノードの種類ごとの保管負荷

つまり

*アーカイブノードには、アーカイブデータだけでなく、状態データと履歴データも格納されます。 アーカイブノードは、履歴チェーンの状態を簡単に照会できるようにしたい場合に使用できます。

• フルノードには、履歴データと状態データのみが格納されます。 今日のロング ノードのほとんどはフルノードです。 フルノードのストレージ負荷は、アーカイブノードの約半分です。
• EIP-4444以降のフルノードは、直近の年の状態データと履歴データのみを保存します。 これにより、ノードのストレージ負荷が 1.2 TiB から 633 GiB に軽減され、履歴データのストレージ不足が定常状態の値になります。
• ステートレスノードは「ライトノード」とも呼ばれ、データセットを保存せず、チェーンの最後にすぐに検証できます。 このノードタイプは、Verkleの試みまたは他のステートコミットメントスキームがイーサリアムに追加されると可能になります。

最後に、現在の上昇率に対応するだけでなく、過去の上昇率を制限できる追加のEIPがあります。 これにより、短期的にはネットワーク IO の制約内にとどまり、長期的にはストレージの制約内にとどまることができます。 EIP-4444 はネットワークのロング長期的な持続可能性のために引き続き必要ですが、これらの他の EIP は、将来的にイーサリアムより効率的に拡張するのに役立ちます。

• EIP-7623: 通話データの価格を再設定し、憧れの通話データを含む一部のトランザクションをより高価にしました。 これらの使用パターンのコストが高くなると、一部のパターンが呼び出しデータから BLOB に変換されざるを得なくなります。 これにより、過去の上昇率がドロップされます。
• EIP-4488:各ブロックに含めることができる通話データの総量に制限を課します。 これにより、履歴の上昇率に厳しい制限が課せられます。

これらの EIP は EIP-4444 よりも実装が容易であるため、EIP-4444 が生産開始されるまでのショート期間オプションとして機能する可能性があります。

まとめ

この記事の目的は、データを使用して、1)過去の上昇がどのように機能するか、および2)その問題を解決する方法を理解することです。 この記事のロングデータの多くは従来の方法では入手が難しいため、このデータを公開して、歴史的な上昇の問題に関する新しい洞察を提供したいと考えました。

歴史的に上昇はイーサリアム拡張のボトルネックとして、十分な注意が払われていませんでした。 ガス上限を引き上げなくても、現在の履歴管理の慣習イーサリアム、Xu ロング ノードは数年以内にハードウェアをアップグレードすることを余儀なくされます。 幸いなことに、これは解決するのが難しい問題ではありません。 EIP-4444にはすでに明確な解決策があります。 このEIPの実施は、将来のガスキャップの増加のためのショートを可能にするために加速されるべきであると考えています。

元の記事へのリンク