この記事は SevenX 調査チームによるオリジナルであり、コミュニケーションと学習のみを目的としており、投資の参考となるものではありません。引用する必要がある場合は出典を明記してください。
オリジナルの英語レポートは、2023年9月にSevenXのMirrorプラットフォームで公開されました。中国投資に関する研究コンテンツをさらにご覧になりたい場合は、公開アカウント [SevenXVentures] をフォローしてください。
Safe の共同創設者である Lukas、Alchemy のエンジニアリング責任者である Noam、Rhinestone の共同創設者である Kurt と Konrad、そして HashKey Capital の投資家である Arnav に感謝します。
編集者注: スマート コントラクト アカウント (SCA) は力強く発展しており、Vitalik を含む多くの中核的な起業家によってサポートされていますが、SCA の導入には依然として多くの課題が残されています。アカウント抽象化 (AA) には、コードを使用して機能をカスタマイズできるという利点がありますが、相互運用性がないため、統合とベンダー ロックインの問題が生じます。モジュール式アカウントの抽象化は、多様な機能、セキュリティ、シームレスな統合を備えたウォレットを開発するためのモジュール式構造を作成することを目的としています。
SevenX Ventures の投資家 Rui 氏は、SCA の採用が直面している 5 つの主要な課題、すなわち弱気市場への影響、移行の難しさ、署名の問題、高いガスコスト、エンジニアリングの難しさを指摘し、エンジニアリングの問題についてさらに議論しました。さらに、モジュール式スマート コントラクト アカウントのアーキテクチャの分析では、モジュール式 SCA が導入パズルのほんの一部にすぎないことが指摘されています。
SCA の可能性を最大限に発揮するには、追加のプロトコル層サポート、強力なバンドラー インフラストラクチャとピアツーピア メモリ プール、よりコスト効率が高く実現可能な SCA 署名メカニズム、クロスチェーン SCA 同期、および管理メカニズムと開発 ユーザーフレンドリーなインターフェイスなど。
将来、現在の課題が徐々に解決され、SCA を採用する人が増えると、次に何が起こるでしょうか? Rui さんは、これに関していくつかの興味深い質問もしました。 BlockBeats は元のテキストを次のようにコンパイルします。
外部所有アカウント (EOA) からスマート コントラクト アカウント (SCA) への移行は勢いを増しており、Vitalik を含む多くの中核的な起業家からの支援を受けています。それにもかかわらず、SCA の採用は EOA ほど普及していません。主な問題には、弱気市場の影響、eoa から sca への移行の困難さ、署名の問題、高いガスコスト、および最も重要な開発上の問題が含まれます。
アカウント抽象化 (AA) の最も重要な利点は、コードを使用して機能をカスタマイズできることです。ただし、AA 機能の非相互運用性は大きな課題を引き起こしており、この断片化により AA の統合が妨げられ、ベンダー ロックインが強化される可能性があります。さらに、アップグレード可能で構成可能でありながらセキュリティを確保することも重要な課題です。
AA 開発トレンドにおけるニッチな領域の 1 つは、スマート アカウントをカスタム機能から分離する革新的なアプローチであるモジュール式アカウント抽象化の出現です。目標は、多様な機能、セキュリティ、シームレスな統合を備えたウォレットを開発するためのモジュール構造を作成することです。将来的には、モジュラーアカウント抽象化により無料のスマートコントラクトアカウント「アプリストア」を実装できるようになり、ウォレットとdAppsは機能の構築に多大なエネルギーを費やすことなく、ユーザーエクスペリエンスの向上に集中できるようになります。
アカウント抽象化 (AA) の簡単な紹介
人々がブロックチェーンに触れる過程で、従来の EOA はニーモニックワード、ガス料金、クロスチェーン操作、複数のトランザクションなど、多くの課題をもたらしました。
アカウントの抽象化ではスマート コントラクト アカウントを活用し、プログラム可能な検証と実行を可能にします。これは、ユーザーが各トランザクションに署名してブロードキャストする代わりに、一連のトランザクションを一度に承認できることを意味します。アカウントの抽象化により、ユーザー エクスペリエンスの向上 (ガス抽象化やセッション キーなど)、コストの削減 (バッチ トランザクションなど)、セキュリティの向上 (ソーシャル リカバリ、マルチ署名など) など、より多くの機能も実現できます。現在、アカウントの抽象化を実装するには 2 つの方法があります。
プロトコル層: 一部のプロトコル自体は、ネイティブ アカウント抽象化サポートを提供します。ZKSync トランザクションは、AA をサポートするために単一のメモリ プールとトランザクション プロセスを使用します。EOA からのものでも SCA からのものでも、同じプロセスに従います。Starknet は EOA を削除し、すべてのアカウントは SCA です、そしてArgentのようなネイティブスマートコントラクトウォレットを持っています。
コントラクト層: イーサリアムおよび同様の L2 の場合、ERC 4337 は、コンセンサス層を変更せずに AA をサポートするための別個のメモリプールを導入します。 Stackup、Alchemy、Etherspot、Biconomy、Candide、Plimico などの企業はバンドラー インフラストラクチャを構築しており、Safe、Zerodev、Etherspot、Biconomy などの企業はバンドラーと SDK を構築しています。
SCA採用時のジレンマ
アカウント抽象化 (AA) のテーマは 2015 年から議論されており、今年 ERC 4337 によってさらに注目を集めました。ただし、導入されているスマート コントラクト アカウントの数は、EOA よりもはるかに少ないです。
このジレンマをさらに深く掘り下げてみましょう。
1. 弱気相場の影響
AAにはシームレスなログインやGas抽象化などの利点がありますが、現在の弱気市場では、すべてのユーザーが教育を受けたEOAユーザーであり、新規ユーザーもそれほど多くないため、dAppsやウォレットにはSCAを採用するインセンティブがありません。それでも、一部の大手 dApps は徐々に AA を導入しており、たとえば Cyberconnect は、AA システムとガスフリー ソリューションの導入により、わずか 1 か月で約 360,000 の UserOps (AA トランザクション) を推進しました。
2. 移行の障壁
ユーザーや資産が蓄積されているウォレットやアプリケーションにとって、資産を安全かつ便利に移行することは依然として課題です。ただし、EIP-7377 のようなスキームでは、EOA が 1 回限りの移行トランザクションを開始できます。
3. 署名の問題
スマート コントラクト自体は EOA のような秘密キーを持たないため、メッセージに署名できません。 ERC 1271のような試みによりこれが可能になりますが、最初のトランザクションの前ではメッセージ署名が機能しないため、反事実的な展開を使用するウォレットにとっても課題が生じます。 Ambire によって提案された ERC-6492 は、ERC-1271 の下位互換性のある後継であり、以前の問題を解決できる可能性があります。
4. ガス代
導入の障壁の 1 つは、標準の EOA と比較して SCA の導入、シミュレーション、実行にかかるコストが高いことです。ただし、アカウント作成をユーザーのアクションから分離したり、ユーザーのアクションを排除したりするなど、いくつかのテストが実行されました。"salt"待って。
5. エンジニアリング上の問題
ERC-4337 チームは、開発者に基本的な実装を提供する eth-infinitim リポジトリを設立しました。ただし、開発者がさまざまなユースケースに合わせて、より微妙で具体的な機能にスケールアップするにつれて、統合とデコードはさらに多くの課題に直面することになります。この記事では、エンジニアリング上の課題について詳しく見ていきます。
モジュール式のスマート コントラクト アカウントでエンジニアリング上の課題を解決する
エンジニアリング上の課題は、断片化、セキュリティ、スケーラビリティの 3 つの側面にさらに詳しく説明できます。
断片化
特定の SCA またはスタンドアロン プラグイン システムを通じて、さまざまな方法で機能を有効にできるようになりました。各プラットフォームとサービス プロバイダーは独自の標準に従っており、開発者はどのプラットフォームとサービス プロバイダーをサポートするかを決定する必要があります。これにより、プラットフォーム (ベンダー) のロックインや冗長な作業が発生する可能性があります。
安全性
アカウントと機能を分離すると柔軟性が得られますが、セキュリティ問題が悪化する可能性もあります。すべての機能が一緒にレビューされる可能性があるため、独立した評価がないとアカウントの脆弱性のリスクが高まる可能性があります。
アップグレード可能性
アカウントが拡大するにつれて、機能を追加、置換、または削除できる機能を維持することが重要になり、既存の機能を再デプロイする更新ごとに複雑さが生じます。
これらの問題に対処するには、安全かつ効率的なアップグレードを保証するためのアップグレード可能なコントラクト、全体的な開発効率を向上させるための再利用可能なコア、およびコントラクト アカウントが異なるフロントエンド間でスムーズに移行できるようにするための標準化されたインターフェイスが必要です。
これらの用語は、モジュール型アカウント抽象化アーキテクチャ (モジュール型 AA) の構築という共通の概念に収束します。
モジュラー アカウントの抽象化は、スマート アカウントをモジュール化してユーザー向けのサービスをカスタマイズし、開発者が最小限の制限でシームレスに機能を強化できるようにすることを想定した広範な AA 開発内の細分化です。
しかし、どの業界においても新しい標準を確立し推進することは大きな課題です。誰もが同じ標準を受け入れるまでの初期段階では、多くの異なるソリューションが登場する可能性があります。 4337 SDK、ウォレット、インフラストラクチャ チーム、プロトコル レイヤ設計者など、アカウントの抽象化の改良と推進に取り組んでいる人々が、このプロセスをスピードアップするために協力しているのを見るのは心強いです。
モジュール構造: マスターアカウントとモジュール
アカウントがモジュールを呼び出して関数を実装する方法
代理通話と代理契約
外部呼び出しと代理呼び出し:
デリゲートコールについて
「委任呼び出し」は「呼び出し」に似ていますが、ターゲット コントラクトのコンテキストではなく、呼び出し側コントラクトの現在の状態のコンテキストで実行されます。これは、ターゲット コントラクトによって行われた状態変更によって、呼び出し側コントラクトのストレージが変更されることを意味します。
代理契約と代理通話
構成可能でアップグレード可能な構造を実現するには、「代理店契約」という基本概念を導入する必要があります。
エージェント コントラクト: 通常のコントラクトはロジックとステータスを保存し、展開後に更新することはできません。プロキシ コントラクトは、デリゲート呼び出しを使用して別のコントラクトにデプロイします。関数を参照によって実装し、エージェント コントラクトの現在の状態で実行します。
使用例: プロキシ コントラクトは変わりませんが、プロキシの背後に新しい実装をデプロイできます。プロキシ契約によりアップグレードが可能になり、パブリック ブロックチェーン上での導入と維持がより安価になります。
安全なアーキテクチャ
安全なアーキテクチャ
何が安全か:
Safe は、実証済みのセキュリティと柔軟性を提供するように設計された主要なモジュール式スマート アカウント インフラストラクチャで、開発者が多様なアプリケーションとウォレットを作成できるようにします。多くのチームが Safe に基づいた (または Safe からインスピレーションを受けて) アプリケーションを構築しています。たとえば、Biconomy がスマート コントラクト アカウントを開始したとき、ネイティブ 4337 と 1/1 マルチ署名を使用して Safe を拡張しました。 164,000 を超える契約が導入され、307 億ドルを超える価値が確保されている Safe は、間違いなくこの分野のリーダーです。
Safe の構造には、セキュリティ アカウント コントラクト、シングルトン コントラクト、モジュール コントラクトが含まれます。
セキュリティアカウント契約（プロキシ契約）：メインエージェント契約（ステートフル）
デリゲート呼び出しはシングルトン コントラクトであるため、セキュリティ アカウントはプロキシ コントラクトです。セキュリティ アカウントには、エージェントに設定される所有者、しきい値、および実装アドレスの変数が含まれており、そのステータスはこれらに基づいて定義されます。
シングルトン コントラクト: Integration Hub (ステートレス)
シングルトン コントラクトはセーフ アカウントを提供し、プラグイン、フック、関数ハンドラー、署名バリデーターなどのさまざまなモジュール コントラクト統合を定義します。
モジュール コントラクト (モジュール): カスタム ロジックと関数
モジュールコントラクトは強力です。モジュール型のプラグインは、支払いフロー、回復メカニズム、セッション キーなどのさまざまな機能を定義でき、オフチェーン データを取得することで Web2 と Web3 の間のブリッジとして機能できます。セキュリティ ガードとしてのフックや関数ハンドラーなどの他のモジュールは、あらゆるコマンドに応答できます。
Safe の採用によってもたらされる変化:
アップグレード可能なコントラクト: 新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要があります。ユーザーは、Safe を目的のシングルトン バージョンにアップグレードする自主性を保持します。
構成可能で再利用可能なモジュール: プラグインのモジュール性により、開発者は機能を独立して開発できます。ユースケースに応じてこれらのプラグインを自由に選択して組み合わせることができるため、高度にカスタマイズ可能なアプローチが得られます。
ERC-2535 ダイヤモンドエージェント
ダイヤモンド代理店 ERC 2535 について:
ERC 2535 標準化されたダイヤモンド モデルは、サイズ制限がほとんどなく、展開後にアップグレード/拡張できるモジュラー スマート コントラクト システムです。現在、Zerodev のカーネルやソウル ウォレットなど、多くのチームの実験はダイヤモンド構造からインスピレーションを受けています。
ダイヤモンド構造とは:
ダイヤモンド コントラクト: メイン プロキシ コントラクト (ステートフル) ダイヤモンドは、デリゲート呼び出しメソッドを使用して実装から関数を呼び出すプロキシ コントラクトです。
モジュール/プラグイン/ファセット コントラクト: カスタム ロジックと機能 (ステートレス) モジュールまたはいわゆるファセットは、その機能を 1 つ以上の Diamond にデプロイできるステートレス コントラクトです。これらは、内部関数、ライブラリ、および状態変数を共有できる個別の独立したコントラクトです。
ダイヤモンド導入による変化：
アップグレード可能なコントラクト: Diamond は、さまざまなプラグインを分離して相互に接続し、プラグイン間でデータを共有する体系的な方法を提供します。また、diamondCut 関数を使用してプラグインを直接追加/置換/削除することもできます。時間の経過とともに、Diamond に追加できるプラグインの数に制限はなくなります。
モジュール式で再利用可能なプラグイン: 導入されたプラグインは任意の数の Diamond で使用できるため、導入コストが大幅に削減されます。
安全なスマート アカウントとダイヤモンド方式の違い:
Safe アーキテクチャと Diamond アーキテクチャには多くの類似点があり、どちらも中核でプロキシ コントラクトに依存し、アップグレード可能性とモジュール性のためにロジック コントラクトを参照しています。
2 つの主な違いは、論理契約の処理です。具体的には：
柔軟性: 新しいプラグインを有効にすると、Safe はシングルトン コントラクトを再デプロイして、プロキシに変更を実装する必要があります。対照的に、Diamond はプロキシ コントラクトの DiamondCut 関数を通じてこれを直接実行します。このアプローチの違いは、Safe が高度な制御を維持するのに対し、Diamond は強化された柔軟性とモジュール性を導入していることを意味します。
セキュリティ: 現在、外部コードによるメイン コントラクトのストレージの操作を可能にする 2 つの構造で使用されています。 Safe アーキテクチャでは、デリゲート呼び出しは単一の論理コントラクトを指しますが、Diamond は複数のモジュール コントラクト プラグインでデリゲート呼び出しを使用します。したがって、悪意のあるプラグインが別のプラグインを上書きする可能性があり、それによってストレージの競合が発生し、エージェントの整合性が損なわれるリスクが生じます。
コスト: ダイヤモンド アプローチでは、柔軟性には安全性の懸念が伴います。これによりコストが増加し、新しいプラグインが追加されるたびに完全なレビューが必要になります。重要なのは、これらのプラグインが相互の機能を干渉しないようにすることですが、これは、特に高いセキュリティ基準を維持しようと努めている中小企業にとっては困難な作業となる可能性があります。
「安全なスマート アカウント方式」と「ダイヤモンド方式」は、エージェントとモジュールが関与するさまざまな構造の例です。柔軟性とセキュリティのバランスをどう取るかが重要であり、これら 2 つのアプローチは今後も進化し、相互に補完し合うことになります。
モジュールの順序: バリデータ、エグゼキュータ、フック
Alchemy チームによって提案され、ダイヤモンドからインスピレーションを得て、特に ERC-4337 用に調整された標準である ERC-6900 を紹介して、議論をさらに進めましょう。共通のインターフェイスを提供し、プラグインとウォレットの開発者間の作業を調整することで、スマート アカウントのモジュール化の課題を解決します。
AA のトランザクション プロセスには、検証、実行、フッキングという 3 つの主要なプロセスがあります。前に説明したように、これらの手順はすべて、プロキシ アカウントを使用してモジュールを呼び出すことで管理できます。プロジェクトごとに異なる名前が使用される場合がありますが、同様の基礎となるロジックを把握することが重要です。
さまざまなデザインの関数名
バリデータ: アカウント呼び出し元の信頼性と権限を確認します。
Executor: アカウントで許可されているカスタム ロジックを実行します。
フック: 別の関数の前または後に実行されるモジュールとして機能します。状態を変更したり、呼び出し全体を元に戻したりできます。
ERC 6900
異なるロジックに基づいてモジュールを分離することが重要です。標準化されたアプローチでは、スマート コントラクト アカウントの検証、実行、およびフック関数の作成方法を決定する必要があります。 Safe であろうと ERC-6900 であろうと、標準化は特定の実装やエコシステムに特有の独自の開発作業の必要性を減らし、ベンダー ロックインを防ぐのに役立ちます。
モジュールの検出とセキュリティ
オープンな方法でモジュールを見つけて検証する方法: 現在進められているソリューションの 1 つは、ユーザーが検証可能なモジュールを発見できる領域 (「レジストリ」と呼ばれる) を作成することです。レジストリは「アプリ ストア」のように機能し、簡素化されながらも繁栄するモジュラー マーケットプレイスを促進するように設計されています。
安全な{コア}プロトコル
Safe{Core} プロトコルは、明確に定義された標準とルールを通じて強力なセキュリティを維持しながら、さまざまなベンダーや開発者のアクセシビリティを強化するように設計された、スマート コントラクト アカウント用のオープンソースの相互運用可能なプロトコルです。
アカウント: Safe{Core} プロトコルでは、アカウントの概念は柔軟であり、特定の実装に結び付けられません。これにより、さまざまなアカウント サービス プロバイダーが参加できるようになります。
マネージャー: マネージャーは、アカウント、レジストリ、モジュール間のコーディネーターとして機能します。また、セキュリティを担当する権限層としても機能します。
登録センター: 登録センターは、セキュリティ属性を定義し、ERC 6900 などのモジュール標準を実装し、オープンな「アプリケーション ストア」環境を作成して発見可能性とセキュリティを実現することを目指しています。
モジュール: モジュールは機能を処理し、プラグイン、フック、署名バリデータ、関数ハンドラーなどのさまざまな初期タイプを持ちます。開発者は、確立された基準を満たしている限り参加できます。
ラインストーンのデザイン
プロセスは次のように展開されます。
スキーマ定義 (スキーマ) の作成: スキーマは、事前定義されたデータ構造を提供します。ユーザーは、特定のユースケースに合わせてカスタマイズできます。
アーキテクチャに基づいてモジュールを作成する: モジュールとして登録されたスマート コントラクトはバイトコードを取得してアーキテクチャ ID を選択し、データはレジストリに保存されます。
モジュールの証明書を取得する: 認証者/監査人は、アーキテクチャに基づいてモジュールの証明書を提供できます。これらの証明書には、一意の識別子 (UID) と、リンクに使用される他の証明書への参照を含めることができます。これらはチェーン全体に伝播し、ターゲット チェーンが特定のしきい値を満たしていることを確認できます。
リゾルバーを使用して複雑なロジックを実装する: リゾルバー (オプションの設定) が機能します。これらは、モジュールの作成、証明の確立、および破棄中に呼び出すことができます。これらのパーサーを使用すると、開発者は証明構造を維持しながら、複雑で多様なロジックを統合できます。
ユーザーフレンドリーなクエリ アクセス (クエリ): クエリは、フロント エンドから安全な情報にアクセスする方法をユーザーに提供します。
このモデルはまだ初期段階にありますが、分散型かつ協力的な方法で標準を確立する可能性があります。レジストリを使用すると、開発者はモジュールを登録でき、監査人はセキュリティを検証でき、ウォレットを統合でき、ユーザーは簡単にモジュールを見つけて認証情報を検証できます。将来的には次のような用途が考えられます。
アテスター: Safe のような信頼できるエンティティは、Rhinestone と連携して内部モジュールのアテスターとして機能します。同時に、独立した認証者も参加できます。
モジュール開発者: オープン マーケットの形成により、モジュール開発者はレジストリを通じて自分の作品を収益化することが可能になります。
ユーザー: ウォレットや dApp などのユーザーフレンドリーなインターフェイスを通じて参加し、ユーザーはモジュール情報を検査し、さまざまな証明者に信頼を委任できます。
「モジュール レジストリ」の概念は、プラグインおよびモジュールの開発者に収益性の高い道を開きます。それはさらに「モジュール市場」への道を開く可能性があります。一部の側面は Safe チームによって監督される場合がありますが、他の側面は分散型マーケットプレイスとして表示され、全員に貢献を促し、透明性のある監査証跡を提供する場合があります。これを統合することでベンダー ロックインを回避し、より幅広いユーザーにアピールする強化されたユーザー エクスペリエンスを追加することで EVM の拡張をサポートします。
これらの方法は個々のモジュールを保護しますが、より広範なセキュリティに関しては、スマート コントラクト アカウントは絶対確実というわけではありません。コンプライアンスモジュールと統合し、ストレージの競合がないことを証明することは困難な場合があり、このような問題を解決する上でのウォレットまたは AA インフラストラクチャの重要性が浮き彫りになります。
要約する
モジュール式のスマート コントラクト アカウント スタックを活用することで、ウォレット プロバイダーと dApp は技術的なメンテナンスの複雑さから解放されます。同時に、外部モジュール開発者は、パーソナライズされた専門サービスを提供する機会が得られます。ただし、対処する必要がある課題には、柔軟性とセキュリティのバランスを取ること、モジュール標準の推進、ユーザーがスマート アカウントを簡単にアップグレードおよび変更できるようにする標準化されたインターフェイスの実装などが含まれます。
さらに、モジュラー スマート コントラクト アカウント (SCA) は、導入パズルのほんの一部にすぎません。 SCA の可能性を最大限に発揮するには、レイヤー 2 ソリューションが、堅牢なバンドラー インフラストラクチャやピアツーピア メモリ プール、よりコスト効率が高く実現可能な SCA 署名メカニズム、クロスチェーン SCA などの追加のプロトコル層サポートを提供する必要があります。同期および管理メカニズム、およびユーザーフレンドリーなインターフェイスを開発します。
将来的には、SCA の採用がさらに進むでしょうが、いくつかの興味深い疑問も生じます: SCA の注文フローが十分な収益性を確保できるようになったら、従来のマイナー抽出可能価値 (MEV) メカニズムはバンドラーを構築するためにどのように参入し、価値を獲得するのでしょうか?インフラストラクチャが成熟したとき、アカウント抽象化 (AA) は「インテントベース」トランザクションのベースレイヤーとしてどのように機能するのでしょうか?様子を見ましょう。
