この記事は ERC-6900 に関する学びを記録した記事になります。
記事の内容に不備等あれば是非フィードバックいただきたいです。
対象読者
- Ethereum の AA(Account Abstraction) や、 そのAA の実現を阻む課題を解決する提案 ERC-4337 について概要を理解している人
- ERC-6900 の概要をざっくり理解したい人 (コードの詳細な解説などは、内容が不確定なため省略しています)
AA や ERC-4337 については、多数の日本語記事が有識者によって執筆されてますので、もし詳しく知りたい場合はそちらを参照してください
参考文献
背景
現在、Ethereum にはトランザクションの起点となれるのが EOA のみという制約が、プロトコルの仕様として存在しています。
そのため、ブロックチェーンのあらゆる利用が EOA の署名アルゴリズムに依存してしまい、体験の拡張性や安全性に制限を生んでしまっています。
Ethereumでは、そのアカウントシステムの制限と課題を克服するために、いくつかの提案がなされています。
特に、ERC-4337 による AA は、プロトコルレイヤーの改修を必要とせずに多くのアカウント管理の課題を解決できることから近年注目を集めています。
問題の定義
ERC-4337 が達成する目標の1つとして、各 SCA(スマートコントラクトアカウント) に対する実行と検証のロジックを抽象化するというものがあります。これにより、開発者は実行と検証のロジックをカスタマイズすることで、アカウントに多様な機能を実装することができます。
(EOA の ECDSA署名に縛られない柔軟な署名, サブスクリプション機能, アクセス権限の制御, etc.)
しかし、現在の SCA は、それぞれが独自の機能セットを備えた静的でモノリシックなコントラクトであり、開発者が新しいアカウント機能を提供するには
- 既存の実装をフォークして追加機能を追加する
- 基本実装から開始して、新しい機能セットとともにいくつかの標準コンポーネント (リカバリなど) を再構築
のどちらかの対応を行い、アカウント全体を監査して再度デプロイする必要があるため、開発体験はあまり良くありません。
再度デプロイにより、エンドユーザーの体験にも影響が出る場面も考えられます。
プラグイン/モジュール機構
この問題を解決する方法として挙げられるのが、プラグイン/モジュール機構の実現です。
実際に、いくつかのスマートコントラクトのSDKやフレームワークを提供するプラットフォームでは再利用可能なプラグイン/モジュール機構が構築されています。
- Safe{Core} Protocol の Safe Plugins
- ERC-4337 のウォレット構築フレームワーク ZeroDev の Plugin
しかし、それぞれのプラットフォームがバラバラな規格を提供しているため、プラットフォームへのロックインや、複数プラットフォーム対応のための開発作業の重複の発生を促してしまいます。
解決策の紹介
ERC-6900 (別名 Modular account abstraction) は、ERC-4337 におけるアカウントの機能群が SCA に統合される方法を標準化することを目的としています。
これにより、先述したプラットフォームへのロックインやユーザーの断片化などの課題を最小限に抑えるエコシステムを実現し、開発者とエンドユーザーにとっての使用体験の向上が期待されています。また、機能の再開発を防ぎプラグインの再利用を促すことで安全性はより高くなり、プラグインを利用するウォレット全体のセキュリティ強化にも繋がります。
また、この提案は ERC-4337 準拠した提案となっていますが、ERC-4337 の EntryPoint からの呼び出しに加えて、通常の EOA やその他スマートコントラクトからの直接呼び出しのユースケースもサポートするものとなっています。
EIPより引用
提案されている規格
EIP では3種類のモジュールの動作の規格化が提案されています。
Validation functions
- 利用者の真正性や、アカウントに対する権限を検証する部分
- ここをカスタマイズすることで、EOA の ECDSA署名に縛られない柔軟な署名の実現が可能
- 例) デバイスの Secure Enclave に保存されているパスキーを追加し、このキーをトランザクション作成のデフォルトの方法にする
- ERC-4337 の EntryPoint からの呼び出しに加えて、通常の EOA やその他スマートコントラクトからの直接呼び出しの両方のユースケースをサポートするため、次の2種類のValidation functionsが提案されている
- User Operation Validator functions は ERC-4337 Account のインターフェースに定義されている関数 validateUserOp の呼び出しを処理し、ERC-4337 のユーザーの有効性をチェックする。
- Runtime Validator functions は実行関数の前に実行され、チェックを強制する。一般的なチェックには、所有者のみによる実行の許可が含まれる。
Execution functions
- アカウントが自動的に実行するロジック部分
- ここをカスタマイズすることで、アカウントのなんらかのトリガーに基づいて自動的に実行されるロジックを決められる
- 例) トランザクションで発生したガス代を、同じ価格分のERC-20トークンで支払う
- Execution functions とは別に、Standard execution funcsions と呼ばれる、アカウントによってネイティブに実装される2つの実行関数が存在するこ
- ここからプラグインとして設定された Execution Functions が呼び出されることで、無制限の処理の実行が可能になる
Hooks
- トランザクションの実行前または実行後に実行して、指定されたルールを強制する部分
- 例) 各トランザクションの前に、取引先スマートコントラクトがブラックリストに載っている場合は却下する
- 4種類の Hook が存在し、それぞれ実行されるタイミングが異なる
- Pre User Operation Validation Hook は User Operation Validator の前に実行される。これらは、バリデーターがユーザー操作を通じて実行できるアクションに対する権限を強制できます。
- Pre Runtime Validation Hook は Runtime Validator の前に実行される。これらは、バリデーターが直接呼び出しを介して実行できるアクションに対する権限を強制できます。
- Pre Execution Hook は Execution functions の前に実行される
- Post Execution Hook は Execution functions の後に実行される
SCA への呼び出しは、以下の図に示すように5つのステップで行われ、モジュールの呼び出される順序が決まっています。
EIPより引用
開発者は、ERC-6900で提案されるインターフェースIPlugin に則った形でモジュール動作を実装することで、プラグインとしてのウォレット機能の提供ができます。
また、モジュールの動作の規格に加えて、アカウントのプラグイン追加、更新、削除、検査する方法についても標準規格が提案されています
EIPを見ると長々とコードが貼られていますが、ざっくり説明すると以下
-
installPlugin関数、uninstallPlugin関数、(IPluginManager.solに定義) を使ってプラグイン群の更新ができる -
getXxx関数(IPluginLoupe.solに定義) を使って拡張されたプラグイン群の参照ができる
このあたりのインターフェースは、ERC-2535 (Diamonds, Multi-Facet Proxy) からインスピレーションを受けており、アップグレード・拡張が可能かつ、サイズの制限がない SCA の規格を実現しています。
これらの規格を満たした SCA は、動的にプラグインを切り替えられるコントラクトとなり、新しいアカウント機能を提供する際、開発者は既存プラグインの選定や新規プラグイン開発などより本質的な部分に集中できるようになります。
まとめ
- 現在の SCA は、それぞれが独自の機能セットを備えた静的でモノリシックなコントラクトであり、開発者が新しいアカウント機能を提供するには再度デプロイする必要があるため、開発者・ユーザーの体験に課題がある。
- この問題を解決する方法として挙げられるのが、プラグイン/モジュール機構の実現であり、すでにいくつかのプラットフォームがそれに取り組んでいるが、各プラットフォームがバラバラな規格を提供しているため、プラットフォームへのロックインや、複数プラットフォーム対応のための開発作業の重複の発生を促してしまう。
- ERC-6900 は、SCA の機能群と、その管理方法を標準化することで、プラットフォームへのロックインやユーザーの断片化、機能の再開発によるセキュリティの低下などの課題を最小限に抑えるエコシステムの実現を目指している。
- この提案は ERC-4337 の EntryPoint からの呼び出しに加えて、通常の EOA やその他スマートコントラクトからの直接呼び出しのユースケースもサポートするものとなっている。
- モジュールの動作は、利用者の検証部、アカウントが自動的に実行するロジック部分、トランザクションの実行前/後にルールを強制する部分の3つに分けて規格化されている
- ERC-2535 からインスピレーションを受けたインターフェースにより、アップグレード・拡張が可能かつ、サイズの制限がない SCA の規格を実現している。
- これらの規格を満たした SCA は、動的にプラグインを切り替えられるコントラクトとなり、新しいアカウント機能を提供する際、開発者は既存プラグインの選定や新規プラグイン開発などより本質的な部分に集中できるようになります。
参考文献
Discussion