EIP-4337 の最後のピース：全チェーンアカウント抽象
著者： ピーター・パン、Particle Networkの共同創設者兼CTO \& ファウスト、ギークWeb3
2022年から現在にかけて、アカウント抽象は広く議論されているトピックであり、EIP-4337を中心としたアカウント抽象の枠組みは業界の一般的な合意となっているようです。そして、意図の概念の熱気は、人々がこのような低いハードルのユーザーインタラクションコンポーネントに対する重視を強化することを促しました。しかし、EIP-4337には依然としてスマートアカウントのアカウントの断片化や、クロスチェーン間のアカウント抽象ユーザー体験の高度な断絶という痛点があります。この記事では、Biconomy、Safe Core、Particle Networkなどのプロジェクトを例に挙げ、EIP-4337の枠組みの下でアカウント抽象の分野をさらに推進する方法を探ります。
取引プロセスの抽象の観点から「アカウント抽象」概念を理解する
アカウント抽象について、ビタリックは何度も指摘していますが、それはイーサリアムユーザーのハードルを下げ、マスアダプションを実現するための必要条件であり、その核心的なビジョンはユーザーがカスタマイズされた署名方法を持ち、ガス代の支払いを享受し、資産なしでチェーン上で取引を開始できる（いわゆる無ガス取引）ことです。これらの前提が実現されることで、Web3アプリケーションの新規ユーザーの転換率を向上させることができます。従来の非アカウント抽象提案やスマートコントラクトウォレットは、類似の体験を実現できますが、まだ十分に柔軟で効率的ではありません。例えば、Gnosis SafeはEOAアドレスを使用して取引をトリガーする必要があり、ガスコストが非常に高いです。アカウント抽象は、スマートコントラクトアカウントの構造の底層から最適化を目指し、次世代のスマートアカウントシステムへの道を開くことを意図しています。しかし、実際のアカウント抽象提案を見ると、彼らの焦点はアカウントモデル自体にはありません。例えば、EIP-86、EIP-4337、EIP-6900などのアカウント抽象関連提案は、取引が発起され、ノードに受信され、署名され、ガスが支払われるまでの一連の処理プロセスの抽象/モジュール化に焦点を当てており、実際にはアカウント構造の抽象には真正に関心を持っていません。したがって、現在のさまざまな提案を「取引抽象」と呼ぶ方がより適切のようです。「取引処理プロセスの抽象」の観点から、広く知られているアカウント抽象提案を理解することで、その要点をより簡単に理解できます：この取引抽象は、実際にはWeb2レベルのユーザーが製品にアクセスし使用する体験をイーサリアムシステムに持ち込むことを目指しています。 例えば、ブラックリスト/ホワイトリスト、一定期間内の取引に対する身分証明不要、無ガス取引、法定通貨での手数料支払いなど。
（画像出典：Zengo）しかし、誰かが尋ねるかもしれません：これらの機能は過去のスマートコントラクトウォレットで実現できたのではないか？EIP-4337のようなアカウント抽象の価値はどこにあるのでしょうか？
EIP-4337の本質：アカウント抽象がイーサリアムエコシステムに落ちる局所的最適解
上記の問題に関して、過去のスマートウォレットは上記の機能を実現できましたが、実現手法は一般的に粗雑であり、しばしば高度に中央集権的な第三者施設に依存しています。 例えば、過去のガス代支払いの提案は、第三者のリレーノード（EIP-2771）を導入する必要がありました。また、異なるスマートウォレット間には統一された基準が欠如しており、関連コンポーネントの開発と展開に不利です。さまざまなアカウント抽象関連EIPの核心的な要求は、スマートコントラクトウォレット専用に設計された標準化されたフレームワークを通じて、異なるウォレットプロジェクトに存在するこれらの欠陥を解決し、イーサリアムエコシステム内のアカウント構造を基本的な機能構造からより高い上限のスマート構造に変換することです。
（画像出典：Springer Link）これは、ERC-20やERC-721が登場する前に、多くのトークンの実装方法、機能、外部に提供される関数/インターフェースが一致していなかったことに似ています。「不一致」は、関連する第三者施設の開発やコード監査に不利です（ERC-20プロトコルがなければ、DeFiアプリケーションが現在の繁栄に発展することは想像できません）。標準化されたプロトコル/機能実装基準は、モジュール化の物語の前提条件であり、モジュール化開発方式はほぼすべての分野が繁栄するための前提条件です（分業は効率を向上させる第一原則です）。最終的に、EIP-4337が際立ちました。
EIP-4337は局所的最適解だが、その枠組み内には最適化が急務な複数の視点がある
EIP-4337は一整セットのインターフェース標準を定義し、4337プロトコルに従うスマートウォレットが少なくともどのモジュールを持つべきか、各モジュールがどの関数/インターフェースを実装すべきかを明確にしました。 例えば、Bundler、EntryPoint、Paymasterなどのコンポーネントは、外部に提供すべき呼び出し可能な関数を持つべきです。これらの枠組みを明確にした後、異なるコンポーネント間の相互関係がより明確になり、モジュール化の設計思考をアカウント抽象とスマートウォレットの設計に導入しやすくなり、ウォレットモジュールの開発者も大いに恩恵を受けます。もちろん、単純にユーザーの観点から見ると、モジュール化されたスマートウォレット開発のパラダイムがもたらす価値はまだ明確ではありません。なぜなら、短期的にはアカウント抽象ウォレット自体に大きな変化を感じることができないからです。しかし、中長期的には、EIP-4337などのプロトコルの価値はERC-20やERC-721に似ており、アカウント抽象ウォレットの長期的な発展の基盤を築くものであり、画期的な意義を持つマイルストーンです。しかし、EIP-4337にはまだ多くの問題が解決されていません：** 例えば、1. アカウント抽象の機能がまだプラグイン化されておらず、異なる開発者が簡単に同じものを作り出すことができる；2. アカウントモジュールの互換性が低く、全体のアカウントシステムがエコシステムの断片化の傾向を示している；3. 異なるチェーン間のアカウント抽象エコシステムが高度に断絶しており、エンドユーザーや開発者に統一かつ高品質な体験を提供するのが難しい。以下では、これらの問題の解決策を探ります。
最適化方向1：アカウント抽象の機能プラグイン化が基本構成となる
現在、アカウント抽象に関連する核心的な議論の一つは、アカウント抽象ウォレットのモジュール化をどのようにより良く実現するか、各モジュールの区分をより細かくすることです。 例えば、BiconomyはEIP-4337に基づき（将来的にはより細かい粒度のEIP-6900を導入予定）、アカウント抽象機能のプラグイン化の物語を提案し、アカウント抽象エコシステムのモジュール化の発展をさらに推進しています。
（画像出典：Biconomy）アカウント抽象機能のプラグイン化とは、実際には一つのプロトコルを通じて、スマートコントラクトウォレットに関わる重要なモジュールが何であるか、これらのモジュールがどのインターフェース/関数を実装すべきか、これらのインターフェースの名称と呼び出し方法がどうであるかを明確にすることです。その後、第三者の開発者は自分の考えに基づいて、さまざまな詳細を持つコンポーネントを開発しますが、これらのコンポーネントはすべてプロトコルで提案された要件に従います。BiconomyのV2バージョンはEIP-4337をプロトコルの骨格として、より詳細な基準を定め、4337に記載されていないインターフェースを追加しました。Bundler、スマートコントラクトウォレット、Paymasterなどのモジュールがどの機能を持つべきかを明示しながら、Biconomyは第三者の開発者が異なるコードの詳細を用いて、同じ特徴を持つ異なるバージョンのモジュールを実現することを許可しています（EIP-4337に互換性があります）。
（Biconomyが提案したインターフェース標準、第三者モジュール開発者がモジュール内で外部から呼び出すために実装すべき関数を指示）同時に、Biconomyは「モジュールストア」というスローガンを提唱し、アカウント抽象モジュールSDKを実際に提供しながら、多くの開発者が自分の設計したアカウント抽象モジュールを提出することを奨励し、「モジュールをサービスとして」展開しています。 これにより、EIP-4337プロトコルに従うすべてのウォレットプロジェクトが、外部の人々が作成したアカウント抽象モジュールを直接採用できるようになります。ユーザーはフロントエンドページを通じてスマートアカウントを作成する際、どのモジュールを採用するかについてより多様な選択肢を持つことができます。
モジュール化は分業を容易にするだけでなく、ユーザーがスマートウォレット内の特定の機能を迅速に切り替えたり、追加したり、削除したりすることも便利にします（要するに、粒度をより細かく分けることです）。Biconomyは、スマートコントラクトウォレットのモジュール化の程度が高いほど、更新やアップグレードに必要な変更が少なくなると指摘しています（既存のスマートコントラクトウォレット契約を更新する必要はなく、特定の外部モジュールを更新するだけで済みます）。Biconomyの将来の新しいアカウント抽象提案では、EIP-4337よりもモジュール化に適したEIP-6900提案を参考にする予定です。
最適化方向2：より細かいモジュールの切り分け、アカウントの断片化問題を解決する
EIP-6900提案について、Safe（旧Gnosis Safe）は実際に今年の8月にそれに関連するSafe Core Protocolのホワイトペーパーを発表しましたが、その中で最も多く参照されているのがEIP-6900です。
（EIP-6900の原理図） EIP-6900は、現在のモジュール化アカウント抽象の一つの問題がアカウントの「断片化」、あるいは孤島問題であると指摘しています。 例えば、異なるアカウント抽象モジュールの供給者や異なるDAPPアプリケーションはEIP-4337に互換性があるかもしれませんが、EIP-4337は異なるモジュールの抽象度が十分に高くなく、区分の粒度が粗いため、スマートアカウントモジュールの開発者に「過度の」自由度を残しています（スマートアカウントはユーザー情報を保存し、カスタマイズされた取引検証やガス支払いロジックを記録する最も核心的な部分です）。こうなると、異なるウォレットプロジェクトは独自の特性を持つスマートアカウントモジュールを設計する傾向があります。長期的には、他のアカウント抽象モジュール供給者は、誰が提供するスマートアカウントモジュールとの互換性を優先的に考慮しなければならず、徐々に固定された上下流の供給チェーンが生まれ、アカウント抽象モジュールエコシステムの断片化と相互断絶を必然的に引き起こします。 （これは、コンピュータ業界の初期において、オペレーティングシステムの開発者がどのハードウェアメーカーのデバイスとの互換性を考慮する必要があったのと似ています）。エコシステムの断片化問題を解決し、異なる供給者が開発したアカウント抽象モジュールの互換性を向上させるための最良の方法は、スマートコントラクトウォレットアカウントをさらに抽象化し、モジュールの切り分け粒度をより細かくすることです。EIP-6900の考え方を参考にしたSafe Coreプロトコルのホワイトペーパーは、スマートアカウント（ユーザーのスマートウォレットアカウント）に対してより詳細な最適化を行いました。Safe Coreプロトコルは、各スマートウォレットアカウントが呼び出すことができるモジュールをプラグイン、フック、署名検証器、関数処理器などのさまざまなカテゴリに分割しました。 スマートアカウントモジュールはできるだけ軽量化され、アカウント契約は最も基本的なデータと関数のみを保存し、外部に移動できる関数はすべて「関数処理器」や「プラグイン」といった細分化されたモジュールに実装させます。これは、オッカムの剃刀原則に応じています------「必要がなければ、実体を増やすな」。 スマートアカウント自体が十分に軽量化され、複雑な詳細を含まない場合、異なるメーカーが開発したスマートアカウントは内部構造がより近くなり、互換性も高くなります。
Safe Coreプロトコルには、iPhoneのアプリストアに似たレジストリが導入され、すべての承認された利用可能なモジュールが含まれています。ユーザーはどのモジュールをアクティブにするかを選択でき、毎回新しいモジュールをアクティブにする際には、Manger契約を介して処理されます。
一般的に、UserOperationは最初に特定のプラグインをトリガーし、その後Manger契約がそのプラグインの状態が正常かどうかを確認します（レジストリに記録があります）。正常であれば、そのプラグインのリクエストが許可されます。必要に応じて、プラグインは特定のフックが提供する機能を呼び出すか、呼び出さないかを決定します。その後、UserOperationに関連するスマートアカウントの状態が変更されます。
上記の細粒度のモジュール切り分け方式と調整プロセスを通じて、Safe Core Protocolはオープンソースのアカウント抽象モジュール相互運用プロトコルを推進しようとしています。その核心的な考え方は、スマートアカウントを軽量化し、EOAアカウントのようにできるだけシンプルにすることで、異なるメーカーが開発したスマートアカウントモジュールの互換性を向上させることです。
最適化方向3：全チェーンアカウント抽象、異なるチェーン上で統一アカウントを実現する
しかし、前述の解決策があっても、現在まだ解決されていない大きな問題があります：異なるチェーンや異なるLayer2がそれぞれ異なるアカウント抽象実現策を推進しており、多くはEIP-4337と矛盾する形式を採用しています。例えば、zkSync Era、Starknet、Flowなどです。これにより、ユーザーはウォレットUXにおいて断絶を感じます。例えば、ユーザーがStarknet上のスマートウォレットアドレスとArbitrum上のスマートウォレットアドレスを統一することができません。また、多チェーン環境では、ユーザーが異なるチェーン上に独立して展開されたスマートアカウントを持ち、それに対応するユーザーデータはしばしばこれらの契約に分散して保存されます。ユーザーデータ（鍵など）を更新する必要がある場合、複数のチェーンで取引を繰り返し発起する必要があり、スマートアカウントの一貫性を保証するのが難しいです。ビタリック自身は以前、全チェーンで統一され、管理が容易なスマートアカウントの提案を行いました。この提案は、イーサリアムまたは非常に高い安全性を持つZKRollupをソースチェーンとして、Keystore契約を展開し、ユーザーのグローバルキーを保存します。 その後、ユーザーはL2上のすべてのスマートコントラクトアカウントがKeystore契約に保存されたグローバルキーを共有します。
（画像出典：https://vitalik.ca/general/2023/06/20/deeperdive.html）しかし、この提案はコストが非常に高く、ソースチェーン上のKeystore契約に記録されたグローバルキーが変更されるたびに、L2/ターゲットチェーン上の各アカウントはクロスチェーンインタラクションを通じて新しいキーを同期する必要があります。イーサリアムからL2へのクロスチェーンインタラクションのコストは非常に高く、ユーザーは全く負担できません。また、注意すべきは、スマートコントラクトアカウントはEOAアカウントとは異なり、後者はその独特のアドレス生成方式により、自然にマルチチェーン統一を実現しています（EVMチェーン間で統一されています）。しかし、スマートコントラクトアカウントは全く異なり、** ユーザーが異なるチェーン上で同じアドレスのスマートコントラクトアカウントを得るのは非常に難しいです。これに対して、Particle Networkは独自の方法を提案しました。大まかな考え方はビタリックのアイデアと一致しており、スマートアカウントのストレージとコードを分離しますが、Particle Networkは独立したチェーン---Particle Network Chainをスマートアカウントの全チェーンストレージデータベースとして使用することを計画しています。 そして、第三者のクロスチェーンメッセージングソリューション（LayerZero、CCIP、Axelar、Connextなど）を通じて、特定のユーザーのアカウントストレージの変更を他のチェーン上のアカウントに同期します。
(Particle Networkのマルチチェーンアカウント抽象構造）具体的には、Particle Networkの全チェーンアカウント抽象システムは、ユーザーが異なるEVMチェーン上で統一されたスマートコントラクトアカウントアドレスを持つことを可能にします。 これは、異なるチェーン上に一セットのDeployer Contractを展開する必要があります。ユーザーはParticle Network Chain上で新しいアカウントの生成をトリガーし、その後Particle Chainがすべてのチェーン上のDeployer Contractをトリガーし、異なるチェーン上でユーザーに生成されたスマートコントラクトアカウントアドレスが統一されることを保証します。また、ユーザーは他のチェーンに気づかないまま、Particle Chain上の契約を通じてマルチチェーンインタラクションプロセスを完了し、Unified Gas Tokenを統一された手数料支払い方法として使用することができます。全チェーンアカウント抽象は、クロスチェーンのユーザー操作を可能にし、ソースチェーンのユーザー操作と対応するガスを支払うことで、ターゲットチェーンのトランザクションをトリガーします。例えば、PolygonのUSDCを使用してBase上のNFTを購入することができます。しかし、Particle Networkの提案は、Deployer Contractとクロスチェーンメッセージングコンポーネントが高度に協調して、マルチチェーンアカウントとソースチェーンストレージの同期を実現する必要があり、これは実際には彼らが採用するオラクルやクロスチェーンメッセージブリッジに高い要求を課します（この問題は、全チェーン相互運用に関連するすべての提案に存在するようです）。ただし、ユーザーのクロスチェーンアカウントの同期は、異なるメッセージブリッジの組み合わせを柔軟に構成でき、特定のブリッジに依存するのではなく、例えば2/3の戦略に設定し、LayerZero、Axelar、Connextのいずれか2つの確認を依存してターゲットチェーン上でストレージの変更を確認することができます。このようにして、単一のポイント依存の問題を近似的に解決できます。EVMと非EVMの全チェーンシームレス相互運用は、イーサリアムエコシステム内の全チェーンアカウント抽象のさらなる進展です。 EVMチェーン間の鍵管理と統一アカウントがあっても、全チェーンアカウント抽象には依然として最適化の余地があります：非EVMチェーン（例えばAptosやSolana、Suiなど）では、ユーザーが生成したスマートコントラクトアカウントアドレスがEVMチェーン上のものと一致することを保証できません。また、非EVMチェーンがEIP-4337プロトコルを実現するための同等の提案を採用していない場合、前述のビタリックやParticle Networkが提案した全チェーンアカウント抽象の構想を引き継ぐことは難しいです。さらに、EIP-4337に互換性のあるウォレットプロジェクト自体にも進歩の余地があります。ほとんどのスマートウォレットが使用するBundlerノードは、公式に独立して運営されており、互いに通信すらしていません。多くのスマートウォレットプロジェクトは実際に独自のチェーンを形成しており、これにより多くのリスク（検閲耐性、可用性）が生じます。ほとんどのチェーンを横断する単一のフロントエンドインターフェースを構築することは非常に困難ですが、一つの解決策は意図中心のデザインを導入し、全チェーンアカウント抽象の上に一層を追加することです。イーサリアムのEIP-4337エコシステムや他のチェーンのネイティブアカウント抽象施設（例えばzkSync）をすべてSolver/Reactorタイプの具体的なインスタンスとして扱い、適切なSolverを選択することがより上位のタスクとなります。 例えば、Particle Networkはシンプルな抽象化されたIntent-Centric実現策を提案しており、異なるアカウント抽象プロジェクトは単にIntentソリューションの中でSolverの範疇に含まれる一つのインスタンスです。まず、ユーザーフロントエンドは自然言語のリクエストや任意のユーザーインタラクションを具体的なプログラム化された記述に変換し、入力制約と出力制約を含みます（要するに、ユーザーの要求を満たす入力条件と出力結果の範囲を示すことです）。その後、Solverネットワーク内の特定のSolverが、具体的な入力出力制約を含むトランザクションを、チェーン上に展開されたSolver契約に転送します（Solverはノード施設だけでなく、チェーン上の契約部分も含まれます）。Solver契約はIntent指令をReactor契約（ユーザーのチェーン上のアカウントを管理）に送信し、後者が他のモジュールを呼び出して最終的なインタラクションを完了します。ユーザーのリクエストは最初にSolverネットワークによって認識され、ユーザーは底層のチェーンや異なるアカウント抽象ソリューションの構造を過度に意識する必要がなく、この部分はSolverに具体的な解決策を構築させることができます。もちろん、これらの構想は現在は理論的な枠組みに過ぎず、実装の詳細はParticle Networkの公式な展開を待つ必要があります。現在比較的明確なのは、将来的には競争の激しいSolver市場が生まれることが確実であり、 ユーザーは競売を発起し、複数のSolverが異なる解決策を提示し、ローカルシミュレーション取引の形式を通じて最適な解決策を選定し、対応するSolverにインセンティブを与えることができます。インセンティブの形式は、Solverネットワークのプロトコル設計者の考慮によります（Particle NetworkはPNTトークンをSolverオークション市場のインセンティブトークンとして使用する予定です）。現在のIntentは、下層の複雑な詳細を隠蔽し、より高いレイヤーを抽象化しています。 このようなTCP/IPプロトコルの性質を持つ階層型設計は、全チェーンシームレス相互運用におけるユーザー体験と開発者体験の両方にとって必要条件です。 アカウント抽象の大規模な採用を迎えるイーサリアムエコシステム内の4337フレームワークをさまざまな角度から最適化した後、同時にイーサリアムと非イーサリアムエコシステムを横断する全チェーンシームレス相互運用を推進し、アカウント抽象の大規模な採用を支援するためには、供給側と需要側を横断する製品が依然として必要です。エンドユーザーがさまざまなWeb3製品サービスを使用する際のハードルを下げることができ、サービス開発者に焦点を当て、開発者のハードルを下げることが求められます。 この役割を果たす最適な製品の一つが、Particle Networkのモジュール化されたアカウント抽象ウォレット即サービス（Modular Smart Wallet-as-a-Service）製品です：
- このサービスは、開発者がアプリケーションにモジュール化されたアカウント抽象機能を簡単に統合できるようにする使いやすいAPIを提供します；
- 開発者はこのサービスを使用して全チェーンアカウントを作成および管理し、クロスチェーンインタラクションを行い、統一された手数料支払い方法を使用できます；
- このようなサービスは、開発者にとってより柔軟で便利な方法を提供し、マルチチェーンアプリケーションの構築を促進し、アカウント抽象の広範な採用を促進します。
以上の開発者に優しい特性に加えて、最も重要な特徴は、Particle Networkのモジュール化アカウント抽象ウォレット即サービス（Modular Smart Wallet-as-a-Service）製品が、署名計算に基づく開発者向けのアカウント抽象分野のオープンエコシステムを構築していることです。自社開発のアカウント抽象製品モジュールを提供するだけでなく、さまざまなアカウント抽象製品とサービスを統合し、全体のアカウント抽象分野における各開発者の製品とサービスの採用度を迅速に推進することができます。
（Particle NetworkのSmart Wallet-as-a-Serviceのモジュール設計）技術を需要に役立て、ERC-4337フレームワークのさまざまな角度の制限を解決した後、開発者体験の向上が、より優れたユーザー体験を持つ製品の創出を促し、Web3業界が暗号パンクに優しい金融業界から大衆に優しい消費者向け業界へと変革することを加速させるでしょう。
