ヴィタリック・ブテリン氏が共同執筆した提案「EIP-8141」が、次期イーサリアム(Ethereum)(ETH)の「Hegotá(ヘゴタ)」アップグレード候補として正式にスケジュール入りした。
同提案は、1件のトランザクションを最大64個のプログラマブルな「フレーム」(コントラクトコールの連なり)に分解できるようにするのが特徴だ。
注目ポイント
- EIP-8141は、従来の「固定フォーマットのトランザクション」を廃し、検証・ガス支払い・実行を担う最大64件のコントラクトコール列へと再設計する。
- この提案は、FOCILと並んでHegotáの候補項目に組み込まれたが、Sepolia、Hoodi、メインネットのアクティベーション日は未定のままだ。
- フレーム設計は、量子コンピューターが楕円曲線暗号を破るリスクに備えた「出口戦略」と位置づけられている。
EIP-8141フレーム、Hegotáスケジュール入り
提案の共同著者の一人であるイーサリアム開発者 Derek Chiang 氏は9月6日、EIP-8141を巡る議論が「設計面でのブレークスルー」に到達したとXで報告した。
コア開発者の Matt Garnett 氏は、その前日に補足エッセイを公開。続いてブテリン氏自身も、トランザクションの「やるべき処理」と「満たすべき条件」を切り離して設計する意義について独自の考えを示した。
現行のドラフトでは、各トランザクションを通常のコントラクトコールの列に分解し、それぞれを「検証」「ガス承認」「実行」の3モードで動作させる構成になっている。
さらに複数フレームを「アトミックなバッチ」に束ねることができ、トークン承認とスワップがセットになった取引が途中で失敗した場合でも、アカウント側で一括巻き戻しが行われる。この仕組みにより、片方だけが実行されて資産が取り残されるリスクを抑制できる。
関連記事: OpenAI、GPT-6 Astraを「史上最高性能」と宣伝もテスターは懐疑的
Derek Chiang 氏と Matt Garnett 氏が語るフレーム設計の狙い
Garnett 氏(ハンドルネーム「lightclient」)は自身のブログで、フレーム型トランザクションは「アカウントに必要な最後のトランザクション形式になるべきだ」と主張し、その理由として鍵ローテーションとポスト量子暗号への対応を挙げた。
量子耐性のある署名スキームは、1署名あたり数キロバイト規模に膨らむケースが多く、そのデータ量がネットワークに負荷をかける。結果として、署名をどう集約・圧縮するかが重要になってくる。
一方でChiang氏は、より実務的な観点から「調整コスト」の削減を前面に押し出した。
同氏によれば、イーサリアムの大型アップグレードは概ね9カ月ごとに行われているが、そのたびにトランザクションコンテナの仕様を作り変えるのは、ウォレットやブロックエクスプローラー、署名デバイス、レイヤー2(L2)などのエコシステムにとって時間もコストも重い負担になる。
外部試算では、EIP-8141導入後のトランザクションオーバーヘッドは「1トランザクションあたり約1万2000ガス+フレームごとに475ガス」と見積もられている。
これは現在の単純送金(約2万1000ガス)と比較するとベースコストが増える一方で、柔軟性の高いアカウント抽象化をプロトコルレベルで取り込む「対価」と位置づけられる。
ウォレット側としては、各フレーム単位で個別にガスを見積もる必要が出てくる。ただし仕様上のデフォルトコードにより、「スポンサーガス」(第三者によるガス負担)やトークン建て手数料、バッチ化されたコールといった機能が、コントラクトをデプロイしていないシンプルなウォレットにも拡張される想定だ。
フレーム以前のイーサリアム・アカウント抽象化の歩み
Hegotáに関するメタドキュメントでは、現在、フレームトランザクションとFOCILの2件のみが予定変更案としてリストアップされている。
これは、以前の検討段階から一歩進んだ形だが、Sepolia、Hoodi、メインネットのアクティベーション欄はいずれも空欄のままで、具体実装にはなお調整の余地がある。
併せて開発者コミュニティでは、フレーム設計をEIP-8130(トランザクションが事前に認証方式を宣言するキーストア設計)とどう組み合わせるかについても議論が進んでいる。
イーサリアムのアカウントを「プログラム可能」にしようとする試みは、プロトコル内の仕様提案からアプリケーションレベルの標準、代替メンプール設計まで、10年以上にわたって続いてきた。
- EIP-2938は、ガス支払い前にトランザクションが任意コードを実行できるようにする構想だった。
- ERC-4337は、トランザクションライフサイクル全体をプロトコル外へ切り出し、バンドラーが管理する専用メンプール上で処理する方式を取った。
- EIP-7702は、通常のアカウントが一時的にコントラクトコードを「借りる」ことで柔軟性を高めようとした。
Garnett 氏は2025年末、EIP-7701の自身の実装を公開したが、従来案は既存クライアントが扱うトランザクション種別との整合性が低いと判断し、路線転換を図っている。





