イーサリアムフレームトランザクションとは？

EthereumやHegotáの議論で「フレームトランザクション」に初めて触れる方には、複数の連携したステップから成る1つのトランザクションとして捉えるのが最も分かりやすいイメージです。たとえば、1つのフレームが送信者を検証し、別のフレームが支払いを承認、その後のフレームがユーザーのアクションを実行するよう設計できます。本記事ではEIP-8141提案全体ではなく、この基本構造に焦点を当てて解説します。

主なポイント

• EIP-8141は新たなフレームトランザクションタイプを定義しており、現時点でトランザクションタイプ0x06が割り当てられています。

• 1つのトランザクションには最大64フレームまで含めることができ、各フレームごとに独自の実行モードとガスリミットを持ちます。

• フレームごとにトランザクション検証、ガス支払い、ユーザー実行を分離できます。

• APPROVEオペコードで実行・支払い・両方の承認を個別に行えます。

• フレーム抽象化によって、ネイティブなアカウント抽象化、アトミックバッチ処理、ガススポンサーシップ、プログラム可能な署名検証が実現します。

EIP-8141フレームトランザクションとは？

公式のEIP-8141フレームトランザクション仕様は、有効性やガス支払い方法を抽象的に定義できる新しいトランザクション形式を規定しています。EIP-8141仕様

このトランザクションのペイロードには送信者アドレス、署名、手数料、フレームリストが含まれます。各フレームは自身のモード、フラグ、ターゲット、実行・ステートガスリミット、バリュー、データを指定できます。現行仕様ではMAX_FRAMESは64、FRAME_TX_TYPEは0x06です。

従来のレガシートランザクションは送信者署名・送信者支払いという固定構造ですが、フレーム抽象化によってそれがプログラム可能なシーケンスに進化します。

フレームトランザクションの実行モードの仕組み

各EIP-8141フレームには、以下3つから1つの実行モードが設定されます：

実行モードによってフレームの実行コンテキストが決まります。VERIFYフレームは送信者フレームの前段で検証ロジックを実行し、SENDERモードは認可された操作を送信者アドレスからの呼び出しとして扱います。DEFAULTモードは中立的なプロトコルレベルの実行アイデンティティを提供します。

このモジュール構造はネイティブアカウント抽象化の要であり、検証処理が1つの秘密鍵や署名方式に縛られなくなります。

APPROVEオペコードの役割

EIP-8141で追加されたAPPROVEオペコードは、トランザクションの承認コンテキストを更新します。

検証ロジックは次のような異なる承認範囲を利用可能です：

• APPROVE_PAYMENTはガス支払いを承認

• APPROVE_EXECUTIONは後続の送信者フレーム実行を承認

• APPROVE_EXECUTION_AND_PAYMENTは両方を承認

フレームの解決ターゲットがAPPROVEの呼び出し元である必要があり、承認できる対象が制限されます。実行が承認されると、後続のSENDERフレームは送信者コンテキストで実行できます。

この分離により、スポンサーコントラクトやペイマスターが最大ガスコストのみを承認し、ユーザー自身の検証ロジックが実行のみを個別に承認することも可能です。

EIP-8141の7つのフレームオペコード

現行仕様にはフレーム関連の新命令が7つ含まれます：

たとえばTXPARAMは送信者・最大手数料・署名ハッシュ・フレーム数などトランザクション全体の情報を取得可能です。FRAMEPARAMは実行モード・フラグ・使用ガス量・アトミックバッチフラグ有無などフレームレベルの詳細を提供します。こうした基本情報の取得操作はガスコスト2で実行されます。

ガス支払い・ガス管理の仕組み

フレームトランザクションはガス支払いを送信者から分離します。VERIFYフレームで別アカウントやスポンサーコントラクトの支払いを承認でき、ガススポンサーシップをネイティブに実現します。

たとえば、ユーザーがステーブルコインを保有し、ガス支払いは別アカウントが担当する場合、フレームトランザクションでERC-20トークンをスポンサーへ送金しつつ、Ethereumの実際のガスコストは指定ペイヤーが精算できます。

各フレームには実行・ステートガスリミットが割り当てられ、未使用ガスは他のフレームの実行余力とはならず、最終的な請求額が減額されます。

アトミックバッチによる「全てかゼロか」の仕組み

アトミックバッチは複数の実行フレームを連動させ、全てが成功するか全てが巻き戻る（リバート）かのいずれかとします。

例えばERC-20の承認後にスワップを実行する場合、アトミックバッチフラグが立っていればスワップがリバートすると承認も巻き戻され、意図しないトークン許可が残る事態を防げます。

この仕組みはフレームトランザクションで複数ステップのスマートコントラクト連携を簡素化できる実践的な理由の一つです。

フレームトランザクションがアカウント抽象化で重要な理由

EthereumのERC-4337アカウント抽象化フレームワークではスマートアカウントやバンドラー、UserOperation、ペイマスターを用いてプログラム可能なウォレット動作が提供されていますが、フレームトランザクションはこの柔軟性をよりプロトコル層に直接もたらします。

EIP-8141のプログラム可能な検証は、様々な署名方式・鍵ローテーション・将来的な署名集約・ポスト量子対応も視野に入れています。デフォルトコードにより、コントラクト未展開アカウントでも利用でき、デプロイフレームによる検証前のアカウント展開も可能です。

一方で、任意の検証ロジックはトランザクションプールでDoSや大量無効化リスクをもたらすため、パブリックメンプール上では検証プレフィックスや未処理フレームトランザクションの扱いに制限が設けられています。

まとめ

Ethereumのフレームトランザクションは、複数のプログラム可能なフレームから成る1つのトランザクションです。検証・ガス支払い・実行を1つのトランザクションロールに固定せず、EIP-8141によって各役割を異なるフレームで分担できます。

この違いこそが最大の特徴です。EIP-8141はプロトコル提案であり、フレームトランザクションはそれによって導入される新たなトランザクション形式です。モジュール構造により、ガススポンサーシップ・アトミックバッチ・プログラム可能な検証・柔軟な署名・ネイティブなアカウント抽象化を個別のシステム構築なしに実現します。

よくある質問

フレームトランザクションのVERIFYモードは読み取り専用か？

はい。VERIFYモードはトランザクション検証用で、永続的なステート変更を伴わずに動作します。これによりノードは、未処理のフレームトランザクションがパブリックメンプールに入るべきかを判断する前に、検証を安全にシミュレーションできます。

Ethereumはフレームトランザクション実行前にガス支払い者を特定できるか？

常に特定できるわけではありません。EIP-8141ではペイヤーがプログラム可能な検証ロジックで選択されるため、トランザクションデータだけから静的には判断できません。支払い承認は検証プロセス中に確立されます。

EIP-8141フレームトランザクションでペイヤーはいつ承認されるか？

最初に送信者の承認が確立され、その後ガスコストを負担するアカウントやペイマスターの支払い承認が確認されます。この分離により、実行承認とガス支払い承認を異なる主体が担うことも可能です。

1つのフレームトランザクションで他のフレームの未使用ガスを消費できるか？

できません。フレームトランザクションのガス管理では、1つのフレームが他のフレームの未使用ガス枠を利用することはできません。各フレームごとに実行・ステートガスリミットがあり、トランザクション全体のガスリミットはインストリンスィックガス＋各フレームの実行リミットで構成されます。

カノニカル・ペイマスターと非カノニカル・ペイマスターの違いは？

カノニカル・ペイマスターはプロトコルで定められた実装に沿い、コントラクトコードが仕様通りである必要があります。ノードは未処理ガスコミットメントを予測しやすくなります。非カノニカル・ペイマスターはメンプール制限が厳しく、未処理トランザクションは1件までなど、DoSや大量無効化リスクを抑える措置が取られます。

本コンテンツは教育目的で作成されています。EIP-8141はEthereumの進化するプロトコルロードマップの一部であり、正式なメインネット適用前に仕様が変更される場合があります。