執筆者: Peter Pan、Particle Network & Faust の共同創設者兼 CTO、Geek Web3

2022年からアカウント抽象化が広く議論されるようになり、EIP-4337を中核としたアカウント抽象化分野のフレームワークが業界の一般的なコンセンサスになってきたと思われます。意図という概念の人気により、人々はそのような敷居の低いユーザー インタラクション コンポーネントにさらに注目するようになりました。

ただし、EIP-4337 には、スマート アカウント アカウントの断片化と、クロスチェーン アカウントの抽象化による高度に断片化されたユーザー エクスペリエンスという問題点が依然として存在します。この記事では、Biconomy、Safe Core、Particle Network などのプロジェクトを例として、EIP-4337 フレームワークの下でアカウント抽象化フィールドの開発をさらに促進する方法について説明します。

トランザクションプロセスの抽象化の観点から「アカウントの抽象化」の概念を理解する

アカウントの抽象化については、Vitalik 氏がイーサリアムのユーザーの敷居を下げ、大量導入を達成するための必要条件であると何度も指摘していますが、その中心的なビジョンは、ユーザーが署名検証方法をカスタマイズしてガス支払いを楽しめるようにすることであり、資産を持たないチェーンでトランザクションを開始します (一般にガスフリートランザクションとして知られています)。これらの前提条件を実現することによってのみ、Web3 アプリケーションの新規ユーザー変換率を向上させることができます。

以前の非アカウント抽象提案やスマート コントラクト ウォレットでも同様のエクスペリエンスを実現できますが、柔軟性や効率性が十分とは程遠いです。

アカウントの抽象化は、スマート コントラクトのアカウント構造の最下層から最適化されて、次世代のインテリジェント アカウント システムへの道を開くことを目的としています。

しかし、実際のアカウント抽象化提案を見てみると、その焦点がアカウント モデル自体にあるわけではないことがわかります。例えば、EIP-86、EIP-4337、EIP-6900などのアカウント抽象化関連の提案は、トランザクションの開始からノード受信、署名検証、ガス支払いなどの処理プロセス全体の抽象化/モジュール化に焦点を当てています。ただし、アカウント構造の抽象化にはあまり焦点を当てません。したがって、現在のさまざまな提案を「トランザクション抽象化」と呼ぶ方が適切であるように思われます。

これらのよく知られたアカウント抽象化の提案を「トランザクション処理プロセスの抽象化」という観点から理解すると、要点をより簡単に理解できます。この種のトランザクション抽象化は、実際には Web2 レベルのユーザーが製品に入って使用できるようにするためのものです。ブラックリスト/ホワイトリストなどのイーサリアムシステムへの導入、一定期間内の取引開始に本人確認不要、ガス取引なし、法定通貨支払い手数料など。

（画像出典：ゼンゴ）

しかし、これらのことは過去にスマート コントラクト ウォレットに実装できなかったのかと疑問に思う人もいるかもしれません。 EIP-4337 このタイプのアカウント抽象化ソリューションの価値は何ですか?

EIP-4337 の本質: イーサリアム エコシステムにおけるアカウント抽象化の局所最適ソリューション

上記の質問で述べたように、過去のスマートウォレットは上記の機能を実現できますが、その実装方法は一般的に大雑把であり、高度に集中化されたサードパーティの機能に依存することがよくあります。たとえば、過去のガス支払いソリューションでは、サードパーティのリレー ノード (EIP-2771) の導入が必要でした。さらに、さまざまなスマートウォレット間で統一された標準が欠如しており、サポートコンポーネントの開発やレイアウトに役立ちません。

上記の質問で述べたように、過去のスマートウォレットは上記の機能を実現できますが、その実装方法は一般的に大雑把であり、高度に集中化されたサードパーティの機能に依存することがよくあります。たとえば、過去のガス支払いソリューションでは、サードパーティのリレー ノード (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. 異なるチェーン間のアカウント抽象化のエコロジーは高度に断片化されており、より良い UX を達成するための統一された高品質のエクスペリエンスをエンドユーザーと開発者に提供することが困難になっています。

以下では、これらの問題の解決策を検討していきます。

最適化の方向性1：アカウント抽象化機能プラグインが基本構成となる

アカウント抽象化に関する中心的な議論のポイントの 1 つは、アカウント抽象化ウォレットのモジュール化をより適切に実装し、各モジュールの粒度をより細かく分割する方法であると言えます。

たとえば、Biconomy は、アカウント抽象化エコシステムのモジュール開発をさらに促進するために、EIP-4337 に基づいたアカウント抽象化機能のプラグイン ナラティブを提案しました (よりきめの細かい EIP-6900 が将来導入される予定です)。

たとえば、Biconomy は、アカウント抽象化エコシステムのモジュール開発をさらに促進するために、EIP-4337 に基づいたアカウント抽象化機能のプラグイン ナラティブを提案しました (よりきめの細かい EIP-6900 が将来導入される予定です)。

(画像出典: Biconomy)

いわゆるアカウント抽象化機能のプラグインは、実際には一連のプロトコルを使用して、どの主要なモジュールがスマート コントラクト ウォレットに関与しているか、これらのモジュールが実装する必要があるインターフェイス/機能、および名前は何かを外部の世界に明確にします。これらのインターフェイスのメソッドを呼び出します。その後、サードパーティの開発者が独自のアイデアに従ってさまざまな詳細を備えたコンポーネントを開発しますが、これらのコンポーネントはすべて、契約に定められた要件に準拠します。

Biconomy の V2 バージョンは、プロトコルの骨格として EIP-4337 を使用し、より詳細な標準を策定し、4337 で言及されていない多数のインターフェイスを追加します。 Biconomy は、Bundler、Smart Contract Wallet、Paymaster などのモジュールがどのような機能を持つべきかを宣言する一方で、Biconomy の事前宣言に従っている限り、サードパーティ開発者が異なるコード詳細を使用して同じ機能と異なるバージョンのモジュールを実装することを許可します。契約の詳細 (EIP-4337 と互換性があります)。

(Biconomy によって提案されたインターフェイス標準は、サードパーティのモジュール開発者が外部呼び出しのためにモジュール内にどの関数を実装する必要があるかを指定します)

同時に、Biconomy は「モジュール ストア」というスローガンも提案し、アカウント抽象化モジュール SDK を積極的に立ち上げると同時に、開発者が独自に設計したアカウント抽象化モジュールを提出し、「サービスとしてのモジュール」を立ち上げることを奨励しています。 EIP-4337 プロトコルを使用すると、すべてのウォレット プロジェクトで、外部者が作成したこれらのアカウント抽象化モジュールを直接使用できます。ユーザーがフロントエンド ページを通じてスマート アカウントを作成する場合、使用するモジュールについてより多様な選択肢も得られます。

モジュール性は分業を容易にするだけでなく、ユーザーがスマートウォレット内の特定の機能を素早く切り替えたり、追加または削除したりすることも容易にします（端的に言えば、粒度を細かく分割することを意味します）。

Biconomy は、スマート コントラクト ウォレットのモジュール性が高くなるほど、更新またはアップグレード時に必要な変更が少なくなると指摘しました (ユーザーの既存のスマート コントラクト ウォレット コントラクトを更新したり、DelegateCall を使用したりする必要はなく、特定の外部モジュールのみを更新する必要があります)。さまざまなユーザーや開発者にとって、特定のコンポーネントを置き換えると便利です。

Biconomy の将来の新しいバージョンのアカウント抽象化スキームでは、EIP-4337 よりもモジュール化された EIP-6900 提案も参照される予定です。

最適化の方向 2: アカウントの断片化の問題を解決するための、よりきめの細かいモジュールのセグメンテーション

EIP-6900 の提案に関しては、実際に Safe (旧 Gnosis Safe) が今年 8 月に関連する Safe Core Protocol ホワイト ペーパーを発表しており、最も参照されているのは EIP-6900 です。

(EIP-6900の回路図)

EIP-6900 は、モジュール型アカウント抽象化に関する現在の問題の 1 つは、アカウントの「断片化」、つまりアイランド問題であると指摘しました。たとえば、さまざまなアカウント抽象化モジュールのサプライヤーやさまざまな DAPP アプリケーションが EIP-4337 と互換性がありますが、EIP-4337 ではさまざまなモジュールが十分に抽象化されておらず、分割の粒度が比較的粗いため、スマート アカウント モジュールの開発者は「」という問題を抱えています。過度の自由度 (スマート アカウントは、ユーザー情報の保存、カスタマイズされたトランザクション検証の記録、ガス支払いロジックの中核部分です)。

その結果、さまざまなウォレット プロジェクトが独自のプロパティを持つスマート アカウント モジュールを設計する傾向があります。このままでは、他のアカウント抽象化モジュールのサプライヤーは他社が提供するスマートアカウントモジュールとの互換性を優先せざるを得なくなり、徐々に上流と下流の固定的なサプライチェーンが形成され、分断化が避けられない。アカウント抽象化モジュールのエコロジー。 (これは、コンピューター業界の初期の頃と同じように、オペレーティング システム開発者は、まずどのコンピューター ハードウェア メーカーが互換性のある機器を提供するかを検討する必要がありました)

生態学的断片化の問題を解決し、さまざまなサプライヤーによって開発されたアカウント抽象化モジュールの互換性を向上させるための最良の方法は、スマート コントラクト ウォレット アカウントをさらに抽象化し、モジュールのセグメント化の粒度をより細かくすることです。

Safe Core プロトコルのホワイト ペーパーでは、EIP-6900 のアイデアを参考にして、スマート アカウント (ユーザーのスマート ウォレット アカウント) をより詳細に最適化しています。 Safe Core プロトコルは、各スマート ウォレット アカウントで呼び出すことができるモジュールを、プラグイン、フック、署名検証器、関数プロセッサなどのさまざまなカテゴリに分割します。

スマートアカウントモジュールは可能な限り軽量であり、アカウントコントラクトには最も基本的なデータと機能のみが格納されており、外部に移動できる機能はすべて「ファンクションプロセッサ」や「プラグイン」などの細分化されたモジュールによって実装されています。これは、「必要な場合以外はエンティティを追加しない」という、いわゆるオッカムのかみそりの原則に沿っています。

スマート アカウント自体が十分に軽量で、複雑な詳細が含まれていない場合、異なるメーカーが開発したスマート アカウントは内部構造が近くなり、互換性が高くなります。

Safe Core プロトコルでは、iPhone App Store と同様に、承認された利用可能なすべてのモジュールを含むレジストリも導入されています。ユーザーはどのモジュールをアクティブ化するかを選択でき、新しいモジュールがアクティブ化されるたびに、Manger コントラクトを通じて処理する必要があります。

Safe Core プロトコルでは、iPhone App Store と同様に、承認された利用可能なすべてのモジュールを含むレジストリも導入されています。ユーザーはどのモジュールをアクティブ化するかを選択でき、新しいモジュールがアクティブ化されるたびに、Manger コントラクトを通じて処理する必要があります。

通常の状況では、UserOperation が最初にプラグインをトリガーし、次に Manger コントラクトがプラグインのステータスが正常かどうか (レジストリにレコードがあるかどうか) をチェックします。正常であれば、プラグインのリクエストはリリースされます。必要に応じて、Plugin プラグインはフックによって提供されるいくつかの関数を呼び出したり、呼び出したりしません。その後、UserOperation に関与するスマート アカウントのステータスが変更されます。

セーフ コア プロトコルは、前述のきめ細かいモジュール セグメンテーション メソッドとスケジューリング プロセスを通じて、一連のオープン ソース アカウント抽象化モジュールの相互運用性プロトコルの実装を試みます。中心的なアイデアは、スマート アカウントを軽量かつ EOA アカウントと同じくらいシンプルにして、容易に利用できるようにすることです。改善: さまざまなメーカーのスマート アカウント モジュールの互換性が向上しました。

最適化の方向 3: 異なるチェーン上で統一されたアカウントを実現するためのフルチェーン アカウントの抽象化

しかし、前述のソリューションがあっても、まだ解決されていない大きな問題が残っています。さまざまなチェーンやさまざまな Layer2 が、さまざまな詳細を持つアカウント抽象化実装ソリューションを推進しており、その多くは zkSync など、EIP-4337 と競合する形式を採用しています。エラ、スタークネット、フローなどこれにより、ユーザーのウォレット UX に断片化が生じ、たとえば Starknet 上のユーザーのスマート ウォレット アドレスと Arbitrum 上のスマート ウォレット アドレスがまったく統一できなくなりました。

さらに、マルチチェーン環境では、ユーザーは異なるチェーンにスマート アカウントを個別に展開しており、対応するユーザー データは多くの場合、これらのコントラクトに分散して保存されています。キーなどのユーザー データを更新する必要がある場合、複数のチェーンでトランザクションを繰り返し開始する必要があるため、スマート アカウントの一貫性を確保することが困難になります。

Vitalik 氏自身は以前、チェーン全体に統合され管理が容易なスマート アカウント ソリューションを提案しました。このソリューションでは、ソース チェーンとしてイーサリアムまたは安全性の高い ZKRollup を使用し、キーストア コントラクトをデプロイし、ユーザーのグローバル キーを保存し、次にユーザーL2 上のすべてのスマート コントラクト アカウントは、キーストア コントラクトに保存されているグローバル キーを共有します。

（画像出典：https://vitalik.ca/general/2023/06/20/deeperdive.html）

ただし、このソリューションは非常にコストがかかります。つまり、ソース チェーン上のキーストア コントラクトによって記録されたグローバル キーが変更されるたびに、L2/ターゲット チェーン上の各アカウントがクロスチェーン インタラクションを通じて新しいキーを同期する必要があります。イーサリアムと L2 間のクロスチェーン相互作用のコストは高すぎるため、ユーザーにはそれを支払う余裕がありません。また、スマートコントラクトアカウントはEOAアカウントとは異なり、後者は独自のアドレス生成方法により本質的にマルチチェーン統合（EVMチェーン間で統合）されていますが、スマートコントラクトアカウントは全く異なるものであり、ユーザーにとっては困難です。異なるチェーン上で同じアドレスを持つスマート コントラクト アカウントを取得します。

この点に関して、Particle Network は独自のアプローチを提案しています。一般的なアイデアは、スマート アカウントのストレージとコードを分離するという Vitalik のアイデアと一致していますが、パーティクル ネットワークは、サードパーティを通じて、独立したチェーンであるパー​​ティクル ネットワーク チェーンをスマート アカウントのフルチェーン ストレージ データベースとして使用することを計画しています。クロスチェーン メッセージング ソリューション (LayerZero、CCIP、Axelar、Connext など) アカウント ストレージに対するユーザーの変更を他のチェーンのローカル アカウントに同期します。

(Particle Network のマルチチェーンアカウントの抽象構造)

具体的には、Particle Network のフルチェーン アカウント抽象化システムにより、ユーザーは異なる EVM チェーン上で統一されたスマート コントラクト アカウント アドレスを持つことができます。これには、異なるチェーン上に Deployer Contract のセットをデプロイする必要があります。

ユーザーはパーティクル ネットワーク チェーン上で新しいアカウントの生成をトリガーする必要があります。その後、パーティクル チェーンはすべてのチェーン上でデプロイヤー コントラクトをトリガーして、異なるチェーン上のユーザーに対して生成されたスマート コントラクト アカウント アドレスが確実に統合されるようにします。認識の場合、パーティクルチェーン上の契約を通じてマルチチェーンインタラクションプロセスが完了し、Unified Gas Token を統一された料金支払い方法として使用できます。

フルチェーンのアカウント抽象化により、クロスチェーンのユーザー操作も可能になります。ソースチェーンのユーザー操作と、それに対応する支払い用のガスを通じて、ターゲットチェーンのトランザクションをトリガーできます。たとえば、Polygon の USDC を使用して購入することができます。 Base上のNFT。

ただし、Particle Network のソリューションでは、マルチチェーン アカウントとソース チェーン ストレージの同期を実現するために、デプロイヤ コントラクトとクロスチェーン メッセージング コンポーネントとの間の高度な連携が必要であり、実際には、使用されるオラクルまたはクロスチェーン メッセージ ブリッジに対してより高い要件が課せられます。 (この問題は、フルチェーンの相互運用性に関連するすべてのソリューションに存在すると思われます)。

ただし、ユーザーのクロスチェーン アカウント同期は、特定のブリッジに依存するのではなく、メッセージ ブリッジのさまざまな組み合わせを柔軟に構成できます。たとえば、LayerZero の任意の 2 つの確認に依存する 2/3 戦略として構成できます。 、Axelar、および Connext がターゲット チェーン上に存在するようにするストレージの変更を確認すると、この単一点の依存関係の問題はほぼ解決できます。

EVM と非 EVM にわたるシームレスなフルチェーンの相互運用性は、イーサリアム エコシステム内のフルチェーン アカウントの抽象化に向けたさらなるステップです。

EVM チェーン全体にキー管理と統合アカウントがありますが、フルチェーンのアカウント抽象化にはまだ最適化の余地があります。Aptos、Solana、Sui など、EVM と互換性のないチェーンでは、ユーザー生成のスマート コントラクト アカウント アドレスは、チェーン上の EVM の一貫性と一致していますが、同時に、非 EVM チェーンが同等のソリューションで EIP-4337 プロトコルを実装していない場合、完全なコンセプトに従うことは困難になります。 -前の記事で Vitalik と Particle Network によって提案されたチェーン アカウントの抽象化。

また、EIP-4337対応ウォレットプロジェクト自体にも改善の余地があります。ほとんどのスマート ウォレットで使用される Bundler ノードは、公式には独立して実行されており、相互に通信することさえありませんが、多くのスマート ウォレット プロジェクトは実際には独自のチェーンを形成しており、多くのリスク (検閲耐性、可用性) をもたらします。ほとんどのチェーンにわたって統一された単一のフロントエンド インターフェイスを構築するのは非常に困難です。 1 つの解決策は、インテント中心の設計を導入し、フルチェーンのアカウント抽象化の上にレイヤーを追加し、イーサリアムの EIP-4337 エコシステムまたは他のチェーンのネイティブ アカウント抽象化機能 (zkSync など) を Reactor タイプのソルバー/特定のインスタンスとして扱うことです。 、適切なソルバーを選択する方法はより高度なタスクです。

パーティクル ネットワークを例に挙げると、一連の簡潔で抽象的なインテント中心の実装ソリューションが提案されており、さまざまなアカウント抽象化プロジェクトは、インテント ソリューションのソルバー カテゴリに含まれるインスタンスの一種にすぎません。

まず、ユーザー フロントエンドは、自然言語リクエストまたは任意のユーザー インタラクションを、入力制約と出力制約 (端的に言うと、ユーザーの要件を満たす入力条件と出力結果の範囲) を含む特定のプログラムによる記述に変換する責任を負います。 ) の場合、ソルバー ネットワーク内の 1 つまたは複数のソルバーは、特定の入出力制約を含むトランザクションをチェーン上にデプロイされたソルバー コントラクトに転送します (ソルバーにはノード機能だけでなく、チェーン上のコントラクト部分もあります)。 Solver コントラクトは Intent 命令を Reactor コントラクト (チェーン上のユーザーのアカウントを管理する) に送信し、後者は他のモジュールを呼び出して最終的な対話を完了します。

ユーザーのリクエストは最初にソルバー ネットワークによって認識されるため、ユーザーは基礎となるチェーンやさまざまなアカウント抽象化ソリューションの構築についてあまり知る必要はありません。この部分はソルバーに任せて特定のソリューションを構築することができます。

もちろん、これらのアイデアは現時点では理論的な枠組みにすぎず、その後の実装の詳細はまだ Particle Network によって正式に定められていません。

現時点で比較的明らかなことは、競争力のあるソルバー市場が将来的に確実に出現し、ユーザーがオークションを開始して複数のソルバーに異なるソリューションを提案させることができるということです。ローカルでシミュレートされたトランザクションを通じて最適なソリューションを選択できます。そして、ユーザーにインセンティブを提供することができます。対応するソルバー。インセンティブの形式に関しては、ソルバー ネットワークのプロトコル設計者の考慮事項によって異なります (パーティクル ネットワークは、ソルバー オークション市場のインセンティブ トークンとして PNT トークンを使用する予定です)。

現在のインテントは基本的に、下位層の複雑な詳細を保護し、上位層を抽象化します。TCP/IP プロトコルの性質を備えたこのような階層化された設計は、チェーン全体にわたるシームレスな相互運用性の下でのユーザー エクスペリエンスと開発に不可欠です。経験は必要です。」状態。

アカウント抽象化の大量導入に備える

イーサリアム エコシステムの 4337 フレームワークをあらゆる角度から最適化した後、イーサリアムおよび非イーサリアム エコシステム全体にわたるシームレスな相互運用性も促進しました。アカ​​ウント抽象化の大規模な導入をサポートするには、まだ製品が必要であると感じています。それは供給側と需要側にまたがります。エンド ユーザーがさまざまな Web3 製品やサービスを使用する必要性を軽減しながら、開発者へのサービスに重点を置き、開発者の敷居を低くすることもできます。

この役割を果たすのに最適な製品の 1 つは、Particle Network のモジュラー アカウント抽象化ウォレット アズ サービス (Modular Smart Wallet-as-Service) 製品です。

(Particle Network の Smart Wallet-as-a-Service アーキテクチャ)

上記の開発者向けの機能に加えて、最も重要な機能は Particle Network の Modular Smart Wallet-as-as-Service 製品であり、署名の計算に基づいて開発者向けのアカウント抽象化フィールドを構築します。自社開発のアカウント抽象化製品モジュールは、さまざまなタイプのアカウント抽象化製品とサービスを統合し、アカウント抽象化分野全体で開発者による製品とサービスの採用を迅速に促進できます。

(Particle Network の Smart Wallet-as-a-Service のモジュール設計)

テクノロジーでニーズに応えましょう。ERC-4337 フレームワークの制限をあらゆる角度から解決した後、開発者のエクスペリエンスが向上することで、優れたユーザー エクスペリエンスを備えたより多くの製品の生産が促進され、サイファーパンクに優しい金融業界から Web3 業界の変革が加速されます。一般向け フレンドリーな消費者グレードの業界。