内容简介：在区块链上，由于一切信息都是透明公开的，提供一个安全实用的随机数是一个非常困难的问题。但是随机数是很多应用的基础，比如游戏，博彩，流程控制等。因此，提供一个实用可靠的随机数是基于智能合约的应用的迫切需求。本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。
在区块链上，由于一切信息都是透明公开的，提供一个安全实用的随机数是一个非常困难的问题。但是随机数是很多应用的基础，比如游戏，博彩，流程控制等。因此，提供一个实用可靠的随机数是基于智能合约的应用的迫切需求。
在区块链上，由于一切信息都是透明公开的，提供一个安全实用的随机数是一个非常困难的问题。但是随机数是很多应用的基础，比如游戏，博彩，流程控制等。因此，提供一个实用可靠的随机数是基于智能合约的应用的迫切需求。
传统的链上随机数
可信第三方为合约提供随机数
这种情况通常是中心化的解决方案，通过一个可信的oracle来提供独立的随机数源。智能合约发送请求给独立于区块链系统之外的Oracle，当Oracle监听到链上相关请求后，生成随机数并调用回调函数将结果返回区块链。
这个方案的主要问题式是中心化的解决方案，与基于区块链的分布式精神相悖，另外还有其他的弱点，比如信息在p2p网络中传递过程中的延时问题，对于不同等级的应用需求没法提供差异化的服务等。
交互式的commit 和reveal。
参与过程的多方预先commit一个随机数，然后将hash递交到区块链上。所有参与方都递交完毕后，各方reveal自己的随机数，通过将各自的随机数合并产生一个最终的随机数。这个过程能够保证随机数不被预先知道。但是这个过程有几个问题，第一是需要交互式的多次通讯，自动化实现起来非常困难。第二是如果某方在对自己结果不利的情况下，可以采用不reveal自己随机数来延迟随机数的流程。特别是在参与方比较多的情况下，正确处理好网络的延迟和故意的攻击比较困难。
采用链上的公开信息
比如使用区块的哈希值/时间戳/难度系数等作为随机数源。一般情况下，应用需要使用将来的某个区块的哈希值以保证在这个区块出来之前，准备操作已经固定且无法修改。这种方式是在实际中被采用最多的方法，但在实现的过程中有很多陷阱。而且，即使实现的过程完美无瑕，还是有个无法克服的漏洞是，产生区块的矿工，可以通过允许范围内的操作，来改变区块的哈希值，使得产生的随机数偏向矿工的选择。最简单的方式，是通过有选择性地打包交易，使得哈希值对自己有利。
从共识层，通过阈值签名的方式
使得每个共识节点递交各自对某个信息的签名片段，在足够多的签名片段收集到之后，任何一个共识节点都可以将签名片段合并成一个合法的可验证的签名。这个签名可以作为随机数源。
这个做法的好处是矿工没法对最终的签名进行可操作的修改。对于同一个信息message，不同的矿工签名组合出来的结果都是一致的。一旦message确定，签名也就确定了。Dfinity采用这个方式作为其共识协议的基础，同时提供可验证的随机数源。但是这里有个问题是在每一轮区块产生的过程中，每个节点需要广播自己的签名片段，这样使得每轮消息的传递是O(n2)，类似于PBFT。这个问题会导致共识的节点数量的限制，以及可支撑的应用效率等。
墨客随机数子链RandDrop
MOAC解决方案
墨客子链采用阈值签名，提出一个O(n)信息复杂度的随机数实现方法。
首先，墨客子链是基于墨客多层结构的layer2区块链实现。子链的矿工是从海量的节点pool中随机选择的一部分来作为某个子链的共识节点。子链的出块顺序由子链的矿工通过Round Robin的方式依次出块。同时，子链会周期性地将子链状态的hash flush到主链上面，实现：
- 状态的finality。
- 剔除已证明的恶意节点。
- 随机retire一小部分节点，随机增加一些新节点。
- 实现子链与母链的跨链操作。
在提供随机数的子链实现中，每个子链的矿工通过VSS初始化操作实现私钥的可验证分发。然后，每个矿工递交一组阈值签名的签名片段，当足够多的签名收集到之后，即可完成阈值签名的合并，矿工可以产生区块，并以此签名作为智能合约的随机数源，处理智能合约中的相关交易。
流程如下：
- 初始化阶段，前每个节点依次产生区块，不需要包括合法的阈值签名。但是每个节点需要在合法的区块中包含当前节点对[ H(b), H(b+1), …, H(b+m-1)]的签名片段，b是当前的区块号。
- 过了m个区块后，正常出块开始，当前节点应该能够收到足够的签名片段(m个)，并合成有效的阈值签名，由此，该节点可以产生一个合法的区块。这个区块中包括收集到的m个签名片段[H1(b), H2(b), …, Hj(b)]，以及合成的阈值签名Sig_thres，交易集{TX}，区块Sig_block，并公布自己的[ H(bi), H(bi+1), …, H(bi+m-1)]的签名片段
- 如果有Byzantine failure，当前节点没有收到足够的签名片段，该节点不产生区块，只广播自己当前的签名片段。
- 第三步可以持续多次up to m次。
- 下一个节点如果收到足够多的签名片段，则可以产生区块，回到步骤。
-
这样，能够保证某个区块的阈值签名是对当前区块号的集合签名。这个签名是可以验证的，但是不能被预先知道，也不可以被矿工的操作修改。而且，这个出块过程中的信息量是O(n)。
另外，当子链的刷新周期到时，子链的节点数量将变化，恶意的节点被剔除，同时有一定几率的新旧节点变化。新节点的VSS过程可以在刷新周期前完成。这样可以保证刷新周期之后，新的一批节点可以马上进入持续的出块过程，使得整个流程不受中断。
此外，墨客子链的实现使得在智能合约中可以直接调用这个阈值签名作为随机数源，来处理应用的逻辑。而且，这个阈值签名是和区块号绑定的，可以大大简化智能合约对相应逻辑的处理。
墨客科技（MOAC BlockChain Tech）已经实现了这个随机数子链，命名为RandDrop （这个是暨ProcWind，FileStorm之后墨客的第三个子链实现）。目前在测试网进行测试。很快可以提供给各游戏和应用厂商进行测试。
总结一下，墨客随机数子链RandDrop的优点：
- 解决了现有智能合约获得可靠的随机数的困境，随机数由子链的共识节点通过阈值签名的方式获得，安全性高。随机数完全不受单个矿工的影响。
- 拜占庭节点的存在可以延迟某个区块的产生，但是不会影响随机数的结果。
- 第一个线性消息复杂度的随机数方案，能够支持更多的共识节点，适用性更强。
- 简化的流程设计，使得智能合约中能够直接调用获得当前区块的随机数。
苗博士提到了，真随机数和假随机数的问题。
我们日常创建账户，赌博游戏验证身份都需要用到随机数。
例如：EOS区块链上的博彩游戏，就是利用EOS的智能合约创造出来的。
只要是人为创造出来的随机数，都会被破解，也就是伪随机数。破解之后，黑客就可以把智能合约上的代币都拿走。
只有自然界通过物理的方式，创造出来的随机数，才是不可能破解，最安全的。
苗博士说他从国内一个实验室买了量子随机数发生器的盒子，2万元，插上电就可以工作。
每分钟可以创造几M的随机数出来，苗博士把端口开放出来，外部可以调用白墨子实验室的随机数。
在区块链上，由于一切信息都是透明公开的，提供一个安全实用的随机数是一个非常困难的问题。但是随机数是很多应用的基础，比如游戏，博彩，流程控制等。因此，提供一个实用可靠的随机数是基于智能合约的应用的迫切需求。
传统的链上随机数
可信第三方为合约提供随机数
这种情况通常是中心化的解决方案，通过一个可信的oracle来提供独立的随机数源。智能合约发送请求给独立于区块链系统之外的Oracle，当Oracle监听到链上相关请求后，生成随机数并调用回调函数将结果返回区块链。
这个方案的主要问题式是中心化的解决方案，与基于区块链的分布式精神相悖，另外还有其他的弱点，比如信息在p2p网络中传递过程中的延时问题，对于不同等级的应用需求没法提供差异化的服务等。
交互式的commit 和reveal。
参与过程的多方预先commit一个随机数，然后将hash递交到区块链上。所有参与方都递交完毕后，各方reveal自己的随机数，通过将各自的随机数合并产生一个最终的随机数。这个过程能够保证随机数不被预先知道。但是这个过程有几个问题，第一是需要交互式的多次通讯，自动化实现起来非常困难。第二是如果某方在对自己结果不利的情况下，可以采用不reveal自己随机数来延迟随机数的流程。特别是在参与方比较多的情况下，正确处理好网络的延迟和故意的攻击比较困难。
采用链上的公开信息
比如使用区块的哈希值/时间戳/难度系数等作为随机数源。一般情况下，应用需要使用将来的某个区块的哈希值以保证在这个区块出来之前，准备操作已经固定且无法修改。这种方式是在实际中被采用最多的方法，但在实现的过程中有很多陷阱。而且，即使实现的过程完美无瑕，还是有个无法克服的漏洞是，产生区块的矿工，可以通过允许范围内的操作，来改变区块的哈希值，使得产生的随机数偏向矿工的选择。最简单的方式，是通过有选择性地打包交易，使得哈希值对自己有利。
从共识层，通过阈值签名的方式
使得每个共识节点递交各自对某个信息的签名片段，在足够多的签名片段收集到之后，任何一个共识节点都可以将签名片段合并成一个合法的可验证的签名。这个签名可以作为随机数源。
这个做法的好处是矿工没法对最终的签名进行可操作的修改。对于同一个信息message，不同的矿工签名组合出来的结果都是一致的。一旦message确定，签名也就确定了。Dfinity采用这个方式作为其共识协议的基础，同时提供可验证的随机数源。但是这里有个问题是在每一轮区块产生的过程中，每个节点需要广播自己的签名片段，这样使得每轮消息的传递是O(n2)，类似于PBFT。这个问题会导致共识的节点数量的限制，以及可支撑的应用效率等。
墨客随机数子链RandDrop
MOAC解决方案
墨客子链采用阈值签名，提出一个O(n)信息复杂度的随机数实现方法。
首先，墨客子链是基于墨客多层结构的layer2区块链实现。子链的矿工是从海量的节点pool中随机选择的一部分来作为某个子链的共识节点。子链的出块顺序由子链的矿工通过Round Robin的方式依次出块。同时，子链会周期性地将子链状态的hash flush到主链上面，实现：
- 状态的finality。
- 剔除已证明的恶意节点。
- 随机retire一小部分节点，随机增加一些新节点。
- 实现子链与母链的跨链操作。
在提供随机数的子链实现中，每个子链的矿工通过VSS初始化操作实现私钥的可验证分发。然后，每个矿工递交一组阈值签名的签名片段，当足够多的签名收集到之后，即可完成阈值签名的合并，矿工可以产生区块，并以此签名作为智能合约的随机数源，处理智能合约中的相关交易。
流程如下：
- 初始化阶段，前每个节点依次产生区块，不需要包括合法的阈值签名。但是每个节点需要在合法的区块中包含当前节点对[ H(b), H(b+1), …, H(b+m-1)]的签名片段，b是当前的区块号。
- 过了m个区块后，正常出块开始，当前节点应该能够收到足够的签名片段(m个)，并合成有效的阈值签名，由此，该节点可以产生一个合法的区块。这个区块中包括收集到的m个签名片段[H1(b), H2(b), …, Hj(b)]，以及合成的阈值签名Sig_thres，交易集{TX}，区块Sig_block，并公布自己的[ H(bi), H(bi+1), …, H(bi+m-1)]的签名片段
- 如果有Byzantine failure，当前节点没有收到足够的签名片段，该节点不产生区块，只广播自己当前的签名片段。
- 第三步可以持续多次up to m次。
- 下一个节点如果收到足够多的签名片段，则可以产生区块，回到步骤。
-
这样，能够保证某个区块的阈值签名是对当前区块号的集合签名。这个签名是可以验证的，但是不能被预先知道，也不可以被矿工的操作修改。而且，这个出块过程中的信息量是O(n)。
另外，当子链的刷新周期到时，子链的节点数量将变化，恶意的节点被剔除，同时有一定几率的新旧节点变化。新节点的VSS过程可以在刷新周期前完成。这样可以保证刷新周期之后，新的一批节点可以马上进入持续的出块过程，使得整个流程不受中断。
此外，墨客子链的实现使得在智能合约中可以直接调用这个阈值签名作为随机数源，来处理应用的逻辑。而且，这个阈值签名是和区块号绑定的，可以大大简化智能合约对相应逻辑的处理。
墨客科技（MOAC BlockChain Tech）已经实现了这个随机数子链，命名为RandDrop （这个是暨ProcWind，FileStorm之后墨客的第三个子链实现）。目前在测试网进行测试。很快可以提供给各游戏和应用厂商进行测试。
总结一下，墨客随机数子链RandDrop的优点：
- 解决了现有智能合约获得可靠的随机数的困境，随机数由子链的共识节点通过阈值签名的方式获得，安全性高。随机数完全不受单个矿工的影响。
- 拜占庭节点的存在可以延迟某个区块的产生，但是不会影响随机数的结果。
- 第一个线性消息复杂度的随机数方案，能够支持更多的共识节点，适用性更强。
- 简化的流程设计，使得智能合约中能够直接调用获得当前区块的随机数。
苗博士提到了，真随机数和假随机数的问题。
我们日常创建账户，赌博游戏验证身份都需要用到随机数。
例如：EOS区块链上的博彩游戏，就是利用EOS的智能合约创造出来的。
只要是人为创造出来的随机数，都会被破解，也就是伪随机数。破解之后，黑客就可以把智能合约上的代币都拿走。
只有自然界通过物理的方式，创造出来的随机数，才是不可能破解，最安全的。
苗博士说他从国内一个实验室买了量子随机数发生器的盒子，2万元，插上电就可以工作。
每分钟可以创造几M的随机数出来，苗博士把端口开放出来，外部可以调用白墨子实验室的随机数。
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。
- 发表于 12分钟前
- 阅读 ( 3 )
- 学分 ( 0 )
- 分类：MOAC
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
构建高可用Linux服务器
余洪春 / 机械工业出版社华章公司 / 2011-11-1 / 79.00元
资深Linux/Unix系统管理专家兼架构师多年一线工作经验结晶，51CTO和ChinaUnix等知名社区联袂推荐。结合实际生产环境，从Linux虚拟化、集群、服务器故障诊断与排除、系统安全性等多角度阐述构建高可用Linux服务器的最佳实践。本书实践性非常强，包含大量企业级的应用案例及相应的解决方案，读者可以直接用这些方案解决在实际工作中遇到的问题。 全书一共10章。第1章以作者的项目实践为......一起来看看 《构建高可用Linux服务器》 这本书的介绍吧!
