2026年のイーサリアムでの構築：何が変わったのか

ガス代

アカウント抽象化

プロトコル・アップグレード

フィリップ・クラウス

EF Builder Growth

2026年5月7日

19 分で読めます

あなたのイーサリアムのメンタルモデルが2021年から2023年に形成されたものなら、それはすでに時代遅れです。それ以降に行われた3つのプロトコル・アップグレード（2024年3月のデンクン、2025年5月のペクトラ、2025年12月のフサカ）は、ビルダーが気にする2つのこと、すなわちレイヤー1 (L1) の利用コストと通常のウォレットでできることを変えました。

メインネットは再び安価に

2021年から2023年の手数料体系は、もはや安全なデフォルトの前提ではありません。

2026年5月5日現在、Etherscanのガストラッカーによると、標準的なガスは約0.15 Gweiであり、4月の1日あたりの平均は0.5 Gwei近くでした。この水準では、基本的なETHの送金コストは1セント未満であり、最近の典型的な日では1桁台前半のセントに収まっています。この傾向は最近の各アップグレードを通じて低下しており、次のグラムステルダムでは手数料がさらに下がることが見込まれています。そのため、「イーサリアム・メインネットはほとんどのアプリにとって高すぎる」という考えは、もはや古い出発点となっています。

シンプルな経験則が必要な場合は、古い言い伝えではなくガスの計算を使用してください。4月の最近の平均である0.5 Gwei、ETHが約2,350ドルの場合、例示的なコストは以下のようになります。

操作	使用ガス	例示的なコスト
ETH送金	21,000	$0.025
ERC-20送金	~65,000	$0.076
ERC-20承認	~46,000	$0.054
スワップ	~180,000	$0.21
ERC-20デプロイ	~1,200,000	$1.41

これらはあくまで例であり、保証するものではありません。コストはETH価格、ガス価格、およびコントラクトの複雑さによって変動します。現在、ロールアップがイーサリアムのトランザクションの約95%を処理しており、L1は通常ブロックの目標値を大きく下回って稼働しているため、通常の1ヶ月の間でもGweiの数値は大きく変動する可能性がありますが、ドル換算のコストはほとんど変わりません。メインネットの手数料は現在十分に低くなっており、多くのアプリがメインネット上で合理的に稼働できるようになっています。

コストが下がった理由

3つのアップグレードがその大部分の役割を果たしました。

デンクン（2024年3月）はEIP-4844を導入し、ブロブを通じてロールアップに独自のデータレーンを提供し、独立した手数料市場を設けました。これにより、ロールアップは同じブロックスペースで通常の実行トラフィックと競合することがなくなりました。

ペクトラは2025年5月7日に有効化されました。EIP-7691により、ブロックあたりのブロブのスループットが目標3個/最大6個から目標6個/最大9個に引き上げられました。これにより、ロールアップが使用する安価なデータレーンが拡張され、レイヤー2 (L2) の手数料がさらに低下しました。

フサカは2025年12月3日に有効化されました。その目玉となる容量変更はPeerDASでした。これにより、バリデーターはすべてのブロブを完全にダウンロードするのではなく、ブロブデータをサンプリングできるようになり、このサンプリングによってネットワーク層でより多くのブロブ数を安全に処理できるようになりました。並行して、コミュニティは2025年中にL1のガス・リミットを3,000万から6,000万に引き上げ、フサカのEIP-7935によって6,000万が新しいデフォルトとして標準化されました。EIP-7825は、単一のトランザクションを約1,678万ガスに制限します。ほとんどのアプリがこれに気づくことはありませんが、非常に大規模なデプロイやモノリシックなマルチコールは、この制限内に収める必要があります。また、EIP-7951はメインネットにネイティブのsecp256r1 (P-256) 検証を追加し、アカウントフローにおいてパスキーやWebAuthnの署名をはるかに安価に検証できるようにしました。

その結果、メインネットはもはや恒常的に混雑しているチェーンのような価格設定ではなくなりました。

EIP-7702がアカウントモデルをどのように変えるか

ペクトラではEIP-7702も導入されました。これにより、ユーザーを新しいアカウントに移行させることなく、通常のウォレットがバッチ処理、ガス代のスポンサーシップ、セッションキー、リカバリーフロー、パスキーに優しいUXなどのスマート・アカウントの機能にアクセスできるようになります。

これは、EOA（外部所有アカウント）がすでにデプロイされたコントラクトコードへのポインターを設定できるようにする新しいトランザクションタイプ（タイプ0x04、SetCode）を追加することで機能します。ユーザーは同じアドレスを保持し、元のEOAの鍵がアカウントの最終的な制御権を維持します。また、委任は後で変更したり、nullアドレスにリセットしたりすることができます。

アプリのビルダーにとっての実践的な変更点は、低レベルのEIP-7702のセットアップではなく、ウォレットに結果を要求することです。ユーザーが1つのフローで承認してスワップする必要がある場合は、ERC-5792のwallet_sendCallsを通じてバッチ処理をリクエストします。ウォレットは、EIP-7702、ERC-4337、または別のアカウントシステムのどれを使用するかを決定できます。

委任されたコードはセキュリティの境界となります。ウォレットがEOAをバグのあるコードや悪意のあるコードに向けると、そのコードはトークンの承認、送金、アプリとのやり取りなど、ユーザーとして呼び出しを行うことができます。ビルダーは委任先をウォレットのインフラストラクチャのように扱い、ウォレットが検証した実装に依存するべきであり、ユーザーにアプリが制御するコードへの委任を安易に求めるべきではありません。

これにより構築方法がどう変わるか

以前は、ビルダーのデフォルトの疑問は「どのL2が十分に安いか？」でした。その疑問にはまだ答えがありますが、それだけではありません。通常の負荷時におけるL1の手数料が1トランザクションあたり数セントの範囲になり、EIP-7702によってアドレスを移行することなくどのウォレットでもスマート・アカウントのUXを提供できるようになった現在、より有用なデフォルトの疑問は、アプリをメインネット上に置くべきか、それとも特定のL2がL1にはない真の流通、流動性、またはUXの利点を提供するかどうかです。

アカウントの前提も変わります。すべてのユーザーアカウントが、何か有用なことをする前にETHを保持していなければならない単なるECDSAのEOAであるかのように、新しいアプリを設計しないでください。ERC-5792のwallet_sendCallsのようなウォレットレベルのバッチ処理インターフェースを優先し、ガス代のスポンサーシップやセッションキーが通常のウォレット機能になると想定し、パスキーやリカバリーフローを個別のオンボーディングのハックとしてではなく、アカウントのUXサーフェスの一部として扱ってください。

次の展開

イーサリアムの次の名前付きアップグレードはグラムステルダムであり、ブロックレベルのアクセスリスト（BAL）とプロトコルに組み込まれたプロポーザー・ビルダー分離 (ePBS) が目玉項目となっています。これらを組み合わせることで、ブロックのガス・リミットを現在の6,000万から約2億へと安全に引き上げることができ、ビルダーが利用できるL1の容量がさらに増えます。有効化は2026年後半に予定されています。グラムステルダムの後にはHegotá (opens in a new tab)が続く予定であり、フォーク選択によって強制されるインクルージョンリスト（FOCIL）がその目玉機能として選ばれています。

ビルダーにとって追跡する価値がある項目は、L1容量の増加（BAL）、より信頼性の高いトランザクションのインクルージョン（FOCIL）、そしてネイティブなアカウント抽象化への道筋です。グラムステルダムのもう1つの目玉であるePBSは、主にL1トランザクションのインクルージョンにおける信頼の依存関係を排除するインフラストラクチャの変更です。アプリレベルでの直接的な表面上の変化はわずかです。

BALは、利用が増加してもL1を安価に保つためのものです。簡単に言えば、ブロックにはそれがアクセスするアカウントとストレージのマップが付属するようになります。クライアントはそのマップを使用してデータをプリフェッチし、独立したトランザクションを並行して実行できるため、ブロックの検証が遅くなりすぎることなく、L1のガス・リミットを安全に引き上げることができます。ビルダーにとっての実践的な効果は、2021年から2023年のガス体制を自動的に再現することなく、より多くのアクティビティがメインネットに戻ってくる可能性があるということです。

FOCILは、あるブロック生成者が有効なトランザクションを除外したいと考えている場合でも、それらをブロックに含めるためのものです。現在、ブロックを構築する当事者がトランザクションを無視した場合、プロトコルの他の部分がそれを強制的に含める方法は限られています。EIP-7805により、複数のバリデーターが事実上「パブリックなメンプールで待機しているこれらの有効なトランザクションを確認した」と宣言するようになります。そのため、次のブロックはそれらを含める必要があり、そうでない場合、バリデーターはそのブロックの支持を拒否できます。ビルダーにとって、これはプライバシー・ツール、規制されたオンランプ、または一部のインフラストラクチャ・プロバイダーによってフィルタリングされる可能性のあるユーザーにサービスを提供するアプリなど、L1への信頼性の高いアクセスが製品の一部である場合に重要になります。

アプリのビルダーにとって、Hegotáで最も注目すべき項目はアカウント抽象化です。EIP-8141（フレーム・トランザクション）は、検証、実行、およびガス代の支払いがフレームに分割されるトランザクションタイプを追加します。実際には、これはスマート・アカウントがトランザクション自体を検証し、独自の署名ルールを定義し、誰がガス代を支払うかを承認し、ERC-4337のEntryPoint、バンドラー、またはアプリが実行するリレイヤーに依存することなく、1つ以上のアクションを実行できることを意味します。

これにより、製品の前提が変わります。ガス代のスポンサーシップは、すべてのアプリが個別に手配しなければならないインフラストラクチャではなく、ネイティブなアカウントパターンになります。現在のパスキーや、ポスト量子暗号への移行が必要になった場合のECDSAからの脱却など、代替の署名スキームのサポートが容易になります。EIP-8141または同様のネイティブなアカウント抽象化の設計が実現した場合、ビルダーのモデルは「EOAがトランザクションに署名する」から「アカウントがトランザクションの検証、支払い、および実行方法を定義する」へと移行します。

これは方向性であり、約束されたものではありません。EIP-8141はドラフト段階であり、2026年5月時点ではHegotáへの「インクルージョンが検討されている」に過ぎません。つまり、クライアントチームは議論を行っていますが、そのアップグレードでの導入を確約しているわけではありません。アカウントUXのための2026年の実践的な構築パスは依然としてEIP-7702とERC-4337のウォレットフローですが、ビルダーはプログラマブルなアカウントがデフォルトのアカウントモデルになりつつあるかのように設計するべきです。

今、構築方法をどう変えるべきか

まず、古い手数料の前提を再確認することから始めましょう。デプロイのプレイブックが依然としてイーサリアム・メインネットをデフォルトで10〜30 Gweiの環境として扱っている場合、おそらくL1から多くの作業を遠ざけすぎているでしょう。アプリが共有の流動性、既存のプロトコルとのコンポーザビリティ、中立性、またはイーサリアムのセキュリティと社会的コンセンサスが最も強い場所に置くべき価値の高い状態に依存している場合、メインネットを最初に検討する価値があります。

流通、非常に高いトランザクション量、アプリ固有のエコシステム、または可能な限りゼロに近いアクションごとのコストなど、依然として重要である理由のためにL2を使用してください。重要なのは「すべてをメインネットで」ということではありません。重要なのは、「メインネットは高すぎる」ということがもはや最初のフィルターになるべきではないということです。

アカウント側では、生のEOAではなくウォレットの機能に合わせて構築してください。フロントエンドは、ウォレットを通じて提供されるバッチ呼び出し、スポンサー付きガス、セッションキー、パスキー、およびリカバリーフローに対応できるように準備しておく必要があります。現在、EIP-7702とERC-4337が実践的なツールです。ネイティブなアカウント抽象化は、次に追跡すべき方向性です。

イーサリアム・メインネットを最後に触れるだけの高価なセトルメント層として扱うのをやめ、ユーザーアカウントを何かをする前にETHを保持していなければならない静的なECDSAの鍵として扱うのをやめてください。2026年のイーサリアムは、より安価なL1実行とプログラマブルなアカウントへと向かっています。その世界に向けて構築してください。

参考文献

ページの最終更新: 2026年5月28日