A consensus method for transferring voting rights of an offline node of a blockchain system

Abstract

The application relates to a consensus realization scheme when an offline node appears in a blockchain system, in particular to an implementation method of voting right transfer among good nodes when network conditions are unstable in the blockchain system. A set of voting right transfer mechanisms designed by the application can make other nodes trusted by honest nodes replace the nodes to exercise voting rights in the case that the honest nodes are temporarily offline, guarantee the safety of a consensus result in the sense of probability, and can determine the previous voting again when the honest nodes return to the network, so that the final safety of the consensus result is guaranteed.

Description

Technical Field

[0001] This invention relates to an implementation scheme for reaching consensus when offline nodes appear in a blockchain system, and more particularly to a method for transferring voting rights among benevolent nodes when network conditions are unstable in a blockchain system. Background Technology

[0002] As blockchain technology matures and develops, various upper-layer applications have brought enormous economic benefits. People are increasingly emphasizing the underlying blockchain system's ability to resist malicious attacks and stably achieve consensus. The essence of a blockchain system is a distributed system where computer nodes with certain computing resources collaborate through network communication, enabling all nodes in the system to reach consensus on specific key information. The difficulty of the blockchain consensus problem lies in the fact that some of these computer nodes are malicious. Malicious nodes may act contrary to the pre-defined consensus protocol, attempting to disrupt the overall system's consensus. Furthermore, the network conditions accessible to nodes in a blockchain system are often unstable for the frequent information reception and transmission needs, and they may also face attacks from adversaries. Therefore, the temporary offline status of honest nodes also needs to be considered in the design of the overall consensus protocol.

[0003] In previous blockchain consensus protocols, nodes that were temporarily offline were often categorized as malicious nodes because their outward behavior was identical to that of malicious nodes that intentionally failed to execute protocol strategies. This approach also simplified the overall analysis of the blockchain consensus protocol architecture. However, this analysis clearly overlooks the role that honest offline nodes can play in the consensus process. Moreover, these honest offline nodes are often temporarily offline due to network fluctuations, and they have a relatively high probability of returning to the blockchain system after a short period of time to continue executing subsequent steps according to the consensus protocol requirements.

[0004] The inventors discovered another type of method focusing on local chain architecture scenarios. This method groups the blockchain nodes in the overall blockchain into N groups, with each group forming a local chain. Within each local chain, at least one node is selected to participate in the global chain's consensus process. When all nodes in a local chain go offline, a pre-configured virtual consensus node replaces the node participating in the global consensus. The limitation of this type of method is its heavy reliance on the local chain's architectural design and the assumptions about the virtual consensus node model; the consensus algorithm lacks broader applicability. Furthermore, this type of algorithm does not consider the scenario where virtual consensus nodes also go offline, or the possibility of nodes briefly returning to the network after a short period of offline activity.

[0005] The technical problem to be solved by the present invention is to provide a consensus method for transferring voting rights of offline nodes in a blockchain system when network conditions are poor, in order to address the shortcomings of the existing technology. Summary of the Invention

[0006] This application designs a voting rights transfer mechanism to address the situation where honest nodes are temporarily offline. This mechanism allows other nodes trusted by the honest node to exercise voting rights on its behalf when the honest node is temporarily offline, thus ensuring the security of the consensus result in a probabilistic sense. When the honest node returns to the network, the voting situation can be reconfirmed, thereby ensuring the final security of the consensus result.

[0007] The technical solution provided in this application is: a consensus method for transferring voting rights of offline nodes in a blockchain system, characterized in that it includes the transfer of voting rights of offline nodes, wherein the transfer of voting rights of offline nodes includes the step of the offline node sending trust credentials to other nodes, the step specifically including: Step 101: Input node A and node B. Node A is the node that is ready to send the trust credential, and node B is the candidate node selected by node A to be observed. Step 102: Node A collects information sent by Node B in the network during a certain period of time while executing the consensus protocol; Step 103: Node A calculates the estimated time for executing each stage of the blockchain consensus protocol based on the information of the blockchain it maintains, which is then used to compare and verify the behavior of Node B. Step 104: Node A performs local comparison and verification based on the estimated time of each stage of the consensus protocol and the information collected from Node B in the network. Step 105: Determine whether node B meets the conditions for node A to issue trust credentials. The conditions are determined based on the voting rights held by node A. If the conditions are met, proceed to step 106; otherwise, proceed to step 107. Step 106: Node A sends a trust credential to Node B. The trust credential contains at least the public key of Node A, the public key of Node B, the latest timestamp, the time period during which Node A observed the information sent by Node B, and the signature of the data items contained in the trust credential by Node A using its private key. Step 107: Node A reselects the candidate node it wants to observe and uses that node as the new node B; Step 108: Node A has completed the process of sending trust credentials to an observed candidate node B.

[0008] The technical solution of this invention also includes steps for a benevolent leader node to propose blocks and tally votes, the steps of which specifically include: Step 201: Input the nodes in the blockchain system, which include online benevolent nodes, offline benevolent nodes, and malicious nodes; Step 202: Determine if the node is the leader node. If it is, proceed to step 203; otherwise, proceed to step 205. Step 203: The leader node selects the transactions with the earliest timestamps from the memory pool to be uploaded to the chain, verifies the validity of the transactions, and packages the transactions into blocks according to the requirements of the consensus protocol and cryptographic tools; Step 204: The leader node distributes the previously packaged proposal block to the online nodes in the blockchain system; Step 205: Online nodes continue to broadcast the proposal block using the underlying gossip protocol, so that more online nodes can receive the proposal block and compare the proposal block information to determine whether the leader node has sent different proposal blocks to different nodes. Step 206: Online nodes in the blockchain system combine information from the network and their own verification of transaction information within the blocks to vote on the proposed blocks; Step 207: Determine whether the proposed block has passed the local verification of the node. If yes, proceed to step 208; otherwise, proceed to step 209. Step 208: The online node votes in favor of the proposed block. If the node has trust credentials sent by other nodes, the trust credentials information should be attached to the vote. Step 209: The online node opposes the proposed block by not voting. Step 210: The leader node collects voting information from other nodes in the network; Step 211: The leader node combines the voting and trust credential information. For the trust credential given by node A to node B, If node A's vote is in the received vote set, then node B does not inherit node A's voting rights. If node A's vote is not in the voting set, then node B inherits node A's voting rights according to the trust parameters agreed in the trust certificate, which range from 0 to 1. The leader node determines whether it has collected the required number of votes within a waiting time. If yes, it proceeds to step 212; otherwise, it proceeds to step 202. Step 212: The leader node will officially put the proposed block on the chain, and other nodes will synchronize their on-chain status. Step 213: End, output the block on the chain.

[0009] The technical solution of this invention also includes a step of re-election when the leader node is offline or malicious, specifically including: Step 301: Begin, input as a node in the blockchain system; Step 302: When the re-election process begins, the old leader node has been detected as offline or has sent different candidate blocks to different nodes, and the nodes begin to broadcast information to start a new round of election. Step 303: Use the blocks from the previous set interval as the random number seed to run a random election program to determine the candidate leader node; Step 304: All nodes send information about the longest blockchain they maintain to the candidate leader node, and synchronize the blockchain with the candidate leader node. Step 305: The candidate leader node synchronizes all block information it has received that conforms to the consensus protocol requirements with all other nodes; Step 306: The node determines the behavior of the candidate leader node to see if it is an online good person node. If it is, proceed to step 307; otherwise, proceed to step 302. Step 307: End, obtain the leader node.

[0010] As a preferred option, the leader node obtained in step 307 only represents that the node was online and operating in accordance with the requirements of the consensus protocol during the process from nomination as a candidate leader node to the synchronization of blocks; if it is found that the node went offline or deliberately acted maliciously due to network fluctuations in the subsequent process, the leader node election process will be triggered again until a new leader node is elected as an online good person node.

[0011] The technical solutions provided in this application embodiment have at least the following technical effects or advantages: This invention provides a method for ensuring the stability of a consensus protocol by allowing offline benevolent nodes to transfer voting rights when network conditions are poor. When a node is online, it observes the behavior of other nodes. If a verification condition is met, it sends a trust credential. When that node goes offline, the node that receives the trust credential inherits its voting rights. This allows the leader node to quickly collect enough votes, improving the stability of the blockchain system's output blocks. Simultaneously, this scheme allows more benevolent nodes to temporarily go offline, enhancing the blockchain consensus protocol's ability to resist security risks.

[0012] This invention, as a supplementary protocol, can assist in the construction of various blockchain consensus protocols and has broad application prospects. Attached Figure Description

[0013] Figure 1This is a schematic diagram illustrating the process of a node sending trust credentials to other nodes in an embodiment.

[0014] Figure 2 This is a schematic diagram illustrating the process of reaching consensus on the proposed block when the leader node is a benevolent node, as shown in the example.

[0015] Figure 3 This is a schematic diagram illustrating the process of re-determining the leader node when the leader node is a malicious node or offline, as shown in the embodiment. Detailed Implementation

[0016] In synchronous network models, it's assumed that the upper limit of communication latency between two nodes in a blockchain is a fixed constant Δ, and this constant is known to all nodes in the blockchain system. However, due to the instability of network conditions in the real world or network attacks launched by adversaries, benevolent nodes often go offline temporarily. When a benevolent node is offline, the communication latency with it will exceed the upper limit Δ assumed by the model. A key step in reaching consensus in a blockchain system is collecting enough node votes. When benevolent nodes go offline, causing the collected votes to fall below a threshold, the consensus protocol of the entire blockchain system can only wait for a longer period, hoping to collect enough votes.

[0017] The technical solution in this embodiment is to address the issue of transferring voting rights of offline nodes in a blockchain system when network conditions are poor. This solution enables the entire blockchain system to still reach a stable consensus even when some beneficiary nodes are offline, thereby improving the stability and security of the blockchain system.

[0018] The technical solution of this embodiment includes three basic procedures: First, this scheme involves a procedure for nodes to send trust credentials to other nodes. In the blockchain system, nodes continuously collect information sent by a specific group of nodes in the network. After verification and review mechanisms, trust credentials are sent to nodes with higher trust levels. Nodes observe messages sent by other nodes in the network over time to infer whether a node is benign or malicious, making a probabilistic inference. A node then sends a trust credential to the node it trusts. This trust credential includes the sending node's public key, the receiving node's public key, the sending node's trust assessment of the receiving node, a timestamp, and the sending node's signature using its private key. During the subsequent consensus protocol execution, when a benign node temporarily goes offline, the node receiving the trust credential can temporarily inherit the voting rights of the offline node, thus fulfilling its voting responsibilities and completing the tasks stipulated in the consensus protocol, ensuring its stable operation.

[0019] Second, the scheme involves a basic process of a consensus protocol. When the leader node is a benevolent node, it will package the transactions to be added to the chain in the mempool into a proposal block according to the requirements of the consensus protocol. After several stages of voting process, the block is finally added to the chain. Third, the scheme involves a process of re-election of leader nodes. When a leader node is found to be sending different proposed blocks to different nodes, or when a leader node is offline, the entire blockchain system will conduct an election process to elect a new leader node to complete the task of proposing blocks.

[0020] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0021] In the method provided by this invention, nodes periodically send trust credentials to surrounding nodes with high trust levels. When a node is temporarily offline due to network fluctuations, other nodes can vote on its behalf, thereby improving the overall ability of the blockchain system to cope with uncertainties in real-world conditions.

[0022] Figure 1 The diagram illustrates a flowchart of a node sending trust credentials to other nodes. Nodes in the network continuously run this process, collecting and analyzing information sent by nodes they are monitoring. They periodically send more timely trust credentials to nodes they deem to have a higher level of trust. The leader node also assigns higher weight to timestamped trust credentials during vote counting. The process of a node sending trust credentials to other nodes can be summarized in the following steps: Step 101: Input node A and node B. Node A is the node that is ready to send the trust credential, and node B is the candidate node selected by node A to be observed. Step 102: Node A collects information sent by Node B in the network during a certain period of time while executing the consensus protocol; Step 103: Node A calculates the estimated time for executing each stage of the blockchain consensus protocol based on the information of the blockchain it maintains, which is then used to compare and verify the behavior of Node B. Step 104: Node A performs local comparison and verification based on the estimated time of each stage of the consensus protocol and the information collected from Node B in the network. Step 105: Determine whether node B meets the threshold for node A to issue trust credentials. If it does, proceed to step 106; otherwise, proceed to step 107. Step 106: Node A sends a trust credential to Node B. The trust credential contains at least the public key of Node A, the public key of Node B, the latest timestamp, the time period during which Node A observed the information sent by Node B, and the signature of the data items contained in the trust credential by Node A using its private key. Step 107: Node A reselects the candidate node it wants to observe and uses that node as the new node B; Step 108: Node A has completed the process of sending trust credentials to an observed candidate node B.

[0023] Figure 2 The diagram illustrates the normal operation of the consensus protocol. When the leader node is a benevolent node and online, it proposes a block and distributes it to other online nodes for voting. If enough votes are collected, the block is allowed to be added to the blockchain. The leader node uses trust credentials to calculate the weight of each vote. The consensus protocol operation when the leader node is an online benevolent node is as follows: Step 201: Input the nodes in the blockchain system. The nodes in the blockchain system may include online benevolent nodes, offline benevolent nodes, and malicious nodes. Step 202: Determine if the node is the leader node. If it is, proceed to step 203; otherwise, proceed to step 205. Step 203: The leader node selects transactions to be added to the chain from the memory pool before the timestamp, verifies the validity of the transactions, and packages the transactions into blocks according to the requirements of the consensus protocol and cryptographic tools; Step 204: The leader node distributes the previously packaged proposal block to the nodes in the blockchain system; Step 205: Online nodes continue to broadcast the proposal block using the underlying gossip protocol, so that as many online nodes as possible can receive the proposal block. This also makes it easier for other online nodes to compare the proposal block information and determine whether the leader node has sent different proposal blocks to different online nodes. Step 206: Online nodes in the blockchain system combine information from the network and their own verification of transaction information within the blocks to vote on the proposed blocks; Step 207: Determine whether the proposed block has passed the local verification of the node. If yes, proceed to step 208; otherwise, proceed to step 209. Step 208: Online nodes vote in favor of the proposed block. If the node has trust credentials sent by other nodes, the trust credentials information should be attached to the vote. Step 209: Online nodes oppose the proposed block by not voting.

[0024] Step 210: The leader node collects voting information from other online nodes in the network; Step 211: The leader node combines the voting and trust credential information. Regarding the trust credential from node A to node B, if node A's vote is in the received vote set, then node B does not inherit node A's voting rights; if node A's vote is not in the vote set, then node B inherits node A's voting rights according to the trust parameter (a value between 0 and 1) agreed upon in the trust credential. The leader node needs to determine whether enough affirmative votes have been collected within a waiting time. If yes, proceed to step 212; otherwise, proceed to step 202. Step 212: The leader node will officially put the proposed block on the chain, and other online nodes will synchronize the on-chain status. Step 213: End, output the block on the chain.

[0025] When the leader node is found to be offline or sending different candidate blocks to different nodes, other nodes will initiate a process to re-elect the leader node. The basic process includes the following steps: Step 301: Begin, input as a node in the blockchain system; Step 302: When the re-election process begins, the old leader node has been detected as offline or has sent different candidate blocks to different nodes, and the nodes begin to broadcast information to start a new round of election. Step 303: Use blocks from a certain time interval ago as random number seeds to run a random election program to determine candidate leader nodes; Step 304: All nodes send information about the longest blockchain they maintain to the candidate leader node, and synchronize the blockchain with the candidate leader node. Step 305: The candidate leader node synchronizes all block information it has received that conforms to the consensus protocol requirements with all other nodes; Step 306: The node determines the behavior of the candidate leader node to see if it is an online good person node. If it is, then proceed to step 307; otherwise, proceed to step 302. Step 307: End, obtain the leader node.

[0026] The leader node obtained through the above steps only indicates that the node was online and operating in accordance with the consensus protocol requirements during the process from nomination as a candidate leader node to block synchronization. If the node is found to be offline or deliberately malicious due to network fluctuations in the subsequent process, the leader node election process will be triggered again until a new leader node is elected as an online good person node.

[0027] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements can be made without departing from the principle of the present invention, and these improvements should also be considered within the scope of protection of the present invention.

Claims

1. A consensus method for transferring voting rights of offline nodes in a blockchain system, characterized in that, This includes the transfer of voting rights for offline nodes, which involves the offline node sending trust credentials to other nodes. The steps specifically include: Step 101: Input node A and node B. Node A is the node that is ready to send the trust credential, and node B is the candidate node selected by node A to be observed. Step 102: Node A collects the information sent by Node B in the network during a certain period of time when executing the consensus protocol; Step 103: Node A calculates the estimated time for executing each stage of the blockchain consensus protocol based on the information of the blockchain it maintains, which is then used to compare and verify the behavior of Node B. Step 104: Node A performs local comparison and verification based on the estimated time of each stage of the consensus protocol and the information collected from Node B in the network. Step 105: Determine whether node B meets the conditions for node A to issue trust credentials. The conditions are determined based on the voting rights held by node A. If the conditions are met, proceed to step 106; otherwise, proceed to step 107. Step 106: Node A sends a trust credential to Node B. The trust credential contains at least the public key of Node A, the public key of Node B, the latest timestamp, the time period during which Node A observed the information sent by Node B, and the signature of the data items contained in the trust credential by Node A using its private key. Step 107: Node A reselects the candidate node it wants to observe and uses that node as the new node B; Step 108: Node A has completed the process of sending trust credentials to an observed candidate node B; It also includes the steps of good leader nodes proposing blocks and counting votes, which specifically include: Step 201: Input the nodes in the blockchain system, which include online benevolent nodes, offline benevolent nodes, and malicious nodes; Step 202: Determine if the node is the leader node. If it is, proceed to step 203; otherwise, proceed to step 205. Step 203: The leader node selects the transactions with the earliest timestamps from the memory pool to be uploaded to the chain, verifies the validity of the transactions, and packages the transactions into blocks according to the requirements of the consensus protocol and cryptographic tools; Step 204: The leader node distributes the previously packaged proposal block to the online nodes in the blockchain system; Step 205: Online nodes continue to broadcast the proposal block using the underlying gossip protocol, so that more online nodes can receive the proposal block and compare the proposal block information to determine whether the leader node has sent different proposal blocks to different nodes. Step 206: Online nodes in the blockchain system combine information from the network and their own verification of transaction information within the blocks to vote on the proposed blocks; Step 207: Determine whether the proposed block has passed the local verification of the node. If yes, proceed to step 208; otherwise, proceed to step 209. Step 208: The online node votes in favor of the proposed block. If the node has trust credentials sent by other nodes, the trust credentials information should be attached to the vote. Step 209: The online node opposes the proposed block by not voting. Step 210: The leader node collects voting information from other nodes in the network; Step 211: The leader node combines the voting and trust credential information. For the trust credential given by node A to node B, If node A's vote is in the received vote set, then node B does not inherit node A's voting rights. If node A's vote is not in the voting set, then node B inherits node A's voting rights according to the trust parameters agreed in the trust certificate, which range from 0 to 1. The leader node determines whether it has collected the required number of votes within a waiting time. If yes, it proceeds to step 212; otherwise, it proceeds to step 202. Step 212: The leader node will officially put the proposed block on the chain, and other nodes will synchronize their on-chain status. Step 213: End, output the block on the chain.

2. The consensus method for transferring voting rights of offline nodes in a blockchain system according to claim 1, characterized in that, It also includes steps for re-election when the leader node is offline or malicious. Specific steps include: Step 301: Begin, input as a node in the blockchain system; Step 302: When the re-election process begins, the old leader node has been detected as offline or has sent different candidate blocks to different nodes, and the nodes begin to broadcast information to start a new round of election. Step 303: Use the blocks from the previous set interval as the random number seed to run a random election program to determine the candidate leader node; Step 304: All nodes send information about the longest blockchain they maintain to the candidate leader node, and synchronize the blockchain with the candidate leader node. Step 305: The candidate leader node synchronizes all block information it has received that conforms to the consensus protocol requirements with all other nodes; Step 306: The node determines the behavior of the candidate leader node to see if it is an online good person node. If it is, proceed to step 307; otherwise, proceed to step 302. Step 307: End, obtain the leader node.

3. The consensus method for transferring voting rights of offline nodes in a blockchain system according to claim 2, characterized in that, The leader node obtained in step 307 only represents that the node was online and operating in accordance with the requirements of the consensus protocol during the process from nomination as a candidate leader node to synchronization of blocks; If the node is found to go offline or act maliciously due to network fluctuations during the subsequent process, the leader node election process will be triggered again until a new leader node is elected as an online good node.

Images