Data processing method and device based on block chain, equipment and readable medium

Abstract

The embodiment of the invention discloses a block chain-based data processing method and related equipment. The method comprises the steps of receiving a to-be-consensus block sent by a consensus node in a block chain and reference read sets corresponding to a plurality of transactions contained in the to-be-consensus block; in the process of executing the corresponding transactions based on the reference read sets of the transactions, obtaining a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area in parallel; then, based on the read set matching result of each transaction, generating a verification result of the to-be-consensus block; and finally, sending a verification result to the main node, so that the main node performs consensus on the to-be-consensus block based on the verification result. According to the technical scheme provided by the embodiment of the invention, the block verification speed can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer and communication technology, and more specifically, to a blockchain-based data processing method, apparatus, device, and readable medium. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In the blockchain, blocks are combined into a chain data structure in a sequential manner according to chronological order, and cryptography is used to ensure that the blocks cannot be tampered with or forged. At the same time, a block generated by a consensus node in the blockchain needs to be verified by other consensus nodes in the blockchain before it can be added to the blockchain. However, the speed at which consensus nodes verify blocks is slow, which affects the performance of the blockchain. Therefore, how to improve the verification speed of blocks is an urgent problem to be solved. Summary of the invention

[0003] The embodiments of the present application provide a blockchain-based data processing method, device, electronic device, computer-readable medium, and computer program product, which can improve the verification speed of blocks.

[0004] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0005] In a first aspect, an embodiment of the present application provides a data processing method based on a blockchain, wherein the blockchain includes a master node and a slave node, and the method is applied to the slave node, and the method includes:

[0006] Receive the block to be agreed upon sent by the master node, and the reference read sets corresponding to the multiple transactions contained in the block to be agreed upon; wherein the reference read set includes the state values ​​corresponding to the transaction parameters required by the master node to execute the corresponding transaction;

[0007] In the process of respectively executing corresponding transactions based on reference read sets of multiple transactions, obtaining in parallel a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area;

[0008] Based on the read set matching result of each transaction, a verification result of the block to be agreed upon is generated; wherein the verification result is used to indicate whether the block to be agreed upon is successfully verified;

[0009] The verification result is sent to the master node so that the master node reaches a consensus on the block to be agreed upon based on the verification result.

[0010] In a second aspect, an embodiment of the present application provides a data processing device based on a blockchain, wherein the blockchain includes a master node and a slave node, the device is configured on the slave node, and the device includes a receiving unit, a parallel processing unit, a generating unit, and a sending unit, wherein:

[0011] The receiving unit is configured to receive the block to be consensus sent by the master node, and the reference read sets corresponding to the multiple transactions contained in the block to be consensus; wherein the reference read set includes the state value corresponding to the transaction parameter required by the master node to execute the corresponding transaction;

[0012] The parallel processing unit is configured to, in the process of respectively executing corresponding transactions based on the reference read sets of multiple transactions, obtain in parallel a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area;

[0013] The generating unit is configured to generate a verification result of the block to be consensus based on the read set matching result of each transaction; wherein the verification result is used to indicate whether the block to be consensus is successfully verified;

[0014] The sending unit is configured to send the verification result to the master node, so that the consensus node reaches a consensus on the block to be agreed upon based on the verification result.

[0015] In a third aspect, an embodiment of the present application provides an electronic device, comprising one or more processors; a storage device for storing one or more computer programs, wherein when the one or more computer programs are executed by the one or more processors, the electronic device implements the blockchain-based data processing method as described above.

[0016] In a fourth aspect, an embodiment of the present application provides a computer-readable medium on which a computer program is stored. When the computer program is executed by a processor of an electronic device, the electronic device executes the blockchain-based data processing method as described above.

[0017] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, wherein the computer program is stored in a computer-readable medium, and a processor of an electronic device reads and executes the computer program from the computer-readable medium, so that the electronic device performs the blockchain-based data processing method as described above.

[0018] In the technical solution provided in the embodiment of the present application, by obtaining the read set matching results of each transaction in parallel in the process of executing the Xiangyin transaction based on the reference read sets of multiple transactions, the transaction execution and read set verification can be executed in parallel. Compared with the traditional solution that requires executing all transactions in the consensus block first and then performing read-write set verification; the embodiment of the present application can reduce the time cost of the two processes of serially executing read set verification and executing transactions, thereby greatly improving the verification speed of the consensus block.

[0019] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0021] Figure 1 It is a structural diagram of a blockchain system provided by an embodiment of the present application;

[0022] Figure 2 It is a schematic diagram of a block link provided in an embodiment of the present application;

[0023] Figure 3 It is a flowchart of a data processing method based on blockchain provided in an embodiment of the present application;

[0024] Figure 4 This is a schematic diagram of a block verification process of a slave node provided in an embodiment of the present application;

[0025] Figure 5 It is a flowchart of another data processing method based on blockchain provided in an embodiment of the present application;

[0026] Figure 6 This is a schematic diagram of a verification process of a slave node treating a consensus block provided in an embodiment of the present application;

[0027] Figure 7 This is a schematic diagram of a read-write set verification process provided by an embodiment of the present application;

[0028] Figure 8 It is a structural block diagram of a blockchain-based data processing device provided in an embodiment of the present application;

[0029] Fig. 9A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0030] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0031] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0032] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all contents and operations, nor must they be executed in the order described. For example, some operations may be decomposed, while some operations may be combined or partially combined, so the actual execution order may change according to actual conditions.

[0033] It should also be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0034] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0035] Among them, the consensus mechanism of blockchain refers to the mechanism by which blockchain nodes reach a consensus on blocks (or block information, block data), which can ensure that the latest blocks are accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among them, in various consensus algorithms, usually after a preset number of consensus nodes reach an agreement on the consensus data (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful.

[0036] For example, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated, where N and f are positive integers. In other words, when 2f + 1 nodes out of N consensus nodes reach a consensus, the consensus is considered successful.

[0037] Specifically, in order to achieve the consensus function, the full amount of ledgers can be stored on the consensus node, that is, the state values ​​of the transaction parameters of all blocks and all accounts can be stored. Therefore, each node in the blockchain can generate the same state value in the blockchain by executing the same transaction, so that the state values ​​corresponding to the same transaction parameters in the node database of each node in the blockchain are the same.

[0038] It should be noted that the consensus node that initiates the consensus proposal in the blockchain can be called the master node, and the other consensus nodes that receive the consensus proposal in the blockchain can be called slave nodes. The consensus proposal can include the consensus block generated by the master node, which usually contains multiple transactions and the transaction execution order of each transaction.

[0039] In the related art, after receiving the block to be agreed upon sent by the master node, the slave node will re-execute the transactions in the block according to the transaction execution order defined in the block, thereby obtaining the execution result of the slave node; if the execution result of the slave node is the same as that of the master node, it can be determined that the block has passed the verification of the slave node, that is, the slave node and the master node have reached a consensus on the block. If the execution result of the slave node is different from that of the master node, it can be determined that the block has not passed the verification of the slave node, that is, the slave node and the master node have not reached a consensus on the block.

[0040] The execution result of any node may include the read-write set corresponding to the transaction executed by the node. Therefore, whether the execution results of two nodes are the same actually refers to whether the read-write sets corresponding to the transactions executed by the two nodes are the same.

[0041] Specifically, the read-write set includes the read set and the write set. The read set includes the key-value pairs of the variables read when executing the transaction, which can be understood as the read set including the status values ​​corresponding to the transaction parameters required to execute the transaction; the write set includes the key-value pairs of the variables written when executing the transaction, which can be understood as the write set including the status values ​​corresponding to the transaction parameters updated during the transaction execution.

[0042] It should be noted that transaction parameters may include one or more parameters related to blockchain ledger transactions, such as account balance, asset ownership, and deposit amount. If the status values ​​corresponding to the same transaction parameters included in two read sets are different, it can be said that the version information of the two read sets is different.

[0043] Furthermore, updates may include one or more operations such as adding, modifying, and deleting. After the consensus block is reached, the transaction status of all consensus nodes in the blockchain can be updated based on the write set, so that the transaction status of all consensus nodes remains consistent.

[0044] Based on this, the embodiment of the present application provides a data processing solution based on blockchain, wherein the blockchain includes a master node and a slave node, and the solution is applied to the slave node. In the solution, after receiving the block to be consensus sent by the master node and the reference read sets corresponding to the multiple transactions contained in the block to be consensus, the slave node will detect in parallel whether the reference read set of each transaction matches the local read set of each transaction in the local storage area during the process of executing multiple transactions based on the multiple reference read sets.

[0045] If each transaction is successfully executed and the reference read set and local read set of each transaction match, a verification result can be generated to indicate that the verification of the block to be agreed upon is successful; if the reference read set and local read set of any transaction do not match, a verification result will be directly generated to indicate that the verification of the block to be agreed upon has failed.

[0046] Among them, the block to be agreed upon refers to the block that has not yet reached consensus. The block needs to be added to the blockchain after the consensus is successful. The reference read set of each transaction can include: the status value of the transaction parameters that the master node needs to use when executing each transaction.

[0047] At the same time, the local read set of each transaction in the local storage area may include: the status value of the transaction parameter required by the slave node when executing each transaction. The local storage area includes multiple transaction parameters and the status value corresponding to each transaction parameter. The transaction parameters required by the slave node when executing each transaction are essentially the transaction parameters in the reference read set of each transaction. The status values ​​corresponding to the same transaction parameter stored in the slave node and the master node may be different.

[0048] In addition, the verification process of the block to be consensus mainly includes verifying whether the read-write set corresponding to the exchange executed by the master node is the same as the read-write set corresponding to the exchange executed by the slave node; if they are the same, it means that the slave node and the master node have reached a consensus on the block; if they are not the same, it means that the slave node and the master node have not reached a consensus on the block.

[0049] It should be noted that the same smart contract needs to be called to execute the same transaction; if the read set used by two nodes to execute the same transaction is the same, it means that the state value read by the two nodes when executing the transaction is the same, and the write set obtained after executing the same smart contract with the same state value will usually be the same. Therefore, passing the read set verification is equivalent to passing the read-write set verification.

[0050] It is not difficult to see that this solution will detect the reference read set and local read set of the transaction in parallel during the transaction execution process. Compared with the traditional solution that needs to check whether the read and write sets of each transaction match after all transactions are executed, this solution improves the verification speed of the identified blocks by performing the two processes of transaction execution and read set detection in parallel.

[0051] Based on the above blockchain-based data processing solution, the present application embodiment provides a blockchain system, which can be found at Figure 1 , Figure 1 A schematic diagram of the structure of a blockchain system is shown. Figure 1 The blockchain system 100 shown may specifically be a system for sharing data between nodes. The blockchain system 100 may include multiple blockchain nodes (also referred to as consensus nodes), such as Figure 1 The blockchain nodes 101 to 104 shown; wherein, Figure 1 The ellipsis in represents that the blockchain system 100 also includes other blockchain nodes. Each blockchain node in the blockchain system 100 stores an identical blockchain.

[0052] In addition, each blockchain node can receive input information during normal operation and maintain the shared data in the blockchain system 100 based on the received input information. In order to ensure the information exchange within the blockchain system 100, Figure 1 As shown, there may be a wired or wireless communication connection between each blockchain node in the blockchain system 100, and information may be transmitted between the blockchain nodes through the above communication connection.

[0053] For example, when any blockchain node in the blockchain system 100 responds to a transaction request of an object and executes multiple requested transactions, the executed multiple transactions can be packaged into a block as input information. After receiving the block, other blockchain nodes in the blockchain system 100 process the block according to the consensus algorithm, and after the block reaches a consensus, the block is stored as data in the shared data, so that the data stored on all blockchain nodes in the blockchain system 100 are consistent.

[0054] Each blockchain node in the blockchain system 100 has a node identifier corresponding to it, and each blockchain node in the blockchain system 100 can store the node identifiers of other blockchain nodes in the blockchain system 100, so that the generated blocks can be broadcast to other blockchain nodes in the blockchain system 100 according to the node identifiers of other blockchain nodes. Each blockchain node can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node. Table 1 only takes the IP address as an example for explanation.

[0055] Node Name Node ID Blockchain Node 101 117.114.151.174 Blockchain Node 102 117.116.189.145 … … Blockchain node xxx xxx.xxx.xxx.xxx

[0056] Table 1

[0057] Each node in the blockchain system 100 stores an identical blockchain. The blockchain consists of multiple blocks, see Figure 2 The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0058] In one embodiment, after receiving the transaction request of the object, the blockchain node 101 will execute the requested multiple transactions and package the executed multiple transactions as input information into a block to be agreed upon. (At this time, the blockchain node 100 is the master node in the blockchain system 100) Then, the blockchain node 101 can send the block to be agreed upon and the reference read-write set obtained after executing multiple transactions in the block to be agreed upon to other blockchain nodes in the blockchain system 100 (at this time, other blockchain nodes are slave nodes in the blockchain system 100).

[0059] When any of the other blockchain nodes receives the block to be agreed upon and the reference read sets corresponding to the multiple transactions contained in the block to be agreed upon, it will detect in parallel whether the reference read set of each transaction matches the local read set of each transaction in the local storage area during the process of executing the above multiple transactions based on the multiple reference read sets.

[0060] If each transaction is successfully executed, and the reference read set and local read set of each transaction match, a verification result is generated to indicate that the block to be consensus has been successfully verified; if the reference read set and local read set of any transaction do not match, a verification result is directly generated to indicate that the block to be consensus has failed to be verified. Finally, any blockchain node can send the generated verification result to blockchain node 101, so that blockchain node 101 can reach a consensus on the block to be consensus based on the verification result.

[0061] It should be noted that the embodiments of the present application can be applied to various scenarios, including but not limited to smart finance, cloud technology, AI (Artificial Intelligence), smart medical care, smart schools and other scenarios, without limitation to this.

[0062] At the same time, in the specific implementation of this application, if the data or information such as consensus blocks, transactions, read-write sets, etc. involves object-related, when the embodiments of this application are applied to specific products or technologies, it is necessary to obtain the object's permission or consent, and the collection, use and processing of relevant data or information need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0063] The following is a detailed description of various implementation details of the technical solution of the embodiment of the present application:

[0064] like Figure 3 As shown, Figure 3 This is a flowchart of a data processing method based on blockchain shown in an embodiment of the present application. The method can be applied to Figure 1 In the blockchain system shown, the method can be executed by any blockchain node (i.e., slave node) in the blockchain system except the blockchain node (i.e., master node) that initiates the consensus proposal. In the embodiment of the present application, the method is described by taking the slave node as an example, wherein the data processing method based on blockchain may include S301 to S304, which are described in detail as follows:

[0065] S301, receiving the block to be agreed upon sent by the master node, and the reference read sets corresponding to the multiple transactions contained in the block to be agreed upon.

[0066] In the embodiment of the present application, the block to be agreed upon refers to a block that has not yet reached a consensus. The block needs to be added to the blockchain after the consensus is successful. The block to be agreed upon usually contains information such as multiple transactions and the transaction execution order between multiple transactions. Optionally, the block to be agreed upon may also contain a reference read set of each transaction; therefore, after receiving the block to be agreed upon, the reference read set of each transaction in the block to be agreed upon is actually received.

[0067] The reference read set of each transaction may include: the state value of the transaction parameters that the master node needs to use when executing each transaction. Specifically, the reference read set of each transaction is the state value of the transaction parameters read from the node database of the master node by the consensus node (i.e., the master node) that initiates the consensus proposal for the block to be agreed upon when executing each transaction.

[0068] In addition, the consensus node in the blockchain is the blockchain node, and the blockchain node can be called a consensus node under the consensus mechanism. The execution subject in the embodiment of the present application is also a consensus node other than the master node in the blockchain system (hereinafter referred to as the current node).

[0069] In contrast, other consensus nodes in the blockchain can be called slave nodes, and the aforementioned current node is also any of the multiple slave nodes. Specifically, after the master node packages the block to be agreed upon, it can broadcast the block to be agreed upon to all slave nodes.

[0070] Optionally, other slave nodes may send the block to be agreed upon to the current node after receiving the block to be agreed upon sent by the master node, which is not limited here. The reference read sets corresponding to multiple transactions are similar and will not be described in detail here.

[0071] In one embodiment, the master node may initiate a consensus proposal for the block to be agreed upon, which may include the block to be agreed upon and reference read sets corresponding to multiple transactions contained in the block to be agreed upon; then, the master node may broadcast the consensus proposal to the slave node, and the slave node may parse the received consensus proposal to obtain the block to be agreed upon and reference read sets corresponding to multiple transactions contained in the block to be agreed upon.

[0072] In one embodiment, since the block to be agreed upon and the reference read sets corresponding to the multiple transactions are sent by the master node to the current node so that the current node can verify the block to be agreed upon; therefore, the current node will preferentially cache the received data to the memory in the local storage area, so as to improve the subsequent reading efficiency of the multiple transactions in the consensus block and the reference read sets corresponding to the multiple transactions.

[0073] S302 . In the process of respectively executing corresponding transactions based on reference read sets of multiple transactions, a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area is obtained in parallel.

[0074] In the embodiment of the present application, the local read set of any transaction in the local storage area may specifically include: the state value of the transaction parameter in the reference read set corresponding to any transaction in the local storage area.

[0075] Therefore, the process of obtaining the local read set of any transaction in the local storage area can be specifically: for the transaction parameters in the reference read set of any transaction, query the status value corresponding to the transaction parameter from the local storage area; and use the queried status value of the transaction parameter as the local read set of any transaction.

[0076] For example, the transaction parameter in the reference read set of any transaction is "account balance", and its corresponding status value is 100 yuan. Then, the transaction parameter "account balance" can be found in the local storage area, and the status value corresponding to the found transaction parameter is used as the local read set of any transaction.

[0077] In one embodiment, the local storage area may include at least one of the disk of the current node (specifically, the node database) and the memory of the current node. Optionally, since the node database of each node in the blockchain mentioned above maintains the state value corresponding to the transaction parameter, and the storage space of the node database (i.e., the disk) is much larger than the storage space of the memory; therefore, the local read set of any transaction is usually stored in the node database.

[0078] It should be noted that there may be a small number of local read sets stored in the memory. In this case, you can choose to search for the local read set from the memory first, and then search for the local read set from the disk if it is not found; or, you can choose to search for the local read set from the disk first, and then search for the local read set from the memory if it is not found.

[0079] In one embodiment, two parallel execution processes may be created, one transaction execution process is used to execute each transaction based on the reference read set of each transaction, and the other read set verification process is used to detect whether the reference read set of each transaction matches the local read set of each transaction in the local storage area, thereby obtaining a read set matching result for each transaction. The read set matching result of any transaction is used to indicate that the reference read set and the local read set of any transaction match, or that the reference read set and the local read set of any transaction do not match.

[0080] Specifically, the method of determining whether two read sets match may include: reading the transaction parameters respectively contained in the two read sets, and the status values ​​corresponding to the transaction parameters respectively contained in the two read sets; if the transaction parameters respectively contained in the two read sets are the same, and the status values ​​corresponding to the transaction parameters respectively contained in the two read sets are the same, then a read set matching result can be generated to characterize that the two read sets match.

[0081] In one possible implementation, there may be certain transaction dependencies between multiple transactions in the block to be agreed upon due to the business to which the transactions belong, that is, some transactions need to be executed before other transactions; therefore, there may be a transaction execution order between multiple transactions in the block to be agreed upon.

[0082] In some embodiments, there may be transaction dependencies between multiple transactions, which need to be executed serially. Then, the transaction execution process can traverse the multiple transactions according to the transaction execution order between the multiple transactions, and execute the next traversed transaction after the current traversed transaction is executed.

[0083] Furthermore, the read set verification process executed in parallel with the transaction execution process can also traverse the reference read sets of multiple transactions according to the transaction execution order between the multiple transactions, so as to detect whether the currently traversed reference read set matches the local read set of the corresponding transaction in the local storage area, and obtain the read set matching result of the corresponding transaction.

[0084] Furthermore, the read set verification process can also obtain the reference read set and local read set of the transaction currently being executed by the transaction execution process, and then detect whether the reference read set and local read set of the currently executing transaction match, thereby obtaining the read set matching result of the currently executing transaction.

[0085] In the specific implementation, since the execution of the transaction needs to call the corresponding smart contract, the transaction execution process can be a smart contract engine. Figure 4 , shows a schematic diagram of the block verification process of a slave node. Figure 4 As shown, the slave node 401 may include a smart contract engine 402, a read set verification module 403 (equivalent to the aforementioned read set verification process) and a node database 404. Among them, the smart contract engine 402 may include multiple smart contracts such as contract A, contract B, contract C, contract D, etc.; the node database 404 stores the state values ​​corresponding to multiple transaction parameters maintained by the slave node 401. After the slave node 401 receives the reference read sets corresponding to the consensus block and multiple transactions in the consensus block, the multiple transactions and the corresponding multiple reference read sets can be cached in the memory.

[0086] like Figure 4As shown, the smart contract engine 402 can read the reference read set of each transaction from the memory of the slave node 401, and then the smart contract engine 402 can find a contract that matches each transaction from multiple smart contracts. Finally, the smart contract engine 402 can execute the corresponding contract based on the state value of the transaction parameter in the reference read set of each transaction, thereby realizing the execution of the transaction that needs to be executed currently.

[0087] Optionally, if it is detected that any transaction in the smart contract engine 402 fails to execute, the slave node 401 controls the smart contract engine 402 to stop executing the transaction and generates a verification result indicating that the verification of the block to be consensus has failed.

[0088] At the same time, the read set verification module 403 can read the reference read set of each transaction from the memory of the slave node 401 and read the local read set of each transaction from the node database 404; and then verify whether the two read sets corresponding to each transaction match.

[0089] If the read set verification module 403 verifies that the two read sets corresponding to a transaction do not match, the slave node 401 can control the smart contract engine 402 to stop executing the transaction, and control the read set verification module 403 to stop verifying the read set, and generate a verification result for characterizing the failure of verification of the block to be consensus.

[0090] In other embodiments, some of the multiple transactions may have transaction dependencies between them and need to be executed serially; while other transactions do not have transaction dependencies with these transactions. In this case, in order to further improve the efficiency of transaction execution and thus increase the verification speed of consensus blocks, other transactions and these transactions may be executed in parallel.

[0091] Specifically, the multiple transactions can be grouped and processed to obtain multiple transaction sequences; wherein there is no transaction execution order between the transactions contained in different transaction sequences, and there is a transaction execution order between the transactions contained in the same transaction sequence; then, the smart contract engine is called to execute the transactions in the multiple transaction sequences in parallel.

[0092] Optionally, the specific process of calling the smart contract engine to execute transactions in multiple transaction sequences in parallel may include: calling the smart contract engine to create a corresponding transaction execution thread for each transaction sequence; calling multiple transaction execution threads in parallel so that each transaction execution thread reads the status value contained in the read set of each transaction in the corresponding transaction sequence in turn; obtaining a smart contract that matches the target transaction corresponding to the currently read status value; and executing the obtained smart contract based on the currently read status value to obtain the local write set of the target transaction.

[0093] Optionally, the read set verification process can create a corresponding read set verification thread for each transaction execution thread. That is, the number of transaction execution threads and read set verification threads can be the same, and there is an executing transaction in each transaction execution thread; therefore, for each executing transaction, there will be a corresponding read set verification thread to detect whether the reference read set and the local read set of the transaction match, thereby obtaining the corresponding read set matching result.

[0094] It can be seen that the embodiments of the present application can perform parallel processing of multiple groups of transactions in the process of transaction execution and read set verification through multi-threading, thereby maximizing the performance advantages of multi-core processors, which is beneficial to improving the verification speed of consensus blocks; it is beneficial to further improve the performance and transaction throughput of the blockchain system.

[0095] Furthermore, before checking whether the reference read set and local read set of any transaction match, it is necessary to first query the reference read set and local read set of any transaction. As mentioned above, the reference read set of each transaction is usually stored in memory, and the speed of querying data from memory is relatively high; however, the local read set of each transaction is usually stored in the disk, and when the disk contains massive data, the query speed will be slow.

[0096] Therefore, in order to further improve the query speed of the local read set and thus improve the verification speed of the consensus block, the local read sets corresponding to each transaction being executed can be queried in parallel from the local storage area; then, based on the queried local read sets of each transaction being executed and the reference read sets corresponding to each transaction being executed, the read set matching results corresponding to each transaction being executed can be obtained.

[0097] Compared with the traditional solution of querying the local read set of each transaction from the node database and then executing each transaction based on the local read set of each transaction, the embodiment of the present application can directly execute each transaction based on the reference read set of each transaction; and the reference read set of each transaction is cached in the memory, and the reading (or query) speed is faster. Therefore, the embodiment of the present application reduces the demand for disk data reading during the transaction execution process by directly executing each transaction based on the reference read set of each transaction, thereby achieving the purpose of optimizing system resource utilization.

[0098] In addition, in smart contracts that use container technology solutions (such as Fabric), the smart contract engine will generate frequent network requests when querying the read set from the node database, and network latency will further reduce the verification speed of the consensus block. Therefore, the embodiment of the present application can also avoid frequent network requests when using the container technology solution by directly executing each transaction based on the reference read set of each transaction, reducing network latency, helping to improve the verification speed of the consensus block, and improving the performance and stability of the blockchain system.

[0099] In a specific implementation, multiple read set verification threads may be called to read reference read sets corresponding to each exchange being executed from memory respectively; and local read sets corresponding to each exchange being executed may be queried from the node database respectively.

[0100] S303: Based on the read set matching results of each transaction, generate the verification results of the block to be consensus.

[0101] In the embodiment of the present application, the verification result can be a number, letter, symbol, field, etc., which is not limited here. For example, the number "1" can be set to represent the successful verification of the block to be consensus, and the number "0" can be set to represent the failure of the verification of the block to be consensus.

[0102] In one embodiment, based on the read set matching result of each transaction, the specific process of generating the verification result of the block to be agreed upon may include: if the read set matching result of any transaction is used to represent that the reference read set of the corresponding transaction does not match the local read set, then the transaction is stopped and a verification result representing that the verification of the block to be agreed upon has failed is generated; if the read set matching result of each transaction is used to represent that the reference read set of the corresponding transaction matches the local read set, and each transaction is executed successfully, then a verification result representing that the verification of the block to be agreed upon has succeeded is generated.

[0103] Optionally, if a failed transaction is detected in the process of executing corresponding transactions based on reference read sets of multiple transactions, a verification result representing the failure of verification of the block to be agreed upon can also be generated.

[0104] S304: Send the verification result to the master node so that the master node can reach a consensus on the consensus block based on the verification result.

[0105] In an embodiment of the present application, in addition to receiving the verification result of the current node, the master node also receives the verification results sent by other slave nodes respectively; then, when the master node detects that the number of verification results used to characterize successful verification is greater than a preset number threshold, it can determine that the block to be agreed upon has reached a consensus and add the block to be agreed upon to the blockchain.

[0106] The preset quantity threshold may be set manually or by any blockchain node in the above blockchain system, which is not limited here. Specifically, the preset quantity threshold may also be set based on the above consensus algorithm.

[0107] Furthermore, after it is determined that the block to be agreed upon has reached a consensus, the master node can also broadcast the on-chain information about the block to be agreed upon to each slave node, so that each slave node can update the state value of the transaction parameters maintained by each slave node according to the write sets corresponding to the multiple transactions in the block to be agreed upon. The write set includes the state value corresponding to the transaction parameters updated during the transaction execution process.

[0108] In one embodiment, the current node may also send the verification result generated by the current node to other slave nodes in the blockchain.

[0109] Furthermore, the slave node may also receive verification results sent by other slave nodes, and when it detects that the number of verification results used to indicate successful verification is greater than a preset number threshold, it determines that the block to be agreed upon has reached a consensus, and adds the block to be agreed upon to the blockchain.

[0110] In an embodiment of the present application, by obtaining the read set matching results of each transaction in parallel during the process of executing Xiangyin transactions based on reference read sets of multiple transactions, it is possible to achieve parallel execution of transaction execution and read set verification. Compared with the traditional solution that requires executing all transactions in the consensus block first and then performing read-write set verification; the embodiment of the present application can reduce the time cost of the two processes of serial execution of read set verification and transaction execution, thereby greatly improving the verification speed of consensus blocks; at the same time, in the case of read set mismatch, the embodiment of the present application can stop executing transactions in advance to avoid the waste of resources and time caused by executing subsequent transactions, thereby effectively improving the verification speed of identified blocks.

[0111] In addition, with the improvement of block verification speed, blockchain nodes can show strong adaptability in the face of massive blockchain data scenarios, which greatly reduces the impact of the continuously growing data to be processed on blockchain nodes, thereby helping to improve the overall performance of the blockchain system.

[0112] In summary, the embodiments of the present application have brought significant changes in parallel execution, resource utilization optimization, multi-core processor performance utilization, adaptability improvement, and network latency reduction. These changes enable blockchain nodes to maintain high performance in the context of massive data and meet growing business needs.

[0113] In one embodiment of the present application, Figure 5 As shown, a flowchart of another data processing method based on blockchain is provided, which can be applied to Figure 1 The blockchain system shown in the figure, the method can be executed by any blockchain node (i.e., slave node) in the blockchain system except the blockchain node (i.e., master node) that initiates the consensus proposal. In the embodiment of the present application, the method is executed by the slave node as an example. The data processing method based on blockchain is Figure 3 The method shown was expanded upon.

[0114] Among them, S501 to S505 are described in detail as follows:

[0115] S501, receiving a block to be agreed upon sent by a consensus node in a blockchain, and a reference read set and a reference write set corresponding to a plurality of transactions contained in the block to be agreed upon.

[0116] In an embodiment of the present application, the reference write set of each transaction may include the state value of the transaction parameters updated by the master node when executing each transaction.

[0117] Optionally, the block to be agreed upon may include reference write sets corresponding to multiple transactions contained in the block to be agreed upon. Therefore, after receiving the block to be agreed upon, the reference write sets of each transaction in the block to be agreed upon are actually received.

[0118] Optionally, referring to the description of the reference read sets corresponding to the multiple transactions in step S301, the reference write sets of the respective transactions may also be preferentially cached to the memory in the local storage area.

[0119] It should be noted that the specific implementation of receiving the block to be agreed upon and the reference read set and the reference write set corresponding to the multiple transactions can be referred to the specific implementation of step S301, which will not be described in detail here.

[0120] S502 . In the process of respectively executing corresponding transactions based on reference read sets of multiple transactions, obtain in parallel a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area.

[0121] In the embodiment of the present application, the specific implementation of step S502 can refer to the specific implementation of step S302 in the above embodiment, which will not be repeated here.

[0122] S503: If it is detected that any transaction is completed, a write-set matching result between a local write-set obtained after any transaction is completed and a reference write-set of any transaction is obtained.

[0123] In the embodiment of the present application, the local write set obtained after any transaction is executed can specifically include: the state value of the transaction parameter updated during the process of executing any transaction from the node. Therefore, after the slave node completes any transaction, the local write set corresponding to any transaction can be obtained.

[0124] In one embodiment, the process of obtaining the write-set matching result of any transaction may specifically include: if the transaction parameters in the reference write-set of any transaction are the same as the transaction parameters in the local write-set of any transaction, and the state values ​​corresponding to the same transaction parameters are the same, then a write-set matching result can be generated to characterize that the local write-set of any transaction matches the reference write-set; if the reference write-set of any transaction and the local write-set of any transaction have different transaction parameters, or the reference write-set of any transaction and the state values ​​corresponding to the same transaction parameters in the local write-set of any transaction are different, then a write-set matching result can be generated to characterize that the local write-set of any transaction does not match the reference write-set.

[0125] In one embodiment, in order to avoid the waste of resources caused by continuing to perform write set verification on certain transactions after the local read set and reference read set of certain transactions have been determined to be mismatched, and further optimize the utilization of system resources, the write set verification of a transaction can be performed after the read set of a transaction is determined to be matched.

[0126] Specifically, the read set matching result between the reference read set of any transaction and the local read set of any transaction can also be obtained; if the obtained read set matching result is used to characterize the matching between the reference read set of any transaction and the local read set of any transaction, then the step of obtaining the write set matching result between the local write set of any transaction and the reference write set in step S503 is triggered.

[0127] In the specific implementation, referring to the description of the transaction execution process and the read-set verification process in step S302, a write-set verification process may also be created; then, by executing the transaction execution process, the read-set verification process, and the write-set verification process in parallel, the three processes of transaction execution, read-set verification, and write-set verification are executed in parallel, thereby further improving the verification speed of the consensus block.

[0128] Optionally, referring to the description of the transaction execution thread and the read-set verification thread in step S302, a corresponding write-set verification thread may be created for each transaction execution thread, thereby realizing the parallel execution of multiple transaction execution threads, multiple read-set verification threads, and multiple write-set verification threads, which is beneficial to greatly improve the verification speed of the consensus blocks, so that the slave nodes can still maintain high performance in the context of massive data, thereby meeting the growing business needs.

[0129] In a possible implementation, the local write set obtained after any transaction is executed can be cached in the memory. Specifically, the transaction dependency mentioned in step S302 may include a write-read dependency. The write-read dependency means that the state value of the transaction parameter required to execute the subsequent transaction is updated during the execution of the previous transaction.

[0130] Therefore, if any transaction has a write-read dependency with a specified transaction that precedes any transaction in the transaction execution order, the local write set obtained after executing the specified transaction can be obtained; then, the obtained local write set is used as a reference read set for any transaction.

[0131] It can be seen from this that if the local write set corresponding to the earlier transaction in two transactions with write-read dependencies is cached in memory, the later transaction in the two transactions with write-read dependencies can read the read set required for its execution more quickly; and the improvement in data reading speed is conducive to the overall improvement of the verification speed of the blocks to be consensus.

[0132] Furthermore, due to the limited storage space of the memory, the local write set of each transaction is less important than the reference read set, transaction information and other data of each transaction; therefore, the local write set of each transaction may be stored to the disk (i.e., the node database) after the storage space of the memory is full.

[0133] Then, when any transaction has a write-read dependency with the specified transaction, you can respond to the execution request of any transaction by first querying the local write set of the specified transaction from the memory to obtain the query result; if the query result does not include the local write set of the specified transaction, then send a write set query request to the node database to obtain the local write set of the specified transaction.

[0134] S504: Generate the verification result of the block to be agreed upon based on the read set matching result and the write set matching result of each transaction.

[0135] In an embodiment of the present application, based on the read set matching result and the write set matching result of each transaction, the specific process of generating the verification result of the block to be agreed upon may include: if the read set matching result of any transaction is used to characterize that the reference read set of the corresponding transaction does not match the local read set, the write set matching result of any transaction is used to characterize that the reference write set of the corresponding transaction does not match the local write set, or any transaction fails to execute, then the transaction is stopped and a verification result characterizing the failure of verification of the block to be agreed upon is generated; if the read set matching result of each transaction is used to characterize that the reference read set of the corresponding transaction matches the local read set, the write set matching result of each transaction is used to characterize that the reference write set of the corresponding transaction matches the local write set, and each transaction is executed successfully, then a verification result characterizing the successful verification of the block to be agreed upon is generated.

[0136] S505. Send the verification result to the master node so that the master node can reach a consensus on the consensus block based on the verification result.

[0137] In the embodiment of the present application, the specific implementation of step S505 can refer to the specific implementation of step S304 in the above embodiment, which will not be repeated here.

[0138] For specific implementation, see the attached Figure 6 , shows a schematic diagram of the verification process of a slave node for a consensus block. Figure 6 As shown, after receiving the consensus block sent by the master node, the slave node needs to first perform a transaction format check on the consensus block. If the check passes, the subsequent transaction signature check will continue; if the check fails, it means that the consensus block has not obtained the consensus of the slave node, so the verification process of the consensus block can be exited, and a verification result is generated to indicate that the verification of the consensus block has failed. Among them, the transaction format check can specifically include checking one or more information such as the version number, timestamp, difficulty target, random number, hash value of the previous block, Merkle root, etc. of the consensus block.

[0139] After the transaction format check passes, such as Figure 6 As shown, it is necessary to continue to check the transaction signature of the consensus block. If the check passes, the subsequent transaction execution will continue; if the check fails, it means that the consensus block has not obtained the consensus of the slave nodes, so the verification process of the consensus block can be exited, and a verification result is generated to indicate that the verification of the consensus block has failed. Among them, the transaction signature check can specifically be to check the digital signature used by the object that initiated the transaction in the consensus block, which will not be elaborated here.

[0140] like Figure 6 As shown in the figure, after the transaction signature check passes, the slave node will simultaneously perform the two processes of read-write set verification and transaction execution. Among them, the process of read-write set verification can include two sub-processes of read set verification and write set verification executed in parallel. Read set verification includes detecting whether the local read set and reference read set of the transaction match. If they match, it means that the read set verification is successful. If any transaction does not match, it means that the read set verification has failed. Similarly, write set verification includes detecting whether the local write set and reference write set of the transaction match. If they match, it means that the write set verification is successful. If any transaction does not match, it means that the write set verification has failed.

[0141] Therefore, if Figure 6 As shown in the figure, if the read set or write set verification of any transaction fails, it means that the block to be agreed upon has not obtained the consensus of the slave node, so the processing flow of the block to be agreed upon can be exited. At the same time, if the transaction execution fails when the slave node executes any transaction, it means that the block to be agreed upon has not obtained the consensus of the slave node, so the verification flow of the block to be agreed upon can be exited, and a verification result is generated to indicate that the verification of the block to be agreed upon has failed.

[0142] Finally, after all transactions in the block to be agreed upon are successfully executed and the read-write set verification of all transactions is successful, it can be determined that the block to be agreed upon has not obtained the consensus of the slave nodes, so the verification process of the block to be agreed upon can be ended, and a verification result is generated to indicate the successful verification of the block to be agreed upon.

[0143] Furthermore, since the write-read dependency is mentioned in step S502, in the specific implementation, please refer to the attached Figure 7 , showing a schematic diagram of the process of read-write set verification.

[0144] like Figure 7 As shown in the figure, after starting the read-write set verification, it is first necessary to determine whether the read-write sets of multiple transactions are parsed successfully. In actual applications, the read-write sets of multiple transactions sent by the master node to the slave node are specifically the state of the data stream. The smart contract corresponding to the transaction is specifically a piece of code; therefore. In order to be able to execute the transaction, the read-write sets of multiple transactions need to be parsed into a data structure that can be used by the code.

[0145] like Figure 7 As shown, if the analysis is successful, the subsequent steps of parallel execution of read-write set verification are performed; if the analysis fails, the verification process of the block to be consensus can be exited, and a verification result is generated to characterize the failure of verification of the block to be consensus.

[0146] Then, executing read-write set verification in parallel may include executing read-set verification and write-set verification in parallel; optionally, executing read-write set verification in parallel may also include: in a scenario where there are multiple parallel transaction sequences and there is one transaction being executed in each transaction sequence, performing read-set verification and write-set verification on each transaction being executed in parallel.

[0147] Similarly, if the read set or write set verification of any transaction fails, it means that the block to be consensus has not obtained the consensus of the slave nodes, and the processing flow of the block to be consensus can be exited.

[0148] At the same time, Figure 7 As shown, if it is detected that the transaction to be executed has a write-read dependency with a previously executed transaction, it is possible to first query whether there is a local write set of the corresponding transaction in the memory; if it exists in the memory, the queried local write set is used as the reference read set of the transaction to be executed, thereby executing the transaction to be executed.

[0149] like Figure 7 As shown, if it does not exist in the memory, continue to query whether there is a local write set of the corresponding transaction from the node database. If it exists in the node database, the queried local write set is used as the reference read set of the transaction to be executed, so as to execute the transaction to be executed; if it does not exist in the node database, it means that the block to be consensus has not obtained the consensus of the slave node, so the processing flow of the block to be consensus can be exited. Finally, when the read-write set verification of all transactions is completed, the read-write set verification process can be ended.

[0150] In the embodiment of the present application, in addition to the read set check, the write set check is also added, which is conducive to further improving the check accuracy of the consensus block. At the same time, by executing transactions, read set check and write set check in parallel, the check speed of the consensus block can be greatly improved compared with the traditional solution. Figure 3 The embodiment shown, the embodiment of the present application can improve the verification accuracy of the consensus block while ensuring a relatively high verification speed.

[0151] Herein, an apparatus embodiment of the present application is introduced, which can be used to execute the data processing system method based on blockchain in the above-mentioned embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the above-mentioned embodiment of the data processing system method based on blockchain in the present application.

[0152] The embodiment of the present application provides a data processing device based on blockchain, wherein the blockchain includes a master node and a slave node, and the device is configured on the slave node. Figure 8 As shown, the device includes a receiving unit 801, a parallel processing unit 802, a generating unit 803 and a sending unit 804, wherein:

[0153] The receiving unit 801 is configured to receive the block to be agreed upon sent by the master node, and the reference read sets corresponding to the multiple transactions contained in the block to be agreed upon; wherein the reference read set includes the state value corresponding to the transaction parameter required by the master node to execute the corresponding transaction;

[0154] The parallel processing unit 802 is configured to obtain read set matching results between the reference read set of each transaction and the local read set of each transaction in the local storage area in parallel during the process of executing corresponding transactions respectively based on the reference read sets of multiple transactions;

[0155] The generating unit 803 is configured to generate a verification result of the block to be consensus based on the read set matching result of each transaction; wherein the verification result is used to indicate whether the block to be consensus is successfully verified;

[0156] The sending unit 804 is configured to send the verification result to the master node, so that the master node reaches a consensus on the consensus block based on the verification result.

[0157] In one embodiment of the present application, based on the aforementioned scheme, when the generation unit 803 generates the verification result of the block to be agreed upon based on the read set matching result of each transaction, it can be specifically configured to: if the read set matching result of any transaction is used to represent that the reference read set of the corresponding transaction does not match the local read set, then the transaction is stopped from being executed, and a verification result representing that the verification of the block to be agreed upon has failed is generated; if the read set matching result of each transaction is used to represent that the reference read set of the corresponding transaction matches the local read set, and each transaction is executed successfully, then a verification result representing that the verification of the block to be agreed upon has succeeded is generated.

[0158] In one embodiment of the present application, based on the aforementioned scheme, the receiving unit 801 can also be configured to: receive reference write sets corresponding to multiple transactions sent by the master node; wherein the reference write set includes the state value corresponding to the transaction parameters updated during the execution of the corresponding transaction by the master node. The parallel processing unit 802 can also be configured to: if it is detected that any transaction is completed, obtain the write set matching result between the local write set obtained after the completion of any transaction and the reference write set of any transaction. When the generation unit 803 generates the verification result of the block to be agreed upon based on the read set matching result of each transaction, it can be specifically configured to: generate the verification result of the block to be agreed upon based on the read set matching result and the write set matching result of each transaction.

[0159] In one embodiment of the present application, based on the aforementioned scheme, the parallel processing unit 802 can also be configured to: if the read set matching result of any transaction is used to characterize the match between the reference read set of any transaction and the local read set of any transaction, then trigger the step of obtaining the write set matching result between the local write set obtained after the execution of any transaction is completed and the reference write set of any transaction.

[0160] In one embodiment of the present application, multiple transactions have a transaction execution order; based on the aforementioned scheme, the parallel processing unit 802 can also be configured to: if any transaction has a write-read dependency with a specified transaction that is before any transaction in the transaction execution order, then obtain the local write set obtained after executing the specified transaction; wherein the write-read dependency means that the state value of the transaction parameter required to execute the subsequent transaction is updated during the execution of the prior transaction; and use the local write set of the specified transaction as a reference read set for any transaction.

[0161] In one embodiment of the present application, the local storage area includes memory and disk; based on the aforementioned scheme, the parallel processing unit 802 can also be configured to: cache the local write set of the specified transaction to the memory; respond to the execution request of any transaction, query the local write set of the specified transaction from the memory, and obtain the query result; if the query result does not include the local write set of the specified transaction, send a write set query request to the disk to obtain the local write set of the specified transaction.

[0162] In one embodiment of the present application, based on the aforementioned scheme, the parallel processing unit 802 can also be configured to: group multiple transactions to obtain multiple transaction sequences; wherein there is no transaction execution order between the transactions contained in different transaction sequences; and call the smart contract engine to execute transactions in multiple transaction sequences in parallel.

[0163] In one embodiment of the present application, in the process of executing transactions in multiple transaction sequences in parallel, there is a transaction being executed in a transaction sequence; based on the aforementioned scheme, the parallel processing unit 802 can also be configured to: query the local read sets corresponding to each transaction being executed in parallel from the local storage area; based on the reference read sets corresponding to each transaction being executed and the queried local read sets, obtain the read set matching results of each transaction being executed.

[0164] In one embodiment of the present application, based on the aforementioned scheme, when the parallel processing unit 802 calls the smart contract engine and executes the transactions contained in each transaction sequence in parallel, it can be specifically configured to: call the smart contract engine to create a corresponding transaction execution thread for each transaction sequence; call multiple transaction execution threads in parallel so that each transaction execution thread reads the status value contained in the read set of each transaction in the corresponding transaction sequence in turn; obtains the smart contract that matches the target transaction corresponding to the currently read status value; executes the obtained smart contract based on the currently read status value to obtain the local write set of the target transaction.

[0165] According to one embodiment of the present application, Figure 3 and Figure 5 The various steps involved in the method shown can be performed by Figure 8 The data processing device based on the blockchain is executed by various units in the shown device.

[0166] According to another embodiment of the present application, Figure 8 The various units in the blockchain-based data processing device shown are divided based on logical functions. The above-mentioned various units can be separately or completely combined into one or several other units to constitute, or one (some) of the units can be further divided into multiple smaller functional units to constitute, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. In other embodiments of the present application, the above-mentioned blockchain-based data processing device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by the collaboration of multiple units.

[0167] According to another embodiment of the present application, the program can be executed on a general computing device such as a computer device including a central processing unit (CPU), a random access memory medium (RAM), a read-only memory medium (ROM), and other processing elements and storage elements. Figure 3 or Figure 5 A computer program (including program code) for each step of the method shown in FIG. Figure 8 The data processing device based on blockchain shown in the figure, and the data processing method based on blockchain to implement the embodiment of the present application. The computer program can be recorded on, for example, a computer storage medium, and loaded into the above-mentioned computer device through the computer storage medium, and run therein.

[0168] It should be noted that the device provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment and will not be repeated here.

[0169] The apparatus provided in the above-mentioned embodiments can be arranged in a terminal device or in a server. The apparatus provided in the embodiments of the present application can realize parallel execution of transaction execution and read set verification by detecting in parallel whether the reference read set of the transaction and the local read set match during the process of executing each transaction based on the reference read set of each transaction, thereby greatly improving the verification speed of the consensus block.

[0170] An embodiment of the present application also provides an electronic device, comprising one or more processors and a storage device, wherein the storage device is used to store one or more computer programs. When the one or more computer programs are executed by one or more processors, the electronic device implements the above-mentioned blockchain-based data processing method.

[0171] Fig. 9 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0172] It should be noted that Fig. 9 The computer system 900 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0173] like Fig. 9As shown, the computer system 900 includes a processor (Central Processing Unit, CPU) 901, which can perform various appropriate actions and processes according to the program stored in the read-only memory (Read-Only Memory, ROM) 902 or the program loaded from the storage part 908 to the random access memory (Random Access Memory, RAM) 903, such as executing the method in the above embodiment. In RAM 903, various programs and data required for system operation are also stored. CPU 901, ROM 902 and RAM 903 are connected to each other through bus 904. Input / output (Input / Output, I / O) interface 905 is also connected to bus 904.

[0174] In some embodiments, the following components are connected to the I / O interface 905: an input section 906 including a keyboard, a mouse, etc.; an output section 907 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable medium 911, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 910 as needed, so that a computer program read therefrom is installed into the storage section 908 as needed.

[0175] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 909, and / or installed from a removable medium 911. When the computer program is executed by a processor (CPU) 901, various functions defined in the system of the present application are executed.

[0176] It should be noted that the computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (Erasable Programmable Read Only Memory), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer-readable signal medium provided in the above-mentioned various embodiments for the data acquisition method as described above may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0177] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the devices, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and a computer program.

[0178] The units or modules involved in the embodiments described in this application may be implemented by software or hardware, and the units or modules described may also be set in a processor. The names of these units or modules do not, in some cases, constitute limitations on the units or modules themselves.

[0179] Another aspect of the present application further provides a computer-readable medium having a computer program stored thereon, which implements the blockchain-based data processing method as described above when the computer program is executed by a processor. The computer-readable medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0180] The embodiment of the present application provides a computer program product or a computer program, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device performs the above-mentioned Figure 2 and Figure 5 The computer-readable storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0181] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0182] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0183] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person of ordinary skill in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A data processing method based on blockchain, characterized in that: The blockchain includes a master node and a slave node, and the method is applied to the slave node, and the method includes: Receive the block to be agreed upon sent by the master node, and the reference read sets corresponding to the multiple transactions contained in the block to be agreed upon; wherein the reference read set includes the state values ​​corresponding to the transaction parameters required by the master node to execute the corresponding transaction; In the process of respectively executing corresponding transactions based on reference read sets of multiple transactions, obtaining in parallel a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area; Based on the read set matching result of each transaction, a verification result of the block to be agreed upon is generated; wherein the verification result is used to indicate whether the block to be agreed upon is successfully verified; The verification result is sent to the master node so that the master node reaches a consensus on the block to be agreed upon based on the verification result.

2. The method according to claim 1, characterized in that Generating the verification result of the block to be consensus based on the read set matching result of each transaction includes: If the read set matching result of any transaction is used to indicate that the reference read set of the corresponding transaction does not match the local read set, the transaction is stopped and a verification result indicating that the verification of the block to be agreed upon has failed is generated; If the read set matching result of each transaction is used to represent that the reference read set of the corresponding transaction matches the local read set, and each of the transactions is executed successfully, a verification result representing that the verification of the block to be consensus is successful is generated.

3. The method according to claim 1, characterized in that The method further comprises: Receiving reference write sets corresponding to the multiple transactions respectively sent by the master node; wherein the reference write sets include state values ​​corresponding to transaction parameters updated during the execution of the corresponding transactions by the master node; If it is detected that any transaction is executed, obtaining a write set matching result between a local write set obtained after the execution of any transaction is completed and a reference write set of any transaction; The step of generating the verification result of the block to be consensus based on the read set matching result of each transaction further includes: Based on the read set matching result and the write set matching result of each transaction, a verification result of the block to be agreed upon is generated.

4. The method according to claim 3, characterized in that The method further comprises: If the read set matching result of any transaction is used to characterize that the reference read set of any transaction matches the local read set of any transaction, then the step of obtaining the write set matching result between the local write set obtained after the execution of any transaction is completed and the reference write set of any transaction is triggered.

5. The method according to claim 1, characterized in that The multiple transactions have a transaction execution order; the method further includes: If any transaction has a write-read dependency with a specified transaction that precedes the transaction in the transaction execution order, then the local write set obtained after executing the specified transaction is obtained; wherein the write-read dependency means that the state value of the transaction parameter required to execute the subsequent transaction is updated during the execution of the prior transaction; The local write set of the specified transaction is used as a reference read set of any transaction.

6. The method according to claim 5, characterized in that The local storage area includes a memory and a disk; the method further includes: caching the local write set of the specified transaction into the memory; In response to an execution request of any of the transactions, query the local write set of the specified transaction from the memory to obtain a query result; If the query result does not include the local write set of the specified transaction, a write set query request is sent to the disk to obtain the local write set of the specified transaction.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: The multiple transactions are grouped and processed to obtain multiple transaction sequences; wherein there is no transaction execution order between the transactions contained in different transaction sequences; Call the smart contract engine to execute transactions in multiple transaction sequences in parallel.

8. The method according to claim 7, characterized in that In the process of executing transactions in multiple transaction sequences in parallel, there is a transaction being executed in a transaction sequence; the method further includes: Parallel querying of local read sets corresponding to each transaction being executed from the local storage area; Based on the reference read sets corresponding to the transactions being executed and the queried local read sets, read set matching results of the transactions being executed are obtained.

9. The method according to claim 7, characterized in that: The calling of the smart contract engine to execute transactions in multiple transaction sequences in parallel includes: Calling the smart contract engine to create a corresponding transaction execution thread for each transaction sequence; Call multiple transaction execution threads in parallel, so that each transaction execution thread sequentially reads the state value contained in the read set of each transaction in the corresponding transaction sequence; Get the smart contract that matches the target transaction corresponding to the currently read state value; The acquired smart contract is executed based on the currently read state value to obtain the local write set of the target transaction.

10. A data processing device based on blockchain, characterized in that: The blockchain includes a master node and a slave node, the device is configured on the slave node, and the device includes a receiving unit, a parallel processing unit, a generating unit and a sending unit, wherein: The receiving unit is configured to receive the block to be consensus sent by the master node, and the reference read sets corresponding to the multiple transactions contained in the block to be consensus; wherein the reference read set includes the state value corresponding to the transaction parameter required by the master node to execute the corresponding transaction; The parallel processing unit is configured to, in the process of respectively executing corresponding transactions based on the reference read sets of multiple transactions, obtain in parallel a read set matching result between the reference read set of each transaction and the local read set of each transaction in the local storage area; The generating unit is configured to generate a verification result of the block to be consensus based on the read set matching result of each transaction; wherein the verification result is used to indicate whether the block to be consensus is successfully verified; The sending unit is configured to send the verification result to the master node, so that the master node reaches a consensus on the block to be agreed upon based on the verification result.

11. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the blockchain-based data processing method as described in any one of claims 1 to 9 is implemented.

12. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the blockchain-based data processing method as described in any one of claims 1 to 9.

Images