一种面向联盟链的状态树上的并行更新方法及更新系统

1.本发明属于区块链技术领域，涉及一种状态树上的更新方法，具体涉及一种面向联盟链的状态树上的并行更新方法及更新系统。


背景技术：

2.区块链是一种面向互不可信环境的多方共同维护的分布式账本，具有去中心化、不可篡改、历史数据可追溯等特点。然而传统的区块链为了保证每个副本拥有一致的最终状态，都是对一批交易顺序执行。但这种顺序执行的模式不能很好的利用现代多核处理器的性能，闲置了大量的计算机资源并且带来了极差的性能。
3.状态的存储主要有一种可验证的数据结构存储，统称为状态树，如mpt、smt等。该结构除了可以计算摘要外，还可以作为账户状态的索引，并提供完整性证明。此外，状态树通过在每个块上构建全局账户状态的快照来存储账户状态数据的所有版本。但是，由于在状态树上每一个节点的更新，都会导致状态树在提交时根节点到这个更新节点的路径上的所有节点的哈希重新计算，并且需要将所有更新的节点持久化。目前很多对状态树的并行操作都是将一整棵树锁住来更新状态，但是这种方法和串行更新效果基本一致；另一种是设计是在节点粒度上使用锁的机制，但是由于节点和其孩子的上下关系，因此越靠近根节点的节点上的锁的竞争越激烈，这也会影响整体并发性能。
4.因此，为了提升联盟链的整体性能，有必要提出一种面向联盟链的状态树上的并行更新策略。


技术实现要素：

5.为了解决现有技术存在的不足，本发明的目的是提供一种面向联盟链的状态树上的并行更新方法，实现了对状态的无锁并行更新，通过将读操作和写操作解耦，并且巧妙结合使用了区块链批量更新的特点，最大化提升并发性能。
6.本发明以提高联盟链吞吐率为目标，针对现有技术的缺失，提出一种面向联盟链的状态树上的并行更新方法。在状态树上的并行更新中，本发明通过将读操作和写操作解耦，解析作业之间的冲突关系，并行下沉从根节点开始找到作业间公共更新的节点，将无冲突的作业分到不同的工作线程上执行，无锁地将一个区块中的所有更新的状态并行的更新到状态树上，从而提高区块处理速度，提高系统吞吐量。
7.本发明提出了一种面向联盟链的状态树上的并行更新方法，所述方法具体包括以下步骤：
8.步骤1：将需要更新的状态集合s以取模、哈希映射、有序分段划分等分配方式分配给不同的工作线程；
9.步骤2：将所有的更新状态在状态树上做并行下沉搜索，直到找到冲突节点，并将对应状态附加到冲突节点上；
10.步骤3：从映射关系中取出冲突节点
‑
更新的状态列表，以取模、哈希映射、有序分
段划分等分配方式将冲突节点以及其附加的状态集合重新分配给不同的工作线程，尽量使一个冲突节点由一个工作线程修改，一个工作线程可以修改一个或多个冲突节点；
11.步骤4：根据工作线程分配的状态和冲突节点信息，并行对状态树的节点进行更新。
12.其中，
13.所述步骤1进一步包括以下步骤：
14.步骤1
‑
1：批量收集所有需要更新的状态集合s、工作线程集合，并初始化计数器；
15.步骤1
‑
2：将每个更新的状态从集合s中取出，利用取模、哈希映射、有序分段划分等方式得到工作线程的索引，将取出的状态分配给对应的工作线程。
16.所述步骤2进一步包括以下步骤：
17.步骤2
‑
1：将状态集合并行从工作线程中取出，初始化节点和工作列表的映射关系；
18.步骤2
‑
2：从状态集合中取出更新的状态，在状态树上查找冲突节点，在步骤2
‑
1的映射关系中，将更新的状态加入到冲突节点的状态列表中。
19.所述步骤4进一步包括以下步骤：
20.步骤4
‑
1：并行从每个工作线程当中读取对应的需要更新的冲突节点及其更新状态列表；
21.步骤4
‑
2：并行从冲突节点集合中依次取出冲突节点，从映射关系中获取冲突节点的更新状态列表，依次在树上对冲突节点及其需要更新的子节点进行更新。
22.本发明还提出了一种实现上述并行更新方法的系统，所述系统包括：共识模块、交易执行模块、存储模块。
23.所述共识模块用于维护系统的运作顺序与公平性并通过奖惩维护系统的稳定运行；所述共识是指达成被分歧各方所接受的陈述(即使有时只是勉强接受，甚至只是搁置争议)的社群解决方案。
24.所述交易执行模块利用执行器(executor)执行交易中的智能合约二进制代码；所述执行器在执行过程中，类似于一个黑盒，输入是智能合约代码，输出是状态的改变。
25.所述存储模块用于交易在通过交易执行模块后，会对账户的状态(state)进行修改，存储模块会将修改后的状态储存下来(storage)。
26.本发明的有益效果包括：本发明实现了对状态的无锁并行更新，通过将读操作和写操作解耦，并且巧妙结合使用了区块链批量更新的特点，最大化提升并发性能。
附图说明
27.图1是本发明实施例1作业分配示例图。
28.图2是本发明实施例1并行下沉示例图。
29.图3是本发明实施例1工作线程分配所需更新的节点示例图。
30.图4是本发明实施例1并行节点更新示例图。
31.图5是本发明实施例2作业分配示例图。
32.图6是本发明实施例2并行下沉示例图。
33.图7是本发明实施例2工作线程分配所需更新的节点示例图。
34.图8是本发明实施例3作业分配示例图。
35.图9是本发明实施例3并行下沉示例图。
36.图10是本发明实施例3工作线程分配所需更新的节点示例图。
具体实施方式
37.结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。
38.在传统的区块链当中，在一个区块中的交易执行完后，更新的状态都是串行地更新到状态树上，这限制了区块链吞吐量地提升。本发明中，为了无锁并行地更新状态到状态树上，从而提升系统的整体性能，将读写操作解耦，并且利用区块链批量的特点，将更新的状态批量地更新到状态树上，这样可以得到状态树上需要更新的节点的冲突关系，从而最大化地进行无锁的并行更新调度，提升整个系统的吞吐量。
39.本发明提出的面向联盟链的状态树上的并行更新方法如下方代码所示：
[0040][0041]
包括以下具体步骤：
[0042]
步骤1：将需要更新的状态集合s分配给不同的工作线程，包括以下具体步骤(第1
‑
5行)：
[0043]
步骤1
‑
1：批量收集所有需要更新的状态集合s，初始化计数器cnt＝0，工作线程集合w；
[0044]
步骤1
‑
2：将每个更新的状态(k,v)从集合s中取出，将计数器cnt与总的工作线程数n
t
取模得到idx，将取出的状态(k,v)分配给第idx个工作线程，计数器cnt加一；
[0045]
所述k为账户地址；所述v为账户地址修改的值；所述idx为根据划分规则分配给的工作线程标识；
[0046]
步骤2：将所有的更新状态在树上并行下沉，直到找到冲突节点，包括以下具体步骤(第6
‑
12行)：
[0047]
步骤2
‑
1：将状态集合task_set并行从工作线程中取出,初始化节点和工作列表的映射关系m；
[0048]
步骤2
‑
2：从状态集合task_set中取出更新的状态(k，v),在状态树上查找冲突节点node
c
,在映射关系m中将更新的状态(k,v)加到更新的状态列表l
t
中；
[0049]
步骤3:从映射关系m中取出冲突节点
‑
更新的状态列表(node
c
,l
t
)，将计数器cnt与总的工作线程数n
t
取模得到idx，将冲突节点
‑
更新的状态列表(node
c
,l
t
)按取模的方式均匀分配给不同的工作线程，计数器cnt加一(第13
‑
17行)；
[0050]
步骤4：根据工作线程分配的状态和冲突节点信息，并行对状态树的节点进行更新，包括以下具体步骤(第19
‑
25行)：
[0051]
步骤4
‑
1：并行从每个工作线程当中读取对应的需要更新的冲突节点集合node_set及其状态(k,v)；
[0052]
步骤4
‑
2：并行从冲突节点集合node_set中依次取出冲突节点node
c
，从映射关系m中获取冲突节点的更新状态列表l
t
，依次在树上对冲突节点及其需要更新的子节点进行更新。
[0053]
本发明还提出了一种实现上述并行更新方法的系统，所述系统包括：共识模块、交易执行模块、存储模块。
[0054]
所述共识模块用于维护系统的运作顺序与公平性并通过奖惩维护系统的稳定运行；所述共识是指达成被分歧各方所接受的陈述(即使有时只是勉强接受，甚至只是搁置争议)的社群解决方案。
[0055]
所述交易执行模块利用执行器(executor)执行交易中的智能合约二进制代码；所述执行器在执行过程中，类似于一个黑盒，输入是智能合约代码，输出是状态的改变。
[0056]
所述存储模块用于交易在通过交易执行模块后，会对账户的状态(state)进行修改，存储模块会将修改后的状态储存下来(storage)。
[0057]
实施例1
[0058]
本实施例是对状态树上节点并行更新的方法。
[0059]
脏状态(dirtystate)：一个区块的所有交易执行结束后修改的状态。
[0060]
作业：对每个状态所在的叶子节点以及其路径上的父节点的更新工作。
[0061]
冲突节点：多个状态会对同一个节点进行更新，那个会被多次更新的节点即为冲突节点。
[0062]
扩展节点：只能有一个子节点。
[0063]
分支节点：可以有多个节点。
[0064]
叶子节点：没有子节点。
[0065]
首先，如图1所示，假设一个区块内的所有交易执行完后，共产生了6个脏状态s1～s6，其中“i(
·
)”和“d(
·
)”分别代表状态的插入和删除。所有这些脏状态(作业)被均匀地分布在3个工作线程中(工作线程a、b、c分别用长方形、圆形、菱形表示)。
[0066]
接下来，如图2所示，3个工作线程在状态树上并行下沉，寻找每个作业的冲突节点，并将此作业附加到对应的冲突节点上。例如圆形的工作线程b，由图1可知，持有作业(脏状态)s2和s6，那么工作线程b在状态树上并行下沉，路径为：节点1
‑
>节点3
‑
>节点6和节点1
‑
>节点2
‑
>节点5。最终下沉步骤结束于两个冲突节点：节点5和节点6。当所有工作线程完成下沉步骤后，如图2所示，最终所有作业(脏状态)附加在了4个冲突节点上：节点5、节点6、节点8、节点9。
[0067]
当找到了所有冲突节点后，虽然经过步骤1后，一些作业(脏状态)分配给了不同的工作线程，但是经过步骤2的状态下沉后，属于不同工作线程的作业分配在了同一个冲突节点上：s2和s6属于工作线程b，s1和s5属于工作线程a，但是s1和s6属于同一个冲突节点，s2和s5属于不同的冲突节点。因此如图3所示，考虑到负载均衡的问题，将s1和s6分配给工作线程a处理，s2和s5分配给工作线程b，s3和s4分配给工作线程c。
[0068]
当将节点更新任务分配给不同的工作线程后，如图4所示，所有工作线程并行更新不同的冲突节点。
[0069]
实施例2
[0070]
如图5所示，假设一个区块内的所有交易执行完后，共产生了6个脏状态s1～s6,其中“i(
·
)”和“d(
·
)”分别代表状态的插入和删除。所有这些脏状态(作业)通过哈希映射的方式被映射在3个工作线程中(工作线程a、b、c分别用长方形、圆形、菱形表示)。
[0071]
接下来，如图6所示，3个工作线程在状态树上并行下沉，寻找每个作业的冲突节点，并将此作业附加到对应的冲突节点上。例如圆形的工作线程b，由图1可知，持有作业(脏状态)s2和s6，那么工作线程b在状态树上并行下沉，路径为：节点1
‑
>节点4
‑
>节点8和节点1
‑
>节点4
‑
>节点9。最终下沉步骤结束于两个冲突节点：节点8和节点9。当所有工作线程完成下沉步骤后，如图2所示，最终所有作业(脏状态)附加在了4个冲突节点上：节点5、节点6、节点8、节点9。
[0072]
当找到了所有冲突节点后，虽然经过步骤1后，一些作业(脏状态)分配给了不同的工作线程，但是经过步骤2的状态下沉后，属于不同工作线程的作业分配在了同一个冲突节点上：s2和s6属于工作线程b，s1和s5属于工作线程a，s3和s4属于工作线程c。但是s1和s4属于同一个冲突节点，s2和s5属于不同的冲突节点。因此如图7所示，考虑到负载均衡的问题，将s1和s4分配给工作线程a处理，s2和s5分配给工作线程b，s3和s6分配给工作线程c。
[0073]
阶段四的流程与实施例1一致。
[0074]
实施例3
[0075]
如图8所示，假设一个区块内的所有交易执行完后，共产生了6个脏状态s1～s6,其中“i(
·
)”和“d(
·
)”分别代表状态的插入和删除。所有这些脏状态(作业)通过有序分段划分的方式被映射在3个工作线程中(工作线程a、b、c分别用长方形、圆形、菱形表示)。
[0076]
接下来，如图9所示，3个工作线程在状态树上并行下沉，寻找每个作业的冲突节点，并将此作业附加到对应的冲突节点上。例如圆形的工作线程b，由图1可知，持有作业(脏
状态)s2和s6，那么工作线程b在状态树上并行下沉，路径为：节点1
‑
>节点3
‑
>节点6和节点1
‑
>节点4
‑
>节点8。最终下沉步骤结束于两个冲突节点：节点6和节点8。当所有工作线程完成下沉步骤后，如图2所示，最终所有作业(脏状态)附加在了4个冲突节点上：节点5、节点6、节点8、节点9。
[0077]
当找到了所有冲突节点后，虽然经过步骤1后，一些作业(脏状态)分配给了不同的工作线程，但是经过步骤2的状态下沉后，属于不同工作线程的作业分配在了同一个冲突节点上：s2和s6属于工作线程b，s1和s5属于工作线程a，s3和s4属于工作线程c。但是s4和s5属于同一个冲突节点，s1和s2属于不同的冲突节点。因此如图10所示，考虑到负载均衡的问题，将s4和s5分配给工作线程a处理，s1和s2分配给工作线程b，s3和s6分配给工作线程c。
[0078]
阶段四的流程与实施例1一致。
[0079]
本发明的保护内容不局限于以上实施例。在不背离本发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。