はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、スマートコントラクトが持つ操作権限を、他のコントラクトやEOAに対して安全かつ柔軟に委譲できる仕組みを提案しているERC7710についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
ERC7710は、スマートコントラクトが持つ権限や実行能力を、他のスマートコントラクトやEOA（Externally Owned Account）に委譲するための標準仕様です。
ここでいうEOAとは、秘密鍵によって操作される通常のユーザーアカウントのことです。 コントラクトアカウントとは異なり、コードを持たず、トランザクションの署名と送信を行う役割を担います。
ERC7710では、権限を委譲する側のコントラクトを「デリゲーター（delegator）」と呼びます。 デリゲーターは、自身の代わりに処理を実行させたい相手に直接すべてを任せるのではなく、「DelegationManager」と呼ばれる専用のコントラクトを明示的に許可します。
このDelegationManagerは、デリゲーターから認可された範囲内でのみ、デリゲーターを呼び出して特定の処理を実行できます。 つまり、誰が・何を・どこまで実行できるのかを、コントラクトレベルで明確に制御できる仕組みです。
この仕組みにより、デリゲーターは「自分が本来実行できる操作」であれば、その一部または全部を、他の主体に委ねることが可能になります。 結果として、スマートコントラクト同士の連携や役割分担を、より柔軟かつ拡張しやすい形で設計できるようになります。
ERC7710が定義するのは、こうした委譲を実現するために最低限必要なインターフェースのみです。 余計な実装を強制せず、アプリケーションごとの設計自由度を保つ点が特徴です。
また、この標準はERC4337（アカウントアブストラクション）と互換性があります。 ただし、ERC7710を利用するためにERC4337を必須とするわけではありません。 従来のEOAベースの環境でも利用できる設計になっています。
動機
現状のスマートコントラクト連携の課題
Ethereum上のスマートコントラクトは、いわゆる「コンポーザビリティ」を強みとしています。 これは、複数のdAppやコントラクトが互いに呼び出し合い、機能を組み合わせて新しい価値を生み出せる性質です。
しかし、実際に「権限」や「実行能力」を共有しようとすると、多くの問題が発生します。
現在一般的な方法では、以下のような対応が必要になります。
- 特定のアドレスをハードコードして許可する
- 専用の中継コントラクトを個別に実装する
これらは一見単純に見えますが、実際には以下のような問題を抱えています。
- 実装が複雑になりやすい
- 開発とテストに時間がかかる
- デプロイ時・実行時のガスコストが増加する
- 既存コントラクトとの後方互換性が低い
さらに、こうした仕組みは一度作ると変更が難しく、新しい要件に柔軟に対応しづらいという問題もあります。 「この操作だけを許可したい」、「一時的にだけ権限を渡したい」といった細かい制御が困難です。
ユーザー体験における署名の問題
もう1つの大きな課題が、署名の回数です。
多くのdAppでは、操作のたびにユーザーに署名を求めます。 特に、頻繁な操作や自動化された処理が必要なケースでは、以下のような問題が顕在化します。
- ユーザーが何度もウォレット操作を求められる
- UXが悪化し、利用を避けられる
- 自動化やバックグラウンド処理が難しい
これは、人が直接操作する前提で設計された現在の仕組みの限界とも言えます。
ERC7710が目指す解決策
ERC7710は、これらの課題を「一度の署名による、長期間有効な権限委譲」によって解決しようとしています。
ユーザーやコントラクトは、単一の署名で「どの操作を」、「どの範囲で」、「誰に」委譲するかを明確に定義できます。 その結果、以下のような使い方が可能になります。
| 利用例 | 説明 |
|---|---|
| 継続的なdAppセッション | 毎回署名せずに、一定条件下で操作を許可できます |
| AIエージェントへの権限付与 | 制限付きで自動実行を任せられます |
| 招待リンクの共有 | 特定の操作だけ可能なリンクを発行できます |
| 第三者による代理実行 | 明確なポリシーの範囲内で処理を委任できます |
重要なのは、「何でも自由にできる権限」を渡すのではなく、「ルールで制約された権限」を渡せる点です。 これにより、安全性を保ちながら、ユーザー操作の回数を大幅に減らせます。
標準化によるメリット
ERC7710は、権限委譲の方法を標準化することで、Ethereum全体の開発効率を高めることを目的としています。
個別実装に頼らず、共通の枠組みで委譲を扱えるようになることで、以下の効果が期待されます。
- 実装の複雑さを減らせます
- ガスコストを抑えられます
- コントラクト設計の柔軟性が高まります
- dApp同士の連携が容易になります
結果として、各dAppは自分たちの強みに集中でき、Ethereumエコシステム全体としての協調と進化が進みます。
ERC7710は、スマートコントラクトの権限管理を「その場しのぎの実装」から「再利用可能な仕組み」へ引き上げるための基盤となる標準です。
仕様
用語定義
ERC7710では、委譲に関わる役割が明確に定義されています。
デリゲーター（Delegator）
デリゲーターは、委譲を作成できるスマートコントラクトです。 本来は自分自身が実行する操作を、他者に実行させる「権限の持ち主」にあたります。
デリゲーションマネージャー（Delegation Manager）
デリゲーションマネージャーは、委譲の正当性を検証し、デリゲーターを呼び出して実際の処理を実行するスマートコントラクトです。
このコントラクトは ERC7710Manager インターフェースを実装する必要があります。
主な役割は以下です。
- 委譲（delegation）が正しく、まだ有効かを検証する
- 問題なければ、デリゲーターの特権関数を呼び出す
なお、デリゲーションマネージャーの実装は1つに限られません。 用途ごとに異なる実装が存在してもよく、コントラクト自身が自分のデリゲーションマネージャーになることも可能です。
デリゲーション（Delegation）
デリゲーションとは、「特定の操作を実行してよい」という権限そのものです。 誰が、どの操作を、どの条件で実行できるか、という情報を含みます。
デリゲート（Delegate）
デリゲートは、デリゲーションを使う権限を持つ主体です。 スマートコントラクト、コントラクトアカウント、EOAのいずれでも構いません。
リディーマー（Redeemer）
リディーマーは、実際にデリゲーションを使って処理を実行しているデリゲートを指します。 「権限を持っている存在」と「今まさに使っている存在」を区別するための用語です。
デリゲーションの取得について
ERC7710は、デリゲーションを「どうやって取得するか」については定義していません。
この仕様が対象としているのは、以下の2点に限定されています。
- デリゲーションを使うためのインターフェース
- デリゲーションの正当性をどう検証するか
デリゲーションの発行方法は、ユースケースによって大きく異なるためです。 例えば、ERC7715や独自プロトコルを使っても構いません。
このように責務を分離することで、以下の柔軟性が得られます。
- 委譲の作成方法は自由に設計できる
- 使う側のインターフェースは共通化できる
全体の流れ
デリゲーションの行使
デリゲートがデリゲーションを使いたい場合、デリゲーションマネージャーの redeemDelegations 関数を呼び出します。
このとき、以下の情報を渡します。
- 実行したい操作の内容
- その操作を実行してよいことを証明する権限情報（デリゲーション）
デリゲーションマネージャーは、それらを検証し、問題なければデリゲーターの特権関数を呼び出します。 処理はデリゲーターの権限で実行されます。
処理フロー図
以下は、redeemDelegations が呼ばれたときの流れを示した図です。
sequenceDiagram
participant Delegate
participant DelegationManager
participant Delegator
Delegate->>DelegationManager: redeemDelegations(...)
DelegationManager->>DelegationManager: 権限を検証
DelegationManager->>Delegator: 特権関数を呼び出す
Delegator-->>DelegationManager: 実行結果
DelegationManager-->>Delegate: 完了インターフェース仕様
pragma solidity 0.8.23;
/**
* @title ERC7710Manager
* @notice Interface for Delegation Manager that exposes the redeemDelegations function.
*/
interface ERC7710Manager {
/**
* @notice This method validates the provided permission contexts and executes the execution if the caller has authority to do so.
* @dev the structure of the _permissionContexts bytes[] is determined by the specific Delegation Manager implementation
* @param _permissionContexts the data used to validate the authority given to execute the corresponding execution.
* @param _action the action to be executed
* @param _modes the array of modes to execute the related executioncallData
* @param _executionCallDatas the array of encoded executions to be executed
*/
function redeemDelegations(
bytes[] calldata _permissionContexts,
bytes32[] calldata _modes,
bytes[] calldata _executionCallData
) external;
}デリゲーションマネージャーは、必ず redeemDelegations 関数を実装する必要があります。
この関数は、委譲の検証と実行の両方を担います。
redeemDelegations の役割
redeemDelegations は、以下を行います。
- 渡された権限情報が正しいかを検証します
- 問題なければ、対応する処理を実行します
引数
permissionContexts
_permissionContexts は、どの操作を実行してよいかを証明するためのデータです。
中身の構造は、デリゲーションマネージャーの実装ごとに自由に決められます。
modes と executionCallDatas
_modes と _executionCallDatas は、ERC7579で定義されている実行形式に従います。
modeは「どう実行するか」を表します- 単一実行
- バッチ実行 など
executionCallDataは「何を実行するか」を表します- 実行対象アドレス
- 送信するETHの量
- 関数呼び出しデータ
配列の対応関係と制約
3つの配列は、同じインデックス同士で1つの処理を表します。
| 要素 | 内容 |
|---|---|
permissionContexts[i] |
権限情報 |
modes[i] |
実行モード |
executionCallDatas[i] |
実行データ |
配列の長さが一致しない場合、必ずエラーを返す必要があります。 また、複数処理をまとめて実行する場合は、全体が原子的（途中失敗なし）に実行される必要があります。
パーミッション検証の考え方
ERC7710では、「権限を事前に確認する専用関数」はあえて定義していません。
代わりに、dApp側は以下の方法で検証することが推奨されています。
- 実際に
redeemDelegationsを実行する想定でシミュレーションします - 成功するかどうかで権限の有無を判断します
- 失敗した場合は、ユーザーに新しい権限を要求します
この方法により、以下を含めた実行全体を検証でき、単純な権限チェック関数よりも安全性が高い設計です。
- 実行条件
- 呼び出し内容
- 状態変化
補足
ERC7710は、Ethereum上で「委譲（delegation）」を標準化し、安全で効率よく扱えるようにするための設計です。 背景には、dAppやスマートアカウントが増える中で、権限を共有したり、他者に代理実行させたりする需要が強くなっている一方、実装がバラバラで安全性や互換性に課題が出やすい、という状況があります。
柔軟性と拡張性
ERC7710のインターフェースは「最小限」ですが、「できることは広い」ことを狙っています。 委譲の仕組みを標準化しつつ、各プロダクトが重い実装を強制されないようにして、採用しやすくしています。 結果として、委譲できる操作の幅を広げながら、エコシステム全体で使われやすいバランスを取っています。
相互運用性
ERC7710は既存標準との整合性を意識しています。 例として、コントラクト署名の検証で使われるERC1271や、アカウント抽象化の文脈で使われるERC4337と組み合わせやすい設計です。
ERC1271については以下の記事を参考にしてください。
ERC4337については以下の記事を参考にしてください。
ここでいう ERC1271は、「コントラクトが署名を検証する方法」を定義する標準です。 EOAのように秘密鍵で署名できないコントラクトでも、署名相当の承認を扱えるようになります。 ERC4337は、EOAに依存しないユーザー操作（UserOperation）を可能にする標準で、スマートアカウントの運用を広げる仕組みです。
ERC7710はこれらと互換性を持たせることで、既存のセキュリティ慣行やインフラを活かしながら導入しやすくしています。
使いやすさ
ERC7710により「特定の操作だけを他者に委譲する」ことがやりやすくなります。 その結果、dAppはユーザーの代わりに複数の処理を実行しやすくなり、ユーザーが毎回ウォレットで操作・署名する頻度を下げられます。 これはUX改善に直結します。
最後に、ERC7710はスマートコントラクト同士の連携をより現実的にし、ユーザーの要求に合わせて権限設計を調整しやすい、より柔軟で相互接続性の高いEthereumを目指す一歩、という位置づけです。
実行インターフェース
過去の仕様
以前の仕様案では、Action を (target, value, data) の単純なタプルとして定義していました。
そして、デリゲーター側が次のような専用関数を実装し、デリゲーションマネージャーがそれを呼ぶ想定でした。
executeDelegatedAction(Action _action)
ここで target は呼び出し先、value は送金額（ETH）、data は関数呼び出しデータ（calldata）です。
その案の問題点
このアプローチには明確な欠点がありました。
| 問題 | 具体的に困ること |
|---|---|
| 既存のスマートアカウントと互換になりにくい | すでに運用されているスマートアカウントが、その専用関数を実装していなければ対応できません |
| 実行表現が単発呼び出しに限定される | Actionが単一コールしか表現できず、バッチ実行や delegatecall、CREATE2 などの複雑な実行ができません |
delegatecall は「呼び出し先のコードを、呼び出し元のストレージ文脈で実行する」仕組みです。
プロキシやモジュール構成でよく使われます。
CREATE2 は「デプロイ先アドレスを事前に決めやすいコントラクト作成命令」で、アドレスの予測可能性が必要な設計で使われます。
解決策1：デリゲーターに特定インターフェースを要求しない
互換性の問題に対して、ERC7710はデリゲーターに「特定の実行インターフェースの実装」を要求しない方針を取りました。
代わりに、以下の前提で成立させています。
- デリゲーションマネージャーが、デリゲーターを正しく呼び出す
- デリゲーターは「その呼び出し方を理解しているデリゲーションマネージャー」に対してだけ
_permissionContextsを発行する
つまり「このマネージャーなら自分を正しく扱える」という関係性を、_permissionContexts の生成側（デリゲーター）に持たせています。
解決策2：ERC7579の実行インターフェースを採用する
実行表現が貧弱という問題に対して、ERC7710はERC7579の実行インターフェースを採用しました。
ERC7579については以下の記事を参考にしてください。
ERC7579 は、モジュール型スマートアカウントのために「多様な実行形態を標準化する」必要があり、単発コールだけでなく、バッチなど複数の実行パターンを扱えるように設計されています。 ERC7710は同じ問題を抱えるため、その解決策を流用した形です。
参考実装
最小の参考実装：Example7710Manager
委譲の「行使（redeem）」に焦点を当てた最小実装として、Example7710Managerが挙げられています。
ここでは主に「redeemDelegations を受けて検証して実行する」という骨格が確認できます。
完全な参考実装：MetaMask Delegation Framework
より実用的で堅牢なデリゲーションマネージャーの例として、MetaMaskのDelegation Frameworkが紹介されています。 これは、ERC7710のインターフェース要求を満たしつつ、運用上必要になりやすい機能をまとめて持っています。
含まれる機能は以下です。
| 機能 | 意味 |
|---|---|
| EIP712 署名検証 | 構造化データ署名で、委譲内容を明確にした上で署名させ、検証します |
| EOA署名とコントラクト署名の両対応（ERC1271） | EOAだけでなく、コントラクトによる署名承認も扱えます |
| Caveat enforcement | 委譲に「条件（制約）」を付けて細かく制御します |
| バッチ処理 | 複数の委譲をまとめて処理できます |
| 委譲の取り消し（revocation） | すでに発行した委譲を無効化できます |
ここで Caveat は「委譲に付ける条件」です。
例えば、「このdAppだけ」、「この関数だけ」、「この回数まで」、「この金額まで」のように、許可範囲を縛るために使います。
MetaMaskの実装は、ERC7710の要求を満たしながら、現実のプロダクトで必要になる機能を足した「一つの実装例」です。 ERC7710自体がこれらを必須にしているわけではありませんが、堅牢なシステムを作る場合の参考になります。
セキュリティ
ERC7710は「カスタマイズ可能な認可条件」を扱える設計です。
つまり _permissionContexts の中身を実装ごとに自由に定義できるぶん、設計を誤ると危険になり得ます。
リスクとして挙げられているのは次の2点です。
- 認可条件の解釈ミス
- インターフェース実装の不備による不正実行
例えば、permissionContext のパースや検証ロジックに穴があると、本来許可していない操作が通ってしまう可能性があります。 また、デリゲーションマネージャーがデリゲーターを呼ぶ手順を誤ると、意図しない関数が呼ばれる、あるいは権限境界が崩れる可能性もあります。
そのため、アプリケーション実装に対して十分なセキュリティ監査が推奨されています。
特に、permissionContext の構造設計、検証の境界、失効や取り消しの扱いは監査対象として重要です。
権限検証
dAppは「過去に委譲を受け取ったことがある」だけで、将来も実行権限があると決めつけてはいけません。 委譲は、取り消し（revoked）されたり、有効期限切れ（expire）になったり、状態変化で無効化されたりします。
そのため、信頼性を上げるための運用として、次が求められています。
実運用で必要な対応
| 要件 | 目的 |
|---|---|
| オンチェーン送信前に常にシミュレーションする | 今この瞬間に通る委譲かを確認します |
| シミュレーション失敗を適切に扱う | ユーザーに新しい権限を要求するなど、UXを壊さず回復させます |
| リトライを検討する | 権限要求を段階的に強めるなど、復旧手段を用意します |
| シミュレーションと実行の間で無効化され得る前提を持つ | フロントラン、失効、取り消しなどを想定します |
「シミュレーション」は、実トランザクションを送る前に eth_call などで同じ呼び出しを試し、成功するかを見ることです。
これにより、委譲の状態、デリゲーターの状態、マネージャーの検証ロジックまで含めた「実行全体の成否」を事前に判断できます。
実行と検証の関係図
シミュレーションとオンチェーン実行の関係を、流れとして整理すると以下です。
flowchart TD
A[dAppが委譲を受け取る] --> B[redeemDelegations をシミュレーション]
B -->|成功| C[オンチェーンで redeemDelegations を送信]
B -->|失敗| D[新しい/更新された権限をユーザーに要求]
C --> E{実行時にまだ有効か}
E -->|有効| F[デリゲーターの権限で実行成功]
E -->|無効| G[リバート/失敗を処理し再要求やリトライへ]引用
Ryan McPeck (@McOso), Dan Finlay (@DanFinlay), Rob Dawson (@rojotek), Derek Chiang (@derekchiang), "ERC-7710: Smart Contract Delegation [DRAFT]," Ethereum Improvement Proposals, no. 7710, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7710.
最後に
今回は「スマートコントラクトが持つ操作権限を、他のコントラクトやEOAに対して安全かつ柔軟に委譲できる仕組みを提案しているERC7710」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
