著者: Rui S、SevenX Ventures、編集者: Deep Wave TechFlow
＃＃＃ 導入
外部所有アカウント (EOA) からスマート コントラクト アカウント (SCA) への移行は急速に進んでおり、Vitalik 氏自身を含む多くの愛好家によって支持されています。盛り上がりにもかかわらず、SCA の採用は EOA ほど普及していません。主要な問題には、弱気市場の課題、移行の懸念、署名の問題、ガスのオーバーヘッド、そして最も重要なエンジニアリングの課題が含まれます。
アカウント抽象化 (AA) の最も重要な利点の 1 つは、コードを使用して機能をカスタマイズできることです。ただし、エンジニアリング上の主要な課題は、AA 機能の相互運用性の非相互運用性であり、この断片化により統合が妨げられ、ベンダー ロックインへの扉が開かれます。さらに、機能のアップグレードと結合を同時に行う際のセキュリティの確保は複雑になる場合があります。
モジュラー アカウントの抽象化は、より広範な AA 運動のサブセットとして登場し、スマート アカウントをカスタム機能から切り離す革新的なアプローチです。目標は、モジュール構造を作成して、多様な機能を備えた安全でシームレスに統合されたウォレットを開発することです。将来的には、無料のスマート コントラクト アカウント「アプリ ストア」を実装して、ウォレットと dApp が機能の構築に焦点を当てるのではなく、ユーザー エクスペリエンスに焦点を当てることができるようになります。
従来の EOA では、シード フレーズ、ガス、クロスチェーン、複数のトランザクションなど、多くの課題が発生します。私たちは複雑さを導入するつもりはありませんでしたが、現実にはブロックチェーンは大衆にとって簡単なゲームではありません。
アカウントの抽象化はスマート コントラクト アカウントを活用し、プログラム可能な検証と実行を可能にし、ユーザーが各トランザクションに署名してブロードキャストするのではなく、一連のトランザクションを一度に承認できるようにし、より多くの機能を有効にします。これは、ユーザー エクスペリエンス (ガス抽象化やセッション キーなど)、コスト (バッチ処理されたトランザクションなど)、セキュリティ (ソーシャル リカバリ、マルチ署名など) にメリットをもたらします。現在、アカウントの抽象化を実装するには 2 つの方法があります。
アカウント抽象化 (AA) のテーマは 2015 年から議論されており、今年 ERC 4337 によって注目を集めました。ただし、導入されているスマート コントラクト アカウントの数は、EOA よりもはるかに少ないです。
このジレンマをさらに深く掘り下げてみましょう。
*弱気市場の影響:
AA はシームレスなログインやガスの抽象化などの利点を導入しましたが、現在弱気市場を経験している人々は主に新規ユーザーではなく教育を受けた EOA ユーザーで構成されているため、dApps やウォレットに対するインセンティブはありません。それでも、一部の主要アプリケーションは徐々に AA を採用しており、たとえば Cyberconnect は、AA システムとガスフリー ソリューションの導入により、わずか 1 か月で約 360,000 の UserOps (AA トランザクション) を推進しました。
ユーザーや資産が蓄積されているウォレットやアプリケーションにとって、資産を安全かつ便利に移行することは依然として課題です。ただし、EIP-7377 のような取り組みにより、EOA は 1 回限りの移行トランザクションを開始できます。
*署名の問題:
スマート コントラクト自体は、EOA のような秘密キーを持たないため、当然のことながらメッセージに署名できません。 ERC 1271のような取り組みにより、このような署名が可能になりますが、メッセージ署名は最初のトランザクションまで機能しないため、反事実的な展開を使用するウォレットにとっては課題となります。 Ambire によって提案された ERC-6492 は、ERC-1271 の下位互換性のある後継であり、以前の問題を解決する可能性があります。
*ガスオーバーヘッド:
SCA の展開、シミュレーション、実行には、標準の EOA よりも高いコストがかかります。これが採用の障壁になります。ただし、これらのコストを削減するために、アカウントの作成をユーザーのアクションから切り離したり、アカウントのソルトや存在チェックの排除を検討したりするなど、いくつかのテストが行われてきました。
ERC-4337 チームは、開発者に基本的な実装を提供するために eth-infinitiism リポジトリを確立しました。ただし、さまざまなユースケースでより詳細な機能や特定の機能に分岐すると、統合とデコードが困難になります。
この記事では、5 番目の問題であるエンジニアリング上の課題を詳しく掘り下げていきます。
エンジニアリング上の課題についてさらに詳しく説明すると、次のとおりです。
これらの問題に対処するには、安全かつ効率的なアップグレードを保証するためのアップグレード可能なコントラクト、全体的な開発効率を向上させるための再利用可能なコア、およびコントラクト アカウントが異なるフロントエンド間でスムーズに移行できるようにするための標準化されたインターフェイスが必要です。
これらの用語は、モジュラー アカウント抽象化アーキテクチャ (モジュラー AA) の構築という共通の概念に収束します。
モジュラー AA は、スマート アカウントをモジュール化してサービスをユーザーに合わせて調整し、開発者が最小限の制限でシームレスに機能を強化できるようにすることを想定した、広範な AA 運動のニッチな分野です。
ただし、新しい標準を確立して推進することは、どの業界でも大きな課題です。誰もが主要な解決策を受け入れる前の初期段階で、多くの異なる解決策が現れる可能性があります。ただし、4337 SDK、ウォレット開発者、インフラストラクチャ チーム、プロトコル設計者の両方がこのプロセスをスピードアップするために協力していることは心強いです。
外部呼び出しと代理呼び出し:
delegatecall は call に似ていますが、独自のコンテキストでターゲット コントラクトを実行するのではなく、呼び出し側コントラクトの現在の状態でターゲット コントラクトを実行します。これは、ターゲット コントラクトによって行われたすべての状態変更が、呼び出し側コントラクトのストレージに適用されることを意味します。
構成可能でアップグレード可能な構造を実装するには、「代理店契約」と呼ばれる基本的な知識が必要です。
Safe は、実績のあるセキュリティと柔軟性を提供するように設計された主要なモジュール式スマート アカウント インフラストラクチャであり、開発者が多様なアプリケーションとウォレットを作成できるようにします。多くのチームが Safe に基づいて構築している、または Safe に触発されて構築していることは注目に値します。 Biconomy は、Safe 上のネイティブ 4337 と 1/1 マルチ署名を拡張してアカウントを開始します。 164,000 以上の契約が展開され、307 億ドル以上の価値が確保されている Safe は、間違いなくこの分野での最大の選択肢です。
※セーフアカウント契約：メインエージェント契約（ステートフル）
Safe アカウントはシングルトン コントラクトを委任呼び出しするため、プロキシ コントラクトです。 Safe アカウントには、所有者、しきい値、および実装アドレスが含まれており、これらはエージェントの変数として設定され、エージェントの状態を定義します。
※シングルトン契約：インテグレーションセンター（ステートレス）
シングルトンは Safe アカウントを提供し、プラグイン、フック、関数ハンドラー、署名バリデータなどのさまざまな統合を統合および定義します。
モジュールは非常に強力です。モジュール型のプラグインは、支払いフロー、回復メカニズム、セッション キーなどのさまざまな機能を定義でき、オフチェーン データを取得することで Web2 と Web3 間のクロスチェーン ブリッジとして機能します。フックなどの他のモジュールは安全装置として機能し、関数ハンドラーはあらゆる命令に応答します。
新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要があります。ユーザーは、好みや要件に合わせて Safe を希望のシングルトン バージョンにアップグレードする自主性を保持します。
プラグインのモジュール性により、開発者は機能を独立して構築できます。その後、独自のユースケースに応じてこれらのプラグインを自由に選択して組み合わせることができるため、高度にカスタマイズ可能なアプローチが容易になります。
ERC 2535 は、導入後にアップグレード/拡張でき、事実上サイズ制限のないモジュール式スマート コントラクト システムである Diamond Agent を標準化します。これまでに、Zerodev のカーネルや Soul Wallet の実験など、多くのチームがそれにインスピレーションを受けてきました。
Safe アーキテクチャと Diamond アーキテクチャには多くの類似点があり、どちらもコアとしてプロキシ コントラクトに依存し、アップグレード可能性とモジュール性のためにロジック コントラクトを参照しています。
ただし、主な違いは論理契約の処理にあります。詳しい手順は次のとおりです。
「安全なスマート アカウント方式」と「ダイヤモンド方式」は、エージェントとモジュールが関与するさまざまな構造の例です。柔軟性とセキュリティのバランスをどのように取るかが重要であり、2 つのアプローチは将来的に相互補完する可能性があります。
Alchemy チームによって提案された標準、ERC 6900 を紹介して議論を広げましょう。この標準は、Diamond からインスピレーションを得て、特に ERC-4337 に適合させたものです。共通のインターフェイスを提供し、プラグインとウォレットの開発者間の作業を調整することで、スマート アカウントのモジュール性の課題を解決します。
AA のトランザクション プロセスには、検証、実行、フックという 3 つの主要なプロセスがあります。前に説明したように、これらの手順は、プロキシ アカウントを使用してモジュールを呼び出すことで管理できます。プロジェクトごとに異なる名前が使用される場合がありますが、同様の基礎となるロジックを把握することが重要です。
異なるロジックに基づいてモジュールを分離することが重要です。標準化されたアプローチでは、スマート コントラクトのアカウント検証、実行、およびフック関数をどのように記述するかを指定する必要があります。 Safe であろうと ERC 6900 であろうと、標準化は特定の実装やエコシステムに対する独自の開発作業の必要性を減らし、ベンダー ロックインを防ぐのに役立ちます。
ブームになっているソリューションの 1 つは、ユーザーが検証可能なモジュールを発見できる場所、いわゆる「レジストリ」を作成することです。このレジストリは、簡素化されながらも繁栄するモジュラー マーケットプレイスを促進するために設計された「アプリ ストア」に似ています。
Safe{Core} プロトコルは、強力なセキュリティを維持しながら、明確に定義された標準とルールを通じてさまざまなベンダーや開発者のアクセシビリティを高めるように設計された、オープンソースの相互運用可能なスマート コントラクト アカウント プロトコルです。
プロセスは次のように展開されます。
このモデルはまだ初期段階にありますが、分散型かつ協力的な方法で標準を確立する可能性があります。レジストリを使用すると、開発者はモジュールを登録でき、監査人はセキュリティを検証でき、ウォレットを統合でき、ユーザーは簡単にモジュールを見つけて認証情報を検証できます。将来的には以下のような用途が考えられます。
「モジュール レジストリ」の概念は、プラグインおよびモジュールの開発者に有益な機会を提供します。 「モジュール市場」への道を開く可能性もある。これらの側面の一部は Safe チームによって監督される可能性がありますが、その他の側面は、誰もが貢献して透明性のある監査証跡を提供する分散型マーケットプレイスとして現れる可能性があります。このアプローチを採用することで、ベンダー ロックインを回避し、より幅広いユーザーにアピールする優れたユーザー エクスペリエンスを提供することで EVM の拡張をサポートできます。
これらの方法は個々のモジュールのセキュリティを保証しますが、スマート コントラクト アカウントの全体的なセキュリティは完全に信頼できるわけではありません。正規のモジュールを結合し、ストレージの競合がないことを証明することは困難な場合があり、そのような問題を解決するにはウォレットや AA インフラストラクチャの重要性が強調されます。
モジュール式のスマート コントラクト アカウント スタックを活用することで、ウォレット プロバイダーと dApp は技術的なメンテナンスの複雑さを回避できます。同時に、外部モジュール開発者は、個々のニーズに合わせた専門的なサービスを提供する機会を得られます。ただし、対処する必要がある課題には、柔軟性とセキュリティのバランスをとること、モジュール標準の進歩を推進すること、ユーザーがスマート アカウントを簡単にアップグレードおよび変更できるようにする標準化されたインターフェイスの実装などが含まれます。
ただし、モジュラー スマート コントラクト アカウント (SCA) は、導入パズルの 1 ピースにすぎません。 SCA の可能性を最大限に発揮するには、強力なバンドラー インフラストラクチャとピアツーピア メモリ プール、よりコスト効率が高く実現可能な SCA 署名メカニズム、クロスチェーン SCA 同期に加えて、第 2 層ソリューションからのプロトコル層サポートも必要です。ユーザーフレンドリーなインターフェイスの開発だけでなく、管理も行います。
私たちは幅広い参加者が参加する未来を構想していますが、これによりいくつかの興味深い疑問が生じます。SCA 注文プロセスが十分な収益を上げられるようになったら、従来のマイナー抽出可能価値 (MEV) メカニズムがどのようにこの領域に参入し、バンドラーを構築し、価値を獲得するのでしょうか?インフラストラクチャが成熟すると、アカウント抽象化 (AA) はどのようにして「インテントベース」トランザクションのベースレイヤーになるのでしょうか?この分野は常に進化しているので、ご期待ください。
13.3K 人気度
29.7K 人気度
32.1K 人気度
270.6K 人気度
178 人気度
モジュール式スマート コントラクト アカウント設計に関する詳細なディスカッション: 実装における技術的問題の解決
著者: Rui S、SevenX Ventures、編集者: Deep Wave TechFlow
＃＃＃ 導入
外部所有アカウント (EOA) からスマート コントラクト アカウント (SCA) への移行は急速に進んでおり、Vitalik 氏自身を含む多くの愛好家によって支持されています。盛り上がりにもかかわらず、SCA の採用は EOA ほど普及していません。主要な問題には、弱気市場の課題、移行の懸念、署名の問題、ガスのオーバーヘッド、そして最も重要なエンジニアリングの課題が含まれます。
アカウント抽象化 (AA) の最も重要な利点の 1 つは、コードを使用して機能をカスタマイズできることです。ただし、エンジニアリング上の主要な課題は、AA 機能の相互運用性の非相互運用性であり、この断片化により統合が妨げられ、ベンダー ロックインへの扉が開かれます。さらに、機能のアップグレードと結合を同時に行う際のセキュリティの確保は複雑になる場合があります。
モジュラー アカウントの抽象化は、より広範な AA 運動のサブセットとして登場し、スマート アカウントをカスタム機能から切り離す革新的なアプローチです。目標は、モジュール構造を作成して、多様な機能を備えた安全でシームレスに統合されたウォレットを開発することです。将来的には、無料のスマート コントラクト アカウント「アプリ ストア」を実装して、ウォレットと dApp が機能の構築に焦点を当てるのではなく、ユーザー エクスペリエンスに焦点を当てることができるようになります。
AA の簡単な説明
従来の EOA では、シード フレーズ、ガス、クロスチェーン、複数のトランザクションなど、多くの課題が発生します。私たちは複雑さを導入するつもりはありませんでしたが、現実にはブロックチェーンは大衆にとって簡単なゲームではありません。
アカウントの抽象化はスマート コントラクト アカウントを活用し、プログラム可能な検証と実行を可能にし、ユーザーが各トランザクションに署名してブロードキャストするのではなく、一連のトランザクションを一度に承認できるようにし、より多くの機能を有効にします。これは、ユーザー エクスペリエンス (ガス抽象化やセッション キーなど)、コスト (バッチ処理されたトランザクションなど)、セキュリティ (ソーシャル リカバリ、マルチ署名など) にメリットをもたらします。現在、アカウントの抽象化を実装するには 2 つの方法があります。
SCA 導入のジレンマ
アカウント抽象化 (AA) のテーマは 2015 年から議論されており、今年 ERC 4337 によって注目を集めました。ただし、導入されているスマート コントラクト アカウントの数は、EOA よりもはるかに少ないです。
このジレンマをさらに深く掘り下げてみましょう。
*弱気市場の影響:
AA はシームレスなログインやガスの抽象化などの利点を導入しましたが、現在弱気市場を経験している人々は主に新規ユーザーではなく教育を受けた EOA ユーザーで構成されているため、dApps やウォレットに対するインセンティブはありません。それでも、一部の主要アプリケーションは徐々に AA を採用しており、たとえば Cyberconnect は、AA システムとガスフリー ソリューションの導入により、わずか 1 か月で約 360,000 の UserOps (AA トランザクション) を推進しました。
ユーザーや資産が蓄積されているウォレットやアプリケーションにとって、資産を安全かつ便利に移行することは依然として課題です。ただし、EIP-7377 のような取り組みにより、EOA は 1 回限りの移行トランザクションを開始できます。
*署名の問題:
スマート コントラクト自体は、EOA のような秘密キーを持たないため、当然のことながらメッセージに署名できません。 ERC 1271のような取り組みにより、このような署名が可能になりますが、メッセージ署名は最初のトランザクションまで機能しないため、反事実的な展開を使用するウォレットにとっては課題となります。 Ambire によって提案された ERC-6492 は、ERC-1271 の下位互換性のある後継であり、以前の問題を解決する可能性があります。
*ガスオーバーヘッド:
SCA の展開、シミュレーション、実行には、標準の EOA よりも高いコストがかかります。これが採用の障壁になります。ただし、これらのコストを削減するために、アカウントの作成をユーザーのアクションから切り離したり、アカウントのソルトや存在チェックの排除を検討したりするなど、いくつかのテストが行われてきました。
ERC-4337 チームは、開発者に基本的な実装を提供するために eth-infinitiism リポジトリを確立しました。ただし、さまざまなユースケースでより詳細な機能や特定の機能に分岐すると、統合とデコードが困難になります。
この記事では、5 番目の問題であるエンジニアリング上の課題を詳しく掘り下げていきます。
エンジニアリング上の問題を解決するモジュール式スマート コントラクト アカウント
エンジニアリング上の課題についてさらに詳しく説明すると、次のとおりです。
これらの問題に対処するには、安全かつ効率的なアップグレードを保証するためのアップグレード可能なコントラクト、全体的な開発効率を向上させるための再利用可能なコア、およびコントラクト アカウントが異なるフロントエンド間でスムーズに移行できるようにするための標準化されたインターフェイスが必要です。
これらの用語は、モジュラー アカウント抽象化アーキテクチャ (モジュラー AA) の構築という共通の概念に収束します。
モジュラー AA は、スマート アカウントをモジュール化してサービスをユーザーに合わせて調整し、開発者が最小限の制限でシームレスに機能を強化できるようにすることを想定した、広範な AA 運動のニッチな分野です。
ただし、新しい標準を確立して推進することは、どの業界でも大きな課題です。誰もが主要な解決策を受け入れる前の初期段階で、多くの異なる解決策が現れる可能性があります。ただし、4337 SDK、ウォレット開発者、インフラストラクチャ チーム、プロトコル設計者の両方がこのプロセスをスピードアップするために協力していることは心強いです。
モジュール構造: メインアカウントとモジュール
代理通話と代理契約
外部呼び出しと代理呼び出し:
delegatecall は call に似ていますが、独自のコンテキストでターゲット コントラクトを実行するのではなく、呼び出し側コントラクトの現在の状態でターゲット コントラクトを実行します。これは、ターゲット コントラクトによって行われたすべての状態変更が、呼び出し側コントラクトのストレージに適用されることを意味します。
構成可能でアップグレード可能な構造を実装するには、「代理店契約」と呼ばれる基本的な知識が必要です。
セキュリティアーキテクチャ
Safe は、実績のあるセキュリティと柔軟性を提供するように設計された主要なモジュール式スマート アカウント インフラストラクチャであり、開発者が多様なアプリケーションとウォレットを作成できるようにします。多くのチームが Safe に基づいて構築している、または Safe に触発されて構築していることは注目に値します。 Biconomy は、Safe 上のネイティブ 4337 と 1/1 マルチ署名を拡張してアカウントを開始します。 164,000 以上の契約が展開され、307 億ドル以上の価値が確保されている Safe は、間違いなくこの分野での最大の選択肢です。
安全構造
※セーフアカウント契約：メインエージェント契約（ステートフル）
Safe アカウントはシングルトン コントラクトを委任呼び出しするため、プロキシ コントラクトです。 Safe アカウントには、所有者、しきい値、および実装アドレスが含まれており、これらはエージェントの変数として設定され、エージェントの状態を定義します。
※シングルトン契約：インテグレーションセンター（ステートレス）
シングルトンは Safe アカウントを提供し、プラグイン、フック、関数ハンドラー、署名バリデータなどのさまざまな統合を統合および定義します。
モジュールは非常に強力です。モジュール型のプラグインは、支払いフロー、回復メカニズム、セッション キーなどのさまざまな機能を定義でき、オフチェーン データを取得することで Web2 と Web3 間のクロスチェーン ブリッジとして機能します。フックなどの他のモジュールは安全装置として機能し、関数ハンドラーはあらゆる命令に応答します。
Safe を採用するとどうなるか
新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要があります。ユーザーは、好みや要件に合わせて Safe を希望のシングルトン バージョンにアップグレードする自主性を保持します。
プラグインのモジュール性により、開発者は機能を独立して構築できます。その後、独自のユースケースに応じてこれらのプラグインを自由に選択して組み合わせることができるため、高度にカスタマイズ可能なアプローチが容易になります。
ERC-2535 ダイヤモンドエージェント
ERC 2535 と Diamond Agent について
ERC 2535 は、導入後にアップグレード/拡張でき、事実上サイズ制限のないモジュール式スマート コントラクト システムである Diamond Agent を標準化します。これまでに、Zerodev のカーネルや Soul Wallet の実験など、多くのチームがそれにインスピレーションを受けてきました。
ダイヤモンドの構造は何ですか?
ダイヤモンドを使用するとどうなるか
安全なスマート アカウントとダイヤモンド方式の違い
Safe アーキテクチャと Diamond アーキテクチャには多くの類似点があり、どちらもコアとしてプロキシ コントラクトに依存し、アップグレード可能性とモジュール性のためにロジック コントラクトを参照しています。
ただし、主な違いは論理契約の処理にあります。詳しい手順は次のとおりです。
「安全なスマート アカウント方式」と「ダイヤモンド方式」は、エージェントとモジュールが関与するさまざまな構造の例です。柔軟性とセキュリティのバランスをどのように取るかが重要であり、2 つのアプローチは将来的に相互補完する可能性があります。
モジュールの順序: バリデータ、エグゼキュータ、フック
Alchemy チームによって提案された標準、ERC 6900 を紹介して議論を広げましょう。この標準は、Diamond からインスピレーションを得て、特に ERC-4337 に適合させたものです。共通のインターフェイスを提供し、プラグインとウォレットの開発者間の作業を調整することで、スマート アカウントのモジュール性の課題を解決します。
AA のトランザクション プロセスには、検証、実行、フックという 3 つの主要なプロセスがあります。前に説明したように、これらの手順は、プロキシ アカウントを使用してモジュールを呼び出すことで管理できます。プロジェクトごとに異なる名前が使用される場合がありますが、同様の基礎となるロジックを把握することが重要です。
異なるロジックに基づいてモジュールを分離することが重要です。標準化されたアプローチでは、スマート コントラクトのアカウント検証、実行、およびフック関数をどのように記述するかを指定する必要があります。 Safe であろうと ERC 6900 であろうと、標準化は特定の実装やエコシステムに対する独自の開発作業の必要性を減らし、ベンダー ロックインを防ぐのに役立ちます。
モジュールの検出とセキュリティ
ブームになっているソリューションの 1 つは、ユーザーが検証可能なモジュールを発見できる場所、いわゆる「レジストリ」を作成することです。このレジストリは、簡素化されながらも繁栄するモジュラー マーケットプレイスを促進するために設計された「アプリ ストア」に似ています。
安全な{コア}プロトコル
Safe{Core} プロトコルは、強力なセキュリティを維持しながら、明確に定義された標準とルールを通じてさまざまなベンダーや開発者のアクセシビリティを高めるように設計された、オープンソースの相互運用可能なスマート コントラクト アカウント プロトコルです。
ラインストーンのデザイン
プロセスは次のように展開されます。
このモデルはまだ初期段階にありますが、分散型かつ協力的な方法で標準を確立する可能性があります。レジストリを使用すると、開発者はモジュールを登録でき、監査人はセキュリティを検証でき、ウォレットを統合でき、ユーザーは簡単にモジュールを見つけて認証情報を検証できます。将来的には以下のような用途が考えられます。
「モジュール レジストリ」の概念は、プラグインおよびモジュールの開発者に有益な機会を提供します。 「モジュール市場」への道を開く可能性もある。これらの側面の一部は Safe チームによって監督される可能性がありますが、その他の側面は、誰もが貢献して透明性のある監査証跡を提供する分散型マーケットプレイスとして現れる可能性があります。このアプローチを採用することで、ベンダー ロックインを回避し、より幅広いユーザーにアピールする優れたユーザー エクスペリエンスを提供することで EVM の拡張をサポートできます。
これらの方法は個々のモジュールのセキュリティを保証しますが、スマート コントラクト アカウントの全体的なセキュリティは完全に信頼できるわけではありません。正規のモジュールを結合し、ストレージの競合がないことを証明することは困難な場合があり、そのような問題を解決するにはウォレットや AA インフラストラクチャの重要性が強調されます。
要約する
モジュール式のスマート コントラクト アカウント スタックを活用することで、ウォレット プロバイダーと dApp は技術的なメンテナンスの複雑さを回避できます。同時に、外部モジュール開発者は、個々のニーズに合わせた専門的なサービスを提供する機会を得られます。ただし、対処する必要がある課題には、柔軟性とセキュリティのバランスをとること、モジュール標準の進歩を推進すること、ユーザーがスマート アカウントを簡単にアップグレードおよび変更できるようにする標準化されたインターフェイスの実装などが含まれます。
ただし、モジュラー スマート コントラクト アカウント (SCA) は、導入パズルの 1 ピースにすぎません。 SCA の可能性を最大限に発揮するには、強力なバンドラー インフラストラクチャとピアツーピア メモリ プール、よりコスト効率が高く実現可能な SCA 署名メカニズム、クロスチェーン SCA 同期に加えて、第 2 層ソリューションからのプロトコル層サポートも必要です。ユーザーフレンドリーなインターフェイスの開発だけでなく、管理も行います。
私たちは幅広い参加者が参加する未来を構想していますが、これによりいくつかの興味深い疑問が生じます。SCA 注文プロセスが十分な収益を上げられるようになったら、従来のマイナー抽出可能価値 (MEV) メカニズムがどのようにこの領域に参入し、バンドラーを構築し、価値を獲得するのでしょうか?インフラストラクチャが成熟すると、アカウント抽象化 (AA) はどのようにして「インテントベース」トランザクションのベースレイヤーになるのでしょうか?この分野は常に進化しているので、ご期待ください。