要約すると

2022年以来、アカウントの抽象化は広く議論されており、EIP-4337を中心としたフレームワークが業界の一般的な合意になったようです。抽象化コンセプトの人気により、低いしきい値のユーザーインタラクションコンポーネントに対する関心が高まっています。

ただし、EIP-4337は、スマートアカウントの断片化やチェーン間で高度に断片化されたユーザーエクスペリエンスなどの課題に直面しています。この記事では、Biconomy、Safe Core、Particle Networkなどのプロジェクトを例に挙げ、EIP-4337フレームワーク内でアカウントの抽象化領域のさらなる発展をどのように推進するかを探っています。

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

アカウントの抽象化に関して、Vitalikは何度も指摘しています。これは、イーサリアムのユーザーの敷居を下げ、大衆採用を実現するための必要条件であると述べています。その中核的なビジョンは、ユーザーに署名検証方法をカスタマイズしてガス支払いを楽しむこと、そして資産なしでチェーン上でトランザクションを開始することを可能にすることです（一般的にガスフリートランザクションとして知られています）。これらの前提条件を達成することで、新しいユーザーのWeb3アプリケーションへの変換率を向上させることができます。

以前のアカウントの抽象化の提案やスマートコントラクトウォレットは、同様の体験を得ることができますが、まだ柔軟性や効率が不十分です。例えば、Gnosis SafeはまだトランザクションをトリガーするためにEOAアドレスが必要で、ガスコストが非常に高いです。

アカウントの抽象化は、スマートコントラクトアカウントの基本的な構造から最適化することを意図しており、次世代のインテリジェントアカウントシステムの道を開くことを目指しています。

ただし、実際の口座抽象化提案を見てみると、その焦点は口座モデルそのものではないことがわかります。たとえば、EIP-86、EIP-4337、EIP-6900などの口座抽象化関連の提案は、取引の開始からノードによって受信されるまでの処理フロー全体を抽象化/モジュール化し、署名の検証、ガスの支払いなどに焦点を当てており、実際に口座構造を抽象化することに真に焦点を当てているわけではありません。したがって、これらのさまざまな提案を「取引抽象化」と呼ぶ方が適切であるように思われます。

よく知られたアカウントの抽象化提案を「トランザクション処理フローの抽象化」という観点から理解すると、Web2レベルのユーザーが製品に入力し使用する経験をEthereumシステムにもたらすことを目的としています。たとえば、ブラックリスト/ホワイトリスト、本人確認なしで期間中に開始された取引、ガス無料取引、手数料の法定通貨支払いなど、そのような取引の抽象化は、それらの要点をより簡単に理解することができます。

疑問を持つ人もいるかもしれません: これらの機能は従来のスマートコントラクトウォレットで達成できませんでしたか？EIP-4337のようなアカウントの抽象化スキームの価値は何ですか？

EIP-4337の本質：イーサリアムエコシステムにおけるローカル最適解としてのアカウントの抽象化

質問が示唆するように、過去のスマートウォレットは確かに述べられた機能を達成することができましたが、その実装方法はしばしば粗末であり、高度に中央集権的な第三者施設に頻繁に依存していました。たとえば、以前のガス支払いスキームでは、第三者のリレーノードの導入が必要でした（EIP-2771）。さらに、異なるスマートウォレットの実装間で統一された標準が欠如していたため、補完的なコンポーネントの開発と展開が妨げられました。

アカウントの抽象化に関連するさまざまなEIPの中心的な目的は、異なるウォレットプロジェクトに存在するこれらの欠点に対処するために、スマートコントラクトウォレット向けに特別に設計された標準化されたフレームワークを導入することです。このフレームワークの目標は、イーサリアムエコシステム内のアカウント構造を基本的な機能的構造からより洗練されたインテリジェント構造に移行し、全体的なエコシステムの効率と拡張性を向上させることです。

これは、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：プラグアンドプレイ機能アカウントの抽象化のモジュール化が基本構成になります

現在のアカウントの抽象化に関する中心的な議論の一つは、アカウントの抽象化ウォレットのモジュール化をよりよく実現し、各モジュールの区分をより洗練されたものにする方法について言える。

たとえば、Biconomyは、EIP-4337に基づいており（将来的にはより細かい粒度のEIP-6900を導入する予定です）、アカウントの抽象化のプラグアンドプレイ機能のモジュール化の物語を提案し、アカウントの抽象化エコシステムのモジュール化開発をさらに促進します。

いわゆるプラグアンドプレイ機能のモジュール化されたアカウントの抽象化は、スマートコントラクトウォレットに関与する主要モジュールを明示的に概説し、これらのモジュールが実装すべきインターフェース/機能、およびこれらのインターフェースの名称と呼び出し方を明確にしたプロトコルを通じて基本的に実現されます。その後、第三者の開発者は、独自のアイデアに基づいてさまざまな詳細を持つコンポーネントを開発しますが、これらのコンポーネントはすべて、プロトコルで概説された要件に準拠します。

BiconomyのV2バージョンは、プロトコルフレームワークとしてEIP-4337に基づいており、より詳細な標準を確立し、4337で言及されていない一連のインターフェイスを追加しました。Bundler、スマートコントラクトウォレット、ペイマスターなどのモジュールが持つべき機能を指定しながら、Biconomyは、第三者の開発者が、Biconomyによって事前に定義されたプロトコルルール（EIP-4337と互換性あり）に準拠すれば、異なるコードの詳細や異なるバージョンのモジュールを実装できるようにしています。

一方、Biconomyは「モジュールストア」というスローガンも導入しています。アカウントの抽象化モジュールSDKを積極的に展開する一方、Biconomyは開発者に独自設計のアカウント抽象化モジュールを提出するよう奨励し、「モジュールサービス」として始動し、EIP-4337プロトコルに準拠したすべてのウォレットプロジェクトがこれらのサードパーティによって書かれたアカウント抽象化モジュールを直接採用できるようにしています。ユーザーがフロントエンドインターフェースを通じてスマートアカウントを作成するとき、より多様なモジュールを選択できるようになります。

モジュラリゼーションは、労働分担を容易にするだけでなく、ユーザーがスマートウォレット内の特定の機能を素早く切り替えたり、追加したり、削除したりできるようにします（より簡単な言葉で言えば、粒度をより細かいコンポーネントに分解します）。

Biconomyは、スマートコントラクトウォレットのモジュール化の程度が高いほど、更新やアップグレード時に必要な変更が少なくなることを指摘しています（ユーザーの既存のスマートコントラクトウォレットの契約を更新する必要がなく、DelegateCallを使用する必要もなく、一部の外部モジュールのみを更新する必要があります）。これにより、異なるユーザーや開発者が特定のコンポーネントを簡単に置き換えることができるようになります。

Biconomyの新しいアカウントの抽象化ソリューションの将来バージョンでは、EIP-4337よりもモジュラリゼーションに適しているEIP-6900も参照されます。

最適化方向2：細かい粒度のモジュールセグメンテーションによってアカウントの断片化問題に対処する

EIP-6900提案に関して、Safe（旧Gnosis Safe）は実際に今年8月にそれに関連するSafe Core Protocolホワイトペーパーを公開しましたが、それはEIP-6900から大きく影響を受けています。

EIP-6900は、モジュール化されたアカウントの抽象化に関する現在の問題として、アカウントの「断片化」または「孤立」の問題を指摘しています。たとえば、異なるアカウント抽象化モジュールの提供業者や異なるDAppアプリケーションがEIP-4337と互換性があるかもしれませんが、EIP-4337の抽象化レベルは異なるモジュールに対して十分に高くなく、粒度が比較的粗いです。これにより、スマートアカウントモジュール開発者には「過剰な」自由が残されます（スマートアカウントはユーザー情報を保存し、カスタムトランザクションの検証とガス支払いロジックの中核部分を記録します）。

その結果、異なるウォレットプロジェクトは、固有の属性を持つスマートアカウントモジュールを設計する傾向があります。 その結果、他のアカウント抽象化モジュールプロバイダーは、提供されるスマートアカウントモジュールとの互換性を優先する必要があり、固定された上流および下流のサプライチェーンの出現につながります。 これにより、アカウント抽象化モジュールエコシステムにおいて破片化と切断が不可避になります。(これは、コンピュータ業界の初期に、オペレーティングシステム開発者が異なるコンピュータハードウェアメーカーからのハードウェアデバイスとの互換性を考慮する必要があった時と似ています。)

エコシステムの断片化の問題を解決し、異なるプロバイダーによって開発されたアカウントの抽象化モジュールの互換性を向上させるためには、最良のアプローチは、スマートコントラクトウォレットアカウントをさらに抽象化し、モジュールの分割の粒度を細かくすることです。

EIP-6900のアイデアを取り入れた後、Safe Core Protocolのホワイトペーパーは、Smart Account（ユーザーのスマートコントラクトウォレットアカウント）にさらに詳細な最適化を行いました。Safe Core Protocolは、スマートコントラクトウォレットアカウントの各呼び出し可能モジュールを、プラグイン、フック、署名検証者、および機能プロセッサなどのさまざまなカテゴリに分割します。

スマートアカウントモジュールは、アカウント契約が最も基本的なデータと機能のみを保存し、外部に移動できる機能は「機能プロセッサ」や「プラグイン」などの専門モジュールによって実装されています。これはオッカムの剃刀の原則に従っています:「必要以上に実体を増やすべきではない」。

スマートアカウント自体が軽量であり、複雑な詳細をあまり含まない場合、異なる製造業者によって開発されたスマートアカウントは内部構造でより類似しており、互換性も高くなります。

Safe Coreプロトコルは、iPhone App Storeに類似したレジストリを導入しており、すべての承認済みおよび利用可能なモジュールが含まれています。ユーザーはアクティブ化するモジュールを選択でき、新しいモジュールをアクティブ化するたびに、それはManger契約を介して処理されなければなりません。

一般的に、UserOperation は最初に特定のプラグインをトリガーし、その後、マネージャー契約はプラグインの状態が正常かどうか（レジストリに記録されている）をチェックします。状態が正常であれば、マネージャー契約はプラグインのリクエストを続行させます。必要に応じて、プラグインは一部のフックが提供する特定の機能を呼び出すことがありますが、そうでない場合もあります。その後、UserOperation に関与するスマートアカウントの状態が変更されます。

上記の細かいモジュールのセグメンテーションとスケジューリングプロセスを通じて、Safe Core Protocolはオープンソースのアカウントの抽象化モジュールの相互運用性プロトコルを推進しようとしています。その中心的なアイデアは、異なるメーカーによって開発されたスマートアカウントモジュール間の互換性を向上させるために、スマートアカウントを可能な限り軽量化し、それらをEOAアカウントと同じくらいシンプルにすることです。

最適化方向三：さまざまなチェーンでの統一されたアカウントの抽象化、異なるチェーン上での一貫したアカウントの実現

しかし、上記の解決策を採用しても、依然として未解決の重大な問題があります。異なるチェーンや異なるLayer 2ソリューションが、相互に衝突する形式で様々なアカウントの抽象化実装スキームを進めており、その多くがEIP-4337と衝突しています。たとえば、zkSync Era、Starknet、Flowなどです。ウォレットUXのこの断片化は、Starknet上のユーザーのスマートウォレットアドレスをArbitrum上のそれと統一することを不可能にしています。

さらに、マルチチェーン環境では、ユーザーは異なるチェーン上で独自にスマートアカウントを展開しており、それらの対応するユーザーデータはしばしばこれらの契約に保存されています。キーなどのユーザーデータを更新する必要がある場合、トランザクションを複数のチェーンにわたって繰り返す必要があり、スマートアカウントの一貫性を確保することが難しくなります。

Vitalik himself previously proposed a unified and easily manageable smart account solution across all chains. This solution uses Ethereum or a highly secure ZKRollup as the source chain, deploys a Keystore contract to store users’ global keys, and then all smart contract accounts on Layer 2 share the global keys stored in the Keystore contract。

しかし、この解決策には非常に高いコストがかかります。ソースチェーン上のKeystore契約に記録されたグローバルキーに変更があるたびに、L2/ターゲットチェーン上の各アカウントは、クロスチェーン相互作用を通じて新しいキーを同期する必要があります。ただし、EthereumとL2の間のクロスチェーン相互作用のコストは、ユーザーには高すぎます。さらに、重要なのは、スマートコントラクトアカウントがEOAアカウントとは異なることです。後者は、独自のアドレス生成方法によって、EVMエコシステム内の複数のチェーン全体で自然に統一されるため、異なるチェーン上で同じアドレスのスマートコントラクトアカウントを取得することが困難になっています。

これに対応するために、Particle Networkは独自の手法を提案しています。一般的な考え方はVitalikのスマートアカウントのストレージとコードを分離するというコンセプトと一致していますが、Particle Networkは別のチェーン、Particle Network Chainをスマートアカウントの完全なチェーンストレージデータベースとして使用する予定です。LayerZero、CCIP、Axelar、Connextなどのサードパーティーのクロスチェーンメッセージングソリューションを通じて、Particle Networkはアカウントのストレージの変更を他のチェーンのローカルアカウントに同期させる意向です。

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

具体的には、Particle Networkのフルチェーンアカウント抽象化システムは、異なるEVMチェーン全体で統一されたスマートコントラクトアカウントアドレスをユーザーに提供することを目指しています。これには、異なるチェーン上に一連のDeployer Contractsを展開する必要があります。ユーザーは、Particle Network Chain上で新しいアカウントの生成をトリガーする必要があり、その後、Particle Chainは異なるチェーン上のすべてのDeployer Contractsをトリガーして、異なるチェーン上でユーザーのために生成されたスマートコントラクトアカウントアドレスが一貫していることを確認します。また、ユーザーは、異なるチェーンを意識することなく、Particleチェーン上の契約を介してマルチチェーンの相互作用を完了することができ、統一された手数料支払い方法として統一されたガストークンを使用することができます。

フルチェーンのアカウント抽象化は、クロスチェーンユーザーオペレーションを可能にし、ユーザーオペレーションを介してターゲットチェーンでトランザクションをトリガーし、ソースチェーンで対応するガスを支払うことができます。たとえば、PolygonのUSDCを使用してBaseでNFTを購入することができます。

ただし、Particle Networkのソリューションには、Deployer契約とクロスチェーンメッセージングコンポーネントの間での高度な連携が必要で、マルチチェーンアカウントとソースチェーンストレージを同期する必要があります。これにより、使用されるオラクルまたはクロスチェーンメッセージングブリッジに高い要求がかかります（これは、フルチェーン相互運用性に関連するすべてのソリューションに存在する課題のようです）。

ただし、ユーザーのクロスチェーンアカウント同期は、単一のブリッジに依存せず、さまざまなメッセージブリッジの組み合わせで柔軟に構成することができます。たとえば、LayerZero、Axelar、またはConnextのいずれか2つが変更を確認した後にのみ、ターゲットチェーンのストレージの変更が確認される2/3ポリシーで構成することができ、これにより単一の依存点の問題を軽減することができます。

EVMおよび非EVMチェーン間のシームレスな相互運用性は、イーサリアムエコシステム内の完全チェーンアカウントの抽象化におけるさらなる進展を表しています。EVMチェーン全体でのキー管理および統合アカウントの進化にもかかわらず、完全なチェーンアカウントの抽象化にはまだ最適化の余地があります。Aptos、Solana、SuiなどのEVM互換性のないチェーンでは、ユーザーによって生成されたスマートコントラクトアカウントアドレスの一貫性をEVMチェーン上のそれらと保証できません。また、非EVMチェーンは、VitalikおよびParticle Networkによって提案された完全チェーンアカウントの抽象化の概念を採用するのに苦労するかもしれません、EIP-4337プロトコルへの同等の解決策を実装せずに。

さらに、EIP-4337と互換性のあるウォレットプロジェクトの改善の余地があります。ほとんどのスマートウォレットは、しばしば相互に接続されていない各プラットフォームによって独立して運営されるBundlerノードを使用しています。この孤立は、検閲耐性や可用性などのリスクをもたらします。ほとんどのチェーン全体にわたる統一されたフロントエンドインターフェイスを構築することは非常に困難です。これを対処する1つのアプローチは、意図中心の設計を導入し、EthereumのEIP-4337エコシステムや他のチェーンのネイティブアカウント抽象化機能（例：zkSyncなど）をSolver/Reactorカテゴリーの特定のインスタンスとして扱い、適切なSolverの選択をより高レベルのタスクと見なすことです。

Particle Networkを例に取ると、異なるアカウント抽象化プロジェクトが、単にIntentスキーム内のSolverカテゴリに含まれるインスタンスである、Intent中心実装の簡潔な抽象化を提案しています。

最初に、ユーザーインターフェイスは、自然言語の要求やユーザーとのやり取りを具体的なプログラム記述に変換する責任があります。つまり、許容される入力の条件と許容される出力結果の範囲（つまり、許容される入力の条件と許容される出力結果の範囲）が含まれます。その後、ソルバーネットワークの1つ以上のソルバーは、特定の入出力制約を含むトランザクションを、チェーンに展開されたソルバーコントラクトに転送します（ソルバーはノード施設だけでなく、オンチェーンのコントラクトコンポーネントも含みます）。ソルバーコントラクトは、その後、インテントの指示をリアクターコントラクト（ユーザーのオンチェーンアカウントを管理する）に渡し、実行を委任して最終的なやり取りを完了します。

ユーザーのリクエストはまずSolverネットワークによって受信され、ユーザーは基礎となるチェーンや異なるアカウント抽象化スキームの構築に過度に関心を持つ必要はありません。この部分はSolverによって処理され、特定のソリューションを構築するために扱われます。

もちろん、これらのアイデアは現在は単なる理論的な枠組みに過ぎず、実装の詳細はまだParticle Networkによる公式の展開が保留されています。明らかなことは、将来競争的なSolver市場が必然的に現れるだろうということであり、ユーザーは複数のSolverに対してオークションを開始し、異なる解決策を提案することができます。ローカルでシミュレートされた取引を通じて、最適な解決策が選択され、対応するSolverに報酬が与えられます。インセンティブの形式については、Solverネットワークのプロトコル設計者の考えに依存します（Particle Networkは、Solverオークション市場に対するインセンティブとしてPNTトークンを使用する予定です）。

現在のIntentは、基礎となる複雑な詳細を実質的に保護し、より上位のレイヤーを抽象化します。このようなTCP/IPプロトコルに似た階層設計は、チェーン間のシームレスな相互運用性において、ユーザーと開発者の両方にとって必要不可欠です。

アカウントの抽象化の広範な採用を受け入れる

Ethereumエコシステム内の4337フレームワークをさまざまな角度から最適化し、同時にEthereumエコシステムと非Ethereumエコシステム間のシームレスな相互運用性を促進することで、アカウントの抽象化の普及を支援するためには、供給側と需要側の両方をカバーする製品の需要がまだあると考えています。これは、エンドユーザーがさまざまなWeb3製品サービスを利用する障壁を減らすだけでなく、サービス開発者がその閾値を下げることに焦点を当てる必要があります。

この役割を果たすのに最適な製品の1つは、Particle NetworkのModular Smart Wallet-as-a-Service（Modular Smart Wallet-as-a-Service）製品です。

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

上記の開発者向け機能に加えて、Particle NetworkのModular Smart Wallet-as-a-Service（Modular Smart Wallet-as-a-Service）製品の最も重要な側面は、開発者コミュニティにおいて署名計算に基づいてアカウントの抽象化のためのオープンなエコシステムを構築していることです。自己開発のアカウント抽象化製品モジュールを提供するだけでなく、様々な種類のアカウント抽象化製品やサービスを統合し、アカウント抽象化全体の開発者からの製品やサービスの迅速な採用を促進しています。

技術と需要を整合させ、ERC-4337フレームワークの制約に対処し、開発者のエクスペリエンスの改善は、優れたユーザーエクスペリエンスを備えた製品の台頭を促進するでしょう。これにより、Web3業界の移行が加速し、暗号通貨愛好家向けの金融志向から、消費者向けのメインストリームへと進化します。

免責事項：

1. この記事は再印刷されました[腾讯網],すべての著作権は元の著者に帰属します[Particle Networkの共同創設者兼CTOであるPeter Pan、およびFaust，Geek Web3]. If there are objections to this reprint, please contact the Gate Learnチームが promptly で対処します。
2. 免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。