帳戶抽象最新進展：EIP-7702 與 ERC-4337 錢包互通性標準完整指南
帳戶抽象（Account Abstraction）是以太坊改進用戶體驗和擴展生態系統的關鍵技術方向。經過多年發展，帳戶抽象領域形成了以 ERC-4337 為代表的應用層標準和以 EIP-7702 為代表的共識層升級兩條主要路徑。截至 2026 年第一季度，這兩種方案都已進入成熟部署階段，錢包互通性成為業界關注的焦點。本文深入分析 EIP-7702 與 ERC-4337 的最新技術進展、兩種方案的互操作性機制、以及錢包生態系統的標準化趨勢。
帳戶抽象最新進展：EIP-7702 與 ERC-4337 錢包互通性標準完整指南
概述
帳戶抽象（Account Abstraction）是以太坊改進用戶體驗和擴展生態系統的關鍵技術方向。經過多年發展，帳戶抽象領域形成了以 ERC-4337 為代表的應用層標準和以 EIP-7702 為代表的共識層升級兩條主要路徑。截至 2026 年第一季度，這兩種方案都已進入成熟部署階段，錢包互通性成為業界關注的焦點。
本文深入分析 EIP-7702 與 ERC-4337 的最新技術進展、兩種方案的互操作性機制、以及錢包生態系統的標準化趨勢。我們將探討錢包開發者如何構建兼容多種標準的應用，以及未來帳戶抽象的發展方向。
一、帳戶抽象技術回顧
1.1 什麼是帳戶抽象
傳統以太坊帳戶分為兩種類型：外部擁有帳戶（EOA）和智慧合約帳戶。EOA 由私鑰控制，可以發起交易；智慧合約帳戶無法主動發起交易，只能響應調用。帳戶抽象的目標是消除這兩種帳戶類型的界限，讓任何帳戶都能夠：
傳統帳戶 vs 抽象帳戶：
傳統 EOA：
├── 由私鑰控制
├── 交易由用戶發起
├── Gas 必須由帳戶餘額支付
├── 驗證邏輯固定（ECDSA）
└── 沒有自定義邏輯
智慧合約帳戶（傳統）：
├── 需要 EOA 發起交易
├── 可自定義驗證邏輯
├── 可實現多重簽名
└── Gas 仍需外部支付
帳戶抽象願景：
├── 任何帳戶可發起交易
├── 可自定義驗證邏輯
├── 可由第三方代付 Gas
├── 支持社交恢復
└── 更好的用戶體驗1.2 帳戶抽象的發展歷程
帳戶抽象發展時間線：
2015-2017：概念階段
├── EIP-86：帳戶抽象提案（早期設想）
└── EIP-101：貨幣和錢包抽象
2018-2020：共識層嘗試
├── EIP-2938：帳戶抽象（共識層升級）
└── 討論：是否修改共識層
2021-2023：應用層突破
├── EIP-4337：帳戶抽象標準發布（2022）
├── ERC-4337 錢包生態爆發
└── EntryPoint 合約部署
2024-2025：共識層回歸
├── EIP-7702 提案提出（2024）
├── EIP-7702 測試網部署（2025）
└── 兩條路徑並行發展
2026：互操作性時代
├── 錢包標準化
├── 跨標準兼容性
└── 機構採用加速二、ERC-4337 當前狀態
2.1 ERC-4337 架構回顧
ERC-4337 是應用層的帳戶抽象標準，通過引入「用戶操作」（UserOperation）概念，在不改變共識層的情況下實現帳戶抽象：
ERC-4337 架構：
┌─────────────────────────────────────────────────────────────────────┐
│ ERC-4337 流程 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────┐ ┌────────┐ │
│ │ User │───▶│ Bundler │───▶│ EntryPoint│───▶│ Smart │ │
│ │ (錢包) │ │ │ │ Contract│ │ Account│ │
│ └──────────┘ └──────────┘ └───────────┘ └────────┘ │
│ │ │ │ │ │
│ │ ┌────┴────┐ │ │ │
│ │ │ Builder │ │ │ │
│ │ │ Network │ │ │ │
│ │ └──────────┘ │ │ │
│ │ │ │ │
│ ┌────┴────┐ ┌─────┴─────┐ │ │
│ │Paymaster│ │ Simulator│ │ │
│ │Contract │ └───────────┘ │ │
│ └─────────┘ │ │
└───────────────────────────────────────────────────────────────┘
核心元件：
├── UserOperation：用戶操作對象
├── EntryPoint：處理操作的中心合約
├── Bundler：收集並提交操作的節點
├── Smart Account：用戶的智慧合約帳戶
└── Paymaster：可選的 Gas 代付服務2.2 ERC-4337 最新進展（2025-2026）
ERC-4337 生態系統現況（2026 Q1）：
錢包實現：
├──argent：#1 實現，超過 200萬用戶
├── gnosis safe：機構級多簽錢包
├── Coinbase Wallet：交易所錢包整合
├── Sequence：遊戲生態主力
├── Biconomy：開發者友好SDK
├── Stackup：新手友好錢包
└── 50+ 其他錢包實現
關鍵指標：
├── 每日 UserOperation：500,000+
├── 活躍帳戶：2M+
├── 支持網路：15+（主網、Polygon、Arbitrum、Optimism等）
└── 總 Gas 消耗：10,000+ ETH/月2.3 ERC-4337 核心合約更新
// ERC-4337 核心介面（2026 版本）
interface IEntryPoint {
struct UserOperation {
address sender;
uint256 nonce;
bytes initCode;
bytes callData;
uint256 callGasLimit;
uint256 verificationGasLimit;
uint256 preVerificationGas;
uint256 maxFeePerGas;
uint256 maxPriorityFeePerGas;
bytes paymasterAndData;
bytes signature;
}
// 模擬驗證
function simulateValidation(UserOperation calldata userOp)
external returns (uint256 validationData);
// 執行操作
function handleOps(
UserOperation[] calldata ops,
address payable beneficiary
) external;
// 批量模擬（新增）
function simulateHandleOps(
UserOperation[] calldata ops,
address payable beneficiary
) external returns (uint256[] memory);
}三、EIP-7702 技術詳解
3.1 EIP-7702 設計理念
EIP-7702 是共識層的帳戶抽象升級提案，允許 EOA 在交易執行期間臨時獲得智慧合約代碼：
EIP-7702 核心概念：
┌─────────────────────────────────────────────────────────────────────┐
│ EIP-7702 交易流程 │
│ │
│ ┌──────────┐ │
│ │ EOA 用戶 │ │
│ └────┬─────┘ │
│ │ 發起交易（包含合約代碼） │
│ ▼ │
│ ┌──────────┐ │
│ │ EVM 執行 │ │
│ │ │
│ │ 臨時設置合約代碼 │
│ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ EOA 臨時變身智慧合約 │ │
│ │ • 可自定義驗證邏輯 │ │
│ │ • 可使用 ERC-20 支付 Gas │ │
│ │ • 可實現社交恢復 │ │
│ └──────────────────────────────────────────┘ │
│ │ │
│ │ 交易結束 │
│ ▼ │
│ ┌──────────┐ │
│ │ EOA 恢復 │（清除臨時代碼） │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘3.2 EIP-7702 技術實現
// EIP-7702 核心實現概念
// 交易類型
// EIP-7702 引入新的交易類型（type = 4）
struct Transaction {
// ... 標準字段 ...
address to; // 目標地址
bytes data; // 調用數據
uint64 chainId; // 鏈 ID
uint256 accessList; // 訪問列表
// EIP-7702 新字段
uint256 authorizationList; // 授權列表
}
// 授權列表
struct Authorization {
address contractAddress; // 目標合約地址
uint256 nonce; // 防重放
uint256 deadline; // 有效期
bytes32 r; // 簽名 R
bytes32 s; // 簽名 S
uint8 v; // 簽名 V
}
// EVM 處理邏輯
function processEIP7702Transaction(tx) {
// 1. 驗證授權
for (auth in tx.authorizationList) {
// 驗證 EOA 簽名
verifyEOASignature(auth);
// 2. 設置臨時代碼
setCode(auth.contractAddress, auth.code);
// 3. 記錄授權以便清除
recordAuthorization(auth);
}
// 4. 執行交易
execute(tx);
// 5. 清除臨時代碼（交易結束）
for (auth in tx.authorizationList) {
clearCode(auth.contractAddress);
}
}3.3 EIP-7702 與 ERC-4337 的差異
EIP-7702 vs ERC-4337 比較：
┌────────────────┬────────────────────┬────────────────────────────┐
│ 特性 │ EIP-7702 │ ERC-4337 │
├────────────────┼────────────────────┼────────────────────────────┤
│ 實現層 │ 共識層（EVM） │ 應用層 │
├────────────────┼────────────────────┼────────────────────────────┤
│ 修改範圍 │ 需要硬分叉 │ 無需修改共識層 │
├────────────────┼────────────────────┼────────────────────────────┤
│ Gas 效率 │ 較高（原生執行） │ 較低（額外驗證） │
├────────────────┼────────────────────┼────────────────────────────┤
│ 相容性 │ 僅支持 EVM 兼容鏈 │ 可跨多鏈部署 │
├────────────────┼────────────────────┼────────────────────────────┤
│ 錢包部署 │ 交易時臨時設定 │ 需預先部署 │
├────────────────┼────────────────────┼────────────────────────────┤
│ 批量交易 │ 需要錢包支持 │ 原生支持 │
├────────────────┼────────────────────┼────────────────────────────┤
│ Paymaster │ 需要錢包實現 │ 標準化支持 │
├────────────────┼────────────────────┼────────────────────────────┤
│ 開發成熟度 │ 早期（測試網） │ 成熟（生產環境） │
├────────────────┼────────────────────┼────────────────────────────┤
│ 錢包遷移 │ 需要錢包升級 │ 需要重新部署 │
└────────────────┴────────────────────┴────────────────────────────┘四、錢包互通性標準
4.1 為什麼需要互通性
錢包互通性是指不同錢包實現之間能夠互相操作、資產可轉移、體驗可攜帶的能力。隨著帳戶抽象生態的發展，互通性變得越來越重要：
互通性需求場景：
用戶痛點：
├── 資產鎖定在特定錢包
├── 私鑰導入導出麻煩
├── 合約帳戶遷移困難
├── DApp 支援有限
└── 跨生態使用不便
生態痛點：
├── 錢包開發重複造輪子
├── DApp 適配成本高
├── 用戶教育困難
├── 安全性參差不齊
└── 創新受限4.2 標準化組織與努力
錢包標準化組織：
1. 以太坊基金會
├── ERC-4337：帳戶抽象標準
├── EIP-7702：共識層升級
└── 帳戶抽象工作組
2. ERC/Standards
├── ERC-4337：Account Abstraction
├── ERC-1271：合約簽名驗證
├── ERC-6492：合約部署前簽名
└── ERC-6551：Token Bound Accounts
3. 業界聯盟
├── WalletConnect：錢包連接標準
├── WalletLink：錢包鏈接標準
└── Safe{Core}：開源錢包框架4.3 錢包互通性框架
// 錢包互通性介面
interface WalletInteroperability {
// 1. 帳戶抽象介面
interface AccountAbstraction {
// 發送用戶操作
sendUserOperation(userOp: UserOperation): Promise<string>;
// 估算 Gas
estimateGas(userOp: UserOperation): Promise<bigint>;
// 獲取帳戶 nonce
getNonce(): Promise<bigint>;
}
// 2. 錢包標準介面
interface StandardWallet {
// 帳戶地址
getAddress(): Promise<string>;
// 簽名驗證
isValidSignature(message: string, signature: string): Promise<boolean>;
// 執行交易
sendTransaction(tx: Transaction): Promise<string>;
}
// 3. 資產標準
interface AssetStandard {
// 獲取代幣餘額
getBalance(token: string): Promise<bigint>;
// 轉移代幣
transfer(token: string, to: string, amount: bigint): Promise<string>;
// 批准代幣
approve(token: string, spender: string, amount: bigint): Promise<string>;
}
}4.4 跨標準錢包實現
// 支持 ERC-4337 和 EIP-7702 的錢包合約
pragma solidity ^0.8.19;
contract UniversalAccount {
// ERC-4337 接口
mapping(address => bool) public owners;
mapping(uint256 => bool) public usedNonces;
// 存儲錢包部署代碼
bytes public walletCode;
// EIP-7702 授權
mapping(address => bool) public authorizedContracts;
// 初始化
function initialize(bytes memory _initCode) external {
require(msg.sender == factory, "Not factory");
// 執行初始化代碼
(bool success, ) = address(this).delegatecall(_initCode);
require(success, "Init failed");
}
// ERC-4337 驗證
function validateUserOp(
UserOperation calldata userOp,
uint256 missingAccountFunds
) external returns (uint256) {
// 驗證簽名
require(
verifySignature(userOp.sender, userOp.signature),
"Invalid signature"
);
// 驗證 nonce
require(!usedNonces[userOp.nonce], "Nonce used");
usedNonces[userOp.nonce] = true;
// 支付缺失資金
if (missingAccountFunds > 0) {
payable(msg.sender).call{value: missingAccountFunds}("");
}
return 0; // 驗證成功
}
// EIP-7702 處理
function processAuthorization(
Authorization calldata auth
) internal {
// 驗證 EOA 簽名
require(
verifyEOASignature(auth),
"Invalid authorization"
);
// 授權合約
authorizedContracts[auth.contractAddress] = true;
}
// 統一執行入口
function execute(bytes calldata data) external {
require(owners[msg.sender], "Not owner");
(bool success, ) = address(this).delegatecall(data);
require(success, "Execution failed");
}
// 簽名驗證（支援多種標準）
function verifySignature(
address signer,
bytes calldata signature
) internal view returns (bool) {
// ERC-1271 標準
if (signature.length == 65) {
return ecrecoverVerify(signature);
}
// ERC-6492（部署前簽名）
if (signature.length > 65) {
return contractSignatureVerify(signature);
}
return false;
}
// 社交恢復
function addOwner(address newOwner) external {
require(owners[msg.sender], "Not owner");
owners[newOwner] = true;
}
function removeOwner(address oldOwner) external {
require(owners[msg.sender], "Not owner");
owners[oldOwner] = false;
}
}五、最佳實踐與實施指南
5.1 構建兼容多標準的錢包
// 多標準錢包 SDK
class UniversalWalletSDK {
private provider: Provider;
private entryPoint: string;
constructor(config: WalletConfig) {
this.provider = config.provider;
this.entryPoint = config.entryPoint;
}
// 檢測錢包類型並選擇執行路徑
async detectWalletType(): Promise<'EOA' | 'ERC4337' | 'EIP7702'> {
const code = await this.provider.getCode(this.address);
if (code === '0x') {
return 'EOA';
} else if (this.hasERC4337Interface(code)) {
return 'ERC4337';
} else if (await this.supportsEIP7702()) {
return 'EIP7702';
}
return 'EOA';
}
// 發送交易（自動選擇最佳路徑）
async sendTransaction(
transaction: Transaction
): Promise<string> {
const walletType = await this.detectWalletType();
switch (walletType) {
case 'EOA':
return this.sendEOATransaction(transaction);
case 'ERC4337':
return this.sendERC4337Transaction(transaction);
case 'EIP7702':
return this.sendEIP7702Transaction(transaction);
default:
throw new Error('Unsupported wallet type');
}
}
// ERC-4337 路徑
private async sendERC4337Transaction(
transaction: Transaction
): Promise<string> {
const userOp = await this.buildUserOperation(transaction);
// 簽名
userOp.signature = await this.signUserOperation(userOp);
// 提交到 EntryPoint
const entryPoint = new Contract(
this.entryPoint,
ENTRYPOINT_ABI,
this.provider
);
return entryPoint.handleOps([userOp], this.beneficiary);
}
// EIP-7702 路徑
private async sendEIP7702Transaction(
transaction: Transaction
): Promise<string> {
const auth = await this.buildAuthorization();
// 構建 EIP-7702 交易
const tx = {
to: transaction.to,
data: transaction.data,
authorizationList: [auth],
// ... 其他字段
};
return this.provider.sendTransaction(tx);
}
// 遷移錢包
async migrateWallet(
targetStandard: 'ERC4337' | 'EIP7702'
): Promise<string> {
if (targetStandard === 'ERC4337') {
return this.deployERC4337Wallet();
} else {
return this.setupEIP7702();
}
}
}5.2 DApp 兼容性指南
// DApp 錢包適配器
class DAppWalletAdapter {
// 檢測錢包能力
static async detectCapabilities(
provider: Provider
): Promise<WalletCapabilities> {
const capabilities = {
eip4337: false,
eip7702: false,
erc1271: false,
metaTransactions: false
};
try {
// 檢測 ERC-4337
const code = await provider.getCode(
await provider.getSigner().getAddress()
);
capabilities.eip4337 = code.length > 2;
// 檢測 ERC-1271
const erc1271Result = await provider.call({
to: await provider.getSigner().getAddress(),
data: '0x1626ba7e' // isValidSignature selector
});
capabilities.erc1271 = erc1271Result !== '0x';
// 檢測 EIP-7702 支持
capabilities.eip7702 = await this.checkEIP7702Support(provider);
} catch (error) {
console.warn('Capability detection failed:', error);
}
return capabilities;
}
// 統一交易發送
static async sendTransaction(
provider: Provider,
transaction: Transaction,
options?: TransactionOptions
): Promise<string> {
const signer = provider.getSigner();
try {
// 首先嘗試使用錢包的原生方法
const txRequest = {
to: transaction.to,
value: transaction.value,
data: transaction.data,
...options
};
// EIP-1193 標準請求
return await signer.sendTransaction(txRequest);
} catch (error) {
// 降級處理
return this.fallbackSendTransaction(provider, transaction);
}
}
}六、未來發展趨勢
6.1 技術發展方向
帳戶抽象技術路線圖（2026-2028）：
2026 年
├── EIP-7702 主網部署
│ └── 取決於以太坊升級時間表
├── 錢包標準化
│ ├── 互通性框架發布
│ └── 測試套件完成
├── 隱私保護
│ ├── 匿名登錄
│ └── 交易隱藏
└── 機構採用
└── 托管錢包支持
2027 年
├── 跨鏈帳戶抽象
│ └── 統一帳戶標準
├── AI 整合
│ ├── 智能交易驗證
│ └── 異常檢測
└── 身份整合
├── 去中心化身份
└── 憑證驗證
2028 年
├── 完全抽象的互聯網帳戶
├── 傳統金融整合
└── 全球化標準6.2 生態系統預測
帳戶抽象生態預測（2026-2028）：
用戶採用：
├── 2026 Q1：5M 抽象帳戶
├── 2027 Q1：20M 抽象帳戶
└── 2028 Q1：100M 抽象帳戶
交易份額：
├── 2026 Q1：5% 的以太坊交易
├── 2027 Q1：15% 的以太坊交易
└── 2028 Q1：35% 的以太坊交易
錢包生態：
├── 主要錢包都將支持雙標準
├── 互通性將成為標準功能
└── 錢包將更加模組化6.3 挑戰與機遇
主要挑戰：
技術挑戰
├── EIP-7702 與現有系統兼容性
├── 跨標準遷移的用戶體驗
├── 安全審計覆蓋範圍
└── 性能優化
生態挑戰
├── 開發者教育
├── DApp 適配成本
├── 用戶遷移意願
└── 標準競爭
機遇：
新興應用
├── 社交遊戲（帳戶綁定物品）
├── DeFi 2.0（更復雜的策略）
├── 機構級應用（合規錢包）
└── 物聯網支付
商業模式
├── 錢包即服務（WaaS）
├── Gas 市場
├── 身份服務
└── 風險管理七、結論
EIP-7702 和 ERC-4337 代表了帳戶抽象的兩條不同路徑，它們各有優勢，將在未來的以太坊生態系統中共存。隨著這兩種標準的成熟，錢包互通性成為行業關注的焦點。
對於錢包開發者：
- 建議同時支持 ERC-4337 和 EIP-7702
- 重視錢包遷移和資產可移植性
- 關注標準化組織的最新動態
對於 DApp 開發者：
- 構建兼容多種錢包類型的應用
- 使用標準化的錢包檢測和適配邏輯
- 提供平滑的用戶體驗
對於用戶：
- 了解不同錢包標準的特點
- 選擇支持互通性的錢包
- 關注資產安全和私鑰管理
展望未來，帳戶抽象將繼續演進，帶來更好的用戶體驗和更廣泛的應用場景。隨著標準化的推進和生態系統的成熟，我們有望在 2026-2028 年看到帳戶抽象的大規模採用。
參考資料
- Ethereum Foundation. "EIP-7702: Set EOA account code". eips.ethereum.org (2025)
- Ethereum Foundation. "ERC-4337: Account Abstraction". ercs.ethereum.org (2022, updated 2025)
- OpenZeppelin. "Account Abstraction Guide". docs.openzeppelin.com (2025)
- Vitalik Buterin. "The future of account abstraction". vitalik.ca (2024)
- ethereum.org. "Account abstraction". ethereum.org/en/roadmap/account-abstraction (2026)
- Stackup. "Building with ERC-4337". docs.stackup.sh (2025)
相關文章
- 以太坊錢包安全模型深度比較：EOA、智慧合約錢包與 MPC 錢包的技術架構、風險分析與選擇框架 — 本文深入分析以太坊錢包技術的三大類型：外部擁有帳戶（EOA）、智慧合約錢包（Smart Contract Wallet）與多方計算錢包（MPC Wallet）。我們從技術原理、安全模型、風險維度等面向進行全面比較，涵蓋 ERC-4337 帳戶抽象標準、Shamir 秘密分享方案、閾值簽名等核心技術，並提供針對不同資產規模和使用場景的選擇框架。截至 2026 年第一季度，以太坊生態系統的錢包技術持續演進，理解這些技術差異對於保護數位資產至關重要。
- EIP-7702 實際應用場景完整指南：從理論到生產環境部署 — EIP-7702 是以太坊帳戶抽象演進歷程中的重要里程碑，允許外部擁有帳戶（EOA）在交易執行期間臨時獲得智慧合約的功能。本文深入探討 EIP-7702 的實際應用場景，包括社交恢復錢包、批量交易、自動化執行和多重簽名等，提供完整的開發指南與程式碼範例，並探討從概念驗證到生產環境部署的最佳實踐。
- 帳戶抽象（Account Abstraction）深入解析 — 帳戶抽象（Account Abstraction, AA）是以太坊發展歷程中最重要的技術演進之一。其核心目標是模糊化「外部擁有帳戶（EOA）」與「智慧合約帳戶（Contract Account）」之間的界線，實現更靈活的帳戶管理與交易驗證機制。
- ERC-4337 與 EIP-7702 完整比較：帳戶抽象的兩條路徑深度分析 — ERC-4337 和 EIP-7702 是帳戶抽象領域兩個最重要的標準。雖然兩者的最終目標相似——讓以太坊帳戶更加智能和靈活——但它們採取了截然不同的實現路徑。ERC-4337 作為應用層標準，無需更改以太坊共識層，已被廣泛採用；EIP-7702 作為共識層升級，提供更原生的支持和更高的效率，正在開發中。本文深入比較這兩個標準的技術架構、優劣勢、適用場景。
- 錢包安全深度實務：從私鑰管理到多籤架構的完整技術指南 — 以太坊錢包安全是整個區塊鏈生態系統安全的基石。本文從工程師視角出發，提供完整的以太坊錢包安全技術指南，深入探討私鑰管理的基本原則、熱錢包與冷錢包的技術架構、多籤錢包的設計模式、硬體錢包的安全性分析、帳戶抽象與錢包安全的關係，以及錢包安全的最佳實踐，幫助開發者和機構投資者建立完善的錢包安全體系。
延伸閱讀與來源
- Ethereum.org Developers 官方開發者入口與技術文件
- EIPs 以太坊改進提案
這篇文章對您有幫助嗎？
請告訴我們如何改進：
0 人覺得有帮助
評論
發表評論
注意：由於這是靜態網站，您的評論將儲存在本地瀏覽器中，不會公開顯示。
目前尚無評論，成為第一個發表評論的人吧！