アカウントの要約：オンチェーンエコシステムが買い手市場への移行を示す兆し
TechFlow厳選深潮セレクト
アカウントの要約：オンチェーンエコシステムが買い手市場への移行を示す兆し
本稿では、アカウント抽象とERC-4337について紹介し、アカウント抽象の応用とWeb2アカウント体系の発展に基づいて、将来のWeb3アカウント体系の進化およびトラフィックエントリーポイントの帰属を推測する。
Web3業界の深掘り報道に専念し潮流を洞察著者：CloudY, Jam
ウォレットアカウントはWeb3に入る上で不可欠な要素であり、ビットコインネットワークのUTXOモデルとイーサリアムネットワークのアカウントモデルは、長年にわたり優劣が比較されてきた。もちろん、両モデルにはそれぞれ長所があり、単純にどちらが優れているとは言えない。むしろ、どちらがどのシナリオに適しているかという話である。
しかし実際には、比較対象として使われるイーサリアムのEOAアカウントはやや原始的な製品である。具体的には：
• アカウント制御が単一的であり、署名による許可があるかないかの二択しかない。価値1ドルの取引でも1億ドルの取引でも、事前にapproveし、署名で取引を確定させる必要がある。つまり、権限を騙されるか通常の取引を行うかの差はただ一つの署名に過ぎず、新しいユーザーはインタラクションのたびに神経をすり減らすことになる。現在ではMetamaskがトークン権限のapprove時にユーザーが承認量を選べるようになっているが、頻繁な操作を行う場合、毎回approveしてガス手数料を消費するよりも、上限額を一括で承認してしまうほうが好まれる。Web2のアカウントモデルでは、Two Factor Authentication（2FA）やUディスクなどで高額取引のリスクを管理し、顔認証やパスワードなし決済で小額取引を簡便にするのに対し、EOAアカウントは非常に硬直的で使いづらい。
• ガス手数料のハードルが高く、多くの新規ユーザーを排除している。イーサリアムメインネットおよびOptimism/ArbitrumなどのLayer2はETHをガストークンとして使用しており、ユーザーは法定通貨を米ドルステーブルコインに変換した後、さらにETHに交換し、それをウォレットに送金しなければならない。多くのユーザーは、米ドルステーブルコインをウォレットに送金した後に、ガスとしてETHが必要だと気づき、再度ETHを購入せざるを得ない。加えて、BSC/Polygon/Solanaなどのパブリックチェーンもそれぞれ独自のガストークンを使用しており、これは初心者が必ず陥る落とし穴である。さらに、多くのユーザーはガストークンの現物を実際に保有したいわけではなく、チェーン上でのインタラクションのために仕方なく大量の余剰ガストークンをウォレットに残さざるを得ない。
EOAアカウントがこれほど使いづらいことは、Vitalikもすでに認識しており、イーサリアムチームも問題解決を試みており、その一つの解決策がアカウント抽象（Account Abstraction）である。しかし、イーサリアムの基盤コンセンサスを変更できないため、ERC-4337というアプリケーション層ベースのスマートコントラクトウォレット方式が提案されるまで、アカウント抽象は注目されず、ようやくホットトピックとなった。
本稿では、アカウント抽象とERC-4337について簡単に紹介した後、アカウント抽象の応用とWeb2アカウント体系の発展に基づき、将来のWeb3アカウント体系の進化とトラフィックエントリーの帰属を推測する。
エコシステムの観点から見ると、従来のユーザーはEOAを使って複雑なチェーン上操作を行う必要があり、現時点でのチェーン上エコシステムの発展が限定的であるため、提供できるプロトコルも限られ、ユーザーの実際のニーズは十分に満たされていなかった。一方、アカウント抽象はこうした操作を簡素化し、ユーザーがinputすればoutputが得られるようになり、煩雑なクリックや署名の繰り返しが不要になる。言い換えれば、AAの実装により、チェーン上エコシステムは売り手主導から買い手主導へと転換した。
アカウント抽象（Account Abstraction）とERC-4337
アカウント抽象（Account Abstraction、以下AA）とは具体的に何を指すのか？基盤技術とデータ構造を抽象化し、ユーザーと開発者の操作手順を簡素化すること。つまり「EOAの上にCAの機能を実現する」ことの簡易理解である。
ERC-4337はAAの基礎標準となった。ERC-4337はUserOperationという、ユーザーの意図を表す特別なトランザクションを導入し、コントラクトアカウントが自ら操作を実行できるようにした。これらのUserOperationはBundlerと呼ばれる役割によって管理され、UserOperationをシミュレーション実行し、有効な操作を特殊なトランザクションプールに追加する。その後、EntryPointコントラクトがこれらのUserOperationを検証・実行し、ユーザーの意図を達成する。
アカウントタイプ
イーサリアムには2つの主要なアカウントタイプがある：EOA（Externally Owned Account）アカウントとコントラクトアカウント。
EOAアカウントのアドレスは20バイトで、ユーザー作成時に生成された秘密鍵と楕円曲線暗号アルゴリズムで生成される公開鍵から計算される。EOAアカウントの状態には、トランザクション回数（Nonce）と資産数量（Balance）が含まれる。コントラクトアカウントのアドレスも20バイトだが、コントラクト作成トランザクションの送信者アドレスとNonceから計算される。コントラクトアカウントの状態には、コントラクト数（Nonce）、資産数量（Balance）、コードハッシュ（CodeHash）、ストレージルートハッシュ（StorageRoot）が含まれ、後者はコントラクトデータを格納するMerkle Patricia Trie木のルートノードハッシュ値である。
アカウントタイプと状態情報は、イーサリアム上のトランザクションおよびスマートコントラクトの実行に極めて重要であり、EOAとCAの違いでもある。
トランザクション
イーサリアムのトランザクションには、送信者と受信者の情報、デジタル署名、トランザクション回数、資金移動量、任意データ、ガスリミット、トランザクション手数料が含まれる。この2種類の異なるアカウントタイプにより、2種類の全く異なる通信トランザクションタイプが生まれる。
署名プロセスでは、トランザクションデータをハッシュ化し、デジタル署名を行う。検証者は楕円曲線上の点を計算することで署名の正当性を確認でき、送信者の秘密鍵を知る必要はなく、トランザクション情報と公開鍵さえあればよい。公開鍵の復元は署名内のv値によって行われ、署名の安全性と検証の効率性が確保される。
アカウント抽象
イーサリアムのトランザクション構造と署名検証プロセスは重要な事実を明らかにする。つまり、トランザクションを開始できるアカウントは、公開鍵秘密鍵ペアを持つEOAアカウントでなければならない。
コントラクトアカウントは公開鍵・秘密鍵ペアを持たないため、自らトランザクションを開始することはできず、トランザクションを受信した後、その内容に応じてコントラクトコードを自動実行したり、他のアカウントにメッセージを送信したり、新たなスマートコントラクトを作成したりする。そのため、現在主流のウォレットアプリ（例：Metamask）が作成するウォレットはすべてEOAアカウントである。しかし、EOAアカウントにはいくつかの欠点がある：秘密鍵リスク、署名アルゴリズムの制限、過度な署名権限、トランザクション手数料の制約。
コントラクトアカウントはコードとデータを保存でき、予め定義されたスマートコントラクトロジックを実行することで、EOAアカウントの上記問題を解決できる。しかし、コントラクトアカウントは自らトランザクションを開始できない。
アカウント抽象は、この2つのアカウントタイプを改良したものであり、両者の境界を曖昧にし、複雑なロジックを含む汎用的なアカウントとして、CA（コントラクトアカウント）とEOAアカウントの両方の機能を持つようにする。
ERC-4337
ERC-4337は、イーサリアムのコンセンサス層を変更せずともアカウント抽象の機能を実現し、イーサリアムが最終的に採用した方式となった。これにより、オンチェーン取引とオフチェーンマッチングの究極のビジョンが達成された。
• UserOperation
ERC-4337は、コントラクトアカウントが自らトランザクションを開始できない問題を解決するため、またイーサリアムプロトコルの基盤トランザクションタイプを変更しないようにするために、「UserOperation」という新しい概念を導入した。
UserOperationは標準的なトランザクションに似ているが、直接のトランザクション行為ではなく、ユーザーの意図を表すものにすぎない。標準的なトランザクションはイーサリアムのmempool（トランザクションプール）に送られ、searcherとbuilderによって完全なブロックが組み立てられ、proposerがブロックチェーンに送信される。通常、報酬の高いブロックが選ばれる。一方、UserOperationは実際のトランザクションではないため、ERC-4337は新しいmempoolとBundlerという役割を導入し、分散型でUserOperationを実行する。この革新により、ユーザーの意図が処理・実行可能となり、標準的なトランザクションプロセスに直接参加する必要がなくなる。
• Bundler
BundlerはUserOperationを処理する際、まず基本的な正当性チェックを行い、次に操作をシミュレーション実行して署名の正当性を確認する。シミュレーションが成功すれば、UserOperationはUserOperation mempoolに追加され、実際のオンチェーン実行を待つ。シミュレーションと実際の実行の整合性を保つため、UserOperationは実行中に変化する可能性のある変数へのアクセスを制限され、送信者アドレスに関連するデータのみにアクセスできる。Bundlerは自身の好みに応じてUserOperationをパッケージ化でき、より高い手数料を支払う操作を優先できる。最終的に、Bundlerは有効な操作のバッチをEntryPointコントラクトに送信し、オンチェーンで実行する。
• EntryPoint
EntryPointはイーサリアム上のシングルトンコントラクトであり、UserOperationの実行を処理することが主な任務である。2つの重要な関数handleOpsとhandleAggregatedOpsがあり、いずれもまずUserOperationを検証し、その後操作を実行する。検証にはアカウント、署名の正当性、手数料の支払い確認が含まれる。実行段階では、UserOperation内のデータを使ってターゲットコントラクトアカウント内のスマートコントラクトコードを呼び出す。異なるスマートコントラクトウォレットプロトコルごとに、解析・実行方法が異なる場合がある。
• データ
SixdegreeLabのERC-4337 半年間データレポートによると：
-
ERC-4337コントラクトがデプロイされた後、チェーン上には68.7万以上のAAウォレットが作成され、200万回以上のUserOpsが呼び出されたが、88.24%のAAウォレットは5回以下の使用しかなく、多くは単なる送金またはNFTの鋳造であった。
-
1.5万のBundlersのうち、pimlicoが43.48%を占め最大シェアを持ち、Alchemyは史上最高の収益約2万ドルを創出した。
-
しかし、97.18%のBundledトランザクションは1つのUserOpしか含んでおらず、これは90%のBundlersがトランザクションのパッケージ化で利益を得られないことを意味する。
-
117のPaymasterが合計1900万のUserOpsに対して46.5万ドルのガス手数料を代わりに支払い、そのうちPimlicoが43.45%を支払った。
-
ZeroDevがWallet Factoryを支配し、62.63%のアカウントをデプロイした。
-
最もよく使われるAAウォレット構築方法はLEGOであり、異なる第三者のPaymaster、Wallet Factory、Bundlerを組み合わせる方式である。
以上から、ERC-4337の採用率にはまだ大きな成長余地があり、インフラ整備も始まったばかりであり、AAの将来には無限の可能性がある。Layer2とソーシャルアプリの台頭とともに、AAウォレットの利用は急速に増加するだろう。
アカウント抽象の発展方向
アカウント抽象の基本原理とERC-4337のアーキテクチャを理解した後、AAの拡張方法をさらに探求する。ここでは、鍵不要・ガス不要といったスマートコントラクトウォレットの基本機能には触れず、AAのコンポーネントの中でさらなる可能性を探す：
アーキテクチャ
ネイティブアカウント抽象
ERC-4337は、現時点のイーサリアムが基盤コンセンサスを変更できないためのアプリケーション層ソリューションにすぎず、アカウント抽象の概念を広めるには有効だが、結局はコントラクトアカウントを借りてのインタラクションである。検証プロセスでの余分なガス消費、他の競合ERCの採用、dappがコントラクトアカウントとのインタラクションを禁止するなど、ERC-4337の発展を妨げる要因は多い。
したがって、特にLayer2におけるネイティブアカウント抽象が極めて重要となる。現在のLayer2の中では、StarknetとZKSyncのみがネイティブアカウント抽象をサポートしている。下図のように、ネイティブアカウント抽象方式ではBundlerやPaymasterは存在せず、StarknetはSequencerがトランザクション順序を決定し、ガスを支払い、実行する。ZKSyncはOperatorがトランザクション順序を決定し、ガスを支払い、bootloaderを呼び出して操作を行う。
DeBank ChainもOP Stackに基づいて構築されると宣言しており、チェーンレベルでアカウント抽象に類似したシステムをネイティブ統合するとされているが、具体的なアーキテクチャはメインネットリリースまで不明である。
NFTコントラクトウォレット
NFTコントラクトウォレットは、ERC-4337に類似したアプリケーション層のアカウント抽象方式であり、EOAアカウントにCAアカウントの機能を持たせるもので、BundlerがEntryPointコントラクトを呼び出すのではなく、現在の主流実装方式にはERC-6551とA3S Protocolがある。
ERC-6551は、ユーザーが自身のEOAウォレット内のERC-721準拠NFTをコントローラーとして使い、1つまたは複数の新規スマートコントラクトウォレットを操作できるようにする。これにより、ERC-721コードを変更せずに、「外付けコントラクト」によって既存のNFTに1つまたは複数のスマートコントラクトアカウントを紐付けることができる。この方式は既存のNFTとアカウント抽象を融合させ、NFTの活用シーンを広げつつ、アカウント抽象の普及にも寄与する。
A3S Protocolは、NFT自体のスマートコントラクトをそのままスマートコントラクトウォレットとして使うもので、つまりウォレット資産はNFTのスマートコントラクトアカウント上にあり、NFTの所有権移転に完全に追随する。ERC-6551のようにNFTコントラクトにウォレット用のコントラクトアカウントを外付けする必要がなく、より短いパスでNFTコントラクトウォレットを実現するが、既存のNFTとの非互換性という代償を伴う。
マルチチェーンウォレットアドレスの統一に関して、両方式とも混同値Saltを利用して、異なるEVM互換チェーン上で同じアドレスを得ることで、コントラクトアカウントのマルチチェーンアドレス混乱問題を解決している。これはかつてWintermuteがマルチチェーンのマルチシグアドレスに送金する際に2000万枚のOPトークンを失った原因でもある。
モジュラー化とマルチチェーン抽象
モジュラー化アカウント抽象の意義は、OP Stackのように開発・メンテナンスコストを最小限に抑え、ウォレット開発者が基盤インフラの構築・維持に集中せず、製品自体に注力できるようにすることにある。当然、こうしたモジュラー化エコシステムの構築こそがモジュラー化プラットフォームの存在意義でもあるため、モジュラー化アカウント抽象は以下の点を実現しなければならない：
• 各モジュールの相互組み合わせ可能性（EIP-6900が標準化を試みている）
• モジュール機能の多様性（署名方式／プライバシー／MEV耐性／出入金／Intentなど）
• セキュリティ（各モジュールが統一標準を持ち、ストレージ衝突を回避）
• マルチチェーン抽象（Vitalikは、統一された単一チェーンのキーストアコントラクトでマルチチェーンスマートコントラクトアカウントを協調させる案を提示）
前述のSaltによるマルチチェーンスマートコントラクトアカウントアドレスの一貫性は第一歩にすぎず、より重要なのはユーザーがクロスチェーン操作において一切違和感を持たないこと、つまりマルチチェーン抽象である。これはモジュラー化の重要な一歩であり、アカウント抽象の重要な一歩でもある。
署名検証
以前述べたように、イーサリアム上のいかなるトランザクションもEOAによって開始され、ETHをガスとして支払う必要がある。さらに、EOAはECDSA署名方式しか使えず、これがEOAの使いにくさと機能単一性、秘密鍵漏洩リスクの原因となっている。そして量子コンピュータが登場する日は、イーサリアムEOAアカウントが犠牲となる日でもある。
署名アルゴリズム
署名レイヤーでは、現在すでにスマートコントラクトによるマルチシグやソーシャルリカバリーの方式（Gnosis Safe、Argent）があり、また「Lens Protocol」のような「一度の許可で指定範囲内で自由にコントラクトとインタラクトできる」いわゆる署名抽象方式もある。しかし、「Not your keys, not your coins（君の鍵でなければ、君のコインではない）」という原則から、署名アルゴリズム自体にも注目すべきである：
• 署名集約
SchnorrやBLSを用いてより効率的でシンプルな署名を実現でき、これにより基盤からマルチシグを実現できるだけでなく、集約署名によってガス消費を削減できる。もちろんそれぞれ課題もあり、追加の通信ラウンドが必要だったり、大規模なm・n値のマルチシグに不向きだったり、多数のマッチング検証に時間がかかるなど。
• ポスト量子セキュア署名
LamportやW-OTSなどのワンタイム署名を用いることで、量子コンピュータを使って公開された部分の秘密鍵を解読し、メッセージや署名を偽造されるリスクを回避できる。
UserOperation
ERC7521 Intent Centric
アカウント抽象、特にERC-4337とIntent Centricアーキテクチャを比較すると、実はBundlerとSolverは同一人物である可能性があることに気づく。つまり、ユーザーのインタラクション内容「UserOperation」をBundlerが提示でき、Bundlerがユーザーの意図を解析して適切な解決パスを提案し、EntryPointコントラクトを通じてユーザーにパスの正当性を確認させることで、Bundlerの悪用を防ぎ、最終的に検証された意図パスを実行する。
アカウント抽象とインテントの結合により、アカウントとインタラクションの同時抽象化が可能となり、Web2を超えるユーザーエクスペリエンスを実現できる。
トランザクション全体のプロセスは、証人／チャレンジとレスポンスなどのプロセスを通じ、ZK証明技術でプライベート決済を実現できる。これによりユーザーはトランザクションの有効性を証明できる一方で、送信者の真のアドレスを明かさなくて済み、複数のトランザクションを単一の証明にまとめて計算負荷を削減し、スケーラビリティを大幅に向上させることができる。まさにコスト削減と効率向上である。監督対象となる企業ユーザーは、機密性を損なわず監督当局に個別にトランザクションを透明化することで、規制遵守要求を満たすことも可能である。
Bundler
Bundler MEV と Bundler Competition
Bundler MEVとBundler Competitionはいずれもインフラが未整備な結果である。Bundler MEVは、BundlerがSearcherと同様にトランザクションをパッケージングする責務を持つことに由来し、BundlerがUserOperationの提出順序を変更することで利益を得られる。一方、Bundler Competitionは複数のBundlerが同一UserOperationをパッケージングしようとする際に発生し、SearcherのGas Warに類似している。パッケージングしたUserOperationがオンチェーンに反映されなかったBundlerは、ガスを消費してもトランザクションが失敗する。
これらは既存のインフラから学ぶことができる。例えばMEV-Boostを活用し、Bundler間およびBundlerとBlock Builder間のコミュニケーションチャネルを確立する。EtherspotはAA向けにmempoolのp2pネットワークを開発中であり、パッケージ待ちのUserOperationsはこのp2pネットワーク内で伝播され、パッケージングされオンチェーン処理されると、マークされてリストから削除されるため、複数のBundlerによる重複パッケージングを回避できる。
Paymaster
Paymaster 出入金
Paymasterはユーザーのガス手数料を代わりに支払い、ユーザーと任意のトークンまたは法定通貨で支払いを交渉できる。したがって、Paymasterが決済サービスプロバイダーと連携し、ユーザーに出入金サービスを提供するのは非常に良いソリューションである。
VisaチームはイーサリアムGoerliテストネットに2つの実験的Visa Paymasterコントラクトをデプロイした。1つは米ドルステーブルコインを含む他のトークンで費用を支払えるかどうかを探索するもの、もう1つは直接トランザクション手数料をスポンサーするものである。もちろん、Paymasterを既存のERC-20トークンと統合するには、外部ソースまたはオンチェーンオラクルを使ってトークン価格を決定し、Paymasterコントラクトがユーザーから指定されたトークンの徴収を承認しているか確認する必要がある。この成熟した方式により、Visaカードで直接法定通貨を支払い、ERC-20トークンとリアルタイムで変換する出入金抽象が実現でき、Web2ユーザーの参入障壁を大きく下げられる。
Web3アカウント体系の進化と将来のWeb3エントリー
Web2時代のネットワークトラフィックエントリーとそれに伴うアカウント体系の進化は、第2世代インターネットの急速な発展とユーザーのニーズの変化を反映している。
当初、ユーザーはポータルサイトを通じてインターネットに入り、サイトが提示するオンラインリソースを自由に選択できた。その後、検索エンジンの登場により、ユーザーはキーワードを検索することで、URLを分析して関連結果を提供するようになった。Web2時代にはソーシャルプラットフォームの台頭があり、PC端末とモバイル端末の両方で顕著だった。ユーザーは能動的に検索エンジンを使ってWeb2に入るだけでなく、PCメディアプラットフォームの情報を受動的に接触したり、PC／モバイルの自媒体プラットフォームから自主的にWeb2に入るようになった。この過程で、受動から能動へと2回の変化があり、情報の非中央集権化のプロセスもあった。
また、Web2のアカウント体系も同時に変化し、当初のSMS／MMSで電話番号をアカウントとする方式から、QQ／WeChat／ブログ／微博などが多元的アカウントを構築し、豊かな付加機能と独立した個人ネットワークアイデンティティを獲得した。これらのプラットフォームはプロフィールと連絡先リストを導入し、ユーザー識別を単一のURLからより複雑なユーザーIDとソーシャルグラフへと拡張した。
ネットワークとハードウェア技術の発展に伴い、自らのエコシステムを発展させる2つの方式が登場した：
-
「iOS＋Apple Pay＋Apple Store」と「WeChat Pay＋ミニプログラム」は、自らのアカウントと決済体系のトラフィック優位性を確立した後、外部開発者が接続できる領域を開拓し、ユーザーを自らのエコシステム内に留めることでエコを拡大した。
-
「淘宝＋支付宝」と「抖音＋抖音支付」は、ヒットアプリがもたらすトラフィックを基盤に自らのアカウントと決済システムを発展させ、さらに他のアプリを統合して統一されたアカウントと決済システムを構築した。
この2つの方式はそれぞれ有効であり、一定の地位を築いている。WeChat一つのアプリでユーザーの大部分のニーズを満たせ、Alipayの支払いは各大アプリで利用できる。
総合すると、Web2時代のトラフィックエントリーはユーザーにより多くの能動性と非中央集権化を目指しており、アカウント体系は単一から豊かで多元的になり、2つの方式で自らのエコシステムを発展させてきた。
アカウント体系
Web3時代のアカウント体系の進化は、Web2の影響を一部残しつつも、独自の発展経路を示している。
Web3時代のアカウント体系の進化は、Web2の特徴を一部継承しつつ、独自の発展経路を示している。Web3では、Metamaskのようなプラグインウォレット、MathやTrustのようなソフトウェアウォレット、「操作プラットフォーム」であるdAppOSやGnosis Safe、dApp内部に埋め込まれたUniPass、取引所内蔵のOKX Web3 Walletなど、さまざまなタイプのアカウントが登場した。
-
Metamaskなどのプラグインウォレットは、初期のSMSのようにユーザーの基本的ニーズを満たすが、どこでも使える反面、機能が単一すぎる。
-
MathやTrustなどのソフトウェアウォレットは、QQやWeChatのように基本機能に加え、多アカウント管理／ソーシャル機能／附属アプリなど、ユーザーエクスペリエンスを向上させるさまざまな機能を追加している。
-
dAppOSやGnosis Safeなどの「操作プラットフォーム」は、ソフトウェアウォレットをさらに進化させ、基盤機能をアップグレードして高度なアカウントシステムを構築し、AppleやWeChatのように自らを中心に「ミニプログラム」を開発してエコを豊かにしている。
-
UniPassやOKX Web3 Walletなどのアプリ内蔵ウォレットは、Alipayや抖音支付のような別のアカウント・決済ルートを歩み、ヒットアプリのトラフィックを活かして自らのユーザーを育て、提携でエコを構築している。
トラフィックエントリー
私たちは以前『Web3トラフィックエントリー』という記事で次のように述べた：
「ユーザーがWeb3に入るプロセスに基づき、Web3トラフィックエントリーを2つの大カテゴリに分類できる：
-
アカウント体系（出入金と資金管理）：中央集権取引所、独立出入金プロジェクト、出入金アグリゲーター、暗号ATM、暗号カード、場外取引（OTC）；EOA、CA、MPCウォレット、アカウント抽象（AA）。
-
Web3 dapp（ツール、ソーシャル、エンタメ）：DEX、NFTマーケットプレイス、ドメイン、DeSoc、著作権取引市場、GameFi、X to Earn。」
今もそのように考えているが、第二部の内容から、これらすべてのエントリーはAAウォレットの一部となり得る。しかし逆に、これらはAAウォレットの採用経路を2つに分けている。すなわち上記のアカウントとアプリの2つであり、ユーザーがまずアカウントを取得してからアプリとインタラクションするか、まずアプリでインタラクションしてからアカウントを使うかである。
ウォレットミニプログラムとWallet as a Service
AAの採用プロセスを見ると、当初はInstadappが独立したAAウォレット製品Avocadoをリリースし、その後MetamaskがSnapsミニプログラムコンポーネントを発表して一部AA機能をサポートし、決済大手VisaもPaymasterで実験しVisaカード決済を導入し、まもなくソーシャルアプリLens ProtocolがERC-6551でAAウォレット構築を試み、SafeもERC-4337に対応して自らの「ミニプログラム」市場を強化し、続いてOKX WalletがAAウォレット使用をサポートし、Circleも自社AAウォレットをリリースした。
ここから明らかなのは、AAの採用は外
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
