作者:ピーターパン、パーティクルネットワーク&ファウストの共同創設者兼CTO、极客Web3
2022年以降、アカウントの抽象化は広く議論されているトピックであり、EIP-4337をコアとするアカウントの抽象化のフレームワークは、業界の一般的なコンセンサスになっているようです。 インテントの概念の人気により、このような低しきい値のユーザーインタラクションコンポーネントにさらに焦点が当てられるようになりました。
ただし、EIP-4337には、スマートアカウントアカウントの断片化とクロスチェーンアカウントの非常に断片化された抽象ユーザーエクスペリエンスの問題点が残っています。 **この記事では、Biconomy、Safe Core、Particle Networkなどのプロジェクトを例として使用し、EIP-4337フレームワークの下でアカウント抽象化の分野をさらに前進させる方法を探ります。 **
アカウントの抽象化に関して、Vitalikは、イーサリアムユーザーのしきい値を下げ、大量採用を達成するための必要条件であると繰り返し指摘しており、そのコアビジョンは、ユーザーが署名検証方法をカスタマイズしてガス決済を享受し、資産なしでチェーン上でトランザクションを開始できるようにすることです(一般にガスレストランザクションとして知られています)。 これらの前提条件を実装することによってのみ、Web3アプリケーションの新規ユーザーのコンバージョン率を高めることができます。
過去には、非アカウントの抽象的な提案やスマートコントラクトウォレットは、同様のエクスペリエンスを実現できますが、Gnosis SafeはトランザクションをトリガーするためにEOAアドレスを必要とし、ガスコストが非常に高いなど、柔軟性と効率性にはほど遠いものでした。
アカウントの抽象化は、スマートコントラクトアカウントの構造の最下層から最適化して、次世代のインテリジェントアカウントシステムへの道を開くことを目的としています。
しかし、実際のアカウント抽象化の提案から、彼らの焦点はアカウントモデル自体にないことがわかります。 たとえば、EIP-86、EIP-4337、EIP-6900、およびその他のアカウント抽象化関連の提案は、開始からノード受信、署名検証、ガス支払いなどのトランザクションの処理プロセス全体の抽象化/モジュール性に焦点を当てており、アカウント構造の抽象化にはあまり注意を払っていません。 したがって、現在の提案を「トランザクション抽象化」と呼ぶ方が適切であるように思われます。
これらのよく知られたアカウント抽象化の提案を「トランザクション処理プロセスの抽象化」の観点から理解すると、それらの要点をより簡単に理解できます:このトランザクション抽象化は、ブラックリスト/ホワイトリスト、一定期間内にトランザクションを開始するための本人確認なし、ガス取引なし、法定通貨支払い手数料など、Web2レベルのユーザーがイーサリアムシステムに製品を入力して使用する経験を実際にもたらしたいと考えています。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
しかし、一部の人々は尋ねるでしょう:これらのことは過去にスマートコントラクトウォレットに実装することはできませんか? EIP-4337のような抽象スキームの価値は何ですか?
上記の質問で述べたように、過去のスマートウォレットは上記の機能を実現できますが、実装方法は一般的に大まかであり、多くの場合、高度に集中化されたサードパーティの機能に依存しています。 たとえば、以前は、ガス支払いスキームはサードパーティのリレイヤーノード(EIP-2771)を導入することでした。 さらに、異なるスマートウォレット間の統一された標準の欠如は、サポートコンポーネントの開発と展開を助長しません。 **
さまざまなアカウントの抽象化に関連するEIPの中心的な魅力は、スマートコントラクトウォレット用に設計された標準化されたフレームワークを通じて、さまざまなウォレットプロジェクトでこれらの欠陥を解決し、イーサリアムエコシステムのアカウント構造を基本的な機能構造からより高い天井を持つインテリジェント構造に促進することです。
たとえば、ERC-20やERC-721が登場する前は、外部から提供される多くのトークン実装、関数、関数/インターフェースに一貫性がなく、「不整合」はサードパーティの機能やコード監査をサポートする開発に役立ちませんでした(ERC-20プロトコルがなければ、Defiアプリケーションがどのように現在の繁栄に発展したか想像するのは難しいです)。
標準化されたプロトコル/機能の実装標準はモジュラーナラティブの前提条件であり、モジュラー開発はほぼすべての分野が繁栄するための前提条件です(分業は効率の最初の原則です)。 **
結局、EIP-4337が前面に出ました。
EIP-4337は一連のインターフェース標準を定義し、少なくとも4337プロトコルに従うスマートウォレットに必要なモジュール、各モジュールが実装すべき機能/インターフェース(バンドラー、エントリーポイント、ペイマスターなど)、およびどの呼び出し可能な機能を外部に提供する必要があるかを明確にしています。
これらのルールを明確にした後、異なるコンポーネント間の相互作用がより明確になり、アカウントの抽象化とスマートウォレットの設計にモジュラー設計のアイデアを導入するのに便利であり、ウォレットモジュールの開発者も大きなメリットを得ます。 **
もちろん、純粋にユーザーの観点からは、モジュラースマートウォレット開発パラダイムによってもたらされる価値は、短期的にはアカウントの抽象ウォレット自体に大きな変化を感じないため、明確ではありません。 **しかし、中長期的には、EIP-4337などのプロトコルは、アカウント抽象ウォレットの長期的な開発の基礎を築くERC-20やERC-721と価値が似ており、画期的なマイルストーンです。
ただし、EIP-4337にはまだ多くの未解決の問題があります:**例:
1.アカウント抽象化の機能は十分にプラグインされておらず、さまざまな開発者が車輪を再発明するのは簡単です。
2.アカウントモジュールの互換性は低く、アカウントシステム全体がエコロジーの断片化の傾向を示しています。
3.異なるチェーン間のアカウント抽象化エコロジーは非常に断片化されているため、エンドユーザーと開発者に統一された高品質のエクスペリエンスを提供し、より良いUXを実現することは困難です。
以下では、これらの問題の解決策を探ります。
**現在、アカウント抽象化に関連する中心的な議論のポイントの1つは、アカウント抽象ウォレットのモジュール性をよりよく実現し、各モジュールの粒度をより細かくカットする方法であると言えます。 **
たとえば、Biconomyは、アカウント抽象化エコロジーのモジュラー開発をさらに促進するために、EIP-4337(より細かい粒度のEIP-6900が将来導入される)に基づく物語を提案しています。
いわゆるアカウント抽象化関数プラグインは、実際には、スマートコントラクトウォレットに含まれる主要なモジュール、これらのモジュールが実装すべきインターフェイス/関数、およびこれらのインターフェイスの名前と呼び出し方法を明確にするためのものです。 その後、サードパーティの開発者は、独自のアイデアに従ってさまざまな詳細を持つコンポーネントを開発しますが、これらのコンポーネントは契約に定められた要件を満たします。
EIP-4337をプロトコルバックボーンとするBiconomyのV2バージョンは、より詳細な標準を開発し、4337で言及されていない多くのインターフェイスを追加しました。 Biconomyは、バンドラー、スマートコントラクトウォレット、Paymasterなどのモジュールが持つべき機能を述べながら、Biconomyによって事前に述べられたプロトコルの詳細に従う限り、サードパーティの開発者が同じ特性と異なるバージョンを持つモジュールを異なるコード詳細で実装できるようにします(EIP-4337と互換性があります)。
同時に、Biconomyは「モジュールストア」のスローガンを提唱し、アカウント抽象モジュールSDKを個人的に立ち上げながら、開発者の大多数は、独自に設計されたアカウント抽象モジュールを提出し、「サービスとしてのモジュール」を展開し、**EIP-4337プロトコルに従うすべてのウォレットプロジェクトが部外者によって書かれたこれらのアカウント抽象モジュールを直接採用できるようにすることをお勧めします。 ユーザがフロントエンドページからスマートアカウントを作成すると、使用するモジュールをより多様に選択できます。
モジュール性は分業に便利ですが、ユーザーがスマートウォレットの特定の機能をすばやく切り替えたり、追加および削除したりすることも便利です(率直に言って、粒度をより細かく分割することです)。
Biconomyは、スマートコントラクトウォレットがモジュール化されているほど、更新またはアップグレード時に行う必要のある変更が少なくなり(ユーザーの既存のスマートコントラクトウォレットコントラクトを更新したり、DelegateCallを使用したりする必要はなく、一部の外部モジュールのみ)、さまざまなユーザーや開発者が特定のコンポーネントを簡単に交換できるようになると指摘しました。
Biconomyの将来の新しいアカウントの抽象化では、EIP-6900よりもモジュール化されたEIP-4337の提案も参照します。
EIP-6900の提案に関して、**Safe(旧Gnosis Safe)は、今年8月に関連するSafe Core Protocolホワイトペーパーを実際に発表し、最も借用されたものはEIP-6900です。 **
**EIP-6900は、モジュラーアカウントの現在の抽象化に関する1つの問題は、アカウントの「断片化」、またはサイロの問題であると指摘しています。 たとえば、さまざまなアカウント抽象化モジュールベンダーまたはさまざまなDAPPアプリケーションがEIP-4337と互換性がありますが、EIP-4337はモジュールごとに十分な高さではなく、粒度は比較的粗く、スマートアカウントモジュール開発者には「高すぎる」自由度が残ります(スマートアカウントは、ユーザー情報を保存し、カスタムトランザクション検証とガス支払いロジックを記録する中核部分です)。
このように、さまざまなウォレットプロジェクト関係者が、独自のプロパティを持つスマートアカウントモジュールを設計する傾向があります。 **長期的には、他のアカウント抽象化モジュールサプライヤは、互換性のあるスマートアカウントモジュールを誰が提供するかを優先し、固定の上流および下流のサプライチェーンをゆっくりと生成する必要があり、必然的にアカウント抽象化モジュールのエコロジーの断片化と分離につながります。 **(これは、コンピューター業界の初期の頃のように、オペレーティングシステム開発者は、どのコンピューターハードウェアメーカーと互換性があるかを検討しなければなりませんでした。
生態学的断片化の問題を解決し、さまざまなベンダーによって開発されたアカウント抽象化モジュールの互換性を向上させるには、スマートコントラクトウォレットアカウントをさらに抽象化し、モジュールをより細かくするのが最善の方法です。
EIP-6900のアイデアを借用した後、**セーフコアプロトコルホワイトペーパーは、スマートアカウント(ユーザーのスマートウォレットアカウント)のより詳細な最適化を行いました。 Safe Coreプロトコルは、各スマートウォレットアカウントから呼び出すことができるモジュールをプラグイン、フック、署名検証機、関数プロセッサ、およびその他のカテゴリに分割します。 **
スマートアカウントモジュールは可能な限り軽量で、アカウントコントラクトは最も基本的なデータと機能のみを保存し、外部に移動できる機能はすべて「関数プロセッサ」または「プラグイン」サブディビジョンモジュールにスローされて実装されます。 これは、いわゆるオッカムのかみそりの原則である「必要な場合を除いてエンティティを追加しない」を反映しています。
スマートアカウント自体が十分に軽量で、面倒な詳細が含まれていない場合、さまざまなメーカーによって開発されたスマートアカウントは内部構造が近く、互換性が高くなります。
Safe Coreプロトコルでは、iPhoneのアプリストアと同様に、承認されたすべての利用可能なモジュールを含むレジストリも導入されています。 ユーザーはアクティブ化するモジュールを選択でき、新しいモジュールがアクティブ化されるたびに、Minger コントラクトを通じて処理されます。
一般に、UserOperationは最初にプラグインプラグインをトリガーし、次にMangerコントラクトはプラグインのステータスが正常かどうか(レジストリにレコードがある)をチェックし、正常であればプラグインのリクエストを許可します。 必要に応じて、プラグインプラグインはフックによって提供される機能の一部を呼び出すかどうか。 その後、UserOperation に関連するスマートアカウントの状態が変更されます。
上記のきめ細かなモジュールシャーディング方法とスケジューリングプロセスを通じて、Safe Core Protocolは、さまざまなベンダーによって改善されたスマートアカウントモジュールの互換性を向上させるために、スマートアカウントをEOAアカウントと同じくらい簡単にすることを目的とした一連のオープンソースアカウント抽象モジュール相互運用性プロトコルの実装を試みます。
しかし、前述のソリューションを使用しても、解決されていない大きな問題がまだあります:異なるチェーンと異なるLayer2は、異なる詳細でアカウントの抽象化を促進しており、多くはeIP-4337と競合するフォームを使用しています(zkSync Era、Starknet、Flowなど)。 これにより、Starknet上のユーザーのスマートウォレットアドレスとArbitrum上のスマートウォレットアドレスがまったく統一できないなど、ウォレットのUXが断片化しています。
さらに、マルチチェーン環境では、ユーザーは異なるチェーンにスマートアカウントを個別に展開しており、対応するユーザーデータがこれらの契約に散在していることがよくあります。 キーなどのユーザデータを更新する必要がある場合、複数のチェーンでトランザクションを繰り返し開始する必要があり、スマートアカウントの一貫性を確保することは困難です。
ヴィタリック自身は以前、フルチェーンの統合された管理しやすいスマートアカウントスキームのセットを提案しており、**このスキームはイーサリアムまたは安全性の高いZKRollupをソースチェーンとして使用し、キーストアコントラクトを展開し、ユーザーのグローバルキーを保存し、L2上のすべてのユーザーのスマートコントラクトアカウントは、キーストアコントラクトに保存されているグローバルキーを共有します。
ただし、このソリューションは非常に高価であり、ソースチェーンのキーストアコントラクトに記録されたグローバルキーが変更されるたびに、L2/ターゲットチェーンの各アカウントは、チェーン間の相互作用を通じて新しいキーを同期する必要があります。 イーサリアムとL2の間のクロスチェーンインタラクションは、ユーザーが余裕があるには高すぎます。 また、スマートコントラクトアカウントは、独自のアドレス生成方法のために本質的にマルチチェーン統合(EVMチェーン間で統一)されているEOAアカウントとは異なりますが、スマートコントラクトアカウントは完全に異なり、ユーザーが異なるチェーンで同じアドレスのスマートコントラクトアカウントを取得することは困難です。
パーティクルネットワークは、これに対する独自のアプローチを考え出しました。 一般的な考え方は、スマートアカウントのストレージとコードを分離するというVitalikの考え方と同じですが、パーティクルネットワークは、サードパーティのクロスチェーンメッセージングソリューション(LayerZero、CCIP、Axelar、Connext)を通じて、スマートアカウントのフルチェーンストレージデータベースとして独立したチェーンであるパーティクルネットワークチェーンを使用する予定です。 など)アカウントストレージに対するユーザーの変更を、他のチェーンのローカルアカウントに同期します。
(パーティクルネットワークのマルチチェーンアカウント抽象化)
具体的には、Particle Networkのフルチェーンアカウント抽象化システムでは、ユーザーは異なるEVMチェーンに統一されたスマートコントラクトアカウントアドレスを持つ必要があり、異なるチェーンに一連のデプロイヤーコントラクトを展開する必要があります。
ユーザーはパーティクルネットワークチェーンで新しいアカウントの生成をトリガーする必要があり、その後、パーティクルチェーンはすべてのチェーンでデプロイヤーコントラクトをトリガーし、異なるチェーンのユーザー用に生成されたスマートコントラクトアカウントアドレスが均一であることを確認するか、ユーザーは他のチェーンを意識することなくパーティクルチェーンのコントラクトを通じてマルチチェーンインタラクションプロセスを完了し、ユニファイドガスを使用できます 統一された料金支払い方法としてのトークン。
フルチェーンアカウントの抽象化により、クロスチェーンのユーザー操作も可能になり、ソースチェーンのユーザー操作と、ポリゴンのUSDCを使用してベースでNFTを購入するなど、対応するガス支払いを通じてターゲットチェーンのトランザクションがトリガーされます。
ただし、Particle Networkソリューションでは、マルチチェーンのアカウントとソースチェーンストレージの同期を実現するために、Deployerコントラクトとクロスチェーンメッセージングコンポーネント間の高度なコラボレーションが必要であり、実際には使用するオラクルまたはクロスチェーンメッセージブリッジに高い要件があります(この問題は、フルチェーンの相互運用性に関連するすべてのスキームに存在するようです)。
ただし、ユーザーのクロスチェーンアカウント同期は、2/3として構成できる戦略など、特定のブリッジのみに依存するのではなく、異なるメッセージブリッジの組み合わせを柔軟に構成でき、LayerZero、Axelar、およびConnextのいずれか2つの確認に依存してターゲットチェーン上のストレージの変更を確認し、この単一ポイントの依存関係の問題をほぼ解決できます。
EVMチェーン全体にキー管理と統合アカウントがありますが、フルチェーンアカウントの抽象化にはまだ最適化の余地があります:Aptos、Solana、SuiなどのEVMと互換性のないチェーンは、ユーザーが生成したスマートコントラクトアカウントアドレスがEVMチェーンと一致していることを保証できません。 同時に、非EVMチェーンが同等のスキームでEIP-4337プロトコルを実装していない場合、上記のVitalikとParticle Networkによって提案されたフルチェーンアカウントの抽象的な概念に従うことは困難です。
さらに、EIP-4337互換のウォレットプロジェクト自体にも改善の余地があります。 スマートウォレットで使用されるバンドラーノードのほとんどは、公式には独立して実行され、相互に通信することすらなく、多くのスマートウォレットプロジェクトは実際には独自のチェーンを形成しており、多くのリスク(検閲耐性、ユーザビリティ)をもたらします。 ほとんどのチェーンで統一された単一のフロントエンドインターフェイスを構築することは非常に困難です。 1つの解決策は、インテント中心の設計を導入し、フルチェーンのアカウント抽象化の上にレイヤーを追加し、イーサリアムのEIP-4337エコシステムまたは他のチェーンのネイティブアカウント抽象化機能(zkSyncなど)をソルバー/リアクタータイプの特定のインスタンスとして扱うことです。 **
パーティクルネットワークを例にとると、簡潔な抽象化インテントの実装を提案しますが、さまざまなアカウントの抽象化は、ソルバーに含まれるインテントソリューションのインスタンスのクラスにすぎません。
まず、ユーザーフロントエンドは、自然言語リクエストまたは任意のユーザーインタラクションを、入力制約や出力制約(率直に言って、ユーザーの要件を満たす入力条件と出力結果間隔)を含む特定のプログラム記述に変換する責任があり、次にソルバーネットワーク内の1つ以上のソルバーにトランザクションの特定の入力および出力制約が含まれます。 オンチェーンでデプロイされたソルバーコントラクトに転送(ソルバーにはノード機能だけでなく、オンチェーンコントラクトパーツもあります)。 ソルバーコントラクトは、インテント命令をリアクタコントラクト(チェーン上のユーザーのアカウントを管理する)に送信し、リアクタコントラクトは他のモジュールを呼び出して最終的な相互作用を完了します。
ユーザーの要求は最初にソルバーネットワークによって認識されるため、ユーザーは基礎となるチェーンやさまざまなアカウント抽象化の構築を認識する必要がなく、この部分は特定のソリューションを構築するためにソルバーに任されます。
もちろん、これらのアイデアはまだ理論的な枠組みに過ぎず、その背後にある実装の詳細はまだパーティクルネットワークによって公式に説明されていません。
現在、競争の激しいソルバー市場が将来生まれることは明らかであり、ユーザーはオークションを開始して複数のソルバーが異なるソリューションを考え出すことができ、ローカルシミュレーション取引の形式を通じて、最適なソリューションを選択し、対応するソルバーにインセンティブを与えることができます。 インセンティブの形式は、ソルバーネットワークのプロトコル設計者によって異なります(パーティクルネットワークは、ソルバーオークション市場のインセンティブトークンとしてPNTトークンを使用する予定です)。
現在の意図は、基本的に下位層の複雑な詳細をシールドし、上位層に抽象化します TCP/IPプロトコルの性質を持つこのような階層化された設計は、チェーン全体のシームレスな相互運用性の下でのユーザーエクスペリエンスと開発者エクスペリエンスに必要です。
イーサリアムエコシステムの4337フレームワークをあらゆる角度から最適化し、イーサリアムエコシステムと非イーサリアムエコシステム間のシームレスな相互運用性を促進する場合、アカウント抽象化の大規模な採用をサポートするために、供給側と需要側にまたがる製品がまだ必要であると感じています。 エンドユーザーによるさまざまなWeb3製品やサービスの使用を減らすと同時に、サービス開発者に焦点を当て、開発者のしきい値を下げることができます。 **
この役割に最適な製品の1つは、パーティクルネットワークのモジュラースマートサービスとしてのウォレット製品です。
*このサービスは、開発者がモジュラーアカウント抽象化機能をアプリケーションに簡単に統合できるようにする使いやすいAPIセットを提供します。 *開発者はこのサービスを使用して、フルチェーンアカウントの作成と管理、クロスチェーンインタラクションの実行、および統一された料金支払い方法の使用を行うことができます。 このようなサービスは、マルチチェーンアプリケーションを構築し、アカウント抽象化の広範な採用を促進するためのより柔軟で便利な方法を開発者に提供します。
上記の開発者向けの機能に加えて、最も重要な機能は、Particle Networkのモジュラースマートサービスとしてのウォレット**製品が、シグネチャコンピューティングに基づくオープンエコロジーを構築し、開発者のアカウント抽象化分野に向けられていることです。 アカウント抽象化分野全体で、さまざまな開発者の製品やサービスの採用を迅速に促進できます。
ERC-4337フレームワークのあらゆる角度の限界を解決した後、テクノロジーが需要に応えられるようにし、開発者エクスペリエンスの向上により、優れたユーザーエクスペリエンスを備えたより多くの製品が促進され、Web3業界がクリプトパンクに優しい金融業界から大衆に優しい消費者業界に加速します。
3k 人気度
157k 人気度
12k 人気度
100k 人気度
84k 人気度
フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
作者:ピーターパン、パーティクルネットワーク&ファウストの共同創設者兼CTO、极客Web3
2022年以降、アカウントの抽象化は広く議論されているトピックであり、EIP-4337をコアとするアカウントの抽象化のフレームワークは、業界の一般的なコンセンサスになっているようです。 インテントの概念の人気により、このような低しきい値のユーザーインタラクションコンポーネントにさらに焦点が当てられるようになりました。
ただし、EIP-4337には、スマートアカウントアカウントの断片化とクロスチェーンアカウントの非常に断片化された抽象ユーザーエクスペリエンスの問題点が残っています。 **この記事では、Biconomy、Safe Core、Particle Networkなどのプロジェクトを例として使用し、EIP-4337フレームワークの下でアカウント抽象化の分野をさらに前進させる方法を探ります。 **
トランザクションプロセスの抽象化の観点から「アカウント抽象化」の概念を理解する
アカウントの抽象化に関して、Vitalikは、イーサリアムユーザーのしきい値を下げ、大量採用を達成するための必要条件であると繰り返し指摘しており、そのコアビジョンは、ユーザーが署名検証方法をカスタマイズしてガス決済を享受し、資産なしでチェーン上でトランザクションを開始できるようにすることです(一般にガスレストランザクションとして知られています)。 これらの前提条件を実装することによってのみ、Web3アプリケーションの新規ユーザーのコンバージョン率を高めることができます。
過去には、非アカウントの抽象的な提案やスマートコントラクトウォレットは、同様のエクスペリエンスを実現できますが、Gnosis SafeはトランザクションをトリガーするためにEOAアドレスを必要とし、ガスコストが非常に高いなど、柔軟性と効率性にはほど遠いものでした。
アカウントの抽象化は、スマートコントラクトアカウントの構造の最下層から最適化して、次世代のインテリジェントアカウントシステムへの道を開くことを目的としています。
しかし、実際のアカウント抽象化の提案から、彼らの焦点はアカウントモデル自体にないことがわかります。 たとえば、EIP-86、EIP-4337、EIP-6900、およびその他のアカウント抽象化関連の提案は、開始からノード受信、署名検証、ガス支払いなどのトランザクションの処理プロセス全体の抽象化/モジュール性に焦点を当てており、アカウント構造の抽象化にはあまり注意を払っていません。 したがって、現在の提案を「トランザクション抽象化」と呼ぶ方が適切であるように思われます。
これらのよく知られたアカウント抽象化の提案を「トランザクション処理プロセスの抽象化」の観点から理解すると、それらの要点をより簡単に理解できます:このトランザクション抽象化は、ブラックリスト/ホワイトリスト、一定期間内にトランザクションを開始するための本人確認なし、ガス取引なし、法定通貨支払い手数料など、Web2レベルのユーザーがイーサリアムシステムに製品を入力して使用する経験を実際にもたらしたいと考えています。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
しかし、一部の人々は尋ねるでしょう:これらのことは過去にスマートコントラクトウォレットに実装することはできませんか? EIP-4337のような抽象スキームの価値は何ですか?
EIP-4337の本質:イーサリアムエコシステムにおけるアカウント抽象化のローカル最適解
上記の質問で述べたように、過去のスマートウォレットは上記の機能を実現できますが、実装方法は一般的に大まかであり、多くの場合、高度に集中化されたサードパーティの機能に依存しています。 たとえば、以前は、ガス支払いスキームはサードパーティのリレイヤーノード(EIP-2771)を導入することでした。 さらに、異なるスマートウォレット間の統一された標準の欠如は、サポートコンポーネントの開発と展開を助長しません。 **
さまざまなアカウントの抽象化に関連するEIPの中心的な魅力は、スマートコントラクトウォレット用に設計された標準化されたフレームワークを通じて、さまざまなウォレットプロジェクトでこれらの欠陥を解決し、イーサリアムエコシステムのアカウント構造を基本的な機能構造からより高い天井を持つインテリジェント構造に促進することです。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
たとえば、ERC-20やERC-721が登場する前は、外部から提供される多くのトークン実装、関数、関数/インターフェースに一貫性がなく、「不整合」はサードパーティの機能やコード監査をサポートする開発に役立ちませんでした(ERC-20プロトコルがなければ、Defiアプリケーションがどのように現在の繁栄に発展したか想像するのは難しいです)。
標準化されたプロトコル/機能の実装標準はモジュラーナラティブの前提条件であり、モジュラー開発はほぼすべての分野が繁栄するための前提条件です(分業は効率の最初の原則です)。 **
結局、EIP-4337が前面に出ました。
EIP-4337は局所的な最適解ですが、フレームワーク内には最適化が必要な角度がいくつかあります
EIP-4337は一連のインターフェース標準を定義し、少なくとも4337プロトコルに従うスマートウォレットに必要なモジュール、各モジュールが実装すべき機能/インターフェース(バンドラー、エントリーポイント、ペイマスターなど)、およびどの呼び出し可能な機能を外部に提供する必要があるかを明確にしています。
これらのルールを明確にした後、異なるコンポーネント間の相互作用がより明確になり、アカウントの抽象化とスマートウォレットの設計にモジュラー設計のアイデアを導入するのに便利であり、ウォレットモジュールの開発者も大きなメリットを得ます。 **
もちろん、純粋にユーザーの観点からは、モジュラースマートウォレット開発パラダイムによってもたらされる価値は、短期的にはアカウントの抽象ウォレット自体に大きな変化を感じないため、明確ではありません。 **しかし、中長期的には、EIP-4337などのプロトコルは、アカウント抽象ウォレットの長期的な開発の基礎を築くERC-20やERC-721と価値が似ており、画期的なマイルストーンです。
ただし、EIP-4337にはまだ多くの未解決の問題があります:**例:
1.アカウント抽象化の機能は十分にプラグインされておらず、さまざまな開発者が車輪を再発明するのは簡単です。
2.アカウントモジュールの互換性は低く、アカウントシステム全体がエコロジーの断片化の傾向を示しています。
3.異なるチェーン間のアカウント抽象化エコロジーは非常に断片化されているため、エンドユーザーと開発者に統一された高品質のエクスペリエンスを提供し、より良いUXを実現することは困難です。
以下では、これらの問題の解決策を探ります。
最適化方向1:アカウント抽象化のプラグイン機能が基本設定になります
**現在、アカウント抽象化に関連する中心的な議論のポイントの1つは、アカウント抽象ウォレットのモジュール性をよりよく実現し、各モジュールの粒度をより細かくカットする方法であると言えます。 **
たとえば、Biconomyは、アカウント抽象化エコロジーのモジュラー開発をさらに促進するために、EIP-4337(より細かい粒度のEIP-6900が将来導入される)に基づく物語を提案しています。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
いわゆるアカウント抽象化関数プラグインは、実際には、スマートコントラクトウォレットに含まれる主要なモジュール、これらのモジュールが実装すべきインターフェイス/関数、およびこれらのインターフェイスの名前と呼び出し方法を明確にするためのものです。 その後、サードパーティの開発者は、独自のアイデアに従ってさまざまな詳細を持つコンポーネントを開発しますが、これらのコンポーネントは契約に定められた要件を満たします。
EIP-4337をプロトコルバックボーンとするBiconomyのV2バージョンは、より詳細な標準を開発し、4337で言及されていない多くのインターフェイスを追加しました。 Biconomyは、バンドラー、スマートコントラクトウォレット、Paymasterなどのモジュールが持つべき機能を述べながら、Biconomyによって事前に述べられたプロトコルの詳細に従う限り、サードパーティの開発者が同じ特性と異なるバージョンを持つモジュールを異なるコード詳細で実装できるようにします(EIP-4337と互換性があります)。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
同時に、Biconomyは「モジュールストア」のスローガンを提唱し、アカウント抽象モジュールSDKを個人的に立ち上げながら、開発者の大多数は、独自に設計されたアカウント抽象モジュールを提出し、「サービスとしてのモジュール」を展開し、**EIP-4337プロトコルに従うすべてのウォレットプロジェクトが部外者によって書かれたこれらのアカウント抽象モジュールを直接採用できるようにすることをお勧めします。 ユーザがフロントエンドページからスマートアカウントを作成すると、使用するモジュールをより多様に選択できます。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
モジュール性は分業に便利ですが、ユーザーがスマートウォレットの特定の機能をすばやく切り替えたり、追加および削除したりすることも便利です(率直に言って、粒度をより細かく分割することです)。
Biconomyは、スマートコントラクトウォレットがモジュール化されているほど、更新またはアップグレード時に行う必要のある変更が少なくなり(ユーザーの既存のスマートコントラクトウォレットコントラクトを更新したり、DelegateCallを使用したりする必要はなく、一部の外部モジュールのみ)、さまざまなユーザーや開発者が特定のコンポーネントを簡単に交換できるようになると指摘しました。
Biconomyの将来の新しいアカウントの抽象化では、EIP-6900よりもモジュール化されたEIP-4337の提案も参照します。
最適化の方向2:アカウントの断片化の問題を解決するためのよりきめ細かなモジュールセグメンテーション
EIP-6900の提案に関して、**Safe(旧Gnosis Safe)は、今年8月に関連するSafe Core Protocolホワイトペーパーを実際に発表し、最も借用されたものはEIP-6900です。 **
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
**EIP-6900は、モジュラーアカウントの現在の抽象化に関する1つの問題は、アカウントの「断片化」、またはサイロの問題であると指摘しています。 たとえば、さまざまなアカウント抽象化モジュールベンダーまたはさまざまなDAPPアプリケーションがEIP-4337と互換性がありますが、EIP-4337はモジュールごとに十分な高さではなく、粒度は比較的粗く、スマートアカウントモジュール開発者には「高すぎる」自由度が残ります(スマートアカウントは、ユーザー情報を保存し、カスタムトランザクション検証とガス支払いロジックを記録する中核部分です)。
このように、さまざまなウォレットプロジェクト関係者が、独自のプロパティを持つスマートアカウントモジュールを設計する傾向があります。 **長期的には、他のアカウント抽象化モジュールサプライヤは、互換性のあるスマートアカウントモジュールを誰が提供するかを優先し、固定の上流および下流のサプライチェーンをゆっくりと生成する必要があり、必然的にアカウント抽象化モジュールのエコロジーの断片化と分離につながります。 **(これは、コンピューター業界の初期の頃のように、オペレーティングシステム開発者は、どのコンピューターハードウェアメーカーと互換性があるかを検討しなければなりませんでした。
生態学的断片化の問題を解決し、さまざまなベンダーによって開発されたアカウント抽象化モジュールの互換性を向上させるには、スマートコントラクトウォレットアカウントをさらに抽象化し、モジュールをより細かくするのが最善の方法です。
EIP-6900のアイデアを借用した後、**セーフコアプロトコルホワイトペーパーは、スマートアカウント(ユーザーのスマートウォレットアカウント)のより詳細な最適化を行いました。 Safe Coreプロトコルは、各スマートウォレットアカウントから呼び出すことができるモジュールをプラグイン、フック、署名検証機、関数プロセッサ、およびその他のカテゴリに分割します。 **
スマートアカウントモジュールは可能な限り軽量で、アカウントコントラクトは最も基本的なデータと機能のみを保存し、外部に移動できる機能はすべて「関数プロセッサ」または「プラグイン」サブディビジョンモジュールにスローされて実装されます。 これは、いわゆるオッカムのかみそりの原則である「必要な場合を除いてエンティティを追加しない」を反映しています。
スマートアカウント自体が十分に軽量で、面倒な詳細が含まれていない場合、さまざまなメーカーによって開発されたスマートアカウントは内部構造が近く、互換性が高くなります。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
Safe Coreプロトコルでは、iPhoneのアプリストアと同様に、承認されたすべての利用可能なモジュールを含むレジストリも導入されています。 ユーザーはアクティブ化するモジュールを選択でき、新しいモジュールがアクティブ化されるたびに、Minger コントラクトを通じて処理されます。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
一般に、UserOperationは最初にプラグインプラグインをトリガーし、次にMangerコントラクトはプラグインのステータスが正常かどうか(レジストリにレコードがある)をチェックし、正常であればプラグインのリクエストを許可します。 必要に応じて、プラグインプラグインはフックによって提供される機能の一部を呼び出すかどうか。 その後、UserOperation に関連するスマートアカウントの状態が変更されます。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
上記のきめ細かなモジュールシャーディング方法とスケジューリングプロセスを通じて、Safe Core Protocolは、さまざまなベンダーによって改善されたスマートアカウントモジュールの互換性を向上させるために、スマートアカウントをEOAアカウントと同じくらい簡単にすることを目的とした一連のオープンソースアカウント抽象モジュール相互運用性プロトコルの実装を試みます。
最適化の方向性3:異なるチェーンで統一されたアカウントを実現するためのフルチェーンアカウントの抽象化
しかし、前述のソリューションを使用しても、解決されていない大きな問題がまだあります:異なるチェーンと異なるLayer2は、異なる詳細でアカウントの抽象化を促進しており、多くはeIP-4337と競合するフォームを使用しています(zkSync Era、Starknet、Flowなど)。 これにより、Starknet上のユーザーのスマートウォレットアドレスとArbitrum上のスマートウォレットアドレスがまったく統一できないなど、ウォレットのUXが断片化しています。
さらに、マルチチェーン環境では、ユーザーは異なるチェーンにスマートアカウントを個別に展開しており、対応するユーザーデータがこれらの契約に散在していることがよくあります。 キーなどのユーザデータを更新する必要がある場合、複数のチェーンでトランザクションを繰り返し開始する必要があり、スマートアカウントの一貫性を確保することは困難です。
ヴィタリック自身は以前、フルチェーンの統合された管理しやすいスマートアカウントスキームのセットを提案しており、**このスキームはイーサリアムまたは安全性の高いZKRollupをソースチェーンとして使用し、キーストアコントラクトを展開し、ユーザーのグローバルキーを保存し、L2上のすべてのユーザーのスマートコントラクトアカウントは、キーストアコントラクトに保存されているグローバルキーを共有します。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
ただし、このソリューションは非常に高価であり、ソースチェーンのキーストアコントラクトに記録されたグローバルキーが変更されるたびに、L2/ターゲットチェーンの各アカウントは、チェーン間の相互作用を通じて新しいキーを同期する必要があります。 イーサリアムとL2の間のクロスチェーンインタラクションは、ユーザーが余裕があるには高すぎます。 また、スマートコントラクトアカウントは、独自のアドレス生成方法のために本質的にマルチチェーン統合(EVMチェーン間で統一)されているEOAアカウントとは異なりますが、スマートコントラクトアカウントは完全に異なり、ユーザーが異なるチェーンで同じアドレスのスマートコントラクトアカウントを取得することは困難です。
パーティクルネットワークは、これに対する独自のアプローチを考え出しました。 一般的な考え方は、スマートアカウントのストレージとコードを分離するというVitalikの考え方と同じですが、パーティクルネットワークは、サードパーティのクロスチェーンメッセージングソリューション(LayerZero、CCIP、Axelar、Connext)を通じて、スマートアカウントのフルチェーンストレージデータベースとして独立したチェーンであるパーティクルネットワークチェーンを使用する予定です。 など)アカウントストレージに対するユーザーの変更を、他のチェーンのローカルアカウントに同期します。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
(パーティクルネットワークのマルチチェーンアカウント抽象化)
具体的には、Particle Networkのフルチェーンアカウント抽象化システムでは、ユーザーは異なるEVMチェーンに統一されたスマートコントラクトアカウントアドレスを持つ必要があり、異なるチェーンに一連のデプロイヤーコントラクトを展開する必要があります。
ユーザーはパーティクルネットワークチェーンで新しいアカウントの生成をトリガーする必要があり、その後、パーティクルチェーンはすべてのチェーンでデプロイヤーコントラクトをトリガーし、異なるチェーンのユーザー用に生成されたスマートコントラクトアカウントアドレスが均一であることを確認するか、ユーザーは他のチェーンを意識することなくパーティクルチェーンのコントラクトを通じてマルチチェーンインタラクションプロセスを完了し、ユニファイドガスを使用できます 統一された料金支払い方法としてのトークン。
フルチェーンアカウントの抽象化により、クロスチェーンのユーザー操作も可能になり、ソースチェーンのユーザー操作と、ポリゴンのUSDCを使用してベースでNFTを購入するなど、対応するガス支払いを通じてターゲットチェーンのトランザクションがトリガーされます。
ただし、Particle Networkソリューションでは、マルチチェーンのアカウントとソースチェーンストレージの同期を実現するために、Deployerコントラクトとクロスチェーンメッセージングコンポーネント間の高度なコラボレーションが必要であり、実際には使用するオラクルまたはクロスチェーンメッセージブリッジに高い要件があります(この問題は、フルチェーンの相互運用性に関連するすべてのスキームに存在するようです)。
ただし、ユーザーのクロスチェーンアカウント同期は、2/3として構成できる戦略など、特定のブリッジのみに依存するのではなく、異なるメッセージブリッジの組み合わせを柔軟に構成でき、LayerZero、Axelar、およびConnextのいずれか2つの確認に依存してターゲットチェーン上のストレージの変更を確認し、この単一ポイントの依存関係の問題をほぼ解決できます。
EVMと非EVM間のフルチェーンのシームレスな相互運用性は、イーサリアムエコシステム内のフルチェーンアカウントの抽象化における一歩です
EVMチェーン全体にキー管理と統合アカウントがありますが、フルチェーンアカウントの抽象化にはまだ最適化の余地があります:Aptos、Solana、SuiなどのEVMと互換性のないチェーンは、ユーザーが生成したスマートコントラクトアカウントアドレスがEVMチェーンと一致していることを保証できません。 同時に、非EVMチェーンが同等のスキームでEIP-4337プロトコルを実装していない場合、上記のVitalikとParticle Networkによって提案されたフルチェーンアカウントの抽象的な概念に従うことは困難です。
さらに、EIP-4337互換のウォレットプロジェクト自体にも改善の余地があります。 スマートウォレットで使用されるバンドラーノードのほとんどは、公式には独立して実行され、相互に通信することすらなく、多くのスマートウォレットプロジェクトは実際には独自のチェーンを形成しており、多くのリスク(検閲耐性、ユーザビリティ)をもたらします。 ほとんどのチェーンで統一された単一のフロントエンドインターフェイスを構築することは非常に困難です。 1つの解決策は、インテント中心の設計を導入し、フルチェーンのアカウント抽象化の上にレイヤーを追加し、イーサリアムのEIP-4337エコシステムまたは他のチェーンのネイティブアカウント抽象化機能(zkSyncなど)をソルバー/リアクタータイプの特定のインスタンスとして扱うことです。 **
パーティクルネットワークを例にとると、簡潔な抽象化インテントの実装を提案しますが、さまざまなアカウントの抽象化は、ソルバーに含まれるインテントソリューションのインスタンスのクラスにすぎません。
まず、ユーザーフロントエンドは、自然言語リクエストまたは任意のユーザーインタラクションを、入力制約や出力制約(率直に言って、ユーザーの要件を満たす入力条件と出力結果間隔)を含む特定のプログラム記述に変換する責任があり、次にソルバーネットワーク内の1つ以上のソルバーにトランザクションの特定の入力および出力制約が含まれます。 オンチェーンでデプロイされたソルバーコントラクトに転送(ソルバーにはノード機能だけでなく、オンチェーンコントラクトパーツもあります)。 ソルバーコントラクトは、インテント命令をリアクタコントラクト(チェーン上のユーザーのアカウントを管理する)に送信し、リアクタコントラクトは他のモジュールを呼び出して最終的な相互作用を完了します。
ユーザーの要求は最初にソルバーネットワークによって認識されるため、ユーザーは基礎となるチェーンやさまざまなアカウント抽象化の構築を認識する必要がなく、この部分は特定のソリューションを構築するためにソルバーに任されます。
もちろん、これらのアイデアはまだ理論的な枠組みに過ぎず、その背後にある実装の詳細はまだパーティクルネットワークによって公式に説明されていません。
現在、競争の激しいソルバー市場が将来生まれることは明らかであり、ユーザーはオークションを開始して複数のソルバーが異なるソリューションを考え出すことができ、ローカルシミュレーション取引の形式を通じて、最適なソリューションを選択し、対応するソルバーにインセンティブを与えることができます。 インセンティブの形式は、ソルバーネットワークのプロトコル設計者によって異なります(パーティクルネットワークは、ソルバーオークション市場のインセンティブトークンとしてPNTトークンを使用する予定です)。
現在の意図は、基本的に下位層の複雑な詳細をシールドし、上位層に抽象化します TCP/IPプロトコルの性質を持つこのような階層化された設計は、チェーン全体のシームレスな相互運用性の下でのユーザーエクスペリエンスと開発者エクスペリエンスに必要です。
アカウント抽象化の大量採用を受け入れる
イーサリアムエコシステムの4337フレームワークをあらゆる角度から最適化し、イーサリアムエコシステムと非イーサリアムエコシステム間のシームレスな相互運用性を促進する場合、アカウント抽象化の大規模な採用をサポートするために、供給側と需要側にまたがる製品がまだ必要であると感じています。 エンドユーザーによるさまざまなWeb3製品やサービスの使用を減らすと同時に、サービス開発者に焦点を当て、開発者のしきい値を下げることができます。 **
この役割に最適な製品の1つは、パーティクルネットワークのモジュラースマートサービスとしてのウォレット製品です。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
*このサービスは、開発者がモジュラーアカウント抽象化機能をアプリケーションに簡単に統合できるようにする使いやすいAPIセットを提供します。 *開発者はこのサービスを使用して、フルチェーンアカウントの作成と管理、クロスチェーンインタラクションの実行、および統一された料金支払い方法の使用を行うことができます。 このようなサービスは、マルチチェーンアプリケーションを構築し、アカウント抽象化の広範な採用を促進するためのより柔軟で便利な方法を開発者に提供します。
上記の開発者向けの機能に加えて、最も重要な機能は、Particle Networkのモジュラースマートサービスとしてのウォレット**製品が、シグネチャコンピューティングに基づくオープンエコロジーを構築し、開発者のアカウント抽象化分野に向けられていることです。 アカウント抽象化分野全体で、さまざまな開発者の製品やサービスの採用を迅速に促進できます。
! フルチェーンアカウントの抽象化がEIP-4337のパズルの最後のピースであるのはなぜですか?
ERC-4337フレームワークのあらゆる角度の限界を解決した後、テクノロジーが需要に応えられるようにし、開発者エクスペリエンスの向上により、優れたユーザーエクスペリエンスを備えたより多くの製品が促進され、Web3業界がクリプトパンクに優しい金融業界から大衆に優しい消費者業界に加速します。