区块链应用如何生成安全的随机数？

许多区块链应用需要使用从安全数据源处生成的随机数。

举例来说，一个 NFT PFP 系列空投需要为每张 NFT 图片选择随机的属性组合；链上游戏可能需要在打开宝箱时随机抽取物品。在这两种情况下，一个安全的随机数生成器可以保障用户在应用程序面前的公平性。这些也仅仅是随机数的一些可能的应用场景 — — 一般来说，随机性是解决许多不同类型算法问题的有用工具。

不幸的是，区块链的固有属性让生成随机数的过程并不那么容易完成。区块链的状态是根据一组确定性的规则进行发展的，其中每个交易都会在给定其输入值的情况下生成特定的输出状态。这些规则必须是确定性的，因为区块链要求每个验证器能够验证每笔交易的处理过程。如果规则不是确定性的，那么验证者就可能会对状态持不同意见。

区块链上有很多种随机数的生成方法。本文解释并分析了其中的一些方法及其优缺点。

参与者

随机数生成协议通常涉及多个不同的参与者。每个参与者都是协议的参与者或是对生成结果感兴趣的人。根据不同的方法，参与者都会涉及不同的子集。可能的参与者有：

应用开发者 — — 开发者负责编写请求并使用随机数的软件。尽管开发者通常不会参与到生成随机数的过程中，但开发者往往希望结果是真正随机的。例如，一个 NFT 系列的开发者希望能够确保没有人可以在 NFT 铸造协议中作弊，以获得具有所有稀有属性的 NFT。

用户 — — 用户通过与协议交互以发起随机数生成请求。例如，用户可以是铸造 NFT 的人。

验证器 — — 许多随机数生成协议使用来自区块链的输入数据。区块链的验证器（或矿工 / 序列器，视情况而定）可能会对输入数据有一定的控制权。

服务提供者 — — 许多协议都有一个指定的链下服务提供者，负责随机数生成流程的某些部分。该服务提供者应该是一个中立的第三方，但这需要更复杂的随机数生成方法来将授予该参与者的信任度最小化。

请注意，一个人可能扮演多个参与者的角色。例如，用户自身可以在区块链网络上运行验证器。这些协议上的许多攻击向量都是由于多个参与者的秘密合作。

属性

在我们讨论随机数生成方法之前，我们应该对期望的随机数生成器属性有一致的了解。

每个随机数生成器都分两个阶段运行。首先，在请求阶段，用户向生成器请求一个随机数。然后，在发布阶段，生成器生成随机数并发布到区块链上。每个阶段都需要至少一个区块链交易 — — 在单个交易中安全地生成链上随机数是不可能的。然而，在不同的协议中，每个阶段执行的精确计算是不同的。

我们关注的安全属性主要有三个：

• 不可预测性 — — 在请求随机数之前，没有一个参与者能够预测随机数。这个属性是「随机」的正式定义。
• 确定性 — — 在请求随机数之后，它只有一个可能的值。这个属性确保了参与者在请求结果后无法影响结果。
• 活动性 — — 在请求随机数后，协议运行立即完成。也就是说，请求阶段完成与揭示阶段完成在同一时刻发生。

关于随机数生成协议的关键问题是：这些属性在什么条件下成立？例如，协议可能要求服务提供者保持诚信。这些条件是协议的信任假设。信任假设越少，协议就越安全。

随机数生成方法可信第三方

最简单的随机数协议是让一个服务提供者生成随机数。当用户请求随机数时，服务提供者只需在链下生成一个随机数并将其发布回区块链即可。

这种方法非常简单，但需要强有力的信任假设：参与者必须信任服务提供者的诚实性。服务提供者可以自由选择随机数，也有能力中止协议。这些假设可以通过让服务提供者在一个安全的隔离环境（如 Intel SGX）内进行计算而得到一定程度的改进，然而这样的隔离环境已经多次被证明它们是不完美的（SgxPectre 攻击）。

区块哈希

一个简单的随机数生成策略是使用未来区块的区块哈希值。随机数生成请求交易将保存当前（或未来）的区块数字。然后，网络验证者将计算该区块的区块哈希。一旦区块哈希可用，生成器即发布生成交易。

区块哈希的生成方法简单，易于在任何区块链上使用。然而，它需要强有力的信任假设：参与者必须信任验证者的诚实性。验证器可以进行重新排序或忽略交易来修改区块哈希值。因此，协议的用户运行验证器或与验证器勾结会带来潜在的攻击风险，以确保用户选择到有利的随机数。

可验证随机函数（VRF）

之前我们讨论的方法的问题主要来自于单个参与者可以影响随机数的生成结果（从而使其变得可预测）。而可验证随机函数（VRF）通过要求多个参与者共同协作影响随机数生成结果来消除这种攻击向量。

VRF 是一个函数 f_s(x) = (y, p)，这个函数的特点是输出值 y 看起来是随机的，但它是由输入值 x 和秘钥 s 确定计算出来的。此外，该函数还会返回一个证明值 p，任何人都可以通过它来验证 y 是否是正确的输出值（这是一个非常简要的解释。有关 VRF 的更详细解释，请参阅 IETF RFC）。

在区块链上，VRF 通常如下所示。首先，输入值 x 部分由用户提供、部分来自区块哈希。链下服务提供者使用密钥 s 监视区块链上的请求，并提交一个链上相应值 (y, p)。发布交易检查证明值 p 以确保 y 是正确的值，然后进行发布。

VRF 的好处是，它比以前的方法改进了信任假设：用户、验证者和服务提供者都必须串通起来才能预测随机数。VRF 的主要关注点是活动性：参与者必须信任服务提供者不会审查交易。服务提供者可以看到生成的随机数，并选择是否将其提交到区块链。例如，一种可能的攻击可能是：用户提交一个抛硬币请求，然后与 VRF 提供者勾结，只有在结果是正面时才完成请求。但是，应用程序开发者可以减轻这些攻击 — — 特别地，只要用户不能从发布失败中获益，他们就没有动机执行此攻击。

VRF 的另一个缺点是密码学相对复杂且计算密集。大多数区块链无法提供内置的所有必要的密码学基础协议，因此发布随机数可能会消耗大量的 gas 或需要多个交易。

交付 – 发布

VRF 并不是改善随机数生成信任假设的唯一方法。另一种方法是在互不信任的双方之间生成随机数的交付 – 发布协议。该协议的基本工作原理如下：

在请求阶段，用户和服务提供者都会生成一个秘密随机数。他们都将随机数的哈希值提交给区块链。这个哈希值称为交付值。在发布阶段，用户和服务提供者都将发布他们的随机数。每个参与者检查另一个参与者所发布的数字是否与他们的交付值相符。该步骤完成后，最终的随机数则是这两个随机数的哈希值。对于区块链部署来说，来自请求交易的区块哈希也可以包含在最后的哈希加密步骤中。

与最初的方法相比，交付 – 发布协议同样地改进了信任假设：用户、验证者和服务提供者必须全部串通才能预测随机数。此外，这个协议只使用了简单的加密技术 — — 它只需要一个哈希函数 — — 所以它很容易实现。然而，该协议有一个与 VRF 类似的活动性问题：用户或服务提供者中的任何一个立即发布其随机数都可以中止协议。与 VRF 一样，应用程序开发者可以使用上述针对 VRF 的相同技术来减轻这种攻击向量。

请注意，该协议的最基础实现方式都将需要两个以上的交易，因为用户和服务提供者都需要在两个阶段中的每个阶段分别发送交易。这个缺点可以通过更复杂的部署方式来解决，这样的部署方式允许服务提供者预先提交多个随机数字。Pyth Entropy 就是交付 – 发布协议的复杂实现。

VRF 和交付 – 发布协议都允许应用程序开发者以牺牲活动性为代价获得不可预测性。如果开发者担心只信任一个服务提供者的风险，他们可以简单地向。N 个服务提供者请求随机数，并将结果组合起来。这种方法提高了不可预测性 — — 所有的 N 个提供者都需要协作才能影响结果 — — 但是降低了活动性 — — N 个提供者中的任何一个都可以中止随机数的发布。但是，请注意，N 个服务提供者中没有任何单独的一个知道最终随机数是什么，因此它们不能使用该知识来决定什么时候中止协议。

其他方法

还有其他更高级的方法来生成安全的随机数。这些方法旨在从上层改进不可预测性 / 活动性的权衡，这样就需要 >1 个提供者才能中止协议。其中一种方法是阈值 VRF，其中 VRF 的秘钥 s 在多个参与者之间进行分片存储。另一种方法是随机信标。虽然这些方法确实比上面的方法具有更好的安全性权衡，但对于大多数应用程序来说，它们有些矫枉过正，因为活动性问题可以通过应用程序设计来改善。

结论

本文介绍了几种在区块链上生成随机数的方法，并分析了它们的优缺点。如果你正在开发需要安全随机数生成器的应用，你可以查看 Pyth Entropy，并通过 Discord、Telegram 或其他社交渠道与 Pyth 贡献者联系，了解如何使用 Pyth 的这个创新产品。