原作者：Rui
多くの人が言っているように、アカウント抽象化 (AA) テクノロジー、特に ERC-4337 は、セルフホスト型ウォレットのユーザー エクスペリエンスに革命をもたらし、大量導入に向けた拡張を可能にすることを約束しています。しかし、2023 年 5 月が近づくにつれて、この基準はまだ初期段階にあり、機会とリスクが存在することを認識する必要があります。
※バージョンアップのスピードが速いため、記事の内容が古くなってしまう可能性がございます。また、この記事はあくまで個人的な意見に基づいたものであることをご了承ください。
TL;DR
ERC 4337 ：
AA 標準はまだ初期段階にありますが、多くの革新的なビルダーがそれをさらに発展させるために取り組んでいます。エコシステムのサポートと MetaMask のような大規模製品の人気を背景に、AA がその開発を加速し、エキサイティングな結果を生み出すことが期待されます。
L2：
AA の採用は L2 ソリューションによって異なります。 Optimism や Arbitrum などの大規模な L2 は AA をネイティブにサポートしていませんが、ZKSync や Starknet はサポートしています。
バンドラーサービス:
AA に対して強気であり、イーサリアムと整合性のある EVM に相当するすべての L2 がネイティブ AA をサポートしていない場合、ネットワーク内で AA をサポートするにはバンドラー サービスが必要です。
オープンソースの性質により、Bundler サービスは非独占的なものとなり、収益化への道が困難になります。ネットワークのセキュリティと安定性を確保するために、さまざまなバンドラー サービスが使用されます。
プライベート バンドラーは、プライバシー、セキュリティ、その他の機能を特定のニーズに合わせて調整することで収益を得ることができます。
ペイマスターサービス:
Paymaster サービスは (Bundler サービスと比較して) 比較的集中化されており、契約はオープンソースですが、バックエンドはクローズドです。
Paymaster サービスには、法定通貨預金、為替、ブリッジング、自動支払い、セッション、スポンサー料などの機能と組み合わせて支払いシナリオを強化し、それによって dApp の使いやすさを向上させることができる収益モデルがあります。
AA ウォレットと SDK:
AAウォレットは、キー管理システム、ソーシャルリカバリ、ガス料金スポンサーシップ、マルチチェーンアカウント同期、サポートされているブロックチェーンなどを含む製品の観点から評価できます。
AA の利点は、スムーズなログイン エクスペリエンスを提供するだけではありません (Web3 認証はホスティング経由で利用可能です)。 AA は、複雑でカスタマイズされたオンチェーン インタラクションにおいて dApp に多くのメリットを提供することもできます。
この戦いの鍵を握るのはBDだ。ほとんどのウォレットは Defi と GameFi をターゲットにしており、エコシステムのサポートを得て、大規模な dApp を説得し、ブレークスルーポイントを見つけることに取り組んでいます。
収益化モデルを徹底的に調査する必要があります。 To Business (To B) モデルはあまり収益を上げられず、独自のユーザーも蓄積しない可能性がありますが、To Customer (To C) モデルは高価値のシナリオを見つけて、ボリュームに基づいて利益を得る必要があります。スイッチング機能とブリッジング機能を統合すると利益が得られますが、重要なのは持続可能なモデルを見つけることです。
暗号通貨ウォレットについて学ぶ
分類
Ethereum ネットワークには、MetaMask などの外部所有アカウント (EOA) ウォレットと、Safe などの契約アカウント (CA) の 2 種類のアカウントがあります。
EOA ウォレットとコントラクト ウォレットの主な違いは、その制御方法です。 EOA ウォレットは秘密鍵を介して個々のユーザーによって制御されますが、コントラクト ウォレットはスマート コントラクトによって制御されます。 EOA ウォレットはよりシンプルで、個人の暗号通貨保有の管理に使用されますが、コントラクト ウォレットにはより複雑なルールがあり、特定の目的に使用できます。
From Bitcoin Insider
問題点
EOA ウォレットのユーザーは、秘密鍵の保護に注意を払う必要があります。秘密キーに間違いや脱落があると資金が失われる可能性があるため、EOA ウォレットの使用コストは比較的高く、リスクが高くなります。経験豊富な暗号通貨ユーザーでも、一度の間違いや不注意な動きによってアカウントの制御を失う可能性があります。複雑な操作、ガス料金をスキップできないかガス料金を支払うことができない、ウォレット機能が制限されているなどはすべてユーザーを悩ませる問題です。
スマート コントラクト ウォレットはいくつかの問題の解決策を提供しますが、イーサリアムでは現在、すべての操作を ECDSA で保護された EOA からのトランザクションにパッケージ化する必要があります。これにより、追加の取引手数料が発生し、追加の 21,000 ガス料金が消費されます。また、潜在的な集中化リスクと複雑な操作が伴います。ユーザーは 2 つのアカウントを管理し、ガス料金を支払うために別の EOA に ETH を入金するか、集中中継システムに依存して支払う必要があります。 。
これらの問題点により、新しい AA 標準である ERC-4337 が誕生しました。
ERC 4337 提案:
CAの問題
現在、これらのことはすべてコントラクト ウォレットで解決できますが、イーサリアム自体では、ECDSA で保護された EOA から発信されるトランザクションですべてをラップする必要があり、その結果、次のような結果になります。
追加の取引手数料:各ユーザー操作は EOA によって開始される必要があり、追加の 21,000 ガス料金が必要です。
複雑さと集中化:ユーザーはガス料金を支払い、両方のアカウントの残高を管理するために別の EOA に ETH を入金するか、通常は集中管理されている支払い用の中継システムに依存する必要があります。
EIP-86 や EIP-2938 など、イーサリアムベースのブロックチェーンにアカウント抽象化を実装する試みが長年にわたっていくつか行われてきました。ただし、これらの方法はいずれもコンセンサス層の変更が必要であり、実装が難しいため、機能しません。
4337機構
ERC-4337 は、UserOperation と呼ばれる高レベルの疑似トランザクション オブジェクトを導入することにより、アカウントの抽象化を実装します。これは、バンドルの概念という点ではロールアップに似ています。幸いなことに、この標準により、コンセンサス層を変更せずにアカウントの抽象化を構築できます。
EIP 4337 のモジュール設計は、スマート コントラクト ウォレットのアカウント抽象化機能を複数のポートに分割します。
Bundler:
バンドラーは EOA です。すべてのトランザクションは EOA によって開始される必要があるため、Bundler を使用すると、ユーザーは EOA 秘密キーを作成して記憶することなく、スマート コントラクト ウォレット トランザクションをトリガーできます。
バンドラーの役割: UserOperation を検証し、一連の UserOperation オブジェクトを単一の「バンドルされたトランザクション」にパッケージ化します。認証された UserOperation の内容をパブリックまたはプライベート メモリ プールにブロードキャストします。
Bundler は、UserOperation の実行後に、最優先料金と実際のガス料金の差額をポケットに入れることで、経済的な利益も得ることができます。通常のトランザクションのリレーラーと同様に、バンドラーはバンドルされたトランザクションで UserOperation を命令することで MEV を取得できます。
エントリーポイント：
エントリ ポイントは、UserOperation を実行するためにすべてのバンドラーが呼び出す必要があるグローバル コントラクトです。エントリ ポイントは、バンドラーとスマート コントラクト ウォレットの間の仲介者として機能します。
handleOp による検証と実行: handleOp 関数は、UserOperation を入力パラメーターとして使用します。まず、UserOperation がチェーン上で検証され、指定されたスマート コントラクト ウォレット アドレスによって署名されているかどうか、ウォレットに Bundler を補償するのに十分なガス料金があるかどうかが確認されます。検証が成功すると、関数シグネチャに基づいて入力パラメータが実行されます。
スマート コントラクト ウォレットに入金する必要があるトークンは、バンドラーにガス料金を支払います。バンドラーが EOA を使用して handleOp をトリガーすると、ガス料金が生成されます。スマート コントラクト ウォレットは、独自の残高でガス料金を支払うことも、Pymaster から支払いをリクエストすることもできます。考えられる失敗: ガス料金が不十分なため、検証ステップが失敗します。十分なガス料金がある場合でも、実行時エラーなど、UserOperation 実行ステップが失敗する可能性があります。実行が成功したかどうかに関係なく、エントリ ポイント コントラクトは、handleOp 関数をトリガーするために Bundler にガス料金を支払います。エントリーポイントコントラクトは、スマートコントラクトウォレットにトークンを担保として追加または引き出す機能を提供します。
スマートウォレット:
スマート コントラクト ウォレットのメイン コントラクトは、UserOperation の検証と実行のステップを分離します。これを分離することで、Bundler は UserOperation をオフチェーンで検証し、ガス料金を支払うことなく悪意のあるトランザクションを除外できます。
検証ステップは validateOp 関数で定義されます: 初めて validateOp が呼び出されたとき、Bundler はオフチェーン検証をシミュレートし、UserOperation で署名を検証し、スマート コントラクト ウォレットに十分なガス残高があることを確認します。2 回目の validateOp の呼び出しでは、エントリポイントコントラクトが実行され、UserOperation の前にオンチェーン検証が実行されます。
Paymaster:
Paymaster は、イーサリアムのガス料金を支払うための ERC 20 代替トークンの使用やガス料金なしのトランザクションなど、スマート コントラクト ウォレットのガス抽象化ロジックを定義します。
Paymaster は、dApp によって展開されるスマート コントラクトで、Paymaster の validatePaymasterOp をトリガーできます。
Wallet Factory:
Wallet Factory は、スマート コントラクト ウォレットを作成するための公的契約です。ウォレット ファクトリのアドレスと新しいスマート コントラクト ウォレットのパラメータが initCode に埋め込まれると、Bundler は対応するウォレット ファクトリをトリガーして、指定されたパラメータでスマート コントラクトを作成します。人気の Wallet Factory コードは完全に監査されているため、Wallet Factory を使用してウォレットを作成する方が安全です。
Wallet Factory は、Bundler からより多くのトラフィックを取得するために、エントリ ポイントに ETH をステークし、UserOperations に優れたサービスを提供し続ける必要があります。
ユーザーは、initCode が入力された UserOperation を送信して、Bundler に CA ウォレットの作成を要求できます。
ユーザーは、特定のカスタマイズパラメータを備えた Wallet Factory を選択して、CA ウォレットをカスタマイズできます。
署名アグリゲーター:
署名アグリゲーターは、トランザクションの検証と実行を高速化するために、複数のトランザクションの署名をバイトに集約するために使用されます。異なるスマート コントラクト ウォレットは異なる署名アルゴリズムを使用するため、最初に同じ署名アルゴリズムを使用して UserOperations を集約する必要があります。
ガス料金の節約: オンチェーン暗号化の計算には大量のガス料金が消費されるため、集約署名スキーム (BLS など) を使用すると、オンチェーン検証中のガス料金を節約できます。
Bundler は、UserOperations を一度に 1 つずつ検証するのではなく、複数の署名集約コントラクトを使用して複数の集約署名を生成します。
Bundler は UserOperation 配列、集約署名、および集約アドレスをエントリ ポイントに渡し、各 UserOperation グループ セッションは対応する署名集約の validateSignature 関数を呼び出します。
検証に合格した後、Bundler はスマート コントラクト ウォレット上でこの一連の UserOperation を実行します。
アグリゲーターは、エントリーポイント契約にイーサリアムを賭け、良好な UserOperation サービス記録を維持することも求められます。
AAの利点
ガスの抽出:
ガスの抽象化にはガスを使用しないトランザクションが含まれており、任意の ERC 20 トークンを使用してガス料金を支払います。このロジックは、Paymaster コントラクト内またはリレーラー経由で実行できます。 AA の場合、多くのスマート コントラクト ウォレット自体が EIP 4337 準拠のペイマスター コントラクトを実装し、エントリー ポイント コントラクトにトークンをステークして、ユーザーがガス料金を支払うのを支援できます。
社会的回復:
秘密キーが紛失または漏洩した場合、ユーザーは正規のウォレット所有者として新しいキーを認証できます。ソーシャル ログインとソーシャル リカバリのロジックは通常、ウォレットのメイン コントラクトで定義されます。電子メール、マルチ署名、MPC または SWIE (イーサリアムでログイン) など、さまざまな方法が使用できます。
トランザクションのバッチ処理:
トランザクションのバッチ処理は、ウォレット ユーザーが単一のオンチェーン トランザクション内で複数のトランザクションを実行できるようにする、スマート コントラクト ウォレットに固有の機能です。
クロスチェーンブリッジングと接続ブリッジの統合:
現在、多くのウォレットはサードパーティプロバイダーと協力して、法定通貨の入出金チャネルとクロスチェーンブリッジをウォレットに統合しています。これらの入出金チャネルとクロスチェーンブリッジは、ガス抽象化の支払い契約 (Paymaster) とさらに統合できます。
モジュール設計：
おそらく AA の最大の強みの 1 つは、Bundler、Paymaster、その他の要素を柔軟に組み合わせることができるモジュール型サービスです。
AAのデメリット
から stackup
手数料は (おそらく) 比較的高いです。
ERC-4337 を使用して単純な送金を行う場合、コントラクトを呼び出す必要があるため、従来のウォレット (EOA と呼ばれることが多い) を使用するよりもコストがはるかに高くなります。
ただし、ロールアップ ネットワークでは、ERC-4337 を使用した単純な転送の方が EOA よりも安価になる可能性があります。、署名を集約してメインネット上のデータ量を削減するためです。
まだ最終化されていない規格:
課題としては、トランザクションのスケーラビリティの拡大による攻撃ベクトルの増加、新しい標準への移行時の未知のエラーやセキュリティ リスクの可能性、すべてのトランザクションが適切に署名および検証されることを保証するための強力で安全なグローバル エントリ ポイント契約の必要性などが挙げられます。
Layer 2
✅ と ❌ は、ネイティブ AA がサポートされているかどうかを示します。
Optimism: ❌
Optimism バージョン 1 には、スマート コントラクト ウォレットのアカウント抽象化を実装するための 3 つの OVM オペコードがあります。ただし、バージョン 2 では一貫性とセキュリティ上の理由からこれらのオペコードが削除されており、アカウント抽象化のサポートに関する公式発表はありません。
Arbitrum: ❌
現在、Arbitrum に基づいて構築されたスマート コントラクト ウォレットがいくつかありますが、アカウント抽象化のサポートに関する公式発表はありません。
Starknet: ✅
Starknet には検証および実行機能を備えたスマート コントラクト アカウントのみがあり、すべてのアカウントは署名を検証し、ガス料金を確保するためにこれらの機能を実装する必要があります。 Starknet では、未実行のトランザクションを防ぐために、検証関数が外部コントラクト状態を呼び出すことを禁止しています。ただし、Starknet には、Paymaster のような取引手数料抽象化プロトコルである UserOperations がないこと、新しい契約を作成するにはトークン残高のあるアカウントが必要であることなど、イーサリアムとの違いがまだいくつかあります。さらに、Starknet の注文者は、検証されたトランザクションが失敗した場合にガス料金を請求できませんが、イーサリアムでは請求できます。
zkSync: ✅
zkSync は EOA アカウントと契約アカウントを区別しません。そのアカウント モデルは EIP 4337 に似ており、個別の validateTransactiom 関数とexecuteTransaction 関数が含まれています。 Paymaster インターフェイスには、validateAndPayForPaymasterTransaction 関数と postOp 関数も含まれています。ただし、検証プロセス中にデプロイされた外部コントラクトや外部ストレージを呼び出す機能などの違いがあります。 Paymaster は、トランザクションの検証中に外部ストレージを呼び出すこともできます。
AA インフラストラクチャ:
現在、Stackup、Etherspot、Candide、Infinistism、Pimlico などの優れたプロジェクトがインフラストラクチャの構築を試みています。
バンドラーサービス:
ビルダー：
積み重ねるGolangの実装
キャンディードさんのPythonの実装
無限主義TypeScriptの実装
スカンダ by Etherspot —TypeScriptの実装
ある程度のコンセンサス:
公共サービス
大多数のバンドラーはオープンソースの性質を持っているため、非独占的であり、非競争的です。オープン ソース コードをコピーすることで、どの RPC エンドポイントでも Bundler を実行できます。
実現するのが難しい
Bundler を実行する RPC エンドポイントは API キーを介してサービス使用料を請求しますが、Paymaster はサードパーティのリチャージプロバイダーや DeFi プロトコルアグリゲーターによって使用される可能性があるため、Bundler サービスは他のインフラストラクチャ (支払い契約の Paymaster など) よりも収益化が困難です。プロバイダーと連携して、簡単に料金の差額を獲得できます。
重要なインフラ
UserOperations を検証して実行するには、分散化を高めるためにできるだけ多くのバンドラーが必要です。現在サードパーティのバンドラー サービス プロバイダーは Stackup と eth-infinitim だけであるため、このようなバンドラー サービス プロバイダーがさらに必要です。
機構
Bundler は、共有メモリ プールと同様に、詳細について合意することなく、メッセージを配信し、ユーザー アクション自体を伝播します。 Bundler にはスパムをフィルタリングする重要な機能があり、Bundler は独自の経済的理由から、メモリ プールの安全性を確保するために可能な限り監視したいと考えています。
バンドラー サービスの違い:
バンドラー サービスは、汎用インフラストラクチャにすることも、ウォレット専用に構築することもできます。ウォレット プロジェクトは最も基本的なバンドラーの構築を優先する場合がありますが、サードパーティ プロバイダーはさまざまなシナリオに合わせてモジュール式バンドラーを構築する必要があります。
Ethereum ノードと同様に、バンドラー サービスはさまざまなプログラミング言語で実装され、単一障害点を防ぎ、エコシステムに利益をもたらします。
Bundler サービスは、プライベート メモリ プールとパブリック メモリ プールをサポートし、プライベート メモリ プールのカスタマイズ オプションを提供します。
ペイマスターサービス
Bundler サービスと比較すると、Paymaster サービスは比較的集中化されており、コントラクトはオープンソースですが、バックエンドはクローズドです。
Paymaster サービスには、法定通貨預金、取引所、ブリッジング、自動支払い、セッション、スポンサー料などの機能を統合することで、dApp の使いやすさを向上させる収益化モデルがあります。
AA ウォレットと SDK:
製品評価
キー管理システム:
マルチシグネチャ ロジック (セキュリティ): 2/3 や 3/5 などのマルチシグネチャ ロジックのみを実装できます。
シンプルな権限管理 (シーケンシャル): キーの重みを設定し、操作アカウントのしきい値を設定できます。
ロールベースの権限管理 (Unipass): キーの重みとロールを設定できます。役割が異なれば、異なる操作を実行できます。各役割には、対応するしきい値もあります。このしきい値を超えると、対応するロールの権限が強制される可能性があります。
社会的回復方法
ガス料金のスポンサーシップ: 独自のリレーを構築するか、Bundler + Paymaster をセットアップします
マルチチェーンアカウントの同期
統合されたマルチチェーンアドレス
サポートされているブロックチェーン
仕事
ビジネスモデル: To B/To B+To C/ToC
dAppsとの連携：さまざまなチェーン上のステーブルコインやDeFiなどの巨大インフラdAppsと連携します。
ユーティリティ: NFT マーケットプレイス、ランチパッドなどを統合します。
外部サポート: イーサリアム財団またはその他の有名なベンチャーキャピタル機関からのサポート
オリジナルの英語レポート2023 年 5 月に初めてリリースされました。中国投資に関する研究コンテンツをさらにご覧になりたい場合は、公開アカウント [SevenXVentures] をフォローしてください。
この記事は SevenX 調査チームによるオリジナルであり、コミュニケーションと学習のみを目的としており、投資の参考となるものではありません。引用する必要がある場合は出典を明記してください。
