Data processing method and device, equipment, medium and program product

Abstract

The embodiment of the invention discloses a data processing method and device, equipment, a medium and a program product. The method comprises the following steps: packaging transaction data which is not discharged from a block by using idle node resources to generate a pre-block, and broadcasting the pre-block to a block chain network where a block chain is located; after the proposal authority of the block chain is obtained, assembling the pre-block to generate a pre-proposal; broadcasting the pre-proposal to a block chain network for consensus processing; after the block chain network succeeds in consensus for the pre-proposal, generating a target block based on the block hash in the pre-proposal and the transaction data in the pre-block; and uploading the target block to a block chain. By adopting the data processing method provided by the embodiment of the invention, the block output efficiency of the block chain can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, particularly to the field of blockchain, and specifically to a data processing method, device, equipment, medium, and program product based on blockchain. Background Art

[0002] Blockchain block generation is one of the core technologies of blockchain, effectively ensuring the security and reliability of the blockchain network.

[0003] Currently, the blockchain network implements blockchain block generation using a serial block generation scheme. That is, only after the previous block is submitted to the blockchain can the next block be generated and consensus be reached. This serial block generation method brings a processing bottleneck to blockchain block generation and reduces the efficiency of blockchain block generation. Summary of the Invention

[0004] Embodiments of this application provide a data processing method, device, equipment, medium, and program product based on blockchain, which can effectively improve the efficiency of blockchain block generation.

[0005] On the one hand, embodiments of this application provide a data processing method based on blockchain, the method comprising:

[0006] Using idle node resources to package unblocked transaction data to generate a pre-block, and broadcasting the pre-block to the blockchain network where the blockchain is located;

[0007] After obtaining the proposal permission of the blockchain, performing assembly processing on the pre-block to generate a pre-proposal; the pre-proposal includes the first block hash of the target block corresponding to the pre-block; the target block is a block composed of the transaction data in the pre-block;

[0008] Broadcasting the pre-proposal to the blockchain network for consensus processing;

[0009] After the blockchain network reaches consensus on the pre-proposal, generating a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block; and,

[0010] Uploading the target block to the blockchain.

[0011] On the other hand, embodiments of this application provide a data processing device based on blockchain, the device comprising:

[0012] A processing unit, configured to use idle node resources to package unblocked transaction data to generate a pre-block, and broadcast the pre-block to the blockchain network where the blockchain is located;

[0013] The processing unit is further configured to, after obtaining the proposal permission of the blockchain, assemble and process the pre-block to generate a pre-proposal; the pre-proposal includes the first block hash of the target block corresponding to the pre-block; the target block is a block composed of the transaction data in the pre-block;

[0014] The consensus unit is configured to broadcast the pre-proposal to the blockchain network for consensus processing;

[0015] The processing unit is further configured to, after the blockchain network successfully reaches a consensus on the pre-proposal, generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block; and,

[0016] The processing unit is further configured to upload the target block to the blockchain.

[0017] In one implementation, when the processing unit is configured to assemble and process the pre-block to generate a pre-proposal, it is specifically configured to:

[0018] Construct a Merkle tree based on the transaction data in the pre-block to obtain the root hash of the Merkle tree; and,

[0019] Calculate the first block hash of the target block corresponding to the pre-block based on the root hash of the Merkle tree and the block height information of the blockchain;

[0020] Perform duplicate verification processing on the transaction data in the pre-block to obtain a duplicate verification result;

[0021] Generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result;

[0022] Digitally sign the initial pre-proposal using the private key of the target blockchain node to generate a pre-proposal.

[0023] In one implementation, when the processing unit is configured to generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result, it is specifically configured to:

[0024] Fill the root hash of the Merkle tree and the first block hash of the target block into the initial pre-proposal; and,

[0025] If the duplicate verification result indicates that the transaction data in the pre-block has been included in a block in historical time, mark the transaction data in the pre-block in the duplicate transaction list; the transaction data marked in the duplicate transaction list will not be executed by the virtual machine in the blockchain network;

[0026] Fill the duplicate transaction list marked with the transaction data in the pre-block into the initial pre-proposal.

[0027] In one implementation, the number of transaction data in the pre-block is at least two; if at least one of the at least two transaction data has been included in a block at a historical time, when the processing unit is used to mark the transaction data in the pre-block in the duplicate transaction list, it is specifically used for:

[0028] Mark at least one transaction data in the pre-block that has been included in a block at a historical time in the duplicate transaction list.

[0029] In one implementation, when the processing unit is used to generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block, it is specifically used for:

[0030] Calculate the second block hash of the target block including the transaction data in the pre-block based on the transaction data in the pre-block and the block height information of the blockchain; if the first block hash is the same as the second block hash, detect whether the duplicate transaction list in the pre-proposal is empty;

[0031] If it is not empty, delete the transaction data marked by the duplicate transaction list from the transaction data in the pre-block, and generate a target block based on the target block hash and the remaining transaction data in the pre-block except the deleted transaction data; the target block hash is the first block hash or the second block hash.

[0032] In one implementation, the processing unit is further used for:

[0033] If the duplicate transaction list in the pre-proposal is empty, when the first block hash is the same as the second block hash, generate a target block based on the target block hash and the transaction data in the pre-block.

[0034] In one implementation, the pre-block includes a transaction list, and the transaction list includes transaction data; the sources of the transaction data in the transaction list include at least one of the following: a client and other blockchain nodes in the blockchain network; the number of un-included transaction data is N, and N is a positive integer; when the processing unit is used to pack the un-included transaction data using idle node resources to generate a pre-block, it is specifically used for:

[0035] Use idle node resources to perform parallel packing processing on N transaction data to generate M pre-blocks; M is a positive integer less than or equal to N.

[0036] In one implementation, when N transaction data are packed into M pre-blocks, the processing unit is further used for:

[0037] Select a pre-block to be proposed from the M pre-blocks according to a data selection strategy;

[0038] Among them, the data selection strategy includes any one of the following: selecting in the order of the generation timestamps of the pre-blocks from the earliest to the latest; or, selecting in the order of the data priorities of the transaction data in the pre-blocks from the highest to the lowest; or, selecting the pre-blocks including the transaction data of the specified data type from the M pre-blocks according to the data types of the transaction data in the pre-blocks.

[0039] In one implementation, the process of packing and broadcasting the pre-blocks by the target blockchain node in the blockchain network is parallel to the consensus process for the reference pre-proposals; the reference pre-proposals are generated by the target blockchain node based on the pre-blocks, or sent to the target blockchain node by other blockchain nodes in the blockchain network.

[0040] On the other hand, the embodiments of the present application provide a blockchain node device, and the device includes:

[0041] a processor, configured to load and execute a computer program;

[0042] a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by the processor, the above-mentioned blockchain-based data processing method is implemented.

[0043] On the other hand, the embodiments of the present application provide a computer-readable storage medium, and the computer-readable storage medium stores a computer program, and the computer program is adapted to be loaded and executed by the processor to implement the above-mentioned blockchain-based data processing method.

[0044] On the other hand, the embodiments of the present application provide a computer program product, and the computer program product includes a computer program, and when the computer program is executed by the processor, the above-mentioned blockchain-based data processing method is implemented.

[0045] In the embodiments of the present application, when there are idle node resources in a target blockchain node (such as a blockchain node with consensus authority) in a blockchain network, the target blockchain node can independently package unblocked transaction data to generate a pre-block and broadcast the pre-block in the blockchain network; since the pre-blockchain does not need to include the hash value of the previous block in the blockchain, the target blockchain node can execute the generation and broadcast of the pre-block as long as there are idle node resources, effectively improving the resource utilization rate of the target blockchain node (such as the efficient utilization of CPU and network resources) and data throughput. Further, when the target blockchain node obtains the proposal authority of the blockchain, the target blockchain node can assemble a pre-proposal based on the pre-block and broadcast the pre-proposal to the blockchain network for consensus processing, and after successful consensus, generate a corresponding target block and chain it. Considering that the pre-block has been pre-generated and broadcast, there is no need to generate and broadcast the pre-block when assembling the pre-proposal, which can effectively reduce the time required for assembling the pre-proposal and improve the generation efficiency of the pre-proposal; moreover, the pre-proposal does not need to include the transaction data in the pre-block, so stripping the transaction data from the pre-proposal can greatly reduce the data volume of the pre-proposal, thereby making the digital signature, broadcast, and consensus of the pre-proposal faster. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0047] Figure 1 is a schematic diagram of the architecture of a data processing system based on blockchain provided by an exemplary embodiment of the present application;

[0048] Figure 2a is a schematic diagram of existing serial block production;

[0049] Figure 2b is a schematic diagram of parallel block production provided by an exemplary embodiment of the present application;

[0050] Figure 3 is a schematic flowchart of a data processing method based on blockchain provided by an exemplary embodiment of the present application;

[0051] Figure 4 is a schematic diagram of a target blockchain node packaging unblocked transaction data provided by an exemplary embodiment of the present application;

[0052] Figure 5It is a schematic flow diagram of an assembly pre-proposal provided by an exemplary embodiment of the present application;

[0053] Figure 6 It is a schematic structural diagram of an assembly pre-proposal provided by an exemplary embodiment of the present application;

[0054] Figure 7 It is a schematic flow diagram of another blockchain-based data processing method provided by an exemplary embodiment of the present application;

[0055] Figure 8 It is a schematic diagram of a state machine for one or more rounds of consensus on pre-proposals based on the Tendermint protocol provided by an exemplary embodiment of the present application;

[0056] Figure 9 It is a schematic structural diagram of a blockchain-based data processing device provided by an exemplary embodiment of the present application;

[0057] Figure 10 It is a schematic structural diagram of a blockchain node device provided by an exemplary embodiment of the present application. Detailed implementation manners

[0058] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0059] In the embodiments of the present application, a blockchain-based data processing system is provided. The schematic diagram of the data processing system is as Figure 1 shown. The data processing system is a blockchain network, and multiple blockchain nodes (or referred to as blockchain node devices, which can be simply referred to as nodes) are deployed. Here, the multiple blockchain nodes can be as Figure 1 shown, such as blockchain node 101, blockchain node 102, blockchain node 103,.... The embodiments of the present application do not limit the number of blockchain nodes deployed in the blockchain network. Among them, the blockchain nodes in the blockchain network can refer to the clients in the data processing system, specifically manifested as the blockchain node devices (or referred to as computer devices) where the clients are deployed; in a distributed data processing system, any computer device such as a server and a terminal can join the data processing system and become a blockchain node.

[0060] In a blockchain network, each blockchain node maintains an identical blockchain to share data among the blockchain nodes in the blockchain network through this blockchain, ensuring the consistency of the data stored on all blockchain nodes in the blockchain network. As Figure 1 shown, blockchain 104 is included in blockchain nodes 101, 102, and 103 in the blockchain network, and the blockchain 104 included in each blockchain node is the same. Continuing to refer to Figure 1 , blockchain 104 is composed of multiple blocks linked one by one. Among them, the first block in the blockchain is called the genesis block, which includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, and the block body stores the input information; the next block linked to the genesis block in the blockchain uses the genesis block as the parent block. This next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value of the parent block, version number, timestamp, and difficulty value, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block. It should be noted that for the convenience of explaining the positions of the blocks included in the blockchain, the block height is supported to represent the block at a certain position on the blockchain; as Figure 1 shown, the block height of the genesis block is represented as 0, and the block height of the next block linked to the genesis block is 1, and so on.

[0061] During the operation of the data processing system (i.e., the blockchain network), the blockchain nodes with the proposal permission in the blockchain network can package the hash value of the block at the highest block height H in the blockchain and the unblocked transaction data (i.e., the data that has not been uploaded to the blockchain yet) into a block, and broadcast this block to the blockchain network, so that other blockchain nodes in the blockchain network use the consensus protocol or consensus algorithm to perform consensus processing on this block. If the consensus on this block is successful, indicating that the transaction data is legal, then each blockchain node submits this block to the blockchain it maintains. At this time, the block height of this block on the blockchain is H + 1. And so on, the blockchain node with the proposal permission in the blockchain network (which can be the same as or different from the blockchain node at the proposal block height H + 1) can continue to make a proposal for the block height H + 2. Thus, it can be seen that by using the consensus protocol to consensus the block and then uploading it to the chain, not only can the security of the data in the blockchain network be ensured, but also the data stored on all blockchain nodes in the blockchain network is consistent.

[0062] In practical applications, to comply with the requirement that a block at a higher block height H+1 in the blockchain must carry the hash value of the block at the previous block height H, traditional blockchain networks implement blockchain block production in a serialized manner (i.e., the entire process from block generation to being added to the chain); the specific block production logic for implementing blockchain block production in a serialized manner here is: after the block at block height H in the blockchain is successfully added to the chain, the blockchain node with the proposal right executes the generation of a new block, including the generation and broadcasting of the proposal for the new block. It is not difficult to find that the traditional serialized block production method results in a relatively long time required for a proposal, including the generation and execution of the blocks that make up the proposal, greatly reducing the efficiency of the proposal and leading to low data throughput of blockchain nodes, etc.

[0063] To improve the speed and efficiency of the proposal and ensure the security of transaction data in the blockchain network; the embodiment of this application proposes a new blockchain-based data processing solution based on the system described above Figure 1 This data processing solution, also known as the pre-proposal consensus optimization solution, emphasizes improving the utilization rate of node resources of the target blockchain node, increasing the throughput of the target blockchain node, shortening the time required for the pre-proposal, and thus enhancing the processing speed and efficiency of the pre-proposal from two aspects: the assembly of the pre-proposal and the double-spending of transaction data. The following is a brief introduction to the two aspects mentioned above, where:

[0064] (1) Assembly of the pre-proposal.

[0065] The embodiments of the present application support splitting the process of traditional blockchain block generation into two independent parts: a pre-block and a pre-proposal. Specifically, when there are idle node resources in the target blockchain node, the target blockchain node is allowed to pre-package the unblocked transaction data into a pre-block; since the pre-block only includes a transaction list and does not require other information related to the blocks on the blockchain (such as block height information, block hash, and proposer information, etc.), the target blockchain node can generate and broadcast the pre-block at any time, improving the data throughput of the target blockchain node while also improving the utilization rate of the node resources of the target blockchain node. For example, the process of packaging and broadcasting the pre-block by the target blockchain node in the blockchain network can be executed in parallel with the consensus process for the reference pre-proposal; where the reference pre-proposal can be generated by the target blockchain node based on the pre-block, that is, the target blockchain node can generate or broadcast the pre-block while assembling and broadcasting the pre-proposal based on the pre-generated pre-block; or, the reference pre-proposal can be sent by other blockchain nodes in the blockchain network to the target blockchain node, that is, the target blockchain node can generate or broadcast the pre-block while performing consensus processing on the pre-proposal sent by other blockchain nodes. Another example, when the target blockchain node has not performed consensus processing on the reference pre-proposal, if the target blockchain node has unblocked transaction data, it also supports pre-packaging the transaction data to generate a pre-block.

[0066] Furthermore, when the target blockchain node has the proposal right for the blockchain, the target blockchain node can assemble a pre-proposal based on the pre-generated pre-block. The pre-proposal does not include the transaction data in the pre-block and includes the first block hash of the target block corresponding to the pre-block (that is, the block hash of the target block packaged based on the transaction data in the pre-block, and the target block is the block composed of the transaction data in the pre-block); in this way, the transaction data can be stripped from the traditional proposal, greatly reducing the data volume of the pre-proposal. Then, the target blockchain node can broadcast the pre-proposal assembled based on the pre-block to the blockchain network, enabling other blockchain nodes in the blockchain network to perform consensus processing on the proposal. Finally, after the target blockchain node detects successful consensus on the pre-proposal, it can reassemble the target block based on the pre-proposal and chain the target block to the blockchain.

[0067] (2) Double-spending of transaction data.

[0068] Among them, double spending in blockchain technology refers to the situation where the same blockchain node or different blockchain nodes produce blocks at least twice for the same transaction data and obtain multiple rewards; when double spending occurs in the transaction data, that is, repeated payments for the same transaction data, it is obviously unreasonable. Considering that the transaction data in the pre-block involved in the embodiments of the present application may come from other blockchain nodes in the blockchain network, this makes the transaction data in the pre-block packaged by the target blockchain node may have been blocked by other blockchain nodes; to avoid double spending of transaction data, in the process of assembling a pre-proposal based on the pre-block, the embodiments of the present application also support marking the double-spent transaction data to the pre-proposal, so as to avoid the double-spent transaction data being executed by the virtual machine integrated in the blockchain network, thus causing the problem of repeated payment.

[0069] It has been found through practice that there are obvious advantages when using the blockchain data processing solution provided by the embodiments of the present application for blockchain block production. The following takes the comparison between the solution of the present application and the traditional serial block production solution as an example to illustrate the advantages of the embodiments of the present application, where:

[0070] Under the Tendermint protocol, the schematic diagram of the traditional serial block production solution can be seen in Figure 2a. Under the traditional Tendermint consensus protocol, validator nodes with the right to produce blocks in the blockchain network generate blocks and proposals. The proposal contains a list of transactions, block height, block hash, proposer information, digital signature, etc. Then, the validator nodes with the right to produce blocks broadcast the blocks and proposals to other blockchain nodes in the blockchain network, and then initiate the consensus processes of pre-vote, pre-commit, and commit. Among them, both pre-vote and pre-commit are broadcast processes. Specifically, assume that the current highest block height of the blockchain is H-1, and blockchain node 1 has the right to propose. Then blockchain node 1 can submit a proposal for block height H. Specifically, when blockchain node 1 obtains the right to propose, the blockchain node 1 packs the transaction data into block 1, and block 1 includes the block hash of the block with block height H-1. Then, based on block 1, proposal 1 is generated and broadcast in the blockchain network so that each blockchain node in the blockchain network can use the consensus protocol (such as the Tendermint protocol) to perform consensus processing on proposal 1, and after successful consensus, block 1 is chained to the blockchain. At this time, the current highest block height of the blockchain is H. Further, assume that blockchain node 2 obtains the right to propose. Then blockchain node 2 can, like blockchain node 1, pack its own transaction data into block 2. Block 2 includes the block hash of block 1 with block height H, and based on block 2, proposal 2 is generated, broadcast, and after consensus, block 2 is chained; and so on. It is not difficult to find that this serial block production method will cause each proposal at each block height to take a long time, and the node resources of blockchain nodes without the right to propose will be idle during the waiting for the proposal, resulting in low data throughput of blockchain nodes and low utilization rate of node resources, leading to poor speed and efficiency of the proposal.

[0071] Under the Tendermint protocol, for the schematic diagram of the parallelization of blockchain block production provided by the embodiments of the present application, please refer to Figure 2b, assume that the current highest block height of the blockchain is H, and during the process of blockchain nodes in the blockchain network consensus processing on the pre-proposal corresponding to the block height H, each blockchain node can, according to its own packaging requirements, package its own transaction data into a pre-block and broadcast the pre-block. For example, when blockchain node 1 consensus on the pre-proposal corresponding to block height H, it can package and broadcast pre-block 1, and when blockchain node 2 consensus on the pre-proposal corresponding to block height H, it can package and broadcast pre-block 2, and so on. After the consensus of the pre-proposal corresponding to block height H is successful, each blockchain node can regenerate the block of block height H based on this pre-proposal and the pre-block corresponding to this pre-proposal. At this time, the block includes the block hash of the block of block height H-1. Further, for block height H+1, if blockchain node 2 obtains the proposal right, and the pre-block 2 pre-generated by this blockchain node 2 has not been mined, then blockchain node 2 can quickly assemble pre-proposal 2 based on this pre-generated pre-block 2 and broadcast this pre-proposal 2 in the blockchain network. It can be seen that, compared with the traditional serial block mining, this solution allows the block mining process of the blockchain to be parallelized. For example, the processing of the previous block (such as the consensus of the previous pre-proposal) and the preparation of the next pre-proposal (such as the generation and broadcast of the pre-block corresponding to the next pre-proposal) can be carried out simultaneously, which can greatly reduce the waiting time during the processing; and, for blockchain nodes, they can generate and broadcast pre-blocks at any time when there are idle node resources, improving the utilization rate of node resources while also improving data throughput, thereby improving the speed and efficiency of blockchain block mining.

[0072] It should be noted that: ① The target blockchain node for executing the data processing solution described above can be a blockchain node with consensus voting rights in the blockchain network. Depending on the consensus protocol used to implement consensus voting in the blockchain network, the names of the blockchain nodes with consensus voting rights in the blockchain network vary. For example, the consensus protocol is the Tendermint protocol; this Tendermint protocol uses a consensus algorithm based on Byzantine Fault Tolerance (BFT), and its working mode is similar to a cyclic voting mechanism. Under the Tendermint consensus protocol, the blockchain nodes participating in consensus in the blockchain network can be divided into two categories: The blockchain nodes in the blockchain network that possess the private key of an active validator and participate in consensus voting are called validator nodes (Validator); the blockchain nodes in the blockchain network that do not have the private key of a validator are called non-validator nodes (non-Validator). In this way, the target blockchain node that can be used to execute the data processing solution in the blockchain network is the validator node. It is worth noting that although non-validator nodes cannot participate in the consensus voting of blocks, they can also play an active role in the consensus process by forwarding the metadata, proposals, blocks, and votes related to transaction data to their Peers (blockchain nodes directly connected to each other in the blockchain network can be called Peers).

[0073] As described above, the working mode of the Tendermint protocol is similar to a cyclic voting mechanism. Specifically, it uses the Round protocol to generate blocks. The consensus process of generating blocks by the Round protocol consists of several steps: NewHeight, Propose, Prevote, Precommit, and Commit. Propose→Prevote→Precommit is called one round of consensus; considering that submitting a block at a certain block height may require multiple rounds, that is, Propose→Prevote→Precommit may have at least two rounds, so the consensus process of generating blocks by rounds can also be expressed as: …→NewHeight→(Propose→Prevote→Precommit)→Commit→NewHeight→.... To facilitate each blockchain node in the blockchain network to control its own consensus process, under the Tendermint protocol, both validator nodes and non-validator nodes can maintain their own node states; the node state can be described as (H, R, S), where H represents the current block height of the consensus, R represents the round number of the proposal (pre-proposal in this application) corresponding to this block height that the blockchain node has reached consensus on, and S represents the step at which the blockchain node is currently in the consensus process (such as any one of the steps NewHeight, Propose, Prevote, Precommit, and Commit).

[0074] Under the Tendermint consensus protocol, after establishing connections among blockchain nodes in a blockchain network, information can be propagated through multiplexing so that directly connected Peers can understand the latest consensus status of each block in the blockchain network. For example, a blockchain node can split a block into several small pieces and use an algorithm inspired by LibSwift to accelerate the propagation speed of the block in the network. Another example is that when a blockchain node sends a prevote / precommit, the leading blockchain node A that achieves prevote / precommit first can send the prevote or precommit of the current (or subsequent) round to the lagging blockchain node B. Another example is that a blockchain node pre-votes on a proposal that is locked (PoLC) in a historical round. Another example is that a blockchain node can synchronize old blocks to lagging blockchain nodes. Another example is that a blockchain node notifies other blockchain nodes of the voting information it holds (such as the number of prevotes / precommits on a certain proposal (specifically a pre-proposal in this application)) so that other blockchain nodes can obtain the missing voting information. Another example is that a blockchain node can broadcast its current node status (mainly including: height H, round number R, and step S) to adjacent blockchain nodes.

[0075] For ease of explanation, in the following embodiments, the consensus protocol is taken as Tendermint as an example to introduce the data processing solution provided by the embodiments of the present application, and it is specifically stated here.

[0076] ② The embodiments of the present application do not limit the data type of transaction data. Depending on the different scenarios applied by the blockchain network, that is, for different network types of the blockchain network, the data types of transaction data to be chained in the blockchain network are different. Optionally, when the blockchain network is an electronic bill network, the transaction data in this blockchain network is data related to electronic bills; optionally, when the blockchain network is a medical industry network, the transaction data in this blockchain network is data related to healthcare; and so on. Even the blockchain network provided by the embodiments of the present application can be combined with cloud technology, and the transaction data can be data stored in the cloud.

[0077] ③ In the embodiments of the present application, the collection and processing of relevant data should be strictly in accordance with the requirements of relevant laws and regulations. To obtain personal information, the informed consent of the individual subject is required (or there is a legal basis for information acquisition), and subsequent data use and processing behaviors should be carried out within the scope authorized by laws, regulations, and the individual information subject. For example, when the embodiments of the present application are applied to specific products or technologies, such as when chaining transaction data, the permission or consent of the owner of the transaction data is required, and the collection, use, and processing of relevant data (such as the collection and release of bullet screens posted by the object, etc.) need to comply with the relevant laws, regulations, and standards of the relevant region.

[0078] Based on the blockchain-based data processing solution described above, the embodiments of the present application propose a more detailed blockchain-based data processing method. The data processing method proposed by the embodiments of the present application will be introduced in detail below with reference to the accompanying drawings.

[0079] Figure 3 FIG. 4 shows a schematic flowchart of a blockchain-based data processing method provided by an exemplary embodiment of the present application. This data processing method can be executed by a computer device, specifically by a target blockchain node (any blockchain node with consensus voting authority) in a blockchain network. As Figure 3 shown, this data processing method may include but is not limited to steps S301-S305:

[0080] S301: Use idle node resources to package unblocked transaction data to generate a pre-block, and broadcast the pre-block to the blockchain network where the blockchain is located.

[0081] In a specific implementation, when the target blockchain node detects that there are idle node resources and there is unblocked transaction data, the target blockchain node can use the idle node resources to package the unblocked transaction data to generate a pre-block; and after the pre-block is generated, it can broadcast the pre-block to the blockchain network by itself. Among them, compared with a block, the data structure of a pre-block only includes a transaction list, and the transaction list includes the unblocked transaction data in the target blockchain node; and it does not include data such as the block height information (or simply referred to as block height), the block hash of the block corresponding to the previous block height, and the proposer information included in a traditional block.

[0082] It can be seen from this that considering that the pre-block does not need to include the relevant information of the blocks in the blockchain (such as block height and block hash), nor does it need to include the relevant information of the blockchain nodes in the blockchain network that are given the proposal authority; this makes the construction of the pre-block not affected by the blockchain structure of the blockchain and the consensus mechanism in the blockchain network (such as the one used to determine the proposer), and any blockchain node with the block generation authority in the blockchain network can construct and broadcast its own pre-block at any time, greatly improving the flexibility of the generation and broadcast of the pre-block.

[0083] Furthermore, it should be understood that the sources of transaction data in each blockchain node in the blockchain network may include: directly sent by the client to the blockchain node, or broadcast by other blockchain nodes in the blockchain network other than the blockchain node itself. That is to say, the sources of the unblocked transaction data included in the target blockchain node may include: the client and other blockchain nodes in the blockchain network other than the target blockchain node; for this reason, when the target blockchain node in the embodiment of the present application packages the unblocked transaction data to generate a pre-block, it specifically supports: packaging a large amount of transaction data directly sent by the client to the target blockchain node, and packaging a small amount of transaction data sent by other blockchain nodes in the blockchain network other than the target blockchain node to the target blockchain node. In other words, the sources of the transaction data in the transaction list included in the pre-block generated by the target blockchain node in one packaging include: a large amount of transaction data comes from the client, and a small amount of transaction data comes from other blockchain nodes in the blockchain network other than the target blockchain node.

[0084] Among them, when the target blockchain node packages the pre-block, the determination methods for the small amount of transaction data from other blockchain nodes may include but are not limited to at least one of the following: ① Determine the other blockchain nodes for which the transaction data to be packaged according to the working status of other blockchain nodes (such as the activity, proposal frequency, or network conditions in the historical time period, etc.); and use the transaction data of the determined other blockchain node as the transaction data to be packaged. For example, assume that the transaction data 1 included in the target blockchain node comes from blockchain node 1, and the transaction data 2 comes from blockchain node 2; the target blockchain node can obtain the network conditions of blockchain node 1 and blockchain node 2 in the historical time period (such as the 10 minutes before the current packaging time). If the offline duration of blockchain node 1 in the historical time period is longer than that of blockchain node 2, indicating that blockchain node 1 is more likely to have transaction data processing delays or transaction data loss, then the target blockchain node can package the transaction data 1 broadcast by blockchain node 1 into the pre-block to prevent the loss or processing delay of the transaction data of blockchain node 1.

[0085] ② Determine the transaction data from other blockchain nodes and to be packaged according to the timestamp when the target blockchain node receives the transaction data. For example, assume that the target blockchain node receives the transaction data 1 sent by blockchain node 1 at the first moment and the transaction data 2 sent by blockchain node 2 at the second moment, and the first moment is earlier than the second moment. Then, when packaging, the target blockchain node can use the transaction data 1 with an earlier reception time as the transaction data to be packaged to improve the timeliness of transaction data processing and avoid transaction data processing delays.

[0086] ③ When each piece of transaction data received by the target blockchain node has a priority, it also supports determining the transaction data to be packaged according to the priority order of the transaction data. For example, assume that the data priority of the transaction data 1 sent by the blockchain node 1 received by the target blockchain node is greater than the data priority of the transaction data 2 sent by the blockchain node 2 received by the target blockchain node; then the target blockchain node can use the transaction data 1 with a higher data priority as the transaction data to be packaged during packaging.

[0087] A schematic diagram of an exemplary target blockchain node packaging unblocked transaction data can be seen Figure 4 ; as Figure 4 shown, assume that the blockchain network includes blockchain nodes 401, 402, and 403; the blockchain node 402 is the target blockchain node involved in the embodiments of the present application. Assume that the total number of unblocked transaction data in the blockchain node 402 is 200; among them, 50 pieces of transaction data are directly sent from the client to the blockchain node 402, and 150 pieces of transaction data are broadcast by other blockchain nodes in the blockchain network; and at least 50 pieces of transaction data from the client include the transaction data 2 directly sent by the client 404 and the transaction data 2 directly sent by the client 405, and 150 pieces of transaction data from other blockchain nodes include the transaction data 3 sent by the client 406 broadcast by the blockchain node 401. Assume that each time 3 pieces of transaction data are packaged into a pre-block, then following the principle of packaging a large amount of transaction data directly sent by the client and a small amount of transaction data broadcast by other blockchain nodes, the transaction data 1 and transaction data 2 from the client, and the transaction data 3 from other blockchain nodes can be packaged into a pre-block; at this time, the data structure of this pre-block includes: two pieces of transaction data from the client and one piece of transaction data from the blockchain node.

[0088] It can be seen that considering that the client often chooses to send transaction data to a single blockchain node when sending transaction data to the blockchain network, the transaction data from the client in the target blockchain node is different from the transaction data broadcast by other blockchain nodes to this target blockchain node; thus, when the target blockchain node packages the pre-block, packaging a large amount of transaction data from the client into the pre-block can ensure that most of the transaction data in the pre-block has not been uploaded to the chain, that is, it can alleviate the problem of duplicate transaction data appearing in different blocks in the blockchain. At the same time, considering that there may be blockchain nodes in the blockchain network that cause transaction data to be delayed in processing or transaction data to be lost due to failures (such as being offline), the embodiments of the present application involve packaging a small amount of transaction data from other blockchain nodes into the pre-block during packaging to prevent problems such as processing delays or losses of transaction data of other blockchain nodes.

[0089] It should be noted that the foregoing is described by taking the case where the target blockchain node packs the unblocked transaction data into a pre-block as an example. However, it can be understood that the data structure of the pre-block involved in the embodiments of the present application is not limited by the blockchain structure and the consensus mechanism. Therefore, the embodiments of the present application also support the target blockchain node to generate and broadcast multiple pre-blocks in parallel by using the idle node resources according to the situation of its own idle node resources. While greatly improving the generation / broadcast efficiency of the pre-block, it can also achieve the maximum utilization of node resources and improve the data throughput of the target blockchain node. Specifically, assuming that the number of unblocked transaction data included in the target blockchain node is N, and N is a positive integer, then when using the idle node resources to pack the unblocked transaction data into pre-blocks, the idle node resources can be used to pack N transaction data in parallel to generate M pre-blocks, where M is a positive integer less than or equal to N. For example, if the node resources required to pack / broadcast a pre-block are 10, and the total amount of idle node resources of the target blockchain node is currently 100, then the target blockchain node can pack / broadcast 10 pre-blocks in parallel to improve the generation / broadcast efficiency of the pre-block. Of course, if the target blockchain node receives a matter with a higher priority during the process of packing multiple pre-blocks in parallel, then the embodiments of the present application support pausing the packing of some pre-blocks until there are idle node resources in the target blockchain node to continue packing the paused pre-blocks, so as to improve the flexibility of the node resources of the target blockchain node and ensure that the matter with a higher priority will not be delayed due to the parallel packing of pre-blocks, and ensure the normal operation of the target blockchain node.

[0090] S302: After obtaining the proposal right of the blockchain, perform an assembly process on the pre-block to generate a pre-proposal.

[0091] It should be understood that each blockchain node in the blockchain network (specifically, the blockchain node with the consensus voting right, such as the validator node under the Tendermint protocol) needs to obtain the proposal right for the block at a certain block height through an auction. In a specific implementation, assuming that the target blockchain node obtains the proposal right for the block at block height H on the blockchain, then the target blockchain node can select a pre-block (which can be represented as the target pre-block) from the pre-generated M pre-blocks, and perform an assembly process on the target pre-block to generate a pre-proposal for the block at block height H. The following details the specific implementation processes of the selection operation for the target pre-block and the assembly operation for the pre-proposal involved in the above process; where:

[0092] (1) Select the target pre-block from the M pre-blocks.

[0093] When M = 1, it indicates that the number of pre - blocks pre - generated by the target blockchain node and not yet chained is 1. Then the target blockchain node can directly use this pre - block as the target pre - block.

[0094] When M>1, it indicates that the target blockchain node stores at least two pre - generated pre - blocks that have not yet been chained. Then the target blockchain node can select the pre - block to be proposed from the M pre - blocks according to the data selection strategy as the target pre - block for generating the pre - proposal (that is, this proposal aims to chain the transaction list included in this target pre - block to the blockchain). Among them, the data selection strategy can include any of the following:

[0095] ① Select in the order of the generation timestamps (or simply timestamps) of the pre - blocks from earliest to latest. It can be understood that each pre - block has a different timestamp. The timestamp of the pre - block is used to indicate the generation time of the block, and the earlier the timestamp of the pre - block, the more likely the transaction data included in the pre - block was sent to the blockchain network earlier. Therefore, to ensure the timeliness of transaction data chaining, the embodiments of this application support selecting the pre - block with the earliest timestamp among the M pre - blocks as the target pre - block in the order of timestamps from earliest to latest.

[0096] ② Select in the order of the data priorities of the transaction data in the pre - blocks from highest to lowest; this way of selecting pre - blocks according to the data priorities of the transaction data can make the pre - blocks corresponding to the transaction data with higher data priorities more likely to be selected, so as to ensure that the transaction data with higher data priorities can be chained in time and meet the chaining requirements of transaction data with higher urgency or importance for chaining first.

[0097] Specifically, the transaction data in the blockchain network can be assigned corresponding data priorities according to the urgency or importance level. The data priority can be set by the target blockchain node receiving the transaction data, or by the source of the transaction data (e.g., set by the user when uploading through the client). Then, due to the different data priorities of the transaction data, the block priorities corresponding to different pre-blocks obtained by packing the transaction data with different data priorities are also different. For example, the order of data priorities from high to low is: transaction data 1 → transaction data 2 → transaction data 3 → transaction data 4. Suppose pre-block 1 includes transaction data 1 and pre-block 2 includes transaction data 2. Then it is determined that the block priority of pre-block 1 is higher than that of pre-block 2, indicating that the urgency of transaction data 1 in pre-block 1 to be uploaded to the chain is greater than the urgency of transaction data 2 in pre-block 2 to be uploaded to the chain. Therefore, pre-block 1 can be selected as the target pre-block. Different from this, suppose pre-block 1 includes transaction data 1 and transaction data 4, and pre-block 2 includes transaction data 2 and transaction data 3. Considering that pre-block 1 includes both transaction data with a data priority lower than that of pre-block 2 and transaction data with a data priority higher than that of pre-block 2; the embodiments of the present application support selecting the target pre-block from pre-block 1 and pre-block 2 according to a set rule.

[0098] Among them, the setting rules may include but are not limited to: randomly selecting, such as randomly selecting the pre-block 1 as the target pre-block. Or, performing an average operation on the data priorities of the transaction data in the pre-block, and using the calculation result as the block priority of the corresponding pre-block; and selecting the pre-block with the largest block priority as the target pre-block. For example, assuming that the data priorities from high to low are 10-1, the larger the value, the higher the data priority, and assuming that the value of transaction data 1 is 9, the data priority of transaction data 2 is 8, the priority of transaction data 3 is 4, and the value of transaction data 5 is 1; then the calculation result obtained by performing an average operation on the data priorities of transaction data 1 and transaction data 4 is 5, and this value 5 is used as the block priority of pre-block 1. Similarly, the calculation result obtained by performing an average operation on transaction data 2 and transaction data 3 is 6, and this value 6 is used as the block priority of pre-block 2; since the block priority of pre-block 2 is higher than that of pre-block 1, pre-block 2 is selected as the target pre-block. Or, using the data priority of the transaction data with the highest data priority in the pre-block as the block priority of the corresponding pre-block; and selecting the pre-block with the largest block priority as the target pre-block. For example, assuming that the data priorities from high to low are 10-1, the larger the value, the higher the data priority, and assuming that the value of transaction data 1 is 9, the data priority of transaction data 2 is 8, the priority of transaction data 3 is 4, and the value of transaction data 5 is 1; then it is determined that the block priority of pre-block 1 is the data priority of transaction data 1 (i.e., the value 9), and the block priority of pre-block 2 is the data priority of transaction data 2 (i.e., the value 8), then it is determined that pre-block 1 is selected as the target pre-block.

[0099] ③ Select a pre-block including transaction data of a specified data type from the M pre-blocks according to the data type of the transaction data in the pre-block. It should be noted that in the case where the blockchain network supports uploading transaction data of multiple data types, the data priorities of the transaction data corresponding to different data types may vary; considering that the target blockchain node often packs transaction data of the same data type into one pre-block when packing, the embodiments of the present application support selecting a pre-block including transaction data of a specified data type from the M pre-blocks as the target pre-block. Among them, the specified data type is variable; for example, according to the different uploading requirements of blockchain nodes, the specified data types corresponding to different blockchain nodes are different; for another example, when proposing for different block heights, the specified data type may also be different. Thus, on the one hand, the variability of the specified data type improves the flexibility of uploading transaction data of different data types in the blockchain network; on the other hand, selecting pre-blocks according to the data type of transaction data meets the requirement of the target blockchain node to customize the data type of transaction data with priority for uploading, and improves the flexibility of data uploading.

[0100] It should be noted that the above ①-③ are only three exemplary selection implementation processes for selecting the target pre-block from the M pre-blocks given in the embodiments of the present application; in actual applications, this selection implementation process can also undergo adaptive changes. For example, a certain pre-block can be randomly selected from the M pre-blocks as the target pre-block, or a pre-block with a large number of transaction data from a specified source party can be selected as the target pre-block according to the source of the transaction data, and so on.

[0101] (2) Assemble and process the target pre-block to generate a pre-proposal.

[0102] After selecting the target pre-block from the M pre-blocks based on the foregoing implementation manner (1), the embodiments of the present application support assembling and processing the target pre-block to generate a pre-proposal corresponding to the target pre-block; this pre-proposal is intended to notify each blockchain node in the blockchain network that it is hoped that the transaction list (specifically, the transaction data in the transaction list) included in the target pre-block will be uploaded to the blockchain this time. Among them, the pre-proposal may include: the transaction merkle root in the target pre-block, the first block hash of the target block corresponding to the pre-block (i.e., the selected target pre-block), the duplicate transaction list, and the digital signature of the target blockchain node, etc. It should be understood that, according to the different consensus protocols adopted by the blockchain network, the information included in the pre-proposal is not limited to the above several types. Exemplarily, assuming that the consensus protocol adopted by the blockchain network is the Tendermint protocol, then according to the round-robin voting mechanism of the Tendermint protocol, the pre-proposal with a block height of H and a consensus round of R should also include: an optional recently locked (PoLC) pre-proposal lower than the current round R; this enables the blockchain nodes in the blockchain network to safely unlock the corresponding pre-block from an older round (i.e., a round lower than the current round R, such as round R-1) when necessary during the consensus process for the pre-proposal, thus ensuring the liveness of the blockchain nodes.

[0103] The following combines Figure 5 and Figure 6 , and introduces the general process of generating a pre-proposal based on the assembly and processing of the target pre-block. The general process may include but is not limited to steps s11-s14:

[0104] s11: The target blockchain node constructs a Merkle Tree corresponding to the transaction data in the target pre-block (i.e., the target pre-block), and obtains the Merkle root of the Merkle Tree. Among them, the Merkle Tree can also be called a hash tree, which is a persistent data structure. The construction of the Merkle Tree is created from bottom to top. The original data (such as the transaction data involved in this solution) is subjected to a hash operation, and the calculation result of the hash operation is used as the leaf node of the Merkle Tree. Then, continue to perform a hash operation on two adjacent leaf nodes in the Merkle Tree, and the calculation result of the hash operation is used as the parent node of the two adjacent leaf nodes. And so on, the final calculation result is used as the root node of the Merkle Tree, that is, the Merkle root of the Merkle Tree.

[0105] s12: The target blockchain node calculates the first block hash of the target block corresponding to the target pre-block based on the Merkle root of the Merkle Tree corresponding to the transaction data and the block height information of the blockchain (i.e., H). The target block includes the transaction data in the target pre-block (i.e., the target pre-block), and the target block can be understood as a block generated based on the transaction data in the target pre-block.

[0106] s13: The target blockchain node also performs duplicate verification processing on the transaction data in the target pre-block (i.e., the target pre-block) to obtain a duplicate verification result. The duplicate verification processing aims to verify whether the transaction data in the target pre-block is double-spent; that is, whether the transaction data in the target pre-block has been on the chain, so as to avoid the problem of double payment for the same transaction data.

[0107] s14: The target blockchain node generates an initial pre-proposal based on the Merkle root, the first block hash of the target block, and the duplicate verification result; then, uses the private key of the target blockchain node to digitally sign the initial pre-proposal to generate a pre-proposal.

[0108] In steps S13 - S14, after the target blockchain node calculates the root hash of the Merkle tree, the first block hash of the target block, and the repeated verification result, it can fill the root hash of the Merkle tree and the first block hash of the target block into the initial pre - proposal; then, based on the indication of the repeated verification result, generate a final pre - proposal based on the initial pre - proposal. Specifically, if the repeated verification result indicates that the transaction data in the pre - block (i.e., the aforementioned target pre - block) has been included in a block at a historical time, it means that there is a blockchain node in the blockchain network that has received a reward due to the transaction data in this pre - block. Then, if the target blockchain node uploads the transaction data again, there will be a double - spending problem of double - paying for the same transaction data. Therefore, the embodiments of this application support marking the transaction data in the pre - block in the repeated transaction list. The repeated transaction list is also called the double - spending transaction list, and the transaction data marked in this list will not be executed by the virtual machine in the blockchain network to avoid the double - spending problem. Conversely, if the repeated verification result indicates that the transaction data in the pre - block has not been included in a block at a historical time, it means that there is no blockchain node in the blockchain network that has included the transaction data in this pre - block, then the transaction data in this pre - block is not marked in the repeated transaction list; in this case, an empty repeated transaction list can be added to the initial pre - proposal.

[0109] It should be understood that the number of transaction data in the pre - block can be multiple, such as at least two. Therefore, if the repeated verification process is performed on the transaction data in the pre - block, and the repeated verification result indicates that at least one of the at least two transaction data has been included in a block at a historical time, that is, only some of the transaction data in the pre - block has been included in a block, then the embodiments of this application support only marking at least one transaction data in the pre - block that has been included in a block at a historical time in the repeated transaction list. In this way, it can accurately mark the transaction data with double - spending in the pre - proposal, avoid the repeated upload of transaction data, and improve the security of transaction data in the blockchain network.

[0110] S303: Broadcast the pre - proposal to the blockchain network for consensus processing.

[0111] S304: After the blockchain network reaches a consensus on the pre - proposal, generate a target block based on the block hash in the pre - proposal and the transaction data in the pre - block.

[0112] S305: Upload the target block to the blockchain.

[0113] In steps S303 - S305, after generating a pre - proposal based on the pre - block assembly, the target blockchain node supports broadcasting the pre - proposal to other blockchain nodes in the blockchain network except the target blockchain node, so that the blockchain nodes with consensus voting rights in the blockchain network perform consensus processing on the pre - proposal based on the consensus algorithm; and, after successful consensus on the pre - proposal, a target block is generated based on the block hash in the pre - proposal and the transaction data in the pre - block, so that each blockchain node in the blockchain network can chain the target block to the blockchain, realizing the chaining of the transaction data in the target block (i.e., the transaction data in the target pre - block).

[0114] It should be noted that the process of generating / broadcasting the pre - block included in step S301 mentioned above in the embodiments of the present application and the process of generating / broadcasting the pre - proposal included in steps S302 - S305 can be executed in parallel, or the process of generating / broadcasting the pre - block is prior to the process of generating / broadcasting the pre - proposal.

[0115] In summary, on the one hand, the pre - proposal consensus optimization method provided in the embodiments of the present application supports pre - broadcasting the transaction data of future blocks in the form of pre - blocks, which can greatly reduce the waiting time during the processing, realize the parallelization of the block - generation process of the blockchain, and significantly improve the processing efficiency and system throughput of the blockchain. On the other hand, when the blockchain node in the embodiments of the present application packs transaction data, a large amount of transaction data directly comes from the client, which can effectively reduce duplicate transactions in the blockchain and further improve the processing efficiency of the blockchain; and it also supports packing a small amount of transaction data transmitted by other blockchain nodes, thus preventing transaction processing delays or transaction losses caused by the offline of other blockchain nodes. On the other hand, although the embodiments of the present application allow duplicate transactions to appear in different pre - blocks, they support marking in the pre - proposal, avoiding the double - spending problem, thus improving the blockchain proposal efficiency, achieving the effect of improving the system throughput, and continuing the fund - security feature.

[0116] Please refer to Figure 7 , Figure 7 which shows a schematic flowchart of another blockchain - based data processing method provided by an exemplary embodiment of the present application. This data processing method can be executed by a computer device, specifically by a target blockchain node (any blockchain node with consensus voting rights) in the blockchain network. As Figure 7 shown, this data processing method may include but is not limited to steps S701 - S706:

[0117] S701: Pack the unblocked transaction data using idle node resources to generate a pre - block, and broadcast the pre - block to the blockchain network where the blockchain is located.

[0118] S702: After obtaining the proposal authority of the blockchain, assemble the pre-blocks to generate a pre-proposal.

[0119] It should be noted that the specific implementation process of the embodiment shown in steps S701-S702 can be found in the aforementioned Figure 3 The relevant description of the specific implementation process of the embodiment shown in steps S301-S302 in the shown embodiment is not repeated here.

[0120] S703: Broadcast the pre-proposal to the blockchain network for consensus processing.

[0121] The embodiment of the present application supports the use of the Tendermint protocol in the blockchain network to achieve consensus processing of pre-proposals. As described above, the Tendermint protocol uses a round protocol to produce blocks; that is, to determine a block on the blockchain, one or more rounds of consensus processes are required for the corresponding pre-proposals, and a round of consensus processes may include: NewHeight→(Propose→Prevote→Precommi t)→Commit. Among them, NewHeight is the block height + 1 after the block is accepted by the entire network; Propose→Prevote→Precommit is a round (Round), and the brackets here indicate that it may take multiple rounds to successfully submit a block (specifically a pre-proposal in this application) at a certain block height; Commit is the process of formally submitting the corresponding target block to the blockchain after a pre-proposal consensus is successful.

[0122] For example, a schematic diagram of a state machine for one or more rounds of consensus based on the Tendermint protocol can be found in Figure 8 ;like Figure 8 As shown, after the block with block height H-1 in the blockchain is put on the chain, each blockchain node in the blockchain network performs the NewHight step, and each blockchain node switches from the Commit step to the Newhight step. If the blockchain node with proposal authority is determined to be the target blockchain node from the blockchain network; then the target blockchain node can execute the pre-proposal generation based on the pre-block assembly, and then initiate the pre-voting, pre-submitting and submitting process for the pre-proposal in the blockchain network; wherein, Prevote and Precommit are both the process of broadcasting the pre-proposal in the blockchain network. In detail, the target blockchain node can initiate a round of consensus for the current block height H based on the pre-proposal; the process of a round of consensus may include:

[0123] 1) Pre-proposal (or proposal stage) step.

[0124] In the pre-proposal stage, the selected proposer (i.e., the target blockchain node) can spread the pre-proposal in the blockchain network; for other blockchain nodes in the blockchain network except the target blockchain node, it can receive the pre-proposal sent by the target blockchain node. Among them, for the blockchain nodes in the blockchain network, the exit conditions for them to exit the pre-proposal step may include:

[0125] ① When the blockchain node enters the pre-proposal stage and the duration in the pre-proposal stage exceeds the specified timeout, it transfers from the pre-proposal stage to the pre-proposal phase;

[0126] ② After the blockchain node receives the pre-proposal (or called the proposal block) and all pre-votes in the Locked-in Proof-of-Lock (PoLC) round, it transfers from the pre-proposal stage to the pre-proposal phase. Among them, when the number of blockchain nodes participating in the consensus vote in the blockchain network is less than 1 / 3 of the total number of nodes, in order to avoid the situation of submitting two different blocks in different rounds at the same block height, the Tendermint protocol introduces a locking mechanism. Specifically, the validator node (i.e., the blockchain node with the consensus voting right) will be locked on the block it most recently pre-committed (in this application, it is locked to the pre-proposal); when the validator node receives more than 2 / 3 of the pre-votes (Prevote) for a block, the validator node pre-commits (Precommit) for this block, and the validator node is locked on this block, indicating that for the same block height, the validator node can only pre-vote (Prevote) for the locked block in the next round, which can prevent the validator node from pre-committing (Precommit) one block in the previous round and pre-voting (Prevote) another block in the next round, thus avoiding the situation of submitting two different blocks at the same block height. Of course, if the validator node detects that it has collected a +2 / 3 pre-vote set for a block / empty block, it can perform a Proof-of-Lock Change (PoLC); specifically, if the validator node detects that the number of pre-votes for a new pre-proposal or empty block in a higher round (compared to the round of its currently locked block) exceeds 2 / 3, the validator node can unlock the originally locked block and vote for the new pre-proposal or empty block. Among them, "2 / 3" can be abbreviated as "+2 / 3".

[0127] ③ When the blockchain node meets the general voting exit conditions, it transfers from the pre-proposal stage to the pre-proposal phase; among them, the general voting exit conditions may include: when the blockchain node receives more than 2 / 3 of the pre-commit votes for a certain block, it transfers to the Commit (H) step, that is, directly chain this certain block; or when the blockchain node receives more than 2 / 3 of the pre-votes for a new round, it pre-votes for the new round (H, R+x); when the blockchain node receives more than 2 / 3 of the pre-commit messages for a new round, it pre-commits for the new round (H, R+x).

[0128] 2) Pre-voting step.

[0129] After each blockchain node in the blockchain network enters the pre-voting stage, it can perform a pre-voting operation and broadcast its vote to other blockchain nodes. Specifically, if the PoLC block locked by the blockchain node has a larger block round than the current locked block, the blockchain node unlocks the locked block. Otherwise, if the blockchain node still has a locked block, it conducts a pre-vote on the locked block and broadcasts its pre-vote. Otherwise, if the pre-proposal is valid, it conducts a pre-vote on the pre-proposal. Otherwise, if the pre-proposal is invalid, it conducts a pre-vote on the empty block. Otherwise, if the pre-proposal is not received in time, it conducts a pre-vote on the empty block.

[0130] The end conditions for the blockchain nodes in the blockchain network to end the pre-voting can include: the blockchain node receives 2 / 3 pre-votes for a certain block or the empty block and then enters the pre-commit stage; or, the blockchain node receives 2 / 3 pre-votes, but no other block obtains a majority of votes, and after waiting for the specified timeout, it enters the pre-commit stage. Or, the blockchain node meets the general voting exit conditions (see the foregoing related descriptions and will not be elaborated here).

[0131] It should be noted that when the blockchain nodes in the blockchain network conduct consensus voting, the signature field of the vote should contain the information of the block height H and the round number R.

[0132] 3) Pre-commit stage.

[0133] After the blockchain nodes in the blockchain network enter the pre-commit stage, the blockchain nodes conduct pre-commit and broadcast the pre-commit vote. Specifically, if the validator node (i.e., the blockchain node with specific consensus voting rights) collects enough pre-votes for the pre-proposal, it locks (or changes the lock) to the pre-proposal, pre-commits the pre-proposal, and updates LastLockRound (i.e., the most recent locked block). Otherwise, if the validator node collects enough pre-votes for the empty block, it unlocks the locked block and pre-commits the empty block. Otherwise, the validator does not change the locked block and pre-commits the empty block. Among them, pre-committing the empty block means that in this round, the validator node has collected more than 2 / 3 of the votes, but has not collected more votes for the PoLC block and has waited for the specified timeout.

[0134] The end conditions for a blockchain node to end pre - submission can include: ① If the blockchain node receives more than 2 / 3 pre - submitted empty blocks, it proceeds to the next round of voting. ② If the blockchain node receives more than 2 / 3 pre - submission votes and no block meets the submission conditions, and waits for the specified timeout period, it proceeds to the next round of voting. Among them, to ensure that each blockchain node has the opportunity to propose its own pre - block, the pre - proposal for each round is assembled, signed, and broadcast by the designated proposer; and the proposer for each round is calculated using a deterministic non - blocking round - robin algorithm proportional to the voting rights of the nodes. Also, for any block height H, the pre - proposal for round R needs to consist of the pre - block and the nearest PoLC proposal with a lower round number than the current round; this allows the Tendermint protocol to safely unlock nodes, thus ensuring system liveness. ③ The blockchain node meets the general voting exit conditions (see the relevant description above and will not be elaborated here).

[0135] The above steps 1) - 3) give the general process of one round of consensus; as described above, for the same block height, multiple rounds may be required. Then, in the following cases, reaching a consensus on a pre - proposal for a block height H requires multiple rounds of consensus to succeed: the designated proposer is not online; or, the proposed block is invalid;; or, the proposed block is not propagated in time; or, the proposed block is valid, but +2 / 3 pre - votes are not collected in time; or, the proposed block is valid, and enough +2 / 3 pre - votes are collected, but +2 / 3 pre - submissions are not collected in time. In addition, the above - mentioned problems can be solved by increasing the number of rounds (the proposer after changing the round can be changed), or increasing the timeout period for subsequent rounds.

[0136] 4) Submission stage.

[0137] After the blockchain nodes in the blockchain network enter the submission stage, they can set CommitTime = now(), and wait until they receive a new block message and then enter the NewHeight(H + 1) stage.

[0138] 5) New block height stage (NewHeight).

[0139] After the blockchain nodes in the blockchain network enter the new block height stage, they can set LastCommit = PreCommit, increment the block height by 1 (e.g., changing from block height H to H + 1), set the new block start time as StartTime = CommitTime+timeoutCommit; and wait until the new block start time to make a new proposal (H + 1, 0), where 0 represents the first round of consensus for block height H + 1.

[0140] In summary, through the above steps 1)-5), consensus processing for block heights can be achieved based on the Tendermint protocol. It should also be noted that in the Tendermint protocol, to ensure that each blockchain node can maintain the latest voting information in real time, it also supports blockchain nodes (such as validator nodes) to notify other blockchain nodes of the voting information they hold (such as pre-vote information or pre-commit information), so that other blockchain nodes can obtain the missing voting information in a timely manner. Additionally, it also supports validator nodes to split the pre-block into several small pieces and use an algorithm inspired by LibSwift to accelerate the propagation speed of the pre-block in the blockchain network.

[0141] S704: After the pre-proposal consensus is successful in the blockchain network, based on the transaction data in the pre-block and the block height information of the blockchain, calculate the second block hash of the target block including the transaction data in the pre-block.

[0142] S705: If the first block hash is the same as the second block hash, generate the target block based on the target block hash and the remaining transaction data in the pre-block except for the deleted transaction data.

[0143] S706: Chain the target block to the blockchain.

[0144] In steps S704 - S706, after the pre-proposal consensus is successful, it indicates that each blockchain node in the blockchain network agrees to chain the transaction data corresponding to the pre-proposal. Then, the embodiments of the present application also support each blockchain network to reorganize the corresponding target block (the data structure of the target block meets the requirements for chaining) based on the pre-block corresponding to the pre-proposal (which has been pre-broadcast to each blockchain node).

[0145] Specifically, if the target blockchain node has previously broadcast a pre-block, then each blockchain node can calculate the second block hash of the target block including the transaction data in the pre-block based on the transaction data in the pre-block and the block height information of the blockchain (i.e., the aforementioned abbreviated block height). Then, the blockchain node will compare the first block hash in the pre-proposal with the second block hash generated by itself to ensure the consistency of the transaction data in the generated target block and the transaction data that the target blockchain node wants to be chained, and guarantee the legality and security of the transaction data chained in the blockchain network. Among them, ① if the first block hash is the same as the second block hash, it indicates that the transaction data in the generated target block is consistent with the transaction data that the target blockchain node wants to be chained, and then continue to detect whether the duplicate transaction list in the pre-proposal is empty. If it is not empty, it indicates that there is double spending in the transaction data in the pre-block, then delete the transaction data marked by the duplicate transaction list from the transaction data in the pre-block, and generate a target block based on the target block hash and the remaining transaction data in the pre-block except the deleted transaction data; the target block hash is the first block hash or the second block hash; on the contrary, if it is empty, it indicates that there is no double spending in the transaction data in the pre-block, then when the first block hash is the same as the second block hash, generate a target block based on the target block hash and the transaction data in the pre-block. ② If the first block hash is different from the second block hash, it indicates that the transaction data in the generated target block is inconsistent with the transaction data that the target blockchain node wants to be chained, then do not chain the transaction data in the pre-block, and can notify each blockchain node in the blockchain network to initiate a new pre-proposal.

[0146] In the embodiment of the present application, when there are idle node resources in the target blockchain node (such as a blockchain node with consensus authority) in the blockchain network, the target blockchain node can pack the unblocked transaction data by itself to generate a pre-block and broadcast the pre-block in the blockchain network; since the pre-blockchain does not need to include the hash value of the previous block in the blockchain, the target blockchain node can execute the generation and broadcast of the pre-block as long as there are idle node resources, effectively improving the resource utilization rate of the target blockchain node (such as the efficient utilization of CPU and network resources) and data throughput. Further, when the target blockchain node obtains the proposal authority of the blockchain, the target blockchain node can assemble a pre-proposal based on the pre-block and broadcast the pre-proposal to the blockchain network for consensus processing, and after successful consensus, generate a corresponding target block and chain it. Considering that the pre-block has been generated and broadcast in advance, there is no need to generate and broadcast the pre-block when assembling the pre-proposal, which can effectively reduce the time required for assembling the pre-proposal and improve the generation efficiency of the pre-proposal; moreover, the pre-proposal does not need to include the transaction data in the pre-block, so stripping this transaction data from the pre-proposal can greatly reduce the data volume of the pre-proposal, and thus the digital signature, broadcast, and consensus of the pre-proposal are all faster.

[0147] The above has elaborated in detail the blockchain-based data processing method of the embodiments of the present application. To facilitate better implementation of the above solutions of the embodiments of the present application, correspondingly, the devices of the embodiments of the present application are provided below. In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the function of that module or unit.

[0148] Figure 9 The structural schematic diagram of a blockchain-based data processing device provided by an exemplary embodiment of the present application is shown; this data processing device can be a computer program (including program code) running in a blockchain node device; this data processing device can be used to execute Figure 3 or Figure 8 Some or all of the steps in the method embodiment shown. Please refer to Figure 9 , this data processing device includes:

[0149] A processing unit 901, configured to use idle node resources to package unblocked transaction data to generate a pre-block, and broadcast the pre-block to the blockchain network where the blockchain is located;

[0150] The processing unit 901 is further configured to, after obtaining the proposal permission of the blockchain, perform an assembly process on the pre-block to generate a pre-proposal; the pre-proposal includes the first block hash of the target block corresponding to the pre-block; the target block is a block composed of the transaction data in the pre-block;

[0151] A consensus unit 902, configured to broadcast the pre-proposal to the blockchain network for consensus processing;

[0152] The processing unit 901 is further configured to, after the blockchain network successfully reaches a consensus on the pre-proposal, generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block; and,

[0153] The processing unit 901 is further configured to upload the target block to the blockchain.

[0154] In one implementation, when the processing unit 901 is configured to perform an assembly process on the pre-block to generate a pre-proposal, it is specifically configured to:

[0155] Construct a Merkle tree based on the transaction data in the pre-block to obtain the root hash of the Merkle tree; and,

[0156] Calculate the first block hash of the target block corresponding to the pre-block based on the root hash of the Merkle tree and the block height information of the blockchain;

[0157] Perform duplicate verification processing on the transaction data in the pre-block to obtain a duplicate verification result;

[0158] Generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result;

[0159] Digitally sign the initial pre-proposal using the private key of the target blockchain node to generate a pre-proposal.

[0160] In one implementation, when the processing unit 901 is used to generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result, it is specifically used for:

[0161] Fill the root hash of the Merkle tree and the first block hash of the target block into the initial pre-proposal; and,

[0162] If the duplicate verification result indicates that the transaction data in the pre-block was included in a block in historical time, mark the transaction data in the pre-block in the duplicate transaction list; the transaction data marked in the duplicate transaction list will not be executed by the virtual machine in the blockchain network;

[0163] Fill the duplicate transaction list marked with the transaction data in the pre-block into the initial pre-proposal.

[0164] In one implementation, the number of transaction data in the pre-block is at least two; if at least one of the at least two transaction data was included in a block in historical time, when the processing unit 901 is used to mark the transaction data in the pre-block in the duplicate transaction list, it is specifically used for:

[0165] Mark at least one of the transaction data in the pre-block that was included in a block in historical time in the duplicate transaction list.

[0166] In one implementation, when the processing unit 901 is used to generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block, it is specifically used for:

[0167] Calculate the second block hash of the target block including the transaction data in the pre-block based on the transaction data in the pre-block and the block height information of the blockchain; if the first block hash and the second block hash are the same, detect whether the duplicate transaction list in the pre-proposal is empty;

[0168] If it is not empty, delete the transaction data marked by the duplicate transaction list from the transaction data in the pre-block, and generate a target block based on the target block hash and the remaining transaction data in the pre-block except the deleted transaction data; the target block hash is the first block hash or the second block hash.

[0169] In one implementation, the processing unit 901 is further configured to:

[0170] If the duplicate transaction list in the pre-proposal is empty, when the first block hash is the same as the second block hash, generate a target block based on the target block hash and the transaction data in the pre-block.

[0171] In one implementation, the pre-block includes a transaction list, and the transaction list includes transaction data; the sources of the transaction data in the transaction list include at least one of the following: the client and other blockchain nodes in the blockchain network; the number of unblocked transaction data is N, and N is a positive integer; when the processing unit 901 uses idle node resources to package the unblocked transaction data to generate a pre-block, it is specifically configured to:

[0172] Use idle node resources to perform parallel packaging processing on N transaction data to generate M pre-blocks; M is a positive integer less than or equal to N.

[0173] In one implementation, when N transaction data are packaged into M pre-blocks, the processing unit 901 is further configured to:

[0174] Select the pre-block to be proposed from the M pre-blocks according to the data selection strategy;

[0175] Wherein, the data selection strategy includes any one of the following: select in the order of the generation timestamps of the pre-blocks from earliest to latest; or, select in the order of the data priorities of the transaction data in the pre-blocks from highest to lowest; or, select the pre-block including the transaction data of the specified data type from the M pre-blocks according to the data types of the transaction data in the pre-blocks.

[0176] In one implementation, the process of the target blockchain node in the blockchain network for packaging and broadcasting the pre-block is parallel to the consensus process for the reference pre-proposal; the reference pre-proposal is generated by the target blockchain node based on the pre-block, or sent to the target blockchain node by other blockchain nodes in the blockchain network.

[0177] According to an embodiment of the present application, Figure 9Each unit in the data processing device shown can be separately or wholly combined into one or several other units to form, or some of them can be further split into multiple smaller units with smaller functions to form, which can achieve the same operations without affecting the realization of the technical effects of the embodiments of this application. The above units are divided based on logical functions. In practical applications, the function of one unit can also be realized by multiple units, or the functions of multiple units can be realized by one unit. In other embodiments of this application, the data processing device can also include other units. In practical applications, these functions can also be assisted by other units and can be realized by the cooperation of multiple units. According to another embodiment of this application, it can be achieved by running a computer program (including program code) capable of executing the respective steps involved in the corresponding method shown in Figure 3 or Figure 8 on a general computing device such as a computer including processing elements and storage elements such as a central processing unit (CPU), a random access storage medium (RAM), and a read-only storage medium (ROM), to construct a data processing device as shown in Figure 9 and to implement the data processing method of the embodiments of this application. The computer program can be recorded on a computer-readable recording medium, for example, and loaded into the above computing device through the computer-readable recording medium and run therein.

[0178] In the embodiments of this application, when there are idle node resources in the target blockchain node (such as a blockchain node with consensus permission) in the blockchain network, the target blockchain node can independently package the unblocked transaction data to generate a pre-block and broadcast the pre-block in the blockchain network; since the pre-blockchain does not need to include the hash value of the previous block in the blockchain, the target blockchain node can execute the generation and broadcast of the pre-block as long as there are idle node resources, effectively improving the resource utilization rate of the target blockchain node (such as the efficient utilization of CPU and network resources) and the data throughput. Further, when the target blockchain node obtains the proposal permission of the blockchain, the target blockchain node can assemble a pre-proposal based on the pre-block and broadcast the pre-proposal to the blockchain network for consensus processing, and after the consensus is successful, generate the corresponding target block and upload it to the chain. Considering that the pre-block has been pre-generated and broadcast, there is no need to generate and broadcast the pre-block when assembling the pre-proposal, which can effectively reduce the time required for assembling the pre-proposal and improve the generation efficiency of the pre-proposal; moreover, the pre-proposal does not need to include the transaction data in the pre-block, so stripping the transaction data from the pre-proposal can greatly reduce the data volume of the pre-proposal, and thus the digital signature, broadcast, and consensus of the pre-proposal are all faster.

[0179] Figure 10 shows a schematic structural diagram of a blockchain node device provided by an exemplary embodiment of this application. Please refer toFigure 10 The blockchain node device includes a processor 1001, a communication interface 1002, and a computer-readable storage medium 1003. Among them, the processor 1001, the communication interface 1002, and the computer-readable storage medium 1003 can be connected through a bus or other means. Among them, the communication interface 1002 is used to receive and send data. The computer-readable storage medium 1003 can be stored in the memory of the blockchain node device. The computer-readable storage medium 1003 is used to store a computer program, and the computer program includes program instructions. The processor 1001 is used to execute the program instructions stored in the computer-readable storage medium 1003. The processor 1001 (or CPU (Central Processing Unit)) is the computing core and control core of the blockchain node device, which is suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to implement the corresponding method flow or corresponding function.

[0180] The embodiment of the present application also provides a computer-readable storage medium (Memory). The computer-readable storage medium is a memory device in the blockchain node device, which is used to store programs and data. It can be understood that the computer-readable storage medium here can include both the built-in storage medium in the blockchain node device, and of course, it can also include the extended storage medium supported by the blockchain node device. The computer-readable storage medium provides a storage space, and this storage space stores the processing system of the blockchain node device. And, one or more instructions suitable for being loaded and executed by the processor 1001 are also stored in this storage space. These instructions can be one or more computer programs (including program codes). It should be noted that the computer-readable storage medium here can be a high-speed RAM memory, or a non-volatile memory, such as at least one disk memory; optionally, it can also be at least one computer-readable storage medium located far from the aforementioned processor.

[0181] In one embodiment, the blockchain node device can be the target blockchain node mentioned in the foregoing embodiment; one or more instructions are stored in the computer-readable storage medium; the processor 1001 loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the data processing method embodiment above; one or more instructions in the computer-readable storage medium are loaded and executed by the processor 1001 as follows:

[0182] Use idle node resources to package unblocked transaction data to generate a pre-block, and broadcast the pre-block to the blockchain network where the blockchain is located;

[0183] After obtaining the proposal permission for the blockchain, the pre-block is assembled to generate a pre-proposal; the pre-proposal includes the first block hash of the target block corresponding to the pre-block; the target block is a block composed of the transaction data in the pre-block;

[0184] Broadcast the pre-proposal to the blockchain network for consensus processing;

[0185] After the blockchain network reaches a successful consensus on the pre-proposal, based on the first block hash in the pre-proposal and the transaction data in the pre-block, generate the target block; and,

[0186] Upload the target block to the blockchain.

[0187] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and execute the assembly process of the pre-block to generate a pre-proposal, the following steps are specifically executed:

[0188] Construct a Merkle tree based on the transaction data in the pre-block to obtain the root hash of the Merkle tree; and,

[0189] Based on the root hash of the Merkle tree and the block height information of the blockchain, calculate the first block hash of the target block corresponding to the pre-block;

[0190] Perform duplicate verification processing on the transaction data in the pre-block to obtain a duplicate verification result;

[0191] Generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result;

[0192] Use the private key of the target blockchain node to digitally sign the initial pre-proposal to generate a pre-proposal.

[0193] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and execute to generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result, the following steps are specifically executed:

[0194] Fill the root hash of the Merkle tree and the first block hash of the target block into the initial pre-proposal; and,

[0195] If the duplicate verification result indicates that the transaction data in the pre-block was included in a block at a historical time, mark the transaction data in the pre-block in the duplicate transaction list; the transaction data marked in the duplicate transaction list will not be executed by the virtual machine in the blockchain network;

[0196] Fill the duplicate transaction list marked with the transaction data in the pre-block into the initial pre-proposal.

[0197] In one implementation, the number of transaction data in the pre-block is at least two; if at least one of the at least two transaction data has been included in a block at a historical time, when one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and executed to mark the transaction data in the pre-block in the duplicate transaction list, the following steps are specifically executed:

[0198] Mark at least one transaction data in the pre-block that has been included in a block at a historical time in the duplicate transaction list.

[0199] In one implementation, when one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and executed to generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block, the following steps are specifically executed:

[0200] Calculate a second block hash of the target block including the transaction data in the pre-block based on the transaction data in the pre-block and the block height information of the blockchain; if the first block hash is the same as the second block hash, detect whether the duplicate transaction list in the pre-proposal is empty;

[0201] If it is not empty, delete the transaction data marked by the duplicate transaction list from the transaction data in the pre-block, and generate a target block based on the target block hash and the remaining transaction data in the pre-block except the deleted transaction data; the target block hash is the first block hash or the second block hash.

[0202] In one implementation, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and the following steps are further executed:

[0203] If the duplicate transaction list in the pre-proposal is empty, when the first block hash is the same as the second block hash, generate a target block based on the target block hash and the transaction data in the pre-block.

[0204] In one implementation, the pre-block includes a transaction list, and the transaction list includes transaction data; the sources of the transaction data in the transaction list include at least one of the following: a client and other blockchain nodes in the blockchain network; the number of un-included transaction data is N, and N is a positive integer; when one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and executed to pack the un-included transaction data using idle node resources to generate a pre-block, the following steps are specifically executed:

[0205] Use idle node resources to perform a parallel packing process on N transaction data to generate M pre-blocks; M is a positive integer less than or equal to N.

[0206] In one implementation, when N transaction data are packed into M of the pre-blocks, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and further perform the following steps:

[0207] Select a pre-block to be proposed from the M pre-blocks according to a data selection strategy;

[0208] Wherein, the data selection strategy includes any one of the following: select in the order of the generation timestamps of the pre-blocks from earliest to latest; or, select in the order of the data priorities of the transaction data in the pre-blocks from highest to lowest; or, select from the M pre-blocks the pre-blocks including transaction data of a specified data type according to the data types of the transaction data in the pre-blocks.

[0209] In one implementation, the process of packing and broadcasting the pre-block by the target blockchain node in the blockchain network is parallel to the consensus process for the reference pre-proposal; the reference pre-proposal is generated by the target blockchain node based on the pre-block, or sent to the target blockchain node by other blockchain nodes in the blockchain network.

[0210] In the embodiments of the present application, when there are idle node resources in the target blockchain node (such as a blockchain node with consensus authority) in the blockchain network, the target blockchain node can itself pack the unblocked transaction data to generate a pre-block and broadcast the pre-block in the blockchain network; since the pre-blockchain does not need to include the hash value of the previous block in the blockchain, the target blockchain node can execute the generation and broadcast of the pre-block as long as there are idle node resources, effectively improving the resource utilization rate of the target blockchain node (such as the efficient utilization of CPU and network resources) and data throughput. Further, when the target blockchain node obtains the proposal authority of the blockchain, the target blockchain node can assemble a pre-proposal based on the pre-block and broadcast the pre-proposal to the blockchain network for consensus processing, and after successful consensus, generate a corresponding target block and chain it. Considering that the pre-block has been pre-generated and broadcast, there is no need to generate and broadcast the pre-block when assembling the pre-proposal, which can effectively reduce the time required for assembling the pre-proposal and improve the generation efficiency of the pre-proposal; moreover, the pre-proposal does not need to include the transaction data in the pre-block, so stripping the transaction data from the pre-proposal can greatly reduce the data volume of the pre-proposal, thereby making the digital signature, broadcast, and consensus for the pre-proposal faster.

[0211] The embodiments of the present application also provide a computer program product or a computer program, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the blockchain node device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the blockchain node device executes the above-mentioned blockchain-based data processing method.

[0212] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this application can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0213] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of this application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0214] The foregoing is only the specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application, and all of them should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

1. A data processing method based on blockchain, characterized in that, Including: Utilize idle node resources to package unblocked transaction data to generate a pre-block, and broadcast the pre-block to the blockchain network where the blockchain is located; After obtaining the proposal permission of the blockchain, perform assembly processing on the pre-block to generate a pre-proposal; The pre-proposal includes the first block hash of the target block corresponding to the pre-block; The target block is a block composed of the transaction data in the pre-block; Broadcast the pre-proposal to the blockchain network for consensus processing; After the blockchain network reaches a successful consensus on the pre-proposal, generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block; And, Chain the target block to the blockchain.

2. The method according to claim 1, characterized in that, The performing assembly processing on the pre-block to generate a pre-proposal includes: Construct a Merkle tree based on the transaction data in the pre-block to obtain the root hash of the Merkle tree; and, Calculate the first block hash of the target block corresponding to the pre-block based on the root hash of the Merkle tree and the block height information of the blockchain; Perform duplicate verification processing on the transaction data in the pre-block to obtain a duplicate verification result; Generate an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result; Use the private key of the target blockchain node to digitally sign the initial pre-proposal to generate a pre-proposal.

3. The method according to claim 2, characterized in that, The generating an initial pre-proposal based on the root hash of the Merkle tree, the first block hash of the target block, and the duplicate verification result includes: Fill the root hash of the Merkle tree and the first block hash of the target block into the initial pre-proposal; and, If the duplicate verification result indicates that the transaction data in the pre-block has been blocked in historical time, mark the transaction data in the pre-block in the duplicate transaction list; the transaction data marked in the duplicate transaction list will not be executed by the virtual machine in the blockchain network; Fill the duplicate transaction list marked with the transaction data in the pre-block into the initial pre-proposal.

4. The method according to claim 3, wherein The number of transaction data in the pre-block is at least two; if at least one of the at least two transaction data has been blocked in historical time, the marking the transaction data in the pre-block in the duplicate transaction list includes: Mark at least one transaction data in the pre-block that has been blocked in historical time in the duplicate transaction list.

5. The method according to claim 1 or 3, characterized in that, The generating a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block includes: Calculate the second block hash of the target block including the transaction data in the pre-block based on the transaction data in the pre-block and the block height information of the blockchain; if the first block hash is the same as the second block hash, detect whether the duplicate transaction list in the pre-proposal is empty; If it is not empty, delete the transaction data marked by the duplicate transaction list from the transaction data in the pre-block, and generate a target block based on the target block hash and the remaining transaction data in the pre-block except the deleted transaction data; the target block hash is the first block hash or the second block hash.

6. The method according to claim 5, characterized in that, The method further includes: If the duplicate transaction list in the pre-proposal is empty, when the first block hash is the same as the second block hash, generate a target block based on the target block hash and the transaction data in the pre-block.

7. The method according to claim 1, wherein The pre-block includes a transaction list, and the transaction list includes transaction data; the sources of the transaction data in the transaction list include at least one of the following: a client and other blockchain nodes in the blockchain network; The number of unblocked transaction data is N, and N is a positive integer; The step of using idle node resources to package unblocked transaction data to generate a pre-block includes: Using idle node resources, parallelly package N transaction data to generate M pre-blocks; M is a positive integer less than or equal to N.

8. The method according to claim 7, characterized in that, When the N transaction data are packaged into M pre-blocks, the method further includes: Select a pre-block to be proposed from the M pre-blocks according to a data selection strategy; Wherein, the data selection strategy includes any one of the following: select in the order of the generation timestamps of the pre-blocks from earliest to latest; or, select in the order of the data priorities of the transaction data in the pre-blocks from highest to lowest; or, select a pre-block including transaction data of a specified data type from the M pre-blocks according to the data types of the transaction data in the pre-blocks.

9. The method according to claim 1, wherein The process of the target blockchain node in the blockchain network for packaging and broadcasting the pre-block is parallel to the consensus process for the reference pre-proposal; the reference pre-proposal is generated by the target blockchain node based on the pre-block, or sent to the target blockchain node by other blockchain nodes in the blockchain network.

10. A data processing device based on a blockchain, characterized in that, It includes: A processing unit, configured to use idle node resources to package unblocked transaction data to generate a pre-block, and broadcast the pre-block to the blockchain network where the blockchain is located; The processing unit is further configured to, after obtaining the proposal right of the blockchain, perform an assembly process on the pre-block to generate a pre-proposal; the pre-proposal includes the first block hash of the target block corresponding to the pre-block; The target block is a block composed of the transaction data in the pre-block; A consensus unit, configured to broadcast the pre-proposal to the blockchain network for consensus processing; The processing unit is further configured to, after the blockchain network successfully reaches a consensus on the pre-proposal, generate a target block based on the first block hash in the pre-proposal and the transaction data in the pre-block; and, The processing unit is further configured to upload the target block to the blockchain.

11. A blockchain node device, characterized in that, It includes: A processor, adapted to execute a computer program; A computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by the processor, the method according to any one of claims 1-9 is implemented.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the computer program is adapted to be loaded and executed by a processor to perform the method according to any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the method according to any one of claims 1-9.

Images