メインコンテンツまでスキップ

ERC-4337 : イーサリアムをアカウント抽象化で革命する

· 約4分
Dora Noda
Software Engineer

こんにちは、ブロックチェーンブログへ再びようこそ! 本日は、コンセンサス層のプロトコル変更を必要とせずにイーサリアムへアカウント抽象化を導入するエキサイティングな新提案「ERC-4337」について掘り下げます。この提案は上位レイヤーのインフラストラクチャに依存して目標を達成します。ERC-4337 が提供するもの、そして現在のイーサリアムエコシステムの制約にどのように対処するかを見ていきましょう。

ERC-4337 とは?

ERC-4337 は、別個の mempool と「UserOperation」と呼ばれる新しい疑似トランザクションオブジェクトを使用してイーサリアムにアカウント抽象化を導入する提案です。ユーザーは UserOperation オブジェクトを代替 mempool に送信し、そこで「bundler」と呼ばれる特別なアクターがそれらをまとめてトランザクションにパッケージし、専用コントラクトへの handleOps 呼び出しを行います。このトランザクションはブロックに取り込まれます。

この提案の目的は以下の通りです:

  1. 任意の検証ロジックを持つスマートコントラクトウォレットをプライマリアカウントとして使用できるようにする。
  2. 外部所有アカウント(EOA)を完全に不要にする。
  3. 任意の bundler がアカウント抽象化されたユーザー操作をブロックに含めるプロセスに参加できるようにし、分散性を確保する。
  4. すべての活動を公開 mempool 上で行い、特定アクターの直接通信アドレスをユーザーが知る必要をなくす。
  5. bundler に対する信頼前提を排除する。
  6. イーサリアムのコンセンサス変更を不要とし、迅速な採用を可能にする。
  7. プライバシー保護アプリケーション、アトミックなマルチオペレーション、ERC-20 トークンでのガス支払い、開発者スポンサー付きトランザクションなど、さまざまなユースケースをサポートする。

後方互換性

ERC-4337 はコンセンサス層を変更しないため、イーサリアム自体の直接的な後方互換性問題はありません。ただし、ERC-4337 が導入される前のアカウントは validateUserOp 関数を持たないため、新システムと簡単に互換化できません。この課題は、検証ロジックをラッパーとして再実装し、元のアカウントの信頼できるオペレーション送信者として設定することで解決できます。

参考実装

ERC-4337 の技術的詳細をさらに深く学びたい方は、以下のリポジトリをご参照ください。
https://github.com/eth-infinitism/account-abstraction/tree/main/contracts

セキュリティ上の考慮点

ERC-4337 のエントリーポイントコントラクトは、システム全体の信頼の中枢となるため、徹底的な監査と形式的検証が必須です。このアプローチは個々のアカウントに対する監査負荷を軽減しますが、エントリーポイントコントラクトにセキュリティリスクが集中する点に注意が必要です。

検証すべき主な主張は次の二つです:

  1. 任意のハイジャックに対する安全性:エントリーポイントは、対象アカウントの validateUserOp が合格した場合にのみ、そのアカウントを汎用的に呼び出します。
  2. 手数料の流出に対する安全性:エントリーポイントが validateUserOp を呼び出し合格した場合、op.calldata と同一の calldata で汎用呼び出しを行う必要があります。

結論

ERC-4337 はコンセンサス層のプロトコル変更を必要とせずにイーサリアムへアカウント抽象化を導入するエキサイティングな提案です。上位レイヤーのインフラストラクチャを活用することで、分散性・柔軟性・多様なユースケースの可能性が広がります。セキュリティ上の課題は残りますが、本提案はイーサリアムエコシステムとユーザー体験を大幅に向上させる潜在力を秘めています。