ベア市場が猛威を振るう中でも、暗号資産が定着しつつあることを疑う人はほとんどいません。たとえば、MetaMaskのようなウォレットはすでに数百万人のユーザーを誇っています。しかし、それでもなお、「次の10億人のユーザーをweb3に引き込むにはどうすればいいのか？」という問いは残り続けています。
誰に聞くかによって答えは異なりますが、ある点については全員が同意しています。特に、ブロックチェーンアプリケーションを利用するユーザーのエクスペリエンスを改善する必要性については、異論がありません。web3をより使いやすくしなければ、人々が毎日使っているweb2アプリから乗り換える動機はほとんどありません。
「アカウント抽象化（Account Abstraction）」は、Ethereumにおけるユーザーインタラクションを改善しようとする提案であり、暗号資産コミュニティでの議論の的となっています。しかし、「アカウント抽象化とは一体何なのか？なぜ気にする必要があるのか？」と思っている方もいるかもしれません。
この記事は、アカウント抽象化の過去・現在・未来を文脈の中で整理し、その全体像を理解するためのものです。アカウント抽象化に関するあらゆる疑問——誰が、何を、なぜ、どのように、いつ——に答えていきます。
主要なポイントの概要：
プログラマブルなセルフカストディアルアカウント（「スマートアカウント」）は、新規ユーザーがweb3エコシステムにオンボーディングする際の摩擦を軽減できます。しかし、Ethereumの設計上の制約により、スマートアカウントの広範な普及と利用が妨げられています。
アカウント抽象化は、トラストレスでセンサーシップ耐性を持つスマートアカウントの広範な普及への道を開く重要な変更をもたらします。アカウント抽象化の実装にはさまざまなアプローチが検討されており、それぞれに独自のメリットとトレードオフがあります。
MetaMaskは、パーミッションレスなイノベーションプラットフォームであるMetaMask Snapsを通じて、アカウント抽象化の普及を支援しています。MetaMask Snapsを使えば、開発者はMetaMaskを拡張し、世界中の暗号資産ユーザーにアカウント抽象化のメリットをもたらすことができます。
アカウント抽象化とは何か？
web3における他の新しいコンセプトと同様に、アカウント抽象化は定義が難しい概念です。しかし、Ethereumにおけるアカウント抽象化の議論に関連するさまざまな用語を紐解くことで、より深く理解することができます。
抽象化（Abstraction） (名詞)：コンピュータサイエンスにおける（やや複雑な）用語で、大まかに言えば、システムやアプリケーションに関する情報を隠蔽することで、バックグラウンドで動作するプロセスの知識が少なくても利用できるようにすることを意味します。また、*「システムの複雑さを隠蔽し、操作を容易にするインターフェースを提供するプロセス」*とも定義されます。
アカウント（Account） (名詞)：トランザクションの送受信や他のオンチェーンアカウントとのインタラクションが可能な、ブロックチェーン上のユーザーの表現。Ethereumには2種類のアカウントがあります：外部所有アカウント（EOA）とコントラクトアカウント（別名「スマートコントラクト」）。
2a. 外部所有アカウント（EOA）：MetaMaskのようなウォレットソフトウェアを使用して生成され、公開鍵と秘密鍵の暗号ペアによって管理されるEthereumアカウント。EOAは「アクティブ」（トランザクションを開始し、EVM実行のガス代を支払うことができる）です。ただし、Etherの送金やコントラクトとのインタラクションなど、基本的な操作の実行に限定されています。
2b. コントラクトアカウント：スマートコントラクトとしてデプロイされ、秘密鍵ではなくコードに書かれたロジックによって制御されるEthereumアカウント。コントラクトアカウントは「パッシブ」であり、EOAからのトランザクションに応答する形でのみトランザクションを送信でき、ガス代を支払うことはできません。ただし、プログラマブルであり、アドレスに保存されたコードに応じて任意のロジックを実行できます。
ウォレット（Wallet） (名詞)：Ethereumアカウントの資金を管理するためのインターフェース。ウォレットの動作は、どのタイプのアカウントに紐付けられているかによって異なります。MetaMaskのようなEOAベースのウォレットでは、トランザクションを承認するために秘密鍵が必要です。一方、スマートコントラクトウォレットはコントラクトアカウントに紐付けられており、任意のロジックを使用してトランザクションを承認できます（例：マルチシグスキームの使用）。
これらの定義を踏まえた上で、アカウント抽象化を定義することができます。
アカウント抽象化の定義
アカウント抽象化は、Ethereumアカウントの管理と動作の柔軟性を高めるための提案です。これは、アカウントコントラクトを導入することで実現されます。アカウントコントラクトとは、ユーザーのEthereumアカウント（現在はスマートアカウントと呼ばれる）を定義・管理する特定目的のスマートコントラクトです。
アカウント抽象化により、セキュリティのために秘密鍵のみに依存するのではなく、スマートコントラクトウォレットを使用することで、資金へのプログラマブルなアクセスが可能になります。これは、スマートアカウントにコインの使用やアセットの転送に関するカスタムルールを設定できるためです。
では、「抽象化」はこれらすべてにどのように関係するのでしょうか？
ネットワークレベルの観点から見ると、「アカウント抽象化」とは、アカウントタイプの詳細がEthereumプロトコルから見えなくなることを意味します。すべてのアカウント（セルフカストディアルアカウントを含む）は単純にスマートコントラクトであり、ユーザーは個々のアカウントの管理・運用方法を自由に決定できます。
ユーザーレベルの観点から見ると、「アカウント抽象化」とは、Ethereumアカウントとのインタラクションに関する特定の技術的詳細が、より高レベルのインターフェースの背後に隠蔽されることを意味します。これにより、ウォレットの設計が改善され、web3アプリケーションの使用における複雑さが大幅に軽減されます。
この説明が必要なのは、アカウント抽象化に関する混乱が、(a) 何が抽象化されているのか、(b) どこで抽象化が行われるのかを知らないことから生じているためです。アカウントは必ずしもユーザーから抽象化されるわけではありません（プロトコルから抽象化されるとしても）。資金を受け取るためのウォレットアドレスと、自分だけが資金を使えることを保証する署名鍵は引き続き存在します。
ユーザーの観点からすると、アカウント抽象化とは、ブロックチェーンとのインタラクションに関する一部の詳細を抽象化するスマートアカウントを使用するようなものです。参考として、初めてdappを使用するユーザーの視点から見たインタラクションの様子を示します：
アカウント抽象化により、ウォレット開発者はこれらのプロセスをバックグラウンドで処理し、web3の使用体験を簡素化するシステムを構築できます（TL;DR：ウォレットが「見えなく」なる）。ユースケースとしては（後ほど詳しく説明します）、シードフレーズ/秘密鍵の保管、トランザクションのガス代の支払い、さらにはオンチェーンアカウントの自分での設定が不要になることなどが挙げられます。
アカウント抽象化のメリット
前述のとおり、アカウント抽象化はweb3ウォレットの使用やdappとのインタラクションに伴う摩擦のほとんどを取り除きます。これにより、web3は初心者から経験者まで、すべてのユーザーが同じレベルの柔軟性、セキュリティ、使いやすさを享受できるというweb2の理想に近づきます。
特に、アカウント抽象化はセルフカストディの未来に大きな影響をもたらします。アカウントコントラクトが提供する機能により、web3ウォレットの使用は、銀行を信頼する必要なく、銀行口座やアプリケーションを使用するような感覚になります。
以降のセクションでは、アカウント抽象化のさまざまな側面に触れ、それらがEthereumの使用体験をどのように改善するかについて説明します。具体的には、署名の抽象化（Signature Abstraction）、手数料の抽象化（Fee Abstraction）、*ノンスの抽象化（Nonce Abstraction）*について説明します。
署名の抽象化
現在、EOAからのトランザクションが有効であるためには、楕円曲線デジタル署名アルゴリズム（ECDSA）を使用してアカウントの秘密鍵で生成された署名が必要です。これにより、ほとんどのEOAはシンプルなセキュリティモデルを持っています：秘密鍵がユーザーの手元にある限り、資金は安全です。しかし、いくつかの制限もあります：
EOAのセキュリティ確保は非常に難しく、悪意のある攻撃者は常に秘密鍵を侵害する新しい方法を進化させています。 MetaMaskでは、フィッシング、ソーシャルエンジニアリング、スプーフィング、マルウェアインジェクション、および同様の攻撃がweb3のユーザーセキュリティに与える課題を直接目の当たりにしてきました。
セルフカストディは極限スポーツのように感じられることがあります。 通常の銀行口座とは異なり、シードフレーズ/秘密鍵を紛失した場合、EOAウォレットを「回復」することはできません。これは、何の手段もなくEthereumアカウントに保有するアセットを完全に失うという意味合いに向き合わなければならない新規ユーザーにとって大きな課題となります。
署名の抽象化は、ノンカストディアルアカウントのデフォルトの承認メカニズムとしてECDSA署名を削除することで、これらの問題を解決します。その代わりに、ユーザーはウォレットがトランザクションを開始するための承認に関するカスタムルールを定義できます。言い換えれば、あなた自身がトランザクションの有効性の意味を決定できます。
署名の抽象化を実装することで、より高度な承認スキームの可能性が開かれます。これにより、web3ウォレットの使用は、web2バンキングアプリケーションと同様、あるいはそれ以上の体験になります。いくつかのユースケースを紹介します：
トランザクション制限： スマートアカウントに紐付けられたウォレットは、金額が事前設定された制限を超えた場合、トランザクションを拒否したり（または追加の承認を求めたり）することができます。聞き覚えがありますか？当然です——銀行はすでに、詐欺、不正使用、その他のセキュリティ上の理由からアカウントやクレジットカードを保護するためにこれを行っています。
マルチパーティ承認： アカウントの部分的な制御を信頼できる関係者、いわゆる「ガーディアン」に委任することができます。ガーディアンは友人、家族、サービスプロバイダー、または自分が所有する別のデバイス（例：ハードウェアウォレット）にすることができます。これにより、スマートアカウントから資金を引き出すトランザクションにガーディアンの承認を要求することで、ウォレットにweb2スタイルの多要素認証（MFA）を有効にすることができます。
鍵のローテーションと失効： スマートアカウントを使用すると、以前の鍵が紛失または盗難にあった場合に新しい署名鍵を生成できます。追加のセキュリティとして、回復プロセス中にガーディアンにアカウントをフリーズさせ、鍵のローテーション/失効フロー（つまりソーシャルリカバリー）の承認を要求することができます。これは、クレジットカードを紛失/盗難された場合に、銀行口座へのアクセスを失うことなくカードをフリーズできる仕組みに似ています。
トラステッドセッション： ブラウザでdappを操作する際に、すべてのアクションを承認しなければならないことが煩わしいと感じていますか？それなら朗報です！スマートアカウントで特別な「セッションキー」を作成し、dappが特定の期間、自動的にトランザクションに署名できるようにすることができます。これにより、ウォレットのポップアップに煩わされることなく、ブロックチェーンゲームのプレイなど、dappとのインタラクションが可能になります。
大まかに言えば、セッションキーはアカウントとdappの間のインタラクションを制御するスマートコントラクトに基づいています。セッションキーの制御は常にあなたが持っており、残高からいくら引き出せるか、どの関数を呼び出せるかなど、dappの署名権限を規制することができます。
自動支払い： セッションキーのアイデアと同様に、事前に定義されたルールに従って、サービスプロバイダーがスマートアカウントから資金を「引き出す」ことを承認できます。これにより、web3ウォレットで定期支払いやサブスクリプションの設定が可能になります。EthereumアカウントでNetflixのサブスクリプションや公共料金を支払うことを想像してみてください。
手数料の抽象化
現在、すべてのEthereumトランザクションには、送信元のEOAが実行のためにいくら支払う意思があるかを示す「ガス代」が必要です。ガス代はEthereumのネイティブトークンであるEtherで表示されます。これは特に、トランザクションを送信する前にETHを調達する必要がある新規ユーザーにとって問題となります。
アカウント抽象化はガス代の支払い義務をなくすわけではありませんが、ユーザーがガスをいつ、どのように支払うかの詳細を抽象化します（手数料の抽象化）。例えば、アカウント抽象化は、別のアカウントがユーザーのトランザクションのガス代を負担する「スポンサード・トランザクション」を可能にします。スポンサード・トランザクションのメリットをいくつか紹介します：
ETH以外でのガス支払い： ウォレット内のERC-20トークンでトランザクション手数料を支払えたらと思ったことはありませんか？スポンサード・トランザクションを使えば、ETHを持つリレイヤーにトランザクションのコストを立て替えてもらい、DAIやUSDCなどの別のトークンで返済することができます。
ガスレス・トランザクション： dapp開発者はトランザクションをスポンサーし、新規Ethereumユーザーのオンボーディングの摩擦を最小化できます。「ガス」について何も知らなくてもweb3アプリを使用でき、web2アプリが提供するのと同じワンクリック体験を楽しむことができます。
ソーシャルログイン：dappがあなたの代わりにコントラクトウォレットをデプロイすることで、オンチェーントランザクションを送信する前にウォレットを設定するという手間を解消できます。さらに嬉しいことに、ウォレットは認証インフラ（例：Web3AuthやWebAuthn）を使用して、メールアドレスやFacebook/Twitterアカウントなどの既存の認証情報でweb3アカウントを作成できるようにすることができます。
ノンスの抽象化
Ethereum上のスマートアカウントにはもう一つの特別な機能があります：トランザクションのバッチ処理です。バッチ処理されたトランザクションにより、複数の操作を1つのオンチェーントランザクションにまとめ、dappとのインタラクションのコストと複雑さを軽減できます。トランザクションのバッチ処理が重要な理由を説明します：
EOAには「ノンス」と呼ばれる値が保存されており、送信したトランザクションの数を示します（トランザクションカウンターのようなものです）。新しいトランザクションが有効であるためには、ノンスを厳密に1増加させる必要があります——このルールにより、他の誰かが同じトランザクションを「リプレイ」して資金を盗むことを防ぎます（はい、実際に起こりえます）。
しかし、落とし穴があります。ノンスにより、トランザクションを先入れ先出し（FIFO）方式で処理しなければなりません。ノンスがそれぞれ0と1のトランザクションAとBがあるとします。この場合、トランザクションAを送信し、Bを送信する前に確認（実行の確認）を待つ必要があります。
Aがまだ保留中の状態でBを送信すると、ノンスが規定の範囲（EOAの現在のノンス + 1）を超えるため、単純に拒否されます。実際、これがウォレット使用時に「スタックしたトランザクション」が発生する大きな原因の一つです。
ノンスの抽象化により、カスタムのリプレイ保護メカニズムを作成できます（Ethereumプロトコルがトランザクションに厳格な順序を強制する代わりに）。例えば、複数のトランザクションを並行して処理できるノンススキームを持つことができます。これにより、詰まった/スタックしたトランザクションの問題が解決され、dappとのインタラクションが大幅に改善されます。
ただし、ノンスの抽象化は実際には実装が難しく、トランザクションハッシュの一意性など、セキュリティとUXにとって重要な特定の不変条件を壊す可能性があります。ここでトランザクションのバッチ処理が登場します：
スマートアカウントは複数のトランザクションを一度に処理できるため、複雑なノンス抽象化スキームの必要性はほぼなくなります。先ほどの例に戻ると、トランザクションAとBは、Uniswapでのアセットスワップのような単一の仮想的な操作の一部に過ぎないと考えることができます：
トランザクションA：Uniswapコントラクトがトークンにアクセスすることを承認する
トランザクションB：トークンスワップを完了する
トランザクションのバッチ処理により、承認とスワップのワークフローを1つのトランザクションにまとめることができます。結果：dapp使用時のガス代の削減と待ち時間の短縮。素晴らしいですよね？
アカウント抽象化の「方法」
この時点で、アカウント抽象化によりユーザーアカウントにカスタム機能と承認ポリシーを追加できることはすでにご存知でしょう。しかし、それがどのように可能なのかについてはまだ説明していません。このセクションでは、Ethereum上で抽象化を実装するさまざまなアプローチについて説明します（あまり興味がない場合は、次のセクションにスキップしても構いません）。
アカウント抽象化を実現する一般的に認められた方法は2つあります：(a) EOAにEVMコードを実行させること、(b) スマートコントラクトがトランザクションを開始できるようにすること。そのため、多くのアカウント抽象化の提案は、EOAをスマートコントラクトのように動作させるか、コントラクトアカウントをEOAのように機能させることを目指しています。
これにより、自然といくつかの疑問が生じます：
「これらのアプローチは具体的にどう違うのか？」
「どのアプローチを採用するかが重要なのはなぜか？」
アカウント抽象化：アプローチ#1（コードを実行するためのEOAのアップグレード）
EOAにコードを実行する能力を与えることで、ユーザー制御のアカウントに複雑な機能を追加できます。これによりEOAが強化され、スマートアカウントへと変換され、ネイティブなアカウント抽象化への道が開かれます。重要なのは、このアプローチにより、新しいコントラクトアカウントをデプロイするコストをかけずにプログラマブルウォレットのメリットを享受できることです。
EOAをコントラクトアカウントにアップグレードするアプローチの中には、EOAトランザクションのデータペイロードをEVMバイトコードとして扱うものがあります。また、EOAの制御を、EOAの代わりにトランザクションを行う特別なアカウントコントラクトに委任するものもあります。後者の場合、同じアカウントコントラクトを異なるEOAで再利用でき、異なるコントラクトウォレット実装の必要性を減らすことができます。
以下は、「EOAをプログラマブルにする」陣営のさまざまなアカウント抽象化提案を、主要な機能と実装状況とともに示したインフォグラフィックです：
アカウント抽象化：アプローチ#2（スマートコントラクトのアップグレード）
このアプローチでは、コントラクトアカウントをアップグレードして、トランザクションを承認し、ガス代を支払えるようにします（EOAと同様に）。これにより、EOAとして機能できる「強化されたコントラクト」（つまりアカウントコントラクト）を導入することで、アカウント抽象化を実現する別のルートが提供されます。さらに、Ethereumの差し迫った問題、つまりプロトコルレベルでのコントラクトウォレットのサポート不足を解決します。
実は——一部のスマートコントラクトウォレットはすでに存在しており、アカウント抽象化の多くのメリットを提供しています。しかし、Ethereumはスマートコントラクトを「二級市民」として扱い、すべてのトランザクションをEOAから開始することを要求するため、これらのウォレットの使用は非常に困難です。
この制限は、スマートコントラクトウォレットがMetaMaskのようなEOAウォレットのトラストレス性とセルフカストディアルな性質を欠いていることも意味します。参考として、スマートコントラクトウォレットの作成と使用のフローを考えてみましょう：
新しいコントラクトアカウントをデプロイする
ウォレットコントラクトの関数を呼び出すトランザクションを送信する
問題はすでに明らかです：2つのウォレットを管理する必要があります。なぜでしょうか？ウォレットのデプロイコストと、その後必要な関数の呼び出しコストをカバーするために、（ETHで事前に資金を供給された）EOAが必要だからです。
ここでリレイヤーの登場です：手数料と引き換えにウォレットのトランザクションを支払うことができるEOAです。スマートコントラクトウォレットプロバイダーは、ユーザーのトランザクションを補助するためにリレイヤーを運営することがよくあります。つまり、リレイヤーは自分のウォレットからETHを支払ってトランザクション手数料をカバーし、法定通貨や他のトークンなど別の形でコストを回収します。
このシステムはほとんどの場合うまく機能します：ガスの支払いの複雑さをあまり気にせずにコントラクトウォレットを作成・使用できます。しかし、リレイヤーがトランザクションを検閲したり改ざんしたりしないことを信頼する必要もあります。
しかし、これは暗号資産の世界であり、私たちはトラストレスなシステムを好みます。
コントラクトアカウントがトランザクションを承認し、ガス代を支払えるようにすることで、アカウント抽象化はスマートコントラクトウォレットの作成と使用のプロセスをよりトラストレスにします。具体的には、リレイヤーを運営する誰でもあなたの代わりにトランザクションを実行できるようになります。トランザクション実行後にリレイヤーがウォレット残高から資金を差し引くことを承認するメッセージに署名するだけです：
スマートコントラクトウォレットの使用フローは少し異なります：
ウォレットコントラクトのデプロイ？カウンターファクチュアルデプロイメントワークフローを使用することで、コントラクトアカウントをデプロイする前に資金を送り、ウォレットの残高からリレイヤーのEOAにデプロイコストを支払うことができます。
ウォレットコントラクトとのインタラクション？オフチェーンでメッセージに署名し、リレイヤーにアカウントコントラクトへの呼び出しを行わせます。メッセージには、アカウントコントラクトがリレイヤーのガスコストを払い戻す指示が含まれます。
トラストレスでセンサーシップ耐性のあるスマートアカウントを実現するというこのアイデアは、このカテゴリの多くのアカウント抽象化提案の基盤となっています。例えば、これまでで最も人気のあるアカウント抽象化提案であるERC-4337は、ユーザーがコントラクトウォレットのトランザクションを処理のために送信できる代替メモリプールを導入することで、リレイヤーを分散化します。
この場合、リレイヤー（「バンドラー」と呼ばれる）はスマートアカウントのトランザクションを実行するために競争でき、検閲やウォレットプロバイダーへの過度の依存のリスクを軽減します。以下は、「スマートコントラクトにEOAの機能を与える」陣営のさまざまなアカウント抽象化提案を、主要な機能と実装状況とともに示したインフォグラフィックです：
アカウント抽象化の未来について
Vitalik Buterinが最初にコンセプトを提唱してから数年が経った今でも、アカウント抽象化の最善の実装方法については意見の相違があります。例えば、EIP-3074とEIP-5003を実装すれば、既存のEOA（MetaMaskユーザーを含む）をスマートアカウントにアップグレードできます。しかし、これらの提案はハードフォークを必要とし、コミュニティがより緊急のアップグレードに集中していることを考えると、現時点では実現が難しいように思われます。
対照的に、EIP-4337はEthereumプロトコルへの大規模な変更を必要とせずにアカウント抽象化を実装するため、幅広い支持を得ています。しかし、現在EOAベースのウォレットを使用しているユーザーにとっては、EOAから新しくデプロイされたコントラクトアカウントにアセットを移動する必要があり、今日のEthereumの高いガス代を考えると、潜在的に複雑でコストのかかるプロセスとなります。
MetaMaskでは、アカウント抽象化が新しいweb3ユーザーにシームレスなオンボーディング体験を提供するための鍵であると考えています。また、EOAでは暗号資産の普及を保証できないことも認識しています（Ethereum Foundationの研究者Yoav Weissが「次の10億人のユーザーは紙に12の単語を書き留めることはない」と端的に表現しているように）。
そのため、MetaMaskウォレットのユーザーが知って愛用している体験を損なうことなく、アカウント抽象化のメリットを提供する方法を考え始めています。この取り組みの一環として、MetaMask Snaps——開発者が既存のMetaMaskインフラの上にカスタム機能を構築できるパーミッションレスなイノベーションプラットフォーム——に注目しています。
Snapsを使用することで、開発者はMetaMaskウォレットの機能を拡張し、さまざまなアカウント抽象化のユースケースをサポートできます。セッションキーから、MetaMaskで構築された完全なスマートアカウント統合まで——すべてSnapsで構築されており——開発者がMetaMaskを使用してユーザーのアカウント抽象化へのアクセスを民主化するという課題に立ち向かっているのを目の当たりにしてきました。
「完璧を善の敵にするな」 — ヴォルテール
現在のアカウント抽象化の提案は、多少不完全であるとしても、Ethereum上でトラストレスでセンサーシップ耐性のあるスマートアカウントを実現に向けた大きな一歩であり、十分な支持に値します。私たちの仲間であるTaylor Monahanの言葉を借りれば、「リリースされた半分の解決策は、リリースされていない完璧な解決策よりも優れている」のです。
だからこそ、アカウント抽象化に関する次の記事では、ERC-4337の詳細を深く掘り下げていきます。特に、web3開発者がMetaMaskを使って、1行のコードずつ、アカウント抽象化の未来を構築し、次の10億人のユーザーをオンボードする方法について説明します。
お楽しみに！
Patrick McCorry、Simon Brown、Mirko Garozzo、Christian Montoya、Oliver Renwick、Megan Diasの各氏には、この記事の初期草稿へのフィードバックに感謝します。また、プロジェクトの初期段階でガイダンスとサポートを提供してくれたClarissa WatsonとFrancesco Andreoliにも感謝の意を表します。
AIによる翻訳です。エラーが含まれている可能性があります。常に情報を確認してください。
