A consortium chain parallel computing method and device for group work

Abstract

The present invention belongs to the field of blockchain technology, and provides a parallel computing method and device for alliance chains working in groups. The method includes dividing the physical nodes provided by all alliance parties into different computing groups based on the alliance party to which they belong; using the scheduling node of each computing group to receive the tasks sent by the client and divide them into multiple branch tasks that can be processed in parallel without conflict, and then assigning the branch tasks to different execution nodes for parallel processing through consistent hashing; wherein the consistency of the account data of multiple computing groups is ensured through a consensus mechanism between the computing groups; in a computing group, a physical node is selected as the scheduling node, and the other physical nodes are execution nodes. If the current scheduling node fails, the next scheduling node is selected from all execution nodes in rotation.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and in particular to a parallel computing method and device for a consortium chain for group work. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] The blockchain system needs to ensure the consistency of a certain scale of the entire network, and the way to achieve consistency is usually a consensus algorithm or consensus mechanism. Commonly used consensus algorithms include proof of work (PoW), proof of stake (PoS), delegated proof of stake (DPoS), and the use of the Byzantine Fault Tolerant algorithm (PBFT). Due to the limited bandwidth of the Internet network and the uneven quality of hardware resources, communication delays between blockchain nodes and the upper limit of storage resources are inevitable, resulting in the widespread performance and capacity bottlenecks in the blockchain system, which cannot support Internet-level applications. In response to this bottleneck problem, sharding is a common way to achieve capacity expansion in the blockchain field. There are generally three types of sharding mechanisms in the blockchain system: network sharding, transaction sharding, and state sharding. The main idea is to divide the blockchain nodes into different sub-networks and process different transactions in parallel, thereby achieving an increase in throughput.

[0004] In the prior art, some blockchain system sharding methods divide blockchain nodes according to network delay. However, the inventors found that in this sharding idea, due to the existence of storage and computing partitions, there is a lack of a global consistency guarantee mechanism, and it is impossible to avoid the existence of malicious nodes that cause the calculation or storage results of a certain shard to be unreliable. Summary of the invention

[0005] In order to solve the technical problems existing in the above-mentioned background technology, the present invention provides a parallel computing method and device for a consortium chain working in a group, which can realize the integrated sharing of computing, network and memory resources of multiple physical nodes, and improve the processing performance and storage capacity of the consortium chain.

[0006] In order to achieve the above object, the present invention adopts the following technical solution:

[0007] A first aspect of the present invention provides a consortium chain parallel computing method for group work, comprising:

[0008] Divide the physical nodes provided by all alliance parties into different computing groups based on the alliance party they belong to;

[0009] The scheduling nodes of each computing group receive tasks sent by the client and divide them into multiple branch tasks that can be processed in parallel without conflicts. The branch tasks are then assigned to different execution nodes for parallel processing through consistent hashing.

[0010] Among them, the consistency of the ledger data of multiple computing groups is ensured through a consensus mechanism between computing groups; in a computing group, one physical node is selected as the scheduling node, and the other physical nodes are execution nodes. If the current scheduling node fails, the next scheduling node is selected from all execution nodes in rotation.

[0011] As an implementation method, each computing group includes at least three physical nodes to ensure that the group can still operate normally after any physical node fails.

[0012] As an implementation method, the physical nodes within each group are neighbor nodes to each other, and the internal neighbor nodes are all trustworthy. The computing group participates in consensus computing and ledger data storage as a unified whole.

[0013] As an implementation method, shared disk space is provided between neighboring nodes in the same computing group to build a distributed ledger library and status library, and each computing group maintains the full amount of ledger data and status data.

[0014] As an implementation method, each neighbor node of the same computing group may have read and write operation permissions on the ledger library and status library of the subordinate computing group.

[0015] A second aspect of the present invention provides a consortium chain parallel computing device for group work, comprising:

[0016] A scheduling node selection component, which is used to select a node from the neighboring nodes of the computing group as a scheduling node, detect the operating status of the neighboring nodes and select a new scheduling node when the scheduling node fails;

[0017] A scheduling component, which is used to provide scheduling processing capabilities for scheduling nodes;

[0018] An execution component, which is used to provide task execution capabilities for execution nodes;

[0019] The message processing component is used to provide message services and processing capabilities for the scheduling node selection component, scheduling component, and execution component during runtime.

[0020] As an implementation manner, the scheduling node selection component includes:

[0021] The dispatcher rotation unit is used to determine the order of the selected scheduling nodes within the computing group and select the next scheduling node in order;

[0022] The node status detection unit is used to detect the operating status of neighboring nodes in real time. When the execution node detects that the scheduling node fails, it communicates with other neighboring nodes to replace the next scheduling node. When the scheduling node detects that the execution node is down, it reallocates tasks.

[0023] The consensus task synchronization unit is used to synchronize the unfinished consensus tasks between the new scheduling node and other scheduling nodes.

[0024] As an implementation mode, the scheduling component includes:

[0025] The transaction request distribution processing unit is used to respond to the transaction request of the client, distribute the request to the execution node for execution, temporarily store the distribution record, and reallocate the task when the execution node is detected to be down;

[0026] The consensus task division unit is used to divide the transaction queue contained in the consensus task into multiple unrelated and ordered branch tasks according to the transaction order, and randomly assign an execution node to each branch task, and temporarily store the assignment record, and reallocate the task of the downed execution node when it is detected that an execution node is down;

[0027] The task division verification unit is used to verify whether the consensus task division method sent by the scheduling node of other computing groups is correct;

[0028] The branch result summary unit is used to summarize the branch task processing results returned after the execution of each execution node.

[0029] As an implementation mode, the execution component includes:

[0030] The transaction construction unit is used to execute the transaction construction task sent by the scheduling node, return the execution result to the scheduling node through the message processing component, and broadcast the constructed transaction among neighboring nodes through the message processing unit;

[0031] The branch task execution unit is used to execute the branch tasks sent by the scheduling node, check whether the transactions in the branch tasks are legal in sequence and execute the transactions. After the branch tasks are executed, the results are fed back to the scheduling node through the message processing component;

[0032] The branch task submission unit is used to submit the transaction object status and transaction after the branch task is executed to the account book after receiving the branch task submission message sent by the scheduling node.

[0033] As an implementation manner, the message processing unit includes:

[0034] A transaction construction message processing unit, which is used to process transaction construction related messages between the scheduling node and the execution node;

[0035] The transaction broadcast message processing unit is used to broadcast the transaction constructed by the execution node among neighboring nodes, and broadcast the transaction received by the scheduling node to the scheduling nodes of other nodes;

[0036] A consensus message processing unit, which is used to process consensus communication messages between scheduling nodes;

[0037] A task distribution message processing unit, which is used to process task distribution and task execution result messages between the scheduling node and the execution node;

[0038] The scheduling node selection message processing unit is used to enable neighbor nodes to communicate with each other to achieve consistency in scheduling node selection.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] (1) The present invention divides the physical nodes provided by all alliance parties into different computing groups based on the alliance party to which they belong, uses the scheduling node of each computing group to receive the tasks sent by the client and divides them into multiple branch tasks that can be processed in parallel without conflict, and then distributes the branch tasks to different execution nodes for parallel processing through consistent hashing, thereby realizing the integrated sharing of computing, network, and memory resources of multiple physical nodes, and improving the processing performance and storage capacity of the alliance chain.

[0041] (2) The computing groups of the present invention use a consensus mechanism to ensure the global consistency of the ledger data and the credibility and security of the alliance chain operation. The number of physical nodes in the computing group can also be increased to further improve the performance of the computing group and further expand the storage capacity, thereby supporting the horizontal expansion of the alliance chain performance and storage capacity.

[0042] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0044] Figure 1 This is a flow chart of a parallel computing method for a consortium chain for group work according to an embodiment of the present invention;

[0045] Figure 2 This is a schematic diagram of the structure of a consortium chain parallel computing device for group work according to an embodiment of the present invention;

[0046] Figure 3 is a flow chart of processing a transaction construction request according to an embodiment of the present invention;

[0047] Figure 4 This is a flowchart of an embodiment of the present invention applied to PBFT consensus;

[0048] Figure 5This is a flow chart of an embodiment of the present invention that supports ensuring the availability of a computing group even if any physical node in the computing group fails. DETAILED DESCRIPTION

[0049] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0050] It should be noted that the following detailed descriptions are all illustrative and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0051] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof.

[0052] Embodiment 1

[0053] like Figure 1 As shown, this embodiment provides a consortium chain parallel computing method for group work, which specifically includes the following steps:

[0054] Step 1: Divide the physical nodes provided by all alliance parties into different computing groups based on the alliance party they belong to.

[0055] Among them, the consistency of the ledger data of multiple computing groups is guaranteed through a consensus mechanism between computing groups; in a computing group, one physical node is selected as the scheduling node (dispatcher), and the other physical nodes are executors (executors). If the current scheduling node (dispatcher) fails, the next scheduling node (dispatcher) is selected from all executors in rotation.

[0056] The dispatcher is responsible for receiving transaction building requests, distributing and scheduling tasks within the computing group, collecting and processing the task processing results of the executor, and communicating with other computing groups;

[0057] The executor is responsible for processing the tasks assigned by the dispatcher and returning the execution results to the dispatcher.

[0058] Among them, task distribution and scheduling include dividing the transaction construction or consensus task into multiple branch tasks and distributing and scheduling them among executors. The basis for task division is that there is no correlation between the branch tasks, and each executor can execute in parallel. The correlation relationship includes but is not limited to the same transaction object, the same transaction initiator or receiver.

[0059] In a specific implementation, each computing group includes at least three physical nodes, so that it can be ensured that the group can still operate normally after any physical node fails.

[0060] Moreover, the physical nodes within each group are neighbor nodes to each other, and the internal neighbor nodes are all trustworthy. The computing group participates in consensus computing and ledger data storage as a unified whole.

[0061] Neighboring nodes in the same computing group provide shared disk space to build distributed ledger libraries and status libraries. Each computing group maintains the full amount of ledger data and status data. Each neighboring node in the same computing group has read and write permissions to the ledger library and status library of the subordinate computing group.

[0062] Step 2: Use the scheduling node of each computing group to receive the tasks sent by the client and divide them into multiple branch tasks that can be processed in parallel without conflict. Then, use consistent hashing to assign the branch tasks to different execution nodes for parallel processing.

[0063] It can be understood here that tasks include but are not limited to transaction construction request tasks and consensus tasks. Those skilled in the art can specifically issue corresponding tasks from the client according to actual conditions.

[0064] In order to solve the bottleneck problems of alliance chain performance and capacity, this embodiment draws on the idea of ​​sharding in the blockchain field, and proposes a parallel computing mechanism for alliance chain working in groups under the premise of ensuring global consistency: the alliance party provides multiple physical nodes as a computing group, and the computing group provides computing, network and storage capabilities as a whole, divides the tasks received by the group into multiple branch tasks that can be processed in parallel without conflict, and distributes the branch tasks to different physical nodes within the computing group for parallel processing, and summarizes the task processing results to complete the task processing. The consistency of the ledger data of multiple computing groups is still guaranteed through the consensus mechanism between computing groups. The performance of the alliance chain can be improved by parallel task processing within the computing group, and the horizontal expansion of the alliance chain can be achieved by increasing the number of physical nodes within the computing group.

[0065] Embodiment 2

[0066] like Figure 2 As shown, this embodiment provides a consortium chain parallel computing device for group work, which specifically includes the following structures: a scheduling node selection component, a scheduling component, an execution component and a message processing component.

[0067] (1) A scheduling node selection component is used to select a node from the neighboring nodes of the computing group as a scheduling node, detect the operating status of the neighboring nodes, and select a new scheduling node when a scheduling node fails.

[0068] In a specific implementation, the scheduling node selection component includes:

[0069] (1.1) The dispatcher rotation unit is used to determine the order of the selected scheduling nodes within the computing group and select the next scheduling node in order;

[0070] (1.2) A node status detection unit, which is used to detect the operating status of neighboring nodes in real time. When an execution node detects that a scheduling node fails, it communicates with other neighboring nodes to replace the next scheduling node. When a scheduling node detects that an execution node fails, it reallocates tasks.

[0071] (1.3) A consensus task synchronization unit, which is used to synchronize the unfinished consensus tasks between the new scheduling node and other scheduling nodes.

[0072] (2) Scheduling component, which is used to provide scheduling processing capabilities for scheduling nodes.

[0073] In a specific implementation, the scheduling component includes:

[0074] (2.1) A transaction request distribution processing unit, which is used to respond to the client's transaction request, distribute the request to the execution node for execution, temporarily store the distribution record, and reallocate the task when the execution node is detected to be down;

[0075] (2.2) A consensus task division unit, which is used to divide the transaction queue contained in the consensus task into multiple unrelated and ordered branch tasks according to the transaction order, and randomly assign each branch task to an execution node, and temporarily store the assignment record, and reallocate the task of the downed execution node when it is detected that an execution node is down;

[0076] (2.3) Task division verification unit, which is used to verify whether the consensus task division method sent by the scheduling node of other computing groups is correct;

[0077] (2.4) A branch result summary unit, which is used to summarize the branch task processing results returned after the execution of each execution node.

[0078] (3) An execution component, which is used to provide the task execution capability of the execution node.

[0079] In a specific implementation, the execution component includes:

[0080] (3.1) A transaction construction unit, which is used to execute the transaction construction task sent by the scheduling node, return the execution result to the scheduling node through the message processing component, and broadcast the constructed transaction among neighboring nodes through the message processing unit;

[0081] (3.2) a branch task execution unit, which is used to execute the branch tasks sent by the scheduling node, check whether the transactions in the branch tasks are legal in sequence and execute the transactions. After the branch tasks are executed, the results are fed back to the scheduling node through the message processing component;

[0082] (3.3) A branch task submission unit, which is used to submit the transaction object status and transaction after the branch task is executed to the ledger after receiving the branch task submission message sent by the scheduling node.

[0083] (4) A message processing component, which is used to provide message services and processing capabilities for the scheduling node selection component, scheduling component, and execution component during operation.

[0084] In a specific implementation, the message processing unit includes:

[0085] (4.1) a transaction construction message processing unit, which is used to process transaction construction related messages between the scheduling node and the execution node;

[0086] (4.2) a transaction broadcast message processing unit, which is used to broadcast the transaction constructed by the execution node among neighboring nodes, and broadcast the transaction received by the scheduling node to the scheduling nodes of other nodes;

[0087] (4.3) a consensus message processing unit, which is used to process consensus communication messages between scheduling nodes;

[0088] (4.4) a task distribution message processing unit, which is used to process task distribution and task execution result messages between the scheduling node and the execution node;

[0089] (4.5) A scheduling node selection message processing unit is used to enable neighbor nodes to communicate with each other to achieve consistency in scheduling node selection.

[0090] The scheduling node is simplified as dispatcher and the execution node is simplified as executor to describe the specific application of the alliance chain parallel computing device for group work in this embodiment.

[0091] The process of the group-working consortium chain parallel computing device of this embodiment when processing a transaction construction request is as follows: Figure 3 As shown:

[0092] Step S101: The dispatcher of any node may receive a transaction construction request from a client;

[0093] Step S102: The dispatcher performs consistent hash calculation on the asset ID in the transaction construction request through the transaction request distribution processing unit, maps it to an executor within the computing group, and forwards the transaction construction task to the executor through the transaction construction message processing unit;

[0094] Step S103: After receiving the construction task, the executor performs transaction construction and transaction broadcasting;

[0095] Wherein, step S103 specifically includes the following steps:

[0096] Step S1031: After receiving the task, the executor constructs the transaction through the transaction construction unit;

[0097] Step S1032: The transaction construction message processing unit returns the transaction constructed by the executor to the dispatcher;

[0098] Step S1033: The transaction broadcast message processing unit asynchronously broadcasts the constructed transaction to neighboring nodes, and broadcasts it between neighboring nodes;

[0099] Step S1034: the dispatcher broadcasts the transaction to the dispatchers of other nodes through the transaction broadcast processing unit;

[0100] Step S1035: The dispatcher that receives the message broadcasts the transaction among internal neighboring nodes until all physical nodes have received the transaction.

[0101] Step S104: The computing groups complete the block building process through a consensus mechanism to execute and record transactions;

[0102] Step S105: the transaction request distribution processing unit of the dispatcher returns the transaction result to the client.

[0103] The following is a flow chart of the PBFT consensus mechanism of the alliance chain parallel computing device for group work in this embodiment:

[0104] The PBFT consensus algorithm provides (n-1) / 3 fault tolerance and is a commonly used consensus algorithm in consortium chains. It includes five stages: request, pre-prepare, prepare, commit, and reply. Consensus is reached through the three-stage submission protocol of pre-prepare, prepare, and commit. The master node sorts transactions and packages blocks, and the replica nodes verify the blocks packaged by the master node.

[0105] The invention [CN108108967A Multi-stage PBFT consensus system and method for complex digital assets] provides a multi-stage PBFT consensus system and method, which achieves a lower error rate and ensures high efficiency, but fails to achieve horizontal expansion based on parallel computing. This embodiment provides a solution for implementing parallel computing in a consortium chain that uses PBFT consensus. Both the master node and the replica node are configured as a group of multiple physical nodes, and the dispatcher inside the node is selected respectively. When a new round of consensus is started, the master node divides the tasks in the block into different unrelated branches, and broadcasts them to the replica nodes in the pre-prepare message. After receiving the pre-prepare message, the replica node verifies the legitimacy of the transaction, the correctness of the master node's task division, etc., and sends a prepare message to the master node and all replica nodes if the verification is passed. All nodes count the number of prepare messages for a block received from different nodes at this node, and when receiving messages greater than 2 / 3 of the number of nodes, send a commit message to the master node and all replica nodes. All nodes count the commit messages for a block received from different nodes at this node, and when receiving messages greater than 2 / 3 of the number of nodes, write the data. Figure 4 To illustrate:

[0106] Step S201: The master node dispatcher sorts and packages the batch transactions and divides the transactions into different task branches, for example: B1{tx1,tx4,tx6}, B2{tx2,tx3,tx5}, ..., BN{txP,txQ}. Among them, the objects of transactions within each branch in B1, B2, ..., BN are associated with each other, and the transaction queues within the branches need to be executed sequentially; there is no association between the objects of transactions between B1, B2, ..., BN, and different branches can be executed in parallel. Assemble the batch packaging information and task division information into a pre-prepare message.

[0107] Step S202: pre-prepare message processing. The processing process is that the master node dispatcher broadcasts the pre-prepare message to the replica node. The replica node dispatcher verifies whether the task division in the pre-prepare message sent by the master node is correct. If the verification is passed, the replica node enters the prepare stage.

[0108] Step S203: Prepare message processing, the replica node broadcasts the prepare message to the master node and all replica nodes, and receives prepare messages broadcast by other nodes at the same time, until it receives messages broadcast by more than 2 / 3 of the nodes and enters the next stage.

[0109] Step S204: The node that has collected enough prepare messages assigns the branch task to the executor for execution.

[0110] In a specific implementation, step S204 also includes the following steps:

[0111] Step S2041: Each node assigns branch tasks to executors for parallel processing according to the task division plan.

[0112] Step S2042: The executor executes the branch tasks in parallel, temporarily stores the branch task execution results, generates branch evidence and returns it to the dispatcher. The branch evidence refers to the hash value calculated based on the state of the transaction object after the branch task is executed.

[0113] The executor processes the received branch tasks in the following way: according to the order in the transaction queue, the state of the transaction object in the previous transaction is used as the input for the execution of the next transaction, and the state after the execution of this transaction is calculated according to the transaction rules, until the transaction queue is executed, the final state of the transaction object is obtained and temporarily stored. The state of the transaction object when the first transaction in the queue is executed is obtained from the account book data.

[0114] Step S2043: Each node dispatcher collects the branch evidences of all tasks to calculate the block execution evidence. The block execution evidence refers to the hash value calculated based on the execution evidence of each branch task.

[0115] Step S205: Commit phase message processing, the dispatcher embeds the block execution evidence into the commit message and broadcasts it to all dispatchers, and collects the commit messages broadcast by other nodes. If more than 2 / 3 of the nodes’ commit messages are collected, and the block execution evidence in the messages is the same, the commit state is reached and the next phase can be carried out;

[0116] Step S206: the dispatcher embeds the branch division scheme, branch execution evidence, and block execution evidence into the block data to construct a block, and broadcasts the verification between nodes.

[0117] Step S207: After verification, each dispatcher notifies the executor to submit the branch task execution result, and the dispatcher writes the block data into the account book.

[0118] The following is a consortium chain parallel computing device for group work of this embodiment that supports the availability of the computing group even if any physical node in the computing group fails. Each computing group is configured with at least 3 physical nodes, and the status of neighboring nodes is monitored in real time through a node status detection unit. When a neighboring node fails, the computing group can still operate normally. The specific steps are as follows: Figure 5 As shown:

[0119] Step S301: Neighboring nodes detect each other's operating status until a node failure is detected;

[0120] Step S302: determine whether the current node is a dispatcher and the faulty node is an executor. If yes, proceed to step S303; otherwise, proceed to step S305.

[0121] Step S303: the dispatcher notifies the consensus task division unit to reallocate the tasks assigned to the faulty node;

[0122] Step S304: the dispatcher notifies the transaction request distribution processing unit to reallocate the tasks assigned to the failed node;

[0123] Step S305: The executor nodes elect the next dispatcher based on the rotation order;

[0124] Step S306: The new dispatcher pulls the consensus tasks to be completed from other dispatchers.

[0125] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A consortium chain parallel computing method for group work, characterized in that: include: Divide the physical nodes provided by all alliance parties into different computing groups based on the alliance party they belong to; The scheduling nodes of each computing group receive tasks sent by the client and divide them into multiple branch tasks that can be processed in parallel without conflicts. The branch tasks are then assigned to different execution nodes for parallel processing through consistent hashing. Among them, the consistency of the ledger data of multiple computing groups is ensured through a consensus mechanism between computing groups; in a computing group, one physical node is selected as the scheduling node, and the other physical nodes are execution nodes. If the current scheduling node fails, the next scheduling node is selected from all execution nodes in rotation.

2. The consortium chain parallel computing method for group work as claimed in claim 1, characterized in that: Each computing group includes at least three physical nodes to ensure that the group can still work normally even if any physical node fails.

3. The consortium chain parallel computing method for group work as claimed in claim 1, characterized in that: The physical nodes within each group are neighbor nodes to each other, and the internal neighbor nodes are all trustworthy. The computing group participates in consensus computing and ledger data storage as a unified whole.

4. The consortium chain parallel computing method for group work as claimed in claim 1, characterized in that: Neighboring nodes in the same computing group provide shared disk space to build a distributed ledger library and status library. Each computing group maintains the full amount of ledger data and status data.

5. The consortium chain parallel computing method for group work as claimed in claim 1, characterized in that: Each neighbor node in the same computing group has read and write permissions to the ledger library and status library of the subordinate computing group.

6. A consortium chain parallel computing device for group work, characterized in that: include: A scheduling node selection component, which is used to select a node from the neighboring nodes of the computing group as a scheduling node, detect the operating status of the neighboring nodes and select a new scheduling node when the scheduling node fails; A scheduling component, which is used to provide scheduling processing capabilities for scheduling nodes; The scheduling component includes: a consensus task division unit, which is used to divide the transaction queue contained in the consensus task into multiple unrelated and ordered branch tasks according to the transaction order, and randomly assign an execution node to each branch task, and temporarily store the assignment record, and reallocate the task of the downed execution node when it is detected that an execution node is down; The task division verification unit is used to verify whether the consensus task division method sent by the scheduling node of other computing groups is correct; An execution component, which is used to provide task execution capabilities for execution nodes; The message processing component is used to provide message services and processing capabilities for the scheduling node selection component, scheduling component, and execution component during runtime.

7. The consortium chain parallel computing device for group work as claimed in claim 6, characterized in that: The scheduling node selection component includes: The dispatcher rotation unit is used to determine the order of the selected scheduling nodes within the computing group and select the next scheduling node in order; The node status detection unit is used to detect the operating status of neighboring nodes in real time. When the execution node detects that the scheduling node fails, it communicates with other neighboring nodes to replace the next scheduling node. When the scheduling node detects that the execution node is down, it reallocates tasks. The consensus task synchronization unit is used to synchronize the unfinished consensus tasks between the new scheduling node and other scheduling nodes.

8. The consortium chain parallel computing device for group work as claimed in claim 6, characterized in that: The scheduling component comprises: The transaction request distribution processing unit is used to respond to the transaction request of the client, distribute the request to the execution node for execution, temporarily store the distribution record, and reallocate the task when the execution node is detected to be down; The consensus task division unit is used to divide the transaction queue contained in the consensus task into multiple unrelated and ordered branch tasks according to the transaction order, and randomly assign an execution node to each branch task, and temporarily store the assignment record, and reallocate the task of the downed execution node when it is detected that an execution node is down; The task division verification unit is used to verify whether the consensus task division method sent by the scheduling node of other computing groups is correct; The branch result summary unit is used to summarize the branch task processing results returned after the execution of each execution node.

9. The consortium chain parallel computing device for group work as claimed in claim 6, characterized in that: The execution component comprises: The transaction construction unit is used to execute the transaction construction task sent by the scheduling node, return the execution result to the scheduling node through the message processing component, and broadcast the constructed transaction among neighboring nodes through the message processing unit; The branch task execution unit is used to execute the branch tasks sent by the scheduling node, check whether the transactions in the branch tasks are legal in sequence and execute the transactions. After the branch tasks are executed, the results are fed back to the scheduling node through the message processing component; The branch task submission unit is used to submit the transaction object status and transaction after the branch task is executed to the account book after receiving the branch task submission message sent by the scheduling node.

10. The consortium chain parallel computing device for group work as claimed in claim 9, characterized in that: The message processing unit comprises: A transaction construction message processing unit, which is used to process transaction construction related messages between the scheduling node and the execution node; The transaction broadcast message processing unit is used to broadcast the transaction constructed by the execution node among neighboring nodes, and broadcast the transaction received by the scheduling node to the scheduling nodes of other nodes; A consensus message processing unit, which is used to process consensus communication messages between scheduling nodes; A task distribution message processing unit, which is used to process task distribution and task execution result messages between the scheduling node and the execution node; The scheduling node selection message processing unit is used to enable neighbor nodes to communicate with each other to achieve consistency in scheduling node selection.

Images