モジュラー型スマートコントラクトアカウント設計：実用化技術の課題を解決する
モジュール化されたスマートコントラクトアカウントスタックを活用することで、ウォレットプロバイダーとdAppは技術的なメンテナンスの複雑さから解放されます。原文标题：モジュラースマートコントラクトアカウントアーキテクチャと課題
原文作者：Rui S，SevenX Ventures
編訳：深潮 TechFlow
はじめに
外部所有アカウント（EOA）からスマートコントラクトアカウント（SCA）への移行が急速に進展しており、Vitalik本人を含む多くの愛好者から支持を受けています。興奮を呼び起こしているにもかかわらず、SCAの採用はEOAほど普及していません。その鍵となる問題には、ベアマーケットによる課題、移行への懸念、署名の問題、Gasコスト、そして最も重要なエンジニアリングの難題が含まれます。
アカウント抽象（AA）の最も重要な利点の一つは、コードを使用して機能をカスタマイズできることです。しかし、主要なエンジニアリングの課題は、AA機能の相互運用性の欠如であり、この断片化は統合を妨げ、ベンダーロックインの扉を開いてしまいます。さらに、機能を同時にアップグレードし組み合わせる際の安全性を確保することは非常に複雑です。
モジュラーアカウント抽象の出現は、より広範なAA運動の一部であり、この革新的なアプローチは、スマートアカウントをそのカスタマイズ機能から分離することを目指しています。その目標は、多様な機能を持つ安全でシームレスに統合されたウォレットを開発するためのモジュラー構造を作成することです。将来的には、ウォレットやdAppが機能の構築に集中するのではなく、ユーザー体験に焦点を当てる自由なスマートコントラクトアカウント「アプリストア」を実現できるでしょう。
AAの概要
従来のEOAは、シードフレーズ、Gas、クロスチェーン、複数のトランザクションなど、多くの課題を引き起こしました。私たちは複雑さを導入するつもりはありませんでしたが、実際にはブロックチェーンは一般の人々にとって簡単なゲームではありません。
アカウント抽象は、スマートコントラクトアカウントを利用し、プログラム可能な検証と実行を可能にし、ユーザーは各トランザクションごとに署名して放送するのではなく、一度に一連のトランザクションを承認できるようにし、さらに多くの機能を実現します。これは、ユーザー体験（例えば、Gasの抽象化やセッションキー）、コスト（例えば、バッチトランザクション）、および安全性（例えば、ソーシャルリカバリーやマルチシグ）に利益をもたらします。現在、アカウント抽象を実現する方法は2つあります：
プロトコル層：いくつかのプロトコル自体がネイティブアカウント抽象のサポートを提供しており、ZKsyncのトランザクションはEOAからのものであれSCAからのものであれ、同じプロセスに従い、単一のメモリプールとトランザクションプロセスを使用してAAをサポートしています。一方、StarknetはEOAを排除し、すべてのアカウントがSCAであり、Argentのようなネイティブスマートコントラクトウォレットを持っています。
コントラクト層：Ethereumおよびその同等のL2に対して、ERC4337はAAをサポートするための別のトランザクションエントリを導入し、コンセンサス層を変更することなく実現します。Stackup、Alchemy、Etherspot、Biconomy、Candide、Plimicoのようなプロジェクトはバンドラーインフラを構築しており、Safe、Zerodev、Etherspot、BiconomyのようなプロジェクトはスタックやSDKを構築しています。
SCA採用のジレンマ
2015年以来、アカウント抽象（AA）についての議論が続いており、今年はERC4337によって注目を集めました。しかし、デプロイされたスマートコントラクトアカウントの数は依然としてEOAには遠く及びません。
このジレンマを深掘りしてみましょう：
- ベアマーケットの影響：
AAはシームレスなログインやGasの抽象化などの利点をもたらしましたが、現在のベアマーケットを経験している人々は主に教育を受けたEOAユーザーであり、新しいユーザーではないため、dAppやウォレットにはインセンティブがありません。それでも、いくつかの先進的なアプリケーションはAAを段階的に採用しています。例えば、Cyberconnectは彼らのAAシステムと無Gasソリューションを導入することで、わずか1か月で約360,000回のUserOps（AAトランザクション）を促進しました。
- 移行障害：
すでにユーザーと資産を蓄積しているウォレットやアプリケーションにとって、安全かつ便利に資産を移行することは依然として課題です。しかし、EIP-7377のようなイニシアティブは、EOAが一度の移行トランザクションを開始することを可能にします。
- 署名の問題：
スマートコントラクト自体は、EOAのようなプライベートキーを持たないため、メッセージに署名することができません。ERC1271のような取り組みはこの署名を可能にしますが、最初のトランザクションの前にメッセージ署名は機能しないため、反事実的にデプロイされたウォレットには課題をもたらします。Ambireが提案したERC-6492はERC-1271の後方互換性のある後継者であり、以前の問題を解決する可能性があります。
- Gasコスト：
SCAのデプロイ、シミュレーション、および実行は、標準のEOAと比較して高いコストを生じます。これは採用の障害となっています。しかし、アカウント作成とユーザー操作をデカップリングし、アカウントの塩や存在確認を排除することを検討するなど、これらのコストを削減するためのいくつかのテストが行われています。
- エンジニアリングの難題：
ERC-4337チームは、開発者に基本的な実装を提供するeth-infinitismリポジトリを構築しました。しかし、異なるユースケースでより詳細または特定の機能に分岐するにつれて、統合とデコードが難しくなります。
この記事では、5番目の問題であるエンジニアリングの難題について詳しく探ります。
エンジニアリングの難題を解決するためのモジュラースマートコントラクトアカウント
エンジニアリングの難題についてのさらなる説明は以下の通りです：
断片化：現在、さまざまな機能が特定のSCAや独立したプラグインシステムを通じて異なる方法で有効化されています。それぞれが独自の標準に従い、開発者はどのプラットフォームをサポートするかを決定する必要があります。これにより、プラットフォームロックインや重複した努力が生じる可能性があります。
安全性：アカウントと機能間の柔軟性は利点をもたらしますが、同時に安全性の問題を悪化させる可能性もあります。機能は集団監査されるかもしれませんが、独立した評価が欠如しているとアカウントの脆弱性のリスクが高まります。
アップグレード性：機能が進化するにつれて、機能の追加、置き換え、または削除の能力を保持することが非常に重要です。既存の機能を再デプロイするたびに複雑さが増します。
これらの問題に対処するためには、安全で効率的なアップグレードを保証するためのアップグレード可能なコントラクト、全体的な開発効率を向上させるための再利用可能なコア、および異なるフロントエンド間でコントラクトアカウントがスムーズに移行できるようにするための標準化されたインターフェースが必要です。
これらの用語は、モジュラーアカウント抽象アーキテクチャ（Modular AA）を構築するという共通の概念に集約されます。
モジュラーAAは、より広範なAA運動の中での一つの細分野であり、スマートアカウントをモジュール化してユーザーにカスタマイズされたサービスを提供し、開発者が最小限の制約でシームレスに機能を強化できるようにすることを想定しています。
しかし、どの業界においても、新しい標準を確立し普及させることは大きな挑戦です。主要なソリューションが受け入れられるまでの初期段階では、多くの異なるソリューションが存在する可能性があります。しかし、4337 SDK、ウォレット開発者、インフラチーム、プロトコルデザイナーが共にこのプロセスを加速させるために努力していることは励みになります。
モジュラー構造：主アカウントとモジュール
委任呼び出しとプロキシコントラクト
外部呼び出しと委任呼び出し：
delegatecallはcallに似ていますが、ターゲットコントラクトを自身のコンテキストで実行するのではなく、呼び出しコントラクトの現在の状態でターゲットコントラクトを実行します。これは、ターゲットコントラクトが行った状態変更が呼び出しコントラクトのストレージに適用されることを意味します。
可組み合わせかつアップグレード可能な構造を実現するためには、「プロキシコントラクト」と呼ばれる基本的な知識が必要です。
プロキシコントラクト：通常のコントラクトはそのロジックと状態を保存し、デプロイ後は更新できません。プロキシコントラクトは、別のコントラクトを委任呼び出し（delegatecall）します。実装関数を参照することで、プロキシコントラクトの現在の状態で実行されます。
使用ケース：プロキシコントラクトは不変ですが、その背後に新しい実装をデプロイすることができます。プロキシコントラクトはアップグレード性に使用され、公共のブロックチェーン上でのデプロイと維持コストが低くなります。
安全アーキテクチャ
Safeは、実戦で検証された安全性と柔軟性を提供することを目的とした先進的なモジュラースマートアカウントインフラです。多くのチームがSafeの上に構築したり、インスパイアを受けたりしていることは注目に値します。Biconomyは、Safe上でネイティブ4337と1/1マルチシグを拡張することでアカウントを立ち上げました。Safeは164,000以上のコントラクトをデプロイし、307億以上の価値をロックしており、間違いなくこの分野の選択肢です。
Safeの構造
- Safeアカウントコントラクト：主プロキシコントラクト（状態あり）
Safeアカウントはプロキシコントラクトであり、単一のコントラクトを委任呼び出し（delegatecall）します。Safeアカウントには、所有者、閾値、実装アドレスが含まれ、これらはプロキシの変数として設定され、その状態を定義します。
- 単一コントラクト：統合センター（状態なし）
単一コントラクトはSafeアカウントにサービスを提供し、プラグイン、フック、関数ハンドラー、署名検証器などのさまざまな統合を定義します。
- モジュールコントラクト：カスタムロジックと機能
モジュールは非常に強力です。モジュラータイプとして、プラグインは支払いフロー、リカバリメカニズム、セッションキーなどの異なる機能を定義し、Web2とWeb3の間のクロスチェーンブリッジとしてオフチェーンデータを取得します。他のモジュールは、フックとして安全を提供し、関数ハンドラーは任意の指示に応じます。
Safeを採用すると何が起こるか
- アップグレード可能なコントラクト：
新しいプラグインが導入されるたびに、新しい単一コントラクトをデプロイする必要があります。ユーザーは、好みや要件に応じてSafeを必要な単一コントラクトのバージョンにアップグレードする権限を保持します。
- 組み合わせ可能で再利用可能なモジュール：
プラグインのモジュール化特性により、開発者は機能を独立して構築できます。その後、彼らは自分のユースケースに基づいてこれらのプラグインを自由に選択し組み合わせることができ、高度にカスタマイズされたアプローチを促進します。
ERC-2535ダイヤモンドプロキシ
ERC2535とダイヤモンドプロキシについて
ERC2535は、デプロイ後にアップグレード/拡張が可能で、ほぼサイズ制限がないモジュラーなスマートコントラクトシステムであるダイヤモンドプロキシを標準化しました。これまでに、多くのチームがZerodevのKernelやSoul Walletの実験など、これに触発されています。
ダイヤモンド構造とは
ダイヤモンドコントラクト：主プロキシコントラクト（状態あり）ダイヤモンドは、委任呼び出し（delegatecall）を介してその実装から関数を呼び出すプロキシコントラクトです。
モジュール/プラグイン/ファセットコントラクト：カスタムロジックと機能（状態なし）モジュールまたはファセットと呼ばれるものは、無状態のコントラクトであり、その機能を1つ以上のダイヤモンドにデプロイできます。これらは独立したコントラクトであり、内部関数、ライブラリ、状態変数を共有できます。
ダイヤモンドを採用すると何が起こるか
アップグレード可能なコントラクト：ダイヤモンドは、異なるプラグインを隔離し、それらを接続するための体系的な方法を提供し、diamondCut関数を介して直接任意のプラグインを追加/置き換え/削除できます。時間が経つにつれて、ダイヤモンドに追加できるプラグインの数に制限はありません。
モジュール化され再利用可能なプラグイン：デプロイされたプラグインは任意の数のダイヤモンドで使用できるため、デプロイコストが大幅に削減されます。
Safeスマートアカウントとダイヤモンドメソッドの違い
Safeとダイヤモンドアーキテクチャには多くの類似点があり、両者ともにコアとしてプロキシコントラクトに依存し、ロジックコントラクトを参照してアップグレード性とモジュール化を実現しています。
しかし、主な違いはロジックコントラクトの扱いにあります。以下は、より詳細な説明です：
柔軟性：新しいプラグインを有効にする場合、Safeはそのプロキシ内で変更を実現するために単一コントラクトを再デプロイする必要があります。一方、ダイヤモンドはそのプロキシ内のdiamondCut関数を介して直接これを実現します。この方法の違いは、Safeがより高い制御を保持するのに対し、ダイヤモンドはより強力な柔軟性とモジュール化を導入することを意味します。
安全性：現在、両方の構造でdelegatecallが使用されており、外部コードが主コントラクトのストレージを操作することを許可します。Safeアーキテクチャでは、delegatecallは単一のロジックコントラクトを指しますが、ダイヤモンドは複数のモジュールコントラクト（プラグイン）間でdelegatecallを使用します。したがって、悪意のあるプラグインが別のプラグインを上書きする可能性があり、ストレージの競合リスクを引き起こし、プロキシの整合性を損なう可能性があります。
コスト：ダイヤモンドメソッドに固有の柔軟性は、増加した安全性の問題と共存します。これにより、コスト要因が増加し、新しいプラグインを追加するたびに全面的な監査が必要になります。重要なのは、これらのプラグインが互いの機能に干渉しないことを保証することであり、強力な安全基準を維持しようとする中小企業にとっては挑戦です。
「Safeスマートアカウントメソッド」と「ダイヤモンドメソッド」は、プロキシとモジュールに関する異なる構造の例です。柔軟性と安全性のバランスを取ることが重要であり、これらの2つの方法は将来的に相互補完的である可能性があります。
モジュールの順序：検証者、実行者、フック
Alchemyチームが提案した標準ERC6900を紹介することで、私たちの議論を拡張しましょう。この標準はダイヤモンドからインスパイアを受け、ERC-4337に特化して調整されています。これは、一般的なインターフェースを提供し、プラグインとウォレット開発者間の作業を調整することで、スマートアカウントにおけるモジュール化の課題を解決します。
AAのトランザクションプロセスには、主に3つのプロセスがあります：検証、実行、フック。以前に議論したように、プロキシアカウントを使用してモジュールを呼び出すことで、これらのステップを管理できます。異なるプロジェクトが異なる名称を使用するかもしれませんが、類似した基本的なロジックを把握することが重要です。
検証：呼び出し元がアカウントの真正性と権限を持っていることを確認します。
実行：アカウントが許可する任意のカスタムロジックを実行します。
フック：別の関数の前または後に実行されるモジュールとして機能します。状態を変更したり、全体の呼び出しを取り消したりすることができます。
異なるロジックに基づいてモジュールを分離することが重要です。標準化されたアプローチは、スマートコントラクトアカウントの検証、実行、フック関数がどのように記述されるべきかを規定する必要があります。SafeでもERC6900でも、標準化は特定の実装やエコシステムに対するユニークな開発作業の必要性を減らし、ベンダーロックインを防ぐのに役立ちます。
モジュールの発見と安全性
急成長している解決策の一つは、ユーザーが検証可能なモジュールを発見できる場所を作成することです。これを「レジストリ」と呼ぶことができます。このレジストリは「アプリストア」のようなもので、簡素化されたが繁栄するモジュール化市場を促進することを目的としています。
Safe{Core}プロトコル
Safe{Core}プロトコルは、明確に定義された標準とルールを通じて、さまざまなベンダーや開発者のアクセス性を向上させることを目的としたオープンソースの相互運用可能なスマートコントラクトアカウントプロトコルです。
アカウント：Safe{Core}プロトコルにおけるアカウントの概念は柔軟であり、特定の実装に制約されません。これにより、さまざまなアカウントサービスプロバイダーが参加できます。
マネージャー：マネージャーはアカウント、レジストリ、モジュール間の調整者として機能します。また、権限層として安全性を担保します。
レジストリ：レジストリは安全属性を定義し、ERC6900のようなモジュール標準を強制し、発見と安全性のためのオープンな「アプリストア」環境を作成することを目的としています。
モジュール：モジュールは機能を処理し、プラグイン、フック、署名検証器、関数ハンドラーなど、さまざまな初期タイプを提供します。定められた標準を満たす限り、開発者はそれに貢献できます。
Rhinestoneデザイン
このプロセスの展開は以下の通りです：
パターン定義の作成：パターンは証明のための事前定義されたデータ構造として機能します。企業は特定のユースケースに基づいてパターンをカスタマイズできます。
パターンに基づくモジュールの作成：スマートコントラクトはモジュールとして登録され、バイトコードを取得し、パターンIDを選択します。これらのデータはその後、レジストリに保存されます。
モジュールの証明を取得：証明者/監査人は、パターンに基づいてモジュールに証明を提供できます。これらの証明には、ユニークな識別子（UID）や他の証明の参照が含まれ、リンクされます。これらはチェーン上で広がり、特定の閾値が目標チェーン上で満たされているかどうかを検証します。
複雑なロジックを実現するためのパーサーの使用：パーサーはパターン内にオプションとして設定されます。これらはモジュールの作成、証明の構築、撤回のプロセスで呼び出されることができます。これらのパーサーは、証明構造を維持しながら、複雑で多様なロジックを組み込むことを可能にします。
ユーザーフレンドリーなクエリアクセス：クエリは、ユーザーがフロントエンドから安全情報にアクセスする方法を提供します。ここでEIPを見つけることができます。
このパターンはまだ初期段階にありますが、分散的かつ協力的な方法で標準を確立する可能性を秘めています。彼らのレジストリは、開発者がモジュールを登録し、監査人がその安全性を検証し、ウォレットが統合し、ユーザーがモジュールを簡単に見つけてその証明情報を検証できるようにします。将来的には以下のような用途が考えられます：
証明者：信頼できる実体であるSafeは、内部モジュールの証明者としてRhinestoneと協力できます。同時に、独立した証明者も参加できます。
モジュール開発者：オープン市場の形成に伴い、モジュール開発者はレジストリを通じて彼らの作品を商業化する可能性があります。
ユーザー：ウォレットやdAppのようなユーザーフレンドリーなインターフェースを通じて、ユーザーはモジュール情報を確認し、異なる証明者に信頼を委託できます。
「モジュールレジストリ」の概念は、プラグインやモジュール開発者に利益をもたらす機会を提供します。また、「モジュールマーケット」の道を開く可能性もあります。これらの側面の一部はSafeチームによって監督されるかもしれませんが、他の側面は分散型市場として表れ、すべての人が貢献し、透明な監査記録を提供することを招待します。このアプローチを採用することで、ベンダーロックインを回避し、より良いユーザー体験を提供することで、EVMの拡張を支援するより広範なオーディエンスを引き付けることができます。
これらの方法は個々のモジュールの安全性を保証しますが、スマートコントラクトアカウント全体の安全性は絶対的ではありません。合法的なモジュールとそれらがストレージの競合を引き起こさないことを証明することは挑戦であり、ウォレットやAAインフラがこのような問題を解決する上での重要性を強調しています。
まとめ
モジュラーなスマートコントラクトアカウントスタックを活用することで、ウォレットプロバイダーやdAppは技術的なメンテナンスの複雑さから解放されます。同時に、外部モジュール開発者は、個々のニーズに合わせた専門的なサービスを提供する機会を得ることができます。しかし、柔軟性と安全性の間でバランスを取ること、モジュール化標準の進展を促進すること、ユーザーがスマートアカウントを簡単にアップグレードおよび変更できるようにするための標準化されたインターフェースを実装することなど、解決すべき課題が残っています。
しかし、モジュラースマートコントラクトアカウント（SCA）は、採用のパズルの一部に過ぎません。SCAの潜在能力を十分に実現するためには、第二層ソリューションからのプロトコル層のサポート、強力なバンドラーインフラとピアツーピアメモリプール、よりコスト効率が高く実行可能なSCA署名メカニズム、クロスチェーンSCAの同期と管理、ユーザーフレンドリーなインターフェースの開発が必要です。
私たちは、広範な参加が促進される未来を想像しており、いくつかの興味深い質問を引き起こしています：SCAの注文プロセスが十分に利益を上げるようになると、従来のマイナーが価値を抽出する（MEV）メカニズムはどのようにこの領域に入ってくるのでしょうか？インフラが成熟したとき、アカウント抽象（AA）は「意図に基づく」トランザクションの基盤層となるにはどうすればよいのでしょうか？この分野は絶えず進化しているため、今後の展開にご期待ください。
