CN116938963A

CN116938963A - Data processing method, device, equipment, medium and product

Info

Publication number: CN116938963A
Application number: CN202210362855.3A
Authority: CN
Inventors: 刘区城; 王宗友; 蓝虎; 张劲松; 朱耿良; 时一防; 刘汉卿; 郭英杰; 廖志勇
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-04-07
Filing date: 2022-04-07
Publication date: 2023-10-24

Abstract

The application provides a data processing method, a data processing device, data processing equipment, a medium and a product. The method comprises the following steps: extracting a block header from the proposal message when receiving a consensus acknowledgement message of the proposal message; searching a zone block corresponding to the zone head in the cache manager and executing results of transactions in the zone block, wherein the zone block and the executing results of the transactions in the zone block are stored in the cache manager before receiving the consensus confirmation message; combining the block head and the block body into a block, adding the block to the block chain, and writing the searched execution result back to the state database of the block chain. The application can separate the zone blocks from the proposal message, thereby improving consensus efficiency in the blockchain.

Description

Data processing method, device, equipment, medium and product

Technical Field

The present application relates to the field of computer technology, and in particular, to a data processing method, a data processing apparatus, a computer device, a computer readable storage medium, and a computer program product.

Background

The practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm is a common consensus algorithm in the coalition chain.

The PBFT consensus algorithm mainly involves three phases, which may specifically include a pre-preparation phase, a preparation phase, and a commit phase. As known from practice, after receiving the consensus confirmation message of the proposal message in the commit stage, the transaction in the proposal message needs to be executed, generally, the execution of the transaction needs to take more time, which results in more time consuming consensus process and lower consensus efficiency. Therefore, how to improve the consensus efficiency is a technical problem to be solved currently.

Disclosure of Invention

Embodiments of the present application provide a data processing method, apparatus, computer device, computer readable storage medium, and computer program product, which can separate a block from a proposal message, thereby improving consensus efficiency in a blockchain.

In one aspect, an embodiment of the present application provides a data processing method, where the method includes:

extracting a block header from the proposal message when receiving a consensus acknowledgement message of the proposal message;

searching a zone block corresponding to the zone head in the cache manager and executing results of transactions in the zone block, wherein the zone block and the executing results of the transactions in the zone block are stored in the cache manager before receiving the consensus confirmation message;

Combining the block head and the block body into a block, adding the block to the block chain, and writing the searched execution result back to the state database of the block chain.

In one aspect, an embodiment of the present application provides a data processing apparatus, including:

an obtaining unit, configured to extract a block header from the proposal message when receiving a consensus acknowledgement message of the proposal message;

the processing unit is used for searching the zone block corresponding to the zone head in the cache manager and executing results of the transactions in the zone block, wherein before receiving the common identification information, the executing results of the transactions in the zone block and the zone block are stored in the cache manager;

the processing unit is also used for combining the block head and the block body into a block, adding the block to the block chain, and writing the searched execution result back to the state database of the block chain.

In one possible implementation, before the acquisition unit receives the consensus acknowledgement message of the proposal message, the processing unit is further configured to:

the method comprises the steps of obtaining a block body, wherein the block body is generated according to a plurality of transactions obtained from a transaction pool;

executing the zone block to obtain an execution result of the transaction in the zone block;

Writing the block and the execution result of the transaction in the block into a cache manager;

and the execution result of the transaction in the block body and the block identification corresponding to the block body are stored in a correlated way.

receiving k confirmation results sent by k nodes in the block chain aiming at the proposal message, wherein one node corresponds to one confirmation result, and k is a positive integer;

and when the number of confirmation passes in the k confirmation results exceeds a first preset number threshold, confirming generation of a consensus confirmation message of the proposal message.

In one possible implementation, the above method is performed by a master node in a blockchain; any one of the k nodes is referred to as a backup node; the processing unit is also configured to perform the following operations:

acquiring proposal information, broadcasting the proposal information to k backup nodes in a blockchain, so that any backup node in the k backup nodes performs voting processing on the proposal information, and obtaining a voting result;

receiving k voting results sent by k backup nodes, and if the number of votes passing through the k voting results exceeds a second preset number threshold value, confirming to generate a confirmation indication message aiming at proposal information, wherein one backup node corresponds to one voting result;

Broadcasting the confirmation indication message to k backup nodes in the blockchain, so that any backup node in the k backup nodes confirms the confirmation indication message and obtains a confirmation result.

In one possible implementation, the above method is performed by any one of the backup nodes in the blockchain; the processing unit is also configured to perform the following operations:

receiving proposal information sent by a main node, and carrying out voting treatment on the proposal information to obtain a voting result;

the voting result is sent to the master node, so that the master node generates a confirmation indication message for the proposal message according to the voting result;

receiving a confirmation indication message sent by a main node, and carrying out confirmation processing on the confirmation indication message to obtain a confirmation result;

and sending the confirmation result to the master node so that the master node generates a consensus confirmation message of the proposal message.

In one possible implementation, the processing unit obtains the proposal message for performing the following operations:

acquiring a transaction request sent by a client, and generating a block header according to the transaction request;

and constructing a proposal message corresponding to the block header according to the block header.

In one possible implementation, the transaction request carries an identifier of the client; the processing unit is further configured to, after acquiring the transaction request sent by the client, perform the following operations:

Acquiring an identifier of a client in a transaction request;

and checking the client according to the identifier of the client, and if the client passes the check, triggering and executing the step of generating the block header according to the transaction request.

In one possible implementation, the processing unit constructs a proposal message corresponding to the block header according to the block header, and is configured to perform the following operations:

carrying out serialization processing on the block head to obtain a serialization byte array corresponding to the block head;

and calculating the abstract of the serialized byte array, and carrying out signature processing on the abstract of the serialized byte array to obtain the proposal message corresponding to the block header.

In one possible implementation, the above method is performed by a master node of a blockchain; the processing unit is further configured to, after acquiring the block body, perform the following operations:

broadcasting the block body to k backup nodes in the block chain, so that each backup node in the k backup nodes executes the block body after receiving the block body, and obtaining the execution result of the transaction in the block body.

In one possible implementation, when the above method is performed by a backup node in a blockchain, the processing unit obtains a block of regions for performing the following operations:

receiving a zone block sent by a main node;

And (3) acquiring a node identifier of the main node, checking the main node according to the node identifier, and if the check is passed, triggering the execution area block and obtaining the execution result of the transaction in the area block.

In one aspect, an embodiment of the present application provides a computer apparatus, where the computer apparatus includes a memory and a processor, and the memory stores a computer program, and when the computer program is executed by the processor, causes the processor to execute the data processing method described above.

In one aspect, embodiments of the present application provide a computer-readable storage medium storing a computer program that, when read and executed by a processor of a computer device, causes the computer device to perform the above-described data processing method.

In one aspect, embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the data processing method described above.

In the embodiment of the application, when the blockchain node receives the consensus confirmation message of the proposal message, the blockhead can be extracted from the proposal message; then, searching a zone block corresponding to the zone head and an execution result of the transaction in the zone block in a cache manager, wherein the execution result of the transaction in the zone block and the zone block is stored in the cache manager before receiving the common identification information; next, the block header and the block body may be combined into a block, the block added to the blockchain, and the execution result of the transaction in the acquired block body written back to the state database of the blockchain. Therefore, the method and the device can strip the zone blocks from the proposal message, reduce the size of the proposal message, facilitate the rapid construction of the proposal in the pre-preparation stage, reduce the time consumption of the pre-preparation stage, and improve the consensus efficiency; further, the zone block is executed in advance before the consensus confirmation message is received, and the zone block and the execution result of the transaction in the zone block are stored in the cache manager. When the consensus confirmation message of the proposal message is obtained, the execution result corresponding to the transaction executed in advance can be directly obtained from the cache manager, the transaction in the block body is not required to be executed again, the time consumption of the commit stage can be reduced, and the consensus efficiency is further improved.

Drawings

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

FIG. 1a is a block chain system according to an embodiment of the present application;

FIG. 1b is a block chain architecture diagram according to an embodiment of the present application;

FIG. 1c is a schematic flow chart of a block generation method according to an embodiment of the present application;

FIG. 2a is a schematic flow diagram of a consensus algorithm provided by an embodiment of the present application;

FIG. 2b is a schematic flow chart of a method for performing a consensus algorithm according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of a data processing method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a proposal message provided by an embodiment of the application;

FIG. 5 is a flow chart illustrating a process for executing a smart contract according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a cache manager according to an embodiment of the present application;

FIG. 7 is a schematic diagram of an interaction flow of a data processing method according to an embodiment of the present application;

FIG. 8 is an interactive flow chart of a transaction execution process provided by an embodiment of the present application;

FIG. 9 is a flowchart of another data processing method according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a 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.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application.

The data processing scheme of the present application may be combined with blockchain techniques. Next, the blockchain technology related to the data processing scheme provided by the application is described in detail:

the system according to the embodiment of the present application may be a distributed system formed by connecting a client and a plurality of nodes (any form of computing device in an access network, such as a server and a terminal device) through a network communication. The blockchain correlation technique is described in association with fig. 1 a-1 c as follows:

1. Blockchain system:

referring to fig. 1a, fig. 1a is a schematic diagram of a blockchain system according to an embodiment of the application. The blockchain system as shown in fig. 1a may be a data sharing system 100, where the data sharing system 100 refers to a system for sharing data between nodes, and the data sharing system 100 may include multiple nodes 101, and the multiple nodes 101 may be respective clients in the data sharing system. Each node 101 may receive input information while operating normally and maintain shared data within the data sharing system based on the received input information. In order to ensure the information intercommunication in the data sharing system, information connection can exist between each node in the data sharing system, and the nodes can transmit information through the information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system acquire the input information according to a consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

Each node in the data sharing system has a node identifier corresponding to the node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system, so that the generated block can be broadcast to other nodes in the data sharing system according to the node identifiers of other nodes. Each node can maintain a node identification list shown in the following table, and the node names and the node identifications are correspondingly stored in the node identification list. The node identifier may be an IP (Internet Protocol, protocol of interconnection between networks) address, and any other information that can be used to identify the node, and the IP address is only illustrated in table 1.

TABLE 1 node identification list

Node name	Node identification
		Node 1	117.114.151.174
Node 2	117.116.189.145
		…	…
Node N	xx.xx.xx.xx

It should be noted that any node in the blockchain system shown in fig. 1a may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network ), and basic cloud computing services such as big data and artificial intelligence platforms, and so on.

Any node in the blockchain system shown in fig. 1a may also be a node including, but not limited to: a cell phone, tablet computer, notebook computer, palm computer, mobile internet device (MID, mobile internet device), intelligent voice interaction device, vehicle-mounted terminal, roadside device, aircraft, wearable device, intelligent home appliance, or wearable device with network configuration management function such as smart watch, smart bracelet, pedometer, etc.

2. Structure of the blockchain:

each node in the data sharing system stores one and the same blockchain. The blockchain is composed of a plurality of blocks, referring to fig. 1b, fig. 1b is a schematic diagram of a blockchain structure according to an embodiment of the present application. As shown in fig. 1b, the blockchain is composed of a plurality of blocks, the starting block includes a block header and a block body, the block header stores an input information characteristic value, a version number, a time stamp and a difficulty value, and the block body stores input information; 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 main body, the block head stores the input information characteristic value of the current block, the block head characteristic value of the father block, the version number, the timestamp and the difficulty value, and the like, so that the block data stored in each block in the block chain are associated with the block data stored in the father block, and the safety of the input information in the block is ensured.

3. The process of generating the block:

in generating each block in the blockchain, referring to fig. 1c, fig. 1c is a schematic flow chart of generating a block according to an embodiment of the present application. When receiving input information, a node where the blockchain is located checks the input information, stores the input information into a memory pool after the check is completed, and updates a hash tree used for recording the input information; then, updating the update time stamp to the time of receiving the input information, trying different random numbers, and calculating the characteristic value for a plurality of times, so that the calculated characteristic value can meet the following formula:

SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

in the above formula, SHA256 is a eigenvalue algorithm used to calculate eigenvalues; version (version number) is version information of the related block protocol in the block chain; the prev_hash is the block header characteristic value of the parent block of the current block; the merkle_root is a characteristic value of input information; ntime is the update time of the update timestamp; the nbits is the current difficulty, is a fixed value in a period of time, and is determined again after exceeding a fixed period of time; x is a random number; TARGET is a eigenvalue threshold that can be determined from nbits.

Thus, when the random number meeting the formula is calculated, the information can be correspondingly stored to generate the block head and the block main body, and the current block is obtained. And then, the node where the blockchain is located sends the newly generated blocks to other nodes in the data sharing system where the newly generated blocks are located according to the node identification of other nodes in the data sharing system, the other nodes verify the newly generated blocks, and the newly generated blocks are added into the blockchain stored in the newly generated blocks after the verification is completed.

4. Block chain consensus:

blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. Among them, blockchains can be categorized into public chains (Public Blockchain) and federated chains (Consortium Blockchain) or private chains (Private Blockchain). Common consensus algorithms in blockchains may include, but are not limited to: proof of Work (POW) algorithm, proof of stock (POS) algorithm, commission Proof of equity (Delegated Proof of Stake, DPOS) algorithm, practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm.

The embodiment of the application mainly relates to a PBFT consensus algorithm in a alliance chain, and next, related description is made on a PBFT algorithm commonly used in the alliance chain by combining with fig. 2 a-2 b:

(1) First, the principle of the PBFT consensus algorithm is briefly described in connection with fig. 2 a. Referring to fig. 2a, fig. 2a is a schematic flow chart of a consensus algorithm according to an embodiment of the present application.

1) Participants in the PBFT consensus algorithm are largely divided into a Leader node (primary node, e.g., node 1) and a Replica node (backup nodes, e.g., node 2, node 3, and node 4). Wherein:

Leader node: the method mainly takes charge of packaging transactions into blocks, and then initiates consensus proposal messages based on the blocks, wherein each round of consensus comprises a leader node, and the leader node can switch each round so as to prevent the leader node from averting and packaging false blocks.

Replica: the replica nodes are mainly responsible for participating in the consensus process of the block, and each round has a plurality of replica nodes and the replica nodes have the same behavior.

2) The PBFT consensus algorithm mainly comprises three phases, namely a Pre-preparation phase, a preparation phase and a confirmation phase, wherein the Pre-preparation phase is the confirmation phase, and the confirmation phase is the Commit phase, wherein:

pre-preparation stage: and the leader node is used for mainly packing the transaction into blocks, and then signing the packed blocks to obtain signed blocks. Next, the proposal made up of the above information (signed block) may be broadcast to other consensus nodes (replica nodes).

Preparation stage: each consensus node (replica node) votes the proposal received by itself, and when a proposal obtains the votes of the consensus nodes exceeding 2/3 nodes of the whole network, the proposal enters a commit stage.

Commit phase: and executing the block, and storing the block header, the transaction (block body), the execution result and the like into the account book.

(2) The specific flow of each stage of the PBFT consensus algorithm is then described in relation to fig. 2 b. Referring to fig. 2b, fig. 2b is a flowchart illustrating a method for executing a consensus algorithm according to an embodiment of the present application. As shown in fig. 2b, executing the PBFT consensus algorithm mainly includes the following steps:

(1) request phase: the client sends a transaction request (request) to the leader node (e.g., node 1).

(2) Pre-preparation stage: the leader node is responsible for collecting the transactions sent by the clients and packaging the transactions into chunks, which may then be serialized, signed, and sent to other replicanodes as proposals (as shown in fig. 2 b: construct proposals: steps of block out, serialization, signature, broadcast proposal, etc.).

(3) Preparation stage: after receiving the proposal message broadcast by the leader node, the replica node inversely sequences the proposal message into a proposal, tests a label, and votes the received proposal to obtain a voting result. If any node in the blockchain receives 2f+1 prepare messages (f is the number of bad nodes in the blockchain), it is stated that most nodes have accepted this proposal and enter the commit phase. It will be appreciated that the voting results may include voting pass and voting fail, wherein when the voting result is a voting pass, the message that received the voting result may also be referred to as a prepare message (as shown in fig. 2 b: broadcast the voting result for proposal, collect the voting result, prove that the leader node is honest).

(4) Commit phase: each node broadcasts a commit message and if any node in the blockchain receives 2f+1 commit messages, then it can be considered that most nodes "execute" those messages (as shown in figure 2 b: broadcast commit results, collect voting results for each node, prove if other replica nodes are honest).

(5) And (3) a response stage: each node returns the execution result of the transaction in the block to the client.

(3) Based on a detailed description of the PBFT consensus algorithm of fig. 2a and 2b, the following conclusions can be drawn: the pre-preparation phase and the commit phase are the more time-consuming phases of the three phases in the PBFT consensus algorithm.

1) In the pre-preparation phase, the proposed construction takes a long time. Among other things, actions to construct a proposal may include, but are not limited to: the transaction list T is obtained, the transaction list T is packed into a block B, the block B is serialized into a byte array M, a digest D of the M is generated, and the digest D is signed to obtain a proposal P.

2) In the commit phase, execution of the smart contract is time consuming.

In summary, in the PBFT consensus scheme, since one proposal needs to be constructed according to one chunk, one chunk needs to include Merkle root (Merkle root) of the execution result of the last chunk (parent chunk). Therefore, to construct a proposal needs to wait for the completion of the previous consensus, and the time consumption of the whole consensus process is long and the consensus efficiency is not high because the pre-preparation stage and the commit stage of the previous block are included.

(4) Based on the above analysis, embodiments of the present application propose a data processing scheme that can be applied to federated chains in blockchains. The general principle of this scheme is as follows: when the node of the block chain receives the consensus acknowledgement message of the proposal message, the block header can be extracted from the proposal message; then, searching a zone block corresponding to the zone head and an execution result of the transaction in the zone block in a cache manager, wherein the execution result of the transaction in the zone block and the zone block is stored in the cache manager before receiving the common identification information; next, the block header and the block body may be combined into a block, the block added to the blockchain, and the execution result of the transaction in the acquired block body written back to the state database of the blockchain.

Therefore, the method and the device can strip the zone blocks from the proposal message, reduce the size of the proposal message, facilitate the rapid construction of the proposal in the pre-preparation stage, reduce the time consumption of the pre-preparation stage, and improve the consensus efficiency; further, the zone block is executed in advance before the consensus confirmation message is received, and the zone block and the execution result of the transaction in the zone block are stored in the cache manager. When the consensus confirmation message of the proposal message is obtained, the execution result corresponding to the transaction executed in advance can be directly obtained from the cache manager, the transaction in the block body is not required to be executed again, the time consumption of the commit stage can be reduced, and the consensus efficiency is further improved.

It should be noted that, in the following specific embodiments of the present application, related data such as object information (for example, identity of an object) is related, and when the above embodiments of the present application are applied to specific products or technologies, permission or consent of the object needs to be obtained, and collection, use and processing of related data need to comply with related laws and regulations and standards of related countries and regions.

Based on the above description about the data processing scheme and system, the embodiment of the application provides a data processing method. Referring to fig. 3, fig. 3 is a flowchart of a data processing method according to an embodiment of the present application, where the data processing method may be applied to a blockchain (e.g., a federated chain), and may be performed by the above-mentioned blockchain node (e.g., a master node or a backup node in the federated chain), and for convenience of explanation, the data processing method will be described hereinafter by taking a computer device as an example. The data processing method may include the following steps S301 to S304:

s301: upon receiving the consensus acknowledgement message of the proposal message, a block header is extracted from the proposal message.

In one possible implementation, the process involved in constructing a proposal message is approximately: first, the computer device obtains a transaction list T (transaction list). The transaction list T may then be packaged into block B. Then, the block B may be serialized into a byte array M, where the byte array M may be a binary string, and the efficiency in the data processing process may be improved by serializing the block into a string form through a serialization operation. Further, the computer device generates a digest D of M and signs D (e.g., may be signed by a private key) to obtain proposal P. Wherein, the digest D of M may be generated by a digest algorithm, which may include, but is not limited to: secure hash algorithms (Secure Hash Algorithm, SHA), message authentication code algorithms (Message Authentication Codes, MAC), MD5 algorithms, and the like.

The proposal message in the embodiment of the application does not comprise a zone block and only comprises a zone head. Referring to fig. 4, fig. 4 is a schematic diagram of a proposal message according to an embodiment of the application. As shown in fig. 4, proposal messages may include, but are not limited to: tx Merkle Root (Merkle Root generated according to transaction), preHash (block header hash value of parent block of current block), preStateRoot (calculated by proposal message in the commit phase using Merkle algorithm according to contract execution result); transactionlist. It can be appreciated that the above mentioned information such as Tx Merkle Root, preHash, preStateRoot is stored in the block header of the block; the transaction list is stored into the block body of the block.

As shown in fig. 4, in the embodiment of the present application, the transaction list of the block in the proposal message (the transaction list is stored in the block body) is stripped from the proposal message, and because the data of the block in the block is relatively large, the size of the proposal message can be reduced by stripping the block from the proposal message, thereby shortening the construction time of the proposal message, facilitating the operations of rapid serialization, deserialization, signature verification, and the like of the proposal message, and improving the efficiency of the pre-preparation stage in the consensus process.

In one possible implementation, the computer device, before receiving the consensus acknowledgement message of the proposal message, further comprises performing the following flow: receiving k confirmation results sent by k nodes in the block chain aiming at the proposal message, wherein one node corresponds to one confirmation result, and k is a positive integer; and when the number of confirmation passes in the k confirmation results exceeds a first preset number threshold, confirming generation of a consensus confirmation message of the proposal message.

Specifically, as shown in fig. 2b, in the third stage (commit stage) of the PBFT consensus algorithm, any node in the blockchain may receive commit messages (acknowledge indication messages) sent by other nodes in the blockchain, and if any node receives 2f+1 commit messages (acknowledge indication messages), it may acknowledge that a consensus acknowledgement message for the proposal message was generated.

In one possible implementation, any one of the k nodes is referred to as a backup node when the above method is performed by a master node in a blockchain. The master node may also perform the following flow: firstly, acquiring proposal information, broadcasting the proposal information to k backup nodes in a block chain, so that any backup node in the k backup nodes performs voting processing on the proposal information, and obtaining a voting result, wherein k is a positive integer. Then, receiving k voting results sent by k backup nodes, and if the number of votes passing through the k voting results exceeds a first preset number threshold value, confirming to generate a confirmation indication message aiming at proposal information, wherein one backup node corresponds to one voting result; and broadcasting the confirmation indication message aiming at the proposal message to k backup nodes in the blockchain, so that any backup node in the k backup nodes confirms the confirmation indication message and obtains a confirmation result.

S302: searching a zone block corresponding to the zone head in the cache manager and executing results of the transactions in the zone block, wherein the zone block and the executing results of the transactions in the zone block are stored in the cache manager before receiving the common identification confirmation message.

In one possible implementation, the computer device, before receiving the consensus acknowledgement message of the proposal message, further comprises performing the following flow: first, a computer device obtains a block of blocks generated from a plurality of transactions obtained from a transaction pool. Then, the computer device executes the block body to obtain the execution result of the transaction in the block body. Next, the computer device writes the zone block, and the execution result of the transaction in the zone block, into the cache manager. And the execution result of the transaction in the block body and the block identification corresponding to the block body are stored in a correlated way. The block identifier corresponding to the block body may be a block hash (block hash).

Specifically, in the embodiment of the present application, the computer device executes the block body by calling the intelligent contract to execute the block body, so as to obtain a contract execution result, and the contract execution result is used as the execution result of the transaction in the block body. The following describes the specific execution process of executing the block body by calling the intelligent contract:

Referring to fig. 5, fig. 5 is a flow chart illustrating an execution process of an intelligent contract according to an embodiment of the application. As shown in fig. 5, the execution process of the smart contract may include the following steps S1 to S6:

s1, triggering contracts.

In particular implementations, the computer device may obtain a top-ranked transaction from a currently pending transaction pool and then trigger invocation of its corresponding smart contract based on the transaction.

S2, analyzing the transaction.

In specific implementation, the ethernet virtual machine analyzes transaction content of the transaction, and obtains information such as contract name, contract method, contract input and the like called by the transaction.

S3, loading storage information of the contract and byte codes of the contract.

In particular implementations, the ethernet virtual machine obtains corresponding contract byte codes and contract inputs from the transaction and status database.

S4, executing the contract.

In specific implementation, the contract code is executed in the Ethernet virtual machine to complete the business logic of the corresponding transaction.

S5, returning a result to update the state database.

In specific implementation, the Ethernet virtual machine writes the contract execution result back into the state database to complete the updating of the service state.

S6, manufacturing a Merck tree root and storing the root in the block.

In particular, when all transactions in the block have been performed, the system stores the hash digest of the current state of the state database as an authentication record in the blockchain.

Based on the execution flow of the transaction in the zone block by calling the intelligent contract shown in fig. 5, the execution result of the transaction in the zone block can be obtained. The association between the execution result of the transaction in the current tile and the tile may then be stored in a cache manager. Next, referring to fig. 6, fig. 6 is a schematic structural diagram of a cache manager according to an embodiment of the present application.

As shown in fig. 6, assuming that the currently executed block of the execution system (Executor) is block n+3, the corresponding execution result is obtained after the execution of the block n+3 by calling the smart contract based on the above description, and then the execution result of the transaction in the block n+3 is stored in the cache manager (Block cache manager). The cache manager further stores the execution result of the transaction in the block N, the execution result of the transaction in the block n+1, and the execution result of the transaction in the block n+2, which can be understood that the execution results of the transactions in the respective block are sequentially stored according to the execution sequence of the transactions in the corresponding block. For example, the transaction in zone block n+1 may be performed prior to the transaction in zone block n+2; as another example, the transaction in zone block n+2 may be performed prior to the transaction in zone block n+3.

In one possible implementation, the execution result of the transaction in the block in the cache manager is stored in association with a block identifier (e.g., block hash) corresponding to the block. Optionally, the cache manager may further store blocks, where the block, and the storage relationship between the execution result of the transaction in the block and the block identifier may be as shown in table 2 below:

TABLE 2 stored relationship between execution results of transactions in zone blocks and block identifications

Block identification	Zone block	Execution results of transactions in a block
			block hash1	Zone block 1	Execution result 1
block hash2	Zone block 2	Execution result 2
			block hash3	Zone block 3	Execution result 3
...	...	...

In one possible implementation, after extracting the block header from the proposal message, a corresponding block body may be found in the cache manager according to the block header, and then, based on the block body, an execution result of the transaction in the block body may be found in the cache manager. For example, the block header extracted from the currently received proposal message includes the following information: tx Merkle Root1, preHash1, preStateRoot1. Then, according to the Tx Merkle Root1, the block body corresponding to the block head can be found (because the Tx Merkle Root1 is obtained by computing the Merkle algorithm on the transaction in the block body), it can be understood that the Tx Merkle Root1 can be used as the block identifier of one block. Then, after the corresponding tile body is found (assuming that the tile body 1 is the tile body), the execution result (i.e., the execution result 1) of the transaction in the tile body corresponding to the tile body 1 may be found from the cache manager (e.g., the stored table 2).

In this way, since the transactions in the block are executed in advance, and the execution results of the transactions in the block are written into the cache manager. When receiving the consensus confirmation message comprising the proposal information of the block header corresponding to the block body, the execution result of the transaction in the block body which is executed in advance can be obtained directly from the cache manager without executing the transaction in the block body again, thereby greatly reducing the time consumption of the commit stage and improving the consensus efficiency.

S303: combining the block head and the block body into a block, adding the block to the block chain, and writing the searched execution result back to the state database of the block chain.

In one possible implementation, after the computer device finds the chunk, it may combine the chunk header and chunk into a complete chunk and add the chunk to the blockchain. And then, the computer equipment can also write the searched execution result corresponding to the current zone block back to the state database of the blockchain, so that the state database can realize the updating of the service state according to the execution result of the transaction in the latest zone block which is written currently. For example, the transactions included in the current zone block are: object a transfers m units of virtual resources to the account of object B. Then, after obtaining the execution result of the transaction and writing the result into the state database, the updating operation of the service state executed in the state database may include: deducting m units of virtual resources from the account of the object A, and adding m units of virtual resources to the account of the object B.

Referring to fig. 7, fig. 7 is an interaction flow diagram of a data processing method according to an embodiment of the present application. The data processing method can be applied to a alliance chain of a blockchain, and can be specifically executed by a blockchain node (a main node or a backup node) in the alliance chain. The data processing method may include the following steps S701 to S7010:

s701: a transaction request is obtained.

In one possible implementation, the master node may obtain a transaction request sent by the client. Optionally, the transaction request carries an identifier of the client, and the master node may acquire the identifier of the client after acquiring the transaction request sent by the client. The master node may then verify the client based on its identity, in particular, the verification may include, but is not limited to: security check, reliability check, etc. If the verification is passed, the master node responds to the transaction request and triggers execution of step S702.

By means of the method, the client is checked, and safety in the data processing process can be improved.

S702: a proposal message is constructed.

In one possible implementation, the process of constructing the proposal message by the master node may include: and generating a block header according to the transaction request, and then constructing a proposal message corresponding to the block header according to the block header. Specifically, generating the block header from the transaction request may include: when a transaction request is received, the transaction request can be checked, after the check is completed, transaction contents in the transaction request are stored in a memory pool, and a hash tree for recording the transaction contents is updated; and updating the update time stamp to the time of receiving the transaction request, trying different random numbers, calculating the characteristic value for a plurality of times (for example, calculating by using the SHA256 algorithm), and constructing to obtain the block header. Next, constructing a proposal message corresponding to the block header according to the block header may include: firstly, carrying out serialization processing on the block head to obtain a serialization byte array corresponding to the block head. Then, calculating the abstract of the serialized byte array, and carrying out signature processing on the abstract of the serialized byte array to obtain the proposal message corresponding to the block head.

For example, one or more transactions may be included in the transaction request (e.g., object a transfers m units of virtual resources to object B, or object a transfers n units of virtual resources to object B, object C, respectively, simultaneously). The master node may then serialize the various fields in each transaction, calculate a corresponding digest using a particular hash function (e.g., sha 256), and store the calculated digest in the proposal message.

S703: the proposal message is broadcast.

In one possible implementation manner, after the master node constructs the proposal message, the proposal message may be broadcast to k backup nodes in the blockchain, so that any one of the k backup nodes performs voting processing on the proposal message, and obtains a voting result, where k is a positive integer.

Specifically, the backup node may perform a deserialization operation, a signature verification (signature verification) operation, etc. on the proposal message after receiving the proposal message. If the proposal message passes the check, the voting result is voting success. If the proposal message is not checked to pass, the voting result is voting failure.

S704: and receiving the voting result sent by the backup node.

In one possible implementation, the master node may receive k voting results sent by k backup nodes. Wherein, a backup node corresponds to a voting result, and the voting result comprises voting success and voting failure.

S705: an acknowledgement indication message is generated.

Specifically, if the number of votes passing through the k voting results exceeds a second preset number threshold, the generation of a confirmation instruction message for the proposal message is confirmed. The second preset number threshold may be preset by the master node, or may be determined according to the number of nodes in the current blockchain. For example, in the PBFT consensus algorithm, the second preset number threshold may be 2f+1 (f is the number of bad nodes in the blockchain). That is, the prepare phase passes (i.e., the master node is honest), i.e., the commit phase is about to be entered.

S706: an acknowledgement indication message is broadcast.

In one possible implementation, the master node may broadcast an acknowledgement indication message for the proposal message to k backup nodes in the blockchain, so that any one of the k backup nodes performs acknowledgement processing on the acknowledgement indication message, and obtains an acknowledgement result.

S707: and receiving a confirmation result sent by the backup node.

In one possible implementation, the master node may receive k acknowledgement results sent by k backup nodes. Wherein, a backup node corresponds to a confirmation result, and the confirmation result comprises confirmation success and confirmation failure.

S708: a consensus acknowledgement message is generated and a block header is extracted from the proposal message.

Specifically, if the number of confirmation passes in the k confirmation results exceeds the first preset number threshold, confirmation is performed to generate a consensus confirmation message for the proposal message. The first preset number threshold may be preset by the master node, or may be determined according to the number of nodes in the current blockchain. In addition, the first preset number threshold may be the same as or different from the second preset number threshold. For example, in the PBFT consensus algorithm, the first preset number threshold and the second preset number threshold are the same, and may be 2f+1 (f is the number of bad nodes in the blockchain). Next, the master node may extract the block header from the proposal message. It should be noted that, in the execution process of extracting the block header from the proposal message, the process executed in step S301 in the embodiment of fig. 3 may be referred to, and the embodiments of the present application are not described herein again.

S709: searching a zone block corresponding to the zone head in a cache manager and executing results of transactions in the zone block.

Wherein the block and the execution result of the transaction in the block are stored in the cache manager before the consensus confirmation message is received.

S7010: combining the block head and the block body into a block, adding the block to the block chain, and writing the searched execution result back to the state database of the block chain.

It should be noted that, the specific flow executed by the computer device in steps S709-S7010 may refer to the specific flow executed by the computer device in steps S302-S303 in the embodiment of fig. 3, and the embodiments of the present application are not described herein again.

It should be noted that, the data processing method provided by the embodiment of the present application may be applied to a federation chain, in which, because nodes are all admitted and trusted, the number of commonly-owned blocks in each round may be properly increased, that is, a master node may continuously generate N block volumes, where N is a positive integer. Next, a detailed description will be given by taking the case that the master node generates any zone block:

in particular, the execution of transactions in a block will be described in detail in connection with FIG. 8. Referring to fig. 8, fig. 8 is an interactive flowchart of a transaction execution process according to an embodiment of the present application. As shown in fig. 8, the interaction flow chart may include the following steps S801 to S805:

s801, acquiring a plurality of transactions from a transaction pool, and generating a zone block according to the plurality of transactions.

In one possible implementation, the master node may obtain a plurality of transactions from the transaction pool, sort the plurality of transactions to obtain a transaction list, and then generate the zone block according to the transaction list. The sorting process may be performed such that the generation time stamp of each transaction is sorted from far to near, for example, the generation time stamp corresponding to the transaction 1 is 9:00, the corresponding generation timestamp of transaction 2 is 9:01, transaction 1 may be placed in front of transaction 2.

S802, broadcasting area block.

In particular, the master node broadcasts the zone block to k backup nodes in the blockchain, so that each backup node in the k backup nodes executes the zone block after receiving the zone block, and an execution result of the transaction in the zone block is obtained.

In one possible implementation manner, after the backup node receives the block body sent by the master node, the node identifier of the master node may be obtained, then the master node is checked according to the node identifier, and if the check is passed, the block body is triggered to be executed, and the execution result of the transaction in the block body is obtained. In this way, the backup node executes the block body sent by the master node after the master node passes the verification, so that the security in the data processing process can be improved.

S803, executing the zone block to obtain an execution result of the transaction in the zone block.

In one possible implementation, the master node may call the intelligent contract execution area block to obtain a contract execution result, and use the contract execution result as an execution result of a transaction in the block. The specific execution process of calling the smart contract to execute the zone block may refer to the execution process of the smart contract mentioned in fig. 5 in the above embodiment, and the embodiments of the present application are not described herein again.

S804, storing the execution result of the transaction in the zone block into a cache manager.

In particular, when the execution result of the transaction in one block is obtained, the execution result of the transaction in the block may be stored in the cache manager of the node. Wherein, the execution result of the transaction in the block body and the block identification corresponding to the block body are associated and stored in the buffer manager.

S805, returning the execution result of the transaction in the zone block to the client.

It should be noted that, in the embodiment of the present application, an example of constructing one zone block is described correspondingly, it may be understood that the master node may be configured as needed to continuously construct N zone blocks, where the specific execution steps in the embodiment of fig. 8 may refer to the execution steps corresponding to any one of the N zone blocks. Referring to fig. 9, fig. 9 is a flowchart of another data processing method according to an embodiment of the application. As shown in fig. 9, assuming that the current proposal message is proposal N, in the consensus process (pre-preparation phase, confirmation phase) and response phase for proposal N, the master node (e.g., node 1) can perform construction of zone block n+1, zone block n+2..zone block n+11 simultaneously, and perform broadcasting and execution of zone block. In this way, it can be seen that, in the consensus process for proposal N, transactions in each zone block of block n+1, block n+2..and the like are executed in advance, and when a consensus confirmation message (confirmation stage) of proposal n+1 (proposal message corresponding to block n+1) is acquired, the transactions in zone block n+1 are executed in advance, so that it is not necessary to execute zone block n+1 in real time, and the transactions in zone block are directly acquired from the cache manager, and the time consumption of the commit stage is greatly reduced by executing transactions in advance, so that the consensus efficiency can be improved.

In the embodiment of the application, the block body is constructed in advance, the transaction in the block body is executed, the next block body is constructed and executed without waiting for the transaction in the previous block body to be executed, thus the block body can be broadcast out in advance, the transaction in the block body is verified in advance, and the transaction in the block body is executed in advance, so that the execution result is obtained. In this way, consensus efficiency can be improved, and eventually, performance and throughput of the entire blockchain can be improved.

Referring to fig. 10, fig. 10 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing apparatus 1000 is applicable to the computer device in the foregoing embodiment. The data processing apparatus 1000 may be a computer program (comprising program code) running in a computer device, for example the data processing apparatus 1000 is an application software; the network configuration management device may be used to execute the corresponding steps in the data processing method provided by the embodiment of the present application. The data processing apparatus 1000 may include:

an obtaining unit 1001, configured to extract a block header from a proposal message when receiving a consensus acknowledgement message of the proposal message;

A processing unit 1002, configured to search a zone block corresponding to the zone header in the cache manager, and an execution result of a transaction in the zone block, where the zone block and the execution result of the transaction in the zone block are stored in the cache manager before receiving the consensus confirmation message;

the processing unit 1002 is further configured to combine the block header and the block body into a block, add the block to the blockchain, and write back the found execution result to the state database of the blockchain.

In one possible implementation, before the obtaining unit 1001 receives the consensus acknowledgement message of the proposal message, the processing unit 1002 is further configured to:

In one possible implementation, the above method is performed by a master node in a blockchain; any one of the k nodes is referred to as a backup node; the processing unit 1002 is further configured to perform the following operations:

In one possible implementation, the above method is performed by any one of the backup nodes in the blockchain; the processing unit 1002 is further configured to perform the following operations:

In one possible implementation, the processing unit 1002 obtains the proposal message for performing the following operations:

In one possible implementation, the transaction request carries an identifier of the client; the processing unit 1002 is further configured to, after acquiring the transaction request sent by the client, perform the following operations:

acquiring an identifier of a client in a transaction request;

In one possible implementation, the processing unit 1002 constructs a proposal message corresponding to the block header according to the block header, and is configured to perform the following operations:

In one possible implementation, the above method is performed by a master node of a blockchain; the processing unit 1002, after acquiring the zone block, is further configured to:

In one possible implementation, when the above method is performed by a backup node in a blockchain, the processing unit 1002 obtains a block of regions for performing the following operations:

receiving a zone block sent by a main node;

Referring to fig. 11, fig. 11 is a schematic structural diagram of a computer device according to an embodiment of the application. The computer device 1100 is configured to perform the steps performed by the computer device in the foregoing method embodiment, where the computer device 1100 includes: one or more processors 1110; one or more input devices 1120, one or more output devices 1130, and a memory 1140. The processor 1110, input device 1120, output device 1130, and memory 1140 are connected by a bus 1150. Memory 1140 is used to store a computer program comprising program instructions, and processor 1110 is used to invoke the program instructions stored in memory 1140 to perform the following operations:

In one possible implementation, before receiving the consensus acknowledgement message of the proposal message, the processor 1110 is further configured to:

In one possible implementation, the above method is performed by a master node in a blockchain; any one of the k nodes is referred to as a backup node; the processor 1110 is also configured to perform the following:

In one possible implementation, the above method is performed by any one of the backup nodes in the blockchain; the processor 1110 is also configured to perform the following:

In one possible implementation, the processor 1110 obtains the proposal message for performing the following operations:

In one possible implementation, the transaction request carries an identifier of the client; the processor 1110, after obtaining the transaction request sent by the client, is further configured to:

acquiring an identifier of a client in a transaction request;

In one possible implementation, the processor 1110 constructs a proposal message corresponding to the block header according to the block header, and is configured to perform the following operations:

In one possible implementation, the above method is performed by a master node of a blockchain; after acquiring the zone block, the processor 1110 is further configured to:

In one possible implementation, when the above method is performed by a backup node in a blockchain, the processor 1110 obtains a block of regions for performing the following operations:

receiving a zone block sent by a main node;

Furthermore, it should be noted here that: the embodiment of the present application further provides a computer storage medium, in which a computer program is stored, and the computer program includes program instructions, when executed by a processor, can perform the method in the corresponding embodiment, so that a detailed description will not be given here. For technical details not disclosed in the embodiments of the computer storage medium according to the present application, please refer to the description of the method embodiments of the present application. As an example, the program instructions may be deployed on one computer device or executed on multiple computer devices at one site or distributed across multiple sites and interconnected by a communication network.

According to one aspect of the present application, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device can perform the method in the foregoing corresponding embodiment, and therefore, a detailed description will not be given here.

Those skilled in the art will appreciate that implementing all or part of the above-described embodiment methods may be accomplished by way of a computer program for instructing relevant hardware, where the program may be stored on a computer readable storage medium, and where the program, when executed, may comprise the embodiment flow of the above-described methods. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a random-access Memory (Random Access Memory, RAM), or the like.

The foregoing disclosure is illustrative of the present application and is not to be construed as limiting the scope of the application, which is defined by the appended claims.

Claims

1. A method of data processing, comprising:

extracting a block header from a proposal message when receiving a consensus acknowledgement message of the proposal message;

searching a zone block corresponding to the zone head and an execution result of the transaction in the zone block in a cache manager, wherein the execution result of the transaction in the zone block and the zone block is stored in the cache manager before receiving a common identification confirmation message;

Combining the block head and the block body into a block, adding the block to a block chain, and writing the searched execution result back to a state database of the block chain.

2. The method of claim 1, wherein prior to receiving the consensus acknowledgement message of the proposal message, further comprising:

acquiring a block body, wherein the block body is generated according to a plurality of transactions acquired from a transaction pool;

and the execution results of the transactions in the block body and the block identifications corresponding to the block body are stored in a correlated manner.

3. The method of claim 1, wherein prior to receiving the consensus acknowledgement message of the proposal message, further comprising:

receiving k confirmation results sent by k nodes in the blockchain aiming at the proposal message, wherein one node corresponds to one confirmation result, and k is a positive integer;

and when the number of confirmation passes in the k confirmation results exceeds a first preset number threshold, confirming to generate a consensus confirmation message of the proposal message.

4. The method of claim 3, wherein the method, when executed by a master node in a blockchain; any one of the k nodes is called a backup node; the method further comprises the steps of:

acquiring proposal information, broadcasting the proposal information to k backup nodes in a block chain, so that any backup node in the k backup nodes performs voting processing on the proposal information, and obtaining a voting result;

receiving k voting results sent by the k backup nodes, and if the number of votes passing through the k voting results exceeds a second preset number threshold, confirming to generate a confirmation indication message aiming at the proposal message, wherein one backup node corresponds to one voting result;

5. The method of claim 4, wherein the method, when executed by any one of the backup nodes in the blockchain; the method further comprises the steps of:

receiving proposal information sent by the master node, and carrying out voting treatment on the proposal information to obtain a voting result;

Sending the voting result to the master node so that the master node generates a confirmation indication message for the proposal message according to the voting result;

receiving a confirmation indication message sent by the master node, and performing confirmation processing on the confirmation indication message to obtain a confirmation result;

6. The method of claim 4, wherein the acquiring proposal message comprises:

7. The method of claim 6, wherein the transaction request carries an identification of the client; after the transaction request sent by the client is obtained, the method further comprises the following steps:

acquiring an identifier of the client in the transaction request;

8. The method of claim 6, wherein constructing the proposal message corresponding to the block header from the block header comprises:

9. The method of claim 2, wherein the method, when executed by a master node in a blockchain; after the obtaining the zone block, further comprising:

broadcasting the block body to k backup nodes in a block chain, so that each backup node in the k backup nodes executes the block body after receiving the block body, and obtaining an execution result of the transaction in the block body.

10. The method of claim 9, wherein the obtaining the region block when the method is performed by a backup node of a blockchain comprises:

receiving the block body sent by the master node;

and acquiring a node identifier of the master node, checking the master node according to the node identifier, and triggering the execution of the block body and obtaining the execution result of the transaction in the block body if the check is passed.

11. A data processing apparatus, comprising:

An obtaining unit, configured to extract a block header from a proposal message when receiving a consensus acknowledgement message of the proposal message;

the processing unit is used for searching a zone block corresponding to the zone head in the cache manager and executing results of transactions in the zone block, wherein the executing results of the transactions in the zone block and the zone block are stored in the cache manager before receiving the common identification information;

the processing unit is further configured to combine the block header and the block body into a block, add the block to a blockchain, and write the found execution result back to a state database of the blockchain.

12. A computer device, comprising:

a processor adapted to execute a computer program;

a computer readable storage medium having stored therein a computer program which, when executed by the processor, implements the data processing method according to any of claims 1-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, cause the processor to perform the data processing method according to any of claims 1-10.

14. A computer program product, characterized in that the computer program product comprises a computer program adapted to be loaded by a processor and to perform the data processing method according to any of claims 1-10.