简述 Filecoin 随机性来源 Drand 特征与功能

区块链的安全保障之一来自于各种的不可预测性，比如私钥、出块权、挑战种子等等。Filecoin 在最初的设计中采用 Ticket Chain 来产生不可预测但可公开验证的随机数。目前改为利用 Drand 来作为随机数源。

Drand 是一个独立的项目，本文对其简单做一个介绍。

类似于以太坊 2.0 实行的信标链（Beacon Chain），Filecoin 目前采用 Drand 作为其 Beacon 源，而启用最初设计的 Ticket 链。我们知道，Ticket Chain 实际上是一个逻辑链，是寄生在 Filecoin 链之上的。尽管 Ticket 链进行了很好的设计，但是仍然有其不令人满意的地方，比如说：1）其 Ticket 是每个区块都有的，但是每个高度仅需要一个，所以这里带来一个选择问题，但这个问题不大；另外，2) Ticket 本身并不是对所有人来说都是不可预测的，因为 Ticket 是矿工产生的，所以出块矿工比其他人更早知道这个随机数是什么；再进一步，3）当链发生分叉重组的时候，Ticket 就会发生变化，这给许多依赖 Ticket 进行的计算将失效。

所以，Ticket Chain 并不是一个理想的解决方案，Filecoin 团队是善于采纳新技术的，在权衡之下，目前的处理方式，随机数的产生完全脱离 Filecoin 网络，启用一个公共的、不可预测的、无倾向性的，可公共验证的随机源，这个随机源，就是 Drand。

可信随机源要解决的问题

简单来说，一个良好的随机源应该包含如下特性：

• 不可预测：任何时间点任何个体和群体都不能预测为发布的随机数
• 没有偏向性：**的输出分布完全是随机的，不能有任何的倾向性
• 公共可验证：在随机数生成之后，任何人都可以进行验证
• 去中心化：随机数的产生应当是由一群独立而且活跃的个体产生出来
• 可获得性：系统必须保持持续运行，总是（按照节奏）不断地输出随机结果

Drand：分布式随机信标守护程序

Drand （发音为「 dee-rand」）本身是一个程序，作为分布式节点都可以加入运行。Drand 由 Golang 编写，使用双线性配对和阈值加密技术，将运行 drand 的服务器彼此链接，以固定的区间生成共同的的，可公开验证的，无偏向于的，不可预测的随机值。Drand 节点还可以将本地生成的私有随机性提供给客户端。

drand 最初是在 DEDIS （去中心化分布式组织）组织内部开发的，在 2019 年 12 月，独立成为 drand 组织。

Drand 的目标和应用

公共可验证随机数的需求非常广泛。比如菠菜、区块链系统、嵌入式设备；同样，其在一些统计抽样中也至关重要：比如自治组织、选举、陪审团的组成、随机财务审计等等。然而，构建安全的随机性来源绝非易事。我们现实生活中就有各种攻击失利，比如福利彩票的作弊，选举的徇私等等。其中影响随机性的产生是原因很多，比如：静态密钥，非均匀分布 ，输出偏向等等。

那么，Drand 旨在通过提供随机即服务网络（类似于用于时间的 NTP 服务器或用于 CA 验证的证书颁发机构服务器）来实现突破，并提供连续的随机源。

Drand 机制包括如下特点，或者说目标：

• 去中心化：Drand 是由 Internet 上各种信誉良好的实体运行的软件，需要一个阈值来产生随机性，没有故障的中心点。
• 可公开验证且无偏向：drand 定期提供可公开验证且无偏向的随机性。任何第三方都可以获取并验证随机性的真实性，并确保该随机性未被篡改。
• 同时提供「私有」的本地服务：Drand 节点还可以提供加密的随机性，以供本地应用程序使用，例如为操作系统的 PRNG 注入种子。

当前，Drand 网络由包括 Cloudflare，EPFL，Kudelski Security，Protocol Labs，Celo，UCL 和 UIUC 在内的世界各地的组织运营。

如果想了解更多信息，您可以访问熵联盟（League of Entropy）网站。在该网站上还可以实时查看网络生成的随机值。

公共随机数

Drand 的主要功能就是产生公共随机数。实现这一点依靠 Drand 节点共同协作。

产生良好随机性的主要挑战是，参与随机性生成过程的任何一方都不能预测或带偏最终输出。此外，最终结果必须是第三方可验证的，以使其可以用于各种应用，比如：抽奖，分片或安全协议中的参数生成等。在 Filecoin 网络中，这种随机数的使用场合非常多，比如出块权、**证明的各个阶段、时空证明等等。

Drand 随机信标由一组分布式节点组成，并分为两个阶段：

1. 设置：每个节点首先生成一个长期使用的固定的公私密钥对。然后，将所有公钥与操作信标所需的其他一些元数据一起写入组文件中。分发此组文件后，节点执行分布式密钥生成（DKG）协议以为每个服务器创建公共公用密钥和一个私有密钥因子。也就是说，这个私钥是一个分布式私钥，有一组节点共同掌握。每一个参与者不会明确地看到或者使用整个分布式私钥，而是利用各自的私钥因子来通过计算获知公共密钥对，来产生公共随机性。设置的过程只需运行一次。
2. 生成：设置后，节点切换到持续性的随机性生成模式。任何一个节点都可以通过广播消息来发起随机性生成回合，所有其他参与者都使用 Boneh-nn-Shacham （BLS）签名方案的 n 个阈值版本及其各自的私钥因子进行签名。一旦任何节点（或第三方观察者）收集了 t 个部分签名，它就可以重建完整的 BLS 签名（使用拉格朗日插值）。然后使用 SHA-512 对签名进行哈希处理，以确保最终输出的字节表示形式没有偏差。该散列对应于集合随机值，并且可以针对集合公钥进行验证。

私有随机性

私有随机性，也就是为节点本地服务的随机性。

私有随机性生成是 Drand 的次要功能。客户端可以从某些或所有 Drand 节点请求私有随机性，这些 Drand 节点从其熵池中本地提取它并以加密形式发送回去。这对于从不同的熵源（例如在嵌入式设备中）收集随机性可能很有用。

在这种模式下，我们假设客户端具有私钥 / 公钥对，并使用 ECIES （Elliptic Cure Integrated Encryption Scheme，椭圆曲线集成加密 ）加密方案将其公钥封装到服务器的公钥中。收到请求后，Drand 节点会在本地生成 32 个随机字节，并使用接收到的公钥对它们进行加密，然后将其发送回客户端。

在一些设备中，由于没有良好的本地墒源，也就是说其随机性是很难保证的。那么通过这种方式，就能够得到很好随机数。比如很多嵌入式设备或者未经过特殊噪声源设计的设备。但是，必须注意，初始客户端密钥对必须由受信任的源（例如设备Maker）来发布，当密钥对的安全收到影响时，那么其随机数的接收也会大打折扣。

中心化还是去中心化

回头看看文章开头提到的随机源的 5 大目标，Drand 实现了吗？我的结论是基本上，但不是理想的方案。

目前此系统由不同的公司运行，做到了一定程度的去中心化，但不是完全的去中心化，并不是一个非常自有的进出的网络。Drand 在区块链世界还没有被广泛接收的原因可能也在于此。

但从理论上来讲，这些节点之间只要不窜谋，而且能够保障持续运行、稳定输出随机数，相对而言还是安全的。