EIP-3074 vs EIP-7702 vs ERC-4337：完整開發者指南

發布於 2025年5月14日閱讀時間 2 分鐘

Ethereum 的錢包生態系統持續演進，朝向可程式化的未來邁進，EIP-7702 是邁向完整帳戶抽象化(ERC-4337)的關鍵一步。但要理解為何 7702 有望重塑我們透過smart wallets與 Ethereum 互動的方式，我們必須先向 EIP-3074 致意——這項提案為 7702 的成型奠定了關鍵基礎。

如果你是開發 apps 的開發者，你可能已經遇過外部擁有帳戶(Externally Owned Accounts, EOAs)的限制——這是 Ethereum 由私鑰控制的傳統錢包。EIP-3074 提出了一種讓 EOA 將控制權委派給智能合約(invokers)的方式，實現了 gas 贊助與批次交易等功能。EIP-7702 則更進一步，提供更精簡、更安全的帳戶抽象化路徑。

對開發者而言，這個概念簡化了在 apps 中加入進階功能的過程，同時讓使用者維持使用熟悉的 EOA。對使用者而言，這代表更順暢的體驗；例如由第三方支付 gas 費，或一鍵執行多筆 DeFi 交易。

在本指南中，我們會先說明 3074 的運作機制作為背景，展示 7702 帶來的進展並附上程式碼，並將兩者與 ERC-4337 做比較。讓我們開始深入探討技術細節。

EIP-3074 試圖解決的問題

EOA 很直觀：用私鑰簽署交易並傳送到 Ethereum 網路。但它們有其限制。EOA 無法原生執行程式碼、批次操作或復原遺失的金鑰。智能合約錢包(由 ERC-4337 實現)提供了更高的彈性，但需要使用者管理新的地址，且通常會產生更高的 gas 成本。EIP-3074 提出了解方，引入兩個 EVM opcode：AUTH 與 AUTHCALL，讓 EOA 能將控制權委派給 invoker 合約，在不需要遷移錢包的情況下加入類似智能合約的功能。

EIP-3074 是一個概念驗證，形塑了 Ethereum 的帳戶抽象化路線圖：從 EOA 到 Smart EOA (EIP-7702)，最終邁向完整的 Smart Wallets (ERC-4337)。讓我們探索 3074 的運作機制，理解它如何鋪路。

Smart wallets 讓你透過流暢的 onchain UX 拓展你的 app。

探索功能

EIP-3074 的核心組成：7702 的基礎

EIP-3074 圍繞三個部分展開：AUTH opcode、AUTHCALL opcode，以及 invoker 合約。這些值得深入理解，因為 7702 是建立在這些原則之上。

1. `auth` opcode

AUTH opcode (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` opcode

AUTHCALL (hex 0xf7) 讓 invoker 能以該 EOA 的身分執行交易，使用 EOA 的地址作為呼叫者，同時由 invoker 支付 gas。這正是 3074 中 gas 贊助與批次處理得以實現的原因。

以下是在 assembly 中使用 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 vs. EIP-7702：為何 7702 勝出

EIP-3074 是一項大膽的實驗，但 EIP-7702 與 ERC-4337 才是未來。以下是簡短的比較：

EIP-3074 vs. ERC-4337

EIP-3074： 為 EVM 新增了 AUTH 與 AUTHCALL，適用於 EOA，但需要 invoker。
ERC-4337： 無需協議層變更；使用獨立的 mempool 與 bundler 來支援智能合約錢包。
重點： 3074 對 EOA 而言較為簡單，但 4337 的彈性使其更適合完整的抽象化。

EIP-3074 vs. EIP-7702

EIP-3074：持久性 invoker 帶來安全風險，且缺乏向前相容性。
EIP-7702：實現逐筆交易的智能合約功能，與 4337 更為一致。
重點： 7702 精煉了 3074 的想法，提供更安全、更具擴展性的路徑，也更貼近 Ethereum 的 AA 路線圖。

EIP-3074 提出的想法經 7702 精煉，促成了一個與Ethereum roadmap一致、朝向完整帳戶抽象化發展的生態系統。

Gas 贊助：由 apps 代替使用者支付 gas，降低導入門檻。
批次交易：使用者可在單一交易中合併多個動作(例如代幣互換與質押)。
復原機制：使用者可透過信任的委派方復原遺失的 EOA。

開始使用 smart wallets 進行開發

EIP-3074 先行鋪路，EIP-7702 才能加速前進。3074 提出了 EOA 委派的突破性想法，7702 則將這些想法精煉為更安全、可擴展的解決方案，讓我們更接近 Ethereum 的帳戶抽象化終局，並與 ERC-4337 相輔相成。EIP-7702 已納入 Ethereum 的 Pectra 升級中，測試網已於 2025 年 4 月啟用。主網已於 2025 年 5 月 7 日正式啟用，仍待各客戶端(Geth、Nethermind 等)完成採用。同時，ERC-4337 已上線，為智能合約錢包提供完整的帳戶抽象化。

無論你是要優化 dApp 的使用體驗，還是打造流暢的使用者流程，現在正是深入了解 7702 與 4337 的時機。Dive into the docs 並開始建置！

如有任何問題，歡迎隨時與我們聯繫。我們樂於討論整合策略、技術實作問題、各種取捨，並協助你找到最適合你的 app 的解決方案。祝開發順利！

常見問題

什麼是 EIP-3074？

EIP-3074 是一項提案，引入了兩個 EVM opcode（AUTH 與 AUTHCALL），讓 EOA 能將控制權委派給稱為 invoker 的智能合約，在不需要使用者遷移到新錢包的情況下，實現 gas 贊助與批次交易等功能。

EIP-7702 相較於 EIP-3074 有哪些改進？

EIP-7702 精煉了 EIP-3074 的概念，以逐筆交易的智能合約功能取代持久性 invoker，提供更安全、更具擴展性的路徑，解決了 3074 持久性委派模型所帶來的安全風險。

EIP-7702 與 ERC-4337 有什麼差異？

EIP-7702 讓 EOA 能在交易期間暫時將控制權委派給智能合約程式碼，而 ERC-4337 則透過鏈下 mempool 與 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 贊助（由 apps 代替使用者支付 gas）、批次交易（在單一交易中合併多個動作），以及透過信任的委派方復原遺失 EOA 的機制。

EIP-7702 是否已在 Ethereum 主網上線？

是的，EIP-7702 已於 2025 年 5 月 7 日隨 Ethereum 的 Pectra 升級正式上線主網，目前仍待 Geth、Nethermind 等各實作端完成全面採用。

打造區塊鏈魔法

Alchemy 結合最強大的 Web3 開發者產品與工具，並提供資源、社群與卓越的支援。

取得您的 API 金鑰

EIP-3074 vs EIP-7702 vs ERC-4337：完整開發者指南

EIP-3074 試圖解決的問題

EIP-3074 的核心組成：7702 的基礎

1. `auth` opcode

2. `authcall` opcode

3. Invoker 合約

EIP-3074 vs. 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：如何為你的 coding agent 建立錢包

什麼是加密貨幣 Bundler？

打造區塊鏈魔法

EIP-3074 vs EIP-7702 vs ERC-4337：完整開發者指南

EIP-3074 試圖解決的問題

EIP-3074 的核心組成：7702 的基礎

1. auth opcode

2. authcall opcode

3. Invoker 合約

EIP-3074 vs. 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：如何為你的 coding agent 建立錢包

什麼是加密貨幣 Bundler？

打造區塊鏈魔法

1. `auth` opcode

2. `authcall` opcode