インフラストラクチャはアカウントの抽象化を通じて何十億ものユーザーをどのようにサポートしていますか?

強気市場であろうと弱気市場であろうと、イーサリアムのエコシステムは常に構築され、自己最適化されています。その中でも、アカウント抽象化 (AA) は近年重要な進歩を遂げており、アプリケーション、インフラストラクチャ、ユーザー、開発者を含むイーサリアム エコシステムのあらゆる部分に浸透しています。 AA の大規模な導入により、全体としてブロックチェーン利用の敷居が下がり、web2 のユーザー エクスペリエンスが web3 業界に導入されることが予想されます。

潜在的に数十億ドル規模の AA 市場の機会を捉えるために、BlockPI は AA を自社のインフラストラクチャ サービスに統合することを計画しています。 BlockPI は、AA 分野での統合とイノベーションを通じて、AA ユーザーにブロックチェーン コントラクト ウォレット アカウントを操作するためのより便利で効率的な方法を提供することに尽力しており、この業界のリーダーになることを望んでいます。

この記事では、BlockPI チームが AA についての理解を深め、インフラストラクチャ サービス プロバイダーの観点から考えを共有します。

EOA とコントラクトウォレット

AA の概念は、EOA アカウントの制限に由来しています。 EOA アカウント (外部所有アカウント) は、公開キー (ブロックチェーン アドレス) で表され、秘密キーを介してアクセスされるイーサリアムのユーザー アカウントです。これはイーサリアム エコシステムの主要なコンポーネントであり、ユーザーがブロックチェーン上で送金したり、スマート コントラクトを操作したりできるようにします。ただし、多くの人にとって、EOA を使用すること自体が困難な作業になる可能性があります。さらに、現在の EOA アカウントには使用上まだ不便な点があり、ユーザー エクスペリエンスに影響を与えています。

一つ目は、ガス料金の問題です。各トランザクションでは、ユーザーにガス料金としてかなりの量の ETH がかかります (例として 25 グウェイのガス料金を取り上げます。単純な ETH 送金のガス料金は約 0.5 米ドルで、契約のやり取りではより高価になります)またはガス価格が高い場合）。このため、特にネットワークが深刻な輻輳の時期には、小規模なトランザクションのコストが非常に高くなります。さらに、Gas の支払いには ETH のみが使用できるため、ユーザーはウォレットに ETH を保持する必要があり、多くのユーザーにとって参入障壁が高くなります。

第 2 に、ユーザーが実現したい複雑な操作の場合、EOA は他のスマート コントラクトに依存する必要があります。たとえば、ユーザーが時間指定の定期転送を設定したい場合、この操作を実現するには、ユーザーはこの機能を使用して ETH をスマート コントラクトに転送する必要があります。

EOA の 3 番目の問題は、署名暗号化アルゴリズムが固定されていることです。イーサリアム ネットワークは、secp256k1 と呼ばれるデジタル署名アルゴリズムを使用して、トランザクションの信頼性とセキュリティを保証します。このアルゴリズムはシステムにハードコーディングされており、ユーザーは他の暗号化アルゴリズムの使用を選択できません。

上記の 3 つの問題に加えて、EOA の公開鍵と秘密鍵の結合関係も問題です。秘密キーはユーザーが EOA にアクセスする唯一の方法であり、秘密キーを紛失した場合は取得できません。これは、それに関連付けられた EOA 内のすべての資産が回復不能になることも意味します。

同時に、EOA には特定の線形タスクを実行する際の制限もあります。たとえば、ユーザーが 1 回の操作でトークンの承認 (承認)、交換 (スワップ)、および承認解除 (トークンの非承認) を行う場合、3 つの別々のトランザクションを実行する必要があり、非効率的で時間がかかります。

良いニュースは、コントラクトウォレットが上記の問題をすべて解決できることです。コントラクト ウォレットは本質的に、AA を実装する特定のタイプのスマート コントラクト アカウントであり、イーサリアム上のユーザーのウォレットとして使用できます。また、より柔軟でパーソナライズされた資金管理方法をユーザーに提供できます。イーサリアムスマートコントラクトで実現できるロジックであれば、コントラクトウォレットでも対応する機能を実現、提供することが可能です。

具体的には、複数のコントラクトウォレット操作をオンチェーントランザクションにパッケージ化でき、これらの操作でこのトランザクションのガスコストを共有できます。第三者がガス料金を支払う意思がある場合、契約ウォレットを使用するユーザーにガス料金を支払う必要はありません。コントラクトウォレットは、複数の線形タスクを一度に完了することもできます。また、コントラクトウォレットはカスタム署名の暗号化アルゴリズムにも対応しており、ウォレット復元機能なども設定されています。

コントラクトウォレットの利点についての議論が続く中、イーサリアムコミュニティは実際にコントラクトウォレットに関する長期的な研究を行ってきました。多くの EIP がアカウントの抽象化に関連する問題を検討してきましたが、2021 年現在、統一された標準は確立されていません。以下にいくつかの代表的な EIP を示します。

EIP-86

もともと 2017 年に Vitalik Buterin によって提案されました。このスキームは、署名検証と nonce チェックを「抽象化」するという共通の目的を持つ一連の変更を実装することで、ユーザーが任意の署名/nonce チェックを実行できる「アカウント コントラクト」を作成できるようにします。

EIP-2938

2020年に発表されました。この EIP のタイトルは「アカウントの抽象化」です。 AA の概念は、この EIP で詳しく説明されています。新しいタイプのトランザクションである AA トランザクションが導入されます。トランザクションはエントリ ポイント アドレス (EntryPoint アドレス) によって開始され、AA コントラクト ウォレットを呼び出します。 EIP-2938 は統一仕様を提供し、AA アカウント抽象化をイーサリアム コンセンサスに正式に導入します。具体的には、2 つの新しいオペコード、3 つのグローバル変数、およびイーサリアム コンセンサスとは異なるペイロード構造が導入されています。

EIP-3074

2020年に発表されました。この EIP では、AUTH と AUTHCALL という 2 つの EVM 命令が導入されています。 AUTH は、ECDSA 署名機関に従って環境変数を設定します。 AUTHCALL は、承認されたアカウントとして通話を送信します。これにより、スマート コントラクトが EOA に代わってトランザクションを送信できるようになります。しかし、これはまだ AA に対する完璧な解決策ではありません。 EIP-3074 は、オーソリゼーション トランザクション プロセスにおいて、元の値の送信に関して一定の制限を設けています。また、ユーザーが EOA にアクセスできなくなった場合でも、資産を取り戻す方法はありません。秘密鍵が漏洩した場合、ユーザーはすべての資産を新しいアカウントに移す必要があります。

上記の提案はいずれも、コンセンサス層での変更の必要性または提案が十分に包括的ではなかったため、イーサリアム プロトコルに正式に組み込まれませんでした。したがって、イーサリアムコミュニティはコンセンサスを変更せずに AA をイーサリアムプロトコルに導入する方法を模索し続け、最終的に EIP4337 を提案しました。

ERC - 4337

EIP-4337 はもともと 2021 年 9 月に提案され、2023 年 3 月に ERC-4337 として認可されました。著者には、Vitalik Buterin、Yoav Weiss、Kristof Gazso、Namra Patel、Dror Tirosh、Shahaf Nacson、Tjaden Hess が含まれます。

EIP-4337 は、イーサリアムのコア プロトコルを変更せずに AA を導入する破壊的な提案です。 EIP-4337 は最終的に ERC-4337 標準となり、ビルダーはこれを使用して独自のスマート コントラクト ウォレットを実装できます。同時に、この標準では、「バンドラー」や「UserOperation mempool」などの追加のインフラストラクチャも導入されています。このようにして、実際にはブロックチェーンシステムの上位層に同様の機能を持つイーサリアムメモリプールを複製します。ユーザーが送信するものは単一のトランザクションではなく、UserOperation になります。これらの UserOperations は単一のトランザクションにパッケージ化して Ethereum に送信できます。

以下は、イーサリアム [公式ドキュメント] の ERC-4337 の詳細な技術説明と、いくつかの役立つコメントです。

ERC-4337 の主な役割とその定義

• UserOperation - ユーザーに代わって送信されるトランザクションの構造を記述します。混乱を避けるため、これには「トランザクション」という名前が付けられておらず、バンドラーに送信されて、他の UserOperations と一緒にバンドルとしてパッケージ化されます。その後、バンドルは単一のトランザクションとしてオンチェーンに送信されます。

• 送信者 - UserOperation を送信する契約アカウント。ウォレット コントラクトは、ERC-4337 標準に従って IAccount インターフェイスを構成する必要があります。

• EntryPoint - UserOperations バンドルを実行するグローバル シングルトン コントラクト。バンドラー/クライアントは、サポートされている EntryPoint をホワイトリストに登録します。コントラクトは、Infinitim チームによって監査および導入が承認され、すべての UserOperations を処理し、ウォレット ファクトリ、アグリゲーター、ペイマスターなどの他のロールとコントラクトを接続する責任があります。コントラクトはすべて、EVM 互換チェーン上の同じアドレスにあります。

• バンドラー - メモリプールから複数の UserOperations をパックし、EntryPoint.handleOps() トランザクションを作成するノード (現在のブロックプロデューサーノード)。 Bundler サービスはブロックチェーン ノードから独立して実行でき、パッケージ化された UserOperations を RPC 経由で送信できます。

• アグリゲーター — 集約された署名を検証するためにアカウントによって信頼される補助契約。バンドラー/クライアントのホワイトリストがサポートする署名アグリゲーター。アグリゲーターは、ERC-4337 標準に従って IAggregator インターフェイスを構成する必要があります。

• Paymaster - お客様に代わって Gas を支払うことができるスマート コントラクト。 EntryPoint コントラクトに十分な ETH をデポジットすると、送信者に UserOperation の Gas 料金をスマート コントラクトに支払うことができ、Gas 抽象化を効果的に実装できます。 Paymaster は、ERC-4337 標準に従って Paymaster インターフェイスを設定する必要があります。 Paymaster は Sender と契約を結ぶことができます。たとえば、Sender は Paymaster に USDC を支払い、Paymaster は送信する UserOperations の Gas を ETH を使用して支払います。実際、Paymaster はあらゆるサポートを選択できます。

トークン

、ERC-20を含む

トークン

他のチェーンでも

トークン

。

• ウォレット ファクトリー - ERC-4337 ユーザー向けのコントラクト ウォレットを作成できるスマート コントラクト。 Wallet Factory の導入はライセンス不要です。オンチェーンのスマート コントラクトとして、そのコードは公開されており、誰でもレビューできます。広く使用されているウォレット ファクトリーは、専門家による完全な監査を受ける必要があります。

以下の図は、EntryPoint コントラクトが他のアクターとどのように対話するかを説明しています。

• バンドラーは、UserOperation を入力として受け入れる EntryPoint コントラクトの handleOps 関数を呼び出します。

• handleOps はチェーン上の UserOperation を検証し、指定されたスマート コントラクト ウォレット アドレスによって署名されているかどうかを確認し、ウォレットに Bundler を補うのに十分な Gas があるかどうかを確認します。

• 検証に合格した場合、handleOps は UserOperation の calldata で定義された関数と入力パラメーターに従ってスマート コントラクト ウォレット関数を実行します。

一方、Bundler が EOA を使用して handleOps 関数をトリガーすると、Gas 料金が発生します。スマート コントラクト ウォレットは、自身のアカウント残高から Bundler Gas 料金を支払うことも、Paymaster コントラクトに支払いを要求することもできます。 UserOperations は、十分な Gas がなければオフチェーン検証ステップを通過できません。つまり、チェーン上でトランザクションを実行する前に失敗します。十分な Gas がある場合でも、UserOperations は実行時のランタイム エラーやその他の理由により失敗する可能性があります。 UserOperation の場合、コントラクトの実行が成功したかどうかに関係なく、EntryPoint コントラクトは handleOps 関数をトリガーするバンドラーにガス料金を支払います。

ERC-4337 の発効後、ユーザーは 2 つの方法でブロックチェーン トランザクションを開始できるようになります。 1 つは従来の方法、つまり EOA がトランザクションを直接開始する方法です。もう 1 つは、ERC-4337 標準を使用して Bundler を通じて UserOperation を開始し、その後 Bundler がそれを他の UserOperation とともにパッケージ化してネットワーク チェーンに送信する方法です。以下のフローチャートは、通常の EOA 送信トランザクションと ERC-4337 コントラクト ウォレット送信 UserOperation の違いを示しています。

道路は舗装されていますが、歩行者はまだ少ないです

ERC-4337 は、ユーザーと開発者が Ethereum 上で AA を使用および構築するための強力なフレームワークを提供します。この枠組みは重要な進歩ですが、対処し解決する必要がある課題と不確実性がまだいくつかあります。

AA の導入はまだ初期段階にあります。 Dune ERC-4337 分析パネル [ERC-4337 Account Abstraction] によると、チェーン上で実行されたのは 65,000 以上の UserOperations のみで、その 90% は Polygon によるものでした。したがって、現在実行されている UserOperations の数はまだ非常に少なく、そのほとんどは開発者テストであり、実際のユーザーから提供されるのはごく一部のみです。 AA を統合した製品はまだ初期段階にあることに注意してください。現時点では、バンドラー全体がまだ損失の状態にあり、現在の損失は約 700 MATIC 以上であることがわかります。これは主に、Polygon 上の一部のバンドラーが必要なガスを誤って見積もっており、その結果、EntryPoint によって返されるガスが、送信されたバンドルによって消費されるガスよりも少なくなることが原因です。この問題は、Bundler クライアント レベルで解決する必要があります。

それ以外にも、対処する必要のある問題がいくつかあります。そのような問題の 1 つは、バンドラーがトランザクションの失敗をどのように処理するかです。

複数の UserOperation をまとめてパッケージ化した後、バンドラーはまずトランザクションをシミュレートし、契約の実行が失敗するかどうかを検出し、送信者または支払マスターから返されたガス料金が支払われたガス料金より大きいかどうかを計算します。

収益性がある場合、Bundler はこの UserOperations のバッチをトランザクションとしてブロック ノードに送信します。ただし、トランザクションが失敗し、バンドラーがガス料金を支払っても、EntryPoint からガスの払い戻しを受け取れない可能性は依然としてあります。たとえば、ユーザーはアクションを別のバンドラーに送信する場合があります。利益の余地があり、シミュレーションが成功した場合、バンドラーはそれをチェーンにコミットします。この場合、UserOperation が異なるバンドラーによって同時にブロック ノードに送信された場合、成功するトランザクションは 1 つだけです。つまり、EntryPoint によって返されたガス料金を受け取るのは 1 つのバンドラーだけであり、他のすべてのバンドラーは失敗します。チェーンにつながり、ガスを失います。この動作は悪意のある攻撃とみなされるべきであり、Bundler が送信者アドレスを禁止し、そのアドレスからの将来のリクエストを拒否できると主張する人もいるかもしれませんが、ユーザーが意図せずにこの動作を実行する可能性があるため、これは合理的な解決策ではありません。この問題は、開発中のパブリック メモリ プール ネットワークを通じて、コードで適切に対処する必要があります。さらに、取引が成功し、シミュレーション結果で利益の余地があることが示された場合でも、バンドラーは突然のガス変動により損失を被る可能性があります。

もう 1 つの問題は、AA から取得できる最大抽出可能値 (MEV) です。イーサリアムのコンテキストでは、MEV は一般に、マイナーまたは他のトランザクション プロセッサがブロック内のトランザクションの順序を操作するか、ブロックに独自のトランザクションを挿入することによって抽出する値を指します。 MEV のロジックは AA にも適用できることに気づくかもしれません。これは、AA ではバンドラーが UserOps を自由に注文できるため、MEV を取得する可能性が得られるからです。ただし、Bundler が MEV を抽出できるかどうかは、十分な UserOperations をバンドルできるかどうかによって決まります。現在、AA 市場全体がまだ初期段階にあるため、Bundler MEV も初期段階にあると考えられます。 AA の MEV は 2 つの方向に発展する可能性があることがわかります: 1 つは、Flashbots、Ultra Sound、BloXroute などの参加者によるイーサリアム メインネットに似たものであり、もう 1 つは、公正なソーティングを実装するためのバンドラーのコンセンサスを形成することです。後者は、AA で MEV を抽出する可能性を完全に排除します。

＃＃＃ 将来の開発

パブリック メモリプール

AA エコシステムはすでに運用されていますが、やるべき開発作業はまだたくさんあります。 AA エコシステム全体を見ると、現時点で最も欠けている部分はパブリック メンプールです。 Skandha Bundler クライアントの開発者である Etherspot チームは現在、パブリック メモリプールを備えた p2p ネットワークを開発中です。パブリック mempool の p2p ネットワークは、今年 8 月に開始される予定です。

バンドルアルゴリズム

その過程で、イーサリアム財団はいくつかの優れた AA 開発チームに資金を提供してきました。これまでに、いくつかの Bundler クライアントが開発され、現在利用可能です。その中にはとても成熟した人もいます。それらは、Candide (Python で書かれた Voltaire Bundler)、Pimlico (Type で書かれた Alto Bundler)、Etherspot (Type で書かれた Skandha Bundler)、Stackup (Go で書かれた Stackup-Bundler) などです。

ここでパッケージ戦略の問題が生じます。現在、UserOperations の数が少ないため、バンドラーは、各バンドル内の一定の時間間隔や特定の数の UserOperations など、単純なパッケージ化ロジックを採用できます。ただし、UserOperation の数が増加するにつれて、特にパブリック メモリプールの導入後は、UserOperations の選択とパッケージ化の戦略がより複雑になります。理由は単純で、AAエコシステムにはブロックチェーンのコンセンサスプロトコルのような仕組みがなく、バンドラー群が暗い森と化し、各バンドラーが自らの利益に応じてタスクの優先順位を付け、互いに競争しているからです。パブリック mempool とは対照的に、プライベート mempool はより早く出現する可能性があります。パブリック メモリプールから UserOperations をパッケージ化することが利益にならない場合でも、プライベート メモリプールに UserOperations をパッケージ化することが可能であるためです。この場合、バンドラーはパッケージ化する際に他のバンドラーよりも競争力が高くなります。

さらに、パブリック mempool が徐々に普及するにつれて、その中の UserOperations には、さまざまな Gas 利益の期待やオンチェーン実行の複雑さなど、さまざまな特性が備わっています。バンドラーはオフチェーン シミュレーションを実行して、UserOperations のさまざまな組み合わせの収益性を評価し、それぞれのバンドル戦略を確立します。より多くの UserOperations をパックすると、より高い利益が得られる可能性がありますが、検証失敗のリスクも高まります。たとえ検証に合格したとしても、チェーン上で実行が失敗するリスクは依然として存在します。対照的に、パッケージ化が少ない UserOperations はその逆です。

バンドラーは独自のトランザクション ガス パラメーターを設定する必要があります。これは、このトランザクションを実行するブロック プロデューサーの優先順位に影響します。推定ガス価格とガスの変動条件が異なると、バンドラーは異なるパッケージング戦略を採用する可能性があります。同時に、これらの検証やポリシー計算のためのローカルハードウェアコンピューティングリソースやブロックチェーンノードリソースのコストも考慮する必要があります。さらに、バンドラーは、ユーザーに優れたユーザー エクスペリエンスを提供し、ユーザーが UserOperations を送信した後に過度の遅延に直面しないようにする必要もあります。

これらの課題の解決策はまだ明らかではありませんが、AA 業界の発展と開発者の共同の努力によって、最終的にはこれらの問題が解決されると自信を持って言えます。 BlockPI は、インフラストラクチャ構築者として、開発者として、または他の開発者に AA フレンドリーなインフラストラクチャを提供することで、AA 業界の発展において問題解決者の役割を果たしたいと考えています。

*インフラストラクチャは AA に適応する必要があります

AA は、送信者、バンドラー、ガス支払者、契約ウォレット、署名者など、オンチェーン トランザクションに関与するさまざまな役割を抽象化するため、ユーザーはブロックチェーンを使用する際により高い自由度を得ることができます。同時に、インフラストラクチャプロバイダーは、独自の判断に従ってこれらのサービスを市場に独自に展開できます。

AA の大規模な導入に適応するために、インフラストラクチャ プロバイダーはまず少なくとも 2 つの基本サービス、Bundler サービスと Paymaster サービスを提供する必要があります。

Bundler サービスでは、優れたユーザー エクスペリエンスを提供するために、インフラストラクチャ プロバイダーが Bundler と共同でプライベート メモリプールを開発する必要がある場合があります。具体的には、インフラストラクチャ プロバイダーは、バンドラー サービスの安定性を確保するために、さまざまなバンドラー クライアントを統合する必要があります。これらの Bundler クライアントは現在、ERC-4337 コア開発グループが提供するいくつかの標準 JSON RPC メソッドをユーザーに提供しています。将来的には、さらに多くの RPC メソッドがユーザーに利用可能になることが予想されます。インフラストラクチャ サービス プロバイダーは、このプロセス中にこれらのメソッドのサポートをタイムリーに更新する必要があります。

また、バンドラー API とオリジン ノード クライアント RPC の間を最適化することも重要です。現在のノード クライアントは AA 用に最適化されていません。一部の Bundler API メソッドでは、AA に提供されるデータに対するインデックスが必要です。たとえば、現在のクライアントがハッシュによって UserOperation を検索する場合、すべてのブロックの EntryPoint コントラクト ログをスキャンする必要があります。データインデックスがない場合、この 1 つのリクエストによるハードウェア リソースの消費は非常に膨大になり、リクエストの戻り時間も非常に長くなります。

さらに、ユーザーにガスフリーのユーザー エクスペリエンスと多様なサービスを提供するために、インフラストラクチャ プロバイダーはさまざまな Paymaster サービス プロバイダーと協力して、さまざまな Paymaster サービスを統合する必要があります。同時に、市場の需要に応じて、インフラストラクチャプロバイダーは、既存の Paymaster サービスに基づいて、より便利な統合ソリューションを設計することもできます。集約署名、ウォレットファクトリーなどの他のサービスも、将来のインフラストラクチャの開発と統合の潜在的な方向性となります。

つまり、AA の大規模なアプリケーションに適応するために、インフラストラクチャ プロバイダーはサービスを継続的に改善し、拡張する必要があります。これには、Bundler サービスの最適化、さまざまな Paymaster サービス プロバイダーとの連携、さまざまな API インターフェイスの統合、その他の潜在的なサービスの開発が含まれます。 AA 業界が発展し続けるにつれて、これらの取り組みは、より効率的で安全かつ便利なブロックチェーン エクスペリエンスを提供するのに役立ちます。

現在、BlockPI は上記の目標を達成するために懸命に取り組んでいます。それだけでなく、私たちはコミュニティ内のほぼすべての Bundler クライアントおよび Paymaster サービス プロバイダーと通信しており、最優先の開発タスクとして AA を BlockPI ネットワークに統合する予定です。同時に、AAウォレット開発者との綿密なコミュニケーションも行い、ユーザーのニーズを理解しました。私たちは、すべてのバンドラー、ペイマスター、ウォレットが私たちとコミュニケーションを取り、協力してくれることを心から歓迎します。

BlockPI の目標は、コミュニティとともに AA エコシステムを構築および発展させ、AA エコシステムの進歩と繁栄を促進するために可能な限りのことを行うことです。 Web2ユーザーが障壁なくブロックチェーン技術を体験できるよう、コミュニティと協力しながら業界リーダーとしてAA業界全体に貢献し、その後の開発プロセスをサポートしていきたいと考えています。