认为实现随机数很简单？再想想。 无论你是在构建链上协议还是链下基础设施，正确的随机数实现都是加密安全中最棘手的部分之一。 让我们深入探讨一下为什么重放保护比看起来要困难 👇

2/ 首先，让我们了解数字签名。在公钥加密（如 BLS）中，您有一个私钥用于签署消息，还有一个公钥用于验证它们。 在 Ethereum 中： 地址 = 公钥哈希 消息 = 交易哈希 签名 = 64 字节的加密证明

问题在于：大多数公钥加密协议中的数学并没有限制对同一消息验证签名的次数。一旦你拥有一个有效的签名，你可以无限次重放它。这为重放攻击打开了大门。

4/ 输入随机数：一个 "只使用一次的数字"，用于防止重放攻击。当消费者收到带有随机数的消息时，它会检查该随机数是否之前被使用过。如果是 → 拒绝。Ethereum 交易使用这种模式。

5/ 但 nonce 的实现 deceptively 复杂。关键要求： - Nonces 必须绝对不能重用（在此链或其他链上） - 必须永久防止重放攻击 - 需要处理存储增长的机制 - 必须抵御前置攻击

6/ 天真的解决方案：将所有 nonce 永久存储在数据库中。这有两个主要问题： a) 存储增长无限制（尤其是在垃圾邮件攻击时） b) 易受前置攻击的影响 问题 (a) 比 (b) 更容易解决。让我们先解决存储问题...

7/ 基于时间戳的随机数解决了存储增长的问题！使用时间戳 + 过期时间。超过 5 分钟的随机数将从数据库中删除。但是来自同一账户的同时消息怎么办？它们共享一个时间戳。解决方案：时间戳 + 随机字节以实现细粒度的唯一性。

8/ 前置交易是一个棘手的问题。恶意行为者可以拦截有效的签名，进行前置交易以将随机数标记为已使用，然后合法用户的调用将被拒绝。这在链上批量操作时是个问题，如果一个坏签名拒绝了整个批次。对于链下：使用TLS加密！不要让任何恶意行为者看到随机数或签名。

9/ 不要忘记持久性！如果你的 nonce 缓存仅在内存中，攻击者可以在系统重启后重放旧的 nonces。始终将 nonce 状态持久化到耐用存储中，并在启动时重新加载。仅内存缓存 = 重放漏洞窗口。

10/ 每个消费者的唯一随机数！在向多个用户广播时，每个用户应该收到不同的消息/签名。否则，您将面临中间人攻击的风险，其中一个接收者转发消息，冒充原始发送者。

11/ 增量 nonce（如 Ethereum，nonce = 上一个 nonce + 1）有其存在的意义，但要小心！它们为链下基础设施带来了巨大的挑战：乱序消息、同步问题和复杂的恢复场景。只有在你确信消息会（或必须）按顺序到达时才使用。

摘要 - Nonce 实现检查清单： ✅ 使用 nonces 防止重放攻击 ✅ 在重启后保持 nonce 状态 ✅ 实现过期机制（时间戳 + 清理） ✅ 确保每个接收者的 nonces 唯一 ✅ 通过加密通道保护免受前置交易影响 ✅ 除非保证顺序，否则避免增量 nonce 安全在于细节！ 🛡️