一个可能的NEO链上安全随机数解决方案

0x00 困境

链上安全随机数生成应该算是一个比较蛋疼的问题，哪怕你的系统再牛逼，合约程序困在小小的虚拟机里，哪怕天大的本事也施展不开。 更悲催的是，交易执行的时候，是在每个节点都执行一遍，那就意味着，要想保证同一个交易在全部节点执行结果都一致， 那么交易获取的随机数也就必须一致。目前来看，当交易执行的时候，合约所能获取到的数据无非是

• （1）已有的链上数据。
• （2）经过调用别的合约获取返回值。
• （3）交易传递的参数。

对于第一种数据来源，已有的链上数据都是公开的，随机数获取算法也是公开的，不管怎么搞，经过链上数据获取的随机数结果怎么看都不怎么靠谱， 用户在交易发布以前，稍微分析甚至不须要分析就能猜到本身可能获取到的随机数值范围。

若是经过调用别的合约来获取返回值，这就进入了死循环————别的合约的随机数哪里来的？

最后一种，交易传参，这就更不能用于随机数生成了，原本随机数是要让用户交易执行以前彻底不可预测的，如今直接跟用户输入相关的话倒不如直接让用户本身设置本身的随机数来的直接。

0x01 共识前的共识

研究过NEO共识的同窗应该都知道，NEO共识协议采用的是dBFT（没研究过的能够看http://www.javashuo.com/article/p-kdcfdtqu-kg.html ），这种共识协议不须要靠计算量证实，也不须要你们提供股权证实，简直是绿色环保节能减排居家旅行必备的良心共识协议。 仔细看看，这个共识协议有一个很奇怪的特性，就是在真正的对区块进行打包共识以前，有一个产生议长的共识过程， 只有在议长肯定以后，才会由议长发起一轮共识。这就意味着，在全部的节点中， 议长节点是第一个对新一个区块中全部的交易进行验证执行的节点。议长以前没有节点执行交易，议长以后你们数据必须跟议长一致，不然就会从新选举议长。放在咱们随机数场景里。议长节点执行以前没有随机数，议长节点执行后，全部的节点的随机数必须和议长使用的 随机数一致。那这就很明确了，在新的区块生成以前，随机数不能存在，而新区块生成的开天辟地第一步就是议长节点发起共识。同时，咱们也知道，其实议长也确实在新区快生成的时候，本地生成了一个新的随机数---nonce。

0x02 没法使用的最可靠的随机数

然而，现实是，因为交易在虚拟机里执行，像是被困在了一个盒子里，能调用的只有system和runtime几个库提供的少的可怜的接口，而这个nonce随机数更是不在可用资源列表里，因此以上分析基本又成了废话。

0x03 议长的可信问题

在现有的dBFT协议中，议长实际上是不须要可信的，由于一个不可信的议长并不会对系统形成任何的干扰，整个系统除了依赖系统发起共识以外，议长并无什么剩余价值，即使是那个随机数nonce虽然依赖议长生成，可是也并不会对系统安全形成影响。可是若是依赖那个nonce来 最为种子生成随机数，那么就至关于给了议长必定的权力，至少议长就能够干扰随机数的生成了。因此这个系统仍是有问题的，那就是议长的可信度。

0x04 共识前的共识前的共识

摆脱议长可信问题的解决方案是，在选举议长的时候增长议员节点间通讯，每一个议员都广播本身本地生成的随机数，而后把全部议员的随机数进行哈希来产生分布式的随机数，这样就能够不依赖某个几点来产生随机数了。