# [ERC7779] EIP-7702時代のEOA再委任とストレージ衝突防止の仕組みを理解しよう！

> ERC7779は、EIP7702によって導入される「委任可能なEOA（Delegated EOA）」同士が、異なるウォレットやスマートアカウント実装間でも安全かつ一貫して動作するための共通インターフェースを定義する提案です。

- URL: https://cardene.dev/articles/54fbb63f9c4eaee1007a
- 公開日: 2026-01-20
- 更新日: 2026-01-20
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、**EIP7702**によって委任可能になったEOAが、異なるウォレット実装間でもストレージ構造を検証しながら安全に移行できるようにする仕組みを提案している**ERC7779**についてまとめていきます！

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

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

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

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

## 概要

**ERC7779**は、**EIP7702**によって導入される「**委任可能なEOA（Delegated EOA）**」同士が、異なるウォレットやスマートアカウント実装間でも安全かつ一貫して動作するための共通インターフェースを定義する提案です。

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

[\[EIP7702\] EOAをコントラクトアカウントに変換する仕組みを理解しよう！](/articles/13a828c97786aab953e4)

**EIP7702**により、従来は単なる署名主体でしかなかったEOA（Externally Owned Account）が、スマートコントラクトのような実行ロジックを委任できるようになります。
これにより以下のような高度な機能が実現可能になります。

* ガス代のスポンサー支払い（ガスレス取引）
* 複数処理の一括実行（バッチトランザクション）
* 定期支払い・自動実行
* 1ステップでの複雑なDeFi操作

このようにEOAが「**スマートアカウント化**」することで、ユーザー体験は大きく向上します。
しかし同時に、新しい問題が生じます。
それが「**ストレージの衝突と再委任時の管理**」です。

委任されたEOAは、接続先のスマートアカウントコントラクトのストレージ領域を使用します。
ここで異なる実装のスマートアカウントへ再委任した場合、以下のようなリスクが発生します。

* 既存のストレージ構造と新しい実装の構造が衝突する
* 不正なスロット上書きによりアカウントが操作不能になる
* 権限管理や検証ロジックが破壊され、資産が危険にさらされる

**ERC7779**は、この問題を解決するために以下を標準化します。

- 委任アカウントが使用しているストレージの「**基点スロット（storage base）**」を取得するための共通インターフェース
- 再委任時に古いストレージを安全にクリーンアップするための仕組み（オプション）

これにより、異なるスマートアカウント実装間での再委任やウォレット移行を、安全かつ予測可能に行えるようにします。

また、この仕様は**EIP7702**専用ではなく、独自のストレージスロット設計を持つすべてのスマートアカウントやスマートコントラクトに適用可能な一般的な設計思想として定義されています。

## 動機

**EIP7702**がメインネットに統合された後、多くのEOAウォレットは、従来の「**単純な鍵管理アカウント**」から「**スマートアカウントに委任されたEOA**」へ移行すると想定されています。
理由は明確で、以下のようなUXが実現できるためです。

* 1トランザクションでのトークンスワップと承認の同時実行
* サブスクリプション型の自動支払い
* ガス代を第三者が肩代わりする仕組み
* セキュリティルールの柔軟なカスタマイズ

一方で、委任型EOAは内部的にスマートコントラクトのストレージを利用するため、ウォレット実装ごとに以下の情報がチェーン上に永続化されます。

* ノンス管理
* 検証ロジック用の設定値
* モジュール構成
* 権限管理データ

ここで重要なのは、ユーザーがウォレットアプリを変更しても、EOA自体は同一アドレスのまま委任先だけが変わる点です。
つまり、秘密鍵やアドレスが同じだが、内部ストレージ構造は新しいスマートアカウント実装に切り替わるという状態になります。

従来のEOAは、単なる「**秘密鍵とアドレス**」のみで構成されており、どのウォレットでも完全に互換でした。
ニーモニックをインポートすれば、すぐに別のウォレットへ移行できるという単純さが、ユーザーの主権性を支えていました。

しかし委任型EOAでは、以下の新たな「移行リスク」が発生します。

* ストレージ構造が実装依存になる
* スロット設計が異なると衝突が起きる
* 不適切な再委任によりアカウントがロックされる可能性がある

さらに、アカウントアブストラクション型ウォレット（例：**ERC4337**系）でも同様の互換性問題は存在しますが、EOAはもともと「**ウォレット移行が当たり前**」の文化があるため、この問題の影響ははるかに大きくなります。

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

https://zenn.dev/heku/books/88e65212339061/viewer/77d826

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

そこで**ERC7779**は以下を目的として設計されています。

| 目的          | 内容                                  |
| ----------- | ----------------------------------- |
| ストレージ基点の標準化 | 委任先コントラクトが使用するストレージ範囲を安全に特定できるようにする |
| 再委任時の安全性    | 古い実装のデータを明示的に整理・初期化できる仕組みを提供する      |
| ウォレット間移行の自由 | ユーザーが実装差異を意識せずにウォレットを切り替えられるようにする   |
| 主権性の維持      | 秘密鍵ベースの自由な移行体験を、スマートアカウント時代でも維持する   |

結果として**ERC7779**は、**EIP7702**時代における「**EOAの互換性レイヤー**」として機能し、スマートアカウント化によって失われかねないウォレット間の可搬性と安全な再委任を両立させるための基盤仕様となります。

![image.png](/images/qiita-f7b7983c-8961-422e-b16e-81d11a42c040.webp)
https://eips.ethereum.org/EIPS/eip-7779

## 補足

#### ストレージ基点チェック

**ERC7779**は、再委任（別実装への切り替え）の前に「**ストレージが安全か**」をウォレット側が検証できることを重視しています。
「**keccak256のハッシュ空間は十分広いので、ウォレットごとに違う基点を使えば衝突しないはず**」と考える人もいますが、**ERC7779**は逆の立場です。
つまり「**確率に任せず、確認する価値がある**」です。

理由は、ストレージ衝突は起きたら致命的だからです。
EOAの委任先実装が変わると、同じアドレスのストレージ空間に別のレイアウトが乗ります。
このとき、偶然でも意図的でも衝突があると、ロックや脆弱性に直結します。

ここでの考え方は、Diamond（**ERC-2535**）でFacetのストレージ配置を検証して衝突を避けるのと近いです。
単に「**ハッシュだから大丈夫**」とはせず、実際に安全性を確認する発想です。

この思想に沿って `accountStorageBases()` は「**現在の実装が使う基点**」だけでなく、「**過去に使われた基点の履歴も含めて全部返す**」ように設計されています。
これにより、ウォレットは委任前にEOAのストレージをスキャンする際に、過去の実装で使っていた領域まで含めてリスク判断ができます。

要点を表にすると以下です。

| 何をしたいか | **ERC7779**が用意するもの | 期待される効果   |
| ------------- | -- | -------------- |
| 再委任前に衝突を避けたい  | `accountStorageBases()` でストレージ基点の履歴を取得 | 「**既存データがある場所**」と「**新実装が使う場所**」の距離や危険性を事前に評価できる |
| ハッシュ確率に頼りたくない | 基点を公開し、スキャン判断を可能にする     | たぶん大丈夫ではなく、根拠を持って委任可否を決められる      |

#### 任意の `onRedelegation`()

`onRedelegation()` が任意なのは、**ERC7779**準拠のハードルを下げるためです。
すべてのアカウント実装が「**再委任前フック**」を必要とするわけではありませんし、実装によってはフックに向かない設計もあります。

例えば以下のようなケースです。

* 再委任前に特に整理すべき状態を持たない実装
* `mapping` を多用していて、初期化解除（uninitialize）が現実的に難しい実装
* データ構造が複雑で「戻す」こと自体が設計思想に合わない実装

また重要なのは、`onRedelegation()` は「**ストレージを完全消去する義務**」ではない点です。
**ERC7779**が求めているのは、完全消去よりも「**ベストエフォートでできるだけクリーンにする**」こと、または「**再委任に必要な準備処理をする**」ことです。

## 互換性

**ERC7779**は、**EIP7702**の議論より前に作られた既存のスマートアカウントに対して、そのままでは対応できない可能性があります。
理由は、既存実装の多くが以下を持っていないからです。

* `accountId()` のような識別情報の公開手段
* `accountStorageBases()` のようなストレージ基点（履歴含む）を外部に知らせる仕組み
* 任意ですが `onRedelegation()` のような再委任準備フック

そのため、既存のスマートアカウントが**ERC7779**に対応するには、インターフェース実装やストレージ基点履歴の管理など、一定の変更が必要になります。

また、**ERC7779**は「EOA向けスマートアカウント」を主対象にしていますが、考え方自体はより広い領域に適用できます。
つまり、独自ストレージスロットを使うスマートアカウントやスマートコントラクト全般でも、同じ問題（ストレージ衝突や移行時の残骸）が起き得るため、応用範囲は広いです。

## セキュリティ

#### `onRedelegation` の呼び出し認証

`onRedelegation()` を呼べるのは、正当な所有者である必要があります。
呼び出し元の確認（owner authentication）がないと、第三者が勝手にクリーンアップ処理を走らせて、アカウントを壊したり弱体化させたりできます。

仕様上は「**所有者を正しく認証する仕組みを含めるべき**」です。
前段の仕様説明でも触れている通り、基本は `msg.sender` を所有者としてチェックする前提です。

#### 標準が“強制”していることと、実装が守るかは別問題

**ERC7779**は、アカウントに対して以下を強制する立て付けです。

* `accountStorageBases()` で適切な基点スロット情報を提供すること
* `onRedelegation()` 対応なら、可能な限りストレージをクリーンにする行動を取ること
* ストレージスロット計算に `keccak256()` を使うこと

ただし、実際にその通りの「**振る舞い**」をしているかは実装次第です。
つまり、インターフェースだけ合わせて中身が雑、あるいは悪意ある実装が混ざる可能性は残ります。

このため、必要ならオフチェーンで情報の正しさを検証してもよい、と書かれています。
ここでいう「**オフチェーン検証**」は、チェーン上の値を読むだけでなく、既知の安全な実装か、監査済みか、過去の挙動に不審点がないかを外部情報も使って確認するイメージです。

#### ストレージ全消去は常に可能ではない

ストレージを完全に消す（wipe out）ことは、実装によっては現実的ではありません。
特に `mapping` や複雑なデータ構造は、キー一覧を持たない限り「**全部を確実に初期化**」できません。

そのため **ERC7779** は「**完全消去を推奨するができない例外はあり得る**」としています。
ただし、できない場合でも「**可能な限りベストな整理をする**」ことは期待されています。

#### `onRedelegation` 後の初期化フローの乗っ取り防止

`onRedelegation()` のあと、初期化処理（`initializer`）が第三者に勝手に呼ばれると危険です。
例えば、クリーンな状態に戻した直後に第三者が初期化を走らせ、権限や署名者を差し替えるような事故が起き得ます。

そのため **ERC7779** は、`onRedelegation()` 呼び出し後に「**任意の第三者が `initializer` を発行できない**」ように注意すべきだとしています。

#### リプレイ保護をリセットしない

`onRedelegation()` でリプレイ保護をリセットしてはいけません。
ここでいうリプレイ保護は、同じ署名や同じ操作が繰り返し実行されるのを防ぐ仕組みです。一般的には nonce 管理が該当します。

もしこれをリセットすると、過去の署名が再利用される「署名リプレイ攻撃」の入口になります。
そのため **ERC7779** は、`onRedelegation()` がリプレイ保護をリセットしないように求めています。

#### “ERC準拠”を名乗る偽実装への注意

**ERC7779**はERCなので、誰でも「**準拠しています**」と言えてしまいます。
しかし実際には準拠していない、または危険な挙動をする実装もあり得ます。

そのため **ERC7779** は、「**その実装が既知で安全**、かつ標準に沿っているかを検証するのが推奨」としています。
ここでのポイントは、標準の存在だけで安全が保証されるわけではなく、実装の信頼性確認が必要だということです。

#### `keccak256` によるスロット計算の強制と `preimage` の自由度

**ERC7779**は、衝突を減らすためにストレージスロット計算を `keccak256()` にすることを強制しています。
一方で、ハッシュの元になる文字列（preimage）は、実装側が自由に決めてよいとしています。

`preimage` は、名前、バージョン、複数情報の組み合わせなどが想定されています。これにより、実装ごとにユニークなストレージ基点を作りやすくなります。

## 引用

David Kim (@PowerStream3604), Richard Meissner (@rmeissner), Akshay Patel (@akshay-ap), Joshua Kim (@LightningHun), Fangting (@trinity-0111), Yoav Weiss (@yoavw), "ERC-7779: Interoperable Delegated Accounts [DRAFT]," Ethereum Improvement Proposals, no. 7779, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7779.

## 最後に

今回は「**EIP7702**によって委任可能になったEOAが、異なるウォレット実装間でもストレージ構造を検証しながら安全に移行できるようにする仕組みを提案している**ERC7779**」についてまとめてきました！
いかがだったでしょうか？

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

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

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

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

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