CN115987528A - Block synchronization method and block link point in block link system - Google Patents

Abstract

A block synchronization method and a block link node in a block chain system, wherein the block chain system comprises N block chain nodes, and the method executed by any one of the N block chain nodes comprises the following steps: receiving a plurality of block states from the remaining N-1 block link points, wherein each block state comprises a first block height of a first type block and a second block height of a second type block, the first type block comprises a plurality of transactions which are arranged in sequence and indicated by consensus proposals achieving consensus, the second type block is obtained based on the first type block with the same block height, and the second type block comprises a block head, a block body and a block certificate; determining a plurality of first type blocks and a plurality of second type blocks to be synchronized according to the maximum allowable malicious node number in the block chain system, the heights of all the first blocks and all the second blocks; the first type blocks and the second type blocks are synchronized from N-1 block chain nodes.

Description

Block synchronization method and block chain nodes in block chain system

technical field

The embodiments of this specification belong to the field of blockchain, and in particular relate to a block synchronization method and blockchain nodes in a blockchain system.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application.

Contents of the invention

The object of the present invention is to provide a block synchronization method and block chain nodes in a block chain system.

In the first aspect, a block synchronization method in a block chain system is provided, the block chain system includes N block chain nodes, and the method is performed by any one of the N block chain nodes Blockchain nodes execute. The method includes: receiving a plurality of block states from the remaining N-1 block chain nodes, and a single block state includes the first block of the first type of block newly obtained by its corresponding block chain node Height and the height of the second block of the second type of block, the first type of block includes a plurality of transactions in order indicated by the consensus proposal to reach a consensus, and the second type of block is based on having the same zone with it The block height of the first type of block is obtained, and the second type of block includes block header, block body and block proof; according to the maximum number of malicious nodes allowed in the block chain system, each of the first block The block height and each of the second block heights determine a number of first-type blocks and a number of second-type blocks to be synchronized; synchronize the number of first-type blocks from the N-1 blockchain nodes , and synchronizing the plurality of blocks of the second type from the N-1 blockchain nodes.

In a first aspect, a blockchain node in a blockchain system is provided, the blockchain system includes N blockchain nodes, and the blockchain node includes: a state acquisition unit configured to Multiple block states are received from the remaining N-1 blockchain nodes, and a single block state includes the first block height and the second type of the first type of block newly obtained by its corresponding blockchain node The second block height of the block, the first type of block includes a plurality of transactions in sequence indicated by the consensus proposal, and the second type of block is based on the first block with the same block height The block of the second type is obtained, and the block of the second type includes a block header, a block body and a block certificate; the block determination unit is configured to, according to the maximum number of malicious nodes allowed in the block chain system, each of the second block A block height and each of the second block heights determine a number of first-type blocks and a number of second-type blocks to be synchronized; a synchronization processing unit configured to synchronize from the N-1 block chain nodes The plurality of blocks of the first type, and the plurality of blocks of the second type are synchronized from the N-1 blockchain nodes.

In a third aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed in a computing device, it causes the computing device to execute the method described in the first aspect.

In the solution of the embodiment of this specification, for any blockchain node that needs to synchronize blocks from other blockchain nodes in the blockchain system that contains N blockchain nodes, the blockchain node can synchronize blocks from the remaining N- A block chain node receives multiple block states, and a single block state includes the first block height of the Raw Block and the second block height of the Stable Block newly obtained by its corresponding block chain node; The maximum number of malicious nodes allowed in the blockchain system, the height of each first block and the height of each second block, determine the number of Raw Blocks and several Stable Blocks to be synchronized, and synchronize from the remaining N-1 blockchain nodes The several Raw Blocks and the several Stable Blocks. In this way, the blockchain node can catch up with the normal progress of the entire blockchain system by synchronizing all RawBlocks and Stable Blocks that have lagged behind other blockchain nodes from other blockchain nodes, so that it can normally participate as a consensus node Consensus on consensus proposals.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. , for those skilled in the art, other drawings can also be obtained according to these drawings without paying creative labor.

FIG. 1 is an architecture diagram of a block chain system provided in the embodiment of this specification;

Figure 2 is a schematic diagram of the process of processing block data using an asynchronous pipeline mechanism in the blockchain system;

FIG. 3 is a flowchart of a block synchronization method in a block chain system provided in an embodiment of this specification;

Fig. 4 is one of the schematic diagrams of the synchronous Raw Block exemplarily provided in the embodiment of this specification;

Fig. 5 is the second schematic diagram of the synchronous Raw Block provided exemplarily in the embodiment of this specification;

Fig. 6 is one of the schematic diagrams of the synchronous Stable Block exemplarily provided in the embodiment of this specification;

Fig. 7 is the second schematic diagram of the synchronous Stable Block exemplarily provided in the embodiment of this specification;

FIG. 8 is a schematic structural diagram of a blockchain node in a blockchain system provided in an embodiment of this specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments in this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

Fig. 1 is an architecture diagram of a block chain system exemplarily provided in the embodiment of this specification. The blockchain system may include N blockchain nodes, where 8 blockchain nodes such as node 1 to node 8 are exemplarily shown in FIG. 1 . The connection between nodes schematically represents a P2P (Peer to Peer, point-to-point) connection. The foregoing connection may be, for example, a transmission control protocol (transmission control trotocol, TCP) connection, and the foregoing connection is used to support data transmission between different nodes.

The consensus mechanism in the blockchain system is a mechanism for blockchain nodes to reach the same consensus on the block information (or block data) in the entire network, which can ensure that the latest acquired blocks are accurately stored. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm etc. Among them, in various consensus algorithms, usually after a preset number of consensus nodes agree on the data to be consensused, it is determined to reach a consensus on the data to be consensused. For example, in the PBFT algorithm, for n≥3f+1 consensus nodes, at most f malicious nodes are allowed to exist, that is to say, when 2f+1 consensus nodes among N blockchain nodes reach the same consensus, the consensus can be determined On success, n may be less than N.

In the blockchain system, an asynchronous pipeline mechanism can be used to process block data. As shown in Figure 2, a single blockchain node may include mutually independent consensus services and several other services. The consensus service can be responsible for consensus on the consensus proposal with the rest of the consensus nodes in the N block chain nodes. When n-f consensus nodes reach a consensus on the consensus proposal, the first type of block corresponding to the consensus proposal (ie Raw Block), and the obtained Raw Block is added to the tail of the Raw Block queue; the Raw Block includes a transaction set, which includes multiple transactions in order indicated by the corresponding consensus proposal. In addition, the Raw Block also includes It can include its corresponding block height (or called block number) and timestamp. Other services can sequentially extract Raw Blocks from the head of the Raw Block queue, and generate a second type of block (ie StableBlock) with the same block height based on the Raw Blocks extracted from the Raw Block queue. What needs to be explained is Stable Block It is usually a block that cannot be rolled back in the blockchain system; StableBlock can include block header, block body and block proof. The block body of the Stable Block includes the transaction set in the corresponding RawBlock, and can also include the receipt set corresponding to the transaction set; the block header of the Stable Block can include block height, timestamp Timestamp, transaction root hash Transaction_Root, The receipt root hash Receipt_Root and the state root hash State_Root, etc.; the block proof of the Stable Block is generated based on the signatures of at least n-f consensus nodes on the block header and block body in the Stable Block. The signature list formed by the signature of the hash value of the block header and block body in the block, or it can be the result of compressing the signature list. It should be noted that the newly obtained Raw Block and StableBlock in the blockchain system may have different block heights. For example, the block height of the newly obtained Stable Block in the blockchain node may be h, and the latest obtained through the consensus service The block height of Raw Block may indeed be h+a greater than h.

It may be difficult for blockchain nodes to ensure that they can always complete the processing of all Raw Blocks and StableBlocks correctly and effectively. For example, blockchain nodes may run slowly due to software program updates, abnormal downtime, insufficient computing resources or storage resources, resulting in the block height of the Raw Block and Stable Block it obtains lagging behind other nodes.

In related technologies, the blockchain node can synchronize the Stable Block of the blockchain node behind the rest of the blockchain nodes from the remaining N-1 blockchain nodes. However, referring to the above, it can be seen that the block heights of the latest Raw Block and Stable Block in the blockchain system may not be the same. In other words, the block height of the latest Raw Block in the blockchain system may be ahead of the Stable Block block height, if a blockchain node only synchronizes its backward Stable Block from other blockchain nodes in the blockchain system, it may cause the blockchain node to be unable to participate in the processing process corresponding to the Raw Block , which may cause the blockchain node to fail to participate in the consensus proposal as a consensus node.

Embodiments of this specification provide a block synchronization method and block chain nodes in a block chain system. For any blockchain node in a blockchain system containing N blockchain nodes that needs to synchronize blocks from other blockchain nodes, the blockchain node can receive multiple Block status, a single block status includes the first block height of Raw Block and the second block height of Stable Block newly obtained by its corresponding blockchain node; then according to the maximum malicious node allowed in the blockchain system Quantity, each first block height and each second block height, determine several Raw Blocks and several Stable Blocks to be synchronized, and synchronize the several Raw Blocks and the several Stable Blocks from the remaining N-1 blockchain nodes . In this way, the blockchain node will synchronize all Raw Blocks and Stable Blocks that are behind other blockchain nodes from other blockchain nodes, so that the blockchain node can catch up with the processing progress of the blockchain system, so that The blockchain node can normally participate in the consensus proposal as a consensus node.

Fig. 3 is a flow chart of a block synchronization method in a blockchain system provided in an embodiment of this specification. The blockchain system may include N blockchain nodes, 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 among the N blockchain nodes. Referring to FIG. 3 , the method can include part or all of the following steps S31 to S35.

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 first block height of the Stable Block newly obtained by its corresponding blockchain node. Two block height.

In the following, the block chain node performing each method step as shown in Figure 3 is node 1 among the N block chain nodes as an example, and the remaining N-1 nodes from node 2 to node N are exemplarily described. The process of synchronizing blocks between blockchain nodes.

The blockchain node as a consensus node in the blockchain system can broadcast the block status. For example, node 2 as a consensus node among N blockchain nodes can broadcast its block status m2, which can include the block height raw_block_number of the latest Raw Block obtained by node 2, and the latest Stable Block block height stable_block_number. Correspondingly, 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, and obtain multiple raw_block_numbers and multiple stable_block_numbers.

In step S33, according to the maximum number of malicious nodes allowed in the blockchain system, each first block height and each second block height, determine several Raw Blocks and several Stable Blocks to be synchronized.

Node 1 can sort the multiple raw_block_numbers it has obtained in descending order, and determine several raw_blocks to be synchronized according to the height of the first block with the sequence number k. The f raw_block_numberk with the largest value 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, and the raw_block_number with the sequence number k will be the latest RawBlock currently obtained in the blockchain system The real block height of . Exemplarily, the block height of the latest raw_block obtained by node 1 itself is n0, and the value of raw_block_number with the 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 raw_block.

Node 1 may determine whether at least n-f raw_block_numbers are the same among the multiple raw_block_numbers it has obtained, and if so, determine several raw_blocks to be synchronized based on the same raw_block_number. Exemplarily, the block height of the latest raw_block obtained by node 1 itself is n0, and at least n-f identical raw_block_number values are nr, then the r raw blocks corresponding to the height interval [n1, nr] are the number of blocks to be synchronized Raw Block.

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

Step S35, synchronizing the several Raw Blocks from the remaining N-1 blockchain nodes, and synchronizing the several Stable Blocks from the remaining N-1 blockchain nodes.

Node 1 can complete the synchronization of several RawBlocks from the remaining N-1 blockchain nodes through 1 or more execution rounds, and complete the synchronization from the remaining N-1 blockchain nodes through 1 or more execution rounds The number of StableBlock. Usually, the number of Raw Blocks/Stable Blocks allowed to be synchronized in a single execution round can be limited to avoid excessive resource occupation in the same period of time.

The following is an exemplary description of the execution process of any i-th execution round in the process of synchronizing the several Raw Blocks from the remaining N-1 blockchain nodes through one or more execution rounds with reference to Figure 4 and Figure 5 . Referring to FIG. 4 , the blockchain node can execute part or all of the following method steps S351 to S353 in the i-th execution round.

In step S351, at least two third block heights are determined from height intervals corresponding to several Raw Blocks to be synchronized.

For example, in the first execution round, node 1 can determine the heights of three blocks, n1 to n3, from the height range [n1, nr] corresponding to several Raw Blocks in order of arrival. In any i-th execution round greater than 1, node 1 can determine at least two The height of the third block. Exemplarily, in the i-1th execution round, it is expected to synchronize the Raw Block corresponding to three block heights such as n4~n6, and the Raw Block with block height n4 cannot be processed within a limited time. Synchronized to node 1, or the verification of the Raw Block with a block height of n4 fails, then at least two third block heights determined in the i-th execution round can include n4, for example, in the i-th execution round, from the height At least two block heights determined in the interval [n1, nr] may include n4, and may also include block heights of one or more Raw Blocks that have not been successfully synchronized to node 1 among several Raw Blocks.

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

Exemplarily, please refer to Figure 5, the block height determined in the first execution round includes n1~n3, for block height n1, node 1 receives N-1 nodes from node 2 to node N N-1 raw_block_numbers are not less than n1, and node 1 can determine that it has successfully obtained a Raw Block with a block height of 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 a block height of n1 from node 2, and the other N-2 nodes from node 3 to node N to synchronize multiple verification data of the Raw Block with a block height of n1 .

The verification data of the Raw Block can include the hash value of the Raw Block provided by the corresponding blockchain node, or the transaction root hash corresponding to multiple transactions arranged in order included in the Raw Block. Exemplarily, node 3 can calculate the verification data of the Raw Block whose block height is n1, and provide the calculated verification data to node 1.

In step S353, for at least two Raw Blocks corresponding to at least two third block heights, concurrently verify the at least two Raw Blocks according to the plurality of verification data respectively corresponding to the at least two Raw Blocks.

In the case where the verification data includes transaction root hashes, for example, for a RawBlock with a block height of n1 from node 2, node 1 can calculate the transaction root hashes corresponding to multiple transactions arranged in order included in the Raw Block H1, among multiple verification data corresponding to the Raw Block from the remaining N-2 nodes, if the number of transaction root hashes that are the same as the transaction root hash H1 is less than n-f-1, the block height is n1 Raw Block verification failed.

In the case that the verification data includes the hash value of the Raw Block, for example, for the Raw Block with block height n1 from node 2, node 1 can calculate the hash value H2 of the Raw Block, and the hash value H2 from the remaining N-2 nodes Among multiple verification data corresponding to the RawBlock, if the number of the same hash value as the hash value H2 is less than n-f-1, the verification of the Raw Block with a block height of n1 fails.

After the Raw Block is verified, node 1 can install its synchronized Raw Block, which is persistent storage.

The following is an exemplary description of the execution process of any i-th execution round in the process of synchronizing the several Stable Blocks from the remaining N-1 blockchain nodes through one or more execution rounds in conjunction with Fig. 6 and Fig. 7 . Referring to Fig. 6, the blockchain node can execute part or all of the following method steps S354 to S359 in any j-th execution round.

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

For example, in the first execution round, node 1 can determine the heights of three blocks, m1 to m3, from the height range [m1, ms] corresponding to several Stable Blocks in ascending order. Node 1 can determine at least two height intervals [m1, ms] corresponding to several Stable Blocks according to the execution result of the j-1th execution round in any jth execution round greater than 1. Four block height. For example, see Figure 7. In the first execution round, it is expected that the slave node 2 will synchronize the Stable Blocks corresponding to the three block heights m1~m3, and the StableBlock with the block height m3 fails to Synchronized to node 1 within a certain period of time, or the Stable Block whose block height is m3 fails to verify, for example, its block header verification fails or block proof verification fails, then at least two fourth blocks determined in the second execution round The height includes m3, and also includes the block height corresponding to one or more StableBlocks that are not currently synchronized to node 1 among several Stable Blocks. What needs to be specially explained is that if the role of a certain blockchain node may change between the consensus node and the non-consensus node during the operation of the blockchain system, then in the jth execution round, the height interval [m1 , ms], at least two fourth block heights determined in it should also be able to form sub-intervals belonging to the height interval [m1, ms]; for example, please continue to refer to Figure 7, the block height in the first execution round is m3 If the Stable Block fails to be synchronized to node 1 within the effective time or fails to pass the verification, then at least two heights of the fourth block determined in the second execution round can be, for example, a subset of the height interval [m1, ms]. Interval [m3, m5].

In step S355, according to at least two fourth block heights, at least two Stable Blocks are synchronized from several second nodes in the remaining N-1 blockchain nodes. Referring to FIG. 7 , at least two Stable Blocks corresponding to the at least two fourth block heights may be synchronized from a single second node, or the at least two Stable Blocks may be synchronized from multiple second nodes.

In step S356, concurrently verify the block headers of the at least two Stable Blocks.

Verify the block header of the Stable Block, which can include information such as the transaction root hash and the state root hash included in the block header of the Stable Block. This part of information can be passed through the transaction set and / Or receipt collection for verification, so 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 blockchain nodes may change between consensus nodes and non-consensus nodes during the operation of the blockchain system, the thread pool used to concurrently verify the block headers of at least two Stable Blocks The number of queues needs to be not less than at least two Stable Blocks to avoid that after the Stable Block with a larger block height fills the thread pool queue, the Stable Block with a smaller block height cannot verify the block header and cannot continue to verify the Stable Block. block proof.

The Stable Block whose block header has been verified can then verify the block proof it includes. Among them, if the blockchain system is running, the roles of blockchain nodes may change between consensus nodes and non-consensus nodes, and it is necessary to verify at least two of the block headers that have passed the verification in the order of block height from small to large. A StableBlock. For example, through the following steps S357 and S358, the verification of the block certificate included in the Stable Block whose block header is verified is completed.

In step S357, the target block is determined from at least two Stable Blocks according to the size of at least two fourth block heights.

According to the order of block heights from small to large, the 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 target block. If the block header of the target block fails the verification, the current execution round can be ended directly and the execution process of the next execution round can be started. If the block header of the target block has passed the verification, the following step S358 may be performed.

In step S358, obtain the respective public keys of multiple consensus nodes corresponding to the target block, and verify the block certificate in the target block according to the respective public keys of the multiple consensus nodes.

For a Stable Block whose block header and block certificate have passed verification, Node 1 can execute multiple transactions included in the transaction set in the Stable Block, and update its own stored state data accordingly; or Node 1 can, for example, according to the Stable Block The receipt collection included in corresponds to updating its own stored state data. Furthermore, through the stored state data, it is possible to discover the change of the role of the blockchain node between the consensus node and the non-consensus node, determine the multiple consensus nodes corresponding to the target block, and then obtain the respective consensus nodes of the multiple consensus nodes. public key, and use the respective public keys of the multiple consensus nodes to verify the block proof in the target block. If the block proof verification in the target block fails, node 1 can directly end the current execution round and start the execution process of the next execution round.

For several Stable Blocks that are synchronized from the remaining N-1 nodes and passed the verification, node 1 can persistently store several Stable Blocks, and execute each of the several Stable Blocks sequentially in order of block height from small to large. The multiple transactions included correspond to update the status data stored by node 1. For several Raw Blocks that are synchronized from the remaining N-1 nodes and passed the verification, node 1 can persistently store several Raw Blocks; in addition, continue to assume that the height intervals corresponding to several Stable Blocks are [m1, ms], several Raw Blocks The height range corresponding to the block is [n1, nr], then node 1 needs to sequentially process each Raw Block corresponding to the height range [ms+1, nr] through other computing services among several Raw Blocks, and then obtain Each Stable Block corresponding to the height interval [ms+1, nr].

Based on the same concept as the foregoing method embodiments, the embodiments of this specification also provide a blockchain node in a blockchain system, and the blockchain system includes N blockchain nodes. As shown in FIG. 8 , the blockchain node includes: a state acquisition unit 81 configured to receive a plurality of block states from the remaining N-1 blockchain nodes, and a single block state includes its corresponding block state The first block height of the first type of block and the second block height of the second type of block newly obtained by the block chain node, the first type of block includes the sequentially arranged A plurality of transactions, the second type of block is obtained based on the first type of block having the same block height, the second type of block includes block header, block body and block proof; block determination unit 83 , configured to determine several first-type blocks and several second class blocks; 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 class blocks.

In a possible implementation manner, 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, according to the at least Two third block heights, synchronizing at least two first-type blocks from the first node in the N-1 blockchain nodes; the synchronization processing unit 85 is also configured to start from the N-1 The remaining N-2 blockchain nodes except the first node among the blockchain nodes obtain multiple verification data corresponding to the at least two first-type blocks; according to the at least two A plurality of verification data respectively corresponding to the blocks of the first type concurrently verify the at least two blocks of the first type.

In a possible implementation manner, the verification data corresponding to the first type of block includes the hash value of the first type of block, and/or, the sequentially arranged The transaction root corresponding to multiple exchanges of .

In a possible implementation manner, the process of synchronizing the several first-type blocks from the N-1 blockchain nodes includes multiple execution rounds; at least The two third block heights include the block height corresponding to the block of the first type that is synchronized in the i-1th execution round and has not passed the verification.

In a possible implementation manner, the synchronization processing unit 85 is specifically configured to determine at least two fourth block heights from the height intervals corresponding to the several second-type blocks; and, according to the at least Two fourth block heights, synchronizing at least two second-type blocks from several second nodes in the N-1 blockchain nodes; the synchronization processing unit 85 is also configured to concurrently verify the at least The block headers of the two second-type blocks; and, verifying the block proofs included in the second-type blocks whose block headers have been verified.

In a possible implementation manner, the heights of the at least two fourth blocks are the heights of the blocks included in the sub-intervals of the height intervals corresponding to the several second-type blocks; the second The block certificate in the block of the second type is obtained based on the signatures of the block header and the body of the block in the block of the second type by multiple consensus nodes corresponding to the block of the second type; the synchronization processing unit 85, specifically It is configured to determine the target block from the at least two second-type blocks according to the size of the height of the at least two fourth blocks; when the block header of the target block has passed the verification, obtain the public keys of multiple consensus nodes corresponding to the target block; and verifying block certificates in the target block according to the public keys of the multiple consensus nodes.

In a possible implementation manner, the process of synchronizing the several second-type blocks from the N-1 blockchain nodes includes multiple execution rounds; at least The two fourth block heights include the block height corresponding to the second type of block that is synchronized in the j-1th execution round and whose block header or block proof has not passed the verification.

In a possible implementation manner, the block determination unit 83 is specifically configured to sort the heights of the first blocks in descending order, according to the height of the first block with the sequence number k Determine a number of blocks of the first type to be synchronized; and/or, sort the heights of each of the second blocks in descending order, and determine the number of blocks to be synchronized according to the height of the second block with the sequence number k The second type of block; wherein, the value of k is greater than the maximum number of malicious nodes allowed in the blockchain system.

The embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in the computer, the computer is instructed to execute the method executed by the blockchain node in the foregoing method embodiment. method.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a field programmable gate array (Field Programmable GateArray, FPGA)) is such an integrated circuit, the logic function of which is determined by the user's programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when program development and writing, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many kinds, 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., currently the most commonly used is VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), 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 also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of future computer technology, the computer that realizes the functions of the above embodiments can be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

Although one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment). The term "comprising", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, product, or apparatus comprising a set of elements includes not only those elements, but also other elements not expressly listed elements, or also elements inherent in such a process, method, product, or apparatus. Without further limitations, it is not excluded that there are additional identical or equivalent elements in a process, method, product or device comprising said elements. For example, if the words first, second, etc. are used, they are used to indicate names and do not indicate any particular order.

For the convenience of description, when describing the above devices, functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be realized in the same or more software and/or hardware, and the modules that realize the same function can also be realized by a combination of multiple submodules or subunits, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

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

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, 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 tape disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification may be provided as a method, system or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.

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

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment. In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification under the condition of not contradicting each other.

The above description is only an example of one or more embodiments of this specification, and is not intended to limit one or more embodiments of this specification. For those skilled in the art, various modifications and changes may occur in one or more embodiments of this description. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims (17)

1. A block synchronization method in a block chain system, comprising N block chain nodes in the block chain system, and the method is composed of any block chain node in the N block chain nodes Execute, said method comprising: Multiple block states are received from the remaining N-1 blockchain nodes, and a single block state includes the first block height and the second type of the first type of block newly obtained by its corresponding blockchain node The second block height of the block, the first type of block includes a plurality of transactions in sequence indicated by the consensus proposal, and the second type of block is based on the first block with the same block height Class blocks are obtained, and the second type blocks include block headers, block bodies and block proofs; According to the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights and each of the second block heights, determine several first-type blocks and several second-type blocks to be synchronized ; Synchronizing the plurality of blocks of the first type from the N-1 blockchain nodes, and synchronizing the plurality of blocks of the second type from the N-1 blockchain nodes. 2. The method according to claim 1, synchronizing the several first-type blocks from the N-1 blockchain nodes comprises: determining at least Two third block heights; according to the at least two third block heights, at least two first-type blocks are synchronized from the first node in the N-1 blockchain nodes; Wherein, the method further includes: from the remaining N-2 blockchain nodes except the first node among the N-1 blockchain nodes, obtaining the information contained in the at least two first-type blocks A plurality of corresponding verification data; concurrently verify the at least two first-type blocks according to the plurality of verification data respectively 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 the hash value of the first type of block, and/or, the first type of block according to Transaction root hash corresponding to multiple transactions arranged in sequence. 4. The method according to claim 2, the process of synchronizing the several first-type blocks from the N-1 blockchain nodes includes multiple execution rounds; determine in any i-th execution round The at least two third block heights include the block heights corresponding to the blocks of the first type that are synchronized in the i-1th execution round and have not passed the verification. 5. The method according to claim 1, synchronizing the several second-type blocks from the N-1 blockchain nodes comprises: determining at least Two fourth block heights; according to the at least two fourth block heights, at least two second-type blocks are synchronized from several second nodes in the N-1 blockchain nodes; Wherein, the method further includes: concurrently verifying the block headers of the at least two second-type blocks; and verifying the block certificates included in the second-type blocks whose block headers have passed verification. 6. The method according to claim 5, wherein the at least two fourth block heights are the heights of each block included in the sub-intervals of the height intervals corresponding to the several second-type blocks; The block certificate in the second type of block is obtained based on the signatures of multiple consensus nodes corresponding to the second type of block on the block header and block body in the second type of block; Wherein, the verification of the block certificate included in the second type of block whose block header has passed the verification specifically includes: according to the size of the at least two fourth block heights from the at least two second type blocks Determine the target block in the block; in the case that the block header of the target block has passed the verification, obtain the public keys of multiple consensus nodes corresponding to the target block; verify according to the public keys of the multiple consensus nodes Block proofs in the target block. 7. The method according to claim 5, the process of synchronizing the several second-type blocks from the N-1 blockchain nodes includes multiple execution rounds; determine in any jth execution round The at least two fourth block heights include the block heights corresponding to the second type of blocks that are synchronized in the j-1th execution round and whose block header or block proof has not passed the verification. 8. The method according to any one of claims 1-7, wherein according to the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights and each of the second blocks Height, to determine a number of first-type blocks and a number of second-type blocks to be synchronized, including: Sort each of the first block heights in order from large to small, and determine a number of first-type blocks to be synchronized according to the first block height with the sequence number k; and/or, in order from large to small The order of each of the second block heights is sorted, and according to the second block height with the sequence number k, several second type blocks to be synchronized are determined; Wherein, the value of k is greater than the maximum number of malicious nodes allowed in the blockchain system. 9. A block chain node in a block chain system, comprising N said block chain nodes in said block chain system, said block chain node comprising: The state acquisition unit is configured to receive multiple block states from the remaining N-1 blockchain nodes, and a single block state includes the first area of the first type of block newly obtained by its corresponding blockchain node A block height and a second block height of a second type of block, the first type of block including a plurality of transactions in sequence indicated by the consensus proposal reached, the second type of block based on having the same The block height of the first type of block is obtained, and the second type of block includes block header, block body and block proof; The block determination unit is configured to determine several first-type blocks to be synchronized according to the maximum number of malicious nodes allowed in the blockchain system, each of the first block heights and each of the second block heights and a number of blocks of the second category; 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. 10. The blockchain node according to claim 9, the synchronization processing unit is specifically configured to determine at least two third block heights from the height intervals corresponding to the several first type blocks; and, Synchronizing at least two blocks of the first type from the first node among the N-1 blockchain nodes according to the at least two third block heights; The synchronization processing unit is further configured to obtain the at least two blocks of the first type from the remaining N-2 blockchain nodes except the first node among the N-1 blockchain nodes A plurality of corresponding verification data; concurrently verifying the at least two first-type blocks according to the plurality of verification data respectively corresponding to the at least two first-type blocks. 11. The blockchain node according to claim 10, the verification data corresponding to the first type of block includes, the hash value of the first type of block, and/or, the first type of block The transaction root corresponding to multiple transactions arranged in order in the block. 12. The block chain node according to claim 10, the process of synchronizing the several first-type blocks from the N-1 block chain nodes includes multiple execution rounds; in any i-th execution round The at least two third block heights determined in this round include the block heights corresponding to the block heights of the first type that are synchronized in the i-1th execution round and have not passed the verification. 13. The blockchain node according to claim 9, the synchronization processing unit is specifically configured to determine the heights of at least two fourth blocks from the height intervals corresponding to the plurality of second-type blocks; and, Synchronizing at least two blocks of the second type from several second nodes in the N-1 blockchain nodes according to 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 certificates included in the second-type blocks whose block headers have passed verification. 14. The block chain node according to claim 13, the height of the at least two fourth blocks is the height of each block included in the sub-interval of the height interval corresponding to the plurality of second-type blocks ; The block certificate in the second type of block is obtained based on the signatures of multiple consensus nodes corresponding to the second type of block to the block header and block body in the second type of block; The synchronization processing unit is specifically configured to determine a target block from the at least two second-type blocks according to the height of the at least two fourth blocks; after the block header of the target block has passed In the case of verification, obtain the public keys of multiple consensus nodes corresponding to the target block; and verify the block certificate in the target block according to the public keys of the multiple consensus nodes. 15. The block chain node according to claim 13, wherein the process of synchronizing the blocks of the second type from the N-1 block chain nodes includes multiple execution rounds; The at least two fourth block heights determined in the execution round include the block heights corresponding to the second type of blocks that are synchronized in the j-1th execution round and whose block header or block proof has not passed the verification. 16. The block chain node according to any one of claims 9-15, the block determination unit is specifically configured to sort the heights of each of the first blocks in descending order, according to The height of the first block with the sequence number k determines a number of blocks of the first type to be synchronized; and/or, sort the heights of each second block in descending order, according to the height of the block with the sequence number k The height of the second block determines a number of blocks of the second type to be synchronized; Wherein, the value of k is greater than the maximum number of malicious nodes allowed in the blockchain system. 17. A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed in a computing device, it causes the computing device to execute the method according to any one of claims 1-8.

Images