Vitalikはガス制限を改善することをお勧めします：リスクと解決策は何ですか

著者：John Otander、コアイーサリアム開発者

この記事は、最近のReddit AMAでのVitalikに対するEthereumの頻繁な回答に触発されました。

Vitalikは、ガス制限を適度に増やすことが合理的であり、3年近くでガス制限が増加していないことを指摘しました。これは、契約の歴史の中で最も長い時間です。また、Vitalikは、イーサリアムガスの制限を4,000万に増やすために、いくつかの簡単な計算を行いました。

この記事では、イーサリアムのガス制限を改善するのが難しい理由について説明します。イーサリアムのガス制限と関連するソリューションによってもたらされるリスクを増やします。

1、ガス制限（ガス制限））

ガス限界は、ブロック内で完了した作業量を決定するため、ブロックごとに実行できるトランザクションの数を決定します。ガス制限を改善することで、イーサリアムはより高いトランザクションスループットまたはより複雑なトランザクションを処理できます。特定のガス制限設定は鉱夫/利害関係者の影響を受けており、長年にわたって制限が増加しています。次の数字はEtherscan.ioからのもので、歴史的なガスの使用量を示しています（ガス制限に非常に近い、すべての制限の増加は市場によって消化されています）。

2、リスク

現在、ガス制限を増やすことにはいくつかのリスクが伴います。

（1）漏れブロックレート

前の記事で、ガス限界の増加を評価する際に叔父のレートが最も議論されている指標であると述べました。さて、イーサリアムの合併後、もうブロックはありません。ノードが現在のガス制限をうまく処理できるかどうかを知りたい場合、唯一の方法は、欠落しているブロックレートを確認することです。しかし、このメトリックには、現在サプライされていないノードのみが表示されるため、欠陥があります。ガス限界の増加を示すための適切なメトリックは提供されず、攻撃で発生する可能性のある最悪のケースではなく、平均的なケースのみを示しています。

（2）ステータスサイズ

ブロック18418786（2023年10月24日）のアカウントスナップショットは10.33GBで、ストレージスナップショットは76.59GBであるため、全体の状態は約87GBです。ブロック17419840（2023年6月6日）のステータスは80GB未満です。これは、4か月でステータスが約7GB増加したことを意味します。これは、1か月あたり約2GBを意味します。

87+（2*12*＃年）を使用して推測すると、ステータスは1年で111GB、5年間で207GBになります。ここでの問題はサイズではありません。誰もが非常に多くのデータを保存できますが、このデータへのアクセスと変更はより遅くなり、遅くなります。

これは単なるスナップショットであり、通常の状態です。ゲスはまた、状態のルートを検証するために、この状態を別の形式で保存する必要があります。ブロック18418786の別の形式の状態ストレージ（TRIEノード）には約180GBが必要です。

したがって、現在、状態ストレージに使用されている合計スペースサイズは約267GBです。ガス制限を増やすと、状態サイズがより速くなります。

州の成長の問題は、過去とは異なり、状態を除去する明確な道がないということです。成長している状態から私たちを追い出すために迅速に実装できる特定の州の締め切りの提案はありません。

（3）歴史的規模

2021年の記事で、完全なGethノードは約350GB（新しく剪定）であると述べました。約3年後、フルゲットノード（PBSS）は900GBを超えています。次の図は、トランザクションの総蓄積量を示しています。トランザクションのボリュームは、約9億8,000万から22億を超える3年で2倍以上になっていることがわかります。

L2が上昇すると、現在（4844が公開される前に）データを保存する方法がデータと呼ばれるように、歴史的規模がより大きな問題になりました。ブロック18418786には427GB以上のブロックがあり、ブロック17419840（4か月前）には339GBのブロックがあり、4か月で28GBの成長を意味し、1か月あたり約9GBの成長を意味します。427+（9*12*＃Year）を使用して、この成長を推測できます。つまり、1年後に535GB、5年後に967GB（再び線形成長を想定します）。

うまくいけば、L2がCallDataの使用を停止してデータの可用性を取得し、数週間で期限切れになるブロブに切り替えると、EIP-4844が発売されると、この成長が遅くなることを願っています。

EIP-4444は、完全なノードがすべての履歴を保存する必要がなくなったため、歴史的な成長の問題を解決します。EIP-4444を実装するには、履歴を取得するための信頼できるネットワークが必要であり、完全なノード停止履歴データサービスを作成できます。

（4）同期時間

ガス制限は、多くの点で同期時間に影響を与える可能性があります。

・完全な同期は、チェーンを完全に同期するのに1週間以上かかります。

・同時履歴データは遅いです。より多くのデータをダウンロードする必要があるため、履歴データの部分を同期するのは遅くなります。

・スナップショット同期ステータスは、より多くのステータスをダウンロードする必要があるため、遅くなります。

・スナップショットの回復は遅いです。スナップショットの同期中にピボットポイントが移動するため、ディスク上には修正する必要がある多くの不完全な状態があります。Pivotがより頻繁に移動し、ブロックごとにさらに多くの変更がある場合、この修理段階は遅くなります。

・ノードはより多くの変更を渡してブロックヘッダーを形成する必要があるため、チェーンとの同期は遅くなります。

（5）クライアントの多様性

新しいELクライアントを構築することは、それ自体が難しい作業です。ガス制限を追加することには追加の欠点があります。つまり、クライアントを構築し、メインネットが使用するために最適化することがより困難になるということです。Gethは10年以上開発されており、多くの最適化を受けています。新しいクライアントが既存のクライアントから借りることができ、もはや同じ間違いを犯さないという反対の見解があるかもしれません。

ただし、2つのクライアントのメインネットのジレンマ（JavaScriptで書かれたPythonとEthereumjで書かれた実行仕様）が見られました。これはまた、特定の言語で書かれたクライアントが現在機能していないことを意味します。言語のオーバーヘッドとコードベースの成熟により、ガスの制限を追加すると、一部のクライアントが残ります。

これはKZGで見られ、必要なパフォーマンスを取得するために、ほとんどのクライアントは、選択した言語で記述されたライブラリを使用するのではなく、C-KZG（Cで書かれたコードベース）を呼び出すことに依存しています。

（6）最悪の場合

ガス制限を検討する場合、一般的な状況を見ることはできません。私たちは常に最悪のシナリオを考慮する必要があります。もちろん、チェーンが平均負荷状況にある場合、ノードはうまく動作する可能性がありますが、5ブロックのディスクI/Oが突然2倍になるとどうなりますか？

ランタイムは考慮する必要がある唯一のメトリックではなく、攻撃者がディスクI/O、CPU時間、メモリなどの他のリソースを取り上げることができる場合、より低い構成マシンをオフラインにすることができます。特にイーサリアムの合併後、同じマシンで2人のクライアントを実行すると、そのうちの1人を攻撃することも、他のクライアントを不安定にする可能性があります。Ethereum Merge Testingの初期には、何度か目撃しました。1つのクライアントのメモリリークがシステム全体をクラッシュさせます。

考慮すべきもう1つの最悪のシナリオは、証明サイズです。ガス限界が増加すると、2つのブロック間で発生する可能性のある状態の潜在的な変化も増加します。これは、前述のスナップショット同期に影響を与えますが、実行レイヤーライトクライアントの証明サイズにも影響します。これは大したことではありません。マークルパトリシアツリーの証拠は、ネットワーク上に送信できないほど大きすぎます。ただし、同じマシンで複数のライトクライアントを実行するという交差検証のアイデアを実装したい場合は、証明サイズが非常に重要です。

3、解決

私たちはそのように終わりましたか？30mgasの上限を維持しますか？いいえ！

2021年の記事では、当時私たちが直面していたジレンマの解決策を提案しました。2021年に直面している完全な同期問題については、GethはSnapshot同期とスナップショットを実装します。剪定およびデータベースレイアウトの問題については、GethはPBSSを実装します。TXPOOLは、高いトランザクション負荷の処理においてより信頼性が高く、MEVラッシュトランザクションのほとんどはビルダーに転送されます。多くのトランザクションもL2に移動し、その結果、メインネットトランザクションの平均サイズが増加しました。

実装されていない唯一のソリューションは再生です。長年にわたり、人々の見解は少し変わり、ほとんどの人は、歴史的データの成長に対する短期的な解決策として、EIP-4444の歴史的締め切りを使用する傾向があるようです。EIP-4444のリリースには、履歴が失われないように、履歴データサービスノードの強力なネットワークが必要です。全て）。

私たちはまだ、州の締め切りに行くためのまともで現実的な方法を見つけていません。

上海でエスカレートする前に攻撃を見たとき、ガスリミットを育てるのを妨げるいくつかの既知の攻撃があります。（私が知る限り）すべての脆弱性が解決されました。

執筆時点で、EIP-4844はオンラインで公開されています。このEIPは、ノードのストレージとI/O要件を増加させます。私の意見では、あらゆる種類のガス制限の追加を試す前に、この変化の影響をメインネットに待って見るのが最も安全です。L2がBLOBトランザクションに変わると、CallDataコストを増やす必要があります（私の意見では、CallDataはデータを保存する必要がある他のものと比較して過小評価されているためです）。これは、Blobspaceを使用したL2の強制機能としても使用できます。

要するに、ガス制限の改善を検討する際には、ノードの多くの側面に影響を与えるため、すべての人に注意することを思い出させたいと思います。効果の一部は比較的明白です。関連する議論では、ガス制限の変化の長期的および短期的な影響を考慮することが非常に重要です。