CN111556115B

CN111556115B - Block chain-based data processing method, device, equipment and storage medium

Info

Publication number: CN111556115B
Application number: CN202010322029.7A
Authority: CN
Inventors: 刘攀; 李茂材; 王宗友; 蓝虎; 周开班; 杨常青; 朱耿良; 黄焕坤; 时一防; 孔利
Original assignee: Tenpay Payment Technology Co Ltd
Current assignee: Tenpay Payment Technology Co Ltd
Priority date: 2020-04-22
Filing date: 2020-04-22
Publication date: 2023-04-21
Anticipated expiration: 2040-04-22
Also published as: CN111556115A

Abstract

The embodiment of the application discloses a data processing method, a device, equipment and a readable storage medium based on a blockchain, wherein the method comprises the following steps: the first node generates a first block; the first node obtains a local transaction execution result which is generated locally and aims at a history block; the block height of the first block is greater than the block height of the history block; the first node determines a target transaction execution result from the local transaction execution result, broadcasts the first block and the target transaction execution result to at least two second nodes, so that the at least two second nodes perform sequencing consensus on the first block and perform transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing; when the target block is identified through the transaction execution result, the first node stores the target block and the target transaction execution result in association with each other in the blockchain. By adopting the method and the device, the generation of the block can be efficiently advanced, and the consensus speed is improved.

Description

Block chain-based data processing method, device, equipment and storage medium

Technical Field

The present disclosure relates to the field of internet technologies, and in particular, to a data processing method, apparatus, device and readable storage medium based on a blockchain.

Background

With the rapid development of network technology and the importance of enterprises on data security, blockchains are greatly emphasized and applied. Blockchain is a new application model of computer technology, which is essentially a decentralised database, and is a string of data blocks (i.e. blocks) which are generated by using a cryptography method, wherein each data block contains a batch of network transaction data for verifying the validity (anti-counterfeiting) of the data and generating the next block, so as to generate a non-tamperable data chain.

When the consensus node newly generates a block, the block needs to be broadcasted to other consensus nodes, so that the new block is consensus. In the prior art, the consensus stage comprises two parts of sequencing and transaction execution, wherein the two parts are executed in series, namely after the sequencing of the block n is completed by a consensus node, the sequenced transaction execution result of the block n needs to be continuously generated, and then the sequenced block n and the sequenced transaction execution result of the block n are subjected to voting consensus together through other consensus nodes. If other consensus nodes are to vote, the other consensus nodes also generate the transaction execution result of the block n. However, the processing speeds of different consensus nodes are inconsistent, so that in order to complete the consensus of the block n, it takes time to wait for other consensus nodes to generate the transaction execution result of the block n together, and after the block n passes the consensus, the consensus network generates and broadcasts the block of the next height. It can be seen that if the speed of generating the transaction execution result by the consensus node is slow, the time interval for generating the next block is also long, so that it is difficult to efficiently advance the generation of the block, and the consensus speed is reduced.

Disclosure of Invention

The embodiment of the application provides a data processing method, device and equipment based on a block chain and a readable storage medium, which can efficiently promote the generation of blocks and improve the consensus speed.

An aspect of an embodiment of the present application provides a data processing method based on a blockchain, including:

the first node generates a first block;

the first node obtains a locally generated local transaction execution result aiming at the history block; the block height of the first block is greater than the block height of the history block;

the first node determines a target transaction execution result from the local transaction execution results, and broadcasts the first block and the target transaction execution result to at least two second nodes so that the at least two second nodes perform sequencing consensus on the first block and perform transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing;

when the target block is identified by the transaction execution result, the first node stores the target block and the target transaction execution result in association with each other in a blockchain.

the second node acquires a first block broadcasted by the first node and a target transaction execution result; the first block and the target transaction execution result are both generated by the first node;

the second node performs sequencing consensus on the first block;

the second node performs transaction execution result consensus on the target block according to the target transaction execution result; the target block is a block corresponding to the target transaction execution result, the block height of the first block is larger than the block height of the target block, and the target block is a block which is commonly known through sequencing;

when the target block is identified by the transaction execution result and the second node has generated the transaction execution result of the target block, the second node stores the target block and the transaction execution result of the target block generated by the second node in association with each other in a blockchain.

An aspect of an embodiment of the present application provides a data processing apparatus based on a blockchain, including:

the generation block module is used for generating a first block;

The local result acquisition module is used for acquiring a local transaction execution result which is generated locally and aims at the history block; the block height of the first block is greater than the block height of the history block;

a broadcast block result module, configured to determine a target transaction execution result from the local transaction execution results, broadcast the first block and the target transaction execution result to at least two second nodes, so that the at least two second nodes perform sequencing consensus on the first block, and perform transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing;

and the first storage block result module is used for storing the target block and the target transaction execution result in a block chain in a correlated way when the target block is identified through the transaction execution result.

Wherein, the generating block module includes:

the data acquisition unit is used for acquiring the second block and transaction data; the second block is generated by a target node of the at least two second nodes;

a sequencing data unit for sequencing the transaction data and generating a block hash parameter according to the second block and the sequenced transaction data;

A block generation unit configured to generate the first block based on the block hash parameter and the sequenced transaction data; the second block is a preceding block of the first block.

Wherein, the broadcast block result module includes:

a broadcast result determining unit, configured to determine a broadcast transaction execution result in the local transaction execution results according to the transaction execution results broadcast by the at least two second nodes;

a target determination unit configured to determine, as a target transaction execution result, a transaction execution result other than the broadcasted transaction execution result among the local transaction execution results; the block height of the target block is larger than the block height corresponding to the broadcasted transaction execution result.

Wherein, the broadcast block result module further comprises:

the generation credential unit is used for generating a merck tree root credential according to the local transaction execution result;

a broadcast result voucher unit, configured to broadcast the first block, the target transaction execution result, and the merck root voucher to the at least two second nodes; the merck root certificate is used for the at least two second nodes to carry out transaction execution result consensus on the target block.

Wherein, the first storage block result module includes:

the voting result obtaining unit is used for obtaining transaction execution voting results respectively sent by the at least two second nodes; the transaction execution voting result is a voting result obtained by carrying out transaction execution result consensus on the target block;

a consensus result determining unit, configured to determine a consensus result of the transaction execution result for the target block according to the transaction execution voting result;

and the block storage result unit is used for storing the target block and the target transaction execution result in association in the block chain when the consensus result of the transaction execution result of the target block is a consensus passing result.

Wherein the determining consensus result unit includes:

a statistics voting passing subunit, configured to count, among the transaction execution voting results, the number of transaction execution voting results that belong to the voting passing as the passing voting number;

a consensus result determination subunit, configured to determine, when the number of passing votes is equal to or greater than a consensus passing threshold, that a consensus result of the transaction execution result of the target block is a consensus passing result;

The sub-unit for determining the consensus result is further configured to determine that the consensus result of the transaction execution result of the target block is a consensus failure result when the passing number of votes is smaller than a consensus passing threshold.

the block result acquisition module is used for acquiring a first block broadcasted by the first node and a target transaction execution result; the first block and the target transaction execution result are both generated by the first node;

a sequencing consensus block module for sequencing consensus of the first block;

the consensus target result module is used for consensus the transaction execution result of the target block according to the target transaction execution result; the target block is a block corresponding to the target transaction execution result, the block height of the first block is larger than the block height of the target block, and the target block is a block which is commonly known through sequencing;

and the second storage block result module is used for storing the target block and the transaction execution result of the target block generated by the second node in a block chain in a correlated way when the target block is identified through the transaction execution result and the second node has generated the transaction execution result of the target block.

Wherein the sequencing consensus block module comprises:

the block hash value obtaining unit is used for obtaining the hash value of the merck tree root and the transaction data in the first block;

generating a root to be verified unit, which is used for generating a merck tree root to be verified according to the hash value of the transaction data in the first block;

a verification data legal unit, configured to verify the validity of the transaction data in the first block when the merck tree root in the first block is the same as the merck tree root to be verified;

a broadcast sequencing-by-result unit configured to broadcast a sequencing-by-vote result for the first block to at least two consensus nodes when the transaction data in the first block is legal data; the at least two consensus nodes include the first node;

and the sequencing voting result acquisition unit is used for acquiring sequencing voting results aiming at the first block and sent by the at least two consensus nodes, and determining the sequencing consensus result of the first block according to the acquired sequencing voting results and the locally generated sequencing passing voting results.

Wherein the sequencing consensus block module further comprises:

The transaction data acquisition unit is used for acquiring transaction data when the first block is subjected to sequencing consensus;

a block hash parameter generating unit for sequencing the transaction data and generating a block hash parameter of a second block according to the first block and the sequenced transaction data;

generating a second chunk unit for generating said second chunk from said second chunk's chunk hash parameters and said sequenced transaction data; the first block is a preceding block of the second block.

Wherein, the consensus target result module comprises:

the broadcast credential obtaining unit is used for obtaining the merck tree root credential broadcasted by the first node; the merck root certificate is a certificate generated according to a transaction execution result generated by the first node; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the transaction execution results generated by the first node;

the local transaction result obtaining unit is used for obtaining a local generated local transaction execution result aiming at the history block; the block height of the first block is greater than the block height of the history block;

The verification unit is used for generating a verification merck tree root voucher according to the local transaction execution result and the target transaction execution result;

and the consensus block transaction result unit is used for carrying out transaction execution result consensus on the target block according to the merck tree root certificate to be verified and the merck tree root certificate.

Wherein the generating the to-be-verified credential unit includes:

an obtaining block Gao Duzi unit, configured to obtain a highest block height in the blocks corresponding to the local transaction execution result;

and generating a to-be-verified certificate subunit, configured to generate the to-be-verified merck root certificate according to the local transaction execution result and the target transaction execution result if the highest block height is smaller than the block height of the target block.

Wherein, the consensus block transaction result unit comprises:

a broadcast transaction passing result subunit, configured to broadcast a transaction execution passing voting result for the target block to the at least two consensus nodes when the merck root certificate to be verified and the merck root certificate are the same; the transaction execution characterizes the second node by voting results to be consensus of the transaction execution results aiming at the target block;

A sub-unit for obtaining transaction voting results, which is used for obtaining transaction execution voting results aiming at the target block and sent by the at least two consensus nodes;

and the transaction identification determination subunit is used for determining the transaction execution identification result of the target block according to the obtained transaction execution voting result and the locally generated transaction execution passing voting result.

In one aspect, the present application provides a computer device comprising: a processor, a memory, a network interface;

the processor is connected to the memory and the network interface, where the network interface is used to provide a data communication function, the memory is used to store a computer program, and the processor is used to call the computer program to perform a method as in an embodiment of the present application.

An aspect of the present embodiments provides a computer readable storage medium storing a computer program comprising program instructions which, when executed by a processor, perform a method as in the embodiments of the present application.

In the embodiment of the present invention, after the first block is generated by the first node, the target transaction execution result is determined from the local transaction execution results for the history block, which are generated locally by the first node, and because the first node broadcasts the latest transaction execution result, that is, the target transaction execution result, while broadcasting the sequenced first block, at least two second nodes can not only sequence and agree with the first block, but also simultaneously agree with the transaction execution result of the target block (that is, the block corresponding to the target transaction execution result). As can be seen from the above, by performing asynchronous processing on the sequencing consensus and the transaction execution result consensus of the first node, that is, after the first node finishes sequencing the first block, the second node does not need to wait for the first node to output the transaction execution result of the first block, and can directly generate the next block on the basis of the first block, thereby efficiently promoting the generation of the block.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a system architecture according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a scenario of a blockchain-based data processing provided in an embodiment of the present application;

FIG. 3 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present disclosure;

FIG. 4a is a schematic diagram of a scenario of a blockchain-based data processing provided by an embodiment of the present application;

FIG. 4b is a schematic diagram of a scenario of a blockchain-based data processing provided by an embodiment of the present application;

FIG. 5 is a schematic diagram of a scenario of a blockchain-based data processing provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of a scenario of a blockchain-based data processing provided by an embodiment of the present application;

FIG. 7 is a schematic diagram of a scenario of a blockchain-based data processing provided by an embodiment of the present application;

FIG. 8 is a flowchart of a data processing method based on a blockchain according to an embodiment of the present disclosure;

FIG. 9 is a schematic diagram of a block chain based data processing apparatus according to an embodiment of the present application;

FIG. 10 is a block chain based data processing apparatus according to an embodiment of the present application;

FIG. 11 is a schematic structural diagram of a computer device according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

Please refer to fig. 1, which is a schematic diagram of a system architecture according to an embodiment of the present application. With the rapid development of network technology and the importance of enterprises on data security, blockchains are greatly emphasized and applied. When the common node of the memory block chain generates a new block, the new block needs to be broadcasted to other common nodes to perform common recognition, as shown in fig. 1, the common node 101 is called a first node, the common node cluster 102 is called at least two second nodes, and the common node cluster 102 may include the common node 1021, the common nodes 1022, …, and the common node 1023, where the common node 101 and the common node cluster 102 belong to the same common network. Each consensus node (including consensus node 101 and consensus node cluster 102) may receive externally transmitted data during normal operation and perform block consensus based on the received data. In order to ensure data intercommunication among the consensus nodes, a data connection can exist among each consensus node, namely, the consensus node 101, the consensus nodes 1021, the consensus nodes 1022 and … and the consensus node 1023, and data or block transmission can be performed among the consensus nodes through the data connection. For example, when consensus node 101 obtains transaction data from a transaction pool, consensus node 101 packages the transaction data into chunks and broadcasts the chunks to consensus node cluster 102. The cluster of consensus nodes 102 performs consensus, verification, storage, etc. on the block according to a consensus algorithm such that the data (i.e., the block) stored on all of the consensus nodes may remain consistent.

For each of the consensus nodes of the memory blockchain, the node identifier corresponding to the node identifier is provided, and each of the consensus nodes can store the node identifiers of other consensus nodes connected with the node identifier, so that the generated block or data can be broadcast to the other consensus nodes according to the node identifiers of the other consensus nodes, for example, the node identifier list shown in table 1 can be maintained in the consensus node 101, and the node identifier list stores the node names and the node identifiers of the consensus nodes in the consensus node cluster 102.

TABLE 1

Node name	Node identification
		Consensus node
1021	117.114.151.174
		Consensus node 1022	117.116.189.145
…	…
		Consensus node 1023	119.123.789.258

The node identifier may be a protocol (Internet Protocol, IP) address of the interconnection between networks, and any other information that can be used to identify the node in common, and table 1 is only illustrated by taking an IP address as an example.

Further, for ease of understanding, the following description is made of partial nouns:

1. blockchain: in a narrow sense, the blockchain is a chain data structure taking a block as a basic unit, and the block uses a digital abstract to verify the previous transaction history, so that the requirements of tamper resistance and expandability in a distributed billing scene are met; in a broad sense, blockchain also refers to distributed accounting techniques implemented by blockchain structures, including distributed consensus, privacy and security protection, point-to-point communication techniques, network protocols, smart contracts, and the like. The goal of the blockchain is to implement a distributed data logging ledger that allows only additions and not deletions. The basic structure of the ledger floor is a linear linked list. The linked list is formed by serially connecting blocks, the Hash value of the preceding block is recorded in the following blocks, and whether each block (and the transaction in the block) is legal or not can be rapidly checked by calculating the Hash value. If a node in the network proposes to add a new block, it must be acknowledged by the consensus mechanism.

2. Block (Block): all transaction data, state results and the like occurring within a period of time are recorded and are a consensus of the current ledger state. Specifically, for blockchains, each time transaction data is written, the transaction process described above, creates a block.

3. Chain (Chain): the system is formed by serially connecting blocks according to the occurrence sequence, and is a log record of the state change of the whole account book.

4. Consensus mechanism: the verification and confirmation of transaction data is completed in a short time by voting of special nodes, and the goal is to make all core nodes store a consistent block chain diagram, which is an algorithm for achieving distributed consensus, such as Proof of Work (POW), proof of equity mechanism (PoS), and bayer consensus algorithm (Practical Byzantine Fault Tolerance, PBFT).

Referring to fig. 1 again, when the consensus node 101 obtains part of the transaction data in the transaction pool, the transaction data is sequenced first, and then a first block is generated according to the sequenced transaction data, and the sequence of the transaction data in the first block is the sequencing result. At this time, after the sequencing is completed, the consensus node 101 may propagate the first block to the consensus node cluster 102, so that the consensus node cluster 102 performs sequencing consensus on the first block, and it is not necessary for the consensus node 101 to wait until a transaction execution result of the first block is generated, but broadcast the first block. And, while broadcasting the first block, the consensus node 101 may also broadcast the latest transaction execution result for the history block (wherein the block height of the history block is lower than the block height of the first block, and the broadcasted latest transaction execution result is generated by the consensus node 101) to the consensus node cluster 102. For example, the first block generated by the consensus node 101 is block 5 (number 5 represents the block height, i.e. the block height is 5), and the consensus node 101 may only currently generate the transaction execution results corresponding to the blocks 1-3, if the block corresponding to the transaction execution result broadcasted in the current consensus network is block 1-block 2, the consensus node 101 may broadcast the transaction execution result corresponding to the locally generated block 3 to the consensus node cluster 102 together, so that the whole consensus network may not only sequence and consensus the block 5, but also consensus the transaction execution result of the block 3. It can be seen that the present application separates the process of sequencing and the process of generating the transaction execution results in an asynchronous manner, i.e., the module for sequencing execution is not associated with the module for generating the transaction execution results. Therefore, the block generated by sequencing will lead the execution result of the generated transaction, and the sequenced block is broadcasted in advance, so that sequencing consensus of the block can be completed in advance, thereby efficiently promoting the generation of the block and improving the consensus speed.

It is understood that the methods provided by embodiments of the present application may be performed by a computer device, including but not limited to a terminal or server. The consensus node in the embodiments of the present application may be a computer device.

The consensus node 101 and the consensus node cluster 102 formed by the consensus node 1021, the consensus nodes 1022, …, and the consensus node 1023 in fig. 1 may include a mobile phone, a tablet computer, a notebook computer, a palm computer, a smart phone, a mobile internet device (MID, mobile internet device), a POS (Point Of sale) machine, a wearable device (e.g., a smart watch, a smart bracelet, etc.), and so on.

Further, please refer to fig. 2, which is a schematic diagram of a scenario of a blockchain-based data processing according to an embodiment of the present application. As shown in FIG. 2, when the first node 10 obtains transaction data, the transaction data is sequenced to obtain sequenced transaction data 11, then a preceding block 128 is obtained in the buffer 13, and a first block 129 is generated according to the block header of the preceding block 128 and the sequenced transaction data 11. The above-mentioned buffer 13 includes blocks 125, …, a preceding block 128 and a first block 129, the blocks (including blocks 125, …, a preceding block 128 and a first block 129) in the buffer 13 are sequenced blocks, and other blocks except the newly generated first block 129 have completed sequencing consensus in the consensus network, that is, at least two second nodes associated with the first node 10 have respectively passed sequencing consensus on the blocks 125, … and the preceding block 128, but have not performed transaction execution result consensus in the consensus network, as shown in fig. 2, the first node has generated a transaction execution result 1251 corresponding to the block 125, and has not generated a local transaction execution result of a block (including the preceding block 128) after the block 125.

In fig. 2, blocks 121, … and 124 have not only completed sequencing consensus in the consensus network, but also completed transaction execution result consensus, that is, at least two second nodes associated with the first node 10 have respectively passed the transaction execution result consensus of the blocks 121, … and 124, so that blocks 121-124 can be written into the local ledger 12, wherein block 124 is a successor block of block 125, that is, block 124 is a parent block of block 125. The local transaction execution results of the first node 10 include transaction execution results 1211 and … corresponding to the block 121, transaction execution result 1241 corresponding to the block 124, and transaction execution result 1251 corresponding to the block 125 in the buffer 13 in the local ledger 12. Since the transaction execution results 1211, … corresponding to the block 121 and the transaction execution result 1241 corresponding to the block 124 are already broadcast in the consensus network, the transaction execution result 1251 corresponding to the block 125 is the target transaction execution result of the first node 10 (also the transaction execution result not yet broadcast in the consensus network).

In summary, after the first node 10 generates the first block 129, the first block 129 is broadcast to at least two second nodes, and the latest local transaction execution result (i.e. the transaction execution result 1251 in fig. 2) and the merck root certificate 14 are broadcast to at least two second nodes, where the merck root certificate 14 refers to the merck root formed by all the local transaction execution results (including the transaction execution results 1211, …, the transaction execution result 1241 and the transaction execution result 1251) of the first node 10, and the merck root certificate 14 is used for the at least two second nodes to agree the transaction execution result for the block corresponding to the target transaction execution result (i.e. the block 125).

Taking the second node 20 of the at least two second nodes as an example, as shown in fig. 2, in the local ledger 22 of the second node 20, blocks 121, … and 124 are included, where the block 121 in the local ledger 22 belonging to the second node 20 is completely consistent with the block 121 in the local ledger 12 belonging to the first node 10, and similarly, the block 124 in the local ledger 22 is completely consistent with the block 124 in the local ledger 12, and the rest of the blocks in the local ledger 22 are also completely consistent. The cache area 23 of the second node 20 includes blocks 125, … and a successor block 128, wherein the block 125 in the cache area 23 belonging to the second node 20 is completely identical to the block 125 in the cache area 13 belonging to the first node 10, and the same is true for the rest blocks in the cache area 23. When the first node 10 broadcasts the first block 129, the transaction execution result 1251 and the merck root certificate 14 to the second node 20, the second node 20 does not generate the transaction execution result corresponding to the block 125 yet, and the second node 20 locally generates the transaction execution results 1212 and … corresponding to the block 121 and the transaction execution result 1242 corresponding to the block 124, at this time, the second node 20 may not only sequence and agree the first block 129, but also may also perform the transaction execution result consensus on the block 125 corresponding to the target transaction execution result according to the merck root certificate 14 and the target transaction execution result in advance, which is specifically: the second node 20 generates the merck tree credential to be verified according to the local transaction execution result (including the transaction execution results 1212 and … and the transaction execution result 1242) and the target transaction execution result (i.e., the transaction execution result 1251), and performs the transaction execution result consensus on the block 125 according to the merck tree root credential to be verified and the merck tree root credential 14.

For the first node 10, since the sequencing consensus and the transaction execution result consensus can be performed asynchronously, the first node 10 can complete the sequencing consensus of the blocks 121 to 129 preferentially through the sequencing module, and meanwhile, the transaction execution result processing module can generate the transaction execution results of the blocks 121 to 129 asynchronously one by one, that is, the generation of the transaction execution results is not required to wait in the process of generating the blocks through the sequencing module, so that the generation of the blocks can be advanced efficiently, and the block consensus speed is improved.

In the embodiment of the present application, the first node 10 that generates the first block 129 and generates the transaction execution result for the block 125, and the second node 20 that receives the first block 129, the target transaction execution result and the merck root certificate 14 are described, and other common nodes may also perform block data processing in the embodiment of the present application.

Further, please refer to fig. 3, which is a flowchart illustrating a data processing method based on a blockchain according to an embodiment of the present application. As shown in fig. 3, the data processing procedure includes the steps of:

in step S101, a first block is generated.

Specifically, the first node acquires a second block and transaction data; the second block is generated by a target node of the at least two second nodes; the first node sequences the transaction data and generates a block hash parameter according to the second block and the sequenced transaction data; the first node generating the first block according to the block hash parameter and the sequenced transaction data; the second block is a preceding block of the first block.

Referring to fig. 2 again, assuming that a block 121 is an originating block in the local ledger 12 of the first node 10, the originating block includes a block header and a block body, the block header can store hash values, version numbers, time stamps, difficulty values, etc. of the acquired transaction data, and the block body stores the transaction data; the next block of the starting block takes the starting block as a father block, the next block also comprises a block head and a block body, the block head can store the hash value of the transaction data of the current block, the hash value of the block head of the father block, the version number, the timestamp, the difficulty value and the like, so that the block data stored in each block in the local account book 12 are associated with the block data stored in the father block, and the safety of the input information in the block is ensured.

After the first node 10 obtains the transaction data, sequencing the transaction data, that is, sequencing the transaction execution sequence of the transaction data in the first block 129, storing the sequenced transaction data 11 into a local memory pool, updating a hash tree for recording the transaction data, updating an update timestamp to the time of receiving the transaction data, trying different random numbers, performing hash value calculation on the sequenced transaction data 11 for a plurality of times, and generating a hash value corresponding to each transaction data and a merck tree root in a block header; the first node 10 then obtains the successor block 128, determines the chunk header hash value of the parent block of the first block 129 according to the successor block 128, and generates chunk hash parameters, which are parameters included in the chunk header of the first block 129, such as the chunk header hash value, the chunk header hash value of the parent block, the chunk height, the merker tree root, the chunk generation signature, the timestamp, and the like, according to the chunk header hash value of the parent block and the sequenced transaction data 11.

The first node 10 generates a block header and a block body according to the block hash parameter and the sequenced transaction data 11, obtains a first block 129, and stores the newly generated block 129 in the buffer 13, and at this time, the first node 10 completes sequencing consensus for the first block 129, and does not calculate a transaction execution result for each transaction data in the first block 129 yet.

Step S102, obtaining a local transaction execution result.

Specifically, the first node obtains a locally generated local transaction execution result aiming at the history block; the block height of the first block is greater than the block height of the history block.

Referring to fig. 2 again, as shown in fig. 2, the local ledger 12 of the first node 10 includes blocks 121, … and 124, the blocks 121, … and 124 are already commonly known in the common network by the transaction execution results, and the first node 10 has generated the transaction execution results corresponding to the blocks 121, … and 124, namely, the transaction execution results 1211, … and the transaction execution result 1251, respectively. The buffer 13 of the first node 10 includes blocks 125, …, a preceding block 128 and a first block 129, but the block for calculating the transaction execution result includes only block 125, i.e. transaction execution result 1251, so that the local transaction execution result of the first node 10 includes transaction execution results 1211, …, transaction execution result 1241 and transaction execution result 1251.

It should be noted that the first block 129 is generated by the first node 10, but the blocks in the local ledger 12 (including the blocks 121, … and 124) and the blocks in the buffer 13 (the blocks 125, … and the successor block 1028) are not necessarily generated by the first node 10, or only a small portion of the blocks are generated by the first node 10, and a large portion of the blocks are generated by the at least two second nodes associated with the first node 10, please refer to fig. 4a together, which is a schematic view of a scenario of a blockchain-based data processing provided in the embodiment of the present application. As shown in fig. 4a, the

consensus nodes

40, 30, …, the first node 10 and the second node 20 form a consensus node cluster, the consensus nodes in the consensus node cluster acquire transaction data from the transaction pool in turn according to a certain rule to package and generate blocks, and as shown in fig. 4a, the blocks 125 are generated by the consensus nodes 40, that is, after the consensus nodes 40 acquire the transaction data from the transaction pool, the consensus nodes themselves perform sequencing consensus on the transaction data, and specific sequencing consensus processes can refer to the sequencing consensus process of the first blocks 129 in the step S101, which is not repeated herein, and generate the blocks 125 after completing sequencing consensus on the transaction data, and the consensus nodes 40 send the newly generated blocks 125 (the transaction execution results of the blocks 125 which are not generated at this time) to the consensus nodes 30, …, the first nodes 10 and the second nodes 20 respectively according to the node identifiers of other consensus nodes (including the consensus nodes 30, the first nodes 10 and the second nodes 20). The consensus node 30 performs sequencing consensus on the block 125, and caches the block 125 in the cache after the sequencing consensus on the block 125 is performed and the sequencing passing consensus results for the block 125 sent by the first node 10, … and the second node 20 respectively are obtained; similarly, the first node 10 performs sequencing consensus on the block 125, and after sequencing consensus on the block 125 and obtaining sequencing passing consensus results sent by the consensus nodes 30 and … and the second node 20 respectively for the block 125, caches the block 125 in the cache region; the second node 20 performs the sequencing consensus on the block 125, and after the sequencing consensus on the block 125 is performed and the sequencing passing consensus results for the block 125, which are sent by the consensus nodes 30 and … and the first node 20, respectively, are obtained, the block 125 is cached in the cache.

Please refer to fig. 4b, which is a schematic diagram illustrating a scenario of a blockchain-based data processing according to an embodiment of the present application. As can be seen from the foregoing, the common node in the common node cluster acquires the transaction data from the transaction pool in turn according to a certain rule to package and generate the block, as shown in fig. 4b, according to the turn rule, the first node 10 acquires the transaction data from the transaction pool, generates the first block 129 according to the transaction data, and when the sequencing common identification of the first block 129 is completed, generates the transaction execution result (i.e. the transaction execution result 1251 in fig. 2) of the block 125 in the buffer area, so that the first block 129 is broadcast to the common node 40, the common nodes 30, …, and the second node 20, and simultaneously broadcasts the transaction execution result for the block 125 to the common node 40, the common nodes 30, …, and the second node 20, so that the common node 40, the common nodes 30, …, and the second node 20 perform the transaction execution result common identification on the block 125. The sequencing consensus process of the consensus node cluster for the block 129 may refer to the sequencing consensus process of the block 125 in the embodiment corresponding to fig. 4a, and will not be described herein. After the consensus node cluster performs consensus on the transaction execution result of the block 125, each consensus node stores the locally generated transaction execution result and the block 125 in a local ledger in an associated manner, that is, after the consensus node 40 performs consensus on the transaction execution result of the block 125, the locally generated transaction execution result 1254 for the block 125 and the block 125 in an associated manner are stored in the local ledger; after completing the consensus of the transaction execution result of the block 125, the consensus node 30 stores the locally generated transaction execution result 1253 for the block 125 and the block 125 association into a local ledger; after completing the consensus of the transaction execution results for block 125, consensus node 20 stores locally generated transaction execution results 1252 for block 125, as well as the association of block 125 to the local ledger, as are other consensus nodes in the consensus node cluster.

It should be noted that, in the embodiment of the present application, the steps S101 and S102 are not limited to the chronological order, and may occur first in the step S101, first in the step S102, or simultaneously in the step S101 and the step S102.

Step S103, determining a target transaction execution result.

Specifically, the first node determines a broadcasted transaction execution result in the local transaction execution results according to the transaction execution results broadcasted by the at least two second nodes; the first node determines a transaction execution result except the broadcasted transaction execution result in the local transaction execution results as a target transaction execution result; the block height of the target block is larger than the block height corresponding to the broadcasted transaction execution result.

Referring to fig. 2 again, as can be seen from step S102, the local transaction execution results of the first node 10 include the transaction execution results 1211, … in the local ledger 12, the transaction execution result 1241, and the transaction execution result 1251 in the buffer 13. Because the transaction execution results corresponding to block 121, …, and the transaction execution results corresponding to block 124 have been broadcast by at least two second nodes, it may be determined that the target transaction execution result is transaction execution result 1251 corresponding to block 125.

Step S104, broadcasting the first block and the target transaction execution result.

Specifically, the first node generates a merck tree root certificate according to the local transaction execution result; the first node broadcasts the first block, the target transaction execution result and the merck root certificate to the at least two second nodes; the merck root certificate is used for the at least two second nodes to carry out transaction execution result consensus on the target block.

From the foregoing, the consensus is divided into two parts, namely, a sequencing consensus and a transaction execution result consensus, the sequencing consensus is completed by the sequencing module, the transaction execution module completes the transaction execution result consensus, and because the sequencing module and the transaction execution module are independent, the sequencing consensus and the transaction execution result consensus are completed independently, and for the first node 10 (the first node 10 can be regarded as a block node at this time), the sequencing module can generate the first block 129, and the transaction execution module can generate the transaction execution result 1251. The first node 10 may immediately broadcast the first block 129 without waiting for the transaction execution result of the first block 129 to be generated, for example, the second node 20 of the at least two second nodes may be used as the second node 20, so that the second node 20 may directly generate the next block after obtaining the transaction data from the transaction pool based on the first block 129, without concern about the generation progress of the transaction execution result. Further, the first node 10 may send the newly generated first block 129 and the target transaction execution result to at least two second nodes according to the node identification of the other consensus nodes.

Step S105, sequence consensus is performed for the first block.

Specifically, the at least two second nodes acquire hash values of the merck tree root and the transaction data in the first block; the at least two second nodes generate merck tree roots to be verified according to the hash values of the transaction data in the first block; when the merck tree root in the first block is the same as the merck tree root to be verified, the at least two second nodes verify the validity of the transaction data in the first block; when the transaction data in the first block is legal data, the at least two second nodes broadcast sequencing passing voting results for the first block to at least two consensus nodes; the at least two second nodes acquire sequencing voting results sent by other nodes and aiming at the first block, and determine sequencing consensus results of the first block according to the acquired sequencing voting results and sequencing passing voting results generated locally, namely the at least two second nodes count the number of sequencing passing voting results and serve as passing voting numbers, and when the passing voting numbers are equal to or larger than a consensus passing threshold, the at least two second nodes determine that the sequencing consensus results of the first block are consensus passing results.

Taking the second node 20 of the at least two second nodes as an example, the sequence consensus process of the other consensus nodes for the first block 129 is the same as described below. Please refer to fig. 5, which is a schematic diagram of a scenario of a blockchain-based data processing according to an embodiment of the present application. As shown in fig. 5, the first node 10 broadcasts the merck root certificate 14, the target transaction execution result (i.e. the transaction execution result 1251), and the first block 129 to the second node 20, and after the second node 20 acquires the first block 129, the second node acquires sequenced transaction data from the block of the first block 129, where the sequenced transaction data includes data corresponding to n transactions, such as transaction data 1, transaction data 2, transaction data 3, …, and transaction data n, where n is a positive integer. According to the merck root generation method, the second node 20 generates a hash 1 according to the transaction data 1 and the transaction data 2, generates a hash 2 according to the transaction data 3 and the transaction data 4 until a hash m is generated according to the transaction data (n-1) and the transaction data n, further generates a hash according to the hash 1 and the hash 2, …, and further generates a hash (x-1) and a hash x until only one hash value is generated, wherein m is a positive integer, and m is n/2.

Then the second node 20 obtains the merck tree root 100a from the hash parameter in the block header of the first block 129, detects the consistency 100c of the merck tree root 100a and the merck tree root 100b to be verified, and when the merck tree root 100a in the first block 129 is different from the merck tree root 100b to be verified, the second node 20 can determine that the first block 129 has illegal parameters; when the merck root 100a in the first block 129 is the same as the merck root 100b to be verified, the second node 20 needs to further verify the validity of the sequenced transaction data in the first block 129, for example, the content of the transaction data 1 is "100 pieces of money in the account of the current XX, 10 pieces of money paid this time" and then the transaction data can be determined to be valid data, if the content of the transaction data 2 is "90 pieces of money in the account of the current XX, 100 pieces of money paid this time" and then the transaction data can be determined to be illegal data, and when the transaction data in the first block 129 are all legal data, the second node 20 recognizes through sequencing with respect to the first block 129.

Step S106, the transaction execution result consensus is carried out on the target block.

Specifically, the at least two second nodes acquire the merck tree root certificates broadcasted by the first node; the merck root certificate is a certificate generated according to a transaction execution result generated by the first node; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the transaction execution results generated by the first node; the at least two second nodes acquire a local transaction execution result which is generated locally and aims at the history block; the block height of the first block is greater than the block height of the history block; the at least two second nodes generate merck tree root certificates to be verified according to the local transaction execution result and the target transaction execution result; and the at least two second nodes perform transaction execution result consensus on the target block according to the merck tree root certificate to be verified and the merck tree root certificate.

Referring to fig. 6, a schematic diagram of a scenario of data processing based on a blockchain is provided in an embodiment of the present application. As shown in fig. 6, the first node 10 broadcasts the merck root voucher 14, the target transaction execution result 1251 and the first block 129 to the second node 20, after the second node 20 obtains the target transaction execution result 1251, it first obtains the generated local transaction execution result for the history block, where the local transaction execution result includes the transaction execution results 1212, … and the transaction execution result 1242 in the local ledger 22, and the buffer 23 includes the blocks 125, … and the preceding block 128, but the transaction execution result for the block 125 is not generated yet, and then the second node 20 may generate the merck root voucher 24 to be verified according to the transaction execution results 1212, …, the transaction execution result 1242 and the target transaction execution result 1251. Verifying the consistency 205 of the merck root ticket 24 to be verified and the merck root ticket 14, wherein when the merck root ticket 24 to be verified and the merck root ticket 14 are different, the second node 20 does not agree with the transaction execution result for the target block; when the merck root certificate 24 to be verified and the merck root certificate 14 are the same, the second node 20 performs result consensus through the transaction for the target block.

Through the merck root certificate 14, the second node 20 can perform the transaction execution result consensus on the block 125 in advance under the condition that the local transaction execution result of the block 125 is not generated, so that the transaction execution result consensus speed of the block 125 is increased.

Optionally, in fig. 6, the second node 20 generates no transaction execution result for the target block (i.e. the block 125), and when the second node generates the transaction execution result for the target block, the second node may generate the merck root credential to be verified according to the locally generated transaction execution results 1212, …, the transaction execution result 1242, and the local transaction execution result for the block 125, and then verify the consistency between the merck root credential to be verified and the merck root credential 14, and the subsequent process is consistent with verifying the consistency 205 between the merck root credential 24 to be verified and the merck root credential 14, so that further description is omitted.

It should be noted that, in the embodiment of the present application, the steps S105 and S106 are not limited to the chronological order, and may occur first in the step S105, first in the step S106, or simultaneously in the step S105 and the step S106.

In step S107, the sequencing consensus result is broadcast and the transaction execution consensus result is obtained.

Specifically, referring to fig. 5, when the second node 20 completes the sequencing consensus for the first block 129, the sequencing consensus result is broadcasted to at least two consensus nodes (including the first node 10), specifically: when the merck root 100a in the first block 129 is different from the merck root 100b to be verified, or the transaction data in the first block 129 is not all legal, the second node 20 may determine that the first block 129 has illegal parameters, and the second node 20 broadcasts the sequencing failure voting result for the first block 109 to at least two consensus nodes; when the merck root 100a in the first block 129 is the same as the merck root 100b to be verified, and the transaction data in the first block 129 are all legal transactions, the at least two second nodes broadcast the sequencing-by-voting result for the first block to at least two consensus nodes.

Meanwhile, the second node 20 obtains the sequenced voting results for the first block 129 sent by the at least two consensus nodes, please refer to fig. 7, which is a schematic view of a block chain-based data processing scenario provided in the embodiment of the present application. As shown in fig. 7, assuming that the consensus network includes the first node 10, the second node 20, the consensus node 30, the consensus node 40, the consensus node 50, and the consensus node 60, when the first node 10 newly generates the first block 129, the first block 129 is broadcast to the consensus node 30, the consensus node 40, the consensus node 50, the consensus node 60, and the second node 20 through the node identification. The consensus node 30, the consensus node 40, the consensus node 50, the consensus node 60, and the second node 20 each sequence the first block 129 and broadcast a corresponding sequence voting result based on the sequence consensus result. Taking the second node 20 as an example, and the consensus algorithm used is the bayer 2/3, as shown in fig. 7, the voting result of the consensus node 30, the voting result of the consensus node 40, the voting result of the first node 10, and the voting result of the consensus node 60 obtained by the second node 20 are all passing votes, and the voting result of the second node 20 itself is also passing votes, and 5 passing votes are obtained in total, so that if the voting result of the consensus node 50 is a failed vote (that is, the sequencing consensus result of the consensus node 50 to the first block 129 is a sequencing failure voting result), the bayer 2/3 condition is satisfied, so that it can be determined that the sequencing consensus result of the first block 129 is passing sequencing consensus, and the second node 20 stores the block 129 in the buffer 23.

Alternatively, when the second node 20 receives the first block 129 broadcast by the first node 10, transaction data may be obtained from the transaction pool, and then the block 130 may be generated according to the transaction data, or after the second node 20 has agreed upon the ordering of the first block 129, the block 130 may be generated, which is not limited herein.

Further, referring to fig. 6, when the second node 20 completes the consensus of the transaction execution result for the block 125, the result of the consensus of the transaction execution is broadcast to at least two consensus nodes (including the first node 10), specifically: when the merck root certificate 24 to be verified and the merck root certificate 14 are different, the second node 20 broadcasts a transaction execution failure voting result for the target block to at least two consensus nodes; the transaction execution failure voting result indicates that the second node 20 does not have a consensus of the transaction execution result for the target block; when the merck root certificate 24 to be verified and the merck root certificate 14 are the same, the second node 20 broadcasts a transaction execution passing voting result for the target block to at least two consensus nodes; the transaction execution characterizes the second node 20 by voting results by a transaction execution result consensus for the target block.

As well as sequencing the first block 129, the second node 20 may also obtain the voting result of the transaction execution for the target block sent by other consensus nodes, and the detailed process may refer to the embodiment corresponding to fig. 7, which is not repeated herein.

Step S108, storing the target block and the target transaction execution result.

Specifically, the first node obtains the transaction execution voting results respectively sent by the at least two second nodes; the transaction execution voting result is a voting result obtained by carrying out transaction execution result consensus on the target block; the first node counts the number of the transaction execution voting results belonging to the passing of the voting among the transaction execution voting results as the passing voting number; when the pass ticket number is equal to or greater than a consensus pass threshold, the first node determines that a consensus result of the transaction execution result of the target block is a consensus pass result; when the number of passing votes is smaller than a consensus passing threshold, the first node determines that a consensus result of the transaction execution result of the target block is a consensus failure result; when the consensus result of the transaction execution result of the target block is a consensus passing result, the first node stores the target block and the target transaction execution result in association with each other in the blockchain.

According to a Bayesian 2/3 consensus algorithm, counting transaction execution voting results respectively sent by the at least two second nodes, namely, only 2/3 transaction execution voting results belong to voting passing in the transaction execution voting results respectively sent by the at least two second nodes, the first node determines that the consensus result of the transaction execution results of the target block is a consensus passing result, if less than 2/3 transaction execution voting results belong to voting passing, the first node determines that the consensus result of the transaction execution results of the target block is a consensus failure result, and the first node needs to audit the local account book.

Alternatively, other consensus algorithms may be used to count the transaction execution voting results respectively sent by the at least two second nodes, which is not limited herein.

Step S109, storing the target block and the local target transaction execution result.

Specifically, taking a second node of at least two second nodes as an example, please refer to fig. 6 again, when the target block (i.e. block 125) is identified by the transaction execution result, and the second node 20 subsequently generates the local transaction execution result 1252 for the block 125, the second node 20 stores the target block and the local transaction execution result 1252 in association with the local ledger 22.

Alternatively, the description is still given by using a certain second node of the at least two second nodes, and the storage process of the other second nodes is the same. If the first node 10 broadcasts the target transaction execution result for the target block, the second node 20 generates the transaction execution result of the target block locally, and when the target block is identified by the transaction execution result, the second node 20 can store the target block and the local target transaction execution result in the local ledger 22 in real time.

In the embodiment of the present invention, after the first block is generated by the first node, the target transaction execution result is determined from the local transaction execution results for the history block, which are generated locally by the first node, and because the first node broadcasts the latest transaction execution result, that is, the target transaction execution result, while broadcasting the sequenced first block, at least two second nodes can not only sequence and agree with the first block, but also simultaneously agree with the transaction execution result of the target block (that is, the block corresponding to the target transaction execution result). As can be seen from the above, by performing asynchronous processing on the sequencing consensus and the transaction execution result consensus of the first node, that is, after the first node finishes sequencing the first block, the second node does not need to wait for the first node to output the transaction execution result of the first block, and can directly generate the next block on the basis of the first block, thereby efficiently promoting the generation of the block. According to the target transaction execution result, the second node can still perform transaction execution result consensus on the target block under the condition that the second node does not generate the local transaction execution result of the target block, so that the transaction execution result consensus speed of the target block is increased, and the consensus speed is further increased.

Further, please refer to fig. 8, which is a flowchart illustrating a data processing method based on a blockchain according to an embodiment of the present application. In the embodiment of the present application, the second node device is used as an execution body, as shown in fig. 8, and the data processing process includes the following steps:

step S201, a second node acquires a first block broadcasted by a first node and a target transaction execution result; the first block and the target transaction execution result are both generated by the first node.

Specifically, when the first node generates the first block in one consensus node cluster, the first block needs to be subjected to sequencing consensus, and similarly, the newly generated target transaction execution result also needs to be subjected to consensus of the transaction execution result, so that the first node broadcasts the first block and the target transaction execution result to other consensus nodes (including the second node) in the consensus node cluster where the first block and the target transaction execution result are located.

In step S202, the second node performs sequencing consensus on the first block.

Specifically, the second node obtains the hash value of the merck tree root and the transaction data in the first block; the second node generates a merck tree root to be verified according to the hash value of the transaction data in the first block; when the merck tree root in the first block is the same as the merck tree root to be verified, the second node verifies the validity of the transaction data in the first block; when the transaction data in the first block is legal data, the second node broadcasts a sequencing passing voting result for the first block to at least two consensus nodes; the at least two consensus nodes include the first node; the second node obtains the sequencing voting results for the first block sent by the at least two consensus nodes, and determines the sequencing consensus result of the first block according to the obtained sequencing voting results and the locally generated sequencing passing voting results.

When the first block is identified through sequencing, the second node acquires transaction data; the second node sequences the transaction data and generates a block hash parameter of a second block according to the first block and the sequenced transaction data; the second node generating the second chunk according to the chunk hash parameter of the second chunk and the sequenced transaction data; the first block is a preceding block of the second block.

Step S203, the second node performs transaction execution result consensus on the target block according to the target transaction execution result; the target block is a block corresponding to the target transaction execution result, the block height of the first block is larger than the block height of the target block, and the target block is a block which is commonly known through sequencing.

Specifically, the second node acquires a merck tree root certificate broadcasted by the first node; the merck root certificate is a certificate generated according to a transaction execution result generated by the first node; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the transaction execution results generated by the first node; the second node obtains a local transaction execution result which is generated locally and aims at the history block; the block height of the first block is greater than the block height of the history block; the second node obtains the highest block height in the blocks corresponding to the local transaction execution result; if the highest block height is smaller than the block height of the target block, the second node generates the merck tree root certificate to be verified according to the local transaction execution result and the target transaction execution result.

When the merck tree root certificate to be verified and the merck tree root certificate are the same, the second node broadcasts a transaction execution passing voting result aiming at the target block to the at least two consensus nodes; the transaction execution characterizes the second node by voting results to be consensus of the transaction execution results aiming at the target block; the second node obtains a transaction execution voting result which is sent by the at least two consensus nodes and is aimed at the target block; and the second node determines a transaction execution consensus result of the target block according to the obtained transaction execution voting result and the locally generated transaction execution passing voting result.

In step S204, when the target block is identified by the transaction execution result and the second node has generated the transaction execution result of the target block, the second node stores the target block and the transaction execution result of the target block generated by the second node in association with each other in the blockchain.

Specifically, please refer to step S109 in the embodiment corresponding to fig. 3, which is not described herein.

Further, please refer to fig. 9, which is a schematic diagram illustrating a block chain-based data processing apparatus according to an embodiment of the present application. The data processing means may be a computer program (comprising program code) running in a computer device, for example the data processing means is an application software; the data processing device may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 9, the data processing apparatus 1 may be used in the computer device in the embodiment corresponding to fig. 3 and 8, and specifically, the data processing apparatus 1 may include: the block generating module 11, the local result acquiring module 12, the broadcast block result module 13 and the first storage block result module 14.

A generation block module 11 for generating a first block;

an acquisition local result module 12, configured to acquire a locally generated local transaction execution result for the history block; the block height of the first block is greater than the block height of the history block;

a broadcast block result module 13, configured to determine a target transaction execution result from the local transaction execution results, broadcast the first block and the target transaction execution result to at least two second nodes, so that the at least two second nodes perform sequencing consensus on the first block, and perform transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing;

The first storage block result module 14 is configured to store the target block and the target transaction execution result in association with each other in a blockchain when the target block is identified by the transaction execution result.

The specific functional implementation manner of the block generating module 11, the local result acquiring module 12, the broadcast block result acquiring module 13, and the first storage block result acquiring module 14 may refer to step S101 to step S108 in the corresponding embodiment of fig. 3, and will not be described herein.

Referring back to fig. 9, the generating block module 11 may include: a fetch data unit 111, a sequence data unit 112, and a generation block unit 113.

An acquisition data unit 111 for acquiring the second block and the transaction data; the second block is generated by a target node of the at least two second nodes;

a sequencing data unit 112 for sequencing the transaction data and generating a block hash parameter according to the second block and the sequenced transaction data;

a block generation unit 113 configured to generate the first block based on the block hash parameter and the sequenced transaction data; the second block is a preceding block of the first block.

The specific functional implementation manner of the acquiring data unit 111, the sequencing data unit 112, and the generating block unit 113 may refer to step S101 in the corresponding embodiment of fig. 3, and will not be described herein.

Referring again to fig. 9, the broadcast block result module 13 may include: a broadcasted result unit 131 and a target result unit 132 are determined.

A broadcast result determining unit 131, configured to determine a broadcast transaction execution result in the local transaction execution results according to the transaction execution results broadcast by the at least two second nodes;

a determination target result unit 132 configured to determine, as a target transaction execution result, a transaction execution result other than the broadcast transaction execution result among the local transaction execution results; the block height of the target block is larger than the block height corresponding to the broadcasted transaction execution result.

The specific functional implementation manner of the broadcasted result unit 131 and the target result unit 132 may be referred to as step S102-step S103 in the corresponding embodiment of fig. 3, and will not be described herein.

Referring again to fig. 9, the broadcast block result module 13 may further include: a voucher unit 133 and a broadcast result voucher unit 134 are generated.

A generation credential unit 133 configured to generate a merck root credential according to the local transaction execution result;

a broadcast result voucher unit 134 for broadcasting the first block, the target transaction execution result, and the merck root voucher to the at least two second nodes; the merck root certificate is used for the at least two second nodes to carry out transaction execution result consensus on the target block.

The specific functional implementation manner of the generation credential unit 133 and the broadcast result credential unit 134 may refer to step S104 in the corresponding embodiment of fig. 3, and will not be described herein.

Referring again to fig. 9, the first memory block result module 14 may include: the voting result section 141 is acquired, the consensus result section 142 is determined, and the block result section 143 is stored.

A voting result obtaining unit 141, configured to obtain a transaction execution voting result sent by the at least two second nodes respectively; the transaction execution voting result is a voting result obtained by carrying out transaction execution result consensus on the target block;

a determining consensus result unit 142, configured to determine a consensus result of the transaction execution result for the target block according to the transaction execution voting result;

And a block result storage unit 143, configured to store the target block and the target transaction execution result in association with each other in the blockchain when the consensus result of the transaction execution result of the target block is a consensus passing result.

The specific functional implementation manner of the voting result unit 141, the determining consensus result unit 142 and the memory block result unit 143 may refer to step S108 in the corresponding embodiment of fig. 3, and will not be described herein.

Referring back to fig. 9, determining the consensus result unit 142 may include: the statistical vote passes through subunit 1421 and determines consensus subunit 1422.

A statistics voting passing sub-unit 1421 for counting the number of transaction execution voting results belonging to the voting passing among the transaction execution voting results as the passing voting number;

a consensus result determination subunit 1422, configured to determine, when the number of passing votes is equal to or greater than a consensus passing threshold, that a consensus result of the transaction execution result of the target block is a consensus passing result;

the determining consensus result subunit 1422 is further configured to determine that the consensus result of the transaction execution result of the target block is a consensus failure result when the passing ticket number is less than the consensus passing threshold.

The specific functional implementation manner of the statistical voting passing subunit 1421 and the consensus result determining subunit 1422 may refer to step S108 in the corresponding embodiment of fig. 3, and will not be described herein.

Further, please refer to fig. 10, which is a schematic diagram illustrating a block chain-based data processing apparatus according to an embodiment of the present application. The data processing means may be a computer program (comprising program code) running in a computer device, for example the data processing means is an application software; the data processing device may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 10, the data processing apparatus 2 may be used in the computer device in the embodiment corresponding to fig. 3 and 8, and specifically, the data processing apparatus 2 may include: the block result acquisition module 21, the sequencing consensus block module 22, the consensus target result module 23 and the second memory block result module 24.

An obtaining block result module 21, configured to obtain a first block and a target transaction execution result broadcasted by the first node; the first block and the target transaction execution result are both generated by the first node;

a sequencing consensus block module 22 for sequencing consensus for the first block;

a consensus target result module 23, configured to consensus the transaction execution result for the target block according to the target transaction execution result; the target block is a block corresponding to the target transaction execution result, the block height of the first block is larger than the block height of the target block, and the target block is a block which is commonly known through sequencing;

And a second block result module 24, configured to store the target block and the transaction execution result of the target block generated by the second node in association with each other in a blockchain when the target block is identified by the transaction execution result and the second node has generated the transaction execution result of the target block.

The specific functional implementation manner of the block result obtaining module 21, the sequencing consensus block module 22, the consensus target result module 23, and the second storage block result module 24 may refer to step S201-step S204 in the corresponding embodiment of fig. 8, and will not be described herein.

Referring again to fig. 10, the sequenced consensus block module 22 may include: a fetch block hash value unit 221, a generate root to be authenticated unit 222, an authentication data legal unit 223, a broadcast sequencing-by-result unit 224, and a fetch sequencing voting result unit 225.

An obtaining block hash value unit 221, configured to obtain hash values of the merck tree root and the transaction data in the first block;

a root to be verified unit 222, configured to generate a merck tree root to be verified according to the hash value of the transaction data in the first block;

A verification data validity unit 223, configured to verify validity of the transaction data in the first block when the merck tree root in the first block is the same as the merck tree root to be verified;

a broadcast sequencing-by-result unit 224 for broadcasting a sequencing-by-vote result for the first block to at least two consensus nodes when the transaction data in the first block is legal data; the at least two consensus nodes include the first node;

an acquisition sequencing voting result unit 225, configured to acquire sequencing voting results for the first block sent by the at least two consensus nodes, and determine a sequencing consensus result for the first block according to the acquired sequencing voting results and a locally generated sequencing passing voting result.

The specific functional implementation manners of the block hash value obtaining unit 221, the root to be verified generating unit 222, the verification data legal unit 223, the broadcast sequencing passing result unit 224, and the sequenced voting result obtaining unit 225 may refer to step S202 in the corresponding embodiment of fig. 8, and will not be described herein.

Referring again to fig. 10, the sequenced consensus block module 22 may further comprise: the transaction data unit 226 is acquired, the chunk hash parameter unit 227 is generated, and the second chunk unit 228 is generated.

An acquire transaction data unit 226 for acquiring transaction data when the first block is consensus sequenced;

a block hash parameter generating unit 227 for sequencing the transaction data and generating a block hash parameter of a second block according to the first block and the sequenced transaction data;

a second chunk generating unit 228 configured to generate the second chunk according to the chunk hash parameter of the second chunk and the sequenced transaction data; the first block is a preceding block of the second block.

The specific functional implementation manners of obtaining the transaction data unit 226, generating the block hash parameter unit 227, and generating the second block unit 228 may refer to step S202 in the corresponding embodiment of fig. 8, and will not be described herein.

Referring again to fig. 10, the consensus target result module 23 may include: the acquiring broadcast voucher unit 231, the acquiring local transaction result unit 232, the generating to-be-verified voucher unit 233 and the consensus block transaction result unit 234.

An acquiring broadcast credential unit 231, configured to acquire a merck tree root credential broadcasted by the first node; the merck root certificate is a certificate generated according to a transaction execution result generated by the first node; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the transaction execution results generated by the first node;

An acquisition local transaction result unit 232, configured to acquire a local transaction execution result for a history block, which has been generated locally; the block height of the first block is greater than the block height of the history block;

the to-be-verified credential unit 233 is configured to generate a to-be-verified merck root credential according to the local transaction execution result and the target transaction execution result;

the consensus block transaction result unit 234 is configured to perform a transaction execution result consensus on the target block according to the merck root certificate to be verified and the merck root certificate.

The specific function implementation manner of the acquiring broadcast credential unit 231, the acquiring local transaction result unit 232, the generating credential unit 233 to be verified, and the consensus block transaction result unit 234 may refer to step S203 in the corresponding embodiment of fig. 8, and will not be described herein.

Referring back to fig. 10, generating the to-be-verified credential unit 233 may include: the fetch block Gao Duzi unit 2331 and the generate credentials to be verified subunit 2332.

An acquiring block Gao Duzi unit 2331, configured to acquire a highest block height in the blocks corresponding to the local transaction execution result;

and a verification-to-be-verified credential subunit 2332 configured to generate the verification-to-be-verified merck root credential according to the local transaction execution result and the target transaction execution result if the highest block height is less than the block height of the target block.

The specific functional implementation of the obtaining block Gao Duzi unit 2331 and the generating credential subunit 2332 to be verified may refer to step S203 in the corresponding embodiment of fig. 8, which is not described herein again.

Referring back to fig. 10, the consensus block transaction result unit 234 may include: the broadcast transaction passes through a results subunit 2341, an acquire transaction vote results subunit 2342, and a determine transaction consensus results subunit 2343.

A broadcast transaction passing result subunit 2341, configured to broadcast a transaction execution passing voting result for the target block to the at least two consensus nodes when the merck root certificate to be verified and the merck root certificate are the same; the transaction execution characterizes the second node by voting results to be consensus of the transaction execution results aiming at the target block;

a transaction voting result obtaining subunit 2342, configured to obtain a transaction execution voting result sent by the at least two consensus nodes and directed at the target block;

a determining transaction consensus result subunit 2343, configured to determine a transaction execution consensus result of the target block according to the obtained transaction execution voting result and a locally generated transaction execution passing voting result.

The specific functional implementation manner of the broadcast transaction passing result subunit 2341, the acquire transaction vote result subunit 2342 and the determine transaction consensus result subunit 2343 may refer to step S203 in the corresponding embodiment of fig. 8, and will not be described herein.

Further, please refer to fig. 11, which is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 11, the computer device 1000 may include: processor 1001, network interface 1004, and memory 1005, in addition, computer device 1000 may further comprise: a user interface 1003, and at least one communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display (Display), a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface, among others. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a nonvolatile memory (non-volatile memory), such as at least one magnetic disk memory. The memory 1005 may also optionally be at least one storage device located remotely from the processor 1001. As shown in fig. 11, an operating system, a network communication module, a user interface module, and a device control application may be included in the memory 1005, which is one type of computer-readable storage medium.

In the computer device 1000 shown in FIG. 11, the network interface 1004 may provide network communication functions; while user interface 1003 is primarily used as an interface for providing input to a user; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

generating a first block;

acquiring a local transaction execution result which is generated locally and aims at a history block; the block height of the first block is greater than the block height of the history block;

determining a target transaction execution result from the local transaction execution results, broadcasting the first block and the target transaction execution result to at least two second nodes, so that the at least two second nodes perform sequencing consensus on the first block and perform transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing;

when the target block is identified by the transaction execution result, the target block and the target transaction execution result are associated and stored in a blockchain.

In one embodiment, the processor 1001, when executing the generating the first block, specifically performs the following steps:

Acquiring a second block and transaction data; the second block is generated by a target node of the at least two second nodes;

sequencing the transaction data, and generating a block hash parameter according to the second block and the sequenced transaction data;

generating the first block according to the block hash parameter and the sequenced transaction data; the second block is a preceding block of the first block.

In one embodiment, the processor 1001, when executing the determination of the target transaction execution result from the above local transaction execution results, specifically executes the following steps:

determining a broadcasted transaction execution result in the local transaction execution results according to the transaction execution results broadcasted by the at least two second nodes;

determining a transaction execution result except the broadcasted transaction execution result in the local transaction execution results as a target transaction execution result; the block height of the target block is larger than the block height corresponding to the broadcasted transaction execution result.

In one embodiment, the processor 1001, when executing the broadcasting of the first block and the target transaction execution result to at least two second nodes, specifically executes the following steps:

Generating merck root certificates according to the local transaction execution result;

broadcasting the first block, the target transaction execution result and the merck root certificate to the at least two second nodes; the merck root certificate is used for the at least two second nodes to carry out transaction execution result consensus on the target block.

In one embodiment, the processor 1001, when executing the first node stores the target block and the target transaction execution result in association with each other in the blockchain when the target block is identified by the transaction execution result, specifically performs the following steps:

obtaining transaction execution voting results respectively sent by the at least two second nodes; the transaction execution voting result is a voting result obtained by carrying out transaction execution result consensus on the target block;

determining a consensus result of the transaction execution result aiming at the target block according to the transaction execution voting result;

and when the consensus result of the transaction execution result of the target block is a consensus passing result, storing the target block and the target transaction execution result in association with the block chain.

In one embodiment, the processor 1001, when executing the voting result executed according to the transaction execution, determines a consensus result of the transaction execution result for the target block, specifically executes the following steps:

counting the number of the transaction execution voting results belonging to the passing of the voting as the passing voting number in the transaction execution voting results;

when the passing ticket number is equal to or greater than a consensus passing threshold, determining that a consensus result of the transaction execution result of the target block is a consensus passing result;

and when the passing ticket number is smaller than the consensus passing threshold value, determining that the consensus result of the transaction execution result of the target block is a consensus failure result.

Further, please refer to fig. 12, which is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 12, the computer device 2000 may include: processor 2001, network interface 2004 and memory 2005, in addition, computer device 2000 may also include: a user interface 2003, and at least one communication bus 2002. Wherein a communication bus 2002 is used to enable connected communications between these components. The user interface 2003 may include a Display screen (Display), a Keyboard (Keyboard), and the optional user interface 2003 may further include a standard wired interface, a wireless interface, among others. The network interface 2004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 2005 may be a high-speed RAM memory or a nonvolatile memory (non-volatile memory), such as at least one magnetic disk memory. The memory 2005 may also optionally be at least one storage device located remotely from the aforementioned processor 2001. As shown in fig. 12, an operating system, a network communication module, a user interface module, and a device control application program may be included in the memory 2005 as one type of computer-readable storage medium.

In the computer device 2000 illustrated in fig. 12, the network interface 2004 may provide network communication functions; while user interface 2003 is primarily an interface for providing input to a user; and processor 2001 may be used to invoke device control applications stored in memory 2005 to implement:

acquiring a first block broadcasted by a first node and a target transaction execution result; the first block and the target transaction execution result are both generated by the first node;

sequencing consensus is performed on the first block;

carrying out transaction execution result consensus on the target block according to the target transaction execution result; the target block is a block corresponding to the target transaction execution result, the block height of the first block is larger than the block height of the target block, and the target block is a block which is commonly known through sequencing;

when the target block is identified by the transaction execution result and the second node has generated the transaction execution result of the target block, the target block and the transaction execution result of the target block generated by the second node are stored in a blockchain in a correlated manner.

In one embodiment, the processor 2001, when executing the sequencing consensus for the first block, specifically performs the following steps:

Acquiring a hash value of the merck tree root and the transaction data in the first block;

generating a merck tree root to be verified according to the hash value of the transaction data in the first block;

verifying the validity of the transaction data in the first block when the merck tree root in the first block is the same as the merck tree root to be verified;

broadcasting a sequencing passing voting result for the first block to at least two consensus nodes when the transaction data in the first block is legal data; the at least two consensus nodes include the first node;

and acquiring sequencing voting results sent by the at least two consensus nodes and aiming at the first block, and determining the sequencing consensus result of the first block according to the acquired sequencing voting results and the locally generated sequencing passing voting results.

In one embodiment, the processor 2001, when executing the sequencing consensus for the first block, further specifically performs the following steps:

when the first block is subjected to sequencing consensus, transaction data are acquired;

sequencing the transaction data, and generating a block hash parameter of a second block according to the first block and the sequenced transaction data;

Generating the second block according to the block hash parameter of the second block and the sequenced transaction data; the first block is a preceding block of the second block.

In one embodiment, the processor 2001, when executing the trade execution result consensus for the target block according to the target trade execution result, specifically executes the following steps:

acquiring the merck tree root certificate broadcasted by the first node; the merck root certificate is a certificate generated according to a transaction execution result generated by the first node; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the transaction execution results generated by the first node;

generating a merck tree root certificate to be verified according to the local transaction execution result and the target transaction execution result;

and carrying out transaction execution result consensus on the target block according to the merck tree root certificate to be verified and the merck tree root certificate.

In one embodiment, the processor 2001, when executing the generation of the merck root voucher to be verified according to the local transaction execution result and the target transaction execution result, specifically performs the following steps:

acquiring the highest block height in the blocks corresponding to the local transaction execution result;

and if the highest block height is smaller than the block height of the target block, generating the merck tree root certificate to be verified according to the local transaction execution result and the target transaction execution result.

In one embodiment, the processor 2001, when executing the consensus of the transaction execution result for the target block according to the merck root certificate to be verified and the merck root certificate, specifically performs the following steps:

broadcasting a transaction execution passing voting result for the target block to the at least two consensus nodes when the merck tree root certificates to be verified are the same; the transaction execution characterizes the second node by voting results to be consensus of the transaction execution results aiming at the target block;

acquiring a transaction execution voting result which is sent by the at least two consensus nodes and is aimed at the target block;

And determining a transaction execution consensus result of the target block according to the obtained transaction execution voting result and the locally generated transaction execution passing voting result.

The embodiments of the present application further provide a computer readable storage medium, where a computer program is stored, where the computer program includes program instructions, where the program instructions, when executed by a processor, implement a blockchain-based data processing method provided by each step in fig. 3 and fig. 8, and specifically refer to the implementation manner provided by each step in fig. 3 and fig. 8, which is not described herein again.

The computer readable storage medium may be the data processing apparatus provided in any one of the foregoing embodiments or an internal storage unit of the computer device, for example, a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash card (flash card) or the like, which are provided on the computer device. Further, the computer-readable storage medium may also include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

The terms first, second and the like in the description and in the claims and drawings of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the term "include" and any variations thereof is intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, article, or device that comprises a list of steps or elements is not limited to the list of steps or modules but may, in the alternative, include other steps or modules not listed or inherent to such process, method, apparatus, article, or device.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The methods and related devices provided in the embodiments of the present application are described with reference to the method flowcharts and/or structure diagrams provided in the embodiments of the present application, and each flowchart and/or block of the method flowcharts and/or structure diagrams may be implemented by computer program instructions, and combinations of flowcharts and/or blocks in the flowchart and/or block diagrams. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or structural diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or structures.

The foregoing disclosure is only illustrative of the preferred embodiments of the present application and is not intended to limit the scope of the claims herein, as the equivalent of the claims herein shall be construed to fall within the scope of the claims herein.

Claims

1. A blockchain-based data processing method, comprising:

the first node generates a first block;

the first node obtains a locally generated local transaction execution result aiming at a history block; the block height of the first block is greater than the block height of the history block;

the first node determines a target transaction execution result from the local transaction execution results; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the local transaction execution result;

the first node generates a merck tree root voucher according to the local transaction execution result, broadcasts the first block, the target transaction execution result and the merck tree root voucher to at least two second nodes so that the at least two second nodes perform sequencing consensus on the first block, acquire a locally generated transaction execution result aiming at a historical block, and generate the merck tree root voucher to be verified according to the locally generated transaction execution result and the target transaction execution result; the block height of the first block is greater than the block height of the history block; the merck tree root certificate to be verified is used for the at least two second nodes to conduct transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing;

When the target block is commonly known by the transaction execution result, the first node stores the target block and the target transaction execution result in a blockchain in a correlated manner.

2. The method of claim 1, wherein the first node generates a first block comprising:

the first node acquires a second block and transaction data; the second block is generated by a target node of the at least two second nodes;

the first node sequences the transaction data and generates a block hash parameter according to the second block and the sequenced transaction data;

the first node generating the first block according to the block hash parameter and the sequenced transaction data; the second block is a successor of the first block.

3. The method of claim 1, wherein the first node determining a target transaction execution result from the local transaction execution results comprises:

the first node determines a broadcasted transaction execution result in the local transaction execution results according to the transaction execution results broadcasted by the at least two second nodes;

The first node determines a transaction execution result except the broadcasted transaction execution result in the local transaction execution results as a target transaction execution result; the block height of the target block is larger than the block height corresponding to the broadcasted transaction execution result.

4. The method of claim 1, wherein the first node storing the target chunk and the target transaction execution result in association into a blockchain when the target chunk is agreed upon by the transaction execution result, comprising:

the first node obtains transaction execution voting results respectively sent by the at least two second nodes; the transaction execution voting result is a voting result obtained by carrying out transaction execution result consensus on the target block;

the first node determines a consensus result of the transaction execution result aiming at the target block according to the transaction execution voting result;

and when the consensus result of the transaction execution result of the target block is a consensus passing result, the first node stores the target block and the target transaction execution result in association with the blockchain.

5. The method of claim 4, wherein the first node determining a consensus of the transaction execution outcome for the target block based on the transaction execution voting outcome, comprising:

the first node counts the number of the transaction execution voting results belonging to the passing of the voting in the transaction execution voting results as the passing voting number;

when the passing ticket number is equal to or greater than a consensus passing threshold, the first node determines that a consensus result of the transaction execution result of the target block is a consensus passing result;

and when the passing ticket number is smaller than a consensus passing threshold value, the first node determines that the consensus result of the transaction execution result of the target block is a consensus failure result.

6. A blockchain-based data processing method, comprising:

the second node acquires a first block broadcasted by the first node, a target transaction execution result and a merck tree root certificate; the first block and the target transaction execution result are both generated by the first node; the merck root voucher is generated according to a transaction execution result generated by the first node; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the transaction execution results generated by the first node;

The second node performs sequencing consensus on the first block;

the second node obtains a locally generated local transaction execution result aiming at the history block; the block height of the first block is greater than the block height of the history block;

the second node generates a merck tree root certificate to be verified according to the local transaction execution result and the target transaction execution result;

the second node performs transaction execution result consensus on the target block according to the merck tree root certificate to be verified and the merck tree root certificate; the target block is a block corresponding to the target transaction execution result, the block height of the first block is larger than the block height of the target block, and the target block is a block which is commonly known through sequencing;

when the target block is identified by the transaction execution result and the second node has generated the transaction execution result of the target block, the second node stores the target block and the transaction execution result of the target block generated by the second node in association with the blockchain.

7. The method of claim 6, wherein the second node sequencing consensus of the first block comprises:

The second node obtains the hash value of the merck tree root and the transaction data in the first block;

the second node generates a merck tree root to be verified according to the hash value of the transaction data in the first block;

when the merck tree root in the first block is the same as the merck tree root to be verified, the second node verifies the validity of the transaction data in the first block;

when the transaction data in the first block is legal data, the second node broadcasts a sequencing-by-vote result for the first block to at least two consensus nodes; the at least two consensus nodes include the first node;

the second node obtains sequencing voting results sent by the at least two consensus nodes and aiming at the first block, and determines sequencing consensus results of the first block according to the obtained sequencing voting results and the sequencing passing voting results generated locally.

8. The method as recited in claim 7, further comprising:

when the first block passes sequencing consensus, the second node acquires transaction data;

the second node sequences the transaction data and generates a block hash parameter of a second block according to the first block and the sequenced transaction data;

The second node generating the second chunk according to chunk hash parameters of the second chunk and the sequenced transaction data; the first block is a successor of the second block.

9. The method of claim 6, wherein the second node generating the merck root voucher to be verified from the local transaction execution result and the target transaction execution result comprises:

the second node obtains the highest block height in the blocks corresponding to the local transaction execution result;

and if the highest block height is smaller than the block height of the target block, the second node generates the merck tree root certificate to be verified according to the local transaction execution result and the target transaction execution result.

10. The method of claim 6, wherein the second node performs transaction execution result consensus on the target block according to the merck root voucher to be verified and the merck root voucher, comprising:

when the merck tree root certificates to be verified and the merck tree root certificates are the same, broadcasting a transaction execution passing voting result aiming at the target block to at least two consensus nodes by the second node; characterizing, by the transaction execution, that the second node is consensus of the transaction execution result for the target block by voting results;

The second node obtains a transaction execution voting result which is sent by the at least two consensus nodes and is aimed at the target block;

and the second node determines a transaction execution consensus result of the target block according to the obtained transaction execution voting result and the locally generated transaction execution passing voting result.

11. A blockchain-based data processing device, comprising:

the generation block module is used for generating a first block;

the broadcast block result module is used for determining a target transaction execution result from the local transaction execution results; the target transaction execution result is a transaction execution result except for the transaction execution result broadcasted in the consensus network in the local transaction execution result;

the broadcast block result module is further configured to generate a merck root voucher according to the local transaction execution result, broadcast the first block, the target transaction execution result, and the merck root voucher to at least two second nodes, so that the at least two second nodes perform sequencing consensus on the first block, acquire a locally generated transaction execution result for a historical block, and generate a merck root voucher to be verified according to the locally generated transaction execution result and the target transaction execution result; the block height of the first block is greater than the block height of the history block; the merck tree root certificate to be verified is used for the at least two second nodes to conduct transaction execution result consensus on the target block; the target block is a block corresponding to the target transaction execution result, and the target block is a block which is already known through sequencing;

And the first storage block result module is used for storing the target block and the target transaction execution result in a block chain in an associated manner when the target block is identified through the transaction execution result.

12. A computer device, comprising: a processor, a memory, and a network interface;

the processor is connected to the memory, the network interface for providing data communication functions, the memory for storing program code, the processor for invoking the program code to perform the steps of the method according to any of claims 1 to 10.

13. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program comprising program instructions, which when executed by a processor, perform the steps of the method according to any of claims 1 to 10.