執筆：imToken
客観的に言えば、過去しばらくの間、多くのユーザーがイーサリアムの直感的な感触を得たのは、ロードマップや開発者会議からではなく、実際のオンチェーン操作を通じてだった。
例えば、ここ2年ほど皆が実感しているのは、送金時のGasが徐々に低下し、クロスチェーンの相互運用性の体験が改善されていることなどであり、これが理由の一つだ。イーサリアムのスケーリングは単なる「性能競争」の問題ではない——一般ユーザーにとっては、より高いTPS、大きなブロック、より複雑な基盤構造は、実際にコストが下がり、操作がスムーズになり、安全なウォレット体験に変わる時にだけ意味を持つ。
そして最近のイーサリアムの一連の新動向は、まさにイーサリアムが従来、ウォレット、DApp、サードパーティリレー、ユーザー自身が負担していた複雑性を、システム的にプロトコル層に前進させようとしていることを示している。
その中には、Vitalikが関わるKeyed Nonces、Glamsterdamアップグレードにおける2億Gasリミットの方向性合意、そして2026年のロードマップで継続的に強調されるネイティブアカウント抽象化、L2間の相互運用性、L1のセキュリティ強化などの一連の伏線も含まれる。
まず、最もユーザーに感知されやすいポイント、Gasリミットから見てみよう。
周知の通り、イーサリアムネットワークでは、各取引（送金もコントラクト操作も）には一定のGasが必要であり、各ブロックのGasリミット容量は固定されている。つまり、席数には限りがある：席数が多いほど、同時に運べる乗客も多くなる；席数が少なければ、皆が同じ座席を争い、Gas代も高騰する。
理論的には、ブロックのGas上限を拡張すれば、イーサリアムメインネットの性能は大きく向上する。ただし、過去のイーサリアムはL2などのルートの発展背景もあり、この点に対して慎重だった。多くのスケーリング圧力は意図的にL2に振り分けられてきた。
イーサリアムのGas Limitの拡張曲線を見ると、2019年9月にGas Limitが800万から初めて1,000万を突破し、それから今年までの7年間で、Gas Limitは800万から6,000万に増加した。特に、2025年に本格的な加速段階に入る——2月に3000万から3600万へ、7月に4500万へ、12月のFusakaアップグレード後に6000万へと引き上げられた。
ほとんどの拡張は2025年に集中していると言える。もちろん、我々も以前述べた通り、2025年はイーサリアムの歴史において非常に重要な年であり、5月のPectraアップグレードから7ヶ月後のFusakaアップグレードは、重大なリーダーシップの調整を経ても、EFが大きなアップデートを推進できる能力を示したものであり、またイーサリアムが「年2回のハードフォーク」という加速開発リズムに正式に入ったことを示している。
Ethereum Foundationが5月2日に発表したSoldøgn Interop Recapによると、100人以上のイーサリアムコア貢献者がノルウェーのスバールバル諸島でGlamsterdamアップグレードに関する相互運用会議に参加し、主な目的はGlamsterdamのマルチクライアント実装、テスト、パラメータ調整を推進することだった。会議の終了時点で、開発者たちはGlamsterdam後の2億Gasリミットに関して方向性の合意を形成していた。
これは、今後の流れが順調に進めば、イーサリアムL1の実行容量は現状の約6000万Gasリミットからさらに引き上げられ、2億規模に達する可能性を示している。長期的に見れば、イーサリアムエコシステムのGasリミットに対する公開討議の姿勢は「かなり積極的」になっている。EIP-9698提案では、「2年ごとに10倍引き上げる」ことも提案されており、2029年にはGasリミットを36億に引き上げることが目標であり、これは現状の50倍にあたる。
ただし、Gasリミットの引き上げは単純にブロックを大きくすることではない。
もし、単に各ブロックの計算能力を乱暴に増やすだけなら、短期的にはコストを下げる可能性もあるが、長期的にはノードの負担増や状態データの膨張を招き、普通のユーザーがノードを運用しづらくなり、結果的にイーサリアムの最も核心的な分散性を弱めることになる。
したがって、Glamsterdamの拡張方針は、次のような複合的アプローチを取っている。
ePBS（enshrined Proposer-Builder Separation）により、ブロック構築と検証のプロセスをより明確にプロトコルルールに組み込み、検証者がより安全に大きなブロックを処理できるようにする；
Block-Level Access Lists（BAL）により、ブロック実行中にアクセスされるアカウントやストレージ位置を事前に記録し、並列ディスク読み取り、並列取引検証、並列状態根計算を可能にする；
EIP-8037は、状態作成に関わる操作のコストを引き上げることで、Gasリミット引き上げ後の過剰な状態増加を抑制する。
結局のところ、イーサリアムは「より多くの取引を詰め込む」だけを目指しているわけではなく、同時にノードの運用ハードルを高めずに、システムの処理能力を向上させることを追求している。
これが、多くの高性能チェーンとの根本的な違いだ。表面的なスループットを追い求めるのではなく、普通のノードも参加でき、システム全体が検証可能な範囲内で、メインネットのキャパシティを高めることを重視している。
もしGasリミットが「一つのブロックに詰められる量」の解決策だとすれば、Keyed Noncesは別の、より細かく重要な問題に焦点を当てている：一つの取引はどうやってキューに入れるのか？
周知の通り、イーサリアムにおいてnonceは、アカウントの取引の「シーケンス番号」として理解される。これの役割は、同じ取引の重複実行を防ぎ、同一アカウントからの取引を順番通りに処理させることだ。
この仕組みは、普通の送金シナリオでは理解しやすい。第一の取引、第二の取引、第三の取引と順番に並べる。
しかし、問題は、アカウントの能力がより複雑になった場合だ。例えば、プライバシー取引、スマートウォレット、セッションキー、一括操作、サードパーティの代行支払いなどが関わると、単一の線形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自身も、これを「単なるプロトコル層のプライバシー支援だけでなく、イーサリアムの新たな状態拡張戦略の第一歩」と位置付けている。彼は、Keyed Noncesは「異なるユースケースに最適化されたストレージタイプを作ることで、プロトコルの分散性を維持しつつ、極限の拡張性を実現する可能性がある」と述べている。
要するに、Gasリミットが「ブロックの大きさ」を解決するのに対し、Keyed Noncesは「状態の形状」を探るものだ——イーサリアムが将来的に担うのは、より多くの取引だけでなく、多種多様な取引を可能にすることだ。
イーサリアムエコシステムにとって、多くのプロトコルのアップグレードは遠い未来の話のように見えるかもしれないが、最終的にはウォレット体験に直結する。
なぜなら、ユーザーがイーサリアムに触れる入口は、EIPやクライアント、開発者会議ではなく、ウォレット内の送金、認証、署名、クロスチェーン、DAppとのインタラクションだからだ。つまり、プロトコル層の変化は、ウォレット側でより明確でスムーズ、安全な操作体験に翻訳されて初めて、技術的な進化がユーザー体験の向上に繋がる。
例えば、今や誰もが耳にしたことのあるアカウント抽象化は、技術的理解を深めるためではなく、将来的にユーザーがより自然にオンチェーンアカウントを使えるようにするためのものだ。近年では、バッチ取引、Gas代付、リカバリーメカニズム、多様な署名方式、セッション認証、より柔軟なセキュリティ戦略などが、徐々にウォレットの基本機能になりつつある。
同様に、Keyed Noncesも、非常に低レベルなアカウントのキューイング最適化のように見えるが、ユーザー側にとっての潜在的な影響は抽象的ではない。今日、多くのユーザーは、取引が遅延したり、キャンセルや高速化を試みたりする際に、nonceやGas、置換取引の関係性を理解していないことが多い。特に複数操作を並行して行うと、一つの失敗が後続の操作に影響を及ぼす。
これらの問題は、「ウォレットの使い勝手が悪い」や「チェーンが使いづらい」と見なされることもあるが、実際にはイーサリアムのアカウントモデルの単一線形nonceの設計に起因している。Keyed Noncesの方向性は、アカウントが一つの列に沿って順番に操作を行うのではなく、シナリオに応じて複数の並列チャネルに分割できるようにすることだ。
将来的には、普通の送金、DApp認証、プライバシー取引、バッチ取引、Gas代付などの操作は、それぞれより独立した実行空間を持ち、相互のブロックや衝突を減らすことが期待できる。
これにより、スマートウォレットの設計空間はさらに広がる。
さらに重要なのは、これらの能力は従来、ウォレットやDApp、中継サービス、ユーザーが共同で複雑性を負担してきたが、今後は一部の複雑性をプロトコル層に前進させ、より標準化された底層能力を基に、ユーザーにとってよりわかりやすいインタラクションを提供しようとしている点だ。
これが、Gas Limit、BAL、ePBS、Keyed Nonces、Frame Transactions、ネイティブアカウント抽象化、クロスL2相互運用性が、それぞれ異なる技術モジュールに見えても、実は同じ目的を果たすためのものである理由だ——それは、「分散性と安全性を犠牲にせずに、より複雑なオンチェーンシナリオを担えるイーサリアムを作る」こと。
具体的にこれらをまとめると、イーサリアムの最近の重点は次のように見える。
Gasリミットの引き上げは、メインネットの実行容量とコスト圧力の解決；
BAL、ePBS、EIP-8037は、拡張中のノード検証性と状態増加の制御；
Keyed NoncesとFrame Transactionsは、アカウントモデル、プライバシー、スマートウォレットのボトルネック解消；
ネイティブアカウント抽象化とクロスL2相互運用性は、最終的にユーザーが実感できる体験改善を指す。
これもまた、イーサリアムが新たな段階に入ったことを意味している。
過去数年、市場はL2のスケーリング、Blobのコスト削減、モジュール化のナラティブに注目してきた。ユーザーも、異なるL2間で資産を移動し、より低コストなインタラクションを求めることに慣れてきた。しかし、メインネットのGasリミットが引き続き上昇し、Glamsterdamなどのアップグレードが進み、アカウント抽象化や相互運用の方案が進化する中で、イーサリアムが答えようとしているのは、「取引をより安くする」だけでなく、「全体としてのオンチェーン体験をどう向上させるか」だ。
この過程で、ウォレットの重要性はさらに高まる。
なぜなら、ウォレットは単にイーサリアムへの入り口だけでなく、プロトコルの能力をユーザーに理解させ、使わせるためのインターフェースだからだ。今後、より複雑な底層のアップグレードほど、より明確な署名提示、理解しやすい取引経路、事前のリスク認識、よりスムーズなオンチェーンインタラクションに変換されていく必要がある。
皆さんと共に歩もう。
1.52M 人気度
12.61M 人気度
46.51K 人気度
914.7K 人気度
1.98M 人気度
イーサリアムのスケーラビリティの次のステップをどう理解すべきか？
執筆：imToken
客観的に言えば、過去しばらくの間、多くのユーザーがイーサリアムの直感的な感触を得たのは、ロードマップや開発者会議からではなく、実際のオンチェーン操作を通じてだった。
例えば、ここ2年ほど皆が実感しているのは、送金時のGasが徐々に低下し、クロスチェーンの相互運用性の体験が改善されていることなどであり、これが理由の一つだ。イーサリアムのスケーリングは単なる「性能競争」の問題ではない——一般ユーザーにとっては、より高いTPS、大きなブロック、より複雑な基盤構造は、実際にコストが下がり、操作がスムーズになり、安全なウォレット体験に変わる時にだけ意味を持つ。
そして最近のイーサリアムの一連の新動向は、まさにイーサリアムが従来、ウォレット、DApp、サードパーティリレー、ユーザー自身が負担していた複雑性を、システム的にプロトコル層に前進させようとしていることを示している。
その中には、Vitalikが関わるKeyed Nonces、Glamsterdamアップグレードにおける2億Gasリミットの方向性合意、そして2026年のロードマップで継続的に強調されるネイティブアカウント抽象化、L2間の相互運用性、L1のセキュリティ強化などの一連の伏線も含まれる。
一、Gasリミットを2億に引き上げる？
まず、最もユーザーに感知されやすいポイント、Gasリミットから見てみよう。
周知の通り、イーサリアムネットワークでは、各取引（送金もコントラクト操作も）には一定のGasが必要であり、各ブロックのGasリミット容量は固定されている。つまり、席数には限りがある：席数が多いほど、同時に運べる乗客も多くなる；席数が少なければ、皆が同じ座席を争い、Gas代も高騰する。
理論的には、ブロックのGas上限を拡張すれば、イーサリアムメインネットの性能は大きく向上する。ただし、過去のイーサリアムはL2などのルートの発展背景もあり、この点に対して慎重だった。多くのスケーリング圧力は意図的にL2に振り分けられてきた。
イーサリアムのGas Limitの拡張曲線を見ると、2019年9月にGas Limitが800万から初めて1,000万を突破し、それから今年までの7年間で、Gas Limitは800万から6,000万に増加した。特に、2025年に本格的な加速段階に入る——2月に3000万から3600万へ、7月に4500万へ、12月のFusakaアップグレード後に6000万へと引き上げられた。
ほとんどの拡張は2025年に集中していると言える。もちろん、我々も以前述べた通り、2025年はイーサリアムの歴史において非常に重要な年であり、5月のPectraアップグレードから7ヶ月後のFusakaアップグレードは、重大なリーダーシップの調整を経ても、EFが大きなアップデートを推進できる能力を示したものであり、またイーサリアムが「年2回のハードフォーク」という加速開発リズムに正式に入ったことを示している。
Ethereum Foundationが5月2日に発表したSoldøgn Interop Recapによると、100人以上のイーサリアムコア貢献者がノルウェーのスバールバル諸島でGlamsterdamアップグレードに関する相互運用会議に参加し、主な目的はGlamsterdamのマルチクライアント実装、テスト、パラメータ調整を推進することだった。会議の終了時点で、開発者たちはGlamsterdam後の2億Gasリミットに関して方向性の合意を形成していた。
これは、今後の流れが順調に進めば、イーサリアムL1の実行容量は現状の約6000万Gasリミットからさらに引き上げられ、2億規模に達する可能性を示している。長期的に見れば、イーサリアムエコシステムのGasリミットに対する公開討議の姿勢は「かなり積極的」になっている。EIP-9698提案では、「2年ごとに10倍引き上げる」ことも提案されており、2029年にはGasリミットを36億に引き上げることが目標であり、これは現状の50倍にあたる。
ただし、Gasリミットの引き上げは単純にブロックを大きくすることではない。
もし、単に各ブロックの計算能力を乱暴に増やすだけなら、短期的にはコストを下げる可能性もあるが、長期的にはノードの負担増や状態データの膨張を招き、普通のユーザーがノードを運用しづらくなり、結果的にイーサリアムの最も核心的な分散性を弱めることになる。
したがって、Glamsterdamの拡張方針は、次のような複合的アプローチを取っている。
ePBS（enshrined Proposer-Builder Separation）により、ブロック構築と検証のプロセスをより明確にプロトコルルールに組み込み、検証者がより安全に大きなブロックを処理できるようにする；
Block-Level Access Lists（BAL）により、ブロック実行中にアクセスされるアカウントやストレージ位置を事前に記録し、並列ディスク読み取り、並列取引検証、並列状態根計算を可能にする；
EIP-8037は、状態作成に関わる操作のコストを引き上げることで、Gasリミット引き上げ後の過剰な状態増加を抑制する。
結局のところ、イーサリアムは「より多くの取引を詰め込む」だけを目指しているわけではなく、同時にノードの運用ハードルを高めずに、システムの処理能力を向上させることを追求している。
これが、多くの高性能チェーンとの根本的な違いだ。表面的なスループットを追い求めるのではなく、普通のノードも参加でき、システム全体が検証可能な範囲内で、メインネットのキャパシティを高めることを重視している。
二、Keyed Nonces：一つの「列」から「複数のチャネル」へ
もしGasリミットが「一つのブロックに詰められる量」の解決策だとすれば、Keyed Noncesは別の、より細かく重要な問題に焦点を当てている：一つの取引はどうやってキューに入れるのか？
周知の通り、イーサリアムにおいてnonceは、アカウントの取引の「シーケンス番号」として理解される。これの役割は、同じ取引の重複実行を防ぎ、同一アカウントからの取引を順番通りに処理させることだ。
この仕組みは、普通の送金シナリオでは理解しやすい。第一の取引、第二の取引、第三の取引と順番に並べる。
しかし、問題は、アカウントの能力がより複雑になった場合だ。例えば、プライバシー取引、スマートウォレット、セッションキー、一括操作、サードパーティの代行支払いなどが関わると、単一の線形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自身も、これを「単なるプロトコル層のプライバシー支援だけでなく、イーサリアムの新たな状態拡張戦略の第一歩」と位置付けている。彼は、Keyed Noncesは「異なるユースケースに最適化されたストレージタイプを作ることで、プロトコルの分散性を維持しつつ、極限の拡張性を実現する可能性がある」と述べている。
要するに、Gasリミットが「ブロックの大きさ」を解決するのに対し、Keyed Noncesは「状態の形状」を探るものだ——イーサリアムが将来的に担うのは、より多くの取引だけでなく、多種多様な取引を可能にすることだ。
三、これが普通のユーザーにどう影響するのか？
イーサリアムエコシステムにとって、多くのプロトコルのアップグレードは遠い未来の話のように見えるかもしれないが、最終的にはウォレット体験に直結する。
なぜなら、ユーザーがイーサリアムに触れる入口は、EIPやクライアント、開発者会議ではなく、ウォレット内の送金、認証、署名、クロスチェーン、DAppとのインタラクションだからだ。つまり、プロトコル層の変化は、ウォレット側でより明確でスムーズ、安全な操作体験に翻訳されて初めて、技術的な進化がユーザー体験の向上に繋がる。
例えば、今や誰もが耳にしたことのあるアカウント抽象化は、技術的理解を深めるためではなく、将来的にユーザーがより自然にオンチェーンアカウントを使えるようにするためのものだ。近年では、バッチ取引、Gas代付、リカバリーメカニズム、多様な署名方式、セッション認証、より柔軟なセキュリティ戦略などが、徐々にウォレットの基本機能になりつつある。
同様に、Keyed Noncesも、非常に低レベルなアカウントのキューイング最適化のように見えるが、ユーザー側にとっての潜在的な影響は抽象的ではない。今日、多くのユーザーは、取引が遅延したり、キャンセルや高速化を試みたりする際に、nonceやGas、置換取引の関係性を理解していないことが多い。特に複数操作を並行して行うと、一つの失敗が後続の操作に影響を及ぼす。
これらの問題は、「ウォレットの使い勝手が悪い」や「チェーンが使いづらい」と見なされることもあるが、実際にはイーサリアムのアカウントモデルの単一線形nonceの設計に起因している。Keyed Noncesの方向性は、アカウントが一つの列に沿って順番に操作を行うのではなく、シナリオに応じて複数の並列チャネルに分割できるようにすることだ。
将来的には、普通の送金、DApp認証、プライバシー取引、バッチ取引、Gas代付などの操作は、それぞれより独立した実行空間を持ち、相互のブロックや衝突を減らすことが期待できる。
これにより、スマートウォレットの設計空間はさらに広がる。
さらに重要なのは、これらの能力は従来、ウォレットやDApp、中継サービス、ユーザーが共同で複雑性を負担してきたが、今後は一部の複雑性をプロトコル層に前進させ、より標準化された底層能力を基に、ユーザーにとってよりわかりやすいインタラクションを提供しようとしている点だ。
これが、Gas Limit、BAL、ePBS、Keyed Nonces、Frame Transactions、ネイティブアカウント抽象化、クロスL2相互運用性が、それぞれ異なる技術モジュールに見えても、実は同じ目的を果たすためのものである理由だ——それは、「分散性と安全性を犠牲にせずに、より複雑なオンチェーンシナリオを担えるイーサリアムを作る」こと。
具体的にこれらをまとめると、イーサリアムの最近の重点は次のように見える。
Gasリミットの引き上げは、メインネットの実行容量とコスト圧力の解決；
BAL、ePBS、EIP-8037は、拡張中のノード検証性と状態増加の制御；
Keyed NoncesとFrame Transactionsは、アカウントモデル、プライバシー、スマートウォレットのボトルネック解消；
ネイティブアカウント抽象化とクロスL2相互運用性は、最終的にユーザーが実感できる体験改善を指す。
これもまた、イーサリアムが新たな段階に入ったことを意味している。
過去数年、市場はL2のスケーリング、Blobのコスト削減、モジュール化のナラティブに注目してきた。ユーザーも、異なるL2間で資産を移動し、より低コストなインタラクションを求めることに慣れてきた。しかし、メインネットのGasリミットが引き続き上昇し、Glamsterdamなどのアップグレードが進み、アカウント抽象化や相互運用の方案が進化する中で、イーサリアムが答えようとしているのは、「取引をより安くする」だけでなく、「全体としてのオンチェーン体験をどう向上させるか」だ。
この過程で、ウォレットの重要性はさらに高まる。
なぜなら、ウォレットは単にイーサリアムへの入り口だけでなく、プロトコルの能力をユーザーに理解させ、使わせるためのインターフェースだからだ。今後、より複雑な底層のアップグレードほど、より明確な署名提示、理解しやすい取引経路、事前のリスク認識、よりスムーズなオンチェーンインタラクションに変換されていく必要がある。
皆さんと共に歩もう。