A consensus method of a decentralized dispatching system based on dynamic election

Abstract

The application discloses a consensus method of a decentralized scheduling system based on dynamic election, and a master selection process is carried out based on a decentralized scheduling system comprising a working node, a scheduling node, a node state chain and a snapshot chain. The scheduling node and the working node have a one-to-many management relationship. The working node maintains a heartbeat between the scheduling node which manages the working node, accepts task scheduling of the scheduling node, executes the task and returns the result to the scheduling node. The scheduling node has stronger computing, storage and communication performance. The task is reasonably scheduled to the working node for execution to build a node state chain to record state information of each node by calculating the task complexity and the managed working node resources. The consensus method provided by the scheme takes a snapshot of the current state of the global node and records the snapshot on the snapshot chain. The tamper-proof feature of the block chain is used to improve safety, and the performance of multi-task concurrent execution and the throughput of system consensus are improved.

Description

Technical Field

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

[0002] The common blockchain structure maintains a single, elongated chain structure with a strict partial order relationship and higher tamper-proof properties.

[0003] However, since each node constantly generates events and undergoes state changes, we use a block-lattice structure to record the state information of each node to ensure asynchronous updates of each node's state record and meet the requirements of a high-performance decentralized system. Each node maintains its own state chain, which is private to each node. The state chains of all nodes are combined 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 a consensus method, the current state of the global node is snapshotted and recorded on the snapshot chain, utilizing the tamper-proof nature of the blockchain to improve security. Summary of the Invention

[0005] Based on the above technical problems, the present invention proposes a consensus method for a decentralized scheduling system based on dynamic elections, constructs a special node status chain, and records the status information of each node. It also designs a consensus method 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] First, a decentralized scheduling system based on dynamic elections, including:

[0007] Worker node: maintains a heartbeat with the scheduling node that manages the worker node, accepts task scheduling from the scheduling node, executes tasks, and returns results to the scheduling node;

[0008] Scheduling node: It has a one-to-many management relationship with the worker nodes. It reasonably dispatches tasks to the worker nodes for execution by calculating the complexity of the tasks and the resources of the worker nodes 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 method and recorded on the snapshot chain.

[0011] Specifically, the node state chain is a strictly partially ordered set consisting of a given set of events and a partial order relationship, which is composed of the state chains of all nodes to form a DAG structure; the block structure of each node state chain includes a block header and a block body, the block header includes 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. 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 said that the state is confirmed. The depth of the snapshot block that first snapshots the state is called the confirmation number. With each block added to the snapshot chain, 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.

[0013] Specifically, 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.

[0014] On the other hand, a consensus method for a decentralized scheduling system based on dynamic election is provided, which is used to implement the decentralized scheduling system based on dynamic election. The consensus method 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 the authorized node.

[0017] Step S3: After the authorized node is selected, it starts the timer and sets a time period. 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;

[0018] Step S4: At the end of the time period, the authorization node collects the fund balances of each scheduling node and the hardware resource usage of each node in the current time period. The authorization node calculates the fund amount of each node after the fund allocation, and then makes the scheduling node with the most funds become the authorized node for the next time period, and deducts the corresponding funds of this node. The funding amount of each scheduling node after the election is then 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 includes:

[0021] Divide the continuous time into several consecutive time periods, the start and end of which 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. During this period, it is responsible for collecting task scheduling events and task execution events.

[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 own 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 each working node's status chain, 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 during this round of period. The authorization node calculates the collected hardware resource usage and obtains the fund allocation amount that each scheduling node should receive and the amount of funds allocated to each node after allocation. The fund allocation ratio is calculated as follows:

[0027] ;

[0028] 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.

[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-ranked candidate node;

[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 another scheduling node, 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 the 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 has lost contact with X" to other scheduling nodes. Upon receiving the broadcast, scheduling node b responds to scheduling node a with a message "b can connect to X" if it can connect to authorized node X. Otherwise, it responds with a message "b has lost contact with X." Upon receiving the broadcast from scheduling node a, scheduling node b records "a has lost contact with X" locally, treating it as a vote against X's decision to authorize the node. If scheduling node b's local record shows that more than half of the scheduling nodes have opposed X's decision to authorize the node in the current period, scheduling node b proactively notifies other scheduling nodes to abandon 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, if no more than half of the scheduling nodes in the network have lost contact with the authorized node X, 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 no-owner 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 further 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 receive the "confirmation" or times out, it resends the status block. If it times out three times, it checks the heartbeat between itself and the scheduling node to see if the scheduling node is faulty and whether a replacement scheduling node needs to be found. After finding a new scheduling node, it resends the corresponding status block for which it did not receive the "confirmation" before.

[0042] After three timeouts between scheduling node a and authorized node X, a still needs to initiate a heartbeat check with X at regular intervals. If the connection between a and X is restored, 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 present invention: The present invention proposes a consensus method for a decentralized scheduling system 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 method, and records it on the snapshot chain, utilizing the tamper-proof characteristics of the blockchain to improve security, and 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 This is a DAG structure diagram of the node state chain in an embodiment of the present invention;

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

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

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

[0048] Figure 5 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 This 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] This paper proposes a consensus method for a decentralized scheduling system based on dynamic elections. Nodes in this system are divided into two categories: worker nodes and task scheduling nodes (hereinafter referred to as "scheduling nodes"). Scheduling nodes and worker nodes have a one-to-many management relationship. Worker nodes must maintain a heartbeat with the scheduling node that manages them, accept task schedules from the scheduling node, execute tasks, and return results to the scheduling node.

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

[0054] Each scheduling node or worker node is a node in the system with state information. Changes in node state are often accompanied by certain events. Therefore, we call the conditions that cause node state changes events. For example, task scheduling events for scheduling nodes and task execution events for worker 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's state record and the requirements of a high-performance decentralized system, the system uses multiple node state chains to record the state 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 method, it takes a snapshot of the current status 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 consisting of a given set of events and a partial order. Each node independently maintains its own state chain. Therefore, each node state chain is essentially a blockchain maintained by the corresponding node and has the relevant properties of a 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 in the figure, the node ID represents the ID of the scheduling node or worker node that generated the status block. The task event message represents data related to scheduling or executing tasks, such as the task number, scheduling status (which scheduling node is scheduling the task, which worker nodes are executing the task), task status (scheduled, executing, or 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 consensus on the entire node state chain. The right to produce blocks is obtained through the consensus protocol. In essence, it is a blockchain generated and maintained by the consensus protocol.

[0061] It’s worth noting that in this system, recording status information on the node status chain is asynchronous with the final system confirmation of the status. Different nodes can concurrently write records to their respective node status chains, and confirmation is only considered when the status of each node is snapshotted and posted 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, with each snapshot block only storing data that has changed since the previous snapshot block. If a node's state remains unchanged between two snapshots, the subsequent snapshot block does not store that node's state information. Because each snapshot only stores the final state of each node at the time of the snapshot, regardless of intermediate states, no matter how many state changes a node undergoes between two snapshot blocks, only the final state is stored in the snapshot.

[0064] In this system, when a state is snapshotted by the snapshot chain, it is said to be confirmed. The depth of the snapshot block that first snapshotted the state is called the confirmation count. With each block added to the snapshot chain, the confirmation count 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: Wherein, the authorized node id represents the node id generating this snapshot block. The time period number represents which time period this snapshot block is generated. The state 1, state 2 and the like state data represent the latest state block of each node collected by the authorized node when it is about to package the snapshot block. These block data include: (1) the task id being executed by the node; (2) the hardware resource occupation / idleness of the node; (3) the hash of the last block of the state chain of the node. The information of the state block is hashed and coded, and finally the root hash of the state data is stored in the block header

[0066] In the embodiment, the consensus method of the dynamic election-based decentralized scheduling system main selection process can be summarized as follows:

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

[0068] II. In a cluster, all scheduling nodes form a candidate group, and a master node is selected through a consensus mechanism, which is called an authorized node. When initializing a cluster, a scheduling node is designated as an authorized node.

[0069] III. After the authorized node is selected, a timer is started, and a time period is set. The authorized node is responsible for collecting task scheduling events and task execution events within the time period, and packaging event summaries into blocks for consensus and chain.

[0070] IV. At the end of the time period, the authorized node collects the balance of funds of each scheduling node and the hardware resource usage of each scheduling node in the current time period. The authorized node calculates the amount of funds of each node after the distribution of funds, 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 update the fund amount of each scheduling node after the election to each scheduling node.

[0071] V. Repeat processes III to IV.

[0072] In addition, in order to avoid system loss caused by node failure, an additional failure judgment mechanism and failure handling mechanism are also provided.

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

[0074] In this embodiment, continuous time is divided into several consecutive time periods, the start and end of which are controlled by the authorization node. Once an authorization node is selected, it starts a timer within the node and sets the duration of the time period (a constant value). During this time period, it is responsible for collecting task scheduling events and task execution events, and creating and uploading snapshot blocks to the chain. In other words, although each node only records its own state update information, during this time period, whenever the authorization node needs 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 state chain to the authorization node. At the same time, the scheduling node will initiate a request to the worker nodes it manages to obtain the last status block on each worker node's state chain and forward it to the authorization node. The authorization node will then package the snapshot block and attach it to 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 entire campaign group receives a total of M, which is then distributed to each scheduling node for election purposes. The amount allocated to each scheduling node is related to its performance margin during the current period. The greater the performance margin, the larger the allocation from the total M. This allocation is intended to give nodes with redundant (i.e., idle) performance a greater chance of becoming authorized nodes. Furthermore, any unused funds from 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. 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 as follows: at the end of a period, the authorization node requires each scheduling node to submit its own fund balance and hardware resource usage during the current period. The authorization node then calculates the collected hardware resource usage information to determine the fund allocation amount each scheduling node should receive and the amount of funds each node will receive after the allocation. The scheduling node with the most funds will then become the authorized node for the next period. This node will be required to deduct an amount of funds equal to one more than the second-ranked candidate node's funds. The funding amount of each scheduling node after the election is then 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, see Chapter 4 for details.

[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 authorizing node is required to return an "acknowledgement" to the dispatching node whenever it receives a status block from another dispatching node. This is a necessary design to prevent the loss of messages containing status blocks. This "acknowledgement" allows other dispatching nodes to detect whether the authorizing node has failed. If a dispatching node times out while waiting for the "acknowledgement," it may indicate that the message was lost or that the authorizing node is disconnected. In this case, the dispatching node is required to resend the event summary. If it times out three times, the dispatching node determines that the authorizing node is disconnected.

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

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

[0089] A broadcasts "a has lost contact with X" to other scheduling nodes. Upon receiving the broadcast, scheduling node b responds to a with "b can connect to X" if it can connect to X. Otherwise, it responds with "b has lost contact with X." Upon receiving a's broadcast, node b locally records "a has lost contact with X," treating this as a vote against X's authorization. If node b's local record (considered a voting database) indicates that more than half of the scheduling nodes have opposed X during the current period, node b will proactively notify other scheduling nodes to abandon X, initiating a no-owner election.

[0090] 2. After sending the broadcast, a waits for a while. Based on the replies it receives, it determines that if no more 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 a message (i.e., "b has lost contact with X"), notifying the remaining scheduling nodes to abandon the current X and initiate a new unowned election.

[0091] 3. After the ownerless election, a new authorized node is established. Since the block was already agreed upon among the scheduling nodes during the process of the previous authorized node packaging and uploading the block, the previous work is not completely lost. The only lost content is the information after the last block on the chain. Therefore, the new authorized node needs to search from the end of the chain to find the last status block sent by each scheduling node on the chain, and then request each scheduling node to resend their respective status blocks after that, and then repackage and upload them to the chain.

[0092] Furthermore, whenever a scheduling node receives an "acknowledgement" from an authorizing node, it knows that the worker node status block it forwarded has been successfully delivered to the authorizing node and returns an "acknowledgement" to the worker node. If a worker node times out before receiving an "acknowledgement," it retransmits the status block. If it times out three times, it performs a heartbeat check with the scheduling node to determine if the scheduling node is faulty and whether a replacement scheduling node is needed. Once a new scheduling node is found, it retransmits the corresponding status block for which it did not receive an "acknowledgement."

[0093] Furthermore, after three timeouts between scheduling node a and authorized node X, a must still periodically initiate heartbeat checks with X to avoid timeouts caused by network fluctuations. If the connection between a and X is restored, a broadcasts "a can connect to X" to the other scheduling nodes, updating their local records.

[0094] In this embodiment, the no-leader 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. The election is an unhosted election, so it is called a leaderless election.

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

[0097] All scheduling nodes broadcast their fund reserves to other scheduling nodes. Once all scheduling nodes have access to the cluster's fund information, they can collectively determine who has the most funds and, therefore, directly designate the authorized node for the new round. The node elected as the authorized node also knows it has the most funds. To become the authorized node, it deducts an amount from its own funds that is one more than the second-ranked candidate's fund reserves. Since other nodes are already aware of the authorized node's establishment, there's no need to notify them further and they can immediately begin their work as authorized nodes.

[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] A 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 schedule 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 worker nodes it manages:

[0105] Should Figure 5This shows that the scheduling node divides a task into three tasks and calculates the optimal task allocation based on the resources and service deployment of worker nodes a and b. Tasks 1 and 2 can be assigned to worker nodes a and b for parallel execution, respectively, while task 3 is assigned to worker node a for execution, but it requires the results of tasks 1 and 2. Therefore, the process is as follows:

[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 task 3 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

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

[0112] The diagram shows that when the first snapshot is taken, the status of the scheduling node is "schedule start", the status of worker node a is "task1 start", and the status of worker node b is "task2 start". At this time, a and b are executing task 1 and task 2 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 a snapshot block as the first block on the snapshot chain.

[0113] When the second snapshot is taken, the status of the scheduling node has not changed. The status of worker node b is "task2finish", indicating that task2 has been completed, and the status of worker node a is "task3 start". Therefore, the status of worker 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. 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 already been recorded).

[0114] 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.

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

[0116] The basic principles, main features, and advantages of the present invention are shown and described above. Those skilled in the art should understand that the present invention is not limited to the foregoing embodiments. The foregoing embodiments and descriptions are merely illustrative of the principles of the present invention. Various changes and modifications may be made to the present invention without departing from the spirit and scope of the present invention. Such changes and modifications are intended to fall within the scope of the present invention. The scope of protection claimed in the present invention is defined by the appended claims and their equivalents.

Claims

1. A consensus method for a decentralized scheduling system based on dynamic elections, characterized in that: The decentralized scheduling system includes working nodes, scheduling nodes, a node state chain, and a snapshot chain. The node state chain is a strictly partially ordered set consisting of a given set of events and a partial order relation, and is composed of the state chains of all nodes combined to form a DAG structure. The snapshot chain is a blockchain generated and maintained by a consensus protocol, maintained by a master node generated by the consensus protocol, and uses incremental storage to generate snapshot blocks. 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, the state is said to be confirmed. The depth of the snapshot block that first snapshots the state is called the confirmation number. With each block added to the snapshot chain, 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. The leader selection process of the consensus method 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 the authorized node. Step S3: After the authorized node is selected, the timer is started and a time period is set. During this time period, the node is responsible for collecting task scheduling events and task execution events, packaging the event summaries into blocks, and uploading the consensus to the blockchain. The time period is specifically set to include: Divide the continuous time into several consecutive time periods, the start and end of which 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. During this period, it is responsible for collecting task scheduling events and task execution events. 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 own 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 each working node's status chain, 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; Step S4: At the end of the time period, the authorization node collects the fund balances of each scheduling node and the hardware resource usage of each node in the current time period. The authorization node calculates the fund amount of each node after the fund allocation, and then makes the scheduling node with the most funds become the authorized node for the next time period, and deducts the corresponding funds of this node. The funding amount of each scheduling node after the election is then 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.

2. The consensus method of a decentralized scheduling system based on dynamic election according to claim 1, characterized in that: The working node maintains a heartbeat with a scheduling node that manages the working node, accepts task scheduling from the scheduling node, executes tasks, and returns results to the scheduling node; The scheduling node and the working nodes have a one-to-many management relationship. By calculating the complexity of the task and the resources of the working nodes it manages, the task is reasonably scheduled to the working nodes for execution. The plurality of node status chains record the change information of the state change caused by the corresponding events generated at each node at all times; The snapshot chain is based on the tamper-proof characteristics of the blockchain and uses a consensus method to take a snapshot of the current state of the global node and record it on the snapshot chain.

3. The consensus method of a decentralized scheduling system based on dynamic election according to claim 1, characterized in that: Each node state chain block structure includes a block header and a block body, wherein the block header includes the node ID, timestamp, block height, target hash, root hash and block size data, and the block body includes the task event; the snapshot chain block structure includes a block header and a block body, wherein the block header includes the authorized node ID, period number, timestamp, target hash and root hash of the state data, and the block body includes the latest state data of each node that has undergone status update collected when the authorized node is about to package the snapshot block.

4. The consensus method of a decentralized scheduling system based on dynamic election according to claim 1, 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 during this round of period. The authorization node calculates the collected hardware resource usage and obtains the fund allocation amount that each scheduling node should receive and the amount of funds allocated to each node after allocation. The fund allocation ratio is calculated as follows: ； 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 scheduling node needs to deduct 1 more funds than the second-ranked candidate node; The amount of funds after the election of each scheduling node is updated to each scheduling node.

5. The consensus method of a decentralized scheduling system based on dynamic election according to claim 1, characterized in that: The fault judgment mechanism is specifically as follows: Whenever the authorization node receives a status block from another scheduling node, it must return a "confirmation" to the scheduling node; The scheduling node detects whether the authorization node has failed by returning "confirmation"; If a scheduling node times out while waiting for "confirmation," it means the returned "confirmation" message may be lost, or the authorization node may be disconnected. At this point, the scheduling node is required to resend the event summary. If it times out three times, the scheduling node concludes that "the authorization node is disconnected." 6. The consensus method of a decentralized scheduling system based on dynamic election according to claim 1, characterized in that: 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: Scheduling node a broadcasts "a has lost contact with X" to other scheduling nodes. Upon receiving the broadcast, scheduling node b responds to scheduling node a with a message "b can connect to X" if it can connect to authorized node X. Otherwise, it responds with a message "b has lost contact with X." Upon receiving the broadcast from scheduling node a, scheduling node b locally records "a has lost contact with X," treating this as a vote of disapproval of authorized node X. If scheduling node b's local record shows that more than half of the scheduling nodes have opposed authorized node X during the current period, scheduling node b proactively notifies other scheduling nodes to abandon X, initiating a no-owner election. After sending a broadcast, scheduling node a waits for a while. Based on the received reply information, if no more than half of the scheduling nodes in the network have lost contact with the authorized node X, 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 no-owner 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.

7. The consensus method of a decentralized scheduling system based on dynamic election according to claim 6, characterized in that: The fault handling mechanism also includes: When the scheduling node receives the "confirmation" from the authorization node, it returns the "confirmation" to the working node. If the working node does not receive the "confirmation" or times out, it resends the status block. If it times out three times, it checks the heartbeat between itself and the scheduling node to see if the scheduling node is faulty and whether a replacement scheduling node needs to be found. After finding a new scheduling node, it resends the corresponding status block for which it did not receive the "confirmation" before. After three timeouts between scheduling node a and authorized node X, a still needs to initiate a heartbeat check with X at regular intervals. If the connection between a and X is restored, a needs to broadcast "a can connect to X" to other scheduling nodes and update the local records of each scheduling node.

Images