元のタイトル: モジュラー スマート コントラクト アカウントのアーキテクチャと課題原作者：Rui S、SevenX Venturesオリジナル編集: Deep Chao TechFlow＃＃＃ 導入外部所有アカウント (EOA) からスマート コントラクト アカウント (SCA) への移行は急速に進んでおり、Vitalik 氏自身を含む多くの愛好家によって支持されています。盛り上がりにもかかわらず、SCA の採用は EOA ほど普及していません。主要な問題には、弱気市場の課題、移行の懸念、署名の問題、ガスのオーバーヘッド、そして最も重要なエンジニアリングの課題が含まれます。アカウント抽象化 (AA) の最も重要な利点の 1 つは、コードを使用して機能をカスタマイズできることです。ただし、エンジニアリング上の主要な課題は、AA 機能の相互運用性の非相互運用性であり、この断片化により統合が妨げられ、ベンダー ロックインへの扉が開かれます。さらに、機能のアップグレードと結合を同時に行う際のセキュリティの確保は複雑になる場合があります。モジュラー アカウントの抽象化は、より広範な AA 運動のサブセットとして登場し、スマート アカウントをカスタム機能から切り離す革新的なアプローチです。目標は、モジュール構造を作成して、多様な機能を備えた安全でシームレスに統合されたウォレットを開発することです。将来的には、無料のスマート コントラクト アカウント「アプリ ストア」を実装して、ウォレットと dApp が機能の構築に焦点を当てるのではなく、ユーザー エクスペリエンスに焦点を当てることができるようになります。### AA の簡単な説明従来の EOA では、シード フレーズ、ガス、クロスチェーン、複数のトランザクションなど、多くの課題が発生します。私たちは複雑さを導入するつもりはありませんでしたが、現実にはブロックチェーンは大衆にとって簡単なゲームではありません。アカウントの抽象化はスマート コントラクト アカウントを活用し、プログラム可能な検証と実行を可能にし、ユーザーが各トランザクションに署名してブロードキャストするのではなく、一連のトランザクションを一度に承認できるようにし、より多くの機能を有効にします。これは、ユーザー エクスペリエンス (ガス抽象化やセッション キーなど)、コスト (バッチ処理されたトランザクションなど)、セキュリティ (ソーシャル リカバリ、マルチ署名など) にメリットをもたらします。現在、アカウントの抽象化を実装するには 2 つの方法があります。* プロトコル層: 一部のプロトコル自体は、ローカル アカウント抽象化サポートを提供します ZKsync トランザクションは、EOA または SCA からのものであっても、同じプロセスに従い、単一のメモリ プールとトランザクション プロセスを使用して AA をサポートしますが、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 よりもはるかに少ないです。このジレンマをさらに深く掘り下げてみましょう。*弱気市場の影響: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 番目の問題であるエンジニアリング上の課題を詳しく掘り下げていきます。## エンジニアリング上の問題を解決するモジュール式スマート コントラクト アカウントエンジニアリング上の課題についてさらに詳しく説明すると、次のとおりです。* 断片化: 特定の SCA または独立したプラグイン システムを通じて、さまざまな機能がさまざまな方法で有効になるようになりました。それぞれが独自の標準に従っているため、開発者はどのプラットフォームをサポートするかを決定する必要があります。これにより、プラットフォームのロックインや作業の重複が発生する可能性があります。* セキュリティ: アカウントと機能間の柔軟性は利点をもたらしますが、セキュリティ上の懸念を悪化させる可能性もあります。機能はまとめて監査できますが、独立した評価がないとアカウント侵害のリスクが高まる可能性があります。* アップグレード可能性: 機能が進化するにつれて、機能を追加、置換、または削除できる機能を維持することが重要です。更新のたびに既存の機能を再デプロイすると、複雑さが生じます。これらの問題に対処するには、安全かつ効率的なアップグレードを保証するためのアップグレード可能なコントラクト、全体的な開発効率を向上させるための再利用可能なコア、およびコントラクト アカウントが異なるフロントエンド間でスムーズに移行できるようにするための標準化されたインターフェイスが必要です。これらの用語は、モジュラー アカウント抽象化アーキテクチャ (モジュラー 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 の実験など、多くのチームがそれにインスピレーションを受けてきました。### ダイヤモンドの構造は何ですか?* ダイヤモンド コントラクト: メイン エージェント コントラクト (ステートフル) ダイヤモンドは、デリゲート呼び出しを通じて実装から関数を呼び出すプロキシ コントラクトです。* モジュール/プラグイン/ファセット コントラクト: カスタム ロジックと機能 (ステートレス) モジュールまたはいわゆるファセットは、その機能を 1 つ以上の Diamond にデプロイできるステートレス コントラクトです。これらは、内部関数、ライブラリ、状態変数を共有できる独立したコントラクトです。## ダイヤモンドを使用するとどうなるか* アップグレード可能な契約: Diamond は、さまざまなプラグインを分離して相互に接続し、diamondCut 関数を通じて直接プラグインを追加/置換/削除する体系的な方法を提供します。 Diamond に追加できるプラグインの数に制限はありません。* モジュール式で再利用可能なプラグイン: 導入されたプラグインは任意の数の Diamond で使用できるため、導入コストが大幅に削減されます。## 安全なスマート アカウントとダイヤモンド方式の違いSafe アーキテクチャと Diamond アーキテクチャには多くの類似点があり、どちらもコアとしてプロキシ コントラクトに依存し、アップグレード可能性とモジュール性のためにロジック コントラクトを参照しています。ただし、主な違いは論理契約の処理にあります。詳しい手順は次のとおりです。* 柔軟性: 新しいプラグインを有効にすると、Safe はエージェントに変更を実装するためにシングルトン コントラクトを再デプロイする必要があります。対照的に、Diamond はデリゲートの DiamondCut 関数を通じてこれを直接実行します。このアプローチの違いは、Safe が高度な制御を維持するのに対し、Diamond はより優れた柔軟性とモジュール性を導入していることを意味します。* セキュリティ: 現在、両方の構造で delegatecall が使用されており、これにより外部コードがメイン コントラクトのストレージを操作できるようになります。 Safe アーキテクチャでは、delegatecall は単一の論理コントラクトを指しますが、Diamond は複数のモジュール コントラクト (プラグイン) 間で delegatecall を使用します。したがって、悪意のあるプラグインが別のプラグインを上書きする可能性があり、その結果、エージェントの整合性が損なわれる可能性のあるストレージ競合のリスクが生じます。* コスト: ダイヤモンド アプローチに固有の柔軟性には、セキュリティ上の懸念が増大します。これによりコスト要因が増加し、新しいプラグインが追加されるたびに完全な監査が必要になります。重要なのは、これらのプラグインが相互の機能を干渉しないようにすることですが、これは強力なセキュリティ標準を維持しようとしている中小企業にとっては課題となる可能性があります。「安全なスマート アカウント方式」と「ダイヤモンド方式」は、エージェントとモジュールが関与するさまざまな構造の例です。柔軟性とセキュリティのバランスをどのように取るかが重要であり、2 つのアプローチは将来的に相互補完する可能性があります。### モジュールの順序: バリデータ、エグゼキュータ、フックAlchemy チームによって提案された標準、ERC 6900 を紹介して議論を広げましょう。この標準は、Diamond からインスピレーションを得て、特に ERC-4337 に適合させたものです。共通のインターフェイスを提供し、プラグインとウォレットの開発者間の作業を調整することで、スマート アカウントのモジュール性の課題を解決します。AA のトランザクション プロセスには、検証、実行、フックという 3 つの主要なプロセスがあります。前に説明したように、これらの手順は、プロキシ アカウントを使用してモジュールを呼び出すことで管理できます。プロジェクトごとに異なる名前が使用される場合がありますが、同様の基礎となるロジックを把握することが重要です。* 検証: 発信者のアカウントの信頼性と権限を確認します。* 実行: アカウントで許可されているカスタム ロジックを実行します。*フック: 別の関数の前または後に実行されるモジュールとして。状態が変更されたり、呼び出し全体が取り消されたりする可能性があります。異なるロジックに基づいてモジュールを分離することが重要です。標準化されたアプローチでは、スマート コントラクトのアカウント検証、実行、およびフック関数をどのように記述するかを指定する必要があります。 Safe であろうと ERC 6900 であろうと、標準化は特定の実装やエコシステムに対する独自の開発作業の必要性を減らし、ベンダー ロックインを防ぐのに役立ちます。### モジュールの検出とセキュリティブームになっているソリューションの 1 つは、ユーザーが検証可能なモジュールを発見できる場所、いわゆる「レジストリ」を作成することです。このレジストリは、簡素化されながらも繁栄するモジュラー マーケットプレイスを促進するために設計された「アプリ ストア」に似ています。## 安全な{コア}プロトコルSafe{Core} プロトコルは、強力なセキュリティを維持しながら、明確に定義された標準とルールを通じてさまざまなベンダーや開発者のアクセシビリティを高めるように設計された、オープンソースの相互運用可能なスマート コントラクト アカウント プロトコルです。* アカウント: Safe{Core} プロトコルでは、アカウントの概念は柔軟であり、特定の実装によって制限されません。これにより、さまざまなアカウント サービス プロバイダーが参加できるようになります。* マネージャー: マネージャーは、アカウント、レジストリ、モジュール間の調整役として機能します。また、セキュリティを担当し、アクセス許可レイヤーとして機能します。* レジストリ: レジストリはセキュリティ属性を定義し、ERC 6900 などのモジュール標準を強制し、検出とセキュリティのためのオープンな「アプリ ストア」環境を作成することを目的としています。* モジュール: モジュールは機能を処理し、プラグイン、フック、署名バリデータ、関数ハンドラーなどのさまざまな初期タイプで提供されます。開発者は、確立された標準を満たしている限り、それに貢献できます。## ラインストーンのデザインプロセスは次のように展開されます。* スキーマ定義の作成: スキーマは証明用の事前定義されたデータ構造として機能します。企業は、特定のユースケースに基づいてパターンをカスタマイズできます。* パターンに基づいてモジュールを作成します。スマート コントラクトがモジュールとして登録され、バイトコードを取得し、パターン ID を選択します。このデータはレジストリに保存されます。* モジュールの証明を取得する: 認証者/監査人は、スキーマに基づいてモジュールの証明を提供できます。これらの証明書には、一意の識別子 (UID) と、リンク用の他の証明書への参照を含めることができます。これらはチェーン上で伝播され、ターゲット チェーン上で特定のしきい値が満たされていることを確認できます。* 複雑なロジックを実装するにはパーサーを使用します。パーサーはオプションでパターンに設定されます。これらは、モジュールの作成、証明の確立、および破棄中に呼び出すことができます。これらのパーサーを使用すると、開発者は証明の構造を維持しながら、複雑で多様なロジックを組み込むことができます。* ユーザーフレンドリーなクエリ アクセス: クエリは、ユーザーがフロントエンドからセキュリティ情報にアクセスする方法を提供します。 EIP はここで見つけることができます。このモデルはまだ初期段階にありますが、分散型かつ協力的な方法で標準を確立する可能性があります。レジストリを使用すると、開発者はモジュールを登録でき、監査人はセキュリティを検証でき、ウォレットを統合でき、ユーザーは簡単にモジュールを見つけて認証情報を検証できます。将来的には以下のような用途が考えられます。* 認証者: Safe などの信頼できるエンティティは、内部モジュールの認証者として Rhinestone と協力できます。同時に、独立した証明者も参加できます。* モジュール開発者: オープン マーケットの形成により、モジュール開発者はレジストリを通じて自分の作品を商業化することが可能になります。* ユーザー: ウォレットや dApps などの使いやすいインターフェイスを通じて、ユーザーはモジュール情報を表示し、さまざまな証明者に信頼を委任できます。「モジュール レジストリ」の概念は、プラグインおよびモジュールの開発者に有益な機会を提供します。 「モジュール市場」への道を開く可能性もある。これらの側面の一部は Safe チームによって監督される可能性がありますが、その他の側面は、誰もが貢献して透明性のある監査証跡を提供する分散型マーケットプレイスとして現れる可能性があります。このアプローチを採用することで、ベンダー ロックインを回避し、より幅広いユーザーにアピールする優れたユーザー エクスペリエンスを提供することで EVM の拡張をサポートできます。これらの方法は個々のモジュールのセキュリティを保証しますが、スマート コントラクト アカウントの全体的なセキュリティは完全に信頼できるわけではありません。正規のモジュールを結合し、ストレージの競合がないことを証明することは困難な場合があり、そのような問題を解決するにはウォレットや AA インフラストラクチャの重要性が強調されます。## 要約するモジュール式のスマート コントラクト アカウント スタックを活用することで、ウォレット プロバイダーと dApp は技術的なメンテナンスの複雑さを回避できます。同時に、外部モジュール開発者は、個々のニーズに合わせた専門的なサービスを提供する機会を得られます。ただし、対処する必要がある課題には、柔軟性とセキュリティのバランスをとること、モジュール標準の進歩を推進すること、ユーザーがスマート アカウントを簡単にアップグレードおよび変更できるようにする標準化されたインターフェイスの実装などが含まれます。ただし、モジュラー スマート コントラクト アカウント (SCA) は、導入パズルの 1 ピースにすぎません。 SCA の可能性を最大限に発揮するには、強力なバンドラー インフラストラクチャとピアツーピア メモリ プール、よりコスト効率が高く実現可能な SCA 署名メカニズム、クロスチェーン SCA 同期に加えて、第 2 層ソリューションからのプロトコル層サポートも必要です。ユーザーフレンドリーなインターフェイスの開発だけでなく、管理も行います。私たちは幅広い参加者が参加する未来を構想していますが、これによりいくつかの興味深い疑問が生じます。SCA 注文プロセスが十分な収益を上げられるようになったら、従来のマイナー抽出可能価値 (MEV) メカニズムがどのようにこの領域に参入し、バンドラーを構築し、価値を獲得するのでしょうか?インフラストラクチャが成熟すると、アカウント抽象化 (AA) はどのようにして「インテントベース」トランザクションのベースレイヤーになるのでしょうか?この分野は常に進化しているので、ご期待ください。
モジュール式スマート コントラクト アカウント設計に関する詳細なディスカッション: 実装における技術的問題の解決
元のタイトル: モジュラー スマート コントラクト アカウントのアーキテクチャと課題
原作者：Rui S、SevenX Ventures
オリジナル編集: Deep Chao 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) はどのようにして「インテントベース」トランザクションのベースレイヤーになるのでしょうか?この分野は常に進化しているので、ご期待ください。