区块链随机数-区块链随机数的实现方案

区块链随机数的实现方案

区块链随机数的实现方案
参考URL: https://learnblockchain.cn/2019/08/10/rand-on-chain

传统链上随机数的几种办法

• 让可信第三方为合约提供随机数
  第一种是让可信第三方为合约提供随机数，这种情况通常是中心化的解决方案，通过一个可信的 Oracle 来提供独立的随机数源。智能合约发送请求给独立于区块链系统之外的 Oracle，当 Oracle 监听到链上相关请求后，生成随机数并调用回调函数将结果返回区块链。

  这个方案的主要问题式是中心化的解决方案，与基于区块链的分布式精神相悖，另外还有其他的弱点，比如信息在 p2p 网络中传递过程中的延时问题，对于不同等级的应用需求没法提供差异化的服务等。

• 交互式的 commit 和 reveal
  第二种是交互式的 commit 和 reveal。参与过程的多方预先 commit 一个随机数，然后将 hash 递交到区块链上。所有参与方都递交完毕后，各方 reveal 自己的随机数，通过将各自的随机数合并产生一个最终的随机数。这个过程能够保证随机数不被预先知道。但是这个过程有几个问题，第一是需要交互式的多次通讯，自动化实现起来非常困难。第二是如果某方在对自己结果不利的情况下，可以采用不 reveal 自己随机数来延迟随机数的流程。特别是在参与方比较多的情况下，正确处理好网络的延迟和故意的攻击比较困难。

• 采用链上的公开信息
  第三种是采用链上的公开信息，比如使用区块的哈希值/时间戳/难度系数等作为随机数源。一般情况下，应用需要使用将来的某个区块的哈希值以保证在这个区块出来之前，准备操作已经固定且无法修改。这种方式是在实际中被采用最多的方法，但在实现的过程中有很多陷阱。而且，即使实现的过程完美无瑕，还是有个无法克服的漏洞是，产生区块的矿工，可以通过允许范围内的操作，来改变区块的哈希值，使得产生的随机数偏向矿工的选择。最简单的方式，是通过有选择性地打包交易，使得哈希值对自己有利。

• 阈值签名
  第四种是从共识层，通过阈值签名的方式，使得每个共识节点递交各自对某个信息的签名片段，在足够多的签名片段收集到之后，任何一个共识节点都可以将签名片段合并成一个合法的可验证的签名。这个签名可以作为随机数源。
  这个做法的好处是矿工没法对最终的签名进行可操作的修改。对于同一个信息 message，不同的矿工签名组合出来的结果都是一致的。一旦 message 确定，签名也就确定了。Dfinity 采用这个方式作为其共识协议的基础，同时提供可验证的随机数源。但是这里有个问题是在每一轮区块产生的过程中，每个节点需要广播自己的签名片段，这样使得每轮消息的传递是 O(n2)，类似于 PBFT。这个问题会导致共识的节点数量的限制，以及可支撑的应用效率等。

在以太坊生成随机数的几种方式

在以太坊生成随机数的几种方式（含代码）
参考URL: https://learnblockchain.cn/article/1083

请查看参考URL，查看原作者文章。

可以总结为： 链上产生、链下产生，链下产生又分为中心化和去中心化。

参考

在以太坊生成随机数的几种方式（含代码）
参考URL: https://learnblockchain.cn/article/1083
什么是随机？完美的随机性真的存在吗？生成的方法究竟为何？
参考URL: https://www.bilibili.com/video/BV1T64y1c7H5?from=search&seid=5307202221623709917