ウォレットインフラストラクチャは、次世代のdappsのWeb3体験を解除する上で重要な役割を果たしています。

これまでのユーザーは、最初のWeb3でのやり取りを行う前に、追加のソフトウェアをインストールし、新しい通貨でそれをソースと資金を提供し、馴染みのない確認画面に直面する必要がありました。ファイアウォールの改善やシードフレーズからの移行にもかかわらず、これらの障壁は分散型アプリケーションにおける高い離脱ポイントです。

環境は、技術的レイヤーを抽象化し、自己保管と分散化の原初的な理念を損なうことなく、新しい金融、社会、ゲームプレイ体験に直感的に参加できるようにする革新に適しています。

2023年は、ウォレットエコシステムにとって画期的な年となりました。アカウントの抽象化やスタックのすべての層での開発により、市場構造が変化し、ユーザー、DApps、およびウォレットの関係についての考え方も変わりつつあります。

アカウント抽象化：何、なぜ、そして方法

アカウント抽象化をアカウント管理とキー管理の切り離しと考えることができます。アカウントは、資産を保持し、取引履歴を持つことができるブロックチェーン上のエンティティです。署名者（キー）は、アカウントを代表してアクションを実行する権限を持つエンティティです。

従来のアカウント（EOA）では、プライベートキーが関連するアカウントに対して唯一無二かつ完全な制御を保持します。プライベートキーとアカウントの間の厳密な1対1のマッピングは、次のような意味です:

ユーザーは、ブロックチェーンとやり取りする際に専用のキーマネジメントソリューション（例: Metamask、Ledger）を使用することに制限されています。

プライベートキーを失うときの救済手段はありません。アカウントを制御するキーは交換できません。

そのプライベートキーによって起こるすべてのアクションは、無料のNFTを作成することから数百万ドルを移動することまで、等しく扱われます。

アカウントの抽象化により、そのキーがその代わりにアクションを実行できる範囲のアカウントにスマートコントラクトを作成し、権限の範囲を定義し、ユースケースに応じて追加のチェックとバランスを行います。

さらに、抽象化されているものを調査することで、その利点をさらに分析することができます。

イーサリアムプロトコルは、EOA発生トランザクションのみを認識するため、アカウントの抽象化には、スマートコントラクト発生トランザクションをチェーンに中継するためのオフチェーンインフラストラクチャが必要です。

ERC-4337は、2021年に導入され、コアプロトコルの変更なしにこれを行う標準化された方法として導入されました。しかし、標準が完全に具体化される前から、いくつかのプロジェクトがAAの利点を提供していました。

2017年に立ち上げられた安全なマルチシグウォレットは、DAO、企業、個人の資産合わせて500億ドル以上を保護して成長しています

Argentのモバイルウォレットは2018年以来、スマートコントラクトアカウントによって動作しています

2021年に発売されたSequenceウォレットは、Skyweaverに対してスマートアカウントを作成し、ログインし、メールを使用して手数料を支払うことを可能にし、非ネイティブトークンを使用します

この必要は、それぞれのプロジェクトによるカスタム中継インフラの構築と維持を意味しました。

ERC-4337を入力します。この標準は、中継層のための分散化された検閲に耐える代替手段を提供し、アカウント、ペイマスター、およびシグネチャアグリゲータがサードパーティのリレーや共有代替メンプールを介してやり取りするためのインターフェイスを定義しています（"ユーザーオペレーション"）。

リレーヤー（"バンドラー"）は、複数のUserOpsを束ねて1つのEntryPointコントラクトに送信するトランザクションにまとめ、その後、手数料が支払われることを検証します（アカウント自体またはペイマスターを介して）、およびスマートアカウントに応じたUserOpsを実行します。

これは、ネイティブでアカウントの抽象化を提供するチェーン上での検証と実行がどのように行われるかを対照させることができ、そのため、余分なリレー（たとえば、zkSync*やStarknet）が不要であるという点があります。また、最近公開されたEthereumおよびそのロールアップでのネイティブAAに関するRIP-7560提案もあります。

2023年3月、4337 EntryPoint契約がメインネットに展開されました。そのコミュニティは、開発者がアカウント抽象化運動に参加することに非常に成功しています。

これにより、ウォレットエコシステムに新しいインフラストラクチャとサービスプロバイダが次々と登場し、既存のプロジェクトも、AAを活用してユーザーにシームレスなweb3体験を提供するアプリケーション開発者のニーズに対応するため、ビジネス戦略と製品スイートを継続的に見直す動きが加速しました。

ウォレットインフラストラクチャーとAAスタック

サインアップ者とキーマネジメント

サイン者＆キーマネジメントインフラストラクチャは、メッセージ、トランザクション、およびユーザー操作の署名に使用される公開キーペアを生成および保護する責任があります。ここで最もわかりやすい例は従来のEOAウォレットですが、ウォレットサービスプロバイダーが出現して、ソーシャルやメールなどの代替認証方法を介して、シードレスのオンボーディングやウォレット管理を可能にしました。

これらのサービスは、基本的には、AWS KMSのようなHSMに鍵素材を保存し、ユーザーだけが認証資格情報（Magic、Turnkey）を介してアクセスできるか、あるいはいくつかのSSS/MPCスキーム（Privy、Web3Auth、Portal、Capsule）の下で運用され、素材を保護します。

Lit*は、このサーバーサイドのキーストア設計を改良し、キーを分散化します。ネットワーク内の各ノードは、DKGアルゴリズムを使用して生成されたECDSA秘密鍵のシェアを格納し、すべての操作は暗号化された仮想化で行われます。任意の認証ルールをキーペアに割り当てることで、アプリケーションまたはユーザーが許可する相互作用を完全に制御し、例えば支出制限を課すことができます。さらに、ネットワークは、バックアップおよび復旧オプションとして2-of-N MPCウォレットによって活用することができます。

今年は、ハードウェアサイナーやパスキーを署名者として活用するための急速な実験が行われ、ユーザーにキーマネジメントをモダンなモバイル端末やデスクトップデバイスで直感的に提供しています。これらの署名者は、生体認証（例：FaceID、TouchID）とネイティブで連携し、なじみのあるUXで追加のセキュリティを提供します。

ハードウェアサイナーは、iPhoneのセキュアエンクレーブやAndroidのTitan HSMなどの分離されたサブシステムを利用して、キーを生成し、メッセージに署名することで、ハードウェアレベルのセキュリティを保証します。キーをデバイスから抽出することができないため、これは追加のリカバリーメソッドとして、または2要素認証システムの一部として連携することで最も強力です。

パスキーは、WebAuthnの上に構築されたパスワードレス認証の標準です。ここでは、キーペアがデバイスのオペレーティングシステムで生成され、iCloudなどのサービスを介してデバイス間で同期させることができるため、ユーザーがそれを選択した場合には復旧が可能です。

ここでの1つの制限は、パスキーとハードウェアサイナーで生成された署名がBitcoinやEthereumなどのチェーンでネイティブに認識されないことです。彼らはsecp256r1（R1）楕円曲線を使用しており、これらのチェーンはK1バリエーションで動作しています。 R1を信頼できるかつ効率的に検証するための作業が進行中ですが、一部のパスキー対応製品は、ユーザーがキーで認証を行った後にK1署名を生成するために、LitやTurnkeyなどのサービスを経由しています。

ここで注目すべき標準は、EIP-7212 です。この標準は、R1 曲線を EVM に直接追加し、すべてのモダンデバイスがサードパーティーサービスや仲介業者なしにトランザクションにネイティブに署名できるよう提案しています。

口座抽象化された取引のボリュームが増加するにつれて、BLS署名を使用した署名集約は、L2上のスマート口座手数料がEOAよりも安くなる可能性があります。4337は、複数のUserOpsを承認する単一の集約署名を検証するAggregatorヘルパーコントラクトのインタフェースを定義しています。これにより、それぞれを個別に検証するのではなく、複数のUserOpsを承認する単一の集約署名を承認することができます。

リレーサー

リレーサー（例：4337バンドラー）は、トランザクションやUserOpsをメンプールに中継します。ネイティブAAを持つチェーンでは、ネットワークオペレーターやシーケンサーがこの役割を果たし、外部の専用リレーサーが必要なくなります。

イーサリアムには複数のクライアント実装（geth、erigon、rethなど）があるように、4337エコシステムには異なる言語で複数のバンドラ実装があり、ネットワークを単一の実装の脆弱性に対してより頑丈にします。 4337仕様には、ネットワーク全体でのバンドラの互換性を確認するためのテストスイートが含まれています。実装者にはStackup（Golang）、Pimlico、Biconomy、Etherspot（Typescript）、Candide（Python）、OKX（Java）、およびAlchemy（Rust）が含まれています。

バンドラーのインセンティブモデルは、ブロックビルダーと類似しており、トランザクションから手数料を取る代わりに、バンドルされたユーザーオペレーションから手数料を取ります。実際には、バンドラーはブロックビルダーに対してAPIが必要で、現在のブロックを参照し、そのブロックに対して有効なバンドルを作成する必要があります。そのため、ブロックビルダーの一部として考慮されるべきです。

4337トラクションが成長するにつれて、ビルダーもバンドラーになることが予想されます。このハイブリッドは、ビルダーだけよりも収益性が高くなるため、トランザクションプールとUserOpsプールの両方から選択できます。

ペイマスターズ

ペイマスターは、dappがユーザーのガスをスポンサー支払いし、ユーザーがネイティブでないトークンを使用して手数料を支払ったり、伝統的な支払いレールを介してオフチェーンで決済したりすることを可能にする手数料抽象化を実現します。 ペイマスターサービスには2つの主要なコンポーネントがあります:

開発者がガスをスポンサーする条件を定義するためのガスポリシーマネージャー。これは、プロジェクト全体、契約ごと、またはウォレットアドレスごとにスコープを設定できます。 開発者はまた、ガススポンサーシップをどのようにレート制限するかを定義できます（たとえば、ガス価格、#リクエスト、またはスポンサーされる金額/月単位で）。 ガススポンサーシップ費用は、通常、サービスプロバイダーからの開発者の月次請求書にロールバックされ、スポンサーされた金額に対して約5％の追加料金がかかります。

ペイマスタースマートコントラクトは、与えられたトランザクションが、オンチェーンのアカウント残高やオフチェーンのガス管理ポリシーなどに基づいてカバーされる資格があるかどうかを検証します。ペイマスターコントラクトは、ガスの支払いに使用されるネイティブトークンの残高を保持し、支払いトークン（例：USDC）とネイティブトークン（例：ETH）の間の為替レートを定期的にチェックする価格オラクルロジックを含んでいる場合があります。

ペイマスターはオンチェーンまたはオフチェーンに分類することができます。

Onchain Paymasters（例：ERC20Paymaster、StablecoinPaymaster）は、トランザクションがペイマスターによってカバーされるかどうかを確認するためにオンチェーンステートにのみ依存します。つまり、ERC-20でガス料金を受け入れるような特定のペイマスターは、アカウントによってペイメントトークンを送金するために承認される必要があるという注意があります。 ペイマスター契約の管理者はトークンを引き出し、ネイティブに変換して契約をリフィルすることができ、ERC20価格にマークアップを設定したり、次のUserOpのためにERC20価格を更新するための価格差のしきい値を設定したり、価格を手動で更新することができます。

オフチェーン・ペイマスター（例：VerifyingPaymaster）は、サービスプロバイダーのペイマスターAPIとのやりとりを含み、UserOpをスポンサーするためのものです。オフチェーン・サービスは、資格をチェックし、ペイマスターのキーを使用して取引に署名します。このソリューションは許可制ですが、オフチェーン・ペイマスターには、オンチェーンのチェックを最小限に抑えることでガスを節約する利点があります。ガスのポリシーをより詳細に設定し、Discordのようなオフチェーンのアクティビティを考慮に入れることができます。

アカウントファクトリーズ＆フレームワーク

アカウントファクトリー＆フレームワークは、DAppsやウォレットクライアントが構築できる「ヘッドレス」スマートアカウント実装とSDKを提供し、ユーザーのために自己保管埋め込みアカウントを作成します。 アカウント自体は、独自の署名検証、実行、および再生保護（ノンス管理）ロジックを持つスマートコントラクトウォレットです。 オーナーは、キーを使用してスマートアカウントから発信されるユーザー操作を承認します。

高いレベルで、スマートアカウントベンダーは3つの核心的なものを提供します。

スマートコントラクトウォレットのためのコア実装であり、取引が検証、実行される方法、および実行前および実行後に実行する追加アクションについて独自のロジックを持っています。また、追加機能がネイティブおよびサードパーティのモジュールを介してウォレットに追加される方法についてのロジックも含まれています。

ウォレットの実装の新しいインスタンスを展開し、そのアカウントの初期署名者で開始される工場契約。ERC-4337によると、dappsは、選択したプロバイダーから工場契約アドレスを指定して、ユーザーのためにスマートアカウントを作成することができます。

開発者が作成しているスマートアカウントにプラグアンドプレイのカスタマイズ性を提供するSDK。これには、異なる署名オプション、オン/オフランピング、リレー技術などが含まれることがあります。

ERC-4337に基づく、送信者UserOpのフィールドは、トランザクションが行われているスマートアカウントを指します。アカウントがまだ展開されていない場合、EntryPointは指定されたファクトリーコントラクトからアカウントを展開します。initCodeユーザーのキーを使用して、スマートアカウントを請求し、その後のdappインタラクションを行うことができます。

Safe、Zerodev、およびBiconomyのようなアカウントプロバイダーは、主要なマネージャーと認証インフラと統合して、Dappsがユーザーにスマートアカウントをどのように管理するかのオプション性を提供しています。たとえば、SafeのWeb3Auth統合を使用すると、ユーザーはソーシャルやメールを使用してアカウントを使用でき、ZerodevのTurnkeyとの統合ではPasskeysでアカウントを管理するオプションが与えられます。

Safeは、個人、チーム、DAOで広く使用されている、実戦でテストされたスマートウォレット製品で最もよく知られています。現在までに、12+チェーンに5m+のSafeが展開され、22m+以上の取引が実行されています。v1.4.1(2023年7月リリース)より前は、開発者はすでにGelato Relayを使用してガスで抽象化されたトランザクションを有効にすることができました。この組み合わせは現在、Gnosis PayやBasedAppなどの暗号デビットカード製品に採用されており、ユーザーはSafeの資金を使用してVisaを受け入れる任意のベンダーから購入することができます。v1.4.1では、モジュールを通じてERC-4337をサポートし、リレープロバイダーに追加のオプションを提供します。

ZeroDevは、今年初めにローンチされたスマートアカウントプロバイダーであり、最初からERC-4337向けに構築されています。ZeroDevは、複数のバンドラープロバイダーを集約してUserOpリレーサービスを抽象化し、開発者がユーザーの手数料をスポンサーするためのスコープとレート制限ロジックを定義できるガスマネージャーダッシュボードを公開しています。ZerodevとBiconomy（独自のバンドラーネットワークも運営しています）は、現在、4337対応アカウントの市場シェアを独占しています。

AlchemyのAccountKitには、4337準拠のスマートアカウント実装「LightAccount」があり、これはEFの実装をベースにしており、EIP-1271サポート（スマートコントラクトから発信される署名の検証）に加えて、所有権の移転、キーの回転、および名前空間の保存機能が追加されています。

アカウントモジュール

アカウントモジュールは、スマートアカウントのインストール可能なコンポーネントとして機能するスマートコントラクトです。モジュールインフラストラクチャはまだ非常に初期の段階にありますが、モジュールは次のようにして発見およびインストール可能であると予想しています：

開発者：埋め込みスマートアカウントは、Dapp開発者が決定した「プリインストール」モジュールを備え、彼らのユースケースにカスタマイズされた機能を備えたスターターウォレットを構築することができます

エンドユーザー：ウォレットインターフェースは、ユーザーが新機能を見つけてウォレットに追加できる「モジュールストア」を公開できます

AAが正式に分離されたことで、UserOpの検証と実行がどのように処理されるかが分かれ、モジュールには検証のみまたは実行のみのロジックを含めることができます。

バリデータ。UserOperationの検証フェーズ中に呼び出されます。彼らの主な機能は、UserOperationの署名を検証し、それが有効で実行されるべきかどうかを判断することです。マルチシグ、ECDSA、パスキー、マルチチェーン検証、およびセッションキーなどの例があります。セッションキーにより、dappsはユーザーを代表してサインすることができ、UXを簡素化し、カスタマイズ可能な権限と有効期限のある一時的なプライベートキーのように振る舞います。

実行者。UserOperationの実行フェーズ中に呼び出されます。それらはアカウントの実行ロジックを拡張し、元々実行できるアクションのより多様なセットを可能にします。例には、通常のERC-4337実行フローの外でトリガーされる自動アクションが含まれます。たとえば、価格が一定の閾値に達したときの自動トークンスワップなどがあります。

フック。アカウントに対して事前または事後の実行を行い、コントロールを強制します。例えば、フックは事後の実行を行い、特定の基準を満たす取引を元に戻して、ユーザーのセキュリティを向上させることができます。

Candideのような一部のウォレットは、ユーザーが直接インストールできるモジュールを開発していますが、私たちは、アプリストアのようなインターフェースでウォレット内に見つけることができるサードパーティのモジュールの豊かなエコシステム、またはdapp開発者によって「スターター」埋め込みウォレットに構成されることを予想しています。

スマートアカウントフレームワークは既にモジュールを考慮して設計されています。セーフのコア契約は、アカウントからモジュールを追加および削除するためのモジュール管理ロジックを処理しますが、実際のモジュール関連のロジックとストレージは完全に別の契約内でスコープされています。この関心の分離により、サードパーティモジュールが同じ状態を上書きするリスクを軽減し、アカウントのセキュリティと期待される動作を損なう可能性を軽減します。

Safe{Core}プロトコルは、モジュール、フック、マネージャー、およびレジストリを備えたオープンなフレームワークを導入し、Safeのウォレット製品からの学びを基にしたコンポーザブルなスマートアカウントエコシステムの育成を目指しています。

ZeroDevは、モジュール（「プラグイン」とも呼ばれる）を明示的に検証または実行のいずれかに分類しています。エグゼキューターモジュールは、バリデータモジュールとペアになっており、異なるバリデータを通じてカスタム機能を「ルーティング」するように設計されています。たとえば、NFTの転送を許可する「NFT転送」関数は、2FAを通じてのみNFTの転送を許可します。

モジュラースマートアカウントの堅牢なエコシステム構築に向けたいくつかの考慮事項:

相互運用性。複数のスマートアカウントベンダーがそれぞれ独自のアプローチでサードパーティがアカウントに新機能を追加できる方法について考えている中、モジュール開発者は、ベンダーロックインの軌道に乗っているか、複数のアカウント実装と準拠するために同じ機能を開発する技術的オーバーヘッドを管理する必要があります。これを緩和するためのいくつかの解決策:

モジュラースマートコントラクトアカウントおよびプラグインのERC-6900は、モジュラースマートコントラクトアカウント（MSCA）、モジュール（「プラグイン」）のためのインターフェースを定義し、任意の標準準拠アカウント実装およびプラグインを互換性のあるものとして動作させることができます。

Rhinestone’s* ModuleKit for building and testing smart account modules provides templates and frameworks for testing modules against different account implementations, a library of integrations (e.g. DeFi protocols), pre-built conditions for execution, and security automation to parse through module code and flag security vulnerabilities.

セキュリティ。ユーザーがウォレットにサードパーティのソフトウェアをインストールできるようにすることには、インターフェースがモジュールに関する関連情報をどのように整理して提示すべきかについて重要な問題があります。

EIP-7484は、独自に構築されたスマートアカウントモジュールの正当性とセキュリティを検証する手段を提供します。ここでは、レジストリを使用して監査人がこれらのモジュールのセキュリティに関する証明を行うことができます。フロントエンドとスマートアカウントは、レジストリをクエリして証明データを取得し、モジュールが安全に使用できることを検証できます。この実装の参照として、Rhinestoneレジストリを参照してください。

EIP-7512は、より広い意味で、スマートコントラクトによって解析可能な監査報告のオンチェーン表現の標準を作成することを目的としています。監査を実施した人や検証された基準に関する関連情報を抽出します。

発見性。登録簿は、開発者やエンドユーザーによってインストールされるスマートアカウントプラットフォームやウォレットインターフェイスによって公開およびクエリできます。

ウォレット機能を拡張する能力により、アカウントは開発者プラットフォームやWeb3製品・サービスの新たな配信チャンネルに変わります。Metamask Snapsを使用することで、セキュリティアラート（WalletGuard経由）、プライバシー機能（Nocturne経由）、StarknetやBitcoinなどのEVMチェーン以外との相互運用性を備えたブラウザ拡張ウォレットをカスタマイズすることができることが既に確認されています。

Chromeが開発者エコシステムを拡張し、拡張機能を通じてブラウザの機能を拡張することが可能になった時、これは、10年若いにもかかわらず、既存の壁に囲まれた庭園に対して市場支配力を持つようになりました。モジュラーアカウントが主流になると、ほとんどの人々にとってウォレット体験がどのように見えるか想像することは難しいかもしれませんが、許可されていない革新が進行中で、その過程を進めるための準備がすでに整っています。

新興開発パターンとその影響

進化したウォレットスタックとは、

開発者は、アプリのコンテキストでユーザーのために非管理型アカウントを作成することができ、コネクタSDKなどのツールを利用して、エンドツーエンドのオンボーディングジャーニーを構築する方法を選択することができます。

埋め込みウォレットは新しいウォレットカテゴリであり、それぞれのベンダーにはアカウントの携帯性、カスタマイズ可能性、および信頼の前提条件に関する独自の機能とトレードオフがあります。

2018年にEthereumのdappsを使ったことがある場合、サイトを読み込むとすぐにMetamaskのポップアップが表示されることを思い出すかもしれません。これは、ウォレットとdappsを接続する際の良いUXプラクティスの不足によるものであり、開発者はユーザーがブラウザの拡張ウォレットをインストールしているかどうかをチェックするためにハードコードされたチェックに頼ることがよくありました。window.ethereumこれにより、ユーザーが複数の拡張ウォレットをインストールしていると予測不能な動作が発生し、ユーザーは1つを選択する必要があり、ウォレット市場が競争力を失ってしまいました。

WalletConnect*通信プロトコルは、ユーザーが任意のウォレットを任意のdappに接続できるようにするために登場しました。Web3Modalは、ユーザーがdappを使用する際にどのウォレットを使用するか選択できるようにボタンとモーダルコンポーネントをラップするライブラリです。

今日、Web3Modalは、RainbowKit、Web3Onboard、ConnectKitなどの複数のウォレットコネクターライブラリと同様に、Dapp開発者のためにウォレットの検出とウォレットベースの認証プロセスを効率化するものです。これらのライブラリには、即座に利用可能なテーマオプション、ウォレット検索機能、およびウォレットがまだインストールされていない場合にユーザーをウォレットのインストール画面にリダイレクトする画面が提供されています。

最近、EIP-6963は、代替ウォレット検出メカニズムとして最終的に決定されましたwindow.ethereum,エクステンションによって提供されるDappsやインジェクトスクリプトが予測可能な方法で通信することを可能にします。この標準のおかげで、ユーザーは今、Dappsに接続するためのエクステンションウォレットを選択する際に、より多くの選択肢を持つようになり、ウォレットの競争市場がより開かれることになります。

コネクターライブラリはDevExとUXを大幅に改善しましたが、ユーザーがすでに追加のソフトウェアを持っているか、またはdappsとやり取りするために追加のソフトウェアをインストールすることが期待されるという点は、まだ採用のハードルが高いという期待があります。

すでに、次世代のウォレットライブラリであるフル機能の「オンボーディングSDK」と呼ぶことにしますが、ウォレットベースの認証に加えて、これらのSDKはメール、ソーシャル、SMSなどの代替サインアップおよびログインオプションを提供し、ユーザーのために追加のソフトウェアのインストールやDAppから離れる必要なく埋め込みウォレットを作成します。

開発者は、主要なプロバイダーが直接提供するコネクター（例：Magic、Privy、Web3Auth）を統合するか、複数のサービスをラップするコネクター（例：Dynamic、Thirdweb、0xPass）を使用して、公開したい認証オプションと作成したいウォレットのタイプを完全にカスタマイズして、プラグアンドプレイの選択肢を提供できます。オンボーディングSDKは、埋め込みスマートウォレットを作成するためにスマートアカウントプロバイダーとも統合でき、ガスレストランザクションやオン/オフラムプなどのさらなるUXの向上を提供できます。

「ヘッドレス」ウォレットの採用拡大と組み込みウォレットへの動きにより、かつてウォレットとDappsの間に明確な境界線があったものが曖昧になり始めています。

スタンドアロンウォレット対組み込みウォレット対アプリケーション固有ウォレット

現在、Web3ユーザーは、MetamaskなどのスタンドアロンウォレットやWalletConnectを介して提供されるウォレットを通じてdappsとやり取りすることに慣れており、資産とオンチェーンフットプリントを1つまたは数個のアカウントに蓄積しています。

さらに多くのdappsが埋め込みウォレットと複数のベンダーを通じてユーザーをオンボードしようとするにつれて、dapp開発者とエンドユーザーの両方にとってアカウント管理はすぐに複雑になります。dapp開発者は、ロックインを避けようとしながら複数のベンダーを評価し管理しなければなりません。エンドユーザーにとって、dappごとに新しいウォレットを作成することは、分断された資産とアイデンティティ管理の経験につながります。

特定のユースケース（例：ゲーム）では、アプリ固有のウォレットが望ましいですが、ユーザーが最初のdappにボードする必要がある場合や、web2サインとパスキーで埋め込みウォレットを作成し、同じサインイン者でログインして他のdappでアクルアセットを使用したい場合など、多くのケースがあります。

Capsuleは、彼らのサービスを使用するdapps全体でウォレットのポータビリティを提供するMPCベースの組み込みウォレットプロバイダーであり、同じメールログインを使用して既存のウォレットにアクセスできるようにユーザーに提供しています。これは、近いうちにWaaSプロバイダー全体で提供される必須のオファリングになると期待されます。

Moonchuteはユーザーが複数のスマートアカウントを仮想的に管理するのを支援します。彼らの統合アカウントマネージャーは、特定の署名者によって作成されたスマートウォレットを発見するためのアプリおよびAPIであり、ユーザーが複数のアカウントから資産を一元管理することができます。

ERC-7555は、SSOに着想を得た標準化されたインターフェースと、代替署名方式を使用して作成されたユーザーアカウントを発見するためのアプリケーション向けのリクエスト/レスポンスパターンを提案しています。ここでは、アプリケーションがユーザーを特定のプロバイダーのURI（自己ホストされたドメインである可能性があります）にリダイレクトし、署名者と関連するスマートアカウントアドレスを解析します。

EOAからの移行

AAのもう1つの優れた課題は、既存のユーザーが複数のEOAで獲得した資産とオンチェーン履歴をすでに持っているユーザーがスマートアカウントに移行するシームレスな方法です。

EIP-7377は、EOAがアカウントにコードを展開する一度限りのトランザクションを送信するためのプロトコル内メカニズムを提案し、事実上、EOAをスマートウォレットに「アップグレード」します。

Aarcは、dappsとエンドユーザー向けの資産移行の問題を解決することを目指しています。彼らのUIとSDKは、特定のソースアドレスの資産とアクセス許可をインデックス化し、ユーザーが移動させたい資産を選択できるようにします。これは、スマートアカウント、別のEOA、またはソーシャルログインで作成された埋め込みMPCウォレットなど、任意の宛先アドレスになります。スタンドアロンウォレットフローに慣れている既存ユーザーを持つdapps向けに、Aarcは埋め込みウォレットやAA機能を追加する際の移行プロセスを効率化するソリューションを提供しています。

マルチチェーンアカウント管理のAAの影響

AAおよびL2アクティビティの勢いを考えると、ユーザーが複数のチェーン上に資産を持つことで、スマートアカウントがEOAよりも主流になる未来が予想されます。

EOAのUXの利点の1つは、ユーザーが同じプライベートキーを使用して異なるEVMチェーン上で同じアドレスに自動的にアクセスできることです。欠点は、特定のアドレスを制御するキーを変更することはできず、ユーザーがプライベートキーを紛失した場合、すべての資金が失われる可能性があるということです。

アカウントの抽象化がキーストアを資産ストアから分離するため、同じアドレスを保持しつつ、特定のアカウントのキーを回転させることが可能になり、資金を移行せずに済みます。CREATE2を使用して、スマートアカウントは同じ初期検証キーおよびアカウントの実装を使用して、まだ特定のチェーンに展開されていないコントラクトでも、チェーン間で同じアドレスを維持することができます。

ただし、長期的には同じアドレスをチェーン全体で維持することはアンチパターンとなる可能性があります。

CREATE2は、EVMバイトコードの等価性を持つチェーンでのみ可能です。zk-Rollups（例：zkSync）を備えたマルチチェーンワールドでは、EVMにわずかな逸脱があるため、このアプローチは十分ではありません。

さまざまなアカウントにアクセスするために必要なキーがウォレットが追加の署名およびキーの回転機能を公開するにつれて時間の経過とともに変わることが予想されます。現在のセットアップでは、これにより、1つのチェーンのアカウントの署名者に対する変更が他のチェーンのアカウントに自動的に新しい権限を伝播することはありません。これにより、チェーン間でアカウントの権限の状態が迅速に変わることがあります。

マルチチェーンAA向けに提案されている長期的なソリューションには、次のものがあります。

ユーザーアカウントが権限をチェックする際に読み取る、複数のチェーンにわたる専用のキーストア契約。Soulウォレットからこの実装を参照してください。

異なるアドレスの抽象化レイヤーとしてENSマルチチェーンリゾルバーを使用する。

クロスチェーンアカウントと署名者の管理はまだ活発に研究されている分野です。ここでの最終目標は、ユーザーが、複数のチェーン上の複数のアカウントにアクセス権を持つキーを、極端に多数の取引を行わずに変更できるようにすることです。

結論と締めの言葉

アカウントの抽象化は、契約ベースのアカウント（EOAの代わりに）をブロックチェーン上の第一級エンティティとして作成することにより、署名者をアカウントから切り離す動きであり、ユーザーに鍵の管理とアカウントの権限設定の柔軟性を提供します。

スマートアカウント起動トランザクションの中継の標準としてのERC-4337は、AAを収容するためにウォレットインフラの進化を促し、新しい市場構造、ウォレットカテゴリ、dapp開発、およびユーザーオンボーディングパターンが生まれるきっかけとなりました。

ウォレットスタックは、開発者がエンドユーザーエクスペリエンスをカスタマイズする方法についてオプションを提供するために、サインアップ者、リレイヤー、アカウントプロバイダー、アカウントモジュールに分解されました。これには、各プロバイダーのトレードオフをガスオーバーヘッド、検閲耐性、ベンダーロックイン、相互運用性の観点から評価する追加のオーバーヘッドが伴います。

EOA からの移行経路やマルチチェーンコンテキストでのアカウント抽象化は、まだ継続中の研究分野です。提案された解決策の最初の実装が来年に行われることを期待しています。

これらの展開は、エコシステム全体に重要な影響を与えると信じています。

新規ユーザーにとって、ウォレットはもはやWeb3への唯一の入り口ではありません。アプリケーションは、埋め込みウォレット、ガス不要トランザクション、およびウォレット内のオンランプを通じて、著しく改善されたオンボーディングを提供します。

現在のユーザーにとって、アプリがセッションキーなどの機能を活用することで、オンチェーン体験がよりシームレスになります。 パワーユーザーは、モジュールを通じてアカウントの権限や追加のウォレット機能をより細かく制御できます。

開発者にとって、モジュラーアカウントインフラストラクチャはウォレットをオペレーティングシステムに変えます。モジュールマーケットは、Web3製品やサービスの新しい許可なし配信チャネルです。

ウォレットインフラストラクチャーは引き続きweb3の採用を促進します。私たち1kxは、この記事で議論されているアイデアの先駆者であるチームを支援していることを誇りに思っており、今後もこの領域を監視し続けます。

この分野でソリューションを検討しているか、このトピックに関する追加の考えがある場合は、お知らせください@nichanank - あなたとお話ししたいです。

David Sneider、John Rising、Konrad Kopp、Kurt Larsen、Marc Sednaoui、Dogan Alparslan、Vivian Phung、Derek Rein、Tom Terado、Diana Biggs、Mel Quarto、およびpet3rpan に、この下書きのレビューをしていただいた皆様に感謝いたします。

*1kxポートフォリオ企業を示します

声明：

1. 本文转载自[1kx]，著作権は元の作者に帰属します[1kx]，如对转载有异议，请联系Gate Learnチームチームは関連プロセスに従ってできるだけ迅速に対応します。
2. 免责声明：本文に表れる見解や意見は著者個人の見解であり、投資アドバイスを構成しません。
3. 他の言語版は Gate Learn チームによって翻訳され、言及されていないGateの場合、転載、配信、または翻訳された記事の模倣を行ってはなりません。