CN111159297A - 一种区块链记账方法、装置、节点及存储介质 - Google Patents

Abstract

本申请涉及区块链技术领域，提供一种区块链记账方法、装置、节点及存储介质。其中，区块链记账方法包括：应用链矿工参与待挖区块的提案组成员的推选，若被推选为提案组成员则向基链矿工发送挖矿请求；应用链矿工同步基链区块信息，并将其纳入本地的基链账本中，基链区块信息中包括基链矿工根据挖矿请求选举提案组领导人的结果；应用链矿工参与待挖区块的验证组成员的推选，若被推选为验证组成员则对提案组领导人所出区块进行验证并广播检验报告；应用链矿工接收检验报告，若根据检验报告确定提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。该方法提出了一种由基链和应用链共同参与挖矿的机制，有助于解决矿机资源浪费问题。

Description

一种区块链记账方法、装置、节点及存储介质

技术领域

本发明涉及区块链技术领域，具体而言，涉及一种区块链记账方法、装置、节点及存储介质。

背景技术

当前业界以比特币为首的区块链公有链，普遍存在双重浪费的现象：第一重浪费是采用工作量证明(Proof of Work，简称PoW)算法，PoW算法中大量无意义的计算导致挖矿过程过于消耗电力资源，这一问题可以通过改进区块链的共识算法来解决；第二重浪费是稀缺的矿机资源只服务于单一的区块链系统，矿机的挖矿能力未能得到充分的利用。例如，在现有的比特币系统中，有百万台级别的矿机参与挖矿，每台矿机的价值可能高达数万人民币，然而受限于系统实现，目前仅能保障约每秒7笔的交易能力。对于如何改善第二重资源浪费，目前尚未有人提出有价值的解决方案。

发明内容

本申请实施例的目的在于提供一种区块链记账方法、装置、节点及存储介质，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种区块链记账方法，应用于应用链矿工，所述方法包括：参与应用链待挖区块的提案组成员的推选；其中，若确定所述应用链矿工被推选为应用链待挖区块的提案组成员，则向基链矿工发送针对所述应用链待挖区块的挖矿请求，所述提案组为有权发送挖矿请求的应用链矿工的集合；同步基链区块信息，并将所述基链区块信息纳入本地的基链账本中，所述基链区块信息来源于基链矿工根据所述挖矿请求生成的确定所述应用链待挖区块的提案组领导人的基链区块，所述基链区块信息中包括指示所述提案组领导人的选举结果；其中，所述提案组领导人为具有所述应用链待挖区块的出块权的提案组成员；参与应用链待挖区块的验证组成员的推选；其中，若确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员，则对所述提案组领导人所出区块进行验证，并向其他应用链矿工广播检验报告，所述验证组为有权生成检验报告的应用链矿工的集合，所述提案组领导人所出区块包括所述提案组领导人打包的所述应用链待挖区块；接收所述检验报告，若根据所述检验报告确定所述提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。

第二方面，本申请实施例提供一种区块链记账方法，应用于基链矿工，所述方法包括：根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人；将保存有选举结果以及选举依据的基链区块纳入基链账本中。

根据对上述两方面方法的描述，应用链矿工并不直接运行共识算法竞争出块权，而是在确定自身为提案组成员后向基链矿工发送挖矿请求，由基链矿工通过计算选举出提案组领导人(即具有出块权的应用链矿工)并将选举结果及选举依据记录在基链区块中，随后应用链矿工通过同步基链区块信息即可获知提案组领导人的信息，进而参与验证组成员的推选，并通过收集验证组成员针对提案组领导人所出区块出具的检验报告判断区块是否通过验证，若通过验证就进行记账。不难看出，上述两方面提供的区块链记账方法实际上提出了一套由基链和应用链共同参与挖矿的全新机制，即可由一条基链汇集矿机资源(体现为上述基链矿工)，为众多应用链提供算力服务，协助应用链完成挖矿过程，从而可以有效改善现有区块链系统中矿机资源的浪费问题，具有良好的社会效益。

另一方面，对于新发展的区块链系统，由于缺乏矿机资源的支持，容易遭到攻击，若为这样的区块链系统设计专有的共识算法，虽然可以改善其安全性，但势必导致矿机缺乏通用性难以得到市场认可，最终还是无法解决新生系统的困境。若利用上述两方面提供的区块链记账方法，可由基链为新发展的区块链系统提供充足的矿机资源，保障其安全、稳定运行。

此外，在很多区块链系统中，矿机不只用于挖矿，还可用于对外提供特定服务，同样需要足够数量的矿机才能够确保分布式服务的稳定运行。若利用上述两方面提供的区块链记账方法，可由基链为这些区块链系统提供充足的矿机资源，保障其提供服务的可靠性。

第三方面，本申请实施例提供一种区块链记账方法，应用于基链中设置的同步节点，所述方法包括：接收基链矿工发送的确定应用链待挖区块的提案组领导人的基链区块，或者，接收所述基链矿工或基链中设置的其他同步节点发送的所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；其中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的提案组领导人的选举结果，包括所述应用链待挖区块的提案组领导人的选举结果；向应用链矿工发送来源于所述基链区块的基链区块信息，所述基链区块信息采用的形式包括以下之一：所述基链区块本身；所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；所述基链区块的区块头以及所述基链区块的区块体中针对所述应用链的片断数据；其中，所述片断数据包括所述选举结果列表中针对所述应用链待挖区块的提案组领导人的选举结果，以及，所述选举结果与所述基链区块的区块头中基于所述选举结果列表计算出的merkle根之间的merkle路径。

在第三方面提供的方法中，基链上可以设置同步节点，同步节点用于从基链矿工或其他同步节点处同步包含提案组领导人选举结果在内的区块数据，应用链矿工则可以进一步从同步节点处同步基链区块信息用于出块及验证。基链区块信息可以是完整的基链区块，也可以适当简化，只保留基链区块中应用链矿工所需部分，以减少数据同步过程中的带宽占用。

允许在一些方案中多个应用链矿工共享一个同步节点，也允许在一些方案中部分应用链矿工不直接从同步节点同步基链区块信息，而是从其他应用链矿工处同步。此外，在某些方案中，基链也可以不设置独立的同步节点，应用链矿工直接从基链矿工处同步数据，这些方案亦可视为基链矿工部分或全部地实现了同步节点的功能。

第四方面，本申请实施例提供一种区块链记账装置，配置于应用链中设置的挖矿节点，所述装置包括：提案组推选模块，用于应用链矿工参与应用链待挖区块的提案组成员的推选；其中，若确定所述应用链矿工被推选为应用链待挖区块的提案组成员，则向基链矿工发送针对所述应用链待挖区块的挖矿请求，所述提案组为有权发送挖矿请求的应用链矿工的集合；区块信息同步模块，用于所述应用链矿工同步基链区块信息，并将所述基链区块信息纳入本地的基链账本中，所述基链区块信息来源于基链矿工根据所述挖矿请求生成的确定所述应用链待挖区块的提案组领导人的基链区块，所述基链区块信息中包括指示所述提案组领导人的选举结果；其中，所述提案组领导人为具有所述应用链待挖区块的出块权的提案组成员；验证组推选模块，用于所述应用链矿工参与应用链待挖区块的验证组成员的推选；其中，若确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员，则对所述提案组领导人所出区块进行验证，并向其他应用链矿工广播检验报告，所述验证组为有权生成检验报告的应用链矿工的集合，所述提案组领导人所出区块包括所述提案组领导人打包的所述应用链待挖区块；应用链记账模块，用于所述应用链矿工接收所述检验报告，若根据所述检验报告确定所述提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。

第五方面，本申请实施例提供一种区块链记账装置，配置于基链中设置的挖矿节点，所述装置包括：选举模块，用于基链矿工根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人；基链记账模块，用于所述基链矿工将保存有选举结果以及选举依据的基链区块纳入基链账本中。

第六方面，本申请实施例提供一种区块链记账装置，配置于基链中设置的同步节点，所述装置包括：信息接收模块，用于所述同步节点接收基链矿工发送的确定应用链待挖区块的提案组领导人的基链区块，或者，接收所述基链矿工或基链中设置的其他同步节点发送的所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；其中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的提案组领导人的选举结果，包括所述应用链待挖区块的提案组领导人的选举结果；信息发送模块，用于所述同步节点向应用链矿工发送来源于所述基链区块的基链区块信息，所述基链区块信息采用的形式包括以下之一：所述基链区块本身；所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；所述基链区块的区块头以及所述基链区块的区块体中针对所述应用链的片断数据；其中，所述片断数据包括所述选举结果列表中针对所述应用链待挖区块的提案组领导人的选举结果，以及，所述选举结果与所述基链区块的区块头中基于所述选举结果列表计算出的merkle根之间的merkle路径。

第七方面，本申请实施例提供一种区块链节点，设置在应用链上，所述节点包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第八方面，本申请实施例提供一种区块链节点，设置在基链上，所述节点包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第二方面或第二方面的任意一种可能的实现方式提供的方法。

第九方面，本申请实施例提供一种区块链节点，设置在基链上，所述节点包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第三方面或第三方面的任意一种可能的实现方式提供的方法。

第十方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面、第二方面、第三方面或以上三方面的任意一种可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种区块链系统的结构图；

图2示出了本申请实施例提供的一种区块链记账方法的流程图；

图3示出了本申请实施例提供的第一种区块链记账装置的功能模块图；

图4示出了本申请实施例提供的第二种区块链记账装置的功能模块图；

图5示出了本申请实施例提供的第三种区块链记账装置的功能模块图；

图6示出了本申请实施例提供的一种区块链节点的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

需要指出，在本申请的描述中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

同时，术语“第一”、“第二”等仅用于将一个实体或者操作与另一个实体或操作区分开来，而不能理解为指示或暗示相对重要性，也不能理解为要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

本申请实施例提供的区块链记账方法旨在构建一套由基链和应用链共同参与挖矿的全新机制：可由一条基链汇集矿机资源(体现为基链矿工)，为众多应用链提供算力服务，协助应用链矿工完成挖矿过程，其目的主要是为了改善现有区块链系统(如比特币系统)中矿机资源浪费的问题；另外，应用链确定提案组及验证组所依赖的随机源由链外系统(即基链)参与提供，提案组成员选举领导人改在链外系统(即基链)实施，并由链外系统(即基链)为应用链挖矿过程提供时钟源，这些措施有助于强化应用链的安全性，关于提案组、验证组、随机源和时钟源等概念的含义具体见后文阐述。

图1示出了本申请实施例提供的一种区块链系统的结构图。参照图1，该区块链系统中包含两种区块链，分别是基链和应用链，在一个典型的场景中，基链为一条，而应用链为一条或多条，即允许基链同时为多条应用链提供算力服务，从而充分调度基链中矿机的算力。当然，基链为每条应用链提供算力的过程是类似的，因此在后文中主要针对一条应用链的情况阐述共同挖矿的流程，图1中也仅示出了一条应用链。需要指出，在本申请中提到基链这一概念时，一般应理解为抽象意义上的区块链，不单单指代基链的分布式账本，还应包括构成基链的节点以及节点实现的功能，但也不排除在后文中某些不致混淆的位置将基链的分布式账本简称为基链；对于应用链这一概念，也应当作类似理解。

进一步参照图1，应用链至少应包括挖矿节点，应用链的挖矿节点上部署应用链矿工(例如，可以是一个应用程序)，通过应用链矿工的挖矿行为实现挖矿节点的功能，在后文中为简单起见，一般不再专门区分应用链的挖矿节点和应用链矿工这两个概念，而认为二者是一体的。图1中示出了4个应用链矿工：基链矿工A、基链矿工B、基链矿工C以及基链矿工D。在本申请的方案中，应用链矿工在挖矿时并不直接在本地运行共识算法竞争记账权，而是将竞争记账权的任务转交给基链处理，应用链矿工只需从基链同步竞争记账权的结果，并依据该结果进行出块以及验证工作。

基链至少应包括挖矿节点，基链的挖矿节点上部署基链矿工，通过基链矿工的挖矿行为实现挖矿节点的功能，在后文中为简单起见，一般也不再专门区分基链的挖矿节点和基链矿工这两个概念，而认为二者是一体的。图1中示出了两个基链矿工：基链矿工A和基链矿工B。应用链矿工在挖矿时，以发送挖矿请求的方式通知基链矿工为其确定记账权获得者，基链矿工根据挖矿请求确定出具有记账权的应用链矿工后，将结果保存在基链区块中。

应用链矿工要获知竞争记账权的结果，在一些实现方式中，可以直接从基链矿工处同步相关数据(该数据可以为基链区块或者其简化形式)，例如图1中应用链矿工D直接从基链矿工B处同步数据。在另一些实现方式中，基链中还可以设置专门的同步节点，应用链矿工可以从同步节点处同步相关数据，而同步节点的数据则同步自基链矿工或者其他同步节点。图1中示出了两个同步节点：同步节点A和同步节点B，其中同步节点A的数据同步自同步节点B，而同步节点B的数据则同步自基链矿工A，应用链矿工A和应用链矿工B都可以从同步节点B处同步相关数据，从而获知竞争记账权的结果。对于直接从基链矿工处同步相关数据的实现方式，也可以认为基链矿工同时实现了同步节点的部分或全部的功能。

基链区块中除了记录应用链竞争记账权的结果外，还可以包含其他内容，这些内容对于应用链来说可能并没有什么价值。因此，在可选的方案中，基链矿工保有的基链区块为原始数据，同步节点从基链矿工处同步数据时可以对原始数据作一定的简化，应用链矿工从同步节点处同步数据时还有可能对数据作进一步简化，尽可能减少数据在传输过程中占用的网络带宽，提高区块链系统的运行效率。

在一些常见的实现方式中，针对每个应用链矿工，都为其在基链中设置一个专属的同步节点。同步节点可以和应用链挖矿节点实现为相互独立的节点，为加快数据同步速度，同步节点和应用链挖矿节点还可以部署在同一局域网内；同步节点也可以和应用链挖矿节点实现为同一节点，此时应用链矿工的功能和同步节点的功能可以分别由该节点上的两个应用程序承担，甚至于合并到一个应用程序中实现。

在另一些实现方式中，若不存在信任问题，多个应用链矿工亦可以共享一个同步节点，例如图1中的应用链矿工A和应用链矿工B就共享了同步节点B，很可能应用链矿工A和应用链矿工B本来就归属于同一机构，相互之间可以信赖，进行同步节点的共享是合理的。此外，还允许应用链矿工不从基链矿工或同步节点处同步数据，而是从其他应用链矿工处同步数据，例如图1中的应用链矿工C就是从应用链矿工B处同步数据的，比如应用链矿工C和应用链矿工B归属于同一机构，应用链矿工C可以信任应用链矿工B的数据，这样的实现方式是完全合理的。

如上所述，在本申请的方案中，同步节点主要起中介作用，用于应用链矿工从基链矿工处同步竞争记账权的结果，至于应用链矿工在挖矿时向基链矿工发送的挖矿请求是否要通过同步节点中转，则不作限定。在一些实现方式中，同步节点也有可能参与基链挖矿，此时基链矿工的功能和同步节点的功能可以分别由该节点上的两个应用程序承担，甚至于合并到一个应用程序中实现。并且，同步节点参与基链挖矿还有利于增加基链矿工的数量，矿工数量越多，基链的安全性也就越高。对于不同的机构而言，在基链中设置自己专用的同步节点是常见的做法(确保同步的数据可信)，若这些同步节点参与挖矿，将使得基链上的矿工被大量不同的机构所控制(而不是像现有的某些区块链系统矿机资源被少数几个机构控制)，从而使得在基链上挖矿具有天然的去中心化特性，整个区块链系统的安全性大大改善。

在一些实现方式中，基链中还可以设置管理节点，管理节点的主要作用有两项：其一是提供应用链注册服务，只有在管理节点上注册的应用链基链才会为其提供算力支持，在此过程中基链的运营方也有可能收取一定的费用；其二是用于基链矿工同步授权及配置信息，授权信息即应用链的注册情况，基链矿工需要根据该信息判断是否应该响应应用链矿工的挖矿请求，配置信息主要包括基链矿工在共同挖矿过程中用到的一些预设参数，这些参数在各基链矿工之间应当尽可能保持一致。

下面再对基链和应用链的具体构成作进一步说明。在现有技术中，比特币属于单链区块链系统，其每秒交易数(Transaction Per Second，简称TPS)非常有限，大约只能达到7。目前业界已提出不少采用并行链机制的方案来改善单链区块链系统的TPS瓶颈问题，其中比较著名的是以太坊中的分片(Sharding)技术。对于本申请中的区块链系统而言，每条应用链或基链都可以是并行链(为简单起见，这里将单链也视为并行链的链数为1的特殊情况)。就提供算力角度而言，可以认为构成基链的各并行链之间是相互独立的，基链的每条并行链都可以为一条或多条应用链并行链提供算力。

应用链矿工在向基链发送挖矿请求时，应明确自己要向基链的哪条并行链上的基链矿工发送。在一种实现方式中，若假设N为基链的并行链的总数(N为正整数)，并且基链的N条并行链按照从0至N-1依次编号，则应用链矿工可以按照如下公式确定为自己所在的应用链提供算力的基链的并行链链号：

n＝(ChainNoOffet+k)％N

其中，n表示确定出的基链的并行链链号，ChainNoOffet为应用链矿工所在的应用链的链号偏移，该参数为一个预设值，每条应用链都拥有自己的ChainNoOffet，k为应用链矿工挖矿所在的应用链并行链链号(若应用链为单链，k可取0)，％表示取余数运算。计算出基链的并行链链号n后，应用链矿工可以向基链的编号为n的并行链上的基链矿工发送挖矿请求，相应的基链矿工接收到请求后，也会根据该公式进行验证(参考后文内容，挖矿请求中包括能够表明是哪条应用链的哪条并行链上的矿工在发送请求的信息，从而公式中的ChainNoOffet和k可以确定下来)自己是否应该响应该挖矿请求。

对于基链存在多条并行链的情况，虽然这些并行链在提供算力服务上相互独立，但在软件实现上则既可以在一个应用程序中实现，也可以在多个应用程序中实现(例如，每条并行链用一个应用程序实现)，并不限定。

需要指出，后文中为简单起见，也经常笼统地称呼基链和应用链，而并明确区分到底是整个基链还是基链的一条并行链，或者，到底是整个应用链还是应用链的一条并行链，可以根据具体场景具体理解，不能一概而论。

进一步的，本申请中的基链/应用链结构还可以嵌套，例如，第一级的1条基链为4条应用链提供算力支持，这4条应用链又可作为第二级的基链各自为16条应用链提供算力支持。

本申请的方案对于基链或应用链具体采用何种类型的区块链没有限制，只要基链和应用链都遵循最长链规则就可以了。在一种典型的实现方式中，基链可以采用公链，应用链则可以采用公链或许可链。当然，若基链或应用链直接采用现有的区块链系统，需要进行适当改造，以符合本申请提出的共同挖矿方案的要求。

应当理解，图1中的系统结构仅为示例，不应当视为对本申请保护范围的限制。以上对共同挖矿过程的阐述，仅仅是简要的概括，具体的实现细节将在对图2的阐述中给出。

图2示出了本申请实施例提供的一种区块链记账方法的流程图，该方法描述了应用链上的一个区块(应用链待挖区块)从产生到纳入应用链账本的过程，该过程大致分为两个阶段：提案阶段和验证阶段。本申请的方案可以简单概括为：在提案阶段应用链矿工根据预设的算法选举提案组成员，只有提案组成员才有资格进一步当选提案组领导人并获得出块权(也即应用链待挖区块的记账权)，至于能否获得出块权则取决于基链矿工对提案组领导人的选举结果，该结果记录在基链区块中，应用链矿工同步基链区块信息后便可获知，成为提案组领导人的应用链矿工所出区块将在应用链中广播；在验证阶段，应用链矿工根据预设的算法选举验证组成员，只有验证组成员才有资格进对提案组领导人所出区块进行验证并出具检验报告，检验报告在应用链中广播，若应用链矿工根据接收到的检验报告确认有足够多的验证组成员认可了提案组领导人所出区块的合法性，则将其纳入本地的应用链账本中。参照图2，该方法具体包括：

步骤S100：应用链矿工参与应用链待挖区块的提案组成员的推选。

步骤S101：若确定应用链矿工被推选为应用链待挖区块的提案组成员，则向基链矿工发送针对应用链待挖区块的挖矿请求。

以上两个步骤合并在一起阐述。应用链待挖区块可以是应用链账本中已通过验证并记账的区块的下一区块，提案组是指有资格竞争应用链待挖区块的出块权的应用链矿工的集合，由于只有提案组成员会向基链矿工发送针对应用链待挖区块的挖矿请求，所以提案组也可以定义为有权发送挖矿请求的应用链矿工的集合。提案组中最终获得应用链待挖区块的出块权的应用链矿工被称为提案组领导人，提案组领导人由基链矿工负责选举，具体见步骤S102。

每个应用链矿工都可以根据预设的算法自主确定是否为提案组成员，不依赖于其他应用链矿工。在一种典型的实现方式中，上述预设的算法可采用可验证随机函数(Verifiable Random Function，简称VRF)算法，VRF算法的核心内容是证明函数VRF_prove以及验证函数VRF_verify：调用VRF_prove(PrivateKey,info)可以得到一个可证明字串proof，VRF_prove针对确定的输入(PrivateKey与info)所得到的proof是确定的(多次运算所得的值相同)，其中，PrivateKey是某一公私钥对K中的私钥，info为一个已知字串；调用VRF_verify(PublicKey,info,proof)可以验证proof是否为伪造，其中，PublicKey为公私钥对K中的公钥，若proof未被伪造(即proof是由PublicKey对应的PrivateKey经VRF_prove调用产生的)，VRF_verify返回True，表明验证通过，否则返回False表明验证不通过。本申请中主要介绍VRF算法在共同挖矿过程中的应用，关于算法的详细原理可以参考现有技术，不作具体说明。

应用链矿工首先基于自身的私钥(对应上面的PrivateKey)以及利用预设规则确定的第一选举字串(对应上面的info)调用VRF算法中的证明函数，可以获得第一可证明字串(对应上面的proof)。之后，应用链矿工基于第一可证明字串利用预设的规则推导第一随机值，并根据第一随机值确定应用链矿工是否被推选为应用链待挖区块的提案组成员，上述预设的推导规则具有确定性(但具体是何种规则不限定)，因此对于同样的输入，推导出的第一随机值也具有确定性，进而在第一随机值的基础上得到的提案组成员的推选结果也具有确定性。

上述第一选举字串为一个已知字串，其获取规则是确定的。基链矿工为应用链待挖区块选举的提案组领导人的信息记录在某个基链区块中，称该区块为确定应用链待挖区块的提案组领导人的基链区块，在应用链矿工参选提案组领导人时，该基链区块还处于待挖状态，但其在基链中的高度可以确定(参考后文内容可知，应用链上也保存有基链账本)。在一种实现方式中，第一选举字串可取：确定应用链待挖区块的提案组领导人的基链区块的前L区块中的信息；其中，L为正整数，所谓区块中的信息可以是区块头中记录的哈希值或者随机数，例如，参考比特币中的区块头实现，第一选举字串对应区块头中的hash和nonce两个字段。

不难发现，第一选举字串的确定依赖于基链，基链矿工为应用链的每个区块选举的提案组领导人信息记录在基链区块中，应用链矿工同步到基链区块信息后，可以在应用链矿工所在的挖矿节点上保存该信息，形成一个应用链矿工本地的基链账本，该账本相对于基链矿工本地的基链账本可能有所简化，但仍然包含基链区块的区块头和选举结果等关键信息，应用链矿工查询该账本即确定第一选举字串的内容。

第一选举字串当然也可以采用其他获取规则，但应尽可能保证应用链矿工和基链矿工都可以获取该字串并得到同样的结果(基链矿工使用该字串的步骤见后文)，因此，基于基链账本中的信息确定第一选举字串是一种比较合理的选择，因为根据上面提到的，无论是在基链矿工本地还是应用链矿工本地都保存有基链账本(虽然应用链矿工本地保存的可能是简化版本)。

进一步的，发明人长期研究后发现，L取值不宜太大，L取值太大意味着第一选举字串来源于较早前的基链区块中的信息，从而第一选举字串的取值很早就可以确定下来，敌手(可以指对区块链系统存有恶意的攻击者)一旦提早获知第一选举字串，便有充足时间进行一些破解行为。当然L的取值太小(例如，取1)也有一些问题，应用链矿工同步基链区块信息也需要时间，因此在应用链矿工本地的基链账本中最近的数据可能还没有同步好，并且近期的区块链数据容易受到基链软分叉的影响，导致第一选举字串的取值受到影响(例如，当前应用链矿工和基链矿工或者其他应用链矿工针对同一应用链待挖区块获取到的字串值不同)。

由于区块链系统是一种分布式系统，软分叉是必然存在的现象，由于软分叉的存在，在不同的基链矿工看来，指定高度的基链区块未必都相同，但产生时间距离当前时刻越久远的区块越容易统一到同一内容，因为基链的最长链规则会消除软分叉，也就是说，L＝2时作为第一选举字串来源的基链区块在内容上的同一性比L＝1时要高得多，L＝3时作为第一选举字串来源的基链区块在内容上的同一性又比L＝2时要高得多(同一性概率以指数级别上升，例如在比特币中6次出块即视为不可逆转的确认，同一性概率接近于100％，而非同一性的概率小到可以忽略)。因此，综合考虑在确定第一选举字串时可取L＝6，此时各应用链矿工、基链矿工在基链指定高度的区块处所确定出的第一选举字串基本可以认为是相同，即基本消除了基链软分叉对第一选举字串取值的影响，同时，由于确定应用链待挖区块的提案组领导人的基链区块的前6区块在较早之前已纳入基链账本，给应用链矿工同步该区块的基链区块信息预留了充足时间，即取L＝6也充分考虑了通信时延的因素，取值比较合理，有利于增加系统的稳健性。

需要指出，上面的分析并不是要排除L＝6之外的实现方式，例如采用L＝1、L＝2的实现方式也是可行的，因为随着时间的推移，软分叉最终会因最长链规则消除，通信时延也会消除，并不影响区块链系统的正常运作。

在一些实现方式中，可以直接根据第一随机值确定应用链矿工是否为应用链待挖区块的提案组成员。在另一些实现方式中，对于每个应用链矿工可以计算一个其专属的提案组参选权重，每个应用链矿工可以根据第一随机值以及自身的提案组参选权重确定自己是否为应用链待挖区块的提案组成员，其中，应用链矿工被选为提案组成员的概率与该提案组参选权重的取值正相关。

例如，某个应用链矿工的提案组参选权重可取该矿工在预设历史时间段内当选为提案组领导人的次数，按照该定义，在历史时间段内当选提案组领导人次数越多的矿工再次被选为提案组领导人的概率也越高，作为对其多次诚实挖矿的回报。之前在介绍第一选举字串的获取方法时已经提到，应用链矿工本地也会保存一个基链账本，应用链矿工查询该账本即可统计获得当前应用链矿工在预设历史时间段内当选为提案组领导人的次数。

作为一种可选方案，为提高当选次数的统计速度，应用链矿工还可以基于同步到的基链区块信息构建查询表格，该表格可以保存在数据库中或者常驻内存，其内容可以包括应用链每个区块的提案组领导人信息，方便应用链矿工快速查询(不再直接从本地的基链账本中查询)。关于查询表格的具体表项，在后文还会提及。

上述预设的历史时间段，可以有不同的选取方式：例如，从基链的倒数G1(比如36)个区块之前取基链的连续G2(G2为正整数)个区块作为历史时间段，查询应用链矿工在这些区块中当选为提案组领导人的次数；又例如，取基链刚过去的一个难度调整周期(这里的难度指挖矿难度，例如比特币每2016个区块为一个难度调整周期)之前的连续G3(G3为正整数)个难度调整周期作为历史时间段，查询应用链矿工在这段时间内产生的基链区块中当选为提案组领导人的次数。不难看出，在上面两个例子中，历史时间段并未取当前时刻的最近一段时间，其原因是通信时延和基链软分叉可能导致统计提案组领导人的当选次数受到影响，这两项影响因素之前阐述第一选举字串时已经分析，不再重复。

提案组参选权重当然也可以采用其他定义，但应尽可能保证应用链矿工和基链矿工都可以计算该权重并获得同样的计算结果(基链矿工使用该权重的步骤见后文)，因此，基于基链账本中的信息确定提案组参选权重是一种比较合理的选择，因为无论是在基链矿工本地还是应用链矿工本地都保存有基链账本。

在一些实现方式中，应用链上还可以预设首次记账权重这一参数，其值为0表示禁止新加入的应用链矿工参与挖矿；否则，若首次记账权重取非0值，表示允许新加入的应用链矿工参与挖矿，当统计出应用链矿工在上述预设的历史时间段内未当选过提案组领导人时(对于新加入的应用链矿工，在该历史时段内可能还未参与挖矿)，可将其提案组参选权重(此时值为0)设置为首次记账权重，使得其可以以较低的概率当选提案组成员。

在一些实现方式中，应用链上还可以预设提案组最大参选权重这一参数，即为提案组参选权重设置一个上限，若计算出的提案组参选权重超过该上限(例如，应用链矿工因在历史时间段内多次当选为提案组领导人而使得提案组参选权重大于预设的提案组最大参选权重)，则将提案组参选权重设置为提案组最大参选权重。避免某一深度参与挖矿的应用链矿工在提案组成员的推选中优势过大，剥夺其他应用链矿工当选提案组成员的机会。

应用链矿工根据第一随机值以及自身的提案组参选权重确定自己是否为应用链待挖区块的提案组成员也可以有不同的实现方式，在一种实现方式中，可以这样实现：

首先，利用如下公式计算第二随机值RandValue2：

RandValue2＝(RandValue1％ExpectedRange1)+priority1

其中，RandValue1为第一随机值，ExpectedRange1为预设的范围值，priority1为提案组参选权重，％表示取余数运算。ExpectedRange1的作用主要是将RandValue1的值调整到一个合理的范围内，因为RandValue1的随机性使得该值可能很大，与priority1完全不在同一数量级，如果直接用RandValue1进行计算，可能导致是否加上priority1对最终结果没有影响。

若计算出的RandValue2满足如下条件，则确定当前应用链矿工被推选为应用链待挖区块的提案组成员：

RandValue2>ExpectedRange1-(ExpectedRange1*1/M1)

其中，M1为预设过滤比例，例如，M1取10，则应用链所有的矿工中大约有1/10(概率意义上)会被选为提案组成员。

应当理解，以上两个公式仅为举例，在不同的实现方式中，也可以采取其他的形式，例如，将priority1以乘积的方式结合到公式中(目前是以加法的方式)，或者，将RandValue2小于某个值作为被推选为提案组成员的条件(目前是大于某个值)，等等。

若一个应用链矿工确认了自己为应用链待挖区块的提案组成员，就会向基链矿工发送针对应用链待挖区块的挖矿请求，如前所述，在不同的实现方式中，应用链矿工可能直接向基链矿工所在的挖矿节点发送请求，也可能向基链上的同步节点发送挖矿请求，基链中最先收到挖矿请求的节点会将挖矿请求在基链中广播，最终各个基链矿工都会收到。若基链由多条并行链构成，应用链矿工在发送挖矿请求前，还需确定要向哪条并行链上的基链矿工发送请求，否则其请求不会被受理，确定方式在阐述图1时已经说明，此处不再重复。

挖矿请求中包括提案候选信息，提案候选信息的概念在本系统中多处会使用，其内容包括：应用链标识、并行链链号、应用链待挖区块的高度、确定提案组领导人的基链区块的高度、应用链矿工公钥以及第一可证明字串。

其中，应用链标识是指发送挖矿请求的提案组成员所在的应用链的标识(用于唯一标记一条应用链)，并行链链号是指构成应用链的并行链中提案组成员挖矿所在的并行链的编号(若应用链为单链，该项可固定取0)，确定提案组领导人的基链区块的高度是指确定应用链待挖区块的提案组领导人的基链区块的高度，应用链矿工公钥是指发送挖矿请求的提案组成员的公钥，第一可证明字串是指应用链矿工被推选为提案组成员时依赖的第一可证明字串。当然提案候选信息中还可以包括其他信息项，例如应用链矿工被推选为提案组成员时依赖的第二随机值，虽然利用第一可证明字串也可以推导出第二随机值，但需要进行一定的运算，在某些对安全性要求不太高的场合也可以直接使用第二随机值进行验证等行为，不必再推导一遍。关于提案候选信息中的各信息项的用途将在后续步骤中说明，此处暂不展开。

步骤S102：基链矿工根据应用链待挖区块的提案组成员发送的针对应用链待挖区块的挖矿请求为应用链待挖区块选举提案组领导人。

基链矿工接收到某个应用链矿工发送的挖矿请求后，首先要确认是否要对该请求进行响应，若确认要响应该请求，才会将该请求作为选举应用链待挖区块的提案组领导人的依据。要验证的内容至少包括以下两项：

其一，基链矿工根据挖矿请求中的应用链标识，确定该标识对应的应用链是否由基链提供算力支持。

在阐述图1时已经提到，在常见的实现方式中，某条应用链要在基链中的管理节点上注册后，基链才会为其提供服务。注册信息会被同步到各个基链矿工，例如，各基链矿工可以在本地维护一个由已注册的应用链对应的应用链标识构成的集合，若基链矿工发现当前挖矿请求中的应用链标识在该集合中，说明该标识对应的应用链已经注册，本项验证通过，否则不通过。

若考虑基链以及应用链为并行链的情况，情况可能会更复杂一些，基链矿工可能还需要根据挖矿请求中的应用链标识R以及并行链链号k计算基链并行链链号n＝(ChainNoOffet+k)％N，若计算结果和自身真实的并行链链号一致，则确认自己可以向标识为R的应用链下的第k条并行链提供算力服务(仅指本项验证通过)，否则确认自己不可以向标识为R的应用链下的第k条并行链提供算力服务。其中，标识R用于确定公式中的ChainNoOffet参数的取值，因为该参数针对每条应用链设置。

其二，基链矿工首先根据挖矿请求中的确定提案组领导人的基链区块的高度，确定发送挖矿请求的应用链矿工被推选为提案组成员时依赖的第一选举字串；然后，基于挖矿请求中的应用链矿工公钥、第一证明字串以及自己计算出的第一选举字串调用VRF算法中的验证函数，验证挖矿请求中的第一可证明字串是否被伪造，验证函数输出True，表明第一可证明字串未被伪造，输出False表明第一可证明字串被伪造。

其中，第一选举字串的获取方式在前文已经介绍，只是之前是由应用链矿工进行计算，而此处是由基链矿工进行计算，在前文列举的实现方式中，第一选举字串来源于基链区块中的信息，显然对于本地保存有基链账本的基链矿工，这些信息是容易获得的，其细节不再阐述。若验证函数的输出结果表明第一可证明字串未被伪造，则本项验证通过，否则本项验证不通过。

在一些可选的方案中，还可以增加第三项验证内容：基链矿工首先根据挖矿请求中的应用链标识、并行链链号以及应用链矿工公钥三项信息，利用哈希算法计算发送挖矿请求的应用链矿工的矿工标识，该标识用于唯一标记一个应用链矿工。然后，基链矿工判断计算出的矿工标识是否在基链针对应用链配置的黑名单中，该黑名单的内容可以是一系列矿工标识的集合，若发送挖矿请求的应用链矿工的矿工标识在黑名单中，则基链矿工应拒绝为其提供服务，即本项验证不通过，否则本项验证通过。

下面举例说明黑名单的一种典型应用场景，对于参与方比较明确的应用链(即大致可以确定该应用链的矿工来源于哪些机构)，可以先开放挖矿一段时间，然后通过配置禁止新加入的应用链矿工挖矿(例如，将之前提到的首次记账权重置0)，再将已参与挖矿但来源于未知机构的应用链矿工纳入黑名单，以避免可能的安全风险。

在一些可选的方案中，还可以增加第四项验证内容：基链矿工首先根据挖矿请求中的应用链标识、并行链链号以及应用链矿工公钥三项信息，利用哈希算法计算发送挖矿请求的应用链矿工的矿工标识。然后，基链矿工判断计算出的矿工标识是否在基链针对应用链配置的实名制名单中，该实名制名单的内容可以是一系列矿工标识的集合，若发送挖矿请求的应用链矿工的矿工标识在实名制名单中，则基链矿工应同意为其提供服务，即本项验证通过，否则本项验证不通过。本项验证适用于要求应用链矿工实名挖矿的情形。

若以上各项验证内容若均获得通过，则基链矿工接纳当前的挖矿请求并进行后续处理。在介绍后续步骤前，先对前面已经提到的基链中设置的管理节点作一些说明：

管理节点的主要功能有两项：第一项功能是授权信息管理。管理节点对外提供应用链注册服务，应用链的管理者若希望运营的应用链得到基链的算力支持，应当向管理节点发起注册，管理节点若同意了应用链的注册请求，可以向基链矿工下发授权信息(这里的下发可以是管理节点主动下发，也可以是基链矿工请求其下发)，授权信息的内容包括进行过注册的应用链的信息(例如这些应用链的应用链标识)。

管理节点的第二项功能是配置信息管理，配置信息包括基链矿工所使用的一些预设参数，例如上面在选举提案组成员时提到的预设的范围值、预设的过滤比例、首次记账权重、提案组最大参选权重以及后文会提到的若干参数。虽然之前只介绍了在应用链上使用这些参数，但其中的部分或全部的参数在基链上也会使用，同一参数在应用链和基链上应当尽可能保持一致(因为参数在基链应用链和基链之间的同步需要时间，所以不排除在某些时刻同一参数的值在基链和应用链上是不同的，但参数在设计时可以预留一定余量)，具体保持参数取值一致的方法本申请不限定。各基链矿工可以从管理节点同步配置信息，或者也可以由管理节点主动广播。

授权配置信息(授权信息和配置信息的简称)对于应用链正常出块十分重要，因此在一些实现方式中，管理节点可以对其进行严格编号，以保障数据的完整性。例如，对配置信息中的每个参数的每次修改操作都进行记录，并顺序编号每次操作行为，使得对于参数的所有修改行为都可以进行追溯。又例如，对于基链的每条并行链，都有自己服务的一条或多条应用链并行链(这些并行链都可以拥有自己专属的一套配置信息)，因此可以对基链的并行链也进行编号，分别进行配置信息管理。

授权配置信息在区块链系统的运行过程中可能会调整，例如可由应用链的管理者将配置信息中参数的最新取值提交到管理节点。在常见的实现方式中，出于数据传输开销及系统稳定性等方面的考虑，授权配置信息更新后并不会实时从管理节点同步到基链矿工，而是在指定的时刻才进行同步。例如，基链矿工可以在基链的难度调整周期开始时向管理节点查询本地保存的授权及配置信息是否是最新版本，若不是最新版本则从管理节点同步最新版本的授权及配置信息；其中，基链矿工每隔预设数量的难度调整周期进行一次查询。管理节点在向基链矿工发送授权及配置信息时，还可以用自身私钥进行签名，避免信息遭到篡改。

基链矿工持续收集各应用链矿工发送的挖矿请求并缓存，这些挖矿请求可能针对于应用链不同的高度的区块(由挖矿请求中应用链待挖区块的高度一项指定)。基链矿工在打包基链区块时，首先根据基链账本中记录的、已经选出提案组领导人的应用链最高区块确定应用链待挖区块所在的新高度(命名为新高度是为了便于和后面的旧高度区分，并无特殊含义)，也即是确定当前打包的基链区块中要记录的是哪个高度的应用链区块的选举结果。在多数情况下，由于区块链中的区块高度是依次增长的，基链账本中记录的、已经选出提案组领导人的应用链最高区块的高度加1就可以得到新高度，但在某些实现方式中，允许应用链中加入空块，则需要加2甚至更多才能得到新高度。基链矿工可以专门维护一个变量，用于记录基链账本中记录的、已经选出提案组领导人的应用链最高区块的高度，当然也可以每次出块时从基链账本中查询。关于应用链中存在空块的情况，可以参考后文关于基链和应用链同频出块的内容。

确定好新高度后，基链矿工从缓存的挖矿请求中选择匹配于新高度的挖矿请求纳入针对新高度的待选举集合，所谓匹配是指挖矿请求中的应用链待挖区块的高度一项与新高度一致。

之后，基链矿工判断针对新高度的待选举集合中的请求个数是否不小于预设的最低矿工个数，若未达到最低矿工个数，则针对应用链新高度的区块选举提案组领导人失败，对于失败的处理方式在步骤S103中阐述，若达到最低矿工个数，则根据针对新高度的待选举集合中的每个挖矿请求中的第一可证明字串，确定应用链在新高度的区块的提案组领导人。对于不同的应用链，最低矿工个数可取不同的值，例如一个10至50之间的值。

其中，设置最低矿工个数这一参数用于验证是否有足够多的应用链矿工认同当前的挖矿状态，因为诚实的应用链矿工只有在应用链待挖区块的前一区块验证通过后才会请求挖下一区块，进而才有可能发出针对应用链待挖区块的挖矿请求，若针对新高度的待选举集合中的请求个数小于最低矿工个数，表明并没有足够多的应用链矿工认同当前要针对应用链新高度的区块进行挖矿，选举出的提案组领导人效力不足。

上面提到，基链矿工在打包基链区块时进行提案组领导人选举，但具体基链矿工何时打包基链区块，根据基链采用的不同机制可能有所不同，本申请对此并不作限定。例如，可能有多个基链矿工同时打包基链区块，当然最后只有获得记账权的基链矿工打包的区块会被认可；又例如，各基链矿工先竞争记账权，只有获得记账权的基链矿工才会打包基链区块，等等。

基链矿工根据针对新高度的待选举集合中的每个挖矿请求中的第一可证明字串，确定应用链在新高度的区块的提案组领导人，可以有不同的实现方式：

例如，若之前应用链矿工在推选提案组成员时使用了第二随机值，则基链矿工首先可以根据针对新高度的待选举集合中的每个挖矿请求中的第一可证明字串计算该挖矿请求对应的第二随机值，其具体过程可以是：先基于第一可证明字串利用预设的规则推导第一随机值，然后根据第一随机值以及发送挖矿请求的应用链矿工的提案组参选权重计算第二随机值(计算公式可参考前文)。之前也提到，提案组参选权重可以基于基链账本中的信息确定，例如，定义为应用链矿工在预设历史时间段内当选为提案组领导人的次数。基链矿工本地保存有基链账本，自然可以统计出应用链矿工的当选次数，当然为提高当选次数的统计速度，在基链矿工处也可以基于基链账本中的信息构建数据库或内存表格，方便查询。

基链矿工计算出每个挖矿请求对应的第二随机值后，会进一步利用一个预设的当选条件从中筛选出一个满足条件的第二随机值，并将该第二随机值对应的挖矿请求的发送者确定为应用链待挖区块的提案组领导人。当选条件可以是计算出的第二随机值最大、最小等，不作限定，但下面为简单起见，以选择最大的第二随机值为例进行阐述。

在一种可选方案中，基链矿工还可以进一步检验最大的第二随机值是否大于预设的最小当选随机值，若大于最小当选随机值，才正式确定提案组领导人选举成功，否则针对应用链新高度的区块选举提案组领导人失败，对于失败的处理方式在步骤S103中阐述。

其中，设置最小当选随机值这一参数用于提高攻击难度，即便敌手伪造大量账号实施女巫攻击，这些账号对应的应用链矿工也只能以低概率当选提案组领导人，特别是对于提案组参选权重取提案组领导人当选次数的情况，按照第二随机值的计算规则，新加入的应用链矿工对应的提案组参选权重很小，最终计算出的第二随机值也较小，从而很可能在验证最小当选随机值的过程中被排除在外，不会将其选为提案组领导人。当然，防范女巫攻击也有其他手段，例如，当基链矿工发现突然出现大量从未参与挖矿的应用链矿工请求挖矿时，直接拒绝这些应用链矿工的挖矿请求。

在一种可选方案中，针对每条应用链可以设置一个连续挖矿标记参数，该参数至少可以取两个值(如True和False)，分别表示允许同一应用链矿工连续当选提案组领导人以及不允许同一应用链矿工连续当选提案组领导人，这里的连续当选是指某一应用链矿工在应用链的连续两次出块(不考虑空块)中都被选为提案组领导人。若连续挖矿标记指示不允许同一应用链矿工连续当选提案组领导人，则基链矿工在根据最大的第二随机值确定了提案组领导人后，还要判断该提案组领导人是否为同一应用链的上一次提案组领导人选举中选出的提案组领导人，若是，则重新确定提案组领导人，将计算出的第二随机值次大的挖矿请求对应的应用链矿工确定为应用链待挖区块的提案组领导人。禁止同一应用链矿工连续当选提案组领导人有利于提高区块链系统的安全性，因为敌手更难连续获得记账权，结合最长链规则，双花攻击将更难实施。

步骤S103：基链矿工将保存有应用链待挖区块的选举结果以及选举依据的基链区块纳入基链账本中。

若在步骤S102中成功选出了应用链待挖区块的提案组领导人，基链矿工会将选举结果及选举依据打包到基链区块中，但需要注意，在基链采取某些共识算法时，有多个基链矿工都会打包基链区块，这些基链区块都记录应用链新高度的区块的选举结果，但最终只有获得记账权的基链矿工所出区块会在基链中传播并纳入基链账本，也就是说步骤S103中所述的基链区块实际上是指获得记账权的基链矿工所出区块，而步骤S102中选举提案组成员的基链矿工则是竞争记账权的矿工，而不一定是已获得记账权的矿工。

下面介绍基链区块中应用链待挖区块的选举结果以及选举依据的可能的形式，其中，选举结果主要用于指明提案组领导人的身份以及该提案组领导人是针对哪个应用链区块选举的，选举依据主要用于记录选举提案组领导人的凭证，从而可供他人验证选举结果是否正确。

在一种实现方式中，选举结果包括从应用链的提案组领导人发送的针对应用链待挖区块的挖矿请求中获取的提案候选信息，每个基链区块针对每条应用链最多记录一个选举结果，换句话说应用链上两个不同的区块的选举结果必然被记录在两个不同的基链区块中。选举结果作为选举结果列表中的一个表项保存在基链区块的区块体中，选举结果列表中可以包括多个表项，每个表项对应一条应用链上的一个待挖区块的选举结果。在一些现有区块链系统中，区块的区块体中保存交易，根据这些交易进行多级哈希运算可以构建merkle树，而merkle根(merkle树的根节点)保存在区块头中。在本申请中，也可以采取类似的方式设计基链区块的结构，即基链区块的区块体中保存选举结果列表的表项，而根据这些表项计算出的merkle根保存在区块头中，为方便后文描述，记作merkle_root1。

选举依据包括从针对新高度的待选举集合中的挖矿请求中获取的提案候选信息的集合，因为应用链待挖区块的提案组领导人就是根据待选举集合中的挖矿请求选出的，所以将这些挖矿请求中的提案候选信息作为选举依据是合理的。可选的，提案组领导人对应的提案候选信息也可以不包含在选举依据中，因为在选举结果中已经包含该信息。选举依据作为选举依据列表中的一个表项保存在基链区块的区块体中，对于同一个表项中的各个提案候选信息，由于其中的应用链标识、并行链链号以及应用链待挖区块的高度三项信息是相同的，因此在存储时也可以只存储一次以便节省存储空间。选举依据列表中可以包括多个表项，每个表项对应一条应用链上的一个待挖区块的选举依据。在同一基链区块中，选举结果列表和选举依据列表具有相同的长度，各表项之间也具有一一对应关系。基链区块的区块体中保存选举依据列表的表项，而根据这些表项计算出的merkle根保存在区块头中，为方便后文描述，记作merkle_root2。

既然区块头中包含了merkle_root1和merkle_root2，意味着计算区块的哈希值时merkle_root1和merkle_root2也会作为其来源字串，也就是说，一旦基链区块的内容确定，选举结果列表、选举依据列表均纳入区块链的不可篡改机制之中。这里，在基链区块头记录merkle_root1和merkle_root2，表明基链采用了双merkle树结构。

在本申请的方案中，基链用于为应用链提供算力，至于基链上是否可以发行数字货币是可选的，如果基链上也发行数字货币，则基链区块的区块体中还可以记录交易以及挖矿信息，挖矿信息可以记录在区块体的首个交易(也称Coinbase)中，其内容包括对出块者、挖矿奖励等的描述。根据区块体中的交易以及挖矿信息可以组织merkle树，计算出的merkle根保存在区块头中，记作merkle_root3，此时基链采用了三merkle树结构。关于交易的内容是目前的区块链系统中已有的，不再具体说明。

在每个基链矿工将接收到的区块纳入本地的基链账本之前，都会先执行区块内容的验证，其内容可以包括：验证选举依据中的各提案候选信息中的第一可证明字串是否伪造(方法如前文所述)；根据选举依据重复提案组领导人的选举过程，验证选出的领导人与选举结果中记录的是否一致；其他关于区块内容的常规验证(比如验证区块头内容、在区块中还包含交易时验证交易是否合法等)。若验证项目全部通过，基链矿工才会进行记账。

上面阐述了应用链待挖区块选举提案组领导人成功的情况，实际中新高度的应用链待挖区块选举失败也是可能的，在步骤S102中提到了两种可能的失败原因，也不排除其他导致选举失败的原因。若某条应用链的待挖区块选举提案组领导人失败，则在基链本次产生的区块中不会记录相应的选举结果及选举依据，若基链区块采用选举结果列表、选举依据列表的形式实现，两个列表中与该应用链对应的表项中都置空，当然，每条应用链上的提案组领导人选举是相互独立的，其他表项的内容不受影响。

若针对应用链在新高度的区块选举提案组领导人失败，一种简单的处理方式是推迟到基链下次出块时再次尝试为应用链新高度的区块选举提案组领导人。另一种复杂一些的处理方式是先尝试在应用链新高度之前的若干旧高度重选提案组领导人，若在某一旧高度处尝试成功，则重挖该旧高度处的应用链区块，若全都不成功，才推迟到基链下次出块时再次尝试为应用链新高度的区块选举提案组领导人。下面具体介绍后一种方式：

若基链矿工根据针对新高度的待选举集合中的挖矿请求选举新高度的区块的提案组领导人失败，则首先确定应用链中与应用链待挖区块相邻的且已经选出提案组领导人的区块所在的旧高度，其中，旧高度在应用链中低于新高度，上述相邻的含义是指在忽略应用链中的空块意义上的相邻。

确定好旧高度后，基链矿工从缓存的挖矿请求中选择匹配于旧高度的挖矿请求纳入针对旧高度的待选举集合，所谓匹配是指挖矿请求中的应用链待挖区块的高度一项与旧高度一致。注意，由于旧高度的应用链区块之前已经成功选举出提案组领导人了，所以在应用链矿工发起的所有针对旧高度的应用链区块的挖矿请求中，有一部份在之前成功选举时已经使用过了，这部分挖矿请求不会再重用(否则可能导致在旧高度重选提案组领导人结果不变)，即此时基链矿工收集的匹配于旧高度的挖矿请求是指哪些尚未被使用过的且针对于旧高度的挖矿请求。

之后，基链矿工根据针对旧高度的待选举集合中的挖矿请求重新选举应用链在旧高度的区块的提案组领导人，选举方式和之前选举应用链在新高度的区块的提案组领导人类似，不再展开阐述。若选举成功，则在本次所出基链区块中保存选举结果以及选举依据。若选举失败，则重复上面的过程，即先确定与当前选举提案组领导人的应用链高度的相邻的旧高度，然后针对该旧高度执行收集挖矿请求以及选举提案组领导人的操作(简称重挖旧块，相应的针对新高度选举提案组领导人的操作可以简称挖新块)，直至满足以下两个条件之一，停止重挖旧块：

其一，针对应用链的某一旧高度的区块选举提案组领导人成功。此时，在本次所出基链区块中保存该旧高度的区块的选举结果以及选举依据。可以理解的，若在应用链的某一旧高度选举提案组领导人成功，可能导致该旧高度的区块重新出块，应用链中串接在其后的区块也全部作废，需要重挖。

其二，重挖旧块达到预设的次数限制。比如，以该次数限制取3为例，假设应用链的新高度为100，若选举新高度的区块的提案组领导人失败，则在基链本次出块期间，基链矿工最多可在应用链的旧高度99、98、97处尝试上述重挖旧块操作，若在上述三个旧高度处仍然不能成功选举提案组领导人，则不再继续尝试。

最后，若是因为上面的第二种原因导致的停止重挖旧块，则在基链下次出块时再针对应用链在新高度的区块选举提案组领导人，若还是不能选举成功，又尝试重挖旧块，如此重复下去。

但需要注意的是，若基链本次出块选举提案组领导人未成功(不管是在新高度还是旧高度)，在基链本次出块时使用的针对新高度的挖矿请求在基链下次出块时就不会再被用于选举新高度的区块的提案组领导人(但在之后可以被作为针对旧高度的挖矿请求用于重挖旧块)，因为基链的出块导致基链账本的变化，挖矿请求中的第一可证明字串的值也会变化(因用于计算第一可证明字串的第一选举字串的值发生变化导致)，挖矿请求中的确定提案组领导人的基链区块的高度也会变化，基链矿工需要重新汇集新的挖矿请求。

相对应的，在基链本次出块时使用的针对旧高度的挖矿请求在基链下次出块时还可以重用，因为重挖旧块操作与基链区块的高度不绑定，即一个应用链旧高度的区块选举提案组领导人成功后，直接将选举结果和选举依据记录在基链最新的出块中，而不是记录在用于选举的挖矿请求中的指定高度(指挖矿请求中的确定提案组领导人的基链区块的高度一项)的基链区块中。而挖新块操作与基链区块的高度绑定，即应用链新高度的区块选举提案组领导人成功后，选举结果和选举依据必须记录在用于选举的挖矿请求中的指定高度(指挖矿请求中的确定提案组领导人的基链区块的高度一项)的基链区块中。

对于一个挖矿请求，基链矿工根据其中应用链待挖区块的高度这一项信息便可以区分其为针对新高度的挖矿请求还是针对旧高度的挖矿请求，从而采取不同的处理方式。对于针对旧高度的挖矿请求，由于挖矿请求中已经指定确定提案组领导人的基链区块的高度，根据该高度可获此时的第一选举字串(如，取该高度的前L区块中的信息)，进而用于请求中第一可证明字串的验证，验证通过后该挖矿请求即可被用于针对旧高度的区块的提案组领导人选举。对于挖新块和挖旧块的挖矿请求采取不同处理方式的原因在于：

在一些实现方式中，应用链矿工可以提前验证前一区块并提前发出针对新高度的挖矿请求(有关提前验证见后文内容)，从而请求有较充分的时间在基链中传播，因此虽然针对新高度的挖矿请求只在本次基链出块期间有效，针对新高度的区块选出提案组领导人的概率也较高。但针对旧高度的挖矿请求则未必能充分传播(已经有效传播的，在之前选出旧高度处的提案组领导人时已经使用过了，不能重复使用)，因此允许在基链多次出块的过程中，尽可能接收更多的针对旧高度的挖矿请求(这些请求之前可能未及时传播)，再加上若重挖旧块未成功，针对旧高度的挖矿请求可以重用，有利于在旧高度重新选举提案组领导人成功。

下面简单分析允许旧块重挖的原因：基链负责为应用链选出提案组领导人，但并不预设选出的提案组领导人在应用链中能否发挥作用(发挥作用指成功出块并且所出区块被纳入应用链账本)，若没有发挥作用，作为一种补救措施，推倒重来是允许的，重挖旧块就是实现推导重来的具体措施。导致提案组领导人在应用链中未能发挥作用的原因有多种：例如，基链认为应用链的某高度的区块已选出提案组领导人，但该提案组领导所出区块未通过验证组成员的验证，或者，验证组成员出具的检验报告因为通信原因未能有效传递导致该区块未通过验证(有关验证过程见后文内容)，即该区块未获应用链认可；又例如，虽然基链和应用链都遵循最长链规则，但二者并不是完全同步的，即基链的最长链并不一定对应应用链的最长链，从而基链按照最长链规则切换到新分支，该新分支上最近选出的提案组领导人可能对应于应用链最长链的旧高度上的区块(而不是最高区块)，并且还有可能和应用链最长链在该旧高度的区块上已确定的提案组领导人不同；当然还可能包括其他原因，不再列举。总之，允许在应用链上重挖旧块有利于消除应用链中的软分叉以及异常。

上面介绍了有关旧块重挖的内容，但在后文阐述时，将仍然聚焦于位于新高度的应用链待挖区块，对于重挖产生的旧块，处理方式和新块是类似的。

步骤S104：应用链矿工从基链矿工处同步确定应用链待挖区块的提案组领导人的基链区块的基链区块信息。

应用链矿工要获知应用链待挖区块的选举结果，需从基链矿工处同步基链区块信息，该基链区块信息来源于确定应用链待挖区块的提案组领导人的基链区块，基链区块信息中至少包括指明应用链待挖区块的提案组领导人的选举结果。根据在阐述图1时提到的，在一种实现方式中，应用链矿工直接从基链矿工处同步相关数据，在另一种实现方式中，应用链矿工间接从基链矿工处同步相关数据：基链中可以设置同步节点，应用链矿工可以从同步节点处同步相关数据，而同步节点的数据则同步自基链矿工或者其他同步节点，由于前一种实现方式可以视为基链矿工兼顾了同步节点的功能，因此下面主要介绍后一种方式的具体实现。

基链区块信息可以采用的形式至少包括以下三种之一：

其一，采用确定应用链待挖区块的提案组领导人的基链区块本身。同步节点从基链矿工处获取基链区块(可以是经过基链矿工验证的区块，当然也不排除同步节点自己验证)，然后应用链矿工再从同步节点处获取基链区块，最后在应用链矿工本地形成基链账本(当然，基链区块信息纳入账本前可做简单验证)。以上所述的获取，既可以是主动请求也可以是被动接收的方式。

其二，采用基链区块的区块头以及基链区块的区块体中的选举结果列表。选举结果列表的结构在上文已经介绍，该表中的每个表项对应一条应用链上的一个待挖区块的选举结果，其中也包括应用链待挖区块的提案组领导人的选举结果。相较于第一种形式，考虑到基链区块中的选举依据等内容应用链矿工未使用，因此可以不包含在基链区块信息中，以降低数据同步开销。

在一种可选的方案中，同步节点从基链矿工处或者其他同步节点处获取基链区块的区块头以及选举结果列表，然后应用链矿工再从同步节点处获取基链区块的区块头以及选举结果列表，最后在应用链矿工本地形成基链账本(当然，基链区块信息纳入账本前可做简单验证)，该基链账本中的区块的区块头和基链区块相同，区块体中则只包含基链区块中的选举结果列表，即是一种简化的基链账本。

其三，采用基链区块的区块头以及基链区块的区块体中针对应用链的片断数据。其中，片断数据包括选举结果列表中针对应用链待挖区块的提案组领导人的选举结果，以及，该选举结果与基链区块的区块头中基于选举结果列表计算出的merkle根(即前文的merkle_root1)之间的merkle路径。在基链区块信息的第二种形式中，选举结果列表中仍然包含各应用链中的选举结果，然而，对于应用链待挖区块所在的应用链，除它自身以外的其他应用链的上的选举结果并不需要关心，因此，只要在基链区块信息中保留区块头以及区块体中和该应用链有关的片断数据即可，这样可以进一步降低数据同步开销，在常见的应用场景中，一条基链可以服务于数百条应用链，若采取第三种基链区块信息的形式，数据传输量的节约相当可观。在片断数据中，merkle路径由一系列哈希值构成，可用于验证片断数据中针对应用链待挖区块的提案组领导人的选举结果未被伪造，在现有技术中，merkle路径可用于验证某个交易是否被伪造，这里的验证原理是类似的，不再具体阐述。

在一种可选的方案中，同步节点从基链矿工处或者其他同步节点处获取基链区块的区块头以及选举结果列表，然后应用链矿工再从同步节点处获取基链区块的区块头以及针对该矿工所在应用链的片断数据，最后在应用链矿工本地形成基链账本(当然，基链区块信息纳入账本前可做简单验证)，该基链账本中的区块的区块头和基链区块相同，区块体中则只包含针对本应用链的片断数据，即是一种进一步简化的基链账本。

无论基链区块信息采用何种形式，其中都包含应用链待挖区块的提案组领导人的选举结果，根据前文，该选举结果的内容包括从提案组领导人发送的针对应用链待挖区块的挖矿请求中获取的提案候选信息，至少包括应用链标识、并行链链号、应用链待挖区块的高度、确定提案组领导人的基链区块的高度、应用链矿工公钥以及第一可证明字串六项信息。

进一步的，在一些实现方式中，可以进一步将选举结果简化为只包含两项信息，提案组领导人的矿工标识以及应用链待挖区块的高度。其中，提案组领导人的矿工标识基于提案组领导人发送的挖矿请求中的应用链标识、并行链链号以及应用链矿工公钥三项信息，利用哈希算法进行计算，其算法和前文提到的应用链矿工的标识相同(因为提案组领导人本来也属于应用链矿工)；应用链待挖区块的高度则可以直接复制自提案组领导人发送的挖矿请求中的应用链待挖区块的高度一项。例如，在一种具体实现中，提案组领导人的矿工标识为一个32字节的哈希值，应用链待挖区块的高度为4字节整数，二者总共占36字节。假设基链服务于300条应用链，以基链区块信息采用上述第二种实现方式为例，300个表项的选举结果列表总共只占10.8KB，再加上区块头大约占11KB，这样少的数据量应用链矿工同步起来很容易。

不仅仅是基链向同步节点同步基链区块信息时其中的选举结果可以采用上述简化形式，同步节点向基链矿工或其他同步节点同步数据时，其中的选举结果也可以采用上述简化形式，甚至在基链矿工本地保存的基链区块中，选举结果列表中的表项(每个表项对应一选举结果)也可以采用上述简化形式，可以理解的，在选举结果列表中的表项采用选举结果的简化形式后，对基链区块的结构并无其他影响，区块头中仍然保存基于选举结果列表的表项计算出的merkle根。在基链矿工本地的基链区块中，由于选举依据列表中保存有选举结果的备份(选举结果对应的挖矿请求必然也是选举所依据的挖矿请求之一)，因此可随时恢复任一选举结果的原始形式。

对于基链中的同步节点，可以从基链中的挖矿节点或者其他同步节点同步数据，但是基链中的挖矿节点不会从同步节点同步数据(因为挖矿节点要保证数据的完整性，不能同步简化版本的数据)。每个节点在加入基链后，与其他节点之间建立连接，可以告知对方自己的属性(是挖矿节点还是同步节点)，从而节点之间在相互同步数据时会根据对方的属性采取不同的操作。

之前提到，应用链或基链上可以构建查询表格，用于查询应用链矿工在预设的历史时间段(对应若干基链区块)内当选提案组领导人的次数，作为应用链矿工的提案组参选权重。在这里给出该表格的一种可能的实现方式，该表格中包括三个字段：提案组领导人的矿工标识、当选提案组领导人的基链区块的高度(此处指区块在基链中的实际高度而非挖矿请求中指定的基链高度，因为重挖旧块操作的存在致使这两个高度不一定相同)以及应用链待挖区块的高度，三个字段中，最后一个字段为可选字段，前两个字段上可以设置索引，加快查询速度。

以应用链矿工为例，根据同步到的基链区块信息便可以构建该表格，基链区块信息中至少包括应用链待挖区块的选举结果。若该选举结果采用原始形式(即包含提案候选信息)，表格中的第一个字段的值根据提案候选信息中的应用链标识、并行链链号、应用链矿工公钥即可计算，第二个字段的值直接复制自提案候选信息中的确定提案组领导人的基链区块的高度，第三个字段直接复制自提案候选信息中的应用链待挖区块的高度。若该选举结果采用简化形式，则表格中的第一、第三个字段的值可以直接从选举结果中复制，并且由于应用链矿工本地保存有基链账本，从而根据基链区块信息中的区块头，基链区块信息形成的区块要串接到基链的哪个分支的哪个位置是明确的，第二个字段的值也可以确定。

步骤S105：应用链矿工参与应用链待挖区块的验证组成员的推选。

步骤S106：若确定应用链矿工被推选为应用链待挖区块的验证组成员，则对提案组领导人所出区块进行验证，验证结果写入检验报告并向其他应用链矿工广播检验报告。

以上两个步骤合并在一起阐述，在阐述之前，首先介绍一下全员验证的概念。在本申请的方案中，提供新区块(提案环节)与验证新区块(验证环节)是保障区块链系统安全性的最关键的两个环节，敌手控制这两项中任一项还无法直接达到破解目的，必须两项都控制才行。这两项中，验证环节对于安全性而言更重要，因为组织非法的区块内容从原理上分析难以完全抵御攻击，例如，敌手如果潜伏一个应用链矿工，只在它得知自己被推选为提案组领导人时才作恶，在提案环节中难以对其进行管控。但在验证环节中则可以管控，最严格的管控便是全员验证，即所有应用链矿工对任何新区块都做完整验证，验证通过才将其纳入应用链账本。然而，全员验证效率较低，虽然在一些现有的区块链系统(如比特币)中，对全员验证作了一定的限制：对历史区块(非最近产生的区块)只做简单验证，而非完整验证，但全员验证仍然对系统TPS影响很大。

在本申请的方案中，在安全性和TPS之间进行了折衷考虑，采用从全部的应用链矿工中组建验证组的方式进行区块验证，验证组是满足预设规则的应用链矿工的集合，只有验证组成员有权对新出区块做完整验证并出具检验报告，其他应用链矿工只是简单地收集检验报告并根据检验报告适当统计后得出最终的验证结论(当然验证组成员也会收集检验报告)。验证组中的应用链矿工的数量可以只占应用链矿工总数量的一小部分，例如1/10，这样在不考虑节点间通信瓶颈的前提下，区块链系统的TPS也能够大约提升接近10倍。

当然，本申请中也可以增设全员验证标记这一参数，该参数至少可以取两个值(如True和False)，分别表示采取全员验证和不采取全员验证，其中不采取全员验证即采取组建验证组的方式验证。若全员验证标记指示采取全员验证，则每个应用链矿工都会对提案组领导人所出区块进行完整验证(正在重建区块链数据库，处于追赶出块进度状态的矿工可以除外)。在后文中主要介绍采取组建验证组进行验证的方式。

对于正在被挖矿的应用链待挖区块而言，验证组是指有权对提案组领导人所出区块进行验证并生成检验报告的应用链矿工的集合。提案组领导人所出区块其实就是提案组领导人打包的应用链待挖区块，但根据应用链不同的实现方式，可能有多个应用链矿工针对应用链同一高度打包应用链待挖区块，即可能产生多个应用链待挖区块，故此处在名称上稍加区分。

推选应用链待挖区块的验证组成员可以分为至少一轮进行，当应用链矿工同步到确定应用链待挖区块的提案组领导人的基链区块信息后，就参与前P轮验证组成员的推选，之后应用链矿工每同步到一个基链区块信息，就参与新一轮验证组成员的推选，若满足以下循环终止条件之一，应用链矿工不再参与新一轮验证组成员的推选：

其一，应用链矿工在已参与的推选轮次中确定自身被推选为验证组成员；其二，应用链矿工根据当前已接收到的检验报告能够得出提案组领导人所出区块验证通过的结论；其三，应用链矿工已参与的推选轮次已经达到预设的最大轮次MaxRounds(MaxRounds为正整数)。

其中，1≤P≤MaxRounds，若应用链矿工在已参与的推选轮次中确定自身被推选为验证组成员，则对提案组领导人所出区块进行验证，向其他应用链矿工广播生成的检验报告(即执行步骤S106)。若P＝1表明应用链矿工不可提前参与后续轮次的验证组成员的推选，若P>1表明应用链矿工可以提前参与后续轮次的验证组成员的推选。下面先介绍P＝1的情况：

验证组成员的推选可视为由基链出块驱动的，基链每出一块(应用链矿工也会对应同步基链区块信息)就进行一轮验证组成员的推选，每一轮验证组成员的推选，都可能选出若干验证组成员，若进行多轮推选，各轮次选出的验证组成员是叠加的，即随着轮次的增长验证组中的成员会越来越多，在某一轮次中被选为验证组成员的应用链矿工，在后续轮次中就不必参加验证组成员的推选了(上述循环终止条件一)，验证组成员的身份可疑一直保留。

一旦被选为验证组成员，应用链矿工就会对提案组领导人所出区块进行验证、出具检验报告并在应用链中广播，每个验证组成员只生成一份检验报告，关于生成检验报告的过程稍后再进行阐述。应用链矿工在参选验证组成员的同时，同时也在接收验证组成员发送的检验报告，若根据已经收集到的检验报告能够确定提案组领导人所出区块验证通过，就不必继续参选验证组成员了(上述循环终止条件二)。例如，当前刚进入第三轮验证组成员推选，某个尚未被选为验证组成员的应用链矿工可以根据在前两轮推选中被选为验证组成员的应用链矿工出具的检验报告判断提案组领导人所出区块是否验证通过。

推选验证组成员的轮次有限制，最多不能超过预设的最大轮次(上述循环终止条件三)，超过则当前应用链矿工结束对应用链待挖区块的验证组成员的推选。

允许分成进行多轮验证组成员的推选有利于自适应消除基链和应用链中的软分叉，具体原理在后文阐述。

在应用链待挖区块的任一轮验证组成员的推选过程中，每个应用链矿工根据预设的算法自主确定是否为验证组成员，不依赖于其他应用链矿工，在一种典型的实现方式中，上述预设的算法可采用可验证随机函数VRF算法，前文在介绍提案组成员推选时已经介绍过该算法。

应用链矿工首先基于自身的私钥(对应VRF算法中的PrivateKey)以及利用预设规则确定的第二选举字串(对应VRF算法中的info)调用VRF算法中的证明函数获得第二可证明字串(对应VRF算法中的proof)。之后，应用链矿工基于第二可证明字串利用预设的规则推导第三随机值，并根据第三随机值确定应用链矿工是否被推选为应用链待挖区块的验证组成员，上述预设的推导规则具有确定性(但具体是何种规则不限定)，因此对于同样的输入，推导出的第三随机值也具有确定性，进而在第三随机值的基础上得到的验证组成员的推选结果也具有确定性。

上述第二选举字串为一个已知字串，其获取规则是确定的。在一种实现方式中，第二选举字串根据以下信息计算：提案组领导人的矿工标识、确定提案组领导人的基链区块的高度(此处指区块在基链中的实际高度而非挖矿请求中指定的基链高度，因为重挖旧块操作的存在致使这两个高度不一定相同)、应用链待挖区块的高度以及推选验证组成员的轮次编号。若基链区块信息中针对应用链待挖区块的选举结果为原始形式(即包含提案候选信息)，则根据选举结果中的应用链标识、并行链链号、应用链矿工公钥三项信息计算上述第一项信息，再加上从选举结果中获取上述第二、三项信息，并结合当前推选验证组成员的轮次编号计算第二选举字串；若选举结果为简化形式，则从选举结果中获取上述第一、三项信息，上述第二项信息就是保存选举结果的基链区块的高度，再结合当前推选验证组成员的轮次编号计算第二选举字串。推选验证组成员的轮次可以从0开始编号，并按照自然数的顺序递增，应用链矿工在参与不同轮次的验证组成员推选时，该编号的取值也要随之变化。

在一些实现方式中，可以直接根据第三随机值确定应用链矿工是否为应用链待挖区块的提案组成员。在另一些实现方式中，对于每个应用链矿工可以计算一个其专属的验证组参选权重，每个应用链矿工可以根据第三随机值以及自身的验证组参选权重确定自己是否为应用链待挖区块的验证组成员，其中，应用链矿工被选为验证组成员的概率与该验证组参选权重的取值正相关。

例如，某个应用链矿工的验证组参选权重可根据该矿工当前持有数字货币的数量进行计算(前提是应用链上要发行数字货币)，并规定：若应用链矿工当前未持有数字货币，则验证组参选权重取0。在这一规定下，一种典型的实现方式是：应用链矿工的验证组参选权重priority2和其持币量stake之间成正比，即：

priority2＝C×stake

其中C为一正常数。当然在满足前述规定的情况下，priority2和stake之间的也可以为其他关系。在这种实现方式中，持币较多的应用链矿工计算出的验证组参选权重也较大，从而被选为验证组成员的概率也更高，因为持币越多表明该矿工与应用链利益关系越密切，其作弊可能性也越小。

在一些实现方式中，应用链上还可以预设最小持币量这一参数，若应用链矿工当前持有数字货币的数量小于预设的最小持币量，则应用链矿工不能参与验证组成员的推选。典型的，未持有数字货币的应用链矿工不能参与提案组成员的推选，此举可以杜绝伪造大量新账号参与挖矿的女巫攻击。当然，在一些替代方案中，预设验证组参选权重的最小值也能够起到类似的效果。

在一些实现方式中，应用链上还可以预设验证组最大参选权重这一参数，即为验证组参选权重设置一个上限，若计算出的验证组参选权重超过该上限(例如，应用链矿工因持有大量数字货币而使得验证组参选权重大于预设的验证组最大参选权重)，则将验证组参选权重设置为验证组最大参选权重。避免大量持币的应用链矿工在验证组成员的推选中优势过大，剥夺其他应用链矿工当选验证组成员的机会。

验证组参选权重当然也可以采用其他定义，但根据应用链的持币数量进行计算是比较方便的，因为应用链账本记录本链所有账号的未花费的交易输出(UnspentTransaction Output，简称UTXO)，从而所有应用链矿工都能查验他人的持币数量并计算相应的验证组参选权重，进而可对他人是否有资格当选验证组成员等进行验证。

应用链矿工根据第三随机值以及自身的验证组参选权重确定自己是否为应用链待挖区块的验证组成员也可以有不同的实现方式，在一种实现方式中，可以这样实现：

首先，利用如下公式计算第四随机值RandValue4：

RandValue4＝(RandValue3％ExpectedRange2)+priority2

其中，RandValue3为第三随机值，ExpectedRange2为预设的范围值，priority2为验证组参选权重，％表示取余数运算。

若计算出的RandValue4满足如下条件，则确定当前应用链矿工被推选为应用链待挖区块的提案组成员：

RandValue4>ExpectedRange2-(ExpectedRange2*1/M2)

其中，M2为预设过滤比例。

不难看出，RandValue4和RandValue2的计算公式基本相同，只是其中的预设参数ExpectedRange2可以和ExpectedRange1取不同值，M2可以和M1取不同值。

还可以看出，验证组成员的推选过程和提案组成员的推选有类似之处，并且基链区块中记录有选举依据(由于只有提案组成员才会发送挖矿请求，因此相当于记录了提案组成员)，故不排除在一些实现方式中直接将全部提案组成员作为验证组成员，略过验证组成员推选的步骤。但在上面的方案中，将验证组成员的推选和提案组成员的推选实现为相互独立的(即一个应用链矿工是否为验证组成员和它是否为提案组成员无关)，综合考虑如下方面：

其一，每个应用链矿工独立地确认自己是否为验证组成员，相较于集中式地确认验证组成员(指直接将提案组成员批量确定为验证组成员)安全性更高；其二，上述验证组成员的推选可分多轮进行，为消除软分叉提供了自适应机制(见后文阐述)；其三，基链区块的选举依据列表中列出提案组成员，是为了预防敌手作弊，使得各基链矿工都可以实施验证，并非为了选举验证组成员的方便。

若一个应用链矿工在某一轮推选中确认了自己为应用链待挖区块的验证组成员，即可对应用链待挖区块的提案组领导人所出区块进行验证。在不同的实现方式中，提案组领导人打包应用链待挖区块的时机可能不同：例如，在第一种方式中，任一应用链矿工在确认自己被推选为提案组成员后，都会打包应用链待挖区块，但最终只有提案组领导人打包的应用链待挖区块会在应用链中传播并在验证通过后被记账，应用链矿工在同步基链区块信息后便可获知哪个应用链矿工当选提案组领导人，再结合区块的出块者信息便可以确定哪个是提案组领导人所出区块；在第二种方式中，只有提案组领导人才会打包应用链待挖区块，而应用链矿工在同步基链区块信息后便可获知自身是否为提案组领导人。

可选的，对于第一种方式，提案组成员在打包好应用链待挖区块后，还可以将应用链待挖区块广播给它周边的局部范围内的其他应用链矿工。此处的局部范围可以定义为消息转发意义上的局部范围，例如，提案组成员在广播应用链待挖区块的广播消息中指定一个预设的转发次数，应用链待挖区块每经过一次转发，广播消息中的转发次数就减去1，在转发次数减少至0时停止广播应用链待挖区块。当然，也不排除局部范围采取其他定义方式，例如地理意义上的，网络拓扑意义上的范围，等等。

对应用链待挖区块提前(指在确定出提案组领导人之前)进行局部扩散有利于改善区块链系统的安全性，具体分析如下：

首先定义定向腐蚀的概念：定向腐蚀是指敌手对某个或某些特定的应用链矿工进行的某种恶意行为。例如，对某个应用链矿工所在挖矿节点进行网络攻击(例如分布式拒绝服务DDoS攻击)，导致其因消息拥塞等原因无法正常工作，从而应用链矿工无法正常出块，有利于敌手进一步进行破解行为；又例如，对某个应用链矿工进行贿赂，指示其按照自己的要求进行记账等。

在本申请方案常见的实现方式中，基链采用公链，拥有海量矿工，并且结合基链的区块链数据来决定提案组成员如何选出(具体可参考前文第一选举字串的获取方式)，即结合了基链的算力因素，敌手难以控制第一选举字串按照其期望的方式去取值，从而无法按照其意愿将特定的应用链矿工选为提案组成员。并且，即使敌手可以在提前于出块的某一时间获知第一选举字串，由于应用链矿工在推导第一可证明字串时除了用到第一选举字串，还需结合自身私钥，因此敌手无法仅根据第一选举字串推导第一可证明字串，进而无法推导作为应用链矿工当选提案组成员的依据的第一随机值或第二随机值，也就难以提前确定某个应用链矿工是否会当选提案组成员，从而无法对其进行定向腐蚀。

然而，一旦提案组成员向基链矿工发送挖矿请求，提案组成员身份就会暴露(例如，敌手可以部署特定应用程序监听挖矿请求，或者在基链上专门部署一个属于他自己的矿工来接收请求)，从而敌手可以对提案组成员进行定向腐蚀。

为解决这一问题，要求应用链矿工在确定自身为提案组成员后，立即打包应用链待挖区块并在有限范围内扩散该区块(之所以限定为局部范围，主要是为了避免消耗过多带宽资源)。由于进行了提前扩散，每个应用链矿工可能收到多个同一高度的应用链待挖区块，由不同的提案组成员打包产生，但应用链矿工在同步基链区块信息后便可确定提案组领导人，应用链矿工将只保留提案组领导人打包的应用链待挖区块(如果应用链矿工本地有缓存该区块的话)并向其他应用链矿工广播该区块(此时是全链广播)，丢弃其他人打包的应用链待挖区块。

这样，即使敌手在提案组成员请求挖矿时获知了其身份，由于应用链待挖区块已经在应用链中扩散，定向腐蚀达不到效果。比如，即使敌手通过某种方式确定了提案组领导人，对提案组领导人所在的挖矿节点进行DDoS攻击，虽然可能导该节点瘫痪，但其周边范围内的应用链矿工仍然可以扩散其所出区块，不受影响；同理，对提案组领导人进行贿赂也是徒劳。

可选的，可以在打包的应用链待挖区块的首个交易(也称Coinbase)中保存应用链矿工被推选为提案组成员的证据，例如，提案候选信息中的各信息项、提案组参选权重、第一随机值、第二随机值等，供他人日后实施验证。

提案组领导人在广播所出区块时，还在广播消息中附带提案组领导人发送的针对该区块的挖矿请求中的提案候选信息用于区块验证，后续提案组领导人所出区块在应用链中传播时，该提案信息也一直附带。被推选为应用链待挖区块的验证组成员的应用链矿工对提案组领导人所出区块进行验证，至少包括以下验证项目：

其一，首先根据上述提案候选信息中的确定提案组领导人的基链区块的高度，确定提案组领导人被推选为提案组成员时依赖的第一选举字串。然后，基于提案候选信息中的第一可证明字串、提案候选信息中的应用链矿工公钥以及第一选举字串调用VRF算法中的验证函数，验证提案候选信息中的第一可证明字串是否被伪造，若未被伪造，则本项验证通过，若被伪造，则本项验证不通过。本项验证内容可参考基链矿工对于挖矿请求中第一可证明字串的验证过程，上文已阐述。

其二，验证提案候选信息中的应用链矿工公钥对应的应用链矿工是否为提案组领导人所出区块的创建者。在本申请的方案中，可以设计一定的机制指明应用链区块的创建者：

例如，在区块头中保存表征区块创建者身份的公钥信息(如可以是公钥本身，可以是公钥的哈希值等)，验证组成员根据提案候选信息中的应用链矿工公钥也可以获得相应的公钥信息，将二者进行对比，若一致，则可确认提案候选信息中的应用链矿工公钥对应的应用链矿工就是提案组领导人所出区块的创建者，本项验证通过，否则可确认该应用链矿工不是提案组领导人所出区块的创建者，本项验证不通过。

又例如，上面提到，提案组领导人在广播所出区块时，在广播消息中附带相应的提案候选信息，此外还可以再附带一项提案组领导人利用自身的私钥对所出区块的签名(如可以是对整个区块的签名，可以是对区块头的签名，可以是对区块头中的某些字段的签名等)。验证组成员利用提案候选信息中的应用链矿工公钥验证广播消息中携带的对提案组领导人所出区块的签名是否正确，若正确，则可确认提案候选信息中的应用链矿工公钥对应的应用链矿工就是提案组领导人所出区块的创建者，本项验证通过，否则可确认该应用链矿工不是提案组领导人所出区块的创建者，本项验证不通过。

此外，上述在区块头中保存区块创建者的公钥信息的实现方式，也不排除将公钥信息替换为创建者的矿工标识，利用提案候选信息也可以计算出一个矿工标识用于验证。

其三，首先根据提案候选信息中的确定提案组领导人的基链区块的高度从验证组成员本地的基链账本中查询提案组领导人(当然，从前文提到的用于查询提案组领导人当选次数的表格中进行查询也是可以的)，然后验证查询出的提案组领导人与提案候选信息确定的提案组领导人是否一致。

对于提案组领导人的身份，可以采用公钥或者矿工标识来表示。对于采用公钥表示的，本项验证这样实现：

首先根据提案候选信息中的确定提案组领导人的基链区块的高度从本地的基链账本中查询提案组领导人的公钥(此时基链账本中的选举结果采用原始形式)，然后验证查询出的提案组领导人的公钥与提案候选信息中的应用链矿工公钥是否一致，若一致，则确认查询出的提案组领导人与提案候选信息确定的提案组领导人一致，本项验证通过，否则确认两个提案组领导人不一致，本项验证不通过。

对于采用矿工标识表示的，本项验证这样实现：

首先根据提案候选信息中的确定提案组领导人的基链区块的高度从本地的基链账本中查询提案组领导人的矿工标识(此时基链账本中的选举结果采用简化形式)，然后基于提案候选信息中的应用链矿工公钥、应用链标识以及并行链链号三项内容，利用哈希算法计算提案组领导人的矿工标识，最后验证查询出的提案组领导人的矿工标识与计算出的提案组领导人的矿工标识是否一致，若一致，则确认查询出的提案组领导人与提案候选信息确定的提案组领导人一致，本项验证通过，否则确认两个提案组领导人不一致，本项验证不通过。

其四，验证提案组领导人所出区块中的所有交易是否正确，若正确则本项验证通过，否则本项验证不通过。具体验证内容包括验证是否存在伪造交易、实施双花等，此项验证和现有的区块链系统中对交易的验证类似，不作具体说明。

进一步的，在上述第一项验证通过后(注意以上验证没有必然的先后顺序，第一项验证未必是最先通过的)，还可以根据提案候选信息中的第一可证明字串推导第一随机值，然后根据第一随机值以及提案候选信息所确定的提案组领导人的提案组参选权重计算第二随机值(具体公式见前文)，最后验证第二随机值是否符合当选提案组领导人的基本要求，例如，是否满足最小当选随机值的要求，若满足则本项验证通过，否则本项验证不通过。在首次介绍提案候选信息的构成时曾经提到，在一些实现方式中，提案候选信息中还可以包括应用链矿工被选为提案组成员时依赖的第二随机值，对于这些实现方式，在推导出第二随机值后，还可以先验证一下推导出的第二随机值和提案候选信息中的第二随机值是否相同。

若以上所有验证项目的验证结果均为通过，则验证组成员生成检验结论为检验通过的检验报告，否则生成检验结论为检验未通过的检验报告，验证组成员生成检验报告后，在应用链中广播该检验报告。

从上述验证组成员的推选过程可知，应用链矿工参与针对应用链待挖区块的每一轮验证组成员的推选时，导致其算出的作为当选与否的依据的第三随机值或第四随机值不同的原因在于计算第二选举字串时使用的推选验证组成员的轮次编号一项，其余各项在推选期间可视为固定值。从而，仅从原理上讲，应用链矿工参与验证组成员的推选并不受同步基链区块信息的限制，应用链矿工只需自行调整轮次编号值，就可以确定自己在某一轮次的推选中是否会被选为验证组成员，即使原本用于指示开始该轮次推选的基链区块信息尚未同步，简称为提前验证，对应于前文提到的P>1的情况。

比如，P＝3，当应用链矿工同步到确定应用链待挖区块的提案组领导人的基链区块信息(假设对应基链上高度为H的区块)后，就可以参与第一轮(轮次编号为0)、第二轮、第三轮验证组成员的推选(当然，比如第一轮就确认自己是验证组成员，就不必参加后续轮次的推选了)，不必等待原本用于指示开始第二轮、第三轮验证组成员推选的基链区块信息(H+1、H+2高度的基链区块对应的基链区块信息)，若不提前参选，此时它只能参与第一轮验证组成员的推选；当应用链矿工同步到高度为H+1的基链区块对应的基链区块信息后，就可以参与第四轮验证组成员的推选，若不提前参选，此时它只能参与第二轮验证组成员的推选；以此类推。

一旦应用链矿工在某轮推选中确定了自己为验证组成员，就对提案组领导所出区块进行验证并广播检验报告，相较于P＝1的情况，这里的检验报告可视为提前广播出去的。提前广播检验报告有利于挖矿请求在基链的充分传播，具体原因在步骤S107中再进行分析。

步骤S107：应用链矿工接收检验报告，若根据检验报告判断提案组领导人所出区块是否验证通过。

步骤S108：若应用链矿工确定提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。

以上两个步骤合并在一起进行阐述。在一种实现方式中，检验报告可以包括如下信息项：提案组领导人的矿工标识、确定提案组领导人的基链区块的高度、应用链待挖区块的高度、推选验证组成员的轮次编号、生成检验报告的验证组成员的公钥、应用链矿工被推选为验证组成员时依赖的第二可证明字串、应用链待挖区块的哈希值、检验结论以及利用验证组成员的私钥对检验报告的签名。

其中，前四项为应用链矿工在参与验证组成员推选时计算第二选举字串时所用，附带在检验报告中供他人验证，推选验证组成员的轮次编号即为应用链矿工最终确认自己是验证组成员的推选轮次的编号；应用链待挖区块的哈希值用于唯一标识一个应用链区块，应用链矿工在步骤S107中统计检验报告的结论时可利用该哈希值区分针对不同的应用链区块的报告；检验结论即通过和不通过两种结论，上文已述；利用验证组成员的私钥对检验报告的签名可以指对检验报告中除签名本身以外的其他信息的签名，用于防止检验报告被篡改。

应用链矿工在使用检验报告之前，可以先对检验报告的内容进行验证，验证的项目可以包括：

其一，利用检验报告中的生成检验报告的验证组成员的公钥验证报告中的签名是否正确，若正确，则本项验证通过，否则本项验证不通过。

其二，首先根据检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询提案组领导人(当然，从前文提到的用于查询提案组领导人当选次数的表格中进行查询也是可以的)，然后验证查询出的提案组领导人与检验报告所确定的提案组领导人是否一致。

在应用链本地的基链账本中，若选举结果采用原始形式(即包含提案候选信息)，本项验证这样实现：

首先根据检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询提案组领导人的公钥，然后获取应用链矿工挖矿所在的应用链标识以及并行链链号(这两项内容每个应用链矿工都可自行获得)，基于这三项信息利用哈希算法计算提案组领导人的矿工标识，然后验证计算出的提案组领导人的矿工标识与检验报告中的提案组领导人的矿工标识是否一致，若一致，则确认查询出的提案组领导人与检验报告确定的提案组领导人一致，本项验证通过，否则确认两个提案组领导人不一致，本项验证不通过。

在应用链本地的基链账本中，若选举结果采用简化形式，本项验证这样实现：

首先根据检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询提案组领导人的矿工标识，然后验证查询出的提案组领导人的矿工标识与检验报告中的提案组领导人的矿工标识是否一致，若一致，则确认查询出的提案组领导人与检验报告确定的提案组领导人一致，本项验证通过，否则确认两个提案组领导人不一致，本项验证不通过。

其三，首先根据检验报告中的提案组领导人的矿工标识、确定提案组领导人的基链区块的高度、应用链待挖区块的高度以及推选验证组成员的轮次编号四项信息计算生成检验报告的应用链矿工被推选为验证组成员时依赖的第二选举字串，然后基于第二选举字串、检验报告中的生成检验报告的验证组成员的公钥以及检验报告中的第二可证明字串调用VRF算法中的验证函数，验证检验报告中的第二可证明字串是否被伪造，若未被伪造，则本项验证通过，否则本项验证不通过。

其四，基于检验报告中的第二可证明字串推导第三随机值，并根据第三随机值验证生成检验报告的应用链矿工是否为验证组成员，若是验证组成员，则本项验证通过，否则本项验证不通过。本项验证即重复验证组成员的推选操作，判断应用链矿工是否有确实有资格出具检验报告。

在一种实现方式中，应用链矿工可以先推导第三随机值，然后根据第三随机值以及自身的验证组参选权重计算第四随机值(具体公式见前文)，最后根据第四随机值验证生成检验报告的应用链矿工是否为验证组成员。

若以上所有验证项目的验证结果均为通过，则应用链矿工认可该检验报告的效力，并执行后续步骤，否则认为检验报告无效，可将其丢弃。

应用链矿工汇总接收到的针对提案组领导人所出区块的检验报告进行统计并获得验证结果，具体可以这样实现：

若收到的检验报告中检验结论为通过的报告份数不小于最小成功验证数，以及，检验结论为不通过的报告份数不大于最大失败验证数，则确定提案组领导人所出区块验证通过。

若收到的检验报告中检验结论为通过的报告份数小于最小成功验证数，以及，检验结论为不通过的报告份数不大于最大失败验证数，则继续等待新的检验报告，除非等待了一段预设的时长(该时长后文有说明)后，检验结论为通过的报告份数仍然小于最小成功验证数，则确定提案组领导人所出区块验证未通过。

若收到的检验报告中检验结论为不通过的报告份数大于最大失败验证数，则确定提案组领导人所出区块验证未通过。

其中，最小成功验证数以及最大失败验证数可以为预设值，或者，也可以根据一预设时间段内被选为提案组领导人的应用链矿工的个数再结合一定的比例进行推算。最小成功验证数表征验证组成员对区块的认可程度，最大失败验证数表征一个容忍范围，若最大失败验证数设置为0也是可以的，但设置为非0值主要是为了防止少数验证组成员作恶(故意出具检验结论为不通过的报告)导致应用链无法正常出块。

应用链矿工可以每收到一份检验报告就根据上面的规则判断能否得出验证结论，或者，应用链矿工也可以先缓存接收到的检验报告，在适当的时刻进行判断(例如定期判断)。对于接收到的检验报告，应用链矿工可以根据其中的推选验证组成员的轮次编号，优先处理靠前轮次的检验报告，避免敌手将后面轮次的报告提前广播而影响验证结果。

若应用链矿工根据检验报告确定提案组领导人所出区块验证通过，则将该区块纳入应用链账本中，并可以开始下一应用链待挖区块的提案组成员的推选。若应用链矿工根据检验报告确定提案组领导人所出区块验证未通过，则弃用提案组领导人所出区块，若该区块已经纳入应用链账本并且之后还串接了其他区块则一同弃用，并重新开始应用链待挖区块的提案组成员的推选。其中，弃用提案组领导人所出区块之后的区块对应验证通过结论被推翻的情况，在后文有具体说明。

应用链矿工统计检验报告可视为一个统计投票过程，投票者为验证组成员，对该过程更一般的描述如下：

应用链矿工首先确定收到的检验报告的在验证过程中所占的票数，然后进行判断：若收到的检验报告中检验结论为通过的报告所占的总票数不小于最小成功验证数，以及，检验结论为不通过的报告所占的总票数不大于最大失败验证数，则确定提案组领导人所出区块验证通过。当然还有需要继续等待以及未通过的情况，和上文类似，这里省略不写。

在最常见的情形中，一份检验报告可以对应一票，在上文已经介绍。但在另一些实现方式中，每份检验报告所占的票数可以设置为与生成该检验报告的验证组成员当前持有的数字货币的数量正相关。让持币多的验证组成员出具的检验报告占据一定优势的原因在于：持币越的提案组成员与应用链利益关系越密切，其作弊可能性也越小。

可选的，检验报告在验证过程中所占的票数可以利用如下公式计算：

vote_num＝1+stake/leverage

其中，vote_num为检验报告所占的票数，stake为生成检验报告的验证组成员当前持有的数字货币的数量，持币量记录在应用链账本中，任一应用链矿工均可查询，leverage为预设的票数调节比例。

为简单起见，在后文阐述时，还是以一份检验报告一票的方式为例进行阐述，若检验报告的份数与票数并不一致，对相关内容进行适应性调整即可。

对于应用链某一高度的区块，应用链矿工在未收到足够多的针对该区块的检验报告之前，并不能精确得出该区块是否会验证通过的结论，这导致得出验证结论可能会等上比较长的时间。在一种可选的方案中，若应用链矿工发现收到的检验报告中检验结论为通过的报告份数占最小成功验证数的比例已不小于预设的已验证比例(当然同时也要满足检验结论为不通过的报告份数不大于最大失败验证数)，则提前开始下一应用链待挖区块的提案组成员的推选以及打包区块等工作。其中，已验证比例可以取50％、60％等等。大多数情况下，应用链区块的验证结论都是通过，因此提前推选出的提案组成员多数情况下是可靠的，后续被撤销提案组成员身份的概率不高，上述举措有利于提高验证和提案工作的并行性，进而提升区块链系统的TPS。

之前在阐述步骤S105和S106时，提到了提前验证的实现方式(P>1),验证组成员可以提前对提案组领导所出区块进行验证并广播检验报告，每个应用链矿工根据这些检验报告可能提前几轮就知道区块的验证结果，若验证结论为通过，应用链矿工即可明确下次应该在应用链哪个高度挖矿，从而可以提前参与下一应用链待挖区块的提案组成员的推选，进而提前向基链矿工发出针对下一应用链待挖区块的挖矿请求，因此挖矿请求有更多的时间在基链中传播，有利于基链矿工选出提案组领导人。

但需要注意的是，尽管应用链矿工可以提前收到检验报告，并且可以根据这些检验报告得出提案组领导人所出区块验证通过的结论，但还是要等待检验报告生效时刻到来，才能执行将区块纳入应用链账本、参与下一应用链待挖区块的提案组成员的推选等工作。其中，检验报告在应用链矿工同步到报告生成轮次对应的基链区块信息后生效，而报告生成轮次是指生成检验报告的应用链矿工被推选为验证组成员的推选轮次。

例如，应用链矿工提前收到了在第二轮验证组成员推选中被选为验证组成员的应用链矿工发送的检验报告，并且根据该份报告可以确定提案组领导人所出区块验证通过，也不能立刻执行后续步骤，而需要等待应用链矿工同步到原本用于指示开始第二轮验证组成员推选的基链区块信息。但是，一旦该同步到该基链区块信息，应用链矿工可立即给出提案组领导人所出区块验证通过的结论，所以在时间上还是有提前的，至多可以提前一个基链出块时间。

因此，所谓提前验证本质上只是提高了验证组成员推选和后续步骤之间的并行化程度，并未破坏基链出块和验证组成员推选之间的同步关系。

在采用了提前验证机制后，虽然应用链矿工可能提前获知提案组领导人所出区块的验证结论，从而有时间进行作弊，例如更改一下应用链待挖区块的高度，但由于区块链的共识机制需要多个矿工认同才能确认结果，所以即使个别应用链矿工作弊，其他诚实矿工不与它串通，作弊行为也是徒劳：比如，个别不诚实矿工改变应用链待挖区块的高度，而多数诚实矿工并不在该高度上开展下一轮挖矿，不诚实矿工的作弊行为最终因投票不足而失败。

前文提到，在提案组领导人所出区块的验证阶段，应用链矿工至多等待预设的时长，若在这段时间内接收到的检验结论为通过的报告份数始终小于最小成功验证数(当然若这段时间内接收到的检验结论为不通过的报告份数大于最大失败验证数，则等待过程提前结束)，则可确定提案组领导人所出区块验证未通过。

在一种实现方式中，上述预设的时长为MaxRounds+Q个基链出块时间(Q取0或正整数)，对于应用链矿工来说，连续两次同步到基链区块信息之间的间隔就是一个基链区块时间。该预设的时长从应用链矿工同步到确定应用链待挖区块的提案组领导人的基链区块信息起开始计时(该时刻也是首轮验证组成员推选的起始时刻)，在前MaxRounds个基链出块时间内允许应用链矿工参与验证组成员的推选(至多进行MaxRounds轮推选)并在确认被选中后广播生成的检验报告，在后Q个基链出块时间内应用链矿工虽然不能再参选验证组成员的推选，但可以持续接收检验报告并根据对检验报告的统计结果确定提案组领导人所出区块是否验证通过。当然，若某个应用链矿工在第MaxRounds轮推选之前就被选为验证组成员，它用于接收检验报告的时间就会相对更长一些。

重要的是，对于一个应用链矿工，即使它根据已经收到的针对提案组领导人所出区块的检验报告已经确认了该区块验证通过，也得继续接收检验报告，直至达到MaxRounds+Q个基链出块时间，在此期间，根据新接收到的检验报告，提案组领导人所出区块验证通过的结论可能被推翻，因为若新接收到的检验报告中的检验结论为不通过，可能导致检验结论为不通过的报告分数大于最大失败验证数。此时，提案组领导人所出区块将被弃用，并且，由于之前已经将该区块认定为验证通过，从而后续高度的应用链区块的挖矿工作已经随之启动，甚至后续区块已经纳入应用链账本，因此若该区块已经纳入应用链账本并且之后还串接了其他区块，串接在其后的区块也要一同弃用，处理完毕后可以重新开始应用链待挖区块的提案组成员的推选。当然，已得出验证结论被推翻是少数情况，大多数情况下应用链矿工收到新的检验报告后还是能维持之前得出的验证结论，并不会导致已出区块频繁作废。

需要指出，若应用链矿工在尚未到达MaxRounds+Q个基链出块时间的某个时间点根据已经收到的针对提案组领导人所出区块的检验报告已经确认了该区块验证未通过，则可直接重新开始应用链待挖区块的提案组成员的推选，不必再等待下去。因为报告的份数只会累加不会减少，一旦检验结论为不通过的检验报告分数大于最大失败验证数，后续再接收检验报告，也不会改变该结论，即，只有验证通过的情况才有可能出现结论反转。增设Q个基链出块时间专门用于继续接收检验报告的原因在于，检验报告在应用链中传播需要时间，因为通信等因素可能导致传播延迟，使得先期得出的验证结论不够准确。

若允许应用链矿工在至多MaxRounds+Q个基链出块时间等待检验报告，意味着应用链矿工至多允许Q+1个连续高度的应用链区块处于验证状态。其中，从区块的验证组成员推选开始，直至得出最终的验证结论(指不可再被推翻的结论)这段时间内区块处于验证状态。例如，当应用链待挖区块开始验证时，至多允许包含它自身在内的最近Q+1个高度的区块同时处于验证状态，应用链待挖区块之前高度的区块虽已验证通过，但由于处于验证状态的时间尚未到达MaxRounds+Q个基链出块时间，因此还未得出最终的验证结论。在理想状态下，基链和应用链保持同频出块(同频出块具体见后文)，所以当验证等待时间多出Q个基链出块时间时，允许处于同时验证状态的应用链区块是Q+1个。特别情况下，Q可取0，表示允许处于验证状态的应用链区块只有1个。

在基链出块的驱动下，处于挖矿进程中的应用链矿工的工作状态将在待挖区块的提案状态与验证状态之间循环切换，一旦某个区块得出验证结论(不一定要是最终的验证结论)，应用链矿工随即进入下一区块的提案组构建工作，它将依据最新同步的基链区块信息确认下一区块是否已选出提案组领导人，进而决定是否继续组建提案组。若下一区块已选出提案组领导人，则下一区块直接进入验证状态，若下一区块未选出提案组领导人，则下一区块进入提案状态，应用链矿工开始为其推选提案组成员、发送挖矿请求等操作。若应用链矿工确定某个待挖区块的提案组领导人始终未选出，则会在每次基链出块时(对应于应用链矿工而言就是同步到基链区块信息)尝试重建提案组，直至该待挖区块的提案组领导人被选出或者在针对某一旧高度的区块重挖成功。

根据上面的阐述，若有多个高度的应用链区块同时处于验证状态(这些区块必然已选出提案组领导人)，只有当其中高度最高的区块最终验证通过后，应用链矿工才会在该区块之后的高度展开新的提案组组建工作。对于非最高高度的区块，即使已得出最终的验证结论为通过，也不会导致应用链矿对针对该区块的下一高度展开新的提案组组建工作(因为此时下一高度的区块还处于验证状态)。

前文曾经提到提案阶段的定向腐蚀问题，对于验证阶段，也可能存在定向腐蚀问题。作为一种解决方案，在应用链中可以通过确保参与完整验证的矿工数量来避免定向腐蚀，改善区块链系统的安全性。例如，若应用链矿工总数不多，可采用全员验证方式，若应用链矿工总数较多，可从中组建验证组，并且最小成功验证数不能设置得太小(比如，可取数十个至数百个)。当有足够多数量的应用链矿工参与区块的完整验证，要进行全面的定向腐蚀非常困难(区块的验证结果是统计得出的，对个别验证者定向腐蚀意义不大)。

上面介绍了本申请实施例提供的区块链系统进行共同挖矿的主要流程，下面再补充介绍该区块链系统在运行过程中涉及的一些关键问题：

(1)同频出块问题

为维持本申请中的区块链系统的正常工作，在常见的实现方式中，应用链应保持与基链基本相同的出块频率(简称同频出块)，具体表现为应用链的最大块高常处于快追上基链最大块高的状态，通常只相差数块，需要保持同频出块的原因稍后再分析。然而发明人研究发现，如果应用链只按照常规方式出块，出块频率必然小于基链。其原因在于：

第一，应用链上组建提案组或验证组可能失败，从而导致应用链矿工出块失败，使得应用链出块频率降低。无论是提案组还是验证组，都对成员的数量有一定的要求，例如，对于提案组成员的数量有最低矿工个数的要求，最小成功验证数也暗含对验证组成员的数量的要求。然而，若提案组或验证组成员采用VRF算法推选，必然存在数量不足的可能，因为VRF算法的结果具有随机性，只能从概率意义上保证选出的成员数量符合预期，但具体到某一次组建提案组或验证组的过程，则选出的成员数量未必符合要求。

第二，由于通信不畅，提案组领导人的选举结果或者检验报告未能及时送达导致应用链矿工出块失败，使得应用链出块频率降低。

第三，即使基链已为应用链区块成功选出提案组领导人，由于组建验证组时存在多轮推选机制，该区块可能还需要隔上几个基链出块的时间才能确定全部的验证组成员，这也使得应用链的出块时间相较于基链偏慢。应用链在推选验证组成员时预期进行的轮次与应用链的设计意图有关，例如，若应用链更看重消息(比如，检验报告等)在节点间的充分传播(消息传播越充分敌手作案就越难)，则可多进行几轮验证组成员推选(设法调低每轮被选中的比例)。

作为对比的，基链出块频度很确定，主要取决于基链上的挖矿算力，通常不受其他因素干扰，特别地，根据前面的阐述，即使在某次基链出块时针对某条应用链上的待挖区块无法选出提案组领导人，本次不在所出的基链区块中记录该待挖区块的选举结果即可，即基链出块并不受应用链出块影响。

因此，保持同频出块实际上就是要提高应用链的出块频率，使其能够赶上基链的出块进度。在一种实现方式中，应用链矿工在打包应用链待挖区块时(应用链矿工可能在确定自身为提案组成员后就打包，或者可能在确定自身为提案组领导人后才打包，如前文所述)，会判断确定提案组领导人的基链区块的高度与应用链待挖区块的高度之差是否大于预设的第一差值阈值，若两个高度之差大于第一差值阈值，则连续打包应用链待挖区块以及预设个数(至少一个)的空块，若两个高度之差不大于第一差值阈值，则只打包应用链待挖区块。例如，假设确定提案组领导人的基链区块的高度为X，应用链待挖区块的高度为Y，第一差值阈值取4，若X-Y>4，则可以连续打包应用链待挖区块以及一个空块。

对于连续打包的应用链待挖区块和空块，其中，前者就是正常出块，而预设个数的空块则起填充作用，其目的只是为了增加应用链的块高，从而提高应用链的出块频率，空块内不包含任何交易内容。可选的，应用链待挖区块的区块头中还可以增加一项标记，用于表明其为连续出块中的首块。在验证组成员对提案组领导人所出区块进行验证时，空块也要参与验证，不过可以直接在检验报告中给出检验通过的结论。

根据前文对提案组领导人选举过程的介绍，基链矿工在打包基链区块时，会根据基链账本中记录的、已经选出提案组领导人的应用链最高区块确定应用链待挖区块的高度，并从缓存的挖矿请求中选择匹配于该高度的挖矿请求纳入针对应用链待挖区块的待选举集合。对于应用链矿工可出空块的情况，相应地，基链矿工可以判断确定应用链待挖区块的提案组领导人的基链区块的高度(该高度可以从针对应用链待挖区块的待选举集合的挖矿请求中直接提取)与应用链待挖区块的高度之差是否大于预设的第一差值阈值，若两个高度之差大于第一差值阈值，则标记在应用链待挖区块所在的高度处应用链矿工会进行连续出块。

从而，基链矿工在后续确定应用链的最大块高时(例如，汇集针对下一应用链待挖区块的挖矿请求进行提案组领导人选举时)，应考虑标记有连续出块的应用链高度，在这些高度处应用链每次出块引起的高度增长将大于1，比如，若允许应用链矿工一次连出两块(其中一块为空块)，则在标记有连续出块的应用链高度处，应用链的高度在一次出块后将增长2。

如果按照上述方法，应用链还是无法追上基链的出块速度，则说明应用链的某些配置参数可能选择欠佳，需要调整，例如最小当选随机值、最小成功验证数、最大失败验证数等参数设置不当可能导致选出的提案组或验证组中成员过少，应用链出块困难。

可选的，还可以针对每条应用链预设一个第二差值阈值(第二差值阈值大于第一差值阈值)，若基链矿工判断出上述两个高度之差大于第二差值阈值，则表明应用链已经无法追赶基链出块，为避免对区块链系统的稳定运行产生负面影响，此时基链可以拒绝为应用链继续提供算力支持。反之，若基链矿工判断出上述两个高度之差不大于第二差值阈值，则应允许应用链继续通过出空块的方式追赶基链出块。

在本申请提供的区块链系统中，基链通常比应用链更早启动运行，因此将基链算力接入到新启动的应用链时，基链很可能已运行一段时间了，只要应用链在创世区块指定的初始块高，与基链当前最大块高能衔接上，后续挖矿就能正常推进。即应用链首个区块通常不从0开始编号，而改由衔接时刻基链已有块高开始编号，相当于默认在此之前应用链和基链出块完全同步。

前面提到，基链出块频度很确定，通常不受挖矿算力以外的因素干扰。应用链在基链出块(对于应用链矿工来说通过同步基链区块信息感知基链出块)的驱动下进行提案及验证等操作，相当于基链为应用链提供一个确定的时钟系统，不妨称之为时钟源，应用链执行各种操作的时机均以此时钟源为参照。应用链采用基链充当时钟源，可以避免应用链自行定义时钟导致的安全性问题：分布式系统常因缺少统一的时间标准，容易被敌手聚焦攻击，比方一应用链条链的矿工中敌手人数占优，敌手可以控制链上时间的计算，比方将1小时记作1分钟，给解密、定向攻击等留出时间。顺带一提，除了时钟源之外，应用链矿工在推选提案组成员时用到的第一选举字串、在推选验证组成员时用到的第二选举字串也来自于基链，敌手同样难以操纵，可将这两个字串称为随机源(因为选举具有随机性)，时钟源与随机源是应用链安全保障的两大基石，因时钟源与随机源均由应用链的链外系统(即基链)提供。

应用链将基链用作为时钟源后，因尽量维持与基链出块频率一致，否则将导致应用链中每两相邻区块生成时间间隔的波动幅变大，对应用链平稳出块不利。在应用链的一些上层应用(如交易转账)中，取应用链区块的出块时间作为与业务流程相关的时间节点或计算这些时间节点的依据，出块时间的波动将直接影响业务对时间判断的精确性。若应用链能够与基链保持同频出块，则可以避免出块时间偏差产生累积效应(应用链中插入空块后应用链平均出块时间将趋同于基链)。还需要指出，空块作为一种保持同频出块的特殊措施，应尽可能避免干扰应用链本身的计时逻辑，例如，空块出块的过程在逻辑上可理解为占用0时长，因此在应用链的上层应用中如果要取用应用链区块的出块时间，空块与它之前的非空块所跨越的时长应视作0时长。

(2)软分叉及最长链问题

在典型的区块链公链系统中，各矿工自主决定何时出块，例如在比特币系统中，某矿工随机碰撞到一个符合难度系数要求的哈希值，算力竞争就胜出了，该矿工随后将自己打包的新块全链广播。这种处理方式必然导致同一时间可能有多个矿工在打包同一高度的区块，即，账本中出现软分叉是必然的。现有的公链系统一般通过最长链机制来消除软分叉，其中涉及最长链切换操作，具体可参考现有技术，此处不展开阐述。软分叉虽不至于使公链系统无法运作，但如果其频繁发生，最长链切换操作也必然频繁执行，导致已记账交易频繁发生回退，进而影响系统的稳健性。因此，有必要对软分叉进行抑制或者尽可能削弱软分叉产生的影响。

本申请提供的区块链系统中，基链继承了现有公链系统中的上述软分叉特性(但并不表示基链一定为公链)，也采用现有公链系统中使用的最长链机制来消除软分叉。

应用链由于依赖基链的算力支持，因此其软分叉有两种来源：其一，应用链矿工自主的挖矿行为会导致软分叉(现有公链系统中的上述软分叉特性)；其二，基链中出现的软分叉必然映射到应用链，使应用链形成软分叉，因为应用链矿工要从基链同步基链区块信息形成本地的基链账本，不同的应用链矿工在不同的位置接入基链，从而在基链出现的软分叉也分别被同步，导致应用链矿工各自只认可它已同步到的基链区块信息中指示的提案组领导人的信息，也只验证该提案组领导人产生的区块。应用链也遵循最长链机制，上述两种原因导致的软分叉也都通过最长链机制来消除，并且由于这两种原因引发的最长链切换未必指向相同的应用链最长链，使得应用链上用于消除软分叉的最长链切换过程变得复杂，具体在后文阐述。

本申请提供的区块链系统中的如下特性有助舒解因基链软分叉带来的干扰：

其一，应用链矿工的挖矿请求会在基链中广播，每个基链矿工都会收到挖矿请求，从而基于这些挖矿请求针对应用链同一高度的区块选出同一提案组领导人的概率较高。并且，在本申请的方案中，提案阶段比验证阶段限制更宽松(比如，在常见的实现方式中，从未参与挖矿的新矿工也会赋予其首次记账权重允许其挖矿，而持币量小于最小持币量的矿工则不允许其参与验证组成员的推选)，也有利于提案组领导人的选举结果趋于一致。从而，不管基链是否发生软分叉，对选举提案组领导人的结果影响不大。

其二，第一方面，应用链推选应用链待挖区块的提案组成员时采用的第一选举字串根据确定应用链待挖区块的提案组领导人的基链区块的前L区块中的信息，该信息基本已经固定下来(特别是在L取稍大一些的值，例如6的时候)。从而，基链若在该第一选举字串的来源区块之后出现软分叉导致应用链也出现软分叉，对应用链后续某高度的待挖区块来说，不管该区块位于应用链哪个候选分支上，获取到的第一选举字串的值大概率相同，进而最终确定出的提案组领导人也大概率一致，因为每个基链矿工上的提案组领导人选举算法相同，仅挖矿请求到达先后不一致有干扰(基链矿工若收到的挖矿请求不一致，存在一定概率选出不同的提案组领导人)。

第二方面，在基链确定应用链待挖区块的提案组领导人后，应用链推选验证组成员时采用的第二选举字串根据以下信息计算：提案组领导人的矿工标识、确定提案组领导人的基链区块的高度、应用链待挖区块的高度以及推选验证组成员的轮次编号，该设计能够在验证组成员的推选过程中有效防止基链分叉的干扰。其原因在于：提案组领导人的矿工标识、应用链待挖区块的高度两项信息在多轮验证组成员推选期间是确定的，而基链在选出应用链待挖区块的提案组领导人后出现软分叉，亦不影响确定提案组领导人的基链区块的高度一项的取值，而其后由于基链软分叉导致的应用链软分叉并不影响推选验证组成员的轮次编号一项的取值。

综合以上两方面，基链与应用链存在软分叉大概率不会干扰提案组领导人选举及验证组成员推选，应用链出块及验证过程具有很高确定性。

其三：若基链上的矿工针对同一应用链待挖区块选出两个或上的提案组领导人，将导致基链发生软分叉，进而应用链也随之发生软分叉，但分叉后应用链出块速度变慢，基链出块速度不变，软分叉将快速消除，这里存在一种基链、应用链出块速度差的自适应调整机制，具体介绍如下：

若应用链的软分叉由上述原因导致，软分叉后应用链上将存在多个提案组领导人出块供验证，参与验证的矿工将被分流，客观上使得验证更难通过。此外，应用链的管理者还可以调整应用链上配置的最小成功验证数与最大失败验证数两个参数，将最小成功验证数调大，将最大失败验证数调小，这样验证通过的条件将更加苛刻，区块通过验证也更困难，特别是只有少数验证组成员认可的提案组领导人所出区块将无法通过验证。

随着验证通过难度的提高，应用链出块速度会变慢，一方面因为推选验证组成员的轮次会变多(只有选出更多的验证组成员才有可能通过验证)，验证耗时会变长，另一方面也因为一旦区块无法通过验证，应用链矿工只能在原高度继续挖矿，应用链高度不会增长。应用链挖矿进度变慢后，使得应用链上已经产生的软分叉程度不会继续加深，有利于分叉走向收敛。并且，应用链的区块高度增长变慢后，基链出块频率并不受影响，基链上产生的软分叉将很快消除。

基链软分叉因素消除后，应用链将回归正常挖矿的状态(但此时应用链上的软分叉可能尚未消除)，其附带效应是，之后的一段时间内应用链上所出空块将会变多，以便追回和基链的块高差。此时，处于活跃区域(含义在下面解释)内的应用链矿工维护的候选分支(下面简称活跃分支)中的区块经几轮验证通过的概率，相对处于不活跃区域内的应用链矿工维护的候选分支(下面简称非活跃分支)中的区块更高。从而，活跃分支上的区块高度增长更加容易，并且，由于应用链连续出块增多，活跃分支与非活跃分支之间的高度差将很快拉大，在较短时间内活跃分支将被确定为应用链最长链，进而应用链上的软分叉也得到消除。其中，活跃区域是区块链系统中由通信畅通的节点构成的群落，活跃区域内的节点往往分布集中、节点间信息同步及时并且节点数量也占系统的大多数。

若应用链软分叉并非由基链软分叉导致，也可类似分析，不再展开阐述。下面继续介绍应用链上的最长链切换过程。

如前所述，有两种导致应用链软分叉的因素，一种是链内各矿工自主挖矿引起，一种是基链软分叉引起。应用链中也相应地设置两种类型的最长链切换规则用于消除这两种因素导致的软分叉。其中，第一重最长链切换借助于应用链内各矿工之间的区块同步来触发，第二重最长链切换则利用基链的最长链切换来触发应用链的最长链切换。无论哪种类型的最长链切换，都将作为切换目标的应用链候选分支上的各区块记账成功作为切换结束标志。

触发最长链切换存在可信的问题，某矿工收到新区块导致最长链切换，新收区块可以只是区块头，也可以是完整区块，但均要求无法随意伪造，因为最长链切换涉及交易回退操作，处理过程比较重，如果轻易伪造一个区块就导致候选分支切换，区块链系统会变得很脆弱。以比特币系统为例，比特币只需区块头就能驱动最长链切换，因为哈希碰撞受挖矿难度约束，伪造区块头与伪造区块体一样困难。在区块链的实践中，区块头和区块体多采用分开传播的方式，因区块头数据量较小易于快速传播以便执行后续操作，当然也不排除区块整体传播的方式。不过为简单起见，后文在介绍时仍假定应用链区块在应用链中采用区块头和区块体分开传播的方式，其中，区块头可以先传播，而区块体则采取向相邻节点索要的方式。如果应用链区块采用其他方式传播，亦可类似分析。

在本申请的方案中，在应用链矿工将某个应用链区块的区块头纳入应用链账本后，若发现该区块头的挂入导致某个应用链候选分支在所有候选分支中变为最长，则触发第一重最长链切换，该应用链区块的区块体则可在后续向其他应用链矿工索要。

在应用链矿工将同步到的基链区块信息纳入本地的基链账本、并使得本地的基链账本中产生最长链切换后触发第二重最长链切换。之前已经提到，基链区块信息有几种形式，但不管哪种形式，至少都包括基链区块的区块头以及基链区块的区块体中针对应用链待挖区块的提案组领导人的选举结果，而并不能只包含基链区块的区块头，因为如果缺少提案组领导人的信息，应用链矿工无法执行后续的验证及挖矿操作。在应用链矿工确认基链发生最长链切换后，通过第二重最长链切换将应用链中进行挖矿的分支切换到基链最长链指示的应用链最长链(简称应用链待切换分支)上去，然而，由于基链最长链和应用链最长链可能并不完全一致(因为有重挖旧块等行为的存在)，所以此时应用链待切换分支并非一定是块高意义上应用链最长链，但并不影响应用链矿工在基链的指示下进行最长链切换。

由于最长链切换会涉及交易回退操作，因此在切换完成前不能进行其他交易相关操作，包括禁止两重最长链切换穿插进行，所谓穿插是指在执行其中一种类型的最长链切换的同时执行另一种类型的最长链切换，两种类型的最长链切换只能分时执行或者若遇同时执行，必须将其中一种终止掉。其具体执行规则为：

其一，在应用链矿工执行已触发的第一重最长链切换的过程中，若有新触发的第一重最长链切换或第二重最长链切换，应用链矿工不进行响应，继续执行当前的第一重最长链切换。

其二，在应用链矿工执行已触发的第二重最长链切换的过程中，若有新的第二重最长链切换被触发，则应用链矿工终止正在执行的第二重最长链切换，并开始执行新触发的第二重最长链切换。

其三，在应用链矿工执行已触发的第二重最长链切换的过程中，若有新的第一重最长链切换被触发，则判断基链最长链指示的已确定提案组领导人的应用链区块的最高高度(即第二重最长链切换中应用链待切换分支的高度)，是否小于纳入触发该第一重最长链切换的区块头的应用链候选分支的高度。若前一高度大于后一高度，表明第一重最长链切换对应的应用链候选分支高度更高，此时应用链矿工终止正在执行的第二重最长链切换，并开始执行新触发的第一重最长链切换，若否，应用链矿工不响应新触发的第一重最长链切换，继续执行当前的第二重最长链切换。

产生第一重最长链切换时，其处理方式可以参考比特币或以太坊等现有区块链系统中的实现，在此不作具体阐述。

产生第二重最长链切换时，应用链矿工则有可能发现应用链待切换分支上的一个或多个新近区块的区块头缺失(第一重最长链切换时应用链待切换分支中区块头不会缺失)，这些区块头缺失的区块可能在应用链其他矿工处保存，还没传输过来，这属于临时缺失，因为既然第二重最长链切换在基链最长链的指示下进行，基链最长链指示的应用链待切换分支的最大高度之前的区块必然已经成功出块，否则应用链矿工不会在前一区块出块未成功的情况下就发起针对下一区块的挖矿请求，基链也不会为其选出提案组领导人。不过，这些区块头缺失的区块也可能在本链尚不存在，这属于真实缺失，由于应用链矿工接入的基链同步节点只在基链的局部区域维持数据同步，某些基链的候选分支可能未在当前应用链的任何矿工处同步过，或者虽然同步过但在同步时基链区块信息发生丢失等原因，导致应用链上未产生对应的应用链区块。

应用链区块的临时缺失与真实缺失需要进行区分，临时缺失尚能通过应用链矿工之间的数据同步补回；真实缺失是基链虽然已选出提案组领导人，但应用链没有任何矿工知道该提案组领导人已当选，所以没矿工出块，或者已当选提案组领导人的应用链矿工虽已出块，但因通信异常未能传播新块，总之，并不能通过应用链矿工之间的数据同步补回。这两种缺失在本申请的第二重最长链切换方案中都能够有效得到处理。

应用链矿工进行第二重最长链切换，总体上的流程是：首先确定应用链待切换分支上的最后一个已确收区块，已确收区块是指区块头已被应用链矿工接收并且应用链矿工根据接收的检验报告已确定其验证通过的区块(区块体可后续从其他应用链矿工处索取)，此时区块头处于可写入应用链账本的状态，至于是否会被写入账本则与实现有关。然后，应用链矿工从已确收区块之后的区块开始，正向(块高增大方向)遍历应用链待切换分支，并在遍历过程中将应用链待切换分支上的区块纳入应用链账本中。

在一种具体的实现方式中，上述第二重最长链切换的流程可以按照如下步骤操作，注意在下面的操作中未涉及应用链上的空块，对于这些空块可以跳过不处理。

第一步，应用链矿工从本地的基链账本中的基链最长链的最后一个区块开始，逆向(块高减小方向)遍历基链最长链，分析各个已选出提案组领导人的区块在应用链待切换分支上是否已经确收，找到的第一个已确收区块就是应用链待切换分支上最后一个已确收区块。

若应用链待切换分支上最后一个已确收区块不是应用链待切换分支上的最后一个区块，则将最后一个已确收区块之后的首个由基链指示的已选出提案组领导人的区块确定为待定首区块，并在至多Z个基链出块时间内等待待定首区块被确收。若待定首区块在等待了至多Z个基链出块时间后还未被应用链矿工确收，则终止第二重最长链切换，重新开始待定首区块的提案组成员的推选。其中，Z为正整数，若待定首区块是应用链待切换分支上的最后一个区块，则Z可取MaxRounds+Q，否则Z可取不小于MaxRounds+Q的值；MaxRounds为应用链矿工推选验证组成员的最大轮次，Q为应用链矿工允许额外同时处于验证状态的区块的高度的数量，这两个参数的含义前文已经介绍过。

若最后一个已确收区块是应用链待切换分支上的最后一个区块，则将最后一个已确收区块的下一区块确定为下一应用链待挖区块并开始该区块的提案组成员的推选。

第二步，应用链矿工判断待定首区块的提案组领导人是否为其自身。若待定首区块的提案组领导人是应用链矿工自身，则进一步判断应用链矿工是否曾经打包过待定首区块，若曾经打包过待定首区块，则重用已打包的待定首区块，若未曾打包过待定首区块，则打包待定首区块。且不论是否打包过待定首区块，应用链矿工都应向其他应用链矿工广播待定首区块并开始参与待定首区块的验证组成员的推选。应用链矿工具有缓存机制，自己最近打包的区块都会缓存，若遇应用链最长链在候选分支之间来回切换数次，某个区块在之前已经打包过并缓存于应用链矿工本地是完全可能的，此时可直接重用之前组建好的区块。对于待定首区块需要打包的情况，表明本地缓存中没有该区块，例如虽然基链已为该区块选出提案组领导人，但应用链矿工之前并未得知自己是提案组领导人，所以要做新区块的补建操作(如果补建失败，应用链矿工将在Z个基链出块超时时间到来后，在待定首区块高度重启挖矿，参见下面第三步的描述)，此种情形对应上文所述的区块真实缺失。若待定首区块的提案组领导人不是应用链矿工自身，直接开始待定首区块的验证组成员的推选即可。

第三步，应用链矿工对待定首区块的验证进度进行监控。若从应用链矿工开始推选待定首区块的提案组成员起的Z个基链出块时间内，待定首区块被纳入应用链账本，则将待定首区块之后的首个由基链指示的已选出提案组领导人的区块确定为下一待定首区块。若从应用链矿工开始推选待定首区块的提案组成员起的Z个基链出块时间内，待定首区块未被纳入应用链账本，则终止第二重最长链切换，重新开始待定首区块的提案组成员的推选。其中，Z的定义和前面的步骤中相同。需要注意的是，待定首区块被纳入应用链账本是指待定首区块的区块整体被写入应用链账本，不仅仅指区块头，这和区块确收是存在区别的。在本步骤中应用链矿工实施监视的目的主要是为了避免已选出的提案组领导人所在的挖矿节点异常离线，或已关机退出，若不处理这样的异常状况，应用链出块容易挂住。

第四步，应用链矿工判断确定出的下一待定首区块是否已经确收(因为从应用链待切换分支的最后一个已确收区块开始处理已经经过一段时间，下一待定首区块可能已经确收)，若下一待定首区块已确收，或者目前虽未确收但在至多等待Z个基链出块时间后确收，则尝试将下一待定首区块纳入应用链账本，其具体方法和上面步骤中对待定首区块的处理类似，即对于待定首区块的处理是一个循环过程，不再重复说明。若下一待定首区块在等待了至多Z个基链出块时间后还未被应用链矿工确收，则终止第二重最长链切换，重新开始下一待定首区块的提案组成员的推选。

应用链矿工持续正向遍历应用链待切换分支查找后续的待定首区块，直至在将应用链待切换分支上的区块都纳入应用链账本后，结束第二重最长链切换。若在执行第二重最长链切换的过程中有新的第二重最长链切换被触发，则应用链矿工终止正在执行的第二重最长链切换，以新的基链最长链指示的应用链最长链为基础，回到上面的第一步执行新触发的第二重最长链切换。

单从最长链切换的角度来说，只需要区块头就可以驱动，但在应用链的第二重最长链切换的过程中，有两处必须依赖于区块体才能进行：其一是区块验证的时候，为验证交易的合法性，必须要使用区块体，因交易保存在区块体中；其二是应用链矿工要开始下一区块的挖矿工作前，由于要确定哪些交易可以纳入新区块，因此必须清楚之前已有哪些交易完成了记账，从而也需要使用区块体。

对于第二重最长链切换中的验证过程，应用链矿工只有在确认自己为验证组成员时才依据区块内容(包括区块头和区块体)执行验证操作，如果发现区块内容尚缺(只有区块头而无区块体，对应上文所述的区块临时失)则先向邻近节点索要相应的区块体，索要到区块体后进行验证并广播检验报告，否则验证组成员处于死等状态：或者，等待其他验证组成员出具的检验报告，并在根据接收到的检验报告得出通过或不通过验证的结论时退出死等，或者，在等待超过了预设的时间限制(如，Z个基链出块时间)后退出死等。对于非验证组成员的应用链矿工，只需凭验证组成员广播来的检验报告，自主按既定规则决定是否采纳相应区块，具体规则和前文普通挖矿(非最长链切换)时相同。

由于应用链存在软分叉，以及分布系统中的检验报告无法以确定时间、确定顺序的方式到达，因此可以要求各应用链矿工对收到检验报告都先缓存(过期则自动删除)，在应用链出现最长链切换时，应用链矿工就扫描该缓存区，并选用与待验区块匹配的检验报告(出块矿工与出块高度均匹配)自主按既定规则决定是否采纳相应区块。甚至，还可能出现这种情况，当前候选分支被切换到另一分支，但过一段时间又切换回来，因为被切走的分支重回应用链最长链了，此时历史上已使用过的检验报告可能反复再用。

对于第二重最长链切换中的提案过程，应用链矿工确认自己成为提案组成员后，在打包新区块之前，它需要保证此前各个区块内容已收全并已写入本地账本(如，可向邻近节点索要相应的区块体)，如果没收全应先等待收全(如，至多等待Z个基链出块时间)，若超时则在当前待定首区块高度重启挖矿工作。

(3)账本压缩问题

区块链系统在运行较长时间后，账本体积会越来越大，为节约区块链节点上的存储空间，可对账本进行压缩。下面以基链矿工本地保存的基链账本的压缩为例进行阐述：

对于基链区块中的选举依据列表，只服务于新区块的开采，没有必要长期保存。例如，在一种实现方式中，基链区块可以按照如下方式保存：

在基链的最近D个难度调整周期内生成的区块保存区块头以及完整的区块体；在基链的最近D个难度调整周期之前生成的区块保存区块头以及区块体中的选举结果列表，但不保存选举依据列表。其中，D取正整数，比如最近D个难度调整周期可能对应最近的十几天、一两个月等。若选举结果列表的表项采用简化形式(只含提案组领导人的矿工标识)，则还要保存选举依据列表中由提案组领导人自身产生的提案候选信息(若选举结果列表的表项未采用简化形式，则本已包含所需的提案候选信息)。若基链上有发行数字货币，则区块体中还要保存交易信息，以便确定账号余额。在具体实现时，基链矿工在新出的基链区块验证通过后，可先将其纳入基链账本，并定期对基链账本进行清理，即移除掉区块中的选举依据列表，实现账本压缩。

对于最近D个难度调整周期之前生成的基链区块，根据保留下来的信息亦足以进行验证，以区块中的选举结果列表的表项采用简化形式的情况为例：要证明表项中记录的提案组领导人的矿工标识未被伪造，只需推导merkle根，然后确认推到出的结果和区块头中记录的merkle_root1一致。要证明提案组领导人自身产生的提案候选信息中的内容真实可信，首先可根据提案候选信息推导提案组领导人的矿工标识，并确认推导结果与选举结果列表的表项中记录的一致；然后可利用提案候选信息中的确定提案组领导人的基链区块的高度一项可获取第一选举字串，进而基于提案候选信息中的应用链矿工公钥、第一可证明字串两项信息以及获取到的第一选举字串调用VRF算法的验证函数确认第一可证明字串未被伪造。

应用链中有矿工需要重建应用链账本时(例如，矿工所在的挖矿节点故障后重启)，必须要验证账本中的每一已出区块是否合法。对于任一待验证的应用链区块，应用链矿工至少需要从基链同步记录该区块的选举结果的基链区块的区块头以及区块体中为该区块选出的提案组领导人对应的提案候选信息(从上面的阐述可知，无论基链账本是否压缩，这两项内容都包含在每个基链区块内)，并根据同步到的信息来确认应用链区块的是否得到基链认可，其具体过程包括：

应用链矿工同步上述信息后首先可用上面提到的方法确认提案候选信息中的第一可证明字串未被伪造；然后，还需要根据提案候选信息中的应用链矿工公钥一项确认提案候选信息所确定的提案组领导人就是待验证的应用链区块的出块者，例如，应用链区块的区块头中可以保存出块者的公钥信息，确认根据应用链矿工公钥获得的公钥信息与区块头中保存的公钥信息一致即可。

在一些可选的方案中，在应用链矿工确认了提案候选信息中的第一可证明字串未被伪造后，还可以进一步第一可证明字串推导第一随机值以及第二随机值(具体公式见前文)，最后验证第二随机值是否满足当选提案组成员的条件、是否符合当选提案组领导人的基本要求等。当然，若提案候选信息的实现中已经包含第二随机值这一项，并且应用链矿工在重建账本时急于追赶块高，也可直接使用提案候选信息中的第二随机值用于验证，不必再根据第一可证明字串进行推导。

应用链矿工在重建应用链账本时从基链同步信息确认账本中的区块被基链认可是十分重要的，因为应用链账本容易被人伪造，如果缺少基链为它背书，其真实性将大打折扣。

综上所述，在本申请实施例提供的区块链记账方法中，应用链矿工并不直接运行共识算法竞争出块权，而是在确定自身为提案组成员后向基链矿工发送挖矿请求，由基链矿工通过计算选举出提案组领导人并将选举结果及选举依据记录在基链区块中，随后应用链矿工通过同步基链区块信息即可获知提案组领导人的信息，进而参与验证组成员的推选，并通过收集验证组成员对提案组领导人所出区块作出的检验报告判断区块是否通过验证，若通过验证就进行记账。

该区块链记账方法实际上提供了一套基链和应用链共同参与挖矿的全新机制，即可由一条基链汇集矿机资源，为众多应用链提供算力服务，协助应用链完成挖矿过程，从而可以有效改善现有区块链系统中矿机资源的浪费问题，具有良好的社会效益。其中，基链和应用链既可以是单链，也可以是并行链，并且基链和应用链构成的区块链系统还可以嵌套，其构成方式非常灵活。上文首先详细介绍了基链与区块链配合进行共同挖矿的工作原理，然后对其中涉及的同频出块、软分叉与最长链、账本压缩等难点问题进行了深入剖析并给出了对应的解决方案，使得共同挖矿机制得以完善。

发明人研究后认为，该方法可以用于，但不限于以下的场景中：

场景一：对于新发展的区块链系统，必然会遭遇成长性与安全性的天然矛盾。新系统上线时由于缺少矿机资源的支持，导致汇集算力不足从而容易遭到攻击，现实案例已证实这一点，已有数个从比特币硬分叉而来的区块链系统，因遭受有预谋的算力攻击而夭折，区块链系统越不安全就越难赢得公众信任，也就越没人用，越少人用导致越少矿机参与，区块链系统更趋于不安全，整个体系将陷入恶性循环。

虽然为区块链系统设计专有的共识算法可以在一定程度上避免算力攻击，但势必导致矿机缺乏通用性难以得到市场认可，最终还是无法解决新生系统缺少算力支持的困境。

若利用本申请实施例提供的区块链记账方法，则可由基链为新发展的区块链系统提供充足的矿机资源，保障其安全、稳定运行，有利于区块链技术在各行业的普及。

场景二：在很多区块链系统中，矿机不只用于挖矿，还根据业务特定对外提供特定公共服务：例如，基于容量共识(Proof of Capacity，简称PoC)的矿机，将硬盘存储能力当作算力，算力本身就是存储服务；又例如，基于可信执行环境(Trusted ExecutionEnvironment，简称TEE)实施挖矿的区块链系统，可将TEE的加解密、签名与验证等能力开放出来，对外提供安全服务。

在这些区块链系统中，必须要足够数量的矿机才能够确相应服务的稳定运行。若利用本申请实施例提供的区块链记账方法，可由基链为这些区块链系统提供充足的矿机资源，保障其提供服务的可靠性。

此外，在本申请实施例提供的区块链系统中，应用链确定提案组及验证组所依赖的随机源由链外系统(即基链)参与提供，提案组成员选举领导人改在链外系统(即基链)实施，并由链外系统(即基链)为应用链挖矿过程提供时钟源，这些措施有助于强化应用链的安全性，采取此种设计的简要分析如下：

当前业界的联盟链普遍采用拜占庭共识算法，该算法限制了参与投票的节点数量，并要求在所有节点之间都建立连接后，才能在明确数量范围内进行投票(例如，典型联盟链的节点数量通常限制在100左右，组成联盟链的所有节点都属于提案组及验证组，不动态组建提案组及验证组)。本申请的方案对此进行了改进，在应用链内实现了提案组与验证组动态推选的机制，如上文所述的借助于VRF算法来确定提案组或验证组的范围，但发明人研究发现，纯粹在应用链内取随机数(指VRF算法中的info)作为VRF算法的输入，以及组建提案组或验证组过程中涉及的时间因素只在应用链内采用特定算法(比方从各节点上报时间取平均值等)来确定，安全强度不够。为了强化应用链的安全性，应在应用链的外部提供随机源与时钟源，在本申请的方案中由基链来提供。

图3示出了本申请实施例提供的区块链记账装置200的功能模块图。参照图3，区块链记账装置200包括：

提案组推选模块210，用于应用链矿工参与应用链待挖区块的提案组成员的推选；其中，若确定所述应用链矿工被推选为应用链待挖区块的提案组成员，则向基链矿工发送针对所述应用链待挖区块的挖矿请求，所述提案组为有权发送挖矿请求的应用链矿工的集合；

区块信息同步模块220，用于所述应用链矿工同步基链区块信息，并将所述基链区块信息纳入本地的基链账本中，所述基链区块信息来源于基链矿工根据所述挖矿请求生成的确定所述应用链待挖区块的提案组领导人的基链区块，所述基链区块信息中包括指示所述提案组领导人的选举结果；其中，所述提案组领导人为具有所述应用链待挖区块的出块权的提案组成员；

验证组推选模块230，用于所述应用链矿工参与应用链待挖区块的验证组成员的推选；其中，若确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员，则对所述提案组领导人所出区块进行验证，并向其他应用链矿工广播检验报告，所述验证组为有权生成检验报告的应用链矿工的集合，所述提案组领导人所出区块包括所述提案组领导人打包的所述应用链待挖区块；

应用链记账模块240，用于所述应用链矿工接收所述检验报告，若根据所述检验报告确定所述提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。

本申请实施例提供的区块链记账装置200，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

图4示出了本申请实施例提供的区块链记账装置300的功能模块图。参照图4，区块链记账装置300包括：

选举模块310，用于基链矿工根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人；

基链记账模块320，用于所述基链矿工将保存有选举结果以及选举依据的基链区块纳入基链账本中。

本申请实施例提供的区块链记账装置300，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

图5示出了本申请实施例提供的区块链记账装置400的功能模块图。参照图5，区块链记账装置400包括：

信息接收模块410，用于所述同步节点接收基链矿工发送的确定应用链待挖区块的提案组领导人的基链区块，或者，接收所述基链矿工或基链中设置的其他同步节点发送的所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；其中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的提案组领导人的选举结果，包括所述应用链待挖区块的提案组领导人的选举结果；

信息发送模块420，用于所述同步节点向应用链矿工发送来源于所述基链区块的基链区块信息，所述基链区块信息采用的形式包括以下之一：所述基链区块本身；所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；所述基链区块的区块头以及所述基链区块的区块体中针对所述应用链的片断数据；其中，所述片断数据包括所述选举结果列表中针对所述应用链待挖区块的提案组领导人的选举结果，以及，所述选举结果与所述基链区块的区块头中基于所述选举结果列表计算出的merkle根之间的merkle路径。

本申请实施例提供的区块链记账装置400，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法施例中相应内容。

图6示出了本申请实施例提供的一种区块链节点的示意图。参照图6，区块链节点500包括：处理器510、存储器520以及通信接口530，这些组件通过通信总线540和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器520包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器510以及其他可能的组件可对存储器520进行访问，读和/或写其中的数据。

处理器510包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器510可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口530包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。例如，通信接口530可以是以太网接口；可以是高速网络接口(如Infiniband网络)；可以是移动通信网络接口，例如3G、4G、5G网络的接口；可以是各类总线接口，例如USB、CAN、I2C、SPI等总线接口；还是可以是具有数据收发功能的其他类型的接口。

在存储器520中可以存储一条或多条计算机程序指令，处理器510可以读取并运行这些计算机程序指令，以实现本申请实施例提供的区块链记账方法以及其他期望的功能。

可以理解，图6所示的结构仅为示意，区块链节点500还可以包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。图6中所示的各组件可以采用硬件、软件或其组合实现。例如，在采用硬件方式实现时，区块链节点500可以是个人计算机、手机、平板电脑、服务器、嵌入式设备、区块链系统专用硬件设备等；在采用软件方式实现时，区块链节点500可以是虚拟机、容器等。此外，区块链节点500也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。于本申请实施例中，基链上的挖矿节点、基链上的同步节点、基链上的管理节点、应用链上的挖矿节点都可以采用上述区块链节点500的结构实现，并运行各自的功能。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的区块链记账方法。例如，计算机可读存储介质可以实现为图6中区块链节点500中的存储器520。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (75)

1.一种区块链记账方法，其特征在于，应用于应用链矿工，所述方法包括：

参与应用链待挖区块的提案组成员的推选；其中，若确定所述应用链矿工被推选为应用链待挖区块的提案组成员，则向基链矿工发送针对所述应用链待挖区块的挖矿请求，所述提案组为有权发送挖矿请求的应用链矿工的集合；

同步基链区块信息，并将所述基链区块信息纳入本地的基链账本中，所述基链区块信息来源于基链矿工根据所述挖矿请求生成的确定所述应用链待挖区块的提案组领导人的基链区块，所述基链区块信息中包括指示所述提案组领导人的选举结果；其中，所述提案组领导人为具有所述应用链待挖区块的出块权的提案组成员；

参与应用链待挖区块的验证组成员的推选；其中，若确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员，则对所述提案组领导人所出区块进行验证，并向其他应用链矿工广播检验报告，所述验证组为有权生成检验报告的应用链矿工的集合，所述提案组领导人所出区块包括所述提案组领导人打包的所述应用链待挖区块；

接收所述检验报告，若根据所述检验报告确定所述提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。

2.根据权利要求1所述的区块链记账方法，其特征在于，所述确定所述应用链矿工被推选为应用链待挖区块的提案组成员，包括：

基于所述应用链矿工的私钥以及利用预设规则确定的第一选举字串调用可验证随机函数VRF算法中的证明函数，获得第一可证明字串；

基于所述第一可证明字串推导第一随机值，并根据所述第一随机值确定所述应用链矿工被推选为应用链待挖区块的提案组成员。

3.根据权利要求2所述的区块链记账方法，其特征在于，所述第一选举字串取确定所述提案组领导人的基链区块的前L区块的区块头中记录的哈希值或随机数，L为正整数。

4.根据权利要求2所述的区块链记账方法，其特征在于，所述根据所述第一随机值确定所述应用链矿工被推选为应用链待挖区块的提案组成员，包括：

根据所述第一随机值以及所述应用链矿工的提案组参选权重确定所述应用链矿工被推选为应用链待挖区块的提案组成员；其中，所述应用链矿工被选为所述提案组成员的概率与所述提案组参选权重的取值正相关。

5.根据权利要求4所述的区块链记账方法，其特征在于，所述根据所述第一随机值以及所述应用链矿工的提案组参选权重确定所述应用链矿工被推选为应用链待挖区块的提案组成员，包括：

利用如下公式计算第二随机值RandValue2：

RandValue2＝((RandValue1％ExpectedRange1)+priority1)

其中，RandValue1为所述第一随机值，ExpectedRange1为预设的范围值，priority1为所述提案组参选权重，％表示取余数运算；

若满足如下条件，则确定所述应用链矿工被推选为应用链待挖区块的提案组成员：

RandValue2>(ExpectedRange1-(ExpectedRange1*1/M1))

其中，M1为预设过滤比例。

6.根据权利要求4所述的区块链记账方法，其特征在于，所述提案组参选权重取所述应用链矿工在预设历史时间段内当选为提案组领导人的次数。

7.根据权利要求6所述的区块链记账方法，其特征在于，所述应用链矿工在所述历史时间段内当选为提案组领导人的次数从基于所述基链区块信息构建的表格中查询获得。

8.根据权利要求6所述的区块链记账方法，其特征在于，若所述应用链矿工因在所述历史时间段内未当选过提案组领导人而使得所述提案组参选权重为0，则所述提案组参选权重取首次记账权重，所述首次记账权重为预设的非0值。

9.根据权利要求6所述的区块链记账方法，其特征在于，若所述应用链矿工在所述历史时间段内当选提案组领导人的次数使得所述提案组参选权重大于预设的提案组最大参选权重，则所述提案组参选权重取所述提案组最大参选权重。

10.根据权利要求2所述的区块链记账方法，其特征在于，所述挖矿请求中包括提案候选信息，所述提案候选信息包括：

应用链标识、并行链链号、应用链待挖区块的高度、确定提案组领导人的基链区块的高度、应用链矿工公钥以及第一可证明字串；

其中，所述应用链标识是指发送所述挖矿请求的所述提案组成员所在的应用链的标识，所述并行链链号是指构成所述应用链的并行链中所述提案组成员挖矿所在的并行链的编号，所述确定提案组领导人的基链区块的高度是指确定所述应用链待挖区块的提案组领导人的基链区块的高度，所述应用链矿工公钥是指所述提案组成员的公钥，所述第一可证明字串是指所述应用链矿工被推选为所述提案组成员时依赖的第一可证明字串。

11.根据权利要求1所述的区块链记账方法，其特征在于，在所述确定所述应用链矿工被推选为应用链待挖区块的提案组成员之后，所述方法还包括：

被推选为所述提案组成员的应用链矿工打包所述应用链待挖区块。

12.根据权利要求11所述的区块链记账方法，其特征在于，所述打包所述应用链待挖区块，包括：

打包所述应用链待挖区块，并在所述应用链待挖区块的首个交易中保存所述应用链矿工被推选为所述提案组成员的证据。

13.根据权利要求11所述的区块链记账方法，其特征在于，所述打包所述应用链待挖区块，包括：

判断确定所述提案组领导人的基链区块的高度与所述应用链待挖区块的高度之差是否大于预设的第一差值阈值；

若两个高度之差大于所述第一差值阈值，则连续打包所述应用链待挖区块以及预设个数的空块；其中，所述预设个数不小于1。

14.根据权利要求11所述的区块链记账方法，其特征在于，在所述打包所述应用链待挖区块之后，所述方法还包括：

将所述应用链待挖区块广播给周边局部范围内的其他应用链矿工。

15.根据权利要求14所述的区块链记账方法，其特征在于，所述将所述应用链待挖区块广播给周边局部范围内的其他应用链矿工，包括：

在用于广播所述应用链待挖区块的广播消息中指定转发次数，所述应用链待挖区块每经过一次转发，所述广播消息中的转发次数减去1，在所述转发次数减少至0时停止广播所述应用链待挖区块。

16.根据权利要求1所述的区块链记账方法，其特征在于，所述基链由至少一条并行链构成，所述向基链矿工发送针对所述应用链待挖区块的挖矿请求，包括：

向所述基链的至少一条并行链中的一条并行链上的基链矿工发送针对所述应用链待挖区块的挖矿请求。

17.根据权利要求16所述的区块链记账方法，其特征在于，所述向所述基链的至少一条并行链中的一条并行链上的基链矿工发送针对所述应用链待挖区块的挖矿请求，包括：

根据如下公式从所述基链的至少一条并行链中确定一条并行链，并向该并行链上的基链矿工发送针对所述应用链待挖区块的挖矿请求：

n＝(ChainNoOffet+k)％N

其中，N为所述基链的并行链的总数，N为正整数，并且所述基链的N条并行链按照从0至N-1依次编号，ChainNoOffet为所述应用链预设的链号偏移，k为构成所述应用链的并行链中所述提案组成员挖矿所在的并行链链号，％表示取余数运算，n表示确定出的所述基链的并行链链号。

18.根据权利要求1所述的区块链记账方法，其特征在于，所述同步基链区块信息，包括：

从所述基链中设置的同步节点同步基链区块信息。

19.根据权利要求1所述的区块链记账方法，其特征在于，所述基链区块信息采用的形式包括以下之一：

确定所述提案组领导人的基链区块本身；

所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的选举结果，包括所述应用链待挖区块的提案组领导人的选举结果；

所述基链区块的区块头以及所述基链区块的区块体中针对所述应用链的片断数据；其中，所述片断数据包括所述选举结果列表中针对所述应用链待挖区块的提案组领导人的选举结果，以及，所述选举结果与所述基链区块的区块头中基于所述选举结果列表计算出的merkle根之间的merkle路径。

20.根据权利要求1所述的区块链记账方法，其特征在于，推选所述应用链待挖区块的验证组成员分为至少一轮进行；

当所述应用链矿工同步到确定所述应用链待挖区块的提案组领导人的基链区块信息，就参与前P轮验证组成员的推选，之后所述应用链矿工每同步到一个基链区块信息，就参与新一轮验证组成员的推选，除非满足以下条件之一，不再参与新一轮验证组成员的推选：

所述应用链矿工在已参与的推选轮次中确定自身被推选为验证组成员；

所述应用链矿工根据当前已接收到的检验报告能够得出所述提案组领导人所出区块验证通过的结论；

所述应用链矿工已参与的推选轮次已经达到预设的最大轮次；

其中，1≤P≤MaxRounds，MaxRounds为所述最大轮次，若所述应用链矿工在已参与的推选轮次中确定自身被推选为验证组成员，则对所述提案组领导人所出区块进行验证，向其他应用链矿工广播检验报告。

21.根据权利要求1所述的区块链记账方法，其特征在于，所述确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员，包括：

基于所述应用链矿工的私钥以及利用预设规则确定的第二选举字串调用VRF算法中的证明函数，获得第二可证明字串；

基于所述第二可证明字串推导第三随机值，并根据所述第三随机值以及所述应用链矿工的验证组参选权重确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员；其中，所述应用链矿工被选为验证组成员的概率与所述验证组参选权重的取值正相关。

22.根据权利要求21所述的区块链记账方法，其特征在于，所述验证组参选权重根据所述应用链矿工当前持有数字货币的数量进行计算，若所述应用链矿工当前未持有数字货币，则所述验证组参选权重取0。

23.根据权利要求22所述的区块链记账方法，其特征在于，若所述应用链矿工当前持有的数字货币数量使得所述验证组参选权重大于预设的验证组最大参选权重，则所述验证组参选权重取所述验证组最大参选权重。

24.根据权利要求22所述的区块链记账方法，其特征在于，若所述应用链矿工当前持有数字货币的数量小于预设的最小持币量，则所述应用链矿工不参与验证组成员的推选。

25.根据权利要求21所述的区块链记账方法，其特征在于，推选所述应用链待挖区块的验证组成员分为至少一轮进行，所述第二选举字串根据以下信息计算：

所述提案组领导人的矿工标识、确定所述提案组领导人的基链区块的高度、所述应用链待挖区块的高度以及推选所述验证组成员的轮次编号。

26.根据权利要求1所述的区块链记账方法，其特征在于，所述提案组领导人在广播所出区块时，还附带广播所述提案组领导人发送的针对该区块的挖矿请求中的提案候选信息，被推选为所述应用链待挖区块的验证组成员的所述应用链矿工对所述提案组领导人所出区块进行验证，包括以下验证项目：

根据所述提案候选信息中的确定提案组领导人的基链区块的高度，确定所述提案组领导人被推选为提案组成员时依赖的第一选举字串，基于所述提案候选信息中的第一可证明字串、所述提案候选信息中的应用链矿工公钥以及所述第一选举字串调用VRF算法中的验证函数，验证所述提案候选信息中的第一可证明字串是否被伪造；

验证所述提案候选信息中的应用链矿工公钥对应的应用链矿工是否为所述提案组领导人所出区块的创建者；

根据所述提案候选信息中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人，验证查询出的所述提案组领导人与所述提案候选信息确定的所述提案组领导人是否一致；

验证所述提案组领导人所出区块中的所有交易是否正确；

若所有验证项目的验证结果均为“是”，则生成检验结论为验证通过的检验报告，否则生成检验结论为验证未通过的检验报告。

27.根据权利要求26所述的区块链记账方法，其特征在于，所述提案组领导人所出区块的区块头中保存有表征区块创建者身份的公钥信息，所述验证所述提案候选信息中的应用链矿工公钥对应的应用链矿工是否为所述提案组领导人所出区块的创建者，包括：

验证根据所述提案候选信息中的应用链矿工公钥获得的公钥信息与所述区块头中保存的公钥信息是否一致，若一致，则确认所述提案候选信息中的应用链矿工公钥对应的应用链矿工是所述提案组领导人所出区块的创建者，否则该应用链矿工四·不是所述提案组领导人所出区块的创建者。

28.根据权利要求26所述的区块链记账方法，其特征在于，所述提案组领导人在广播所出区块时，还附带广播所述提案组领导人利用自身的私钥对所出区块的签名，所述验证所述提案候选信息中的应用链矿工公钥对应的应用链矿工是否为所述提案组领导人所出区块的创建者，包括：

利用所述提案候选信息中的应用链矿工公钥验证广播消息中携带的对所述提案组领导人所出区块的签名是否正确，若正确，则确认所述提案候选信息中的应用链矿工公钥对应的应用链矿工是所述提案组领导人所出区块的创建者，否则该应用链矿工不是所述提案组领导人所出区块的创建者。

29.根据权利要求26所述的区块链记账方法，其特征在于，所述根据所述提案候选信息中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人，验证查询出的所述提案组领导人与所述提案候选信息确定的所述提案组领导人是否一致，包括：

根据所述提案候选信息中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人的公钥，验证查询出的所述提案组领导人的公钥与所述提案候选信息中的应用链矿工公钥是否一致，若一致，则确认查询出的所述提案组领导人与所述提案候选信息确定的所述提案组领导人一致，否则两个提案组领导人不一致；

或者，

根据所述提案候选信息中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人的矿工标识，基于所述提案候选信息中的应用链矿工公钥、所述提案候选信息中的应用链标识以及所述提案候选信息中的并行链链号，利用哈希算法计算所述提案组领导人的矿工标识，并验证查询出的所述提案组领导人的矿工标识与计算出的所述提案组领导人的矿工标识是否一致，若一致，则确认查询出的所述提案组领导人与所述提案候选信息确定的所述提案组领导人一致，否则两个提案组领导人不一致。

30.根据权利要求1所述的区块链记账方法，其特征在于，所述根据所述检验报告确定所述提案组领导人所出区块验证通过，包括：

若收到的检验报告中检验通过的报告份数不小于最小成功验证数，以及，检验不通过的报告份数不大于最大失败验证数，则确定所述提案组领导人所出区块验证通过；

其中，所述最小成功验证数以及所述最大失败验证数为预设值，或者，根据一预设时间段内被选为提案组领导人的应用链矿工的个数进行推算。

31.根据权利要求1所述的区块链记账方法，其特征在于，所述根据所述检验报告确定所述提案组领导人所出区块验证通过，包括：

确定收到的检验报告的在验证过程中所占的票数,每份检验报告所占的票数与生成该检验报告的验证组成员当前持有的数字货币的数量正相关；

若收到的检验报告中检验通过的报告所占的总票数不小于最小成功验证数，以及，检验不通过的报告所占的总票数不大于最大失败验证数，则确定所述提案组领导人所出区块验证通过。

32.根据权利要求31所述的区块链记账方法，其特征在于，所述确定收到的检验报告的在验证过程中所占的票数，包括：

根据如下公式确定收到的检验报告的在验证过程中所占的票数：

vote_num＝1+stake/leverage

其中，vote_num为所述检验报告所占的票数，stake为生成所述检验报告的验证组成员当前持有的数字货币的数量，leverage为预设的票数调节比例。

33.根据权利要求30所述的区块链记账方法，其特征在于，所述方法还包括：

若收到的检验报告中检验通过的报告份数占所述最小成功验证数的比例不小于预设的已验证比例，则提前开始下一应用链待挖区块的提案组成员的推选。

34.根据权利要求1所述的区块链记账方法，其特征在于，所述检验报告包括以下信息：

提案组领导人的矿工标识、确定提案组领导人的基链区块的高度、应用链待挖区块的高度、推选验证组成员的轮次编号、生成检验报告的验证组成员的公钥、应用链矿工被推选为验证组成员时依赖的第二可证明字串、应用链待挖区块的哈希值、检验结论以及利用验证组成员的私钥对检验报告的签名。

35.根据权利要求34所述的区块链记账方法，其特征在于，在所述应用链矿工认可所述检验报告中的检验结论之前，所述方法还包括：

利用所述检验报告中的验证组成员的公钥确认报告中的签名正确；

根据所述检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人，确认查询出的所述提案组领导人与所述检验报告所确定的所述提案组领导人一致；

根据所述检验报告中的提案组领导人的矿工标识、确定提案组领导人的基链区块的高度、应用链待挖区块的高度以及推选验证组成员的轮次编号计算生成所述检验报告的应用链矿工被推选为所述验证组成员时依赖的第二选举字串，基于所述第二选举字串、所述检验报告中的生成检验报告的验证组成员的公钥以及所述检验报告中的第二可证明字串调用VRF算法中的验证函数，确认所述检验报告中的第二可证明字串未被伪造；

基于所述检验报告中的第二可证明字串推导第三随机值，并根据所述第三随机值确认生成所述检验报告的应用链矿工为所述验证组成员。

36.根据权利要求35所述的区块链记账方法，其特征在于，所述根据所述检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人，确认查询出的所述提案组领导人与所述检验报告确定的所述提案组领导人一致，包括：

根据所述检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人的公钥，基于查询出的所述提案组领导人的公钥、所述应用链矿工挖矿所在的应用链标识以及并行链链号，利用哈希算法计算所述提案组领导人的矿工标识，确认计算出的所述提案组领导人的矿工标识与所述检验报告中的提案组领导人的矿工标识一致；

或者，

根据所述检验报告中的确定提案组领导人的基链区块的高度从本地的基链账本中查询所述提案组领导人的矿工标识，确认查询出的所述提案组领导人的矿工标识与所述检验报告中的提案组领导人的矿工标识一致。

37.根据权利要求1所述的区块链记账方法，其特征在于，所述方法还包括：

若根据所述检验报告确定所述提案组领导人所出区块验证通过，则开始下一应用链待挖区块的提案组成员的推选；

若根据所述检验报告确定所述提案组领导人所出区块验证未通过，则弃用所述提案组领导人所出区块，若该区块之后还串接了其他区块则一同弃用，并重新开始所述应用链待挖区块的提案组成员的推选。

38.根据权利要求20所述的区块链记账方法，其特征在于，P＞1，所述若根据所述检验报告确定所述提案组领导人所出区块验证通过，则将该区块纳入应用链账本中，包括：

若根据所述检验报告确定所述提案组领导人所出区块验证通过，且得出通过结论的所依赖的检验报告均已生效，则将该区块纳入应用链账本中；其中，所述检验报告在所述应用链矿工同步到报告生成轮次对应的基链区块信息后生效，所述报告生成轮次是指生成所述检验报告的应用链矿工被推选为验证组成员的推选轮次。

39.根据权利要求20所述的区块链记账方法，其特征在于，所述方法还包括：

从所述应用链矿工同步到确定所述应用链待挖区块的提案组领导人的基链区块信息起的MaxRounds+Q个基链出块时间内，持续接收针对所述提案组领导人所出区的检验报告，并根据新接收到的检验报告维持或变更之前作出的所述提案组领导人所出区块验证通过的结论；

其中，所述应用链矿工至多允许包含所述应用链待挖区块在内的最近Q+1个高度的区块同时处于验证状态，Q取0或正整数。

40.根据权利要求1所述的区块链记账方法，其特征在于，所述基链以及所述应用链均遵循最长链规则，所述应用链中的最长链切换包括第一重最长链切换以及第二重最长链切换两种类型；

其中，所述第一重最长链切换在所述应用链矿工将应用链区块的区块头纳入应用链账本后触发，所述第二重最长链切换在所述应用链矿工将同步到的基链区块信息纳入本地的基链账本、并使得本地的基链账本中产生最长链切换后触发。

41.根据权利要求40所述的区块链记账方法，其特征在于，在所述应用链矿工执行已触发的第一重最长链切换的过程中，不响应新触发的第一重最长链切换或第二重最长链切换；

在所述应用链矿工执行已触发的第二重最长链切换的过程中，若有新的第二重最长链切换被触发，则终止正在执行的第二重最长链切换，并开始执行新触发的第二重最长链切换；

在所述应用链矿工执行已触发的第二重最长链切换的过程中，若有新的第一重最长链切换被触发，则判断基链指示的已确定提案组领导人的应用链区块的最高高度，是否小于纳入触发所述第一重最长链切换的区块头的应用链候选分支的高度，若是，则终止正在执行的第二重最长链切换，并开始执行新触发的第一重最长链切换，若否，则不响应新触发的第一重最长链切换。

42.根据权利要求40所述的区块链记账方法，其特征在于，所述应用链矿工进行第二重最长链切换，包括：

确定应用链待切换分支上的最后一个已确收区块，并从所述已确收区块之后的区块开始，正向遍历所述应用链待切换分支，并在遍历过程中将所述应用链待切换分支上的区块纳入应用链账本中；

其中，所述应用链待切换分支是指基链指示的应用链最长链，所述已确收区块是指区块头已被所述应用链矿工接收并且所述应用链矿工根据接收的检验报告已确定其验证通过的区块。

43.根据权利要求42所述的区块链记账方法，其特征在于，所述确定应用链待切换分支上的最后一个已确收区块，并从所述已确收区块之后的区块开始，正向遍历所述应用链待切换分支，并在遍历过程中将所述应用链待切换分支上的区块纳入应用链账本中，包括：

从本地的基链账本中基链最长链的最后一个区块开始逆向遍历所述基链最长链，在所述应用链待切换分支上已选出提案组领导人的区块中确定最后一个已确收区块；

若所述最后一个已确收区块不是所述应用链待切换分支上的最后一个区块，则将基链指示的所述已确收区块之后的首个已选出提案组领导人的区块确定为待定首区块，并在至多Z个基链出块时间内等待所述待定首区块被确收；其中，Z为正整数；

若所述待定首区块的提案组领导人是所述应用链矿工自身，则判断所述应用链矿工是否打包过所述待定首区块，若是，则重用已打包的所述待定首区块，若否，则打包所述待定首区块，且不论是或否，都向其他应用链矿工广播所述待定首区块并开始所述待定首区块的验证组成员的推选；若所述待定首区块的提案组领导人不是所述应用链矿工自身，则直接开始所述待定首区块的验证组成员的推选；

对所述待定首区块的验证进度进行监控，若从所述应用链矿工开始推选所述待定首区块的提案组成员起的Z个基链出块时间内，所述待定首区块被纳入应用链账本，则将基链指示的所述待定首区块之后的首个已选出提案组领导人的区块确定为下一待定首区块；

判断所述下一待定首区块是否已经确收，若已确收，或者虽未确收但在至多Z个基链出块时间内确收，则尝试将所述下一待定首区块纳入应用链账本；

持续正向遍历所述应用链待切换分支查找后续的待定首区块，直至将所述应用链待切换分支上的区块都纳入应用链账本后，结束所述第二重最长链切换。

44.根据权利要求43所述的区块链记账方法，其特征在于，所述方法还包括：

若所述最后一个已确收区块是所述应用链待切换分支上的最后一个区块，则将所述最后一个已确收区块的下一区块确定为下一应用链待挖区块并开始该区块的提案组成员的推选。

45.根据权利要求43所述的区块链记账方法，其特征在于，所述方法还包括：

若从所述应用链矿工开始推选所述待定首区块的提案组成员起的Z个基链出块时间内，所述待定首区块未被纳入应用链账本，则终止所述第二重最长链切换，重新开始所述待定首区块的提案组成员的推选。

46.根据权利要求43所述的区块链记账方法，其特征在于，若所述待定首区块是所述应用链待切换分支上的最后一个区块，则Z＝MaxRounds+Q，否则Z≥MaxRounds+Q；其中，MaxRounds为所述应用链矿工推选验证组成员的最大轮次，Q为所述应用链矿工允许额外同时处于验证状态的区块的高度的数量。

47.根据权利要求43所述的区块链记账方法，其特征在于，所述方法还包括：

若任一待定首区块在至多等待的Z个基链出块时间未确收，则终止所述第二重最长链切换，重新开始所述待定首区块的提案组成员的推选。

48.一种区块链记账方法，其特征在于，应用于基链矿工，所述方法包括：

根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人；

将保存有选举结果以及选举依据的基链区块纳入基链账本中。

49.根据权利要求48所述的区块链记账方法，其特征在于，所述挖矿请求中包括提案候选信息，所述提案候选信息包括：

应用链标识、并行链链号、应用链待挖区块的高度、确定提案组领导人的基链区块的高度、应用链矿工公钥以及第一可证明字串。

50.根据权利要求49所述的区块链记账方法，其特征在于，在所述根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人之前，所述方法还包括：

根据所述挖矿请求中的应用链标识确定该标识对应的应用链由所述基链提供算力支持；

根据所述挖矿请求中的确定提案组领导人的基链区块的高度确定发送所述挖矿请求的应用链矿工被推选为提案组成员时依赖的第一选举字串，基于所述挖矿请求中的应用链矿工公钥、所述挖矿请求中的第一证明字串以及所述第一选举字串调用VRF算法中的验证函数，确定所述挖矿请求中的第一可证明字串未被伪造。

51.根据权利要求49所述的区块链记账方法，其特征在于，在所述根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人之前，所述方法还包括：

根据所述挖矿请求中的应用链标识、并行链链号以及应用链矿工公钥，利用哈希算法计算发送所述挖矿请求的提案组成员的矿工标识；

确定计算出的矿工标识不在所述基链针对所述应用链配置的黑名单中。

52.根据权利要求50所述的区块链记账方法，其特征在于，所述方法还包括：

从所述基链中设置的管理节点获取授权及配置信息；其中，授权信息包括向所述管理节点进行过注册从而获得了所述基链的算力支持的应用链的信息，配置信息包括所述基链矿工所使用的预设参数。

53.根据权利要求52所述的区块链记账方法，其特征在于，所述从所述基链中设置的管理节点获取授权及配置信息，包括：

在所述基链的难度调整周期开始时向所述基链中设置的管理节点查询本地保存的授权及配置信息是否是最新版本，若不是最新版本则从所述管理节点同步最新版本的授权及配置信息；其中，每隔预设数量的难度调整周期进行一次查询。

54.根据权利要求49所述的区块链记账方法，其特征在于，所述根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人，包括：

根据基链账本中记录的、已经选出提案组领导人的应用链最高区块确定所述应用链待挖区块所在的新高度，并将其中包含的应用链待挖区块的高度与所述新高度一致的挖矿请求纳入针对所述新高度的待选举集合；

若针对所述新高度的待选举集合中的请求个数不小于预设的最低矿工个数，则根据针对所述新高度的待选举集合中的每个挖矿请求中的第一可证明字串，确定所述应用链在所述新高度的区块的提案组领导人。

55.根据权利要求54所述的区块链记账方法，其特征在于,在所述根据基链账本中记录的、已经选出提案组领导人的应用链最高区块确定所述应用链待挖区块所在的新高度之后，所述方法还包括：

判断确定所述应用链待挖区块的提案组领导人的基链区块的高度与所述新高度之差是否大于预设的第一差值阈值；

若两个高度之差大于所述第一差值阈值，则标记所述应用链在所述新高度进行连续出块。

56.根据权利要求55所述的区块链记账方法，其特征在于,所述方法还包括：

若两个高度之差大于预设的第二差值阈值，则拒绝为所述应用链继续提供算力支持；其中，所述第二差值阈值大于所述第一差值阈值。

57.根据权利要求54所述的区块链记账方法，其特征在于，所述根据针对所述新高度的待选举集合中的每个挖矿请求中的第一可证明字串，确定所述应用链在所述新高度的区块的提案组领导人，包括：

根据针对所述新高度的待选举集合中的每个挖矿请求中的第一可证明字串计算该挖矿请求对应的第二随机值，并将计算出的第二随机值满足预设的当选条件的挖矿请求对应的提案组成员确定为所述应用链在所述新高度的区块的提案组领导人。

58.根据权利要求57所述的区块链记账方法，其特征在于，所述当选条件为计算出的第二随机值最大。

59.根据权利要求58所述的区块链记账方法，其特征在于，所述当选条件为计算出的第二随机值最大且所述第二随机值大于预设的最小当选随机值。

60.根据权利要求58所述的区块链记账方法，其特征在于，所述方法还包括：

若所述应用链被配置为不允许同一矿工连续挖矿、且根据最大的第二随机值确定的提案组领导人在针对所述应用链的上一次提案组领导人选举中也被选为提案组领导人，则将计算出的第二随机值次大的挖矿请求对应的提案组成员确定为所述应用链在所述新高度的区块的提案组领导人。

61.根据权利要求54或59所述的区块链记账方法，其特征在于，所述方法还包括：

若根据针对所述新高度的待选举集合中的挖矿请求选举所述新高度的区块的提案组领导人失败，则获取所述应用链中与所述应用链待挖区块相邻的且已经选出提案组领导人的区块所在的旧高度，并将其中包含的应用链待挖区块的高度与所述旧高度一致的挖矿请求纳入针对所述旧高度的待选举集合；

根据针对所述旧高度的待选举集合中的挖矿请求重新选举所述应用链在所述旧高度的区块的提案组领导人，若选举成功，则在所述基链本次所出区块中保存选举结果以及选举依据，若选举失败，则继续针对前一旧高度执行收集挖矿请求以及选举提案组领导人的重新挖矿操作，直至针对所述应用链的一旧高度选举提案组领导人成功或者针对所述应用链的旧高度的重新挖矿操作达到预设的次数限制；

若针对所述应用链的旧高度的重新挖矿操作已经达到预设的次数限制但仍未成功选出提案组领导人，则在基链下次出块时再针对所述应用链在所述新高度的区块选举提案组领导人。

62.根据权利要求54所述的区块链记账方法，其特征在于，所述选举结果包括从所述应用链的提案组领导人发送的挖矿请求中获取的提案候选信息；

所述选举结果作为选举结果列表中的一个表项保存在所述基链区块的区块体中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的选举结果；

基于所述选举结果列表的表项计算出的merkle根保存在所述基链区块的区块头中。

63.根据权利要求54所述的区块链记账方法，其特征在于，所述选举结果包括所述提案组领导人的矿工标识以及所述应用链待挖区块的高度；

所述提案组领导人的矿工标识基于所述提案组领导人发送的挖矿请求中的应用链标识、并行链链号以及应用链矿工公钥，利用哈希算法进行计算，所述应用链待挖区块的高度复制自所述提案组领导人发送的挖矿请求中的对应信息项；

所述选举结果作为选举结果列表中的一个表项保存在所述基链区块的区块体中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的选举结果；

基于所述选举结果列表的表项计算出的merkle根保存在所述基链区块的区块头中。

64.根据权利要求62或63所述的区块链记账方法，其特征在于，所述选举依据包括从针对所述新高度的待选举集合中的挖矿请求中获取的提案候选信息的集合；

所述选举依据作为选举依据列表中的一个表项保存在所述基链区块的区块体中，所述选举依据列表中的每个表项对应一条应用链上的一个待挖区块的选举依据；

基于所述选举依据列表的表项计算出的merkle根保存在所述基链区块的区块头中。

65.根据权利要求64所述的区块链记账方法，其特征在于，所述方法还包括：

向所述基链中设置的同步节点发送所述基链区块；

或者，向所述同步节点发送所述基链区块的区块头以及所述基链区块的区块体中的所述选举结果列表。

66.根据权利要求64所述的区块链记账方法，其特征在于，在基链账本中区块按照如下方式保存：

在所述基链的最近D个难度调整周期内生成的区块保存区块头以及区块体；其中，D为正整数；

在所述基链的最近D个难度调整周期之前生成的区块保存区块头以及选举结果列表，若所述选举结果列表的表项中包含提案组领导人的矿工标识，则还要保存选举依据列表中由所述提案组领导人自身产生的提案候选信息。

67.一种区块链记账方法，其特征在于，应用于基链中设置的同步节点，所述方法包括：

接收基链矿工发送的确定应用链待挖区块的提案组领导人的基链区块，或者，接收所述基链矿工或基链中设置的其他同步节点发送的所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；其中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的提案组领导人的选举结果，包括所述应用链待挖区块的提案组领导人的选举结果；

向应用链矿工发送来源于所述基链区块的基链区块信息，所述基链区块信息采用的形式包括以下之一：

所述基链区块本身；

所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；

所述基链区块的区块头以及所述基链区块的区块体中针对所述应用链的片断数据；其中，所述片断数据包括所述选举结果列表中针对所述应用链待挖区块的提案组领导人的选举结果，以及，所述选举结果与所述基链区块的区块头中基于所述选举结果列表计算出的merkle根之间的merkle路径。

68.根据权利要求67所述的区块链记账方法，其特征在于，所述方法还包括：

向基链中设置的其他同步节点发送所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表。

69.一种区块链记账装置，其特征在于，配置于应用链中设置的挖矿节点，所述装置包括：

提案组推选模块，用于应用链矿工参与应用链待挖区块的提案组成员的推选；其中，若确定所述应用链矿工被推选为应用链待挖区块的提案组成员，则向基链矿工发送针对所述应用链待挖区块的挖矿请求，所述提案组为有权发送挖矿请求的应用链矿工的集合；

区块信息同步模块，用于所述应用链矿工同步基链区块信息，并将所述基链区块信息纳入本地的基链账本中，所述基链区块信息来源于基链矿工根据所述挖矿请求生成的确定所述应用链待挖区块的提案组领导人的基链区块，所述基链区块信息中包括指示所述提案组领导人的选举结果；其中，所述提案组领导人为具有所述应用链待挖区块的出块权的提案组成员；

验证组推选模块，用于所述应用链矿工参与应用链待挖区块的验证组成员的推选；其中，若确定所述应用链矿工被推选为所述应用链待挖区块的验证组成员，则对所述提案组领导人所出区块进行验证，并向其他应用链矿工广播检验报告，所述验证组为有权生成检验报告的应用链矿工的集合，所述提案组领导人所出区块包括所述提案组领导人打包的所述应用链待挖区块；

应用链记账模块，用于所述应用链矿工接收所述检验报告，若根据所述检验报告确定所述提案组领导人所出区块验证通过，则将该区块纳入应用链账本中。

70.一种区块链记账装置，其特征在于，配置于基链中设置的挖矿节点，所述装置包括：

选举模块，用于基链矿工根据应用链待挖区块的提案组成员发送的针对所述应用链待挖区块的挖矿请求为所述应用链待挖区块选举提案组领导人；

基链记账模块，用于所述基链矿工将保存有选举结果以及选举依据的基链区块纳入基链账本中。

71.一种区块链记账装置，其特征在于，配置于基链中设置的同步节点，所述装置包括：

信息接收模块，用于所述同步节点接收基链矿工发送的确定应用链待挖区块的提案组领导人的基链区块，或者，接收所述基链矿工或基链中设置的其他同步节点发送的所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；其中，所述选举结果列表中的每个表项对应一条应用链上的一个待挖区块的提案组领导人的选举结果，包括所述应用链待挖区块的提案组领导人的选举结果；

信息发送模块，用于所述同步节点向应用链矿工发送来源于所述基链区块的基链区块信息，所述基链区块信息采用的形式包括以下之一：

所述基链区块本身；

所述基链区块的区块头以及所述基链区块的区块体中的选举结果列表；

所述基链区块的区块头以及所述基链区块的区块体中针对所述应用链的片断数据；其中，所述片断数据包括所述选举结果列表中针对所述应用链待挖区块的提案组领导人的选举结果，以及，所述选举结果与所述基链区块的区块头中基于所述选举结果列表计算出的merkle根之间的merkle路径。

72.一种区块链节点，其特征在于，设置在应用链上，所述节点包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求1-47中任一项所述的方法。

73.一种区块链节点，其特征在于，设置在基链上，所述节点包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求48-66中任一项所述的方法。

74.一种区块链节点，其特征在于，设置在基链上，所述节点包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求67或68所述的方法。

75.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机运行时，执行如权利要求1-68中任一项所述的方法。

Images