Distributed consensus method based on blockchain and related equipment

Abstract

The present application discloses a distributed consensus method based on blockchain and related equipment, which relates to the field of blockchain technology and is applied to blockchain. The blockchain includes a standing consensus node and a candidate consensus node. The method includes: the standing consensus node receives a construction request issued by a business terminal or the candidate consensus node, and generates a block proposal based on the construction request; the standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on confirmation messages issued by the other standing consensus nodes; wherein the confirmation message is obtained by the other standing consensus nodes confirming the block proposal; after the standing consensus node sends the block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information to obtain a consensus result. In this application, the consensus efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a distributed consensus method based on blockchain and related equipment. Background Art

[0002] PBFT (Practical Byzantine Fault Tolerance) is an algorithm designed to solve the problem of reaching consensus on a message or transaction among nodes in a distributed system. It is particularly suitable for consortium blockchain environments, where the number of nodes participating in the consensus is known and limited, and they are generally trusted to some extent. PBFT can tolerate Byzantine faults, meaning that some nodes may exhibit arbitrary erroneous behavior (including failure or malicious behavior), while still ensuring system consistency.

[0003] However, a major limitation of the PBFT consensus algorithm is its high communication complexity. During each consensus phase, messages must be broadcast across all nodes, resulting in an overall communication complexity of O(n^2), where n represents the total number of nodes participating in the consensus. This communication overhead increases rapidly as the number of nodes increases, resulting in lower consensus efficiency. Summary of the Invention

[0004] The main purpose of this application is to provide a distributed consensus method based on blockchain and related equipment, aiming to solve the problem of low consensus efficiency.

[0005] To achieve the above objectives, the present application provides a distributed consensus method based on blockchain, which is applied to a blockchain. The blockchain includes a standing consensus node and a candidate consensus node. The distributed consensus method based on blockchain includes the following steps:

[0006] The executive consensus node receives a construction request from the business end or the candidate consensus node, and generates a block proposal based on the construction request;

[0007] The standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on confirmation messages sent by the other standing consensus nodes; wherein the confirmation messages are obtained by the other standing consensus nodes confirming the block proposal;

[0008] After the standing consensus node sends the block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information to obtain a consensus result.

[0009] Optionally, the blockchain includes multiple nodes, and after the standing consensus node sends block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information, and the step of obtaining a consensus result includes:

[0010] The node obtains node information of other nodes;

[0011] The node determines the malicious node in the blockchain through a smart contract based on the node information;

[0012] After the node sends a blocking instruction to the other nodes, the other nodes block the malicious node.

[0013] Optionally, after the node issues a blocking instruction to the other nodes, and the other nodes block the malicious node, the method further includes:

[0014] The node obtains pre-selected node information of the other nodes that are not shielded; wherein the pre-selected node information includes a communication speed between the other nodes and the associated pre-selected nodes;

[0015] The node updates a standing consensus node group according to the communication speed; wherein the standing consensus node group includes all standing consensus nodes.

[0016] Optionally, the blockchain includes multiple nodes, and before the step of the standing consensus node receiving a construction request from the business terminal or the candidate consensus node and generating a block proposal based on the construction request, the step includes:

[0017] The node obtains the number of nodes in the blockchain and calculates the number of groups based on the number of nodes;

[0018] The node determines a standing consensus node group and at least one candidate consensus node group based on the number of groups.

[0019] Optionally, the step of determining, by the node, a standing consensus node group and at least one candidate consensus node group based on the number of groups includes:

[0020] The node receives a test instruction and a reply message sent by other nodes based on the test instruction, and records the time interval between the test instruction and the reply message;

[0021] The node exchanges the time interval with the other nodes, and determines a standing consensus node group and at least one candidate consensus node group according to the time interval.

[0022] Optionally, after the standing consensus node sends the block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information, and before the step of obtaining the consensus result includes:

[0023] The standing consensus node determines the communication duration with each of the candidate consensus nodes, and exchanges the communication duration with the other standing consensus nodes;

[0024] The standing consensus node determines a target candidate consensus node based on the communication duration;

[0025] The standing consensus node sends the block information to the target candidate consensus node, so that the target candidate consensus node can confirm the block information.

[0026] In addition, to achieve the above objectives, the present application also provides a distributed consensus device based on blockchain, which includes:

[0027] A receiving module, configured for the executive consensus node to receive a construction request from a business terminal or the candidate consensus node, and to generate a block proposal based on the construction request;

[0028] A small consensus module, configured for the executive consensus node to send the block proposal to other executive consensus nodes, and generate block information based on confirmation messages sent by the other executive consensus nodes; wherein the confirmation message is obtained by the other executive consensus nodes confirming the block proposal;

[0029] The large consensus module is used to obtain a consensus result after the standing consensus node sends block information to the candidate consensus node, and the candidate knowledge node receives and confirms the block information.

[0030] In addition, to achieve the above-mentioned purpose, the present application also provides a blockchain-based distributed consensus device, which includes: a memory, a processor, and a blockchain-based distributed consensus program stored on the memory and executable on the processor, wherein the blockchain-based distributed consensus program is configured to implement the steps of the blockchain-based distributed consensus method.

[0031] In addition, to achieve the above-mentioned purpose, the present application also provides a storage medium, on which a distributed consensus program based on blockchain is stored. When the distributed consensus program based on blockchain is executed by a processor, the steps of the distributed consensus method based on blockchain are implemented.

[0032] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a distributed consensus program based on blockchain, and when the distributed consensus program based on blockchain is executed by a processor, it implements the steps of the distributed consensus method based on blockchain.

[0033] The present application provides a distributed consensus method based on blockchain and related equipment. A major limitation of the PBFT consensus algorithm in the related art is that its communication complexity is high. In each consensus stage, messages need to be broadcast between all nodes, so the overall communication complexity is O(n^2), where n represents the total number of nodes participating in the consensus. As the number of nodes increases, this communication overhead will increase rapidly, resulting in lower consensus efficiency. In comparison, in the present application, it is applied to a blockchain, the blockchain includes a standing consensus node and a standby consensus node, the standing consensus node receives a build request issued by a business end or the standby consensus node, and generates a block proposal based on the build request; the standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on the confirmation message issued by the other standing consensus nodes; wherein the confirmation message is obtained by the other standing consensus nodes confirming the block proposal; after the standing consensus node sends the block information to the standby consensus node, the standby knowledge node receives and confirms the block information to obtain a consensus result. It can be understood that in this application, when the consensus algorithm is running, the standing consensus node generates a block proposal based on the construction request issued by the business end or the candidate consensus node, and realizes the "small consensus" among all standing nodes, and then pushes the block information to multiple candidate consensus nodes. The candidate consensus node can complete the "big consensus" of the entire chain by confirming the consensus result once. By expanding from the preliminary consensus reached by the local node set to the final consensus of the entire network, the complexity of communication in the multi-alliance node scenario is reduced, thereby reducing communication overhead and improving consensus efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 This is a first flow chart of the first embodiment of the distributed consensus method based on blockchain of this application;

[0035] Figure 2 This is a schematic diagram of the first scenario of the first embodiment of the distributed consensus method based on blockchain in this application;

[0036] Figure 3 This is a schematic diagram of the second scenario of the first embodiment of the distributed consensus method based on blockchain in this application;

[0037] Figure 4 This is a second flow chart of the second embodiment of the distributed consensus method based on blockchain of this application;

[0038] Figure 5 This is a schematic diagram of the third scenario of the second embodiment of the distributed consensus method based on blockchain in this application;

[0039] Figure 6 This is a third flow chart of the third embodiment of the distributed consensus method based on blockchain of this application;

[0040] Figure 7 This is a schematic diagram of the fourth scenario of the third embodiment of the blockchain-based distributed consensus method of this application;

[0041] Figure 8 This is a structural diagram of the distributed consensus device based on blockchain in this application;

[0042] Figure 9 This is a schematic diagram of the structure of the hardware operating environment involved in the embodiment of this application.

[0043] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0045] Reference Figure 1 , Figure 1 This is a first flow chart of the first embodiment of the distributed consensus method based on blockchain in this application.

[0046] In a first embodiment, applied to a blockchain, the blockchain includes a standing consensus node and a candidate consensus node. The blockchain-based distributed consensus method includes the following steps:

[0047] Step S10: The executive consensus node receives a construction request from the business end or the candidate consensus node, and generates a block proposal based on the construction request;

[0048] Step S20: The standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on confirmation messages sent by the other standing consensus nodes; wherein the confirmation messages are obtained by the other standing consensus nodes confirming the block proposal;

[0049] In step S30, after the standing consensus node sends block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information to obtain a consensus result.

[0050] This embodiment aims to: when the consensus algorithm is running, the executive consensus node generates a block proposal based on the construction request issued by the business end or the candidate consensus node, and realizes the "small consensus" among all executive nodes through the improved PBFT algorithm, and then pushes the block information to multiple candidate consensus nodes. The candidate consensus nodes can complete the "big consensus" of the entire chain by confirming the consensus result in one communication. By expanding the preliminary consensus reached from the local node set to the final consensus of the entire network, the complexity of communication in the multi-alliance node scenario is reduced, thereby reducing communication overhead and improving consensus efficiency.

[0051] The following describes the specific steps:

[0052] Step S10: The executive consensus node receives a construction request from the business end or the candidate consensus node, and generates a block proposal based on the construction request;

[0053] It should be noted that the executor of this embodiment is a distributed consensus device based on blockchain, and the distributed consensus device based on blockchain may be subordinate to the blockchain. The blockchain includes a standing consensus node and a candidate consensus node, and the blockchain may be subordinate to a distributed consensus device based on blockchain.

[0054] It should be noted that blockchain is a distributed database technology, also known as distributed ledger technology. It ensures the security, integrity and immutability of data through decentralization, openness, transparency and collective maintenance.

[0055] It should be noted that the standing consensus node refers to a node that is more active in the consensus mechanism and is qualified to generate new blocks. After receiving a construction request, the standing consensus node will convert the request into a preliminary block proposal based on preset rules and protocols. This proposal contains transactions to be confirmed and other relevant information.

[0056] It should be noted that a candidate consensus node refers to a node that does not directly participate in block generation but plays an auxiliary or backup role. The candidate consensus node will follow the network communication protocol and forward the received construction request to the known permanent consensus node in a timely manner. Even if the business end does not directly interact with the permanent consensus node, its transaction request can be passed to the correct processing path through the candidate node, thereby participating in the consensus process of the entire blockchain network.

[0057] It should be noted that PBFT (Practical Byzantine Fault Tolerance), also known as the Practical Byzantine Fault Tolerance algorithm, is a consensus protocol that ensures data consistency in distributed systems. Its main process includes the following: Phase 1: The client submits a new transaction or request to the master node in the current view. Phase 2: After receiving the client request, the master node assigns it a globally unique sequence number and constructs a "prepare" message containing the request content and sequence number. The master node broadcasts this "prepare" message to all slave nodes. Phase 3: After receiving the "prepare" message, the slave node verifies the correctness of the message and the validity of the sequence number. If the slave node verifies that the message is correct, it agrees with the master's proposal and sends a "prepare" message to all other nodes (including the master and other slave nodes). When a slave node collects a sufficient number (typically 2f, where f is the number of nodes with Byzantine faults that the system can tolerate) of prepare messages with the same sequence number from different nodes, it considers the request to have reached the "prepared" state and obtains the corresponding prepared authentication certificate. In phase four, once a slave node enters the prepared state, it will further send a "commit" type message to all nodes in the network, indicating that it has confirmed and committed to executing the request; if a node receives 2f+1 commit messages for the same request (which means it contains confirmations from at least f+1 non-Byzantine nodes), then it can be determined that the request has been accepted by the majority of nodes and enters the "committed" state. In phase five, when the node's request state becomes committed, it will execute the requested operation locally (for example, process the transaction and update its local ledger); after execution is complete, the node will generate a response result and send it back to the client as a "reply" message.

[0058] In this embodiment, the blockchain-based distributed consensus device utilizes a modified PBFT algorithm to achieve full blockchain consensus. The main process includes the following: In Phase 1, the client initiates a build request, marking the block in the "pre-pre" state, and then broadcasting it to all standing consensus nodes. In Phase 2, upon receiving the request, the standing consensus node checks for duplicates and discards them if any. The standing consensus node verifies the block number to ensure it complies with the expected ordering rules and has not been pre-authenticated. The validity of the block content is verified and executed through business logic. If the block is valid and executed correctly, it is placed in the Prepare queue, changed to the "prepare" state, and then broadcast to the entire network. In Phase 3, the receiving node performs the same rigorous verification of the block number again. If the number is valid, the node updates the block state to "commit" and broadcasts this change to other standing consensus nodes. In Phase 4, when a standing consensus node collects more than a quorum (i.e., 2f+1, where f is the maximum number of faulty nodes it can tolerate) of commit confirmations, it deems the block to have been agreed upon by the network and sets the block to the "committed" state. The node then writes the block's metadata to the blockchain and archives the complete block content in a local relational database. In Phase 5, the message that a new block has been generated is broadcast to all standing consensus nodes. Upon receiving the notification of a new block generation, each node checks whether it has already processed the block locally. If not, it proceeds with subsequent operations. The node writes the new block's metadata to the blockchain and stores the block content in the local database. In Phase 6, after consensus is reached among the standing consensus nodes, the selected block is set to the "commit-all" state and broadcast to candidate consensus nodes across the network. Upon receiving this message, each candidate consensus node writes the data locally and responds to the message with a response indicating whether the write was successful. If unsuccessful, the node retrys locally and then responds with a message indicating success.

[0059] It can be understood that the business end initiates a build request to any node in the blockchain. If the business end sends the build request to the standing consensus node, the standing consensus node generates a block proposal based on the build request; if the business end sends the build request to the candidate consensus node, the candidate consensus node forwards the build request to the known standing consensus node.

[0060] In specific implementations, the candidate consensus node selects the most quickly communicating permanent consensus node based on historically published data synchronization performance with the permanent consensus node, and forwards the build request to the fastest communicating permanent consensus node. After receiving the confirmation data from the permanent consensus node, the candidate consensus node calculates the time it takes to send and receive the data and updates the data synchronization performance with the permanent consensus node.

[0061] It is understandable that the business end initiates a build request, sets the block status to the pre-prepare state, and then broadcasts it to all standing consensus nodes.

[0062] It is understandable that after receiving a build request, the standing consensus node checks whether it is a duplicate request, and if so, discards it; if the received build request is not a duplicate request, the standing consensus node verifies the block number according to specific rules (such as block height or timestamp), and if the verification fails, the request is not processed; if the verification succeeds, the standing consensus node performs pre-generation on the block proposal based on the build request, and if the execution is valid, the block is added to the Prepare queue and the block status is changed to Prepare.

[0063] In specific implementations, the standing consensus node verifies the block number according to specific rules, including: traversing all voting information in the block status stage. If the block corresponding to the hash has already voted, the number verification fails; if the block number to be voted is smaller than the current block number, the number verification fails.

[0064] Step S20: The standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on confirmation messages sent by the other standing consensus nodes; wherein the confirmation messages are obtained by the other standing consensus nodes confirming the block proposal;

[0065] It can be understood that the standing consensus node sends a block proposal to other standing consensus nodes. After receiving the block proposal, other standing consensus nodes perform number verification. If the number is valid, the block status is updated to commit, and a confirmation message is sent to all standing consensus nodes in the standing consensus node group.

[0066] In the specific implementation, the standing consensus node counts the confirmation messages received. When it receives confirmation messages from more than 2f+1 different nodes (including itself), the standing consensus node considers that the block proposal has been agreed upon by the entire network, enters the committed state, writes the block information into the blockchain, and saves the entire content of the block in the local relational database.

[0067] In the specific implementation, the executive consensus node broadcasts the generated new block to the executive consensus node group. After receiving the message that the new block has been generated, other executive consensus nodes check whether the block has been generated locally. If it has been generated, the message is ignored; if not, the metadata information of the block is written into the blockchain and the entire content of the block is saved in the local relational database.

[0068] In step S30, after the standing consensus node sends block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information to obtain a consensus result.

[0069] It is understandable that the standing consensus node sets the consensus block to the full-chain consensus state, sets the block state to the commit-all state, and broadcasts it to the candidate consensus nodes in the entire network.

[0070] In the specific implementation, the standing consensus node determines the communication duration between itself and each candidate consensus node, exchanges the communication duration with other standing consensus nodes, and then determines the target candidate consensus node based on the global ranking of the communication duration. The standing consensus node sends the block information to the candidate consensus node.

[0071] In the specific implementation, after receiving the block information, each candidate consensus node writes the local data and replies whether the block information is written successfully. If unsuccessful, the local retry is successful and the information is replied, thereby further reducing one round of communication process with the candidate consensus nodes.

[0072] Specifically, before step S30, steps t1-t3 are also included:

[0073] Step t1: the standing consensus node determines the communication duration with each of the candidate consensus nodes, and exchanges the communication duration with the other standing consensus nodes;

[0074] In specific implementations, the executive consensus node, based on the smart contract, collects statistics on the top M candidate consensus nodes with the shortest communication times and several candidate consensus nodes with relatively long communication times. The executive consensus node packages the top M candidate consensus nodes, several candidate consensus nodes with relatively long communication times, and the communication times into a block and sends it to other executive consensus nodes.

[0075] Step t2: The standing consensus node determines a target candidate consensus node based on the communication duration;

[0076] In the specific implementation, the standing consensus node performs two rounds of sorting operations based on the candidate consensus nodes: in the first round, for each candidate consensus node, the communication time between it and different standing consensus nodes is sorted from short to long; in the second round, the candidate consensus nodes are sorted by the shortest total communication time.

[0077] For example, refer to Figure 2After the first round of sorting, for candidate node 1, the sorting from shortest to longest in terms of communication duration is: standing consensus node 1, standing consensus node 2, and standing consensus node 3; for candidate node 2, the sorting from shortest to longest in terms of communication duration is: standing consensus node 1, standing consensus node 2, and standing consensus node 3; for candidate node 3, the sorting from shortest to longest in terms of communication duration is: standing consensus node 1, standing consensus node 2, and standing consensus node 3.

[0078] For example, refer to Figure 3 ,After the second round of sorting, the ranking of the shortest communication time of the candidate consensus nodes is: candidate node 3 (1.1+2.1+3.1=6.3 seconds), candidate node 2 (1.2+2.2+2.3=6.6 seconds) and candidate node 1 (1.3+2.3+3.3=6.9 seconds).

[0079] In the specific implementation, each candidate consensus node selects the standing consensus node with which it communicates the fastest. The standing consensus node calculates the number of candidate consensus nodes currently corresponding to the node. If the number is M, the currently corresponding candidate consensus node is determined as the target candidate consensus node.

[0080] In a specific implementation, if the number of candidate consensus nodes currently corresponding to this node is less than M, the executive consensus node will list this node in the table List; if the number of candidate consensus nodes currently corresponding to this node is greater than M, the executive consensus node will select the fastest M candidate consensus nodes and list the candidate consensus nodes exceeding M in the table List; the executive consensus node will compare the second or third fastest executive consensus node of the candidate consensus node with the List, and change the sent mapping relationship to the second-best fastest executive consensus node currently found.

[0081] In step t3, the executive consensus node sends the block information to the target candidate consensus node, so that the target candidate consensus node can confirm the block information.

[0082] In a specific implementation, the executive consensus node sends the block information to the target candidate consensus node, and the target candidate consensus node confirms the block information.

[0083] In this embodiment, a major limitation of the PBFT consensus algorithm in the related art is its high communication complexity. In each consensus phase, messages need to be broadcast between all nodes, so the overall communication complexity is O(n^2), where n represents the total number of nodes participating in the consensus. As the number of nodes increases, this communication overhead will increase rapidly, resulting in lower consensus efficiency. In this embodiment, it is applied to a blockchain, and the blockchain includes a standing consensus node and a candidate consensus node. The standing consensus node receives a build request from a business terminal or the candidate consensus node, and generates a block proposal based on the build request; the standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on confirmation messages sent by the other standing consensus nodes; wherein the confirmation message is obtained by the other standing consensus nodes confirming the block proposal; after the standing consensus node sends the block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information to obtain a consensus result. That is, in this embodiment, when the consensus algorithm is running, the executive consensus node generates a block proposal based on the construction request issued by the business end or the candidate consensus node, and realizes the "small consensus" among all executive nodes through the improved PBFT algorithm, and then pushes the block information to multiple candidate consensus nodes. The candidate consensus nodes can complete the "big consensus" of the entire chain by confirming the consensus result in one communication. By expanding the process from the preliminary consensus reached by the local node set to the final consensus reached by the entire network, the complexity of communication in the multi-alliance node scenario is reduced, thereby reducing communication overhead and improving consensus efficiency.

[0084] Further, refer to Figure 4 Based on the above embodiment, a second embodiment of the present application is provided. In this embodiment, the blockchain includes multiple nodes. After step S30, the following steps are further included:

[0085] Step A10: the node obtains node information of other nodes;

[0086] In the specific implementation, the nodes in the blockchain use the interface of the alliance chain management node service in the data zone, which will return the legal alliance chain node information for verification.

[0087] In step A20, the node determines the malicious node in the blockchain through a smart contract based on the node information;

[0088] It should be noted that the smart contract includes a contract metadata area, a contract data area, a contract area and a contract data verification area.

[0089] In the specific implementation, refer to Figure 5The contract metadata area (ContractMetaData) includes the contract number (string field type, field name contract_num), contract name (string field type, field name contract_name), contract version (string field type, field name contract_version) and contract trigger method (integer field type, field name contract_runway).

[0090] In practice, there are multiple ways to trigger a contract, including but not limited to time-based triggering (real-time and scheduled) and data volume-based triggering. In the time-based triggering method, for real-time triggering, contract_runway = 0; for scheduled triggering, the trigger time is written as an integer string. For example, 2023-04-10 10:00:00 can be written as 20230410100000, i.e., contract_runway = 20230410100000. In the data volume-based triggering method, the contract is triggered based on the number of data items that meet the triggering conditions.

[0091] In the specific implementation, refer to Figure 5 The contract data area (ContractData) includes the alliance management node service interface and malicious node identification rules. The interface is used by smart contracts to query information such as the number and IP address of nodes. Together, the interface and rules provide data support for identifying malicious nodes. The contract area (Contract) includes a grouping calculation function for calculating how many groups the current alliance chain nodes can be divided into; the contract area (Contract) also includes an alliance node classification and grouping function for classifying alliance chain nodes into standing consensus nodes and candidate consensus nodes; and the contract area (Contract) also includes a malicious node identification function for identifying malicious nodes. The contract data verification area (ContractVerifyData) includes metadata verification, data area verification, and contract area verification to verify the integrity and authenticity of data in the blockchain.

[0092] In specific implementations, the verification data is calculated based on the MD5 value of the JSON of each set of data. Taking the generation of data verification data in the metadata area as an example: Step 1, organize the contract number, contract name, contract version, and contract trigger method and their corresponding values ​​into JSON format; Step 2, generate the contract metadata verification metaVerify according to the MD5 algorithm from the JSON in step 1, that is, the contract metadata verification metaVerify = MD5(JSON). When the contract needs to be generated, the values ​​of the corresponding fields are filled in according to the data structure of the above contract to complete the assembly of the smart contract data. The contract is then published on the chain and enters the alliance chain for consensus and localized storage of the contract on each node.

[0093] It is understandable that in order to avoid interference from a small number of malicious nodes in the standing consensus nodes, the number of consensus nodes is required to be no less than 2 / 3 of the number of standing consensus nodes during the consensus period of the standing consensus nodes.

[0094] In this embodiment, nodes in the blockchain use node information and the malicious node identification function in the smart contract to determine the malicious nodes among other standing consensus nodes and candidate consensus nodes. There are three scenarios where malicious nodes exist: all or most of the malicious nodes are among the standing consensus nodes; a small number of malicious nodes are among the standing consensus nodes; and no malicious nodes are among the standing consensus nodes.

[0095] Step A30: After the node sends a blocking instruction to the other nodes, the other nodes block the malicious node.

[0096] In specific implementation, the malicious nodes identified by the nodes in the blockchain will be broadcast to the entire chain by the smart contract, and each node will receive the malicious nodes calculated by the smart contracts of other nodes (including the alliance chain management node service); then the entire chain will reach a consensus on the malicious node information and block the malicious node (that is, it will not be allowed to communicate, such as in the standing consensus node, it will be removed from the standing consensus node record).

[0097] In a specific implementation, the nodes in the blockchain obtain the pre-selected node information of other unshielded nodes, and update the standing consensus node group according to the communication speed between other nodes and the associated pre-selected nodes in the pre-selected node information.

[0098] Specifically, after step A30, steps A31-A32 are further included:

[0099] Step A31: the node obtains pre-selected node information of the other nodes that are not shielded; wherein the pre-selected node information includes the communication speed between the other nodes and the associated pre-selected nodes;

[0100] In the specific implementation, when the malicious node is broadcast to each node of the alliance chain, the standing consensus node is dynamically adjusted, that is, the node in the blockchain sends the top N / M node information obtained by the node statistics to other nodes. After each node receives the top N / M data pushed by other nodes, it can calculate the global top N / M nodes.

[0101] In the specific implementation, the nodes in the blockchain continuously calculate the communication speed of the previous N / M node information based on the time when each node sends it to this node during the operation of the consensus algorithm.

[0102] In step A32, the node updates the standing consensus node group according to the communication speed; wherein the standing consensus node group includes all standing consensus nodes.

[0103] In the specific implementation, the nodes in the blockchain reach a consensus on the calculated global top N / M nodes to obtain the initialized standing consensus node, and each node records it in its own node.

[0104] In this embodiment, compared to the related art PBFT, if the master node is a malicious node (Byzantine node), it may send inconsistent messages to different slave nodes in an attempt to disrupt consensus. Although PBFT has designed certain fault-tolerance mechanisms to deal with this situation, if the master node completely controls more than f slave nodes (i.e., when the total number of nodes is 3f+1, a maximum of f Byzantine nodes can be tolerated), the system may be attacked and unable to reach a correct consensus. In this embodiment, the node obtains the node information of other nodes; based on the node information, the node determines the malicious node in the blockchain through a smart contract; after the node issues a blocking instruction to the other node, the other node blocks the malicious node. That is, in this embodiment, the node in the blockchain obtains the node information of other nodes and determines the malicious node through a smart contract. The other nodes block the malicious node based on the received blocking instruction. By monitoring and identifying malicious nodes within the alliance chain, they can be promptly eliminated to ensure the healthy, stable, and orderly operation of the alliance chain.

[0105] Further, refer to Figure 6 Based on the above embodiment, a third embodiment of the present application is provided. In this embodiment, the blockchain includes multiple nodes, and the distributed consensus method based on the blockchain further includes the following steps:

[0106] Step B10: The node obtains the number of nodes in the blockchain and calculates the number of groups based on the number of nodes.

[0107] In a specific implementation, the node obtains the number N of nodes in the current alliance chain and calculates the number of groups M based on the number of nodes:

[0108] In step B20, the node determines a standing consensus node group and at least one candidate consensus node group based on the number of groups.

[0109] In a specific implementation, the node divides N / M nodes into the standing consensus node group, and the others are standby consensus nodes.

[0110] For example, refer to Figure 7 Group 1 includes standing node 1, standing node 2 and standing node N / M, group 2 includes candidate node 1, candidate node 2 and candidate node N / M, and group M includes candidate node 1, candidate node 2 and candidate node N / M.

[0111] In a specific implementation, the node receives a test instruction and a reply message sent by other nodes based on the test instruction, and records the time interval between the test instruction and the reply message; the node exchanges time intervals with other nodes, and determines a standing consensus node group and at least one standby consensus node group based on the time interval.

[0112] Specifically, the step B20 further includes steps B21-B22:

[0113] Step B21: The node receives a test instruction and a reply message sent by other nodes based on the test instruction, and records the time interval between the test instruction and the reply message;

[0114] In the specific implementation, one of the nodes in the blockchain sends a test message to all nodes based on the smart contract, and then starts a timer to count the time it takes for each node to reply to the message and reach this node.

[0115] In step B22, the node exchanges the time interval with the other nodes, and determines a standing consensus node group and at least one candidate consensus node group according to the time interval.

[0116] In a specific implementation, the node receives information from the first N / M+1 nodes and can obtain the first N / M nodes with the fastest communication speed that are not its own (the 1 in +1 is the node's voice) at the local node; the smart contract of each node sends the first N / M node information obtained by the local node to other nodes; after each node receives the first N / M data pushed by other nodes, it can calculate the global first N / M nodes; then each node reaches a consensus on the calculated global first N / M nodes to obtain the initialized standing consensus node, and each node records it at the local node.

[0117] In this embodiment, unlike related art where a master node fails or a network partition renders it inoperable, the system must undergo a view change process to re-elect a new master node. During this process, the PBFT consensus temporarily stops processing client requests until a new master node is elected and the consensus process resumes. This means that system availability and efficiency are affected during the master election period. In this embodiment, the node obtains the number of nodes in the blockchain and calculates the number of groups based on this number. Based on this number of groups, the node determines a standing consensus node group and at least one candidate consensus node group. In other words, in this embodiment, the number of groups is calculated based on the number of nodes in the blockchain, and a standing consensus node group and at least one candidate consensus node group are determined. The algorithm has no master node, and all nodes in the consortium chain have equal status. This prevents master node failures due to network partitions, thereby improving system availability and efficiency.

[0118] In addition, the present application also proposes a distributed consensus device based on blockchain, referring to Figure 8 , the distributed consensus device based on blockchain includes:

[0119] Receiving module 10, configured for the executive consensus node to receive a construction request from a business terminal or the candidate consensus node, and generate a block proposal based on the construction request;

[0120] The small consensus module 20 is configured for the executive consensus node to send the block proposal to other executive consensus nodes, and generate block information based on confirmation messages sent by the other executive consensus nodes; wherein the confirmation messages are obtained by the other executive consensus nodes confirming the block proposal;

[0121] The large consensus module 30 is used to obtain a consensus result after the standing consensus node sends block information to the candidate consensus node, and the candidate knowledge node receives and confirms the block information.

[0122] In this embodiment, applied to a blockchain, the blockchain includes a standing consensus node and a candidate consensus node, the standing consensus node receives a construction request issued by a business terminal or the candidate consensus node, and generates a block proposal based on the construction request; the standing consensus node sends the block proposal to other standing consensus nodes, and generates block information according to confirmation messages issued by the other standing consensus nodes; wherein the confirmation message is obtained by the other standing consensus nodes confirming the block proposal; after the standing consensus node sends the block information to the candidate consensus node, the candidate knowledge node receives and confirms the block information to obtain a consensus result. That is, in this embodiment, when the consensus algorithm is running, the executive consensus node generates a block proposal based on the construction request issued by the business end or the candidate consensus node, and realizes the "small consensus" among all executive nodes through the improved PBFT algorithm, and then pushes the block information to multiple candidate consensus nodes. The candidate consensus nodes can complete the "big consensus" of the entire chain by confirming the consensus result in one communication. By expanding the process from the preliminary consensus reached by the local node set to the final consensus reached by the entire network, the complexity of communication in the multi-alliance node scenario is reduced, thereby reducing communication overhead and improving consensus efficiency.

[0123] The specific implementation of the distributed consensus device based on blockchain in this application is basically the same as the above-mentioned embodiments of the distributed consensus method based on blockchain, and will not be repeated here.

[0124] Reference Figure 9 , Figure 9 This is a schematic diagram of the distributed consensus device structure based on blockchain in the hardware operating environment involved in the embodiment of the present application.

[0125] like Figure 9 As shown, the blockchain-based distributed consensus device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display and an input unit such as a keyboard. Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a wireless fidelity (WI-FI) interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also be a storage device independent of the processor 1001.

[0126] Those skilled in the art will understand that Figure 9 The structure shown in does not constitute a limitation on the distributed consensus device based on blockchain, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0127] like Figure 9 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a distributed consensus program based on blockchain.

[0128] Among them, the operating system is a program that manages and controls blockchain-based distributed consensus devices and software resources, and supports the operation of network communication modules, user interface modules, blockchain-based distributed consensus programs and other programs or software. The network communication module is used to manage and control the network interface 1004; the user interface module is used to manage and control the user interface 1003.

[0129] exist Figure 9 In the blockchain-based distributed consensus device shown, the blockchain-based distributed consensus device calls the blockchain-based distributed consensus program stored in the memory 1005 through the processor 1001 to implement the steps of any of the above-mentioned blockchain-based distributed consensus methods.

[0130] The specific implementation methods of the blockchain-based distributed consensus device in this application are basically the same as the above-mentioned blockchain-based distributed consensus method embodiments, and will not be repeated here.

[0131] In addition, an embodiment of the present invention also proposes a storage medium. An embodiment of the present application provides a storage medium, and the storage medium stores one or more programs. The one or more programs can also be executed by one or more processors to implement the steps of the blockchain-based distributed consensus method described in any of the above items.

[0132] The specific implementation methods of the storage medium of this application are basically the same as the above-mentioned embodiments of the distributed consensus method based on blockchain, and will not be repeated here.

[0133] In addition, an embodiment of the present invention also proposes a computer program product, including a distributed consensus program based on blockchain, which implements the steps of the distributed consensus method based on blockchain as described above when executed by a processor.

[0134] The specific implementation methods of the computer program product of the present invention are basically the same as the above-mentioned embodiments of the distributed consensus method based on blockchain, and will not be repeated here.

[0135] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0136] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0137] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0138] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A distributed consensus method based on blockchain, characterized in that: Applied to a blockchain, the blockchain includes multiple nodes, the blockchain includes a standing consensus node and a candidate consensus node, and the blockchain-based distributed consensus method includes the following steps: The node obtains the number of nodes in the blockchain and calculates the number of groups based on the number of nodes; The node determines a standing consensus node group and at least one candidate consensus node group based on the number of groups; The executive consensus node receives a build request from the business end or the candidate consensus node, and generates a block proposal based on the build request. The candidate consensus node is a node that does not directly participate in block generation but plays an auxiliary or backup role. The candidate consensus node is used to follow the network communication protocol and forward the received build request to the known executive consensus node; The standing consensus node sends the block proposal to other standing consensus nodes, and generates block information based on confirmation messages sent by the other standing consensus nodes; wherein the confirmation messages are obtained by the other standing consensus nodes confirming the block proposal; After the standing consensus node sends the block information to the candidate consensus node, the candidate consensus node receives and confirms the block information to obtain a consensus result.

2. The distributed consensus method based on blockchain according to claim 1, characterized in that: The blockchain includes a plurality of nodes. After the standing consensus node sends block information to the candidate consensus node, the candidate consensus node receives and confirms the block information, and obtains a consensus result, the following steps are included: The node obtains node information of other nodes; The node determines the malicious node in the blockchain through a smart contract based on the node information; After the node sends a blocking instruction to the other nodes, the other nodes block the malicious node.

3. The distributed consensus method based on blockchain as claimed in claim 2, characterized in that: After the node issues a blocking instruction to the other nodes, and the other nodes block the malicious node, the method includes: The node obtains pre-selected node information of the other nodes that are not shielded; wherein the pre-selected node information includes a communication speed between the other nodes and the associated pre-selected nodes; The node updates a standing consensus node group according to the communication speed; wherein the standing consensus node group includes all standing consensus nodes.

4. The distributed consensus method based on blockchain according to claim 1, characterized in that: The step of determining, by the node, a standing consensus node group and at least one candidate consensus node group based on the number of groups includes: The node receives a test instruction and a reply message sent by other nodes based on the test instruction, and records the time interval between the test instruction and the reply message; The node exchanges the time interval with the other nodes, and determines a standing consensus node group and at least one candidate consensus node group according to the time interval.

5. The distributed consensus method based on blockchain according to any one of claims 1 to 3, characterized in that: After the standing consensus node sends the block information to the candidate consensus node, the candidate consensus node receives and confirms the block information, and before the step of obtaining the consensus result includes: The standing consensus node determines the communication duration with each of the candidate consensus nodes, and exchanges the communication duration with the other standing consensus nodes; The standing consensus node determines a target candidate consensus node based on the communication duration; The standing consensus node sends the block information to the target candidate consensus node, so that the target candidate consensus node can confirm the block information.

6. A distributed consensus device based on blockchain, characterized in that: Applied to a blockchain, the blockchain includes multiple nodes, the blockchain includes a standing consensus node and a candidate consensus node, and the blockchain-based distributed consensus device includes: A receiving module, configured for the node to obtain the number of nodes in the blockchain and calculate the number of groups based on the number of nodes. The node determines a standing consensus node group and at least one candidate consensus node group based on the number of groups. The standing consensus node receives a build request from a service end or the candidate consensus node and generates a block proposal based on the build request. A candidate consensus node is a node that does not directly participate in block generation but serves as an auxiliary or backup node. The candidate consensus node is configured to follow the network communication protocol and forward the received build request to a known standing consensus node. A small consensus module, configured for the executive consensus node to send the block proposal to other executive consensus nodes, and generate block information based on confirmation messages sent by the other executive consensus nodes; wherein the confirmation message is obtained by the other executive consensus nodes confirming the block proposal; The large consensus module is used to obtain a consensus result after the standing consensus node sends block information to the candidate consensus node, and the candidate consensus node receives and confirms the block information.

7. A distributed consensus device based on blockchain, characterized in that: The device includes: a memory, a processor, and a blockchain-based distributed consensus program stored in the memory and executable on the processor, wherein the blockchain-based distributed consensus program is configured to implement the steps of the blockchain-based distributed consensus method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that: The storage medium stores a distributed consensus program based on blockchain, and when the distributed consensus program based on blockchain is executed by the processor, the steps of the distributed consensus method based on blockchain as described in any one of claims 1 to 5 are implemented.

9. A computer program product, characterized in that The computer program product includes a distributed consensus program based on blockchain, and when the distributed consensus program based on blockchain is executed by a processor, the steps of the distributed consensus method based on blockchain as described in any one of claims 1 to 5 are implemented.

Images