アカウントアブストラクション 第4回:集約署名

集約署名

現在の実装では、バンドル内の各user opを個別に検証している。これは検証の考え方として非常に素直だが、無駄が生じる可能性がある。署名の検証はかなりの暗号演算を必要とするため、ガス代の面でコストが高くなりがちだ。

多くのopを、多数の署名ではなく1つの署名だけで同時に検証できたらどうだろうか?

これを実現するには、暗号理論の概念である**集約署名（aggregate signatures）**が必要になる。

集約をサポートする署名方式とは、異なる鍵で署名された複数のメッセージが与えられたとき、1つの結合署名を生成する方法を提供し、その結合署名を検証することで元の署名すべてが有効であることが示せる、というものだ。

集約をサポートする署名方式の一般的な例がBLSだ。

この最適化はロールアップの実装において特に有用だ。ロールアップの主な目的はデータ圧縮であり、署名集約によって署名部分を圧縮できるからだ。

署名集約による容量削減について詳しくは、この件に関するVitalikのツイートを参照してほしい。

アグリゲーターの導入

すぐに気づくことだが、バンドル内のすべてのuser opの署名を一緒に集約できるわけではない。ウォレットは与えられた署名を検証するために任意のロジックを使ってよいのだったから、同一バンドル内にさまざまな署名方式が混在しうる。

異なる方式の署名を集約することはおそらくできないため、バンドルは最終的にop群のグループに分かれ、各グループはそれぞれ固有の集約方式を使うか、まったく集約しないかのいずれかになる。

オンチェーンにはそれぞれ独自のロジックを持つさまざまな集約方式が存在する必要があるため、各集約方式は**アグリゲーター（aggregator）**と呼ぶコントラクトとして表現することにする。

集約方式は、複数の署名を1つにまとめる方法と、その結合署名を検証する方法によって定義される。したがって、アグリゲーターはこれら2つの機能をメソッドとして公開する。

各ウォレットが独自の署名方式を定義しているため、どのアグリゲーターと互換性があるか（もしあれば）は各ウォレットが決めることになる。

ウォレットが集約に参加したい場合、自身のアグリゲーターを選択するためのメソッドを公開する:

この新しいgetAggregatorメソッドを使うことで、バンドラーは同じアグリゲーターを持つopをグループ化し、そのアグリゲーターのaggregateSignaturesメソッドを使って結合署名を計算できる。

グループは以下のようになる:

次に、新しいアグリゲーターを利用できるようエントリーポイントコントラクトを更新する必要がある。

エントリーポイントにはopのリストを受け取るhandleOpsメソッドがあったことを思い出してほしい。

これに新しいメソッドhandleAggregatedOpsを追加する。これは同じことを行うが、opをアグリゲーターごとにグループ化して受け取る:

新しいメソッドhandleAggregatedOpsは、大部分がhandleOpsと同様に動作する。違いは検証ステップだけだ。

handleOpsが各ウォレットのvalidateOpメソッドを呼び出して検証を行うのに対し、handleAggregatedOpsは代わりに各グループのアグリゲーターを使って、そのグループの結合署名に対してアグリゲーターのvalidateSignaturesメソッドを呼び出す。

もう少しで完成だ！

しかし、ここで、もうお馴染みの問題が一つある。

バンドラーは検証をシミュレーションし、opのグループをバンドルに含める前にアグリゲーターがそれを検証できることを確認したい。検証に失敗するとバンドラーがガス代を負担することになるからだ。しかし、任意のロジックを持つアグリゲーターは、シミュレーション中は簡単に成功し、実行時には失敗することがありうる。

これはpaymasterやfactoryのときとまったく同じ方法で解決する。アグリゲーターがアクセスできるストレージと使用できるオペコードを制限し、ストレージにアクセスしない場合を除いて、エントリーポイントにETHをステークすることを要求する。

これで集約署名については以上だ！

まとめ

ここまでで作り上げたものは、ほぼERC-4337の完全なアーキテクチャそのものだ！メソッドの名前や引数など細部にいくつかの違いはあるが、アーキテクチャ上の違いと呼べるものはもう残っていないと思う。ここまでの説明がうまくいっていれば、あなたは今、実際のERC-4337を読んで何が起きているか理解できるはずだ。

ここまで読んでくれてありがとう！この説明が、私自身が書きながら学んだのと同じくらい、あなたの役に立てば嬉しい。

補足: ERC-4337との相違点

アカウント抽象化の全体的なアーキテクチャは押さえられたが、ERC-4337の背後にいる頭の良い人たちは、上で説明した内容といくつか異なる工夫をしている。

そのいくつかを見ていこう！

1. 検証の有効時間範囲

上では、ウォレットのvalidateOpとpaymasterのvalidatePaymasterOpの戻り値の型について、かなり曖昧にしていた。ERC-4337はこれをうまく活用する方法を見つけている。

ウォレットがぜひやりたいと思うことの一つに、user opが有効なのは一定期間だけに限定するというものがある。そうしないと、悪意のあるバンドラーがそのoperationを長期間保持しておき、後になって自分に有利なタイミングでバンドルに含める、ということが起こりうる。

ウォレットはこれを防ぐために、検証中にTIMESTAMPをチェックして未来すぎないか確認したいところだが、それはできない。シミュレーションが不正確にならないよう、検証中のTIMESTAMPを禁止しているからだ。つまり、ウォレットにはoperationがいつ有効なのかを示す別の方法が必要になる。

そこでERC-4337は、validateOpにウォレットが時間範囲を選択できる戻り値を与えている:

この戻り値は、operationが有効な時間範囲を、連続する2つの8バイト整数として表す。

ERC-4337からもう一つ補足しておくと、ウォレットは検証失敗時にrevertするのではなく、validateOpから番兵値（sentinel value）を返すべきだ。これは、revertしたトランザクションでどれだけガスが使われたかをeth_estimateGasが教えてくれないため、ガス見積もりの助けになる。

2. ウォレットとfactoryのための任意のcall data

私たちのウォレットのインターフェースは次のようなものだと説明した:

ERC-4337では、実はウォレットにexecuteOpという名前のメソッドは存在しない。

代わりに、user operationはcallDataフィールドを持つ:

これがcall dataとしてウォレットに渡される。

典型的なスマートコントラクトでは、このデータの最初の4バイトは関数セレクタとして解釈され、残りは関数の引数として解釈される。

つまり、必須のvalidateOpメソッド以外は、ウォレットが独自のインターフェースを定義でき、user operationを使ってウォレット上の任意のメソッドを呼び出せるということだ。

同様に、ERC-4337ではfactoryコントラクトも実際にはdeployContractメソッドを持たない。factoryも任意のcall dataを、この場合はopのinitCodeフィールドから受け取る。

3. paymasterとfactoryのためのコンパクトなデータ

上では、user operationにはpaymasterを指定するフィールドと、それに渡すデータを指定するフィールドが含まれると説明した:

ERC-4337では、最適化としてこれらを1つのフィールドにまとめており、フィールドの最初の20バイトがpaymasterのアドレス、残りがデータとなる:

factoryとそこに送るデータについても同様だ。私たちはfactoryとfactoryDataという2つのフィールドを使ったが、ERC-4337はこれらを単一のフィールドinitCodeにまとめている。

これでおしまいだ！

アカウント抽象化について、多くを学んでもらえたなら幸いだ。

あなたもアカウント抽象化を発明できた

この全4部構成のシリーズの最初を見逃しただろうか？最初から読み直してみよう！

1. Account Abstraction Part 1: Protect Our Assets
2. Account Abstraction Part 2: Sponsoring Transactions with Paymasters
3. Account Abstraction Part 3: Wallet Creation