# [ERC7766] ERC4337の署名集約の仕組みを理解しよう！

> ERC4337は、Ethereum上でAccount Abstractionを実現する仕組みを提案していて、標準のトランザクション処理とは別の「UserOperation mempool」を用いることで、柔軟なトランザクション実行を可能にし

- URL: https://cardene.dev/articles/edda29b011254d3722d6
- 公開日: 2025-06-14
- 更新日: 2025-06-14
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、アグリゲーターという新しいコントラクトを導入し、複数のUserOperationを一括で検証・承認する仕組みを提案している**ERC7766**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-7766

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ERC4337**は、Ethereum上でAccount Abstractionを実現する仕組みを提案していて、標準のトランザクション処理とは別の「UserOperation mempool」を用いることで、柔軟なトランザクション実行を可能にします。

:::message
**ERC4337**については以下の記事を参考にしてください。
:::

[\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](/articles/8c97ca7c93c4557ebfc2)

しかしながら、**ERC4337**には重要な制限があります。
それは、各UserOperationが個別に署名（または他の検証入力）を持つ必要があるという点です。
この制限により、複数のトランザクションをまとめて処理する際の効率性やガスコスト最適化に限界がありました。

この課題を解決するために提案されているのが、「aggregator（アグリゲーター）」という新たな仕組みです。
アグリゲーターは、バリデーションの際に呼び出され、複数のUserOperationをまとめて検証する役割を担います。
これにより、署名や検証データの共有が可能になり、トランザクションバンドルのガスコスト削減や原子性（全体の一括成功）を保証できるようになります。

## 動機

署名の集約（aggregation）を活用した検証方式を導入することで、次のような利点が得られます。

* **ガス代の大幅な削減**
    * 検証処理の共通部分をまとめることで無駄な計算を省けます。
* **トランザクションデータの軽量化**
    * 各UserOperationが個別の署名を持たなくても済むため、データサイズが小さくなります。
* **Rollupとの親和性**
    * RollupはEthereumメインネットにデータを投稿する必要があるため、データサイズの削減はコスト面で大きな恩恵になります。

このように、アグリゲーターの導入によって、**ERC4337**の柔軟性がさらに高まり、特に大量のUserOperationを扱う状況において高効率な実行が実現されます。

## 仕様

### Aggregatorの導入

アグリゲーターとは、署名の集約と検証を担う新しいコントラクトです。
これは、**ERC4337**に基づくUserOperationの検証を補助するもので、アカウントから信頼されて利用されます。
バンドラーやクライアントは、使用可能なアグリゲーターをホワイトリスト化して管理します。

### インターフェース

アグリゲーターは、以下のインターフェースを持ちます。

```js
interface IAggregator {
  function validateUserOpSignature(PackedUserOperation calldata userOp) external view returns (bytes memory sigForUserOp);

  function aggregateSignatures(PackedUserOperation[] calldata userOps) external view returns (bytes memory aggregatesSignature);

  function validateSignatures(PackedUserOperation[] calldata userOps, bytes calldata signature) external view;
}
```

* `validateUserOpSignature`
    * UserOperationの署名を検証し、代替の署名データを返します。
* `aggregateSignatures`
    * 複数のUserOperationの署名を1つに集約します。
* `validateSignatures`
    * 集約された署名がすべてのUserOperationに対して正しいかを確認します。

### アカウントによるアグリゲーターの使用

コントラクトアカウントは、`validateUserOp`関数の返り値に自身の使うアグリゲーターのアドレスを含めることで、署名集約を使用することを示します。
この情報は、`simulateValidation`中に返される`ValidationResult`の`aggregatorInfo`フィールドに含まれます。

### ステーク要件とバンドラーの役割

全てのアグリゲーターはステークをする必要があります。
バンドラーは、**ERC7562**に基づいてアグリゲーターが制限中やブロック対象でないことを確認する必要があります。
バンドラーは、まず`validateUserOpSignature`を呼び出して署名を検証し、得られた代替署名を使用して再度`validateUserOp`を呼び出し、値の整合性を確認しなければなりません。

:::message
**ERC7562**については以下の記事を参考にしてください。
:::

[\[ERC7562\] Account Abstractionのトランザクション検証ルールについて理解しよう！](/articles/213a17c8dd12a29f8f2c)

### バンドル処理の変更点

**ERC4337**の標準的な処理に加え、以下のステップが必要です。

* UserOperationをアグリゲーターごとにグループ化（ソート）する
* 各グループに対して`aggregateSignatures`を呼び、署名を集約する
* UserOperationを更新し、集約署名を使うようにする

### EntryPointコントラクトの新機能

`EntryPoint`コントラクトに新たに以下の関数が追加されます。

```js
function handleAggregatedOps(
    UserOpsPerAggregator[] calldata opsPerAggregator,
    address payable beneficiary
);
```

この関数は、複数のアグリゲーターを含むUserOperationのバッチ処理を行います。

```js
struct UserOpsPerAggregator {
    PackedUserOperation[] userOps;
    IAggregator aggregator;
    bytes signature;
}
```

アグリゲーターと対応するUserOperationのリスト、および集約署名をまとめて渡します。
`handleAggregatedOps`は、各アグリゲーターに対して`validateSignatures`を呼び出し、検証に成功したものだけを処理対象とします。

### エラーと署名指定

署名アグリゲーターが正しく指定されていない場合、以下のエラーが返されることがあります。

```
code: -32506 - transaction rejected because wallet specified unsupported signature aggregator
```

このとき、`validateUserOp()`で返されたアグリゲーターのアドレスが`data`フィールドに含まれていることが推奨されます。

## 補足

#### 代替署名を返す理由

アグリゲーターを利用する場合、アカウント自身がUserOperationの署名検証を行う代わりに、検証をアグリゲーターに委任します。
このとき、アグリゲーターは`validateUserOpSignature`関数を通じて、元の署名の代わりに使われる「代替署名（alternative signature）」を生成します。

これにより、アカウント側の`validateUserOp`関数では、署名以外のロジック（残高確認やタイミング制御など）を実行でき、署名自体の検証は完全にアグリゲーターに任せることが可能になります。

## 互換性

**ERC7766**は、すでに導入済みの**ERC4337**のEntryPointコントラクトを変更することなく機能を拡張します。
元々**ERC4337**では署名の集約が将来的な機能として想定されていたため、今回の追加仕様もその設計の枠内に収まっています。

そのため、既存のアカウントやバンドラーと衝突することなく、新機能を段階的に導入できる互換性があります。

## セキュリティ

アグリゲーターは、コントラクトアカウントの代わりにトランザクションの承認を行う非常に信頼度の高いコントラクトです。
そのため、不正なアグリゲーター（malicious aggregator）が存在すると、多数のUserOperationを一括で無効化したり、悪意あるトランザクションを通すリスクがあります。

アグリゲーターを利用するアカウント開発者や、バンドルを処理するブロックビルダーは、どのアグリゲーターを許可するかを慎重に判断する必要があります。
不適切なアグリゲーターの採用は、エコシステム全体の安全性に深刻な影響を及ぼします。

## 引用

Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat), "ERC-7766: Signature Aggregation for ERC-4337 [DRAFT]," Ethereum Improvement Proposals, no. 7766, September 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7766.

## 最後に

今回は「アグリゲーターという新しいコントラクトを導入し、複数のUserOperationを一括で検証・承認する仕組みを提案している**ERC7766**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4