上⼀篇文章《Neo 智能合约如何保证随机数安全性？》，我们讨论了随机数生成的执行过程。简单来说就是把打包交易的权利交给议⻓，把⽣成随机数的权利分别赋予给两位议员。

– 后⽂⽤ N1 和 N2 指⽣成随机数的两位议员；

– R1 和 R2 指两位议员最终发给议⻓的包含随机数的交易

负责⽣成随机数的议员 N1 和 N2 ⽆法提前知道最终的随机数，负责打包的议⻓⽆法更改随机数的值，如此三⽅共同协作是为了在每⼀个区块里⽣成安全可信的随机数。

随机数⽣成的算法模型

接下来我们对这个随机数⽣成的算法模型进⾏分析完善。

⾸先考虑到 N1 和 N2 发出的交易都是公开的，因此 如果 N1 是恶意的，那么它可以故意等到接收到 N2 的随机数 R1 之后再依据 R1 的值来推断并⽣成对⾃⼰最有利的那个随机数 R2。

这⾥稍微提⼀下为什么 N2 依然可以对⽣成的随机数进⾏选择，因为我们考虑 2/3 多数的共识原则，因此 N2 是可能收到超过 2/3 来⾃别的议员的随机数的，因此 N2 就可以在这些收到的随机数⾥⾃由选择。⽐如我们有 7 个议员，那 N2 如果只收到5个议员的随机数，那当然就只有⼀种组合⽅案，但是如果 N2 收到了 6 个议员的随机数，那么它就可以在 6 个⾥⾯选出 5 个，于是就有了总共 6 种可能供 N2 选择；同理，如果 N2 收到了所有 7 个议员的随机数，那 N2 就有了 50 种选择，在这么多的选择⾥，N2 完全可以选出⼀个对⾃⼰有利的最终⽅案。

要避免这种问题，我们需要保证在议⻓⽣成最终随机数之前，两位议员⽆法提前知道随机数。这似乎是在绕圈⼦，但解决这个问题其实相对简单，我们可以让 N1 和 N2 ⽤议⻓的公钥对 R1 和 R2 进⾏加密，如此就可以在议⻓⼴播新区快议案之前，只有议⻓可以同时知道 R1 和 R2 。

与此同时，为了让议⻓⽣成的最终随机数可验证并且简化流程，N1 和 N2 在加密 R1 和 R2 的时候还应该加上对 R1 和 R2 的签名。如此，在议⻓公开解密后的 R1 和 R2 时，别的议员就可以在不与 N1 和 N2 做额外通信的情况下来验证 R1 和 R2 以及最终随机数的真实性。

现在我们再讨论假如 N1 是个傻⼦，它就想把 R1 的明⽂公布出来，因此 N2 就可以提前获取 R1 的值并加以利⽤以实现⾃⼰利益的最⼤化，这⾥我们分为两种情况来讨论：

N2 是诚实节点

它哪怕收到了 R1 也不会做任何的事情，所以即使 N1 是个傻⼦，对系统也不会造成任何影响，毕竟仅仅知道 R1 是无法推断出最终随机数的。此外我们还可以设置⿊名单，对故意提前泄漏随机数的议员 N1 进⾏惩罚进⽽提⾼系统的鲁棒性。

N2 是恶意节点

这个就⽐较⿇烦了，毕竟 Neo 的共识算法是只需要超过 2/3 的节点是正常的即可，所以议员⾥出现两个反动派是正常的，但是对于随机数⽣成来说就有点要命。索性我们假设选择 N1 和 N2 的过程也是随机的，那么在⼀个不超过 1/3 的议员是恶意的情况下，对⼀个区块来说，N1 和 N2 都是恶意的概率在 5% 左右，不过随着议员数量的提升，这个概率会随之增⼤，但是最⾼不超过 11%。

以上，虽然⽅案依然存在一定被攻击的可能，但是相对于单纯的让单独节点来⽣成随机数还是更安全的⼀种解决⽅案。

通过两篇关于安全随机数的文章，希望大家可以更深入地了解为了保证系统环境的安全运行，研究员们对于整个执行机制、算法模型所做的尝试与验证。

区块链要走的路还很长，咱们一道见证。