Blockchain consensus method and device, electronic device, and storage medium

Abstract

This application provides a blockchain consensus method and device, electronic device, and storage medium. The method includes: when a blockchain forks at a first block height, selecting a forked block as a parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block; generating a new block at a second block height based on the information of the uncle block; broadcasting the new block in the blockchain network, so that after receiving the new block, consensus nodes in the blockchain network verify the correctness of the new block. If the verification is successful, the consensus voting process for the new block begins. This solution eliminates the need for manual intervention in forking issues. When a forked block occurs, consensus can continue, increasing the fault tolerance of the consortium chain against malicious nodes.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain consensus method and device, electronic device, and computer-readable storage medium. Background Art

[0002] Consortium chains primarily use PBFT (Practical Byzantine Fault Tolerance) or BFT (Byzantine Fault Tolerance) consensus algorithms optimized on top of PBFT, with different implementations. The FISCO-BCOS consortium chain directly uses the PBFT algorithm.

[0003] In PBFT theory, the network is assumed to have 3f+1 nodes, with no more than f Byzantine nodes. Consensus availability is guaranteed by the viewChange protocol, which assumes no more than f Byzantine nodes. If the number of Byzantine nodes exceeds f, they are not considered in this algorithm.

[0004] If there are more than f malicious nodes, and a malicious node becomes a block producer and simultaneously packages and broadcasts two legitimate blocks, the blockchain system will still fork. After the fork occurs, the block producer at the next consensus height will be unable to determine which block to use as the parent block for the new block. In this case, human intervention is required to resolve the fork problem and ensure the system can continue to operate. Summary of the Invention

[0005] The embodiments of the present application provide a blockchain consensus method, which does not require manual intervention in forking problems, and the consensus can continue, thereby increasing the fault tolerance of the alliance chain against malicious nodes.

[0006] The present application provides a blockchain consensus method, including:

[0007] When a blockchain forks at the first block height, one forked block is selected as the parent block based on the random number of each forked block, and the remaining forked blocks are selected as uncle blocks.

[0008] Generate a new block at a second block height based on the information of the uncle block;

[0009] The new block is broadcasted in the blockchain network, so that after receiving the new block, the consensus nodes in the blockchain network verify the correctness of the new block. If the verification is successful, the consensus voting process for the new block is entered.

[0010] In one embodiment, when a blockchain forks at a first block height, before selecting a forked block as a parent block and the remaining forked blocks as uncle blocks based on a random number of each forked block, the method further includes:

[0011] If there are at least two blocks at the first block height whose number of votes exceeds two-thirds of the total number of nodes, the at least two blocks are stored on the chain at the same time to obtain at least two forked blocks.

[0012] In one embodiment, the process of selecting a forked block as a parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block includes:

[0013] According to the random number of each forked block, the forked block with the smallest random number is selected as the parent block, and the remaining forked blocks are selected as the uncle blocks.

[0014] In one embodiment, the new block includes a random number field and an uncle block reference field.

[0015] In one embodiment, generating a new block at a second block height based on the uncle block information includes:

[0016] Obtaining a parameter value of the uncle block reference field according to the number of uncle blocks and the hash value of each uncle block;

[0017] Generate a random number and assign it to the random number field, and add the generated random number and the parameter value to a new block of the second block height.

[0018] In one embodiment, verifying the correctness of the new block includes:

[0019] Verify whether the uncle block information included in the new block is the same as the uncle block information of the local blockchain of the consensus node.

[0020] In one embodiment, verifying the correctness of the new block further includes:

[0021] Verify the correctness of the parent block pointed to by the new block and the correctness of the transaction data contained in the new block.

[0022] In one embodiment, verifying the correctness of the parent block pointed to by the new block and verifying the correctness of the transaction data contained in the new block includes:

[0023] Verify that the hash value contained in the block header of the new block is the same as the hash value of the parent block;

[0024] Verify whether the root hash value included in the block header of the new block is the same as the Merkle tree root value of the transaction information included in the block body of the new block.

[0025] In one embodiment, if the verification passes, the consensus voting process for the new block is entered, including:

[0026] If the verification is successful, the consensus node broadcasts the voting information for the new block in the blockchain network;

[0027] If the number of votes for the new block exceeds two-thirds of the total number of nodes, the new block will be stored on the chain.

[0028] In one embodiment, the method further comprises:

[0029] If the verification fails, the consensus node initiates a view change request to elect a new block producer.

[0030] The present application also provides a blockchain consensus device, including:

[0031] The block selection module is used to select a forked block as the parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block when the blockchain forks at the first block height;

[0032] A new block generation module, configured to generate a new block of a second block height based on the information of the uncle block;

[0033] The block consensus module is used to broadcast the new block in the blockchain network, so that after receiving the new block, the consensus nodes in the blockchain network verify the correctness of the new block. If the verification is successful, the consensus voting process for the new block begins.

[0034] An embodiment of the present application further provides an electronic device, comprising:

[0035] processor;

[0036] a memory for storing processor-executable instructions;

[0037] The processor is configured to execute the consensus method of the blockchain.

[0038] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. The computer program can be executed by a processor to complete the above-mentioned blockchain consensus method.

[0039] The solution provided by the embodiments of this application is that when a blockchain forks at a first block height, one forked block is selected as the parent block based on the random number of each forked block, and the remaining forked blocks are selected as uncle blocks. A new block at a second block height is generated based on the information in the uncle block. This new block is broadcast to the blockchain network, so that consensus nodes in the blockchain network, upon receiving the new block, verify its correctness. If the verification passes, the consensus voting process for the new block begins. This solution eliminates the need for manual intervention in forking issues, and consensus can continue even when a forked block occurs, increasing the consortium chain's fault tolerance against malicious nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments of the present application.

[0041] Figure 1 A schematic diagram of the basic process of the PBFT algorithm provided in the embodiments of this application;

[0042] Figure 2 This is a schematic diagram of an application scenario of the blockchain consensus method provided in an embodiment of the present application;

[0043] Figure 3 is a structural diagram of an electronic device provided in an embodiment of the present application;

[0044] Figure 4 This is a flowchart of the consensus method of the blockchain provided by the embodiment of the present application;

[0045] Figure 5 A block diagram of a blockchain consensus device according to an embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0047] Similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0048] Introduction to the PBFT Algorithm: The PBFT algorithm is based on the Byzantine fault model and can achieve consensus among healthy nodes even in the presence of faulty nodes. Faulty nodes can be divided into two types: down nodes, which do not send any response messages. Malicious nodes, which can exhibit incorrect behavior, such as malicious voting. Faulty node behavior can be arbitrary, including node failure, delayed communication, collaborating with malicious nodes to negotiate, and sending erroneous information. Nodes in the network use cryptographic techniques to authenticate each other's identities and messages. All nodes store the public keys of other nodes and use these keys to verify the signatures of messages from other nodes. No attacker in the network can forge signatures.

[0049] The PBFT algorithm can tolerate f = (n-1) / 3 Byzantine nodes, where n represents the total number of network nodes and f represents the maximum number of tolerated Byzantine nodes. Specifically, as long as the number of Byzantine nodes in the network does not exceed (n-1) / 3, the algorithm ensures both security and availability of network consensus. Security means that no matter what actions malicious nodes take, even if they act in concert and send a unified error message, the consensus of other normal nodes in the network will not be affected. Whether the network is synchronous or asynchronous does not affect the security of the algorithm. However, the availability of the algorithm relies on weak synchronization. In an asynchronous network, communication between nodes will have an infinite delay, which will affect the progress of network consensus. As long as the communication delay time t between correct nodes is not infinite, the consensus process will not be interrupted, and the algorithm maintains availability.

[0050] PBFT consensus is based on a client-server architecture. The general process is that the client sends a request to the server network, which broadcasts the request within the network. After reaching consensus, the request is executed and the results are fed back to the client. The client confirms the request has been executed after receiving confirmation from f+1 servers. Since the network can have at most f faulty servers, the fact that one healthy node executes the request indicates that the network has reached consensus on the request.

[0051] The basic process of the PBFT algorithm is as follows Figure 1 The three core phases of the algorithm are the pre-prepare phase, the prepare phase, and the commit phase.

[0052] The client initiates a request to the master node. After receiving the client request, the master node will send a pre-prepare message to other nodes (excluding the master node). When other nodes receive the pre-prepare message, the core three-stage consensus process begins. Pre-prepare stage: After receiving the pre-prepare message, other nodes will have two options: accept or reject. Prepare stage: After the node agrees to the request, it will send a prepare message (signature package) to other nodes. Within a certain time frame, if at least 2f+1 prepare messages are received from different nodes, it means that the prepare stage has been completed. Then it enters the commit stage and broadcasts the commit message to other nodes. After receiving at least 2f+1 commit messages (including itself), it means that the majority of nodes have entered the commit stage and consensus has been reached in this stage, so the node will execute the request and write the data.

[0053] In the PBFT implementation of FISCO (the consortium blockchain), a solution was considered for situations where more than f nodes are down. This is because, in reality, there's no guarantee that the number of Byzantine nodes will not exceed f. It's possible that more than f nodes might experience power outages or network message transmission failures. In this case, the blockchain system loses availability at a certain block height, and consensus and storage at that height cannot continue. Manual intervention is required to wait for all Byzantine nodes to recover before restarting the blockchain system. However, this can lead to a fork in the blockchain. The specific scenarios that may cause a fork are as follows:

[0054] Suppose four nodes, abcd, are working towards consensus on block M at height h. Just after abcd completes the prepare phase and enters the commit phase, sending a commit message, node bcd crashes. Node a, however, receives enough commit messages to have block M on the chain and begin consensus at height h+1. However, due to the downtime of bcd, a's consensus at height h+1 will fail. When bcd resumes normal operation, if bcd now considers a to be the masternode for the current consensus height h, and a broadcasts block N at height h, node bcd will reach consensus on block N and simultaneously synchronize a's block M at height h. Consequently, the blockchain forks, resulting in blocks M and N at height h.

[0055] FISCO's solution to this situation is to persist block X in storage before entering the commit phase after receiving enough prepare votes for block X in the prepare phase. When the node crashes and restarts, it first retrieves block X from the database and continues to reach consensus on block X, thus ensuring that the blockchain does not fork.

[0056] After the prepare phase of the consensus phase is completed, the consensus block is persistently stored. This is a fault-tolerant solution for large-scale node failures. This allows the consortium chain system to continue reaching consensus on blocks even after more than f nodes fail and restart. This is essentially a fault-tolerant solution for situations where more than f nodes fail.

[0057] There are two types of faulty nodes in PBFT: downtime, which means no messages or responses are sent. Malicious nodes, on the other hand, send incorrect information to valid nodes. Existing solutions only consider the case where there are more than f downtime nodes, but not the case where there are more than f malicious nodes.

[0058] If there are more than f malicious nodes, and a malicious node becomes the consensus leader and simultaneously packages and broadcasts two legitimate blocks, the blockchain system will still fork. After the fork, the leader at the next consensus height will be unable to determine which block to use as the parent block for packaging the new block. In this case, human intervention is required to resolve the fork problem and ensure the system can continue to operate.

[0059] Therefore, the embodiment of this application aims to ensure that when there are more than f malicious nodes in the system and the blockchain forks, consensus can continue without human intervention, thereby increasing the fault tolerance of the consortium chain system against malicious nodes.

[0060] In consortium blockchain business scenarios, consortium chains primarily serve to ensure the immutability of ledger records. Because blockchains using PBFT algorithms cannot fork within their fault tolerance, most current consortium chains define a valid blockchain as one that has not forked. This ensures data immutability. However, in blockchain systems using PBFT consensus, each block contains a set of consensus signatures from nodes, guaranteeing the validity of transactions within that block. Furthermore, the essence of PBFT consensus is to ensure the consistency of the state machines of all nodes. Therefore, even if a consortium chain forks, as long as the state machines of all nodes are consistent and the transactions in the forked block are valid, the accuracy and immutability of the ledger records will not be affected from the consortium chain's business perspective.

[0061] Ethereum introduces the "uncle block" reference rule, which makes orphaned blocks from forks valid. Therefore, based on the concept and reference rule of Ethereum uncle blocks, the present embodiment first redefines the validity of the forked portion of a consortium chain after a forked block is generated. Second, it provides a method for handling consensus after a blockchain fork, allowing the consortium chain to continue the consensus process after a fork, thereby indirectly increasing the consortium chain's fault tolerance. The following describes the method for handling consensus after a blockchain fork in detail.

[0062] Figure 2 This is a schematic diagram of an application scenario of the consensus method of the blockchain provided by the embodiment of the present application. As shown in Figure 2, the application scenario includes multiple nodes 110, and the multiple nodes 110 are interconnected to form a blockchain network. The nodes 110 can be smart terminals such as desktop computers, laptops, servers, etc. The blockchain network can be a consortium chain. There may be some malicious nodes (indicated by black circles) among the multiple nodes 110. Figure 2For example, if there are 7 nodes in total, the maximum number of fault-tolerant nodes is 2. When there are 3 malicious nodes and 4 correct nodes, assuming that 2 correct nodes vote for block a and the other 2 correct nodes vote for block b, and the 3 malicious nodes vote for both block a and block b, then both block a and block b will have enough votes to be on the chain at the same time, resulting in a fork. Currently, manual intervention is required to resolve the fork so that the blockchain system can operate normally. The method provided in the embodiment of the present application can be executed by a block-producing node (also known as a leader node or master node) in multiple nodes 110. When the blockchain forks at the first block height h, a forked block is selected as the parent block based on the random number of each forked block, and the remaining forked blocks are used as uncle blocks; based on the information of the uncle block, a new block of the second block height h+1 is generated; the new block is broadcast in the blockchain network so that after the consensus node in the blockchain network receives the new block, it verifies the correctness of the new block. If the verification passes, the consensus voting process of the new block is entered. This allows the consortium chain to continue the consensus process after a fork occurs, thereby indirectly increasing the fault tolerance of the consortium chain.

[0063] Figure 3 Schematic diagram of the structure of the electronic device provided in the embodiment of the present application. The electronic device can be used as the node 110, and the electronic device 200 can be used to execute the consensus method of the blockchain provided in the embodiment of the present application. Figure 3 As shown, the electronic device 200 includes: one or more processors 202, and one or more memories 204 storing processor-executable instructions. The processor 202 is configured to execute the blockchain consensus method provided in the following embodiments of the present application.

[0064] The processor 202 can be a device including a central processing unit (CPU), a graphics processing unit (GPU) or other forms of processing units with data processing capabilities and / or instruction execution capabilities. It can process data of other components in the electronic device 200 and control other components in the electronic device 200 to perform desired functions.

[0065] The memory 204 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), a hard disk, or flash memory. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 202 may execute the program instructions to implement the blockchain consensus method described below. The computer-readable storage medium may also store various applications and various data, such as data used and / or generated by the applications.

[0066] In one embodiment, Figure 3 The electronic device 200 may further include an input device 206, an output device 208, and a data acquisition device 210, which are interconnected via a bus system 212 and / or other forms of connection mechanisms (not shown). Figure 2 The components and structures of the electronic device 200 shown are merely exemplary and non-limiting. The electronic device 200 may also have other components and structures as needed.

[0067] The input device 206 can be a device used by a user to input instructions, and can include one or more of a keyboard, a mouse, a microphone, and a touch screen. The output device 208 can output various information (e.g., images or sounds) to the outside (e.g., a user), and can include one or more of a display, a speaker, etc. The data acquisition device 210 can capture images of an object and store the captured images in the memory 204 for use by other components. For example, the data acquisition device 210 can be a camera.

[0068] In one embodiment, the various components in the example electronic device 100 for implementing the consensus method of the blockchain of the embodiment of the present application can be integrated or dispersed, such as integrating the processor 202, memory 204, input device 206 and output device 208 into one body, while separating the data acquisition device 210.

[0069] In one embodiment, the example electronic device 200 for implementing the consensus method of the blockchain of the embodiment of the present application can be implemented as an intelligent device such as a computer, a server, etc.

[0070] Figure 4 This is a flow chart of the consensus method of the blockchain provided by the embodiment of the present application. This method can be executed by the block node, such as Figure 4As shown, the method includes the following steps S410-S430.

[0071] Step S410: When the blockchain forks at the first block height, one forked block is selected as the parent block based on the random number of each forked block, and the remaining forked blocks are selected as uncle blocks.

[0072] Block height refers to the number of blocks created in a blockchain network. For example, the first block, often called the genesis block, has a height of 0, and the tenth block has a height of 9. Blocks don't all appear at once. For example, Bitcoin blocks are generated every 10 minutes. This means that blocks are generated in a certain order, and this order is labeled with the block height.

[0073] The first block height is used to distinguish it from the second block height described below. The second block height refers to the block number of the next block after the first block height, relative to the first block height. For example, if the first block height is h, the second block height is h+1.

[0074] If there is more than one block on the chain at the same block height, these blocks on the chain at the same block height can be called forked blocks.

[0075] Assuming a total of 3f+1 nodes, if the number of malicious nodes is less than or equal to f, consensus will proceed normally without forking. If the number of malicious nodes is greater than f but less than or equal to 2f, and the block producer at the first block height h is a malicious node, if the block producer simultaneously packages two valid blocks based on block h-1, the blockchain may produce two forked blocks at height h. If the number of malicious nodes exceeds 2f, the malicious node can forge a block composed of completely invalid transactions, vote on this block for consensus, and ultimately commit it to the blockchain. Therefore, the fault-tolerant number of nodes in the existing PBFT algorithm is f. This application can increase this to 2f.

[0076] In one embodiment, if there are at least two blocks at the first block height whose number of votes exceeds two-thirds of the total number of nodes, the at least two blocks are stored on the chain at the same time to obtain at least two forked blocks.

[0077] Based on the PBFT algorithm, when the total number of nodes reaches 3f+1, each node will collect 2f+1 commit votes and then store the corresponding block on-chain. Therefore, if at the first block height h, two blocks with votes exceeding two-thirds of the total number of nodes receive votes, both blocks at the first block height h will be stored on-chain. These two blocks are called cross-blocks. For example, a malicious node, acting as a block producer, may generate multiple blocks. If two valid blocks a and b are packaged and broadcast simultaneously, and if f valid nodes sign and vote for block a, f valid nodes sign and vote for block b, and f+1 malicious nodes simultaneously vote for block ab, then blocks ab will have enough votes to be simultaneously uploaded to the chain, resulting in a fork.

[0078] Among multiple cross-blocks, only one cross-block serves as the parent block. The next new block at block height h+1 is connected to this parent block. The remaining cross-blocks are called uncle blocks.

[0079] Each block includes a random number field. In one embodiment, based on the random number of each forked block, the forked block with the smallest random number can be selected as the parent block, and the remaining forked blocks can be selected as uncle blocks. As needed, each time a forked block appears, the forked block with the largest random number can always be selected as the parent block, and the remaining forked blocks can be selected as uncle blocks to generate a new block at the next height.

[0080] Step S420: Generate a new block of a second block height according to the information of the uncle block.

[0081] New blocks include an uncle block reference field, which represents the information about the referenced uncle block. Block producers can package transaction data into a new block at block height h+1 and add the uncle block reference field to the new block. Uncle block information can include the number of uncle blocks and their hash values. The parameter value of the uncle block reference field is generated based on the number of uncle blocks and the hash value of each uncle block.

[0082] Because the blockchain can still fork at height h+1, if a malicious node simultaneously broadcasts two valid blocks, there's still a chance both blocks will be included simultaneously. Therefore, the new block also includes a random number field. This ensures that malicious nodes always package and broadcast multiple forked blocks based on the same parent block with the smallest random number. Without this restriction, malicious nodes could generate multiple forked blocks based on multiple parent blocks, making the blockchain's forked structure uncontrollable.

[0083] Therefore, the above step S420 may include: obtaining the parameter value of the uncle block reference field based on the number of uncle blocks and the hash value of each uncle block; generating a random number to assign a random number field, and adding the generated random number and the parameter value to the packaged new block at the second block height. As a result, the new block at the second block height h+1, in addition to the existing block information, also references the uncle block information and random number. The uncle block reference rules here are different from those of Ethereum and are stipulated as follows:

[0084] (1) Each block at height h can only reference the uncle block at the previous height h-1. It cannot reference uncle blocks at other heights.

[0085] (2) The number of uncle blocks referenced by a block of height h must be the number of all forked blocks at height h-1-1.

[0086] (3) Each uncle block can only be referenced once.

[0087] Step S430: broadcast the new block in the blockchain network, so that after receiving the new block, the consensus nodes in the blockchain network verify the correctness of the new block. If the verification is successful, enter the consensus voting process for the new block.

[0088] A block-producing node can broadcast a new block within the blockchain network, essentially sending it to all other nodes except itself. For purposes of distinction, these nodes are referred to as consensus nodes. Each consensus node receives a new block and verifies it. If it matches its own blockchain, verification passes, confirming the new block's correctness. The node then broadcasts its votes for the new block to all nodes (including the block-producing node). Similarly, a consensus node also receives votes from other consensus nodes. If any node receives votes for a new block that exceed two-thirds of the total number of nodes, it can store the new block on-chain until all nodes reach consensus on block height h+1. The consensus process for block height h+2 can then begin.

[0089] Conversely, if a consensus node fails verification of a new block and finds it doesn't match its own blockchain, it will initiate a view change request, sending a message to other nodes to change the block producer. The consensus node can then elect itself as the block producer. If more than two-thirds of the nodes reply with a confirmation message, the new block producer is elected successfully. The new block producer can then submit its own block to consensus. The new block can also include a nonce field and an uncle block reference field.

[0090] Because the new blocks packaged in this application reference uncle block information, the verification of new blocks in this application differs from the existing technology. In addition to verifying the correctness of the parent block pointed to by the new block and the correctness of the transaction data contained in the new block, this application also needs to verify whether the uncle block information contained in the new block is the same as the uncle block information in the local blockchain of the consensus node.

[0091] In one embodiment, verifying the correctness of the parent block pointed to by the new block and verifying the correctness of the transaction data contained in the new block may specifically include: (1) verifying whether the hash value contained in the block header of the new block is the same as the hash value of the parent block, thereby ensuring that the parent block is the block with the smallest random number of block height h; (2) verifying whether the root hash value contained in the block header of the new block is the same as the Merkle tree root value of the transaction information contained in the block body of the new block; (3) calculating the information digest value digest-1 of the transaction data, decrypting the signature information of the new block according to the public key of the block-producing node, obtaining the information digest digest-2, and comparing digest-1 and digest-2 to see if they are consistent; (4) verifying the correctness of the timestamp in the block header of the new block.

[0092] In one embodiment, it is verified whether the information of the uncle blocks contained in the new block is the same as the information of the uncle blocks of the local blockchain of the consensus node, which may specifically include verifying whether the number of uncle blocks and the hash values ​​of the uncle blocks contained in the new block are the same as the number of uncle blocks and the hash value of each uncle block on the local blockchain.

[0093] The new block is considered valid only when all the above verification results are the same, that is, the information of the parent block of the new block, the transactions of the new block, the information of the uncle block referenced by the new block, and the block header are all verified.

[0094] It should be noted that although the consortium chain may fork, the immutability of the data will not be affected. This is because the hash values ​​of the multiple forked blocks generated at each block height h are recorded in the uncle block reference field of the next block at height h+1. If the data in the forked block at height h is tampered with, it will not match the uncle block reference field of the block at height h+1. Since all forked blocks at each block height are recorded in the block at the next height, the multiple forked blocks at each height can be treated as a logical whole block.

[0095] The nodes in the alliance chain are allowed to enter, and the situation where the number of malicious nodes exceeds f is relatively small. After a fork occurs, it can only be resolved through human intervention and negotiation. The method provided in the embodiment of this application can, when the number of malicious nodes is greater than f and less than or equal to 2f, when a forked block occurs, the alliance chain can still continue to reach consensus, thereby increasing the fault tolerance of the alliance chain system. The validity definition of the alliance chain ensures the immutability of the transaction data recorded in the alliance chain and the correctness of the transaction data.

[0096] The following are embodiments of the apparatus of the present application, which can be used to implement the consensus method embodiment of the blockchain of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the consensus method embodiment of the blockchain of the present application.

[0097] Figure 5 This is a block diagram of a consensus device for a blockchain according to one embodiment of the present application. Figure 5 As shown, the device includes: a block selection module 510, a new block generation module 520, and a block consensus module 530.

[0098] The block selection module 510 is used to select a forked block as a parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block when the blockchain forks at the first block height;

[0099] A new block generation module 520 is configured to generate a new block of a second block height based on the information of the uncle block;

[0100] The block consensus module 530 is used to broadcast the new block in the blockchain network, so that after receiving the new block, the consensus nodes in the blockchain network verify the correctness of the new block. If the verification is successful, the consensus voting process for the new block is entered.

[0101] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the consensus method of the above-mentioned blockchain, and will not be repeated here.

[0102] In several embodiments provided in this application, the disclosed devices and methods may also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of the devices, methods, and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram may represent a module, a program segment, or a portion of code, and the module, program segment, or a portion of code contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions marked in the boxes may also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes may actually be executed substantially in parallel, or they may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, may be implemented using a dedicated hardware-based system that performs the specified functions or actions, or may be implemented using a combination of dedicated hardware and computer instructions.

[0103] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0104] If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A consensus method for blockchain, characterized in that: include: When a blockchain forks at the first block height, one forked block is selected as the parent block based on the random number of each forked block, and the remaining forked blocks are selected as uncle blocks. Generate a new block at a second block height based on the uncle block information, wherein the new block includes a random number field and an uncle block reference field; Broadcasting the new block in the blockchain network so that consensus nodes in the blockchain network can verify the correctness of the new block after receiving it. If the verification is successful, the consensus voting process for the new block begins; Generating a new block at a second block height according to the information of the uncle block includes: Obtaining a parameter value of the uncle block reference field according to the number of uncle blocks and the hash value of each uncle block; Generate a random number to assign the random number field, and add the generated random number and the parameter value to a new block at the second block height; Verifying the correctness of the new block includes: Verify whether the uncle block information included in the new block is the same as the uncle block information of the local blockchain of the consensus node.

2. The method according to claim 1, wherein: Before selecting, when a blockchain forks at the first block height, one forked block as a parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block, the method further includes: If there are at least two blocks at the first block height whose number of votes exceeds two-thirds of the total number of nodes, the at least two blocks are stored on the chain at the same time to obtain at least two forked blocks.

3. The method according to claim 1, characterized in that The process of selecting a forked block as the parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block includes: According to the random number of each forked block, the forked block with the smallest random number is selected as the parent block, and the remaining forked blocks are selected as the uncle blocks.

4. The method according to claim 1, wherein: Verifying the correctness of the new block further includes: Verify the correctness of the parent block pointed to by the new block and the correctness of the transaction data contained in the new block.

5. The method according to claim 4, wherein: Verifying the correctness of the parent block pointed to by the new block and verifying the correctness of the transaction data contained in the new block includes: Verify that the hash value contained in the block header of the new block is the same as the hash value of the parent block; Verify whether the root hash value included in the block header of the new block is the same as the Merkle tree root value of the transaction information included in the block body of the new block.

6. The method according to claim 1, wherein: If the verification passes, the consensus voting process for the new block will begin, including: If the verification is successful, the consensus node broadcasts the voting information for the new block in the blockchain network; If the number of votes for the new block exceeds two-thirds of the total number of nodes, the new block will be stored on the chain.

7. The method according to claim 1, wherein: The method further comprises: If the verification fails, the consensus node initiates a view change request to elect a new block producer.

8. A consensus device for blockchain, characterized in that: include: The block selection module is used to select a forked block as the parent block and the remaining forked blocks as uncle blocks based on the random number of each forked block when the blockchain forks at the first block height; A new block generation module is configured to generate a new block of a second block height based on the uncle block information, wherein the new block includes a random number field and an uncle block reference field; generating the new block of the second block height based on the uncle block information includes: obtaining a parameter value of the uncle block reference field based on the number of uncle blocks and the hash value of each uncle block; generating a random number to assign to the random number field, and adding the generated random number and the parameter value to a packaged new block of the second block height; The block consensus module is used to broadcast the new block in the blockchain network, so that after receiving the new block, the consensus nodes in the blockchain network verify the correctness of the new block. If the verification is successful, the consensus voting process for the new block begins. The verification of the correctness of the new block includes: verifying whether the information of the uncle block contained in the new block is the same as the information of the uncle block in the local blockchain of the consensus node.

9. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing processor-executable instructions; The processor is configured to execute the blockchain consensus method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The storage medium stores a computer program, which can be executed by a processor to complete the blockchain consensus method described in any one of claims 1 to 7.

Images