Data processing method, apparatus and device, medium, product

Abstract

The application provides a data processing method, device and equipment, medium and product. The method comprises the following steps: extracting a block header from a proposal message when a consensus confirmation message of the proposal message is received; searching, in a cache manager, a block body corresponding to the block header and an execution result of a transaction in the block body, wherein the block body and the execution result of the transaction in the block body have been stored in the cache manager before the consensus confirmation message is received; combining the block header and the block body into a block, adding the block to a block chain, and writing the found execution result back to a state database of the block chain. The application can separate the block body from the proposal message, thereby improving the consensus efficiency in the block chain.

Description

Technical Field

[0001] This 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 Technology

[0002] The Practical Byzantine Fault Tolerance (PBFT) algorithm is a commonly used consensus algorithm in consortium blockchains.

[0003] The PBFT consensus algorithm mainly involves three phases: pre-prepare, prepare, and commit. In practice, after receiving the consensus confirmation message for the proposal message during the commit phase, the transactions in the proposal message need to be executed. Typically, transaction execution takes considerable time, resulting in a lengthy consensus process and low consensus efficiency. Therefore, improving consensus efficiency is a pressing technical problem that needs to be addressed. Summary of the Invention

[0004] This application provides a data processing method, apparatus, computer device, computer-readable storage medium, and computer program product that can separate the block body from the proposal message, thereby improving the consensus efficiency in the blockchain.

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

[0006] Upon receiving the consensus confirmation message for the proposal message, extract the block header from the proposal message;

[0007] The cache manager searches for the block body corresponding to the block header, as well as the execution results of the transactions in the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager.

[0008] The block header and block body are combined into a block, the block is added to the blockchain, and the found execution results are written back to the blockchain's state database.

[0009] On one hand, embodiments of this application provide a data processing apparatus, the apparatus comprising:

[0010] The acquisition unit is used to extract the block header from the proposal message when a consensus confirmation message is received.

[0011] The processing unit is used to find the block body corresponding to the block header and the execution results of the transactions in the block body in the cache manager. Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager.

[0012] The processing unit is also used to combine the block header and block body into a block, add the block to the blockchain, and write the found execution results back to the blockchain's state database.

[0013] In one possible implementation, before the acquisition unit receives the consensus confirmation message of the proposal message, the processing unit is also used to perform the following operations:

[0014] Obtain the block body, which is generated from multiple transactions obtained from the transaction pool;

[0015] Execute the block body to obtain the execution results of the transactions within the block body;

[0016] Write the block body and the execution results of the transactions in the block body to the cache manager;

[0017] The execution results of transactions within the block body and the block identifier corresponding to the block body are stored in association.

[0018] In one possible implementation, before the acquisition unit receives the consensus confirmation message of the proposal message, the processing unit is also used to perform the following operations:

[0019] Receive k confirmation results from k nodes in the blockchain for the proposal message, with one confirmation result corresponding to one node, and k being a positive integer;

[0020] When the number of accepted confirmations out of k received confirmations exceeds a first preset threshold, a consensus confirmation message for the proposal message is generated.

[0021] In one possible implementation, when the above method is executed by the master node in the blockchain; any one of the k nodes is called a backup node; the processing unit is also used to perform the following operations:

[0022] Obtain the proposal message and broadcast it to k backup nodes in the blockchain, so that any one of the k backup nodes can vote on the proposal message and obtain the voting result;

[0023] Receive k voting results from k backup nodes. If the number of votes in the k voting results exceeds the second preset threshold, then confirm the generation of a confirmation instruction message for the proposal message. One backup node corresponds to one voting result.

[0024] The confirmation instruction message is broadcast to k backup nodes in the blockchain, so that any one of the k backup nodes can confirm the confirmation instruction message and obtain the confirmation result.

[0025] In one possible implementation, when the above method is executed by any backup node in the blockchain, the processing unit is also configured to perform the following operations:

[0026] Receive proposal messages sent by the master node, process the proposal messages through voting, and obtain the voting results;

[0027] The voting results are sent to the master node, which then generates an acknowledgment message for the proposal based on the voting results.

[0028] Receive the confirmation instruction message sent by the master node, process the confirmation instruction message, and obtain the confirmation result;

[0029] The confirmation result is sent to the master node, so that the master node generates a consensus confirmation message for the proposal message.

[0030] In one possible implementation, the processing unit receives the proposal message and performs the following operations:

[0031] Obtain the transaction request sent by the client and generate a block header based on the transaction request;

[0032] Construct the proposal message corresponding to the block header based on the block header.

[0033] In one possible implementation, the transaction request carries the client's identifier; after obtaining the transaction request sent by the client, the processing unit is also used to perform the following operations:

[0034] Retrieve the client's identifier from the transaction request;

[0035] The client is verified based on its identifier. If the verification passes, the step of generating a block header based on the transaction request is triggered.

[0036] In one possible implementation, the processing unit constructs a proposal message corresponding to the block header based on the block header, which is used to perform the following operations:

[0037] The block header is serialized to obtain the serialized byte array corresponding to the block header;

[0038] Calculate the digest of the serialized byte array and sign the digest to obtain the proposal message corresponding to the block header.

[0039] In one possible implementation, when the above method is executed by the blockchain's master node, the processing unit, after obtaining the block body, is also used to perform the following operations:

[0040] The block body is broadcast to k backup nodes in the blockchain, so that each of the k backup nodes executes the block body after receiving it and obtains the execution result of the transactions in the block body.

[0041] In one possible implementation, when the above method is executed by a backup node in the blockchain, the processing unit obtains the block body and performs the following operations:

[0042] Receive block bodies sent by the master node;

[0043] The steps include obtaining the node identifier of the master node, verifying the master node based on the node identifier, and if the verification passes, triggering the execution of the block body and obtaining the execution results of the transactions in the block body.

[0044] On one hand, embodiments of this application provide a computer device, which includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the data processing method described above.

[0045] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when read and executed by a processor of a computer device, causes the computer device to perform the aforementioned data processing method.

[0046] On one hand, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned data processing method.

[0047] In this embodiment, when a blockchain node receives a consensus confirmation message for a proposal message, it can extract the block header from the proposal message. Then, it searches the cache manager for the block body corresponding to the block header and the execution results of the transactions within the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions within it have already been stored in the cache manager. Next, the block header and block body can be combined into a block, added to the blockchain, and the execution results of the transactions within the block body can be written back to the blockchain's state database. Therefore, this application can separate the block body from the proposal message, reducing the size of the proposal message and facilitating rapid proposal construction in the pre-prepare phase, reducing the time consumed in the pre-prepare phase, and thus improving consensus efficiency. Furthermore, before receiving the consensus confirmation message, the block body is executed in advance, and the execution results of the block body and the transactions within it are stored in the cache manager. When a consensus confirmation message for a proposal is received, the execution results of transactions that have already been executed can be retrieved directly from the cache manager. There is no need to execute the transactions in the block body again, which can reduce the time spent in the commit phase and further improve consensus efficiency. Attached Figure Description

[0048] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1a This is a schematic diagram of the structure of a blockchain system provided in an embodiment of this application;

[0050] Figure 1b This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0051] Figure 1c This is a schematic diagram of a block generation process provided in an embodiment of this application;

[0052] Figure 2a This is a flowchart illustrating the principle of a consensus algorithm provided in an embodiment of this application;

[0053] Figure 2b This is a flowchart illustrating the execution of a consensus algorithm provided in an embodiment of this application;

[0054] Figure 3 This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0055] Figure 4This is a schematic diagram of a proposal message provided in an embodiment of this application;

[0056] Figure 5 This is a flowchart illustrating the execution process of a smart contract provided in an embodiment of this application;

[0057] Figure 6 This is a schematic diagram of the structure of a cache manager provided in an embodiment of this application;

[0058] Figure 7 This is a schematic diagram of the interaction flow of a data processing method provided in an embodiment of this application;

[0059] Figure 8 This is an interactive flowchart illustrating the execution process of a transaction, as provided in an embodiment of this application.

[0060] Figure 9 This is a flowchart illustrating another data processing method provided in an embodiment of this application;

[0061] Figure 10 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0062] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0063] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0064] The data processing solution in this application can be combined with blockchain technology. The following section provides a detailed introduction to the blockchain technology involved in the data processing solution provided in this application:

[0065] The system involved in the embodiments of this application can be a distributed system formed by connecting clients and multiple nodes (any form of computing device accessing the network, such as servers and terminal devices) through network communication. The following is a reference to the appendix... Figure 1a -Appendix Figure 1c This section provides an introduction to blockchain-related technologies.

[0066] I. Blockchain System:

[0067] Please see Figure 1a , Figure 1a This is a schematic diagram of the structure of a blockchain system provided in an embodiment of this application. Figure 1aThe blockchain system shown can be a data sharing system 100, which refers to a system for data sharing between nodes. This data sharing system 100 can include multiple nodes 101, which can refer to various clients within the data sharing system. Each node 101, during normal operation, can receive input information and maintain shared data within the data sharing system based on the received input information. To ensure information interoperability within the data sharing system, information connections can exist between each node, allowing for information transmission between nodes. For example, when any node in the data sharing system receives input information, other nodes in the system obtain this input information according to a consensus algorithm and store it as data in the shared data, ensuring consistency of data stored on all nodes in the data sharing system.

[0068] Each node in the data sharing system has a corresponding node identifier, and each node can also store the node identifiers of other nodes in the data sharing system. This allows for the subsequent broadcasting of generated blocks to other nodes in the data sharing system based on their node identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 only uses IP addresses as an example.

[0069] Table 1. Node Identifier List

[0070] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N xx.xx.xx.xx

[0071] It should be noted that, Figure 1a Any node in the blockchain system shown can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as 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 big data and artificial intelligence platforms, etc.

[0072] Figure 1aAny node in the blockchain system shown can also be, but is not limited to: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), smart voice interaction devices, in-vehicle terminals, roadside devices, aircraft, wearable devices, smart home appliances, or wearable devices with network configuration management functions such as smartwatches, smart bracelets, and pedometers, etc.

[0073] II. The Structure of Blockchain:

[0074] Each node in the data-sharing system stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1b , Figure 1b This is a schematic diagram of a blockchain structure provided in an embodiment of this application. For example... Figure 1b The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block of the blockchain is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0075] III. The process of generating blocks:

[0076] When generating the individual blocks in the blockchain, see Figure 1c , Figure 1c This is a schematic diagram of a block generation process provided in an embodiment of this application. When a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates the hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers to calculate the feature value multiple times, so that the calculated feature value can satisfy the following formula:

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

[0078] In the above formula, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0079] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node where the blockchain resides sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes in the data sharing system. The other nodes then verify the newly generated block and add it to their stored blockchain after verification.

[0080] IV. Blockchain Consensus:

[0081] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Blockchain can be categorized into public blockchains, consortium blockchains, and private blockchains. Commonly used consensus algorithms in blockchain include, but are not limited to: Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT).

[0082] This application's embodiments mainly involve the PBFT consensus algorithm in consortium blockchains. Next, in conjunction with... Figures 2a-2b This article provides an introduction to the PBFT algorithm, which is commonly used in consortium blockchains.

[0083] (1) First, combined with Figure 2a This section provides a brief introduction to the principles of the PBFT consensus algorithm. Please refer to [link / reference]. Figure 2a , Figure 2a This is a flowchart illustrating the principle of a consensus algorithm provided in an embodiment of this application.

[0084] 1) The participants in the PBFT consensus algorithm are mainly divided into Leader nodes (primary nodes, such as node 1) and Replica nodes (backup nodes, such as node 2, node 3, and node 4). Among them:

[0085] Leader node: Primarily responsible for packaging transactions into blocks and then initiating consensus proposal messages based on the blocks. Each round of consensus involves one leader node, which will switch every round to prevent the leader node from acting maliciously and packaging fake blocks.

[0086] Replica: Replica nodes are primarily responsible for participating in the block consensus process. There are multiple replica nodes in each round, and they all exhibit the same behavior.

[0087] 2) The PBFT consensus algorithm mainly consists of three phases: the pre-prepare phase, the prepare phase, and the commit phase.

[0088] Pre-prepare phase: Executed by the leader node, this phase primarily involves packaging transactions into blocks and then signing them to obtain signed blocks. Next, the proposal, comprised of the signed blocks, can be broadcast to other consensus nodes (replica nodes).

[0089] Prepare phase: Each consensus node (replica node) votes on the proposals it receives. When a proposal receives votes from more than 2 / 3 of the consensus nodes across the network, it enters the commit phase.

[0090] Commit phase: Execute the block, and store the block header, transactions (block body), execution results, etc. into the ledger.

[0091] (2) Then, combined Figure 2b This section provides a detailed overview of the specific processes involved in each stage of the PBFT consensus algorithm. Please refer to [link / reference]. Figure 2b , Figure 2b This is a flowchart illustrating the execution of a consensus algorithm according to an embodiment of this application. Figure 2b As shown, executing the PBFT consensus algorithm mainly includes the following steps:

[0092] ① Request phase: The client sends a transaction request to the leader node (e.g., node 1).

[0093] ②Pre-prepare phase: The leader node is responsible for collecting transactions sent by clients, packaging them into blocks, serializing and signing the blocks, and sending the signature and blocks as a proposal to other replica nodes (e.g., ...). Figure 2b The steps shown are: constructing a proposal, including block production, serialization, signing, and broadcasting the proposal.

[0094] ③ Prepare Phase: After receiving the proposal message broadcast by the leader node, the replica nodes deserialize it into a proposal, verify the signature, and vote on the received proposal to obtain the voting result. If any node in the blockchain receives 2f+1 prepare messages (f is the number of malicious nodes in the blockchain), it means that a majority of nodes have agreed to the proposal, and the process enters the commit phase. It is understandable that the voting result can include passing and failing. When the voting result is passing, the message receiving this voting result can also be called a prepare message (e.g., ...). Figure 2b As shown: broadcasting the voting results on the proposal, collecting the voting results, and proving whether the leader node is honest.

[0095] ④ Commit Phase: Each node broadcasts a commit message. If any node in the blockchain receives 2f+1 commit messages, then it can be considered that a majority of nodes have "executed" these messages (e.g., ...). Figure 2b As shown in the diagram: broadcasting the submission results, collecting the voting results from each node, and proving whether other replica nodes are honest.

[0096] ⑤ Response phase: Each node returns the execution results of the transactions in the block to the client.

[0097] (3) Based on Figure 2a and Figure 2b A detailed introduction to the PBFT consensus algorithm leads to the following conclusions: the pre-prepare and commit phases are the most time-consuming of the three phases in the PBFT consensus algorithm.

[0098] 1) In the pre-prepare stage, the construction of the proposal takes a relatively long time. The actions for constructing the proposal may include, but are not limited to: obtaining a transaction list T, packaging the transaction list T into a block B, serializing the block B into a byte array M, generating a digest D of M, and signing D to obtain the proposal P.

[0099] 2) During the commit phase, the execution of smart contracts is relatively time-consuming.

[0100] In summary, in the PBFT consensus scheme, because a proposal needs to be constructed based on a block, and a block needs to include the Merkle root of the execution result of the previous block (parent block), constructing a proposal requires waiting for the completion of the previous round of consensus. Since this includes the pre-prepare and commit phases of the previous block, the entire consensus process is time-consuming and inefficient.

[0101] (4) Based on the above analysis, this application proposes a data processing scheme that can be applied to consortium blockchains. The general principle of the scheme is as follows: When a blockchain node receives a consensus confirmation message for a proposal message, it can extract the block header from the proposal message; then, it searches the cache manager for the block body corresponding to the block header and the execution results of the transactions in the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager; next, the block header and block body can be combined into a block, the block can be added to the blockchain, and the execution results of the transactions in the obtained block body can be written back to the blockchain's state database.

[0102] Therefore, this application demonstrates that the block body can be separated from the proposal message, reducing the size of the proposal message and facilitating rapid proposal construction during the pre-prepare phase, thus reducing the time consumed in the pre-prepare phase and improving consensus efficiency. Furthermore, before receiving the consensus confirmation message, the block body is executed in advance, and the execution results of the block body and its transactions are stored in the cache manager. When the consensus confirmation message for the proposal message is received, the execution results corresponding to the pre-executed transactions can be directly retrieved from the cache manager without re-executing the transactions in the block body, reducing the time consumed in the commit phase and further improving consensus efficiency.

[0103] It should be noted that in the subsequent specific embodiments of this application, when data related to object information (such as the object's identity) is applied to specific products or technologies, permission or consent from the object is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0104] Based on the above description of the data processing scheme and system, this application proposes a data processing method. See also... Figure 3 As shown, Figure 3This is a flowchart illustrating a data processing method provided in an embodiment of this application. This data processing method can be applied to a blockchain (e.g., a consortium blockchain) and can be executed by the aforementioned blockchain nodes (e.g., the master node or backup node in a consortium blockchain). For ease of explanation, the following description will use a computer device executing this data processing method as an example. The data processing method may include the following steps S301 to S304:

[0105] S301: When a consensus confirmation message for a proposal message is received, the block header is extracted from the proposal message.

[0106] In one possible implementation, the process of constructing a proposal message roughly involves the following steps: First, the computer device obtains a transaction list T. Then, the transaction list T can be packaged into a block B. Next, block B can be serialized into a byte array M, where the byte array M can be a binary string. Serializing the block into a string format improves efficiency in the data processing. Further, the computer device generates a digest D of M and signs D (e.g., using a private key) to obtain the proposal P. The digest D of M can be generated using a digest algorithm, which may include, but is not limited to, Secure Hash Algorithm (SHA), Message Authentication Code (MAC), MD5, etc.

[0107] The proposal message in this embodiment does not include the block body, but only the block header. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of a proposal message provided in an embodiment of this application. For example... Figure 4 As shown, the proposal message may include, but is not limited to: TxMerkle Root (the Merkle root generated based on the transactions), PreHash (the block header hash of the current block's parent block), PreStateRoot (calculated using the Merkle algorithm during the commit phase of the proposal message based on the contract execution result); and a transaction list. It is understood that the aforementioned TxMerkle Root, PreHash, and PreStateRoot information are stored in the block header; the transaction list is stored in the block body.

[0108] like Figure 4As shown, in this embodiment of the application, the transaction list of the block in the proposal message (the transaction list is stored in the block body) is separated from the proposal message. Since the block body accounts for a large proportion of the data in the block, by separating the block body from the proposal message through this application, the size of the proposal message can be reduced, thereby shortening the construction time of the proposal message. This is beneficial for the rapid serialization, deserialization, signing, and verification of the proposal message, thereby improving the efficiency of the pre-prepare stage in the consensus process.

[0109] In one possible implementation, before receiving the consensus confirmation message for the proposal message, the computer device further includes performing the following process: receiving k confirmation results sent by k nodes in the blockchain for the proposal message, with one node corresponding to one confirmation result, and k being a positive integer; when the number of confirmed results received exceeds a first preset threshold, confirming and generating the consensus confirmation message for the proposal message.

[0110] Specifically, please see Figure 2b As shown, in the third phase (commit phase) of the PBFT consensus algorithm, any node in the blockchain can receive commit messages (confirmation indication messages) sent by other nodes in the blockchain. If any node receives 2f+1 commit messages (confirmation indication messages), it can confirm the consensus confirmation message for generating the proposal message.

[0111] In one possible implementation, when the above method is executed by the master node in the blockchain, any one of the k nodes is called a backup node. The master node can also execute the following process: First, it obtains the proposal message and broadcasts it to the k backup nodes in the blockchain, so that any one of the k backup nodes can vote on the proposal message and obtain a voting result, where k is a positive integer. Then, it receives the k voting results sent by the k backup nodes. If the number of votes in the k voting results exceeds a first preset threshold, it confirms the generation of a confirmation instruction message for the proposal message, with one backup node corresponding to one voting result; it then broadcasts the confirmation instruction message for the proposal message to the k backup nodes in the blockchain, so that any one of the k backup nodes can confirm the confirmation instruction message and obtain a confirmation result.

[0112] S302: Locate the block body corresponding to the block header and the execution results of the transactions in the block body in the cache manager. Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager.

[0113] In one possible implementation, before receiving the consensus confirmation message for the proposal message, the computer device further includes the following steps: First, the computer device obtains a block body, which is generated based on multiple transactions obtained from the transaction pool. Then, the computer device executes the block body to obtain the execution results of the transactions within it. Next, the computer device writes the block body and the execution results of the transactions within it to a cache manager. The execution results of the transactions within the block body and the block identifier corresponding to the block body are stored in association. The block identifier corresponding to the block body can be a block hash.

[0114] Specifically, in this embodiment, the computer device can execute the block by calling a smart contract, obtain the contract execution result, and use the contract execution result as the execution result of the transactions in the block. The specific execution process of calling the smart contract to execute the block will be described below:

[0115] Please see Figure 5 , Figure 5 This is a flowchart illustrating the execution process of a smart contract according to an embodiment of this application. Figure 5 As shown, the execution process of this smart contract may include the following steps S1-S6:

[0116] S1, trigger the contract.

[0117] In practice, the computer device can obtain the top-ranked transactions from the pool of transactions currently pending, and then trigger the invocation of its corresponding smart contract based on the transaction.

[0118] S2, Analyze the transaction.

[0119] In practice, the Ethereum Virtual Machine analyzes the transaction content and obtains information such as the contract name, contract method, and contract input called by the transaction.

[0120] S3, Load the contract's storage information and the contract's bytecode.

[0121] In practice, the Ethereum Virtual Machine obtains the corresponding contract bytecode and contract inputs from the transaction and state database.

[0122] S4, Execute the contract.

[0123] In practice, the contract code is executed in the Ethereum Virtual Machine to complete the business logic of the corresponding transaction.

[0124] S5. Return the results and update the status database.

[0125] In practice, the Ethereum Virtual Machine writes the contract execution results back to the state database to update the business state.

[0126] S6. Create the Merkel tree root and store it in the block.

[0127] In practice, once all transactions in a block have been executed, the system stores the hash digest of the current state in the state database as an authentication record in the blockchain.

[0128] based on Figure 5 The illustrated process involves invoking a smart contract to execute transactions within a block, yielding the execution results. These results can then be associated with the block itself and stored in a cache manager. Please refer to the following section for further information. Figure 6 , Figure 6 This is a schematic diagram of the structure of a cache manager provided in an embodiment of this application.

[0129] like Figure 6 As shown, assuming the Executor is currently executing block N+3, based on the above description, after executing block N+3 by calling a smart contract, the execution results are obtained, and then the execution results of the transactions in block N+3 are stored in the Block Cache Manager. This cache manager also stores the execution results of transactions in block N, block N+1, and block N+2. It can be understood that the execution results of transactions in each block are stored sequentially according to the execution order of the transactions within that block. For example, transactions in block N+1 can be executed before transactions in block N+2; similarly, transactions in block N+2 can be executed before transactions in block N+3.

[0130] In one possible implementation, the execution result of a transaction within a block body is stored in the cache manager in association with the block identifier (e.g., block hash) corresponding to the block body. Optionally, the cache manager may also store the block body, where the storage relationship between the block body, the execution result of the transactions within the block body, and the block identifier can be as shown in Table 2 below:

[0131] Table 2. Storage relationship between transaction execution results and block identifiers in the block body

[0132] block hash1 Block 1 Execution result 1 block hash2 Block 2 Execution result 2 block hash3 Block 3 Execution result 3 ... ... ...

[0133] In one possible implementation, after extracting the block header from the proposal message, the corresponding block body can be found in the cache manager based on the block header. Then, based on the block body, the execution result of the transactions in the block body can 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, and PreStateRoot1. Then, based on Tx Merkle Root1, the block body corresponding to this block header can be found (because Tx Merkle Root1 is calculated using the Merkle algorithm for the transactions in the block body). It can be understood that Tx Merkle Root1 can be used as a block identifier. Then, after finding the corresponding block body (let's say block body 1), the execution result of the transactions in the block body corresponding to block body 1 (i.e., execution result 1) can be found in the cache manager (e.g., the stored table 2 mentioned above).

[0134] In this way, by executing transactions in the block body in advance and writing the execution results of these transactions to the cache manager, when a consensus confirmation message containing proposal information including the block header corresponding to the block body is received, it is not necessary to execute the transactions in that block body again. The execution results of the pre-executed transactions in the block body can be directly obtained from the cache manager, thereby greatly reducing the time spent in the commit phase and improving consensus efficiency.

[0135] S303: Combine the block header and block body into a block, add the block to the blockchain, and write the found execution results back to the blockchain's state database.

[0136] In one possible implementation, after finding the block body, the computer device can combine the block header and block body into a complete block and add it to the blockchain. Then, the computer device can write the execution result corresponding to the current block body back to the blockchain's state database, allowing the state database to update the business state based on the execution result of the transaction in the latest block body. For example, if the transaction included in the current block body is: object A transfers m units of virtual resources to object B's account, then after obtaining the execution result of this transaction and writing it to the state database, the business state update operation performed in the state database can include: deducting m units of virtual resources from object A's account and adding m units of virtual resources to object B's account.

[0137] In this embodiment, when a blockchain node receives a consensus confirmation message for a proposal message, it can extract the block header from the proposal message. Then, it searches the cache manager for the block body corresponding to the block header and the execution results of the transactions within the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions within it have already been stored in the cache manager. Next, the block header and block body can be combined into a block, added to the blockchain, and the execution results of the transactions within the block body can be written back to the blockchain's state database. Therefore, this application can separate the block body from the proposal message, reducing the size of the proposal message and facilitating rapid proposal construction in the pre-prepare phase, reducing the time consumed in the pre-prepare phase, and thus improving consensus efficiency. Furthermore, before receiving the consensus confirmation message, the block body is executed in advance, and the execution results of the block body and the transactions within it are stored in the cache manager. When a consensus confirmation message for a proposal is received, the execution results of transactions that have already been executed can be retrieved directly from the cache manager. There is no need to execute the transactions in the block body again, which can reduce the time spent in the commit phase and further improve consensus efficiency.

[0138] Please see Figure 7 , Figure 7 This is a schematic diagram of the interaction flow of a data processing method provided in an embodiment of this application. This data processing method can be applied to a consortium blockchain, and can be executed by blockchain nodes (master node or backup node) within the consortium blockchain. The data processing method may include the following steps S701 to S7010:

[0139] S701: Obtain transaction request.

[0140] In one possible implementation, the master node can obtain the transaction request sent by the client. Optionally, the transaction request carries the client's identifier, which the master node can obtain after receiving the transaction request. Then, the master node can verify the client based on the client's identifier. Specifically, the verification may include, but is not limited to, security verification, reliability verification, etc. If the verification passes, the master node responds to the transaction request and triggers step S702.

[0141] This method of client verification can improve the security of data processing.

[0142] S702: Build proposal message.

[0143] In one possible implementation, the process of the master node constructing the proposal message may include: generating a block header based on the transaction request, and then constructing the corresponding proposal message based on the block header. Specifically, generating the block header based on the transaction request may include: upon receiving a transaction request, verifying the request; after verification, storing the transaction content in the request in a memory pool and updating the hash tree used to record the transaction content; then, updating the timestamp to the time the transaction request was received, and trying different random numbers and performing feature value calculations multiple times (e.g., using the SHA256 algorithm) to construct the block header. Next, constructing the corresponding proposal message based on the block header may include: first, serializing the block header to obtain a serialized byte array corresponding to the block header; then, calculating the digest of the serialized byte array and signing the digest to obtain the corresponding proposal message.

[0144] For example, a transaction request may include one or more transactions (such as object A transferring m units of virtual resources to object B, or object A simultaneously transferring n units of virtual resources to both object B and object C). The master node can then serialize each field in each transaction, calculate the corresponding digest using a specific hash function (such as SHA256), and store the calculated digest in the proposal message.

[0145] S703: Broadcast proposal message.

[0146] In one possible implementation, after the master node constructs the proposal message, it can broadcast the proposal message to k backup nodes in the blockchain, so that any one of the k backup nodes can vote on the proposal message and obtain the voting result, where k is a positive integer.

[0147] Specifically, after receiving a proposal message, the backup node can perform deserialization and signature verification operations. If the signature verification of the proposal message passes, the vote is successful. If the signature verification fails, the vote fails.

[0148] S704: Receives the voting results sent by the backup node.

[0149] In one possible implementation, the master node can receive k voting results from k backup nodes. Each backup node corresponds to one voting result, which can be either a successful vote or a failed vote.

[0150] S705: Generate an acknowledgment message.

[0151] Specifically, if the number of votes in favor of the k votes exceeds a second preset threshold, a confirmation instruction message for the proposal is generated. This second preset threshold can be pre-set by the master node or determined based on the number of nodes in the current blockchain. For example, in the PBFT consensus algorithm, the second preset threshold can be 2f+1 (where f is the number of malicious nodes in the blockchain). In other words, once the prepare phase is passed (i.e., the master node is honest), the commit phase is about to begin.

[0152] S706: Broadcast confirmation instruction message.

[0153] In one possible implementation, the master node can broadcast a confirmation instruction message for the proposal message to k backup nodes in the blockchain, so that any one of the k backup nodes can confirm the confirmation instruction message and obtain the confirmation result.

[0154] S707: Receive confirmation results sent by the backup node.

[0155] In one possible implementation, the master node can receive k acknowledgments from k backup nodes. Each backup node corresponds to one acknowledgment, and the acknowledgment can be either successful or unsuccessful.

[0156] S708: Generates consensus confirmation messages and extracts block headers from proposal messages.

[0157] Specifically, if the number of accepted confirmations out of the k confirmation results exceeds a first preset threshold, a consensus confirmation message for the proposal message is generated. This first preset threshold can be pre-set by the master node or determined based on the number of nodes in the current blockchain. Furthermore, the first preset threshold can be the same as or different from a second preset threshold. For example, in the PBFT consensus algorithm, the first and second preset thresholds are the same, both being 2f+1 (where f is the number of malicious nodes in the blockchain). Next, the master node can extract the block header from the proposal message. It should be noted that the execution process for extracting the block header from the proposal message can be found in [reference needed]. Figure 3 The process performed in step S301 of the embodiment will not be described again in this application embodiment.

[0158] S709: Locate the block body corresponding to the block header and the execution results of the transactions in the block body in the cache manager.

[0159] Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager.

[0160] S7010: Combines the block header and block body into a block, adds the block to the blockchain, and writes the found execution results back to the blockchain's state database.

[0161] It should be noted that the specific procedures executed by the computer device in steps S709-S7010 can be found in [reference needed]. Figure 3 The specific processes executed by the computer device in steps S302-S303 of the embodiments will not be repeated here.

[0162] It should be noted that the data processing method provided in this application embodiment is applicable to consortium blockchains. In consortium blockchains, since nodes are all admittedly trusted, the number of blocks produced in each consensus round can be appropriately increased, that is, the master node can continuously generate N blocks, where N is a positive integer. The following is a detailed explanation using the example of the master node generating any block:

[0163] Specifically, combined Figure 8 This section provides a detailed explanation of the execution of transactions within a block. Please refer to [link / reference]. Figure 8 , Figure 8 This is an interactive flowchart illustrating the execution process of a transaction, as provided in an embodiment of this application. Figure 8 As shown, the interaction flowchart may include the following steps S801 to S805:

[0164] S801: Obtain multiple transactions from the transaction pool and generate a block body based on the multiple transactions.

[0165] In one possible implementation, the master node can retrieve multiple transactions from the transaction pool, sort them to obtain a transaction list, and then generate a block body based on the transaction list. The sorting process can be based on the transaction timestamps, from oldest to youngest. For example, if transaction 1's timestamp is 9:00 and transaction 2's timestamp is 9:01, then transaction 1 can be placed before transaction 2.

[0166] S802, Broadcast Block.

[0167] In practice, the master node broadcasts the block body to k backup nodes in the blockchain, so that each of the k backup nodes can execute the block body after receiving it and obtain the execution result of the transactions in the block body.

[0168] In one possible implementation, after receiving the block body sent by the master node, the backup node can obtain the master node's node identifier and then verify the master node based on the node identifier. If the verification passes, the execution of the block body is triggered, and the execution results of the transactions within the block body are obtained. In this way, the backup node executes the block body sent by the master node only after verifying the master node's identity, which improves the security of the data processing process.

[0169] S803. Execute the block body to obtain the execution results of the transactions in the block body.

[0170] In one possible implementation, the master node can invoke a smart contract to execute the block, obtain the contract execution result, and use the contract execution result as the execution result of the transactions in that block. The specific execution process of invoking the smart contract to execute the block can be found in the above embodiments. Figure 5 The execution process of the smart contract mentioned will not be described again in the embodiments of this application.

[0171] S804. Store the execution results of the transactions in the block body into the cache manager.

[0172] In practice, once the execution result of a transaction within a block body is obtained, the execution result can be stored in the node's cache manager. Specifically, the execution result of the transaction within the block body and the block identifier corresponding to the block body are stored in association within the cache manager.

[0173] S805: Return the execution results of the transactions in the block to the client.

[0174] It should be noted that the embodiments in this application are illustrated using the construction of a single block as an example. It is understood that the master node can be configured to continuously construct N blocks as needed. The execution steps for any of the N blocks can be referred to [the relevant documentation / reference]. Figure 8 The specific execution steps in the embodiments are as follows. Please refer to [link / reference]. Figure 9 , Figure 9 This is a flowchart illustrating another data processing method provided in an embodiment of this application. For example... Figure 9As shown, assuming the current proposal message is proposal N, during the consensus process (preparation phase, preparation phase, confirmation phase) and response phase for proposal N, the master node (e.g., node 1) can simultaneously construct block N+1, block N+2... block N+11, and broadcast and execute the blocks. This demonstrates that during the consensus process for proposal N, the transactions in each block (N+1, N+2...) have already been executed. Therefore, when the consensus confirmation message (confirmation phase) for proposal N+1 (the proposal message corresponding to block N+1) is received, since the transactions in block N+1 have already been executed, there is no need to execute block N+1 in real time; it can be retrieved directly from the cache manager. Executing the transactions in the block in advance significantly reduces the commit phase time, thereby improving consensus efficiency.

[0175] In this embodiment, the blocks are constructed and the transactions within them are executed in advance, without waiting for the transactions in the previous block to be completed before constructing and executing the next block. This allows the blocks to be broadcast in advance, enabling early verification and execution of the transactions within the blocks, and obtaining the execution results. This approach improves consensus efficiency and ultimately enhances the overall performance and throughput of the blockchain.

[0176] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. The data processing apparatus 1000 can be applied to the computer device described in the foregoing embodiments. The data processing apparatus 1000 can be a computer program (including program code) running on the computer device; for example, the data processing apparatus 1000 is an application software. The network configuration management device can be used to execute corresponding steps in the data processing method provided in the embodiments of this application. The data processing apparatus 1000 may include:

[0177] The acquisition unit 1001 is used to extract the block header from the proposal message when a consensus confirmation message of the proposal message is received;

[0178] The processing unit 1002 is used to search for the block body corresponding to the block header and the execution results of the transactions in the block body in the cache manager. Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager.

[0179] The processing unit 1002 is also used to combine the block header and block body into a block, add the block to the blockchain, and write the found execution results back to the blockchain's state database.

[0180] In one possible implementation, before the acquisition unit 1001 receives the consensus confirmation message of the proposal message, the processing unit 1002 is further configured to perform the following operations:

[0181] Obtain the block body, which is generated from multiple transactions obtained from the transaction pool;

[0182] Execute the block body to obtain the execution results of the transactions within the block body;

[0183] Write the block body and the execution results of the transactions in the block body to the cache manager;

[0184] The execution results of transactions within the block body and the block identifier corresponding to the block body are stored in association.

[0185] In one possible implementation, before the acquisition unit 1001 receives the consensus confirmation message of the proposal message, the processing unit 1002 is further configured to perform the following operations:

[0186] Receive k confirmation results from k nodes in the blockchain for the proposal message, with one confirmation result corresponding to one node, and k being a positive integer;

[0187] When the number of accepted confirmations out of k received confirmations exceeds a first preset threshold, a consensus confirmation message for the proposal message is generated.

[0188] In one possible implementation, when the above method is executed by the master node in the blockchain; any one of the k nodes is called a backup node; the processing unit 1002 is also used to perform the following operations:

[0189] Obtain the proposal message and broadcast it to k backup nodes in the blockchain, so that any one of the k backup nodes can vote on the proposal message and obtain the voting result;

[0190] Receive k voting results from k backup nodes. If the number of votes in the k voting results exceeds the second preset threshold, then confirm the generation of a confirmation instruction message for the proposal message. One backup node corresponds to one voting result.

[0191] The confirmation instruction message is broadcast to k backup nodes in the blockchain, so that any one of the k backup nodes can confirm the confirmation instruction message and obtain the confirmation result.

[0192] In one possible implementation, when the above method is executed by any backup node in the blockchain, the processing unit 1002 is also configured to perform the following operations:

[0193] Receive proposal messages sent by the master node, process the proposal messages through voting, and obtain the voting results;

[0194] The voting results are sent to the master node, which then generates an acknowledgment message for the proposal based on the voting results.

[0195] Receive the confirmation instruction message sent by the master node, process the confirmation instruction message, and obtain the confirmation result;

[0196] The confirmation result is sent to the master node, so that the master node generates a consensus confirmation message for the proposal message.

[0197] In one possible implementation, processing unit 1002 obtains the proposal message and performs the following operations:

[0198] Obtain the transaction request sent by the client and generate a block header based on the transaction request;

[0199] Construct the proposal message corresponding to the block header based on the block header.

[0200] In one possible implementation, the transaction request carries the client's identifier; after obtaining the transaction request sent by the client, the processing unit 1002 is further configured to perform the following operations:

[0201] Retrieve the client's identifier from the transaction request;

[0202] The client is verified based on its identifier. If the verification passes, the step of generating a block header based on the transaction request is triggered.

[0203] In one possible implementation, processing unit 1002 constructs a proposal message corresponding to the block header based on the block header, for performing the following operations:

[0204] The block header is serialized to obtain the serialized byte array corresponding to the block header;

[0205] Calculate the digest of the serialized byte array and sign the digest to obtain the proposal message corresponding to the block header.

[0206] In one possible implementation, when the above method is executed by the blockchain's master node, the processing unit 1002, after obtaining the block body, is also used to perform the following operations:

[0207] The block body is broadcast to k backup nodes in the blockchain, so that each of the k backup nodes executes the block body after receiving it and obtains the execution result of the transactions in the block body.

[0208] In one possible implementation, when the above method is executed by a backup node in the blockchain, the processing unit 1002 obtains the block body and performs the following operations:

[0209] Receive block bodies sent by the master node;

[0210] The steps include obtaining the node identifier of the master node, verifying the master node based on the node identifier, and if the verification passes, triggering the execution of the block body and obtaining the execution results of the transactions in the block body.

[0211] In this embodiment, when a blockchain node receives a consensus confirmation message for a proposal message, it can extract the block header from the proposal message. Then, it searches the cache manager for the block body corresponding to the block header and the execution results of the transactions within the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions within it have already been stored in the cache manager. Next, the block header and block body can be combined into a block, added to the blockchain, and the execution results of the transactions within the block body can be written back to the blockchain's state database. Therefore, this application can separate the block body from the proposal message, reducing the size of the proposal message and facilitating rapid proposal construction in the pre-prepare phase, reducing the time consumed in the pre-prepare phase, and thus improving consensus efficiency. Furthermore, before receiving the consensus confirmation message, the block body is executed in advance, and the execution results of the block body and the transactions within it are stored in the cache manager. When a consensus confirmation message for a proposal is received, the execution results of transactions that have already been executed can be retrieved directly from the cache manager. There is no need to execute the transactions in the block body again, which can reduce the time spent in the commit phase and further improve consensus efficiency.

[0212] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 1100 is used to execute the steps performed by the computer device in the aforementioned method embodiment. 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 processors 1110, input devices 1120, output devices 1130, and memory 1140 are connected via a bus 1150. The memory 1140 is used to store a computer program, which includes program instructions. The processor 1110 is used to call the program instructions stored in the memory 1140 to perform the following operations:

[0213] Upon receiving the consensus confirmation message for the proposal message, extract the block header from the proposal message;

[0214] The cache manager searches for the block body corresponding to the block header, as well as the execution results of the transactions in the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions in the block body have been stored in the cache manager.

[0215] The block header and block body are combined into a block, the block is added to the blockchain, and the found execution results are written back to the blockchain's state database.

[0216] In one possible implementation, before receiving the consensus confirmation message for the proposal message, processor 1110 is also configured to perform the following operations:

[0217] Obtain the block body, which is generated from multiple transactions obtained from the transaction pool;

[0218] Execute the block body to obtain the execution results of the transactions within the block body;

[0219] Write the block body and the execution results of the transactions in the block body to the cache manager;

[0220] The execution results of transactions within the block body and the block identifier corresponding to the block body are stored in association.

[0221] In one possible implementation, before receiving the consensus confirmation message for the proposal message, processor 1110 is also configured to perform the following operations:

[0222] Receive k confirmation results from k nodes in the blockchain for the proposal message, with one confirmation result corresponding to one node, and k being a positive integer;

[0223] When the number of accepted confirmations out of k received confirmations exceeds a first preset threshold, a consensus confirmation message for the proposal message is generated.

[0224] In one possible implementation, when the above method is executed by the master node in the blockchain; any one of the k nodes is called a backup node; the processor 1110 is also used to perform the following operations:

[0225] Obtain the proposal message and broadcast it to k backup nodes in the blockchain, so that any one of the k backup nodes can vote on the proposal message and obtain the voting result;

[0226] Receive k voting results from k backup nodes. If the number of votes in the k voting results exceeds the second preset threshold, then confirm the generation of a confirmation instruction message for the proposal message. One backup node corresponds to one voting result.

[0227] The confirmation instruction message is broadcast to k backup nodes in the blockchain, so that any one of the k backup nodes can confirm the confirmation instruction message and obtain the confirmation result.

[0228] In one possible implementation, when the above method is executed by any backup node in the blockchain, processor 1110 is also configured to perform the following operations:

[0229] Receive proposal messages sent by the master node, process the proposal messages through voting, and obtain the voting results;

[0230] The voting results are sent to the master node, which then generates an acknowledgment message for the proposal based on the voting results.

[0231] Receive the confirmation instruction message sent by the master node, process the confirmation instruction message, and obtain the confirmation result;

[0232] The confirmation result is sent to the master node, so that the master node generates a consensus confirmation message for the proposal message.

[0233] In one possible implementation, processor 1110 obtains the proposal message and performs the following operations:

[0234] Obtain the transaction request sent by the client and generate a block header based on the transaction request;

[0235] Construct the proposal message corresponding to the block header based on the block header.

[0236] In one possible implementation, the transaction request carries the client's identifier; after receiving the transaction request sent by the client, the processor 1110 is also used to perform the following operations:

[0237] Retrieve the client's identifier from the transaction request;

[0238] The client is verified based on its identifier. If the verification passes, the step of generating a block header based on the transaction request is triggered.

[0239] In one possible implementation, processor 1110 constructs a proposal message corresponding to the block header based on the block header, for performing the following operations:

[0240] The block header is serialized to obtain the serialized byte array corresponding to the block header;

[0241] Calculate the digest of the serialized byte array and sign the digest to obtain the proposal message corresponding to the block header.

[0242] In one possible implementation, when the above method is executed by the blockchain's master node, the processor 1110, after obtaining the block body, is also used to perform the following operations:

[0243] The block body is broadcast to k backup nodes in the blockchain, so that each of the k backup nodes executes the block body after receiving it and obtains the execution result of the transactions in the block body.

[0244] In one possible implementation, when the above method is executed by a backup node in the blockchain, processor 1110 obtains the block body and performs the following operations:

[0245] Receive block bodies sent by the master node;

[0246] The steps include obtaining the node identifier of the master node, verifying the master node based on the node identifier, and if the verification passes, triggering the execution of the block body and obtaining the execution results of the transactions in the block body.

[0247] In this embodiment, when a blockchain node receives a consensus confirmation message for a proposal message, it can extract the block header from the proposal message. Then, it searches the cache manager for the block body corresponding to the block header and the execution results of the transactions within the block body. Before receiving the consensus confirmation message, the block body and the execution results of the transactions within it have already been stored in the cache manager. Next, the block header and block body can be combined into a block, added to the blockchain, and the execution results of the transactions within the block body can be written back to the blockchain's state database. Therefore, this application can separate the block body from the proposal message, reducing the size of the proposal message and facilitating rapid proposal construction in the pre-prepare phase, reducing the time consumed in the pre-prepare phase, and thus improving consensus efficiency. Furthermore, before receiving the consensus confirmation message, the block body is executed in advance, and the execution results of the block body and the transactions within it are stored in the cache manager. When a consensus confirmation message for a proposal is received, the execution results of transactions that have already been executed can be retrieved directly from the cache manager. There is no need to execute the transactions in the block body again, which can reduce the time spent in the commit phase and further improve consensus efficiency.

[0248] Furthermore, it should be noted that this application also provides a computer storage medium storing a computer program, which includes program instructions. When the processor executes these program instructions, it can perform the methods described in the preceding embodiments. Therefore, further details will not be provided here. For technical details not disclosed in the embodiments of the computer storage medium involved in this application, please refer to the description of the method embodiments of this application. As an example, the program instructions can be deployed on a computer device, executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network.

[0249] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described in the preceding embodiments; therefore, further details will not be provided here.

[0250] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0251] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method, characterized in that, include: Retrieve the proposal message constructed from the block header; Upon receiving the consensus confirmation message of the proposal message, the block header is extracted from the proposal message; The block body corresponding to the block header and the execution results of the transactions in the block body are located in the cache manager. The block body has been executed before the consensus confirmation message is received, and the execution results of the block body and the transactions in the block body have been stored in the cache manager. The block header and the block body are combined into a block, the block is added to the blockchain, and the found execution result is written back to the state database of the blockchain.

2. The method as described in claim 1, characterized in that, Before receiving the consensus confirmation message for the proposal message, the process also includes: Obtain a block body, which is generated based on multiple transactions obtained from a transaction pool; Execute the block body to obtain the execution results of the transactions in the block body; Write the block body and the execution results of the transactions in the block body to the cache manager; The execution results of transactions within the block body and the block identifier corresponding to the block body are stored in association.

3. The method as described in claim 1, characterized in that, Before receiving the consensus confirmation message for the proposal message, the process also includes: Receive k confirmation results from k nodes in the blockchain in response to the proposal message, with one confirmation result corresponding to one node, and k being a positive integer; When the number of confirmed results received exceeds a first preset threshold, a consensus confirmation message for the proposal message is generated.

4. The method as described in claim 3, characterized in that, When the method is executed by the master node in the blockchain; any one of the k nodes is called a backup node; the method further includes: Obtain the proposal message and broadcast it to k backup nodes in the blockchain, so that any one of the k backup nodes can vote on the proposal message and obtain the voting result; Receive k voting results sent by the k backup nodes. If the number of votes in the k voting results exceeds a second preset threshold, then confirm the generation of a confirmation instruction message for the proposal message. One backup node corresponds to one voting result. The confirmation instruction message is broadcast to k backup nodes in the blockchain, so that any one of the k backup nodes can confirm the confirmation instruction message and obtain a confirmation result.

5. The method as described in claim 4, characterized in that, When the method is executed by any backup node in the blockchain; the method further includes: Receive the proposal message sent by the master node, and perform voting on the proposal message to obtain the voting result; The voting result is sent to the master node, so that the master node generates a confirmation instruction message for the proposal message based on the voting result; Receive the confirmation instruction message sent by the master node, and perform confirmation processing on the confirmation instruction message to obtain a confirmation result; The confirmation result is sent to the master node, so that the master node generates a consensus confirmation message for the proposal message.

6. The method as described in claim 4, characterized in that, The process of obtaining the proposal message includes: Obtain the transaction request sent by the client, and generate a block header based on the transaction request; Construct the proposal message corresponding to the block header based on the block header.

7. The method as described in claim 6, characterized in that, The transaction request carries the client's identifier; After obtaining the transaction request sent by the client, the process further includes: Obtain the client's identifier from the transaction request; The client is verified based on its identifier. If the verification passes, the step of generating a block header based on the transaction request is triggered.

8. The method as described in claim 6, characterized in that, The step of constructing the proposal message corresponding to the block header based on the block header includes: The block header is serialized to obtain a serialized byte array corresponding to the block header; Calculate the digest of the serialized byte array and sign the digest of the serialized byte array to obtain the proposal message corresponding to the block header.

9. The method as described in claim 2, characterized in that, When the method is executed by the master node in the blockchain; after obtaining the block body, it further includes: The block body is broadcast to k backup nodes in the blockchain, so that each of the k backup nodes executes the block body after receiving it and obtains the execution result of the transactions in the block body.

10. The method as described in claim 9, characterized in that, When the method is executed by a backup node of the blockchain, obtaining the block body includes: Receive the block body sent by the master node; The steps include obtaining the node identifier of the master node, verifying the master node based on the node identifier, and if the verification passes, triggering the execution of the block body and obtaining the execution result of the transactions in the block body.

11. A data processing apparatus, characterized in that, include: Get the unit, which retrieves the proposal message constructed from the block header; The acquisition unit is further configured to extract the block header from the proposal message when it receives the consensus confirmation message of the proposal message; The processing unit is used to search in the cache manager for the block body corresponding to the block header and the execution results of the transactions in the block body, wherein the block body has been executed before the consensus confirmation message is received, and the execution results of the block body and the transactions in the block body have been stored in the cache manager. The processing unit is further configured to combine the block header and the block body into a block, add the block to the blockchain, and write the found execution result back to the state database of the blockchain.

12. A computer device, characterized in that, include: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program that, when executed by the processor, implements the data processing method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the data processing method as described in any one of claims 1-10.

14. A computer program product, characterized in that, The computer program product includes a computer program adapted to be loaded by a processor and execute the data processing method as described in any one of claims 1-10.

Images