A distributed node consensus method and system based on hybrid communication model

Abstract

The present application provides a distributed node consensus method and system based on a hybrid communication model, the method comprising: a proposal node in the hybrid communication model generates corresponding block data according to a received transaction request, wherein the hybrid communication model comprises at least a number of communication nodes arranged in a closed loop, the communication nodes comprising a proposal node; the proposal node generates corresponding notification consensus information and sends it to communication nodes whose number of sequential delays is the number of tolerable error nodes plus one; after the communication node verifies any of the received notification consensus information, it enters a notified state and continues to send it to communication nodes whose number of sequential delays is the number of tolerable error nodes plus one; when the proposal node receives the notification consensus information and completes the verification, it enters a notified state. Therefore, the method described in the present application can effectively improve the consensus efficiency of communication nodes in a distributed system.

Description

Technical Field

[0001] The present application relates to the field of blockchain transactions, and in particular to a distributed node consensus method and system based on a hybrid communication model. Background Art

[0002] The expansion of distributed systems places higher demands on the performance and fault tolerance of consensus protocols. While traditional Byzantine fault-tolerant algorithms can achieve multi-node consistency, their communication complexity grows quadratically with the node size, resulting in severe network redundancy and limited scalability. Furthermore, their reliance on a fully connected topology makes them difficult to adapt to dynamic environments. Furthermore, when overlaid with security mechanisms, their strict consistency can easily lead to additional delays, resulting in an imbalance between security and efficiency.

[0003] In existing solutions, technicians often improve their performance by optimizing topology or processes, but there are many flaws: solutions that improve topology are mostly limited to a single structure (such as ring or tree) and lack dynamic adaptability; solutions that streamline interaction rounds sacrifice fault tolerance or introduce centralization risks; at the same time, in some network scenarios (for example, application scenarios with high real-time requirements but allowing temporary inconsistencies), it is impossible to improve the consensus efficiency of communication nodes in distributed systems while ensuring reliability.

[0004] Therefore, the implementation of existing technologies still has the problem of low consensus efficiency of communication nodes. Summary of the Invention

[0005] Based on this, the purpose of this application is to provide a distributed node consensus method and system based on a hybrid communication model, which can effectively improve the consensus efficiency of communication nodes in a distributed system.

[0006] The purpose of this application can be achieved through the following technical solutions:

[0007] A distributed node consensus method based on a hybrid communication model, comprising the following steps: in response to a received transaction request, a proposal node in the hybrid communication model generates corresponding block data, wherein the hybrid communication model includes at least a number of communication nodes arranged in a closed loop; each communication node is connected to an adjacent communication node, and the communication node includes a proposal node; the proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the hybrid communication model whose sequential delay is the number of tolerable error nodes plus one, wherein the error nodes include Byzantine nodes and crash nodes; after the communication node verifies any of the received notification consensus information, it enters a notified state and sends the corresponding notification consensus information to the communication nodes in the hybrid communication model whose sequential delay is the number of tolerable error nodes plus one; when the proposal node receives the notification consensus information and completes the verification of any of the received notification consensus information, it enters a notified state to complete the first node consensus.

[0008] A distributed node consensus system based on a hybrid communication model, characterized in that: the distributed node consensus system includes a plurality of communication nodes, the communication nodes are arranged in a closed loop and each communication node is connected to an adjacent communication node; the communication nodes include proposal nodes;

[0009] After receiving the transaction request, the proposal node generates the corresponding block data; the proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the distributed node consensus system whose number of sequential delays is the tolerable number of error nodes plus one, wherein the error nodes include Byzantine nodes and crashed nodes; after verifying any of the received notification consensus information, the communication node enters the notified state, and sends the corresponding notification consensus information to the communication nodes in the distributed node consensus system whose number of sequential delays is the tolerable number of error nodes plus one; when the proposal node receives the notification consensus information and completes the verification of any of the received notification consensus information, it enters the notified state and completes the first node consensus.

[0010] Compared with the prior art, the method described in this application adopts a ring topology structure, in which the proposal node sends the consensus information to the subsequent sequentially delayed node group (the number is the number of tolerable error nodes plus one), and at the same time limits the number of nodes that receive the consensus information (the number of tolerable error nodes plus one). After the communication node and the proposal node complete local verification, they simultaneously enter the informed state and trigger relay information forwarding to complete and form dynamic consensus advancement. Therefore, by applying the method described in this application, the redundant paths of the broadcast mode of the full connection or star topology are reduced, the communication complexity is reduced, thereby alleviating the message flooding pressure in large-scale node scenarios, improving the scalability of the distributed system, and, under the premise of ensuring Byzantine fault tolerance, avoiding the delay problem caused by strict consistency requirements, combined with the dynamic adjustment of the number of tolerable error nodes, reducing the performance loss caused by excessive pursuit of consistency, and optimizing the overall throughput of the distributed system, thereby effectively improving the consensus efficiency of the communication nodes in the distributed system.

[0011] For better understanding and implementation, the present application is described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A flowchart of a distributed node consensus method based on a hybrid communication model provided by this application;

[0013] Figure 2 Schematic diagram of the hybrid communication model provided for this application;

[0014] Figure 3 Schematic diagram of the two-stage consensus process provided for this application;

[0015] Figure 4 A flowchart of the steps for rotating proposal nodes in a distributed node consensus method based on a hybrid communication model provided by this application;

[0016] Figure 5 A graph showing the performance comparison of a distributed node consensus method based on a hybrid communication model provided in this application and a Byzantine fault-tolerant consensus method in the prior art.

[0017] Figure 6 This is a test result chart showing a performance comparison test between a distributed node consensus method based on a hybrid communication model provided by this application and a Byzantine fault-tolerant consensus method in the prior art after introducing a 5±0.5 millisecond network delay;

[0018] Figure 7 This figure shows the test results of a performance comparison test between a distributed node consensus method based on a hybrid communication model provided in this application and a Byzantine fault-tolerant consensus method in the prior art after introducing a 10±1 millisecond network delay. DETAILED DESCRIPTION

[0019] This application provides a distributed node consensus method and system based on a hybrid communication model. To make the purpose, technical solutions, and effects of this application clearer and more explicit, the application is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0020] It will be understood by those skilled in the art that, unless expressly stated otherwise, the singular forms "a", "an", "said" and "the" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. In addition, "connected" or "coupled" as used herein may include wireless connections or wireless couplings. The term "and / or" used herein includes all or any units and all combinations of one or more associated listed items.

[0021] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with their meanings in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0022] The invention will be further explained below through description of embodiments in conjunction with the accompanying drawings.

[0023] Example 1

[0024] Please refer to Figure 1 and Figure 2 , Figure 1 This is a flowchart of a distributed node consensus method based on a hybrid communication model provided by this application. Figure 2 This is a schematic diagram of the hybrid communication model provided by this application. The method includes the following steps:

[0025] S10. In response to the received transaction request, the proposal node in the hybrid communication model generates corresponding block data;

[0026] S20. The proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the hybrid communication model whose number of sequential delays is the number of tolerable error nodes plus one;

[0027] S30, after verifying any of the received notification consensus information, the communication node enters the notified state, and sends the corresponding notification consensus information to the communication nodes in the hybrid communication model whose sequence delay is the number of tolerable error nodes plus one;

[0028] S40. When the proposal node receives the notification consensus information and completes the verification of any notification consensus information received, it enters the notified state and completes the first node consensus.

[0029] Compared with the existing technology, this application optimizes the communication efficiency in Byzantine fault-tolerant scenarios, the consensus efficiency of communication nodes in distributed systems, and the scalability of the system by combining a hybrid communication model with a dynamic consensus process. Specifically: First, this application adopts a closed loop-arranged communication node structure, and the proposal node will send the consensus information to the subsequent sequentially delayed node group (the number is the number of tolerable error nodes plus one). Compared with the fully connected or star-topology broadcast mode in traditional technologies, it effectively reduces redundant communication paths and message transmission times, solves the problems of limited network load and scalability, and at the same time, based on the loop structure and directional forwarding mechanism, it significantly reduces the complexity of network communication and alleviates the message flooding pressure in large-scale node scenarios; secondly, in the process of applying the hybrid communication model, this application avoids strict requirements on Byzantine fault tolerance by limiting the number of nodes that receive the consensus information (the number of tolerable error nodes plus one). The excessive reliance on grid consistency requirements solves the problem of additional delays caused by the superposition of security mechanisms such as node access verification. At the same time, through the dynamic adaptation of the number of tolerable error nodes, while maintaining the Byzantine fault tolerance, it reduces the performance loss caused by strict consistency and optimizes the system throughput. Finally, in this application, the communication node and the proposal node synchronously enter the informed state after completing local verification, and trigger the relay information forwarding between multi-level nodes to form a dynamic consensus promotion mechanism, which overcomes the technical defects of frequent view switching and stagnant consensus progress in traditional technical solutions. In addition, the multi-level node relay forwarding mechanism supports dynamic adjustment of the topology structure and is also applicable to asynchronous network environments, solving the scalability bottleneck problem caused by topology solidification in traditional technical solutions. Therefore, the technical solution of this application overcomes the technical defects of communication redundancy, limited scalability and insufficient dynamic adaptability in the existing technology under the premise of ensuring the consistency and security of the distributed system, and effectively improves the consensus efficiency of communication nodes in the distributed system.

[0030] For step S10, in response to the received transaction request, the proposal node in the hybrid communication model generates corresponding block data.

[0031] Among them, please refer to Figure 2 The hybrid communication model includes at least a number of communication nodes arranged in a closed loop; each of the communication nodes is connected to an adjacent communication node, and the communication nodes include proposal nodes.

[0032] In one embodiment, the hybrid communication model may be a directed graph topology or an undirected graph topology.

[0033] In one embodiment, in response to a received transaction request, the step of generating corresponding block data by a proposal node in the hybrid communication model includes:

[0034] S101. In response to a received transaction request, the proposal node verifies whether a generation timestamp of the transaction request, an identifier of the sender of the transaction request, and a signature of the sender of the transaction request are legal.

[0035] In one embodiment, the proposal node may pre-store the generation timestamp of the legal transaction request, the sender identifier of the transaction request, and the sender signature of the transaction request, and then match them one by one when receiving the corresponding transaction request. If they are consistent, it is determined to be legal.

[0036] In one embodiment, the client of the consortium blockchain sends a transaction request to the proposal node, wherein the format may be transaction request <transaction content, timestamp, client identity, client signature>, wherein the transaction content includes specific transaction data or operation content (for example, in the consortium blockchain, the transaction data may include the addresses of the sender and receiver, the amount, the transaction fee, etc.); the timestamp is the timestamp of the transaction request (that is, the timestamp of the generation of the transaction request); the client identity is the unique identifier of the client (that is, the sender identifier); and the client signature is the client digital signature of the transaction request (that is, the sender signature of the transaction request).

[0037] In this embodiment, the proposal node verifies whether the generation timestamp of the transaction request is legal to ensure the order of the transaction request and prevent replay attacks; the proposal node verifies whether the sender identifier of the transaction request is legal to identify the source of the transaction request; the proposal node verifies whether the sender signature of the transaction request is legal to verify the integrity of the transaction request and the legitimacy of the source of the transaction request, thereby preventing the transaction request from being tampered with.

[0038] S102. After the proposal node receives a preset number of legal transaction requests, the proposal node packages all legal transaction requests into a block, and generates the block height information, the block hash value, the block generation timestamp and the block proposal node signature to obtain block data.

[0039] In one embodiment, the proposal node verifies that it has received the transaction request, collects legal transaction requests, and generates block data (batch requests) in batches, wherein the format may be block data <height, hash value, previous block hash value, block timestamp, transaction content package, proposal node signature>, wherein the height is the height information of the block, the hash value is the hash value of the block, the previous block hash value is the hash value of the previous block (optional for non-blockchain systems), the block timestamp is the generation timestamp of the block, the transaction content package includes several specific transaction data or operation contents, and the proposal node signature is the node signature of the proposal node on the content in the block.

[0040] In this embodiment, the height information of the first block generated by the proposal node is 1, the height information of the second block generated is 2, and so on; the hash value of the block is a unique fixed-length string generated by encrypting the content of the block (including transaction data, timestamp, hash value of the previous block, etc.) through a hash function. Those skilled in the art can obtain the hash value of the block by calculating through various existing technologies.

[0041] For step S20, the proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the hybrid communication model whose number of sequential delays is the tolerable number of error nodes plus one.

[0042] The faulty nodes include Byzantine nodes and crashed nodes. Byzantine nodes are malicious or intentionally malicious communication nodes in a distributed system. Generally speaking, their behavior does not comply with the distributed system's system protocol, with the intention of disrupting consensus or misleading other communication nodes. Crashed nodes are communication nodes that stop responding due to non-malicious reasons (such as hardware failure, software crash, or network interruption). The consensus notification information includes at least block data and the signature of the sending node.

[0043] In one embodiment, the step of generating the consensus information according to the block data by the proposal node includes:

[0044] S201. The proposal node sends a node signature to the block data to generate corresponding notification consensus information.

[0045] In one embodiment, the proposal node stores a node number list, which includes the name information of all the communication nodes arranged in the closed loop order in the hybrid communication model; in this embodiment, the proposal node sends the notification consensus information to its subsequent f+1 communication nodes according to the node number list, wherein the format may be the notification consensus information <view identifier, node signature, block data>, f is the tolerable number of error nodes, the view identifier is the view identifier of the communication node, and the node signature is the signature of the information sending node (proposal node) to the sending node of the message (i.e., the notification consensus information).

[0046] In one embodiment, those skilled in the art may arbitrarily set and modify the tolerable number of error nodes according to actual conditions to meet the system requirements of the distributed system to which the distributed node consensus method is applied. For example, in a distributed system with high multi-node consistency requirements, the tolerable number of error nodes may be 0.

[0047] In one embodiment, the tolerable number of error nodes is 2.

[0048] In step S30, after verifying any of the received notification consensus information, the communication node enters the notified state and sends the corresponding notification consensus information to the communication nodes in the hybrid communication model whose sequence delay is the number of tolerable error nodes plus one;

[0049] Wherein, each of the communication nodes stores a communication node list including the names of all communication nodes; the communication node names are the names of the communication nodes in the hybrid communication model.

[0050] In one embodiment, the step of the communication node verifying any received consensus information includes:

[0051] S301. In response to the received notification consensus information, the communication node verifies whether the sending node signature in the notification consensus information matches the communication node name in the communication node list.

[0052] In one embodiment, the communication node list also includes view identifiers of all the communication nodes; the communication node also verifies whether the view identifier in the notification consensus information matches the view identifier of the communication node in the communication node list.

[0053] S302. The communication node verifies whether the signature of the proposal node in the block data that notifies the consensus information matches the signature of the proposal node.

[0054] In one embodiment, those skilled in the art may preset a communication node as a starting proposal node in the hybrid communication model, and the starting proposal node is known to the remaining communication nodes.

[0055] S303. The communication node verifies whether the height information in the block data notifying the consensus information is the height information of the verified block plus one.

[0056] In one embodiment, the consortium blockchain system also verifies whether the hash value of the previous block is consistent with the local storage.

[0057] S304. The communication node verifies whether the generation timestamp in the block data notifying the consensus information is greater than the generation timestamp of the verified block.

[0058] S305. If the verification results are all yes, the communication node replaces the sending node signature in the consensus information with its own node signature.

[0059] In one embodiment, when the communication node executes the steps S301-304, it will obtain a verification result respectively. If the verification results obtained are all yes, the communication node determines that the consensus information is legal and replaces the sending node signature in the consensus information with its own node signature.

[0060] In one embodiment, those skilled in the art may arbitrarily replace or change the order of steps S302-S304 to continue implementing the distributed node consensus method described in this application.

[0061] Please also refer to Figure 2 In one embodiment, since the communication nodes send the corresponding notification consensus information to the communication nodes in the hybrid communication model whose sequential delay is the number of tolerable error nodes plus one, each of the communication nodes may repeatedly receive the notification consensus information with the same height information. For example, the third communication node simultaneously receives the notification consensus information sent by the first communication node and the second communication node respectively; and since each of the communication nodes may have different communication delays, each of the communication nodes may repeatedly receive the notification consensus information with the same height information after an interval of several time units. For example, after the third communication node receives the notification consensus information sent by the first communication node, it receives the notification consensus information sent by the second communication node after an interval of 5 seconds.

[0062] In this embodiment, the communication node also stores a node number list, which includes the name information of all the communication nodes arranged in the closed loop order in the hybrid communication model; when the communication node verifies any of the received notification consensus information (it is not necessary to perform and complete verification on all the notification consensus information that needs to be received), it enters the notified state, and at the same time replaces the sending node signature in the notification consensus information with its own node signature, and continues to send the notification consensus information to its subsequent f+1 communication nodes according to the node number list, where f is the tolerable number of error nodes.

[0063] In one embodiment, the communication node verifies any of the earliest received notification consensus information and enters the notified state, while replacing the sending node signature in the notification consensus information with its own node signature, and continues to send the notification consensus information to its subsequent f+1 communication nodes according to the node number list; the communication node only verifies the notification consensus information with the same height information received from the remaining communication nodes.

[0064] Regarding step S40, when the proposal node receives the notification consensus information and completes the verification of any of the received notification consensus information, it enters the notified state and completes the first node consensus.

[0065] In one embodiment, since the communication nodes are arranged in a closed loop and each communication node is connected to the adjacent communication node, the consensus notification information will reach the proposal node again after being sent and received multiple times by the communication nodes, and it will be determined that the first node consensus has been completed.

[0066] In addition, this application also provides some distributed node consensus steps, which can be applied to the distributed node consensus method based on the hybrid communication model to achieve further node consensus between the communication nodes. Figure 3 , Figure 3 The schematic diagram of the two-stage consensus process provided in this application, after completing the first node consensus step (i.e., step S40), the steps include:

[0067] S50. The proposal node generates corresponding execution consensus information based on the block data, and sends the execution consensus information to the communication nodes in the hybrid communication model whose number of sequential delays is the tolerable number of error nodes plus one.

[0068] In one embodiment, after the proposal node receives the notification consensus information sent by the communication node, the proposal node performs the second round of node consensus information transmission; similarly, the proposal node sends the execution consensus information to the subsequent f+1 communication nodes according to the node number list, wherein the format may be execution consensus information <view identifier, node signature, block data>, wherein the view identifier is the view identifier of the communication node, and the node signature is the signature of the information sending node (proposal node) to the sending node of the sent message (i.e., execution consensus information).

[0069] S60. After the communication node that has entered the informed state verifies any of the received execution consensus information, it enters the execution state and sends the corresponding execution consensus information to the communication nodes in the hybrid communication model whose number of sequential delays is the tolerable number of error nodes plus one, thereby completing the second node consensus.

[0070] Please also refer to Figure 2 In one embodiment, since the communication nodes send the corresponding execution consensus information to the communication nodes in the hybrid communication model whose sequential delay is the number of tolerable error nodes plus one, each of the communication nodes may repeatedly receive the execution consensus information with the same height information. For example, the third communication node simultaneously receives the execution consensus information sent by the first communication node and the second communication node respectively; and since each of the communication nodes may have different communication delays, each of the communication nodes may repeatedly receive the execution consensus information with the same height information after an interval of several time units. For example, after receiving the execution consensus information sent by the first communication node, the third communication node receives the execution consensus information sent by the second communication node after an interval of 5 seconds.

[0071] In one embodiment, after receiving and verifying any execution consensus information, a communication node in the notified state (i.e., the communication node that has entered the notified state) will replace the node signature therein with its own node signature, and then continue to send the execution consensus information to the subsequent f+1 nodes. The execution consensus information with the same height information received thereafter from the remaining communication nodes will only be verified.

[0072] Therefore, in this embodiment, by applying the distributed node consensus method described in this application, the completion of node consensus between communication nodes does not need to be linked to the status of all the communication nodes, but depends on the flow of consensus information in the hybrid communication model. Technical personnel in this field do not need to pay attention to the specific status of each of the communication nodes, thereby effectively improving the consensus efficiency of communication nodes in the distributed system.

[0073] In one embodiment, those skilled in the art may refer to steps S301-304 to verify the execution consensus information.

[0074] In addition, this application also provides some distributed node consensus steps, which can be applied to the distributed node consensus method based on the hybrid communication model, so that the communication nodes can respectively execute specific transaction requests. Figure 3 After the communication node that has entered the informed state verifies any of the received execution consensus information and then enters the execution state, the steps include:

[0075] S601: After the communication node that has entered the execution state completes the verification of all the received execution consensus information, it executes the transaction request in the block data and returns the corresponding execution result to the sender of the transaction request.

[0076] In one embodiment, the communication node can complete the verification of all the execution consensus information received, and can also complete the verification of all the execution consensus information that needs to be received. For example, the third communication node may first receive the execution consensus information sent by the first communication node, and then receive the execution consensus information sent by the second communication node after an interval of several seconds. During the interval of several seconds, the execution consensus information sent by the first communication node is all the execution consensus information received by the third communication node, and the execution consensus information sent by the first communication node and the execution consensus information sent by the second communication node together constitute all the execution consensus information that the third communication node needs to receive.

[0077] In one embodiment, the communication node does not need to wait for the completion of verification of all the execution consensus information that needs to be received. Instead, after completing the verification of all the execution consensus information received, the communication node can execute the transaction request in the block data corresponding to the execution consensus information, thereby improving consensus efficiency.

[0078] In one embodiment, please refer to Figures 5 to 7 , which is a performance comparison test effect diagram of the distributed node consensus method and the Byzantine fault-tolerant consensus method described in this application. In the performance comparison test, throughput and average latency are used as measurement factors of the consensus efficiency of communication nodes in the distributed system. At the same time, communication delays of 5±0.05 milliseconds and 10±0.1 milliseconds are introduced as performance comparison test groups to eliminate interference from irrelevant items, thereby improving the credibility of the performance comparison test results.

[0079] In this embodiment, the throughput TPS can be calculated using the following formula:

[0080] ,

[0081] Among them, N tops It represents the total number of operations successfully processed per second by the corresponding method during the observation period, and T represents the total time of the observation.

[0082] The average latency is the average time required from sending the transaction request to receiving the corresponding response, which can be calculated using the following formula:

[0083] ,

[0084] Among them, t I represents the response time of the Ith transaction request (in seconds), and N represents the total number of transaction requests.

[0085] In this embodiment, as the number of communication nodes increases, compared to the Byzantine fault-tolerant consensus method in the prior art, regardless of whether communication delay is introduced, the throughput of the distributed system using the distributed node consensus method described in this application decreases more gradually, and the delay increases more slowly. Therefore, in the case of multiple communication nodes and high latency, the distributed system using the distributed node consensus method described in this application can have more stable and efficient performance, and also has stronger adaptability, which will be further enhanced in the case of high fault tolerance.

[0086] In addition, this application also provides some distributed node consensus steps, which can be applied to the distributed node consensus method based on the hybrid communication model, to handle abnormal situations in the block data, and further improve the consensus efficiency of the communication nodes in the distributed system. Figure 4 , Figure 4 This is a flowchart of the steps for rotating proposal nodes in a distributed node consensus method based on a hybrid communication model provided by this application, the steps including:

[0087] S701. When the communication node verifies the notification consensus information and / or the execution consensus information, if the block data in the notification consensus information and / or the execution consensus information is abnormal, the communication node unmarks the corresponding block data, and at the same time broadcasts the rotation information to the remaining communication nodes and enters the rotation state.

[0088] In one embodiment, the communication node broadcasts rotation information to the remaining communication nodes, wherein the format may be rotation information <first information, second information>, wherein the first information and the second information may be the notification consensus information and / or the execution consensus information.

[0089] S702: In response to the received rotation information, the corresponding communication node enters a rotation state.

[0090] S703. According to the current proposal node, a communication node that is one position later in the hybrid communication model replaces the current proposal node and becomes a new proposal node.

[0091] In one embodiment, when the communication node receives the rotation information and enters the rotation state, the communication node queries the node number list stored in itself. If it is the communication node that is one position behind the current proposal node in the hybrid communication model, it replaces the current proposal node with itself and becomes the new proposal node. For example, when the proposal node (first communication node) is untrustworthy (the block data in the notification consensus information and / or the execution consensus information is abnormal), the second communication node queries the node number list and finds that it is in the next position after the current proposal node in sequence, and then it replaces the first communication node with itself and becomes the new proposal node.

[0092] S704. The new proposing node broadcasts the rotation result information to the remaining communication nodes, wherein the rotation result information includes the node signature of the new proposing node.

[0093] S705. In response to the received rotation result information, the corresponding communication node verifies the rotation result information. If the node signature is legal, it returns the rotation consent information to the new proposal node and ends the rotation state.

[0094] In one embodiment, those skilled in the art may verify the legitimacy of the node signature in the rotation result information in a variety of ways based on actual conditions and in combination with existing technologies, for example, determining whether the node signature in the rotation result information is the node signature of the communication node in the hybrid communication model and / or whether it is the node signature of the communication node that is delayed by one position in the hybrid communication model, etc.

[0095] S706. When the new proposal node receives the agreed rotation information, the number of which is the total number of communication nodes minus the tolerable number of error nodes minus one, the new proposal node sends transaction request recipient change information to the sender of the transaction request.

[0096] In this embodiment, when the sender of the transaction request has not received the execution result of the corresponding transaction request, it will continue to send the corresponding transaction request to the new proposal node after receiving the change information of the transaction request recipient.

[0097] In one embodiment, in the distributed node consensus method described in the present application, the node consensus scheme between communication nodes implemented by "fast execution + rollback remediation" can be applied to application scenarios that have high real-time requirements but allow temporary inconsistencies.

[0098] In one embodiment, for step S701, the present application further provides some distributed node consensus steps for verifying the abnormality of the block data in the notification consensus information and / or the execution consensus information:

[0099] S701a. When the communication node is verifying the notification consensus information and / or the execution consensus information, if the height information of the blocks in the notification consensus information and / or the execution consensus information received by the communication node is consistent and the proposal node signatures of the blocks are the same, but the transaction requests in the corresponding blocks are different, it is determined that there is an abnormality in the block data in the notification consensus information and / or the corresponding execution consensus information at the corresponding height.

[0100] In this embodiment, since the notification consensus information and the execution consensus information are both generated by the proposal node based on the block data, the notification consensus information and the execution consensus information both include the block data, and the block data includes the block and the height information of the block, the hash value of the block, the generation timestamp of the block, and the proposal node signature of the block. Therefore, when the communication node verifies the notification consensus information and / or the execution consensus information, if the height information of the blocks in the notification consensus information and / or the execution consensus information received by the communication node is consistent and the proposal node signature of the block is the same, but the transaction requests in the corresponding blocks are different, then it is determined that the block data in the notification consensus information and / or the corresponding execution consensus information at the corresponding height is abnormal (unreliable).

[0101] In one embodiment, for step S704, the present application further provides some distributed node consensus steps for handling the situation where the new proposal node goes down:

[0102] S704a. When the corresponding communication node receives the rotation information and enters the rotation state, if the rotation result information is not received within the preset waiting time period, it is determined that the new proposal node is down.

[0103] S704b. According to the current new proposal node, the communication node that is one position later in sequence in the hybrid communication model replaces the current new proposal node.

[0104] S704c: If the number of timeouts exceeds a preset number, the communication node extends the preset waiting time period according to the number of timeouts and a preset delay rule.

[0105] The timeout count is the number of times the communication node fails to receive the rotation result information within a preset waiting time period.

[0106] In one embodiment, the preset delay rule is a preset exponential function; specifically, since the communication delays of each communication node are inconsistent, in order to ensure that all communication nodes can eventually reach a consensus on the election of a new proposal node at a certain moment, if the number of timeouts exceeds the preset number, the communication node exponentially increases the preset waiting time period according to the exponential function based on the number of timeouts.

[0107] In one embodiment, when the number of timeouts is 1, the preset waiting period is 5 seconds; when the number of timeouts is 2, the preset waiting period is 25 seconds; when the number of timeouts is 3, the preset waiting period is 125 seconds, and so on.

[0108] Example 2

[0109] The present application also provides a distributed node consensus system based on a hybrid communication model to implement the steps of the distributed node consensus method based on the hybrid communication model described in the above embodiment.

[0110] The distributed node consensus system based on the hybrid communication model includes at least a plurality of communication nodes, wherein the communication nodes are arranged in a closed loop and each communication node is connected to an adjacent communication node; wherein the communication nodes include proposal nodes;

[0111] After receiving the transaction request, the proposal node generates the corresponding block data; the proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the distributed node consensus system whose number of sequential delays is the tolerable number of error nodes plus one, wherein the error nodes include Byzantine nodes and crashed nodes; after verifying any of the received notification consensus information, the communication node enters the notified state, and sends the corresponding notification consensus information to the communication nodes in the distributed node consensus system whose number of sequential delays is the tolerable number of error nodes plus one; when the proposal node receives the notification consensus information and completes the verification of any of the received notification consensus information, it enters the notified state and completes the first node consensus.

[0112] It should be noted that when implementing a distributed node consensus method based on a hybrid communication model, the distributed node consensus system based on a hybrid communication model provided by the above embodiment can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above.

[0113] In addition, the distributed node consensus system based on the hybrid communication model provided in the above embodiment belongs to the same concept as the distributed node consensus method based on the hybrid communication model in Example 1. The implementation process is detailed in the method embodiment, i.e., Example 1, and will not be repeated here.

[0114] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the spirit of the present application, and the present application is intended to encompass such modifications and variations.

Claims

1. A distributed node consensus method based on a hybrid communication model, comprising the following steps: In response to a received transaction request, a proposal node in a hybrid communication model generates corresponding block data, wherein the hybrid communication model includes at least a plurality of communication nodes arranged in a closed loop; each of the communication nodes is connected to an adjacent communication node, and the communication nodes include a proposal node; The proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the hybrid communication model whose number of sequential delays is the number of tolerable error nodes plus one, wherein the error nodes include Byzantine nodes and crashed nodes; After verifying any of the received notification consensus information, the communication node enters the notified state and sends the corresponding notification consensus information to the communication nodes in the hybrid communication model whose sequence delay is the number of tolerable error nodes plus one; When the proposal node receives the notification consensus information and completes the verification of any notification consensus information received, it enters the notified state and completes the first node consensus.

2. According to the distributed node consensus method based on the hybrid communication model of claim 1, in response to a received transaction request, the step of generating corresponding block data by the proposal node in the hybrid communication model includes: In response to the received transaction request, the proposal node verifies whether the generation timestamp of the transaction request, the sender identifier of the transaction request, and the sender signature of the transaction request are legal; After the proposal node receives a preset number of legal transaction requests, the proposal node packages all legal transaction requests into a block, and generates the block height information, the block hash value, the block generation timestamp and the block proposal node signature to obtain block data.

3. The distributed node consensus method based on the hybrid communication model according to claim 2 is characterized in that: The consensus information notified includes at least block data and the signature of the sending node; The step of the proposal node generating consensus information based on the block data includes: The proposal node signs the block data and generates corresponding consensus information.

4. The distributed node consensus method based on the hybrid communication model according to claim 3 is characterized in that: Each of the communication nodes stores a communication node list including the names of all communication nodes; The step of the communication node verifying any received consensus information includes: In response to the received notification consensus information, the communication node verifies whether the sending node signature in the notification consensus information matches the communication node name in the communication node list; The communication node verifies whether the signature of the proposal node in the block data informing the consensus information matches the signature of the proposal node; The communication node verifies whether the height information in the block data notifying the consensus information is the height information of the verified block plus one; The communication node verifies whether the generation timestamp in the block data notifying the consensus information is greater than the generation timestamp of the verified block; If the verification results are all yes, the communication node replaces the sending node signature in the consensus information with its own node signature.

5. According to the distributed node consensus method based on the hybrid communication model of claim 2, after completing the first node consensus step, the distributed node consensus method based on the hybrid communication model further includes: The proposal node generates corresponding execution consensus information according to the block data, and sends the execution consensus information to the communication nodes in the hybrid communication model whose number of sequential delays is the number of tolerable error nodes plus one; After the communication node that has entered the informed state verifies any of the received execution consensus information, it enters the execution state and sends the corresponding execution consensus information to the communication nodes in the hybrid communication model whose sequential delay number is the tolerable number of error nodes plus one, completing the second node consensus.

6. The distributed node consensus method based on the hybrid communication model according to claim 5, wherein the execution consensus information at least includes the block data; After the communication node that has entered the informed state verifies any received execution consensus information and then enters the execution state, the distributed node consensus method further includes: After the communication node that enters the execution state completes the verification of all the received execution consensus information, it executes the transaction request in the block data and returns the corresponding execution result to the sender of the transaction request.

7. The distributed node consensus method based on the hybrid communication model according to claim 6, further comprising the following steps: When the communication node verifies the notification consensus information and / or the execution consensus information, if the block data in the notification consensus information and / or the execution consensus information is abnormal, the communication node marks the corresponding block data with a cancellation mark, and at the same time broadcasts the rotation information to the remaining communication nodes and enters the rotation state; In response to the received rotation information, the corresponding communication node enters a rotation state; According to the current proposal node, a communication node that is one position later in the hybrid communication model replaces the current proposal node and becomes the new proposal node; The new proposal node broadcasts the rotation result information to the remaining communication nodes, wherein the rotation result information includes the node signature of the new proposal node; In response to the received rotation result information, the corresponding communication node verifies the rotation result information. If the node signature is valid, it returns the rotation approval information to the new proposal node and ends the rotation state; When the new proposal node receives the agreed rotation information, the number of which is the total number of communication nodes minus the tolerable number of error nodes minus one, the new proposal node sends transaction request recipient change information to the sender of the transaction request.

8. The distributed node consensus method based on the hybrid communication model according to claim 7 is characterized in that: The process further includes verifying the abnormality of the block data in the consensus notification information and / or the consensus execution information: When the communication node is verifying the notification consensus information and / or the execution consensus information, if the height information of the blocks in the notification consensus information and / or the execution consensus information received by the communication node is consistent and the proposal node signatures of the blocks are the same, but the transaction requests in the corresponding blocks are different, it is determined that there is an abnormality in the block data in the notification consensus information and / or the corresponding execution consensus information at the corresponding height.

9. The distributed node consensus method based on the hybrid communication model according to claim 7 is characterized in that: Also included are steps for handling downtime of the new proposal node: When the corresponding communication node receives the rotation information and enters the rotation state, if the rotation result information is not received within the preset waiting time period, it is determined that the new proposal node is down; According to the current new proposal node, the communication node that is delayed by one position in the hybrid communication model replaces the current new proposal node; If the number of timeouts exceeds the preset number, the communication node extends the preset waiting time period according to the preset delay rules based on the number of timeouts, wherein the number of timeouts is the number of times the communication node fails to receive the rotation result information within the preset waiting time period.

10. A distributed node consensus system based on a hybrid communication model, characterized by: The distributed node consensus system includes a plurality of communication nodes, the communication nodes are arranged in a closed loop and each communication node is connected to an adjacent communication node; the communication nodes include proposal nodes; After receiving the transaction request, the proposal node generates the corresponding block data; The proposal node generates notification consensus information based on the block data, and sends the notification consensus information to the communication nodes in the distributed node consensus system whose number of sequential delays is the tolerable number of error nodes plus one, wherein the error nodes include Byzantine nodes and crashed nodes; after the communication node verifies any of the received notification consensus information, it enters the notified state and sends the corresponding notification consensus information to the communication nodes in the distributed node consensus system whose number of sequential delays is the tolerable number of error nodes plus one; when the proposal node receives the notification consensus information and completes the verification of any of the received notification consensus information, it enters the notified state and completes the first node consensus.

Images