EIP-3074 vs EIP-7702 vs ERC-4337:開発者向け完全ガイド
執筆者 Usman Asim
Ethereumのウォレットエコシステムは進化を続けており、プログラマブルな未来に向けて前進しています。その中でEIP-7702は、完全なアカウント抽象化(ERC-4337)に向けた重要なステップとなっています。ですが、なぜ7702がsmart walletsを通じたEthereumとの関わり方を変えようとしているのかを理解するには、7702の基盤を築いた提案であるEIP-3074に触れておく必要があります。
アプリを開発しているエンジニアであれば、Externally Owned Accounts (EOAs) ―秘密鍵によって制御されるEthereumの従来型ウォレット―の限界に直面したことがあるはずです。EIP-3074は、EOAがスマートコントラクト(invoker)に制御を委譲する方法を導入し、ガスの肩代わりやバッチトランザクションといった機能を可能にしました。EIP-7702はこれをさらに発展させ、より洗練された、より安全なアカウント抽象化への道を提供します。
開発者にとって、この仕組みはユーザーを従来のEOAのまま維持しながら、高度な機能をアプリに追加することを簡素化します。ユーザーにとっては、より滑らかな体験を意味します。例えば、サードパーティによるガス支払いや、複数のDeFi取引をワンクリックで実行することなどが挙げられます。
このガイドでは、背景を理解するために3074の仕組みを解説し、コードを用いて7702の進歩を示し、両者をERC-4337と比較します。それでは技術的な内容に入っていきましょう。
EIP-3074が解決しようとした課題
EOAはシンプルです。秘密鍵でトランザクションに署名し、Ethereumネットワークに送信します。しかし、制限もあります。コードを実行できず、アクションをバッチ化できず、失われた鍵をネイティブに復旧することもできません。スマートコントラクトウォレット(ERC-4337によって実現される)はより高い柔軟性を提供しますが、ユーザーは新しいアドレスを管理する必要があり、多くの場合ガスコストも高くなります。EIP-3074は、AUTHとAUTHCALLという2つのEVMオペコードを導入することで解決策を提案し、EOAがinvokerコントラクトに制御を委譲できるようにし、ウォレットの移行なしにスマートコントラクトのような機能を追加できるようにしました。
EIP-3074は、EthereumのアカウントAbstractionロードマップ、すなわちEOAからSmart EOA(EIP-7702)へ、そして最終的には完全なSmart Wallets(ERC-4337)へという流れを形作った概念実証でした。3074の仕組みを見ていくことで、それがどのように道を切り開いたのかを理解しましょう。
スマートウォレットは、シームレスなオンチェーンUXでアプリの成長を支援します。
EIP-3074の中核要素:7702の基盤
EIP-3074は、AUTHオペコード、AUTHCALLオペコード、そしてinvokerコントラクトという3つの要素を中心としています。これらは7702がその原則の上に構築されているため、理解しておく価値があります。
1. authオペコード
AUTHオペコード(hex 0xf6)は、EOAからのECDSA署名を検証し、そのEOAが特定のinvokerに代理としての行動を許可したことを証明します。EOAは、invokerのアドレスとコミットメント(実行されるアクションのハッシュ)を含むメッセージに署名します。署名が有効であれば、EVMは認証済みのコンテキストを設定します。
以下は、AUTHの署名検証を模したSolidityのスニペットです。
*// Invoker contract: Verify EOA authorization*
function authenticate(bytes memory signature, address eoa, bytes32 commitment) public pure returns (bool) {
*// Hash the message the EOA signed*
bytes32 messageHash = keccak256(abi.encodePacked(eoa, commitment));
*// Recover the signer from the signature*
address signer = recoverSigner(messageHash, signature);
*// Check if the signer matches the EOA*
return signer == eoa;
}
_// Helper function to recover signer_
function recoverSigner(bytes32 messageHash, bytes memory signature) internal pure returns (address) {
bytes32 r; bytes32 s; uint8 v;
assembly {
r := mload(add(signature, 32))
s := mload(add(signature, 64))
v := byte(0, mload(add(signature, 96)))
}
return ecrecover(messageHash, v, r, s);
}このコードは、EOAが制御を委譲する意図を検証します。認証されると、invokerはEOAとして振る舞うことができます。
2. authcallオペコード
AUTHCALL(hex 0xf7)は、invokerがEOAとしてトランザクションを実行できるようにするもので、呼び出し元としてEOAのアドレスを使用しながら、invokerがガスを支払うことができます。これにより、3074ではガスの肩代わりやバッチ処理が可能になりました。
以下は、アセンブリでのAUTHCALLの使用例です。
// Invoker contract: Execute a call as the EOA
function executeAsEOA(address target, bytes memory data) public {
// Assumes prior AUTH verification
assembly {
// AUTHCALL: gas, target, value, argsOffset, argsSize, retOffset, retSize
let success := authcall(gas(), target, 0, add(data, 32), mload(data), 0, 0)
if iszero(success) {
revert(0, 0)
}
}
}このスニペットは、EOAとしてターゲットコントラクト(例:DeFiプロトコル)を呼び出します。gas\(\)関数は残りのガスを割り当て、AUTHCALLはそのアクションがEOAのアイデンティティを反映することを保証します。
3. Invokerコントラクト
Invokerは、EOAが委譲するスマートコントラクトです。EIP-3074のinvokerは永続的な存在であり、これが7702で対処されるセキュリティ上の懸念を生んでいました。以下は、ガスの肩代わりとバッチ処理のための3074スタイルのinvokerです。
⚠️ セキュリティに関する注意: invokerは監査され、慎重に構築される必要があります。欠陥のあるinvokerは署名を悪用したり、アクションをリプレイしたりする可能性があります。
// EIP-3074 invoker for gas sponsorship and batching
contract LegacyInvoker {
address public authorizedEOA;
// Set authorized EOA
function setAuthorizedEOA(address eoa, bytes memory signature, bytes32 commitment) external {
require(authenticate(signature, eoa, commitment), "Invalid signature");
authorizedEOA = eoa;
}
// Execute batch transactions, optionally sponsored
function executeBatch(
address[] memory targets,
bytes[] memory datas,
uint256[] memory values,
bool sponsored
) external payable {
require(msg.sender == authorizedEOA || sponsored, "Not authorized");
if (sponsored) {
require(msg.value >= estimateGas(targets, datas), "Insufficient gas funds");
}
for (uint i = 0; i < targets.length; i++) {
assembly {
let success := authcall(
gas(),
mload(add(targets, add(32, mul(i, 32)))),
mload(add(values, add(32, mul(i, 32)))),
add(mload(add(datas, add(32, mul(i, 32)))), 32),
mload(mload(add(datas, add(32, mul(i, 32))))),
0,
0
)
if iszero(success) { revert(0, 0) }
}
}
}
// Estimate gas for sponsored transactions
function estimateGas(address[] memory targets, bytes[] memory datas) internal view returns (uint256) {
uint256 totalGas = 21000; // Base transaction gas
for (uint i = 0; i < targets.length; i++) {
totalGas += 10000; // Approximate per call
}
return totalGas;
}
}💡** 実装のヒント**:EIP-3074のinvokerは、署名のリプレイを防ぐために監査が必要でした。EIP-7702は永続的なinvokerを避けることで、リスクを低減しています。
EIP-3074 対 EIP-7702:7702が優れている理由
EIP-3074は大胆な実験でしたが、EIP-7702とERC-4337がこれからの未来です。簡単に比較してみましょう。
EIP-3074 対 ERC-4337
- EIP-3074: EVMに
AUTHとAUTHCALLを追加し、EOAと連携しましたがinvokerを必要としました。 - ERC-4337: プロトコルの変更はなく、スマートコントラクトウォレットのために独立したmempoolとbundlerを使用します。
- 要点: 3074はEOAにとってよりシンプルでしたが、4337の柔軟性は完全な抽象化に理想的です。
EIP-3074 対 EIP-7702
- EIP-3074:永続的なinvokerがセキュリティリスクをもたらし、将来的な互換性にも欠けていました。
- EIP-7702:トランザクション単位でのスマートコントラクト機能を可能にし、4337と整合しています。
- 要点: 7702は3074のアイデアを洗練させ、EthereumのAAロードマップにより緊密に沿った、より安全でスケーラブルな道筋を提供します。
EIP-3074が導入したアイデアを7702が完成させたことで、完全なアカウント抽象化に向けたEthereumロードマップに沿ったエコシステムが実現しています。
- ガスの肩代わり:アプリがユーザーの代わりにガスを支払い、オンボーディングの障壁を下げます。
- バッチトランザクション:ユーザーは複数のアクション(トークンスワップとステーキングなど)を1つのトランザクションにまとめることができます。
- リカバリーの仕組み:ユーザーは信頼できるdelegateを通じて、失われたEOAを復旧できます。
Smart walletsの開発を始める
EIP-3074が道を切り開いたからこそ、EIP-7702が走り出せました。3074がEOA委譲に向けた画期的なアイデアを導入した一方、7702はそれをより安全でスケーラブルなソリューションへと洗練させ、ERC-4337と並んでEthereumのアカウント抽象化の到達点に近づけています。EIP-7702はEthereumのPectraアップグレードに含まれており、2025年4月時点でテストネットが稼働しています。メインネットでの有効化は2025年5月7日時点で実施済みですが、クライアントの対応(Geth、Nethermindなど)次第となっています。一方、ERC-4337はすでに稼働しており、スマートコントラクトウォレットに対して完全なアカウント抽象化を提供しています。
dAppのUXを最適化するにせよ、シームレスなユーザー体験を作り込むにせよ、今こそ7702と4337に取り組む時です。ドキュメントを見る、そして開発を始めましょう。
ご質問があれば、いつでもお気軽にお問い合わせください。統合戦略、技術的な実装に関する質問、トレードオフについて話し合い、あなたのアプリに最適なソリューションを見つけるお手伝いをします。良い開発を!
よくある質問
EIP-3074とは何ですか?
EIP-3074は、2つのEVMオペコード(AUTHとAUTHCALL)を導入し、EOAがinvokerと呼ばれるスマートコントラクトに制御を委譲できるようにする提案でした。これにより、ユーザーが新しいウォレットに移行することなく、ガスの肩代わりやバッチトランザクションといった機能が可能になりました。
EIP-7702はEIP-3074をどのように改善していますか?
EIP-7702は、永続的なinvokerではなくトランザクション単位でのスマートコントラクト機能を可能にすることで、EIP-3074の概念を洗練させています。これにより、3074の永続的な委譲モデルに伴うセキュリティリスクに対処した、より安全でスケーラブルな道筋を提供します。
EIP-7702とERC-4337の違いは何ですか?
EIP-7702は、EOAがトランザクション中に一時的にスマートコントラクトコードへ制御を委譲できるようにするものです。一方、ERC-4337は、プロトコルの変更を必要とせず、オフチェーンのmempoolとbundlerを用いてスマートコントラクトウォレットに完全なアカウント抽象化を提供します。
EIP-3074とERC-4337は併用できますか?
はい、両者は補完関係にあります。EIP-3074は、EOAが実行のためにERC-4337のスマートアカウントと連携することを可能にし、スマートコントラクトウォレットへの完全な移行を必要とせずに、ガスの肩代わりやユーザー体験の向上といった利点をもたらすことができます。
EIP-3074にはどのようなセキュリティ上の懸念がありますか?
EIP-3074の永続的なinvokerは、EOAに対して大きな制御権を与えることでセキュリティリスクをもたらしました。署名のリプレイや、委譲された権限の悪用といった潜在的な脆弱性があり、慎重な監査が必要でした。
なぜEIP-3074ではなくEIP-7702が選ばれたのですか?
EIP-7702が選ばれた理由は、永続的なinvokerに関するEIP-3074のセキュリティ上の懸念に対処していること、ERC-4337とのより良い将来的な互換性を提供していること、そしてEthereumのアカウント抽象化ロードマップにより密接に沿っていることです。
これらの提案は開発者にどのような機能を可能にしますか?
これらの提案により、ガスの肩代わり(アプリがユーザーの代わりにガスを支払う)、バッチトランザクション(複数のアクションを1つのトランザクションにまとめる)、そして信頼できるdelegateを通じた失われたEOAのリカバリーの仕組みが可能になります。
EIP-7702はEthereumのメインネットで稼働していますか?
はい、EIP-7702はEthereumのPectraアップグレードの一部として、2025年5月7日にメインネットで有効化されました。ただし、GethやNethermindといった実装全体での完全なクライアント対応は現在進行中です。
関連する概要
ウォレット2026年9月2日
エージェントウォレット: AIエージェントのためのセッションと権限モデル
AIエージェントが秘密鍵を保持せずにスコープ化された取り消し可能なウォレットアクセスを得る仕組み: セッション、委任署名、即時失効。
ウォレット2026年7月29日
Cursorに秘密鍵を貼り付けるのをやめる:コーディングエージェントにウォレットを持たせる方法
秘密鍵を渡さずに、コーディングエージェントにウォレットを持たせる方法。Alchemy CLIのエージェントウォレットがスコープ付きセッションを使い、.envに秘密鍵を置かずにエージェントが取引できる仕組みを解説します。
ウォレット2026年6月24日
暗号資産Bundlerとは?
暗号資産のBundlerは、バッチ処理、MEV、ロールアップ、トークンローンチ、アカウントアブストラクションにわたって、複数のトランザクションや操作を1つのオンチェーン送信にまとめます。

ブロックチェーンで魔法を生み出す
Alchemyは、最も強力なweb3開発者向けプロダクトとツールを、豊富なリソース、コミュニティ、そして卓越したサポートと組み合わせて提供します。