Account Abstraction (ERC-4337) vs. Meta Transactions (ERC-2771) の Q&A
ikmzkro下記記事を読みつつ個人的な見解をメモしながら、答え合わせを行いながら理解を深めていきます。歴史とかは割愛します。
ikmzkroAA(アカウントの抽象化)はメタトランザクションとどう違うのですか?
個人的見解
AAはガス代をBundler/walletに委託するだけでなく取引内容のカスタムを設計できるようになる。例えば、ガス代をネイティブトークン以外のERC20やERC721で支払うなどの対策も設計次第では可能になる。メタトラはリレイヤサーバ運用者が管理するアドレスの残高を利用してフロントでDappsやDefiを触るので、ユーザがガス代を気にしないUXを経験できる企画。
答え
アカウントの抽象化は、ガス料金だけでなく、イーサリアム アカウントのより複雑な部分を抽象化することを目的としています。 技術的な観点から見ると、メタ トランザクションとアカウント抽象化の違いは、メッセージの構造とその下位互換性にあります。
→ガス代の視点はあってたな。メッセージの構造とその下位互換性が差異の本質だと。
ikmzkroアカウント抽象化における UserOps とは何ですか?
個人的見解
取引内容(data)に対してフロントのEOAでEIP712署名を行ったもの(signature)を含めた取引詳細を示すパラメータで、エンドユーザが AA でのアカウントに関する EVM 上の状態変更を要求する際に発行される。それをBundlerのRPC Serverに送信する際に付加する。
答え
メタトランザクションの場合、業界標準は EIP712 ベースのメッセージを使用することであり、これにはすべてのスマート コントラクトをアップグレードする必要がありました。 アカウントの抽象化は、 UserOperationsと呼ばれる特別なトランザクション形式を標準化します。UserOperation には、どの Paymaster を使用するかを決定するフィールド、ユーザーが支払う意思のある金額 (自己スポンサーシップの場合)、署名された UserOperation など、ユーザーが実行しようとしているトランザクションを把握するために必要なすべての情報が含まれています。
→取引内容と言っても通常の取引（例：アドレスAからアドレスBに1TH送金するための情報とEIP712Sig）などではなく、Paymasterの決定、バンドラー補償用のガス代などAA固有のパラメータがある。
| 分野 | タイプ | 説明 |
|---|---|---|
| sender | address | ユーザー操作を送信するスマート アカウントのアドレス。 |
| nonce | uint256 | アンチリプレイ保護。 |
| initCode | bytes | まだオンチェーンにない場合に送信者をデプロイするために使用されるコード。 |
| callData | bytes | 実行のために送信者に渡されるデータ。 |
| callGasLimit | uint256 | 実行フェーズのガス制限。 |
| verificationGasLimit | uint256 | 検証フェーズのガス制限。 |
| preVerificationGas | uint256 | ユーザー操作を送信するためのオーバーヘッドをバンドラーに補償するためのガス。 |
| maxFeePerGas | uint256 | EIP-1559 maxFeePerGasに類似 |
| maxPriorityFeePerGas | uint256 | EIP-1559 maxPriorityFeePerGasに似ています。 |
| paymasterAndData | bytes | ペイマスター契約のアドレスと、ペイマスター契約の検証と実行に必要な追加データ。またはゼロのアドレスに設定すると、ペイマスターは使用されません。0x |
| signature | bytes | 検証中にユーザー操作を検証するために使用されます。 |
コントラクトの細部まで見る場合はこちらを参考。
ikmzkroAAにおけるPaymasterとは何ですか?
個人的見解
メタトランザクションではRelayer Serverが運用するアドレスのアセットにガス代の補填を依頼している。AAではこのガス代行者がPaymasterという立ち位置になる。
前提として、Wallet ContractはEntryPoint（UserOpsの受け取りと署名検証実行者）に対してガス代を支払う。逆にEntryPointはWallet Contractからのデポジット額を常に監視して支払い能力を確認している。残高がない場合にPaymasterというガス代行機構を頼る（validatePaymasterUserOp）。
うろ覚えなのが_postOp関数。EntryPointがPaymasterを利用してtx実行した場合contextが返却される。EntryPointのDeposit 額が少なくなってきたときにcontextを引数にして_postOpを叩けば、ガス補填できるみたい。難しいしかなり理解度があやふや。
答え
ペイマスターは、有効なガススポンサーシップを定義するために使用できる任意の検証ロジックを持つオンチェーンのスマートコントラクト。ここでの違いは実行が onchain であることです。DAO、dapp、その他のチームは、ERC-20 ガス支払いなどの機能を備えた独自のカスタム ペイマスターをデプロイできます。
→単なるガス代行者ではなく、コントラクト設計者によってガス代の補填の仕方が柔軟に設計できるようになる。
これらのカスタム Paymaster は、ERC-4337 を使用して、既存のバンドラー サービスとプラグ アンド プレイできます。これは、プロバイダーの採用を必要とするメタ トランザクションとは異なります。
→次のセクションで確認
ikmzkroRelayer vs Paymaster
個人的見解
ガス代をNativeTokenで支払うかウォレットコントラクトで設計したERC20等で支払うかを選択できる点で異なる。メタトラではRelayer ServerをOZDefenderなどにデプロイしてサーバ運用したが、AAではコントラクト内部にあるからonchain管理かどうかも違う？
答え
メタ トランザクションの概念におけるリレイヤーはインフラプロバイダーの制御下にある秘密キーですが、AAバンドラーは標準化されたノードです。異なるバンドラー間の切り替えは、API キーと API URL を変更するのと同じくらい簡単です。
スポンサーシップの検証はペイマスター契約内のオンチェーンで行われるため、アカウントの抽象化には MinimalForwarder の概念はありません。
メタ トランザクションの場合、ネイティブ トランザクション内にトランザクションが 1 つだけ存在するのではなく、バンドラーは複数のUserOperation を1 つのバンドル (1 つのネイティブ トランザクション) にバンドルします。
⇨普通に知らなかったなあ・・・てか知識薄いので出直すか。
ikmzkroメタトランザクションに対するAAの 5 つの利点
個人的見解
メタトランザクション、AAに対する理解度が低いのであまり答えられない。よって答えを見ても意味なし。AA実装するのが一番早い。
答え
NAN
ikmzkroメタトランザクションをAAに更新するにはどうすればよいですか?
個人的見解
NAN
答え
NAN