---
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 交互的方式，我们需要先了解 EIP-3074——这项提案为 7702 的形成奠定了关键基础。

如果你是构建[应用](https://www.alchemy.com/dapps/top/defi-dapps)的开发者，你可能已经体会过外部账户\(EOA\)的局限——EOA 是 Ethereum 中由私钥控制的传统钱包。EIP-3074 引入了一种方式，让 EOA 可以将控制权委托给智能合约\(invoker\)，从而实现 gas 代付和批量交易等功能。EIP-7702 在此基础上更进一步，提供了一条更简洁、更安全的账户抽象路径。

对开发者而言，这一概念简化了在应用中添加高级功能的方式，同时让用户继续使用熟悉的 EOA。对用户而言，这意味着更流畅的体验：例如第三方代付 gas，或一键执行多笔 DeFi 交易。

在本指南中，我们将先梳理 3074 的机制以提供背景，再通过代码展示 7702 的改进之处，最后将两者与 ERC-4337 进行比较。让我们深入了解技术细节。

## EIP-3074 旨在解决的问题

EOA 很直接：用私钥对交易签名，然后发送到 Ethereum 网络。但它们也有局限——无法执行代码、无法批量操作、也无法原生恢复丢失的私钥。智能合约钱包\(由 ERC-4337 实现\)提供了更高的灵活性，但要求用户管理新地址，且通常会产生更高的 gas 成本。EIP-3074 提出了一种解决方案：引入两个 EVM 操作码 `AUTH` 和 `AUTHCALL`，让 EOA 可以将控制权委托给 invoker 合约，从而在不迁移钱包的情况下添加类似智能合约的功能。

EIP-3074 是一个概念验证，塑造了 Ethereum 账户抽象的路线图：从 EOA 到 Smart EOA\(EIP-7702\)，最终到完整的 Smart Wallets\(ERC-4337\)。让我们来了解 3074 的机制，看看它是如何为后续铺路的。

<CardWithCta
  text="智能钱包提供流畅的链上体验，助力应用增长。"
  ctaLabel="探索功能"
  ctaHref="#"
  theme="light"
/>

## EIP-3074 的核心组成：7702 的基础

EIP-3074 围绕三个部分展开：`AUTH` 操作码、`AUTHCALL` 操作码，以及 invoker 合约。这些内容值得了解，因为 7702 正是建立在它们的原理之上。

### 1. `auth` 操作码

`AUTH` 操作码\(`hex 0xf6`\)用于验证来自 EOA 的 ECDSA 签名，证明该 EOA 已授权特定 invoker 代表其行动。EOA 会对一条包含 invoker 地址和 commitment\(即待执行操作的哈希\)的消息进行签名。如果签名有效，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，而 gas 则由 invoker 支付。这正是 3074 中实现 gas 代付和批量操作的基础。

以下是在汇编中使用 `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\(\)` 函数分配剩余的 gas，`AUTHCALL` 确保该操作体现的是该 EOA 的身份。

### 3. Invoker 合约

Invoker 是 EOA 委托的智能合约。EIP-3074 中的 invoker 是持久性的，这带来了安全隐患，而这正是 7702 所要解决的问题。以下是一个用于 gas 代付和批量操作的 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：** 不改变协议本身；使用独立的内存池和 bundler 来支持智能合约钱包。
- **要点：** 3074 对 EOA 而言更简单，但 4337 的灵活性使其更适合实现完整的账户抽象。

**EIP-3074 与 EIP-7702**

- EIP-3074：持久性 invoker 带来安全风险，且缺乏向前兼容性。
- EIP-7702：支持按交易粒度的智能合约功能，与 4337 保持一致。
- **要点：** 7702 完善了 3074 的思路，提供了一条更安全、更具可扩展性的路径，也更贴合 Ethereum 的账户抽象路线图。

EIP-3074 提出的理念在 7702 中得到了完善，这推动了一个与 [Ethereum 路线图](https://ethereum.org/en/roadmap/pectra/7702/) 保持一致、面向完整账户抽象的生态系统。

1. **Gas 代付**：应用可以为用户支付 gas，降低使用门槛。
1. **批量交易**：用户可以在一笔交易中组合多个操作\(例如代币兑换和质押\)。
1. **恢复机制**：用户可以通过可信委托方恢复丢失的 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 的用户体验，还是在打造无缝的用户交互流程，现在都是深入了解 7702 和 4337 的好时机。[查阅文档](https://www.alchemy.com/docs/wallets/react/quickstart)并[开始构建](https://dashboard.alchemy.com/services/smart-wallets/overview)吧！

如有任何问题，欢迎随时联系我们。我们很乐意与你探讨集成策略、技术实现问题、各种权衡取舍，并帮助你为应用找到最合适的方案。祝构建顺利！

## 常见问题

### 什么是 EIP-3074？

EIP-3074 是一项提案，引入了两个 EVM 操作码\(`AUTH` 和 `AUTHCALL`\)，允许 EOA 将控制权委托给称为 invoker 的智能合约，从而在无需用户迁移到新钱包的情况下实现 gas 代付和批量交易等功能。

### EIP-7702 相较于 EIP-3074 有哪些改进？

EIP-7702 完善了 EIP-3074 的理念，通过支持按交易粒度的智能合约功能来取代持久性 invoker，提供了一条更安全、更具可扩展性的路径，解决了 3074 持久性委托模型所带来的安全风险。

### EIP-7702 和 ERC-4337 有什么区别？

EIP-7702 让 EOA 能够在交易期间临时将控制权委托给智能合约代码，而 ERC-4337 则通过链下内存池和 bundler，为智能合约钱包提供完整的账户抽象能力，且无需任何协议层面的改动。

### EIP-3074 和 ERC-4337 可以协同工作吗？

可以，两者可以互补：EIP-3074 可以让 EOA 与 ERC-4337 智能账户交互以执行操作，从而在无需完全迁移到智能合约钱包的情况下获得 gas 代付和更好用户体验等优势。

### EIP-3074 存在哪些安全隐患？

EIP-3074 的持久性 invoker 存在安全隐患，因为它赋予 invoker 对 EOA 的重大控制权，可能存在签名重放和委托权限被滥用等漏洞，因此需要谨慎审计。

### 为什么最终选择了 EIP-7702 而非 EIP-3074？

EIP-7702 之所以更受青睐，是因为它解决了 EIP-3074 持久性 invoker 带来的安全隐患，提供了与 ERC-4337 更好的向前兼容性，并且更贴合 Ethereum 的账户抽象路线图。

### 这些提案为开发者提供了哪些功能？

这些提案支持 gas 代付\(应用为用户支付 gas\)、批量交易\(在一笔交易中组合多个操作\)，以及通过可信委托方为丢失的 EOA 提供恢复机制。

### EIP-7702 是否已在 Ethereum 主网上线？

是的，EIP-7702 已作为 Ethereum Pectra 升级的一部分，于 2025 年 5 月 7 日在主网上线，具体效果取决于 Geth、Nethermind 等各实现在客户端层面的完整采用情况。