イーサリアムはなぜガス上限を6000万に引き上げることができるのか？

著者: Zhixiong Pan

過去一年間、イーサリアムのブロックのガス上限（Gas Limit）は約3000万から6000万へと急速に引き上げられました。この飛躍の背後には、プロトコルレイヤーによるブロックの最悪のケースサイズの制御、実行クライアントの性能の大幅な最適化、そしてより高いガス上限に対する体系的なテスト検証など、複数の要因が共同で推進しています。

簡単に言えば、開発者はEthereumプロトコルのルールを改善することで、Gas上限を引き上げるリスクを減少させ、各クライアントが大きなブロックを処理する速度を大幅に向上させ、ネットワークがより高い負荷の下でも時間通りにブロックを生成し、ブロックを伝播できることを証明しました。

これらの努力により、イーサリアムのメインネットはガス上限を軽々に引き上げることに躊躇していたが、今では安全に上限を60Mガスまで引き上げることができるようになった。以下では、ガスリミットの概念と歴史について詳しく説明し、次にガスリミットの引き上げの核心的な理由を深く探り、将来的なさらなる拡張に必要な条件について展望します。

ガスリミットとブロブ：定義と違い

ガス上限（Gas Limit） はイーサリアムにおいて各ブロック内の最大計算作業量を測るパラメーターであり、各ブロックに含まれる取引実行のための総ガス数の上限を意味します。ガス上限が高いほど、単一のブロックが収容できる取引が増え、チェーン上のスループットが増大します。しかし、副作用として、より高いガス上限はネットワーク参加者の負担を増加させます：ブロック検証者は固定のブロック時間内により大きなブロックをパッケージ化し、ブロードキャストする必要があり、全ネットワークのすべてのノードもより大きなブロックをダウンロードし、実行しなければならず、ネットワーク帯域幅とノードハードウェアへの圧力が上昇します。

Blob は、イーサリアムのデータ可用性を拡張するために導入された新しい要素であり、異なる性質のブロックコンテンツの一種です。Blob は EIP-4844 提案に由来し、ブロック内に Layer 2 用の大量のバイナリデータを一時的に収容することを可能にし、そのコスト計測は通常の取引のガス消費とは独立しています。簡単に言えば、Blob は L2 Rollup データのための追加のスペースを提供し、ガスリミットは一般的な EVM 計算の規模上限を測るものです。両者は直接比較できるものではありません：Blob の数を増やすことは、ブロック内に追加できる L2 データ容量に主に影響し、ガスリミットを増加させることは L1 の取引実行の計算容量を直接増加させます。

この記事では、Gas Limit というトピックに焦点を当て、Blob 容量の変化については詳しく説明しません。

歴史的背景：なぜ過去に Gas Limit を引き上げることができなかったのか？

イーサリアムは初期にブロックのガス上限を引き上げることに慎重な態度を持っていました。EIP-1559が2021年に実施された後、イーサリアムはブロックのガスターゲットを約1500万（単一ブロックの最大約3000万）に設定し、その後数年間は引き上げていません。その理由は、その当時いくつかの重要なボトルネックが未解決であり、無謀にガス上限を引き上げることはネットワークの安全性と分散化を危険にさらす可能性があるためです。

• 実行性能：クライアントソフトウェアは、より多くの取引を十分な速さで実行できますか？もしブロックが大きすぎてノードがブロック間隔内に実行と検証を完了できない場合、タイムリーにブロックを生成できなかったり、チェーンの分岐が発生する可能性があります。
• ネットワーク伝播：大きなブロックは 12秒 のブロック生成周期内にネットワーク全体にブロードキャストされる必要があり、特に 4秒 内に多数のバリデーターに受信されなければ、タイムリーにステーク決済を行うことができません。大きすぎるブロックは伝播遅延を引き起こし、コンセンサスの問題を引き起こす可能性があります。
• ステータスの成長：より高いスループットは、イーサリアムのグローバルステータス（台帳データ）の膨張を加速させ、ノードの同期とストレージの負担が増加し、長期的にはネットワークの分散化を弱める可能性があります。
• ハードウェア要件：これらの要因が重なり合うことで、ノードを運営するために必要なハードウェア構成が向上します。一般ユーザーが家庭用コンピュータでは追いつきにくく、高いガス上限があるとネットワークが少数の高性能ノードに集中し、分散化に不利になる可能性があります。

上記の懸念により、長い間イーサリアムメインネットのGas上限は基本的に安定しており、3000万のレベルを簡単に突破することはありませんでした。特にRollupの台頭により、大量の取引が低コストのcalldataを通じてL1に圧縮データを公開するため、イーサリアムブロックの平均サイズは徐々に限界に近づいており、極端な場合には1ブロックのデータが数メガバイトに達することさえあります。

他の改善がない場合、ガス上限を引き上げることはブロックサイズとパフォーマンスの問題をさらに拡大するだけです。したがって、当時のイーサリアムコミュニティはLayer 2のスケーリングに主に依存することを選択し、L1でガス上限を無闇に引き上げることはしませんでした。

今日のガス制限の急激な増加の主な理由

では、なぜ2025年以降、イーサリアムは安全性を維持しながらガス上限を倍以上に迅速に引き上げることができるのでしょうか？その根本的な理由は、以下のいくつかの技術的改善が同時に実施され、スケーラビリティの障害を取り除いたためです。

!

プロトコルアップグレード制限最悪ケースブロックサイズ

イーサリアムは、「最悪のシナリオ」におけるブロックサイズの上限を縮小するために新しいプロトコルルールを導入しました。中でも重要なものがEIP-7623提案で、これはトランザクション内のcalldataデータのGasコストを引き上げることで、極端な状況下で単一のブロックに含まれる安価なデータ量を大幅に減少させます。

EIP-7623の実施前、攻撃者は超低のcalldata Gas単価を利用して、1つのブロックに数MBのデータを詰め込むことができました。しかし、価格が上がった後は、同じサイズのデータにより多くのGasが必要になり、実質的にブロックサイズの上限が低下し、ブロックサイズの「平均値と極値の差が大きすぎる」問題が緩和されました。

この変更により、全体のガスリミットを引き上げても、ブロック全体のバイトサイズが無制限に膨張することはなくなり、ガスの上限を引き上げるための安全な余地が確保されました。言い換えれば、プロトコルレイヤーはデータ面のコストを主導的に引き締め、「計算量が倍増しても、ブロックサイズは倍増しない」ことを保証し、後にガスの上限を3000万から6000万に引き上げるための基盤を築きました。

同時に、メインネットはEIP-4844でRollup用の専用Blobデータトランザクションを導入し、Rollupが安価なcalldataに依存することをさらに減少させました。Rollupデータが通常のGas空間からBlob空間に徐々に移行することで、通常のブロックGasは真の契約計算により集中し、平均ブロックは「軽く」なり、これはGas上限の引き上げにより有利な条件を間接的に作り出します。

クライアントのパフォーマンスが大幅に最適化されました

各イーサリアム実行クライアントチームは、ソフトウェアの詳細な性能ベンチマークテストと最適化を行い、大きなブロックの処理速度を大幅に向上させました。Nethermindなどのチームが主導するGasベンチマークテストフレームワークは、全ブロックで単一タイプの命令またはプリコンパイルコントラクトを充填し、クライアントの限界処理能力をストレステストするために（「百万Gas毎秒」で性能を測定）使用されます。

この統一基準を通じて、開発者は過去に隠れていたいくつかの実行ボトルネックを発見し修正しました。例えば、テスト中に「モジュラーレピート乗算」（ModExp）プリコンパイルの特定の極端なケースが、そのGas価格を大幅に超えて時間がかかることが判明し、すべての主要なクライアントの共通のボトルネックとなりました。

これらの発見に対して、コミュニティは迅速に EIP-7883 を提案し、ModExp のプリコンパイルのガス再価格設定を行い、クライアントの最適化アルゴリズムを調整しました。同時に、他の時間のかかる暗号操作（例えば、BLS12-381 楕円曲線計算 BN256、ハッシュなど）もそれぞれクライアントチームによって最適化または再価格設定されました。

統計によれば、2025年中期に行われるクロスクライアントの「ベルリン相互運用性」パフォーマンススプリントを経て、各実行クライアントの最悪のシナリオにおけるブロック処理速度が著しく向上し、大多数の操作が毎秒約2000万Gasのレベルに達しています。

換算すると、クライアントが毎秒 2000 万 Gas を実行できる場合、PoS のブロック生成間隔 4 秒内に理論的に最大 80M Gas のブロックを処理できることになります。これは、ブロックの上限を 60M Gas に引き上げても安全な余裕があることを意味します。

これらの性能改善により、「実行速度がガスの上限に追いつかない」という懸念が解消され、ブロックに従来の2倍の取引量が含まれていても、クライアントは定められた時間内に検証を完了でき、実行が遅すぎてコンセンサスの期限を逃すことはありません。

ネットワーク伝播の限界を全面的にテスト検証する

メインネットのガス上限の引き上げを実施する前に、開発者は複数の専門ネットワークで十分なテストを行い、より大きなブロックが依然として迅速に伝播し、ほとんどのノードによって受け入れられることを確認しました。

例えば、2025年にイーサリアムの開発者がテストネットSepoliaと新しい開発ネットHoodiでブロックのGas上限を60Mに引き上げ、ネットワークのパフォーマンス指標を継続的に観察しました。結果として、最大60MのGasを使用したブロックでも、これらのネットワーク内のブロック提案は時間通りにパッケージ化され、P2Pネットワークを通じて迅速に広がることができました：90％のノードはブロック生成後約0.7〜1.0秒以内にブロックを受信し、ほぼすべてのノードが4秒以内に検証を完了し、新しいチェーンの先頭としてブロックを受け入れました。

言い換えれば、ブロックの Gas 使用量が倍増しても、ブロックはイーサリアムの定めた 4 秒の提案者提出期限前にネットワーク全体に伝播することができます。これらのストレステストでは、開発者は提案ノードがブロックを時間通りに生成しているか、全ノードが新しいブロックを受け入れるのに必要な時間の分布などの重要データを監視し、明らかな異常は見つかりませんでした。

テストネットの状態規模とノードトポロジーがメインネットと異なるため、開発者はこれに慎重に楽観的ですが、テスト結果は理論的および工学的に60M Gasブロックが実行可能であることを証明しました。同時に、コンセンサスレイヤーの安全性を保証するために、開発者はビーコンサインのレベルでの制限（例えば、ビーコンサインネットワークレイヤーでは現在約10MBの単一ブロックGossip伝播上限があります）も考慮しています。前述のEIP-7623などの手段を通じて、単一ブロックのバイト数を削減し、同時に過剰なペナルティトランザクションが発生する最悪のシナリオを回避することで、60M Gasの実行負荷はこれらの上限には達していません。

!

総合的に見て、各種テストと調整により、コアチームはメインネットのガスリミットを3000万から6000万に引き上げるリスクを十分に把握し、自信を高めました。多くのバリデーターが支持信号を表明した後（約15万+バリデーションノードが増額に同意）、イーサリアムは2025年にメインネットのガス上限を引き上げる作業を開始し、今後のアップグレードでデフォルト値を60Mに正式に調整する計画です。

未来の展望：さらなる向上には何が必要か？

イーサリアムコミュニティは60Mガスで止まるつもりはありません。 Fusakaなどの後続のアップグレード計画の中で、開発者はブロックガスの上限を100Mやそれ以上に引き上げる道筋を描いています。この目標を達成するためには、解決すべき技術的課題がいくつか残っているか、引き続き注目する必要があります。

• 重度計算操作のさらなる最適化：前述のModExpアルゴリズムの通り、現在EIP-7883の価格変更とクライアントの最適化により、ボトルネックはほぼ解消されています。しかし、100Mレベルのブロックを支えるには、他の高いGas消費を伴う暗号運算（例えば、楕円曲線署名検証、ゼロ知識証明検証など）に対して最適化や専用アクセラレーションの追加が求められるかもしれません。幸いにも、クライアントチームはこれらの方向で協力を始めており、2025年のテストではBN256楕円曲線関連のプリコンパイルの実装が調整され、その性能はもはや足かせにならないようになりました。Ethereumがより多くの高性能暗号原語（さらにはSTARKなどのネイティブサポートを考慮する）を導入するにつれて、実行のボトルネックは引き続き突破され、Gas上限を向上させるための障害が取り除かれることが予想されます。
• 状態規模とノードコストの管理：より高いガス上限は、オンチェーン状態がより早く成長する可能性を意味します。これに対処しないと、数年後にはフルノードのストレージと新しいノードの同期が著しく困難になるでしょう。イーサリアムの開発者たちは、状態の成長問題を研究しており、例えば状態のレンタルや歴史的状態の定期的な剪定を提案していますが、無限の膨張を避けるためのこれらの長期的なメカニズムはまだ議論の段階にあります。短期的には、ガス上限が引き上げられるにつれて、ノードオペレーターは増加する状態とデータ量に対応するために、より頻繁にハードウェア（より速いSSDやより大きなメモリなど）をアップグレードする必要があるかもしれません。コミュニティはガス上限を引き上げる一方で、分散化を犠牲にしないことを強調しており、状態管理の仕組みが成熟する前に、一般ノードへの影響を慎重に評価するでしょう。
• コンセンサス層の改善とネットワークプロトコルの最適化：将来的に 100M Gas またはそれ以上のブロックをサポートする必要がある場合、一部のコンセンサスおよびネットワークパラメータを調整する必要があるかもしれません。例えば、現在のビーコントレインのブロックは、実行負荷、Blob データ、証明データを含む全体サイズ制限があります。開発者は、P2P 層のメッセージサイズ上限を引き上げるか、圧縮、シャーディング伝播などの技術を通じて大型ブロックの遅延を減らす必要があるかもしれません。さらに、イーサリアムは Blob データの効率的な伝播を扱うために PeerDAS（ピア・データ・サンプリングネットワーク）を導入しており、これにより実行層のブロック伝播の圧力がある程度軽減されます。実行層が 60M+ Gas 安全に運営されることを保証した後、データ層とネットワーク層の改善が次の段階のスケーリングの重点となります。

未来を展望すると、上記のプロセスの改善が同時に進行すれば、イーサリアムメインネットがさらにGas上限を引き上げることは手の届かない目標ではありません。開発者はテストネットで36Mから45M、60Mへの引き上げの実現可能性を検証しています。次のステップとして100Mへの移行も計画されています。強調すべきは、イーサリアムコミュニティが拡張に対して一貫して慎重な態度を保っていることです：すべての引き上げは「まずテスト、次にメインネット」となり、ネットワークの安全性と分散化を危険にさらさないことが確認された後にのみ実施されます。

全体として、過去1年間のガスリミットの大幅な向上は、複数の分野の協調的な革新の結果です：プロトコル層はリスクを低減し、クライアントは性能を向上させ、テストデータは信頼を提供します。これらの努力の支えにより、EthereumはL1のスケーラビリティにおいて重要な一歩を踏み出し、将来のさらなる容量の向上やより多くのアプリケーションを支えるための基盤を築きました。