Block alliance consensus method and related device

Abstract

The invention discloses a block alliance consensus method and a related device, and relates to the technical field of block chains, the block alliance consensus method is applied to a block chain network, the block chain network comprises a plurality of committee nodes and a plurality of consensus nodes, the plurality of committee nodes comprise a main node and a plurality of candidate main nodes, according to the method, traditional single-round complex voting is divided into two rounds of verification with high dependency and simplified steps, cross-round consensus linking is carried out in the mode that the consensus state under the chain of the previous block is hashed and then the subsequent block is embedded, the communication complexity between the nodes is remarkably reduced, the expenditure of voting messages of the nodes of the whole network is avoided, and meanwhile, the communication efficiency is improved. Through candidate verification of the candidate master node and rapid consensus state confirmation based on Hash, the efficiency of the consensus process and the system throughput are greatly improved. Therefore, compared with the traditional Byzantine fault-tolerant consensus, the communication complexity is reduced, and the communication efficiency and the calculation efficiency of the system are improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain consortium consensus method and related apparatus. Background Technology

[0002] When building distributed networks and systems, such as blockchain infrastructure for the Internet of Things, the choice and design of consensus methods are crucial to ensuring network security and efficiency. Due to their advantages in fault tolerance, some consensus methods based on traditional Byzantine fault tolerance have been widely researched and adopted. However, high communication complexity is a technical problem inherent in traditional Byzantine fault-tolerant consensus methods. Summary of the Invention

[0003] In view of the above problems, this application provides a blockchain consortium consensus method and related apparatus, the specific solution of which is as follows:

[0004] This application provides a blockchain consortium consensus method applied to a blockchain network, wherein the blockchain network includes multiple committee nodes and multiple consensus nodes, the multiple committee nodes including master nodes and multiple candidate master nodes, and the blockchain consortium consensus method includes:

[0005] The master node generates and broadcasts a first block; wherein, the first block is at a first height, the first block includes a first block header and a first block body, the first block header includes a hash digest of the first data, and the first block body includes the first data;

[0006] After receiving the first block, the candidate master node performs data authentication on the first block based on the first data and the first block header. If the data authentication is successful, the first block is broadcast.

[0007] After receiving the first block, the consensus node performs data authentication on the first block based on the first data and the first block header. If the data authentication is successful, it broadcasts a first authentication message, which is used to indicate that the first block has passed authentication.

[0008] If the committee node receives a first authentication message from the consensus node exceeding a preset first ratio, it determines that the first block has passed the first round of consensus, and stores the first round of consensus data of the first block locally. The first round of consensus data of the first block includes the received first authentication message and the node identifier of the corresponding consensus node.

[0009] The master node generates and broadcasts a second block; the second block is a second height, which is the first height plus 1. The second block includes a second block header and a second block body. The second block header includes a hash digest of the second data and a predecessor consensus hash digest. The second block body includes the second data. The predecessor consensus hash digest in the second block header is a hash digest of the first round consensus data of the first block stored locally by the master node.

[0010] After receiving the second block, the candidate master node determines whether the hash digest of the first round consensus data of the first block stored locally by the candidate master node is consistent with the predecessor consensus hash digest in the header of the second block. If they are consistent, the consensus authentication is confirmed to be successful, and the second block is broadcast.

[0011] The consensus node determines whether it has received the second block from a candidate master node that exceeds a preset second ratio. If so, it determines that the first block has passed the second round of consensus.

[0012] In one possible implementation, the master node generates and broadcasts the first block, including:

[0013] After receiving the on-chain request for the first data, the master node determines the data type of the first data;

[0014] If the data type of the first data is sensor data, the master node calculates the hash value of the first data as a hash digest of the first data.

[0015] If the data type of the first data is transaction data, the master node calculates the Merkle root of the first data as a hash digest of the first data;

[0016] The master node generates the first block at the first height and broadcasts the first block at the first height.

[0017] In one possible implementation, the target node performs data authentication on the first block based on the first data and the first block header, including:

[0018] The target node determines the data type of the first data;

[0019] If the data type of the first data is sensor data, the target node calculates the hash value of the first data, compares the hash value of the first data with the hash digest in the first block body, and if they match, the data authentication is confirmed to be successful.

[0020] If the data type of the first data is transaction data, the target node calculates the Merkle root of the first data, compares the Merkle root of the first data with the hash digest in the first block body, and if they match, the data authentication is confirmed to be successful.

[0021] The target node includes the candidate master node and the consensus node.

[0022] In one possible implementation, the first ratio is not less than 50%, and the second ratio is not less than 50%.

[0023] In one possible implementation, after receiving the first block, the candidate master node performs data authentication on the first block based on the first data and the first block header. If the data authentication passes, it broadcasts the first block, including:

[0024] After receiving the first block, the candidate master node executes:

[0025] If the first block header also includes a predecessor consensus hash digest, determine whether the hash digest of the first round consensus data of the predecessor block of the first block stored locally by the candidate master node is consistent with the predecessor consensus hash digest in the first block header. If they are consistent, then the consensus authentication is confirmed to be successful.

[0026] Furthermore, based on the first data and the first block header, data authentication is performed on the first block;

[0027] If consensus authentication and data authentication both pass, then the first block is broadcast.

[0028] In one possible implementation, after receiving the first block, the consensus node performs data authentication on the first block based on the first data and the first block header. If the data authentication passes, it broadcasts a first authentication message, including:

[0029] After receiving the first block, the consensus node executes:

[0030] Determine whether the first block issued by a candidate master node exceeding the second ratio has been received; if so, determine whether the predecessor block of the first block has passed the second round of consensus.

[0031] Based on the first data and the first block header, perform data authentication on the first block. If the data authentication is successful, broadcast the first authentication message.

[0032] In one possible implementation, the blockchain consortium consensus method also includes:

[0033] After any block is successfully added to the blockchain, the reputation score of each blockchain node is updated through on-chain smart contracts.

[0034] If the candidate master node does not receive the block or heartbeat message broadcast by the master node within a preset time threshold, the candidate master node with the highest reputation score will take over as the new master node.

[0035] A second aspect of this application provides a blockchain network comprising committee nodes and multiple consensus nodes, wherein the committee nodes include a master node and multiple candidate master nodes; the blockchain network is used to execute the blockchain consortium consensus method described above.

[0036] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the block consortium consensus method described in the first aspect or any implementation thereof.

[0037] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0038] The memory is used to store computer programs;

[0039] The processor is used to execute the computer program to enable the electronic device to implement the block consortium consensus method of the first aspect or any implementation thereof.

[0040] Using the above technical solution, this application provides a blockchain consortium consensus method and related apparatus, applied to a blockchain network. The blockchain network includes multiple committee nodes and multiple consensus nodes. The multiple committee nodes include master nodes and multiple candidate master nodes. The blockchain consortium consensus method includes: the master node generating and broadcasting a first block. The first block is at a first height, and includes a first block header and a first block body. The first block header includes a hash digest of first data, and the first block body includes the first data. After receiving the first block, the candidate master nodes perform data authentication on the first block based on the first data and the first block header. If the data authentication is successful, they broadcast the first block. After receiving the first block, the consensus nodes perform data authentication on the first block based on the first data and the first block header. If the data authentication is successful, they broadcast a first authentication message, which indicates that the first block has passed authentication. If a committee node receives more than a preset first ratio of first authentication messages from consensus nodes, it determines that the first block has passed the first round of consensus and locally stores the first round of consensus data for the first block. The first round of consensus data for the first block includes the received first authentication messages and the node identifiers of the corresponding consensus nodes. The master node generates and broadcasts the second block. The second block is at a second height, which is the first height plus 1. The second block includes a second block header and a second block body. The second block header includes a hash digest of the second data and a hash digest of the preceding consensus. The second block body includes the second data. The preceding consensus hash digest in the second block header is the hash digest of the first round of consensus data from the first block stored locally by the master node. After receiving the second block, the candidate master node determines whether the hash digest of the first round of consensus data from the first block stored locally by the candidate master node matches the preceding consensus hash digest in the second block header. If they match, the consensus authentication is successful, and the second block is broadcast. The consensus node determines whether it has received a second block from a candidate master node exceeding a preset second ratio. If so, the first block has passed the second round of consensus.

[0041] As can be seen from the above technical solution, the blockchain consortium consensus method provided in this application significantly reduces the communication complexity between nodes and avoids the overhead of broadcasting voting messages multiple times across the network by splitting the traditional complex single-round voting into two rounds of verification with strong dependencies and simplified steps. Furthermore, it utilizes the hashing of the off-chain consensus state of the previous block and embedding it into subsequent blocks for cross-round consensus linking. Simultaneously, through candidate verification of candidate master nodes and fast consensus state confirmation based on hashing, the efficiency of the consensus process and system throughput are greatly improved. Thus, the communication complexity of traditional Byzantine fault-tolerant consensus is reduced from O(n²) to O(n), significantly improving the system's communication and computational efficiency. Attached Figure Description

[0042] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0043] Figure 1 A schematic diagram of the structure of a blockchain network is provided for this application;

[0044] Figure 2 A flowchart illustrating a blockchain consortium consensus method provided in this application;

[0045] Figure 3 A flowchart illustrating yet another blockchain consortium consensus method provided in this application;

[0046] Figure 4 A flowchart illustrating yet another blockchain consortium consensus method provided in this application;

[0047] Figure 5 A schematic diagram illustrating the specific implementation process of a block consortium consensus method provided in this application;

[0048] Figure 6a This application provides a schematic diagram of the structure of a blockchain consortium consensus system;

[0049] Figure 6b A flowchart illustrating yet another blockchain consortium consensus method provided in this application;

[0050] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0051] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0052] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0053] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same properties in the description of embodiments of this application. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0054] The blockchain consortium consensus method provided in this application can be applied in the field of blockchain technology, specifically to the consensus of data upload requests.

[0055] Traditional Byzantine fault-tolerant consensus methods result in a quadratic increase in the number of inter-node communications within each consensus cycle, i.e., O(n²). While this communication pattern can maintain the normal operation of the blockchain when the number of nodes is small, the network communication overhead increases rapidly as the number of nodes grows, which is particularly detrimental to resource-constrained Internet of Things (IoT). Secondly, traditional Byzantine fault-tolerant consensus algorithms typically do not support the dynamic addition or removal of nodes. As the number of nodes in the IoT continues to increase, the network size exhibits dynamic characteristics, requiring consensus methods to flexibly handle the addition of new nodes and the removal of old nodes without affecting system efficiency and security.

[0056] Furthermore, the Proof-of-Work (PoW) consensus method results in low blockchain transaction throughput and long block confirmation times. For example, the average block confirmation time for Bitcoin is 10 minutes, and a secure transaction confirmation typically requires waiting for 6 blocks (approximately 1 hour). This consensus method requires a large amount of computing power, leading to huge energy consumption. It does not take into account the scenario where blockchain nodes (such as IoT nodes) need to operate under extremely limited energy consumption due to limited computing power and power supply constraints.

[0057] In response, this application provides a block consortium consensus method that achieves consensus on a block through two rounds of consensus, thereby reducing the communication complexity of block consensus.

[0058] The block consortium consensus method of this application embodiment will be described in detail below with reference to the accompanying drawings.

[0059] Reference Figure 1 , Figure 1 This application provides a schematic diagram of the structure of a blockchain network, as shown in the embodiments. Figure 1As shown, the blockchain network includes multiple committee nodes and multiple consensus nodes. The multiple committee nodes include a master node and multiple candidate master nodes. That is, the committee is composed of one master node and multiple candidate master nodes. The distribution of the number of blockchain nodes of various types in the blockchain network is: 1 master node, c candidate master nodes, and n consensus nodes, where n is much larger than c. For example, the proportion of n to the total number of blockchain nodes (1+c+n) is greater than a preset proportion threshold. Optionally, the proportion threshold is equal to 90%. Specifically, the blockchain network provided in this application embodiment is a consortium blockchain network. This consortium blockchain network achieves higher performance, lower energy consumption, and stronger controllability by adopting a layered, multi-role node architecture and a two-round voting consensus mechanism.

[0060] In this embodiment, the master node is the core of the committee, responsible for generating and broadcasting blocks. It acts as the initiator in each round of consensus. Candidate master nodes are members of the committee, responsible for verifying and supervising the blocks generated by the master nodes, and are qualified to become master nodes. Consensus nodes are the majority of nodes in the blockchain network, responsible for participating in block verification and consensus voting, and are the foundation of consensus security.

[0061] Reference Figure 2 , Figure 2 A flowchart illustrating a block consortium consensus method provided in this application embodiment is shown below. Figure 2 As shown in the embodiments of this application, a blockchain consortium consensus method is provided, which is applied to, for example... Figure 1 The blockchain shown in this paper may include steps S201 to S207, which are described in detail below.

[0062] S201, The master node generates and broadcasts the first block.

[0063] In this embodiment, the height of the first block is called the first height. The first block includes a first block header and a first block body. The first block header includes a hash digest of the first data, and the first block body includes the first data. Specifically, in the current consensus cycle, the first block is created and initiated first by the master node. It is the starting point for triggering the subsequent two rounds of consensus processes. The first height refers to the specific position number of the first block in the blockchain, serving as the block order identifier. The block header also contains other metadata, such as a timestamp and a block height identifier.

[0064] In this embodiment, the hash digest of the first data is a fixed-length, unique digital fingerprint obtained by performing a preset cryptographic hash operation (such as SHA-256) on the first data, which is used to ensure the integrity of the first data.

[0065] In this embodiment, taking transaction data as an example, after the master node collects a certain number of transactions or reaches a specific time window, it packages these transactions into first data and calculates their hash value as a hash digest. Subsequently, the master node constructs a complete first block, the block header of which contains the hash digest. After construction, the master node broadcasts the first block through a preset network protocol.

[0066] For example, assuming the current highest block height in the blockchain is 100, the master node packages transaction data into a set Tx_Set_A, generating a block of height 101, which is the first block with a height of 101. The master node calculates the hash digest of Tx_Set_A (for example, it can be a hash value or a Merkle hash), fills it into the block header, and then broadcasts the first block.

[0067] S202. After receiving the first block, the candidate master node performs data authentication on the first block based on the first data and the first block header. If the data authentication is successful, the first block is broadcast.

[0068] In this embodiment, data authentication is the process of verifying the validity and correctness of the received block.

[0069] In this embodiment, data authentication includes digest hash authentication of the first data and the first block header, and may also include checking whether the transaction format in the first data is correct, whether the signature is valid, and whether it meets business rules such as double-spending checks.

[0070] S203. After receiving the first block, the consensus node performs data authentication on the first block based on the first data and the first block header. If the data authentication is successful, it broadcasts the first authentication message.

[0071] In this embodiment, the first authentication message is used to indicate that the first block has passed authentication.

[0072] In this embodiment, the first authentication message is a signal or statement issued by the consensus node to indicate that the consensus node has verified and passed the authentication of the first block. Specifically, this message does not contain the block data itself, but only the block identifier (such as height or block hash) and the signature of the consensus node.

[0073] S204. If a committee node receives a first authentication message from a consensus node exceeding a preset first ratio, it determines that the first block has passed the first round of consensus and stores the first round of consensus data of the first block locally.

[0074] In this embodiment, the first round of consensus data for the first block includes the received first authentication message and the node identifier of the corresponding consensus node, which is the set of evidence collected by the committee node to prove that the first block has passed the first round of consensus.

[0075] In one optional embodiment, each committee node (the master node and each candidate master node) independently listens to and counts the "first authentication messages" from the consensus nodes. When any committee node counts that the proportion of consensus nodes issuing authentication messages to the total number of consensus nodes in the network exceeds a first ratio, the committee node can determine that the first block has passed the first round of consensus. Subsequently, the committee node securely stores the hash digests (hash values ​​or Merkle roots) of all the first authentication messages collected, along with the corresponding consensus node identifiers, locally as the first round of consensus data.

[0076] In this embodiment, the first ratio is used to determine whether enough consensus nodes have been supported, for example, 50%, which means that more than half of the consensus nodes need to pass the consensus authentication of the first block.

[0077] In one alternative embodiment, the first ratio is not less than 50%, for example, the first ratio is equal to 50%.

[0078] It should be noted that the first round of consensus is the first stage of the consensus process, and the goal is to reach an agreement on the validity of the first block among most consensus nodes across the network.

[0079] S205, The master node generates and broadcasts the second block.

[0080] In this embodiment, the second block is a block generated immediately after the first block. The height of the second block is the second height, which is the first height plus 1, i.e., the height of the next block after the first block. In other words, the first block is the predecessor node of the second block.

[0081] In this embodiment, the second block includes a second block header and a second block body. The second block header includes a hash digest of the second data and a preceding consensus hash digest. The second block body includes the second data. The preceding consensus hash digest in the second block header is a hash digest of the first round of consensus data of the first block stored locally by the master node. The preceding consensus hash digest is a hash digest of the first round of consensus data of the first block stored locally by the master node, used to cryptographically bind the first round consensus result of the first block to the second block.

[0082] In this embodiment, after confirming that the first block has passed the first round of consensus, the master node begins generating the second block. When constructing the block header of the second block, the master node calculates the hash digest of the first round of consensus data stored locally and fills the second block header with this hash digest as the predecessor consensus hash value. This allows the second block to maintain the data chain not only through the hash pointing to the previous block, but also through the predecessor consensus hash value to maintain the consensus state.

[0083] Continuing the previous example, the master node generates a second block with a height of 102. This involves hashing the first round of consensus data (i.e., the first authentication message set from numerous consensus nodes) stored locally regarding block 101 to obtain Consensus_Hash_101, which is then inserted into the header of block 102.

[0084] S206. After receiving the second block, the candidate master node determines whether the hash digest of the first round consensus data of the first block stored locally by the candidate master node is consistent with the predecessor consensus hash digest in the header of the second block. If they are consistent, the consensus authentication is confirmed to be successful and the second block is broadcast.

[0085] In this embodiment, after receiving the second block, the candidate master node performs the following steps: extracts the predecessor consensus hash from the second block header, reads the first-round consensus data about the first block stored locally, and calculates its hash digest. The two hash digests are compared. If they match, it proves that the master node's claim that the first block has passed the first round of consensus is true and credible, because the consensus evidence seen by the master node and this candidate master node is consistent, which is equivalent to a fast and efficient secondary confirmation of the first-round consensus result. After passing this confirmation, the candidate master node broadcasts the second block, pushing the consensus process to continue.

[0086] It should be noted that this step refers to the network-wide synchronous confirmation of the consensus status of the first block, not just the authentication of transaction data in the second block. S207, the consensus node determines whether it has received a second block from a candidate master node exceeding the preset second ratio. If so, it determines that the first block has passed the second round of consensus.

[0087] In this embodiment, the second ratio is a preset threshold value used to determine whether sufficient candidate master node support has been obtained. For example, 50% means that more than half of the candidate master nodes need to support it.

[0088] In this embodiment, consensus nodes listen for second block broadcasts from candidate master nodes. When a consensus node determines that it has received the same second block from more than a second ratio (e.g., more than half) of the candidate master nodes, it can infer that a majority of candidate master nodes have verified and approved the consensus state of the first block (passed the first round of consensus). Based on this, the consensus node ultimately determines that the first block has passed the second round of consensus, and therefore, the first block is confirmed to be safe to be submitted to the local blockchain ledger.

[0089] In one alternative embodiment, the second ratio is not less than 50%, for example, the second ratio is equal to 50%.

[0090] As can be seen from the above technical solutions, the blockchain consortium consensus method provided in this application, as illustrated by the steps above, breaks down the consensus process into a first round of voting (S201-S204) targeting the "block data itself" and a second round of indirect confirmation (S205-S207) targeting the "consensus state of the previous block." The two rounds of consensus are tightly coupled using a hash chain. This demonstrates that by decomposing the traditional complex single-round voting into two highly dependent and simplified rounds of verification, and by embedding the hashed off-chain consensus state of the previous block into subsequent blocks for cross-round consensus linking, the communication complexity between nodes is significantly reduced, avoiding the overhead of multiple broadcasts of voting messages by all network nodes. Simultaneously, through candidate verification of candidate master nodes and fast consensus state confirmation based on hashing, the efficiency of the consensus process and system throughput are greatly improved. Thus, the communication complexity of traditional Byzantine fault-tolerant consensus is reduced from O(n²) to O(n), significantly improving the system's communication and computational efficiency.

[0091] Based on the above embodiments, referring to Figure 3 , Figure 3 This is a flowchart illustrating another blockchain consortium consensus method provided in an embodiment of this application. Figure 3 This illustrates the specific implementation process of a master node generating and broadcasting a target block. The target block can be any block, such as the first block or the second block. Correspondingly, the target data can be either the first data or the second data, such as... Figure 3 As shown, this method may include steps S301 to S305, which are described in detail below.

[0092] S301. After receiving the on-chain request for the target data, the master node determines the data type of the target data.

[0093] S302. If the data type of the target data is sensor data, the master node calculates the hash value of the target data as the hash digest of the target data.

[0094] S303. If the data type of the target data is transaction data, the master node calculates the Merkle root of the target data as the hash digest of the target data.

[0095] S304. The master node determines whether the predecessor block of the target block has passed the first round of consensus. If so, it obtains the hash value of the target consensus data of the predecessor block stored locally as the predecessor consensus hash digest.

[0096] S305. The master node generates a target block at the target height and broadcasts the target block at the target height.

[0097] In this embodiment, the target height is the height of the predecessor block plus 1, that is, the current block height. The block header of the target block includes the predecessor consensus hash digest and the hash digest of the target data.

[0098] It should be noted that the block header of any block, as the core metadata of the block, also includes information such as the hash of the preceding block, timestamp, nonce, and difficulty target. The block header forms a chain structure through hash links, ensuring data integrity and supporting the operation of the consensus method, ensuring that the blockchain is tamper-proof. The specific method for generating blocks can be found in existing technologies. In this embodiment, the block body of the target block includes the target data, taking transaction data as an example. The block body is the part of the block that stores transaction data, containing specific transaction information (such as transfers and contracts). A unique hash value (Merkel root) is generated through a Merkle tree structure and written into the block header, ensuring that the data is tamper-proof and efficiently verifying integrity.

[0099] Based on the above embodiments, referring to Figure 4 , Figure 4 This is a flowchart illustrating another blockchain consortium consensus method provided in an embodiment of this application. Figure 4 This illustrates the specific method by which any blockchain node (any consensus node or candidate blockchain node, denoted as the target node) performs data authentication on a target block, such as... Figure 4 As shown, this method may include steps S401 to S403, which are described in detail below.

[0100] S401, The target node determines the data type of the target data.

[0101] S402. If the data type of the target data is sensor data, the target block calculates the hash value of the target data, compares the hash value of the target data with the hash digest in the target block body, and if they match, the data authentication is confirmed to be successful.

[0102] S403. If the data type of the target data is transaction data, the target block calculates the Merkle root of the target data, compares the Merkle root of the target data with the hash digest in the target block body, and if they match, the data authentication is confirmed to be successful.

[0103] As can be seen from the above technical solutions, the blockchain consortium consensus method provided in this application addresses two types of data scenarios. Sensor data focuses more on its real-time security, such as data from mines or other critical industries, including temperature, humidity, and dust levels. This allows for real-time monitoring of the industrial environment, preventing safety accidents and protecting against post-accident data tampering, which would hinder investigations into the cause of the accident. Transaction data also has real-time requirements and is more sensitive than sensor data; therefore, transaction data needs to undergo consensus across the entire network and verification by all network nodes.

[0104] Reference Figure 5 , Figure 5 This application provides a schematic diagram illustrating the specific implementation process of a block consortium consensus method, as shown in the following example. Figure 5 As shown in the figure, the block consortium consensus method provided in this application embodiment may include steps S501 to S512, which are described in detail below.

[0105] S501, The master node generates and broadcasts the first block.

[0106] In this embodiment, the first block is the first height, and the first block includes a first block header and a first block body. The first block header includes a hash digest of the first data, and the first block body includes the first data.

[0107] Specifically, the method for the master node to generate and broadcast the first block can be found in the above embodiments.

[0108] It should be noted that after any block is successfully uploaded to the chain, the reputation score of each blockchain node is updated through the on-chain smart contract. If the candidate master node does not receive the block or heartbeat message broadcast by the master node within the preset time threshold, the candidate master node with the highest reputation score will take over as the new master node.

[0109] S502. After receiving the first block, if the first block header also includes the predecessor consensus hash digest, perform consensus authentication on the first block: determine whether the hash digest of the first round consensus data of the predecessor block of the first block stored locally by the candidate master node is consistent with the predecessor consensus hash digest in the first block header. If they are consistent, the consensus authentication is confirmed to be successful.

[0110] S503, Candidate Master Node, performs data authentication on the first block: Based on the first data and the first block header, performs data authentication on the first block.

[0111] Specifically, the method for candidate master nodes to perform data authentication on the first block based on the first data and the first block header can be found in the above embodiments.

[0112] S504. If consensus authentication and data authentication are successful, then broadcast the first block.

[0113] S505. After receiving the first block, the consensus node determines whether it has received the first block from a candidate master node that exceeds the second ratio. If so, it determines that the predecessor block of the first block has passed the second round of consensus.

[0114] In this embodiment, the first ratio is not less than 50%, and the second ratio is not less than 50%. For example, the first ratio is equal to 50%, and the second ratio is equal to 50%.

[0115] S506. The consensus node performs data authentication on the first block based on the first data and the first block header. If the data authentication is successful, it broadcasts the first authentication message.

[0116] Specifically, the consensus node performs data authentication on the first block based on the first data and the first block header. The specific method for this is described in the above embodiments.

[0117] S507. If a committee node receives a first authentication message from a consensus node exceeding a preset first ratio, it determines that the first block has passed the first round of consensus and stores the first round of consensus data of the first block locally.

[0118] In this embodiment, the first round of consensus data in the first block includes the received first authentication message and the node identifier of the corresponding consensus node.

[0119] S508, The master node generates and broadcasts the second block.

[0120] In this embodiment, the second block is the second height, which is the first height plus 1. The second block includes a second block header and a second block body. The second block header includes a hash digest of the second data and a predecessor consensus hash digest. The second block body includes the second data. The predecessor consensus hash digest in the second block header is a hash digest of the first round of consensus data of the first block stored locally by the master node.

[0121] Specifically, the method for the master node to generate and broadcast the second block can be found in the above embodiments.

[0122] S509. After receiving the second block, the candidate master node performs consensus authentication on the second block: determine whether the hash digest of the first round consensus data of the first block stored locally by the candidate master node is consistent with the predecessor consensus hash digest in the header of the second block. If they are consistent, the consensus authentication is confirmed to be successful.

[0123] S510, Candidate master node performs data authentication on the second block: Based on the second data and the second block header, perform data authentication on the second block.

[0124] Specifically, candidate master nodes are based on the second data and the second block header.

[0125] In this embodiment, the specific method for performing data authentication on the second block can be found in the embodiments described above.

[0126] S511. If consensus authentication and data authentication are successful, then broadcast the second block.

[0127] S512. The consensus node determines whether it has received a second block from a candidate master node that exceeds the preset second ratio. If so, it determines that the first block has passed the second round of consensus.

[0128] In this embodiment, once the first block passes the second round of consensus, the block is further added to the blockchain. Specifically, taking transaction data as an example, the transaction data is packaged into a block, verified through a consensus method, and then encrypted and linked to the end of the blockchain, forming an immutable chain structure. Hash encryption ensures data uniqueness, and nodes synchronously maintain the decentralized ledger, achieving transparent and trustworthy distributed storage.

[0129] As can be seen from the above technical solution, the block consortium consensus method provided in this application adopts a chain structure and confirms each block through two rounds of consensus. The first round achieves preliminary consensus through sequential transmission between nodes, and the second round confirms the consensus result through implicit verification. This approach can reduce communication latency while ensuring the correctness of the blocks.

[0130] Furthermore, this application reconstructs the message passing method, reducing the communication complexity of traditional Byzantine fault-tolerant consensus from O(n²) to O(n), significantly improving the system's communication and computational efficiency, and ensuring that the system can still operate under high load.

[0131] Furthermore, this application allows nodes to initiate a preliminary consensus process for subsequent blocks while confirming the current block, thus enabling consensus for the next block to be advanced while one block is being verified, thereby enhancing the algorithm's foresight.

[0132] In summary, addressing the limitations of traditional Byzantine fault-tolerant consensus algorithms in terms of communication complexity and energy efficiency, as well as the inherent drawbacks of traditional blockchain consensus methods such as high energy consumption, token dependence, and potential centralization risks, this application significantly improves the communication efficiency between nodes without sacrificing the system's decentralization and Byzantine fault-tolerant characteristics, making it particularly suitable for the diverse application scenarios in the Internet of Things (IoT) environment.

[0133] The above describes a block consortium consensus method provided by the embodiments of this application. The following describes the apparatus for implementing the above-described block consortium consensus method.

[0134] Please see Figure 6a , Figure 6a This is a schematic diagram illustrating the specific structure of a blockchain consortium consensus system provided in an embodiment of this application. For example... Figure 6a As shown, the blockchain consortium consensus system 600 includes: a data transmission module 601, a block request module 602, a block candidate verification module 603, a data consensus module 604, a block confirmation module 605, and a block on-chain module 606.

[0135] See Figure 6b , Figure 6b A flowchart illustrating another consortium consensus method provided in this application embodiment, combined with... Figure 6bThis section introduces the functions of each module in the blockchain consortium consensus system:

[0136] (1) The data transmission module is used to perform data transmission. The data transmission process includes:

[0137] Sensor nodes transmit data to master node P and candidate master nodes CP (taking 5 CP nodes as an example), while the requesting user broadcasts the data requested to be uploaded to the blockchain (e.g., the first data and the second data) to all blockchain nodes in the blockchain system. For sensors capable of calculating hash values, the sensor data and its hash value can be directly transmitted to P and CP, meaning that nodes do not need to calculate the hash digest of the sensor data locally in real time.

[0138] Among them, P and CP nodes are committee nodes that store the entire block (block header and block body), while consensus nodes CS only need to store the block header.

[0139] In this embodiment, if P experiences a network failure or is attacked, the system will re-elect P, selecting a candidate master node as the new master node based on node reputation scores and a random number. Each candidate master node (CP) has a timer. When the CP node is in the block candidate verification state, the CP stops timing. If the CP is waiting to verify a new block state, the CP will restart timing. Each candidate master node has a timeout period. During normal system operation, the CP will receive heartbeat messages from the master node within the timeout period. After successfully receiving the heartbeat message, the CP will reset the timeout timer. If the master node does not broadcast a block or verification message within the timeout period, the CP with the highest score will become the new master node P and package the relevant information into a block. If P times out and initiates a block request, the candidate master node CP with the highest reputation score will become the new master node and package the relevant information into a block. If P engages in malicious behavior, such as data tampering, honest candidate master nodes and consensus nodes will reject the illegal block after verification. After receiving rejection messages from a majority of other nodes, P will repackage the transaction information into a block.

[0140] (2) The block request module is used to execute block requests. The block request process includes:

[0141] P collects sensor data and transaction data, which are in a pending state before being included in a new block. For user transaction data, P verifies the legality of each transaction, ensuring it complies with network rules, including verifying transaction signatures and ensuring the sender has sufficient balance. Once a transaction is verified, P creates a new block (i). The content of block (i) includes the hash value of the previous block, all selected transactions, timestamps, and other information. After block creation, P broadcasts block (i) to CP, which verifies block (i) and decides whether to add it to its local blockchain copy.

[0142] (3) The block candidate verification module is used to perform block candidate verification. The block candidate verification process includes:

[0143] Let block(i) = (header(i), data(i)) represent an unverified block at height i, and BLOCK(i) represent a verified block at height i. The CP verifies block(i) from P. The basic verification criterion is to verify the predecessor consensus hash digest Prev_Hash stored in header(i). The CP calculates the hash value H(II) of BLOCK(i−1). If H(II) ≠ Prev_Hash, it indicates that the data in block(i) may have been tampered with, and the CP rejects the current block (i). The CP calculates the Merkle root of the data and compares it with the Merkle root in block(i). If the CP fails to receive block(i) due to network failures or other factors, it can request it from other nodes in the committee. If all the above verification processes pass, the CP sends an authentication message to the CS.<CP−validate> .

[0144] (5) The block confirmation module is used to perform block confirmation. The block confirmation process includes:

[0145] This consensus method completes the first round of consensus during the block confirmation phase. The committee collects block verification messages from the CS (Confirmation Controller). This consensus method takes into account the Byzantine behavior of the CS: a CS may intentionally not broadcast the authentication message for block(i) (intentionally not respond), or may be unable to send the authentication message due to a CS crash. During this phase, the committee follows the majority principle: as long as the committee receives more than 50% of the authentication messages from the CS, either P or CP can accept block(i).

[0146] (6) The block uploading module is used to perform block uploading. The block uploading process includes:

[0147] If the current block (i) is valid, it is accepted by the committee during block confirmation, but it still cannot be officially added to the chain. The first round of consensus avoids pairwise communication between all nodes in traditional Byzantine fault tolerance. However, this also means that each node in the committee can only know the local verification result of block (i) and cannot know whether block (i) has been accepted by the entire network. Therefore, the nodes cannot reach a consensus. In the second round of consensus, P broadcasts the next block (i+1) to the committee. This block contains the hash value of block (i) in its block header. Referring to the block candidate verification, CP checks whether H(block(i)) in the block header of block (i+1) is the same as the hash value of its local block (i) consensus authentication data in the first round of consensus. CS receives enough verification messages from the committee. If the locally valid block (i) also receives majority authentication from the committee, then block (i) can be officially added to the chain.

[0148] In summary, compared to traditional BFT (Byzantine Fault Tolerance) consensus methods, the classic PBFT (Practical Byzantine Fault Tolerance) consensus method includes three core phases: "pre-preparation," "preparation," and "commit." In the "pre-preparation" phase, the designated master node broadcasts a pre-preparation message to other replica nodes, requiring N-1 rounds of communication. In the "preparation" phase, if each replica node agrees to the master node's proposal request, it broadcasts a preparation message to all other replicas, thus requiring N(N-1) rounds of communication, or N²-N. In the "commit" phase, once each replica reaches the ready state, it needs to broadcast a commit message to other replicas, also requiring N²-N rounds of communication.

[0149] This application presents a consensus method for blockchain that is fault-tolerant to Byzantine nodes. In this method, other nodes need to vote on the blocks published by the leader node, and the blocks have only two states: 0 and 1 (true value is 1, false value is 0). Before being added to the blockchain, the blocks need to be verified by the nodes. Only when more than 50% of the nodes agree on the block can it be officially packaged into the blockchain.

[0150] Compared to the PBFT algorithm, which tolerates 1 / 3 of the total number of nodes, PBFT considers malicious nodes, i.e., complex situations where nodes send inconsistent messages or do not send messages at all.

[0151] This application adopts a multi-round verification and voting method for nodes, which prevents nodes from sending inconsistent messages that could interfere with the consensus decision-making of nodes. It uses reputation points as an incentive, does not rely on powerful computing power, and still maintains 1 / 2 fault tolerance.

[0152] Furthermore, this application has c CP nodes and n CS nodes, where c is a fixed constant value, and c is much smaller than n. During the block request phase, the number of communication rounds is c; during the block candidate verification phase, the number of communication rounds is cn; and during the data consensus phase, the number of communication rounds is (c+1)n. Therefore, the number of communication rounds in this application is [c+cn+(c+1)n], reducing communication overhead and complexity.

[0153] This application also provides an electronic device. Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, with reference to... Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0154] like Figure 7 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. When the electronic device is powered on, the RAM 703 also stores various programs and data required for the operation of the electronic device. The processing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0155] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 708 including, for example, memory cards, hard drives, etc.; and communication devices 709. Communication device 709 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0156] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the block consortium consensus methods provided in this application.

[0157] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device is able to implement any of the block consortium consensus methods provided in this application.

[0158] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0160] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0161] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A block alliance consensus method, characterized in that, The application is applied to a blockchain network, the blockchain network includes a plurality of committee nodes and a plurality of consensus nodes, the plurality of committee nodes include a master node and a plurality of candidate master nodes, and the blockchain alliance consensus method includes: The master node generates and broadcasts a first block; wherein the first block is of a first height, the first block includes a first block header and a first block body, the first block header includes a hash digest of first data, and the first block body includes the first data; After the candidate master node receives the first block, the candidate master node performs data authentication on the first block based on the first data and the first block header, and if the data authentication is passed, the candidate master node broadcasts the first block; After the consensus node receives the first block, the consensus node performs data authentication on the first block based on the first data and the first block header, and if the data authentication is passed, the consensus node broadcasts a first authentication message, and the first authentication message is used to indicate that the first block passes the authentication; If the committee node receives more than a preset first ratio of the first authentication messages sent by the consensus nodes, the committee node determines that the first block passes the first round of consensus, locally stores the first round of consensus data of the first block, and the first round of consensus data of the first block includes the received first authentication messages and the node identifiers of the corresponding consensus nodes; The master node generates and broadcasts a second block; the second block is of a second height, the second height is 1 more than the first height, the second block includes a second block header and a second block body, the second block header includes a hash digest of second data and a predecessor consensus hash digest, and the second block body includes the second data; the predecessor consensus hash digest in the second block header is a hash digest of the first round of consensus data of the first block locally stored by the master node; After the candidate master node receives the second block, the candidate master node determines whether the hash digest of the first round of consensus data of the first block locally stored by the candidate master node is consistent with the predecessor consensus hash digest in the second block header, and if so, determines that the consensus authentication is passed, and broadcasts the second block; The consensus node determines whether to receive more than a preset second ratio of the second blocks sent by the candidate master nodes, and if so, determines that the first block passes the second round of consensus. 2.The block alliance consensus method according to claim 1, characterized in that, The master node generates and broadcasts the first block, including: After the master node receives the on-chain request of the first data, the master node determines the data type of the first data; If the data type of the first data is sensor data, the master node calculates the hash value of the first data as the hash digest of the first data; If the data type of the first data is transaction data, the master node calculates the Merkle root of the first data as the hash digest of the first data; The master node generates the first block of the first height and broadcasts the first block of the first height. 3.The block alliance consensus method of claim 2, wherein, The target node performs data authentication on the first block based on the first data and the first block header, including: The target node determines the data type of the first data; If the data type of the first data is sensor data, the target node calculates a hash value of the first data, compares the hash value of the first data with the hash digest in the first block body, and determines that data authentication is passed if they are consistent; If the data type of the first data is transaction data, the target node calculates a Merkle root of the first data, compares the Merkle root of the first data with the hash digest in the first block body, and determines that data authentication is passed if they are consistent; The target node includes the candidate master node and the consensus node. 4.The block alliance consensus method of claim 1, wherein, The first ratio is not less than 50%, and the second ratio is not less than 50%. 5.The block alliance consensus method of claim 1, wherein, After receiving the first block, the candidate master node performs data authentication on the first block based on the first data and the first block header, and broadcasts the first block if data authentication is passed, including: After receiving the first block, the candidate master node performs: If the first block header further includes a predecessor consensus hash digest, the candidate master node determines whether the hash digest of the first round consensus data of the predecessor block of the first block stored locally is consistent with the predecessor consensus hash digest in the first block header, and determines that consensus authentication is passed if they are consistent; and performs data authentication on the first block based on the first data and the first block header; If consensus authentication and data authentication are passed, the first block is broadcast. 6.The block alliance consensus method of claim 5, wherein, After receiving the first block, the consensus node performs data authentication on the first block based on the first data and the first block header, and broadcasts a first authentication message if data authentication is passed, including: After receiving the first block, the consensus node performs: Determines whether the first block issued by the candidate master node exceeding the second ratio is received, and determines that the predecessor block of the first block passes the second round of consensus if yes; Performs data authentication on the first block based on the first data and the first block header, and broadcasts the first authentication message if data authentication is passed. 7.The block alliance consensus method of claim 1, wherein, The block alliance consensus method further includes: After any block is successfully chained, the reputation points of each blockchain node are updated by a smart contract on the chain; If the candidate master node does not receive the block or heartbeat message broadcast by the master node within a preset time threshold, the candidate master node with the highest reputation points replaces the master node and becomes a new master node.

8. A blockchain network, characterized in that, The blockchain network includes a committee node and a plurality of consensus nodes, the committee node includes a master node and a plurality of candidate master nodes; the blockchain network is used to execute the block alliance consensus method according to any one of claims 1 to 7.

9. A computer program product, characterised in that, The computer readable instructions, when executed on an electronic device, cause the electronic device to implement the block alliance consensus method according to any one of claims 1 to 7.

10. An electronic device, comprising: The memory is used to store computer programs; The memory is used to store computer programs; The processor is configured to execute the computer program to enable the electronic device to implement the block federation consensus method according to any one of claims 1 to 7. The processor is configured to execute the computer program to enable the electronic device to implement the block federation consensus method according to any one of claims 1 to 7.

Images