---
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 的成型奠定了關鍵基礎。

如果你是開發 [apps](https://www.alchemy.com/dapps/top/defi-dapps) 的開發者，你可能已經遇過外部擁有帳戶\(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 的運作機制，理解它如何鋪路。

<CardWithCta
  text="Smart wallets 讓你透過流暢的 onchain UX 拓展你的 app。"
  ctaLabel="探索功能"
  ctaHref="#"
  theme="light"
/>

## 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](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` opcode

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

以下是在 assembly 中使用 `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 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](https://ethereum.org/en/roadmap/pectra/7702/)一致、朝向完整帳戶抽象化發展的生態系統。

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

## 開始使用 smart wallets 進行開發

EIP-3074 先行鋪路，EIP-7702 才能加速前進。3074 提出了 EOA 委派的突破性想法，7702 則將這些想法精煉為更安全、可擴展的解決方案，讓我們更接近 Ethereum 的帳戶抽象化終局，並與 ERC-4337 相輔相成。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 的時機。[Dive into the docs](https://www.alchemy.com/docs/wallets/react/quickstart) 並[開始建置](https://dashboard.alchemy.com/services/smart-wallets/overview)！

如有任何問題，歡迎隨時與我們聯繫。我們樂於討論整合策略、技術實作問題、各種取捨，並協助你找到最適合你的 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 等各實作端完成全面採用。