アカウントの抽象化 (AA) 技術、とりわけERC-4337 は、自己管理型ウォレットのユーザー体験を根本的に変え、大規模な採用に向けて拡張できる可能性があると言われています。しかし、2023年5月が近づいていることを考えると、この規格はまだ初期段階にあることを認識しなければなりません。今現在、機会とリスクが共存しています。

*この記事の内容は、アップグレードの進展により、すぐに古くなる可能性があります。また、個人の見解に基づいています。

ERC4337：

AA（アカウント抽象化）はまだ初期段階の標準ですが、多くの革新的なビルダーがさらなる開発に取り組んでいます。エコシステムのサポートとMetaMaskなどの大型プロダクトの普及という背景のもと、AAは発展を加速し、エキサイティングな成果を生み出すと予想されています。

L2：

AAの採用はL2ソリューションによって異なります。大規模なL2（例えばOptimismやArbitrum）はAAをサポートしていませんが、ZKSyncやStarknetはサポートしています。

Bundlerサービス：

• EVM互換のL2がAAをサポートしていない場合、BundlerサービスはAAをサポートするためのネットワーク上の必要条件となります。
• オープンソースの特性により、Bundlerサービスは非排他的であり、収益化が困難です。ネットワークの安全性、安定性を確保するためには、異なる特性のBundlerサービスを利用する必要があります。
• プライベートなBundlerは、特定のニーズに合わせてプライバシー、セキュリティ、その他の機能をカスタマイズすることで収益化を実現できます。

Paymasterサービス：

• PaymasterサービスはBundlerサービスに比べて集中的であり、コントラクトはオープンソースですが、バックエンドはクローズドです。
• Paymasterサービスは収益化モデルを持ち、法定通貨の入金、交換、ブリッジ、自動支払い、チャット、スポンサーなどの機能と組み合わせて、支払いシーンを強化し、dAppの利用性を向上させることができます。

AAウォレットとSDK：

• AAウォレットは、秘密のキー管理システム、ソーシャルリカバリー、ガス費スポンサー、マルチチェーンアカウントの同期、サポートするブロックチェーンなどの視点から評価できます。
• AAのメリットは、スムーズなログイン体験（Web3 Authはホスティング方式で実現できる）だけではありません。複雑でカスタマイズされたチェーン上のインタラクションでは、AAはdAppに多くの利点をもたらすことができます。
• BDがカギとなります。ほとんどのウォレットはDefiやGameFiを狙っており、エコシステムのサポートを得たり、大型のdAppを説得したり、ブレイクスルーを見つけたりすることに努めています。
• 収益化モデルとしてはさらに探求する必要があります。To Business（To B）モデルではあまり儲けを出さず、ユーザーも増やせません。To Customer（To C）モデルでは、高価値のシーンを見つけて、規模感を増やして収益化する必要があります。交換やブリッジの機能を統合すれば収益化できますが、持続可能なモデルを見つけることが重要です。

‍

‍

暗号資産ウォレットについて知ろう

暗号資産ウォレットの分類

イーサリアムネットワークには、外部所有アカウント (Externally Owned Account, EOA) ウォレットと、コントラクトアカウント (Contract Account, CA) の2種類のアカウントが存在します。MetaMask などの EOA ウォレットは、ユーザーが秘密鍵で制御できるアカウントです。Safe などのコントラクトウォレットは、スマートコントラクトで制御されるアカウントです。EOA ウォレットはシンプルで、個人の暗号通貨の保有量を管理するのに使われますが、コントラクトウォレットはより複雑なルールを持ち、特定の目的に使われることができます。

弱点

EOAウォレットのユーザーは秘密鍵を保護する必要があります。秘密鍵に関するあらゆるミスや不注意は資金の損失につながる可能性があります。そのため、EOAウォレットの使用コストは高く、リスクも高いです。経験豊富な暗号通貨ユーザーであっても、一度のミスや不注意で自分のアカウントのコントロールを失うことがあります。操作が複雑で、ガス代を省略したり、代わりに支払ったりすることができず、ウォレットの機能も限られているというのも、ユーザーの悩みです。

スマートコントラクトウォレットは、それら一部の問題に対する解決策を提供していますが、イーサリアムは現在、すべての操作をEOAからのECDSAで保護されたトランザクションにパッケージ化することを要求しています。これにより、追加のトランザクション料金が発生し、21000 ガス代も多く消費されます。さらに、潜在的な中央集権化のリスクや複雑な操作も伴います。ユーザーは2つのアカウントを管理し、個別のEOAにETHを入金してガス代を支払うか、中央集権化された中継システムに依存する必要があります。

このような過不足が、AAの新しい規格であるERC-4337を生み出しました。

ERC4337の提案：

CAの問題

現在、これらのことはすべてコントラクトウォレットで解決できますが、イーサリアム自体は、すべての内容をECDSAで保護されたEOAのトランザクションにパッケージすることを要求しています。これにより、以下の問題が発生します。

• 追加のトランザクション費用：ユーザー操作はすべてEOAから発行する必要があり、21000 ガス代用が追加で発生します。
• 複雑さと中央集権化：ユーザーは別々のEOAにETHを入金してガス代を支払い、2つのアカウントの残高を管理する必要があります。または、中央集権的な中継システムに依存して支払いを行います。

長年にわたり、イーサリアムベースのブロックチェーン上でアカウント抽象化を実現しようと何度も試みてきました。例えば、EIP-86やEIP-2938などです。しかし、これらの方法はすべてうまくいきませんでした。なぜなら、それらはすべてのコンセンサスを変更する必要があるからです。それは非常に困難なことです。

4337のメカニズム

ERC-4337は、UserOperationという高層の擬似トランザクションオブジェクトを導入することで、アカウント抽象化を実現します。これは、rollupsのようなバンドルの概念に似ています。幸いなことに、この標準により、コンセンサスを変更せずにアカウント抽象化を構築できます。

EIP 4337のモジュール化された設計では、スマートコントラクトウォレットのアカウント抽象化機能を複数のポートに分割しています。

Bundler :

• BundlerはEOAです。すべてのトランザクションはEOAから発行する必要があるため、Bundlerがあれば、ユーザーはEOAの秘密鍵を作成したり覚えたりする必要なく、スマートコントラクトウォレットのトランザクションを触発できます。
• Bundlerの役割：UserOperationを検証し、一連のUserOperationオブジェクトを単一の「バンドルトランザクション」にパッケージします。検証済みのUserOperationの内容を公共またはプライベートのメモリプールにブロードキャストします。
• Bundlerでは以下の方法で利益を得ることができます：UserOperationを実行した後、最高優先費用と実際のガス代の差額を自分のものにします。通常のトランザクションの中継と同様に、Bundlerはバンドルトランザクション内のUserOperationの順序を変更することでMEVを獲得できます。

エントリポイント :

• エントリポイントは、すべてのBundlerがUserOperationを実行するために呼び出す必要があるグローバルなコントラクトです。エントリポイントは、Bundlerとスマートコントラクトウォレットの間の仲介として機能します。
• handleOpでの検証と実行： handleOp関数はUserOperationを入力パラメータとして使用し、まずチェーン上でUserOperationを検証し、指定されたスマートコントラクトウォレットアドレスによって署名されているかどうか、およびウォレットにBundlerを補償するのに十分なガス代があるかどうかをチェックします。検証が成功した場合、関数の署名に従って入力パラメータを実行します。 スマートコントラクトウォレットに入金されたトークンでBundlerにgas費用を支払う：BundlerがEOAを使用してhandleOpをトリガーすると、ガス代が発生します。スマートコントラクトウォレットは自分の残高でガス代を支払うことも、Pymasterに支払いを依頼することもできます。失敗する可能性：ガス代が不足している場合や、検証ステップが失敗している場合などガス代が十分であっても、UserOperationの実行ステップはランタイムエラーなどで失敗する可能性があります。実行の成否にかかわらず、エントリポイントコントラクトはBundlerにhandleOp機能をトリガーするためのガス代を支払います。エントリポイントコントラクトは、スマートコントラクトウォレットにトークンを追加または引き出すための抵当品としての機能を提供します。

スマートウォレット：

スマートコントラクトウォレットのメインコントラクトは、

UserOperation

の検証と実行のステップを分離します。これにより、Bundlerはチェーン外で

UserOperation

を検証できるようになり、悪意のあるトランザクションをガス代を支払わずにフィルタリングできます。

validateOp

関数で検証ステップを定義する：

validateOp

関数は最初にBundlerによってチェーン外で検証され、UserOperationの署名を検証し、スマートコントラクトウォレットに十分なガス代残高があることを確認します。次に、エントリポイントコントラクトによってチェーン上で検証され、UserOperationを実行する前に検証します。

Paymaster :

• Paymasterは、スマートコントラクトウォレットのgas抽象化ロジックを定義します。これには、ERC20同質化トークンを使用してイーサリアムのガス代を支払うことや、ガス代なしでのトランザクションが含まれます。
• Paymasterは、dAppがデプロイしたスマートコントラクトであり、PaymasterのvalidatePaymasterOpをトリガーできます。

Wallet Factory :

• Wallet Factoryは、スマートコントラクトウォレットを作成するためのパブリックコントラクトです。initCodeにWallet Factoryのアドレスと新しいスマートコントラクトウォレットのパラメーターを埋め込むと、Bundlerは指定されたパラメーターでスマートコントラクトを作成するためにWallet Factoryをトリガーします。人気のあるWallet Factoryのコードは完全に監査されているので、Wallet Factoryでウォレットを作成する方法は安全です。
• Wallet Factoryは、エントリーポイントでETHをステークし、UserOperationsに対して良好なサービスを継続的に提供する必要があります。そうすることで、Bundlerからより多くのトラフィックを得ることができます。
• ユーザーは、initCodeで埋められたUserOperationを送信し、BundlerにCAウォレットの作成を要求することができます。
• ユーザーは、特定のカスタムパラメーターを持つWallet Factoryを選択して、自分のCAウォレットをカスタマイズすることができます。

署名アグリゲーター：

• 署名アグリゲーターは、複数のトランザクションの署名をバイトに集約することで、トランザクションの検証と実行を高速化するためのものです。異なるスマートコントラクトウォレットは異なる署名アルゴリズムを使用するので、同じ署名アルゴリズムでUserOperationsを集約する必要があります。
• ガス代の節約：チェーン上の計算には多くのガス代を消費するため、集約署名スキーム（BLSなど）はチェーン上での検証時にガス代を節約できます。
• Bundlerは、複数の署名アグリゲーターコントラクトを使用して複数の集約署名を生成し、一度に一つのUserOperationsを検証するのではなく、複数のUserOperationsを検証します。
• Bundlerは、UserOperationの配列、集約署名、およびアグリゲーターのアドレスをエントリーポイントに渡し、各UserOperationグループはそれぞれの署名アグリゲーターのvalidateSignature関数を呼び出します。
• 検証が成功すると、Bundlerはスマートコントラクトウォレット上でこのセットのUserOperationを実行します。
• アグリゲーターもまた、エントリーポイントコントラクトでETHをステークし、UserOperationに対して正確な記録を維持する必要があります。

AAの利点

• Gas抽象化：

Gas抽象化には、ガス代のないトランザクションや任意のERC20トークンでガス代を支払うことが含まれます。このロジックは、Paymasterコントラクトやリレーを介して実行することができます。AAにとって、多くのスマートコントラクトウォレットは、EIP 4337に準拠したPaymasterコントラクトを自身で実装でき、エントリーポイントコントラクトでトークンをステークしてユーザーのガス代を支払うことができます。

• ソーシャルリカバリー：

プライベートキーが紛失したり漏洩したりした場合、ユーザーは新しいキーを合法的なウォレットの所有者として承認することができます。ソーシャルログインやソーシャルリカバリーのロジックは、一般的にウォレットのメインコントラクトで定義されます。電子メール、マルチシグ、MPC、SWIE（Ethereumでログイン）など、さまざまな方法が利用できます。

• トランザクションバッチング：

トランザクションバッチングは、スマートコントラクトウォレットに固有の機能であり、ウォレットユーザーは単一のチェーン上トランザクションで複数のトランザクションを実行できます。

• クロスチェーンブリッジとコネクタブリッジの統合：

現在、多くのウォレットは、法定通貨の入出金チャネルやクロスチェーンブリッジをウォレットに統合するために、サードパーティのプロバイダと協力しています。これらの入出金チャネルやクロスチェーンブリッジは、ガス代抽象化の中の支払いコントラクト（Paymaster）とさらに統合することができます。

• モジュール化された設計：

AAの最大の利点の一つは、おそらくそのモジュール化されたサービスであり、Bundler、Paymaster、およびその他の部分を柔軟に組み合わせることができます。

AAの欠点

• 手数料が比較的高い（かもしれない）：

ERC-4337を使って単純な送金を行うコストは、通常EOAと呼ばれる伝統的なウォレットを使うよりも高くなります。なぜなら、コントラクトを呼び出す必要があるからです。

しかし、Rollupネットワーク上では、ERC-4337を使って単純な送金を行う方がEOAよりも安くなる可能性があります。なぜなら、署名を集約してメインネット上のデータ量を減らすことができるからです。

• まだ未定の標準：

拡張されたトランザクションのスケーラビリティは攻撃ベクトルを増加させ、新しい標準への移行時に未知のエラーやセキュリティリスクが発生する可能性があります。また、すべてのトランザクションが適切に署名され検証されることを保証するために、強力で安全なグローバルなエントリーポイントコントラクトが必要です。これら課題への対応が試されます。

Layer 2

✅ と ❌ はAAをサポートしているかどうかを示します。

Optimism: ❌

Optimismバージョン1には、スマートコントラクトウォレットのアカウント抽象化を実現するための3つのOVMオペコードがありました。しかし、一貫性と安全性のために、バージョン2ではこれらのオペコードは削除され、アカウント抽象化をサポートするという公式の発表はありませんでした。

Arbitrum: ❌

現在、いくつかのスマートコントラクトウォレットがArbitrum上で構築されていますが、アカウント抽象化をサポートするという公式の発表はありませんでした。

Starknet: ✅

Starknetには、署名を検証し、ガス代を確保する機能を持つスマートコントラクトアカウントのみあります。すべてのアカウントは、これらの機能を実装する必要があります。Starknetは、未実行のトランザクションが発生するのを防ぐために、検証機能が外部コントラクトの状態を呼び出すことを禁止しています。しかし、StarknetとEthereumにはいくつかの違いがあります。例えば、UserOperationsやPaymasterのようなトランザクション費用の抽象化プロトコルがないことや、新しいコントラクトを作成するためにはトークンの残高を持つアカウントが必要であることなどです。また、検証済みのトランザクションが失敗した場合、Starknetのソーターはgas費を受け取ることができませんが、Ethereumとの間ではできます。

zkSync: ✅

zkSyncは、EOAとコントラクトアカウントを区別しません。そのアカウントモデルはEIP 4337に似ており、独立したvalidateTransactiomとexecuteTransaction関数を含みます。Paymasterインターフェースには、validateAndPayForPaymasterTransactionとpostOp関数も含まれます。しかし、両者にはいくつかの違いがあります。例えば、検証プロセス中にデプロイ済みの外部コントラクトや外部ストレージを呼び出す能力などです。Paymasterは、トランザクションの検証中にも外部ストレージを呼び出すことができます。

AAインフラストラクチャ：

現在、Stackup、Etherspot、Candide、Infinistism、Pimlicoなどの優れたプロジェクトがインフラストラクチャの構築に取り組んでいます。

Bundlerサービス：

ビルダー：

• StackupのGolang実装
• CandideのPython実装
• InfinitismのTypeScript実装
• EtherspotのSkandha — TypeScript実装

いくつかのコンセンサス：

公益サービス

ほとんどのBundlerのオープンソース性は、それらが排他的でも競争的でもないことを意味します。どのRPCエンドポイントも、オープンソースのコードをコピーすることでBundlerを実行できます。

収益化の難しさ

Bundlerを実行するRPCエンドポイントがAPIキーでサービス利用料を請求しても、Bundlerサービスは他のインフラストラクチャ（例えば、支払いコントラクトPaymasterなど）よりも収益化が難しいです。なぜなら、Paymasterは第三者の入出金プロバイダーやDeFiプロトコルのアグリゲータープロバイダーと協力して、簡単に手数料差を稼ぐことができるからです。

重要なインフラストラクチャ

UserOperationを検証し実行するには、できるだけ多くのBundlerが必要です。これは、分散化をより良く実現するためです。現在、第三者のBundlerサービスプロバイダーはStackupとeth-infinitismしかありませんので、もっと多くのBundlerサービスプロバイダーが必要です。

メカニズム

• Bundlerは自分でメッセージを伝達し、ユーザーアクションを伝播します。共有メモリプールのように、具体的な事項について合意する必要はありません。
• Bundlerには、スパムをフィルタリングする重要な機能があり、自身の経済的な理由から、メモリプールの安全性を確保するためにできるだけ監視することを望んでいます。

Bundlerサービスの違い：

• Bundlerサービスは、汎用的なインフラストラクチャとしても、ウォレットに特化しても構築できます。ウォレットプロジェクトは、最も基本的なBundlerを優先的に構築する可能性がありますが、第三者プロバイダーは、さまざまなシナリオに対応するためにモジュール化されたBundlerを構築する必要があります。
• Ethereumノードと同様に、Bundlerサービスは、シングルポイントオブフェイルを防ぎ、エコシステムに貢献するために、異なるプログラミング言語で実装されています。
• Bundlerサービスは、プライベートメモリプールとパブリックメモリプールをサポートし、プライベートメモリプールにカスタマイズオプションを提供します。

Paymasterサービス

• Bundlerサービスと比較して、Paymasterサービスは比較的中央集権的で、コントラクトはオープンソースですが、バックエンドはクローズドです。
• Paymasterサービスには収益モデルがあり、法定通貨の入出金、両替、ブリッジ、自動支払い、セッション、スポンサー料などの機能との組み合わせで、dAppの利便性を向上させることができます。

AAウォレットとSDK：

製品評価

• キー管理システム：

　マルチシグロジック（セキュリティ）：2/3や3/5などのマルチシグロジックのみを実現できます。

　シンプルな権限管理（順序）：キーに重みを設定し、アカウント操作に閾値を設定できます。

　ロールベースの権限管理（Unipass）：キーに重みとロールを設定できます。異なるロールは異なる操作を実行できます。各ロールには対応する閾値があります。この閾値を超えると、対応するロールの権限を実行できます。

• ソーシャルリカバリ方法
• gas費用のスポンサー：自前のリレーやBundler + Paymasterを設定する
• マルチチェーンアカウントの同期
• マルチチェーンアドレスの統一
• サポートするブロックチェーン

ビジネス

• ビジネスモデル：To b/ To B+To C / ToC
• dAppsとの協力：各チェーン上のステーブルコインやDeFiなどの巨大なインフラストラクチャ型dAppと協力する
• 実用性：NFTマーケット、launchpadなどを統合する
• 外部サポート：Ethereum財団や他の有名なベンチャーキャピタルからの支援

‍