什么是智能钱包？智能账户、账户抽象与链上工作流

智能钱包的定义与范围

智能钱包是一种链上地址由智能合约控制的加密货币账户。决定某项提议操作是否获得授权的，是合约，而非裸私钥。该合约可以接受来自 Passkey、一个或多个密钥、守护者集合，或作者定义的任何逻辑的签名。面向用户的钱包应用是准备请求的客户端；权威存在于已部署的合约中。

这与传统的外部拥有账户（EOA）不同，例如 MetaMask 或硬件钱包地址。EOA 由恰好一个私钥控制，每笔交易都必须由该密钥签名。智能钱包仍然可以是自托管的，但托管权以合约逻辑和签名者配置的形式表达，而非单一秘密。

该术语也用于具有 RFID 屏蔽或追踪器的物理钱包。那是不同的产品类别，不在本文讨论范围内。本指南涵盖加密货币含义：智能合约账户（通常称为智能账户），以及使其可用的账户抽象标准。

• EOA：一个密钥、一种签名方案、一个签名者。
• 智能钱包：验证用户操作并可执行策略的合约。
• 智能账户：持有资产并执行调用的链上合约实例。

假设与前提条件

以下流程假设您拥有一个兼容 EVM 的 RPC 端点、一个已部署的智能账户地址，以及您正在测试的账户抽象版本对应的 EntryPoint 合约地址。读取状态不需要有资金的账户，但提交用户操作需要已注资的账户或带有代付的 Bundler。

请将秘密信息排除在源文件之外。使用 RPC_URL 和 PRIVATE_KEY 等环境变量，切勿提交它们。对于生产工作负载，请使用托管端点而非公共端点；OnFinality API 服务和 RPC 定价页面描述了端点选项，网络目录列出了支持的链。

export RPC_URL="https://your-endpoint.example"
export SMART_ACCOUNT="0xYourSmartAccountAddress"
export ENTRYPOINT="0xEntryPointAddress"
export PRIVATE_KEY="0x..."

智能钱包如何执行用户操作

在 ERC-4337 下，用户不直接发送普通交易。相反，钱包客户端构建一个 UserOperation：一个包含发送者（智能账户）、nonce、调用数据、Gas 限制、费用参数和签名的结构体。Bundler 收集这些操作，进行模拟，并将它们打包成一笔交易提交给单例 EntryPoint 合约。

EntryPoint 调用智能账户的验证函数。该函数决定签名是否可接受。如果验证通过，EntryPoint 执行账户的调用数据。由于验证是合约代码，账户可以接受 WebAuthn Passkey 断言、多签批准、带作用域的会话密钥或社交恢复证明。

Paymaster 是可选的合约，可以代付 Gas 或接受 ERC-20 代币支付。这就是为什么智能钱包对最终用户来说可以显得免 Gas：由 Paymaster、应用或赞助方承担原生代币费用，用户无需持有 ETH 或其他 Gas 代币。

• Sender：智能账户地址。
• Nonce：由 EntryPoint 管理以对操作排序。
• CallData：账户应执行的操作。
• Paymaster 字段：由谁支付，以何种资产支付。
• Signature：由账户的验证逻辑解释。

通过 RPC 读取智能账户状态

在信任任何钱包 UI 之前，请在链上验证账户。以下 curl 调用使用标准 EVM 端点上可用的 JSON-RPC 方法。将 RPC_URL 替换为您的端点。第一个调用确认地址处存在代码；智能钱包必须具有字节码。第二个调用读取账户余额。

curl -s "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["'"$SMART_ACCOUNT"'","latest"]}'

curl -s "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getBalance","params":["'"$SMART_ACCOUNT"'","latest"]}'

使用 JavaScript 验证用户操作

以下脚本使用 ethers 检查 EntryPoint 和智能账户。它检查 EntryPoint 是否有代码，从 EntryPoint 读取账户的 nonce，并打印结果。这是一个诊断工具，而非完整的 Bundler 客户端；它在您提交任何内容之前确认连接是否正确。

使用 npm install ethers 安装依赖，然后使用 node 运行脚本。如果 nonce 调用回滚，账户可能未在该 EntryPoint 注册，或者您查询了错误的 EntryPoint 版本。

import { JsonRpcProvider, Contract, formatEther } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);
const account = process.env.SMART_ACCOUNT;
const entryPoint = process.env.ENTRYPOINT;

const code = await provider.getCode(account);
console.log("account has code:", code !== "0x");

const epCode = await provider.getCode(entryPoint);
console.log("entrypoint has code:", epCode !== "0x");

const balance = await provider.getBalance(account);
console.log("native balance:", formatEther(balance));

const ep = new Contract(entryPoint, [
  "function getNonce(address sender, uint192 key) view returns (uint256)"
], provider);

try {
  const nonce = await ep.getNonce(account, 0);
  console.log("entrypoint nonce:", nonce.toString());
} catch (err) {
  console.error("nonce read failed:", err.shortMessage || err.message);
}

预期验证结果

配置正确的智能账户会从 eth_getCode 返回非空字节码字符串、一个数值余额，以及来自 EntryPoint 的 nonce。如果账户从未发送过操作，nonce 通常为零。如果 EntryPoint 地址错误，nonce 调用会回滚或返回空数据。

将您的观察结果记录在表格中，以便比较不同环境。下表是模板；请用您自己运行的值填充，而非假设数字。

• | 检查项 | 方法 | 预期 | 观察值 |
• | 账户代码 | eth_getCode | 非空 | |
• | EntryPoint 代码 | eth_getCode | 非空 | |
• | 原生余额 | eth_getBalance | 数值 | |
• | Nonce | getNonce | uint256 | |

排查常见的智能钱包故障

大多数故障分为四类：网络错误、EntryPoint 版本错误、签名验证失败，以及 Gas 或 Paymaster 拒绝。按此顺序隔离它们。首先确认 RPC 端点的链 ID 与账户部署所在的链匹配。在一个链上部署的智能账户在另一个链上没有代码，除非它也在那里部署过。

其次，确认 EntryPoint 地址与账户的实现匹配。ERC-4337 v0.6 和 v0.7 使用不同的 EntryPoint 地址和不同的结构体布局。混用它们会产生看起来像签名错误的验证回滚。

第三，检查签名格式。Passkey 账户期望 WebAuthn 断言，而非 ECDSA 签名。多签账户期望配置的阈值。第四，检查 Paymaster 策略：代付可能受允许列表、时间窗口或每用户配额限制。

• 链不匹配：将 eth_chainId 与部署链进行比较。
• EntryPoint 不匹配：对照账户文档验证地址。
• 签名不匹配：确认签名者类型和编码。
• Paymaster 拒绝：阅读 Bundler 错误和 Paymaster 策略。

权衡：智能钱包与 EOA 及硬件钱包

智能钱包改善了入门和恢复体验，但增加了活动部件。用户操作依赖于 Bundler、EntryPoint，通常还有 Paymaster。每一个都是可用性和信任方面的考量。合约账户的部署和验证成本也比单一 ECDSA 签名更高。

硬件钱包在冷存储方面仍然强大，因为密钥永远不会离开设备。智能钱包可以通过让硬件签名者成为多个签名者之一来补充它，但这并不会自动使设置更安全。安全性取决于验证逻辑、签名者集合和恢复策略。

对于团队来说，实际问题是运营层面的：谁运行 Bundler、谁代付 Gas、升级如何处理？如果账户可升级，升级权限是一个关键的信任假设。在持有重要价值之前，请记录它。

为智能钱包测试选择基础设施

智能钱包开发比 EOA 开发产生更多 RPC 流量，因为每个用户操作都涉及模拟、nonce 读取和收据轮询。如果您需要历史状态，请使用具有一致延迟和归档访问的端点。OnFinality API 服务提供托管 RPC 访问，专用节点可供需要隔离容量的团队使用。

对于特定链的端点选择，RPC Assistant 提供了具体建议。从多链 RPC 端点指南开始，然后缩小到您正在测试的链。如果您在比较提供商，请运行自己的延迟和错误率测量，而非依赖营销宣传。

• 开发和 CI 使用托管端点。
• 需要可预测吞吐量时使用专用节点。
• 在承诺之前，按方法测量成功率和 p95 延迟。

使用智能账户构建的后续步骤

诊断通过后，转向 Bundler 客户端，如 permissionless.js 或 viem 的账户抽象工具。构建一个用户操作，使用 eth_call 或 Bundler 的模拟端点进行模拟，然后提交。将诊断脚本保留在仓库中，作为新环境的冒烟测试。

如果您在 Gnosis Chain 上测试，请查看 Gnosis RPC 指南；对于 L2 部署，请查看 Arbitrum RPC 端点指南。如需更广泛的基础设施视角，请阅读区块链节点托管指南。当您准备选择端点时，RPC Assistant 的 Web3 项目最佳 RPC 提供商页面是一个实用的起点。

• 将诊断脚本添加到 CI。
• 提交前先模拟。
• 监控 Bundler 和 Paymaster 错误率。
• 记录升级和恢复权限。