Block consensus method, electronic equipment and storage medium

Abstract

The invention discloses a block consensus method, electronic equipment and a storage medium, and the method comprises the steps: receiving first messages sent by at least one second node, verifying the Merkel proof of a first fragment in each first message, determining at least one target fragment of which the Merkel proof verification succeeds, and sending the at least one target fragment to a server; and decoding the at least one target fragment to generate a second micro-block, and if the second micro-block is successfully matched with the first micro-block, determining that the second node and the first node reach a consensus for the first micro-block. Thus, the first node can decode and generate the corresponding second micro-block according to the at least one target fragment, so that the consensus is realized through matching of the second micro-block and the first micro-block, the consensus can be realized without obtaining complete data of the first micro-block, and therefore, the consensus efficiency is improved. According to the method, the blocking probability caused by data missing of a single node in the consensus process can be reduced.

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] 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, embodiments of this application provide a block consensus method, which is applied to a first node. The method includes: 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. 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 from the first micro-block by a node corresponding to the first micro-block; Verifying 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; 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.

[0007] 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, and 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 then 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.

[0008] 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 a 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 a micro-block retrieval event of the grandparent block.

[0009] 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 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, and 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 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 a micro-block retrieval event of the grandparent block.

[0010] 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 of 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.

[0011] 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: In the case of 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, 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; 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.

[0012] In some embodiments, 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, 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 an aggregated legal certificate; constructing a block based on the target certificate 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 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 determining the grandparent block as the preset block and triggering the micro-block retrieval event of the grandparent block.

[0013] In some embodiments, 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, 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 an aggregated legal certificate; verifying 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 determining the grandparent block as the preset block and triggering the micro-block retrieval event of the grandparent block.

[0014] In some embodiments, when a micro-block retrieval event of a preset block is triggered, 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: 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 a pre-order 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 aggregation proof; and forming an availability certificate of the first micro-block according to the aggregation proof and the identifier of the first micro-block in the third message of the at least one first node.

[0015] 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; When the processor executes the computer program instructions, the block consensus method as described in the first aspect or the second aspect is implemented.

[0016] 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 as described in the first aspect or the second aspect is implemented.

[0017] 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 the micro-block retrieval event of the 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. 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

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

[0019] Figure 1 is a flowchart of a block consensus method applied to a first node provided by an embodiment of the present application; Figure 2 is a flowchart of a block consensus method applied to a second node provided by an embodiment of the present application; Figure 3 is a structural block diagram of a block consensus device including a first node provided by an embodiment of the present application; Figure 4 is a structural block diagram of a block consensus device including a second node provided by an embodiment of the present application; Figure 5 is a structural diagram of an electronic device provided by an embodiment of the present application. Detailed Implementation Manner

[0020] The features and exemplary embodiments of various aspects of the present application will be described in detail below. To make the objectives, technical solutions, and advantages of the present application clearer and more understandable, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application and not to limit 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.

[0021] It should be noted that in this text, 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 comprising 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, an element defined by the statement "comprising..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the said element.

[0022] Although some existing partially 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 be affected by malicious nodes or the asynchronous characteristics of the network, resulting in some nodes being unable to receive some blocks, which affects 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.

[0023] Third, the bandwidth adaptability problem. 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. Existing protocols do not fully consider the importance of the transaction order in micro-blocks, which may lead to damage to the legality of transactions.

[0024] To solve the related technical problems, the embodiments of the present application provide a block consensus method, device, equipment, computer storage medium, and computer program product. First, the block consensus method provided by the embodiments of the present application will be introduced below.

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

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

[0027] 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.

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

[0029] Step S104: 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.

[0030] 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.

[0031] The above at least one first message is sent by at least one second node other than the first node, and each of the second nodes other than the first node may send a first message to the first node.

[0032] For example, the nodes altogether include node A, node B, and node C. 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.

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

[0034] Each first message is generated by a second node when a 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 a 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.

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

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

[0037] In step S101, the form of the first message above 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.

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

[0039] 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 the Merkle proof verification algorithm in the Merkle tree algorithm .

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

[0041] The number of the at least one target shards above 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.

[0042] 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 an algorithm for the node to encode the first micro-block to obtain the first shard, such as an erasure code algorithm (such as Reed-Solomon). The preset decoding algorithm can be the decoding algorithm in the erasure code algorithm .

[0043] 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 according to a preset protocol format, so as to implement using the erasure code algorithm to decode at least one target shard to generate a second micro-block. The above preset protocol format can be the protocol format used by the node.

[0044] In some embodiments, step S104 above may include but is not limited to the following steps: 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.

[0045] In one embodiment, 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. .

[0046] The above identifier may be a Merkle root. Specifically, to determine the identifier of the second micro-block based on at least one second shard, a Merkle tree corresponding to the second micro-block may be constructed with at least one second shard as leaf nodes, and a Merkle root corresponding to the Merkle tree may be generated according to the Merkle proof generation algorithm to obtain the identifier of the second micro-block.

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

[0048] In one embodiment, 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.

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

[0050] 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: If the identifier of the second micro-block matches the identifier of the first micro-block, it is determined that the second micro-block matches the first micro-block successfully.

[0051] 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, and then 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.

[0052] In some embodiments, before step S101, the following steps may further be included but are not limited to: If the first node is the primary node of the current view, the first node constructs a target certificate according to the obtained target messages from at least one second node.

[0053] If the target message is a voting message, the target certificate is the Qualified Certificate (QC) qc; if the target message is a new view message, the target certificate is the Aggregate Qualified Certificate aggQc.

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

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

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

[0057] Based on the target certificate, the first node constructs a block according to the identifiers of the first micro-blocks newly generated by each node.

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

[0059] In one implementation, the first node calls 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 according to the identifiers of the first micro-blocks newly generated by each node, 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.

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

[0061] 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.

[0062] 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 of the parent block and 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.

[0063] In some embodiments, before step S101, it may further include but is not limited to the following steps: 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.

[0064] The above-mentioned proposal message is generated by the primary node based on the composed block, and the block is composed 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 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.

[0065] 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.

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

[0067] 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.

[0068] 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.

[0069] In some embodiments, before step S101, it may further include but is not limited to the following steps: 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.

[0070] 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. .

[0071] 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.

[0072] In one implementation, the above identifier can be a 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.

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

[0074] 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.

[0075] 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.

[0076] In one implementation, the second node can 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 can be a partial signature algorithm in threshold signature technology.

[0077] 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.

[0078] In one implementation, the first node can 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.

[0079] 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.

[0080] In one implementation, the first node can 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.

[0081] 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: The first node monitors the number of received availability certificates and the number of completed retrievals.

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

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

[0084] When monitoring the difference between the number of availability certificates and the number of completed retrievals of Greater than a preset threshold If so, calculate the waiting time t = T1 + T2, where .

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

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

[0087] In this embodiment, if the number of availability certificates monitored and the number of retrievals completed The difference is greater than a preset threshold , it indicates that the performance of the network bandwidth is not very good. In order 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, so as to optimize the use of bandwidth resources and improve the overall performance of the system.

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

[0089] Step S201, when triggering the 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.

[0090] The above first nodes are nodes other than the second node.

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

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

[0093] The above 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.

[0094] 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.

[0095] 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.

[0096] In some embodiments, before the above step S201, it may further include but is not limited to the following steps: 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.

[0097] 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.

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

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

[0100] 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.

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

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

[0103] In one implementation, the second node can call 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 according to the identifiers of the first micro-blocks newly generated by each node, so as to construct a block based on the target certificate and the identifiers of the first micro-blocks newly generated by each node.

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

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

[0106] 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 the micro-block retrieval event of the grandparent block is triggered.

[0107] In some embodiments, before the above step S201, it may further include but is not limited to the following steps: 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.

[0108] The proposal message is generated by the primary node based on the composed 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.

[0109] 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.

[0110] The above 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.

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

[0112] In one implementation, 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.

[0113] 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 the micro-block retrieval event of the grandparent block.

[0114] In some embodiments, before step S201, it may further include but is not limited to the following steps: The second node encodes the first micro-block of the second node and encodes the first micro-block into at least one first shard.

[0115] In one embodiment, 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.

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

[0117] In one embodiment, the above identifier may be a Merkle root. Specifically, determining the identifier of the first micro-block based on the at least one first shard may be to construct a Merkle tree corresponding to the first micro-block with the at least one first shard as leaf nodes, generate the Merkle root corresponding to the Merkle tree according to the Merkle proof generation algorithm to obtain the identifier of the first micro-block, and generate Merkle proofs for each of the at least one first shard according to the Merkle proof generation algorithm.

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

[0119] The above 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 shard, and the availability certificate of the previous micro-block of the first micro-block.

[0120] The first node is used to verify the validity of the second message. If the validity verification of the second message is successful, it stores the second message, signs the identifier of the first micro-block in the second message to generate a partial signature, and sends a third message to the second node. The third message includes the identifier of the first micro-block and the partial signature.

[0121] In one embodiment, 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 the threshold signature technology.

[0122] 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 node into an aggregation proof.

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

[0124] The second node constitutes an availability certificate of the first micro-block based on the aggregation proof and the identifier of the first micro-block in the third messages of the at least one first node.

[0125] 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.

[0126] 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: The second node monitors the number of received availability certificates and the number of completed retrievals of the first node.

[0127] The above-mentioned number of availability certificates represents the number of availability certificates (ACs) of the received micro-blocks.

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

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

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

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

[0132] In this embodiment, if it is monitored that the difference between the number of availability certificates 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 first node can be performed 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 changes in the network bandwidth, thereby optimizing the use of bandwidth resources and improving the overall performance of the system.

[0133] 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: First, an explanation of the algorithm technology used in the embodiment is given: In this embodiment, the erasure coding 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 coding blocks, that is, , where x is a pre-encoded vector of length k, and y is a post-encoded vector of length n. Only a portion of the encoded code blocks (e.g., d) are needed to decode the original k data blocks and restore the file. If d=k, any k of the n code blocks can be decoded to get the original k data blocks. Such encoding is called maximum distance separable (MDS) code. Reed-Solomon (RS) code is a widely used MDS code. In practical applications, RS code can be used.

[0134] In this embodiment, an erasure code technology of (n, f+1)-RS code may be used. The code includes a pair of encoding algorithm and decoding algorithm (Enc, Dec): Encoding algorithm Enc: S←Enc(m), Enc encodes data m into n blocks ; Decoding algorithm Dec: m←Dec( ), Dec can be obtained by any f+1 blocks out of the blocks are used to restore the original data m.

[0135] For Merkle tree, in blockchain, Merkle tree is used to organize transaction data in blocks. 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 encoding block, and the core process of the Merkle tree can be abstracted into two algorithms (MGen, MVrf): Merkle proof generation MGen ; Merkle proof verification .

[0136] For a collection of data blocks ,Should Algorithm generates a set of data blocks The corresponding Merkle root , and for each element in the collection Generate the corresponding Merkle proof The Mvrf algorithm takes a data block, its Merkle proof and Merkle root as input, verifies the correctness of the proof and outputs the verification result.

[0137] For signature and threshold signature, digital signatures are added to the messages in the network. Messages sent by any honest node cannot be forged, and any node cannot deny the signed messages. Use to represent the node 's signature on the message . To reduce the size of the signature, the signature on the message in the present invention can adopt the signature on the message hash.

[0138] A threshold signature technology can also be adopted in the present invention, 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 : Partial signature : ; Signature aggregation : ; Signature verification : .

[0139] Among them, algorithm is a partial signature scheme. The node uses its private key to sign the message , thereby generating the signature . 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 , the message m and the aggregated signature .

[0140] For the micro-block, define the structure of a micro-block as follows: That is, 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 the ack messages for this micro-block, and aggregate the signatures in the sufficient number of ack messages into a threshold signature , which constitutes the availability certificate (AC) of this micro-block, .

[0141] 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, typically using a round-robin mechanism, so that each node knows who the primary node is in the current view. The process of primary node switching is called view change.

[0142] For the quorum certificate (QC) and the aggregated quorum certificate (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 (QuoremCertificate, QC). The quorum certificate proves that at least honest nodes have received the block under normal circumstances. 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 a sufficient number of honest nodes.

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

[0144] For the block, the block includes the view number of the current view, the QC of the previous block (using the AggQC if the previous view fails), the availability proofs 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.

[0145] This 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.

[0146] First, enter the micro-block distribution phase. There is a sender role in the distribution phase, and all other roles are receivers. However, this is for a single micro-block. One node is the distributor of one micro-block, and 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.

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

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

[0149] Node i uses the 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 Merkle proof corresponding to each first shard Among them, , and uses this Merkle root as the identifier of the first micro-block .

[0150] 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 , let t = T1 + T2. When it is monitored that - is less than or equal to the preset threshold , let t = T1 - T2.

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

[0152] Any node When receiving the second message (Micro - block Distribution (Mb - Dis) message), use the verification algorithm to check the validity of the availability certificate and verify the correctness of the Merkle proof and the Merkle root.

[0153] If the verification of the second message passes, node j stores this second message locally and uses the partial signature algorithm to sign the identifier in the second message, generating a partial signature . If the verification of the second message fails, ignore this second message.

[0154] And according to the partial signature and the identifier construct the third message, the third message is MB - Ack , and return this third message MB - Ack to node .

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

[0156] 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.

[0157] In this embodiment, the process of the consensus stage is as follows: The primary node of the current view collects the voting messages (Vote messages) or new - view messages (New - View messages) of the previous view, and constructs a quorum certificate (QC) using the voting messages (Vote messages) (derived from the voting message) or constructing an aggregated legal certificate using New-View messages (derived from the New-View message).

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

[0159] For non-primary nodes, when receiving a proposal message, the non-primary node verifies the validity of the proposal message. If the verification passes, the non-primary node signs the block and sends a voting message to the primary node (i.e., the next view), attaching the latest availability certificate of the non-primary node. Then, the non-primary node enters the view .

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

[0161] Finally, it enters the retrieval stage.

[0162] The second node is node i. When the second node i triggers Mb-Retrieval event, it enters the retrieval stage for the first micro-block , where a ranges from 0 to h-1. In this stage, 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 broadcasts the first message Mb-Chk to the other h-1 first nodes j, where the first message contains the shard and its corresponding Merkle proof .

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

[0164] When the first node j receives the first message ( Mb-Chk Mb-Chk When the first node j receives the first message (e.g., a transaction message), the first node j will verify 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 local storage; if the verification fails, the first node j ignores the first message.

[0165] When the first node j collects f + 1 valid shards (target shards) corresponding to it, 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.

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

[0167] 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 sequentially executes all transactions in the transaction list and returns the corresponding responses to the client.

[0168] In the embodiment of the present application, by introducing the Erasure Coding technology, each micro-block is encoded into multiple shards for distribution, thus ensuring 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.

[0169] Secondly, the availability certificate of the predecessor micro-block can act as a pointer, thus forming a chain structure. By adopting the chain structure, it is ensured that each micro-block contains the hash value (Merkle root) of its predecessor micro-block, thus guaranteeing the sequentiality of the micro-blocks. In particular, the guarantee of the micro-block sequentiality 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.

[0170] In addition, the present application introduces 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.

[0171] Finally, this application decouples the consensus process into three stages: distribution - consensus - retrieval, achieving an efficient micro - block sharing and consensus process. Under this framework, even if a node fails to receive the complete content of a micro - block, 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 proceeding with the subsequent steps, thus improving the consensus efficiency.

[0172] To better implement the above - mentioned method, an embodiment of this application provides a block consensus device. Refer to Figure 3 , Figure 3 which is the structural block diagram of the block consensus device including the first node provided by the embodiment of this application.

[0173] If the block consensus device includes a first node, then the block consensus device 30 specifically includes the following: A message receiving module 301, configured to receive at least one first message. 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.

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

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

[0176] 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.

[0177] A consensus module 305, configured to, if the second micro - block matches the first micro - block successfully, reach a consensus on the first micro - block between the second node and the first node.

[0178] 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 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 second node, and 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, determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

[0179] 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, 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 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; 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.

[0180] 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 first shard in the at least one first shard according to 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 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, where the third message includes the identifier of the first micro-block and the partial signature; receive the third messages 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; construct 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 the at least one second node.

[0181] In some embodiments, the matching module 304 is specifically configured to: encode the second micro-block into at least one second shard, determine the identifier of the second micro-block according to the at least one second shard; match the identifier of the second micro-block with the identifier of the first micro-block; 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.

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

[0183] If the block consensus device includes a second node, the block consensus device 30 specifically includes the following: 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 there is a first shard corresponding to the first micro-block 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.

[0184] The first node is configured 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, 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.

[0185] 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; based on the target certificate, construct a block 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 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, then determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

[0186] In some embodiments, the message broadcast module 401 is specifically configured to: if the second node is a non-primary node in the current view, receive a proposal message sent by the primary node of the current view, where 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; 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, determine the grandparent block as the preset block, and trigger a micro-block retrieval event of the grandparent block.

[0187] In some embodiments, the message broadcast 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; Generate 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 shard; Send a second message to at least one first node, where the 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 an availability certificate of the previous micro-block of the first micro-block; the first 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 second node. 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, aggregate the partial signatures in the third messages of the at least one first node into an aggregated proof; and form an 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 the at least one first node.

[0188] 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.

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

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

[0191] Specifically, the above-mentioned processor 501 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured as one or more integrated circuits for implementing the embodiments of the present application.

[0192] 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 disk, a magneto-optical disk, 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.

[0193] 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 an aspect of the present disclosure.

[0194] 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.

[0195] 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 to complete communication with each other.

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

[0197] 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 Enhanced 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 bus or a combination of two or more of these. Where appropriate, 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.

[0198] In addition, in combination with the block consensus method in the above embodiments, the embodiments of the present application may be implemented by providing a computer storage medium. 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.

[0199] In combination with the block consensus method in the above embodiments, the embodiments of the present application further provide 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.

[0200] It should be clear that the present application is not limited to the specific configurations and processes described above and illustrated 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 illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated, and 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.

[0201] The functional blocks shown in the above-described structural block diagrams 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 functional card, and so on. When implemented in software, the elements of the present application are programs or code segments for performing the required tasks. The program or code segment can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via a data signal carried in a carrier wave. A "machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, 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, and so on.

[0202] 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, can be different from the order in the embodiments, or several steps can be executed simultaneously.

[0203] Aspects of the present disclosure have been 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 flowcharts and / or block diagrams, and the combinations of blocks in the flowcharts and / or block diagrams, 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 combinations of blocks in the block diagram and / or flowchart, can also be implemented by dedicated hardware for performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0204] As described above, this 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 comprises: receiving at least one first message, wherein the at least one first message is sent by at least one second node other than the first node, each first message is a message generated by the second node when a micro-block retrieval event of a preset block is triggered and the second node stores a first shard of a 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 obtained by encoding the first micro-block by a node corresponding to the first micro-block; Verify the Merkle proof of the first shard in each of the first messages, and determine at least one target shard for which the Merkle proof is successfully verified; Decoding the at least one target slice to generate a second micro-tile; matching the second micro-tile with a corresponding first micro-tile based on an identifier of the first micro-tile in the at least one first message; If the second micro-tile matches the first micro-tile successfully, the second node and the first node reach a consensus on the first micro-tile.

2. The method according to claim 1, characterized in that The matching the second micro-tile with the corresponding first micro-tile based on the identifier of the first micro-tile in the at least one first message includes: encoding the second micro-tile into at least one second slice, and determining an identifier of the second micro-tile according to the at least one second slice; matching the identifier of the second micro-tile with the identifier of the first micro-tile; Before the second node and the first node reach a consensus on the first micro-tile if the second micro-tile is successfully matched with the first micro-tile, the method further includes: If the identifier of the second micro-tile successfully matches the identifier of the first micro-tile, it is determined that the second micro-tile successfully matches the first micro-tile.

3. The method according to claim 1, characterized in that Before receiving at least one first message, the method further includes: If the first node is the master node of the current view, constructing a target certificate according to the target message obtained from the at least one second node; if the target message is a voting message, the target certificate is a statutory certificate; if the target message is a new view message, the target certificate is an aggregated statutory certificate; Based on the target certificate, construct a block according to the identifier of the first micro-block most recently generated by each node; broadcasting a proposal message generated according to the block to the at least one second node, The second node is used to receive the proposal message sent by the master node, and when the validity of the proposal message is verified and the view numbers corresponding to the parent block and the grandparent block of the block are continuous, determine the grandparent block as the preset block and trigger the micro-block retrieval event of the grandparent block.

4. The method according to claim 1, characterized in that Before receiving at least one first message, the method further includes: If the first node is a non-master node of the current view, a proposal message sent by the master node of the current view is received, wherein the proposal message is generated by the master node based on the constituted block, and the block is constituted by the master node based on the target certificate and the identifier of the first micro-block newly generated by each node, and the target certificate is obtained by the master node according to the target message, and if the target message is a voting message, the target certificate is a statutory certificate, and if the target message is a new view message, the target certificate is an aggregated statutory 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 continuous, the grandparent block is determined as the preset block, and a micro-block retrieval event of the grandparent block is triggered.

5. The method according to claim 1, characterized in that 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 slice; Generate, according to the at least one first shard, an identifier corresponding to the first micro-block and a Merkle proof of each first shard in 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-tile, the at least one first shard, the Merkle proof corresponding to the at least one first shard, and the availability certificate of the preceding micro-tile of the first micro-tile; the second node is used to verify the validity of the second message, and if the validity verification of the second message is successful, store the second message, sign the identifier of the first micro-tile in the second message, generate a partial signature, and send a third message to the first node, the third message including the identifier of the first micro-tile and the partial signature; receiving the third message from the at least one second node, and aggregating the partial signatures in the third message of the at least one second node into an aggregate proof; An availability certificate of the first micro-tile is constructed based on the aggregate proof and the identifier of the first micro-tile in the third message of the at least one second node.

6. A block consensus method, characterized in that: The method is applied to the second node, and the method includes: 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 obtained by encoding the first micro-block by the corresponding node, and the first message includes an identifier of the first micro-block, a first shard corresponding to the first micro-block, and a 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, and verify the Merkle proof corresponding to each of the first shards in the received first message, determine at least one target shard for which the Merkle proof is successfully verified, 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 an 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, characterized in that In the case of triggering a micro-tile retrieval event of a preset block, for each first micro-tile in the preset block, if a first slice corresponding to the first micro-tile is stored, before broadcasting a first message to at least one first node, the method further includes: If the second node is the master node of the current view, construct 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 statutory certificate; if the target message is a new view message, the target certificate is an aggregated statutory certificate; Based on the target certificate, construct a block according to the identifier of the first micro-block most recently generated by each node; broadcasting a proposal message generated according to the block to the at least one first node, The first node is used to receive the proposal message sent by the master node. When the validity of the proposal message is verified and the view numbers corresponding to the parent block and the grandparent block of the block are continuous, the grandparent block is determined as the preset block, and a micro-block retrieval event of the grandparent block is triggered.

8. The method according to claim 6, characterized in that In the case of triggering a micro-tile retrieval event of a preset block, for each first micro-tile in the preset block, if a first slice corresponding to the first micro-tile is stored, before broadcasting a first message to at least one first node, the method further includes: If the second node is a non-master node of the current view, a proposal message sent by the master node of the current view is received, wherein the proposal message is generated by the master node based on the constituted block, and the block is constituted by the master node based on the target certificate and the identifier of the first micro-block newly generated by each node, and the target certificate is obtained by the master node according to the target message, and if the target message is a voting message, the target certificate is a statutory certificate, and if the target message is a new view message, the target certificate is an aggregated statutory 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 continuous, the grandparent block is determined as the preset block, and a micro-block retrieval event of the grandparent block is triggered.

9. The method according to claim 6, characterized in that In the case of triggering a micro-tile retrieval event of a preset block, for each first micro-tile in the preset block, if a first slice corresponding to the first micro-tile is 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 slice; Generate, according to the at least one first shard, an identifier corresponding to the first micro-block and a Merkle proof of each first shard in 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-tile, the at least one first shard, the Merkle proof corresponding to the at least one first shard, and the availability certificate of the preceding micro-tile of the first micro-tile; the first node is used to verify the validity of the second message, and if the validity verification of the second message is successful, store the second message, sign the identifier of the first micro-tile in the second message, generate a partial signature, and send a third message to the second node, the third message including the identifier of the first micro-tile 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 aggregate proof; An availability certificate of the first micro-tile is constructed based on the aggregate proof and the identifier of the first micro-tile in the third message of the at least one first node.

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

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by the processor, the block consensus method according to any one of claims 1 to 9 is implemented.

Images