暗号ウォレットの革命：アカウント抽象化のすべてを変える方法

簡単に言うと、アカウント抽象化によりユーザーはスマートコントラクトを自分のアカウントとして使用できるようになり、暗号ウォレットを実質的にプログラム可能にします。これはユーザーがブロックチェーンアプリケーションと対話する方法において画期的な変化であり、暗号をより使いやすく、安全で、広く採用されるための重要なステップであると多くの人が信じています。

Ethereum’s共同創設者のヴィタリック・ブテリンも、アカウント抽象化を採用しない限り、イーサリアムはその目標を達成できないかもしれないと提案しており、この技術が Web3の未来にとってどれほど重要であるかを強調しています。

しかし、アカウント抽象化とは正確には何であり、それはどのように機能するのでしょうか？その重要性を理解するには、まず従来のブロックチェーンアカウントがどのように機能するかを理解し、なぜその古いモデルには限界があるのかを理解する必要があります。その後、アカウント抽象化がどのようにゲームを変えるかを掘り下げ、セキュリティの向上やユーザー体験の簡素化など、その利点を探求し、実際の例を見て、残っている課題を検討します。

最後には、なぜアカウント抽象化が暗号ウォレットへの大きなアップグレードとされているのか、そしてそれが最終的に暗号通貨の管理を現代の金融アプリを使用するのと同じくらいシームレスにする可能性があるのかを理解できるようになるでしょう。

従来のアカウントモデル：EOAs 対スマートコントラクトアカウント

今日のイーサリアムなどのブロックチェーンは、資産を管理し、トランザクションを実行するためのアカウントモデルを使用しています。イーサリアムには2つの主なタイプのアカウントがあります。

外部所有アカウント（EOA） – これらは個人のプライベートキーによって制御される「通常の」ユーザーアカウントです。イーサリアムのウォレット（MetaMaskやハードウェアウォレットなど）を作成したことがあるなら、EOAを持っています。EOAでは、公開鍵から派生された公開アドレスと、トランザクションに署名するためのプライベートキーがあります。EOAを使用すると、コインやトークンを保持し、資金を転送するためのトランザクションやスマートコントラクトを呼び出すトランザクションを送信できます。重要なことに、EOAは自らトランザクションを開始できますが（プライベートキーの署名付きで）、カスタムコードを実行することはできません – 基本的な送信機能を超えてプログラム可能ではありません。 EOAは2つの主要なアクションに制限されます：別のアカウントに価値（ETHまたはトークン）を送信すること、またはスマートコントラクトの関数を呼び出すことです。
コントラクトアカウント（スマートコントラクト） – これらはプライベートキーではなくコード（スマートコントラクトコード）によって管理されます。コントラクトアカウントは資産を保有し、トランザクションを受け取ったときに実行される規則やロジック（コード）を定義できます。たとえば、分散型アプリケーションまたはトークンコントラクトがコントラクトアカウントにいます。しかし、コントラクトアカウントは自らトランザクションを開始できません。外部のアカウントや他のコントラクトからのトランザクションによってトリガーされた場合のみ、コードを実行します。言い換えれば、誰か（または外部アカウント）がコントラクトを呼び出す必要があります。それにより何かを行うことができます。コントラクトアカウントは完全にプログラム可能であり、複雑な規則を強制できますが、新しいトランザクションを送信するために直接制御するプライベートキーが欠けています。

イーサリアムアカウントタイプの比較：外部所有アカウント（EOA）対スマートコントラクトアカウント（SCA）。EOAはプライベートキーによって制御され、トランザクションを開始できるが、任意のコードを実行することはできません。 SCA（スマートコントラクト）はコードを実行できますが、自発的に新しいトランザクションを開始できません。アカウント抽象化はこの分割を取り除くことを目指しています。

現在のパラダイムでは、これらの2つのアカウントタイプは別々であり、それぞれに欠点があります。EOAは単一のプライベートキーに結びついているため、大きな制限と脆弱性があります：そのプライベートキー（またはバックアップシードフレーズ）へのアクセスを失うと、アカウントやそこにあるすべての資産へのアクセスを失います – ブロックチェーンには「パスワードを忘れた」オプションはありません。逆に、悪意のある人物がプライベートキーを入手すると、資金を盗む完全なコントロールを得ることになります。EOAでは標準では支出制限を設定したり、複数の承認（マルチシグ）を要求する方法も、信頼できる仲間を介したアクセスの回復手段もありません；アカウントのセキュリティはその単一の秘密キーの強さにのみ依存しています。これは従来の銀行業務と顕著に対照的であり、詐欺対策、カスタマーサポート、または二要素認証によってミスや盗難を緩和できることと大きく異なります。それに加えて、EOAを使用するには、すべてのトランザクションに署名する必要があり（面倒な場合もある）、トランザクションのガス料金を支払うためにブロックチェーンのネイティブ暗号通貨（たとえばETH）をアカウントに保持しておく必要があります。これらの要件により、EOAの使用は日常のユーザーにとってリスクが高く煩雑です。Rumble Fish開発チームが端的に述べているように：EOAには「ソーシャルリカバリメカニズムも、支出制限設定も、2FAも追加できず」、料金をカバーするためにいつもETHを保有しなければならない — すべてが「満足しないユーザーエクスペリエンスにつながり、新規参入者にはあまり歓迎されない。」

一方、スマートコントラクトアカウントはコードによる柔軟性を提供します。たとえば、スマートコントラクトのウォレットは、1トランザクションを承認するために複数の人が必要なマルチシグウォレット、や毎日の引き出し上限を課す、またはキーを紛失した場合に信頼できる友人がアクセスを回復できる「ソーシャルリカバリ」を可能にするようにプログラムできます。これは素晴らしい話で、実際にGnosis Safe （一般的なマルチシグウォレット）やArgent （ソーシャルリカバリのあるウォレット）などの製品は、スマートコントラクトアカウントを活用して、通常のEOAでは不可能な追加のセキュリティ機能をユーザーに提供しています。それでも、コントラクトアカウントは自らの力でトランザクションを開始できないため、歴史的にEOAに依存してアクションを起こさせる必要があるのです。たとえば、スマートコントラクトウォレットを使用する場合、通常は中継サービス（外部EOA）が意図されたアクションを受け取り、EOAトランザクションに包んでネットワークに送信します。この中継者に支払わなければならないか、少なくとも他のアカウントにガスのためのETHを保持しておく必要があるなど、同じ悩みを扱うことになります。そのため、コントラクトベースのウォレットを利用することが、設計が適切でなければ通常のウォレットよりもさらに複雑になるかもしれません。最近の革新が起こるまでは、スマートコントラクトアカウントを利用することは実質上第2のEOA（またはヘルパーサービス）が必要で、コントラクトを駆動するための主なものとしてETHで「チャージ」されている必要がある — ユーザーに摩擦を与えていました。

要するに、現在のモデルの下では：

EOA = あなたのウォレット（1つのキーで制御される） – シンプルだが融通が効かず、厳格。
コントラクトアカウント = プログラム可能な保管庫（高度な機能あり） – 強力だが自動運転ではない。

これはアカウント抽象化が取り除くことを目指している分離です。ビジョンは、スマートコントラクトの柔軟性を持ち、機能するために別々のEOAに依存しないユーザーアカウントが持てるようにすることです。言い換えれば、すべてのアカウントがスマートであるようにする。これを行うことによって、ユーザーは自分のアカウントのセキュリティや動作を自由にカスタマイズできるようになり、行動を開始する能力を犠牲にすることなく実現できます。アカウント抽象化の達成方法とブロックチェーンユーザーエクスペリエンスを劇的に改善する理由を探ってみましょう。 Content: 重要ですか？ なぜなら、より広範な暗号通貨の普及を妨げていた多くの問題が、EOAの制限に起因しているからです。新しいユーザーは、プライベートキーやシードフレーズを安全に管理することに苦労し、間違いが起こった際のセーフティーネットがありません。経験豊富なユーザーは、単一障害点の問題について心配しています。1つのハッキングされたキーが壊滅的な結果をもたらし得ます。開発者たちは、（ガスなしのトランザクションやソーシャルリカバリーのような）機能を提供するために、不器用な迂回策（リレイヤーネットワークや中央集権型サービスなど）を構築せざるを得ませんでした。なぜならブロックチェーンそのものがそれらをネイティブにサポートしていなかったからです。アカウント抽象化は、アカウントモデル自体をより強力でユーザー中心にすることで、これらの問題に正面から取り組みます。その結果、Web3の次の進化のための重要なインフラストラクチャとみなされています。実際、アカウント抽象化は何年もエテリアムのコア開発者たちの夢であり、Vitalik Buterinや他の人々が何度もその実現を主張しており、エテリアムの使いやすさと安全性を大いに向上させる道として考えられてきました。それはもはや抽象的な理論ではなく、最近の標準の中で現実化しつつあり、より新しいブロックチェーンはアカウント抽象化を最初から設計に組み込んでいます。

理論から実践への移行をよりよく理解するために、エテリアムがどのようにアカウント抽象化を実装しているか、特にERC-4337として知られるアップグレードを通じた方法を見てみましょう。

Ethereumにおけるアカウント抽象化の仕組み（ERC-4337）

エテリアムのアカウント抽象化への旅は最近、ERC-4337と呼ばれる提案で頂点に達しました（EIP-4337とも）。2021年に発表され、2023年に展開されたERC-4337は、エテリアムのコアプロトコルに基本的な変更を加えることなく、アカウント抽象化を導入しました。これは重要なことでした。なぜなら、コア（L1）プロトコルの変更は時間がかかり、広範なコンセンサスが必要だからです。代わりに、4337はスマートコントラクトとエテリアムの上のオフチェインインフラストラクチャを使用してアカウント抽象化を達成します。この巧妙なソリューションにより、ハードフォークを要することなく、今日のAAの利点を提供します。

では、それはどのように機能するのでしょうか？ERC-4337は、トランザクションの新しい代替ワークフローを「ユーザーオペレーション」オブジェクト（略してUserOp）というコンセプトに基づいて定義します。ユーザーオペレーションは、ユーザーのスマートコントラクトウォレットが実行したい取引のようなものです。ユーザーのウォレットが通常のエテリアムトランザクションを直接作成する代わりに（EOAが行うように）、ウォレットはUser Operationを作成し、意図されたアクションのすべての詳細を含めます。

以下に、ERC-4337の新しいコンポーネントによる高レベルのフローを示します：

ユーザーオペレーションとメンプール： ERC-4337対応ウォレット（スマートコントラクトウォレット）を使用する場合、ウォレットは通常のトランザクションをブロードキャストしません。代わりに、必要な情報と署名を持つUserOperationオブジェクトを作成します（ただし、この署名は契約のロジックが期待するものであれば何でもよく、必ずしも単一のEOAキーである必要はありません）。これらのUserOpは特別なUserOperationメンプールに放出され、通常のエテリアムトランザクションメンプールとは別です。これは、スマートコントラクトウォレットからの意図的なアクションが拾われるのを待つステージングエリアのようなものです。
バンドラー： バンドラーが登場します。これは、マイナーまたはブロック生成者とある程度類似していますが、ユーザーオペレーションレベルでのことです。バンドラーは、このUserOpメン・プールを監視し、さまざまなユーザーから複数のUserOpを収集して1つの“バンドル”にまとめ、それを1つのエテリアムL1トランザクションとしてラップします。簡単に言えば、バンドラーは多くのユーザーの代理としてその操作をブロックチェーンに運びます。バンドラーはEOAである必要がありますが、これは現在のプロトコルではEOAのみがL1トランザクションを開始できるためです。しかし、エンドユーザーはもはやそれぞれEOAトランザクションを実行する必要がありません。バンドラーは大きなトランザクションのためにガスを支払い、代わりに各UserOpから手数料を得ます。
エントリーポイントコントラクト： バンドルされたトランザクションは、特別なエントリーポイントスマートコントラクトに送信されます。この契約はERC-4337の設計の中心です。エントリーポイントコントラクトの仕事は、バンドル内のUser Operationsを検証し実行することです。バンドルを解凍し、各UserOpごとにターゲットスマートコントラクトウォレット（ユーザーのアカウントコントラクト）を呼び出し、その操作を検証し、望ましいアクションを実行します。各スマートコントラクトウォレットは、エントリーポイントが呼び出す標準インターフェースを実装しなければなりません。これは通常、そのアカウントのルールのための署名、ナンスなどをチェックするためのvalidateUserOpのような関数と、検証が通過すればリクエストされたアクションを実行するためのexecute関数を含みます。検証が失敗すれば（例えば無効な署名や資金不足など）、エントリーポイントはそれを拒否し、違法なトランザクションを実行しないようにします。
ペイマスター（オプション）： ERC-4337は、ガス料金をスポンサーすることができる補助スマートコントラクトであるペイマスターという概念も導入しました。存在する場合、ペイマスターはUserOpに接続でき、検証中にエントリーポイントはペイマスターに代わってユーザーのガスを支払うように要求します。これはユーザーがETHを持たずにトランザクションを行うことを可能にするメカニズムです。例えば、dAppの開発者が新しいユーザーのためにガス代を支払うフレンドリーなオンボーディング戦略としてペイマスターを運用したり、ユーザーが保有するERC-20トークンでガスを支払えるようにしたりします。ペイマスターが使われない場合、ガスはユーザーのスマートウォレットの資金から支払われます（ただし、ウォレット自体がそのためのスワップやロジックを持っていれば、それでもERC-20トークンの形式になります）。
バンドラーインセンティブ： 操作が完了すると、エントリーポイントコントラクトはその対価としてバンドラーに手数料を支払います（これはユーザーのアカウントまたはペイマスターのいずれかから提供されます）。これにより、バンドラーが引き続きオペレーションを行うインセンティブがもたらされます。要するに、バンドラーはマイナーやバリデーターがガス料金を稼ぐのと同様に手数料を稼ぎますが、今やユーザーオペレーションのバッチから収入を得ることができます。

このアーキテクチャは、すべてのユーザーがEOAを持つ必要を事実上取り除きます。バンドラーのみがEOAを使用してトランザクションを投稿する必要があり、それ以外のすべての「トランザクション」はスマートコントラクトによって処理されるUserOpsとしてカプセル化されます。Rumble Fishチームが述べたように、4337モデルでは、バンドラーが「このアカウント抽象化エコシステム内で[EOA]が必要な唯一の参加者」であり、エンドユーザーにとっては、そのアカウントは純粋にスマートコントラクトウォレットであり、手動でEOAからL1トランザクションを送信することはなく、エントリーポイントの仲介者を通じてオンチェーンでその意思が実行されます。

これを具体例で詳しく見てみましょう。仮にAliceがアカウント抽象化ウォレットを持っていて、「友人のBobが私のウォレットから1日あたり最大0.1ETHしか支出できない」というルールがあるとします。これは通常のEOAでは実現不可能です。組み込みのツールでオンチェーンでの権限の限定的委任を行うことはできません。しかしAAを使えば、Aliceのウォレットはそのルールを強制するスマートコントラクトです。そしてBobはオフラインのAliceの代わりに取引を実行しようとします。BobはAliceのウォレットコントラクトを呼び出すUserOperationを作成します：「AliceからあるDEXへ0.05ETHを転送する」。BobはこのUserOpに署名します（おそらくAliceの契約コードで認可された自分のキーを使って）。このUserOpがメン・プールに送られます。バンドラーがそれを拾い上げ、他のUserOpとともにEntryPointに送ります。EntryPointはAliceのウォレットコントラクトの検証関数を呼び出し、「Bobは許可された代理で、この金額は0.1ETHの日次制限内か？」と確認します。もしそうであれば、検証は通過します。次にエントリーポイントはAliceのウォレットの実行関数を呼び出し、0.05ETHの転送がDEX契約に向けて開始されます。この操作が成功し、エントリーポイントがAliceのウォレット資金から小さなガス料金でバンドラーに支払います（または設定によってはBobのデポジットやペイマスターからかもしれません）。Aliceはその瞬間、何もしなくても済みました。彼女のウォレットの事前設定されたルールがBobの行動を安全に許可しました。もしBobが制限を超えたり、認可されていなかったりしようとした場合、ウォレットは検証中にそれを拒否します。Content:

AAの力: EOA/コントラクトの分割をプロトコルレベルで取り除くことにより、より豊かなウォレット機能を設計することができます。EthereumのERC-4337アプローチは少し複雑ですが（レイヤーの上に重ねられているので）、最終的にはLayer-1 Ethereum上で同じ結果を提供します。

アカウントアブストラクションが何であるか、そしてどのように機能するか（少なくともEthereumの実装では）を理解したので、その利点に話を移しましょう。なぜこれほどまでに話題になっているのでしょうか？ユーザーや開発者にとって、以前は不可能（あるいは非常に困難）だったことを実現するのは何でしょうか？アカウントアブストラクションの利点は多岐にわたり、セキュリティやユーザビリティをはじめとする様々な側面に影響を及ぼします。

アカウントアブストラクションの利点

アカウントアブストラクションは、クリプトにおけるユーザー体験とセキュリティを大きく変えるものとしてしばしば称賛されています。ウォレットをスマートコントラクト化することで、クリプトの管理を現代の銀行口座やオンラインプロファイルの管理に近づける機能を解放します。では、主な利点を詳しく見ていきましょう：

セキュリティとリカバリーオプションの改善

アカウントアブストラクションの最大の魅力の一つは、クリプトアカウントのセキュリティが劇的に向上する可能性です。現在、EOAウォレットのシードフレーズや秘密鍵を失うと、アクセスを失ってしまいます。同様に、鍵が盗まれた場合、盗人はすべてを奪うことができ、アカウントを凍結したり被害を元に戻すために呼べる人はいません。この厳しい現実は多くの財産を失った物語を生み、初心者にとって最大の恐怖となっています。

アカウントアブストラクションは修正策を提供します：アカウントがプログラム可能なコントラクトであるため、自分自身のセキュリティメカニズムを組み込むことができます。例えば、開発者は社会的リカバリーやマルチシグ認証を備えたスマートウォレットを実装できます。社会的リカバリーウォレットでは、日常使用のための主要署名鍵は保持していますが、それを失った場合、「ガーディアン」（友人、家族、あるいは自分の他のデバイス）が共同で新しい鍵を承認できます。これは単一点の故障を防ぎ、一つの鍵を失っても永遠にアクセスできなくなることはなく、一つの鍵が盗まれても（ガーディアン全員が侵害されない限り）、攻撃者がアクセスすることはできません。Vitalik Buterinはウォレットのセキュリティ確保のためにこの社会的リカバリーモデルを推奨しており、アカウントアブストラクションを用いることでこのモデルの広範な展開が容易になります（実際、Argentなどのプロジェクトはこれをスマートコントラクトを通じて使用しています）。

同様に、アカウントアブストラクションは、個人向けにも、組織だけでなくマルチシグウォレットを一般化することができます。例えば、ウォレットからの取引には電話とノートパソコン（2つの鍵）が署名する必要がありますが、これにより単一のデバイスの不正アクセスのリスクを大幅に減少させます。以前、Gnosis Safeのようなマルチシグウォレットが存在していましたが、セットアップが複雑であったため主にチームやエキスパートによって利用されていました。AAウォレットを使用すると、ユーザーフレンドリーなインターフェースを使用して、誰もが2-3マルチシグを自分で有効化したり、上限を超える場合に追加の確認が必要な日次支出制限を設定することが可能です。これらの種類のカスタムルールは、普通のEOAでは不可能でした。

本質的に、アカウントアブストラクションにより、開発者はアカウントの認証とリカバリーのために「巧妙な仕掛けを作り、あらゆるオプションをプログラムする」ことが自由になります。取引には携帯デバイスの共署名が必要な2段階認証（2FA）を追加しますか？できます。攻撃が疑われる場合にウォレットをロックする「フリーズ」機能（クレジットカードの凍結のようなもの）を追加しますか？それをプログラムすることが可能です。特定の「安全な」アドレス（例えば自分のコールドストレージ）への無制限の資金が受け取れるが、他人に送る場合に追加のチェックが必要なようにする？すべて契約ロジックで可能です。要するに、アカウントアブストラクションは、現代のセキュリティデザインの柔軟性をクリプトウォレットに持ち込み、これまではすべてか無かの鍵モデルに締め付けられていたウォレットに新たな可能性をもたらします。これにより、多くの脆弱性やEOAウォレットが抱える故障ポイントを大幅に削減します。ユーザーは安全綱なしに綱渡りを行う必要はなくなります– 1つの鍵を失っても、他の方法でリカバリーできる可能性があります。不審な試みを見た場合、サーキットブレーカーのようなものをプログラムしているかもしれません。

新規ユーザーの参入障壁の低下

セキュリティを越えて、アカウントアブストラクションは、一般のユーザーがクリプトをより利用しやすくします。正直なところ、ガス料金やシードフレーズでEOAを管理することは、新参者には威圧的です。UI/UXはしばしばインターネットの初期段階に例えられます – ユーザーに秘密鍵（長いパスワードのようなもの）を完璧に管理するよう求め、ガスやナンスのような概念を初日から理解させるのです。これは採用の障壁です。

アカウントアブストラクションはより親しみやすく、ユーザーフレンドリーな体験を実現することでこの障壁を下げます。例えば、ペイマスターがガス費用をカバーしたり、安定した暗号通貨でガスを支払えるようにすることで、新しいユーザーがガスのためにETHを所有せずに最初のブロックチェーントランザクションを実行できるようになります。dAppやウォレットは（おそらくオンボーディングプロモーションやフリーミアムモデルで）ガス費用をスポンサーすることができ – ユーザーは彼らのアクションがそのまま行われたと感じ、フィンテックアプリが初回トランザクションで手数料を撤廃するのに似ています。これは大きなことです：新しいユーザーがdAppを使用するためだけにETHを（しばしば交換所で）最初に取得することは、オンボーディングの悪夢でした。アカウントアブストラクションは、ガス料金の抽象化を可能にし – ユーザーは持っているトークンで支払え、第三者が介入すればまたは全く支払わない場合があります。

もう一つのユーザーエクスペリエンスの改善は、「サインレス」またはワンクリックトランザクションのアイデアです。文字通り署名なしというわけではありませんが（フードの下にはまだ暗号があります）、ユーザーの視点から見ると、セッション中にdAppに「ログイン」し、各アクションを手動で確認する必要がないかもしれません。アカウントの抽象化によって、ウォレットはセッションキーを実装できます – 限られた権利を持つエフェメラルキーです（例えば一定のアクションしか実行できない期間）。ゲームdAppにログインし、例えば、次の1時間の間にあなたの代わりにそのゲームが動作を実行できるセッションキーを承認することができ、支出の上限があります。その1時間の間、まるで普通のオンラインゲームをプレイするかのようなシームレスな体験を楽しむことができます – 分ごとのトランザクションポップアップはありません。ウォレットのスマートコントラクトはセッションキーが与えられた許可を越えることができないことを保証し、一時間後には無効になります。このような流れはweb2アプリがセッションを維持する方法に類似しており、アカウントアブストラクションの柔軟性によって可能になります。セッションキーや「Ethereumでログイン」体験の初期実装が今、AAウォレットを用いて模索されています。

さらに、アカウントアブストラクションは自動支払いやサブスクリプションのような機能を可能にすることができます。前述のように、Visaのクリプト研究チームは、自動引き落としを独自のスケジュールで実行できるスマートコントラクトウォレットの概念実証を示しました。彼らのシナリオでは、自己管理型のウォレットからの月次請求書の支払いをさせることができ、現在は中央集権的なサービスや銀行だけが行えるものがあります – スマートコントラクトに事前承認を与えることで、資金を引き出せるようになっています。これはネイティブAAを持つレイヤー2（StarkNet）で行われましたが、広く適用されます。トレードや請求書の支払い、転送を条件を設定して事前にスケジュールできるようになることを想像してください（「もし残高が日にちYでX以上であればこの取引を実行」） – アカウントが適切にトリガーされたときに自律的にコードを実行できる場合に実現可能です。ユーザーは毎回「承認」をクリックする必要はなく、ウォレット契約が設定したルールに従って動作します。

これらの改善はすべてよりフレンドリーなオンボーディングと使用体験に繋がります。あるブログでは、アカウント抽象化によってdAppが非暗号通貨ネイティブのユーザーにとって伝統的なフィンテックアプリのようにスムーズに感じることができると適切に指摘されています。ユーザーは（ガーディアンに連絡したりバックアップデバイスを使用したりと「パスワードをリセット」するのに似た）慣れ親しんだプロセスを通じてアカウントを回復でき、アプリはガスを理解することなく使用できます（複雑さはアプリが引き受けたりもします）。これは非暗号通貨ネイティブな人々にとって重要なことであり、コマンドラインを通じて自分のインターネットを構成するのではなく、アプリアイコンをタップしてサービスを使用するのと同じくらい簡単なものです。

トランザクションのカスタマイズと自動化

アカウントアブストラクションにより、ユーザーは自分のアカウントができることに対してより多くのコントロールを得ることができ、手動の努力や外部サービスの信頼が必要だった複雑なタスクを自動化できます。いくつかの例に触れましたが、いくつかの主な機能を強調しましょう：

一括および複雑なアクション: 伝統的なEOAは一度に1つのトランザクションを提出し、それぞれ別々に確認する必要があります。スマートコントラクトウォレットは、複数のアクションを1つのメタトランザクションにバッチ処理するよう設計できます。例えば、DEXで取引し、その後にレンディングプラットフォームで得たトークンを貸し、そのトークンを転送する一連のステップをアトミックに実行することができます。これにより時間やクリックが節約され、ステップを統合することでガスを節約することが可能です。実際、アカウントアブストラクションの利点の一つとして「複数のトランザクションを一括処理できること」が挙げられており、オーバーヘッドを削減し、手数料を節約できる可能性があります。ユーザーにとって、これは複数のトランザクションを juggling するのではなく、ワンクリック戦略が可能になることを意味します。
事前承認トランザクションと自動化: 特定の条件下で追加の承認なしで特定のトランザクションを許可することができます。これにより、DeFiにおけるストップロスオーダー（価格が閾値に達した場合にウォレットが自動で取引を実行する）や、ブロックチェーンゲーム内で特定のパラメータ内で自動でゲームプレイの動作を実行できるようになります。アカウントがコードとして意思を実行するため、チェーン上での個人的なエージェントを持つようなものです。実際の具体的な利用例として、「自分のアカウントで1年間何もやり取りしない場合、自動的に資金をバックアップウォレットに転送する」というプログラムが考えられます – 一種のデッドマン・スイッチで、相続のメカニズムを提供します。AAがなければ、これは第三者を信頼する必要があります。サービスまたは特別契約の呼び出しを期待するのではなく、自分自身のアカウントで実行することができます。
簡単な資産管理: アカウント抽象化により、“ワンコールで全てのトークンを転送する”といった機能が可能になります。通常、新しいウォレットに移行したい場合、一つずつトークンを送信しなければなりません。スマートウォレットには、一度で全ての資産（ETHやトークン、NFTなど）を別のアドレスに送るメソッドがあり、ウォレットの移行や資産の集約を簡素化します。また、ウォレット自体の所有権変更も可能です。例えば、ウォレットを販売したり、誰かに譲渡することもできます（EOAでは固定されたキーに紐付けられているため、これは簡単ではありません）。
プログラム可能な制限: あなたのアカウントの使用に任意のポリシーを課すことができます。例えば、1日の支出限度額を設定することができます。トランザクションがその合計を超えた場合、ウォレットは翌日までさらなる転送を停止するか、追加の確認を必要とするように設定できます。この種のレート制限は、キーがひそかに不正侵入された場合にすべての資金を失うことを防ぎます。例として、泥棒は1日にあなたの資金の1%しか盗むことができず、注意して対処する時間が得られます。アカウントは特定のトランザクションタイプを制限することも可能です（例えば、“危険なDeFi契約Xを呼び出すことは不許可”など）。

要するに、アカウント抽象化は前例のない柔軟性を提供します。ブロックチェーン開発者のコメントはこう要約しています：EOAを使用するユーザーは“カスタマイズや自動化できないトランザクションに縛られている。すべて1つずつ署名する必要があります”。しかし、アカウント抽象化により“ゲームが変わる”として、ユーザーは“定期的な支払いを設定し、他の自動化の形態に入り込むことができる”、あるいは“一度に複数のアクションを承認することさえも可能”です。それは、マニュアルのスティックシフトの車から、ルートとルールをプログラムできる知能的な自動運転車へ移行するようなものです – 自分ですべての小さなアクションを実行する代わりに、望むものを定義し、システムにそのメカニズムを処理させるという風に変わります。

ガス料金の柔軟性とスポンサーシップ

もう一つの大きな利点は、アカウント抽象化がもたらすガス料金に関する柔軟性です。現在のEthereumでは、すべてのトランザクションに対して自分のアカウントからETHでガス料金を支払わなければなりません。これは多くのユーザーフレンドリーな体験にとって始めの一歩になりません – クレジットカードを使用するたびに、別の通貨で料金を支払う必要があると想像してみてください。

アカウント抽象化はこの制約を解消し、ガスの抽象化を可能にします:

あなたのアカウント（スマートウォレット）は、保有する任意のトークンでガスを支払うように設定できます。例えば、USDCステーブルコインしか持っていない場合、ウォレットのロジック（ペイマスターやDEX統合と連携して）で自動的に少量のUSDCを変換したり、それを使用してマイナー/バリデーターを支払いすることができるため、ETHを全く必要としません。
スポンサー（ペイマスター） があなたのガスを負担することができます。これにより、ユーザーにとってガスレストランザクションが可能になります。あるdAppはアドプションを促進するためにユーザーのトランザクションフィーを負担することを決めるかもしれません – これは、顧客にインセンティブとして送料を負担するビジネスに似ています。このようなことは過去にメタトランザクションを通じて一部可能でしたが、アカウント抽象化はそれを標準化し、より安全にしています。ユーザーはガスが存在することなど気にすることなくブロックチェーンアプリケーションと対話でき、操作が“ただ動作する”という印象を与えます。例えば、初めてのユーザーがアプリがスポンサーするいくつかの無料トランザクションを受け取ることができれば、最初の体験がスムーズになります。
柔軟な料金ロジック: 例えば、現時点で最も安い資産を自動的に使用して料金を支払いたい、または市場レートに応じてETHと他のトークンの間で支払いを選択したい場合、そのすべてのロジックをウォレットの契約やペイマスターポリシーに埋め込むことができます。

ERC-4337スペックはこれを主要な機能と考えており、ペイマスターのおかげでユーザーはもはやネットワークと関わるためにネイティブのETHトークンを保有する義務はありません。これはWeb3に新しく入るユーザーにとって大幅な改善です。Rumble Fishの分析は、アカウント抽象化を通じて、dAppsや他の人々が誰かのガスをプレゼントやプロモーションとして支払うことを強調し、オンボーディングをよりスムーズにすると述べています。私たちはこのようなことで企業がすでに実験しているのを目にします。例えば、Visaがユーザーがクレジットカードや第三者を通じてガスを支払えるようにするためにアカウント抽象化を利用している例が見られ、これにより暗号トランザクションを通常のオンライン購入と感じさせることができます。この種のUXはブロックチェーンアプリケーションを主流向けにするための大きな一歩となるでしょう。

将来への備えと新しい可能性

最後に、アカウント抽象化は、今日何を可能にするかだけでなく、将来のテクノロジーに対するブロックチェーンアカウントの将来性を確保し、まったく新しいアプリケーションのクラスを解放することができます。

ポスト量子暗号技術: 今日のEthereumの署名（ECDSA）は、将来量子コンピューターによって破られる可能性があります。アカウント抽象化を使用することで、すべての署名方法を変更するハードフォークがなくても、アカウントごとに量子対応の署名スキームに徐々に移行することができます。実際、AAは複数の署名スキームが共存することを可能にし、従来のキーを使用するアカウントもあれば、LamportやBLISSのような量子安全な署名を必要とするものもあります。Ethereumの4337は、“量子コンピュータに対応した取引の作成に向けた最初のステップとして見られ”、アカウントの検証を固定されたアルゴリズムから切り離しているためです。
役割ベースのアクセスとモジュール性: アカウントは役割ベースのアクセス制御にプログラム可能です。例えば、“取引キー”を指定し、それだけで取引を行うことが許可されているが、引き出しは許可されていない、または“デプロイキー”が契約をデプロイすることは許可されているが、資金の移動は許可されていないとすることができます。これは組織や詳細な制御を求めるパワーユーザーに役立ちます。
ファーストクラスのマルチシグと共有アカウント: アカウント抽象化はエコシステム全体でマルチオーナーアカウントをファーストクラスの市民にすることができます。これはdAppsとプロトコルがマルチシグアカウントとの相互作用をより簡単にサポートできることを意味します。また、チームや家庭のウォレットがより簡単になり、アカウント契約がN人の人々に所有され、それぞれが特定の権利を持つことができるということを意味します。EOAではこれは簡単ではありません。参考文献では、アカウント抽象化が“チームウォレット”を可能にする使用例について言及し、複数の人々が管理するプログラム可能なガバナンスルールを持つウォレット（ビジネス資金運営やDAO資金に理想的）を指しています。
オンチェーンのアイデンティティと評判: アカウント契約にはロジックを含むことができ、評判スコアやDeFiの許可リストなどを統合することが可能です（例えば、ユーザーが設定を変更するまで特定のプロトコルとの相互作用のみを許可するアカウントなど）。それはまた、特定の資格情報またはNFTを必要としていくつかの機能を解除する識別システムと統合できます。これは、スマートアカウントがウォレットとアイデンティティのハブの両方として機能する領域に融合します。

要するに、アカウント抽象化の利点はセキュリティ、使いやすさ、柔軟性、将来性を網羅しています。これは、自己管理と分散化の原則を犠牲にすることなく、現代のソフトウェアが許す限り暗号アカウントを強力で便利にすることを意味します。多くのEthereumコミュニティの中でそれが次の大きな波の普及を推進するために極めて重要と見なされている理由は不思議ではありません。ある情報源では、アカウント抽象化はEthereumの“マスアダプションへの道の重要なステップ”と広く見られています。

AAが何を可能にするかのイメージを描き出した後、実際の実装とアカウント抽象化がどのように機能しているか、現実世界の例について見ていきましょう。

現実世界のアプリケーションと例

アカウント抽象化は理論的な概念に聞こえるかもしれませんが、すでに実社会で実装され試験されています。次に、その影響を示すいくつかの注目すべき例とシナリオを示します:

スマートコントラクトウォレット（ソーシャルリカバリーとマルチシグ）: Argentウォレットのようなプロジェクトは、スマートコントラクトウォレットの初期の先駆者であり、ソーシャルリカバリーと信頼されたコンタクトを提供しています。Argentのウォレットは（ERC-4337以前でも）ユーザーがキーを失った場合に備えて“ガーディアン”を指名することができました – これはユーザーごとのカスタム契約を介して実現されました。現在、ERC-4337がライブであるため、そのようなウォレットは標準化されたインフラに接続でき、業界全体でより一般的になる可能性があります。Similarly, Gnosis Safe (now called Safe) has been a widely used multi-signature wallet (mostly for teams/DAOs). Safe is essentially an account abstraction use-case (multiple owners controlling one contract account). Safe チームはAAを積極的に受け入れており、彼らはERC-4337を活用するためのプロトタイプさえ開発しており、今後のプロトコールの変更（EIP-7702など）の既存のSafeアカウントをファーストクラスのスマートアカウントに移行するためにどのように役立つかを調べています。これらの例は、個人および組織にとっての強化されたセキュリティウォレットがAAによっての明確な直近の勝利であることを示しています。
DAppsによるガススポンサーシップ: 分散型アプリケーションがユーザーのUXを向上させるためにガス料金を負担する例もあります。例えば、ブロックチェーンゲームや分散型取引所がPaymaster（ERC-4337に基づく）を使用してユーザーがETHをガスに保持せずに取引できるようにするかもしれません – dAppがガスをスポンサーし、少し高いプロトコールフィーやマーケティング費用としてそのコストを回収します。ガスなしのトランザクション体験は新しいユーザーをオンボーディングするのに非常に魅力的です。DeFiプラットフォームは“ETHなしで貸付を開始できます – USDCを直接使用して入金します”と広告できる。BiconomyやOpenGSNのようなウォレットSDKプロバイダーは、歴史的にメタトランザクションフレームワークを提供しています; アカウント抽象化のおかげで、これがよりネイティブかつ安全に行えるようになっています。あるケースでは、Ethereum財団がサポートするプロジェクトが、ユーザーがクレジットカードを使用して間接的に料金を支払うシステムをデモンストレーションしました – そのビザ``` Content: research we mentioned allowed a wallet to pay gas by charging a Visa card, all mediated by the wallet’s logic and a paymaster. While charging a credit card for gas isn’t common yet, the fact it’s possible highlights how far we can abstract the blockchain mechanics away from the user. 研究で指摘したように、ウォレットはビザカードを使用してガスを支払うことができ、そのプロセスはウォレットのロジックとペイマスターによって仲介されます。クレジットカードでガスを支払うことはまだ一般的ではありませんが、この可能性があることで、ブロックチェーンのメカニズムをどれほどユーザーから遠ざけることができるかがわかります。
Recurring Payments and Subscriptions: The concept of automated recurring payments from a self-custodial wallet was practically unheard of before, because an EOA can’t initiate a payment on its own at a future date. With account abstraction, however, auto-payments become feasible. The Visa proof-of-concept on StarkNet is a prime example: they used account abstraction to implement a pull-based payment (the biller could trigger the payment from the user’s wallet on the due date, because the wallet had pre-authorized it). Another hypothetical example: a streaming service could deploy a smart contract that, each month, pings your wallet contract for the subscription fee; your wallet’s code could verify it’s the legitimate service and automatically pay them in, say, a stablecoin – all without you signing in every month. This kind of convenience was typically missing in Web3, potentially forcing users into custodial solutions if they wanted such features. Account abstraction brings it to self-custody.
定期支払いとサブスクリプション: 自己管理ウォレットからの自動定期支払いの概念は、それまでほとんど聞かれることがありませんでした。これは、EOA が将来日付に自ら支払いを開始できないためです。しかし、アカウントアブストラクションにより、自動支払いが可能になります。StarkNet での Visa の概念実証がその好例です。彼らはアカウントアブストラクションを使用して、プルベースの支払いを実行しました（請求者は、ウォレットが事前承認したため、支払期日にユーザーのウォレットからの支払いをトリガーできました）。別の仮想例では、ストリーミングサービスはスマートコントラクトを展開し、毎月ウォレットコントラクトにサブスクリプション料金をピンで通知することができます。ウォレットのコードは、それが正当なサービスであることを確認し、たとえばステーブルコインで自動的に支払います。すべて、毎月サインインする必要はありません。この種の利便性は通常 Web3 には欠けており、そのような機能を望む場合、ユーザーを管理ソリューションに追い込む可能性がありました。アカウントアブストラクションにより、自己管理が可能になります。
“One-Click” Experiences & Composability: Consider an NFT marketplace where buying an NFT might involve multiple steps (approve token, then trade, etc.), or a DAO participation that requires locking tokens then casting a vote. With AA wallets, projects can design flows where the user does a one-click “buy” or “participate” and behind the scenes the wallet contract bundles the necessary steps. We already see this with some DeFi aggregators that do meta-transactions, but with native AA it could be more prevalent and simpler to integrate. This increases composability of dApps – your smart account could interact with multiple protocols in one go, which encourages developers to create richer features without worrying that users will drop off after the first of several transactions.
「ワンクリック」での体験と合成可能性: NFT マーケットプレイスでは、NFT の購入には複数の手順 (トークンの承認、取引など) が含まれる場合や、トークンをロックして投票を行う必要がある DAO 参加が考えられます。AA ウォレットを使用すると、プロジェクトは、ユーザーがワンクリックで「購入」または「参加」し、舞台裏でウォレットコントラクトが必要な手順を束ねるフローを設計できます。これは、メタトランザクションを行う一部の DeFi アグリゲーターで既に見られますが、ネイティブ AA を使用すると、より普及し、統合が簡単になる可能性があります。これにより dApp の合成可能性が向上します。スマートアカウントを使用すると、一度に複数のプロトコルと対話できるため、開発者は、最初の複数のトランザクションの後にユーザーがドロップアウトすることを心配することなく、よりリッチな機能を作成することが奨励されます。
Layer-2 Adoption and Cross-Chain UX: On Ethereum Layer-2 networks like StarkNet and zkSync (which have native AA), users are getting a taste of these benefits from day one. A user on StarkNet, for example, might create their account by deploying a contract (there is an initial one-time cost to deploy your account contract) and thereafter enjoy features like choosing any token to pay fees. As these L2s gain users, the expectation for such convenience will grow, pressuring other chains to adopt similar ideas. Moreover, account abstraction can help with cross-chain experiences. Some in the community talk about “chain abstraction” hand-in-hand with account abstraction. For instance, a smart wallet could abstract which chain an operation happens on – you could initiate an action and the wallet (via relays or bridges) handles getting it executed on the appropriate chain, returning the result to you, without you manually switching networks or holding multiple chain tokens. This is still early-stage, but conceptually a smart account could manage resources on multiple chains if designed to, giving a unified UX.
レイヤー2の採用とクロスチェーン UX: StarkNet や zkSync (ネイティブ AA を備えた) などの Ethereum レイヤー 2 ネットワークでは、ユーザーは初日からこれらの利点を味わうことができます。たとえば、StarkNet を使用しているユーザーは、契約を展開してアカウントを作成し (アカウント契約を展開するための初期の一時費用があります)、その後、料金を支払うための任意のトークンを選択するなどの機能を楽しむことができます。これらの L2 がユーザーを獲得するにつれて、そのような利便性に対する期待が高まり、他のチェーンにも同様のアイデアを採用するプレッシャーがかかります。さらに、アカウントアブストラクションはクロスチェーンエクスペリエンスに役立ちます。コミュニティの一部の人々は、アカウントの抽象化と連動して「チェーンの抽象化」について話しています。たとえば、スマートウォレットは、操作が行われるチェーンを抽象化することができます。アクションを開始すると、ウォレット (リレーまたはブリッジを介して) がそれを適切なチェーンで実行し、結果を返すという仕組みで、ネットワークを手動で切り替えたり、複数のチェーントークンを保持したりする必要はありません。これはまだ初期段階ですが、概念的には、スマートアカウントが複数のチェーン上のリソースを管理するように設計されていれば、統一された UX を提供できます。
Developer Tooling and New Services: A host of new services are popping up to support account abstraction. For example, providers offering Wallet-as-a-Service (WaaS) that handle the deployment of smart wallets for users and manage keys in user-friendly ways (some integrate secure enclaves in phones or cloud backups, etc.). While we won’t promote specific companies, it’s notable that many startups and projects are actively building AA tooling – from SDKs that let any dApp spin up an AA wallet for their users, to specialized paymasters that handle gas conversions. This means the ecosystem is rapidly moving towards making AA seamless. As these tools mature, more apps can adopt AA without reinventing the wheel, and users might use AA without even knowing it (for example, a game might automatically give each user a contract wallet in the background linked to their email login – the user just knows they have a game account, which under the hood is a smart contract wallet tied to their email-authenticated key).
開発者向けツールと新しいサービス: アカウントアブストラクションをサポートする新しいサービスが多数登場しています。たとえば、ユーザー向けのスマートウォレットの展開を処理し、ユーザーフレンドリーな方法で鍵を管理するウォレット・アズ・ア・サービス（WaaS）を提供するプロバイダーがあります（携帯電話に安全なエンクレーブを統合したり、クラウドバックアップを行ったりするものもあります）。特定の企業を宣伝することはしませんが、多くのスタートアップやプロジェクトが AA ツールを積極的に構築していることは注目に値します。これは、任意の dApp がユーザー向けに AA ウォレットを起動できるようにする SDK から、ガス変換を処理する専門的なペイマスターまで様々です。つまり、エコシステムは AA をシームレスにする方向へ急速に進んでいます。これらのツールが成熟すると、車輪の再発明を必要とせずにより多くのアプリが AA を採用できるようになり、ユーザーは気付かないうちに AA を使用しているかもしれません（例: ゲームは、各ユーザーに自動的に契約ウォレットを付与するかもしれません。メールログインにリンクされた背景 - ユーザーはゲームアカウントを持っていることのみを知っており、その裏ではメール認証されたキーに結び付けられたスマートコントラクトウォレットを持っています）。

All these examples reinforce that account abstraction isn’t just a theoretical upgrade; it’s happening now across various fronts, bringing concrete improvements. However, it’s not all sunshine and roses yet. Like any new technology, there are challenges and trade-offs to be aware of. It’s important to examine these to get a balanced view. これらの例はすべて、アカウントの抽象化が単なる理論的なアップグレードではなく、さまざまな分野で実際に起こりつつあり、具体的な改善をもたらしていることを強調しています。ただし、すべてが良いとは限りません。他の新しい技術と同様に、知っておくべき課題やトレードオフもあります。これらを検証して、バランスの取れた見方を得ることが重要です。

Challenges and Limitations of Account Abstraction

アカウントアブストラクションの課題と制限

While account abstraction opens exciting possibilities, it also introduces new complexities and considerations. Here are some of the challenges and limitations to keep in mind: アカウントの抽象化は、エキサイティングな可能性をもたらしますが、新たな複雑性や考慮事項ももたらします。ここに留意すべき課題と制限のいくつかを示します。

Smart Contract Risk: By turning user wallets into smart contracts, we inherently introduce smart contract risk to personal accounts. A bug in the wallet’s code could be disastrous – for instance, a flaw could allow an attacker to bypass security or drain funds. With EOAs, the “code” involved in your account is basically just ECDSA signature verification, which is a well-tested cryptographic primitive. Smart wallets are far more complex. Although the core AA frameworks (like the EntryPoint contract in ERC-4337) are audited, the security of each wallet implementation can vary. As one developer guide noted, when using an AA wallet, you’re “deploying an immutable contract” and if a bug is found, it can be challenging to patch since that contract code can’t be easily changed. Some wallet contracts might include upgradeability or migration features to mitigate this, but that then introduces trust considerations (who can upgrade it?). Diligence in auditing wallet contracts is crucial.
スマートコントラクトのリスク: ユーザーウォレットをスマートコントラクトに変換することで、個人アカウントにスマートコントラクトリスクを内在的に導入します。ウォレットのコードにバグがあると壊滅的な影響を与える可能性があります。たとえば、欠陥によって攻撃者がセキュリティを回避したり、資金を流出させたりする可能性があります。EOA を使用する場合、アカウントに関与する「コード」は基本的に ECDSA 署名検証だけであり、これは十分にテストされた暗号プリミティブです。スマートウォレットははるかに複雑です。コア AA フレームワーク (ERC-4337 の EntryPoint コントラクトなど) は監査されていますが、各ウォレットの実装のセキュリティは異なる場合があります。ある開発者ガイドによると、AA ウォレットを使用する場合、「変更不可能な契約をデプロイしている」ため、バグが見つかった場合、その契約コードを簡単に変更できないため、修正が困難になる可能性があります。これを緩和するために、アップグレード機能や移行機能を備えたウォレット契約もありますが、それにより、誰がそれをアップグレードできるかという信頼の考慮事項が導入されます。ウォレット契約の監査には注意が必要です。
Complexity and New Failure Modes: The AA architecture (with bundlers, paymasters, separate mempool) is more complex than the status quo. This means more components that could fail or be attacked. For example, what if the bundler network is not sufficiently decentralized early on? Could bundlers censor certain UserOps or demand high fees? There’s a risk of centralization if only a few actors become dominant bundlers. Over time, it’s expected that many Ethereum nodes or miners/validators themselves might run bundler software (especially if economic incentives are there), but in early stages, users are trusting that the mempool of UserOps and bundlers are working honestly. The EntryPoint contract is another central trust point – if a vulnerability were found there, it could affect all AA users. The Ethereum community has taken precautions (the EntryPoint can be replaced via an update mechanism if a bug is found, under a multisig governance by devs until full decentralization), but it’s a key piece to watch.
複雑さと新しい障害モード: AA アーキテクチャ (バンドラー、ペイマスター、独立したメモリプールを含む) は、現状よりも複雑です。これは、障害が発生する可能性のあるコンポーネントが増えることを意味します。たとえば、初期にバンドラーネットワークが十分に分散化されていない場合はどうでしょうか?バンドラーは特定のユーザーオペレーションを検閲したり、高額な料金を要求したりする可能性がありますか?中央化のリスクはわずか数人のアクターが主要なバンドラーになる場合に存在します。時間の経過とともに、多くのイーサリアムノードやマイナー/バリデーター自身がバンドラーソフトウェアを実行することが予想されますが（特に経済的インセンティブがあれば）、初期段階ではユーザーはユーザーオペレーションとバンドラーのメモリプールが誠実に機能していると信頼しています。EntryPoint コントラクトは別の中央の信頼ポイントです。ここに脆弱性が見つかった場合、すべての AA ユーザーに影響を与える可能性があります。イーサリアムコミュニティは予防策を講じています（バグが見つかった場合、完全に分散化されるまで開発者によるマルチシグガバナンスの下でアップデートメカニズムを介して EntryPoint を置き換えることができます）が、それは注目すべき重要な部分です。
Resource Costs (Gas and Deployment): Using a smart contract wallet has overhead. There is a one-time deployment cost to create your account (you have to publish a new contract on-chain for each user wallet, unless using a counterfactual deployment pattern where it’s created at first use). This could cost a few dollars in gas on Ethereum mainnet, which might deter some users or require wallets to sponsor that. Additionally, each operation through a smart wallet might be slightly more expensive in gas than a simple EOA transaction because it involves calling the EntryPoint, executing additional code, etc. However, some of this can be offset by batched execution efficiencies. Still, for heavy on-chain activity, those costs add up. This means, at least initially, account abstraction might be more common on Layer-2s (where gas is cheaper) and only for higher-value use cases on Layer-1. The good news is that Ethereum developers are aware of this and are working on protocol changes to make AA more gas-efficient. For example, proposals like “InitCode compression” or other EIPs aim to reduce the cost of deploying and using smart accounts, and in the long run if AA becomes the default, the protocol can optimize for it.
リソースコスト（ガスとデプロイメント）: スマートコントラクトウォレットの使用にはオーバーヘッドがあります。アカウントを作成するために初回デプロイメントコストが発生します（カウンターファクトデプロイメントパターンを使用しない限り、各ユーザウォレットのために新しい契約をオンチェーンに発行する必要があります）。これは Ethereum メインネットで数ドルのガス費用がかかる可能性があり、一部のユーザーを妨げたり、ウォレットがその費用を負担する必要があるかもしれません。さらに、スマートウォレットを介した各操作は、エントリーポイントの呼び出し、追加コードの実行などを伴うため、単純な EOA トランザクションよりもやや高いガス代がかかる可能性があります。ただし、一部はバッチ実行効率向上で相殺できます。それでも、オンチェーンアクティビティが激しい場合があり、コストが積み重なります。これは少なくとも初期の段階では、アカウントの抽象化が Layer-2 (ガスが安価な) でより一般的になり、Layer-1 ではより高価値のユースケースのみになることを意味します。良いニュースは、Ethereum 開発者がこれを認識しており、AA をよりガス効率的にするためにプロトコル変更に取り組んでいることです。たとえば、「InitCode 圧縮」やその他の EIP のような提案は、スマートアカウントのデプロイと使用のコストを削減することを目的としており、長期的に AA がデフォルトになる場合、プロトコルがそれに合わせて最適化できる可能性があります。
Key Management is Still Key (Literally): It’s important to note that account abstraction doesn’t eliminate private keys – it just adds layers around how keys are used. You still ultimately need some form of private key or secret to authenticate as the owner of an account (even if that key is split among multiple parties or stored in hardware, etc.). If a user chooses poor security for their keys, they can still get hacked. AA provides tools like social recovery, but users must actually use them and set them up properly. Some critics point out that many users might stick to default settings, which could be a single key controlling the account contract (basically replicating an EOA, but with more complexity). In such cases, if they never configure guardians or 2FA, they haven’t gained much security – and they might even be at more risk if they don’t understand the new wallet model. In summary, account abstraction greatly improves potential security, but does not guarantee it. Users will need good UX to guide them to safer setups (e.g., prompts to add a guardian or a backup key during wallet onboarding).
鍵管理は依然として重要です（文字通り）: アカウントの抽象化が秘密鍵を排除しないことに注意することが重要です。鍵の使用方法にレイヤーを追加するだけです。最終的には、アカウントの所有者として認証するために、何らかの形式の秘密鍵またはシークレットが必要です（その鍵が複数のパーティ間で分割されている場合でも、ハードウェアに保存されている場合でも）。ユーザーが鍵のセキュリティが不十分な設定を選択した場合でも、ハッキングされる可能性があります。AA にはソーシャルリカバリーなどのツールが提供されていますが、ユーザーがこれを実際に使用し、適切に設定する必要があります。一部の批評家は、多くのユーザーがデフォルト設定に固執する可能性があることを指摘しており、それはアカウント契約を制御する単一の鍵（基本的に EOA を再現しているが、より複雑）が関与します。そのような場合、彼らがガーディアンまたは 2FA を設定しなければ、あまりセキュリティを向上させることができません。新しいウォレットモデルを理解していない場合、さらなるリスクにもさらされる可能性があります。要約すると、アカウントアブストラクションは潜在的なセキュリティを大幅に改善しますが、それを保証するものではありません。ユーザーには、より安全な設定を案内するための良い UX が必要です（例: ウォレットのオンボーディング時にガーディアンまたはバックアップキーを追加するように促す）。
Not Yet Universal: As of 2025, account abstraction via ERC-4337 is available on Ethereum, but it requires wallet providers to support it. If your current wallet (say MetaMask or hardware wallets) doesn’t support creating and managing 4337 smart accounts, you can’t benefit from AA without switching. We are in a transition period where both EOAs and AA accounts coexist. This can cause user confusion and friction. For instance, AA accounts have their own address (which looks like any Ethereum address, but it’s actually a contract). If someone sends ETH to your AA wallet address, that’s fine – it’s an address – but to send ETH out, you’ll be going through the AA flow rather than a simple EOA transaction. Power users might worry about compatibility: “Will this dApp support my
まだユニバーサルではない: 2025年現在、ERC-4337を介したアカウントアブストラクションはEthereumで利用可能ですが、これにはウォレットプロバイダーのサポートが必要です。現在のウォレット(MetaMaskやハードウェアウォレットさえ)が4337スマートアカウントの作成と管理をサポートしていない場合、切り替えなしにAAの恩恵を受けることはできません。我々はEOAとAAアカウントが共存する移行期間にいます。このことがユーザーの混乱や摩擦を引き起こす可能性があります。たとえば、AAアカウントには独自のアドレスがあります (これは通常のEthereumアドレスのように見えますが、実際には契約です)。誰かがあなたのAAウォレットアドレスにETHを送信した場合、それは問題ありません - それはアドレスです - しかし、ETHを送信するには、単純なEOAトランザクションではなく、AAフローを経て送信します。パワーユーザーは互換性を心配するかもしれません。「このdAppは私の


* **インターオペラビリティとマルチチェーン:** スマートアカウントを複数のチェーン（L1、L2s、サイドチェーン）で使用する場合、各チェーンにコントラクトをデプロイする必要があるかもしれません。これが手間になる可能性があります。アカウントのデプロイメントをチェーン間で「複製可能」にする作業が進められていて、どこでも同じアドレスと機能を維持できるようになるでしょう。しかし、それが完全に解決されるまでは、AAを1つのネットワークで使用することは自動的に他のネットワークでも提供されるわけではなく、各チェーンごとに設定が必要かもしれません。

* **既存ユーザーの移行の課題:** すでに何百万ものEOAがあり、中には貴重な資産（ソウルバウンドまたはトランスファー不可能なNFTなど）が含まれています。これを簡単に新しいスマートウォレットに移動することはできません。アカウント抽象化に移行したい場合、それらのユーザーはどうすればよいのでしょうか。一つのアプローチは、Vitalik氏などによって提案されたプロトコルアップグレード、例えばEIP-7702で、アドレスを変えずにEOAがスマートコントラクト機能を「採用」できるようにするものです（次のセクションで詳しく説明します）。しかし、そのようなアップグレードが行われるまでは、ユーザーはAA機能を得るために新しいアカウントを作成しなければならないかもしれません。特に古いアドレスに資産が紐付いている場合、それは負担です。教育上の課題もあります。ユーザーはスマートウォレットに移行する利点を理解し、「壊れていないなら直すな」の考えを持っていることが多いからです。コミュニティはその利点を強調し（おそらくウォレットがワンクリックでの移行ツールを提供することができるかもしれません）。

それらの課題にもかかわらず、イーサリアムコミュニティの全体的な感情はアカウント抽象化の利点が欠点をはるかに上回るということであり、これらの制限の多くは積極的に対処されています。新しい基盤技術が最初は複雑であり、時間が経つにつれて滑らかになるのは珍しいことではありません。初期のスマートフォンは使いにくく、バッテリー寿命が短かったが、今では不可欠でユーザーフレンドリーです。同じように、今日のAAウォレットは新しく異なって感じるかもしれませんが、数年後にはソーシャルリカバリーやガスレストランザクションのような機能がなければ生活できないかもしれません。

そのようなバランスのとれた見方で、アカウント抽象化の未来について展望してみましょう。それはどのように進化し、スマートアカウントを新しい標準にするための発展が期待されているのでしょうか？

## 完全なアカウント抽象化に向けて

イーサリアムにおけるアカウント抽象化—特にERC-4337を介して—は重要なマイルストーンでありますが、それはしばしば最終目的地ではなく、旅の途中の一歩として説明されます。多くのイーサリアムコア開発者が表現しているように、究極のビジョンはプロトコルレベルで「完全なアカウント抽象化」に到達することです。すべてのアカウントがスマートアカウントとなり、古いEOAの概念が完全に消えることです。その実現には、今後数年間でさらなるアップグレードと慎重な移行戦略が必要になることでしょう。ここでは今後の展望を少し見てみましょう。

**1. プロトコルレベルでの統合:** 現在ERC-4337はアプリケーション層で動作し、EntryPointコントラクトを通じてイーサリアムの既存のトランザクションメカニズムを利用しています。長期的には、イーサリアムはアカウント抽象化をプロトコル（Layer 1）に直接統合してプロセスを簡素化することができるかもしれません。これは、スマートコントラクトウォレットがバンドラー間接を使わずにトランザクションを開始できるように、新しいトランザクションタイプを導入したりコンセンサスルールを変更したりすることを意味するかもしれません。実際、以前の提案であるEIP-2938（未採用）は、プロトコルレベルでの新しい「AAトランザクション」タイプを追加することを試みました。コミュニティはまず4337アプローチを選びましたが、最終的にはもっと深い変更を検討しています。AAをネイティブに統合することにより、EthereumはUserOpsのための別のメンブロックプールが不要になり、プロトコルコードがEntryPointのロジックをより効率的に処理できるため、ガスコストを削減できるかもしれません。最近のアイデアとして、「統合メンブロックプール」というもの（提案中のRIP-7560として議論）があり、UserOpsを通常のトランザクションと一つのプールに統合し、よりガス効率的に実行できるようにしようとしています。技術的な話ですが、簡潔なアーキテクチャと低コストという成果をもたらします。

**2. EOAからスマートアカウントへの移行:** 完全なアカウント抽象化を達成するには、新しいEOAの作成を完全に停止する必要があります。すべての新しいアカウントはデフォルトでスマートアカウントになります。これは、MetaMaskのようなウォレットソフトウェアが、ユーザーがオンボードする際に純粋な鍵アカウントの代わりに4337スマートウォレットを単に作成することで実現することができます。これにより、ユーザーは気付くことなくコントラクトアカウントを持つかもしれません。既存のEOAの移行が難しい部分です。現在進行中のアプローチの一つは、2025年に「Pectra」と命名される可能性のあるネットワークアップグレードの一部として期待されているEIP-7702です。EIP-7702は、EOAから直接スマートコントラクトコードをアドレスから実行できるようにするために設計されています。これはEOAが「デリゲーション」コントラクトを指定することによって機能します—基本的にEOAにスマートロジックの一部を添付します。誰かがEOAと対話する際、ネットワークは関連するコントラクトコード（デリゲートコールのような）を実行し、EOAがコントラクトであったかのように振る舞います。この機能により、EOAとコントラクトアカウントの線引きがぼやけ、「デリゲートコール」のように機能するスマートコントラクトモジュールを追加して、マルチシグ、ソーシャルリカバリーなどの機能をアドレスや資産を移動させることなく使えるようにします。いわば、古い車に最新のコンピュータ支援エンジンをレトロフィットするようなものです。

**3. 単一の秘密鍵制御の段階的廃止:** 真のアカウント抽象化を達成するために、イーサリアムはアカウントがスマートアカウントに転換された場合、元の鍵をトランザクションの署名に直接使用できなくなるルールを導入する可能性があります。興味深い提案としてEIP-3607があり、アカウントがコントラクトコードを持つ場合、そのアカウントは通常のトランザクションを拒否すべきだとしています（それらはおそらく旧鍵からのものと想定されます）。つまり、EOAをスマートアカウントに変換すれば、後戻りはできません—コントラクトが今は指揮を執っており、プライベートキーだけで契約のルールを回避して資金を移動させることはできません。このような変更は、ユーザーを孤立させないために慎重に計画する必要がありますが、「EOAのない終盤」を示すものです。また、複数の署名スキームが許可される可能性があります: あなたのアカウントが電話のバイオメトリック（指紋にリンクされているSecure Enclaveのキーなどを使用するかもしれません）で認証できるようにし、バックアップとしてハードウェアキーも持っていることを想像してみてください。

**5. アプリケーションでの広範な採用:** より多くのdAppsとユーザーがAAに移行するにつれて、創造的な利用が爆発的に増えることが予想されます。DeFiプラットフォームはAAウォレットに特別な機能を提供するかもしれません（例えば「AAウォレットを使用すると、UIから直接条件付き注文を設定できます」など）。ブロックチェーンゲームはユーザー署名の摩擦を減らすかもしれません。DAOガバナンスの新しいパラダイムも期待できます。

**6. 他のブロックチェーンの追随:** イーサリアムが先頭に立っているが、他のチェーンも注目しています。StarkNetやzkSyncについて話しましたが、ポルカドットやコスモスのネットワークでは、「スマートキー」や柔軟なアカウントの概念が浮上しています。例えば、ポルカドットはプロトコルレベルで複数の友人アカウントを持つソーシャルリカバリメカニズムを設定することを許可しています。アカウント抽象化が多くのプラットフォームで標準になる可能性があります—それぞれがユーザーのアカウントのセキュリティと実行ロジックを調整できるコアアイデアを実装しています。このようなクロスポーリンネーション（交差受粉）により、数年後には「アカウント抽象化」というフレーズはあまり使われず、単にスマートアカウントまたはアカウントと呼ばれることになるでしょう。

要約すると、アカウント抽象化の未来は、すべての暗号アカウントをデフォルトでスマート契約と同じほど強力にすることを目指しており、古いEOAの概念は徐々にサンセットされます。そこに到達するには、慎重なアップグレード（EIP-7702など）が含まれます。内容：強制的に一晩で切り替えさせることはできませんが、モメンタムはすでに存在しています。Ethereumの開発者たちは、最終的に大多数のユーザーがスマートアカウントに移行し、セキュリティと使いやすさの利点を享受し、プロトコルがそれらの仮定に基づいて最適化できるロードマップを描いています（例えば、いつの日か、EthereumがPaymasterなどを全員が使用するようになればETHで必ずしもガスを支払うという概念を捨てることができるかもしれませんが、それは推測で遠い未来の話です）。

## 最後の考察

アカウントアブストラクションは、ブロックチェーンアカウント管理におけるパラダイムシフトを表しています。ユーザーがスマートコントラクトを彼らのアカウントとして活用できることで、過去の厳しい制限を破り、仮想通貨の使用を伝統的なバンキングアプリよりも簡単に、あるいは同等に簡単にしながら、より大きなセキュリティ制御をユーザーに与える未来を開きます。もはや一つの鍵を失っただけで取り返しのつかない悲劇にはならず、手動で全ての操作に署名する必要も、dAppsを使用するために余分なETHを保持する必要もありません。アカウントアブストラクションがあることで、ソーシャルリカバリー、多重署名セキュリティ、自動支払い、一括取引、ガスフリーの使用などの機能がハックや夢ではなく、標準的なツールボックスの一部になりつつあります。

実用的に言えば、アカウントアブストラクションは、広範囲な仮想通貨の普及における2つの最大の障壁であるユーザー体験と安全性に直接対処するため重要です。それは柔軟性（カスタムウォレットルール、任意の認証方法）と包摂性（他の人に料金を支払わせる、簡単なログイン方法を使う、間違いからの復活）を提供しつつ、非カストディアルの精神を犠牲にしません。この技術はWeb3をユーザーフレンドリーにするための基盤となる部分です。Ethereumのリーダーシップやコミュニティの多くが、その重要性をエコシステムの成功に不可欠だと考えているのは示唆に富んでおり、もし今日のウォレットのUX悪夢とセキュリティの落とし穴を排除しなければ、仮想通貨は数十億のユーザーに届くことはないという感覚があります。アカウントアブストラクションはその解決策の大部分です。

現在、これはEthereum上のERC-4337や、さまざまなLayer-2ネットワークでのネイティブ実装で、その初期段階が見られます。来るべき数年間では、よりシームレスな統合が期待されており、あなたが分散型アプリを使う際、それがバックグラウンドで「アカウント」がスムーズに人気を整えてくれているスマートコントラクトだと気付かないうちに使うかもしれません。ウォレットプロバイダ、dApp開発者、ユーザー全てが利益を得ることができます：摩擦の少ない、より多くの可能性。

もちろん、この新しいモデルを採用する際には注意が必要です。スマートコントラクトウォレットは注意深く構築・監査されるべきであり、ユーザーもソーシャルリカバリーなどの新機能について教育を受けるべきです。しかし、それは暗号エコシステムの安全性と利便性をもたらすという利点に比べて管理可能な課題です。

締めくくりとして、アカウントアブストラクションはブロックチェーン技術の成熟への一歩として見ることができます。インターネットがコマンドラインインターフェースから現在のユーザーフレンドリーなウェブへと進化したように、ブロックチェーンも生のキー管理の時代からスマートアカウントの時代へと進化しています。それはインフラストラクチャ内で起こる静かな革命ですが、その効果はユーザーに直接感じられます：より安全な資金、より簡単なログイン、そしてデジタル資産と対話するより強力な方法。技術が発展し続けるにつれて、「パスワードを忘れた」や「このアプリを24時間認可」などの機能があなたの仮想通貨の語彙に組み込まれることに驚かないでください。それがアカウントアブストラクションの仕事であり、仮想通貨が他のデジタルサービスと同じように自然に感じられつつ、私たちが最初にブロックチェーンに引かれた自由と主権を依然として提供してくれるのです。

暗号ウォレットの革命： アカウント抽象化のすべてを変える方法

従来のアカウントモデル：EOAs 対 スマートコントラクトアカウント