EIP-8141とERC-4337：その違いとは？

EIP-8141とERC-4337の本質的な違いはアーキテクチャにあります。ERC-4337は、スマートコントラクトウォレット、UserOperation、バンドラー、EntryPointという単一のスマートコントラクト、そして任意のペイマスターを活用し、Ethereumの既存トランザクションシステム上にアカウント抽象化を実装します。一方、EIP-8141はプロトコル層に新たなFrame Transactionを提案し、検証・ガス支払い・デプロイ・実行を1つのトランザクション内で複数のフレームとして処理できる設計です。

どちらもスポンサー付きトランザクション、バッチ処理、柔軟な署名、リカバリ機能、シンプルなウォレット体験といった主要なアカウント抽象化機能を追求しています。相違点は、これらの機能がEthereumにどの程度深く統合されているかにあります。

要点

ERC-4337は、Ethereumのネイティブトランザクションタイプを変更せずに機能します。EIP-8141はFrame Transactionをプロトコルレベルに直接導入します。

ERC-4337は、UserOperation、バンドラー、EntryPointコントラクト、ペイマスターコントラクトを利用します。

EIP-8141は、VERIFYやSENDERなどのフレームによって、検証・ガス支払い・デプロイ・実行を明確に分離します。

両方式とも、ガス抽象化、トランザクションバッチ、代替署名、スポンサー付きトランザクションを実現できます。

EIP-7702は、既存EOAがスマートコントラクト機能を獲得する移行経路を提供し、両アプローチとの連携が可能です。

EIP-8141 vs. ERC-4337 アカウント抽象化

Feature ERC-4337 EIP-8141

Main user object UserOperation Frame Transaction

Account model Smart account contract Native AA-capable account

Protocol change required No Yes

Execution coordinator EntryPoint singleton smart contract Protocol execution of frames

Bundlers Core part of standard flow Not required in the same way

Gas abstraction Paymaster contract Payment approval inside frames

Batch transactions Smart account logic Multiple frames / atomic batch

Account deployment Factory/init code Deploy frame

Validation Smart account validation VERIFY frame

User execution Smart account call SENDER frame

EOA path EIP-7702 support Default code / EIP-7702-compatible model

ERC-4337はUserOperationを疑似トランザクションと定義しています。コールデータ、ガスリミット、最大手数料、署名、ペイマスターデータなどのフィールドを持ちますが、最終的にはバンドラーがこれを通常のEthereumトランザクションにまとめ、EntryPointに送信します。

EIP-8141は従来のトランザクションフォーマット自体を刷新します。ペイロードに複数のフレーム、署名、手数料パラメータ、送信者アドレスなどを含め、各フレームが独自の実行モードやガスリミットを持つことが可能です。

ERC-4337スマートコントラクトウォレットの仕組み

ERC-4337では、ユーザーは従来のEOAではなく、スマートアカウントコントラクトを作成・利用します。

ユーザーは意図したコールデータを含むUserOperationに署名し、バンドラーが保留中のUserOperationを収集し、EntryPointコントラクトを通じて提出します。EntryPointが各アカウントを検証し、実行を調整します。ペイマスターコントラクトはガスコストをスポンサーでき、アプリケーションは条件付き支払いポリシーを設計したり、ユーザーがERC-20トークンで間接的に支払うことも可能です。

署名フィールドはEthereumのコンセンサスルールで固定されず、スマートアカウント側で解釈されるため、ERC-4337はセッションキー、マルチ署名ポリシー、リカバリロジック、モジュラー型スマートアカウントなどにも対応できます。

既存のERC-4337アカウント抽象化アーキテクチャは、プロトコルアップグレードなしで十分なスマートコントラクト機能を提供しています。

EIP-8141のFrame Transactionによるモデル変化

EIP-8141はこれらの機能をEthereumのネイティブなトランザクションフローにより深く統合します。

verify frameが検証段階を担い、sender frameが送信者の実行コンテキストでユーザーの操作を実行します。必要に応じて、deploy frameがバリデーション前にアカウントコードをインストールし、追加のフレームが支払いや実行後のロジックを処理します。

APPROVEオペコードにより、バリデーションコードは実行や支払い、またはその両方をカバーする承認範囲を設定できます。実行が承認されると、残りのフレームが複数の操作を一括で実行します。

Frame TransactionとERC-4337の決定的な違いは、プロトコル自体がこれらの段階を認識し、UserOperationパイプラインに依存しない点です。

ガス支払いとガス計算

どちらの方式も、ユーザーがすべてのトランザクションでETHを保有していなくても利用できます。

ERC-4337では、ペイマスターコントラクトがガスを肩代わりし、ユーザーから他のトークンでコストを回収することも可能です。ウォレットプロバイダーやdAppはスポンサー条件を自由に設計できます。

EIP-8141では、ガス支払いがトランザクションのバリデーションシーケンスに組み込まれ、スポンサーコントラクトが支払いを承認し、送信者は別途実行を承認します。支払者と送信者は必ずしも同じである必要はありません。

EIP-8141はより明確なガスモデルを採用し、各フレームごとに実行および状態のガスリミットを設定し、トランザクション全体で最大コストを制約します。あるフレームで余ったガスは他のフレームで自動的に流用できず、シミュレーションコストやバリデーション作業の抑制に寄与します。

バッチトランザクションと複数操作

ERC-4337のスマートアカウントはすでにトランザクションバッチを実装可能で、1つのアカウントアクションで複数操作を実行できます。

EIP-8141は複数フレームでバッチ操作をより明確にし、アトミックバッチとして連続したアクションをグループ化できます。関連するフレームの1つでもリバートすれば、そのグループ内の全変更もロールバックされます。

例えば、トークン承認とスワップを1つのシーケンスで実行し、スワップが失敗した場合には未使用の承認が残らないようにできます。

こうしたマルチステップ処理のネイティブ対応が、EIP-8141がスマートアカウント設計の簡素化を目指す理由の1つです。

EIP-7702とEOAの移行経路

EIP-7702は、EOAが既存アドレスを維持したままコントラクトコードへの実行委任を可能にし、従来型アカウントとスマートアカウントの機能を橋渡しします。

ERC-4337は全ユーザーが新しいコントラクトアドレスへ移行せずとも、EIP-7702対応アカウントを利用できます。

EIP-8141はさらに進み、デフォルトコードを導入してアカウントに最低限のFrame Transaction挙動を付与。ストレージが空、もしくはコード未デプロイでも動作し、追加機能が必要な場合はdeploy frameでコードのインストールや委任を行えます。

したがって、EIP-7702・ERC-4337・EIP-8141は、Ethereumのアカウント抽象化移行経路における連続した段階として捉えられ、相互排他的な仕組みではありません。

ネイティブアカウント抽象化：プロトコル層での変化

EIP-8141の深い統合によって、標準的なアカウント抽象化操作におけるバンドラーや他のオフチェーントランザクション処理基盤への依存が大きく減少する可能性があります。

また、プログラム可能な検証がコンセンサスレベルのトランザクションモデルにより近づきます。リカバリポリシー、将来の署名集約、セッション型権限、ポスト量子認証など、異なる検証ロジックのサポートも期待できます。

その分複雑さも増します。パブリックノードはFrame Transactionをインクルード前に安全に評価する必要があります。EIP-8141は制約付きバリデーションプレフィックスを定義し、状態アクセスに制限を設け、検証作業の上限・正規／非正規ペイマスターの区別などで、大量無効化やDoSリスクを低減します。

Ethereumの広範なアカウント抽象化アーキテクチャは、ウォレットUXがアプリケーションレベルの回避策からプロトコルレベルのサポートへと進化してきた理由を示しています。

まとめ

最も分かりやすい比較は、ERC-4337はEthereumの周辺でアカウント抽象化を実現し、EIP-8141はEthereum内部により深く組み込むという点です。

ERC-4337はスマートコントラクトウォレット、UserOperation、バンドラー、EntryPoint、ペイマスターを用い、EIP-8141は検証・送信者・デプロイ・支払い・実行など専用ステージを持つFrame Transactionを採用します。

ERC-4337は既にインフラが成熟しており、プロトコルアップグレードを待たずにアカウント抽象化を実現できます。EIP-8141の優位性は、ガス抽象化やプログラム可能な検証、バッチ処理、スポンサー付きトランザクションをよりネイティブに、個別パイプラインへの依存を減らして実現できる点にあります。

よくある質問

EIP-8141はERC-4337を置き換えますか？

自動的に置き換わるわけではありません。ERC-4337は既存のスマートアカウントと確立されたインフラをサポートしており、EIP-8141がEthereumのネイティブ機能を変える場合でも、ウォレットは有用な場面でERC-4337コンポーネントを活用し続けることができます。

EIP-8141にEntryPointコントラクトは必要ですか？

コアのFrame Transactionフローには同等の単一EntryPointコントラクトは不要です。検証と実行はUserOperationをEntryPointでルーティングするのではなく、トランザクションフレームで直接表現されます。

両方式ともスポンサー付きガス支払いに対応していますか？

はい。ERC-4337はペイマスターでUserOperationのスポンサーが可能ですし、EIP-8141はトランザクションバリデーションで送信者と支払者を分離してスポンサーコントラクトによるガス肩代わりが可能です。

ERC-4337は既存のEOAをサポートしますか？

はい、特にEIP-7702を通じて可能です。EOAは既存アドレスを保持したままスマートコントラクト機能を委任できるため、完全なアカウント移行の必要がありません。

EIP-8141が「ネイティブアカウント抽象化」と呼ばれる理由は？

検証・支払い承認・デプロイ・実行が、新しいEthereumトランザクションフォーマットにネイティブ組み込みされ、主に外部のUserOperationインフラで実装されていないためです。

本コンテンツは教育目的のみです。Ethereumの標準・プロトコルアップグレード・ウォレット実装・EIP仕様は変更される場合があります。