区块链应用的安全随机数生成
许多区块链应用程序需要访问随机生成的数字的安全来源。
例如，头像 NFT 掉落需要为每个 NFT 选择随机属性组合。或者，在区块链上运行的视频游戏可能希望在打开宝箱时随机抽取宝箱中的物品。在这两种情况下，安全的随机数生成器使应用程序对用户来说是公平的。这些只是随机数的一些可能应用——一般来说，随机性是解决许多不同类型算法问题的有用工具。
不幸的是，区块链的固有属性使得生成随机数变得更加困难。区块链的状态根据一组确定性的规则演变，其中每笔交易都会根据其输入生成特定的输出状态。这些规则必须是确定性的，因为每个验证者都必须能够验证每笔交易的处理。如果规则不是确定性的，那么验证者可能会对状态产生分歧。
但是，有多种随机数生成方法适用于区块链。本文将介绍和分析其中的一些方法。
参与者
随机数生成协议通常涉及多个不同的参与者。每个参与者都是参与协议或对结果感兴趣的人。根据方法的不同，将涉及以下参与者的不同子集。可能的参与者是：
应用程序开发人员 — 开发人员编写请求和使用随机数的软件。尽管开发人员通常不会在生成随机数方面发挥积极作用，但开发人员希望结果是真正随机的。例如，NFT 集合的开发人员希望确保没有人可以欺骗他们的协议来铸造具有所有最稀有属性的 NFT。
用户 — 用户与协议交互以发起随机数请求。例如，用户可能是铸造 NFT 的人。
验证器 — 许多随机数生成协议使用来自区块链的输入数据。区块链的验证者（或矿工/排序者，视情况而定）可能对该输入数据有一定的控制权。
服务提供商 — 许多协议都有一个指定的链下服务提供商，负责流程的某些部分。该服务提供商应该是中立的第三方，但更复杂的随机数生成方法将最大限度地减少对该参与者的信任。
请注意，一个人可能会扮演多个参与者的角色。例如，用户还可以在网络上运行验证器。这些协议上的许多攻击媒介将来自多个参与者秘密合作的场景。
性能
在我们讨论方法之前，我们应该就随机数生成器的所需属性达成一致。
每个随机数生成器分两个阶段运行。首先，用户在请求阶段请求一个随机数。其次，在揭示阶段生成随机数并发布到区块链。这些阶段中的每一个都需要至少一个区块链交易——不可能在单个交易中安全地生成链上随机数。但是，在每个阶段执行的确切计算在各种协议之间会有所不同。
我们关注三个安全属性：
不可预测性 — 在请求随机数之前，任何参与者都不应能够以比机会更好的赔率预测随机值。此属性只是“随机”的正式定义。
确定性 — 请求随机数后，它正好可以取一个可能的值。此属性可确保参与者在请求结果后无法影响结果。
活动 — 请求随机数后，协议将运行至完成。也就是说，揭示阶段也完成。
关于随机数生成协议，要问的关键问题是：这些属性在什么条件下成立？例如，协议可能要求服务提供商诚实行事。这些条件是协议的信任假设。信任假设越少，协议就越安全。
方法
受信任的第三方
最简单的协议是让一个生成随机数的服务提供商。当用户请求一个随机数时，服务提供商只需在链下生成一个随机数并将其发布回区块链。
这种方法非常简单，但需要很强的信任假设：参与者必须信任服务提供商的诚实。服务提供商可以选择随机数，并且还能够停止协议。通过让服务提供商在安全区域（例如英特尔 SGX）内进行计算，可以在一定程度上改进这些假设，尽管此类区域一再证明它们并不完美（例如 SgxPectre 攻击）。
区块哈希
一种简单的随机数生成策略是使用未来区块的区块哈希。请求事务保存当前（或未来）区块号。然后，网络的验证者计算该区块的区块哈希。一旦 blockhash 可用，揭示交易就会简单地返回它。
blockhash 方法在任何区块链上都简单易用。然而，它需要强有力的假设：参与者必须相信验证者的诚实。验证者可以对交易进行重新排序或省略以修改区块哈希。因此，攻击是协议的用户运行或与验证者串通，以确保选择有利的随机数。
可验证随机函数
到目前为止，以前方法的问题在于，单个参与者可以影响结果（从而使其可预测）。可验证随机函数通过要求多个参与者协作来影响随机数来消除此攻击媒介。
VRF 是一个函数，其属性是输出看起来是随机的，但根据输入和密钥确定性地计算。此外，该函数返回一个证明，任何人都可以检查以验证输出是否正确。（这个解释有点简化。有关更详尽的解释，请参阅有关 VRF 的 IETF RFC）。f_s(x) = (y,p)yxspy
在区块链上，VRF 通常按如下方式使用。首先，输入部分由用户提供，部分来自blockhash。拥有密钥的链下服务提供商监视区块链中的请求，并提交链上响应。显示事务检查证明以确保其值正确，然后继续。xs(y,p)py
VRF 的好处是，与以前的方法相比，它改进了信任假设：用户、验证者和服务提供商都必须串通才能预测随机数。VRF的主要关注点是活跃度：参与者必须相信服务提供商不会审查交易。服务提供商可以看到生成的随机数，并选择是否将其提交到区块链。例如，一种可能的攻击可能是：用户提交一个请求说掷硬币，然后与VRF提供商串通，只有在结果是正面时才完成请求。但是，应用程序开发人员可以缓解这些攻击，特别是，只要用户不能从失败的披露中受益，就没有动力执行这种攻击。
VRF 的另一个缺点是密码学相对复杂且计算密集。大多数区块链不提供所有必要加密原语的内置实现，因此实现可能会使用大量 gas 或需要多次交易。
提交-揭示
VRF 并不是改善随机数生成的信任假设的唯一方法。另一种方法是在相互不信任的各方之间生成随机数的提交-揭示协议。该协议的基本版本工作如下：
- 在请求阶段，用户和服务提供商都会生成一个秘密随机数。他们都将该随机数的哈希值提交给区块链。哈希称为承诺。
- 在显示阶段，用户和服务提供商都会显示他们的随机数。每个参与者检查其他参与者显示的数字是否符合其承诺。然后，随机数是两个随机数的哈希值。对于区块链实现，来自请求交易的区块哈希也可以包含在最后的哈希步骤中。
与初始方法相比，提交-揭示协议同样改进了信任假设：用户、验证者和服务提供商都必须串通起来预测随机数。此外，该协议仅使用简单的加密技术——它只需要一个哈希函数——因此易于实现。然而，该协议与VRF存在类似的活动性问题：无论哪个用户或服务提供商透露他们的随机数秒，都可以停止该协议。与 VRF 一样，应用程序开发人员可以使用上述 VRF 的相同技术来缓解此攻击媒介。
请注意，此协议的幼稚实现将需要两个以上的事务，因为用户和服务提供商都需要在两个阶段中的每一个阶段发送事务。这个缺点可以通过更复杂的实现来解决，该实现允许服务提供商预先承诺许多数字。Pyth Entropy 就是这样一个复杂的提交-揭示协议的实现。
VRF 和 commit-reveal 都允许应用程序开发人员以牺牲活动性为代价获得不可预测性。如果开发人员担心信任一个服务提供商，他们可以简单地向服务提供商请求随机数并合并结果。这种方法提高了不可预测性——所有提供者都需要合作来影响结果——但会降低活力——任何一个提供者都可以阻止随机数被泄露。但是，请注意，没有一个提供商单独知道最终的随机数是什么，因此他们不能使用该知识来决定何时停止协议。NNNN
其他方法
还有其他更高级的方法可以生成安全随机数。这些方法旨在从上面改善不可预测性/活跃度的权衡，因此需要> 1 个提供者来停止协议。其中一种方法是阈值 VRF，其中 VRF 的密钥在多个参与者之间分片。另一种方法是随机信标.虽然这些方法确实比上述方法具有更好的安全权衡，但对于大多数应用程序来说，它们有点矫枉过正，特别是因为可以通过应用程序设计来缓解活动问题。s
结论
本文介绍了几种在区块链上生成随机数的方法，并分析了它们的优缺点。如果您正在开发一个需要安全随机数生成的应用程序，请查看 Pyth Entropy，并通过 Discord、Telegram 或其他社交渠道联系 Pyth 贡献者，了解如何利用 Pyth 的这款创新新产品。