アカウントアブストラクション（ERC-4337）とメタトランザクション（ERC-2771）

Meta TransactionsとAccount Abstractionは、Ethereumのユーザー体験を改善するための手法です。Meta Transactionsはスマートコントラクトの更新が必要であるため、廃止が進んでいます。

Account AbstractionはMeta Transactionsとどう違うのか

Account Abstractionは、ガス代だけでなく、Ethereum Accountのより多くの複雑さを抽象化することを目指しています。

技術的な観点では、Meta TransactionsとAccount Abstractionの違いは、メッセージの構造とその後方互換性にあります。

Account Abstractionについてさらに学ぶ

Account AbstractionにおけるUserOpsとは

Meta Transactionsの場合、業界標準はEIP712ベースのメッセージを使用することであり、これにはすべてのスマートコントラクトのアップグレードが必要でした。

Account Abstractionは、_UserOperations_と呼ばれる特別なトランザクション形式を標準化しています。

UserOperationには、ユーザーが実行しようとしているトランザクションを判断するために必要なすべての情報が含まれています。これには、どのPaymasterを使用するか、（自己負担の場合）ユーザーがいくら支払う意思があるか、そして署名済みのUserOperationを決めるためのフィールドが含まれます。

Account AbstractionにおけるPaymastersとは

ERC-4337 Account Abstraction標準のGas抽象化部分では、_Paymasters_が導入されています。

Paymastersは、有効なガススポンサーシップを定義するために使用できる任意の検証ロジックを持つオンチェーンのスマートコントラクトです。ここでも違いは実行がオンチェーンで行われるという点です。

DAOs、apps、その他のチームは、ERC-20でのガス支払いなどの機能を備えた独自のカスタムPaymastersをデプロイできます。

これらのカスタムPaymastersは、ERC-4337を使用して既存のBundler Servicesとプラグアンドプレイで利用できます。これは、Providerの採用が必要なMeta Transactionsとは異なります。

Relayers対Paymasters

Meta Transactionsの概念におけるRelayersがInfraプロバイダーの管理下にある秘密鍵であるのに対し、Account AbstractionのBundlersは標準化されたノードです。異なるBundlers間の切り替えは、APIキーとAPI URLを変更するだけで済みます。

Account AbstractionにはMinimalForwarderという概念がありません。これは、スポンサーシップの検証がPaymasterコントラクト内でオンチェーンで行われるためです。

Meta Transactionsの場合はネイティブトランザクション内に1つのトランザクションしか含まれませんが、Bundlersは複数の_UserOperations_を1つのバンドル（1つのネイティブトランザクション）にまとめます！

Meta TransactionsよりAccount Abstractionが優れている5つの理由

1. スマートコントラクトの変更が不要

Meta Transactionsは、それを採用するすべての既存コントラクトへの更新が必要ですが、Account Abstractionは既存のインフラの上に構築されます。つまり、すべてのスマートコントラクトはデフォルトでAccount Abstractionをサポートしており、これがMeta Transactionsより優れた選択肢となる理由です。

2. BundlerとPaymasterサービス間の摩擦のない切り替え

ERC-4337の下では、すべてのBundlersとPaymastersが特定の標準に従って通信します。チームは、自社のアプリケーション向けの条件付きロジックを持つ独自のPaymastersを作成することもできます。

3. 独自仕様のRelayersを採用する必要がない

独自仕様のRelayersには一貫性がなく、各Relayerはそのユースケースに応じた独自のメッセージ形式を持つ場合があります。これにより、それぞれ異なるRelayerと互換性を持たせるためにスマートコントラクトの変更が必要になります。

4. より高い分散性

より多くのプロバイダーがBundlerサービスを提供するようになるにつれ、開発者はトランザクションフローを分散化する能力を得られます。これにより、開発者は品質の劣るBundlerを乗り換える選択肢も得られます。

5. 開発者ツールへのロックインがない

Meta Transactionsを使用する場合、InfraプロバイダーのSडकを使用する必要もあります。

Wait, that has an error, let me redo without the typo.

Meta Transactionsを使用する場合、Infraプロバイダーの SDK を使用する必要もあります。これにより、ツールへのロックインが生じ、Relayerを移行する際の摩擦が増えます。

Account Abstractionの場合、すべての標準機能がすべてのSDKでサポートされているため、専門知識に基づいて選択し、好みに応じて切り替えることができます！

さらに、UserOperation標準がすべてのベンダーによって採用される予定であるため、UserOperation Explorersのようなツールを構築することも可能です。

Meta TransactionsからAccount Abstractionへの更新方法

Meta Transactionsをサポートするためにスマートコントラクトにすでに変更を加えている場合、それらの変更を元に戻す移行プロセスは簡単です。

Meta Transactionsとは異なり、msg.senderとmsg.dataはAccount Abstractionでもそのまま使用できます。

カスタムPaymastersやAccount Factoriesが必要な場合は、その開発が移行の次のステップとなります。

標準的な実装の場合、開発時間や自らのミスによるバグを減らすために、十分に監査された既存のAAプロバイダーを使用することをお勧めします。

AlchemyのGas Managerは、アドレスごとのガス使用量制限、スポンサーするUserOperationsの最大数、_アドレスの許可リスト、スポンサーシップの期限、ドメインレベルの許可リスト_といった詳細な制御機能を提供します！

Gas Manager Admin APIを使用すると、Gasポリシーの作成、読み取り、更新をプログラムから行えます。それに加えて、開発者はスポンサーされたすべてのUserOperationを視覚的に確認できる優れたダッシュボードを利用できます！

結論

Account Abstraction（ERC-4337）は、コントラクトレベルのコード変更を回避できる、摩擦のないベンダー切り替えが可能、既存インフラとの組み合わせが可能、より高い分散性が得られるといった利点を持つ、ガスレストランザクションをアプリに組み込むための新しくより優れた方法です。