AI 安全预警之后，钱包该怎么用

看到一条密码学安全预警，普通用户最想知道的往往只有一句话：我的钱包现在该怎么用？

Justin Drake 在 10 月 7 日的长帖里提出，AI 带来的数学进展可能让区块链使用的签名算法比预期更早面临威胁。他建议行业开始准备，把长期保管的资产放到公钥尚未暴露的地址，同时反复提醒不要恐慌、不要仓促迁移。

这篇文章回应的是他的这则原帖：

Vitalik Buterin 随后也回应了这次预警。他同样认真看待风险，但明确不建议大家今天急着更换钱包。他把讨论进一步推进到：我们准备换上的密码学，是否也可能受到 AI 数学进展的影响？

两人的提醒并不矛盾：Drake 更强调尽早准备，Vitalik 更强调行动的条件和代价。两人都反对仓促迁移。

我赞成认真对待这样的预警。但从技术判断走到用户操作，中间还有很长一段路。一种防护办法如果让用户更容易转错地址、丢失备份，或者不敢验证自己能否把钱转出来，它的安全收益就需要连同这些代价一起衡量。

尤其值得讨论的是测试转账。先发一笔小额，确认收款；如果目标是自己的钱包，再转出一笔，确认自己有控制权。这是有用的操作验证。可是在“尽量不暴露公钥”这个新的防护目标下，转出测试恰恰可能把公钥公开。这并不意味着测试突然变成了坏习惯，而是我们需要分清，它原来验证什么，现在又多了什么约束。

预警不等于钱包已经被破解

先把三个经常混在一起的东西分开：私钥、公钥和地址。

私钥是你必须保密的签字凭据。钱包用它给交易做数字签名，证明这笔操作得到授权。公钥用来检查签名是否有效；正常情况下，别人知道公钥，也不能据此算出私钥。地址是你提供给付款方的收款标识。在一些常见地址格式中，地址由公钥经过哈希运算产生。哈希可以粗略理解为一种难以倒推原文的数字摘要，因此看到地址，并不一定已经看到了完整公钥。[1][2]

这套设计原本就允许公钥公开。公钥已公开，不等于私钥已泄露。

Drake 担心的是安全假设本身发生变化：假如 AI 帮助人类找到足够高效的新算法，从公钥倒推出私钥变得可行，那么公开过公钥的账户就会处于另一种风险之下。他提到的 ECDSA，是一种广泛使用的数字签名算法。这个担忧也不必等到大型量子计算机出现，才有讨论的意义。

但原帖没有给出针对实际钱包、可以复现的私钥破解方法。他提出的时间窗口是风险判断，不能当成已经得到验证的倒计时。值得推动研究和准备，与需要所有人今天搬动资产，是两件不同的事。

Vitalik 补充的一个关键问题是：抗量子，不等于已经证明能抵御 AI 帮助发现的未知攻击。 他特别担心格密码的安全余量。格密码是一类把安全性建立在高维数学难题上的方案，ML-DSA 就是其中已经被美国国家标准与技术研究院（NIST）标准化的签名算法。标准化说明它经过了评估，不意味着未来不会出现更高效的攻击。[7]

他倾向于在适合的场景使用基于哈希的签名。这类签名也已有标准，例如 SLH-DSA。[8] 但这不是“格密码已经被攻破”，更不是“哈希永远安全”的结论。对普通用户，值得理解的是升级需要持续评估；不需要因此自行挑选算法，或把网上的参数建议当作钱包设置指南。

这也解释了为什么“我用冷钱包”不能回答全部问题。所谓冷存储，重点是让私钥远离联网环境；硬件钱包则把私钥和签名操作放在专门设备里。链上的资产记录并不装在那个设备里。如果未来攻击者能从公开信息算出私钥，设备没有联网也挡不住这种攻击。与此同时，硬件钱包对防止私钥被普通电脑上的恶意软件直接窃取，仍然有重要价值。

一个钱包，为什么能有很多地址？

这里有一段值得讲清楚的钱包设计史。

如果每个地址都使用一把独立随机生成的钥匙，备份就很麻烦：新增了钥匙，旧备份里可能没有它。后来，钱包设计者采用了一种办法，让同一个秘密起点按照确定的规则，生成一棵分支树，每个位置都能得到相应的钥匙。[3]

这就是 HD 钱包。HD 是 Hierarchical Deterministic，意思是“分层确定性”。名字很复杂，用户得到的好处却很直接：恢复同一个秘密起点，并沿相同的分支走，就能重新找到那些钥匙。常见的助记词，是恢复这个起点的一种备份形式；如果还使用额外口令，口令也参与决定得到哪个钱包。

可以把它想成一本能重新生成的钥匙目录。你不必每增加一个收款地址，就另外保存一份秘密。但目录上的位置仍然重要：不同链、不同账户或不同地址类型，可能使用不同分支。

这为测试转账提供了一个更细致的思路。对于一个新配置的钱包，可以先用其中一个地址完成小额收款和转出测试，检查基本操作流程。若另有“长期保管地址尚未公开公钥”的需求，再使用同一钱包按规则派生的另一个新地址，并在硬件钱包自身的可信屏幕上核对完整地址。设备确认地址的过程，通常不需要在链上发起转出交易。[4]

这里验证的是不同的事情。测试地址帮助检查收发流程；设备上的地址确认，帮助确认新地址属于设备当前的钱包，并避免电脑把收款地址悄悄替换。它们可以配合使用，不能互相替代。一次成功的转账，也不能证明备份以后一定恢复成功；备份检查应遵循设备厂商的流程，助记词不要输入聊天机器人、网页检查器或陌生的“迁移工具”。

同一份助记词派生，不等于任何新地址都无条件可用，也不等于它的公钥一定没有暴露。 恢复或核对某个地址时，必须使用生成它时相同的链、账户、地址类型和额外口令等设置。某些只读钱包还使用一种叫 xpub 的扩展公钥来生成地址和观察余额；如果它已交给外部服务，相关分支的公钥可能已经能够被推导出来。不能仅凭“这个地址没有转过账”，就判定公钥仍然隐藏。[3]

还有一个容易被忽略的例外：比特币一种名为 Taproot 的地址格式，其对应的链上交易输出本身就包含公钥。因此，“新地址”不是跨所有地址格式都有效的公钥隐藏措施。这里的区别需要钱包软件解释清楚，不适合让普通用户看一条帖子后自行猜测、仓促切换格式。[5]

钱要存得住，也要花得出去

比特币和以太坊在这里还不能照搬同一套操作说明。

比特币的钱包余额，是若干笔尚未花掉的交易输出加起来的。这些输出通常叫 UTXO，可以粗略想成面额不一的现金。花费时，用掉的是整张“钞票”，多出来的部分作为找零回到自己控制的地址。[1]

假设某一笔输出有 100 BTC，这次要支付 1 BTC，交易可以同时把接近 99 BTC 的找零扣除手续费后，放到自己的新地址。它不必先把余款留在原地址，再补做第二笔转账。使用新找零地址，本来就是比特币钱包已有的做法。

不过，如果还有其他未花费的输出使用同一把已公开的公钥，它们不会因为这次找零就自动搬走。反过来，一个地址公开了公钥，也不能直接推断同一钱包里所有不同钥匙都已经公开。

以太坊常见的普通账户更像有持续余额的账户。发出一笔交易后，剩余余额仍在原账户；交易签名会让对应公钥可以被恢复出来。某些链下消息签名，例如钱包弹出的部分登录或消息确认请求，也会产生同样的公钥暴露问题，所以“不发交易”还不等于“没有公开过公钥”。[2]

如果这个账户还持有不同代币，或者在应用里留下了授权和身份关系，换一个地址就更不只是搬一次余额。有些权限需要重新设置，有些记录不会跟着走。让用户每次操作之后都自行处理这些关系，会明显增加出错的机会。

而且，隐藏公钥主要是在改变资产静置期间的暴露面。当需要花费，公钥或可恢复它的签名仍可能公开。假如未来攻击快到能在交易确认之前完成，原先隐藏公钥也不能单独保证安全退出。它是一种有条件的防护思路，不能替代签名算法本身的升级。[5]

Vitalik 对迁移的提醒尤其值得保留：他公开提到，自己因迁移失误遭受的损失，比遭遇黑客攻击的损失还多。这个个人经验不能代表所有用户，却把一个容易被技术讨论遮住的风险说得很具体。新地址带来的潜在防护收益，必须与迁移出错的可能性一起看。

还有两类场景，需要把建议再分细一点。

多签钱包，要看签名在哪里公开。 多签意味着一笔操作需要达到指定数量的签署者同意。Vitalik 建议优先在链下收集确认，减少公开签名带来的暴露。但“链下”只是没有发布到链上，收到签名的人仍然能看到它。如果从公钥恢复私钥真的变得可行，收集方也可能成为新的风险点；最后提交交易时会公开什么，还取决于具体钱包与合约。不能把这条建议简化成“改用多签就安全了”。

隐私数据，要区分签名与加密。 签名回答“谁批准了这件事”，加密回答“谁能读到内容”。改善签名，并不会顺带保护过去上传的密文。Vitalik 建议隐私协议避免把加密记录永久放在链上。道理是，公开留下的密文可以被复制，等待未来的新方法来尝试解密。移到链下能减少永久公开，但仍需处理访问控制、备份和接收方泄露，不能保证已经流出的副本消失。

这两点也提醒我们：减少公开信息有价值，但最终仍要问，信息到了谁手里，系统以后怎样更新。

因此，对普通用户，我更愿意把当前可执行的建议放在下面几个具体动作上：

这些操作无法许诺抵御未来一切数学突破。但它们能避免在准备防范一种潜在威胁时，引入另一种非常现实的失误。

换一把钥匙，不该重建整个账户

这次讨论让我重新想到我们早期设计 ArcBlock 区块链时的问题：企业系统会更换密钥、撤销权限、调整人员和设备，为什么到了区块链里，更换一把钥匙就常常意味着让用户重新安排所有关系？

我们当时做账户迁移和委托授权，出发点包括把这些企业安全实践带进来。密钥应当能够更新，应用只应取得完成任务所需的权限，旧的收款关系也需要有系统认可的延续办法。

ArcBlock 于 2019 年申请、2022 年获授权的账户迁移专利 US11388010B2，描述了由旧账户批准迁往新账户，并在链上记录新旧关系的机制。它也讨论了因为算法出现漏洞而更换所用算法的情形。旧版 SDK 中有相应迁移流程；我们对专利和实现的梳理区分了设计范围与具体版本行为。

这件事的意义，在于让换钥匙之后的延续关系由系统处理，而不只是告诉用户“请生成一个新地址”。但它不是这次预警的现成解法：该迁移流程会提交新公钥，并依赖旧私钥签名。如果旧算法已经能被攻破，攻击者也可能有能力批准迁移。只换一把仍采用同样脆弱算法的钥匙，不能消除算法层面的风险。[6]

委托授权处理的是另一个问题：让应用取得限定范围的操作权限，而不必拿走用户的主私钥，并能撤销委托。它有助于控制应用失误或受侵入时的影响范围，但也不能把已经失效的签名算法变安全，更不能据此保证主公钥从未公开。

这些设计给今天留下了有用的起点，也留下了需要继续回答的问题。更换签名算法时，谁有权批准？旧密钥不再可靠时，有没有提前建立的其他验证途径？用户的地址、资产和应用关系能延续到什么程度？钱包怎样让用户确认这些变化，而不要求他先成为密码学专家？

Drake 提醒我们尽早准备，Vitalik 提醒我们审视算法选择与迁移代价。我认为，这场讨论值得继续向系统怎样承接这些变化推进。协议要准备更稳健的密码学，钱包和应用则需要准备人能正确完成的操作。一个用户可以放心验证、可以恢复、也能在需要时安全花费的账户，才是我们应该努力交付的安全体验。

参考资料