---
title: "EIP-3074 vs EIP-7702 vs ERC-4337:開発者向け完全ガイド"
description: "EIP-3074、EIP-7702、ERC-4337を比較:Ethereumのアカウント抽象化のアプローチ、機能、トレードオフ。"
---

# EIP-3074 vs EIP-7702 vs ERC-4337:開発者向け完全ガイド

Ethereumのウォレットエコシステムは進化を続けており、プログラマブルな未来に向けて前進しています。その中で**EIP-7702**は、完全なアカウント抽象化\(**ERC-4337**\)に向けた重要なステップとなっています。ですが、なぜ7702が**smart wallets**を通じたEthereumとの関わり方を変えようとしているのかを理解するには、7702の基盤を築いた提案であるEIP-3074に触れておく必要があります。

[アプリ](https://www.alchemy.com/dapps/top/defi-dapps)を開発しているエンジニアであれば、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の仕組みを見ていくことで、それがどのように道を切り開いたのかを理解しましょう。

<CardWithCta
  text="スマートウォレットは、シームレスなオンチェーンUXでアプリの成長を支援します。"
  ctaLabel="機能を見る"
  ctaHref="#"
  theme="light"
/>

## EIP-3074の中核要素：7702の基盤

EIP-3074は、`AUTH`オペコード、`AUTHCALL`オペコード、そしてinvokerコントラクトという3つの要素を中心としています。これらは7702がその原則の上に構築されているため、理解しておく価値があります。

### 1. `auth`オペコード

`AUTH`オペコード\(`hex 0xf6`\)は、EOAからのECDSA署名を検証し、そのEOAが特定のinvokerに代理としての行動を許可したことを証明します。EOAは、invokerのアドレスとコミットメント\(実行されるアクションのハッシュ\)を含むメッセージに署名します。署名が有効であれば、EVMは認証済みのコンテキストを設定します。

以下は、AUTHの署名検証を模した[Solidity](https://www.alchemy.com/overviews/solidity)のスニペットです。

<CodeSnippet language="solidity" code={`*// 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`の使用例です。

<CodeSnippet
  language="solidity"
  code={`// 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は署名を悪用したり、アクションをリプレイしたりする可能性があります。

<CodeSnippet language="jsx" code={`// 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ロードマップ](https://ethereum.org/en/roadmap/pectra/7702/)に沿ったエコシステムが実現しています。

1. **ガスの肩代わり**：アプリがユーザーの代わりにガスを支払い、オンボーディングの障壁を下げます。
1. **バッチトランザクション**：ユーザーは複数のアクション\(トークンスワップとステーキングなど\)を1つのトランザクションにまとめることができます。
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](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one)、Nethermindなど\)次第となっています。一方、ERC-4337はすでに稼働しており、スマートコントラクトウォレットに対して完全なアカウント抽象化を提供しています。

dAppのUXを最適化するにせよ、シームレスなユーザー体験を作り込むにせよ、今こそ7702と4337に取り組む時です。[ドキュメントを見る](https://www.alchemy.com/docs/wallets/react/quickstart)、そして[開発を始めましょう](https://dashboard.alchemy.com/services/smart-wallets/overview)。

ご質問があれば、いつでもお気軽にお問い合わせください。統合戦略、技術的な実装に関する質問、トレードオフについて話し合い、あなたのアプリに最適なソリューションを見つけるお手伝いをします。良い開発を！

## よくある質問

### 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といった実装全体での完全なクライアント対応は現在進行中です。