EIP-3074 vs EIP-7702 vs ERC-4337：完整开发者指南

发布于 2025年5月14日2 分钟阅读

Ethereum 的钱包生态系统在不断演进，朝着可编程的未来快速推进，EIP-7702 是迈向完整账户抽象(ERC-4337)的关键一步。但要理解为什么 7702 有望重塑我们通过 smart wallets 与 Ethereum 交互的方式，我们需要先了解 EIP-3074——这项提案为 7702 的形成奠定了关键基础。

如果你是构建应用的开发者，你可能已经体会过外部账户(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 的机制，看看它是如何为后续铺路的。

智能钱包提供流畅的链上体验，助力应用增长。

探索功能

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

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

1. `auth` 操作码

AUTH 操作码(hex 0xf6)用于验证来自 EOA 的 ECDSA 签名，证明该 EOA 已授权特定 invoker 代表其行动。EOA 会对一条包含 invoker 地址和 commitment(即待执行操作的哈希)的消息进行签名。如果签名有效，EVM 会设置一个已授权的上下文。

以下是一段模拟 AUTH 签名验证的 Solidity 代码：

solidityCopied
*// 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 的示例：

solidityCopied
// 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 可能被滥用签名或重放操作。

jsxCopied
// 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 路线图保持一致、面向完整账户抽象的生态系统。

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

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

常见问题

什么是 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 等各实现在客户端层面的完整采用情况。

构建区块链应用

Alchemy 将最强大的 Web3 开发者产品和工具与资源、社区及专业支持结合在一起。

获取您的 API 密钥

EIP-3074 vs EIP-7702 vs ERC-4337：完整开发者指南

EIP-3074 旨在解决的问题

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

1. `auth` 操作码

2. `authcall` 操作码

3. Invoker 合约

EIP-3074 与 EIP-7702 对比：为什么 7702 更胜一筹

开始使用 Smart Wallets 进行构建

常见问题

什么是 EIP-3074？

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

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

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

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

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

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

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

相关概览

智能体钱包：AI 智能体的会话与权限模型

别再把私钥粘贴进 Cursor 了：如何给你的编码 agent 配一个钱包

什么是 crypto bundler？

构建区块链应用

EIP-3074 vs EIP-7702 vs ERC-4337：完整开发者指南

EIP-3074 旨在解决的问题

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

1. auth 操作码

2. authcall 操作码

3. Invoker 合约

EIP-3074 与 EIP-7702 对比：为什么 7702 更胜一筹

开始使用 Smart Wallets 进行构建

常见问题

什么是 EIP-3074？

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

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

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

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

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

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

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

相关概览

智能体钱包：AI 智能体的会话与权限模型

别再把私钥粘贴进 Cursor 了：如何给你的编码 agent 配一个钱包

什么是 crypto bundler？

构建区块链应用

1. `auth` 操作码

2. `authcall` 操作码