モジュール式スマートコントラクトアカウント設計：実用化における技術的課題の解決
TechFlow厳選深潮セレクト
モジュール式スマートコントラクトアカウント設計：実用化における技術的課題の解決
モジュール化されたスマートコントラクトアカウントスタックを利用することで、ウォレットプロバイダーやdAppは技術的なメンテナンスの複雑さから解放される。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Rui S (SevenX Ventures)
翻訳：TechFlow
はじめに
外部所有者アカウント（EOA）からスマートコントラクトアカウント（SCA）への移行は盛んになっており、Vitalik氏自身を含む多くの支持者が存在する。しかし、注目を集めているにもかかわらず、SCAの採用はEOAほど普及していない。その主な課題には、熊相場による影響、移行に関する懸念、署名の問題、ガスコスト、そして最も重要な工学的課題が含まれる。
アカウント抽象化（AA）最大の利点の一つは、コードを使って機能をカスタマイズできる点である。しかし、大きな工学的課題として、AA機能の非相互運用性があり、この断片化は統合を困難にし、ベンダー・ロックインを招く恐れがある。さらに、機能のアップグレードと組み合わせを同時に安全に行うことは複雑になり得る。
モジュラー型アカウント抽象化の登場は、より広範なAA運動の一側面であり、スマートアカウントとそのカスタム機能を分離する革新的なアプローチである。目的は、多様な機能を持つセキュアでシームレスな統合が可能なウォレットを開発するためのモジュラー構造を作ることにある。将来、これは自由なスマートコントラクトアカウント「アプリストア」を実現し、ウォレットやdAppが機能開発に集中するのではなく、ユーザー体験に注力できるようになるかもしれない。
AAの概要
従来のEOAは、シードフレーズ、ガス、クロスチェーン、複数トランザクションなど多くの課題をもたらしている。我々は意図して複雑さを導入したわけではないが、事実としてブロックチェーンは大衆向けに簡単なゲームではない。
アカウント抽象化はスマートコントラクトアカウントを活用し、プログラマブルな検証と実行を可能にする。これにより、ユーザーは個々のトランザクションごとに署名・ブロードキャストを行うのではなく、一連のトランザクションを一度に承認でき、他の機能も実現できる。UX（例：ガス抽象化、セッションキー）、コスト（例：バッチ処理）、セキュリティ（例：ソーシャルリカバリー、マルチシグ）においてメリットがある。現在、AAを実現する方法は2つある：
-
プロトコル層：一部のプロトコル自体がネイティブなAAサポートを提供しており、ZKsyncではEOAでもSCAでも同じフローに従い、単一のmempoolとトランザクションフローでAAをサポートしている。またStarknetはEOAを廃止し、すべてのアカウントをSCAとしており、Argentのようなネイティブスマートコントラクトウォレットを持っている。
-
コントラクト層：イーサリアムおよび同等のL2向けに、ERC4337はコンセンサス層を変更せずに別途トランザクションエントリポイントを設けてAAをサポートしている。Stackup、Alchemy、Etherspot、Biconomy、Candide、Plimicoなどのプロジェクトがバウンダリーインフラを構築しており、Safe、Zerodev、Etherspot、BiconomyなどがスタックやSDKの構築を行っている。
SCA採用のジレンマ
2015年以降、アカウント抽象化（AA）の議論は続いており、今年はERC4337によって注目を集めた。しかし、展開されたスマートコントラクトアカウントの数は依然としてEOAに遠く及ばない。
このジレンマについて深掘りしよう：
-
熊相場の影響：
AAはシームレスログインやガス抽象化といった利点をもたらすものの、現在の熊相場下では教育を受けたEOAユーザーが多く、新規ユーザーではないため、dAppやウォレットにとって採用のインセンティブがない。それでも、CyberconnectのようにAAシステムとガスフリー解決策を導入し、1か月で約36万件のUserOps（AAトランザクション）を達成した先進的なアプリケーションもある。
-
移行障壁：
すでにユーザーと資産を蓄積したウォレットやアプリケーションにとって、資産を安全かつ容易に移行することは依然として課題である。しかし、EIP-7377のような取り組みにより、EOAがワンタイムの移行トランザクションを開始できるようになる。
-
署名問題：
スマートコントラクト自体は、EOAのような秘密鍵を持たないため、自然にメッセージに署名できない。ERC1271のような取り組みによりこの署名が可能になったが、最初のトランザクション前では動作せず、事実上展開されるウォレットに対して課題となる。Ambireが提唱するERC-6492は、ERC-1271の後方互換性を持つ次世代であり、以前の問題を解決する可能性がある。
-
ガスコスト：
標準的なEOAに比べて、SCAのデプロイ、シミュレーション、実行にはより高いコストがかかる。これが採用の障壁となっている。しかし、アカウント作成とユーザーオペレーションの分離、アカウントソルトや存在チェックの削除などを通じてコスト削減の試みが行われている。
-
工学的課題：
ERC-4337チームはeth-infinitismリポジトリを構築し、開発者に基本的な実装を提供している。しかし、異なるユースケースでより詳細または特定の機能を派生させると、統合とデコードが困難になる。
本稿では、第5の問題、すなわち工学的課題について詳しく考察する。
工学的課題を解決するモジュラー型スマートコントラクトアカウント
工学的課題についてさらに詳述すると以下の通り：
-
断片化：現在、さまざまな機能が特定のSCAや独立したプラグインシステムなど異なる方法で有効化されている。それぞれ独自の基準に従っており、開発者はどのプラットフォームをサポートするか決定しなければならない。これによりプラットフォームロックインや重複作業が生じる。
-
セキュリティ：アカウントと機能間の柔軟性は利点だが、セキュリティリスクを高める可能性もある。機能は集団的に監査されるが、独立した評価が欠けるとアカウントの脆弱性リスクが増す。
-
アップグレード性：機能の進化に伴い、機能の追加・交換・削除の能力を維持することが重要である。毎回更新時に既存機能を再デプロイすると複雑さが増す。
これらの問題に対処するため、安全で効率的なアップグレードを保証するアップグレード可能なコントラクト、全体的な開発効率を向上させる再利用可能なコア、異なるフロントエンド間でのスムーズな移行を保証する標準化されたインターフェースが必要である。
これらの概念は共通のアイデアに収束する：モジュラー型アカウント抽象化アーキテクチャ（Modular AA）の構築である。
モジュラー型AAは、より広範なAA運動の中の一分野であり、スマートアカウントをモジュール化し、ユーザーにカスタマイズされたサービスを提供するとともに、開発者が最小限の制約で機能をシームレスに拡張できるようにすることを目指している。
しかし、どの業界でも新しい基準の確立と普及は大きな挑戦である。主要なソリューションが広く受け入れられるまで、初期段階では多数の異なるソリューションが現れるだろう。しかし、4337 SDK、ウォレット開発者、インフラチーム、プロトコル設計者のいずれも、このプロセスを加速するために協力しているのは励みになる。
モジュラー構造：メインアカウントとモジュール
デリゲートコールとプロキシコントラクト
外部コールとデリゲートコール：
delegatecallはcallと似ているが、ターゲットコントラクトを自身のコンテキストで実行するのではなく、呼び出し元コントラクトの現在状態で実行する。つまり、ターゲットコントラクトの状態変更は呼び出し元コントラクトのストレージに適用される。
組み合わせ可能でアップグレード可能な構造を実現するには、「プロキシコントラクト」と呼ばれる基本知識が必要である。
-
プロキシコントラクト：通常のコントラクトはロジックと状態を保持し、デプロイ後に更新できない。プロキシコントラクトは、別のコントラクトをデリゲートコール（delegatecall）する。関数実装を参照することで、プロキシコントラクトの現在状態で実行する。
-
使用例：プロキシコントラクト自体は変更しないが、その背後に新しい実装をデプロイできる。プロキシコントラクトはアップグレード性を提供し、パブリックブロックチェーン上で展開・維持するコストが低い。
セキュリティアーキテクチャ
Safeは、実績のあるセキュリティと柔軟性を備えたモジュラー型スマートアカウント基盤としてリードしており、開発者が多様なアプリケーションやウォレットを構築できるようにしている。注目に値するのは、多くのチームがSafe上に構築したり、その影響を受けていることだ。Biconomyは、Safe上にネイティブ4337と1/1マルチシグを拡張してアカウントをリリースした。Safeは16万4千以上のコントラクトを展開し、307億ドル以上の価値を担保している。Safeは間違いなくこの分野のトップ選択肢である。
Safeの構造
-
Safeアカウントコントラクト：メインプロキシコントラクト（状態あり）
Safeアカウントは、デリゲートコール（delegatecall）を通じてシングルトンコントラクトを呼び出すプロキシコントラクトである。Safeアカウントはオーナー、閾値、実装アドレスを含み、これらはプロキシの変数として設定され、状態を定義する。
-
シングルトンコントラクト：統合センター（状態なし）
シングルトンはSafeアカウントにサービスを提供し、プラグイン、Hook、関数ハンドラー、署名検証器など異なる統合を統合・定義する。
-
モジュールコントラクト：カスタムロジックと機能
モジュールは非常に強力である。モジュラー型の一種として、プラグインは支払いフロー、リカバリメカニズム、セッションキーなど異なる機能を定義でき、Web2とWeb3の間のクロスチェーンブリッジとしてチェーン外データを取得できる。他のモジュールとして、セキュリティ保護のためのHook、任意の命令に応答する関数ハンドラーなどがある。
Safeを採用した場合どうなるか
-
アップグレード可能なコントラクト：
新しいプラグインが導入されるたびに、新しいシングルトンをデプロイする必要がある。ユーザーは自身の好みや要件に応じて、Safeを希望するシングルトンバージョンにアップグレードする自主権を持つ。
-
組み合わせ可能で再利用可能なモジュール：
プラグインのモジュラー特性により、開発者は機能を独立して構築できる。その後、自身のユースケースに応じて自由に選択・組み合わせることができ、高度にカスタマイズ可能なアプローチを促進する。
ERC-2535 Diamondプロキシ
ERC2535とDiamondプロキシについて
ERC2535はDiamondプロキシを標準化したもので、デプロイ後にアップグレード／拡張が可能で、サイズ制限ほぼなしのモジュラー型スマートコントラクトシステムである。これまでにZerodevのKernelやSoul Walletの実験など、多くのチームがその影響を受けている。
Diamond構造とは
-
Diamondコントラクト：メインプロキシコントラクト（状態あり）Diamondはプロキシコントラクトであり、デリゲートコール（delegatecall）を通じて実装から関数を呼び出す。
-
モジュール／プラグイン／ファセットコントラクト：カスタムロジックと機能（状態なし）モジュールまたはファセットと呼ばれるものは、状態のないコントラクトで、その機能を1つまたは複数のDiamondにデプロイできる。独立したコントラクトであり、内部関数、ライブラリ、状態変数を共有できる。
Diamondを採用した場合どうなるか
-
アップグレード可能なコントラクト：Diamondは異なるプラグインを分離して接続する体系的な方法を提供し、diamondCut関数を通じて直接プラグインを追加／置換／削除できる。時間とともに、Diamondに追加できるプラグインの数に制限はない。
-
モジュラーで再利用可能なプラグイン：一度デプロイされたプラグインは任意の数のDiamondで使用でき、デプロイコストを大幅に削減できる。
SafeスマートアカウントとDiamond方式の違い
SafeとDiamondアーキテクチャには多くの類似点があり、どちらもプロキシコントラクトをコアとして依存し、ロジックコントラクトを参照してアップグレード性とモジュラー性を実現している。
しかし、主な違いはロジックコントラクトの扱いにある。以下に詳細を示す：
-
柔軟性：新しいプラグインを有効にする場合、Safeは変更をプロキシ内で実現するためにシングルトンコントラクトを再デプロイする必要がある。一方、Diamondはプロキシ内のdiamondCut関数を通じて直接これを実現する。このアプローチの違いにより、Safeはより高い程度の制御を保持するが、Diamondはより強力な柔軟性とモジュラー性をもたらす。
-
セキュリティ：現在、両構造ともdelegatecallを使用しており、外部コードがメインコントラクトのストレージを操作できる可能性がある。Safeアーキテクチャでは、delegatecallは単一のロジックコントラクトを指すが、Diamondでは複数のモジュールコントラクト（プラグイン）間で使用される。そのため、悪意あるプラグインが別のプラグインを上書きし、ストレージの競合リスクを引き起こし、プロキシの整合性を損なう可能性がある。
-
コスト：Diamond方式に内在する柔軟性は、増大するセキュリティ課題を伴う。これによりコスト要因が増加し、新しいプラグインを追加するたびに包括的な監査が必要になる。これらのプラグインが互いの機能を妨害しないことを確保することが鍵であり、堅牢なセキュリティ基準を維持しようとする中小企業にとっては課題となる。
「Safeスマートアカウント方式」と「Diamond方式」は、プロキシとモジュールに関連する異なる構造の例である。柔軟性とセキュリティのバランスを取ることは極めて重要であり、今後これらの二つのアプローチが互いに補完し合う可能性がある。
モジュール順序：バリデータ、エグゼキュータ、Hook
Alchemyチームが提案したERC6900という標準について紹介することで議論を展開しよう。これはDiamondに着想を得ており、特にERC-4337向けに調整されている。共通インターフェースを提供し、プラグインとウォレット開発者間の作業を調整することで、スマートアカウントにおけるモジュラー化の課題を解決する。
AAのトランザクションプロセスに関しては、検証、実行、Hookの3つの主要プロセスがある。前述したように、プロキシアカウントがモジュールを呼び出すことでこれらのステップを管理できる。異なるプロジェクトで名称は異なっても、基本的なロジックの類似性を理解することが重要である。
-
検証：呼び出し元がアカウントに対する正当性と権限を持っていることを保証する。
-
実行：アカウントが許可するあらゆるカスタムロジックを実行する。
-
Hook：別の関数の前または後に実行されるモジュール。状態を変更したり、呼び出し全体を中止させたりできる。
モジュールを異なるロジックに基づいて分離することは極めて重要である。標準化されたアプローチでは、スマートコントラクトアカウントの検証、実行、Hook関数の記述方法を規定すべきである。SafeであろうとERC6900であろうと、標準化は特定の実装やエコシステムに特化した開発作業の必要性を減らし、ベンダー・ロックインを防ぐのに役立つ。
モジュールの発見とセキュリティ
成長を遂げつつあるソリューションの一つは、ユーザーが検証済みモジュールを発見できる場所を創出することであり、これを「レジストリ」と呼べる。このレジストリは「アプリストア」のようなもので、簡素化されながらも活気あるモジュラー市場を促進することを目的としている。
Safe{Core}プロトコル
Safe{Core}プロトコルは、明確に定義された基準とルールを通じて、さまざまなベンダーと開発者のアクセシビリティを高めつつ、堅牢なセキュリティを維持するオープンソースで相互運用可能なスマートコントラクトアカウントプロトコルである。
-
アカウント：Safe{Core}プロトコルでは、アカウントの概念は柔軟で、特定の実装に制限されない。これにより、さまざまなアカウントサービスプロバイダーが参加できる。
-
マネージャ：マネージャはアカウント、レジストリ、モジュール間の調整者として機能する。また、権限レイヤーとしてセキュリティを担当する。
-
レジストリ：レジストリはセキュリティ属性を定義し、ERC6900などのモジュール基準を強制する。発見とセキュリティのためのオープンな「アプリストア」環境を創出することを目的としている。
-
モジュール：モジュールは機能を処理し、プラグイン、Hook、署名検証器、関数ハンドラーなどさまざまな初期タイプで提供される。確立された基準を満たせば、開発者は貢献できる。
Rhinestone Design
このプロセスの展開は以下の通り：
-
パターン定義の作成：パターンは証明のために使用される事前定義されたデータ構造である。企業は自身の特定のユースケースに応じてパターンをカスタマイズできる。
-
パターンに基づいたモジュールの作成：スマートコントラクトはモジュールとして登録され、バイトコードを取得し、パターンIDを選択する。これらのデータはその後レジストリに保存される。
-
モジュールの証明の取得：証明者／監査人はパターンに基づきモジュールに証明を提供できる。これらの証明には、固有識別子（UID）や他の証明の参照が含まれ、リンク可能である。これらはチェーン上で伝播され、ターゲットチェーン上で特定のしきい値が満たされているか検証できる。
-
解析器による複雑なロジックの実装：解析器はパターン内にオプションで設定できる。モジュール作成、証明生成、取り消しの過程で呼び出される。これにより、証明構造を維持しながらも、複雑で多様なロジックを組み込むことが可能になる。
-
ユーザーに優しい照会アクセス：照会はユーザーがフロントエンドからセキュリティ情報をアクセスする手段を提供する。ここにEIPが見つかる。
このパターンはまだ初期段階だが、分散的で協調的な方法で標準を確立する可能性を秘めている。彼らのレジストリにより、開発者はモジュールを登録でき、監査人はそのセキュリティを検証でき、ウォレットは統合でき、ユーザーはモジュールを簡単に探し、証明情報を確認できる。将来の用途としては以下が考えられる：
-
証明者：Safeのような信頼できる実体は、内部モジュールの証明者としてRhinestoneと協力できる。また、独立した証明者も参加できる。
-
モジュール開発者：オープンマーケットが形成されれば、モジュール開発者はレジストリを通じて自身の作業を商業化できる可能性がある。
-
ユーザー：ウォレットやdAppのようなユーザーに優しいインターフェースを通じて、ユーザーはモジュール情報を確認し、異なる証明者に信頼を委ねることができる。
「モジュールレジストリ」という概念は、プラグインやモジュール開発者に収益化の機会を提供する。また、「モジュールマーケット」の道を開く可能性もある。その一部はSafeチームが監督するかもしれないが、他の部分は去中心化市場として現れ、誰もが貢献し透明な監査記録を提供するようになるかもしれない。このようなアプローチを採用することで、ベンダー・ロックインを避け、より良いユーザー体験を提供して広範なオーディエンスを惹きつけ、EVMのスケーリングを支援できる。
これらの手法は個々のモジュールのセキュリティを保証するが、スマートコントラクトアカウント全体のセキュリティは絶対的ではない。正当なモジュールを組み合わせても、それらがストレージ競合を起こしていないことを証明するのは困難であり、この問題の解決においてウォレットやAAインフラの重要性を強調している。
まとめ
モジュラー型スマートコントラクトアカウントスタックを利用することで、ウォレットプロバイダーとdAppは技術的メンテナンスの複雑さから解放される。同時に、外部のモジュール開発者は個人のニーズに合わせた専門サービスを提供する機会を得る。しかし、解決すべき課題として、柔軟性とセキュリティのバランス、モジュラー型標準の進展、ユーザーが簡単にスマートアカウントをアップグレード・変更できる標準化インターフェースの実装がある。
しかし、モジュラー型スマートコントラクトアカウント（SCA）は採用のパズルの一部にすぎない。SCAの潜在能力を完全に発揮するには、第2層ソリューションからのプロトコル層サポート、強力なバウンダリーインフラとP2P mempool、よりコスト効率的で実現可能なSCA署名メカニズム、クロスチェーンSCAの同期と管理、使いやすいインターフェースの開発も必要である。
我々は広く参加される未来を想像しており、興味深い疑問が浮かぶ：SCAのオーダーフローが十分に利益を生むようになったとき、従来のMEV（マイナーが抽出可能な価値）メカニズムはどのように領域に入り込み、バウンダーを構築して価値を獲得するのか？インフラが成熟したとき、アカウント抽象化（AA）は「インテンションベース」のトランザクションの基盤層となるのか？注目してほしい。この分野は常に進化し続けている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@SevenXVentures
