作者:Rui,SevenX Ventures 出資者编译:Luccy,Joyce,BlockBeats>> *編集者注:スマートコントラクトアカウント(SCA)は勢いを増しており、Vitalikを含む多くのコア起業家によってサポートされていますが、SCAの採用にはまだ多くの課題があります。 Account Abstraction (AA) には、コードのカスタマイズを使用できるという利点がありますが、相互運用性がないため、統合とベンダー ロックインの問題が発生します。 モジュラー口座の抽象化は、汎用性が高く、安全で、シームレスに統合されたウォレットを開発するためのモジュラー構造を作成することを目的としています。 *>>SevenX Ventures >の投資家であるRui氏は、SCAを採用する上での5つの課題(弱気市場への影響、移行の難しさ、署名の問題、ガスコストの高騰、エンジニアリングの課題)を特定し、さらに議論した。 さらに、モジュール式スマートコントラクトアカウントのアーキテクチャを分析したところ、モジュール式SCAは採用の課題のほんの一部に過ぎないことが指摘されています。>>> SCAの可能性を最大限に引き出すには、追加のプロトコル層サポート、堅牢なバンドラーインフラストラクチャとピアツーピアメモリプール、より費用対効果が高く実行可能なSCA署名メカニズム、クロスチェーンSCAの同期と管理、およびユーザーフレンドリーなインターフェースの開発を提供するレイヤー2ソリューションが必要です。>>> 現在の課題が解決され、SCAを採用する人が増えるにつれて、将来は何が起こるのでしょうか? Rui氏はまた、いくつかの興味深い質問をします。 BlockBeatsは、元のテキストを次のように編集しました。>>>外部所有口座(EOA)からスマートコントラクト口座(SCA)への移行は勢いを増しており、ヴィタリックを含む多くのコア起業家によってすでに支持されています。 それにもかかわらず、SCAの採用はEOAほど普及していません。 主な問題には、弱気相場の影響、EOAからSCAへの移行の難しさ、署名の問題、ガスコストの高騰、そして最も重要な開発上の課題が含まれます。Account Abstraction (AA) の最も大きな利点は、コードを使用して機能をカスタマイズできることです。 しかし、AA機能の非相互運用性は、この断片化がAA統合を妨げ、ベンダーロックインを強化するため、大きな課題となっています。 また、アップグレードやコンポーザブルでありながらセキュリティを確保することも重要な課題です。モジュラーアカウント抽象化の出現は、スマートアカウントをカスタム機能から分離する革新的なアプローチであるAAトレンドのニッチです。 目標は、複数の機能、セキュリティ、シームレスな統合を備えたウォレットを開発するためのモジュール構造を作成することでした。 将来的には、モジュール式のアカウント抽象化により、無料のスマートコントラクトアカウント「アプリストア」が可能になり、ウォレットとdAppsは、機能の構築に多くの労力を費やすのではなく、ユーザーエクスペリエンスの向上に集中できるようになります。### 簡単なアカウントの抽象化 (AA)! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3)従来のEOAは、シードフレーズ、ガス料金、クロスチェーン操作、複数のトランザクションなど、人々がブロックチェーンに触れる機会に多くの課題をもたらします。アカウントの抽象化は、スマートコントラクトアカウントを活用して、プログラム可能な検証と実装を可能にします。 つまり、ユーザーは、各トランザクションに署名してブロードキャストするのではなく、一連のトランザクションを一度に承認できます。 また、アカウントの抽象化により、ユーザーエクスペリエンスの向上(ガスの抽象化やセッションキーなど)、コストの削減(一括トランザクションなど)、セキュリティの向上(ソーシャルリカバリ、マルチシグなど)など、より多くの機能を有効にすることができます。 現在、勘定科目を抽象化するには、次の 2 つの方法があります。· プロトコル層:一部のプロトコルはネイティブアカウント抽象化サポートを提供し、ZKSyncトランザクションは単一のmempoolとトランザクションフローを使用してAAをサポートし、EOAとSCAの両方から同じプロセスに従いますが、StarknetはEOAを削除し、すべてのアカウントはSCAであり、Argentのようなネイティブスマートコントラクトウォレットを持っています。· コントラクトレイヤー:イーサリアムや類似のL2 ERC4337、コンセンサスレイヤーを変更せずにAAをサポートするために、別のmempoolを導入しました。 Stackup、Alchemy、Etherspot、Biconomy、Candide、Plimico などのサイトがバンドラーのインフラストラクチャを構築しているのに対し、Safe、Zerodev、Etherspot、Biconomy などはバンドラーと SDK を構築しています。### SCA導入のジレンマ勘定科目の抽象化(AA)のトピックは2015年から議論されており、今年はERC 4337によってさらに脚光を浴びています。 しかし、デプロイされたスマートコントラクトのアカウント数は、EOAほど低くはありません。! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147)このジレンマを掘り下げてみましょう。1. 弱気相場の影響シームレスなログインやガスの抽象化などのAAの利点にもかかわらず、すべてのユーザーが教育を受けたEOAユーザーであり、新規ユーザーがあまりいない現在の弱気市場では、dAppsやウォレットがSCAを採用するインセンティブはありません。 それでも、AAシステムとガスレスソリューションを導入することで、わずか1か月で約360,000のUserOps(AAトランザクション)を牽引したCyberconnectなど、主要なdAppsのいくつかは徐々にAAを採用しています。2. 移行の障害すでにユーザーや資産を蓄積しているウォレットやアプリの場合、資産を安全かつ便利に移行することは依然として課題です。 ただし、EIP-7377 のようなスキームでは、EOA が 1 回限りの移行トランザクションを開始できます。3. 署名の問題スマートコントラクト自体は、EOAのような秘密鍵を持たないため、メッセージに署名できません。 ERC1271のような試みはこれを可能にしますが、メッセージ署名は最初のトランザクションまで機能せず、反事実でデプロイされたウォレットに課題をもたらします。 Ambireが提案したERC-6492は、ERC-1271の後継機であり、以前の問題を解決できる可能性があります。4.ガス代また、標準的なEOAと比較して、SCAの導入、シミュレーション、実行にかかるコストが高いことも、導入の障壁となっています。 ただし、アカウントの作成とユーザーのアクションを分離したり、アカウントに関連付けられた「ソルト」を削除したりするなど、いくつかのテストが実施されています。5.エンジニアリングの問題ERC-4337チームは、開発者に基本実装を提供するeth-infinitismリポジトリを構築しました。 しかし、開発者がさまざまなユースケースに合わせてよりきめ細かく特定の機能に拡張するにつれて、統合とデコードはより多くの課題に直面します。 この記事では、エンジニアリングの課題について掘り下げていきます。! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d)### モジュール式のスマートコントラクトアカウントでエンジニアリングの課題を解決エンジニアリング上の課題は、断片化、セキュリティ、アップグレード可能性の 3 つの側面にさらに詳しく説明できます。· フラグメンテーション: 機能は、特定の SCA またはスタンドアロンのプラグインシステムなど、さまざまな方法で有効にできるようになりました。 各プラットフォームとサービスプロバイダーは独自の基準に従っており、開発者はどのプラットフォームとサービスプロバイダーをサポートするかを決定する必要があります。 これにより、プラットフォーム (ベンダー) のロックインや冗長な作業につながる可能性があります。· セキュリティ:アカウントと機能を切り離すことで柔軟性が得られる一方で、セキュリティの問題が深刻になることもあります。 すべての機能が一緒にレビューされる可能性があるため、独立した評価がないと、アカウントの脆弱性のリスクが高まる可能性があります。· アップグレード性: アカウントが成長するにつれて、機能を追加、置換、または削除する機能を維持することが重要であり、既存の機能を再デプロイする更新ごとに複雑さが生じます。これらの問題に対処するには、安全で効率的なアップグレードを保証するためのアップグレード可能な契約、全体的な開発効率を向上させるための再利用可能なコア、および異なるフロントエンド間のスムーズな移行を保証するための標準化されたインターフェイスが必要です。これらの用語は、モジュラーアカウント抽象化アーキテクチャ(モジュラーAA)の構築という共通の概念に収束します。モジュラーアカウントの抽象化は、スマートアカウントのモジュール化を想定した広範なAA開発の下位区分であり、カスタマイズされたサービスをユーザーに提供し、開発者が最小限の制約で機能をシームレスに強化できるようにします。しかし、どの業界でも新しい基準を確立し、推進することは大きな課題です。 全員が同じ基準を受け入れるまでは、初期段階で多くの異なるソリューションが出現する可能性があります。 4337 SDK、ウォレット、インフラストラクチャチーム、プロトコルレイヤー設計者など、アカウントの抽象化の改良と促進に取り組んでいる人々が、このプロセスを加速するために協力しているのを見るのは心強いことです。### モジュール構造: マスターアカウントとモジュールアカウントがモジュールを呼び出して関数を実装する方法通話とプロキシ契約の委任外部呼び出しと委任された呼び出し:! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66)デリゲート呼び出しについて"委任された呼び出し" は "呼び出し" と似ていますが、ターゲット コントラクトのコンテキストではなく、呼び出し元のコントラクトの現在の状態のコンテキストで実行されます。 つまり、ターゲット コントラクトによって状態が変更されると、呼び出し元のコントラクトのストレージが変更されます。! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732)プロキシ コントラクトとデリゲート呼び出し**構成可能でアップグレード可能な構造を実現するには、「代理店契約」の基本的な概念を導入する必要があります。 **プロキシ コントラクト: 通常のコントラクトにはロジックと状態が格納され、デプロイ後に更新することはできません。 プロキシ コントラクトは、デリゲート呼び出しを使用して別のコントラクトに展開されます。 関数を参照で実装し、プロキシ コントラクトの現在の状態で実行します。ユースケース: プロキシーコントラクトは変わりませんが、ブローカーの背後に新しい実装をデプロイできます。 プロキシコントラクトはアップグレード可能で、パブリックブロックチェーンへの展開と維持が安価です。**安全なアーキテクチャ**! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3)安全なアーキテクチャSafeとは:Safeは、実績のあるセキュリティと柔軟性を提供するように設計された、業界をリードするモジュール式スマートアカウントインフラストラクチャであり、開発者は多様なアプリケーションやウォレットを作成できます。 多くのチームが、Safe上に(またはSafeに触発されて)アプリを構築しています。 例えば、Biconomyは、スマートコントラクトのアカウントを立ち上げた際に、ネイティブの4337と1/1マルチシグでSafeを拡張しました。 164,000件以上の契約が展開され、307億ドル以上の価値が確定したSafeは、間違いなくこの分野のリーダーです。Safeの構造には、セキュアアカウントコントラクト、シングルトンコントラクト、モジュールコントラクトが含まれます。プロキシ コントラクト: ステートフル委任された呼び出しはシングルトン コントラクトであるため、セキュリティで保護されたアカウントはプロキシ コントラクトです。 セキュリティ アカウントには、所有者、しきい値、および実装アドレスがすべてエージェントとして設定され、それらに基づいて状態が定義される変数が含まれています。单例合约(singleton contract):Integration Hub(无状态)シングルトンコントラクトはSafeアカウントを提供し、プラグイン、フック、関数ハンドラ、署名バリデーターなど、さまざまなモジュールコントラクトの統合を定義します。モジュール: カスタム ロジックと機能モジュール コントラクトは強力です。 モジュラー型としてのプラグインは、決済フロー、リカバリーメカニズム、セッションキーなどのさまざまな機能を定義でき、オフチェーンデータを取得することでWeb2とWeb3の架け橋として機能することができます。 セキュリティガードとしてのフックや関数ハンドラなどの他のモジュールは、任意のコマンドに応答できます。Safeの導入後に変更された点:アップグレード可能なコントラクト:新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要があります。 ユーザーは、Safeを目的のシングルトンバージョンにアップグレードする自律性を保持します。構成可能で再利用可能なモジュール:プラグインのモジュール性により、開発者は独自に機能を開発できます。 これらのプラグインは、ユースケースに応じて自由に選択して組み合わせることができるため、高度にカスタマイズ可能なアプローチが得られます。**ERC-2535 Diamond 代理****! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555) ****ダイヤモンドエージェントのERC2535について:**ERC2535標準化されたDiamondモデルは、実質的にサイズ制限なしで展開後にアップグレード/拡張できるモジュール式のスマートコントラクトシステムです。 現在、ZerodevのKernelやSoul Walletの実験など、多くのチームがDiamond構造に触発されています。ダイヤモンド構造とは:**ダイアモンド コントラクト: プライマリ プロキシ コントラクト (ステートフル) ダイアモンドは、委任された呼び出しメソッドを使用して、その実装から関数を呼び出すプロキシ コントラクトです。モジュール/プラグイン/ファセット コントラクト: カスタム ロジックと機能 (ステートレス) モジュールまたはいわゆるファセットは、その機能を 1 つ以上のダイヤモンドにデプロイできるステートレス コントラクトです。 これらは、組み込み関数、ライブラリ、および状態変数を共有できる個別の独立したコントラクトです。**ダイヤモンドによる変更点**アップグレード可能なコントラクト:Diamondは、異なるプラグインを分離して接続し、それらの間でデータを共有し、diamondCut機能を使用してプラグインを直接追加/置換/削除するための体系的な方法を提供します。 時間の経過とともに、Diamondに追加できるプラグインの数に制限はありません。モジュール式で再利用可能なプラグイン:デプロイされたプラグインは、任意の数のダイヤモンドで使用でき、デプロイコストを大幅に削減します。**セーフスマートアカウントとダイヤモンド方式の違い:**SafeアーキテクチャとDiamondアーキテクチャには多くの類似点があり、どちらもコアプロキシコントラクトに依存し、アップグレード可能性とモジュール性のために論理コントラクトを参照しています。この 2 つの主な違いは、論理コントラクトの処理です。 具体的には：· 柔軟性:新しいプラグインを有効にすると、Safeはシングルトンコントラクトを再デプロイしてプロキシに変更を実装する必要があります。 対照的に、DiamondはプロキシコントラクトのdiamondCut関数を介してこれを直接実現します。 アプローチの違いは、Safeが高度な制御を維持するのに対し、Diamondは柔軟性とモジュール性を高めていることを意味します。· セキュア: 現在、両方の構造で使用されており、外部コードがメインコントラクトのストレージを操作できるようにします。 Safeアーキテクチャでは、デリゲート呼び出しは単一の論理コントラクトを指しますが、Diamondは複数のモジュールコントラクトプラグイン間でデリゲート呼び出しを使用します。 その結果、悪意のあるプラグインが別のプラグインを上書きし、ストレージの競合のリスクをもたらし、プロキシの整合性を損なう可能性があります。· コスト:ダイヤモンド・アプローチでは、柔軟性とセキュリティが両立しています。 これによりコストが増加し、新しいプラグインが追加されるたびに、完全に監査する必要があります。 重要なのは、これらのプラグインが互いの機能に干渉しないようにすることですが、これは特に高いセキュリティ基準を維持するのに苦労している中小企業にとって困難な目的です。「セーフスマートアカウント方式」と「ダイヤモンド方式」は、エージェントとモジュールを含む異なる構造の例です。 柔軟性とセキュリティのバランスを取ることが重要であり、この2つのアプローチは今後も進化し、互いに補完し合うでしょう。### モジュールの順序: バリデーター、エグゼキューター、フックAlchemy のチームが ERC-4337 専用に調整したダイヤモンドにインスパイアされた標準規格である ERC6900 を紹介して、これについてさらに説明しましょう。 共通のインターフェースを提供することで、スマートアカウントのモジュール化の課題を解決し、プラグイン開発者とウォレット開発者間の作業を調整します。AAの取引プロセスには、検証、実行、紐付けの3つの主要なプロセスがあります。 前述したように、これらの手順はすべて、プロキシ アカウント呼び出しモジュールを使用して管理できます。 プロジェクトが異なれば名前も異なりますが、類似性の根底にあるロジックを把握することが重要です。! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2)さまざまなデザインでの関数の名前バリデーター: アカウント呼び出し元の信頼性と権限を確保します。実行 (UTOR): アカウントで許可されているカスタムロジックを実行します。フック: 別の関数の前または後に実行されるモジュールとして機能します。 状態を変更したり、呼び出し全体を元に戻したりできます。! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14)異なるロジックに従ってモジュールを分離することが重要です。 標準化されたアプローチでは、スマートコントラクトアカウントの検証、実行、およびペギング関数の記述方法を指定する必要があります。 安全かERC6900かにかかわらず、標準化は、特定の実装やエコシステムに固有の独自の開発作業の必要性を減らし、ベンダーロックインを防ぐのに役立ちます。### モジュールの検出とセキュリティオープンな方法でモジュールを見つけて検証する方法: 開発中のソリューションの 1 つに、ユーザーが検証可能なモジュールを検出できる領域 ("レジストリ" と呼ばれる) を作成することが含まれます。 レジストリは「アプリストア」のように機能し、簡素化された繁栄するモジュラーマーケットプレイスの育成を目的としています。**Safe{Core} 协议**! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17)Safe{Core}プロトコルは、スマートコントラクトアカウント用のオープンソースで相互運用可能なプロトコルであり、明確に定義された標準とルールを通じて強力なセキュリティを維持しながら、幅広いベンダーや開発者のアクセシビリティを強化するように設計されています。· アカウント: Safe{Core} プロトコルでは、アカウントの概念は柔軟であり、特定の実装に縛られていません。 これにより、さまざまなアカウントサービスプロバイダーが関与できるようになります。· マネージャー: マネージャーは、アカウント、レジストリ、およびモジュール間のコーディネーターとして機能します。 また、ライセンスレイヤーとしてセキュリティも処理します。· レジストリ:レジストリは、セキュリティ属性を定義し、ERC6900などのモジュール標準を適用して、検出可能性とセキュリティのためのオープンな「アプリストア」環境を作成します。· モジュール: モジュールは機能を処理し、プラグイン、フック、署名バリデーター、関数ハンドラーなど、さまざまな初期型があります。 開発者は、確立された基準を満たしている限り、参加できます。**ラインストーン设计**! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f)このプロセスは次のように展開されます。· スキーマの作成: スキーマは、事前定義されたデータ構造を提供します。 ユーザーは、特定のユースケースに合わせて調整できます。· スキーマに基づいてモジュールを作成する: モジュールとして登録されたスマートコントラクトは、バイトコードを取得してスキーマ ID を選択し、データはレジストリに格納されます。· モジュールの構成証明を取得する: 証明者/監査人は、アーキテクチャに基づいてモジュールの証明を提供できます。 これらの構成証明には、一意の識別子 (UID) と、リンクに使用される他の構成証明への参照を含めることができます。 チェーンをまたいで伝播し、ターゲットチェーンが特定のしきい値を満たしていることを検証できます。· リゾルバーで複雑なロジックを実装する: パーサー (オプション) が機能します。 これらは、モジュールの作成、構成証明の確立、および失効中に呼び出すことができます。 これらのパーサーにより、開発者は証明構造を維持しながら、複雑で多様なロジックを統合できます。ユーザー フレンドリなクエリ アクセス: クエリは、ユーザーがフロントエンドからセキュリティ情報にアクセスする方法を提供します。このモデルはまだ初期段階にありますが、分散型で協調的な方法で標準を確立する可能性を秘めています。 レジストリを使用すると、開発者はモジュールを登録し、監査人はセキュリティを検証し、ウォレットを統合できるため、ユーザーはモジュールを簡単に見つけて構成証明情報を検証できます。 将来的には、次のような用途が考えられます。· アテスター:Safeのような信頼できるエンティティは、内部モジュールの証明者としてRhinestoneと連携できます。 同時に、独立した認証機関も参加できます。· モジュール開発者:オープンマーケットプレイスの形成により、モジュール開発者はレジストリを通じて自分の仕事を収益化することができます。· ユーザー:ウォレットやdAppなどのユーザーフレンドリーなインターフェースを介して参加することで、ユーザーはモジュール情報を確認し、さまざまな証明者に信頼を委任することができます。「モジュールレジストリ」の概念は、プラグインやモジュールの開発者が収益化する方法を開きます。 「モジュール市場」への道がさらに開かれる可能性もある。 Safeチームによって監督される側面もあれば、誰もが貢献し、透明性のある監査証跡を提供する分散型マーケットプレイスとして現れる側面もあります。 これを組み込むことで、ベンダーロックインを回避し、より幅広いオーディエンスにアピールする強化されたユーザーエクスペリエンスを追加することで、EVMの拡張をサポートします。これらの方法は個々のモジュールのセキュリティを保証しますが、スマートコントラクトアカウントは、より広範なセキュリティに関しては絶対確実ではありません。 コンプライアンスモジュールと組み合わせて、ストレージの競合がないことを証明することは困難な場合があり、このような問題に対処する上でウォレットやAAインフラストラクチャの重要性が浮き彫りになっています。### まとめモジュール式のスマートコントラクトアカウントスタックを活用することで、ウォレットプロバイダーとdAppsは技術的なメンテナンスの複雑さから解放されます。 同時に、外部モジュール開発者には、パーソナライズされたプロフェッショナルサービスを提供する機会があります。 ただし、対処する必要がある課題には、柔軟性とセキュリティのバランスを取ること、モジュール標準の推進、ユーザーがスマートアカウントを簡単にアップグレードおよび変更できる標準化されたインターフェイスの実装などがあります。さらに、モジュラースマートコントラクトアカウント(SCA)は、採用パズルのほんの一部にすぎません。 SCAの可能性を最大限に引き出すには、堅牢なバンドラー・インフラストラクチャーとピアツーピア・メモリー・プール、より費用対効果が高く実行可能なSCA署名メカニズム、クロスチェーンSCA同期および管理メカニズム、ユーザー・フレンドリーなインターフェースの開発など、追加のプロトコル層サポートを提供するレイヤー2ソリューションが必要です。将来的には、SCAの採用がさらに増えるでしょうが、SCAの注文フローが十分に利益を生むようになったら、従来のマイナー抽出可能価値(MEV)メカニズムがバンドラーを構築して価値を獲得するためにどのように参入するのか、インフラストラクチャが成熟したときにアカウント抽象化(AA)が「インテントベース」トランザクションのベースレイヤーとしてどのように機能するのか、という興味深い疑問も提起されます。
モジュール式のスマートコントラクトアカウントアーキテクチャと課題の詳細
作者:Rui,SevenX Ventures 出資者
编译:Luccy,Joyce,BlockBeats
SevenX Ventures >の投資家であるRui氏は、SCAを採用する上での5つの課題(弱気市場への影響、移行の難しさ、署名の問題、ガスコストの高騰、エンジニアリングの課題)を特定し、さらに議論した。 さらに、モジュール式スマートコントラクトアカウントのアーキテクチャを分析したところ、モジュール式SCAは採用の課題のほんの一部に過ぎないことが指摘されています。
外部所有口座(EOA)からスマートコントラクト口座(SCA)への移行は勢いを増しており、ヴィタリックを含む多くのコア起業家によってすでに支持されています。 それにもかかわらず、SCAの採用はEOAほど普及していません。 主な問題には、弱気相場の影響、EOAからSCAへの移行の難しさ、署名の問題、ガスコストの高騰、そして最も重要な開発上の課題が含まれます。
Account Abstraction (AA) の最も大きな利点は、コードを使用して機能をカスタマイズできることです。 しかし、AA機能の非相互運用性は、この断片化がAA統合を妨げ、ベンダーロックインを強化するため、大きな課題となっています。 また、アップグレードやコンポーザブルでありながらセキュリティを確保することも重要な課題です。
モジュラーアカウント抽象化の出現は、スマートアカウントをカスタム機能から分離する革新的なアプローチであるAAトレンドのニッチです。 目標は、複数の機能、セキュリティ、シームレスな統合を備えたウォレットを開発するためのモジュール構造を作成することでした。 将来的には、モジュール式のアカウント抽象化により、無料のスマートコントラクトアカウント「アプリストア」が可能になり、ウォレットとdAppsは、機能の構築に多くの労力を費やすのではなく、ユーザーエクスペリエンスの向上に集中できるようになります。
簡単なアカウントの抽象化 (AA)
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3)
従来のEOAは、シードフレーズ、ガス料金、クロスチェーン操作、複数のトランザクションなど、人々がブロックチェーンに触れる機会に多くの課題をもたらします。
アカウントの抽象化は、スマートコントラクトアカウントを活用して、プログラム可能な検証と実装を可能にします。 つまり、ユーザーは、各トランザクションに署名してブロードキャストするのではなく、一連のトランザクションを一度に承認できます。 また、アカウントの抽象化により、ユーザーエクスペリエンスの向上(ガスの抽象化やセッションキーなど)、コストの削減(一括トランザクションなど)、セキュリティの向上(ソーシャルリカバリ、マルチシグなど)など、より多くの機能を有効にすることができます。 現在、勘定科目を抽象化するには、次の 2 つの方法があります。
· プロトコル層:一部のプロトコルはネイティブアカウント抽象化サポートを提供し、ZKSyncトランザクションは単一のmempoolとトランザクションフローを使用してAAをサポートし、EOAとSCAの両方から同じプロセスに従いますが、StarknetはEOAを削除し、すべてのアカウントはSCAであり、Argentのようなネイティブスマートコントラクトウォレットを持っています。
· コントラクトレイヤー:イーサリアムや類似のL2 ERC4337、コンセンサスレイヤーを変更せずにAAをサポートするために、別のmempoolを導入しました。 Stackup、Alchemy、Etherspot、Biconomy、Candide、Plimico などのサイトがバンドラーのインフラストラクチャを構築しているのに対し、Safe、Zerodev、Etherspot、Biconomy などはバンドラーと SDK を構築しています。
SCA導入のジレンマ
勘定科目の抽象化(AA)のトピックは2015年から議論されており、今年はERC 4337によってさらに脚光を浴びています。 しかし、デプロイされたスマートコントラクトのアカウント数は、EOAほど低くはありません。
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147)
このジレンマを掘り下げてみましょう。
シームレスなログインやガスの抽象化などのAAの利点にもかかわらず、すべてのユーザーが教育を受けたEOAユーザーであり、新規ユーザーがあまりいない現在の弱気市場では、dAppsやウォレットがSCAを採用するインセンティブはありません。 それでも、AAシステムとガスレスソリューションを導入することで、わずか1か月で約360,000のUserOps(AAトランザクション)を牽引したCyberconnectなど、主要なdAppsのいくつかは徐々にAAを採用しています。
すでにユーザーや資産を蓄積しているウォレットやアプリの場合、資産を安全かつ便利に移行することは依然として課題です。 ただし、EIP-7377 のようなスキームでは、EOA が 1 回限りの移行トランザクションを開始できます。
スマートコントラクト自体は、EOAのような秘密鍵を持たないため、メッセージに署名できません。 ERC1271のような試みはこれを可能にしますが、メッセージ署名は最初のトランザクションまで機能せず、反事実でデプロイされたウォレットに課題をもたらします。 Ambireが提案したERC-6492は、ERC-1271の後継機であり、以前の問題を解決できる可能性があります。
4.ガス代
また、標準的なEOAと比較して、SCAの導入、シミュレーション、実行にかかるコストが高いことも、導入の障壁となっています。 ただし、アカウントの作成とユーザーのアクションを分離したり、アカウントに関連付けられた「ソルト」を削除したりするなど、いくつかのテストが実施されています。
5.エンジニアリングの問題
ERC-4337チームは、開発者に基本実装を提供するeth-infinitismリポジトリを構築しました。 しかし、開発者がさまざまなユースケースに合わせてよりきめ細かく特定の機能に拡張するにつれて、統合とデコードはより多くの課題に直面します。 この記事では、エンジニアリングの課題について掘り下げていきます。
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d)
モジュール式のスマートコントラクトアカウントでエンジニアリングの課題を解決
エンジニアリング上の課題は、断片化、セキュリティ、アップグレード可能性の 3 つの側面にさらに詳しく説明できます。
· フラグメンテーション: 機能は、特定の SCA またはスタンドアロンのプラグインシステムなど、さまざまな方法で有効にできるようになりました。 各プラットフォームとサービスプロバイダーは独自の基準に従っており、開発者はどのプラットフォームとサービスプロバイダーをサポートするかを決定する必要があります。 これにより、プラットフォーム (ベンダー) のロックインや冗長な作業につながる可能性があります。
· セキュリティ:アカウントと機能を切り離すことで柔軟性が得られる一方で、セキュリティの問題が深刻になることもあります。 すべての機能が一緒にレビューされる可能性があるため、独立した評価がないと、アカウントの脆弱性のリスクが高まる可能性があります。
· アップグレード性: アカウントが成長するにつれて、機能を追加、置換、または削除する機能を維持することが重要であり、既存の機能を再デプロイする更新ごとに複雑さが生じます。
これらの問題に対処するには、安全で効率的なアップグレードを保証するためのアップグレード可能な契約、全体的な開発効率を向上させるための再利用可能なコア、および異なるフロントエンド間のスムーズな移行を保証するための標準化されたインターフェイスが必要です。
これらの用語は、モジュラーアカウント抽象化アーキテクチャ(モジュラーAA)の構築という共通の概念に収束します。
モジュラーアカウントの抽象化は、スマートアカウントのモジュール化を想定した広範なAA開発の下位区分であり、カスタマイズされたサービスをユーザーに提供し、開発者が最小限の制約で機能をシームレスに強化できるようにします。
しかし、どの業界でも新しい基準を確立し、推進することは大きな課題です。 全員が同じ基準を受け入れるまでは、初期段階で多くの異なるソリューションが出現する可能性があります。 4337 SDK、ウォレット、インフラストラクチャチーム、プロトコルレイヤー設計者など、アカウントの抽象化の改良と促進に取り組んでいる人々が、このプロセスを加速するために協力しているのを見るのは心強いことです。
モジュール構造: マスターアカウントとモジュール
アカウントがモジュールを呼び出して関数を実装する方法
通話とプロキシ契約の委任
外部呼び出しと委任された呼び出し:
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66)
デリゲート呼び出しについて
"委任された呼び出し" は "呼び出し" と似ていますが、ターゲット コントラクトのコンテキストではなく、呼び出し元のコントラクトの現在の状態のコンテキストで実行されます。 つまり、ターゲット コントラクトによって状態が変更されると、呼び出し元のコントラクトのストレージが変更されます。
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732)
プロキシ コントラクトとデリゲート呼び出し
**構成可能でアップグレード可能な構造を実現するには、「代理店契約」の基本的な概念を導入する必要があります。 **
プロキシ コントラクト: 通常のコントラクトにはロジックと状態が格納され、デプロイ後に更新することはできません。 プロキシ コントラクトは、デリゲート呼び出しを使用して別のコントラクトに展開されます。 関数を参照で実装し、プロキシ コントラクトの現在の状態で実行します。
ユースケース: プロキシーコントラクトは変わりませんが、ブローカーの背後に新しい実装をデプロイできます。 プロキシコントラクトはアップグレード可能で、パブリックブロックチェーンへの展開と維持が安価です。
安全なアーキテクチャ! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3)
安全なアーキテクチャ
Safeとは:Safeは、実績のあるセキュリティと柔軟性を提供するように設計された、業界をリードするモジュール式スマートアカウントインフラストラクチャであり、開発者は多様なアプリケーションやウォレットを作成できます。 多くのチームが、Safe上に(またはSafeに触発されて)アプリを構築しています。 例えば、Biconomyは、スマートコントラクトのアカウントを立ち上げた際に、ネイティブの4337と1/1マルチシグでSafeを拡張しました。 164,000件以上の契約が展開され、307億ドル以上の価値が確定したSafeは、間違いなくこの分野のリーダーです。
Safeの構造には、セキュアアカウントコントラクト、シングルトンコントラクト、モジュールコントラクトが含まれます。
プロキシ コントラクト: ステートフル
委任された呼び出しはシングルトン コントラクトであるため、セキュリティで保護されたアカウントはプロキシ コントラクトです。 セキュリティ アカウントには、所有者、しきい値、および実装アドレスがすべてエージェントとして設定され、それらに基づいて状態が定義される変数が含まれています。
单例合约(singleton contract):Integration Hub(无状态)
シングルトンコントラクトはSafeアカウントを提供し、プラグイン、フック、関数ハンドラ、署名バリデーターなど、さまざまなモジュールコントラクトの統合を定義します。
モジュール: カスタム ロジックと機能
モジュール コントラクトは強力です。 モジュラー型としてのプラグインは、決済フロー、リカバリーメカニズム、セッションキーなどのさまざまな機能を定義でき、オフチェーンデータを取得することでWeb2とWeb3の架け橋として機能することができます。 セキュリティガードとしてのフックや関数ハンドラなどの他のモジュールは、任意のコマンドに応答できます。
Safeの導入後に変更された点:
アップグレード可能なコントラクト:新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要があります。 ユーザーは、Safeを目的のシングルトンバージョンにアップグレードする自律性を保持します。
構成可能で再利用可能なモジュール:プラグインのモジュール性により、開発者は独自に機能を開発できます。 これらのプラグインは、ユースケースに応じて自由に選択して組み合わせることができるため、高度にカスタマイズ可能なアプローチが得られます。
ERC-2535 Diamond 代理
**! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555) **
ダイヤモンドエージェントのERC2535について:
ERC2535標準化されたDiamondモデルは、実質的にサイズ制限なしで展開後にアップグレード/拡張できるモジュール式のスマートコントラクトシステムです。 現在、ZerodevのKernelやSoul Walletの実験など、多くのチームがDiamond構造に触発されています。
ダイヤモンド構造とは:**
ダイアモンド コントラクト: プライマリ プロキシ コントラクト (ステートフル) ダイアモンドは、委任された呼び出しメソッドを使用して、その実装から関数を呼び出すプロキシ コントラクトです。
モジュール/プラグイン/ファセット コントラクト: カスタム ロジックと機能 (ステートレス) モジュールまたはいわゆるファセットは、その機能を 1 つ以上のダイヤモンドにデプロイできるステートレス コントラクトです。 これらは、組み込み関数、ライブラリ、および状態変数を共有できる個別の独立したコントラクトです。
ダイヤモンドによる変更点
アップグレード可能なコントラクト:Diamondは、異なるプラグインを分離して接続し、それらの間でデータを共有し、diamondCut機能を使用してプラグインを直接追加/置換/削除するための体系的な方法を提供します。 時間の経過とともに、Diamondに追加できるプラグインの数に制限はありません。
モジュール式で再利用可能なプラグイン:デプロイされたプラグインは、任意の数のダイヤモンドで使用でき、デプロイコストを大幅に削減します。
セーフスマートアカウントとダイヤモンド方式の違い:
SafeアーキテクチャとDiamondアーキテクチャには多くの類似点があり、どちらもコアプロキシコントラクトに依存し、アップグレード可能性とモジュール性のために論理コントラクトを参照しています。
この 2 つの主な違いは、論理コントラクトの処理です。 具体的には：
· 柔軟性:新しいプラグインを有効にすると、Safeはシングルトンコントラクトを再デプロイしてプロキシに変更を実装する必要があります。 対照的に、DiamondはプロキシコントラクトのdiamondCut関数を介してこれを直接実現します。 アプローチの違いは、Safeが高度な制御を維持するのに対し、Diamondは柔軟性とモジュール性を高めていることを意味します。
· セキュア: 現在、両方の構造で使用されており、外部コードがメインコントラクトのストレージを操作できるようにします。 Safeアーキテクチャでは、デリゲート呼び出しは単一の論理コントラクトを指しますが、Diamondは複数のモジュールコントラクトプラグイン間でデリゲート呼び出しを使用します。 その結果、悪意のあるプラグインが別のプラグインを上書きし、ストレージの競合のリスクをもたらし、プロキシの整合性を損なう可能性があります。
· コスト:ダイヤモンド・アプローチでは、柔軟性とセキュリティが両立しています。 これによりコストが増加し、新しいプラグインが追加されるたびに、完全に監査する必要があります。 重要なのは、これらのプラグインが互いの機能に干渉しないようにすることですが、これは特に高いセキュリティ基準を維持するのに苦労している中小企業にとって困難な目的です。
「セーフスマートアカウント方式」と「ダイヤモンド方式」は、エージェントとモジュールを含む異なる構造の例です。 柔軟性とセキュリティのバランスを取ることが重要であり、この2つのアプローチは今後も進化し、互いに補完し合うでしょう。
モジュールの順序: バリデーター、エグゼキューター、フック
Alchemy のチームが ERC-4337 専用に調整したダイヤモンドにインスパイアされた標準規格である ERC6900 を紹介して、これについてさらに説明しましょう。 共通のインターフェースを提供することで、スマートアカウントのモジュール化の課題を解決し、プラグイン開発者とウォレット開発者間の作業を調整します。
AAの取引プロセスには、検証、実行、紐付けの3つの主要なプロセスがあります。 前述したように、これらの手順はすべて、プロキシ アカウント呼び出しモジュールを使用して管理できます。 プロジェクトが異なれば名前も異なりますが、類似性の根底にあるロジックを把握することが重要です。
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2)
さまざまなデザインでの関数の名前
バリデーター: アカウント呼び出し元の信頼性と権限を確保します。
実行 (UTOR): アカウントで許可されているカスタムロジックを実行します。
フック: 別の関数の前または後に実行されるモジュールとして機能します。 状態を変更したり、呼び出し全体を元に戻したりできます。
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14)
異なるロジックに従ってモジュールを分離することが重要です。 標準化されたアプローチでは、スマートコントラクトアカウントの検証、実行、およびペギング関数の記述方法を指定する必要があります。 安全かERC6900かにかかわらず、標準化は、特定の実装やエコシステムに固有の独自の開発作業の必要性を減らし、ベンダーロックインを防ぐのに役立ちます。
モジュールの検出とセキュリティ
オープンな方法でモジュールを見つけて検証する方法: 開発中のソリューションの 1 つに、ユーザーが検証可能なモジュールを検出できる領域 ("レジストリ" と呼ばれる) を作成することが含まれます。 レジストリは「アプリストア」のように機能し、簡素化された繁栄するモジュラーマーケットプレイスの育成を目的としています。
Safe{Core} 协议
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17)
Safe{Core}プロトコルは、スマートコントラクトアカウント用のオープンソースで相互運用可能なプロトコルであり、明確に定義された標準とルールを通じて強力なセキュリティを維持しながら、幅広いベンダーや開発者のアクセシビリティを強化するように設計されています。
· アカウント: Safe{Core} プロトコルでは、アカウントの概念は柔軟であり、特定の実装に縛られていません。 これにより、さまざまなアカウントサービスプロバイダーが関与できるようになります。
· マネージャー: マネージャーは、アカウント、レジストリ、およびモジュール間のコーディネーターとして機能します。 また、ライセンスレイヤーとしてセキュリティも処理します。
· レジストリ:レジストリは、セキュリティ属性を定義し、ERC6900などのモジュール標準を適用して、検出可能性とセキュリティのためのオープンな「アプリストア」環境を作成します。
· モジュール: モジュールは機能を処理し、プラグイン、フック、署名バリデーター、関数ハンドラーなど、さまざまな初期型があります。 開発者は、確立された基準を満たしている限り、参加できます。
ラインストーン设计
! [モジュール式スマートコントラクトアカウントのアーキテクチャと課題の詳細] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f)
このプロセスは次のように展開されます。
· スキーマの作成: スキーマは、事前定義されたデータ構造を提供します。 ユーザーは、特定のユースケースに合わせて調整できます。
· スキーマに基づいてモジュールを作成する: モジュールとして登録されたスマートコントラクトは、バイトコードを取得してスキーマ ID を選択し、データはレジストリに格納されます。
· モジュールの構成証明を取得する: 証明者/監査人は、アーキテクチャに基づいてモジュールの証明を提供できます。 これらの構成証明には、一意の識別子 (UID) と、リンクに使用される他の構成証明への参照を含めることができます。 チェーンをまたいで伝播し、ターゲットチェーンが特定のしきい値を満たしていることを検証できます。
· リゾルバーで複雑なロジックを実装する: パーサー (オプション) が機能します。 これらは、モジュールの作成、構成証明の確立、および失効中に呼び出すことができます。 これらのパーサーにより、開発者は証明構造を維持しながら、複雑で多様なロジックを統合できます。
ユーザー フレンドリなクエリ アクセス: クエリは、ユーザーがフロントエンドからセキュリティ情報にアクセスする方法を提供します。
このモデルはまだ初期段階にありますが、分散型で協調的な方法で標準を確立する可能性を秘めています。 レジストリを使用すると、開発者はモジュールを登録し、監査人はセキュリティを検証し、ウォレットを統合できるため、ユーザーはモジュールを簡単に見つけて構成証明情報を検証できます。 将来的には、次のような用途が考えられます。
· アテスター:Safeのような信頼できるエンティティは、内部モジュールの証明者としてRhinestoneと連携できます。 同時に、独立した認証機関も参加できます。
· モジュール開発者:オープンマーケットプレイスの形成により、モジュール開発者はレジストリを通じて自分の仕事を収益化することができます。
· ユーザー:ウォレットやdAppなどのユーザーフレンドリーなインターフェースを介して参加することで、ユーザーはモジュール情報を確認し、さまざまな証明者に信頼を委任することができます。
「モジュールレジストリ」の概念は、プラグインやモジュールの開発者が収益化する方法を開きます。 「モジュール市場」への道がさらに開かれる可能性もある。 Safeチームによって監督される側面もあれば、誰もが貢献し、透明性のある監査証跡を提供する分散型マーケットプレイスとして現れる側面もあります。 これを組み込むことで、ベンダーロックインを回避し、より幅広いオーディエンスにアピールする強化されたユーザーエクスペリエンスを追加することで、EVMの拡張をサポートします。
これらの方法は個々のモジュールのセキュリティを保証しますが、スマートコントラクトアカウントは、より広範なセキュリティに関しては絶対確実ではありません。 コンプライアンスモジュールと組み合わせて、ストレージの競合がないことを証明することは困難な場合があり、このような問題に対処する上でウォレットやAAインフラストラクチャの重要性が浮き彫りになっています。
まとめ
モジュール式のスマートコントラクトアカウントスタックを活用することで、ウォレットプロバイダーとdAppsは技術的なメンテナンスの複雑さから解放されます。 同時に、外部モジュール開発者には、パーソナライズされたプロフェッショナルサービスを提供する機会があります。 ただし、対処する必要がある課題には、柔軟性とセキュリティのバランスを取ること、モジュール標準の推進、ユーザーがスマートアカウントを簡単にアップグレードおよび変更できる標準化されたインターフェイスの実装などがあります。
さらに、モジュラースマートコントラクトアカウント(SCA)は、採用パズルのほんの一部にすぎません。 SCAの可能性を最大限に引き出すには、堅牢なバンドラー・インフラストラクチャーとピアツーピア・メモリー・プール、より費用対効果が高く実行可能なSCA署名メカニズム、クロスチェーンSCA同期および管理メカニズム、ユーザー・フレンドリーなインターフェースの開発など、追加のプロトコル層サポートを提供するレイヤー2ソリューションが必要です。
将来的には、SCAの採用がさらに増えるでしょうが、SCAの注文フローが十分に利益を生むようになったら、従来のマイナー抽出可能価値(MEV)メカニズムがバンドラーを構築して価値を獲得するためにどのように参入するのか、インフラストラクチャが成熟したときにアカウント抽象化(AA)が「インテントベース」トランザクションのベースレイヤーとしてどのように機能するのか、という興味深い疑問も提起されます。