Decentralization scheduling system based on dynamic election and consensus algorithm

Abstract

The invention discloses a decentralized scheduling system based on dynamic election and a consensus algorithm. The system comprises a working node which maintains heartbeat with a scheduling node for managing the working node, accepts task scheduling of the scheduling node, executes a task and returns a result to the scheduling node; the scheduling node is in a one-to-many management relationship with the working nodes, and reasonably schedules the tasks to the working nodes for execution by calculating the task complexity and the resources of the working nodes managed by the task complexity; a plurality of node state chains are used for recording change information of state change caused by corresponding events generated at each node moment; and a snapshot chain: carrying out snapshot on the current state of the global node through a consensus algorithm based on the tamper-proof characteristic of the block chain, and recording the current state on the snapshot chain. According to the scheme, through the node state chain and the consensus algorithm, the security is improved, and the multi-task concurrent execution performance and the system consensus throughput are improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a decentralized scheduling system and consensus algorithm based on dynamic elections. Background Art

[0002] Common blockchain structures, such as Bitcoin, maintain a single, elongated chain structure with a strict partial order relationship and higher tamper-proof properties.

[0003] However, since each node will generate corresponding events and change its state at any time, in order to ensure the asynchronous update of each node's state record and the requirements of a high-performance decentralized system, we use the block-lattice structure to record the state information of each node. It is stipulated that each node maintains its own state chain separately. For each node, its state chain is private. The state chains of all nodes are combined together to form a DAG structure.

[0004] However, in the block-lattice structure, each node maintains its own state chain, with fewer partial order relationships and a lack of consensus on the unified state of all nodes. This poses a risk of malicious tampering. Therefore, it is necessary to introduce an additional chain structure - the snapshot chain. Through the consensus algorithm, the current state of the global node is snapshotted and recorded on the snapshot chain, using the tamper-proof feature of the blockchain to improve security. Summary of the invention

[0005] Based on the above technical problems, the present invention proposes a decentralized scheduling system and consensus algorithm based on dynamic elections, constructs a special node status chain, and records the status information of each node; it also designs a consensus algorithm to ensure that the system reaches a consensus on the final status of each node and forms a snapshot chain. The specific technical solution is as follows.

[0006] In the first aspect, a decentralized scheduling system based on dynamic elections includes:

[0007] Worker node: maintains the heartbeat with the scheduling node that manages the worker node, accepts the task scheduling of the scheduling node, executes the task and returns the result to the scheduling node;

[0008] Scheduling node: It has a one-to-many management relationship with the working nodes. It reasonably schedules tasks to the working nodes for execution by calculating the complexity of the tasks and the working node resources it manages.

[0009] Node status chain: multiple node status chains record the status change information of each node when corresponding events occur at any time;

[0010] Snapshot chain: Based on the tamper-proof characteristics of the blockchain, the current state of the global node is snapshotted through the consensus algorithm and recorded on the snapshot chain.

[0011] Specifically, the node state chain is a strictly partially ordered set consisting of a given event set and a partially ordered relationship, and the state chains of all nodes are combined together to form a DAG structure; each node state chain block structure includes a block header and a block body, the block header includes a node id, timestamp, block height, target hash, root hash and block size data, and the block body includes task events.

[0012] Specifically, the snapshot chain is a blockchain generated and maintained by a consensus protocol, maintained by a master node generated by the consensus protocol, and generates snapshot blocks in an incremental storage manner. A snapshot block only stores data that has changed compared to the previous snapshot block. When a state information in the system is snapshotted by the snapshot chain, it is called the state being confirmed. The depth of the snapshot block that snapshots the state for the first time is called the confirmation number. As the snapshot chain grows by one block, the confirmation number of all previously confirmed states increases by 1, and the probability of a successful malicious tampering attack gradually decreases as the snapshot chain continues to increase.

[0013] Specifically, the snapshot chain block structure includes a block header and a block body. The block header includes an authorized node ID, a period number, a timestamp, a target hash, and a root hash of state data. The block body includes the latest state data of each node that has undergone a state update, which is collected when the authorized node is about to package the snapshot block.

[0014] On the other hand, a consensus algorithm for a decentralized scheduling system based on dynamic election is used to implement the decentralized scheduling system based on dynamic election. The consensus algorithm master selection process includes the following steps:

[0015] Step S1: Divide the nodes in the network into multiple node clusters according to the physical space distribution, and divide the nodes in each cluster into working nodes and scheduling nodes;

[0016] Step S2: In a cluster, all scheduling nodes form an election group and select a master node through a consensus mechanism, which is called an authorized node. When the cluster is initialized, a scheduling node is designated as an authorized node.

[0017] Step S3: After the authorized node is selected, the timer is started and the time period is set. During the time period, it is responsible for collecting task scheduling events and task execution events, and packaging the event summaries into blocks and uploading them to the blockchain through consensus.

[0018] Step S4: At the end of the time period, the authorization node collects the fund balance of each scheduling node and the hardware resource usage of each scheduling node in this round of time period, and calculates the amount of funds of each node after the fund allocation, and then makes the scheduling node with the most funds become the authorized node of the next time period, and deducts the corresponding funds of the node; then the amount of funds of each scheduling node after the election is updated to each scheduling node;

[0019] Step S5: Set up a fault judgment mechanism and a fault handling mechanism, and loop through steps S3 to S4.

[0020] Specifically, the step S3 of setting the time period specifically includes:

[0021] The continuous time is divided into several consecutive time periods, and the start and end of the time period are controlled by the authorized node;

[0022] When the authorized node is selected, a timer is started in the node to set the length of the period, and is responsible for collecting task scheduling events and task execution events during the period;

[0023] During this period, when the authorization node creates a snapshot block, it initiates a request to other scheduling nodes. The scheduling node returns the last status block on its status chain to the authorization node. At the same time, the scheduling node initiates a request to the working nodes it manages, obtains the last status block on the status chain of each working node, and forwards it to the authorization node. The authorization node packages the snapshot block and hangs it on the snapshot chain.

[0024] When the countdown ends, it means that the period has ended, and a new authorized node for the next period is selected from other scheduling nodes.

[0025] Specifically, the node election in step S4 is as follows:

[0026] At the end of the period, the authorization node requires each scheduling node to submit its own fund balance and its own hardware resource usage in this round of period. The authorization node calculates the collected hardware resource usage and obtains the fund allocation amount that each scheduling node should obtain and the amount of funds for each node after allocation. The fund allocation ratio calculation formula is:

[0027]

[0028] Among them, x, y, z represent indicators for measuring hardware performance: communication redundancy, computing redundancy, and storage redundancy; k is used to adjust the impact of hardware performance on fund allocation; p is used to adjust the magnitude of allocation;

[0029] The funds allocated to node i are: M is the total amount of funds;

[0030] The scheduling node with the most funds becomes the authorized node for the next period. This node needs to deduct 1 more funds than the second largest candidate node in terms of funds reserves;

[0031] The amount of funds after the election of each scheduling node is updated to each scheduling node.

[0032] Specifically, the fault judgment mechanism is as follows:

[0033] Whenever the authorization node receives a status block from other scheduling nodes, it must return a "confirmation" to the scheduling node;

[0034] By returning "confirmation", the scheduling node can detect whether the authorization node fails;

[0035] If a scheduling node times out while waiting for "confirmation", it means that the message may be lost or the authorization node is disconnected. At this time, the scheduling node is required to send the event summary again. If it times out three times, the scheduling node concludes that "the authorization node is disconnected."

[0036] Specifically, the fault handling mechanism is as follows: if the scheduling node a cannot connect to the authorized node X in the time period, the following processing is performed:

[0037] Scheduling node a broadcasts "a and X are out of touch" to other scheduling nodes; if scheduling node b that receives the broadcast can connect to authorized node X, it replies to scheduling node a "b can connect to X", otherwise it replies "b and X are out of touch"; when scheduling node b receives the broadcast from scheduling node a, it will record "a and X are out of touch" locally, which is regarded as a vote against authorized node X as an authorized node. When scheduling node b has accumulated more than half of the scheduling nodes in the local record that oppose authorized node X in this period, scheduling node b will actively notify other scheduling nodes to give up X and initiate a no-owner election;

[0038] After sending a broadcast, scheduling node a waits for a while. Based on the received reply information, it determines that if less than half of the scheduling nodes in the network have lost contact with the authorized node X, then scheduling node a selects a scheduling node c that can connect to the authorized node X, and scheduling node c forwards the task event on its behalf. If more than half of the scheduling nodes have lost contact with the authorized node, these scheduling nodes jointly sign to notify the remaining scheduling nodes to abandon the current authorized node X and re-initiate a masterless election.

[0039] After the ownerless election, a new authorization node is established. The new authorization node needs to search from the end of the chain to the last status block sent by each scheduling node recorded on the chain, and then ask each scheduling node to resend their respective status blocks after that, and then repackage them on the chain.

[0040] Specifically, the fault handling mechanism also includes:

[0041] When the scheduling node receives the "confirmation" returned by the authorization node, it returns the "confirmation" to the working node; if the working node does not wait for the "confirmation" or times out, it resends the status block. If it times out three times, it confirms the heartbeat detection between itself and the scheduling node to check whether the scheduling node is faulty and whether it needs to find a replacement scheduling node; after finding a new scheduling node, it resends the corresponding status block that has not received the "confirmation" before;

[0042] When scheduling node a and authorization node X time out three times, a still needs to initiate a heartbeat check to X at regular intervals; if a and X are restored to connection, a needs to broadcast "a can connect to X" to other scheduling nodes and update the local records of each scheduling node.

[0043] Beneficial effects of the invention: The present invention proposes a decentralized scheduling system and consensus algorithm based on dynamic elections, constructs a node status chain to record the status information of each node, takes a snapshot of the current status of the global node through the consensus algorithm, and records it on the snapshot chain, using the tamper-proof characteristics of the blockchain to improve security, improve the performance of concurrent execution of multiple tasks and the throughput of system consensus. Improve the performance of concurrent execution of multiple tasks and the throughput of system consensus. The nodes in the system are composed of working nodes and task scheduling nodes (hereinafter referred to as "scheduling nodes"). There is a one-to-many management relationship between the scheduling node and the working node. Among them, the working node needs to maintain a heartbeat with the scheduling node that manages it, accept the task scheduling of the scheduling node, execute the task and return the result to the scheduling node. The scheduling node has stronger computing, storage, and communication performance, and can reasonably schedule tasks to the working node for execution by calculating the complexity of the task and the resources of the working node it manages. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 It is a DAG structure diagram of the node state chain in an embodiment of the present invention;

[0045] Figure 2 It is a schematic diagram of the node status chain block structure in an embodiment of the present invention;

[0046] Figure 3 is a schematic diagram of the state chain and global snapshot chain of all nodes in an embodiment of the present invention;

[0047] Figure 4 It is a schematic diagram of the snapshot chain block structure in an embodiment of the present invention;

[0048] Figure 5 It is a schematic diagram of a DAG formed between a scheduling node and two working nodes managed by it in an embodiment of the present invention;

[0049] Figure 6 is a schematic diagram of a storage model after adding a snapshot chain in an embodiment of the present invention;

[0050] Figure 7 It is a schematic diagram of the algorithm flow of the present invention. DETAILED DESCRIPTION

[0051] In order to have a clearer understanding of the technical features, purposes and effects of the present invention, specific embodiments of the present invention are now described with reference to the accompanying drawings.

[0052] The present invention proposes a decentralized scheduling system and consensus algorithm based on dynamic election. The nodes in the system are divided into two categories, namely working nodes and task scheduling nodes (hereinafter referred to as "scheduling nodes"). There is a one-to-many management relationship between scheduling nodes and working nodes. Among them, the working node needs to maintain a heartbeat with the scheduling node that manages it, accept the task scheduling of the scheduling node, execute the task and return the result to the scheduling node.

[0053] The scheduling node has stronger computing, storage, and communication performance, and can reasonably schedule tasks to working nodes for execution by calculating the complexity of the tasks and the working node resources it manages.

[0054] Each scheduling node or working node is a node with status information in the system. The change of node status is often accompanied by the occurrence of certain events, so we call the conditions that cause the node status change events, such as task scheduling events of scheduling nodes and task execution events of working nodes.

[0055] Since each node will generate corresponding events and change its state at any time, in order to ensure the asynchronous update of each node status record and the requirements of high-performance decentralized system, the system uses multiple node status chains to record the status information of each node.

[0056] At the same time, the system also uses a chain structure to record global information - the snapshot chain. Through the consensus algorithm, it takes a snapshot of the current state of the global node and records it on the snapshot chain, using the tamper-proof characteristics of the blockchain to improve security.

[0057] In this embodiment, the node state chain is a strictly partially ordered set composed of a given event set and a partial order relationship, and each node maintains its own state chain separately. Therefore, each node state chain is essentially a blockchain maintained by the corresponding node alone, and has the relevant properties of the blockchain.

[0058] When the state chains of all nodes are combined together, a DAG structure is formed, such as Figure 1 As shown, circles represent the states of nodes and arrows represent the dependencies between node states.

[0059] The state chain block structure should Figure 2 As shown: The node id represents the id number of the scheduling node or working node that generates the status block. The task event message represents data related to the scheduling task or the execution task, such as the task number, scheduling status (which scheduling node schedules it, which working nodes execute it), task status (scheduled, executing, and completed), and execution results.

[0060] In this embodiment, the snapshot chain is the most important storage structure in the system. Its main function is to maintain the consensus of the entire node state chain. The right to generate blocks is obtained through the consensus protocol. Its essence is a blockchain generated and maintained by the consensus protocol.

[0061] It is worth noting that in this system, recording status information on the node status chain is also asynchronous with the final system confirmation of the status. Different nodes can concurrently write records to their respective node status chains, and the status of each node is considered confirmed only when it is snapshotted and hung on the snapshot chain.

[0062] After joining the snapshot chain, the status chains of all nodes and the global snapshot chain are as follows: Figure 3 As shown:

[0063] The snapshot chain is maintained by the master node generated by the consensus protocol. When generating snapshot blocks, incremental storage is used, and a snapshot block only saves data that has changed compared to the previous snapshot block. If a node has not undergone any state changes between two snapshots, the latter snapshot block does not save the state information of the node. Since each snapshot only saves the last state of each node at the snapshot time, and does not care about the intermediate state, no matter how many state changes a node has undergone between two snapshot blocks, only the last state is saved in the snapshot.

[0064] In this system, when a state information is snapshotted by the snapshot chain, it is called the state is confirmed. The depth of the snapshot block of the first snapshot of the state is called the confirmation number. Every time the snapshot chain grows a block, the confirmation number of all previously confirmed states increases by 1. The probability of a successful malicious tampering attack gradually decreases as the snapshot chain continues to grow.

[0065] The block structure of the snapshot chain is as follows: Figure 4As shown in the figure: Among them, the authorization node id indicates the node id that generated this snapshot block. The time period number indicates the time period in which the snapshot block was generated. State data such as state 1 and state 2 indicate that when the authorization node is about to package the snapshot block, it collects the latest state blocks of each node that has undergone status updates. These block data include: (1) the task id that the node is executing; (2) the hardware resource occupancy / idleness of the node; (3) the hash of the last block in the node status chain. The information of the status block is hashed and finally forms the root hash of the status data and is stored in the block header.

[0066] In this embodiment, the leader selection process of the decentralized scheduling system consensus algorithm based on dynamic election can be summarized as follows:

[0067] 1. The nodes in the network are divided into multiple node clusters according to their physical space distribution. Within a cluster, the nodes need to be divided into working nodes and scheduling nodes.

[0068] 2. In a cluster, all scheduling nodes form an election group and select a master node through a consensus mechanism, which is called an authorized node. When the cluster is initialized, a scheduling node is designated as the authorized node.

[0069] 3. After the authorized node is selected, the timer is started and the time period is set. During the time period, it is responsible for collecting task scheduling events and task execution events, packaging the event summaries into blocks, and uploading the consensus to the chain.

[0070] 4. At the end of the period, the authorization node collects the fund balance of each scheduling node and the hardware resource usage of each scheduling node in this round of period, and calculates the amount of funds of each node after the fund allocation, and then makes the scheduling node with the most funds the authorized node of the next period, and deducts the corresponding funds of the node. Then, the amount of funds of each scheduling node after the election is updated to each scheduling node.

[0071] 5. Repeat process three to four.

[0072] In addition, in order to avoid system losses caused by node failures, additional fault judgment mechanisms and fault handling mechanisms are provided.

[0073] In this embodiment, in a cluster, ideally there should be multiple scheduling nodes and a large number of working nodes. For the scheduling nodes, a master node needs to be selected through a consensus mechanism. Here, we logically form a campaign group for the scheduling nodes, and finally select a master node, called an authorized node. When the system is initialized, we designate a scheduling node as an authorized node.

[0074] In this embodiment, the continuous time is divided into several consecutive time periods, and the start and end of the time period are controlled by the authorization node. When the authorization node is selected, a timer is started in the node, and the time length of the time period (a constant value) is set. During this time period, it is responsible for the collection of task scheduling events and task execution events, and the creation and chaining of snapshot blocks. That is to say, although each node only records its own status update information, during this time period, whenever the authorization node wants to create a snapshot block, it will initiate a request to other scheduling nodes. The scheduling node will return the last status block on its own status chain to the authorization node. At the same time, the scheduling node will initiate a request to the working node it manages, obtain the last status block on the status chain of each working node, and forward it to the authorization node, which will package the snapshot block and hang it on the snapshot chain.

[0075] When the countdown ends, it means that the period has ended. We require that the authorized node cannot be "re-elected", that is, the authorized node needs to select a new authorized node for the next period from other scheduling nodes.

[0076] In this embodiment, at the end of each period, the election group as a whole will receive a sum of money, the total amount of which is M, which will be allocated to each scheduling node for election. The amount allocated to each scheduling node is related to its performance redundancy in this round of time. The more performance redundancy, the more money it will get from the total amount M. This amount is intended to give nodes with performance redundancy (i.e., idle) a better chance of becoming authorized nodes. At the same time, the unused funds of each node can be stored until the next round.

[0077] The reference formula for fund allocation is as follows, where:

[0078] x, y, and z represent indicators for measuring hardware performance, such as communication redundancy, computing redundancy, and storage redundancy; k is used to adjust the impact of hardware performance on fund allocation; and p is used to adjust the magnitude of allocation. i Used to calculate the proportion of funds allocated from M

[0079]

[0080] Finally, for node i, the funds allocated to it should be:

[0081]

[0082] The specific process of the election is that at the end of the period, the authorization node requires each scheduling node to submit its own fund balance and its own hardware resource usage in this round of period. The authorization node calculates the collected hardware resource usage and obtains the fund allocation quota that each scheduling node should obtain and the amount of funds of each node after allocation. Then, the scheduling node with the most funds becomes the authorized node of the next period. This node needs to deduct 1 more funds than the second-ranked election node. Then, the amount of funds of each scheduling node after the election is updated to each scheduling node.

[0083] In this embodiment, the fault judgment mechanism specifically includes:

[0084] If the scheduling node fails, you can still refer to the mechanism of replacing it with a capable working node, as detailed in Chapter 4.

[0085] If the authorization node fails, it will directly affect the packaging and chaining of blocks. Therefore, the system needs to be able to detect whether the authorization node is faulty and recover after the failure.

[0086] Therefore, the authorization node is required to return "confirmation" to the scheduling node whenever it receives a status block from other scheduling nodes. This is also a necessary design to avoid the loss of messages containing status blocks. Through "confirmation", other scheduling nodes can detect whether the authorization node has failed. If the scheduling node times out while waiting for "confirmation", it means that the message may be lost or the authorization node may be disconnected. At this time, the scheduling node is required to send the event summary again. If it times out three times, the scheduling node determines that the "authorization node is disconnected."

[0087] In this embodiment, the fault handling mechanism specifically includes:

[0088] At this time, assuming that the scheduling node a cannot connect to the authorized node X in this period, the following steps are taken:

[0089] a will broadcast "a is out of touch with X" to other scheduling nodes. If the scheduling node b that receives the broadcast can connect to X, it will reply to a "b can connect to X", otherwise it will reply "b is out of touch with X". When b receives a's broadcast, it will record "a is out of touch with X" locally, which is regarded as a vote against X as an authorized node. When b accumulates more than half of the scheduling nodes in the local record (regarded as a voting library) that oppose X in this period, b will actively notify other scheduling nodes to give up X and initiate a no-owner election.

[0090] 2. After a sends out a broadcast, it waits for a while, and then, based on the received reply information, it determines that if less than half of the scheduling nodes in the network have lost contact with X, a selects a scheduling node c that can connect to X, and c forwards the task event on its behalf. If more than half of the scheduling nodes have lost contact with the authorized node, these scheduling nodes jointly sign (that is, the message "b has lost contact with X"), notifying the remaining scheduling nodes to abandon the current X and re-initiate a masterless election.

[0091] 3. After the ownerless election, the new authorization node is established. Since the block has been agreed upon among the scheduling nodes during the process of the previous authorization node packaging the block and putting it on the chain, the previous work is not completely lost. The only lost content is the message after the last block on the chain. Therefore, the new authorization node needs to search from the end of the chain to the last status block sent by each scheduling node recorded on the chain, and then ask each scheduling node to resend their respective status blocks after this, and then repackage and put it on the chain.

[0092] In addition, whenever the scheduling node receives a "confirmation" from the authorization node, it knows that the forwarded working node status block has been successfully handed over to the authorization node, and then returns a "confirmation" to the working node. If the working node times out before the "confirmation", it resends the status block. If it times out three times, it needs to confirm the heartbeat detection between the scheduling node and the scheduling node to check whether the scheduling node is faulty and whether it needs to find a replacement scheduling node. After finding a new scheduling node, resend the corresponding status block that did not receive a "confirmation" before.

[0093] In addition, when scheduling node a and authorized node X have timed out three times, a still needs to initiate a heartbeat check to X at regular intervals to avoid timeouts caused by network fluctuations. If a and X are connected again, a will broadcast "a can connect to X" to other scheduling nodes to update the local records of each scheduling node.

[0094] In this embodiment, the no-owner election specifically includes:

[0095] Since more than half of the scheduling nodes believe that the authorization node has been disconnected, the previous authorization node no longer has authority, and the election is an unhosted election, so it is called a hostless election.

[0096] At this time, a new authorization node is selected through auction bidding.

[0097] All scheduling nodes broadcast their own fund reserve values ​​to other scheduling nodes, and then all scheduling nodes obtain the fund information in the cluster, so they can unanimously determine who has the most funds, that is, they can directly identify the authorized nodes for the new round of time periods. The node that is elected as the authorized node also knows that it has the most funds and wants to be an authorized node, so it deducts 1 more fund from its own funds than the second-ranked candidate node in terms of fund reserves. At the same time, other nodes have also known the establishment of the authorized node, so there is no need to notify other nodes additionally, and it can directly start to take on the work of the authorized node.

[0098] In this system, events are divided into task scheduling and task execution, which correspond to "schedule start" and "schedule finish" of the scheduling node, and "task start" and "task finish" of the working node.

[0099] Among them, the task must be scheduled before it starts to execute, so "task start" needs to reference the corresponding "schedule start" hash;

[0100] The task must be started before it is finished, so "task finish" needs to reference the corresponding "taskstart" hash;

[0101] When all tasks included in a task schedule are completed, it means that the scheduling is finished, so "schedule finish" needs to reference the corresponding "task finish" hash;

[0102] In a cluster, when a scheduling node receives a task, a task scheduling event occurs, and the scheduling event is stored locally in the scheduling node in a chain structure.

[0103] After receiving the task, the working node starts to execute the task and returns the task execution result to the scheduling node after the task is completed. In this process, two events, "task start" and "task finish", are generated and stored locally in the working node in a chain structure.

[0104] Figure 5 The following is an example of a DAG formed between a scheduling node and the two working nodes it manages:

[0105] Should Figure 5It shows that the scheduling node divides a task into three tasks, and calculates the best task allocation based on the resources and service deployment of working nodes a and b. Task1 and task2 can be assigned to working nodes a and b for parallel execution respectively, and task3 is assigned to working node a for execution, but the results of task1 and task2 are needed. Therefore, the following process is involved:

[0106] (1) The scheduling node first generates a “schedule start” event and records it on the local chain.

[0107] (2) Worker node a receives the command to execute task1 and task3, and worker node b receives the command to execute task2. They each generate a "task start" event and record it on their respective local chains, and "task start" and "schedule start" have a sequential dependency relationship.

[0108] (3) After task1 and task2 are completed, task3 can start executing, so "task3 start" depends on "task1 finish" and "task2 finish".

[0109] (4) Finally, after task3 is completed, the result is returned to the scheduling node, which generates a “schedulefinish” event and records it on the local chain.

[0110] Snapshot chain: After joining the snapshot chain, the storage model is as follows Figure 6 As shown:

[0111] The figure shows that when the first snapshot is taken, the status of the scheduling node is "schedule start", the status of the working node a is "task1 start", and the status of the working node b is "task2 start". At this time, a and b are executing task1 and task2 respectively, and have not yet completed the execution. Therefore, after the system takes a snapshot of the status of these three nodes, their status at that moment is packaged into the snapshot block as the first block on the snapshot chain.

[0112] When the second snapshot is taken, the status of the scheduling node has not changed, the status of the working node b is "task2finish", indicating that task2 has been completed, and the status of the working node a is "task3 start", so the status of the working nodes a and b has changed. Therefore, the snapshot block will record the last block on the status chain of the node whose status has changed, and the status information of the node whose status has not changed does not need to be recorded in the new snapshot block (because it has been recorded).

[0113] During the third snapshot, the status of the scheduling node and working node a changed, so the latest status of these two nodes was recorded in the new snapshot block.

[0114] The consensus algorithm code of the decentralized scheduling system based on dynamic election is as follows Figure 7 shown.

[0115] The present invention has shown and described the basic principles and main features of the present invention and the advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A decentralized scheduling system based on dynamic election, characterized in that: include: Worker node: maintains the heartbeat with the scheduling node that manages the worker node, accepts the task scheduling of the scheduling node, executes the task and returns the result to the scheduling node; Scheduling node: It has a one-to-many management relationship with the working nodes. It reasonably schedules tasks to the working nodes for execution by calculating the complexity of the tasks and the working node resources it manages. Node status chain: multiple node status chains record the status change information of each node when corresponding events occur at any time; Snapshot chain: Based on the tamper-proof characteristics of the blockchain, the current state of the global node is snapshotted through the consensus algorithm and recorded on the snapshot chain.

2. A decentralized scheduling system based on dynamic election according to claim 1, characterized in that: The node state chain is a strictly partially ordered set consisting of a given event set and a partially ordered relationship, and is composed of the state chains of all nodes combined together to form a DAG structure; each node state chain block structure includes a block header and a block body, the block header includes a node id, timestamp, block height, target hash, root hash and block size data, and the block body includes a task event.

3. According to claim 1, a decentralized scheduling system based on dynamic elections is characterized in that: The snapshot chain is a blockchain generated and maintained by a consensus protocol. It is maintained by the master node generated by the consensus protocol and generates snapshot blocks in an incremental storage manner. A snapshot block only stores data that has changed compared to the previous snapshot block. When a state information in the system is snapshotted by the snapshot chain, it is called the state being confirmed. The depth of the snapshot block that snapshots the state for the first time is called the confirmation number. As the snapshot chain grows by one block, the confirmation number of all previously confirmed states increases by 1. The probability of a successful malicious tampering attack gradually decreases as the snapshot chain continues to grow.

4. A decentralized scheduling system based on dynamic election according to claim 3, characterized in that: The snapshot chain block structure includes a block header and a block body. The block header includes the authorization node id, period number, timestamp, target hash and root hash of status data. The block body includes the latest status data of each node that has undergone status update collected when the authorization node is about to package the snapshot block.

5. A consensus algorithm for a decentralized scheduling system based on dynamic election, used to implement a decentralized scheduling system based on dynamic election as described in any one of claims 1 to 4, characterized in that: The consensus algorithm leader selection process includes the following steps: Step S1: Divide the nodes in the network into multiple node clusters according to the physical space distribution, and divide the nodes in each cluster into working nodes and scheduling nodes; Step S2: In a cluster, all scheduling nodes form an election group and select a master node through a consensus mechanism, which is called an authorized node. When the cluster is initialized, a scheduling node is designated as an authorized node. Step S3: After the authorized node is selected, the timer is started and the time period is set. During the time period, it is responsible for collecting task scheduling events and task execution events, and packaging the event summaries into blocks and uploading them to the blockchain through consensus. Step S4: At the end of the time period, the authorization node collects the fund balance of each scheduling node and the hardware resource usage of each scheduling node in this round of time period, and calculates the amount of funds of each node after the fund allocation, and then makes the scheduling node with the most funds become the authorized node of the next time period, and deducts the corresponding funds of the node; then the amount of funds of each scheduling node after the election is updated to each scheduling node; Step S5: Set up a fault judgment mechanism and a fault handling mechanism, and loop through steps S3 to S4.

6. According to claim 5, a decentralized scheduling system consensus algorithm based on dynamic elections is characterized in that: The step S3 of setting the time period specifically includes: The continuous time is divided into several consecutive time periods, and the start and end of the time period are controlled by the authorized node; When the authorized node is selected, a timer is started in the node to set the length of the period, and is responsible for collecting task scheduling events and task execution events during the period; During this period, when the authorization node creates a snapshot block, it initiates a request to other scheduling nodes. The scheduling node returns the last status block on its status chain to the authorization node. At the same time, the scheduling node initiates a request to the working nodes it manages, obtains the last status block on the status chain of each working node, and forwards it to the authorization node. The authorization node packages the snapshot block and hangs it on the snapshot chain. When the countdown ends, it means that the period has ended, and a new authorized node for the next period is selected from other scheduling nodes.

7. According to claim 5, a decentralized scheduling system consensus algorithm based on dynamic elections is characterized in that: The node election in step S4 is specifically as follows: At the end of the period, the authorization node requires each scheduling node to submit its own fund balance and its own hardware resource usage in this round of period. The authorization node calculates the collected hardware resource usage and obtains the fund allocation amount that each scheduling node should obtain and the amount of funds for each node after allocation. The fund allocation ratio calculation formula is: Among them, x, y, and z represent indicators for measuring hardware performance: communication redundancy, computing redundancy, and storage redundancy; k is used to adjust the impact of hardware performance on fund allocation; and p is used to adjust the magnitude of allocation. The funds allocated to node i are: M is the total amount of funds; The scheduling node with the most funds becomes the authorized node for the next period. This node needs to deduct 1 more funds than the second largest candidate node in terms of funds reserves; The amount of funds after the election of each scheduling node is updated to each scheduling node.

8. According to claim 5, a decentralized scheduling system consensus algorithm based on dynamic elections is characterized in that: The fault judgment mechanism is specifically as follows: Whenever the authorization node receives a status block from other scheduling nodes, it must return "confirmation" to the scheduling node; By returning "confirmation", the scheduling node can detect whether the authorization node fails; If a scheduling node times out while waiting for "confirmation", it means that the message may be lost or the authorization node is disconnected. At this time, the scheduling node is required to send the event summary again. If it times out three times, the scheduling node concludes that "the authorization node is disconnected." 9. According to claim 5, a decentralized scheduling system consensus algorithm based on dynamic elections is characterized in that: The fault handling mechanism is specifically as follows: if the scheduling node a cannot connect to the authorized node X in the time period, the following processing is performed: Scheduling node a broadcasts "a and X are out of touch" to other scheduling nodes; if scheduling node b that receives the broadcast can connect to authorized node X, it replies to scheduling node a "b can connect to X", otherwise it replies "b and X are out of touch"; when scheduling node b receives the broadcast from scheduling node a, it will record "a and X are out of touch" locally, which is regarded as a vote against authorized node X as an authorized node. When scheduling node b accumulates more than half of the scheduling nodes in the local record that oppose authorized node X in this period, scheduling node b will actively notify other scheduling nodes to give up X and initiate a no-owner election; After sending a broadcast, scheduling node a waits for a while. Based on the received reply information, it determines that if less than half of the scheduling nodes in the network have lost contact with the authorized node X, then scheduling node a selects a scheduling node c that can connect to the authorized node X, and scheduling node c forwards the task event on its behalf. If more than half of the scheduling nodes have lost contact with the authorized node, these scheduling nodes jointly sign to notify the remaining scheduling nodes to abandon the current authorized node X and re-initiate a masterless election. After the ownerless election, a new authorization node is established. The new authorization node needs to search from the end of the chain to the last status block sent by each scheduling node recorded on the chain, and then ask each scheduling node to resend their respective status blocks after that, and then repackage them on the chain.

10. A decentralized scheduling system consensus algorithm based on dynamic election according to claim 9, characterized in that: The fault handling mechanism also includes: When the scheduling node receives the "confirmation" returned by the authorization node, it returns the "confirmation" to the working node; if the working node does not wait for the "confirmation" or times out, it resends the status block. If it times out three times, it confirms the heartbeat detection between itself and the scheduling node to check whether the scheduling node is faulty and whether it needs to find a replacement scheduling node; after finding a new scheduling node, it resends the corresponding status block that has not received the "confirmation" before; When scheduling node a and authorization node X time out three times, a still needs to initiate a heartbeat check to X at regular intervals; if a and X are connected again, a needs to broadcast "a can connect to X" to other scheduling nodes and update the local records of each scheduling node.

Images