换了私钥，旧地址收到的转账怎么办？

ArcBlock2026年9月29日

换一对密钥并不难。麻烦的是，别人手里的收款地址还没换，应用保存的账户记录也还指向原来的地址。即使你已经把余额转到新账户，明天仍可能有人向旧地址转账。

账户迁移需要处理这段延续关系：由谁批准换到新账户，系统怎样从旧地址找到迁移后的账户，哪些状态能够跟着迁移。 只生成新密钥，不能回答这些问题。

ArcBlock 的 US11388010B2 描述了在链上记录迁移关系的设计。这件专利于 2019 年申请，2022 年获授权。下面先解释其中的机制，再对照 SDK 源码说明地址实际怎样变化；专利描述不等于每个钱包或网络都已提供同样功能。出版物记录保留了完整书目信息。

旧地址留下来做什么

假设一个账户的旧地址是 A，新密钥对应的地址是 B。这是一个用于解释的例子。

在专利权利要求 1 的流程中，迁移交易包含旧地址、新地址和新公钥，由旧私钥签名。系统据此建立迁移关系，随后处理发往旧账户的交易时，可以按该关系把转入导向新账户。

A 因而仍然有用：它是别人已经知道的入口，也是历史记录中的地址。B 则是迁移后的目标。保留 A 的用途，不等于 A 和 B 是同一个地址，也不等于旧密钥继续拥有原来的操作权限。

如果以后 B 又迁移到 C，系统还要能沿迁移关系找到合适的目标。权利要求 6、7 涉及这种迁移历史及中间账户。这个机制需要链的执行规则支持，不能靠钱包把界面上的地址文字替换一下实现。

拿“换手机号”类比只能走到这里：旧联系方式还能找到你。区块链账户多了一项关键要求，系统必须能够验证谁有权建立这个转向关系，否则任何人都可能把别人的入账改到自己的账户。

这些名称在不同系统里可能重叠，判断时应看实际规则。尤其要问：这次变更究竟由哪一把密钥、哪些参与者或什么预先设置批准？

专利上述迁移流程需要旧私钥签名。如果旧私钥已经彻底丢失，又没有另外配置可用的恢复机制，这个流程不能替你生成那份签名。如果旧私钥是泄露而非丢失，你和攻击者可能同时有签名能力；迁移交易尚未生效时，不能把“已提交”当作账户已经安全。

DID 恢复的学习节点讨论了另一个常见误会：恢复标识符的控制权，并不自动恢复加密文件的解密密钥。

查看公开发布的 @ocap/client 与 @ocap/tx-protocols 1.20.2 源码，可以把“迁移”落实到具体操作。以下说明针对这两个发布包，所用网络可能运行不同代码。

客户端的 migrateAccount 接收 from 和 to 两个钱包。它把 to.address、to.publicKey 放进迁移内容，用 from 钱包发起交易。

执行侧要求目标地址与发送方不同，还要求目标公钥和地址匹配。目标账户不能已经存在。通过相关检查后，它创建目标账户状态，并写入新旧账户的迁移关系。

因此，把这个 API 解释成“账户地址不变，只换关联的公钥”是不准确的。旧地址查询可能沿迁移关系返回新账户状态，容易让调用方误以为地址没有变。账户管理指南提供 API 参数和示例。

迁移流程还包含费用和 gas 处理。“延续账户状态”也不能直接改写成“迁移前后余额数字保证完全相同”。

一个月前，A 的密钥签过一条记录。今天迁移到 B，这条旧记录是否就不能验证了？

签名验证回答的是：这段内容能否用对应公钥验证，内容有没有被改动。未来权限回答的是：系统现在是否仍接受这把密钥代表该账户发起操作。两者需要分别判断。专利权利要求 5 明确涉及迁移后使用旧公钥验证迁移前的签名。

保留旧公钥用于历史验证，不等于重新授予它当前权限。反过来，取消旧密钥的未来权限，也不应被描述成把过去的签名从历史中抹掉。

应用仍需保留足够的上下文，例如记录属于哪个账户、形成于什么状态下。若只看“签名数学上有效”就放行今天的请求，应用可能忽略已经生效的迁移、撤销或权限变更。

专利区分可转移代币与不可转移代币的情况，后者受到规则限制，不能直接转给其他账户：权利要求 3 涉及可转移代币，权利要求 10、16 涉及不可转移代币留在旧账户的情形。这已经说明“迁移”不是对账户相关一切对象的统一搬家指令。

链外的数据更要单独检查。某个应用可能用 A 识别用户；一张凭据可能明确签发给 A；一份文件可能使用另一把密钥加密。这些对象是否接受 A 到 B 的关系，取决于各自的验证、更新和访问规则。账户迁移记录不会替凭据签发者重签文件，也不会凭空恢复解密秘密。

因此验收不能只看钱包首页余额。能否重新登录、是否还能读取旧数据、凭据是否仍被接受，都要到对应应用中确认。

先在可以丢弃的测试网络上使用测试账户，确认版本、交易费用和目标地址的要求。不要把真实账户迁移当作第一次学习这个 API 的练习。

你可以自己测试，也可以要求钱包或网络提供方给出下面这些验证结果。

一组有意义的验证应从 A 迁移到 B 开始：确认交易已生效，分别查看原始账户记录和会跟随迁移关系的查询结果。再检查旧密钥发起的新操作会怎样处理，新账户能否按规则操作，以及迁移后发往 A 的转账最终记在哪里。若产品支持再次迁移，再验证 B 到 C 后从 A 开始的解析。

拒绝路径也值得保留结果：迁往自身、迁往已存在账户、使用不匹配的目标公钥。余额不足需要单独检查：这个发布版本不会仅因余额不足以支付迁移费用就必然拒绝交易。费用行为和具体错误必须以所用版本为准，不能把某个前端按钮成功返回当作链已完成状态变更。

把这些结果与实际网络运行的版本对照。阅读公开实现可以解释一条规则，但不能证明某个部署已经按它执行。

如果只是让一个程序代办有限操作，可以先考虑委托授权。让程序拿到受限权限，与把整个账户迁到新的控制密钥，解决的是不同问题。

如果目标网络没有对应规则，或者业务必须继续使用完全相同的地址，本文的迁移设计不能靠客户端单方面补出来。若旧密钥已经不可用，则需要检查事先建立的恢复安排。

换掉密钥之后，真正需要留下的是可被系统验证的延续关系：旧入口仍能找到正确目标，新的操作使用当前权限，历史记录保留其验证依据。地址、资产和应用数据是否都满足这些条件，必须逐项确认。