区块链应用程序的安全随机数生成

许多区块链应用程序需要访问随机生成数字的安全来源。

例如，头像 NFT 掉落需要为每个 NFT 选择随机属性组合。或者，在区块链上运行的视频游戏可能希望在打开宝箱时随机抽取宝箱中的物品。在这两种情况下，安全的随机数生成器都可以证明应用程序对用户来说是公平的。这些只是随机数的一些可能的应用 - 一般来说，随机性是解决许多不同类型的算法问题的有用工具。

不幸的是，区块链的固有属性使得生成随机数变得更加困难。区块链的状态根据一组确定性规则演变，其中每笔交易根据其输入生成特定的输出状态。这些规则必须是确定性的，因为每个验证器都必须能够验证每笔交易的处理。如果规则不是确定性的，那么验证者可能对状态不同意。

然而，有多种适用于区块链的随机数生成方法。本文解释并分析了其中一些方法。

参加者

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

应用程序开发人员 - 开发人员编写请求和使用随机数的软件。尽管开发人员通常在生成随机数方面不发挥积极作用，但开发人员希望结果是真正随机的。例如，NFT 集合的开发者希望确保没有人可以欺骗他们的协议来铸造具有所有最稀有属性的 NFT。

用户 — 用户与协议交互以发起随机数请求。例如，用户可能是 NFT 的铸造者。

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

服务提供商——许多协议都有一个指定的链下服务提供商，负责流程的某些部分。该服务提供商应该是中立的第三方，但更复杂的随机数生成方法将最大限度地减少对该参与者的信任。

请注意，一个人可能会扮演多个参与者的角色。例如，用户还可以在网络上运行验证器。这些协议的许多攻击媒介将来自多个参与者秘密合作的场景。

特性

在讨论方法之前，我们应该就随机数生成器所需的属性达成一致。

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

我们关心三个安全属性：

不可预测性 - 在请求随机数之前，没有任何参与者能够以比机会更好的几率来预测随机值。这个属性只是“随机”的正式定义。

确定性 — 请求随机数后，它只能取一个可能的值。此属性确保参与者在请求后无法影响结果。

Liveness - 请求随机数后，协议将运行完成。也就是说，揭示阶段也完成了。

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

随机性的方法

值得信赖的第三方

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

这种方法极其简单，但需要很强的信任假设：参与者必须信任服务提供商的诚实。服务提供商可以选择随机数，也可以停止协议。通过让服务提供商在安全飞地（例如英特尔 SGX）内进行计算，可以在一定程度上改进这些假设，尽管此类飞地已多次证明它们是不完美的（例如 SgxPectre 攻击）。

区块哈希

一种简单的随机数生成策略是使用未来区块的区块哈希。请求交易保存当前（或未来）的区块号。然后网络的验证器计算该块的块哈希。一旦区块哈希可用，揭示交易就会简单地返回它。

区块哈希方法简单且易于在任何区块链上使用。然而，它需要强有力的假设：参与者必须信任验证者的诚实。验证器可以重新排序或省略交易来修改区块哈希。因此，攻击是协议的用户运行或与验证者串通，以确保选择有利的随机数。

可验证的随机函数

到目前为止，先前方法的问题是单个参与者可以影响结果（从而使其可预测）。可验证随机函数通过要求多个参与者协作来影响随机数来消除这种攻击向量。

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 的另一个缺点是密码学相对复杂且计算量大。大多数区块链不提供所有必要的加密原语的内置实现，因此实现可能会使用大量气体或需要多个交易。

提交-揭示

VRF 并不是改善随机数生成的信任假设的唯一方法。另一种方法是在互不信任的各方之间生成随机数的提交-揭示协议。该协议的基本版本工作原理如下：

1. 在请求阶段，用户和服务提供商都生成一个秘密随机数。他们都将该随机数的哈希值提交到区块链。该哈希值称为承诺。
2. 在揭示阶段，用户和服务提供商都揭示他们的随机数。每个参与者都会检查其他参与者透露的数字哈希值是否符合他们的承诺。那么，随机数就是这两个随机数的哈希值。对于区块链实现，请求交易的区块哈希也可以包含在最后的哈希步骤中。

提交-揭示协议同样改进了初始方法的信任假设：用户、验证者和服务提供者必须共谋预测随机数。此外，该协议仅使用简单的密码学——它只需要一个哈希函数——因此实现起来很简单。然而，该协议与 VRF 存在类似的活跃性问题：无论用户或服务提供商中的哪一方透露其随机数，都可以停止该协议。与 VRF 一样，应用程序开发人员可以使用上述 VRF 相同的技术来缓解这种攻击向量。

请注意，该协议的简单实现将需要两个以上的事务，因为用户和服务提供商都需要在两个阶段的每个阶段发送事务。这个缺点可以通过更复杂的实现来解决，该实现允许服务提供商预先承诺许多号码。 Pyth Entropy 就是提交-显示协议的复杂实现。

VRF 和 commit-reveal 都允许应用程序开发人员以牺牲活性为代价获得不可预测性。如果开发人员担心信任一个服务提供商，他们可以简单地向 N 个服务提供商请求随机数，然后组合结果。这种方法提高了不可预测性 - 所有 N 提供者需要协作才能影响结果 - 但降低了活跃度 - 任何一个 N 提供者都可以防止随机数被泄露。但是，请注意，没有一个 N 提供商单独知道最终的随机数是什么，因此他们无法使用该知识来决定何时停止协议。

其他方法

还有其他更先进的方法来生成安全随机数。这些方法旨在改善上述不可预测性/活跃性权衡，以便需要 > 1 个提供商来停止协议。其中一种方法是阈值 VRF，其中 VRF 的密钥 s 在多个参与者之间分片。另一种方法是随机信标。虽然这些方法确实比上述方法具有更好的安全权衡，但对于大多数应用程序来说，它们有些过大，特别是因为活性问题可以通过应用程序设计来缓解。

结论

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