一种区块链上实现分布式密钥生成的方法、系统和节点

技术领域

本说明书实施例属于区块链技术领域，尤其涉及一种区块链上实现分布式密钥生成的方法、系统和节点。

背景技术

区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。

发明内容

本发明的目的在于提供一种区块链上实现分布式密钥生成的方法、系统和区块链节点，包括：

第一方面提供一种区块链上实现分布式密钥生成的方法，所述区块链包括若干个节点，所述方法包括：

每一节点生成n个秘密份额和与所述n个秘密份额对应的公共验证参数，自身保留一份秘密份额；

每一节点生成第一交易，所述第一交易调用合约，包括其生成的n个秘密份额中的n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数，所述n-1个秘密份额的密文通过使用其他n-1个节点的公钥分别加密而生成；

每一节点将其生成的所述第一交易发送到区块链中，以通过所述合约将所述n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数存储到所述区块链中；

每一节点对从区块链获取的与该节点对应的秘密份额和与该秘密份额对应的公共验证参数进行验证；

每一节点在每一验证通过后，通过向区块链发送调用所述合约的交易，将通过验证的节点编号发送至所述合约；

每一节点各自基于验证参数及由所述合约确定的节点集合计算公钥份额，并基于本地的秘密份额和节点集合计算自身对应的私钥份额，其中，所述节点集合由所述合约根据各节点发来的节点编号确定。

第二方面提供一种区块链上实现分布式密钥生成的方法，所述区块链包括若干个节点，所述方法由第一节点执行，包括：

生成n个秘密份额和与所述n个秘密份额对应的公共验证参数，自身保留一份秘密份额；

生成第一交易，所述第一交易调用合约，包括其生成的n个秘密份额中的n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数，所述n-1个秘密份额的密文通过使用其他n-1个节点的公钥分别加密而生成；

将所述第一交易发送到区块链中，以通过所述合约将所述n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数存储到所述区块链中；

从区块链中获取其它节点生成与所述第一节点对应的秘密份额、和与该秘密份额对应的公共验证参数；

对获取的每一秘密份额和对应的公共验证参数进行验证；

在每一验证通过后，将通过验证的节点编号发送至所述合约；

接收所述合约确定的节点集合，其中，所述节点集合由所述合约根据各节点发来的节点编号确定；

基于验证参数及节点集合计算公钥份额，并基于本地的秘密份额和节点集合计算自身的私钥份额。

第三方面提供一种区块链系统，包括若干个节点，其中：

每一节点用于生成n个秘密份额和与所述n个秘密份额对应的公共验证参数，自身保留一份秘密份额；

每一节点用于生成第一交易，所述第一交易调用合约，包括其生成的n个秘密份额中的n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数，所述n-1个秘密份额的密文通过使用其他n-1个节点的公钥分别加密而生成；

每一节点用于将其生成的所述第一交易发送到区块链中，以通过所述合约将所述n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数存储到所述区块链中；

每一节点用于对从区块链获取的与该节点对应的秘密份额和与该秘密份额对应的公共验证参数进行验证；

每一节点用于在每一验证通过后，通过向区块链发送调用所述合约的交易，将通过验证的节点编号发送至所述合约；

每一节点用于各自基于验证参数及由所述合约确定的节点集合计算公钥份额，并基于本地的秘密份额和节点集合计算自身对应的私钥份额，其中，所述节点集合由所述合约根据各节点发来的节点编号确定。

第四方面提供一种区块链系统中的第一节点，包括：

生成单元，用于生成n个秘密份额和与所述n个秘密份额对应的公共验证参数，自身保留一份秘密份额；生成第一交易，所述第一交易调用合约，包括其生成的n个秘密份额中的n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数，所述n-1个秘密份额的密文通过使用其他n-1个节点的公钥分别加密而生成；

发送单元，用于将其生成的所述第一交易发送到区块链中，以通过所述合约将所述n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数存储到所述区块链中；

获取单元，用于从区块链中获取其它节点生成与所述第一节点对应的秘密份额、和与该秘密份额对应的公共验证参数；

验证单元，用于对接收到的每一秘密份额和对应的公共验证参数进行验证；

所述发送单元还用于，在对每一验证通过后，将通过验证的节点编号发送至所述合约；

接收单元，用于接收所述合约确定的节点集合，其中，所述节点集合由所述合约根据各节点发来的节点编号确定；

计算单元，用于基于验证参数及节点集合计算公钥份额，并基于所述秘密份额和节点集合计算自身对应的私钥份额。

第五方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第二方面所述的方法。

第六方面提供一种区块链节点，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第二方面所述的方法。

本申请提供的上述方案，在共识机制保障区块链网络整体一致性和同步的基础上，结合区块链智能合约实现分布式密钥生成，保障了分布式密钥的生成一方面是由各个参与方通过协作来生成的，另一方面生成的结果是一致和可靠的，从而摆脱了原有的区块链之外实现分布式密钥生成对网络同步的强依赖，并解决了该情况下生成结果的不可靠性问题。

附图说明

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是一实施例中实用拜占庭容错算法常规阶段的示意图；

图2是一实施例中实用拜占庭容错算法视图切换阶段的示意图；

图3是一实施例中共识节点都没有宕机情况下实用拜占庭容错算法常规阶段的示意图；

图4是本说明书一实施例中区块链上产生随机数种子的流程图；

图5是本说明书一实施例中区块头结构的示意图；

图6是本说明书一实施例中区块链上实现分布式密钥生成的方法；

图7是本说明书一实施例中区块链上实现分布式密钥生成的方法；

图8是本说明书一实施例中的区块链节点的架构图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

区块链1.0时代通常是指在2009年到2014年之间，以比特币为代表的区块链应用发展阶段，它们主要致力于解决货币和支付手段的去中心化问题。从2014年开始，开发者们越来越注重于解决比特币在技术和扩展性方面的不足。2013年底，Vitalik Buterin发布了以太坊(Ethereum)白皮书《以太坊：下一代智能合约和去中心化应用平台》，将智能合约引入区块链，打开了区块链在货币领域以外的应用，从而开启了区块链2.0时代。

区块链系统中，不同参与方通过部署的节点(Node)可以建立一个分布式的区块链网络。利用链式区块结构构造的去中心化(或称为多中心化)的分布式账本，保存于分布式的区块链网络中的每个节点(或大多节点上，如共识节点)上。这样的区块链系统需要解决去中心化(或多中心化)的多个节点上各自的账本数据的一致性和正确性的问题。每个节点(或多个节点)上都运行着区块链程序，在一定容错需求的设计下，通过共识(consensus)机制保证所有忠诚节点具有相同的交易，从而保证所有忠诚节点对相同交易的执行结果一致，并将交易及执行结果打包生成区块。

智能合约是一种基于规定触发规则的，可自动执行的计算机合约，也可以看作是传统合约的数字版本。智能合约这一概念最早由跨领域法律学者、密码学研究工作者尼克·萨博(Nick Szabo)在1994年提出。这项技术曾一度因为缺乏可编程数字系统和相关技术而没有被用于实际产业中，直到区块链技术和以太坊的出现为其提供了可靠的执行环境。由于区块链技术采用块链式账本，产生的数据不可篡改或者删除，且整个账本将不断新增账本数据，从而保证了历史数据的可追溯；同时，去中心化的运行机制避免了中心化因素的影响。基于区块链技术的智能合约不仅可以发挥智能合约在成本、效率方面的优势，而且可以避免恶意行为对合约正常执行的干扰。将智能合约以数字化的形式写入区块链中，由区块链技术的特性保障存储、读取、执行整个过程透明可跟踪、不可篡改。

区块链发展及应用多样化。一些业务逻辑被编辑为智能合约并在区块链平台上执行。具体的，这些包含业务逻辑的智能合约可以运行于区块链网络中的每个节点(或大多节点上，如共识节点)上。相对于中心化的业务逻辑执行环境所带来的单点故障导致整个中心化系统不可用的问题，区块链环境中执行智能合约也被称为“世界计算机”，这是因为分布式的区块链网络中有较多节点各自独立执行智能合约。如前所述，这些不同节点上执行相同逻辑的智能合约，需要获得相同的执行结果，从而保证这些节点中的多数保存的账本是一致的。

一些业务逻辑中，可能需要基于随机数产生一个结果，例如实现摇号的业务逻辑，或者实现一定范围内随机金额发红包或盲盒等的业务逻辑，这一般需要在智能合约中包含产生随机数的程序。再例如，一些系统合约中，可能需要实现对主节点的投票或对小规模委员会的投票，这个投票逻辑中可能采用随机的方式或者是用到随机数。如前所述，分布式的区块链网络中有一个显著特点，是为了保证分布式的区块链网络整体可用而需要多数节点中的账本是一致的，这也就需要多数节点中的智能合约产生的随机数是一致的。

前述提到，每个节点(或多个节点)上都运行着区块链程序，在一定容错需求的设计下，通过共识机制保证所有忠诚节点具有相同的交易，从而保证所有忠诚节点对相同交易的执行结果一致，并将交易及执行结果打包生成区块。当前主流的共识机制包括：工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(DelegatedProof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法，蜜獾拜占庭容错(HoneyBadgerBFT)算法等。

以PBFT为例，该算法是Miguel Castro(卡斯特罗)和Barbara Liskov(利斯科夫)在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。该论文发表在1999年的操作系统设计与实现国际会议上(OSDI99)。PBFT算法中，所有的副本(replica)在一个被称为视图(View)的轮换过程(succession of configuration)中运行。在某个视图中，一个副本作为主节点(primary)，其他的副本作为备份节点(backups)。视图是连续编号的整数。主节点可以由公式p＝v mod|R|计算得到，这里v是视图编号，p是副本编号，|R|是副本集合的个数。该算法中假设，当最多存在f个副本(即节点)失效时，如果存在总数为至少3f+1个副本，就能保证在异步系统中提供安全性和活性。为了能够确保所有副本的数据一致性要求和容错要求而需要的一定数量副本的集合，一般是分布式系统中的大多数节点构成的集合，构成大多数(Quorum)。例如在总节点数n为3f+1(n＝3f+2或n＝3f的情况一般不会对容错效果带来提升)的情况下，Quorum为2f+1。这样，对于包含四个节点的分布式系统，任意三个节点可以构成一个Quorum。

PBFT包括Normal Case Phase和View Change Phase两个过程，图1为Normal CasePhase(常规阶段)过程的流程图。Normal Case Phase中主要包括PRE-PREPARE(预准备)、PREPARE(准备)和COMMIT(提交)三个阶段，其中3号节点例如可以表示宕机的节点(图1中以×表示)。当主节点失效的时候(图2中以×表示，如更换视图前主节点Primary也就是Replica 0(副本0)失效)就需要启动视图更换(view change)过程，从而在系统存在故障时进行调整，更换新的主节点(如更换视图后Replica 1为主节点Primary)。图2为ViewChange Phase(视图切换)的示意图。如果主节点掉线或者作恶而不广播客户端的请求等，客户端可以设置超时机制。如果超时的话，客户端可以向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线后，也可以发起View Change协议阶段，以更换主节点(经常简称为“换主”)。此外，也可能由于主节点发起错误的提议导致PRE-PREPARE、PREPARE和COMMIT三阶段共识过程失败，或者，PREPARE、COMMIT阶段可能达不成Quorum数量(如3f+1个节点中的2f+1个，也称为法定数量)的一致，也都无法完成共识。这些情况下也可能发起View Change协议阶段，以更换主节点。

在正常情况下，即共识节点都没有宕机，共识消息也能在一定时间内到达对方，即不会发生换主的情况下，PBFT中的Normal Case Phase过程可以如图3所示，该图仍然以4个共识节点为例。

在第r-1轮的Normal Case Phase过程，0号节点作为主节点收集一定数量的待共识交易(或读写集之类，后续以交易为例作说明)后，发起预准备过程(即前述的PRE-PREPARE，也简称为PP阶段)，进而节点1、2、3进入准备过程(即前述的PREPARE，也简称为P阶段)，之后节点0、1、2、3进入提交过程(即前述的COMMIT，也简称为C阶段)。PP阶段、P阶段、C阶段一般也合称为PBFT的三阶段。这样，在正常情况下就完成了第r-1轮PBFT的三阶段过程，也就完成了第m-1个区块对应的交易数据的共识，同时也产生了这个区块的区块号等信息。从而，各个共识节点可以各自以共识的交易数据为基础，按照共识的交易数据的顺序和内容，顺序执行这些交易，进而生成世界状态和收据。具体的，各个节点各自在本地基于共识的交易数据可以构建Merkle树(包括MPT树等树形结构，MPT全称为Merkle PatriciaTree，是结合了Merkle Tree(默克尔树)和Patricia Tree(压缩前缀树，一种更节省空间的Trie树，字典树)的一种树形结构)并生成这颗Merkle树的树根的hash(也称为交易根hash)，类似的，可以基于世界状态数据构建Merkle树并生成这颗Merkle树的树根的hash(也称为状态根hash)，可以基于收据数据构建Merkle树并生成这颗Merkle树的树根的hash(也称为收据根hash)。各个节点各自在本地生成这三个根hash后，可以在本地生成第m-1个区块。该第m-1个区块的区块头中可以包括前述区块号、交易根hash、状态根hash、收据根hash等信息，区块体可以包括交易数据集合、世界状态集合和收据集合。这样，就生成了第m-1个区块。

在第m个区块的生成过程中，将重复PBFT中的三阶段过程。如图3中，对于第m个区块，0号节点作为主节点收集一定数量的待共识交易后，发起PP过程，进而节点1、2、3进入P过程，之后节点0、1、2、3进入C过程。这样，在正常情况下就完成了第r轮PBFT的三阶段过程，也就完成了第m个区块对应的交易数据的共识，同时也产生了这个区块的区块号等信息。各个节点可以各自以共识的交易数据为基础，按照共识的交易数据的顺序和内容，顺序执行这些交易，进而生成世界状态和收据。各个节点各自在本地生成如前所述的三个根hash后，可以在本地生成第m个区块。该第m个区块的区块头中可以包括前述区块号、交易根hash、状态根hash、收据根hash等信息，区块体可以包括交易数据集合、世界状态集合和收据集合。这样，就生成了第m个区块。类似的，生成第m+1个区块，在这个过程中包含如图3中所示的第r+1轮PBFT的三阶段过程。

可见，常规产生区块的情况下，每个共识节点在每个区块的产生过程中包含一次PBFT的Normal Case Phase过程。随着区块的不断产生，每个共识节点将会重复这个共识过程，图3中仅示例性的示出了第r-1、r和r+1轮共识过程。其中，有的共识节点作为PBFT中的主节点的角色，有的共识节点作为PBFT中的备份节点的角色。

在一次共识过程中，即一次PBFT的三阶段过程中，可以包括：

a110：(PRE-PREPARE预准备阶段)主节点0收集一定数量的待共识交易后，将待共识交易排序并打包为消息m(也称为原始交易列表)，发送pre-prepare请求至备份节点1、2、3，pre-prepare请求中包括原始交易列表；

a120：(PREPARE准备阶段)节点1、2、3收到pre-prepare请求后，如果检查原始交易列表合法，则分别通过prepare消息广播其收到的消息m的hash值(广播的内容一般不包括消息m本身，因为消息m包括了若干个原始交易请求，体积一般比较大)。具体的，节点1将prepare消息扩散至节点0、2、3，节点2将prepare消息扩散至节点0、1、3，节点3将prepare消息扩散至节点0、1、2。相应的，每一节点还接收其他节点广播的prepare消息。每一节点将自己发送的prepare消息(其中包含消息m的hash值，代表自己的认可)和收到的prepare消息(其中包含消息m的hash值，代表其它节点的认可)都添加到本地日志(Log)中。如果某一节点收集齐来自不同节点的至少Quorum个数量的合法的pp消息/p消息后(包括自身发出的pre-prepare、prepare消息，和收到的prepare消息)，转变成prepared状态。

a130：(COMMIT提交阶段)参与共识的节点中的每一个在进入prepared状态后，发送commit消息给其他的共识节点，并将自己发送的commit消息添加到本地Log中(代表自己的认可)，而且，每一节点还接收其他节点广播的commit消息。某一节点如果收集齐来自不同节点的至少Quorum数量的合法的commit消息后，添加到本地Log中(这时加上自己添加到本地Log中的共有Quorum个)，转变成committed状态。

a140：转变为committed状态的节点将消息m输出为本轮的共识结果。

消息m中包含哪些交易，以及所包含的交易的前后顺序，一般是由主节点在a110中决定的。确定包含哪些交易，包含的交易的前后顺序，这两个是共识机制的重要内容。区块链网络中可能接收到很多交易请求，a110中主节点打包哪些交易，决定了哪些交易会被区块链网络处理，交易的执行结果会上链。即使一组相同的交易，前后执行顺序不同会导致最终结果不同，而这影响到各个节点上的账本是否一致。

本申请提供一种区块链上产生随机数种子的方法，可以结合上述PBFT三阶段的过程实现。如图4所示，包括：

S110：在PBFT的commit阶段，每一共识节点基于门限签名算法，采用自身私钥份额对包含本次共识中原始交易列表特有值的原始报文进行签名，生成签名份额，并将该签名份额加入到广播的commit消息中。

门限签名是普通数字签名的一个重要分支，是门限秘密共享技术和数字签名的一种结合。传统的签名方案，可以采用RSA算法实现。RSA算法是一种非对称加密算法，由罗纳德·李维斯特(Ron Rivest)、阿迪·萨莫尔(Adi Shamir)和伦纳德·阿德曼(LeonardAdleman)于1977年一起提出。RSA算法可以在不直接传递密钥的情况下完成解密，这能够确保信息的安全性的同时，避免直接传递密钥所造成的信息被破解的风险。RSA中包括私钥和公钥，这个私钥和公钥是成对。一个信息由公钥加密后，只能由对应的私钥解密；类似的，一个信息由私钥加密后，只能由对应的公钥解密。之所以具有这样的性质，是因为成对的私钥和公钥之间在数学原理上具有相关性，例如一种底层原理是根据数论，寻求两个大素数比较简单，而将它们的乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥，从而可以保证安全性。私钥通常要严格保密，不能泄露，而公钥是公开的(且可以由多人持有)。由于私钥是由持有者严格保密的，其他人在无法获得私钥的前提下，就无法伪造私钥持有者的签名。

RSA签名机制，可以保证报文传递过程中的完整性。例如节点A需要将报文传送至节点B，且中间可能经过若干个节点的中转。则A可以采用RSA签名机制，将报文连同签名一并经由若干个中间节点传送至B，而B对签名的验证可以确信收到的报文是A发出的，且在传送过程中没有经过篡改。一种RSA签名的过程如下：

b1：A生成一对密钥(公钥和私钥)，私钥不公开，自己保留。公钥为公开的，任何人可以获取。

b2：A用自己的私钥对原始报文的hash值进行签名，并将原始报文和签名结果一并传递给B。如前所述，这个传递过程可能经过若干个中间节点的转发。

hash算法也称为散列算法，可以将原始内容映射为一个固定长度的序列，这个序列即为hash值。一般有sha256，sha384，sha512等hash算法。sha256的结果是256个bits，可以表示2的256次方个原始内容。类似的，sha384的结果是384bits，sha512的结果是512bits。这些hash算法，可以针对内容较多体积较大的原始内容，因而hash值相对来说可以比原始内容小很多。好的hash算法可以确保不同原始内容有极大概率映射为不同的hash值，同时这种映射是杂乱无章的，即无法预测不同的原始内容得到的hash值的关联性；而且也是抗逆运算的，即无法由hash值倒推得到原始内容。

原始报文可能内容较多，体积较大，采用私钥直接对原始报文进行签名计算可能比较费时和耗费算力。因此，可以将原始报文采用一种hash算法计算到一个hash值，这样这个hash值长度较小，又可以完全代表原始报文。进而，采用私钥对这个hash值进行加密计算，得到的结果即为签名。

b3：B收到消息后，采用A的公钥进行验签。

一方面，B可以采用与A相同的hash算法来计算原始报文的hash值，计为hash1；另一方面，B采用A的公钥对签名结果进行解密计算，得到hash2。如果hash1与hash2相同，则可以确定收到的原始报文是A发出的，且在传送过程中没有被篡改过。

门限签名方案，首先是包括1个总公钥和n个公私钥对。每个公私钥对中的1个公钥称为公钥份额，每个公私钥对中的1个私钥称为私钥份额。其次，存在与这个总公钥和n个公私钥对对应的恢复函数，该恢复函数可以将至少门限数量个不同私钥份额签名的签名份额恢复成一个完整签名，这个生成的完整签名也可以由所述的那1个总公钥来验证正确性。而任意少于门限数量的签名份额则无法恢复生成该完整签名。

除了可以采用基于RSA的门限签名机制外，还可以采用基于ECDSA((EllipticCurve Digital Signature Algorithm，椭圆曲线数字签名算法)的门限签名机制、基于Schnorr(一种基于离散对数难题的知识证明机制)的门限签名机制、基于BLS(Boneh-Lynn-Shacham Signature)的门限签名机制等。

需要说明的是，在区块链中所采用的门限签名，私钥份额的个数可以等于共识节点的个数，恢复函数产生完整签名的最少签名份额的个数(即门限数量)可以等于PBFT算法中的quorum。当然，私钥的个数也可以不等于共识节点的个数，恢复函数产生完整签名的最少签名份额的个数可以不等于PBFT算法中的quorum。以下以前者为例说明。

所述1个总公钥和n个公私钥对，可以由一个中心化的dealer生成，并分发给n个区块链共识节点，这种属于中心化的密钥分配方式。这样，结合共识算法，n个私钥份额可以是每个区块链共识节点持有其中一个。同时，每个区块链共识节点可以持有相同的1个总公钥。此外，还存在去中心化的密钥分配方式，即取消dealer，而是由n个共识节点通过密钥协商过程协商得到成对的n个公私钥对和1个总公钥，仍然是每个共识节点单独持有n个私钥份额中的一个，且各共识节点持有同一个总公钥。

采用门限签名算法，每一共识节点都可以采用自身特有的那一份私钥(例如包含4个节点且采用PBFT作为共识算法的区块链网络中，节点0、节点1、节点2、节点3采用门限签名算法所持有的私钥份额分别是sk

原始交易列表的特有值，可以包括原始交易列表本身或者原始交易列表的hash值。一般来说，不同的交易，交易内容是不同的，这样，不同的原始交易列表或其hash值一般都不相同。因此，原始报文中可以至少包括原始交易列表或其hash值，这样由hash函数的性质，足以区分不同区块对应的共识过程完毕后所生成的随机数种子。

考虑到共识过程中会为本次共识的内容生成一个编号，如果共识完成，生成的编号可以作为本次共识所对应的区块的区块号，因此，区块号(也就是编号)也可以作为原始报文中的内容。不论第N+1个区块中所包含的原始交易列表与第N个区块中所包含的原始交易表是否相同，区块生成是顺序的，可以体现为后一区块的区块号是前一区块的区块号+1。因此，区块号作为原始报文中的内容，即使第N+1个区块中所包含的原始交易列表与第N个区块中所包含的原始交易表相同，仍然由各个节点采用自身私钥基于(原始交易列表+区块号)得到不同的签名，主节点仍然无法获知其它节点的签名，从而无法预测第N+1号区块的完整签名，因此主节点无法使用第N号块已公开的随机数种子来预测第N+1号块的随机数种子，达到了不可预测的目的。与编号类似的，时间戳也是一个区块特有的，且后一区块的时间戳在前一区块之后。因此，时间戳也可以作为原始报文中的内容。

除了原始交易列表的特有值之外，签名的对象还可以加入其它内容，例如上一区块中产生的随机数种子，即原始报文中还可以包括上一区块中产生的随机数种子。前述a140执行之后，如前所述，各个节点可以各自以共识的交易数据为基础，生成第m个区块。由于第m个区块是各个节点在本地各自独立生成的，因此，如果区块链节点之间没有相互广播自身生成的上一区块的hash值并比对，各个节点可能都无法确定区块链网络中生成的第m个区块是否相同，或者从区块链系统整体可用的角度来说是否有至少quorum数量的共识节点上生成的第m个区块是相同的。经过本申请中随机数种子的生成过程，相同区块的随机数种子应当是相同的，不同区块中的随机数种子应当是不同的，因此可以将随机数种子加入到原始报文中。这样，如果各个节点各自生成的第m个区块对应的随机数种子有所不同，根据门限签名算法的性质，可能无法在第m+1号区块的产生随机数种子的过程中通过恢复函数得出完整签名，从而可以根据本申请的方案帮助共识节点确认上一区块是否一致。也可采用上一区块的hash值来代替上一区块的随机数种子，由于一个区块的hash值一般是唯一的，因此也可以帮助共识节点确认上一区块是否一致。

采用自身私钥份额对包含本次共识中原始交易列表特有值的原始报文进行签名，这个原始报文里可以包括的原始交易列表的特有值，可以是原始交易列表。一般在PBFT的PP阶段已经广播过原始交易列表，且C阶段广播的commit消息较小的话更利于传播及节省带宽，因此原始交易列表特有值可以是原始交易列表的hash值。

对于原始报文包括多个内容，例如包括原始交易列表hash值、区块号、上一区块中产生的随机数种子的情况下，可以先计算原始报文的hash值，进而采用私钥份额对该原始报文hash值进行签名，得到签名结果。

对原始报文进行签名，生成的签名结果和原始报文可以一并加入到广播的commit消息中。这样，在commit阶段，参与共识的节点中的每一个都发送commit消息给其他的共识节点，并将自己发送的commit消息添加到本地Log中(代表自己的认可)，而且，每一节点还接收其他节点广播的commit消息。

S120：每一共识节点收集齐至少门限数量的commit消息后，将通过验证的至少门限数量的签名份额经过所述门限签名算法产生的私钥份额所对应的恢复函数得到完整签名。

如前所述，门限签名算法在应用中，可以产生成对的1个总公钥和n个公私钥对，并可以产生该n个公私钥对所对应的恢复函数。前述提到，该恢复函数可以将验证正确的至少门限个签名恢复生成一个完整签名，门限签名算法的门限值即门限数量可以设为w。当然，正确的签名多于w个时也可以通过该恢复函数生成一个完整签名。也就是说，正确的签名大于等于门限数量w时，都可以通过该恢复函数生成一个完整签名，且生成的这个完整签名是确定的，不会因为输入的正确签名的个数而发生变化(只要大于等于w)。

这个生成的完整签名可以由所述的那1个总公钥来验证正确性。这样，任何持有这个总公钥的节点都可以采用该总公钥来验证这个完整签名的正确性。例如，节点1生成完整签名后，可以采用总公钥验证该完整签名的完整性，例如采用总公钥对完整签名进行密码学运算得到第一hash，并对原始报文进行hash运算得到第二hash，如果第一hash与第二hash一致则可以确定该完整签名的完整性。所述完整性包括该完整签名是针对所述原始报文的，且该原始报文没有经过篡改。再例如，节点1生成完整签名后，可以将该完整签名、总公钥和原始报文发送至区块链以外的一个设备，该设备可以采用所述总公钥和原始报文验证这个完整签名的正确性，原理同上不再赘述。这里的报文原文仍然是前述的包含本次共识中原始交易列表特有值的内容，或还包括当前区块的区块号和/或时间戳和/或上一区块中产生的随机数种子。

此外，也可以是每一共识节点收集每一commit消息后，采用对应的公钥份额对所述接收到的commit消息中的签名份额进行验证，然后再将所述至少门限数量的签名份额经过所述门限签名算法产生的私钥份额所对应的恢复函数得到完整签名。相对于采用总公钥对生成的完整签名进行验证的方式，采用公钥份额对每一签名份额进行验证，验证通过后再经恢复函数恢复为完整签名的方式，能够确定哪个签名是错误的，从而能够确定哪个节点可能是作恶节点。

门限签名算法中，每个共识节点都具有1个总公钥和n个公私钥对中的1个私钥份额和对应的1个公钥份额，如前所述，可以是由dealer生成并分发的，也可以是各共识节点协商得到的。

每个共识节点可以采用对应的公钥份额对接收到的commit消息中的签名份额进行验证。具体的，例如在包含4个共识节点的采用PBFT共识算法的联盟链中，节点0在S110中向节点1、2、3广播自身生成的签名份额σ

进而，节点0可以用对应的公钥份额来验证收集的σ

同样的，节点1可以用对应的公钥份额来验证收集的σ

同样的，节点2可以用对应的公钥份额来验证收集的σ

同样的，节点3可以用对应的公钥份额来验证收集的σ

S130：每一共识节点基于所述完整签名得到随机数种子。

随机数种子(random seed)，是指在伪随机数生成器中用于生成伪随机数的初始数值。对于一个伪随机数生成器，从相同的随机数种子出发，可以得到相同的随机数序列。对于单机来说，随机数种子可以由当前计算机的状态确定，如当前的时间。而对于分布式系统来说，要在各个节点上产生相同的随机数种子，以在系统合约/业务合约/区块链平台功能等中基于相同的随机数种子产生相同的随机数，且不应由任一节点以其可操控的、可预测的、可撤销的方式产生随机数。这就需要由参与共识的节点共同确定。而且，考虑到分布式网络往往是异步网络或半同步网络，从即时性出发，还需要在当前区块中的交易执行时即可以产生随机数并采用。

经过上述S110-S120的步骤，正常情况下每个共识节点都可以得到相同的完整签名。当然，考虑到分布式系统的容错特性，在采用PBFT共识算法的区块链网络中至少应当有quorum数量的共识节点各自都可以分别得到相同的完整签名。

这样，基于完整签名，各共识节点可以采用相同的随机数种子生成算法生成随机数种子。一种较为简单的随机数种子生成算法例如是sha256算法。当然，也可以直接将完整签名作为随机数种子。

经过上述过程，即可在区块链上产生随机数种子。

这样，区块链节点在执行当前共识完毕后输出共识结果的过程中，即执行确定了内容和顺序的一系列交易的过程中，如果其中包含需要使用随机数的智能合约/系统合约/区块链平台代码，可以基于S130的随机数种子来执行。例如，在C++语言编写的智能合约中，可以采用C++标准库或boost库提供的mt19937(r)方法来构造一个跨平台一致的随机数引擎，其中的参数r即为随机数种子。类似的，python中的random库，java中的random库，也都提供了类似的随机数生成方法。基于相同的随机数种子，在相同的随机数生成算法下可以生成相同的随机数。这样，例如各个区块链节点各自分别执行相同区块中的相同交易时，对于其中相同的随机数生成过程，可以基于相同随机数种子产生相同的随机数，从而完成诸如摇号、发红包、盲盒之类的业务逻辑，或完成系统合约/区块链平台功能，并在各个节点上得到一致的执行结果。

此外，在上述方案基础上，还可以包括如下步骤：每一共识节点将得到的随机数种子放至在生成的当前区块的区块头中。

以太坊(Ethereum)为例，图5是一个区块的区块头的结构示意图。由图5所示的结构中，每一区块的区块头包括若干字段，例如上一区块哈希previous_Hash(图中的PrevHash)，Nonce(这是工作量证明涉及的随机数，与本申请中的随机数种子不同，且在一些以以太坊为基础的联盟链中并不启用这个nonce)，时间戳Timestamp，上一区块号Block Num，状态根哈希State Root，交易根哈希Transaction Root，收据根哈希Receipt Root等。其中，下一区块(如区块N+1)的区块头中的Prev Hash指向上一区块(如区块N)，即为上一区块的hash值，也就是上一区块的区块头的hash值。区块头的hash值，可以是区块头中所包含的各个字段顺序拼接后经某种hash算法计算得到的hash值。通过这种方式，区块链上通过区块头实现了下一区块对上一区块的锁定。特别的，如前所述，state root是当前区块中所有账户的状态组成的MPT树的根的哈希值，指向state_root的为一颗MPT形式的状态树statetrie。

Transaction Root一般是本区块包含的原始交易列表的组织成一种树形结构后的树根节点的hash值，Receipt Root一般是本区块包含的交易经过执行后生成的所有收据组织成一种树形结构后的树根节点的hash值。

这里需要注意的是，本申请可以在区块头中增加一个字段——“随机数种子”，即S130中的随机数种子。这样，本区块产生的随机数种子，可以记录在区块链账本上，此外，对于回放区块来说，可以按照区块头中的随机数种子来回放区块中涉及随机数的交易。

本申请提供的上述方案，将门限签名算法与PBFT共识算法相结合，使得对应每个区块的原始交易列表在通过PBFT算法达成共识后，即可通过采用的门限签名算法得到完整签名，从而得到随机数种子，在执行本区块对应的原始交易列表中的交易的过程中，即可以采用随机数，这样，执行本区块的交易不需要额外的等待。

本申请提供的上述方案，基于门限签名算法的性质，各共识节点各自分别基于至少门限数量的签名份额通过恢复函数可以恢复出相同的完整签名，进而生成相同的随机数种子，从而，各个区块链节点各自分别执行相同区块中的相同交易时，对于其中相同的随机数生成过程可以基于相同随机数种子产生相同的随机数，从而完成诸如摇号、发红包、盲盒之类的业务逻辑，或完成系统合约/区块链平台功能，并在各个节点上得到一致的执行结果。

本申请提供的上述方案，将门限签名算法与PBFT共识算法相结合，使得任一共识节点在共识完成前无法预测完整签名，即使是PBFT的主节点也无法预测完整签名，也就无法预测随机数种子和随机数。特别是当门限＝quorum时，一旦完成共识，由于quorum数量的节点对交易列表的内容和顺序已达成一致，即生成新区块的基础内容已经确定，这时至少quorum数量的节点根据恢复函数得到的完整签名是相同的，这quorum数量的节点生成的随机数种子也必然相同，即使有不超过f个节点作恶而想要控制或撤销得到的随机数种子，这f个节点也不会影响系统的一致性，即这f个节点不可操控或撤销生成的完整签名、随机数种子和随机数。

本申请中的方法，可以在每一区块生成的过程中实施，这样，每一区块的区块头中都可以包括随机数种子这一字段。即使某一区块的区块体中并不包含涉及随机数的交易，该区块的生成过程中仍然可以包含生成随机数种子的过程。

前面提到，门限签名算法可以采用基于RSA的门限签名机制，基于ECDSA的门限签名机制、基于Schnorr的门限签名机制或基于BLS的门限签名机制等。采用的门限签名算法中，一般都需要生成1个总公钥和n个公私钥对。一种典型且简洁的实现中，私钥份额的个数可以等于共识节点的个数，每个共识节点持有其中一个私钥，也即一个私钥份额。这样，每一共识节点基于门限签名算法，采用自身私钥份额对原始报文进行签名以生成签名份额。恢复函数产生完整签名的最少个数即门限数量w可以等于PBFT算法中的quorum，也就是至少w个签名份额可以由对应的恢复函数生成一个确定的完整签名，而不论是n个签名份额中的至少哪w个，只要这至少w个签名是采用各自正确的私钥份额对同一原始报文所做的签名。

为了在区块链的共识节点上实现门限签名算法，需要通过一种机制使得n个共识节点分别具有1个私钥份额和对应的1个公钥份额，且都具有同一个总公钥。前述提到，可以由一个中心化的dealer生成，并分发给n个区块链共识节点，这种属于中心化的密钥分配方式。这种中心化的密钥分配方式，需要借助第三方dealer，则要求这个dealer不会作恶。例如一种分布式密钥生成(Distributed Key Generation)协议的实现，原理上需要生成一个t次多项式，然后根据这个多项式形成的曲线，在上面取出n个点，通过这n个点生成n个私钥份额，并分给n个阈值签名的参与者。这个过程如果放在一个dealer上进行，那么如果这个dealer作恶，则这个dealer可以获取所有n个参与者的私钥份额，不符合区块链系统的安全要求。

此外，还存在去中心化的密钥生成和分配方式，即取消dealer，而是由n个共识节点通过密钥协商过程协商得到n个公私钥对和1个总公钥，仍然是每个共识节点单独持有n个私钥份额中的一个，且各共识节点持有同一个总公钥。上述这种方式，传统的是在区块链之外实现，并且依赖网络同步。区块链上的节点在构成分布式网络，而分布式网络一般是半同步或者异步的。因此，在区块链之外实现分布式网络各节点之间的密钥生成和分配，是不可靠的。而实现可靠的分布式密钥协议，又是区块链上生成随机数种子的重要前提。

前述提到的PBFT协议属于半同步(partial synchronous)协议，其特点是假设网络一开始是异步的，但是能够从某一时刻开始同步。要在网络中让不同节点对同一提议达成共识，最简便的方式是设置主节点，由主节点来统一各个节点的意见。通过设置定时器，可以防止主节点出错。PBFT中，如果在有限时间内没有完成Normal Case Phase，会触发Backups发起View Change Phase，以更换主节点。PBFT将主节点固定在一个位置，所有请求都可以先发送到主节点，再由主节点广播到其他共识节点。与此相对的，HoneyBadgerBFT(也常简称为HBBFT)算法属于一种异步(asynchronous)协议。异步协议适用于异步网络，也就是这个网络中节点间的消息可以被任意延迟，但最终会到达。HoneyBadgerBFT中去掉了定时器，而是通过消息来驱动协议的执行。同时，HoneyBadgerBFT算法中所有节点都是对等的，没有主节点和备份节点之分，也就没有换主的过程。HBBFT等异步网络共识协议无主节点的概念，各节点都可提议请求，尝试构造区块，因此异步网络协议在一定程度上缓解了公平性和单节点瓶颈的问题。

例如为中国专利ZL202111175184.1、ZL202111178795.1、ZL202111178745.3、ZL202111178754.2、ZL202111175144.7、ZL202111175151.7以及中国专利申请CN202111178779.2，都考虑了区块链网络的半同步或异步网络的特性的前提下提出了新的共识算法。

通过区块链网络中的各种共识机制，可以保障区块链网络的整体一致性和同步。对于后者，只要区块链能够持续的出块，就能实现区块的同步。那么，结合区块链实现分布式密钥生成将是可靠的。

图6为本说明书实施例中的一种区块链上实现分布式密钥生成的方法流程图，包括：

S610：每一节点生成一组特有的n个秘密份额和与该n个秘密份额对应的公共验证参数，自身保留一份秘密份额。

下文中，以共识节点为例描述本说明书实施例的方法。可以理解，本说明书实施例中不限于通过共识节点执行该方法，而可以通过其它节点(例如非共识节点)执行该方法。

DKG算法中对节点重新进行了编号，从1开始。这里为了与DKG算法一致，也将共识节点从1开始编号。

椭圆曲线(Elliptic Curve Cryptography，ECC)加密算法是一种公钥加密技术，以椭圆曲线理论为基础。利用有限域上椭圆曲线的点构成的阿贝尔(Abel)群离散对数难解性，实现加密、解密和数字签名。以下以椭圆曲线为例进行说明。每一个节点可以在群Z

f

公式(1)中，a

当区块链网络的共识节点数量n设置为4时，采用PBFT、HBBFT之类算法的quorum为3的情况下，这时t＝2。这时，这个多项式为：

f

节点1可以从一个有限素数域中随机选择一组数作为系数，即作为a

类似的，节点2可以从同一有限素数域中随机选择一组数作为系数，即作为a

类似的，节点3可以从同一有限素数域中随机选择一组数作为系数，即作为a

类似的，节点4可以从同一有限素数域中随机选择一组数作为系数，即作为a

每个节点基于确定的多项式，可以进一步确定一组秘密份额。可以根据如下公式由多项式系数确定秘密份额：

s

公式(3)中，q是每个节点采用的相同的一个大数，对f

共识节点1生成4个秘密份额，分别为S

共识节点2生成4个秘密份额，分别为S

共识节点3生成4个秘密份额，分别为S

共识节点4生成4个秘密份额，分别为S

每一共识节点可以生成自身密钥份额对应的一组验证参数，生成方法可以采用下面公式：

/>

公式(4)中，g是椭圆曲线上的基点。根据椭圆曲线的运算性质，g的幂次方也是椭圆曲线上的一个点。t是多项式的次数，一般设置为(quorum-1)。如前所述，如果要最终实现在从n个签名份额中取任意w个即可通过恢复函数生成一个完整签名，这里需要设置多项式的次数是t，其中t＝w-1。下同。

基于上述公式(4)，设t＝2，共识节点1生成的一组验证参数为

基于密码学的性质，A

每一节点在生成n个秘密份额之后，自身保留一个，并使用其他n-1个节点的公钥分别对其他n-1个秘密份额加密以提供给至其它n-1个节点。

具体可以如下：

共识节点1保留S

共识节点2保留S

共识节点3保留S

共识节点4保留S

可见秘密份额的下标中的两个数字，左边的可以表示发出秘密份额的节点的编号，右边的可以表示接收秘密份额的节点。

S620：每一节点生成一笔交易，该交易调用DKG合约，包括其生成的n-1个秘密份额的密文及对应的公共验证参数。

每一节点在生成n-个秘密份额的密文之后，生成调用DKG合约的一笔交易，该交易包括该节点生成的n-1个秘密份额的密文及该n-1个秘密份额对应的公共验证参数。

具体是，每个节点可以内置区块链SDK(Software Development kit，软件开发工具包)。SDK是一系列程序接口、文档、范例、开发工具等的集合。通过内置SDK，区块链节点可以像区块链客户端一样向区块链网络发起交易。区块链节点用自身私钥签名发出的交易中，可以包含对区块链上的智能合约的调用。被调用的合约，例如是DKG合约。这个DKG合约可以是系统级的合约，即是预先部署在区块链上的合约，例如由具有系统管理员权限的账户创建的合约，起到系统级的控制功能，而非由用户自行开发并部署的实现某种具体的业务逻辑的合约。

在步骤S630,每一节点将其生成的交易发送到区块链中，以将n-1个秘密份额的密文及对应的公共验证参数存储到区块链中。

每一节点将其生成的交易发送到区块链中之后，区块链中的各个共识节点将对该交易进行共识，在共识完成之后，区块链中的各个节点可执行该交易。节点在执行该交易的过程中，执行该交易调用的DKG合约，从而可通过DKG合约的执行将n-1个秘密份额的密文及对应的公共验证参数存储到区块链中，以提供给其他n-1个节点。

具体是，像其它合约一样，DKG合约可以在虚拟机(例如Ethereum VirtualMachine，EVM)中执行，当然也可以是在容器(例如docker)中执行，这里并不限定。外部账户向区块链发起一笔调用链上合约的交易，可以触发该合约的执行。交易的内容例如包括from字段、to字段、value字段、data字段。from字段可以是交易发起方的账户地址，to字段可以代表被调用的智能合约的地址，value字段可以是区块链上原生的通证(例如在以太坊中是以太币的值)，data字段可以包含的调用智能合约的方法和参数。通过在to字段指明调用的智能合约的地址，可以表明是对区块链上某个智能合约的调用。智能合约中一般可以包括一个或多个函数，每个函数可以包括一些输入的参数。交易中通过data字段可以指明所要调用的智能合约中的某个函数，并在data字段中填入需要传入的参数。

合约执行的结果，一方面可以改变合约的存储，即合约的世界状态，另一方面，该交易的执行结果或相关信息可以记录在区块链的收据(receipt)中。具体的，合约执行结果/相关信息可以表现为收据中的事件(event)。事件的结构例如为如下格式：

Event：

[topic][msg]

[topic][msg]

......

在上述示例中，事件的数量可以为一个或多个。每个事件可以包括主题(topic)和数据(data)等字段。交易执行时输出的事件的格式，可以在合约中指定。通过内置的SDK，区块链客户端或区块链节点可以监听特定topic的事件，并在监听到特定topic事件的情况下，拉取相应的msg的内容，以及可以监听到特定topic或对应msg中的某些内容后执行预设的处理。

通过该事件机制，节点可以将执行结果存放到某个topic对应的msg中，从而监听该topic的监听方(即内置区块链SDK的客户端或区块链节点)可以获得相应的执行结果。具体是，可以是某一节点将生成的n-1个秘密份额的密文及对应的公共验证参数通过发起调用DKG合约中第一函数(例如名为Broadcast的函数，其中该函数可以包括参数，参数可以包括n-1个秘密份额的密文及对应的公共验证参数)的方式传入区块链网络，区块链网络执行该交易的一个结果是将n-1个秘密份额的密文及对应的公共验证参数置入收据中特定topic对应的msg中。

在本说明书实施例中，每个节点通过一笔交易将n-1个秘密份额的密文及对应的公共验证参数存储到区块链中，相比于将n-1个秘密份额分别发送给n-1个其他节点，大大减少了区块链中的通信次数，或者相比于通过n-1个交易分别将n-1个秘密份额的密文存储到区块链中，，大大减少了区块链中处理的交易数量，提升了交易处理速度，提高了区块链系统的效率。

在步骤S640，每一节点对从区块链获取的秘密份额和对应的公共验证参数进行验证。

每一节点可以通过SDK向区块链节点注册要监听事件。具体的，区块链节点可以在运行的区块链平台代码中对生成的事件绑定一个钩子函数(钩子函数可以与平台代码一同在开发阶段编辑完成)。这个钩子函数属于一种回调函数，其可以在监听的事件发生时被调用，并可以执行一定的处理逻辑。监听代码例如可以包括监听区块链交易的交易内容，智能合约的合约状态，合约产生的收据等一种或多种。通过SDK向区块链节点注册监听事件后，区块链节点可以保存监听事件与监听者(例如置入SDK并发起事件监听的客户端/节点的网络连接，一般可以包括IP地址、端口号等信息)的映射关系，例如保存监听某个合约的某个事件与监听者的映射关系。当钩子函数监听到对应的事件主题(topic)发生时，可以调用钩子函数，进而钩子函数可以查询所述映射关系，将监听的事件推送至所述网络连接。这样，发起监听的SDK可以通过保持的网络连接获得监听的事件。合约的执行也是通过类似方式的实现链上合约广播。具体的，合约的执行结果和本区块其它交易的执行结果一并存入区块链节点的一个交易结果缓存区。当该区块链的所有交易都执行完毕并组织成块后，区块链平台代码可以监听交易结果中的收据，从中将被监听的事件广播至发起监听的SDK。这里，通过这种监听机制，节点可以监听注册的特定topic事件，并在这样的事件发生时，通过保持的连接获取这个topic对应的msg，从而获得msg中的内容，这里msg中的内容包括n-1个秘密份额的密文及对应的公共验证参数。总之，可以通过区块链的事件机制实现广播公共验证参数，并通过事件监听机制实现对广播内容的接收。

监听的节点在监听到n-1个秘密份额的密文及对应的公共验证参数之后，获取n-1个密文中与该节点对应的密文，使用自身的私钥对该密文解密，从而得到该秘密份额。

这样，通过链上广播各节点生成的n-1个秘密份额的密文及对应的公共验证参数的结果可以如下：

共识节点1本地具有不同节点生成的秘密份额S

共识节点2本地具有不同节点生成的秘密份额S

共识节点3本地具有不同节点生成的秘密份额S

共识节点4本地具有不同节点生成的秘密份额S

如果每一节点发出的秘密份额和对应的公共验证参数是归属于同一个多项式的，则下面等式应当成立：

如前所述，t＝quorum-1；n＝4时，quorum＝3，这时t＝2。

基于公式(5)这样的性质，可以用该公式对接收到的每一秘密份额和公共验证参数进行验证。如果验证等式成立，说明秘密份额和对应的公共验证参数是归属于同一多项式，否则不归属于同一多项式。这样也可以检验生成秘密份额和对应公共验证参数的节点是否存在作恶行为。典型的作恶行为例如为节点根据第一个多项式生成了S

上述验证，具体的：

j＝1时，即共识节点1可以验证以下内容：

i＝1：

i＝2：

i＝3：

i＝4：

j＝2时，即共识节点2可以验证以下内容：

i＝1：

i＝2：

i＝3：

i＝4：

j＝3时，即共识节点3可以验证以下内容：

i＝1：

i＝2：

i＝3：

i＝4：

j＝4时，即共识节点4可以验证以下内容：

i＝1：

i＝2：

i＝3：

i＝4：

S650：每一共识节点对每一验证通过后，将通过验证的节点编号发送至所述合约；所述合约根据各共识节点发来的节点编号确定节点集合。

共识节点2验证等式

共识节点3验证等式

共识节点4验证等式

这样，DKG合约可以收集齐除节点1之外的其它所有节点对节点1通过验证的确认，因此可以认为节点1发出的秘密份额及对应公共验证参数都是归属于同一多项式的。

类似的：

共识节点1验证等式

共识节点3验证等式

共识节点4验证等式

这样，DKG合约可以收集齐除节点2之外的至少quorum个(例如2f个)节点对节点2通过验证的确认，因此可以认为节点2发出的秘密份额及对应公共验证参数都是归属于同一多项式的。

类似的：

共识节点1验证等式

共识节点2验证等式

共识节点4验证等式

这样，DKG合约可以收集齐除节点3之外的其它所有节点对节点3通过验证的确认，因此可以认为节点3发出的秘密份额及对应公共验证参数都是归属于同一多项式的。

类似的：

共识节点1验证等式

共识节点2验证等式

共识节点4验证等式

这样，DKG合约可以收集齐除节点4之外的其它所有节点对节点4通过验证的确认，因此可以认为节点4发出的秘密份额及对应公共验证参数都是归属于同一多项式的。

进一步，所述合约可以根据各共识节点发来的节点编号确定节点集合。

例如所述DKG合约，可以根据各共识节点发来的交易校验确定节点集合，具体的，对于一个节点，如果DKG合约收到了至少quorum-1个其它节点对其的确认，则DKG合约将被确认的节点加入节点集合。这个集合例如是QUAL集合。其中，在根据PBFT算法的情况下，quorum例如为2f。

例如，DKG合约收到了节点2、节点3和节点4中至少两个节点对节点1的确认，则DKG合约将节点1加入到QUAL集合中；类似的，DKG合约收到了节点1、节点3和节点4中至少两个节点对节点2的确认，则DKG合约将节点2加入到QUAL集合中；类似的，DKG合约收到了节点1、节点2和节点4中至少两个节点对节点3的确认，则DKG合约将节点3加入到QUAL集合中；类似的，DKG合约收到了节点1、节点2和节点3中至少两个节点对节点4的确认，则DKG合约将节点4加入到QUAL集合中。

经过上述合约的执行，QUAL集合中包括节点集合为{1,2,3,4}。

当在执行某个调用DGK合约以进行确认的交易中，DKG合约确定节点集合中包括quorum个节点的节点编号，则DKG合约可确认DKG可进入下一个阶段，因此，DKG合约可在该交易的收据中记录结束事件，以用于指示各个节点开展之后的步骤(即步骤S660)。

需要说明的是，在区块链网络中，由于半同步或异步的网络特性，合约的执行并不一定是在同一个区块中执行的，而是可能在不同的区块中分别执行一部分。这种情况，一般可以再合约中设置状态机，从而在执行完一部分的情况下转变状态机的状态，或直至状态机转变为某种最终状态。状态机执行的每一步，可以是在接收到一个交易后执行并触发的。因此，本步骤中DKG合约确定节点的集合，可能会延续多个区块。

S660：每一节点获得所述节点集合，并基于验证参数及所述节点集合计算公钥份额，并基于本地的秘密份额和节点集合计算自身对应的私钥份额。

各个共识节点在从区块链中监听到DKG的结束事件之后，一方面，每一共识节点各自可以在本地基于验证参数及合约中的节点集合计算公钥份额，可以按照下面公式计算该公钥份额：

这样，例如共识节点1计算的公钥份额可以是：

类似的，例如共识节点2计算的公钥份额可以是：

类似的，例如共识节点3计算的公钥份额可以是：

类似的，例如共识节点4计算的公钥份额可以是：

另一方面，每一共识节点各自基于本地的秘密份额和合约中的节点集合计算自身对应的私钥份额，可以按照下面公式计算：

x

例如，共识节点1在本地计算自身的私钥份额：

共识节点2在本地计算自身的私钥份额：

共识节点3在本地计算自身的私钥份额：

共识节点4在本地计算自身的私钥份额：

可见，节点1、节点2、节点3和节点4计算得到的私钥份额不相同。

再一方面，每一共识节点各自可以在本地基于验证参数及合约中的节点集合计算总公钥，可以按照下面公式计算该总公钥：

y＝∏

其中，y

这样，例如共识节点1计算总公钥可以是：

y＝y

类似的，例如共识节点2计算总公钥可以是：

y＝y

类似的，例如共识节点3计算总公钥可以是：

y＝y

类似的，例如共识节点4计算总公钥可以是：

y＝y

可见，节点1、节点2、节点3和节点4计算得到的总公钥相同，即通过上述方法，各节点获得相同的总公钥。

上述私钥份额x

通过上述方法，在共识机制保障区块链网络整体一致性和同步的基础上，结合区块链智能合约实现分布式密钥生成，保障了分布式密钥密钥的生成一方面是由各个参与方通过协作来生成的，另一方面生成的结果是一致和可靠的，从而摆脱了原有的区块链之外实现分布式密钥生成对网络同步的强依赖，并解决了该情况下生成结果的不可靠性问题。

以下以以一个共识节点的角度描述区块链上实现分布式密钥生成的方法，如图7所示，该方法例如由区块链中的第一节点执行，包括：

在步骤S710，第一节点生成n个秘密份额和与n个秘密份额对应的公共验证参数，自身保留一份秘密份额。

在步骤S720，第一节点生成一笔交易，该交易调用DKG合约，包括其生成的其他n-1个秘密份额的密文及对应的公共验证参数。

在步骤S730，第一节点将交易发送到区块链中，以将n-1个秘密份额的密文及对应的公共验证参数存储到区块链中。

在步骤S740，第一节点从区块链中获取其它节点生成的与第一节点对应的秘密份额和与该秘密份额对应的公共验证参数。

在步骤S750，第一节点对获取的每一秘密份额和对应的公共验证参数进行验证。

在步骤S760，第一节点对每一验证通过后，将通过验证的节点编号发送至DKG合约。

在步骤S770，第一节点接收所述DKG合约确定的节点集合。

在步骤S780，第一节点基于验证参数及节点集合计算公钥份额，并基于所述秘密份额和节点集合计算自身对应的私钥份额。

第一节点还可以基于验证参数及节点集合计算总公钥。

图8为本说明书实施例中的一种区块链系统中的区块链节点的架构图，包括：

生成单元81，用于生成n个秘密份额和与所述n个秘密份额对应的公共验证参数，自身保留一份秘密份额；生成第一交易，所述第一交易调用合约，包括其生成的n个秘密份额中的n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数，所述n-1个秘密份额的密文通过使用其他n-1个节点的公钥分别加密而生成；

发送单元82，用于将其生成的所述第一交易发送到区块链中，以通过所述合约将所述n-1个秘密份额的密文、及与所述n-1个秘密份额对应的公共验证参数存储到所述区块链中；

获取单元83，用于从区块链中获取其它节点生成与所述第一节点对应的秘密份额、和与该秘密份额对应的公共验证参数；

验证单元84，用于对接收到的每一秘密份额和对应的公共验证参数进行验证；

所述发送单元82还用于，在对每一验证通过后，将通过验证的节点编号发送至所述合约；

接收单元85，用于接收所述合约确定的节点集合，其中，所述节点集合由所述合约根据各节点发来的节点编号确定；

计算单元86，用于基于验证参数及节点集合计算公钥份额，并基于所述秘密份额和节点集合计算自身对应的私钥份额。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。