イーサリアム実行レイヤーのスケーラビリティ拡張におけるパラダイムシフト：防御的保守主義から実証科学主導の60M Gas Limit進化へ

これらの取り組みにより、EthereumメインネットはかつてはGas上限の引き上げに慎重だったものの、現在では安全に上限を60M Gas、さらにはそれ以上に引き上げることが可能となりました。

執筆：ZHIXIONG PAN

過去1年間で、EthereumブロックのGas上限（Gas Limit）は約3,000万から6,000万へと急速に引き上げられました。この飛躍の背後には、プロトコルレベルでのブロック最悪ケースサイズの制御、実行クライアントのパフォーマンス大幅最適化、そしてより高いGas上限に向けたシステマティックなテスト検証など、複数の要因が複合的に作用しています。

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

これらの努力により、EthereumメインネットはGas上限の引き上げに慎重だった時代から、安全に上限を60M Gasまで引き上げられるようになりました。以下では、Gas Limitの概念と歴史を詳しく説明し、Gas Limit引き上げの核心的な理由を掘り下げ、今後さらなるスケーリングに必要な条件について展望します。

Gas LimitとBlob：定義と違い

Gas上限（Gas Limit）は、Ethereumにおいて各ブロック内で実行可能な最大計算作業量を測るパラメータであり、各ブロックが含むことのできるトランザクション実行の総Gas量の上限を示します。Gas上限が高いほど、1ブロックに収容できるトランザクションが増え、オンチェーンスループットも大きくなります。しかし副作用として、より高いGas上限はネットワーク参加者の負担を増やします。ブロックバリデーターは決められたブロック生成時間内により大きなブロックをパッケージし、ブロードキャストする必要があり、全ノードもより大きなブロックをダウンロード・実行しなければならず、ネットワーク帯域やノードハードウェアへの負荷が増大します。

Blobは、Ethereumのデータ可用性拡張のために導入された新しいブロック内容であり、性質が異なります。BlobはEIP-4844提案に由来し、ブロック内にLayer 2向けの大量バイナリデータを一時的に格納することを可能にし、そのコスト計測は通常トランザクションのGas消費とは独立しています。簡単に言えば、BlobはL2 Rollupデータ専用の追加スペースを提供し、Gas Limitは通常のEVM計算の規模上限を測るものです。両者は直接比較できません。Blob数の増加は主にブロック内に付加できるL2データ容量に影響し、Gas Limitの引き上げはL1でのトランザクション実行の計算容量を直接増やします。

本記事ではGas Limitに焦点を当てて議論し、Blob容量の変化については触れません。

歴史的背景：なぜ過去はGas Limitを引き上げられなかったのか？

Ethereum初期はブロックGas上限の引き上げに一貫して慎重な姿勢を取っていました。EIP-1559が2021年に実装された後、EthereumはブロックGasターゲットを約1,500万（1ブロック最大約3,000万）に設定し、その後数年間は引き上げられませんでした。その理由は、当時いくつかの重要なボトルネックが未解決であり、無謀にGas上限を引き上げるとネットワークの安全性や分散性を脅かす可能性があったためです：

• 実行パフォーマンス：クライアントソフトウェアはより多くのトランザクションを十分に速く実行できるか？ブロックが大きすぎてノードがブロック間隔内に実行・検証を完了できない場合、タイムリーなブロック生成を逃したり、チェーン分岐が発生する可能性があります。
• ネットワーク伝播：より大きなブロックは12秒のブロック生成サイクル内に全ネットワークへブロードキャストされる必要があり、特に4秒以内に大多数のバリデーターに受信されなければ証明提出が間に合いません。ブロックが大きすぎると伝播遅延が発生し、コンセンサス問題を引き起こします。
• ステート成長：より高いスループットはEthereum全体のステート（台帳データ）の膨張を加速させ、ノードの同期やストレージ負担が増し、長期的にはネットワークの分散性を損なう可能性があります。
• ハードウェア要件：上記要因が重なることで、ノード運用に必要なハードウェア構成が高くなります。一般ユーザーが家庭用PCで追従できなくなると、より高いGas上限はネットワークを少数の高性能ノードに集中させ、分散性に悪影響を及ぼします。

これらの懸念から、EthereumメインネットのGas上限は長期間ほぼ安定し、3,000万の水準を容易に突破することはありませんでした。特にRollupが台頭した後、多数のトランザクションが圧縮データを低コストのcalldataでL1に投稿するようになり、Ethereumブロックの平均サイズは徐々に限界に近づき、極端な場合は1ブロックのデータが数メガバイトに達することもありました。

他の改良がない場合、Gas上限の引き上げはブロックサイズやパフォーマンスの問題をさらに拡大するだけです。そのため、Ethereumコミュニティは当時、主にLayer 2によるスケーリングに依存し、L1でのGas上限引き上げは控えていました。

現在Gas Limitが急速に引き上げられた核心的な理由

では、なぜ2025年以降、Ethereumは安全を保ったままGas上限を2倍以上に急速に引き上げることができたのでしょうか？根本的な理由は、以下の技術的改良が同時に実現し、スケーリングの障壁を取り除いたことにあります。

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

Ethereumは新しいプロトコルルールを導入し、「最悪ケース」のブロックサイズ上限を縮小しました。その中で重要なのがEIP-7623提案で、これはトランザクション内のcalldataデータのGasコストを引き上げることで、極端な場合に1ブロックに含められる安価なデータ量を大幅に減少させました。

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

この変更により、全体のGas Limitを引き上げても、ブロック全体のバイトサイズが無制限に膨張することはなくなり、Gas上限引き上げの安全余地が確保されました。言い換えれば、プロトコルレベルでデータ層のコストを積極的に引き締め、「計算量が2倍になってもブロックサイズは2倍にならない」ことを保証し、Gas上限を3,000万から6,000万に引き上げる基礎を築きました。

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

クライアントパフォーマンスの大幅最適化

各Ethereum実行クライアントチームはソフトウェアのパフォーマンスベンチマークと最適化を徹底的に行い、大規模ブロックの処理速度を大幅に向上させました。Nethermindなどのチーム主導によるGasベンチマークテストフレームワークでは、全ブロックに単一タイプの命令やプリコンパイルコントラクトを詰め込み、クライアントの限界処理能力（「毎秒百万Gas」で性能を測定）をストレステストしました。

この統一ベンチマークにより、開発者は過去に隠れていた実行ボトルネックを発見・修正しました。例えば、テスト中に「モジュラー指数乗算（ModExp）」プリコンパイルの一部極端ケースが、そのGas価格を大きく上回る時間を要し、全主流クライアントの共通ボトルネックとなっていることが判明しました。

これを受けて、コミュニティは迅速にEIP-7883を提案し、ModExpプリコンパイルのGas再価格付けとクライアントのアルゴリズム最適化を調整しました。同時に、他の時間のかかる暗号操作（BLS12-381楕円曲線計算BN256、ハッシュなど）もクライアントチームによって最適化または再価格付けされました。

統計によると、2025年中期のクロスクライアント「Berlin Interop」パフォーマンススプリントを経て、各実行クライアントの最悪ケースでのブロック処理速度は大幅に向上し、大多数の操作が毎秒約2,000万Gasの処理レベルに達しました。

換算すると、クライアントが毎秒2,000万Gasを実行できれば、PoSブロック生成間隔4秒内に理論上最大80M Gasのブロックを処理できます。つまり、ブロック上限を60M Gasに引き上げても安全余地内に収まります。

これらのパフォーマンス改良により、「実行速度がGas上限に追いつかない」という懸念が解消され、ブロックに従来の2倍のトランザクション量が含まれても、クライアントは規定時間内に検証を完了でき、実行遅延によるコンセンサス期限の逸脱が発生しません。

ネットワーク伝播限界の徹底テスト検証

メインネットでGas上限を引き上げる前に、開発者は複数の専用ネットワークで十分なテストを行い、より大きなブロックでもタイムリーに伝播し、ほとんどのノードに受け入れられることを確認しました。

例えば、2025年にEthereum開発者はテストネットSepoliaや新開発ネットHoodiでブロックGas上限を60Mに引き上げ、ネットワークパフォーマンス指標を継続的に観察しました。その結果、最大60M Gasのブロックを使用しても、これらのネットワークでのブロック提案は定時にパッケージされ、P2Pネットワークを通じて迅速に伝播されました。90%のノードがブロック生成後約0.7～1.0秒でブロックを受信し、ほぼ全てのノードが4秒以内に検証・受理して新しいチェーンヘッドとなりました。

言い換えれば、ブロックGas使用量が2倍になっても、Ethereumが規定する4秒のバリデーター提出締切前にブロックはネットワーク全体に伝播できます。これらのストレステストでは、開発者は提案ノードのブロック生成が定時か、全ノードの新ブロック受信所要時間分布などの重要データを監視し、明らかな異常は見られませんでした。

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

総合的に見て、各種テストと調整により、コアチームはメインネットのGas Limitを3,000万から6,000万に引き上げるリスクを十分に把握し、自信を深めました。大多数のバリデーターが支持を表明した後（約15万以上のバリデーターノードが引き上げに賛成票を投じた）、Ethereumは2025年にメインネットのGas上限引き上げに着手し、今後のアップグレードでデフォルト値を正式に60Mに調整する計画です。

今後の展望：さらなる引き上げには何が必要か？

Ethereumコミュニティは60M Gasで満足するつもりはありません。Fusakaなどの今後のアップグレード計画では、開発者はブロックGas上限を100Mやそれ以上に引き上げる道筋を描いています。この目標を実現するには、なおいくつかの技術的課題を解決または継続的に注視する必要があります：

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

今後、上記の改良が同時に進めば、EthereumメインネットのさらなるGas上限引き上げは決して遠い目標ではありません。開発者はすでにテストネットで36Mから45M、60Mへの引き上げの実現可能性を検証しており、次は100Mへの前進も計画中です。強調すべきは、Ethereumコミュニティはスケーリングにおいて一貫して慎重な姿勢を保っていることです。各引き上げは「まずテスト、次にメインネット」であり、ネットワークの安全性や分散性を損なわないことを確認した上で実施されます。

総じて、過去1年間のGas Limit大幅引き上げは、プロトコルレイヤーのリスク低減、クライアントのパフォーマンス向上、テストデータによる信頼性確保など、複数分野の協調的なイノベーションの成果です。これらの取り組みに支えられ、EthereumはL1スケーリングの重要な一歩を踏み出し、今後さらに容量を拡大し、より多くのアプリケーションを支える基盤を築きました。

参考文献