内容简介:区块链的安全保障之一来自于各种的不可预测性,比如私钥、出块权、挑战种子等等。Filecoin在最初的设计中采用 Ticket Chain 来产生不可预测但可公开验证的随机数。目前改为利用Drand来作为随机数源。Drand是一个独立的项目,本文对其简单做一个介绍。类似于以太坊2.0实行的信标链(Beacon Chain),Filecoin目前采用Drand作为其Beacon源,而启用最初设计的 Ticket 链。我们知道,Ticket Chain实际上是一个逻辑链,是寄生在Filecoin 链之上的。尽管
区块链的安全保障之一来自于各种的不可预测性,比如私钥、出块权、挑战种子等等。Filecoin在最初的设计中采用 Ticket Chain 来产生不可预测但可公开验证的随机数。目前改为利用Drand来作为随机数源。Drand是一个独立的项目,本文对其简单做一个介绍。
类似于以太坊2.0实行的信标链(Beacon Chain),Filecoin目前采用Drand作为其Beacon源,而启用最初设计的 Ticket 链。我们知道,Ticket Chain实际上是一个逻辑链,是寄生在Filecoin 链之上的。尽管 Ticket 链进行了很好的设计,但是仍然有其不令人满意的地方,比如说:1)其Ticket是每个区块都有的,但是每个高度仅需要一个,所以这里带来一个选择问题,但这个问题不大;另外,2Ticket 本身并不是对所有人来说都是不可预测的,因为 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-Lynn-Shacham(BLS)签名方案的n个阈值版本及其各自的私钥因子进行签名。一旦任何节点(或第三方观察者)收集了t个部分签名,它就可以重建完整的BLS签名(使用拉格朗日插值)。然后使用SHA-512对签名进行哈希处理,以确保最终输出的字节表示形式没有偏差。该散列对应于集合随机值,并且可以针对集合公钥进行验证。
私有随机性
私有随机性,也就是为节点本地服务的随机性。
私有随机性生成是Drand的次要功能。客户端可以从某些或所有Drand节点请求私有随机性,这些Drand节点从其熵池中本地提取它并以加密形式发送回去。这对于从不同的熵源(例如在嵌入式设备中)收集随机性可能很有用。
在这种模式下,我们假设客户端具有私钥/公钥对,并使用ECIES(Elliptic Curve Integrated Encryption Scheme,椭圆曲线集成加密 )加密方案将其公钥封装到服务器的公钥中。收到请求后,Drand节点会在本地生成32个随机字节,并使用接收到的公钥对它们进行加密,然后将其发送回客户端。
在一些设备中,由于没有良好的本地墒源,也就是说其随机性是很难保证的。那么通过这种方式,就能够得到很好随机数。比如很多嵌入式设备或者未经过特殊噪声源设计的设备。但是,必须注意,初始客户端密钥对必须由受信任的源(例如设备制造商)来发布,当密钥对的安全收到影响时,那么其随机数的接收也会大打折扣。
中心化还是去中心化
回头看看文章开头提到的随机源的5大目标,Drand实现了吗?我的结论是基本上,但不是理想的方案。
目前此系统由不同的公司运行,做到了一定程度的去中心化,但不是完全的去中心化,并不是一个非常自有的进出的网络。Drand在区块链世界还没有被广泛接收的原因可能也在于此。
但从理论上来讲,这些节点之间只要不窜谋,而且能够保障持续运行、稳定输出随机数,相对而言还是安全的。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 你了解HTTPS,但你可能不了解X.509
- 你真的了解Mybatis的${}和#{}吗?是否了解应用场景?
- 你所了解的 array_diff_uassoc 真的是你了解的那样吗?
- 图文了解 Kubernetes
- 深入了解 JSONP
- 一文了解 Kubernetes
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。