インフラストラクチャは、アカウント抽象を通じて数十億のユーザーをどのようにサポートするか

著者: BlockPI Network

牛市でも熊市でも、イーサリアムエコシステムは常に構築と自己最適化を続けています。その中で、アカウント抽象（Account Abstraction、AA）は近年重要な進展を遂げ、アプリケーション、インフラストラクチャ、ユーザー、開発者など、イーサリアムエコシステムのさまざまな部分に浸透しています。AAの大規模な採用は、全体としてブロックチェーンの利用の敷居を下げ、web2のユーザー体験をweb3業界に持ち込むことが期待されます。

数十億ドルの潜在的価値を持つAA市場の機会を捉えるために、BlockPIはAAをそのインフラサービスに統合する計画です。AA分野での統合的な革新を通じて、BlockPIはAAユーザーにとってより便利で効率的なブロックチェーン契約ウォレットアカウントのインタラクション方法を提供し、この業界のリーダーになることを目指しています。

この記事では、BlockPIチームがAAに対する理解を深く探求し、インフラサービスプロバイダーの視点から考えを共有します。

EOAと契約ウォレット

牛市でも熊市でも、イーサリアムエコシステムは常に構築と自己最適化を続けています。その中で、アカウント抽象（Account Abstraction、AA）は近年重要な進展を遂げ、アプリケーション、インフラストラクチャ、ユーザー、開発者など、イーサリアムエコシステムのさまざまな部分に浸透しています。AAの大規模な採用は、全体としてブロックチェーンの利用の敷居を下げ、web2のユーザー体験をweb3業界に持ち込むことが期待されます。

数十億ドルの潜在的価値を持つAA市場の機会を捉えるために、BlockPIはAAをそのインフラサービスに統合する計画です。AA分野での統合的な革新を通じて、BlockPIはAAユーザーにとってより便利で効率的なブロックチェーン契約ウォレットアカウントのインタラクション方法を提供し、この業界のリーダーになることを目指しています。

この記事では、BlockPIチームがAAに対する理解を深く探求し、インフラサービスプロバイダーの視点から考えを共有します。

1. EIP-86

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

2. EIP-2938

2020年に提案されました。このEIPのタイトルはアカウント抽象（Account Abstraction）です。AAの概念はこのEIPでよく説明されています。新しい取引、すなわちAA取引を導入し、取引はエントリーポイントアドレス（`EntryPoint` address）から開始され、AA契約ウォレットを呼び出します。EIP-2938は統一された仕様を提供し、正式にAAアカウント抽象をイーサリアムコンセンサスに導入しました。具体的には、イーサリアムコンセンサスに2つの新しいオペコード、3つのグローバル変数、および異なるペイロード構造を導入しました。

3. EIP-3074

2020年に提案されました。このEIPは2つのEVM命令、AUTHとAUTHCALLを導入します。`AUTH`はECDSA署名に基づいて環境変数を設定します。`AUTHCALL`は認可されたアカウントから呼び出しを送信します。これにより、スマートコントラクトはEOAを代表して取引を送信できます。しかし、AAにとっては依然として完璧な解決策ではありません。認可取引の過程で、EIP-3074はネイティブ価値の移転に関して一定の制限があります。また、ユーザーがEOAへのアクセス権を失った場合、資産を取り戻すことはできません。もし秘密鍵が漏洩した場合、ユーザーはすべての資産を新しいアカウントに移転する必要があります。

コンセンサス層での変更が必要であるか、提案が十分でないため、上記の提案は正式にイーサリアムプロトコルに組み込まれていません。そのため、イーサリアムコミュニティは、コンセンサスを変更することなくAAをイーサリアムプロトコルに導入する方法を引き続き探求し、最終的にEIP4337を提案しました。

4. 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標準となり、構築者はこの標準を利用して自分のスマートコントラクトウォレットを実現できます。また、この標準は「Bundlers」と「UserOperationメモリプール」を含むいくつかの追加インフラを導入しました。これにより、実際にはブロックチェーンシステムの上層で、同様の機能を持つイーサリアムメモリプールを複製しました。ユーザーが提出するのは単一の取引ではなく、`UserOperation`です。複数の`UserOperations`は1つの取引にパッケージ化され、イーサリアムに送信されます。

ERC-4337の重要な役割とその定義

UserOperation: ユーザーを代表して送信される取引の構造を説明します。混乱を避けるために、「取引」とは名付けられず、Bundlerに送信され、他のUserOperationsと一緒にBundleとしてパッケージ化されます。次に、Bundleは単独の取引としてチェーンに送信されます。

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

EntryPoint: UserOperationsのバンドルを実行するグローバルシングルトン契約。Bundlers/ClientsはサポートされているEntryPointをホワイトリストに登録します。この契約はInfinitismチームによって監査され、展開が承認され、すべてのUserOperationsを処理し、Wallet Factory、Aggregator、Paymasterなどの他の役割の契約と接続します。この契約はEVM互換チェーン上で同じアドレスです。

Bundler: メモリプールから複数のUserOperationsをパッケージ化し、EntryPoint.handleOps()取引を作成するノード（現在のブロック生成ノード）。Bundlerサービスはブロックチェーンノードから独立して実行でき、RPCを介してパッケージ化されたUserOperationsを送信します。

Aggregator: アカウントが信頼する補助契約で、署名の集約を検証します。Bundlers/Clientsはサポートされている署名集約器をホワイトリストに登録します。AggregatorはERC-4337標準に従ってIAggregatorインターフェースを構成する必要があります。

Paymaster: Gasを代わりに支払うことができるスマート契約です。EntryPoint契約に十分なETHを預け入れた場合、送信者のUserOperationのGas費用を支払うことができ、実質的にGasの抽象化を実現します。PaymasterはERC-4337標準に従ってPaymasterインターフェースを構成する必要があります。PaymasterはSenderと合意に達することができます。たとえば、SenderがPaymasterにUSDCを支払い、PaymasterがETHを使用して送信したUserOperationsのGasを支払います。実際、PaymasterはERC-20トークンや他のチェーン上のトークンを含む任意のトークンをサポートすることを選択できます。

Wallet Factory: ERC-4337ユーザーのために契約ウォレットを作成できるスマート契約です。Wallet Factoryの展開は許可なしに行えます。オンチェーンのスマート契約として、そのコードは公開されており、誰でもレビューできます。広く使用されるWallet Factoryは、専門家による包括的な監査を受けるべきです。

下の図は、EntryPoint契約が他の役割とどのように相互作用するかを説明しています。

BundlersはEntryPoint契約のhandleOps関数を呼び出し、この関数はUserOperationを入力として受け取ります。

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

検証が通過した場合、handleOpsはUserOperationのcalldataに定義された関数と入力パラメータに基づいてスマート契約ウォレット関数を実行します。

一方、BundlerがEOAを使用してhandleOps関数をトリガーすると、Gas費用が発生します。スマート契約ウォレットは自分のアカウント残高からBundlersにGas費用を支払うことができるか、Paymaster契約に代わりに支払うよう要求できます。UserOperationsは十分なGasがない場合、オフチェーンの検証ステップを通過できず、チェーン上での取引実行前に失敗します。十分なGasがあっても、UserOperationsは実行中にランタイムエラーなどの理由で失敗する可能性があります。1つのUserOperationに対して、契約の実行が成功したかどうかに関わらず、EntryPoint契約はhandleOps関数をトリガーしたBundlerにGas費用を支払います。

ERC-4337が有効になった後、ユーザーはブロックチェーン取引を開始するために2つの方法を使用できます。1つは従来の方法で、EOAが直接取引を開始します。もう1つはERC-4337標準を使用し、Bundlerを介してUserOperationを開始し、その後Bundlerが他のUserOperationsとパッケージ化してチェーンに送信します。以下のフローチャートは、通常のEOAが取引を送信する方法とERC-4337契約ウォレットがUserOperationを送信する方法の違いを説明しています。

道は整備されているが、多くの行人はいない

ERC-4337は、ユーザーと開発者がイーサリアムでAAを使用し構築できる強力なフレームワークを提供します。このフレームワークは重要な進展ですが、依然として対処し解決すべきいくつかの課題と不確実性があります。

AAの採用はまだ初期段階にあります。DuneのERC-4337分析パネルによると、チェーン上で実行されたUserOperationsは65k以上で、その90%はPolygonからのものです。したがって、現在実行されているUserOperationの数は非常に少なく、その大部分は開発者のテストであり、実際のユーザーからのものはごくわずかです。AAが統合された製品はまだ初期段階にあります。現在、Bundlers全体が依然として損失状態にあることが観察されています。現在の損失は約700以上のMATICです。これは、Polygon上の一部のBundlerが必要なGasを誤って見積もったために、EntryPointが返すGasが提出されたBundleが消費するGasよりも少なくなったことが原因です。この問題はBundlerクライアントレベルで解決する必要があります。

さらに、解決すべきいくつかの問題があります。その1つは、Bundlersが取引の失敗をどのように処理するかです。

複数のUserOperationsをまとめてパッケージ化した後、Bundlersはまず取引をシミュレートし、契約の実行が失敗するかどうかを検出し、SenderまたはPaymasterが返すGas費用が支払ったGas費用を上回るかどうかを計算します。

利益が見込まれる場合、BundlerはこのバッチのUserOperationsを1つの取引としてブロック生成ノードに提出します。しかし、取引は依然として失敗する可能性があり、BundlerがGas費用を支払うがEntryPointからGasを返されない場合があります。たとえば、ユーザーが異なるBundlersに操作を送信する可能性があります。利益が見込まれ、シミュレーションが成功した場合、Bundlersはそれをチェーンに提出します。この場合、1つのUserOperationが異なるBundlersによって同時にブロック生成ノードに提出されると、成功する取引は1つだけであり、つまり1つのBundlerだけがEntryPointからGas費用を受け取り、他のすべてのBundlerはチェーン上での失敗によりGasを失うことになります。このような行動は悪意のある攻撃と見なされるべきだと考える人もいるかもしれませんが、BundlerがそのSenderアドレスを禁止し、そのアドレスからの将来のリクエストを拒否することは合理的な解決策ではありません。なぜなら、ユーザーが意図せずそのような行動を取る可能性があるからです。この問題はコード内で適切に解決する必要があり、開発中の公共メモリプールを通じて実現できるかもしれません。さらに、取引が成功裏に提出され、シミュレーション結果が利益の見込みを示していても、Bundlersは突然のGasの変動によって損失を被る可能性があります。

もう1つの問題は、AAから得られる最大抽出可能価値（MEV）です。イーサリアムの文脈において、MEVは通常、マイナーや他の取引処理者がブロック内の取引の順序を操作したり、ブロック内に自分の取引を挿入することによって抽出する価値を指します。MEVの論理はAAにも適用できることに注意する人もいるかもしれません。なぜなら、AAではBundlersがUserOpsを自由に並べ替えることができ、これがMEVを得る可能性を提供するからです。しかし、BundlerがMEVを抽出できるかどうかは、十分な数のUserOperationsをまとめてパッケージ化できるかどうかに依存します。現在、AA市場全体はまだ初期段階にあるため、Bundler MEVも初期段階と見なすことができます。AAのMEVは2つの方向に進展する可能性があります。1つは、イーサリアムメインネットのように、Flashbots、Ultra Sound、BloXrouteなどの参加者が関与する方向です。もう1つは、Bundlerの合意を形成して公正な順序を実施する方向です。後者はAAにおけるMEVの抽出の可能性を完全に排除します。

今後の発展

公共メモリプール

AAエコシステムはすでに稼働していますが、まだ多くの開発作業が残っています。AAエコシステム全体で現在最大の欠落部分は公共メモリプールです。Etherspotチーム、Skandha Bundlerクライアントの開発者は、現在公共メモリプールのp2pネットワークを開発中です。公共メモリプールのp2pネットワークは、今年の8月にリリースされる予定です。

バンドルアルゴリズム

この過程で、イーサリアム財団は数つの優れたAA開発チームに資金を提供しました。これまでに、現在使用可能な複数のBundlerクライアントが開発されました。その中には、非常に成熟したものもあります。具体的には、Candide（Pythonで書かれたVoltaire Bundler）、Pimlico（Typescriptで書かれたAlto Bundler）、Etherspot（Typescriptで書かれたSkandha Bundler）、Stackup（Goで書かれたStackup-Bundler）などです。

ここで、パッケージ化戦略の問題が関わってきます。現在、UserOperationsの数が少ないため、Bundlersは固定の時間間隔や各Bundle内の一定数のUserOperationsなど、シンプルなパッケージ化ロジックを採用できます。しかし、UserOperationsの数が増加するにつれて、特に公共メモリプールが導入された後は、UserOperationsの選択とパッケージ化の戦略がより複雑になります。その理由は簡単です。AAエコシステムにはブロックチェーンのコンセンサスプロトコルのようなメカニズムが欠けており、Bundlerの集団は暗い森となり、各Bundlerは自分の利益に基づいてタスクを優先的に処理し、競争しています。公共メモリプールに対して、プライベートメモリプールは早期に出現する可能性があります。なぜなら、公共メモリプールからUserOperationsをパッケージ化しても利益が出ない場合、プライベートメモリプール内のUserOperationsをパッケージ化することには依然として利益の可能性があるからです。この場合、そのBundlerは他のBundlersよりもパッケージ化時に競争力を持つことになります。

さらに、公共メモリプールが徐々に普及するにつれて、その中のUserOperationsには異なるGasの利益期待やチェーン上の実行の複雑性など、さまざまな特性があります。Bundlersはオフチェーンでシミュレーションを行い、さまざまなUserOperationsの組み合わせの利益性を評価し、それぞれのパッケージ化戦略を確立します。より多くのUserOperationsをパッケージ化することで、より高い利益を得る可能性がありますが、同時に検証失敗のリスクも増加します。検証が通過しても、チェーン上での実行失敗のリスクは依然として存在します。逆に、少ないUserOperationsをパッケージ化する場合はその逆です。Bundlersは自分の取引Gasパラメータを設定する必要があり、これがブロック生成ノードがこの取引を実行する優先度に影響を与えます。異なるGas価格の見積もりやGasの変動率の条件下で、Bundlersは異なるパッケージ化戦略を持つ可能性があります。また、これらの検証や戦略計算には、ローカルハードウェアの計算リソースやブロックチェーンノードリソースのコストがかかることも考慮する必要があります。さらに、Bundlersはユーザーに良好なユーザー体験を提供するために努力し、ユーザーがUserOperationを提出した後に長時間の遅延に直面しないようにする必要があります。

これらの課題の解決策はまだ明確ではありませんが、AA業界の発展と開発者の共同努力が最終的にこれらの問題を解決することを自信を持って言えます。

インフラはAAに適応する必要がある

AAは、チェーン上の取引行動に関与するさまざまな役割を抽象化し、Sender、Bundlers、Gas支払者、契約ウォレット、Signersを含むことで、ユーザーがブロックチェーンを使用する際により高い自由度を持つことを可能にします。同時に、インフラストラクチャプロバイダーは、市場に対する自らの判断に基づいて、これらのサービスを独立して展開できます。

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

Bundlerサービスにおいて、インフラストラクチャプロバイダーはBundlersと協力してプライベートメモリプールを開発し、良好なユーザー体験を提供する必要があります。具体的には、インフラストラクチャプロバイダーは、Bundlerサービスの安定性を確保するために、さまざまなBundlerクライアントを統合する必要があります。これらのBundlerクライアントは現在、ユーザーにいくつかの標準のJSON RPCメソッドを提供しており、これらはERC-4337コア開発グループによって提供されています。将来的には、ユーザーが使用できるRPCメソッドがさらに増えることが予想されます。インフラストラクチャサービスプロバイダーは、このプロセスでこれらのメソッドのサポートをタイムリーに更新する必要があります。

さらに、Bundler APIと原始ノードクライアントRPCの間での最適化も非常に重要です。現在のノードクライアントはAAに対して最適化されていません。一部のBundler APIメソッドは、ノードがAAに関するデータインデックスを提供する必要があります。たとえば、現在のクライアントは、ハッシュを介してUserOperationを検索する際に、すべてのブロック内のEntryPoint契約のログをスキャンする必要があります。データインデックスが欠けている場合、この単一のリクエストのハードウェアリソース消費は非常に大きくなり、リクエストの返答時間も長くなります。

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