A block consensus method and device, electronic equipment and storage medium

Abstract

The application discloses a block consensus method and device, electronic equipment and a storage medium. Specifically, in the view increasing order, a current master node in a current view obtains voting messages of each verifier node in a previous view; if the voting messages of the previous view obtained by the current master node exceed a preset threshold, a block with the highest view number is obtained from the voting messages; a current block is generated according to the hash value of the block with the highest view number, current transaction information in the current view and the current view number; when the blocks included in each voting message of the previous view are completely the same and the view number in the block is the previous view number, the block is confirmed as a commitable block; the current block is proposed to each verifier node in the current view, and each verifier node in the current view is instructed to write the commitable block into a block chain ledger. The technical scheme improves the efficiency of the overall consensus of the block chain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a block consensus method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of computer and big data technologies, an increasing number of online transactions and data are facing security challenges. Decentralized platforms with tamper-proof data are needed to safeguard online transactions, thus giving rise to blockchain technology. Consensus is one of the key technologies of blockchain; only when all nodes in the blockchain effectively reach a consensus can the synchronization of the blockchain and the security of information be guaranteed.

[0003] Currently, there are generally two consensus methods for blockchain: Byzantine fault-tolerant consensus and crash-tolerant consensus (also known as non-Byzantine fault-tolerant consensus). Byzantine fault-tolerant consensus can support Byzantine-type node errors, but it incurs high network and time overhead and is inefficient. Crash-tolerant consensus, while having lower network and time overhead, cannot support Byzantine-type errors. Although crash-tolerant consensus cannot support Byzantine-type errors, it is suitable for some consortium blockchain scenarios where the level of trust among participants is high. Combining crash-tolerant consensus with the technical characteristics of blockchain can achieve higher consensus efficiency. Summary of the Invention

[0004] This application provides a block consensus method, apparatus, electronic device, and storage medium to improve the efficiency of block consensus.

[0005] According to a first aspect of this application, a block consensus method is provided, applied to a current master node, the method comprising:

[0006] According to the ascending order of views, the current master node in the current view obtains the voting messages of each validator node in the previous view;

[0007] If the voting messages of the previous view obtained by the current master node exceed the preset threshold, the block with the highest view number is obtained from each voting message;

[0008] The current block is generated based on the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number;

[0009] When all the voting messages in the previous view contain the same blocks and the view number in the block is the previous view number, the block is confirmed as a committable block.

[0010] Propose the current block to each validator node in the current view and instruct each validator node in the current view to write the committable block into the blockchain ledger.

[0011] According to a second aspect of this application, a block consensus method is provided, applied in at least one validator node, the method comprising:

[0012] Retrieve the block proposals and committable block indication information from the master node in the current view;

[0013] If the block proposal and committable block indication information of the current view's master node are obtained within the first preset time, then the information reception is confirmed to be normal.

[0014] Once it is confirmed that the information reception is normal, the proposed block will be stored locally;

[0015] Vote on the block proposed by the master node in the current view to generate a block voting message;

[0016] The voting messages for the block are fed back to the master node of the next view, so that the master node of the next view can determine whether the block is a committable block based on the voting messages.

[0017] According to a third aspect of this application, a block consensus device is provided, applied to a current master node, the device comprising:

[0018] The voting verification module is used to obtain the voting messages of each validator node in the previous view from the current master node in the current view in ascending order of views;

[0019] The block acquisition module is used to acquire the block with the highest view number from each voting message if the voting messages of the previous view obtained by the current master node exceed a preset threshold.

[0020] The block generation module is used to generate the current block based on the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number.

[0021] The block confirmation module is used to confirm a block as a committable block when all the blocks included in the voting messages of the previous view are exactly the same and the view number in the block is the previous view number.

[0022] The block on-chain module is used to propose the current block to each validator node in the current view and instruct each validator node in the current view to write the committable block into the blockchain ledger.

[0023] According to a fourth aspect of this application, a block consensus apparatus is provided, applied in at least one validator node, the apparatus comprising:

[0024] The instruction information acquisition module is used to acquire instruction information on the blocks proposed by the master node in the current view and the blocks that can be committed.

[0025] The information receiving judgment module is used to confirm that the information receiving is normal if it obtains the block proposal and the indication information of the committable block of the master node of the current view within the first preset time.

[0026] The local block storage module is used to store the proposed block locally when the information reception is confirmed to be normal.

[0027] The voting message generation module is used to vote on the blocks proposed by the master node of the current view in order to generate voting messages for the blocks;

[0028] The voting information feedback module is used to feed back the voting messages of the block to the master node of the next view, so that the master node of the next view can determine whether the block is a committable block based on the voting messages.

[0029] According to a fifth aspect of this application, an electronic device is provided, the electronic device comprising:

[0030] At least one processor; and

[0031] A memory communicatively connected to the at least one processor; wherein,

[0032] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the block consensus method described in the first aspect embodiment of this application; and / or, to execute the block consensus method described in the second aspect embodiment of this application.

[0033] According to a sixth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the block consensus method described in the first aspect embodiment of this application; and / or to execute the block consensus method described in the second aspect embodiment of this application.

[0034] The technical solution of this application embodiment involves the current master node obtaining the voting message from the previous view under the current view. As the block assembler, the current master node determines whether a block can be submitted based on the corresponding view number of the block included in the voting message, and shares the confirmed submittable current block with all validator nodes. Based on the previous round of voting messages, only one round of communication is needed in the current view to confirm that a certain block has reached consensus among all validator nodes, thereby putting the submittable current block on the chain. This solves the defect in the prior art that requires two communication sessions to reach consensus on a certain block, resulting in slow consensus efficiency, and further improves the overall consensus efficiency of the blockchain.

[0035] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart of a block consensus method provided according to Embodiment 1 of this application;

[0038] Figure 2 This is a flowchart of a block consensus method provided according to Embodiment 2 of this application;

[0039] Figure 3 This is a schematic diagram of a block consensus mechanism applicable to Embodiment 3 of this application;

[0040] Figure 4 This is a schematic diagram of a block consensus device according to Embodiment 4 of this application;

[0041] Figure 5 This is a schematic diagram of a block consensus device according to Embodiment 5 of this application;

[0042] Figure 6 This is a schematic diagram of the structure of an electronic device that implements the block consensus method of the embodiments of this application. Detailed Implementation

[0043] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0044] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0045] Before explaining the embodiments of this application, a brief introduction to the block consensus scheme in the prior art is given: Currently, when reaching consensus on a block, node X, as the master node, generates and proposes block A, and sends the proposed block A to other nodes for voting, i.e., whether to approve the passage of block A. These other nodes are the validator nodes. In the crash error model, at least one round of voting is required to reach consensus on a certain block. If all validator nodes agree to pass transaction A in one round of voting, then transaction A is recognized by all nodes and can be directly written into the blockchain ledger. The master node X communicates with the validator nodes in the first round, sending the proposed block A. At this time, the validator nodes cannot submit block A because they do not know whether other validator nodes will submit block A. After the master node receives the response from a majority of validator nodes, it will communicate with the validator nodes in another round, notifying the validator nodes that the proposed block A has been recognized by a majority of validator nodes and can be submitted to the blockchain ledger. This round of consensus ends.

[0046] Of course, during the voting process, there are often instances where votes do not pass completely. Some validator nodes may not accept the blocks and transactions proposed by the master node, or due to network errors, the master node may not receive the vote responses from the validator nodes. In such cases, another round of voting is required. Each round of voting corresponds to a view: the first round of consensus where all nodes fail to reach a consensus is considered view 0 (if consensus is reached in view 0, the consensus round ends as described above and is written into the blockchain ledger); the process of re-voting is considered view 1. In view 0, if node X, as the master node, proposes transaction A but it is not approved, in view 1, node Y becomes the master node and proposes the transaction. Figure 1The master node Y first needs to communicate with each validator node in view 0 to obtain the voting results; this process is generally called the view transition protocol. At this point, there are two scenarios: First, if a majority of nodes in view 0 agree on transaction A, then in view 2, node Y must propose block A again and submit it to all validator nodes for voting. Second, if no majority of nodes in view 0 agree on block A, then in view 1, node Y can propose a new transaction B and submit it to all validator nodes for voting, thus determining whether block B can reach consensus in this round of voting. If consensus still cannot be reached in view 1, the process switches to view 2, and other nodes take over the master node role to propose transactions, and so on, until all nodes can reach consensus. However, this block consensus method is complex and lengthy, requiring a large amount of communication between nodes, resulting in long consensus times and low block consensus efficiency.

[0047] Example 1

[0048] Figure 1 This application provides a flowchart of a block consensus method in Embodiment 1. This embodiment is applicable to situations where blocks in a blockchain reach consensus. The method can be executed by a block consensus device, which can be implemented in hardware and / or software. This block consensus method can be applied to the current master node, and the block consensus device can be configured in an electronic device. Figure 1 As shown, the method includes:

[0049] S110. According to the ascending order of views, the current master node in the current view obtains the voting messages of each validator node in the previous view.

[0050] Since block generation follows a sequential order, blocks 0, 1, 2, and so on are generated according to the order in which nodes propose them. Each view has a unique view number, which increments sequentially. Each view has a unique master node, and each node can determine its current master node based on its current view number and preset rules. The master node can propose blocks within the current view. The previous view can be the view corresponding to the previous master node, and validator nodes can be any node other than the master node. Voting messages represent votes from validator nodes regarding the master node's proposal, and these messages are sent to the master node within a view for coordination. It's understood that a master node in the previous view is a validator node in the current view, and vice versa. Furthermore, voting messages can indicate their source, such as which validator node and voting round they came from—essentially, which view the vote originated from. This distinction is made by recording the view number, allowing for subsequent confirmation of the number of votes cast for each proposal.

[0051] S120. If the voting messages of the previous view obtained by the current master node exceed the preset threshold, the block with the highest view number is obtained from each voting message.

[0052] It should be noted that when the current master node obtains voting information from the previous view, there is a preset threshold to check whether all normal voting information has been collected (because some erroneous information and data need to be discarded). Furthermore, after the received voting messages reach this preset threshold, the block with the highest view number among these voting messages is determined.

[0053] S130. Generate the current block based on the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number.

[0054] The current transaction information can be the transaction content that the current master node wants included in the block it is about to propose, and it will also become the content for the block to be voted on. The block to be proposed by the current master node is generated by assembling the hash value of the block with the highest view number, the current transaction information, and the current view number. The content of the current block includes the hash value of the block with the highest view number in the previous view, which is equivalent to the current block pointing to the block with the highest view number in the previous view. The block with the highest view number in the previous view is called the preceding block of the current block. Block assembly is performed by the current master node, and the method of block assembly is not limited in this embodiment.

[0055] S140. When all the blocks included in the voting messages of the previous view are exactly the same and the view number in the block is the previous view number, the block is confirmed as a committable block.

[0056] The criteria for determining whether a block is committable are based on whether all the blocks in the voting messages of the previous view obtained by the current master node are identical. In other words, it's about whether more than a certain threshold of validator nodes in the previous view endorse the proposed block. If the blocks included in the obtained voting messages are completely identical, and all view numbers belong to the previous view, the block can be committed. This confirmed committable block is called a committable block, which can be understood as the preceding block to the currently assembled proposed block.

[0057] S150. Propose the current block to each validator node in the current view and instruct each validator node in the current view to write the committable block into the blockchain ledger.

[0058] In the current view, after assembling the current block, the current master node shares the current block with all current validator nodes, thus proposing the current block. Furthermore, the current master node shares the committable block confirmed in the previous step with the current validator nodes, notifying all validator nodes to write the committable block into the blockchain ledger, thereby completing the on-chain process of this committable block.

[0059] The technical solution of this application embodiment is that the current master node obtains the voting message of the previous view under the current view. As the block assembler, the current master node judges whether the block can be submitted according to the corresponding view number of the block included in the voting message, and shares the confirmed submittable block and the newly proposed block with all validator nodes at the same time. This solves the defect in the prior art that two communications are required for consensus on a certain block, which makes the consensus efficiency slow, thereby improving the efficiency of the overall consensus of the blockchain.

[0060] Example 2

[0061] Figure 2 This application provides a flowchart of a block consensus method in Embodiment 2. This embodiment is applicable to situations where blocks in a blockchain reach consensus. The method can be executed by a block consensus device, which can be implemented in hardware and / or software. This block consensus method can be applied to at least one validator node, and the block consensus device can be configured in an electronic device. Figure 2 As shown, the method includes:

[0062] S210. Obtain the block proposal and committable block indication information of the master node in the current view.

[0063] Among them, the proposed block is the block assembled by the current master node, and the committable block is the block confirmed by the current master node and reached through consensus by voting by all validator nodes.

[0064] S220. If the block proposal and the indication information of the committable block proposed by the master node of the current view are obtained within the first preset time, then the information reception is confirmed to be normal.

[0065] The first preset time can be used to confirm whether the current verifier node is receiving messages normally from the current master node. The first preset time can be implemented using a timer. Of course, the first preset time can be set by relevant technical personnel according to actual conditions or human experience, and this application embodiment does not limit this.

[0066] S230. When it is confirmed that the information reception is normal, the proposed block is stored locally.

[0067] Once each validator node confirms receipt of the proposed block and the indication information for a committable block sent by the current master node, it stores the proposed block locally.

[0068] S240. Vote on the block proposed by the master node of the current view and generate a block voting message.

[0069] Each validator node votes on the block proposed by the current master node and generates a voting message, which is the voting message under the current view.

[0070] S250: Feed back the block voting message to the master node of the next view, so that the master node of the next view can determine whether the block is a committable block based on the voting message.

[0071] After the current round of voting in the current view ends, all voting messages in the current view will be sent to the next master node of the next view. This allows the master node of the next view to determine whether the proposed current block has reached consensus among all nodes based on these voting messages. If the vote passes and consensus is reached, the current block can be confirmed as a committable block and can be added to the blockchain.

[0072] In one alternative implementation, the method may further include: each validator node writing a committable block into the blockchain ledger according to the instruction information for committable blocks.

[0073] After receiving the instruction information for a committable block sent by the master node corresponding to the view, all validator nodes in each view can put the committable block on the chain, that is, write it into the node's blockchain ledger.

[0074] In one alternative implementation, the method may further include: determining whether the preceding block of the committable block has been stored locally; if the preceding block is not stored locally, requesting the preceding block from the master node of the current view or other validator nodes so as to write the preceding block into the blockchain ledger.

[0075] In this context, a preceding block can be any block that has been uploaded to the blockchain by any node before the committable block. Since the uploading of blocks is sequential, any block uploaded before the committable block can be considered a preceding block. It's understandable that a blockchain is an immutable ledger; if omissions occur, they should be promptly corrected. Therefore, if a missing preceding block is discovered before the committable block is uploaded, information about the preceding block can be obtained from other nodes (including the current master node and other validator nodes). The missing preceding block can then be corrected on the current node before the committable block is uploaded.

[0076] In one optional implementation, the method may further include: if the block proposed by the master node of the current view and the indication information of the block that can be submitted are not obtained within a first preset time, then confirm that the information reception has timed out; after confirming that the information reception has timed out, the locally stored block is fed back to the master node of the next view.

[0077] If the current block and commit indication information published by the current master node to all validator nodes are not received within the first preset time, it can be determined that a transmission problem has occurred between the nodes, and the information transmitted between the nodes cannot be received within a reasonable time. Therefore, after the information reception timeout, the block already stored locally in the current validator node can be directly sent to the next master node, thus entering the consensus phase of the next view.

[0078] In one optional implementation, the method may further include: after feeding back the locally stored block to the master node of the next view, confirming whether the master node of the next view has received the block proposal and the indication information of the committable block within a second preset time; if the master node of the next view has not received the block proposal and the indication information of the committable block within the second preset time, confirming that the information reception has timed out; if the master node of the next view has received the block proposal and the indication information of the committable block within the second preset time, confirming that the information reception is normal, and adjusting the time for receiving the master node's block proposal and the indication information of the committable block to the initial preset time.

[0079] The second preset time can be the verification time after the validator node of the current view sends its local block to the master node of the next view. It can be understood that the second preset time is for the consensus phase in the next view, equivalent to other consensus processes that occur after the consensus process of the current view has ended. Of course, the second preset time can be set by relevant technical personnel based on actual conditions or human experience, and can be set according to the length of the first preset time. For example, the second preset time can be a multiple of the first preset time.

[0080] If no block proposal or committable block indication is received from the next view's master node within the second preset time, then the message reception is considered to have timed out. If a block proposal or committable block indication is received from the next master node within the second preset time, then the message reception can be considered normal. In other words, even if the current validator node timed out sending information to the next master node between previous and next views, after this normal message reception, it can be considered that a correct and valid interaction has occurred, and the timeout duration can be restored to the default time, i.e., the initial preset time. Of course, the initial preset time can be the same as or different from the first preset time.

[0081] The technical solution of this application simplifies the existing technology and improves the efficiency of block consensus by having each validator node vote on the current proposed block assembled by the master node, and at the same time helping the blockchain determine the current committable block. Communication is only required once in a view.

[0082] Example 3

[0083] Figure 3 This is a schematic diagram of a block consensus mechanism applicable to an embodiment of this application. The embodiment of this application provides a preferred embodiment of block consensus based on the foregoing implementation methods, as detailed below:

[0084] First, let's introduce the basic data structures that appear in the block consensus process:

[0085] I. A block, in its simplified form, comprises at least three parts: (at least one) a transaction (represented by txs), a view number (viewNumber), and a hash. The hash points to the parent block of the current block, represented by the parent symbol. Therefore, a block can be represented as B = (txs, viewNumber, parent). Blocks are generated by the leader node and sent to all validator nodes via a proposal message.

[0086] 2. The view number is represented by viewNumber.

[0087] 3. The block with the highest viewNumber known to the validator node is called highBlock. It is the block with the highest viewNumber that the validator node knows from the propose message. Each time the validator node receives a propose message sent by the master node, it updates highBlock and stores it locally.

[0088] 4. commitpointer: A pointer to a block that can be committed.

[0089] The following types of messages can be sent between nodes:

[0090] 1. vote(view, block): Used to vote on a block (or node). view is the view and block is the block to be voted on.

[0091] 2. propose(block, commitpointer): Used to propose a block. Similarly, block is the proposed block, and commitpointer is a pointer to the block that can be committed.

[0092] The following process aims to illustrate the flow of master nodes and validator nodes in view v. As mentioned above, the current master node becomes a validator node in the voting process of the next view after proposing a block.

[0093] In the current master node, first collect the vote messages (i.e., voting messages) sent by the validator nodes in view v, until nf vote messages are collected, where n is the total number of nodes and f is the number of erroneous nodes. In the set M of nf vote messages, find the message with the highest viewNumber, and use the block in this message to update the master node's highBlock.

[0094] Next, assemble the current block B = [txs, v, hash(highBlock)], where txs is the transaction the current master node wants to include, highBlock is the updated value mentioned above, hash is the hash value of highBlock, and v is the current view number. If the blocks in every message in set M are consistent, and the view corresponding to each block is v-1, then the commitpointer can be pointed to this highBlock, meaning that this highBlock can be committed and written to the blockchain ledger.

[0095] Then, the current master node sends propose(block, commitpointer) to all validator nodes and transitions to the next view v+1.

[0096] For each validator node, upon receiving the propose message, it updates its local view number and changes the view to the next view. It updates its own highBlock using the block from the propose(block, commitpointer) message and updates its own commitpointer using the commitpointer from the propose message. It then checks if the preceding block pointed to by the updated commitpointer exists locally; if not, it fills in all missing preceding blocks in ascending view order. Finally, it commits all blocks sequentially on the current validator node, starting with the block executed by the last commit.

[0097] Vote on the block in the propose message, send the vote message vote(view, block) to the current master node and proceed to the next view v+1.

[0098] In the above steps, both the master node and the validator node have timeout mechanisms. If the corresponding message is not received within a preset time, the message transmission is considered to have timed out. If the transmission timeout occurs, the local view number is first incremented by 1, i.e., viewNumber = v + 1. Simultaneously, vote(v + 1, highBlock) is sent to the master node of view v + 1. Of course, for timeout handling, the timeout duration can be extended by a multiple of the original setting, for example, 1.5 times the original duration: after the first timeout, the node's timeout duration is set to t = 1.5t, that is, the timeout duration is increased to 1.5 times the original. Changing the timeout duration to 1.5 times the original is to gradually extend the timeout events. After a normal interaction occurs, the timeout time is restored to the default value.

[0099] Example 4

[0100] Figure 4 This is a schematic diagram of a block consensus device provided in Embodiment 4 of this application. This device can be used by the current master node. Figure 4 As shown, the device 400 includes:

[0101] The voting verification module 410 is used to obtain the voting messages of each verifier node in the previous view from the current master node in the current view according to the ascending order of the views;

[0102] The block acquisition module 420 is used to acquire the block with the highest view number from each voting message if the voting messages of the previous view obtained by the current master node exceed a preset threshold.

[0103] The block generation module 430 is used to generate the current block based on the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number;

[0104] The block confirmation module 440 is used to confirm a block as a committable block when the blocks included in each voting message of the previous view are exactly the same and the view number in the block is the previous view number.

[0105] The block on-chain module 450 is used to propose the current block to each validator node in the current view and instruct each validator node in the current view to write the committable block into the blockchain ledger.

[0106] In the technical solution of this application embodiment, the current master node obtains the voting message of the previous view under the current view. As the assembler of blocks, the current master node judges whether the block can be submitted based on the corresponding view number of the block included in the voting message, and shares the current block that is confirmed to be submittable with all validator nodes. In the current view, it is only necessary to go through one round of communication to confirm that the current block has reached a consensus among the validator nodes, thereby improving the efficiency of the overall consensus of the blockchain.

[0107] The block consensus device provided in this application embodiment can execute the block consensus method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each block consensus method.

[0108] Example 5

[0109] Figure 5 This is a schematic diagram of a block consensus device provided in Embodiment 5 of this application. This device can be applied to at least one validator node. Figure 5 As shown, the device 500 includes:

[0110] The instruction information acquisition module 510 is used to acquire instruction information on the blocks proposed by the master node in the current view and the blocks that can be committed.

[0111] The information receiving judgment module 520 is used to confirm that the information receiving is normal if it obtains the indication information of the block proposed by the master node of the current view and the block that can be submitted within a first preset time.

[0112] The local block storage module 530 is used to store the proposed block locally when the confirmation information is received normally.

[0113] The voting message generation module 540 is used to vote on the block proposed by the master node of the current view and generate the voting message for the block.

[0114] The voting information feedback module 550 is used to feed back the voting messages of the block to the master node of the next view, so that the master node of the next view can determine whether the block is a committable block based on the voting messages.

[0115] The technical solution of this application improves the efficiency of block consensus by having each validator node vote on the current block assembled by the master node, thereby helping the blockchain determine whether the current block can be agreed upon and uploaded to the chain.

[0116] In one alternative embodiment, the device 500 may further include:

[0117] The ledger writing module is used by each validator node to write commitable blocks into the blockchain ledger according to the instructions for committable blocks.

[0118] In one alternative embodiment, the device 500 may further include:

[0119] The storage determination module is used to determine whether the preceding block of a committable block has been stored locally;

[0120] The node request module is used to request the preceding block from the master node or other validator nodes of the current view if the preceding block is not stored locally, so that the preceding block can be written into the blockchain ledger.

[0121] In one alternative embodiment, the device 500 may further include:

[0122] The timeout judgment module is used to confirm that the information reception has timed out if the block proposed by the master node of the current view and the indication information of the block that can be submitted are not obtained within the first preset time.

[0123] The voting feedback module is used to send the locally stored block back to the master node of the next view after the confirmation message reception timeout.

[0124] In one alternative embodiment, the device 500 may further include:

[0125] The instruction information confirmation module is used to confirm whether, after feeding back the locally stored block to the master node of the next view, it has received the instruction information of the proposed block and the block that can be committed from the master node of the next view within a second preset time.

[0126] If the block proposal and the indication of a committable block are not received from the master node of the next view within the second preset time, the confirmation message reception timeout will occur.

[0127] If the master node proposes a block and indicates a block that can be committed in the next view is received within the second preset time, the information reception is confirmed to be normal, and the time for receiving the master node's proposed block and indication of a block that can be committed is adjusted to the initial preset time.

[0128] The block consensus device provided in this application embodiment can execute the block consensus method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each block consensus method.

[0129] Example 6

[0130] Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0131] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0132] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0133] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as block consensus methods.

[0134] In some embodiments, the block consensus method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the block consensus method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the block consensus method by any other suitable means (e.g., by means of firmware).

[0135] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0136] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0137] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0138] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0139] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0140] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0141] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0142] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A block consensus method, characterized in that, Applied to the current master node, the method includes: According to the ascending order of views, the current master node in the current view obtains the voting messages of each validator node in the previous view; If the voting messages of the previous view obtained by the current master node exceed a preset threshold, the block with the highest view number is obtained from each of the voting messages; The current block is generated based on the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number; When all the voting messages in the previous view contain the same blocks and the view number in the block is the previous view number, the block is confirmed as a committable block. The current block is proposed to each validator node in the current view, and each validator node in the current view is instructed to write the committable block into the blockchain ledger.

2. A block consensus method, characterized in that, The method, applied to at least one validator node, includes: Retrieve the block proposals and committable block indication information from the master node in the current view; If the block proposal and committable block indication information of the current view's master node are obtained within the first preset time, then the information reception is confirmed to be normal. Once it is confirmed that the information reception is normal, the proposed block will be stored locally. Vote on the block proposed by the master node of the current view and generate a voting message for the block; The voting message for the block is fed back to the master node of the next view, so that the master node of the next view can determine whether the block is a committable block based on the voting message.

3. The method according to claim 2, characterized in that, The method further includes: each validator node writing the commitable block into the blockchain ledger according to the instruction information of the commitable block.

4. The method according to claim 3, characterized in that, The method further includes: Determine whether the preceding block of the committable block has already been stored locally; If the preceding block is not stored locally, request the preceding block from the master node or other validator nodes of the current view so that the preceding block can be written into the blockchain ledger.

5. The method according to claim 2, characterized in that, The method further includes: If the block proposal and the indication information of the committable block proposed by the master node of the current view are not obtained within the first preset time, the confirmation message reception timeout will occur. After confirming that the message reception timeout has expired, the locally stored block is fed back to the master node of the next view.

6. The method according to claim 5, characterized in that, The method further includes: after feeding back the locally stored block to the master node of the next view, confirming whether the master node of the next view has received the block proposal and the indication information of the block that can be submitted within a second preset time. If the block proposal and the indication of a committable block are not received from the master node of the next view within the second preset time, the confirmation message reception timeout will occur. If the master node proposes a block and indicates a block that can be committed in the next view is received within the second preset time, the information reception is confirmed to be normal, and the time for receiving the master node's proposed block and indication of a block that can be committed is adjusted to the initial preset time.

7. A block consensus device, characterized in that, Applied to the current master node, the device includes: The voting verification module is used to obtain the voting messages of each validator node in the previous view from the current master node in the current view in ascending order of views; The block acquisition module is used to acquire the block with the highest view number from each of the voting messages if the voting messages of the previous view obtained by the current master node exceed a preset threshold. The block generation module is used to generate the current block based on the hash value of the block with the highest view number, the current transaction information in the current view, and the current view number; The block confirmation module is used to confirm a block as a committable block when the blocks included in the voting messages of the previous view are completely identical and the view number in the block is the previous view number. The block on-chain module is used to propose the current block to each validator node in the current view and instruct each validator node in the current view to write the commitable block into the blockchain ledger.

8. A block consensus device, characterized in that, The device, applied in at least one validator node, comprises: The instruction information acquisition module is used to acquire instruction information on the blocks proposed by the master node in the current view and the blocks that can be committed. The information receiving judgment module is used to confirm that the information receiving is normal if it obtains the indication information of the block proposed by the master node of the current view and the block that can be submitted within the first preset time. The local block storage module is used to store the proposed block locally when the information reception is confirmed to be normal. The voting message generation module is used to vote on the block proposed by the master node of the current view and generate the voting message for the block; The voting information feedback module is used to feed back the voting messages of the block to the master node of the next view, so that the master node of the next view can determine whether the block is a committable block based on the voting messages.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the block consensus method of claim 1; and / or, to perform the block consensus method of any one of claims 2-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute and implement the block consensus method of claim 1; and / or, implement the block consensus method of any one of claims 2-6.

Images