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、entrypoints、paymaster などのコンポーネントが外部で提供する必要がある呼び出し可能な関数です。これらのガイドラインを導入することで、異なるコンポーネント間の相互作用がより明確になり、モジュール設計のアイデアを口座抽象化とスマートウォレットの設計に統合することが容易になります。ウォレットモジュールに取り組んでいる開発者も大きな恩恵を受けます。しかし、純粋にユーザーの立場から見ると、アカウント抽象化ウォレット自体の変化は短期的には明白ではない可能性があるため、モジュール式スマートウォレット開発パラダイムがもたらす価値はすぐには明らかではないかもしれません。しかし、中長期的に見ると、EIP-4337のようなプロトコルの価値は、ERC-20やERC-721の価値と似ています。これは、アカウント抽象化ウォレットの長期的な開発の基礎を築き、重要なマイルストーンをマークします。それにもかかわらず、EIP-4337 には、次のような多くの未解決の問題がまだ残っています。

1. アカウントの抽象化は統合が十分に簡単ではなく、異なる開発者が無意識に「車輪の再発明」をしてしまうことがあります。

2. アカウントモジュール間の互換性の低さは、断片化されたエコシステムを引き起こしています。

3. 異なるチェーン間のアカウント抽象化エコシステムの高い断片化は、エンドユーザーや開発者に統一された高品質な体験を提供することが難しい状況を生み出しています。

以下、これらの問題の解決策について詳しく説明します。

最適化ソリューション1：アカウント抽象化プラグインが基本構成になります

現在の口座抽象化に関する議論の中心的な焦点の1つは、口座抽象化ウォレットのモジュール化を向上させ、各モジュールの粒度をさらに精緻にすることです。 たとえば、EIP-4337に基づくBiconomy（将来、より細かいEIP-6900が導入されます）は、プラグアンドプレイの口座抽象化を提案し、口座抽象化エコシステムのモジュラー開発をさらに推進します。

(画像の出典：Biconomy)

いわゆるアカウント抽象化プラグインは、実際には、スマートコントラクトウォレットに関与する主要モジュールを明示的に定義するプロトコルを確立することであり、これらのモジュールが実装すべきインターフェース/機能を概説し、これらのインターフェースの名前と呼び出し方法を指定します。その後、サードパーティの開発者は、このプロトコルで設定された要件を満たすように、さまざまな詳細を持つコンポーネントを作成します。

Biconomyのv2は、プロトコルフレームワークとしてEIP-4337をベースに構築され、EIP-4337で言及されていない一連のインターフェースを導入することで、より詳細な標準を策定しました。Biconomyは、バンドラ、スマートコントラクトウォレット、ペイマスター、およびその他のモジュールが持つべき機能を宣言しながら、第三者の開発者が、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は、現在のモジュール式アカウントの抽象化に蔓延している問題、つまりアカウントの「断片化」、つまりアイランド問題に焦点を当てています。例えば、異なるアカウント抽象化モジュールプロバイダーや様々なDAppsはEIP-4337と互換性があるかもしれませんが、異なるモジュール間の抽象化のレベルは不十分であり、粒度は比較的低いです。このシナリオでは、スマート アカウント モジュール開発者(スマート アカウントは、ユーザ情報を保存し、カスタム トランザクション検証を記録し、ガス支払いロジックを処理するコア コンポーネント)が、一意の属性を持つモジュールを作成するための「過度の」自由度が認められます。その結果、時間の経過とともに、さまざまなウォレットプロジェクトが、異なるプロパティを持つスマートアカウントモジュールを設計する傾向があります。この傾向により、他のアカウント抽象化モジュールプロバイダーは、特定のスマートアカウントモジュールプロバイダーとの互換性を優先し、固定された上流と下流のサプライチェーンを徐々に形成することを余儀なくされています。これは必然的に、アカウント抽象化モジュールのエコシステムの断片化と分離につながります(オペレーティングシステム開発者がさまざまなメーカーのハードウェアとの互換性を考慮しなければならなかったコンピュータ業界の初期の頃に似ています)。エコシステムの断片化の問題に対処し、さまざまなプロバイダーによって開発されたアカウント抽象化モジュール間の互換性を高めるには、スマートコントラクトウォレットアカウントをさらに抽象化し、モジュールセグメンテーションの粒度を洗練させるのが最適なアプローチです。EIP-6900 で概説されている原則に従って、セーフ コア プロトコル ホワイトペーパーでは、スマート アカウント (ユーザーのインテリジェント ウォレット アカウント) を詳細に最適化しています。Safe Core Protocolは、各スマートウォレットアカウント内の呼び出し可能なモジュールを、プラグイン、フック、署名バリデーター、関数プロセッサなどのさまざまなカテゴリに分類します。スマートアカウントモジュールは、可能な限り軽量化し、重要なデータと機能のみを保存し、移動可能な機能を「機能プロセッサ」または同様のセグメント化されたモジュールに委任することを目指しています。このアプローチは、オッカムの剃刀の原則である「エンティティを不必要に増やすべきではない」と一致しています。スマートアカウント自体が十分に軽量で、詳細が複雑になりすぎない場合、異なるプロバイダーによって開発されたスマートアカウントは、より緊密な内部構造とより高い互換性を示します。

Safe Coreプロトコルは、iPhone App Storeに似たレジストリを導入し、すべての承認済みモジュールが含まれています。ユーザーはアクティブにするモジュールを選択でき、新しいモジュールをアクティブにするたびに、Mangerを介して処理する必要があります。

一般的に、UserOperationはまずプラグインをトリガーし、その後、マネージャーがプラグインの状態（レジストリに記録されている）をチェックします。正常であれば、プラグインのリクエストが許可されます。必要であれば、プラグインはHookによって提供されるいくつかの機能を呼び出すか、それとも呼び出さないかを選択します。その後、UserOperationに関与するスマートアカウントの状態が変更されます。

上記の細かいモジュール分割メソッドとスケジューリングプロセスにより、Safe Core Protocolはオープンソースのアカウント抽象化モジュール相互運用プロトコルのセットを実装しようとしています。中心的なアイディアは、スマートアカウントを軽量化し、異なるプロバイダーからのスマートアカウントモジュール間の互換性を高めるために、スマートアカウントをEOAアカウントと同様にシンプルにすることです。

最適化ソリューション3：さまざまなチェーン間で統一されたアカウントのためのオムニチェーンアカウント抽象化

しかし、前述の解決策にもかかわらず、まだ解決されていない重大な問題が残っています:異なるチェーンと様々なレイヤー2ソリューションは、異なるアカウント抽象化の実装の詳細を進めており、その多くはzkSync Era、Starknet、Flowなど、EIP-4337と競合しています。これにより、ユーザーのウォレットUXが断片化されます。例えば、Starknetのスマートウォレットアドレスは、Arbitrumのアドレスと統一することはできません。さらに、マルチチェーン環境では、ユーザーは異なるチェーンにスマートアカウントを個別に展開しており、対応するユーザーデータはこれらのコントラクトに分散していることがよくあります。キーなどのユーザーデータを更新する必要がある場合、トランザクションを複数のチェーンで繰り返し開始する必要があり、スマートアカウントの一貫性を確保することが困難になります。ヴィタリックは以前、チェーン全体で統一され、管理が容易なスマートアカウントソリューションを提案しました。このソリューションでは、イーサリアムまたは安全性の高いZK-Rollupをソースチェーンとして使用し、キーストアコントラクトをデプロイしてユーザーのグローバルキーを保存します。次に、レイヤー 2 上のすべてのスマート コントラクト アカウントは、キーストア コントラクトに格納されているグローバル キーを共有します。

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

ただし、このソリューションには大きなコストがかかります。ソースチェーンのキーストアコントラクトに記録されたグローバルキーが変更されるたびに、L2/ターゲットチェーンの各アカウントは、クロスチェーンの相互作用を通じて新しいキーを同期する必要があります。イーサリアムとレイヤー2の間のクロスチェーンインタラクションのオーバーヘッドは、ユーザーが負担するには高すぎます。さらに、スマートコントラクトのアカウントはEOAとは異なることに注意することが重要です。後者は、独自のアドレス生成アプローチにより、複数のEVMチェーン間で本質的に統合されています。しかし、スマートコントラクトのアカウントはまったく異なるため、ユーザーが異なるチェーンで同じアドレスを持つスマートコントラクトのアカウントを取得することは困難です。そこで、パーティクルネットワークは独自の手法を提案しました。その方法の一般的な考え方は、スマートアカウントのストレージとコードを分離することに焦点を当てたVitalikのコンセプトと一致していますが、Particle Networkは、スマートアカウントの完全なストレージデータベースとして、独立したチェーンであるParticle Network Chainを利用する予定です。彼らは、サードパーティのクロスチェーンメッセージングソリューション(LayerZero、CCIP、Axelar、Connextなど)を介して、アカウントのストレージへの変更を他のチェーン上のアカウントのローカルストレージに同期することを計画しています。

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

特に、Particle NetworkのOmnichain Account Abstractionシステムにより、ユーザーは異なるEVMチェーン上で統一されたスマートコントラクトアカウントアドレスを持つことができます。これには、一連のデプロイヤーコントラクトを異なるチェーンにデプロイする必要があります。ユーザーはParticle Network Chainで新しいアカウントの生成をトリガーする必要があり、その後、Particle ChainはすべてのチェーンでDeployer Contractをトリガーして、異なるチェーン上のユーザー用に生成されたスマートコントラクトアカウントアドレスが一貫していることを確認します。あるいは、ユーザーは他のチェーンを意識することなく、パーティクルチェーン上のコントラクトを通じてマルチチェーンの相互作用を行うことができ、取引手数料の普遍的な支払い方法としてUnified Gas Tokenを利用することができます。

Omnichain Account Abstractionは、ユーザー操作を介してターゲットチェーンでトランザクションを開始し、ソースチェーンで対応するガスを支払うことにより、クロスチェーンユーザー操作も可能にします。たとえば、これにより、ユーザーはPolygonの$USDCを使用してBaseでNFTを購入することができます。

Particle Networkのソリューションは、Deployer Contractとクロスチェーンメッセージングコンポーネントの間での高度な連携が必要とされることに注意してください。これにより、マルチチェーンアカウントとソースチェーンストレージの同期が達成されます。これは、オムニチェーン相互運用性に関連するすべてのソリューションで共通の問題であると思われる、オラクルまたはクロスチェーンメッセージブリッジに高い要件を課すことになります。ただし、ユーザーのクロスチェーンアカウントの同期は、単一のブリッジに依存するのではなく、異なるメッセージブリッジの組み合わせを柔軟に構成できます。たとえば、LayerZero、Axelar、Connextのいずれか2つの確認に依存する2/3戦略として構成でき、ターゲットチェーンのストレージ変更の確認に使用できます。これは、単一の依存関係の問題への潜在的な解決策となり得ます。

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

EVMチェーン全体で主要な管理アカウントと統合アカウントがあるにもかかわらず、オムニチェーンアカウントの抽象化にはまだ最適化の余地があります。Aptos、Solana、SuiなどのEVM非互換チェーンは、スマートコントラクトのアカウントアドレスがEVMチェーンのアドレスと一致していることを保証できません。さらに、非EVMチェーンは、ERC-4337プロトコルを同等のソリューションで実装しない場合、前の議論で提案されたクロスチェーンアカウント抽象化の概念を採用することが困難になります。さらに、EIP-4337と互換性のあるウォレットプロジェクトには改善の余地があります。ほとんどのスマートウォレットで使用されているBundlerノードは、公式には独立して実行されており、時には互いに分離して実行されており、さまざまなリスク(検閲耐性や可用性に関連するリスクなど)を生み出しています。大多数のチェーンにまたがる統一されたフロントエンドインターフェイスを構築することは、非常に困難であることが証明されています。考えられる解決策の1つは、インテント中心の設計を導入し、オムニチェーンアカウントの抽象化の上にレイヤーを追加することです。このレイヤーには、イーサリアムのEIP-4337エコシステムまたは他のチェーンのネイティブアカウント抽象化機能(zkSyncなど)がソルバー/リアクタータイプの特定のインスタンスとして組み込まれており、適切なソルバーを選択するタスクは上位レベルの責任です。パーティクル ネットワークを例にとると、簡潔で抽象化されたインテント中心の実装を提案します。異なる勘定科目抽象化プロジェクトは、インテントスキーム内のソルバーカテゴリに含まれるインスタンスにすぎません。まず、ユーザーフロントエンドは、自然言語の要求やユーザーインタラクションを、入力と出力の制約を含む特定のプログラム記述に変換します(言い換えれば、これらは、ユーザーの要件を満たす入力と出力結果が特定の範囲内に収まることを許容する条件です)。その後、ソルバーネットワーク内では、特定のソルバーが、正確な入力と出力の制約を含むトランザクションを、チェーン上にデプロイされたソルバーコントラクトに転送します(ソルバーには、ノードインフラストラクチャだけでなく、オンチェーンコントラクトコンポーネントも含まれます)。ソルバーコントラクトは、IntentディレクティブをReactorコントラクトに送信し(ユーザーアカウントをオンチェーンで管理)、Reactorコントラクトが他のモジュールを呼び出して最終的なインタラクションを実行するように委任します。このフレームワークにより、ユーザーのリクエストをソルバーネットワークで最初に処理できるため、ユーザーが基礎となるチェーンや異なるアカウント抽象化スキーム(特定のソリューションを構築するためにソルバーに委任されたタスク)を理解する必要性が軽減されます。ただし、これらの概念化はまだ理論上のフレームワークであり、実装の詳細は Particle Network によるさらなる精緻化が待たれます。将来的には競争の激しいソルバー市場が出現し、複数のソルバーが個別のソリューションを提案する入札を開始できるようになることは明らかです。ローカルでシミュレートされたトランザクションを通じて、最適なソリューションを選択し、対応するインセンティブをソルバーに提供できます。インセンティブ構造は、ソルバーネットワークのプロトコル設計者によって形成されます(Particle Networkは、ソルバーオークション市場のインセンティブトークンとしてPNTトークンを使用することを目指しています)。現在、意図の本質は、下位層の複雑な詳細を隠蔽し、上位層を抽象化しています。TCP/IPプロトコルに似たこの階層型設計は、チェーン間でシームレスな相互運用性を実現し、ユーザーエクスペリエンスと開発者エクスペリエンスの両方を向上させるために不可欠です。

アカウント抽象化の大規模な採用を受け入れる

EIP-4337フレームワークをさまざまな側面から最適化し、Ethereumエコシステム全体でシームレスな相互運用性を推進することに成功した後、口座抽象化の大規模採用をサポートするには、供給側と需要側をまたぐ製品が依然として必要であると考えています。この製品は、さまざまなWeb3製品サービスを利用するエンドユーザーの複雑さを軽減し、開発者の参入障壁を下げることに焦点を当てるべきです。この役割を果たす最適な製品の1つは、Particle NetworkのModular Smart Wallet-as-a-Service Stackです。

（Particle Networkのスマートウォレット・アズ・ア・サービス・アーキテクチャ）

• サービスはユーザーフレンドリーなAPIを提供し、開発者がモジュラーアカウント抽象化機能をシームレスにアプリケーションに統合できるようにしています。
• 開発者はこのサービスを使用して、オムニチェーンアカウントを作成および管理し、クロスチェーンの相互作用を行い、統一された手数料支払い方法を使用することができます。
• このようなサービスは、開発者により柔軟で便利な方法を提供し、マルチチェーンアプリケーションを構築し、口座の抽象化の普及を促進します。

上記の開発者向け機能に加えて、Particle NetworkのModular Smart Wallet-as-a-Serviceスタックの最も重要な側面は、署名計算に基づき開発者向けに向けられたアカウント抽象化ドメインのオープンエコシステムを構築したことです。Particle Networkは、社内のアカウント抽象化製品モジュールとともに、さまざまな種類のアカウント抽象化製品とサービスを統合しています。この統合により、開発者向けのアカウント抽象化ドメイン全体での製品およびサービスの採用が加速されます。

（Particle Networkのスマートウォレットサービスのモジュラーデザイン）技術がユーザーのニーズに対応します。ERC-4337フレームワークの制限を解決した後、開発者の体験の向上により、優れたユーザーエクスペリエンスを持つ製品がさらに登場し、Web3のクリプトパンクにとっての友好的な金融業界から、大衆向けの消費者フレンドリーな業界への移行が加速します。

免責事項：

1. この記事は[から転載されました极客 Web3]. すべての著作権は元の著者に帰属します [Particle Network＆Faustの共同創設者であるPeter Pan、CTO].この転載に異議がある場合は、ゲートラーンチームが迅速に対応します。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。