紹介

外部所有口座(EOA)からスマートコントラクト口座(SCA)への移行は勢いを増しており、 ヴィタリック自身を含む多くの愛好家に受け入れられています。 このような盛り上がりにもかかわらず、SCAの採用はEOAほど普及していません。 その中でも鍵となるのは、弱気相場がもたらす課題、移民の懸念、契約問題、ガスオーバーヘッド、そして最も重要なのはエンジニアリング上の困難である。

Account Abstractions (AA) の最も大きな利点は、コードを使用して機能をカスタマイズできることです。 しかし、エンジニアリング上の大きな課題の1つは、AA機能の相互運用性の欠如であり、断片化が統合を妨げ、ベンダーロックインへの扉を開きます。 さらに、セキュリティを確保しながら、同時に機能のアップグレードと構成を行うことは複雑になる可能性があります。

より広範なAAムーブメントのサブセットとして、この革新的なアプローチにより、スマートアカウントをカスタム機能から分離することができます。 目標は、多様な機能を備えた安全でシームレスに統合されたウォレットを開発するためのモジュール構造を作成することです。 将来的には、スマートコントラクトアカウント用の無料の「アプリストア」を実現し、ウォレットとdAppsを機能の構築から解放し、ユーザーエクスペリエンスに焦点を当てることができます。

この記事を読んだ後、読者は次の洞察を得ることができます。

1. モジュラーアカウント抽象化とは
2. アカウントはモジュールとどのように相互作用しますか
3. モジュールを呼び出す順序は何ですか
4. オープンな方法でモジュールを見つけて検証する方法

AAの簡単なレビュー

SCAランドスケープ

従来のEOAでは、シードフレーズ、ガス、クロスチェーン、複数のトランザクションなど、多くの課題が生じます。 複雑さを導入するつもりはありませんでしたが、実際、ブロックチェーンは大衆にとって簡単なゲームではありません。

Account Abstractionは、スマートコントラクトアカウントを活用して、プログラム可能な検証と実行を可能にし、ユーザーは一連のトランザクションをそれぞれに署名してブロードキャストするのではなく、一度に承認し、さらに多くの機能を実装できます。 ユーザーエクスペリエンスにメリットをもたらします(例: ガスの抽象化、およびセッションキー)、コスト(例: バッチ処理トランザクション)、およびセキュリティ(例: 社会回復、マルチシグ)。 現在、アカウントの抽象化を実現するには、次の 2 つの方法があります。

1. プロトコル層:一部のプロトコル自体はネイティブのアカウント抽象化サポートを提供し、 ZKsync トランザクションはEOAから発信されるか、単一のmempoolとトランザクションフローを使用してAAをサポートするSCAから発信されるかにかかわらず同じフローに従い、 Starknet はEOAを削除し、すべてのアカウントはSCAであり、 Argentのようなネイティブスマートコントラクトウォレットを持っています。
2. コントラクトレイヤー:イーサリアムと同等のL2 ERC4337 、コンセンサスレイヤーを変更せずにAAをサポートするためのトランザクション用の個別のエントリポイントを導入しています。 Stackup 、 Alchemy 、 Etherspot 、Biconomy、 Candide 、 Plimico などのプロジェクトがバンドラー インフラストラクチャを構築しており、 Safe 、 Zerodev 、 Etherspot 、 Biconomy などの多くのプロジェクトがスタックと SDK を構築しています。

👉 AAやERC4337に馴染みのない方は、 SevenXの過去の調査をこちらでご確認ください。

SCA導入のジレンマ

Account Abstraction(AA)のトピックは2015年から議論されており、今年のERC4337によってさらに脚光を浴びました。 しかし、デプロイされたスマートコントラクトアカウントの数は、EOAと比較するとまだ見劣りします。

このジレンマを掘り下げてみましょう。

1. 弱気相場の影響:
   AAはシームレスなログインやガスの抽象化などのメリットを導入していますが、一般的な弱気相場は、新規ユーザーではなく、主に教育を受けたEOAユーザーで構成されているため、dAppsやウォレットに対するインセンティブはありません。 そうは言っても、 サイバーコネクト がAAシステムとガスレスソリューションを導入することで、月に約360,000のUserOps(AAのトランザクション)を牽引したように、主要なアプリはまだAAの採用の途上にあります。
2. 移行の障害:
   ユーザーを蓄積し、EOAに資産を保管しているウォレットやアプリケーションにとって、資産を安全かつ便利に移行することは依然として課題です。 それにもかかわらず、 EIP-7377 のようなイニシアチブにより、EOA は 1 回限りの移行トランザクションを開始できます。
3. 署名の問題:
   スマートコントラクト自体は、EOAのような秘密鍵を持っていないため、当然ながらメッセージに署名することはできません。 ERC1271のような努力はそれを可能にしますが、メッセージ署名は最初のトランザクションまで機能せず、反事実的な展開を使用するウォレットに課題を提起します。また、 Ambire が提案する ERC-6492 は、ERC-1271の後継機であり、以前の問題を解決する可能性があります。
4. ガス間接費:
   SCAのデプロイ、シミュレーション、および実行には、標準のEOAと比較して高いコストがかかります。 これは、採用の抑止力になります。 しかし、アカウント作成とユーザー操作を切り離し、アカウントソルトを廃止し、存在確認を行うことで、これらのコストを削減するための いくつかのテストが検討されています。
5. エンジニアリング上の難しさ:
   ERC-4337チームは、開発者に基本的な実装を提供するために、 eth-infinitismリポジトリ を設定しました。 しかし、さまざまなユースケースに合わせて、より微妙な機能や特定の機能に枝分かれするにつれて、統合とデコードが困難になります。

この記事では、#5の問題であるエンジニアリングの難しさについて掘り下げます。

🤔️

エンジニアリングの難しさに対処するためのモジュール式スマートコントラクトアカウント

エンジニアリングの難しさをさらに詳しく説明すると、次のようになります。

1. フラグメンテーション：
   機能は、特定のSCAによってネイティブに、または独立したプラグインシステムを介して、さまざまな方法で有効になりました。 それぞれが標準に従っているため、開発者はどのプラットフォームを推奨するかを決定する必要があります。 これにより、プラットフォームがロックインされたり、冗長な作業が行われたりする可能性があります。
2. 安全：
   アカウントと機能の柔軟性には利点がありますが、セキュリティ上の懸念が増幅される可能性があります。 機能はまとめて監査される可能性がありますが、独立した評価が行われていないため、アカウントの脆弱性のリスクが高まる可能性があります。
3. アップグレード性:
   機能が進化するにつれて、機能を追加、置換、または削除する機能を保持することが重要です。 更新のたびに既存の機能を再デプロイすると、複雑さが増します。

これらの海域をナビゲートするには、安全で効率的なアップグレードを保証するアップグレード可能な契約、全体的な開発効率を高めるための再利用可能なコア、および契約アカウントが異なるフロントエンド間でスムーズに移行できるようにするための標準化されたインターフェイスが必要です。

これらの用語は、Building a Modular Account Abstraction Architecture (Modular AA) という単一の概念に収束します。

モジュラーAAは、スマートアカウントをモジュール化してユーザー向けにカスタマイズし、開発者が最小限の制限で機能をシームレスに強化できるようにすることを想定している、より広範なAAムーブメントの中のニッチです。

しかし、どの業界でも、新しい標準を設定し、推進することは大きな課題です。 初期段階では、全員がメインのソリューションに落ち着く前に、さまざまなソリューションを目撃する可能性があります。 しかし、4337 SDK、ウォレット開発者、インフラストラクチャチーム、プロトコル設計者など、アカウントの抽象化に取り組んでいる人たちが一丸となってプロセスをスピードアップしているのを見るのは心強いことです。

モジュール構造: 主勘定とモジュール

アカウントは、関数を実現するためにモジュールをどのように呼び出しますか

通話とプロキシ契約の委任

外部呼び出しと委任呼び出し:

delegateCallについて

delegatecall は call と似ていますが、ターゲット コントラクトを独自のコンテキストで実行する代わりに、呼び出し元のコントラクトの現在の状態のコンテキストで実行します。 つまり、ターゲット コントラクトによって行われた状態の変更は、呼び出し元のコントラクトのストレージに対して行われます。

プロキシ コントラクトと delegateCall

コンポーザブルでアップグレード可能な構造を実現するには、「プロキシコントラクト」と呼ばれる基本的な知識が必要です。

1. プロキシ コントラクト: 通常のコントラクトにはロジックと状態が格納され、デプロイ後に更新することはできません。 別のコントラクトへの delegatecall を使用するプロキシ コントラクト。 実装関数を参照することで、プロキシコントラクトの現在の状態で実行します。
2. ユースケース: プロキシ コントラクトは不変のままですが、プロキシの背後に新しい実装をデプロイできます。 プロキシコントラクトはアップグレード性のために使用され、パブリックブロックチェーンへのデプロイと保守が安価です。

安全なアーキテクチャ

安全なアーキテクチャ

安全とは:

Safe は、実証済みのセキュリティと柔軟性を提供するように設計された主要なモジュラースマートアカウントインフラストラクチャであり、開発者が多様なアプリケーションやウォレットを作成できるようにします。 注目すべきは、多くのチームがSafeをベースに構築したり、Safeに触発されたりしていることです。 Biconomyは、ネイティブの4337と1/1マルチシグでSafeを拡張し、 アカウント を立ち上げました。 164,000件以上の契約が展開され、307億を超える価値を秘めているSafeは、間違いなく宇宙のプレミアです。

What's Safeの構造

1. セーフアカウント契約:メインプロキシ契約(ステートフル)
   Safeアカウントは、シングルトンコントラクトをデリゲートコールするため、プロキシコントラクトです。 Safe Accountには所有者が含まれており、しきい値、および実装アドレスはすべてプロキシの変数として設定されるため、その状態が定義されます。
2. シングルトン コントラクト: Integration Hub (ステートレス)
   SingletonはSafeアカウントを提供し、プラグイン、フック、関数ハンドラ、署名バリデーターなどのさまざまな統合を統合して定義します。
3. モジュール コントラクト: カスタム ロジックと機能:
   モジュールは強力です。 モジュラータイプのプラグインは、支払いストリーミング、リカバリーメカニズム、セッションキーなどのさまざまな機能を定義でき、オフチェーンデータを取得することでweb2とweb3の間の架け橋として機能することができます。 安全ガードとしての Hook や Function Handler などの他のモジュールは、あらゆる指示に応答します。

Safeを採用するとどうなるか:

1. アップグレード可能な契約:
   新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要があります。 ユーザーは、自分の好みや要件に合わせて、Safeを希望のシングルトンバージョンにアップグレードする自律性を保持します。
2. コンポーザブルおよび再利用可能なモジュール:
   プラグインのモジュール性により、開発者は機能を独立して作成できます。 その後、ユースケースに基づいてこれらのプラグインを自由に選択して組み合わせることができ、高度にカスタマイズ可能なアプローチを促進します。

ERC-2535ダイヤモンドプロキシ

ERC2535 ダイヤモンドアーキテクチャ

ERC2535ダイヤモンドプロキシについて:

このERC2535は、展開後にアップグレード/拡張でき、実質的にサイズ制限のないモジュール式スマートコントラクトシステムであるダイヤモンドを標準化しています。これまで、ZerodevのKernelやSoul Walletの実験など、多くのチームがそれに触発されてきました。

ダイヤモンド構造とは:

1. ダイアモンド コントラクト: メイン プロキシ コントラクト (ステートフル) ダイアモンドは、デリゲート呼び出しを使用して実装から関数を呼び出すプロキシ コントラクトです。
2. モジュール/プラグイン/ファセットコントラクト:カスタムロジックと機能(ステートレス) モジュールまたはいわゆるファセットは、その機能を1つ以上のダイヤモンドにデプロイできるステートレスコントラクトです。 これらは、内部関数、ライブラリ、および状態変数を共有できる個別の独立したコントラクトです。

ダイヤモンドを採用するとどうなるか:

1. アップグレード可能なコントラクト:Diamondは、異なるプラグインを分離して接続し、それらの間でデータを共有する体系的な方法を提供し、diamondCut関数を使用してプラグインを直接追加/置換/削除します。 時間の経過とともにダイヤモンドに追加できるプラグインの量に制限はありません。
2. モジュール式で再利用可能なプラグイン:デプロイされたプラグインは、デプロイコストを大幅に削減するために、任意の数のダイヤモンドで使用できます。

セーフスマートアカウントとダイヤモンドアプローチの違い:

SafeアーキテクチャとDiamondアーキテクチャの間には類似点がたくさんあり、どちらもプロキシコントラクトをコアに頼り、アップグレード性とモジュール性を実現するためにロジックコントラクトを参照しています。

それにもかかわらず、主な違いは論理コントラクトの処理にあります。 詳しく見てみましょう。

1. 柔軟性：
   新しいプラグインを有効にするコンテキストでは、Safeはプロキシに変更を実装するためにシングルトンコントラクトの再デプロイを必要とします。 対照的に、Diamond はプロキシの diamondCut 関数を使用して直接これを実現します。 このアプローチの違いは、Safeが高度な制御を維持するのに対し、Diamondは柔軟性とモジュール性を高めることを意味します。
2. 安全：
   DelegateCallは、今のところ両方の構造で利用されており、外部コードがメインコントラクトのストレージを操作できるようにすることができます。 Safeアーキテクチャでは、delegatecallは単一のロジックコントラクトを指しますが、Diamondは複数のモジュールコントラクト(プラグイン)にまたがってdelegatecallを使用します。 その結果、悪意のあるプラグインは別のプラグインを上書きする可能性があり、プロキシの整合性を損なう可能性のあるストレージの競合のリスクが生じます。
3. 費用：
   ダイアモンドのアプローチに内在する柔軟性は、セキュリティ上の懸念の増幅と密接に関連しています。 これにより、コスト要因が増加し、新しいプラグインを追加するたびに包括的な監査が必要になります。 重要なのは、これらのプラグインが互いの機能に干渉しないようにすることであり、特に堅牢なセキュリティ基準を維持しようと努力している中小企業にとって課題となります。

「セーフスマートアカウントアプローチ」と「ダイヤモンドアプローチ」は、プロキシとモジュールを含む異なる構造の例として機能します。 柔軟性とセキュリティのバランスをどう取るかが重要であり、将来的にはこれら2つの手法が互いに補完し合う可能性があります。

モジュールシーケンス: バリデーター、エグゼキューター、フック

モジュールを呼び出す順序は何ですか

Alchemy チームが提案し、Diamondにインスパイアされ、ERC-4337専用に調整された標準である ERC6900 を紹介して、議論を広げましょう。共通のインターフェースを提供することで、スマートアカウントのモジュール性の課題に対処し、プラグインとウォレット開発者間の取り組みを調整します。

AAのトランザクションプロセスには、検証、実行、フックの3つの主要なプロセスがあります。 これらの手順はすべて、前に説明したように、プロキシ アカウントを使用してモジュールを呼び出すことで管理できます。 プロジェクトが異なれば名前も異なりますが、基本的なロジックは似ていることを把握することが重要です。

異なる設計の関数名

1. 検証: アカウントに対する呼び出し元の信頼性と権限を確認します。
2. 実行: アカウントが許可するカスタムロジックを実行します。
3. フック: 別の関数の前または後に実行されるモジュールとして機能します。 状態を変更したり、呼び出し全体を元に戻したりできます。

ERC6900

異なるロジックに基づいてモジュールを分離することが重要です。 標準化されたアプローチは、スマートコントラクトアカウントの検証、実行、およびフック関数の記述方法を指示する必要があります。 安全かERC6900かにかかわらず、標準化は、特定の実装またはエコシステムに固有の独自の開発作業の必要性を減らし、ベンダーロックインを防ぐのに役立ちます。

モジュールの検出とセキュリティ

オープンな方法でモジュールを見つけて検証する方法

勢いを増しているソリューションには、ユーザーが検証可能なモジュールを発見できる場所の作成が含まれており、これは「レジストリ」と呼ぶことができます。 このレジストリは「App Store」のように機能し、シンプルでありながら繁栄するモジュラーマーケットプレイスを育成することを目的としています。

セーフ{Core} プロトコル

セーフ{Core} プロトコル

Safe{Core} Protocol は、スマートコントラクトアカウント用のオープンソースで相互運用可能なプロトコルであり、明確に定義された標準とルールを通じて堅牢なセキュリティを維持しながら、さまざまなベンダーや開発者のアクセシビリティを強化するように設計されています。

1. アカウント: Safe{Core} Protocol では、アカウントの概念は柔軟であり、特定の実装に縛られません。 これにより、多様なアカウントサービスプロバイダーが参加できるようになります。
2. マネージャー: マネージャーは、アカウント、レジストリ、およびモジュール間のコーディネーターとして機能します。 また、許可レイヤーとしてのセキュリティも担当します。
3. レジストリ:レジストリは、セキュリティ属性を定義し、モジュールのERC6900などの標準を適用し、発見可能性と安全性の両方のためのオープンな「アプリストア」環境を作成することを目的としています。
4. モジュール: モジュールは機能を処理し、プラグイン、フック、署名バリデーター、関数ハンドラーなど、さまざまな初期タイプがあります。 これらは、確立された標準を満たしていれば、開発者が貢献できるようになっています。

ラインストーンデザイン

ラインストーンデザイン

このプロセスは次のように展開されます。

1. スキーマ定義の作成: スキーマは、構成証明に必要な事前定義済みのデータ構造として機能します。 企業は、特定のユースケースに合わせてカスタマイズできます。
2. スキーマに基づくモジュールの作成:スマートコントラクトはモジュールとして登録され、バイトコードを取得し、スキーマIDを選択します。 このデータは、レジストリ内に格納されます。
3. モジュールの構成証明の取得: 構成証明者/監査者は、スキーマ ベースでモジュールの構成証明を提供できます。 これらの構成証明には、一意の識別子 (UID) と、チェーンのための他の構成証明への参照を含めることができます。 チェーン間で伝播し、宛先チェーンで特定のしきい値が満たされているかどうかを検証できます。
4. リゾルバーを使用した複雑なロジックの実装: リゾルバーは、オプションでスキーマで設定されます。 これらは、モジュールの作成、構成証明の確立、および失効中に呼び出すことができます。 これらのリゾルバーを使用すると、開発者は構成証明構造を維持しながら、複雑で多様なロジックを組み込むことができます。
5. ユーザーフレンドリーなクエリアクセス:クエリは、ユーザーがフロントエンドからセキュリティ情報にアクセスするための手段を提供します。 この EIP はこちらをご覧ください。

このスキーマはまだ初期段階にありますが、分散型で協調的な方法で標準を確立する可能性を秘めています。 レジストリを使用すると、開発者はモジュールを登録でき、監査人はセキュリティを検証し、ウォレットは統合され、ユーザーはモジュールを簡単に見つけて構成証明情報を検証できます。 将来的には、次のような用途が考えられます。

1. アテスター:Safeのような信頼できるエンティティは、社内モジュールのアテスターとしてRhinestoneと協力することができます。 同時に、独立した認証者も参加できます。
2. モジュール開発者: オープンマーケットが具体化するにつれて、モジュール開発者はレジストリを通じて作業を収益化できる可能性があります。
3. ユーザー:ウォレットやdAppsなどのユーザーフレンドリーなインターフェースを介して、ユーザーはモジュール情報を調べ、多様な証明者に信頼を委ねることができます。

「モジュールレジストリ」の概念は、プラグインとモジュールの開発者に収益化の道を開きます。 これにより、「モジュールマーケットプレイス」への道がさらに開かれる可能性があります。 Safeのチームが監督する側面もあれば、分散型マーケットプレイスとして現れ、すべての人に貢献と透明性のある監査記録を招く側面もあります。 これを組み込むことで、ベンダーロックインを回避し、より幅広いユーザーを惹きつける強化されたユーザーエクスペリエンスを追加することで、EVMの拡大をサポートすることができます。

これらのアプローチは単一のモジュールの安全性を保証しますが、スマートコントラクトアカウントのより広範なセキュリティは絶対確実ではありません。 正規のモジュールとストレージの競合がないことを証明することを組み合わせることは困難な場合があり、このような懸念に対処する上でウォレットやAAインフラストラクチャの重要性が浮き彫りになっています。

締めくくりの感想

モジュール式のスマートコントラクトアカウントスタックを利用することで、ウォレットプロバイダーとdAppsは、技術的なメンテナンスの複雑さから解放されます。 一方、外部モジュール開発者には、個々のニーズに合わせた専門的なサービスを提供する機会があります。 ただし、対処すべき課題には、柔軟性とセキュリティのバランスを取ること、モジュール標準を前進させること、ユーザーがスマートアカウントを簡単にアップグレードおよび変更できるようにする標準化されたインターフェイスの実装などがあります。

しかし、モジュール式のスマートコントラクトアカウント(SCA)は、導入のパズルの1つのピースにすぎません。 SCAの可能性を完全に実現するには、堅牢なバンドラーインフラストラクチャとピアツーピアmempool、より費用対効果が高く実現可能なSCA署名メカニズム、クロスチェーンSCAの同期と管理、ユーザーフレンドリーなインターフェースの開発など、レイヤー2ソリューションから追加のプロトコル層サポートが必要です。

将来を見据えると、SCAの注文フローが十分に収益性を持つようになったら、従来のMiner Extractable Value(MEV)メカニズムがバンドラーを構築し、価値を獲得するためにどのように分野に参入するのか、という興味深い疑問が湧いてきます。 インフラストラクチャが成熟したとき、Account Abstractions(AA)は「インテントベース」トランザクションの基盤レイヤーとしてどのように機能できるでしょうか? 乞うご期待。風景は刻々と進化しています。

重要なピース

1. 安全なホワイトペーパー: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. ラインストーンドキュメント: https://docs.rhinestone.wtf/
3. バイコノミードキュメント: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

免責事項：

1. この記事は[SevenX Ventures]からの転載です。 ]です。 すべての著作権は原作者[SevenX Ventures]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。