从 Gas Limit 到「Keyed Nonces」，如何理解以太坊可扩展性的下一站？
客観的に見ると、最近、多くのユーザーがイーサリアムに対して抱く直感的な印象は、ロードマップや開発者会議からではなく、個々のオンチェーン操作から生じていることが多い。
例えば、ここ数年誰もが実感している送金時のガス代の低下や、クロスチェーン相互運用性の体験改善などがそれだ。だからこそ、イーサリアムのスケーリングは単なる「パフォーマンス競争」の問題ではない――一般ユーザーにとって、より高いTPS、より大きなブロック、より複雑な基盤アーキテクチャは、それが実際に低コストでスムーズな操作、そして安全なウォレット体験へと変換されて初めて意味を持つ。
そして最近のイーサリアムに関する一連の新しい動きは、まさにイーサリアムが、これまでウォレット、DApp、サードパーティの中継器、そしてユーザー自身が負担していた複雑性を、システム的にプロトコル層へと移行させようとしていることを示している。
その中には、Vitalik が関与する Keyed Nonces、Glamsterdam アップグレードにおける 2 億 Gas Limit floor を巡って形成された方向性のコンセンサス、そして 2026 年のロードマップで引き続き強調されているネイティブアカウント抽象化、クロス L2 相互運用性、L1 のセキュリティ強化といった、一連の伏線が含まれている。
一、Gas Limit は 2 億に？
まず、ユーザーが最も認識しやすい点、Gas Limit から見ていこう。
周知の通り、イーサリアムネットワークでは、各トランザクション（送金であれコントラクトとの相互作用であれ）は一定量の Gas を消費する必要があり、各イーサリアムブロックの Gas Limit 容量は固定されている。つまり、席数には限りがあるのだ：席数が多ければ、同じ時間により多くの乗客を運べる；席が窮屈であれば、誰もが同じ席を巡って競り合わなければならず、ガス代も高騰する。
理論的には、ブロック Gas 上限の拡大は確かにイーサリアムメインネットのパフォーマンスを直接大幅に向上させる。しかし、過去イーサリアムは L2 などのロードマップが大いに発展する中で、これに対しては常に慎重かつ抑制的であり、ほとんどのスケーリング圧力は意図的に L2 というレースへと押しやられてきた。
イーサリアムの Gas Limit の拡大曲線を見てみると、2019 年 9 月にイーサリアムネットワークの Gas Limit が 800 万から初めて 1000 万を突破してから、今年に至るまで、7 年間で Gas Limit は 800 万から 6000 万になったに過ぎない。特に 2025 年になってようやく加速レーンに入った――2 月に 3000 万から 3600 万、7 月にさらに 4500 万へ、そして 12 月の Fusaka アップグレード後には 6000 万へと引き上げられた。
スケーリングの大部分が 2025 年のこの一年間に詰め込まれたと言っても過言ではない。もちろん、以前にも触れたように、2025年はイーサリアム開発史上極めて重要な年でもあり、Pectra アップグレードからわずか 7 ヶ月後に行われた Fusaka アップグレードは、大規模なリーダーシップ再編を経た EF が依然として重要なアップデートを推進できることを証明し、イーサリアムが正式に「年 2 回のハードフォーク」という加速的な開発リズムに入ったことを示している（関連記事『イーサリアム 2026：EF 最新プロトコルロードマップの解釈、正式に「エンジニアリングアップグレード」時代へ？』）。
出典：Etherscan
Ethereum Foundation が 5 月 2 日に公開した Soldøgn Interop Recap によると、100 人以上のイーサリアムコアコントリビューターがノルウェーのスヴァールバル諸島に集まり、Glamsterdam アップグレードを中心とした相互運用性会議に参加した。主な目標は Glamsterdam のマルチクライアント実装、テスト、パラメータ調整を推進することで、会議終了時には開発者は Glamsterdam 後の 2 億 Gas Limit に関する方向性のコンセンサスを形成していた。
これは、今後のプロセスが順調に進めば、イーサリアム L1 の実行容量が現在の約 6000 万 Gas Limit から、さらに 2 億レベルに引き上げられる可能性があることを意味する。より長い時間軸で見ると、イーサリアムエコシステムの Gas Limit に対する公の議論可能な姿勢は明らかに「積極的」になっており、EIP-9698 提案では「2 年ごとに 10 倍に引き上げる」ことさえ提案されており、2029 年までに Gas Limit を 36 億、つまり現在の 50 倍にまで引き上げることを目指している。
しかしここで強調すべきは、Gas Limit の引き上げは単にブロックを大きくすることではない、ということだ。
各ブロックが処理できる計算量を単純に乱暴に増やすだけなら、短期的には手数料を下げる可能性があるが、長期的にはノードの負担を重くし、状態データを膨張させ、一般ユーザーがノードを実行することをより困難にし、結局はイーサリアムの中核である分散化の基盤を弱体化させる。
したがって、Glamsterdam のスケーリングの考え方は、一連の複合的な施策である：
- ePBS（enshrined Proposer-Builder Separation）は、ブロック構築と検証のプロセスをより明確にプロトコルルールに組み込み、バリデーターがより安全に大きなブロックを処理できるようにする；
- Block-Level Access Lists（BAL）は、ブロック実行中にアクセスされるアカウントとストレージの場所を事前に記録し、並行ディスク読み取り、並行トランザクション検証、並行ステートルート計算をサポートする；
- そして EIP-8037 は、状態作成に関連する操作のコストを引き上げることで、Gas Limit の引き上げ後に状態が急激に増加するのを防ぐ；
つまり、イーサリアムは単に「より多くのトランザクションを詰め込みたい」だけでなく、より多くのトランザクションを詰め込みつつ、ノードの実行ハードルを高くしない方法を模索しているのだ。
これはまた、イーサリアムのスケーリングロードマップと多くの高性能チェーンのナラティブとの根本的な違いでもある。イーサリアムが常に追求してきたのは、検証コストを犠牲にして表面的なスループットを得ることではなく、一般ノードの参加可能性とシステムの検証可能性をできる限り維持しながら、メインネット自体の処理能力を高めることである。
二、Keyed Nonces：「一つの列」を「複数の通路」に
Gas Limit が「一つのブロックにどれだけ詰め込めるか」を解決するならば、Keyed Nonces が注目するのは別の、より細かいながらも重要な問題である：トランザクションはどのように順番待ちをするべきか？
周知の通り、イーサリアムにおいて nonce はアカウントのトランザクションの「通し番号」と簡単に理解でき、その役割は同一トランザクションの重複実行を防ぎ、同じアカウントから送信されるトランザクションが順番通りに処理されることを保証することである。
この仕組みは通常の送金シナリオでは非常に理解しやすい。すなわち、最初のトランザクション、2 番目のトランザクション、3 番目のトランザクションと順番に並んでいく。
しかし問題は、アカウントの機能がより複雑になり、例えばプライバシートランザクション、スマートウォレット、セッションキー、バッチ操作、サードパーティによるガス代支払いなどが関わってくると、単一の線形 nonce がボトルネックになり得るということだ。そこで EIP-8250 が提案する Keyed Nonces の核となるアイデアは、元々アカウントが一つの nonce キューしか持てなかったのを、複数の nonce ドメインを持てるように変更することである。
具体的には、EIP-8141 Frame Transaction における単一の sender nonce を、(nonce_key, nonce_seq) 構造に置き換える。ここで nonce_key == 0 は従来のアカウント nonce に対応し、非ゼロの key は独立したプロトコル管理の nonce シーケンスを選択できる。異なる key 下のトランザクションは互いに独立しており、リプレイプロテクションも互いに影響しない。
これは非常に技術的に聞こえるが、日常生活の比喩を使って理解できる：過去のアカウントは、銀行に窓口が一つしかなく、すべての用事が同じ列に並ばなければならなかったようなものだ。Keyed Nonces は、異なる用事を異なる窓口に振り分け、送金、プライバシー出金、セッション認証、バッチ実行がそれぞれ自分の通路を通れるようにするようなものだ。
これはプライバシープロトコルにとって特に重要である。なぜなら、ユーザーのオンチェーンアクティビティを特定の公開アドレスに直接結びつけることを避けるために、プライバシープロトコルは複数のユーザーに同じ共有 sender アドレスからトランザクションを発信させる可能性があるからだ。しかし、単一の nonce メカニズムの下では、あるユーザーのトランザクションがパッケージ化された後、他のユーザーのまだ待機中のトランザクションを無効にしたりブロックしたりする可能性がある。
そしてKeyed Nonces は、各支出が独自の nonce ドメイン（例えばプライバシー nullifier から派生させるなど）を選択することを可能にし、プロトコルレベルでこのような待ち行列の競合を減らす。
Vitalik 自身は、これをさらに壮大に位置づけている。彼は EIP-8250 を紹介する際に、Keyed Nonces は「プロトコルレベルのプライバシースキームに対するより強力なサポートであるだけでなく、イーサリアムの新しい状態スケーリング戦略の第一歩かもしれない――異なるユースケースに特化して最適化されたストレージタイプを作成することで、プロトコルの分散化を維持しつつ、極限のスケーラビリティを実現するものだ。」と明確に述べている。
言い換えれば、簡単に理解すると、Gas Limit が「ブロックのサイズ」を解決するのに対し、Keyed Nonces は「状態の形状」を探求している――イーサリアムが将来負うことになるのは、単により多くのトランザクションではなく、より多くの種類のトランザクションなのだ。
三、これは一般ユーザーにどのような影響を与えるか？
イーサリアムエコシステムにとって、多くのプロトコルアップグレードは一般ユーザーからは遠く感じられるが、最終的にはすべてウォレットの体験に反映される。
なぜなら、ユーザーが実際にイーサリアムに触れる入り口は、EIP やクライアント、開発者会議ではなく、ウォレット内での毎回の送金、承認、署名、クロスチェーン、DApp インタラクションだからだ。つまり、プロトコル層の変化は、ウォレット層においてより明確で、よりスムーズで、より安全な操作体験へと翻訳されて初めて、技術アップグレードからユーザー体験アップグレードへの変換が完了する。
例えば、今や誰もがよく耳にするアカウント抽象化は、ユーザーに技術用語を理解させるためではなく、ユーザーが将来より自然にオンチェーンアカウントを使用できるようにするためのものだ。近年、バッチトランザクション、ガス代肩代わり、復旧メカニズム、異なる署名方法、セッション認証、そしてより柔軟なセキュリティポリシーが、徐々にウォレットの基本機能になりつつあるのもこのためである。
同様に Keyed Nonces を例にとると、これは非常に低レベルのアカウント待ち行列メカニズムの最適化に聞こえるが、ユーザー側に置き換えると、その潜在的な影響は抽象的ではない。今日、多くのユーザーがオンチェーン操作中に、次のようなシナリオに遭遇したことがあるかもしれない：あるトランザクションがなかなか確認されず、後続のトランザクションが止まってしまう。トランザクションをキャンセルしたり加速したいが、nonce、Gas、置換トランザクションの関係が理解できない。特に複数の操作を並行して行う場合、一つの失敗ステップが後続の全プロセスに影響を与えてしまう。
一般ユーザーにとって、これらの問題は「ウォレットが使いにくい」または「チェーンが使いにくい」ように見えるが、その背後には実際にはイーサリアムのアカウントモデルにおける単一線形 nonce の設計が関係している。そして Keyed Nonces が示す方向性は、アカウントがすべての操作を一つの列で順番に実行するしかないのではなく、異なる使用シナリオに応じて複数の並行チャネルに分割できるようにすることである。
将来、通常の送金、DApp 承認、プライバシートランザクション、バッチトランザクション、ガス代肩代わりなどの操作は、理論的にはより独立した実行スペースを持ち、互いのブロックや競合の確率を減らすことができるだろう。
これは間違いなく、スマートウォレットの設計空間をさらに広げることになる。
さらに重要なのは、これまでこれらの機能は、ウォレット、DApp、中継サービス、そしてユーザーの間で複雑性を共同で負担する必要があったということだ。ユーザーは承認範囲を理解し、ガス代が妥当か判断し、自分が何に署名しているのかを知り、クロスチェーン、スワップ、ステーキング、報酬の受け取りといった複数ステップの操作で繰り返し確認する必要があった。どのステップでも理解の誤りがあれば、操作失敗や資産喪失のリスクにつながりかねない。
そして今イーサリアムが試みているのは、まさにその複雑性の一部をプロトコル層に前倒しし、ウォレットがより標準化された、よりネイティブな基盤機能に基づいて、ユーザーにより優れたインタラクションの抽象化を提供できるようにすることだ。
これこそが、Gas Limit、BAL、ePBS、Keyed Nonces、Frame Transactions
