ビタリック、エーテルガスの上限引き上げを提案：そのリスクとは？

Author: John Otander, Core Ether Developer; Translated by Golden Finance xiaozou

この投稿は、最近の Reddit AMAにおけるイーサ・フリークエントフライヤーVitalikの回答にインスパイアされたものです。

Vitalik氏は、ガスリミットの小幅な引き上げが正当化され、ガスリミットが3年近く引き上げられなかったことを指摘した。

Vitalikは、ガス・リミットの適度な増加が正当化され、ガス・リミットは、プロトコルの歴史の中で最も長い、およそ3年間、増加されていなかったと指摘しました。

この記事は、なぜエーテルガスの上限を上げるのが難しいと言われているのかについてです。

この記事では、エーテルガスの上限を引き上げることが難しいと言われる理由と、それに伴うリスク、そして解決策について紹介する。

1, ガスリミット

ガスリミットは、与えられた資産に使うことができる金額を決定します。">ガスリミットは、ブロック内で行われる仕事の量を決定し、したがってブロックごとに実行できるトランザクションの数を決定します。ガスリミットを増やすと、イーサはより高いトランザクションスループットやより複雑なトランザクションを処理できるようになります。正確なガスリミットの設定は常にマイナー/プレジャーによって影響され、リミットは長年にわたって増加し続けています。以下のetherscan.ioのチャートは、過去のガス使用量を示しています（ガスリミットに非常に近く、リミットの増加はすべて市場に吸収されています）。

2, リスク

今、ガスの上限を引き上げることにはいくつかのリスクがある。

(1)おじさん率

前回の記事で述べたように、おじさん率はガス上限引き上げを評価する際に最も議論される指標の一つである。a metric that is most discussed when evaluating the gas limit increase.イーサ合併後、おじさんブロックはなくなりました。ノードが現在のガスリミットをうまく処理しているかどうかを知る唯一の方法は、おじさんレートを見ることです。しかし、この指標には欠陥があります。なぜなら、この指標は現在プロビジョニングが不足しているノードしか示さないからです。また、平均的なシナリオを示しているだけで、攻撃で起こりうる最悪のシナリオを示しているわけではありません。

(2)ステートサイズ

ブロック18418786（2023年10月24日）のアカウントスナップショットは10.33GB、ストレージスナップショットは76.59GBなので、全体の状態はおよそ87GBです。ブロック17419840 (2023年6月6日)の状態は80GBをわずかに下回っています。12*#年)を使って外挿すると、1年後には111GB、5年後には207GBになります。ここでの問題はサイズではありません。ここでの問題はサイズではありません。誰もがそれだけのデータを保存できますが、そのデータへのアクセスや変更はどんどん遅くなります。

これはまだスナップショットに過ぎず、一般的な状態です。

Gethはまた、状態ルートを検証するために、この状態を別の形式で保存する必要があります。

したがって、状態ストレージのためだけに現在利用可能なスペースの合計サイズは約267GBです。

状態の増加に関する問題は、過去とは異なり、状態を削除するための明確な道筋がないことです。成長状態から脱却するためにすぐに実行できる具体的な国家存続期間の勧告がないのだ。

(3)歴史的なサイズ

2021年の投稿の1つで述べたように、完全なgethノードは約350GBです(新しく刈り込まれた)。下のグラフはトランザクションの累積量を示しています。このグラフから、トランザクション量が3年間で約2倍以上、約9億8000万から22億以上になったことが容易にわかる。

L2の台頭により、（4844が稼動する前に）現在では以下のようにデータを保存しているため、過去のサイズがさらに大きな問題になっています。ブロック18418786のブロックサイズは427GBを超え、ブロック17419840（同じく4ヶ月前）のブロックサイズは339GBであり、4ヶ月で28GB、1ヶ月でおよそ9GBの成長を意味する。この成長を427 + (9*12*#年)で外挿することができ、1年で535GB、5年後には967GBになります(これも線形成長を仮定しています)。

EIP-4844が稼動し、L2がデータの可用性のためにCALLDATAを使用するのをやめ、数週間で期限切れになるブロブを使用するように移行した後、この成長が鈍化することを願っています。

EIP-4444は履歴を解決します。-44444は、フルノードがすべての履歴を保存する必要がなくなるため、履歴の増加問題を解決します。EIP-4444を実装するには、フルノードが履歴データの提供を停止する前に、履歴を取得するための信頼できるネットワークが必要です。

(4)同期時間

ガス制限は、さまざまな方法で同期時間に影響を与えます。align: "left;">- 完全同期が遅くなり、gethノードはチェーンを完全に同期するのに1週間以上かかります。

-  ヒストリカルデータの同期が遅くなります。より多くのデータをダウンロードする必要があるため、履歴データの同期部分が遅くなります。

- Snapshot synccing state is slower because we need to download more state.

- Snapshot recovery is slower.スナップショットの同期中にピボット・ポイントが移動するため、修正する必要がある不完全な状態がディスク上にたくさんあります。ピボットがより頻繁に移動し、ブロックごとにより多くの変更がある場合、その修復フェーズはより遅くなります。

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

(5)クライアントの多様性

新しいELクライアントを構築することは、それだけで大変な作業です。ガス制限を追加することは、クライアントを構築し、メインネットワークで使用するために最適化することをより困難にするという追加の欠点があります。新しいクライアントは既存のクライアントから学ぶことができ、同じ間違いを繰り返さないという反対意見もあるかもしれません。

しかし、私たちはすでに2つのクライアント（pythonで書かれたExecution Specsとjavascriptで書かれたEthereumJ）のメインネットの苦境を見てきました。これはまた、特定の言語で書かれたクライアントが現在動作しないことを意味する。ガスの上限を増やすと、言語のオーバーヘッドとコードベースの成熟により、いくつかのクライアントが落ちるでしょう。

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

(6)最悪のケース

ガス限界を考えるとき、一般的なケースだけを見ることはできません。常に最悪のケースを考慮しなければなりません。確かに、チェーンが平均的な負荷のときはノードは問題なく動作するかもしれませんが、突然ディスクI/Oが5ブロック連続で2倍になったらどうなるでしょうか？

考慮すべき指標はランタイムだけではありません。攻撃者がディスクI/O、CPU時間、メモリなど他のリソースを占有できれば、低設定のマシンを強制的にオフラインにできるかもしれません。特にイーサネットの統合後は、同じマシン上で2つのクライアントを実行しているため、片方を攻撃するともう片方も不安定な状態になる可能性がある。イーサネット合併のテストの初期には、1つのクライアントのメモリリークがシステム全体をクラッシュさせるという事例をいくつか目撃しました。

考慮すべきもう1つの最悪のシナリオは、プルーフサイズです。ガスの上限が大きくなると、2つのブロック間で起こりうる状態の変化も大きくなります。これは前述したスナップショット同期にも影響するが、実行レベルでのライトクライアントのプルーフサイズにも影響する。メルクル・パトリシア・ツリーの証明は、ネットワーク経由で送信するには大きすぎるからだ。しかし、同じマシン上で動作する複数のライトクライアントで交差検証のアイデアを実装したい場合は、証明サイズが重要になります。

3、解決策

これで終わりでしょうか？このまま30MGasを上限とするのでしょうか？そうでもありません！

2021年の投稿の1つで、私は当時直面したジレンマに対する解決策を提案しました。2021年に直面した完全同期の問題に対して、gethはスナップショット同期とスナップショットを実装しました。txpoolは高負荷トランザクションの処理においてはるかに信頼できるようになり、MEVロボコールのトランザクションのほとんどはビルダーに移行された。また、多くのトランザクションがL2に移行し、メインネット上のトランザクションの平均サイズが増加した。

実現しなかった唯一の解決策はリジェネシスでした。何年もの間、意見に若干の変化があり、ほとんどの人はヒストリカルデータ増加のための短期的な解決策としてEIP-4444ヒストリカルデュレーションを支持しているようです。EIP-4444のリリースのためには、すべての完全なノードによって保存されなくなったとしても履歴が失われないように、履歴データを提供するノードの堅牢なネットワークが必要です（ちなみに、ほとんどのビットコインノードは履歴データをまったく保存していません）。

状態のデッドラインを行うまともで現実的な方法はまだ見つかっていません。

上海アップグレード前の攻撃でお分かりのように、ガスリミットの引き上げを妨げる既知の攻撃がいくつかありました。

本稿執筆時点では、EIP-4844がテストネットワーク上でリリースされています。このEIPは、ノードのストレージとI/O要件を増加させます。私見では、この変更がメインネットワークにどのような影響を与えるか確認するのを待つのが、何らかのガス制限の引き上げを試みる前の最も安全な行動方針である。L2がBlobトランザクションに移行したら、calldataのコストを引き上げるべきだ（私の意見では、calldataはデータの保存が必要な他のものに比べて過小評価されているため）。これは、L2がblobspaceを使うための強制機能にもなり得る。

まとめると、ノードの多くの側面に影響を与え、そのうちのいくつかは比較的明白になるため、ガス制限の引き上げを検討する際は慎重に進めるよう、人々に注意を促したいと思います。関連する議論として、ガスリミットの変更がもたらす長期的な影響と短期的な影響の両方を考慮することが重要です。