CN114157550B - 一种基于无冲突事务合并的联盟区块链系统 - Google Patents

Abstract

本发明提供一种基于无冲突事务合并的联盟区块链系统，涉及区块链技术领域。该系统是由多个全节点和多个Epoch服务器组成的区块链网络；Epoch服务器只负责为全节点提供Epoch号服务，Epoch服务器之间通过共识来增加Epoch号，系统其他功能都由全节点完成；每个全节点都存储完整的区块链副本；该系统具体包括持久层、逻辑层、网络层和应用层；持久层用于状态数据存储、无冲突事务数据存储以及区块数据存储的持久层；逻辑层包括交易分割方法、事务确定性排序方法、无冲突事务处理方法以及系统运行所必须的功能模块；网络层包括P2P网络配置、全节点间的数据传输以及心跳机制；应用层包括一个客户端程序，并支持开发各种应用程序。

Description

一种基于无冲突事务合并的联盟区块链系统

技术领域

本发明涉及区块链技术领域，尤其涉及一种基于无冲突事务合并的联盟区块链系统。

背景技术

区块链本质上是一个去中心化的分布式数据库系统。随着区块链的不断发展，出现了以太坊、HyperLdeger Fabric等许多区块链系统，区块链技术也从加密货币领域拓展到了金融、物流、版权等许多领域。

以太坊系统通过基于工作量证明机制的POW共识算法，选择出块节点，出块节点将交易排序打包成区块后将区块广播到其他的记账节点，每个节点验证区块正确性后顺序执行交易并将区块加入到本地区块链上。由于POW算法的限制和以太坊网络中每个节点都顺序执行一遍区块内的交易，这导致以太坊系统性能很低。HyperLedger Fabric创新性地引入了一种新架构：客户端发送交易给背书节点并发执行，背书节点将执行结果返回给客户端；客户端将包含执行结果的交易发给排序节点；排序节点对包含执行结果的一批交易排序并打包成新区块，将新区块广播到到所有记账节点；各记账节点验证区块正确性后，验证区块内的交易是否冲突，若不冲突，使用执行结果更新数据库，若冲突，则将这笔交易标记为无效，最后将区块加入到本地区块链上。由于Fabric系统更换了共识算法，并且在背书阶段交易可以并发执行，Fabric系统的性能远高于以太坊系统，但是目前区块链系统的性能仍然很低。

并发执行模型是提升区块链性能的一个重要研究方向。目前有许多区块链系统都结合了并发执行模型。如HyperLedger Fabric区块链、SlimChain区块链等。但是并发执行模型也带来了冲突事务被废弃的问题，从而限制了系统的性能。如Fabric系统中冲突事务被标记为无效。事务冲突本质上是由于事务的顺序问题，上一笔事务的执行结果，会影响下一笔事务的执行。像这种对顺序敏感的事务必须按照顺序更新数据库，如果基于上一个区块的状态并发执行事务，在更新数据库时，必然会导致只能成功提交冲突事务中排在最前面的那笔事务，其余的事务都被废弃。

一些事务对于顺序并不敏感，是可以通过合并规则来保证这些事务都能够成功提交的，这种事务为无冲突事务。尽管很少一个应用程序内的事务全部都是无冲突的。但是许多应用程序内都存在一些无冲突事务，对于这些无冲突事务，使用基于冲突事务合并的区块链来实现，性能可以提升几倍甚至几十倍、几百倍。若不是无冲突事务，通过使用原来的废弃冲突事务的方法，仍然能够保持与基于现有区块链系统实现时的同样性能。

发明内容

本发明要解决的技术问题是针对上述现有技术的不足，提供一种基于无冲突事务合并的联盟区块链系统，解决区块链网络中存在的冲突事务。

为解决上述技术问题，本发明所采取的技术方案是：一种基于无冲突事务合并的联盟区块链系统，为包括多个全节点和多个Epoch服务器的区块链网络；Epoch服务器只负责为全节点提供Epoch号服务，Epoch服务器之间通过共识来增加Epoch号，系统其他功能都由全节点完成；每个全节点都存储完整的区块链副本；一个联盟的组织内有一个或多个全节点，同时为了安全性，每个组织提供一台机器去作为Epoch服务器参与Epoch共识。

优选地，所述一种基于无冲突事务合并的联盟区块链系统包括持久层、逻辑层、网络层和应用层；

所述持久层用于状态数据存储以及区块数据存储，区块数据使用数据库或文件来存储；而对于状态数据则需要使用数据库来存储，因为每个交易的执行都需要访问状态数据；对于无冲突事务，使用无冲突事务的存储结构进行存储；

所述逻辑层包括基于Epoch的交易分割方法、基于哈希函数的事务确定性排序方法，无冲突事务处理方法，以及系统运行所必须的功能模块；

所述网络层包括P2P网络配置、全节点间的数据传输以及心跳机制；P2P网络配置采用配置文件的方式进行网络配置；全节点之间的数据传输使用ZeroMQ完成，全节点之间数据传输使用的消息格式通过ProtoBuf来定义；节点间的心跳机制用来检测区块链网络内部的故障节点；

所述应用层包括一个客户端程序，并支持开发各种应用程序；所述客户端程序用于向全节点发出交易请求，查询执行结果、查询区块数据。

优选地，基于Epoch的交易分割方法具体为：

当系统中全节点收集了由客户端发起的一组事务后，先验证事务的合法性，然后它将生成一个请求并将其发送到Epoch服务器；该请求包括这组事务的摘要和组中的事务数量；每个组都由有序的事务组成；Epoch服务器为该组事务分配Epoch号，并使用组摘要和Epoch号生成证明；因为Epoch服务器之间已经达成了共识，因此Epoch号分配不需要额外的共识；每个全节点在一个Epoch号中生成多个组；随后，在完成一个Epoch之后，每个全节点将已签名的组广播给其他全节点；其他全节点收集一个Epoch期间内的所有组，然后将通一个Epoch号的所有事务划分到一个区块中。

优选地，基于哈希函数的事务确定性排序方法具体为：

Epoch服务器为一组事务分配Epoch号之后，全节点收集同一Epoch服务器的所有事务；全节点通过使用哈希函数为每个事务生成TID；按照TID的大小对区块内的事务进行排序；各全节点使用相同的哈希函数独自生成TID并保证全节点之间的一致性和随机性；在基于冲突事务合并的联盟区块链中，使用客户端id和事务请求签名作为哈希函数的输入来创建TID。

优选地，所述无冲突事务处理方法，具体为：

当全节点根据基于Epoch的交易分割方法收集完区块号为n的所有事务，并根据基于哈希函数的事务确定性方法排序后，基于第n-1个区块上链后的状态，并发执行区块n内的所有事务，生成每个事务的读写集，对于普通事务按照MVCC并发控制方法验证事务是否冲突，提交通过验证的事务，未通过的事务标记为无效；对于无冲突事务，调用对应的合并方法提交全部无冲突事务。

优选地，所述系统运行所必须的功能模块包括默克尔树生成模块、区块组装模块、区块验证模块、无冲突事务合并模块和MVCC并发控制模块；

所述默克尔树生成模块根据一个区块内的所有事务生成一颗默克尔树，最后将默克尔树根存放在区块头部，用于验证区块的数据完整性以及每笔事务的正确性；

所述区块组装模块负责将前一个区块的哈希、默克尔树根、时间戳、事务列表组装到一个区块中；

所述区块验证模块用于确保当前节点生成的区块与其他非恶意的节点生成的区块相同；

所述无冲突事务合并模块调用合并方法合并无冲突事务，合并方法是由应用程序开发者实现的，并且每个无冲突事务的合并方法都是不同的，应用程序开发者需要保证合并方法的逻辑正确性；

所述MVCC并发控制模块用于检查非无冲突事务之间是否冲突，并废弃冲突事务。

优选地，所述系统运行所必须的功能模块还包括分区聚合模块，该模块通过分区聚合功能执行事务；且分区聚合功能一与配合背书功能一起使用。

优选地，所述无冲突事务接口声明了一个合并方法；合并方法定义了每个无冲突事务的更新规则；所述无冲突事务存储结构基于哈希表实现，每个无冲突事务的数据需要实现无冲突事务接口；每个事务数据的存储对象也实现为一个哈希表，其中，key为string类型的字符串，value为对应事务的实现了无冲突事务接口的对象；实现了无冲突事务接口的对象直接合并对应事务的读写集，完成事务数据更新。

优选地，所述系统还针对系统内部存在拜占庭节点的情况，设计可行方法并实施保障系统安全性，具体为：

第一种情况是恶意的Epoch服务器，会发送给全节点错误的Epoch号；解决办法是多个Epoch服务器基于PBFT共识算法进行共识；全节点获取多个Epoch服务器提供的Epoch号，全节点收到大于1/3节点个数的相同Epoch号时，表示Epoch号是正确的；

第二种情况是在启用分区聚合功能下，恶意的全节点可能会广播错误的执行结果，导致正确的节点使用错误的执行结果更新了数据库；解决办法是分区聚合功能需要配合背书功能一起使用，一组交易，会指定联盟内的几个组织甚至所有组织一同背书，当所有背书结果相同时，才能直接使用这组交易的执行结果，当有一个背书结果不相同时，直接在本地执行这组交易；

第三种情况是恶意的全节点可能会打包不正确的区块并提交上链；解决办法是每个全节点在出完区块后，广播区块的哈希值，只有当本地计算的区块哈希值与区块链网络中的大于1/3节点的区块哈希值一致时才能提交区块。

采用上述技术方案所产生的有益效果在于：本发明提供的基于无冲突事务合并的联盟区块链系统，使用基于Epoch的交易分割方法与基于哈希函数的确定性排序方法替代了Fabric系统中负责排序生成区块的Orderer中心节点，解决了Orderer中心节点单点瓶颈的问题，大幅度提高了系统的吞吐率。同时，分区聚合模块保证了系统具有一定的拓展性。本发明设计的无冲突事务处理流程，包括无冲突事务存储结构、无冲突事务合并模块，能够有效的解决冲突事务被废弃的问题，事务的冲突率越高，使用本系统的吞吐率提升越大。

本发明提供的基于无冲突事务合并的联盟区块链系统，具有较高的吞吐率，相比与HyperLedger Fabric系统吞吐率提升2倍以上。

附图说明

图1为本发明实施例提供的基于无冲突事务合并的联盟区块链系统的结构示意图；

图2为本发明实施例提供的基于无冲突事务合并的联盟区块链系统的架构图；

图3为本发明实施例提供的基于哈希表的无冲突事务存储结构示意图；

图4为本发明实施例提供的基于Epoch号的交易分割方法示意图；

图5为本发明实施例提供的基于哈希函数的事务确定性排序方法示意图；

图6为本发明实施例提供的无冲突事务处理方法示意图；

图7为本发明实施例提供的使用Set_CFS和Max_CFS模板类构建的投票数据存储结构和商业竞拍数据存储结构示意图，其中，(a)为投票数据存储结构图，(b)为商业竞拍数据存储结构图；

图8为本发明实施例提供的基于无冲突事务合并的联盟区块链系统实现的投票应用实验结果图；

图9为本发明实施例提供的基于无冲突事务合并的联盟区块链系统实现的商业竞拍应用实验结果图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

本实施例中，一种基于无冲突事务合并的联盟区块链系统，为由多个全节点和多个Epoch服务器组成的区块链网络；Epoch服务器只负责为全节点提供Epoch号服务，Epoch服务器之间通过共识来增加Epoch号，系统其他功能都由全节点完成；每个全节点都存储完整的区块链副本；一个联盟的组织内有一个或多个全节点，同时为了安全性，每个组织提供一台机器去作为Epoch服务器参与Epoch共识。例如，设计一个联盟区块链系统结构如图1所示，图中展示具有5个全节点和3个Epoch服务器组成的区块链网络。Epoch服务器只负责为全节点提供Epoch号服务，Epoch服务器之间通过共识来增加Epoch号，系统其他功能都由全节点完成。每个全节点都存储完整的区块链副本。

本实施例中，一种基于无冲突事务合并的联盟区块链系统如图2所示，具体包括持久层、逻辑层、网络层和应用层；

所述持久层用于状态数据存储以及区块数据存储，区块数据使用数据库或文件来存储；对于无冲突事务，使用无冲突事务的存储结构来存储；

在本实施例中，由于应用程序几乎不会直接访问区块数据，所以使用文件来存储区块数据。而对于状态数据则需要使用数据库来存储，因为每个交易的执行都需要访问状态数据；本实施例选择了访问速度更快的KV型数据库LevelDB，而不是关系型数据库来存储状态数据。

无冲突事务主要是通过改变使用写集更新数据的规则来保证一致性，为此我们设计了无冲突事务数据的存储结构。

为了规范无冲突事务数据的存储结构，每个无冲突事务的数据需要实现无冲突事务接口(conflict-interface，即CFI)；无冲突事务接口中声明了一个合并方法；合并方法定义了每个无冲突事务的更新规则；每个实现了无冲突事务接口的结构称其为无冲突结构(Conflict Free Structure)，简称CFS。一般的无冲突事务的合并方法都是利用集合、最大值的性质，因为集合和取最大值的操作是满足可交换律的。所以本实施例中，系统提供了预定义的Set_CFS和Max_CFS模板类来帮助程序开发者快速的实现无冲突事务的合并方法以及存储结构。同时为了增强程序的灵活性，Set_CFS、Max_CFS模板都采用C++的模板编程方法。

为了快速的根据事务类型快速检索到事务数据的存储对象，本实施例设计了基于哈希表的无冲突事务存储结构。如图3所示，将所有的无冲突事务数据的存储结构存放在一个哈希表(DBS)中。当处理某一类事务的读写集，可以以O(1)的时间复杂度根据事务类型得到事务数据的存储对象。每个事务数据的存储对象也实现为一个哈希表，其中，key为string类型的字符串，value为对应事务的实现了无冲突事务接口的对象。实现了无冲突事务接口的对象可以直接合并对应事务的读写集，完成事务数据更新。

所述逻辑层包括基于Epoch的交易分割方法、基于哈希函数的事务确定性排序方法，无冲突事务处理方法，以及系统运行所必须的功能模块；

所述系统运行所必须的功能模块包括默克尔(Merkel)树生成模块、区块组装模块、区块验证模块、无冲突事务合并模块和MVCC并发控制模块；

所述默克尔树生成模块根据一个区块内的所有事务生成一颗默克尔树，最后将默克尔树根存放在区块头部，用于快速验证区块的数据完整性以及每笔事务的正确性；

所述区块组装模块负责将前一个区块的哈希、默克尔树根、时间戳、事务列表组装到一个区块中；

所述区块验证模块用于确保当前节点生成的区块与其他非恶意的节点生成的区块相同；

所述无冲突事务合并模块调用合并方法合并无冲突事务，合并方法是由应用程序开发者实现的，并且每个无冲突事务的合并方法都是不同的，应用程序开发者需要保证合并方法的逻辑正确性；

所述MVCC并发控制模块用于检查非无冲突事务之间是否冲突，并废弃冲突事务。

同时为了进一步增强系统的吞吐率和可拓展性，设计了一个可选择启用的分区聚合模块，该模块通过分区聚合功能执行事务；且分区聚合功能一与配合背书功能一起使用。分区聚合是数据库中的概念，即一组事务分成几片执行，每个节点执行一部分，最后互相合并其他节点的执行结果，分区聚合功能能够增强系统的拓展性。但是因为区块链系统中节点之间互不信任，所以分区聚合功能一般需要配合背书功能一起使用，即每一笔事务需要用户指定由哪几个节点背书执行，然后这笔事务就由这几个节点背书执行，其他节点只需要验证背书结果正确性后直接使用这笔事务的执行结果即可，避免了重复执行，能够极大地节约系统算力，提高系统吞吐率；

所述网络层包括P2P网络配置、全节点间的数据传输以及节点间的心跳机制；P2P网络配置采用配置文件的方式进行网络配置，达到方便、灵活的目的；节点之间的数据传输使用ZeroMQ完成，全节点之间数据传输使用的消息格式通过ProtoBuf来定义；节点间的心跳机制用来检测区块链网络内部的故障节点；

所述应用层包括一个客户端程序，并支持开发各种应用程序如投票、商业竞拍等；所述客户端程序用于向全节点发出交易请求，查询执行结果、查询区块数据。

基于Epoch的交易分割方法如图4所示，具体为：

当系统中全节点收集了由客户端发起的一组事务后，先验证事务的合法性，然后它将生成一个请求并将其发送到Epoch服务器；该请求包括这组事务的摘要和组中的事务数量；每个组都由有序的事务组成；Epoch服务器为该组事务分配Epoch号，并使用组摘要和Epoch号生成证明；因为Epoch服务器之间已经达成了共识，因此Epoch号分配不需要额外的共识；每个全节点在一个Epoch号中生成多个组；随后，在完成一个Epoch之后，每个全节点将已签名的组广播给其他全节点；其他全节点收集一个Epoch期间内的所有组，然后将同一个Epoch号的所有事务划分到一个区块中。

基于哈希函数的事务确定性排序方法如图5所示，具体为：

Epoch服务器为一组事务分配Epoch号之后，全节点收集同一Epoch服务器的所有事务；全节点通过使用哈希函数为每个事务生成TID；TID决定了事务处理的顺序；各全节点使用相同的哈希函数独自生成TID并保证全节点之间的一致性和随机性；在基于冲突事务合并的联盟区块链中，使用客户端id和事务请求签名作为哈希函数的输入来创建TID。

无冲突事务处理方法如图6所示，具体为：

当全节点根据基于Epoch的交易分割方法收集完区块号为n的所有事务，并根据基于哈希函数的事务确定性方法排序后，基于第n-1个区块上链后的状态，并发执行区块n内的所有事务，生成每个事务的读写集，对于普通事务按照MVCC并发控制方法验证事务是否冲突，提交通过验证的事务，未通过的事务标记为无效；对于无冲突事务，调用对应的合并方法提交全部无冲突事务。

该系统还针对系统内部存在拜占庭节点的情况，设计可行方法并实施保障系统安全性，具体为：

第一种情况是恶意的Epoch服务器，会发送给全节点错误的Epoch号；解决办法是多个Epoch服务器基于PBFT(Practical Byzantine Fault Tolerance)共识算法进行共识；全节点获取多个Epoch服务器提供的Epoch号，全节点收到大于1/3节点个数的相同Epoch号时，表示Epoch号是正确的；

第二种情况是在启用分区聚合功能下，恶意的全节点可能会广播错误的执行结果，导致正确的节点使用错误的执行结果更新了数据库；解决办法是分区聚合功能需要配合背书功能一起使用，一组交易，会指定联盟内的几个组织甚至所有组织一同背书，当所有背书结果相同时，才能直接使用这组交易的执行结果，当有一个背书结果不相同时，直接在本地执行这组交易；

第三种情况是恶意的全节点可能会打包不正确的区块并提交上链；解决办法是每个全节点在出完区块后，广播区块的哈希值，只有当本地计算的区块哈希值与区块链网络中的大于1/3节点的区块哈希值一致时才能提交区块。

本实施例还搭建一个基于无冲突事务合并的联盟区块链系统进行商业竞拍和投票应用程序的仿真实验，软件环境为Ubuntu20.04系统，实现的语言为C++，分布式节点间通信库采用ZeroMQ，消息通信协议采用Google的ProtoBuf。在阿里云上租用4台4核4G的密集计算型服务器实现多节点部署实验。同时，在阿里云上租用了5台4核4G的密集计算型服务器，搭建Fabric系统，并部署商业竞拍和投票智能合约，使用Caliper进行压力测试进行对比实验。

基于无冲突事务合并的联盟区块链系统进行商业竞拍和投票应用程序的具体包括以下步骤：

步骤1：定义商业竞拍事务结构以及对应合并方法，具体如下：

步骤1.1：定义商品id作为数据库的key，竞拍用户id、竞拍金额组成一个结构体作为数据库中的value；

步骤1.2：竞拍事务的合并方法实现逻辑十分简单，对于两个竞拍事务，哪个事务的竞拍金额高，就用这个事务去更新商品id对应的value中的结构体的值；

本实施例中，使用Set_CFS和Max_CFS模板类构建的投票数据存储结构和商业竞拍数据存储结构如图7所示。

步骤2：根据联盟区块链结构编写配置文件，配置哪些节点为全节点、哪些节点为Epoch服务器、各节点的IP地址等，统一为联盟区块链内节点生成公钥、私钥。启动联盟区块链系统网络，等待客户端发送请求。

步骤3：启动几个客户端程序，分别向联盟区块链系统内的全节点发送竞拍请求。

步骤4：各全节点运行基于Epoch的交易分割算法，来保证各全节点将一个Epoch的所有交易分割到一个区块内，具体如下：

步骤4.1：各全节点收集客户端发来的交易，等到缓冲区满或者时间片到达就将缓冲区内的交易打包成一组，用私钥对其签名，将签名和交易数量一同发送给Epoch服务器。

步骤4.2：Epoch服务器用对应节点的公钥解密消息，在用Epoch服务器的私钥将Epoch号和原数据一起签名发送给对应节点。

步骤4.3：各全节点收到的Epoch号发生变化时，广播上一个Epoch号的全部交易。

步骤4.4：各全节点收集其他节点发来的全部交易，这些交易的Epoch号都相同，来达到交易被分割到一个区块内的目的。

步骤5：各全节点运行基于哈希函数的确定性排序算法，来保证各全节点的同一个Epoch的区块内的事务的顺序相同，具体如下：

步骤5.1：对于一个Epoch内的每个事务，用SHA256算法根据客户端id和客户端对事务的签名组成的字符串进行哈希运算得到事务ID。

步骤5.2：对于一个Epoch内的每个事务，按照事务ID的字典序从小到大对一个Epoch内的事务进行排序。

步骤6：执行事务并构造区块，并发执行一个区块内的事务，生成读写集；同时进行生成默克尔树根、组装区块步骤，具体如下：

步骤6.1：基于上一个区块上链后的状态并发执行当前区块的所有事务，生成读写集。

步骤6.2：调用已经实现好的库函数生成默克尔树根，然后将上一个区块的哈希值、默克尔树根、事务数量等组装成区块头，将所有事务按顺序组装在区块体内，然后将区块头与区块体组合，形成一个区块。

步骤7：根据读写集进行事务提交，包含MVCC并发验证、无冲突事务合并，具体步骤如下：

步骤7.1：对于不是无冲突的事务，按照MVCC策略验证事务的读写集，提交通过MVCC验证的事，未通过的事务标记为无效。对于冲突的事务，只能提交冲突事务中排在最前面的事务；

步骤7.2：对于无冲突事务，调用对应预先实现好的合并方法进行无冲突事务提交，无冲突事务的合并方法保证无冲突事务全部可以提交成功；

步骤8：进行区块验证及区块上链；

所述区块验证的方法为：

各节点生成区块后，计算出区块的哈希值，然后对区块的哈希值签名，广播到联盟区块链系统网络中。

其他节点收到区块的哈希值后，进行哈希值验证，当本地计算出的区块哈希值与大于节点总数的1/3节点计算出的区块哈希值相同时，证明当前节点生成的区块没问题，区块上链。进行区块哈希值验证失败的节点被认为是拜占庭节点，会直接崩溃。

本实施例的实验结果如图8、图9所示，从实验结果看出，基于本发明实现的投票和商业竞拍应用程序的吞吐量比基于Fabric系统实现的高2倍左右。实验结果证明了，基于无冲突合并的联盟区块链构建包含高冲突率但本质上是无冲突事务的应用程序，能够显著提升应用程序的性能。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明权利要求所限定的范围。

Claims (4)

1.一种基于无冲突事务合并的联盟区块链系统，为包括多个全节点和多个Epoch服务器的区块链网络；其特征在于：所述系统包括持久层、逻辑层、网络层和应用层；

所述持久层用于状态数据存储以及区块数据存储，区块数据使用文件来存储；而对于状态数据则需要使用数据库来存储，因为每个交易的执行都需要访问状态数据；对于无冲突事务，使用无冲突事务存储结构进行存储；

所述逻辑层包括基于Epoch的交易分割模块、基于哈希函数的事务确定性排序模块，无冲突事务处理模块，以及系统运行所必须的功能模块；

所述网络层包括P2P网络配置的装置、全节点间的数据传输的装置以及心跳机制装置；P2P网络配置采用配置文件的方式进行网络配置；全节点之间的数据传输使用ZeroMQ完成，全节点之间数据传输使用的消息格式通过ProtoBuf来定义；节点间的心跳机制用来检测区块链网络内部的故障节点；

所述应用层包括一个客户端程序，并支持开发各种应用程序；所述客户端程序用于向全节点发出交易请求，查询执行结果、查询区块数据；

所述基于Epoch的交易分割模块具体实现以下功能：

当系统中全节点收集了由客户端发起的一组事务后，先验证事务的合法性，然后它将生成一个请求并将其发送到Epoch服务器；该请求包括这组事务的摘要和组中的事务数量；每个组都由有序的事务组成；Epoch服务器为该组事务分配Epoch号，并使用组摘要和Epoch号生成证明；因为Epoch服务器之间已经达成了共识，因此Epoch号分配不需要额外的共识；每个全节点在一个Epoch号中生成多个事务组；随后，在处理完成一个Epoch号的事务组之后，每个全节点对该Epoch号的事务组进行数字签名并将该数字签名与事务组一起广播给其他全节点；其他全节点收集同一Epoch号的所有事务组，并验证数字签名正确性，然后将同一个Epoch号的所有事务划分到一个区块中；

基于哈希函数的事务确定性排序模块具体实现以下功能：

Epoch服务器为一组事务分配Epoch号之后，全节点收集同一Epoch号下的所有事务；

全节点通过使用哈希函数为该Epoch号下的每个事务生成TID；按照TID的大小对区块内的事务进行排序；各全节点使用相同的哈希函数独自生成TID并保证全节点之间的一致性和随机性；在基于冲突事务合并的联盟区块链中，使用客户端id和事务请求签名作为哈希函数的输入来创建TID；

所述无冲突事务处理模块具体实现以下功能：

当全节点根据基于Epoch的交易分割模块收集完区块号为n的所有事务，并根据基于哈希函数的事务确定性方法排序后，基于第n-1个区块上链后的状态，并发执行区块n内的所有事务，生成每个事务的读写集，对于普通事务按照MVCC并发控制方法验证事务是否冲突，提交通过验证的事务，未通过的事务标记为无效；对于无冲突事务，调用对应的合并方法提交全部无冲突事务；

所述系统运行所必须的功能模块包括默克尔树生成模块、区块组装模块、区块验证模块、无冲突事务合并模块和MVCC并发控制模块；

所述默克尔树生成模块根据一个区块内的所有事务生成一颗默克尔树，最后将默克尔树根存放在区块头部，用于验证区块的数据完整性以及每笔事务的正确性；

所述区块组装模块负责将前一个区块的哈希、默克尔树根、时间戳、事务列表组装到一个区块中；

所述区块验证模块用于确保当前节点生成的区块与其他非恶意的节点生成的区块相同；

所述无冲突事务合并模块调用合并方法合并无冲突事务，合并方法是由应用程序开发者实现的，并且每个无冲突事务的合并方法都是不同的，应用程序开发者需要保证合并方法的逻辑正确性；

所述MVCC并发控制模块用于检查非无冲突事务之间是否冲突，并废弃冲突事务。

2.根据权利要求1所述的一种基于无冲突事务合并的联盟区块链系统，其特征在于：所述系统运行所必须的功能模块还包括分区聚合模块，该模块通过分区聚合功能执行事务；且分区聚合功能配合背书功能一起使用。

3.根据权利要求2所述的一种基于无冲突事务合并的联盟区块链系统，其特征在于：所述无冲突事务合并模块声明了一个合并方法；合并方法定义了每个无冲突事务的更新规则；所述无冲突事务存储结构基于哈希表实现，每个无冲突事务的数据需要实现无冲突事务接口；每个事务数据的存储对象也实现为一个哈希表，其中，key为string类型的字符串，value为对应事务的实现了无冲突事务接口的对象；实现了无冲突事务接口的对象直接合并对应事务的读写集，完成事务数据更新。

4.根据权利要求2或3任一项权利要求所述的一种基于无冲突事务合并的联盟区块链系统，其特征在于：所述系统还针对系统内部存在拜占庭节点的情况，设计可行方法并实施保障系统安全性，具体为：

第一种情况是恶意的Epoch服务器，会发送给全节点错误的Epoch号；解决办法是多个Epoch服务器基于PBFT共识算法进行共识；全节点获取多个Epoch服务器提供的Epoch号，全节点收到大于1/3节点个数的相同Epoch号时，表示Epoch号是正确的；

第二种情况是在启用分区聚合功能下，恶意的全节点可能会广播错误的执行结果，导致正确的节点使用错误的执行结果更新了数据库；解决办法是分区聚合功能需要配合背书功能一起使用，一组交易，会指定联盟内的几个组织甚至所有组织一同背书，当所有背书结果相同时，才能直接使用这组交易的执行结果，当有一个背书结果不相同时，直接在本地执行这组交易；

第三种情况是恶意的全节点可能会打包不正确的区块并提交上链；解决办法是每个全节点在出完区块后，广播区块的哈希值，只有当本地计算的区块哈希值与区块链网络中的大于1/3节点的区块哈希值一致时才能提交区块。

Images