Ethereum、「ETHを保有せずに」取引可能にするEIP-8141をHegotá向けに実装・検証へ
2026年9月10日 23:34
Ethereumのコア開発者は2026年8月27日、ETHを保有しない利用者でも取引できるようにするEIP-8141「Frame Transactions」を、将来のHegotáアップグレードに向けて実装・検証する段階へ進めた。これはメインネットでの提供決定や提供日を意味するものではなく、Hegotáは2027年が目標とされ、仕様もなおドラフトである。ウォレット、アプリ、ノード運営者は、テストネット、仕様の確定、ネイティブ対応の進展を見極める必要がある。
■EIP-8141がETH保有の前提を切り離す仕組み
Ethereumのコア開発者は2026年8月27日、利用者がETHを一度も保有せずにネットワーク上で取引できるようにするプロトコル変更の開発を正式に進める方針を固めた。提案名はEIP-8141、通称「Frame Transactions」である。同日のAll Core Developers Execution（ACDE）会合で、Hegotáネットワークアップグレードに向けた「採用検討中」（CFI：Considered for Inclusion）から「採用予定」（SFI：Scheduled for Inclusion）へと位置付けが引き上げられた。これはEthereumのクライアント開発チームが、この機能の実装とテストに取り組むことを約束した正式な節目である。開発者のnixo.ethも会合直後、XでSFIへの移行を確認した。Hegotáの全提案に関する開発者の選好表明期限は9月10日である。
現在のEthereumトランザクションは、署名済みの単一メッセージとして、送信者の本人確認、実行する操作の指定、ETH建てガス料金の差し引きを同時に担う。この3機能が一つのオブジェクトに束ねられているため、利用者は何をする場合でも、実際に保有する資産がUSDCなどのステーブルコインであっても、まずウォレット内にETHを必要とする。EIP-8141の動機説明では、この依存関係が示されている。
EIP-8141はこの束ね方を改め、トランザクションをそれぞれ独立したコントラクト呼び出しである複数の「フレーム」に分解する。Ethereumの型レジストリにおける技術的なトランザクション型は0x06で、ペイロードにはチェーンID、ノンス、送信者アドレス、署名、手数料パラメーターとともにフレームのリストが含まれる。
各ステップの動作は3種類のフレームモードで規定される。VERIFYフレームは静的呼び出しとして実行され、新しいEVM命令APPROVE（オペコード0xaa）を除き、ブロックチェーンの状態を変更できない。この命令で取引の支払者を指定する。SENDERフレームはアカウント所有者として実行され、価値の移転やコントラクト呼び出しを行える。DEFAULTフレームは中立的なエントリーポイントアドレスから実行される。
VERIFYモードのAPPROVE_PAYMENTによる手数料支払いの承認と、別フレームのAPPROVE_EXECUTIONによる本人確認の承認を分離することで、ガス料金の支払い元は送信者のETH残高である必要がなくなる。スポンサーコントラクト、ステーブルコインのDEX、アプリの資金庫などが代わりに支払いを承認できる。バリデーターが受け取るのは従来どおりETHであり、決済の仕組みは変わらない。一方、利用者が取引のためにETHを保有しなければならないという要件はなくなる。
各フレームは、トランザクションで宣言される実行ガスと状態ガスという2つの独立したガス枠に対して動作する。これはEIP-8037で導入されたEthereumの2次元会計モデルを反映したものだ。予算はトランザクション全体で共有されず、フレームごとに割り当てられる。このため、ペイマスターフレームが後続フレームに必要な状態ガスを意図せず使い切ることはない。こうしたフレーム単位のガス分離は仕様に組み込まれている。
■最大64フレームの原子的な処理と既存アカウントへの対応
EIP-8141では、1トランザクション当たりのフレーム数をMAX_FRAMES定数により最大64に制限する。原子的に処理するバッチ内の各フレームにはATOMIC_BATCH_FLAGが付与され、バッチ内のいずれかのフレームがリバートすると、それより前のフレームもすべてリバートする。例えば、トークン移転の承認、スワップ、DeFiプロトコルへの受取資産の預け入れを1トランザクションで実行できる。スワップに失敗した場合はトークン承認も取り消され、後続の攻撃者に悪用され得る「残存した承認」を残さない。
このほか、プログラム可能な鍵ローテーションも含まれる。SENDERフレームがアカウントのストレージへ新しい署名者を書き込むことで、資金を別アドレスへ移すことなく署名権限を更新できる。また、正規または非正規のペイマスターコントラクトを通じ、アプリケーションが利用者のガス料金を直接負担するスポンサードトランザクションもネイティブにサポートする。
スマートコントラクトコードを配置していない既存のMetaMaskウォレットも、「デフォルトコード」機構を通じてFrame Transactionsを利用できる。プロトコルはコードハッシュが空のアカウントに標準のVERIFY動作を提供するため、通常の外部所有アカウント（EOA）でも、新アドレスへの移行やコントラクトのデプロイをせずにUSDCでガス料金を支払えるようになる。
■ERC-4337との違いはベースプロトコルへの組み込み
2023年3月に登場したERC-4337は、アプリケーション層でアカウント抽象化を実現し、ハードフォークなしでガス料金のスポンサー負担とトランザクションのバッチ処理を可能にした重要な技術的成果だった。ただし、そのアーキテクチャには、EIP-8141が解消しようとする構造上の依存関係がある。
ERC-4337では、ノードは信頼できる仲介者なしに、任意のEVMコードをメモリプールへの受け入れ前に検証できない。シミュレーションのコストを誰かが引き受ける必要があるためだ。そこで、ユーザー操作を収集して有効性を絞り込み、通常のEthereumトランザクションとして送信するオフチェーン事業者「バンドラー」が生まれた。バンドラーにはレピュテーションシステムが必要になり、それには別個のメモリプールが必要となる。別個のメモリプールでは、利用者はバリデーターによる取り込みではなく、バンドラーの稼働に依存する。実際には、現在のユーザー操作の多くがAlchemy、Pimlico、Biconomy、StackUpという少数のバンドラー事業者を経由しており、分散型を標榜するネットワークに中央集権的なボトルネックを作っている。
EIP-8141は、アカウント抽象化をEthereumのベースプロトコル層へ移すことでバンドラーの必要性をなくす。フレームトランザクションは、他のトランザクションと同じルールで検証され、公開メモリプールに直接入る。
■耐量子暗号への移行経路も設ける
ガス料金の改善に注目が集まりやすいが、より深いアーキテクチャ上の意義は、Ethereumに耐量子暗号への移行経路を与える点にある。現在のEthereumアカウントはすべて、楕円曲線上の離散対数問題の計算困難性に依存するECDSA（楕円曲線デジタル署名アルゴリズム）で保護されている。Shorのアルゴリズムを実行する量子コンピューターはこの問題を多項式時間で解けるため、ECDSAは完全に破られる。
米国国立標準技術研究所（NIST）は2024年8月、耐量子暗号の標準としてML-DSA（CRYSTALS-Dilithium）、ML-KEM（CRYSTALS-Kyber）、SLH-DSA（SPHINCS+）の3件を最終決定した。米国家安全保障局（NSA）とNISTは、2030年から2035年にかけて量子耐性暗号へ移行するスケジュールを示している。
Ethereumにとっての問題は、プロトコルに組み込むべき特定の耐量子アルゴリズムについて合意がないことだ。誤った方式を採用すれば、修正にはさらに別のハードフォークが必要になる。EIP-8141は、認証層をプロトコルに固定するのではなく、プログラム可能にすることでこの難題を回避する。
仕様はSECP256K1（既存のEthereum署名）、P256（ハードウェアセキュリティキーやApple Secure Enclaveで使われる標準のsecp256r1）、独自の暗号ロジック向けARBITRARYという3つの署名方式を導入する。ARBITRARY方式では、アカウントは、最終的な標準となる耐量子アルゴリズムがML-DSA、Falcon、SPHINCS+のいずれであっても、デプロイ済みVERIFYフレームのコードで実装できる。より良い耐量子アルゴリズムが標準化された場合、開発者はスマートアカウントのコードを更新すればよく、プロトコル変更は不要である。Gethクライアントチームは、公開した主要提案に関する選好メモで、この結果をEthereumの耐量子化への道筋に対する「決定的な答え」と呼んだ。
このアーキテクチャは、現時点でEthereumを量子コンピューターに対して安全にするものではない。ECDSAアカウントは依然として脆弱である。ただし、別のハードフォークを待たずに移行できる経路を作る。
■SFIは実装・検証の約束であり、提供日ではない
EIP-8141は、Hegotáで検討されている唯一のアカウント抽象化提案ではない。Baseネットワーク（CoinbaseのL2）に関係するチームも一部開発に携わったEIP-8130は、EIP-8141の新オペコードとフレーム実行モデルとは異なる「verifier sandbox」モデルにより、似た目標を目指す。ParadigmのTempo Transactionsは第3の競合する方向性だった。CryptoBriefingによると、8月27日のACDE会合時点でHegotáでは全体で約66件の提案が検討されており、選好表明の期限は9月10日に設定されている。
EIP-8141がSFIに至るまでの経緯は平坦ではなかった。2026年3月26日のACDE会合では、クライアント開発者から複雑さへの懸念が示され、提案はCFIにとどまった。Besuの開発者Daniel Lehrnerは当時、チームはこの提案を「得られるものに対して複雑すぎる」と判断したと述べた。一方、Arbitrum開発元のOffchain Labsは、アカウント抽象化を一つのカテゴリーとして幅広くコミットすべきだと主張し、これを「最も重要なユーザー体験上の選択」と呼んだ。また、利用者と企業から日々寄せられるフィードバックにも言及した。
4月22日にethereum-magicians.orgで開かれたアカウント抽象化の分科会は、主要ACDE会合とは別の専門作業セッションである。そこでは、メモリプールへの影響、既存ハードウェアウォレットの移行経路、L2間の調整要件、プログラム可能な検証ロジックに伴うDoSリスクという具体的な技術的トレードオフに議論が絞られた。開発者のParthasarathy Ramanujamは、Frame TransactionsがHegotáの主要提案に選ばれなければ、ネイティブなアカウント抽象化は実現しないかもしれないと警告した。8月27日の決定はこの議論をEIP-8141に有利な形で決着させた。nixo.ethの会合後の確認では、決め手となったコミュニティの支持は強かったとされる。
SFIは、Ethereumのコアクライアントチームが特定のフォークに向け、提案を実装・検証する正式な約束を意味する。提供日ではない。eips.ethereum.org上で仕様は依然として「Draft」とされており、最終展開までに技術的な詳細が変わる可能性がある。
■任意コードの検証に伴うDoSリスクへの対策
Frame Transactionsにおける最も重要な技術課題は、サービス拒否攻撃（DoS）への防御である。VERIFYフレームには署名検証のための任意のEVMコードを含められるため、悪意のある利用者が、初期検証時には有効に見えるものの、外部のブロックチェーン状態が変われば無効になるトランザクションを送る可能性がある。その場合、ノードは処理に計算資源を浪費させられる。
EIP-8141は、検証プレフィックス、すなわち支払者が承認される前に実行されるフレームにおいて、変更可能な状態への依存を厳格に禁じることで対処する。VERIFYフレームでは、TIMESTAMP、BLOCKHASH、COINBASE、NUMBER、PREVRANDAO、GASLIMIT、BASEFEE、BALANCE、SELFBALANCEなど、20種類超のオペコードが禁止される。ストレージの読み取りも、送信者自身のストレージスロットに制限される。検証プレフィックスのガス予算合計は、MAX_VERIFY_GASにより実行ガス10万に上限設定される。
これらの規則により、検証段階でフレームトランザクションが有効かどうかは、トランザクション自身のフィールド、送信者のノンス、送信者のコード、必要に応じて正規ペイマスターの残高だけに依存する。ノードは、この限定的で追跡可能な依存関係における変化を監視できる。公開メモリプールでは、送信者ごとに保留中のFrame Transactionを同時に最大1件だけ保持する。
バリデーター運営事業者のEverstakeは2026年4月、機能の有効化前にノード運営者がクライアントソフトウェア、メモリプールポリシー、ブロック選択ロジックを更新する必要があると指摘した。
■Hegotáは2027年目標、メインネット有効化日は未確定
期待値を適切に設定するには、アップグレードの順序におけるHegotáの位置を理解する必要がある。Hegotáは次に予定されるEthereumハードフォークではない。その位置にあるのは、より対象を絞った2026年第4四半期予定のGlamsterdamアップグレードである。HegotáはGlamsterdamの後に続き、2027年が目標とされているが、現時点でメインネット有効化日は確認されていない。
クライアントチームは2026年後半にFrame Transactionsの実装作業を開始する可能性がある。しかし、メインネットへの全面展開には、まずGlamsterdamの提供、EIP-8141実装を検証する開発ネットワーク、重大な失敗なく運用されるテストネット、主要ウォレットによるネイティブ対応が必要になる。最初の開発ネットワークであるframes-devnet-0は2026年8月中にGitHubで公開された。仕様はなおドラフトであり、技術定数とメモリプール規則は今後も変更され得る。
進捗はEthereum開発者コミュニティが管理するForkcastダッシュボード、および毎週火曜日14時UTCに実施されるアカウント抽象化分科会で追跡できる。競争上の文脈では、Starknet、zkSync、Near Protocolなどのネットワークは、開始時からアカウント抽象化をネイティブ機能として構築してきた。Ethereumが同等の機能に到達する経路はHegotáを通る。
Frame Transactionsが単に採用予定とされた段階ではなく、実際にメインネットへ近づいたと判断するには、3つの具体的な節目がある。第1に、誰でもFrame Transactionを送信し、フレームごとの状態コード、ガス内訳、支払者アドレスを含むフレームレシートを確認できる公開テストネットである。第2に、MetaMask、Coinbase Wallet、Rainbowなどの主要ウォレットが、EIP-8141のネイティブ対応を名称を明示して発表することだ。これは、利用者がスマートアカウントコントラクトを操作するのではなく、ウォレットがフレームトランザクションのペイロードを直接構築することを意味する。第3に、eips.ethereum.orgで仕様の「Draft」表記が外れることである。これは、技術定数、メモリプール規則、オペコードの意味が最終化されたとの技術コミュニティの合意を示す。
これらの節目が現れるまで、8月27日のSFI決定は、Ethereumのコアチームが機能を構築・検証するという実質的な技術上の前進ではあるが、まだ提供日ではない。
本稿は情報提供を目的とするものであり、投資または金融上の助言を構成するものではない。
元記事: Ethereum Locks In Protocol That Eliminates ETH Requirement for Gas Payments