Block synchronization method and blockchain nodes in blockchain system

Abstract

A block synchronization method and blockchain node in a blockchain system, wherein the blockchain system includes N blockchain nodes, and the method performed by any blockchain node among the N blockchain nodes includes: receiving multiple block states from the remaining N-1 blockchain nodes, wherein a single block state includes a first block height of a first-type block and a second block height of a second-type block most recently obtained by its corresponding blockchain node, wherein the first-type block includes multiple transactions arranged in sequence as indicated by a consensus proposal reached on consensus, and the second-type block is obtained based on the first-type block with the same block height, and the second-type block includes a block header, a block body, and a block proof; determining a number of first-type blocks and a number of second-type blocks to be synchronized based on the maximum number of malicious nodes allowed in the blockchain system, each first block height, and each second block height; and synchronizing the number of first-type blocks and the number of second-type blocks from the N-1 blockchain nodes.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain, and more particularly to a block synchronization method and blockchain node in a blockchain system. Background Art

[0002] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application. Summary of the Invention

[0003] The object of the present invention is to provide a block synchronization method and a blockchain node in a blockchain system.

[0004] In a first aspect, a block synchronization method in a blockchain system is provided, wherein the blockchain system includes N blockchain nodes, and the method is performed by any one of the N blockchain nodes. The method comprises: receiving multiple block states from the remaining N-1 blockchain nodes, wherein each block state includes a first block height of a first-type block and a second block height of a second-type block most recently obtained by its corresponding blockchain node, wherein the first-type block includes a plurality of transactions arranged in sequence as indicated by a consensus proposal, and the second-type block is obtained based on a first-type block having the same block height as the first-type block, wherein the second-type block includes a block header, a block body, and a block proof; determining a number of first-type blocks and a number of second-type blocks to be synchronized based on the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights, and each of the second block heights; synchronizing the number of first-type blocks from the N-1 blockchain nodes, and synchronizing the number of second-type blocks from the N-1 blockchain nodes.

[0005] In a first aspect, a blockchain node in a blockchain system is provided, wherein the blockchain system includes N blockchain nodes, and the blockchain node includes: a state acquisition unit, configured to receive multiple block states from the remaining N-1 blockchain nodes, wherein a single block state includes a first block height of a first type of block and a second block height of a second type of block most recently obtained by its corresponding blockchain node, wherein the first type of block includes a plurality of transactions arranged in sequence as indicated by a consensus proposal that has reached consensus, and the second type of block is obtained based on the first type of block with the same block height as the first type of block, and the second type of block includes a block header, a block body, and a block proof; a block determination unit, configured to determine a number of first type blocks and a number of second type blocks to be synchronized based on the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights, and each of the second block heights; a synchronization processing unit, configured to synchronize the number of first type blocks from the N-1 blockchain nodes, and synchronize the number of second type blocks from the N-1 blockchain nodes.

[0006] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computing device, the computing device is caused to execute the method described in the first aspect.

[0007] In the embodiments of this specification, for any blockchain node in a blockchain system comprising N blockchain nodes that needs to synchronize blocks from other blockchain nodes, the blockchain node can receive multiple block states from the remaining N-1 blockchain nodes. Each block state includes the first block height of the Raw Block and the second block height of the Stable Block most recently obtained by its corresponding blockchain node. Then, based on the maximum number of malicious nodes allowed in the blockchain system, the respective first block heights, and the respective second block heights, the node determines the number of Raw Blocks and Stable Blocks to be synchronized, and synchronizes these Raw Blocks and Stable Blocks from the remaining N-1 blockchain nodes. In this way, by synchronizing all of its own Raw Blocks and Stable Blocks, which have lagged behind those of the remaining blockchain nodes, the blockchain node catches up with the normal progress of the entire blockchain system, thereby being able to normally participate in reaching consensus on consensus proposals as a consensus node. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0009] Figure 1 This is an architecture diagram of a blockchain system provided in the embodiments of this specification;

[0010] Figure 2 This is a schematic diagram of the process of using an asynchronous pipeline mechanism to process block data in a blockchain system;

[0011] Figure 3 This is a flowchart of a block synchronization method in a blockchain system provided in an embodiment of this specification;

[0012] Figure 4 This is one of the schematic diagrams of the synchronized Raw Block provided exemplarily in the embodiments of this specification;

[0013] Figure 5 This is the second schematic diagram of the synchronous Raw Block provided as an example in the embodiments of this specification;

[0014] Figure 6 This is one of the schematic diagrams of synchronizing Stable Blocks provided as an example in the embodiments of this specification;

[0015] Figure 7 This is the second schematic diagram of the synchronization of Stable Blocks provided as an example in the embodiments of this specification;

[0016] Figure 8 This is a schematic diagram of the structure of a blockchain node in a blockchain system provided in an embodiment of this specification. DETAILED DESCRIPTION

[0017] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0018] Figure 1 This is an architectural diagram of a blockchain system provided as an example in the embodiments of this specification. The blockchain system may include N blockchain nodes, where Figure 18 blockchain nodes, Node 1 through Node 8, are shown as examples. The lines between the nodes schematically represent P2P (Peer to Peer) connections, which can be, for example, Transmission Control Protocol (TCP) connections, used to support data transmission between different nodes.

[0019] The consensus mechanism in a blockchain system is a mechanism by which blockchain nodes reach a consensus across the entire network on block information (or block data), ensuring that the most recently acquired block is accurately stored. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT). Consensus on the data is typically determined after a predetermined number of consensus nodes agree on the data being agreed upon. For example, in the PBFT algorithm, for n ≥ 3f + 1 consensus nodes, a maximum of f malicious nodes are allowed. This means that consensus is considered successful when 2f + 1 consensus nodes out of N blockchain nodes agree, and n may be less than N.

[0020] In blockchain systems, asynchronous pipeline mechanisms can be used to process block data. Figure 2As shown, a single blockchain node may include independent consensus services and several other services. The consensus service can be responsible for reaching consensus on a consensus proposal with the remaining consensus nodes in the N blockchain nodes. When nf consensus nodes reach consensus on a consensus proposal, it obtains the first-type block (i.e., Raw Block) corresponding to the consensus proposal and adds the obtained Raw Block to the end of the Raw Block queue. A Raw Block includes a transaction set, which includes multiple transactions indicated by the consensus proposal in a sequential order. The Raw Block may also include its corresponding block height (or block number) and timestamp. Other services can sequentially extract Raw Blocks from the head of the Raw Block queue and generate a second-type block (i.e., Stable Block) with the same block height based on the Raw Block extracted from the Raw Block queue. It should be noted that Stable Blocks are generally irreversible blocks in a blockchain system. Stable Blocks can include a block header, a block body, and a block proof. The block body of a Stable Block includes the transaction set in the corresponding Raw Block, and may also include a receipt set corresponding to the transaction set. The block header of a Stable Block may include the block height, timestamp, transaction root hash Transaction_Root, receipt root hash Receipt_Root, and state root hash State_Root, etc. The block proof of a Stable Block is generated based on the signatures of at least nf consensus nodes on the block header and block body in the Stable Block. For example, it can be a signature list consisting of the signatures of nf consensus nodes on the hash values ​​of the block header and block body in the Stable Block, or it can be the result of compressing the signature list. It should be noted that the most recently obtained Raw Block and Stable Block in the blockchain system may have different block heights. For example, the block height of the most recently obtained Stable Block in the blockchain node may be h, while the block height of the most recently obtained Raw Block through the consensus service may be h+a, which is greater than h.

[0021] It may be difficult for blockchain nodes to guarantee that they can always correctly and effectively complete the entire Raw Block and Stable Block processing process. For example, a blockchain node may experience slowdowns due to software updates, abnormal downtime, insufficient computing resources, or storage resources, causing the block height of the Raw Block and Stable Block it obtains to lag behind other nodes.

[0022] In related technologies, a blockchain node can synchronize its lagging Stable Block from the remaining N-1 blockchain nodes. However, as mentioned above, the block heights of the most recently acquired Raw Block and Stable Block in a blockchain system may differ. In other words, the block height of the most recently acquired Raw Block in a blockchain system may be ahead of the block height of the Stable Block. If a blockchain node only synchronizes its lagging Stable Block from the remaining blockchain nodes in the blockchain system, it may be unable to participate in the processing of the corresponding Raw Block, which means that it may not be able to properly participate in consensus proposals as a consensus node.

[0023] The embodiments of this specification provide a block synchronization method and blockchain node in a blockchain system. For any blockchain node in a blockchain system comprising N blockchain nodes that needs to synchronize blocks from other blockchain nodes, the blockchain node can receive multiple block states from the remaining N-1 blockchain nodes. Each block state includes the first block height of the Raw Block and the second block height of the Stable Block most recently obtained by its corresponding blockchain node. The node then determines the number of Raw Blocks and Stable Blocks to be synchronized based on the maximum number of malicious nodes allowed in the blockchain system, the first block heights, and the second block heights. The node then synchronizes these Raw Blocks and Stable Blocks from the remaining N-1 blockchain nodes. In this way, the node synchronizes all of its own Raw Blocks and Stable Blocks that lag behind the remaining nodes, allowing it to catch up with the processing progress of the blockchain system and to participate in consensus on consensus proposals as a consensus node.

[0024] Figure 3 This is a flowchart of a block synchronization method in a blockchain system provided in an embodiment of this specification. The blockchain system may include N blockchain nodes, wherein the N blockchain nodes may include n consensus nodes, and the maximum number of malicious nodes allowed in the blockchain system is f. The method can be executed by any blockchain node in the N blockchain nodes, see Figure 3 As shown, the method may include part or all of the following steps S31 to S35.

[0025] In step S31, multiple block states are received from the remaining N-1 blockchain nodes, and a single block state includes the first block height of the Raw Block and the second block height of the Stable Block most recently obtained by its corresponding blockchain node.

[0026] The following will mainly focus on executing Figure 3 The blockchain node in each method step shown in the figure is node 1 among N blockchain nodes. For example, the process of node 1 synchronizing blocks from node 2 to node N and other N-1 blockchain nodes is described in detail.

[0027] Blockchain nodes acting as consensus nodes in a blockchain system can broadcast block states. For example, node 2, acting as a consensus node among N blockchain nodes, can broadcast its block state m2. Block state m2 may include the block height (raw_block_number) of node 2's most recently acquired Raw Block and the block height (stable_block_number) of node 2's most recently acquired Stable Block. Accordingly, each node in the blockchain system may receive multiple block states broadcast by consensus nodes. For example, node 1 may receive multiple block states broadcast by some or all of the n consensus nodes from the remaining N-1 blockchain nodes, obtaining multiple raw_block_numbers and multiple stable_block_numbers.

[0028] In step S33, a number of Raw Blocks and a number of Stable Blocks to be synchronized are determined based on the maximum number of malicious nodes allowed in the blockchain system, each first block height, and each second block height.

[0029] Node 1 can sort the multiple raw_block_numbers it obtains from largest to smallest, and determine the number of raw_blocks to be synchronized based on the height of the first block with sequence number k. The largest f raw_block_numberk may come from malicious nodes, so the value of k can be greater than the maximum number of malicious nodes f allowed in the blockchain system. The raw_block_number with sequence number k will be the actual block height of the most recently obtained RawBlock in the blockchain system. For example, if the block height of the most recently obtained raw_block of node 1 is n0, and the value of the raw_block_number with sequence number k is nr, then the r raw_blocks corresponding to the height interval [n1, nr] are the number of raw_blocks to be synchronized.

[0030] Node 1 can determine whether there are at least nf raw_block_numbers that are identical among the multiple raw_block_numbers it obtains. If so, it determines the number of raw_blocks to be synchronized based on the identical raw_block_numbers. For example, if the block height of the raw_block most recently obtained by node 1 is n0, and the value of at least nf identical raw_block_numbers is nr, then the r raw blocks corresponding to the height interval [n1, nr] are the number of raw blocks to be synchronized.

[0031] Similar to the process of determining the number of Raw Blocks to be synchronized, node 1 can determine the s Stable Blocks corresponding to the height interval [m1, ms] as the number of Stable Blocks to be synchronized, which will not be repeated here.

[0032] Step S35: synchronize the Raw Blocks from the remaining N-1 blockchain nodes, and synchronize the Stable Blocks from the remaining N-1 blockchain nodes.

[0033] Node 1 can complete synchronization of the RawBlocks from the remaining N-1 blockchain nodes in one or more execution rounds, and complete synchronization of the StableBlocks from the remaining N-1 blockchain nodes in one or more execution rounds. It is usually possible to limit the number of RawBlocks / StableBlocks allowed to be synchronized in a single execution round to avoid excessive resource usage in the same period.

[0034] The following combination Figure 4 and Figure 5 This example describes the execution process of any i-th execution round in the process of synchronizing the raw blocks from the remaining N-1 blockchain nodes through one or more execution rounds. Figure 4 As shown, the blockchain node can execute part or all of the following method steps S351 to S353 in the i-th execution round.

[0035] In step S351 , at least two third block heights are determined from height intervals corresponding to a plurality of Raw Blocks to be synchronized.

[0036] For example, in the first execution round, node 1 may determine three block heights, n1 to n3, from the height interval [n1, nr] corresponding to the plurality of Raw Blocks in descending order. In any i-th execution round greater than 1, node 1 may determine at least two third block heights from the height interval [n1, nr] corresponding to the plurality of Raw Blocks based on the execution results of the i-1-th execution round. Exemplarily, in the i-1th execution round, the Raw Blocks corresponding to three block heights, n4 to n6, are expected to be synchronized, wherein the Raw Block with a block height of n4 fails to be synchronized to node 1 within a limited time, or the Raw Block with a block height of n4 fails to be verified, then the at least two third block heights determined in the i-th execution round may include n4. For example, the at least two block heights determined from the height interval [n1, nr] in the i-th execution round may include n4, and may also include the block heights of one or more Raw Blocks that have not been successfully synchronized to node 1 among several Raw Blocks.

[0037] In step S352, for each third block height, synchronize its corresponding Raw Block from the first node among the remaining N-1 blockchain nodes, and obtain multiple verification data of the Raw Block from the remaining N-2 blockchain nodes except the first node.

[0038] For example, see Figure 5 As shown, the block heights determined in the first execution round include n1 to n3. For block height n1, node 1 receives N-1 raw_block_numbers from nodes 2 to N, and so on, all of which are no less than n1. Node 1 can determine that it has successfully obtained the Raw Block with block height n1 based on the raw_block_numbers from the remaining N-1 blockchain nodes. In this case, node 1 can, for example, choose to synchronize the Raw Block with block height n1 from node 2, and synchronize multiple verification data of the Raw Block with block height n1 from the remaining N-2 nodes, such as nodes 3 to N.

[0039] The verification data for a Raw Block may include the hash value of the Raw Block provided by the corresponding blockchain node, or the transaction root hashes corresponding to multiple transactions included in the Raw Block in a sequential order. For example, Node 3 may calculate the verification data for the Raw Block obtained at block height n1 and provide the calculated verification data to Node 1.

[0040] In step S353 , for at least two Raw Blocks corresponding to at least two third block heights, the at least two Raw Blocks are concurrently verified according to a plurality of verification data respectively corresponding to the at least two Raw Blocks.

[0041] In the case where the verification data includes a transaction root hash, for example, for a RawBlock with a block height of n1 from node 2, node 1 can calculate the transaction root hash H1 corresponding to multiple transactions included in the Raw Block in sequence. If the number of transaction root hashes identical to the transaction root hash H1 among the multiple verification data corresponding to the Raw Block from the remaining N-2 nodes is less than nf-1, then the Raw Block with a block height of n1 fails verification.

[0042] In the case where the verification data includes the hash value of the Raw Block, for example, for a Raw Block with a block height of n1 from node 2, node 1 can calculate the hash value H2 of the Raw Block. If the number of hash values ​​identical to the hash value H2 among the multiple verification data corresponding to the RawBlock from the remaining N-2 nodes is less than nf-1, the Raw Block with a block height of n1 fails verification.

[0043] After the Raw Block passes verification, Node 1 can install the synchronized Raw Block, i.e., persist the data.

[0044] The following combination Figure 6 and Figure 7 This example describes the execution process of any i-th execution round in the process of synchronizing the Stable Blocks from the remaining N-1 blockchain nodes through one or more execution rounds. Figure 6 As shown, the blockchain node can execute part or all of the following method steps S354 to S359 in any j-th execution round.

[0045] In step S354, at least two fourth block heights are determined from the height intervals corresponding to the several Stable Blocks to be synchronized.

[0046] For example, in the first execution round, node 1 can determine three block heights, such as m1 to m3, from the height intervals [m1, ms] corresponding to several Stable Blocks in ascending order. In any j-th execution round greater than 1, node 1 can determine at least two fourth block heights from the height intervals [m1, ms] corresponding to several Stable Blocks based on the execution results of the j-1-th execution round. For example, see Figure 7 In the first execution round, it is expected that the Stable Blocks corresponding to three block heights, such as block heights m1 to m3, will be synchronized from Node 2. If the Stable Block with block height m3 fails to be synchronized to Node 1 within a limited time, or the Stable Block with block height m3 fails to be verified, for example, its block header verification fails or the block proof verification fails, then the at least two fourth block heights determined in the second execution round include m3, and also include the block heights corresponding to one or more Stable Blocks in several Stable Blocks that are not currently synchronized to Node 1. It should be noted that if the role of a blockchain node may change between a consensus node and a non-consensus node during the operation of the blockchain system, then the at least two fourth block heights determined from the height interval [m1, ms] in the jth execution round should also be able to form a sub-interval belonging to the height interval [m1, ms]; for example, please continue to refer to Figure 7 , if the Stable Block with a block height of m3 in the first execution round fails to be synchronized to node 1 within the valid time or fails to pass verification, then the at least two fourth block heights determined in the second execution round can be, for example, a sub-interval [m3, m5] of the height interval [m1, ms].

[0047] In step S355, according to at least two fourth block heights, synchronize at least two Stable Blocks from several second nodes among the remaining N-1 blockchain nodes. Figure 7 As shown, the at least two Stable Blocks corresponding to the at least two fourth block heights can be synchronized from a single second node, or the at least two Stable Blocks can be synchronized from multiple second nodes.

[0048] In step S356, the block headers of the at least two Stable Blocks are verified concurrently.

[0049] Verification of the block header of the Stable Block may include information such as the transaction root hash and state root hash included in the block header of the Stable Block. This information can be verified through the transaction set and / or receipt set included in the block body of the Stable Block itself. Therefore, the block headers of at least two Stable Blocks can be verified in parallel, thereby improving verification efficiency. It should be noted that if the role of the blockchain node may change between consensus nodes and non-consensus nodes during the operation of the blockchain system, the number of thread pool queues used for concurrent verification of the block headers of at least two Stable Blocks must be no less than the number of at least two Stable Blocks, so as to avoid the situation where the thread pool queue of the Stable Block with a larger block height is filled, and the Stable Block with a smaller block height cannot verify the block header and subsequently cannot continue to verify the block proof of the Stable Block.

[0050] For Stable Blocks with verified block headers, the block proofs included in them can be verified. If the roles of blockchain nodes may change between consensus nodes and non-consensus nodes during the operation of the blockchain system, it is necessary to verify at least two Stable Blocks with verified block headers in ascending order of block height. For example, verification of the block proofs included in Stable Blocks with verified block headers can be completed through the following steps S357 and S358.

[0051] In step S357, a target block is determined from at least two Stable Blocks according to the heights of at least two fourth blocks.

[0052] In ascending order of block height, an unselected fourth block height can be selected from at least two fourth block heights, and the Stable Block corresponding to the selected fourth block height can be used as the target block. If the block header of the target block fails verification, the current execution round can be directly terminated and the execution process of the next execution round can be started. If the block header of the target block passes verification, the following step S358 can be continued.

[0053] In step S358, the public keys of the multiple consensus nodes corresponding to the target block are obtained, and the block proof in the target block is verified based on the public keys of the multiple consensus nodes.

[0054] For a Stable Block whose block header and block proof have both passed verification, Node 1 can execute multiple transactions included in the transaction set in the Stable Block, updating its own stored state data accordingly. Alternatively, Node 1 can, for example, update its own stored state data based on the receipt set included in the Stable Block. Furthermore, through its stored state data, it can detect changes in the roles of blockchain nodes between consensus nodes and non-consensus nodes, determine the multiple consensus nodes corresponding to the target block, and then obtain the public keys of each of these consensus nodes. These public keys are then used to verify the block proof in the target block. If the block proof in the target block fails to be verified, Node 1 can directly end the current execution round and begin the next execution round.

[0055] For the Stable Blocks that have been synchronized and verified from the remaining N-1 nodes, Node 1 can persistently store the Stable Blocks and, in ascending order of block height, execute the multiple transactions included in each of the Stable Blocks, thereby correspondingly updating the state data stored by Node 1. For the Raw Blocks that have been synchronized and verified from the remaining N-1 nodes, Node 1 can persistently store the Raw Blocks. Furthermore, assuming that the height interval corresponding to the Stable Blocks is [m1, ms] and the height interval corresponding to the Raw Blocks is [n1, nr], Node 1 also needs to process each Raw Block corresponding to the height interval [ms+1, nr] in sequence through other computing services in the Raw Blocks, thereby obtaining each Stable Block corresponding to the height interval [ms+1, nr].

[0056] Based on the same concept as the aforementioned method embodiment, this specification also provides a blockchain node in a blockchain system, wherein the blockchain system includes N blockchain nodes. Figure 8As shown, the blockchain node includes: a state acquisition unit 81, configured to receive multiple block states from the remaining N-1 blockchain nodes, a single block state including the first block height of the first type of block and the second block height of the second type of block most recently obtained by its corresponding blockchain node, the first type of block including a plurality of transactions arranged in sequence indicated by a consensus proposal for reaching consensus, the second type of block is obtained based on the first type of block with the same block height, the second type of block including a block header, a block body and a block proof; a block determination unit 83, configured to determine a number of first type blocks and a number of second type blocks to be synchronized based on the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights and each of the second block heights; a synchronization processing unit 85, configured to synchronize the several first type blocks from the N-1 blockchain nodes, and synchronize the several second type blocks from the N-1 blockchain nodes.

[0057] In one possible implementation, the synchronization processing unit 85 is specifically configured to determine at least two third block heights from the height intervals corresponding to the several first-type blocks; and, based on the at least two third block heights, synchronize at least two first-type blocks from the first node among the N-1 blockchain nodes; the synchronization processing unit 85 is also configured to obtain multiple verification data corresponding to the at least two first-type blocks from the remaining N-2 blockchain nodes other than the first node among the N-1 blockchain nodes; and concurrently verify the at least two first-type blocks based on the multiple verification data corresponding to the at least two first-type blocks.

[0058] In a possible implementation, the verification data corresponding to the first type of block includes a hash value of the first type of block and / or transaction roots corresponding to multiple transactions arranged in sequence in the first type of block.

[0059] In one possible implementation, the process of synchronizing the plurality of first-class blocks from the N-1 blockchain nodes includes multiple execution rounds; the at least two third block heights determined in any i-th execution round include the block height corresponding to the first-class block synchronized in the i-1-th execution round and not passed verification.

[0060] In one possible implementation, the synchronization processing unit 85 is specifically configured to determine at least two fourth block heights from the height intervals corresponding to the plurality of second-type blocks; and, based on the at least two fourth block heights, synchronize at least two second-type blocks from the plurality of second nodes among the N-1 blockchain nodes; the synchronization processing unit 85 is further configured to concurrently verify the block headers of the at least two second-type blocks; and, verify the block proof included in the second-type blocks whose block headers have passed the verification.

[0061] In one possible implementation, the at least two fourth block heights are the block heights included in the sub-interval of the height interval corresponding to the plurality of second-type blocks; the block proof in the second-type block is obtained based on the signatures of the block header and block body in the second-type block by the plurality of consensus nodes corresponding to the second-type block; the synchronization processing unit 85 is specifically configured to determine the target block from the at least two second-type blocks based on the size of the at least two fourth block heights; obtain the public keys of the plurality of consensus nodes corresponding to the target block when the block header of the target block has passed verification; and verify the block proof in the target block based on the public keys of the plurality of consensus nodes.

[0062] In one possible implementation, the process of synchronizing the plurality of second-type blocks from the N-1 blockchain nodes includes multiple execution rounds; the at least two fourth block heights determined in any j-th execution round include the block height corresponding to the second-type block synchronized in the j-1-th execution round and whose block header or block proof fails verification.

[0063] In one possible implementation, the block determination unit 83 is specifically configured to sort the first block heights in descending order, and determine a number of first-category blocks to be synchronized based on the first block height with an arrangement number k; and / or sort the second block heights in descending order, and determine a number of second-category blocks to be synchronized based on the second block height with an arrangement number k; wherein the value of k is greater than the maximum number of malicious nodes allowed in the blockchain system.

[0064] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method performed by the blockchain node in the aforementioned method embodiment.

[0065] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0066] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0067] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0068] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0069] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0070] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0071] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0072] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0073] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0074] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0075] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0076] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0078] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, the description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, unless they conflict with each other.

[0079] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A method for synchronizing blocks in a blockchain system, wherein the blockchain system includes N blockchain nodes, the method being executed by any one of the N blockchain nodes, the method comprising: Receive multiple block states from the remaining N-1 blockchain nodes, where each block state includes a first block height of a first-type block and a second block height of a second-type block most recently obtained by its corresponding blockchain node, the first-type block including a plurality of transactions arranged in sequence as indicated by a consensus proposal that has reached consensus, the second-type block being obtained based on the first-type block having the same block height, and the second-type block including a block header, a block body, and a block proof; Determining a number of first-category blocks and a number of second-category blocks to be synchronized based on a maximum number of malicious nodes allowed in the blockchain system, each of the first block heights, and each of the second block heights; Synchronizing the plurality of first-type blocks from the N-1 blockchain nodes, and synchronizing the plurality of second-type blocks from the N-1 blockchain nodes; The method of determining a number of first-category blocks and a number of second-category blocks to be synchronized based on the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights, and each of the second block heights specifically includes: sorting the first block heights in descending order, and determining the number of first-category blocks to be synchronized based on the first block height with an arrangement number k; and / or sorting the second block heights in descending order, and determining the number of second-category blocks to be synchronized based on the second block height with an arrangement number k; wherein the value of k is greater than the maximum number of malicious nodes allowed in the blockchain system.

2. According to the method of claim 1, synchronizing the plurality of first-type blocks from the N-1 blockchain nodes comprises: Determining at least two third block heights from the height intervals corresponding to the plurality of first-type blocks; Synchronize at least two first-type blocks from a first node among the N-1 blockchain nodes according to the at least two third block heights; The method further includes: obtaining multiple verification data corresponding to the at least two first-type blocks from the remaining N-2 blockchain nodes other than the first node among the N-1 blockchain nodes; and concurrently verifying the at least two first-type blocks based on the multiple verification data corresponding to the at least two first-type blocks.

3. The method according to claim 2, wherein the verification data corresponding to the first type of block includes a hash value of the first type of block and / or a transaction root hash corresponding to multiple exchanges arranged in sequence in the first type of block.

4. The method of claim 2, wherein synchronizing the plurality of first-type blocks from the N-1 blockchain nodes comprises multiple execution rounds; and wherein the at least two third block heights determined in any i-th execution round include the block height corresponding to the first-type block synchronized in the i-1-th execution round and not passed verification.

5. According to the method of claim 1, synchronizing the plurality of second-type blocks from the N-1 blockchain nodes comprises: Determining at least two fourth block heights from the height intervals corresponding to the plurality of second-type blocks; Synchronize at least two second-type blocks from a plurality of second nodes among the N-1 blockchain nodes according to the at least two fourth block heights; The method further includes: concurrently verifying the block headers of the at least two second-type blocks; and verifying the block proof included in the second-type blocks whose block headers have passed the verification.

6. The method according to claim 5, wherein the at least two fourth block heights are block heights included in a subrange of the height range corresponding to the plurality of second-type blocks; and the block proof of the second-type block is obtained based on signatures of the block header and block body of the second-type block by multiple consensus nodes corresponding to the second-type block. in, The verifying the block proof included in the second-type block whose block header has passed the verification specifically includes: determining a target block from the at least two second-type blocks according to the size of the at least two fourth block heights; when the block header of the target block has passed the verification, obtaining the public keys of multiple consensus nodes corresponding to the target block; and verifying the block proof in the target block according to the public keys of the multiple consensus nodes.

7. The method of claim 5, wherein synchronizing the plurality of second-type blocks from the N-1 blockchain nodes comprises a plurality of execution rounds; and wherein the at least two fourth block heights determined in any j-th execution round include block heights corresponding to second-type blocks synchronized in the j-1-th execution round and whose block headers or block proofs fail verification.

8. A blockchain node in a blockchain system, wherein the blockchain system includes N blockchain nodes, each of which includes: a state acquisition unit configured to receive multiple block states from the remaining N-1 blockchain nodes, wherein each block state includes a first block height of a first-type block and a second block height of a second-type block most recently obtained by its corresponding blockchain node, wherein the first-type block includes a plurality of transactions arranged in sequence as indicated by a consensus proposal that has reached consensus, and the second-type block is obtained based on the first-type block having the same block height as the first-type block, and includes a block header, a block body, and a block proof; a block determination unit configured to determine a number of first-category blocks and a number of second-category blocks to be synchronized based on a maximum number of malicious nodes allowed in the blockchain system, each of the first block heights, and each of the second block heights; a synchronization processing unit configured to synchronize the plurality of first-type blocks from the N-1 blockchain nodes, and synchronize the plurality of second-type blocks from the N-1 blockchain nodes; The block determination unit is specifically configured to sort the first block heights in descending order, and determine a number of first-type blocks to be synchronized based on the first block height with an arrangement number k; and / or sort the second block heights in descending order, and determine a number of second-type blocks to be synchronized based on the second block height with an arrangement number k; wherein the value of k is greater than the maximum number of malicious nodes allowed in the blockchain system.

9. The blockchain node according to claim 8, wherein the synchronization processing unit is specifically configured to determine at least two third block heights from the height intervals corresponding to the plurality of first-type blocks; and synchronize at least two first-type blocks from a first node among the N-1 blockchain nodes based on the at least two third block heights; The synchronization processing unit is further configured to obtain multiple verification data corresponding to the at least two first-type blocks from the remaining N-2 blockchain nodes other than the first node among the N-1 blockchain nodes; and concurrently verify the at least two first-type blocks based on the multiple verification data corresponding to the at least two first-type blocks.

10. The blockchain node according to claim 9, wherein the verification data corresponding to the first type of block includes a hash value of the first type of block and / or transaction roots corresponding to multiple exchanges arranged in sequence in the first type of block.

11. According to the blockchain node of claim 9, the process of synchronizing the plurality of first-type blocks from the N-1 blockchain nodes includes multiple execution rounds; and the at least two third block heights determined in any i-th execution round include the block height corresponding to the first-type block synchronized in the i-1-th execution round and not passed the verification.

12. The blockchain node according to claim 8, wherein the synchronization processing unit is specifically configured to determine at least two fourth block heights from the height intervals corresponding to the plurality of second-type blocks; and synchronize at least two second-type blocks from the plurality of second nodes among the N-1 blockchain nodes based on the at least two fourth block heights; The synchronization processing unit is further configured to concurrently verify the block headers of the at least two second-type blocks; and verify the block proof included in the second-type blocks whose block headers have passed the verification.

13. The blockchain node according to claim 12, wherein the at least two fourth block heights are block heights included in a subrange of the height range corresponding to the plurality of second-type blocks; and the block proofs for the second-type blocks are obtained based on signatures of the block header and block body of the second-type blocks by the plurality of consensus nodes corresponding to the second-type blocks. The synchronization processing unit is specifically configured to determine a target block from the at least two second-type blocks based on the sizes of the at least two fourth block heights; obtain public keys of multiple consensus nodes corresponding to the target block when the block header of the target block has passed verification; and verify the block proof in the target block based on the public keys of the multiple consensus nodes.

14. The blockchain node according to claim 12, wherein: The process of synchronizing the plurality of second-type blocks from the N-1 blockchain nodes includes multiple execution rounds; the at least two fourth block heights determined in any j-th execution round include the block height corresponding to the second-type block synchronized in the j-1-th execution round and whose block header or block proof failed verification.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computing device, causes the computing device to execute the method according to any one of claims 1 to 7.

Images