0x00 困境
链上安全随机数生成应该算是一个比较蛋疼的问题，哪怕你的系统再牛逼，合约程序困在小小的虚拟机里，哪怕天大的本事也施展不开。 更悲催的是，交易执行的时候，是在每一个节点都执行一遍，那就意味着，要想保证同一个交易在所有节点执行结果都一致， 那么交易获取的随机数也就必须一致。目前来看，当交易执行的时候，合约所能获取到的数据无非是
- （1）已有的链上数据。
- （2）通过调用别的合约获取返回值。
- （3）交易传递的参数。
对于第一种数据来源，已有的链上数据都是公开的，随机数获取算法也是公开的，无论怎么搞，通过链上数据获取的随机数结果怎么看都不怎么靠谱， 用户在交易发布之前，稍微分析甚至不需要分析就能猜到自己可能获取到的随机数值范围。
如果通过调用别的合约来获取返回值，这就进入了死循环————别的合约的随机数哪里来的？
最后一种，交易传参，这就更不能用于随机数生成了，本来随机数是要让用户交易执行之前完全不可预测的，现在直接跟用户输入相关的话倒不如直接让用户自己设置自己的随机数来的直接。
0x01 共识前的共识
研究过NEO共识的同学应该都知道，NEO共识协议采用的是dBFT（没研究过的可以看https://my.oschina.net/u/2276921/blog/1621870 ），这种共识协议不需要靠计算量证明，也不需要大家提供股权证明，简直是绿色环保节能减排居家旅行必备的良心共识协议。 仔细看看，这个共识协议有一个很奇怪的特性，就是在真正的对区块进行打包共识之前，有一个产生议长的共识过程， 只有在议长确定之后，才会由议长发起一轮共识。这就意味着，在所有的节点中， 议长节点是第一个对新一个区块中所有的交易进行验证执行的节点。议长之前没有节点执行交易，议长之后大家数据必须跟议长一致，否则就会重新选举议长。放在我们随机数场景里。议长节点执行之前没有随机数，议长节点执行后，所有的节点的随机数必须和议长使用的 随机数一致。那这就很明确了，在新的区块生成之前，随机数不能存在，而新区块生成的开天辟地第一步就是议长节点发起共识。同时，我们也知道，其实议长也确实在新区快生成的时候，本地生成了一个新的随机数---nonce。
0x02 无法使用的最可靠的随机数
然而，现实是，由于交易在虚拟机里执行，像是被困在了一个盒子里，能调用的只有system和runtime几个库提供的少的可怜的接口，而这个nonce随机数更是不在可用资源列表里，所以以上分析基本又成了废话。
0x03 议长的可信问题
在现有的dBFT协议中，议长其实是不需要可信的，因为一个不可信的议长并不会对系统造成任何的干扰，整个系统除了依赖系统发起共识之外，议长并没有什么剩余价值，即便是那个随机数nonce虽然依赖议长生成，但是也并不会对系统安全造成影响。但是如果依赖那个nonce来 最为种子生成随机数，那么就相当于给了议长一定的权力，至少议长就可以干扰随机数的生成了。所以这个系统还是有问题的，那就是议长的可信度。
0x04 共识前的共识前的共识
摆脱议长可信问题的解决方案是，在选举议长的时候增加议员节点间通信，每个议员都广播自己本地生成的随机数，然后把所有议员的随机数进行哈希来产生分布式的随机数，这样就可以不依赖某个几点来产生随机数了。
来源：oschina
链接：https://my.oschina.net/u/2276921/blog/2247708