イーサリアムアカウントの抽象化と ERC-4337
著者:鹿目円、IOBC Capital
イーサリアムシステムには実際に2種類のアカウントが存在します:
1つは、外部アカウント(externally-owned account、EOA)で、私たちが使用するウォレット内のアカウントのように、プライベートキーによって制御されるアカウントです。この種のアカウントはそれぞれ独自の残高を持っています。所有者は、自分の外部アカウントからメッセージを送信するために、トランザクションを作成し署名することができます。
もう1つは、ブロックチェーンにデプロイされたコードによって制御されるコントラクトアカウント(contract account)で、スマートコントラクトアカウント(時にはスマートウォレットとも呼ばれる)内に保存されたイーサリアム仮想マシンコードによって制御されます。コントラクトアカウントが情報を受け取ると、その内部コードがアクティブになり、内部ストレージの読み書きや新しいコントラクトの作成などの操作が可能になります。
現在のイーサリアムプロトコルに従って、取引を開始できるのは外部アカウントのみであり、アカウントの所有者だけがそのアカウントの状態を変更することが許可されています。
アカウント抽象化とは何ですか?
アカウント抽象化は、上記の2種類のアカウントの改善を試み、両者の境界を曖昧にし、複雑なロジックを含む汎用アカウントに変えることを目指しています。これにより、アカウントはコントラクトアカウントと外部アカウントの機能を同時に持つことができます。
このアプローチは、ユーザーがコントラクトアカウントの形式に従って外部アカウントを定義できるようにし、ユーザーはスマートコントラクトウォレット内に任意のロジック検証を含めることができます。キーによって制御されるアカウントもコードのサポートを受けることができます。
アカウント抽象化のさまざまな提案
アカウント抽象化の実現は、イーサリアム開発者コミュニティのビジョンであり続けています。コミュニティは、EIP-86、EIP-2938など、さまざまな提案を行っています。
EIP-86はアカウント抽象化のための技術的準備を行い、ユーザーがスマートコントラクトに基づくアカウントを作成できる新しいアカウントタイプを定義しています。
イーサリアムプロトコル自体は、すべての内容をECDSAセキュリティに基づく外部アカウント(EOA)からのトランザクションにパッケージ化することを要求しており、各ユーザー操作はEOAからのトランザクションでラップされる必要があり、これにより21000ガスの費用が発生します。ユーザーは、ガスを支払うために別のEOAにETHを保有する必要があります。
EIP-86が提案するアカウント抽象化は、新しいタイプのトランザクションをもたらし、従来のトランザクションが送信者としてEOAを必要とするのに対し、これらのトランザクションには送信者が存在しません。このトランザクションは、トランザクションハッシュの一意性を破壊します。EIP-86は当初、Metropolis段階でのアップグレードを予定していましたが、前述の問題により、開発者はMetropolisでの導入を保留することに決定しました。
EIP-2938は、アカウント抽象化の解決策を提供し、イーサリアムプロトコルの一部を変更することで、コントラクトアカウントが外部アカウントと同様にトランザクションを開始できるようにします。しかし、この提案はコンセンサス層でのイーサリアムプロトコルの変更を必要とするため、広く受け入れられていません。
その後提案された新しいプロトコルERC-4337は、コンセンサスプロトコルを変更することなく、EIP-2938と同様の効果を達成しようとする提案であり、この安全性の高い実装方法は現在コミュニティでより多くの注目を集めています。
ERC-4337はどのように実現されるのか?
ERC-4337はプロトコルのコンセンサスを変更しようとはせず、システム内でmempoolの機能を複製しました。
ユーザーはユーザー操作(UserOperation)オブジェクトを送信し、このオブジェクトにはユーザーの意図、署名、およびその他のデータが含まれています。ユーザー操作には、別のmempoolストレージプールがあり、このストレージプールに接続されたノードはERC-4337特有の検証を行い、操作をフィルタリングして、料金を支払う操作のみを受け取ることを保証します。
マイナーまたはFlashbotsサービスを使用するパッカーは、これらのユーザー操作を一括収集し、単一のバンドルトランザクション(bundle transaction)としてパッケージ化し、イーサリアムブロックに組み込みます。パッカーはイーサリアム内のバンドルトランザクションのガス料金を支払い、各ユーザー操作に対して支払われた料金を補償として受け取ります。パッカーは、料金優先度ロジックを使用して、どのUserOperationオブジェクトを含めるかを選択します。
その中のユーザー操作UserOperationはトランザクションのように見えますが、ABIエンコードされた構造であり、以下のフィールドを含みます:
送信者:操作を行うウォレット;
nonceとsignature:ウォレット検証関数に渡されるパラメータで、ウォレットが操作を検証できるようにします;
initCode:ウォレットがまだ存在しない場合、ウォレットを作成するための初期化コード;
callData:実際のステップを呼び出すためのデータ。
各ウォレットはスマートコントラクトであり、2つの機能関数を含む必要があります:validateUserOp:UserOperationを入力として受け取ります。この関数はUserOperation内の署名とnonceを検証し、検証が成功した場合は料金を支払いnonceを増加させ、検証が失敗した場合は例外をスローします;
op実行関数:calldataを解析してウォレットが操作を実行するための1つ以上の命令に変換します。
ERC-4337がもたらす変化
この提案が広く採用されれば、署名検証はイーサリアム仮想マシン(EVM)に移行し、validateUserOp関数は任意の署名とランダム数の検証ロジックを追加し、検証ロジックがより柔軟になります。
これにより、トランザクションを署名する際に新しい暗号ツールを使用でき、ウォレットは以下のような新しい機能を提供できるようになります:
- マルチシグネチャ;
- ソーシャルリカバリー;
- より効率的でシンプルな署名アルゴリズム(例:Schnorr、BLS);
- 後量子安全署名アルゴリズム(例:Lamport、Winternitz);
- アップグレード可能なウォレット。
この提案は、スマートコントラクトを介してガス料金を支払うことを許可するなど、さまざまな他のトランザクション許可管理を開きます。
現在、外部ウォレットがイーサリアム上で相互作用するためのガス料金は、ウォレット内のETHを通じてのみ支払うことができます。ウォレットにERC-20トークンしかない場合、これらのトークンを出金する方法はありません。ERC-4337が採用されると、ユーザーはアカウント内のERC-20トークンを使用して料金を支払い、マイナーノードがコントラクトを仲介としてETHをオンチェーンで支払い、ユーザーのERC-20トークンを取得します。
抽象化が実現されると、外部アカウントの所有者がトランザクションに署名し、ブロードキャストすることがトランザクションを開始する唯一の方法ではなくなります。これにより、イーサリアムがメタトランザクションのリレーとして機能する可能性が生まれます。現在、多くのイーサリアム上のアプリケーションは、リレーターに依存してユーザーのトランザクションをブロックチェーン上に公開し、リレーターに料金を支払っています。ウォレットにより複雑なコントラクトが内蔵できるようになれば、一部のリレーターはもはや存在する必要がなくなり、彼らに追加の料金を支払う必要もなくなります。
多くの利点がある一方で、新しい提案もいくつかの問題に直面しています。
最も顕著な点は、より高いガスコストです。基本的なERC-4337操作は約42000ガスを必要とし、通常のトランザクションは21000ガスを必要とします。その理由は以下の通りです:
大量の個別ストレージの読み書きコストを支払う必要があり、EOAの場合、これらのコストは21000ガスの支払いにバンドルされます:
(1)pubkey+nonce(約5000)のストレージスロットを編集;
(2)ユーザー操作呼び出しデータコスト(約4500、圧縮により約2500に削減可能);
(3)ECRECOVER(約3000);
(4)ウォレット自体の初回アクセス(約2600);
(5)受取人アカウントの初回アクセス(約2600);
(6)受取人アカウントへのETHの転送(約9000);
(7)料金を支払うためのストレージの編集(約5000);
(8)代理を含むストレージスロットへのアクセス(約2100)、その後代理自体へのアクセス(約2600);上記のストレージの読み書きコストに加えて、コントラクトは「ビジネスロジック」(UserOperationのアンパック、ハッシュ化、変数のシャッフルなど)を実行する必要があります。
ログ料金を支払うためにガスを消費する必要があります(EOAはログを公開しません);
一度きりのコントラクト作成コスト(約32000ガス、さらに代理の各コードバイト200ガス、代理アドレスの設定に20000ガスが必要)
要するに、アカウント抽象アドレスの各ステップは計算を必要とし、より多くのリソースを消費し、追加の費用が増加します。
幸いにも、これは解決できない問題ではありません。
Rollupはデータ圧縮を得意としており、データが複雑なアカウント抽象化の提案と自然に適合します。
Vitalikの最新の提案では、レイヤー2を通じてアカウント抽象化によって生成されたデータを処理することが提案されています。その改善点は、段階的に実現できる機能をバンドルトランザクションとしてパッケージ化し、SNARK技術を使用してトランザクションの有効性を保証することです。
ERC-4337とRollup技術を組み合わせることで、アカウント抽象化においてデータ圧縮とガスコストの削減を実現し、アカウント抽象化の利点を最大限に引き出すことができます。
結論
イーサリアムがLayer 2の発展に重点を置くことが確定した今、Vitalikはイーサリアムのアップグレードの次の計画をアカウント抽象化にシフトし始めました。最新の提案では、rollup+アカウント抽象化の技術的な道筋が示されています。各Rollupプロバイダーも、アカウント抽象化に対応した新しいバージョンを発表しています。
今年6月、zkSyncはV2の更新情報を発表し、「アカウント抽象化」機能を追加し、イーサリアムEVMとの互換性を高めました。10月にはERC-4337が新バージョンを発表し、BLS署名アルゴリズムを含む署名集約機能を追加しました。署名集約により、ビルダーやバッチ提出者も署名を集約でき(例:BLS、SNARKs)、チェーン上のデータを大幅に削減し、Rollupのデータコストを低減できます。
アカウント抽象化がもたらす変化には、エコシステムの爆発的な可能性が秘められていると信じる理由があります。Rollupの発展に伴い、Rollupと組み合わせることができるアカウント抽象化も、より優れた精緻な提案を発展させることができるでしょう。