非托管数字钱包：密钥控制、RPC 依赖与验证工作流

范围与核心定义

非托管数字钱包是指控制某个地址的私钥在用户控制的基础设施上生成和存储，且交易签名在本地产生的钱包。钱包应用可以是浏览器扩展、移动应用、硬件设备或命令行工具。无论哪种形式，其定义性特征是没有任何服务持有能够转移用户资产的密钥。

本文聚焦于运维和集成层面：钱包在本地做什么、将什么委托给远程基础设施，以及如何验证这一边界。本文不推荐特定钱包产品。在需要具体端点或提供商决策时，下文链接的配套 RPC Assistant 资源涵盖了相关选择。

• 密钥与签名：位于用户设备或硬件模块本地。
• 链上状态读取与交易广播：委托给 RPC 端点。
• 恢复：依赖用户持有的助记词或备份，而非客服支持。

假设与前提条件

以下流程假设你有一个能够导出公共地址（绝不导出私钥）的钱包，以及一个可以转移无价值资产的测试网络。JavaScript 示例需要 Node.js 18 或更高版本，RPC 检查需要 curl。请将你为测试生成的每个密钥视为一次性使用。

你还应在公共测试网上拥有一个已注资的测试账户。如果你正在为生产钱包集成选择端点，请在运行检查前查阅 /en/learn/multi-chain-rpc-endpoints-guide 中的多链端点指南，因为速率限制和归档要求因网络而异。

• 一个测试钱包，其助记词已知并离线存储。
• 一个你控制或拥有配额的测试网 RPC_URL。
• Node.js 18+、curl 和终端。
• 任何脚本或 shell 历史中均无生产私钥。

密钥控制与 RPC 信任边界如何相互作用

钱包的本地组件从熵（通常是 BIP-39 助记词）派生密钥对，并计算地址。签名交易是对包含链 ID、nonce、接收方、金额、gas 参数和数据的载荷进行的本地密码学操作。然后，已签名交易被发送到 RPC 节点，由该节点验证并传播到点对点网络。

因此，RPC 提供商能看到你的已签名交易和读取查询，但永远看不到你的私钥。这就是信任边界：恶意或受损的 RPC 端点可以审查、延迟、返回过期状态或错误报告余额，但无法为你的地址伪造签名。这就是为什么钱包安全与 RPC 可靠性是两个独立问题，需要分别验证。

• 本地：熵生成、密钥派生、地址计算、载荷构建、签名。
• 远程：余额和 nonce 读取、gas 估算、eth_call 模拟、交易广播、收据轮询。
• 绝不远程：私钥材料、助记词或签名操作。

用可运行检查验证签名在本地进行

以下 Node.js 脚本从测试助记词派生地址，在本地签名交易载荷，并打印恢复出的地址。如果恢复出的地址与派生地址匹配，则签名在本地进行，且载荷内部一致。此步骤不进行任何网络调用。

仅使用一次性测试助记词运行。脚本使用 ethers v6；通过 npm install ethers 安装。

const { Wallet, Transaction, getAddress } = require('ethers');

async function main() {
  const mnemonic = process.env.TEST_MNEMONIC; // disposable test phrase only
  const wallet = Wallet.fromPhrase(mnemonic);
  console.log('derived address:', wallet.address);

  const tx = Transaction.from({
    to: '0x000000000000000000000000000000000000dEaD',
    value: 1n,
    nonce: 0,
    gasLimit: 21000n,
    maxFeePerGas: 1000000000n,
    maxPriorityFeePerGas: 1000000000n,
    chainId: 11155111,
    type: 2
  });

  const signed = await wallet.signTransaction(tx);
  const parsed = Transaction.from(signed);
  console.log('recovered address:', getAddress(parsed.from));
  console.log('match:', getAddress(parsed.from) === getAddress(wallet.address));
}

main().catch((e) => { console.error(e); process.exit(1); });

预期验证结果及不匹配的含义

正确运行会为派生地址和恢复地址打印相同地址，并显示 match: true。这确认本地签名路径一致。不匹配通常意味着交易字段在签名后被修改、目标网络的链 ID 错误，或签名库版本与生成载荷的版本不同。

此检查不能证明钱包 UI 是诚实的。要测试这一点，请将钱包界面显示的地址与脚本从同一助记词派生的地址进行比较。如果不同，请停止并在为账户注资前进行调查。

• match: true — 本地签名路径一致。
• match: false — 检查链 ID、字段顺序和库版本。
• 地址与钱包 UI 不匹配 — 在解释清楚之前，视为安全事件。

检查 RPC 的广播和状态读取行为

签名验证后，测试远程侧。以下 curl 命令检查链 ID、当前 nonce，并针对你的 RPC_URL 进行模拟调用。将 RPC_URL 替换为你的端点，将 ADDRESS 替换为你的测试地址。这些是只读调用，不消耗 gas。

将输出记录在结果表中，以便比较端点或时间窗口。不要编造数值；记录端点返回的内容并注明时间戳。

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

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getTransactionCount","params":["ADDRESS","pending"]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"eth_call","params":[{"to":"ADDRESS","data":"0x"},"latest"]}'

端点比较的结果表流程

在同一时刻对每个候选端点运行上述三个调用，并填写下表列：端点标签、eth_chainId 结果、待处理 nonce、最新区块号、响应时间（毫秒）以及错误代码（如有）。每个端点重复三次并取中位数。这样无需依赖供应商声明即可获得可复现的比较。

如果端点之间的待处理 nonce 不同，则一个节点在内存池上滞后。这对预签名交易的钱包很重要。对于生产集成，请在 /en/dedicated-node 比较专用节点选项，并在承诺前查阅 /en/pricing/rpc 的配额行为。

排查常见的非托管钱包故障

大多数钱包故障分为三类：密钥丢失、状态不一致和广播拒绝。密钥丢失在设计上不可恢复；状态不一致和广播拒绝是可诊断的。

对于状态不一致，比较两个独立端点返回的 nonce。对于广播拒绝，检查 JSON-RPC 错误代码和消息；replacement underpriced 和 nonce too low 最常见。如果交易卡住，标准补救措施是使用相同 nonce 和更高费用的替换交易，但只有在确认原始交易尚未被打包后才签名。

• 助记词丢失且设备丢失 — 资金不可恢复；不存在支持路径。
• nonce too low — 交易已被打包或替换；重新读取 nonce。
• replacement transaction underpriced — 将费用提高到待处理交易之上。
• 余额过期 — 端点落后；查询第二个端点或区块浏览器。
• 链 ID 不匹配 — 钱包指向错误网络；检查 /en/networks。

自托管的局限与权衡

非托管钱包消除了交易对手风险，但将操作风险集中在用户身上。没有密码重置、没有退款、没有恢复服务台。硬件签名减少密钥暴露，但增加了设备依赖。基于 MPC 的钱包将密钥材料分散到多方，但引入了协调复杂性和新的故障模式。

RPC 依赖是另一个权衡。从单一端点读取的钱包继承了该端点的可用性和正确性。多端点故障转移提高弹性，但使 nonce 管理复杂化，因为不同节点可能报告不同的待处理状态。对于构建钱包基础设施的团队，/en/api-service 的集成指南和 /en/learn/blockchain-node-hosting-guide 的节点托管概述是相关的起点。

• 自托管：完全控制，完全责任。
• 硬件签名：更强的密钥隔离，设备生命周期负担。
• MPC：无单一密钥故障点，增加协调开销。
• 单一 RPC：简单，但存在状态和可用性的单点故障。

钱包构建者和运营者的后续步骤

如果你正在将非托管钱包集成到应用中，首先使用上述脚本验证本地签名路径，然后使用结果表流程对至少两个 RPC 端点进行基准测试。记录你的集成所依赖的链 ID 和 nonce 行为，并在持有真实价值之前，在干净设备上测试从助记词恢复。

对于跨网络的端点选择，使用 RPC Assistant 指南而非硬编码提供商。/en/learn/best-ethereum-rpc-api 的以太坊 API 概述和 /en/learn/rpc-endpoints-guide 的更广泛端点指南涵盖了共享与专用基础设施之间的权衡。保持签名路径本地、RPC 路径冗余、恢复路径经过测试。