EIP-4337によるアカウント抽象化は、どのようにイーサリアムのUXを改善するのか？
TechFlow厳選深潮セレクト
EIP-4337によるアカウント抽象化は、どのようにイーサリアムのUXを改善するのか？
EIP-4337は、アカウント抽象（Account Abstraction）を用いて、どのようにしてイーサリアムのユーザーエクスペリエンスの複雑さを解決しようとしているのでしょうか？
Web3業界の深掘り報道に専念し潮流を洞察
原文著者：Nishil、Biconomy 研究員
翻訳：DeFi 之道
イーサリアムの主な欠点の一つはユーザーエクスペリエンスが複雑であることです。nethermindおよびopengsnの研究者が提唱したEIP-4337が、アカウント抽象（Account Abstraction）によってこの問題をどのように解決しようとしているかを見ていきましょう。
それではまず、アカウント抽象（AA）の意味から始めましょう。
一、アカウント抽象（AA）とは
アカウント抽象は、ユーザーがアカウントを利用する際のプロセスを簡素化し、基盤となる仕組みについての理解を必要としないようにするものです。
私たちがGmailアカウントを使うときに、その仕組みを知らなくてもよいのと同じです。
アカウント抽象があれば、恐ろしいニーモニックフレーズの世界から離れることができます。
さまざまな署名方式の利用や、Dappによるガス代のスポンサード、法定通貨での支払いなどが可能になります。
ここでアカウント抽象（AA）の定義を理解したので、次にそれをイーサリアムにもたらす方法について見ていきましょう。
二、イーサリアムにおけるアカウント抽象の実現方法
現在、イーサリアムには2種類のアカウントがあります：外部所有アカウント（EOA）とスマートコントラクトアカウントです。
-
外部所有アカウント（EOA）は、ユーザーの鍵ペア（公開鍵と秘密鍵）によって制御されるアカウントであり、Metamask（ウォレット）などのサービスを通じてイーサリアムとやり取りする際に多くのユーザーが使用しています。
-
スマートコントラクトアカウントは、秘密鍵ではなくコードによって制御されるアカウントです。たとえば、すべてのDeFiプロトコルはスマートコントラクトアカウントによって管理されています。
イーサリアムの問題点は、外部所有アカウント（EOA）が、スマートコントラクトアカウントにはない特権を持っていることです。最も顕著な例が取引の発行能力で、現状ではEOAだけがこれを実行できます。
これは問題です。なぜなら、EOAの機能はイーサリアムプロトコルにハードコードされており、カスタマイズの余地がないためです。
例えば、Gmailではアカウントに2段階認証（2FA）を設定できますが、今のイーサリアムでは同様のカスタマイズが不可能です。
イーサリアム上のEOAには以下のような制限があります：
-
ユーザーは独自の署名スキームを使用できません。 イーサリアムで公開鍵・秘密鍵ペアを生成するために使われる標準的な署名スキームはECDSAです。
-
ガス代はネイティブ暗号資産（$ETH）で支払う必要があります。
-
秘密鍵がアカウントそのものなので、鍵を失うとアカウントも失うことになります。
これらすべての問題は、カスタムロジックを利用できるスマートコントラクトウォレットを使えば簡単に解決できます。
しかし前述の通り、イーサリアム上の取引はECDSAで保護されたEOAからのみ開始でき、スマートコントラクトウォレットからは開始できません。
ここで疑問に思うかもしれません――なぜこれを変更しないのか？
実は、EIP-2938 はこの問題を解決する手段の一つです。これにより、イーサリアムプロトコルを変更して、EOAではなくスマートコントラクトから取引を開始できるようになります。
しかし、この方法には大きな課題があります。それは、プロトコルに大規模な変更が必要になる点です。
そのため、nethermindおよびopengsnの研究者たちはVitalik Buterinの支援を得てEIP-4337を提案しました。
この提案は、コンセンサス層のプロトコルを一切変更せずに「アカウント抽象」をイーサリアムにもたらす方法を示しています。
コンセンサス層自体のロジックを変更するのではなく、現在のトランザクションプールの機能をより上位のシステムに再現するものです。
このプロセスにはいくつかの構成要素があり、次のものがあります：
-
ユーザーオペレーション（User operations）
-
バンドラー（Bundler）
-
ペイマスター（Paymaster、任意）
次に、これらの概念を一つずつ見ていきましょう。
この提案では、「ユーザーオペレーション」という概念を導入しており、これによりカスタム機能をスマートコントラクトウォレットにコーディングできます。
ユーザーオペレーションは、ユーザーの意図、署名、および検証に必要な他のデータをパッケージ化します。
関連画像：
スマートコントラクトウォレットを使って取引を発行する一般的な流れは以下の通りです：
1. Alice（ユーザー）が実行したいトランザクションを含む「ユーザーオペレーション」を発行する；
2. 彼女はそのオペレーションを上位レベルの「ユーザーオペレーションプール」に送信する。
3. そのオペレーションは部分的に検証され、P2Pネットワーク上のプールノードにブロードキャストされる。
4. その後、「バンドラー」がそのオペレーションを選択して実行する。誰でもバンドラーになれる――MEV searcher、バリデータ、あなたや私など。
5. バンドラーはすべてのオペレーションをまとめて1つの大きなトランザクションにする。
6. バンドラーはそのブロックを他のトランザクションとともにイーサリアムブロックに含める。
次に、バンドラーの機能を分解して、トランザクションがどのように実行・検証されるかを理解しましょう。
1. バンドラーはトランザクションをグローバルな「エントリポイント」スマートコントラクトにルーティングする。
2. グローバルコントラクトは各ユーザーオペレーションを処理し、スマートコントラクトウォレット内の「検証関数」を呼び出す。
3. ウォレットはこの関数を実行してユーザーオペレーションの署名を検証し、バンドラーに手数料を支払う。
4. ウォレットは指定された操作を実行するための実行関数を走らせる。
5. 操作完了後、残りのガスはウォレットに返金される。
このEIPはまた、「ペイマスター」（paymaster）という概念も提案しています。
ユーザーはもはや自分のウォレットに頼らず、ペイマスターが取引手数料をスポンサーすることも可能になります。
取引のスポンサード機能には多くのユースケースがあります。特によく言及されるのは：
-
アプリ開発者がユーザーの手数料を代わりに支払えるようにする；
-
ユーザーがERC20トークンで手数料を支払い、コントラクトがそのERC20を受け取る仲介役となる；
三、アカウント抽象が私たちにもたらすこと
これらすべては非常に興味深いですが、なぜ私たちはこれに関心を持つべきなのでしょうか？理由はいくつかあります。
この提案により、カスタム署名スキームの使用が可能になります。ユーザーはiOSやAndroid端末の内蔵セキュリティ機能を使い、それぞれのスマホをハードウェアウォレットのように使えるようになります。
イーサリアム上でマルチシグネチャのネイティブサポートが可能になります。2人以上のユーザーが共同で1回の取引を承認できるようになり、セキュリティが向上します。
ソーシャルリカバリーも実現可能です。ユーザーが何らかの理由で秘密鍵を失った場合、友人や家族に依頼してアカウントを簡単に復旧できます。
以上がこの提案の概要です。
この提案は多様な革新をもたらします。私がこれらを明確に説明できたことを願っています。今後、チームが構築するユースケースを見て、ユーザーにとってより良いエクスペリエンスが提供されることを楽しみにしています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@biconomy
