SevenX Ventures：モジュール化スマートコントラクトアカウントの構造と課題

原文タイトル：《モジュラースマートコントラクトアカウントアーキテクチャと課題》
原文著者：Rui、SevenX Venturesの投資家
原文編訳：Luccy、Joyce、BlockBeats

編者按：

スマートコントラクトアカウント（SCA）の発展は勢いを増しており、Vitalikを含む多くのコア起業家からの支持を受けていますが、SCAの採用には依然として多くの課題が残っています。アカウント抽象（AA）の利点は、コードを使用して機能をカスタマイズできることですが、その相互運用性の欠如は、統合やベンダーロックインの問題を引き起こします。モジュラーアカウント抽象は、多様な機能を持ち、安全でシームレスに統合されたウォレットを開発するためのモジュラー構造を作成することを目的としています。

SevenX Venturesの投資家Ruiは、SCAの採用に直面する5つの主要な課題、すなわち、熊市の影響、移行の難しさ、署名の問題、高額なガスコスト、エンジニアリングの課題を指摘し、エンジニアリングの課題についてさらに議論を深めました。また、モジュラースマートコントラクトアカウントのアーキテクチャを分析した結果、モジュラーSCAは採用の課題のほんの一部に過ぎないことを指摘しました。

SCAの潜在能力を最大限に引き出すためには、Layer 2ソリューションが追加のプロトコル層のサポートを提供し、強力なバンドラーインフラストラクチャとピアツーピアメモリプール、よりコスト効率が高く実行可能なSCA署名メカニズム、クロスチェーンSCAの同期と管理メカニズム、ユーザーフレンドリーなインターフェースの開発などが必要です。

将来的には、現在の課題が徐々に解決され、より多くの人々がSCAを採用することになるでしょうが、その後何が起こるのでしょうか？Ruiはこの点についてもいくつかの興味深い質問を提起しました。BlockBeatsは原文を以下のように編訳します：

外部所有アカウント（EOA）からスマートコントラクトアカウント（SCA）への移行は勢いを増しており、Vitalikを含む多くのコア起業家からの支持を受けています。それにもかかわらず、SCAの採用はEOAほど広範ではありません。この主な問題には、熊市の影響、EOAからSCAへの移行の難しさ、署名の問題、高額なガスコスト、そして最も重要な開発の課題が含まれます。

アカウント抽象（AA）の最も顕著な利点は、コードを使用して機能をカスタマイズできることです。しかし、AA機能の相互運用性の欠如は主要な課題を引き起こし、この分散性はAAの統合を妨げ、ベンダーロックインを強化します。さらに、セキュリティを確保しながらアップグレード可能で組み合わせ可能であることも重要な課題です。

モジュラーアカウント抽象の出現は、AAの発展トレンドの中での一つの細分野であり、この革新的なアプローチはスマートアカウントとそのカスタマイズ機能を分離することができます。その目標は、多様な機能を持ち、安全でシームレスに統合されたウォレットを開発するためのモジュラー構造を作成することです。将来的には、モジュラーアカウント抽象が自由なスマートコントラクトアカウント「アプリストア」を実現し、ウォレットやdAppがユーザー体験の改善に集中できるようにし、機能の構築に過度な労力を費やす必要がなくなるでしょう。

アカウント抽象（AA）の概要

人々がブロックチェーンに接触する過程で、従来のEOAは、助記詞、ガス費用、クロスチェーン操作、多発取引など、多くの課題をもたらしました。

アカウント抽象は、スマートコントラクトアカウントを利用し、プログラム可能な検証（validation）と実行（execution）を許可します。これは、ユーザーが一度に一連の取引を承認できることを意味し、各取引ごとに署名して放送する必要がなくなります。アカウント抽象は、ユーザー体験の改善（ガス抽象やセッションキーなど）、コストの削減（バッチ取引など）、セキュリティの向上（ソーシャルリカバリーやマルチシグなど）など、さらなる機能を実現することもできます。現在、アカウント抽象を実現する方法は2つあります。

· プロトコル層：いくつかのプロトコル自体がローカルアカウント抽象のサポートを提供しており、ZKSync取引は単一のメモリプールと取引フローを使用してAAをサポートします。EOAからでもSCAからでも同じフローに従い、StarknetはEOAを排除し、すべてのアカウントがSCAであり、Argentのようなローカルスマートコントラクトウォレットを持っています。

· コントラクト層：Ethereumや類似のL2に対して、ERC4337はAAをサポートするために共通のメモリプールを導入しました。Stackup、Alchemy、Etherspot、Biconomy、Candide、Plimicoなどはバンドラーインフラを構築しており、Safe、Zerodev、Etherspot、BiconomyなどはバンドラーとSDKを構築しています。

SCA採用の困難

2015年以降、アカウント抽象（AA）についての議論が続いており、今年はERC4337によってさらに注目を集めました。しかし、展開されたスマートコントラクトアカウントの数は、EOAにはまだ遠く及びません。

この困難を深く掘り下げてみましょう：

1、熊市の影響

AAはシームレスなログインやガス抽象などの利点を持っていますが、現在の熊市では、すべてのユーザーが教育を受けたEOAユーザーであり、新しいユーザーはあまりいないため、dAppやウォレットはSCAを採用する動機がありません。それにもかかわらず、一部の先進的なdAppはAAを徐々に採用しています。例えば、Cyberconnectは彼らのAAシステムと無ガスソリューションを導入することで、わずか1か月で約36万回のUserOps（AA取引）を促進しました。

2、移行障害

すでにユーザーと資産を蓄積しているウォレットやアプリケーションにとって、資産を安全かつ便利に移行することは依然として課題です。しかし、EIP-7377のようなソリューションは、EOAが一度の移行取引を開始することを許可します。

3、署名の問題

スマートコントラクト自体はメッセージに署名できません。なぜなら、EOAのようなプライベートキーを持っていないからです。ERC1271のような試みがこれを可能にしましたが、メッセージの署名は最初の取引の前には機能しないため、反事実的にデプロイされたウォレットには課題があります。Ambireが提案したERC-6492はERC-1271との後方互換性を持つ後継者であり、以前の問題を解決できるかもしれません。

4、ガスコスト

標準のEOAと比較して、SCAのデプロイ、シミュレーション、実行にはより高いコストがかかるため、採用の障害の一つとなっています。しかし、現在、アカウント作成とユーザー操作を分離したり、特定のアカウントに関連する「salt」を排除したりするなどのテストが行われています。

5、エンジニアリングの課題

ERC-4337チームは、開発者に基礎的な実装を提供するためにeth-infinitismリポジトリを構築しました。しかし、開発者が異なるユースケースに応じてより詳細で具体的な機能に拡張するにつれて、統合やデコードはさらなる課題に直面します。本稿では、エンジニアリングの課題について深く掘り下げていきます。

モジュラースマートコントラクトアカウントを通じてエンジニアリングの課題を解決する

エンジニアリングの課題は、断片化、安全性、アップグレード可能性の3つの側面にさらに詳述できます。

· 断片化：現在、特定のSCAを通じて機能を有効にする方法や独立したプラグインシステムを通じて、さまざまな方法があります。各プラットフォームとサービスプロバイダーは独自の基準に従い、開発者はどのプラットフォームとサービスプロバイダーをサポートするかを決定します。これにより、潜在的なプラットフォーム（ベンダー）ロックインや冗長な作業が発生する可能性があります。

· 安全性：アカウントと機能のデカップリングは柔軟性の利点をもたらしますが、セキュリティの問題を悪化させる可能性もあります。すべての機能が一緒に監査される可能性があるため、独立した評価が欠如するとアカウントの脆弱性のリスクが高まります。

· アップグレード可能性：アカウントの発展に伴い、機能を追加、置き換え、削除する能力を維持することが非常に重要です。既存の機能を再デプロイするたびに、更新が複雑さを引き起こします。

これらの問題に対処するためには、安全で効率的なアップグレードを確保するためのアップグレード可能なコントラクト、全体的な開発効率を向上させるための再利用可能なコア、異なるフロントエンド間でコントラクトアカウントがスムーズに移行できるようにするための標準化されたインターフェースが必要です。

これらの用語は、モジュラーアカウント抽象アーキテクチャ（モジュラーAA）を構築するという共通の概念に集約されます。

モジュラーアカウント抽象は、広範なAAの発展の中での一つの細分野であり、スマートアカウントをモジュール化し、ユーザーにカスタマイズされたサービスを提供し、開発者が最小限の制約の下でシームレスに機能を強化できるようにすることを想定しています。

しかし、どの業界においても新しい標準を確立し、普及させることは大きな挑戦です。皆が同じ標準を受け入れる前の初期段階では、多くの異なるソリューションが登場する可能性があります。標準化とアカウント抽象の改善に取り組む人々、4337 SDK、ウォレット、インフラストラクチャチーム、プロトコル層の設計者たちがこのプロセスを加速させるために共に努力しているのを見るのは励みになります。

モジュラー構造：主アカウントとモジュール

アカウントがモジュールを呼び出して機能を実現する方法

委任呼び出し（Delegate call）とプロキシコントラクト（proxy contract）

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

委任呼び出しについて

「委任呼び出し」は「呼び出し」と似ていますが、ターゲットコントラクトのコンテキスト内で実行されるのではなく、呼び出しコントラクトの現在の状態のコンテキスト内で実行されます。これは、ターゲットコントラクトが行う状態変更が呼び出しコントラクトのストレージを変更することを意味します。

プロキシコントラクトと委任呼び出し

可組み合わせでアップグレード可能な構造を実現するためには、基本的な概念「プロキシコントラクト」を導入する必要があります。

プロキシコントラクト：通常のコントラクトはそのロジックと状態を保存し、デプロイ後は更新できません。一方、プロキシコントラクトは委任呼び出し（delegate call）を使用して別のコントラクトにデプロイされます。参照を通じて関数を実行し、プロキシコントラクトの現在の状態でそれを実行します。

使用例：プロキシコントラクトは不変ですが、その背後に新しい実装をデプロイできます。プロキシコントラクトはアップグレード可能性を実現し、公共ブロックチェーン上でのデプロイとメンテナンスコストを低く抑えます。

Safeアーキテクチャ

Safeアーキテクチャ

Safeとは：Safeは、実戦での安全性と柔軟性を提供することを目的とした先進的なモジュラースマートアカウントインフラであり、開発者が多様なアプリケーションやウォレットを作成できるようにします。多くのチームがSafeを基に（またはSafeからインスパイアを受けて）アプリを構築しています。例えば、Biconomyはスマートコントラクトアカウントをローンチする際に、ネイティブ4337と1/1マルチシグを使用してSafeを拡張しました。Safeは164,000以上のコントラクトのデプロイを目撃し、307億ドル以上の価値をロックしています。間違いなくこの分野のリーダーです。

Safeの構造には、安全アカウントコントラクト、シングルトンコントラクト、モジュールコントラクトが含まれます。

安全アカウントコントラクト（proxy contract）：主プロキシコントラクト（Stateful）

安全アカウントはプロキシコントラクトです。なぜなら、委任呼び出しはシングルトンコントラクトだからです。安全アカウントには、所有者、閾値、実装アドレスがプロキシに設定された変数が含まれ、これに基づいてその状態が定義されます。

シングルトンコントラクト（singleton contract）：Integration Hub（無状態）

シングルトンコントラクトはSafeアカウントにサービスを提供し、Plugin、Hook、Function Handler、Signature Validatorなどの異なるモジュールコントラクトの統合を定義します。

モジュールコントラクト（modules）：カスタマイズされたロジックと機能

モジュールコントラクトは強力です。プラグインはモジュール化されたタイプとして異なる機能を定義でき、例えば支払いフロー、リカバリーメカニズム、セッションキーなどがあり、Web2とWeb3の間の橋渡しとしてオフチェーンデータを取得することができます。他のモジュールは、セキュリティ保護としてのHookやFunction Handlerとして、任意の指示に応じて応答します。

Safeを採用した後の変化：

アップグレード可能なコントラクト：新しいプラグインを導入するたびに新しいシングルトンをデプロイする必要があります。ユーザーはSafeを必要なシングルトンバージョンにアップグレードする権限を保持します。

可組み合わせで再利用可能なモジュール：プラグインのモジュール化特性により、開発者は機能を独立して開発できます。彼らは自分のユースケースに応じてこれらのプラグインを自由に選択し、組み合わせることで、高度にカスタマイズされたアプローチを形成できます。

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

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

ERC2535はダイヤモンドモデルを標準化したもので、これはデプロイ後にアップグレード/拡張できるモジュラースマートコントラクトシステムであり、サイズ制限がほとんどありません。現在、ZerodevのKernelやSoul Walletの実験など、多くのチームがダイヤモンド構造からインスパイアを受けています。

ダイヤモンド構造とは：

ダイヤモンドコントラクト：主要なプロキシコントラクト（有状態）ダイヤモンドは、委任呼び出しメソッドを使用してその実装から関数を呼び出すプロキシコントラクトです。

モジュール/プラグイン/ファセットコントラクト：カスタマイズされたロジックと機能（無状態）モジュールまたはファセットと呼ばれるものは、機能を1つまたは複数のダイヤモンドにデプロイできる無状態コントラクトです。これらは独立したコントラクトであり、内部関数、ライブラリ、状態変数を共有できます。

ダイヤモンドを採用した後の変化：

アップグレード可能なコントラクト：ダイヤモンドは異なるプラグインを隔離し、それらを接続してデータを共有するためのシステム的な方法を提供し、diamondCut機能を使用して任意のプラグインを直接追加/置き換え/削除できます。時間が経つにつれて、ダイヤモンドに追加できるプラグインの数に制限はありません。

モジュール化され再利用可能なプラグイン：デプロイされたプラグインは任意の数のダイヤモンドで使用できるため、デプロイコストが大幅に削減されます。

Safeスマートアカウントとダイヤモンド方式の違い：

Safeとダイヤモンドアーキテクチャの間には多くの類似点があります。両者はそのコアプロキシコントラクトに依存し、ロジックコントラクトを参照してアップグレード可能性とモジュール化を実現しています。

両者の主な違いは、ロジックコントラクトの処理にあります。具体的には：

· 柔軟性：新しいプラグインを有効にする場合、Safeはそのプロキシ内の変更を実現するためにシングルトンコントラクトを再デプロイする必要があります。それに対して、ダイヤモンドはそのプロキシコントラクト内のdiamondCut関数を通じてこれを直接実現します。このアプローチの違いは、Safeがより高い制御の程度を保持する一方で、ダイヤモンドは強化された柔軟性とモジュール化を導入することを意味します。

· セキュリティ：現在、両方の構造で使用されているものは、外部コードが主コントラクトのストレージを操作することを許可できます。Safeアーキテクチャでは、委任呼び出しは単一のロジックコントラクトを指しますが、ダイヤモンドは複数のモジュールコントラクト-プラグインで委任呼び出しを使用します。したがって、悪意のあるプラグインが別のプラグインを上書きする可能性があり、ストレージの競合のリスクを引き起こし、プロキシの整合性を損なう可能性があります。

· コスト：ダイヤモンド方式では、柔軟性とセキュリティのリスクが同時に存在します。これによりコストが増加し、新しいプラグインを追加するたびに全面的な監査が必要になります。これらのプラグインが互いの機能に干渉しないことを確保することが重要であり、この目的は特に高いセキュリティ基準を維持しようとする中小企業にとって挑戦的です。

「Safeスマートアカウント方式」と「ダイヤモンド方式」は、プロキシとモジュールに関する異なる構造の例です。柔軟性とセキュリティのバランスを取ることが重要であり、これらの2つの方法は今後も進化し、相互に補完し合うでしょう。

モジュールの順序：バリデーター（Validator）、エグゼキューター（Executor）、フック（Hook）

ERC6900を紹介することで、さらに議論を深めましょう。これはAlchemyチームが提案したもので、ダイヤモンドからインスパイアを受け、ERC-4337に特化した標準です。これは、一般的なインターフェースを提供することでスマートアカウントのモジュール化の課題を解決し、プラグインとウォレット開発者間の作業を調整します。

AAの取引プロセスには主に3つのプロセスがあります：検証、実行、フック。前述のように、これらのステップはプロキシアカウントを使用してモジュールを呼び出すことで管理できます。異なるプロジェクトが異なる名称を使用する可能性がありますが、類似の基盤となるロジックを把握することが重要です。

異なる設計における関数名

検証（Validator）：アカウント呼び出し者の真正性と権限を確認します。

実行（Executor）：アカウントが許可する任意のカスタムロジックを実行します。

フック（Hook）：別の関数の前または後に実行されるモジュールとして機能します。状態を変更したり、全体の呼び出しを取り消したりできます。

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

モジュールの発見とセキュリティ

モジュールをオープンな方法で発見し、検証するにはどうすればよいか：進行中の解決策には、ユーザーが検証可能なモジュールを発見できる領域を作成することが含まれます。これを「レジストリ」と呼ぶことができます。このレジストリの機能は「アプリケーションストア」に似ており、簡素化されたが活気に満ちたモジュラー市場を育成することを目的としています。

Safe{Core}プロトコル

Safe{Core}プロトコルは、スマートコントラクトアカウントに対するオープンソースで相互運用可能なプロトコルであり、さまざまなベンダーや開発者のアクセス性を向上させることを目的とし、明確に定義された基準とルールを通じて強力なセキュリティを維持します。

· アカウント：Safe{Core}プロトコルにおけるアカウントの概念は柔軟であり、特定の実装に制約されません。これにより、異なるアカウントサービスプロバイダーが参加できるようになります。

· マネージャー：マネージャーはアカウント、レジストリ、モジュール間の調整役を果たします。また、セキュリティを担当する許可層として機能します。

· 登録センター：登録センターは安全属性を定義し、ERC6900などのモジュール標準を実行します。これは、発見性とセキュリティを実現するためのオープンな「アプリケーションストア」環境を作成することを目的としています。

· モジュール：モジュールは機能を処理し、プラグイン、フック、署名検証器、関数ハンドラーなど、さまざまな初期タイプを持っています。定められた基準を満たす限り、開発者は参加できます。

Rhinestoneデザイン

このプロセスは以下のように展開されます：

· スキーマの定義を作成する：スキーマは事前定義されたデータ構造を提供します。人々は特定のユースケースに合わせてカスタマイズできます。

· スキーマに基づいてモジュールを作成する：モジュールとして登録されたスマートコントラクトはバイトコードを取得し、スキーマIDを選択し、データがレジストリに保存されます。

· モジュールの証明を取得する：証明者/監査員はスキーマに基づいてモジュールに証明を提供できます。これらの証明には、一意の識別子（UID）やリンクに使用される他の証明への参照が含まれる場合があります。これらはクロスチェーンで伝播し、ターゲットチェーンが特定の閾値を満たしているかどうかを検証できます。

· リゾルバーを使用して複雑なロジックを実現する：リゾルバー（オプション設定）は、モジュールの作成、証明の確立、撤回の期間中に呼び出されることがあります。これらのリゾルバーは、開発者が複雑で多様なロジックを統合し、証明構造を維持することを可能にします。

ユーザーフレンドリーなクエリアクセス：クエリはユーザーにフロントエンドから安全情報にアクセスする方法を提供します。

このモデルはまだ初期段階にありますが、分散的かつ協力的な方法で標準を構築する可能性を秘めています。レジストリは、開発者がモジュールを登録し、監査員がその安全性を検証し、ウォレットが統合し、ユーザーがモジュールを簡単に見つけてその証明情報を検証できるようにします。将来的な用途には以下のようなものが考えられます：

· 証明者（attestor）：Safeのような信頼できるエンティティがRhinestoneと協力し、内部モジュールの証明者として機能できます。同時に、独立した証明者も参加できます。

· モジュール開発者（module developer）：オープン市場の形成に伴い、モジュール開発者はレジストリを通じて彼らの作業を貨幣化する可能性があります。

· ユーザー：ユーザーフレンドリーなインターフェース（ウォレットやdAppなど）を通じて参加し、ユーザーはモジュール情報を確認し、異なる証明者に信頼を委託できます。

「モジュールレジストリ」の概念は、プラグインやモジュール開発者に利益を得る道を開きます。これはさらに「モジュール市場」を築くための道を開くことができます。特定の側面はSafeチームが監督する可能性がありますが、他の側面は分散型市場として機能し、すべての人が貢献し、透明な監査記録を提供することを招待します。これを統合することで、ベンダーロックインを回避し、より広範なオーディエンスを引き付けることができるユーザー体験を強化することでEVMの拡張を支援します。

これらの方法は個々のモジュールの安全性を保証することができますが、より広範な安全性の観点から、スマートコントラクトアカウントは万全ではありません。モジュールを組み合わせてそれらがストレージの競合を引き起こさないことを証明することは挑戦的であり、ウォレットやAAインフラストラクチャがこのような問題を解決する上での重要性を強調しています。

まとめ

モジュラースマートコントラクトアカウントスタックを活用することで、ウォレットプロバイダーやdAppは技術的なメンテナンスの複雑さから解放されます。同時に、外部モジュール開発者は個別の専門サービスを提供する機会を得ます。しかし、解決すべき課題には、柔軟性と安全性のバランスを取ること、モジュラー標準を推進すること、ユーザーがスマートアカウントを簡単にアップグレードおよび変更できるようにするための標準化されたインターフェースを実装することが含まれます。

さらに、モジュラースマートコントラクトアカウント（SCA）は採用の課題のほんの一部に過ぎません。SCAの潜在能力を最大限に引き出すためには、Layer 2ソリューションが追加のプロトコル層のサポートを提供する必要があります。例えば、強力なバンドラーインフラストラクチャとピアツーピアメモリプール、よりコスト効率が高く実行可能なSCA署名メカニズム、クロスチェーンSCAの同期と管理メカニズム、ユーザーフレンドリーなインターフェースの開発などです。

将来的には、より多くの人々がSCAを採用することになるでしょうが、いくつかの興味深い質問も生じるでしょう。SCAの注文フローが十分な利益を生むようになると、従来のマイナーが価値を抽出する（MEV）メカニズムはどのようにこの分野に参入し、バンドラーを構築して価値を獲得するのでしょうか？インフラストラクチャが成熟したとき、アカウント抽象（AA）は「意図に基づく」取引の基盤層としてどのように機能するのでしょうか？今後の展開に注目しましょう。