アカウントの抽象化ERC4337を理解することは、イーサリアムアカウントの進化にどのようにつながるのでしょうか?

著者: Rui

多くの人が言っているように、アカウント抽象化(AA)技術、特にERC-4337は、セルフカストディウォレットのユーザーエクスペリエンスに革命をもたらし、大量採用のために拡張できるようにすることを約束します。 しかし、2023年5月が近づくにつれ、この規格はまだ初期段階にあり、機会とリスクの両方があることを認識する必要があります。

この記事の内容は、アップグレードが急速に進化するにつれてすぐに古くなる可能性があり、この記事はあくまでも私の個人的な意見に基づいていることに注意してください。

TL; 博士

ERC4337:

AA規格はまだ初期段階にありますが、多くのイノベーションビルダーがさらなる開発に取り組んでいます。 エコシステムのサポートとMetaMaskなどの大規模製品の人気により、AAは開発プロセスを加速させ、エキサイティングな結果を生み出すことが期待できます。

L2:

AA の採用は、L2 ソリューションによって異なります。 より大きなL2(OptimismやArbitrumなど)はAAをネイティブにサポートしていませんが、ZKSyncとStarknetはサポートしています。

バンドラー サービス:

• AAに強気で、イーサリアムにアライメントされたEVMと同等のL2がすべてネイティブAAをサポートしていない場合、ネットワークでAAをサポートするにはBundlerサービスが必要です。 ※オープンソース機能により、Bundlerサービスが非独占的になるため、収益化が難しくなります。 ネットワークの安定性を確保するには、さまざまな Bundler サービスを使用する必要があります。
• プライベートバンドラーは、プライバシー、セキュリティ、その他の機能を特定のニーズに合わせてカスタマイズすることで収益化できます。

Paymasterサービス:

• Paymasterサービスは(Bundlerサービスと比較して)比較的中央集権的であり、コントラクトはオープンソースですが、バックエンドは閉じられています。
• Paymasterサービスには、法定通貨の入金、交換、ブリッジ、自動支払い、セッション、スポンサー料などの機能と組み合わせて、支払いシナリオを強化し、dAppの使いやすさを向上させることができる収益化モデルがあります。

AA ウォレットと SDK:

• AA Walletは、秘密鍵管理システム、ソーシャルリカバリー、ガス料金スポンサーシップ、マルチチェーンアカウント同期、サポートされているブロックチェーンなど、製品の観点から評価できます。
• AAの利点は、スムーズなログイン体験を提供するだけではありません(Web3認証がホストされています)。 また、AAは、複雑でカスタマイズされたオンチェーンインタラクションにおいて、dAppsに多くのメリットを提供することができます。 ※この戦いのカギを握るのがBDです。 ほとんどのウォレットはDefi、GameFiをターゲットとしており、エコシステムのサポートを獲得し、大規模なdAppsを説得し、ブレークスルーを見つけることを目的としています。 *収益化モデルはさらに調査する必要があります。 To Business(To B)モデルはあまり収益を上げず、独自のユーザーを蓄積しない可能性がありますが、To Customer(To C)モデルは、価値の高いシナリオを見つけ、ボリュームに基づいて利益を上げる必要があります。 スイッチング機能とブリッジング機能を統合することは有益ですが、重要なのは持続可能なモデルを見つけることです。

クリプトウォレットについて学ぶ

分類

イーサリアムネットワークには、MetaMaskなどの外部所有アカウント(EOA)ウォレットと、Safeなどのコントラクトアカウント(CA)の2種類のアカウントがあります。

EOAウォレットとコントラクトウォレットの主な違いは、その管理方法です。 EOAウォレットは秘密鍵を介して個々のユーザーによって制御されますが、コントラクトウォレットはスマートコントラクトによって制御されます。 EOAウォレットはよりシンプルで、個人の暗号資産の保有を管理するために使用されますが、コントラクトウォレットはより複雑なルールを持つことができ、特定の目的に使用できます。

差出人ビットコインインサイダー

問題点

EOAウォレットのユーザーは、秘密鍵の保護に注意を払う必要があります。 秘密鍵の間違いや脱落は資金の損失につながる可能性があるため、EOAウォレットの使用はより高価でリスクが高くなります。 経験豊富な暗号資産ユーザーでさえ、1つのミスや不注意な動きにより、アカウントの制御を失う可能性があります。 操作の複雑さ、ガス代をスキップしたり、ガス料金を支払ったりできないこと、ウォレットの機能の制限はすべて、ユーザーを悩ませる問題です。

Smart ContractWalletはこれらの問題のいくつかに対する解決策を提供しますが、イーサリアムは現在、すべての操作をECDSAで保護されたEOAからのトランザクションにパッケージ化する必要があります。 これにより、追加の取引手数料と21,000のガス料金が発生し、ユーザーは2つのアカウントを管理し、ガス料金を支払うために別々のEOAにETHを預けるか、中央集権的なリレーシステムに依存して支払う必要があります。

これらの問題点により、新しいAA規格であるERC-4337が誕生しました。

ERC4337提案:

CA の問題

現在、これらのことはすべてコントラクトウォレットで解決できますが、イーサリアム自体は、ECDSAで保護されたEOAから派生したトランザクションにすべてをパッケージ化する必要があり、その結果、次のようになります。

追加の取引手数料:各ユーザーアクションはEOAによって開始される必要があり、その結果、追加の21,000ガス料金が発生します。 複雑さと集中化:ユーザーは、ガス料金を支払い、両方の口座の残高を管理するために別々のEOAにETHを預けるか、リレーシステムに依存して支払う必要があります。

何年にもわたって、EIP-86やEIP-2938などのイーサリアムベースのブロックチェーンにアカウントの抽象化を実装する試みがいくつか行われてきました。 しかし、これらのアプローチはいずれもコンセンサスレイヤーへの変更が必要であり、実装が難しいため、どれもうまくいきません。

4337 メカニズム

ERC-4337 は、バンドルの概念の点でロールアップに類似した UserOperation と呼ばれる高レベルの疑似トランザクション オブジェクトを導入することで、アカウントの抽象化を実装しています。 幸いなことに、この標準により、コンセンサスレイヤーを変更することなくアカウントの抽象化を構築できます。

EIP 4337のモジュラー設計は、Smart ContractWalletアカウントの抽象化を複数のポートに分割します。

バンドラー:

• Bundler は EOA です。 すべてのトランザクションはEOAによって開始される必要があるため、Bundlerを使用すると、ユーザーはEOA秘密鍵を作成して記憶することなく、Smart ContractWalletトランザクションをトリガーできます。
• Bundler の機能: UserOperation を検証し、UserOperation オブジェクトのセットを 1 つの “バンドル トランザクション” にパッケージ化します。 認証された UserOperation コンテンツをパブリックまたはプライベートのメモリー・プールにブロードキャストします。
• Bundlerは、UserOperation実行後に最も優先度の高い料金と実際のガス料金の差額をポケットに入れることで、金銭的なメリットもあります。 通常のトランザクションのリレーと同様に、Bundler は、バンドルされたトランザクションの UserOperation を並べ替えることによって MEV を取得します。

エントリ ポイント:

• エントリ ポイントは、すべての Bundler が UserOperation を実行するために呼び出す必要があるグローバル コントラクトです。 エントリポイントは、BundlerとSmart ContractWalletの間の仲介役として機能します。
• handleOpで検証して実行する:handleOp関数は、UserOperationを入力パラメータとして使用して、最初にUserOperationをオンチェーンで検証し、指定されたSmart ContractWalletAddressによって署名されているかどうかを確認し、Bundlerに補償するのに十分なガス料金をウォレットします。 検証が成功すると、関数シグネチャに基づいて入力パラメーターが実行されます。

Smart ContractWalletを入金する必要があるトークンは、Bundlerにガス料金を支払う:BundlerがEOAを使用してhandleOpをトリガーすると、ガス料金が発生します。 Smart ContractWalletは、自分の残高でガス料金を支払うか、Pymasterに支払いを依頼することができます。 失敗の可能性:ガス代が足りず、検証ステップが失敗し、ガス代が十分であっても、ランタイムエラーなど、UserOperation実行ステップが失敗することがあります。 実行が成功したかどうかに関係なく、エントリ ポイント コントラクトは handleOp 関数をトリガーするために Bundler にガス料金を支払います。 エントリーポイントコントラクトは、Smart ContractWalletにトークンを担保として追加または出金する機能を提供します。

スマートウォレット:

スマートコントラクトウォレットのメインコントラクトは、UserOperationの検証ステップと実行ステップを分離します。 これを切り離すことで、BundlerはUserOperationをオフチェーンで検証し、ガス料金を支払うことなく悪意のあるトランザクションを除外することができます。

検証ステップは validateOp 関数で定義され、validateOp の最初の呼び出しでは、Bundler はオフチェーン検証をシミュレートし、UserOperation の署名を検証し、Smart ContractWallet に十分なガス残高があることを確認し、validateOp の 2 番目の呼び出しは、UserOperation を実行する前にオンチェーン検証を実行するエントリポイントコントラクトです。

ペイマスター:

• Paymasterは、ERC20 Fungible Tokenを使用してイーサリアムのガス料金を支払うことや、ガス料金のない取引など、Smart ContractWalletのガス抽象化ロジックを定義しています。
• Paymasterは、PaymasterのvalidatePaymasterOpをトリガーできるdAppによってデプロイされたスマートコントラクトです。

ウォレットファクトリー:

※Wallet Factoryは、Smart ContractWalletを作成する公開コントラクトです。 ウォレットファクトリーのアドレスと新しいスマートコントラクトウォレットパラメータがinitCodeに埋め込まれると、バンドラーは対応するウォレットファクトリをトリガーして、指定されたパラメータでスマートコントラクトを作成します。 一般的なWallet Factoryコードは十分に吟味されているため、Wallet Factoryでウォレットを作成する方が安全です。

• Wallet Factoryは、Bundlerからより多くのトラフィックを得るために、エントリーポイントでETHをステークし、UserOperationsに適切にサービスを提供し続ける必要があります。
• ユーザーは、initCode で満たされた UserOperation を送信し、Bundler に CA ウォレットの作成を要求できます。 *ユーザーは、特定のカスタムパラメータを使用してWallet Factoryを選択して、CAウォレットをカスタマイズできます。

署名アグリゲーター:

*署名アグリゲーターは、トランザクションの検証と実行を高速化するために、複数のトランザクションの署名をバイトに集約するために使用されます。 スマートコントラクトウォレットが異なれば、異なる署名アルゴリズムを使用するため、最初に同じ署名アルゴリズム集計UserOperationsを使用する必要があります。 *ガス料金の節約:オンチェーンの暗号化計算は多くのガス料金を消費するため、集約署名スキーム(BLSなど)は、オンチェーンでの検証時にガス料金を節約できます。

• Bundler は、一度に 1 つの UserOperations を検証するのではなく、複数の署名アグリゲータ コントラクトを使用して複数の集計署名を生成します。
• Bundler は UserOperation 配列、集約署名、およびアグリゲーターの Address をエントリ ポイントに渡し、各 UserOperation グループ会議は対応する署名アグリゲーターの validateSignature 関数を呼び出します。
• 検証後、BundlerはSmart ContractWalletでこのUserOperationsのセットを実行します。 *また、アグリゲーターはエントリーポイントコントラクトにイーサリアムをステークし、良好なUserOperationサービス記録を維持する必要があります。

AAの利点

ガスの抽象化:

ガスの抽象化にはガス料金のトランザクションは含まれておらず、ERC20トークンでガス料金を支払います。 ロジックは、Paymasterコントラクトまたはリレーを介して実行できます。 AAの場合、多くのSmart ContractWallet自体がEIP 4337準拠のPaymasterコントラクトを実装し、エントリーポイントコントラクトにトークンをステークして、ユーザーがガス料金を支払うのを助けることができます。

社会の回復:

秘密鍵が紛失または侵害された場合、ユーザーは新しい秘密鍵を正当なウォレット所有者として承認できます。 ソーシャルログインとソーシャルリカバリのロジックは、通常、ウォレットのメインコントラクトで定義されています。 これは、電子メール、マルチシグ、MPC、SWIE(イーサリアムでのログイン)など、さまざまな方法で行うことができます。

トランザクション バッチ:

トランザクションのバッチ処理は、Smart ContractWallet独自の機能で、Walletユーザーが1つのオンチェーントランザクションで複数のトランザクションを実行できるようにします。

クロスチェーンインタラクションとコネクションブリッジの統合:

現在、多くのウォレットがサードパーティベンダーと協力して、法定通貨の入出金チャネルとクロスチェーンインタラクションブリッジをウォレットに統合しています。 これらの入出金チャネルとクロスチェーン相互作用ブリッジは、ガス抽象化で支払い契約(Paymaster)とさらに統合できます。

モジュラー設計:

AAの最大の強みの1つは、Bundler、Paymaster、その他のパーツを柔軟に組み合わせることができるモジュラーサービスでしょう。

AAの欠陥

スタックアップから

比較的高い手数料:

ERC-4337を使用して簡単な送金を行うと、従来のウォレット(EOAと呼ばれることが多い)を使用するよりもはるかにコストがかかります。

ただし、Rollupネットワークでは、ERC-4337を使用した単純な転送は、署名を集約してメインネット上のデータ量を減らすため、EOAよりも安価になる可能性があります。

基準はまだ確定していません:

トランザクションのスケーラビリティの拡大による攻撃ベクトルの増加、新しい標準に移行する際の未知のバグやセキュリティリスクの可能性、すべてのトランザクションが適切に署名および検証されるようにするための堅牢で安全なグローバルエントリポイントコントラクトの必要性などの課題。

レイヤー 2

• ✅ で、❌ネイティブ AA がサポートされているかどうかを示します。 *

**楽観主義: ❌ **

Optimismバージョン1には、Smart ContractWalletアカウントの抽象化を実現するための3つのOVM操作コードがあります。 ただし、一貫性とセキュリティ上の理由から、バージョン 2 ではこれらの操作コードが削除されており、アカウントの抽象化のサポートに関する公式声明はありません。

**アービトラム: ❌ **

現在、Arbitrum上に構築されたスマートコントラクトウォレットがいくつかありますが、アカウントの抽象化のサポートに関する公式声明はありません。

**スタークネット: ✅ **

Starknetには、検証および実行機能を備えたスマートコントラクトアカウントのみがあり、すべてのアカウントは、署名を検証し、ガス料金を確保するためにこれらの機能を実装する必要があります。 Starknetは、トランザクションの未実行を防ぐために、検証機能が外部コントラクト状態を呼び出すことを禁止しています。 ただし、StarknetとEthereumの間には、UserOperationsの欠如、Paymasterに似たトランザクション手数料の抽象化プロトコル、新しいコントラクトを作成するためにトークン残高を持つアカウントが必要であるなど、いくつかの違いがあります。 また、Starknetのシーケンサーは、検証済みのトランザクションが失敗した場合にガス料金を請求できませんが、イーサリアムは請求できます。

**zkSync: ✅ **

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

AA インフラストラクチャー:

現在、Stackup、Etherspot、Candide、Infinistism、Pimlicoなどの優れたプロジェクトがインフラストラクチャの構築を試みています。

バンドラーサービス:

ビルダー：

• StackupのGolang実装
• CandideのPython実装
• インフィニティズムの型実装
• Skandha - Etherspotの型実装

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

公共サービス

大多数のバンドラーはオープンソースであるため、非独占的で競争力がありません。 どのRPCエンドポイントでも、オープンソースコードをコピーすることでBundlerを実行できます。

• 収益化が難しい

Bundlerを実行するRPCエンドポイントがAPI秘密鍵を通じてサービス利用料を請求する場合でも、Paymasterはサードパーティの入出金プロバイダーや分散型金融プロトコルアグリゲータープロバイダーと提携することで料金の差額を簡単に獲得できるため、Bundlerサービスは支払い契約であるPaymasterなどの他のインフラストラクチャよりも収益化が困難です。

重要インフラ

UserOperations の検証と実行には、分散化を改善するために、できるだけ多くのバンドラーが必要です。 現在、サードパーティの Bundler サービス プロバイダーは Stackup と eth-infinitism のみであるため、このような Bundler サービス プロバイダーがさらに必要です。

メカニズム**

バンドラーは、特定の事項について合意することなく、共有メモリプールと同様に、メッセージの配信とユーザーアクションの伝播を独自に行います。 Bundlerにはスパムをフィルタリングするための重要な機能があり、独自の経済的な理由から、Bundlerはmempoolの安全性を確保するために可能な限り監視したいと考えています。

Bundler サービス間の違い:

• Bundler サービスは、一般的なインフラストラクチャにすることも、ウォレット専用に構築することもできます。 ウォレットプロジェクトでは、最も基本的なバンドラーの構築を優先する場合がありますが、サードパーティプロバイダーは、さまざまなシナリオでモジュラーバンドラーを構築する必要があります。
• EthereumNodeと同様に、Bundlerサービスは異なるプログラミング言語で実装されており、単一障害点を防ぎ、エコシステムに利益をもたらします。
• Bundlerサービスは、プライベート・メモリプールとパブリック・メモリプールの両方をサポートし、プライベート・メモリプールのカスタマイズ・オプションを提供します。

Paymasterサービス

• Bundlerサービスと比較して、Paymasterサービスはより集中化されており、契約はオープンソースですが、バックエンドは閉じられています。
• Paymasterサービスには、法定通貨の入金、交換、ブリッジング、自動支払い、セッション、スポンサー料、およびその他の機能と組み合わせることで、dAppsのユーザビリティを向上させることができる収益化モデルがあります。

AA ウォレットと SDK:

製品評価

• 秘密鍵管理システム: +マルチシグロジック(安全):2/3および3/5マルチシグロジックのみを実装できます。 +シンプルな権限管理(シーケンシャル):秘密鍵の重みを設定してから、運用アカウントのしきい値を設定できます。 +ロールベースの権限管理(Unipass):秘密鍵の重みとロールを設定できます。 役割が異なれば、実行できるアクションも異なります。 各ロールには、対応するしきい値もあります。 このしきい値を超えると、対応するロールの権限を適用できます。 *社会的回復方法 *ガス料金のスポンサーシップ:独自のリレーを構築するか、Bundler + Paymasterを設定します *マルチチェーンアカウントの同期 *マルチチェーンアドレスの統一性 *サポートされているブロックチェーン

ビジネス

※ビジネスモデル:To b/ To B + To C / ToC

• dAppsとの提携:各チェーンでStable CoinやDecentralized Financeなどの巨大インフラdAppsと提携 *ユーティリティ:非代替性トークンマーケットプレイス、ローンチパッドなどを統合します。 *外部サポート:イーサリアム財団またはその他の有名なベンチャーキャピタル機関から