Block consensus method, electronic device and storage medium

Abstract

The present application discloses a block consensus method, an electronic device, and a storage medium. The method includes: receiving first messages sent by at least one second node, verifying the Merkle proofs of the first shards in each first message, determining at least one target shard for which the Merkle proof verification is successful, decoding the at least one target shard to generate a second micro-block, and if the second micro-block matches the first micro-block successfully, determining that the second node and the first node reach a consensus on the first micro-block. In this way, according to the present application, the first node can decode the at least one target shard to generate a corresponding second micro-block, so as to achieve consensus by matching the second micro-block with the first micro-block, and it is not necessary to obtain the data of the complete first micro-block to achieve consensus. Therefore, the method of the present application can reduce the blocking probability caused by data loss of a single node during the consensus process.

Description

Technical Field

[0001] This application belongs to the technical field of data processing, and particularly relates to a block consensus method, an electronic device, and a storage medium. Background Art

[0002] In a blockchain, a consensus mechanism is required to ensure data consistency among nodes, and the consensus mechanism needs to perform data interaction through each node to achieve the consensus process.

[0003] When the nodes participating in the consensus are malicious nodes, it is possible that a malicious node fails to transmit complete transaction data, which may cause the consensus process to be restricted and affect the efficiency and effectiveness of block consensus.

[0004] Therefore, there is an urgent need for a method to reduce the blocking probability caused by data loss of a single node during the block consensus process. Summary of the Invention

[0005] The embodiments of this application provide a block consensus method, an electronic device, and a storage medium, which can reduce the blocking probability caused by data loss of a single node during the block consensus process.

[0006] In a first aspect, the embodiments of this application provide a block consensus method, which is applied to a first node, and the method includes:

[0007] Receiving at least one first message, where the at least one first message is sent by at least one second node other than the first node, and each first message is generated when a micro-block retrieval event of a preset block is triggered by the second node and the second node stores a first shard of the first micro-block in the preset block. The first message includes an identifier of the first micro-block, the first shard, and a Merkle proof of the first shard; the first shard is encoded by a node corresponding to the first micro-block for the first micro-block;

[0008] Verifying the Merkle proofs of the first shards in each of the first messages to determine at least one target shard for which the Merkle proof verification is successful;

[0009] Decoding the at least one target shard to generate a second micro-block;

[0010] Based on the identifier of the first micro-block in the at least one first message, matching the second micro-block with the corresponding first micro-block;

[0011] If the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

[0012] In one embodiment, matching the second micro-block with the corresponding first micro-block based on the identifier of the first micro-block in the at least one first message includes: encoding the second micro-block into at least one second shard, determining the identifier of the second micro-block according to the at least one second shard; matching the identifier of the second micro-block with the identifier of the first micro-block; before, if the second micro-block matches the first micro-block successfully, and the second node and the first node reach a consensus on the first micro-block, the method further includes: if the identifier of the second micro-block matches the identifier of the first micro-block successfully, determining that the second micro-block matches the first micro-block successfully.

[0013] In one embodiment, before receiving the at least one first message, the method further includes: if the first node is the primary node of the current view, constructing a target certificate according to the obtained target message from the at least one second node; if the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; based on the target certificate, constructing a block according to the identifiers of the first micro-blocks newly generated by each node; broadcasting the proposal message generated according to the block to the at least one second node, where the second node is used to receive the proposal message sent by the primary node, and when the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, determining the grandparent block as the preset block and triggering the micro-block retrieval event of the grandparent block.

[0014] In one embodiment, before receiving the at least one first message, the method further includes: if the first node is a non-primary node of the current view, receiving the proposal message sent by the primary node of the current view, where the proposal message is generated by the primary node based on the constructed block, and the block is constructed by the primary node based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node, and the target certificate is obtained by the primary node according to the target message, if the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; verifying the validity of the proposal message; when the validity verification of the proposal message passes, if the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, determining the grandparent block as the preset block and triggering the micro-block retrieval event of the grandparent block.

[0015] In one embodiment, before receiving at least one first message, the method further includes: encoding a first micro-block corresponding to the first node, encoding the first micro-block into at least one first shard; generating an identifier corresponding to the first micro-block and Merkle proofs for each of the at least one first shards according to the at least one first shard; sending a second message to the at least one second node, the second message including the identifier of the first micro-block, the at least one first shard, the Merkle proofs corresponding to the at least one first shards, and an availability certificate of a previous micro-block of the first micro-block; the second node is configured to perform validity verification on the second message, if the validity verification of the second message is successful, store the second message, and sign the identifier of the first micro-block in the second message to generate a partial signature, and send a third message to the first node, the third message including the identifier of the first micro-block and the partial signature; receiving the third message from the at least one second node, aggregating the partial signatures in the third message of the at least one second node into an aggregated proof; and forming an availability certificate of the first micro-block according to the aggregated proof and the identifier of the first micro-block in the third message of the at least one second node.

[0016] In a second aspect, an embodiment of the present application provides a block consensus method, which is applied to a second node, and the method includes:

[0017] In the case of triggering a micro-block retrieval event of a preset block, for each first micro-block in the preset block, if a first shard corresponding to the first micro-block is stored, broadcast a first message to at least one first node; the first node is a node other than the second node, each first micro-block in the preset block comes from a different node, the first shard corresponding to the first micro-block is encoded by the corresponding node for the first micro-block, and the first message includes the identifier of the first micro-block, the first shard corresponding to the first micro-block, and the Merkle proof corresponding to the first shard;

[0018] The first node is configured to receive the first message from at least one of the second nodes, verify the Merkle proofs corresponding to each of the first shards in the received first message, determine at least one target shard for which the Merkle proof verification is successful, decode the at least one target shard to generate a second micro-block, and match the second micro-block with the first micro-block based on the identifier of the first micro-block in at least one received first message. If the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

[0019] In some embodiments, when triggering a micro-block retrieval event for a preset block, for each first micro-block in the preset block, if a first shard corresponding to the first micro-block is stored, before broadcasting a first message to at least one first node, the method further includes: if the second node is the primary node of the current view, constructing a target certificate according to the target message obtained from the at least one first node; if the target message is a voting message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is a combined legal certificate; based on the target certificate, constructing a block according to the identifiers of the first micro-blocks newly generated by each node; broadcasting a proposal message generated according to the block to the at least one first node, where the first node is used to receive the proposal message sent by the primary node, and when the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, the grandparent block is determined as the preset block, and a micro-block retrieval event for the grandparent block is triggered.

[0020] In some embodiments, when triggering a micro-block retrieval event for a preset block, for each first micro-block in the preset block, if a first shard corresponding to the first micro-block is stored, before broadcasting a first message to at least one first node, the method further includes: if the second node is a non-primary node of the current view, receiving a proposal message sent by the primary node of the current view, where the proposal message is generated by the primary node based on a constructed block, the block is constructed by the primary node based on a target certificate according to the identifiers of the first micro-blocks newly generated by each node, and the target certificate is obtained by the primary node according to the target message, if the target message is a voting message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is a combined legal certificate; verifying the validity of the proposal message; when the validity verification of the proposal message passes, if the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, the grandparent block is determined as the preset block, and a micro-block retrieval event for the grandparent block is triggered.

[0021] In some embodiments, when triggering a micro-block retrieval event of a preset block, for each first micro-block in the preset block, if there is a first shard corresponding to the first micro-block stored, before broadcasting a first message to at least one first node, the method further includes: encoding the first micro-block of the second node, encoding the first micro-block into at least one first shard; generating an identifier corresponding to the first micro-block and a Merkle proof for each of the at least one first shards according to the at least one first shards; sending a second message to the at least one first node, the second message including the identifier of the first micro-block, the at least one first shards, the Merkle proof corresponding to the at least one first shards, and an availability certificate of the previous micro-block of the first micro-block; the first node is configured to perform validity verification on the second message, if the validity verification of the second message is successful, store the second message, and sign the identifier of the first micro-block in the second message to generate a partial signature, and send a third message to the second node, the third message including the identifier of the first micro-block and the partial signature; receiving the third message from the at least one first node, aggregating the partial signatures in the third message of the at least one first node into an aggregated proof; and constituting an availability certificate of the first micro-block according to the aggregated proof and the identifier of the first micro-block in the third message of the at least one first node.

[0022] In a third aspect, an embodiment of the present application provides an electronic device, the device includes: a processor and a memory storing computer program instructions;

[0023] When the processor executes the computer program instructions, the block consensus method described in the first aspect or the second aspect is implemented.

[0024] In a fourth aspect, an embodiment of the present application provides a computer storage medium, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the block consensus method described in the first aspect or the second aspect is implemented.

[0025] A block consensus method, an electronic device, and a storage medium according to an embodiment of the present application receive at least one first message sent by at least one second node other than the first node. Each first message is generated when a micro-block retrieval event of a preset block is triggered at the second node and the second node stores a first shard of the first micro-block in the preset block. The first message includes an identifier of the first micro-block, the first shard, and a Merkle proof of the first shard. The first shard is encoded from the first micro-block by the node corresponding to the first micro-block. Verify the Merkle proofs of the first shards in each first message to determine at least one target shard for which the Merkle proof verification is successful. Decode at least one target shard to generate a second micro-block. Based on the identifier of the first micro-block in at least one first message, match the second micro-block with the corresponding first micro-block. If the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block. In this way, by regarding the first micro-blocks of each node as shared resources, the first node can obtain the first messages corresponding to the first micro-blocks from multiple other second nodes, which can improve the probability of obtaining data of the first micro-block. Secondly, by encoding the first micro-block into multiple first shards, the first node can decode at least one target shard to generate the corresponding second micro-block, and then achieve consensus through the matching of the second micro-block and the first micro-block, without the need to obtain the complete data of the first micro-block to achieve consensus. Even if a certain node has data missing, the consensus process can still be advanced. Therefore, the method of the present application can reduce the blocking probability caused by data missing of a single node during the consensus process. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0027] Figure 1 is a flowchart of a block consensus method applied to a first node provided by an embodiment of the present application;

[0028] Figure 2 is a flowchart of a block consensus method applied to a second node provided by an embodiment of the present application;

[0029] Figure 3 is a structural block diagram of a block consensus device including a first node provided by an embodiment of the present application;

[0030] Figure 4 is a structural block diagram of a block consensus device including a second node provided by an embodiment of the present application;

[0031] Figure 5 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0032] The features of various aspects of the present application and exemplary embodiments will be described in detail below. To make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than limiting the present application. For those skilled in the art, the present application can be implemented without some of these specific details. The following description of the embodiments is only intended to provide a better understanding of the present application by showing examples of the present application.

[0033] It should be noted that, in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, the elements defined by the statement "including..." do not exclude the presence of additional identical elements in the process, method, article or device including the said elements.

[0034] Although some existing synchronous Byzantine consensus protocols have solved the system performance and security problems to a certain extent, in the presence of malicious nodes, they still face the following challenges: First, the completeness problem. The system may cause some nodes to fail to receive some blocks due to malicious nodes or the asynchronous characteristics of the network, affecting the consistency of the system. Second, the micro-block availability problem. In the existing protocols, the micro-blocks in the proposals cannot guarantee availability to all honest nodes, increasing the delay of the consensus process.

[0035] Third, the bandwidth adaptability problem. The existing protocols usually assume that the network environment resources are balanced and stable, but in practice, the network bandwidth conditions are usually uneven and fluctuate greatly, affecting the system performance. Fourth, the transaction order preservation problem. The existing protocols do not fully consider the importance of the transaction order in the micro-blocks, which may lead to damage to the legality of the transactions.

[0036] To solve the related technical problems, an embodiment of the present application provides a block consensus method, apparatus, device, computer storage medium and computer program product. First, the block consensus method provided by the embodiment of the present application will be introduced below.

[0037] Figure 1 The figure shows a schematic flow chart of a block consensus method applied to a first node provided by an embodiment of the present application. As Figure 1 shown, with the first node as the execution subject, the method specifically includes the following steps S101-S105.

[0038] Step S101: Receive at least one first message.

[0039] Step S102: Verify the Merkle proofs of the first shards in each first message, and determine at least one target shard for which the Merkle proof verification is successful.

[0040] Step S103: Decode at least one target shard to generate a second micro-block.

[0041] Step S104: Based on the identifiers of the first micro-blocks in at least one first message, match the second micro-block with the corresponding first micro-block.

[0042] Step S105: If the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

[0043] The above at least one first message is sent by at least one second node other than the first node, and each second node other than the first node can send the first message to the first node.

[0044] For example, the nodes include node A, node B, and node C in total. Node A, node B, and node C can all be used as the first node. If node A is the first node, then for node A, node B and node C are the second nodes. If node B is the first node, then for node B, node A and node C are the second nodes. If node C is the first node, then for node C, node A and node B are the second nodes.

[0045] The above nodes may refer to devices participating in the blockchain network, such as servers or personal computers, etc.

[0046] Each first message is a message generated by a second node when the micro-block retrieval event of a preset block is triggered and the second node stores the first shard of the first micro-block in the preset block. That is, for each second node, when the micro-block retrieval event of a preset block is triggered and the second node stores the first shard of the first micro-block in the preset block, the second node sends the corresponding first message to the first node.

[0047] The above first message includes the identifier of the first micro-block, the first shard, and the Merkle proof of the first shard.

[0048] The above first shard is encoded by a node corresponding to the first micro-block for the first micro-block.

[0049] In step S101, the form of the above first message can be determined by a specific protocol. The form of the first message is binary data or text data. For a binary protocol, the form of the first message is binary data, and the binary protocol can be or a custom protocol, etc. For a text protocol, the form of the first message is text data, and the text protocol can be HTTP / REST or HTTP / JSON, etc.

[0050] The first node can receive the first message by listening to a network port and decode the first message according to the protocol to obtain the content of the first message.

[0051] In step S102, the first node can verify the Merkle proof of the first shard in each first message through a preset verification algorithm. The preset verification algorithm can be at least one of a bottom-up hash calculation algorithm, a bit operation optimization algorithm using an index, a variant and optimization algorithm of verification, etc. The preset verification algorithm can also be a Merkle proof verification algorithm in the Merkle tree algorithm .

[0052] Each of the at least one target shards is different.

[0053] The number of the at least one target shards can be a preset number, and the preset number can be set according to requirements. The preset number can be , where f represents the maximum number of faulty nodes allowed by the system.

[0054] In step S103, the first node can use a preset decoding algorithm to decode at least one target shard to generate a second micro-block. The preset decoding algorithm can be the algorithm by which a node encodes a first micro-block to obtain a first shard. For example, an erasure code algorithm (such as Reed-Solomon), and the preset decoding algorithm can be a decoding algorithm in the erasure code algorithm .

[0055] The first node can reconstruct the complete shard data according to at least one target shard by using an erasure code algorithm, and decode the restored shard data into a second micro-block in a preset protocol format, so as to implement decoding at least one target shard by using an erasure code algorithm to generate a second micro-block. The above preset protocol format can be the protocol format used by the node.

[0056] In some embodiments, the above step S104 may include but is not limited to the following steps:

[0057] The first node encodes the second micro-block into at least one second shard, and determines the identifier of the second micro-block according to the at least one second shard.

[0058] In one implementation, the first node may use a preset encoding algorithm to encode the second micro-block into at least one second shard. The preset encoding algorithm may be an erasure code algorithm, and the preset encoding algorithm may be an encoding algorithm in the erasure code algorithm. 。

[0059] The above identifier may be a Merkle root. Specifically, determining the identifier of the second micro-block according to the at least one second shard may be to construct a Merkle tree corresponding to the second micro-block with the at least one second shard as leaf nodes, and generate the Merkle root corresponding to the Merkle tree according to the Merkle proof generation algorithm to obtain the identifier of the second micro-block.

[0060] The first node matches the identifier of the second micro-block with the identifier of the first micro-block.

[0061] In one implementation, the first node may achieve the matching by calculating the similarity between the identifier of the second micro-block and the identifier of the first micro-block.

[0062] In one implementation, when the similarity between the identifier of the second micro-block and the identifier of the first micro-block reaches the similarity threshold, the first node determines that the matching is successful. The similarity threshold may be 100%.

[0063] In some embodiments, before the second node and the first node reach a consensus on the first micro-block, the following steps are further included:

[0064] If the identifier of the second micro-block matches the identifier of the first micro-block successfully, it is determined that the second micro-block matches the first micro-block successfully.

[0065] In the embodiments of the present application, by regarding the first micro-blocks of each node as shared resources, the first node can obtain the first messages corresponding to the first micro-blocks from multiple other second nodes, which can improve the probability of obtaining data of the first micro-block. Secondly, by encoding the first micro-block into multiple first shards, the first node can decode at least one target shard to generate the corresponding second micro-block, so as to achieve consensus through the matching of the second micro-block and the first micro-block. It is not necessary to obtain the complete data of the first micro-block to achieve consensus. Even if a certain node has data loss, the consensus process can still be advanced. Therefore, the method of the present application can reduce the blocking probability caused by data loss of a single node during the consensus process.

[0066] In some embodiments, before step S101, the following steps may also be included but are not limited to:

[0067] If the first node is the primary node of the current view, the first node constructs a target certificate based on the obtained target messages from at least one second node.

[0068] If the target message is a vote message, the target certificate is the quorum certificate (QC) qc; if the target message is a new view message, the target certificate is the aggregated quorum certificate aggQc.

[0069] The above-mentioned vote messages are the voting opinions of the corresponding second nodes on the view change.

[0070] The above-mentioned new view messages are the voting opinions of the corresponding second nodes on entering the next view.

[0071] In one implementation, the first node constructs a target certificate based on the obtained target messages from at least one second node by deriving the target certificate from the target messages of at least one second node.

[0072] The first node constructs a block based on the target certificate and the identifiers of the first micro-blocks newly generated by each node.

[0073] Each node includes the first node and at least one second node.

[0074] In one implementation, the first node constructs a block based on the identifiers of the first micro-blocks newly generated by each node by calling and obtaining the identifiers of the first micro-blocks newly generated by each node based on the target certificate, so as to construct a block based on the target certificate and the identifiers of the first micro-blocks newly generated by each node.

[0075] The first node broadcasts the proposal message generated based on the block to at least one second node.

[0076] The above-mentioned proposal message may include at least one of the proposal type, proposal data, proposer identity, block height / round, timestamp, signature, and proof.

[0077] The second node is used to receive the proposal message sent by the primary node. When the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, the grandparent block is determined as the preset block, and the micro-block retrieval event of the grandparent block is triggered.

[0078] In some embodiments, before step S101, it may further include but is not limited to the following steps:

[0079] If the first node is a non-primary node of the current view, the first node receives the proposal message sent by the primary node of the current view.

[0080] The above proposal message is generated by the master node based on the formed block, and the block is formed by the master node based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node. The target certificate is obtained by the master node according to the target message. If the target message is a voting message, the target certificate is a legal certificate. If the target message is a new view message, the target certificate is an aggregated legal certificate.

[0081] The above target message is sent by at least one non-master node other than the master node, and the non-master node is a node other than the master node.

[0082] The first node verifies the validity of the proposal message.

[0083] In one implementation, the first node can verify the validity of the proposal message by verifying at least one of the proposer identity, the proposal data structure, the proposal content, etc. If at least one of verifying the proposer identity, the proposal data structure, the proposal content, etc. passes the verification, it is determined that the validity verification of the proposal message passes.

[0084] When the validity verification of the proposal message passes, if the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, the first node determines the grandparent block as the preset block and triggers the micro-block retrieval event of the grandparent block.

[0085] In some embodiments, before step S101, it may further include but is not limited to the following steps:

[0086] The first node encodes the first micro-block corresponding to the first node and encodes the first micro-block into at least one first shard.

[0087] In one implementation, the first node can use a preset encoding algorithm to encode the first micro-block into at least one first shard. The preset encoding algorithm can be an erasure code algorithm (such as Reed-Solomon), and the preset encoding algorithm can be an encoding algorithm in the erasure code algorithm .

[0088] The first node generates an identifier corresponding to the first micro-block and Merkle proofs for each of the at least one first shards based on the at least one first shard.

[0089] In one implementation, the above identifier can be the Merkle root. Specifically, to determine the identifier of the first micro-block based on the at least one first shard, a Merkle tree corresponding to the first micro-block is constructed with the at least one first shard as leaf nodes, and the Merkle root corresponding to the Merkle tree is generated according to the Merkle proof generation algorithm to obtain the identifier of the first micro-block, and the Merkle proofs for each of the at least one first shards are generated according to the Merkle proof generation algorithm.

[0090] The first node sends a second message to at least one second node.

[0091] The above-mentioned second message includes the identifier of the first micro-block, at least one first shard, the Merkle proof corresponding to at least one first shard, and the availability certificate of the previous micro-block of the first micro-block.

[0092] The second node is used to verify the validity of the second message. If the validity verification of the second message is successful, the second message is stored, and the identifier of the first micro-block in the second message is signed to generate a partial signature, and a third message is sent to the first node. The third message includes the identifier of the first micro-block and the partial signature.

[0093] In one implementation, the second node may use a preset signature algorithm to sign the identifier of the first micro-block in the second message to generate a partial signature. The preset signature algorithm may be a partial signature algorithm in threshold signature technology.

[0094] The first node receives the third message from at least one second node and aggregates the partial signatures in the third messages of at least one second node into an aggregated proof.

[0095] In one implementation, the first node may use a signature aggregation algorithm in threshold signature technology to aggregate the partial signatures in the third messages of at least one second node into an aggregated proof.

[0096] The first node constitutes the availability certificate of the first micro-block according to the aggregated proof and the identifier of the first micro-block in the third messages of at least one second node.

[0097] In one implementation, the first node may combine the aggregated proof and the identifier of the first micro-block in the third messages of at least one second node to constitute the availability certificate of the first micro-block.

[0098] In some embodiments, before sending the second message to at least one second node, it may further include but is not limited to the following steps:

[0099] The first node monitors the number of received availability certificates and the number of completed retrievals.

[0100] The above-mentioned number of availability certificates Represents the number of availability certificates (AC) of the received micro-blocks.

[0101] The above-mentioned number of completed retrievals Refers to the number of micro-blocks for which the retrieval process has been completed.

[0102] When the number of availability certificates is monitored The difference from the number of completed retrievals is greater than a preset threshold In this case, the waiting time t = T1 + T2 is calculated, where .

[0103] When the number of availability certificates monitored and the difference from the number of completed retrievals is less than or equal to the preset threshold In this case, the waiting time t = T1 - T2 is calculated, where T1 and T2 are different preset values.

[0104] After the waiting time t, the first node sends the second message to at least one second node.

[0105] In this embodiment, if the difference between the number of availability certificates monitored and the number of completed retrievals is greater than the preset threshold , it indicates that the performance of the network bandwidth is not very good. To avoid the consensus process being too inefficient due to the network, the step of sending the second message to at least one second node can be executed after waiting for a longer period of time. This application sets a bandwidth adaptation mechanism to dynamically adjust the micro-block distribution rate according to the real-time change of the network bandwidth, thereby optimizing the use of bandwidth resources and improving the overall performance of the system.

[0106] Figure 2 shows a schematic flowchart of a block consensus method applied to a second node provided by an embodiment of this application. As Figure 2 shown, with the second node as the execution subject, the method specifically includes the following step S201.

[0107] Step S201, when triggering a micro-block retrieval event of a preset block, for each first micro-block in the preset block, if there is a first shard corresponding to the first micro-block, broadcast a first message to at least one first node.

[0108] The above-mentioned first nodes are nodes other than the second node.

[0109] Each first micro-block in the above-mentioned preset block comes from different nodes.

[0110] The first shard corresponding to the first micro-block is encoded from the first micro-block by the corresponding node.

[0111] The above-mentioned first message includes the identifier of the first micro-block, the first shard corresponding to the first micro-block, and the Merkle proof corresponding to the first shard.

[0112] If the first shard corresponding to the first micro-block is stored, the second node generates a first message with the identifier of the first micro-block, the first shard corresponding to the first micro-block, and the Merkle proof corresponding to the first shard as the message content, and broadcasts the first message to at least one first node.

[0113] The first node is used to receive the first message from at least one second node, verify the Merkle proof corresponding to each first shard in the received first message, determine at least one target shard for which the Merkle proof verification is successful, decode the at least one target shard to generate a second micro-block, and match the second micro-block with the first micro-block based on the identifier of the first micro-block in the at least one received first message. If the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

[0114] In some embodiments, before the above step S201, it may further include but is not limited to the following steps:

[0115] If the second node is the primary node of the current view, the second node constructs a target certificate according to the obtained target messages from at least one first node.

[0116] If the target message is a vote message, the target certificate is a quorum certificate (QC) qc. If the target message is a new view message, the target certificate is an aggregated quorum certificate aggQc.

[0117] The above vote messages are the voting opinions of the corresponding first nodes on the view change.

[0118] The above new view messages are the voting opinions of the corresponding first nodes on entering the next view.

[0119] In one implementation, the second node can construct the target certificate according to the obtained target messages from at least one first node by deriving the target certificate from the target messages of at least one first node.

[0120] The second node constructs a block based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node.

[0121] Each node includes the second node and at least one first node.

[0122] In one implementation, the second node can construct a block according to the identifiers of the first micro-blocks newly generated by each node by calling to obtain the identifiers of the first micro-blocks newly generated by each node based on the target certificate, so as to construct a block based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node.

[0123] The second node broadcasts the proposal message generated according to the block to at least one first node.

[0124] The above-mentioned proposal message may include at least one of a proposal type, proposal data, proposer identity, block height / round, timestamp, signature, and proof.

[0125] The first node is used to receive the proposal message sent by the primary node. When the validity verification of the proposal message passes and the view numbers corresponding to the parent block and grandparent block of the block are consecutive, the grandparent block is determined as the preset block, and a micro-block retrieval event of the grandparent block is triggered.

[0126] In some embodiments, before the above step S201, it may further include but is not limited to the following steps:

[0127] If the second node is a non-primary node of the current view, the second node receives the proposal message sent by the primary node of the current view.

[0128] The proposal message is generated by the primary node based on the formed block, and the block is composed of the identifiers of the first micro-blocks newly generated by each node by the primary node based on the target certificate, and the target certificate is obtained by the primary node according to the target message.

[0129] If the target message is a vote message, the target certificate is a legal certificate; if the target message is a new view message, the target certificate is an aggregated legal certificate.

[0130] The above-mentioned target message is sent by at least one non-primary node other than the primary node, and the non-primary node is a node other than the primary node.

[0131] The second node verifies the validity of the proposal message.

[0132] In one implementation manner, the second node can verify the validity of the proposal message by verifying at least one of the proposer identity, verifying the proposal data structure, verifying the proposal content, etc. If at least one of verifying the proposer identity, verifying the proposal data structure, verifying the proposal content, etc. passes the verification, it is determined that the validity verification of the proposal message passes.

[0133] When the validity verification of the proposal message passes, if the view numbers corresponding to the parent block and grandparent block of the block are consecutive, the second node determines the grandparent block as the preset block and triggers a micro-block retrieval event of the grandparent block.

[0134] In some embodiments, before step S201, it may further include but is not limited to the following steps:

[0135] The second node encodes the first micro-block of the second node and encodes the first micro-block into at least one first shard.

[0136] In one implementation, the second node may use a preset encoding algorithm to encode the first micro-block into at least one first shard. The preset encoding algorithm may be an erasure code algorithm (such as Reed-Solomon), and the preset encoding algorithm may be the encoding algorithm Enc in the erasure code algorithm.

[0137] The second node generates an identifier corresponding to the first micro-block and a Merkle proof for each of the at least one first shards based on the at least one first shard.

[0138] In one implementation, the above identifier may be a Merkle root. To determine the identifier of the first micro-block based on the at least one first shard specifically, a Merkle tree corresponding to the first micro-block is constructed with the at least one first shards as leaf nodes, and the Merkle root corresponding to the Merkle tree is generated according to the Merkle proof generation algorithm to obtain the identifier of the first micro-block, and the Merkle proof for each of the at least one first shards is generated according to the Merkle proof generation algorithm.

[0139] The second node sends the second message to at least one first node.

[0140] The above second message includes the identifier of the first micro-block, at least one first shard, the Merkle proof corresponding to the at least one first shards, and the availability certificate of the previous micro-block of the first micro-block.

[0141] The first node is used to verify the validity of the second message. If the validity verification of the second message is successful, the second message is stored, and the identifier of the first micro-block in the second message is signed to generate a partial signature, and the third message is sent to the second node. The third message includes the identifier of the first micro-block and the partial signature.

[0142] In one implementation, the first node may use a preset signature algorithm to sign the identifier of the first micro-block in the second message to generate a partial signature. The preset signature algorithm may be a partial signature algorithm in threshold signature technology.

[0143] The second node receives the third message from at least one first node and aggregates the partial signatures in the third messages of the at least one first nodes into an aggregated proof.

[0144] In one implementation, the second node may use a signature aggregation algorithm in threshold signature technology to aggregate the partial signatures in the third messages of the at least one second nodes into an aggregated proof.

[0145] The second node forms an availability certificate for the first micro-block based on the aggregation proof and the identifier of the first micro-block in the third message of at least one first node.

[0146] In one implementation, the second node may combine the aggregation proof and the identifier of the first micro-block in the third message of at least one second node to form an availability certificate for the first micro-block.

[0147] In some embodiments, before sending the second message to at least one first node, it may further include but is not limited to the following steps:

[0148] The second node monitors the number of availability certificates received by the first node and the number of retrievals completed.

[0149] The above-mentioned number of availability certificates represents the number of availability certificates (AC) for the received micro-blocks.

[0150] The above-mentioned number of retrievals completed refers to the number of micro-blocks for which the retrieval process has been completed.

[0151] When the number of availability certificates is monitored and the number of retrievals completed The difference is greater than a preset threshold then calculate the waiting time t = T1 + T2, where .

[0152] When the number of availability certificates is monitored and the number of retrievals completed The difference is less than or equal to the preset threshold then calculate the waiting time t = T1 - T2, where T1 and T2 are different preset time durations.

[0153] After waiting for the time t, the second node then sends the second message to at least one first node.

[0154] In this embodiment, if the difference between the monitored number of availability certificates and the number of retrievals completed The difference is greater than the preset threshold , it indicates that the performance of the network bandwidth is not very good. In order to avoid the consensus process being inefficient due to the network, the step of sending the second message to at least one first node can be executed after waiting for a longer period of time. This application sets up a bandwidth adaptability mechanism to dynamically adjust the micro-block distribution rate according to the real-time change of the network bandwidth, thereby optimizing the use of bandwidth resources and improving the overall performance of the system.

[0155] To better understand the above method, an example embodiment of a block consensus method is provided in this application, and the example embodiment is as follows:

[0156] First, the algorithm technology used in the embodiment is described:

[0157] Regarding the erasure code technology, in this embodiment, the erasure code technology is described. For an erasure code over a finite field, a file is divided into k data blocks, and then the data blocks are encoded using a generator matrix G to obtain n encoded blocks, that is , where x is the pre-encoding vector of length k, and y is the post-encoding vector of length n. Only a partial number (such as d) of the encoded blocks are required to decode the original k data blocks and thus recover the file. If d = k, that is, any k of the n encoded blocks can decode the original k data blocks, such an encoding is called a maximum distance separable (MDS) code. Reed-Solomon (RS) code is a widely used MDS code, and in practical applications, RS code can be adopted.

[0158] In this embodiment, an erasure code technology that can be (n, f + 1)-RS code can be used. This encoding includes a pair of encoding algorithms and decoding algorithms (Enc, Dec):

[0159] Encoding algorithm Enc: S ← Enc(m), Enc encodes the data m into n chunks ;

[0160] Decoding algorithm Dec: m ← Dec( ), Dec can recover the original data m through f + 1 chunks out of any chunks.

[0161] Regarding the Merkle tree, in a blockchain, the Merkle tree is used to organize the transaction data in a block. Each block contains a Merkle root, which is used to quickly verify whether the transactions in the block are valid. The Merkle tree can be used to verify the consistency of the block encoded chunks, and the core process of the Merkle tree can be abstracted into two algorithms (MGen, MVrf):

[0162] Merkle proof generation MGen ;

[0163] Merkle proof verification .

[0164] For the data block set , this algorithm generates the Merkle root corresponding to the data block set ​, and for each element in the set generate the corresponding Merkle proof . The Mvrf algorithm takes a data block, its Merkle proof, and the Merkle root as inputs, verifies the correctness of the proof, and outputs the verification result.

[0165] For signatures and threshold signatures, digital signatures are added to the messages in the network. Messages sent by any honest node cannot be forged, and any node cannot deny a signed message. Let denote the signature of node on message . To reduce the size of the signature, in the present invention, the signature of a message can be the signature of the hash of the message.

[0166] In the present invention, a threshold signature technology can also be adopted, with parameters . All nodes share a public key , and each node has its own private key , and it is assumed that each private key has been distributed to the corresponding node before the system runs . This scheme includes multiple algorithms :

[0167] Partial signature : ;

[0168] Signature aggregation : ;

[0169] Signature verification : .

[0170] Among them, the algorithm is a partial signature scheme. Node uses its private key to sign message , thereby generating signature . The algorithm receives a set of t signatures containing the same message , and generates an aggregated signature \sigma. The TVerf algorithm verifies the validity of the signature through the public key , message m, and the aggregated signature .

[0171] For a micro-block, define the structure of a micro-block as follows: It consists of the identifier of this block, the available proof of the previous data block, and the content of this block. When a node distributes a micro-block, it needs to collect ack messages for this micro-block, and aggregate the signatures in enough ack messages into a threshold signature , which constitutes the Availability Certificate (AC) of this micro-block .

[0172] For the view, the protocol proceeds in rounds, and each round is called a view. Each view has a designated primary node and is assigned a view number. The protocol uses a deterministic algorithm to select the primary node, usually adopting the Round-Robin mechanism, so that each node knows who the primary node in the current view is. The process of primary node switching is called View Change

[0173] For the Quorum Certificate (QC) and Aggregated QC, in each round of consensus, when the primary node starts to propose, it collects a set of voting message sets from the previous view , which contains voting messages and partial signatures. Then, the primary node uses TComb to aggregate the partial signatures to generate a Quorum Certificate (QC). The QC proves that at least honest nodes have received this block under normal circumstances, and the height of the QC is identified by the view in which it is formed. Therefore, the QC is the key to ensuring that the block is recognized by enough honest nodes

[0174] If the primary node of the previous view fails, causing other nodes to fail to vote correctly and trigger a view change, then all nodes will send New-View messages and send the highest QC they know to the new primary node. After the new primary node receives a set of new view messages , by packing these QCs to generate an Aggregated QC, that is, simply stacking QCs together to obtain the Aggregated QC. An AggQC proves that the highest QC among the QCs it contains is also the highest QC for at least honest nodes

[0175] For a block, the block includes the view number of the current view, the QC of the previous block (AggQC is used when the previous view fails), the availability proof of the latest positions reported by all nodes, and the hash value of the parent block. By default, the first block is empty, indicating that the block has no parent block.

[0176] The complete embodiment includes a micro-block distribution phase, a consensus phase, and a retrieval phase. There are a total of h nodes participating in the consensus.

[0177] First, enter the micro-block distribution phase. In the distribution phase, there is a sender role, and other roles are receivers. However, for one micro-block, one node is the distributor of one micro-block. At the same time, each node is distributing a different micro-block. For example, in the first step, node 0 encodes the micro-block , and at the same time, node 1 encodes the micro-block and so on for h nodes.

[0178] That is, when i ranges from 0 to h - 1, each node i encodes the corresponding first micro-block .

[0179] For node i, node i uses the (f + 1, n) erasure coding algorithm , and encodes the micro-block into first shards .

[0180] Node i uses n first shards as leaf nodes, and adopts the Merkle proof generation algorithm to generate the Merkle root of the first micro-block and the corresponding Merkle proof for each first shard Among them, , and uses this Merkle root as the identifier of the first micro-block .

[0181] Node i monitors two metrics. One metric is the number of received availability certificates , and the number of availability certificates represents the number of availability certificates (AC) of the micro-blocks received locally. One metric is the number of completed retrievals , and the number of retrievals refers to the number of micro-blocks for which the retrieval process has been completed. When it is monitored that - is greater than the preset threshold When it is, let \(t = T1 + T2\). When it is monitored that - is less than or equal to a preset threshold let \(t = T1 - T2\).

[0182] After the node \(i\) waits for the time \(t\), the node \(i\) uses the availability certificate of the previous micro-block and sends a second message for each node \(j\). The second message is where the node \(j\) is \(h - 1\) nodes other than the node \(i\) among the \(h\) nodes, that is, \(j\) takes any value other than \(i\) from \([0, h - 1]\).

[0183] Any node Upon receiving the second message (micro-block distribution (Mb-Dis) message), uses the verification algorithm to check the validity of the availability certificate and verify the correctness of the Merkle proof and the Merkle root.

[0184] If the verification of the second message passes, the node \(j\) stores this second message locally and uses the partial signature algorithm to sign the identifier in the second message to generate a partial signature . If the verification of the second message fails, the second message is ignored.

[0185] And constructs a third message according to the partial signature and the identifier . The third message is MB - Ack and returns this third message MB - Ack to the node .

[0186] When the node collects the third messages from \(2f + 1\) different nodes \(j\), uses the signature aggregation algorithm to aggregate the partial signatures included in these third messages into a complete proof (i.e., the aggregated proof). According to the proof and the identifier constitutes the availability certificate of the first micro-block .

[0187] Then enter the consensus stage. There are two roles in the consensus stage: a primary node and all other nodes (also called follower nodes, that is, the nodes other than the primary node among the \(h\) nodes). Different from the above micro-block distribution stage, there is exactly one primary node in the consensus step.​

[0188] In this embodiment, the process of the consensus phase is as follows:

[0189] The primary node of the current view collects the vote messages or new-view messages of the previous view, and constructs a quorum certificate (QC) using the vote messages (derived from the vote messages), or constructs an aggregated quorum certificate using the new-view messages (derived from the new-view messages).

[0190] Next, the primary node constructs a block using the identifiers of the first micro-blocks at position p from each node based on the quorum certificate (QC) or the aggregated quorum certificate , and broadcasts the block as a proposal message to other nodes.

[0191] For non-primary nodes, when receiving a proposal message, the non-primary nodes will verify the validity of the proposal message. If the verification passes, the non-primary nodes will sign on the block and send the vote message to the primary node of the view (i.e., the next view), along with the latest availability certificate of the non-primary node. Then, the non-primary nodes enter the view .

[0192] When the view numbers of the parent block B' and the grandparent block B" of this block are consecutive, the node will trigger the micro-block retrieval event of all the first micro-blocks in the grandparent block B", and wait for these micro-blocks to be available.

[0193] Finally, enter the retrieval phase.

[0194] The second node is node i. When the second node i triggers Mb-Retrieval event, it enters the retrieval phase for the first micro-block , where a ranges from 0 to h-1. In this phase, the second node i first checks whether it has received the first shard corresponding to . If the first shard is already stored locally, the second node i will broadcast the first message Mb-Chk to the other h-1 first nodes j. Among them, the first message contains the shard and its corresponding Merkle proof . .

[0195] Then, the second node i checks whether the Mb-Retrieval event of the previous micro-block of has been triggered. If not, it recursively triggers the retrieval event of the previous micro-block.

[0196] When the first node j receives the first message ( Mb-Chk message) for , the first node j verifies the validity of the Merkle proof attached to the first message. If the verification is successful, the first node j adds the first message to the local storage; if the verification fails, the first message is ignored.

[0197] When the first node j collects f + 1 valid shards (target shards) corresponding to , the first node j decodes and generates the complete micro-block content based on the f + 1 valid shards to obtain the second micro-block.

[0198] The decoded result is re-encoded into a group of second shards Chk' and its corresponding Merkle root is calculated. If the recalculated Merkle root matches the original , it indicates that the decoding is correct, and then the first node j and the second node i reach a consensus on the first micro-block ; otherwise, the decoding is determined to be incorrect. In the case of decoding error, the content field of the first micro-block is marked as empty. When this first micro-block enters the consensus process, if it is marked as empty, it is regarded as reaching a consensus on an empty micro-block.

[0199] Once all the first micro-blocks in the grandparent block B" are successfully decoded and become available, each node can start the process of confirming the block. Specifically, each node extracts all requests, sorts these requests according to the position and timestamp of the micro-blocks to form a transaction list. Subsequently, each node executes all the transactions in the transaction list in order and returns the corresponding responses to the client.

[0200] In the embodiments of the present application, by introducing the Erasure Coding technology, each micro-block is encoded into multiple shards for distribution, so as to ensure that even if some nodes fail or data is lost, the nodes can still recover the complete micro-block by collecting a sufficient number of shards.

[0201] Secondly, the availability certificate of the precursor micro-block can act as a pointer, enabling the formation of a chain structure. By adopting the chain structure, it is ensured that each micro-block contains the hash value (Merkle root) of its precursor micro-block, thus guaranteeing the sequentiality of the micro-blocks. In particular, the guarantee of the sequentiality of the micro-blocks ensures that the micro-blocks generated by the same node are executed in the submission order, avoiding malicious nodes from interfering with the transaction execution order.

[0202] In addition, the present application introduces a bandwidth adaptability mechanism to dynamically adjust the micro-block distribution rate according to the real-time change of the network bandwidth, thereby optimizing the use of bandwidth resources and improving the overall performance of the system.

[0203] Finally, the present application decouples the consensus process into three stages: distribution - consensus - retrieval, realizing an efficient micro-block sharing and consensus process. Under this framework, even if a node fails to receive the complete micro-block content, it can continue to advance the consensus steps and retrieve the complete micro-block content in subsequent rounds without waiting for the complete micro-block to be ready before advancing the subsequent steps, improving the consensus efficiency.

[0204] To better implement the above method, the embodiments of the present application provide a block consensus device. Referring to Figure 3 , Figure 3 is the structural block diagram of the block consensus device including the first node provided by the embodiments of the present application.

[0205] If the block consensus device includes a first node, then the block consensus device 30 specifically includes the following:

[0206] A message receiving module 301, configured to receive at least one first message, where the at least one first message is sent by at least one second node other than the first node. Each first message is generated when the micro-block retrieval event of a preset block is triggered at the second node and the second node stores the first shard of the first micro-block in the preset block. The first message includes the identifier of the first micro-block, the first shard, and the Merkle proof of the first shard; the first shard is encoded from the first micro-block by the node corresponding to the first micro-block.

[0207] A message verification module 302, configured to verify the Merkle proof of the first shard in each first message to determine at least one target shard for which the Merkle proof verification is successful.

[0208] A shard decoding module 303, configured to decode at least one target shard to generate a second micro-block.

[0209] A matching module 304, configured to match the second micro-block with the corresponding first micro-block based on the identifier of the first micro-block in at least one first message.

[0210] The consensus module 305 is configured to, if the second micro-block matches the first micro-block successfully, enable the second node and the first node to reach a consensus on the first micro-block.

[0211] In some embodiments, the message receiving module 301 is specifically configured to: if the first node is the primary node of the current view, construct a target certificate according to the obtained target messages from at least one second node; if the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; construct a block based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node; broadcast the proposal message generated according to the block to at least one second node, and the second node is configured to receive the proposal message sent by the primary node, and if the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

[0212] In some embodiments, the message receiving module 301 is specifically configured to: if the first node is a non-primary node of the current view, receive the proposal message sent by the primary node of the current view, where the proposal message is generated by the primary node based on the constructed block, the block is constructed by the primary node based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node, and the target certificate is obtained by the primary node according to the target message, if the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; verify the validity of the proposal message; if the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

[0213] In some embodiments, the message receiving module 301 is specifically configured to: encode the first micro-block corresponding to the first node, and encode the first micro-block into at least one first shard; generate an identifier corresponding to the first micro-block and Merkle proofs of each of the at least one first shards based on the at least one first shard; send a second message to at least one second node, where the second message includes the identifier of the first micro-block, the at least one first shard, the Merkle proofs corresponding to the at least one first shards, and an availability certificate of the previous micro-block of the first micro-block; the second node is configured to perform validity verification on the second message, and if the validity verification of the second message is successful, store the second message, and sign the identifier of the first micro-block in the second message to generate a partial signature, and send a third message to the first node, where the third message includes the identifier of the first micro-block and the partial signature; receive the third message from at least one second node, and aggregate the partial signatures in the third messages of the at least one second node into an aggregated proof; and form an availability certificate of the first micro-block based on the aggregated proof and the identifier of the first micro-block in the third messages of the at least one second node.

[0214] In some embodiments, the matching module 304 is specifically configured to: encode the second micro-block into at least one second shard, and determine the identifier of the second micro-block based on the at least one second shard; match the identifier of the second micro-block with the identifier of the first micro-block; and if the identifier of the second micro-block matches the identifier of the first micro-block successfully, determine that the second micro-block matches the first micro-block successfully.

[0215] Refer to Figure 4 , Figure 4 which is the structural block diagram of the block consensus device including a second node provided by an embodiment of the present application.

[0216] If the block consensus device includes a second node, then the block consensus device 30 specifically includes the following:

[0217] A message broadcasting module 401, configured to, in the case of triggering a micro-block retrieval event of a preset block, for each first micro-block in the preset block, if a first shard corresponding to the first micro-block is stored, broadcast a first message to at least one first node; the first node is a node other than the second node, each first micro-block in the preset block comes from a different node, and the first shard corresponding to the first micro-block is encoded from the first micro-block by the corresponding node, and the first message includes the identifier of the first micro-block, the first shard corresponding to the first micro-block, and the Merkle proof corresponding to the first shard.

[0218] The first node is used to receive a first message from at least one second node, verify the Merkle proofs corresponding to each first shard in the received first message, determine at least one target shard for which the Merkle proof verification is successful, decode the at least one target shard to generate a second micro-block, match the second micro-block with the first micro-block based on the identifier of the first micro-block in the received at least one first message, and if the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

[0219] In some embodiments, the message broadcasting module 401 is specifically configured to: if the second node is the primary node of the current view, construct a target certificate according to the obtained target message from at least one first node; if the target message is a voting message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; construct a block based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node; broadcast the proposal message generated according to the block to at least one first node, and the first node is used to receive the proposal message sent by the primary node, and if the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, then determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

[0220] In some embodiments, the message broadcasting module 401 is specifically configured to: if the second node is a non-primary node of the current view, receive the proposal message sent by the primary node of the current view, where the proposal message is generated by the primary node based on the constructed block, the block is constructed by the primary node based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node, and the target certificate is obtained by the primary node according to the target message, if the target message is a voting message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; verify the validity of the proposal message; if the validity verification of the proposal message passes, and if the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, then determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

[0221] In some embodiments, the message broadcasting module 401 is specifically configured to: encode the first micro-block of the second node and encode the first micro-block into at least one first shard;

[0222] Generate an identifier corresponding to the first micro-block and Merkle proofs for each of the at least one first shards according to the at least one first shard;

[0223] Send a second message to at least one first node, where the second message includes an identifier of a first micro-block, at least one first shard, a Merkle proof corresponding to at least one first shard, and an availability certificate of a pre-order micro-block of the first micro-block; the first node is used to verify the validity of the second message. If the verification of the second message is successful, store the second message, sign the identifier of the first micro-block in the second message to generate a partial signature, and send a third message to the second node, where the third message includes the identifier of the first micro-block and the partial signature; receive the third message from at least one first node, and aggregate the partial signatures in the third messages of at least one first node into an aggregated proof; according to the aggregated proof and the identifier of the first micro-block in the third message of at least one first node, construct an availability certificate of the first micro-block.

[0224] Based on the above device, it can be realized that even if there is data loss in a certain node, the consensus process can still be advanced, and the blocking probability caused by data loss of a single node in the consensus process can be reduced.

[0225] Figure 5 The figure shows a schematic hardware structure diagram of an electronic device provided by an embodiment of the present application.

[0226] The electronic device may include a processor 501 and a memory 502 storing computer program instructions.

[0227] Specifically, the above processor 501 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0228] The memory 502 may include a mass storage for data or instructions. By way of example and not limitation, the memory 502 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disc, a magneto-optical disc, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In a suitable case, the memory 502 may include a removable or non-removable (or fixed) medium. In a suitable case, the memory 502 may be internal or external to the integrated gateway disaster recovery device. In a specific embodiment, the memory 502 is a non-volatile solid state memory.

[0229] In some embodiments, the memory 502 may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage media device, an optical storage media device, a flash memory device, an electrical, optical, or other physical / tangible memory storage device. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of the present disclosure.

[0230] The processor 501 reads and executes the computer program instructions stored in the memory 502 to implement any one of the block consensus methods in the above embodiments.

[0231] In one example, the electronic device may further include a communication interface 503 and a bus 510. Among them, as Figure 5 shown, the processor 501, the memory 502, and the communication interface 503 are connected through the bus 510 and complete communication with each other.

[0232] The communication interface 503 is mainly used to implement communication between various modules, devices, units, and / or devices in the embodiments of the present application.

[0233] The bus 510 includes hardware, software, or both, and couples the components of the block consensus device to each other. By way of example and not limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses or a combination of two or more of these. In a suitable case, the bus 510 may include one or more buses. Although the embodiments of the present application describe and illustrate specific buses, the present application contemplates any suitable bus or interconnect.

[0234] In addition, in combination with the block consensus method in the above embodiments, the embodiments of the present application may provide a computer storage medium to implement. Computer program instructions are stored on the computer storage medium; when the computer program instructions are executed by a processor, any one of the block consensus methods in the above embodiments is implemented.

[0235] Combined with the block consensus method in the above embodiments, an embodiment of the present application also provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device implements the block consensus method in the above embodiments.

[0236] It should be clear that the present application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order between steps after understanding the spirit of the present application.

[0237] The functional blocks shown in the structural block diagrams described above can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium or transmitted via a data signal carried in a carrier wave on a transmission medium or a communication link. A "machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical discs, hard disks, fiber optic media, radio frequency (RF) links, and so on. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0238] It should also be noted that the exemplary embodiments mentioned in the present application describe some methods or systems based on a series of steps or devices. However, the present application is not limited to the order of the above steps. That is, the steps can be executed in the order mentioned in the embodiments, or different from the order in the embodiments, or several steps can be executed simultaneously.

[0239] As described above with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block in the flowchart and / or block diagram, and the combination of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the functions / actions specified in one or more blocks of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It should also be understood that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can also be implemented by dedicated hardware that performs the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0240] As described above, the above is only the specific implementation manner of the present application. Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein. It should be understood that the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should all be covered within the protection scope of the present application.

Claims

1. A block consensus method, characterized in that, The method is applied to a first node, and the method includes: Receiving at least one first message sent by at least one second node other than the first node. Each of the at least one first message is generated when a micro-block retrieval event of a preset block is triggered at the second node and the second node stores a first shard of the first micro-block in the preset block. The first message includes an identifier of the first micro-block, the first shard, and a Merkle proof of the first shard; the first shard is encoded from the first micro-block by a node corresponding to the first micro-block; Verifying the Merkle proof of the first shard in each of the at least one first message to determine at least one target shard for which the Merkle proof verification is successful; Decoding the at least one target shard to generate a second micro-block; Based on the identifier of the first micro-block in the at least one first message, matching the second micro-block with the corresponding first micro-block; If the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

2. The method according to claim 1, characterized in that, The matching the second micro-block with the corresponding first micro-block based on the identifier of the first micro-block in the at least one first message includes: Encoding the second micro-block into at least one second shard, and determining an identifier of the second micro-block according to the at least one second shard; Matching the identifier of the second micro-block with the identifier of the first micro-block; Before the step that if the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block, the method further includes: If the identifier of the second micro-block matches the identifier of the first micro-block successfully, determining that the second micro-block matches the first micro-block successfully.

3. The method according to claim 1, characterized in that Before the step of receiving at least one first message, the method further includes: If the first node is the primary node of the current view, constructing a target certificate according to the obtained target message from the at least one second node; if the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; Based on the target certificate, constructing a block according to the identifiers of the first micro-blocks newly generated by each node; Broadcasting a proposal message generated according to the block to the at least one second node, The second node is configured to receive the proposal message sent by the primary node, and determine the grandfather block as the preset block and trigger a micro-block retrieval event of the grandfather block when the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandfather block of the block are consecutive.

4. The method according to claim 1, characterized in that, Before the step of receiving at least one first message, the method further includes: If the first node is a non-primary node of the current view, receive a proposal message sent by the primary node of the current view. The proposal message is generated by the primary node based on the formed block, and the block is formed by the primary node based on the target certificate according to the identifiers of the first micro-blocks newly generated by each node. The target certificate is obtained by the primary node according to the target message. If the target message is a vote message, the target certificate is a legal certificate. If the target message is a new view message, the target certificate is an aggregated legal certificate; Verify the validity of the proposal message; When the validity verification of the proposal message passes, if the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

5. The method according to claim 1, wherein Before receiving at least one first message, the method further includes: Encode the first micro-block corresponding to the first node and encode the first micro-block into at least one first shard; Generate an identifier corresponding to the first micro-block and a Merkle proof for each first shard in the at least one first shard according to the at least one first shard; Send a second message to the at least one second node. The second message includes the identifier of the first micro-block, the at least one first shard, the Merkle proof corresponding to the at least one first shard, and the availability certificate of the previous micro-block of the first micro-block. The second node is used to verify the validity of the second message. If the validity verification of the second message is successful, store the second message, sign the identifier of the first micro-block in the second message to generate a partial signature, and send a third message to the first node. The third message includes the identifier of the first micro-block and the partial signature; Receive the third message from the at least one second node and aggregate the partial signatures in the third message of the at least one second node into an aggregated proof; Construct an availability certificate for the first micro-block according to the aggregated proof and the identifier of the first micro-block in the third message of the at least one second node.

6. A block consensus method, characterized in that, The method is applied to a second node, and the method includes: When triggering the micro-block retrieval event of the preset block, for each first micro-block in the preset block, if the first shard corresponding to the first micro-block is stored, broadcast a first message to at least one first node. The first node is a node other than the second node. Each first micro-block in the preset block comes from a different node. The first shard corresponding to the first micro-block is obtained by the corresponding node encoding the first micro-block. The first message includes the identifier of the first micro-block, the first shard corresponding to the first micro-block, and the Merkle proof corresponding to the first shard; The first node is used to receive a first message from at least one of the second nodes, verify the Merkle proofs corresponding to each of the first shards in the received first message, determine at least one target shard for which the Merkle proof verification is successful, decode the at least one target shard to generate a second micro-block, match the second micro-block with the first micro-block based on the identifier of the first micro-block in at least one received first message, and if the second micro-block matches the first micro-block successfully, the second node and the first node reach a consensus on the first micro-block.

7. The method according to claim 6, wherein In the case of triggering a micro-block retrieval event for a preset block, for each first micro-block in the preset block, before broadcasting a first message to at least one first node if the first shard corresponding to the first micro-block is stored, the method further includes: If the second node is the primary node of the current view, construct a target certificate according to the target message obtained from at least one of the first nodes; if the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; Construct a block based on the target certificate and the identifiers of the first micro-blocks newly generated by each node; Broadcast a proposal message generated according to the block to at least one of the first nodes; The first node is used to receive the proposal message sent by the primary node. If the validity verification of the proposal message passes and the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, then determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

8. The method according to claim 6, wherein In the case of triggering a micro-block retrieval event for a preset block, for each first micro-block in the preset block, before broadcasting a first message to at least one first node if the first shard corresponding to the first micro-block is stored, the method further includes: If the second node is a non-primary node of the current view, receive a proposal message sent by the primary node of the current view. The proposal message is generated by the primary node based on the constructed block, and the block is constructed by the primary node based on the target certificate and the identifiers of the first micro-blocks newly generated by each node. The target certificate is obtained by the primary node according to the target message. If the target message is a vote message, the target certificate is a legal certificate, and if the target message is a new view message, the target certificate is an aggregated legal certificate; Verify the validity of the proposal message; In the case where the validity verification of the proposal message passes, if the view numbers corresponding to the parent block and the grandparent block of the block are consecutive, then determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

9. The method according to claim 6, wherein In the case of triggering a micro-block retrieval event for a preset block, before broadcasting a first message to at least one first node for each first micro-block in the preset block if there is a first shard corresponding to the first micro-block stored, the method further includes: Encoding the first micro-block of the second node and encoding the first micro-block into at least one first shard; Generating an identifier corresponding to the first micro-block and Merkle proofs for each of the at least one first shards according to the at least one first shard; Sending a second message to the at least one first node, the second message including the identifier of the first micro-block, the at least one first shard, the Merkle proofs corresponding to the at least one first shards, and an availability certificate of a previous micro-block of the first micro-block; the first node is used to perform validity verification on the second message, if the validity verification of the second message is successful, then store the second message, and sign the identifier of the first micro-block in the second message to generate a partial signature, and send a third message to the second node, the third message including the identifier of the first micro-block and the partial signature; Receiving the third message from the at least one first node and aggregating the partial signatures in the third message of the at least one first node into an aggregated proof; Constituting an availability certificate of the first micro-block according to the aggregated proof and the identifier of the first micro-block in the third message of the at least one first node.

10. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the block consensus method according to any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, Computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, they implement the block consensus method according to any one of claims 1-9.

Images