Read-write set generation method, device, storage medium and electronic device

Abstract

The present disclosure relates to a read-write set generation method, device, storage medium and electronic device to solve the read-set lock problem existing in a blockchain based on a read-write set method. The method comprises: receiving a transaction plan sent by an application; simulating the execution of the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set comprises a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update a world state database if the target write set is valid; and, caching write set pre-execution data according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular, to a read-write set generation method, device, storage medium and electronic device. Background Art

[0002] In a narrow sense, blockchain is a chain data structure that combines data blocks in a sequential manner in chronological order, and a distributed ledger that is cryptographically guaranteed to be tamper-proof and unforgeable. Each block contains the hash value of the previous block, starting from the genesis block. Once the data is recorded in the block, it is irreversible. In a broad sense, blockchain technology is a new distributed infrastructure and computing paradigm that uses block chain data structures to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script codes to program and operate data.

[0003] Blockchain modifies distributed ledgers through transactions. There are currently two main ledger methods in the blockchain world. One is to record transactions. The other is to record status, such as Ethereum and Hyperledger. Blockchain based on recording transactions is not very friendly to smart contracts because it does not directly record the final status. Ethereum and Hyperledger based on status recording are very suitable for using smart contracts. Smart contracts give blockchain the possibility of realizing unlimited applications, so the use of smart contracts is becoming more and more widespread. Ethereum and Hyperledger, which are also blockchains based on state recording, have different transaction execution mechanisms. Simply put, Ethereum executes transactions at the time of consensus, while Hyperledger executes transactions before consensus. One advantage of executing transactions before consensus and consensus only determining the final order of transactions is that the blockchain will not fork. Once a block is generated, the final result of the execution is determined, and there will be no rollback. Therefore, in the transaction scenario based on Hyperledger, after the transaction is entered into the block, the execution result of the transaction can be directly returned without waiting for confirmation. However, in the transaction process based on Hyperledger, there is a read set lock problem. Summary of the invention

[0004] The purpose of the present disclosure is to provide a read-write set generation method, device, storage medium and electronic device to solve the read-set lock problem existing in the blockchain based on the read-write set method.

[0005] In order to achieve the above-mentioned purpose, a first aspect of an embodiment of the present disclosure provides a method for generating a read-write set, the method comprising:

[0006] Receive the transaction plan sent by the application;

[0007] Simulate and execute the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update a world state database if the target write set is valid; and

[0008] Write-set pre-execution data is cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write-set.

[0009] Optionally, the target read set includes a unique key and a corresponding version, and the simulation executes the transaction plan to obtain the target read-write set of the transaction plan, including:

[0010] In the process of simulating the execution of the transaction plan, determining the unique key;

[0011] When it is determined that the cache has historical write set pre-execution data including the unique key, the version of the unique key is determined according to the historical version in the historical write set pre-execution data to obtain the target read set.

[0012] Optionally, the target write set includes the unique key and the corresponding modified value, and the simulation executes the transaction plan to obtain the target read-write set of the transaction plan, and further includes:

[0013] When it is determined that the cache has historical write-set pre-execution data including the unique key, the modification value is determined according to the historical modification value in the historical write-set pre-execution data to obtain the target write-set.

[0014] Optionally, the simulating execution of the transaction plan to obtain a target read-write set of the transaction plan includes:

[0015] Simulate and execute the transaction plan to determine an initial read-write set based on a local state database, wherein the initial read-write set includes an initial read set, and the initial read set includes a unique key and a corresponding initial version;

[0016] When it is determined that the cache has historical write set pre-execution data including the unique key, the initial version in the initial read set is corrected according to the historical version in the historical write set pre-execution data to obtain the target read set.

[0017] Optionally, the initial read-write set further includes an initial write set, and the initial write set includes the unique key and the corresponding initial modification value;

[0018] The method further comprises:

[0019] When it is determined that the cache has historical write set pre-execution data including the unique key, the initial modification value in the initial write set is modified according to the historical modification value in the historical write set pre-execution data to obtain the target write set.

[0020] Optionally, when it is determined that the cache has historical write set pre-execution data including the unique key, determining the version of the unique key according to a historical version in the historical write set pre-execution data to obtain the target read set includes:

[0021] If a plurality of the historical write set pre-execution data including the unique key are cached, the version of the unique key is determined from the most recently cached historical write set pre-execution data to obtain the target read set.

[0022] Optionally, the receiving the transaction plan sent by the application terminal includes:

[0023] Receiving a plurality of transaction plans sent by the application end;

[0024] The simulating and executing the transaction plan to obtain a target read-write set of the transaction plan, and caching write-set pre-execution data according to the target read-write set, includes:

[0025] The step of executing the simulated execution of the transaction plan for each of the multiple transaction plans in turn to obtain a target read-write set of the transaction plan, and caching write set pre-execution data according to the target read-write set.

[0026] Optionally, the step of executing the simulated execution of the transaction plan for each of the multiple transaction plans in sequence to obtain a target read-write set of the transaction plan, and caching write set pre-execution data according to the target read-write set includes:

[0027] Sorting the plurality of transaction plans to obtain a transaction plan sequence;

[0028] According to the transaction plan sequence, for each transaction plan in turn, the step of simulating the execution of the transaction plan to obtain a target read-write set of the transaction plan, and caching the write set pre-execution data according to the target read-write set.

[0029] Optionally, the step of sorting the plurality of transaction plans to obtain a transaction plan sequence includes:

[0030] Determine target transaction plans that have a reference relationship between transaction plans;

[0031] Bundle the target transaction plans into an overall plan;

[0032] The overall plan and other transaction plans except the target transaction plan are sorted to obtain the transaction plan sequence.

[0033] Optionally, the method further comprises:

[0034] After updating the world state database according to the target write set, deleting the write set pre-execution data cached according to the target read-write set.

[0035] A second aspect of an embodiment of the present disclosure provides a read-write set generation device, the device comprising:

[0036] The receiving module is used to receive the transaction plan sent by the application end;

[0037] An execution module is used to simulate the execution of the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update a world state database when the target write set is valid; and write set pre-execution data is cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set.

[0038] Optionally, the target read set includes a unique key and a corresponding version, and the execution module includes:

[0039] A first determination submodule, used to determine the unique key during the process of simulating the execution of the transaction plan;

[0040] The second determination submodule is used to determine the version of the unique key according to the historical version in the historical write set pre-execution data to obtain the target read set when it is determined that the cache has historical write set pre-execution data including the unique key.

[0041] Optionally, the target write set includes the unique key and the corresponding modified value, and the execution module further includes:

[0042] The third determination submodule is used to determine the modification value according to the historical modification value in the historical write set pre-execution data to obtain the target write set when it is determined that the cache has the historical write set pre-execution data including the unique key.

[0043] Optionally, the execution module includes:

[0044] A generating submodule, for simulating the execution of the transaction plan, to determine an initial read-write set based on a local state database, wherein the initial read-write set includes an initial read set, and the initial read set includes a unique key and a corresponding initial version;

[0045] The first correction module is used to correct the initial version in the initial read set according to the historical version in the historical write set pre-execution data to obtain the target read set when it is determined that the cache has historical write set pre-execution data including the unique key.

[0046] Optionally, the initial read-write set further includes an initial write set, and the initial write set includes the unique key and the corresponding initial modification value;

[0047] The execution module also includes:

[0048] The second correction module is used to correct the initial modification value in the initial write set according to the historical modification value in the historical write set pre-execution data to obtain the target write set when it is determined that the cache has historical write set pre-execution data including the unique key.

[0049] Optionally, the second determining submodule includes:

[0050] The first execution submodule is used to determine the version of the unique key from the most recently cached historical write set pre-execution data to obtain the target read set if multiple historical write set pre-execution data including the unique key are cached.

[0051] Optionally, the receiving module is further used to receive a plurality of the transaction plans sent by the application end;

[0052] Correspondingly, the execution module is also used to execute the simulated execution of the transaction plan for each of the multiple transaction plans in turn, obtain the target read-write set of the transaction plan, and cache the write set pre-execution data according to the target read-write set.

[0053] Optionally, the execution module includes:

[0054] A sorting submodule, used for sorting the plurality of transaction plans to obtain a transaction plan sequence;

[0055] The second execution submodule is used to execute the simulated execution of the transaction plan for each transaction plan in turn according to the transaction plan sequence, obtain the target read-write set of the transaction plan, and cache the write set pre-execution data according to the target read-write set.

[0056] Optionally, the sorting submodule includes:

[0057] A fourth determination submodule is used to determine a target transaction plan having a reference relationship between the transaction plans;

[0058] A bundling submodule, used to bundle the target transaction plans into an overall plan;

[0059] The third execution submodule is used to sort the overall plan and other transaction plans except the target transaction plan to obtain the transaction plan sequence.

[0060] Optionally, the device further comprises:

[0061] A deletion module is used to delete the write-set pre-execution data cached according to the target read-write set after updating the world state database according to the target write-set.

[0062] A third aspect of an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0063] A fourth aspect of the embodiments of the present disclosure provides an electronic device, including:

[0064] a memory having a computer program stored thereon;

[0065] A processor is used to execute the computer program in the memory to implement the steps of the method described in the first aspect.

[0066] By adopting the above technical solution, at least the following beneficial technical effects can be achieved:

[0067] Receive the transaction plan sent by the application, and simulate the execution of the transaction plan to obtain the target read-write set of the transaction plan. Cache the write set pre-execution data according to the target read-write set to generate a new target read-write set for the new transaction plan before updating the world state database according to the target write set in the target read-write set. In this way, before the transaction data of the transaction plan is uploaded to the chain (that is, the data is stored in the blockchain) (that is, before the world state database is updated according to the target write set in the target read-write set of the transaction plan), the transaction plan can be prevented from causing a read set lock problem on the new transaction plan, so that the transaction data of the new transaction plan can be correctly stored in the blockchain ledger.

[0068] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] The accompanying drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the following specific embodiments, they are used to explain the present disclosure but do not constitute a limitation of the present disclosure. In the accompanying drawings:

[0070] Figure 1 The figure is a flowchart of a method for generating a read-write set according to an exemplary embodiment of the present disclosure.

[0071] Figure 2It is a block diagram of a read-write set generation device according to an exemplary embodiment of the present disclosure.

[0072] Figure 3 It is a block diagram of an electronic device according to an exemplary embodiment of the present disclosure.

[0073] Figure 4 is a block diagram of another electronic device according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0074] The specific implementation of the present disclosure is described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation described herein is only used to illustrate and explain the present disclosure, and is not used to limit the present disclosure.

[0075] It should be noted that all actions of acquiring signals, information or data in the present disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the device is located and with the authorization given by the owner of the corresponding device.

[0076] In order to make it easier for ordinary technicians in the field to understand the technical solution of the present disclosure, the application scenario of the present disclosure is first described below.

[0077] The technical solution disclosed in the present invention is applied to a blockchain solution based on read-write set transactions. For example, it can be applied to the transaction processing process of Hyperledger, and specifically can be applied to the endorsement node of the blockchain ledger based on read-write set transactions.

[0078] For example, the transaction process of Hyperledger Fabric is as follows:

[0079] The application first builds a transaction plan, which is used to call the chain code in the channel to read or write data in the ledger. The application uses Fabric's SDK to package the transaction plan and signs the plan with the user's private key. After the application packages the transaction plan, it submits the plan to the endorsement node in the channel. The endorsement policy of the channel defines which nodes must endorse the transaction for it to be valid. The application selects the corresponding endorsement nodes according to the endorsement policy and submits the transaction plan to them.

[0080] Next, after receiving the transaction plan, the endorsement node first verifies whether the signature of the transaction is legal, and then confirms whether the signer has the authority to conduct the relevant transaction based on his / her identity. In addition, the endorsement node also needs to check whether the format of the transaction plan is correct and whether it has been submitted before (to prevent replay attacks). After all the legitimacy checks are passed, the endorsement node calls the chain code according to the transaction plan. When the chain code is executed, the data read (key-value pair) is the local state database in the node. It should be pointed out that the chain code is simulated in the endorsement node, that is, the write operation to the database will not change the ledger, and all write operations will be summarized and recorded in a write set (Write Set). After the chain code is executed, the data set (Read Set) read by the chain code and the data set (Write Set) written by the chain code will be returned. The read set and write set (i.e., read-write set) will be used in the confirmation node to determine whether the transaction is finally written to the ledger. The endorsement node signs the read-write set (Read-Write Set) and other information obtained after the chain code is simulated and sent back to the plan submitter (i.e., the application end). Among them, the read-write set is defined as a read-write set (Read-Write Set) generated during the process of the endorser node (Endorser) simulating the execution of the transaction. The read set (ReadSet) contains a list of unique keys and the submitted key values ​​read by the transaction during the simulation execution. The write set (WriteSet) also contains a list of unique keys and the key values ​​written by the transaction during the simulation execution. That is, the read set will contain the version of the key, and the write set will only contain the latest value of the key. It can be understood that the read-write set is an access and modification record of the current blockchain world state. The blockchain world state is a key-value data set, and each key has a version record. After the value corresponding to the key is modified, the version of the key will change. The read-write set is a set containing all affected (read and write) keys.

[0081] After receiving the endorsement response, the application checks the signature of the endorsement node and compares the endorsement results of different nodes to see if they are consistent. If the plan is a request to query the ledger, the application does not need to submit the transaction to the sorting node. If it is a request to update the ledger, after collecting the number of endorsement responses that meet the endorsement policy, the application sends the read-write set obtained in the endorsement plan, the signatures of all endorsement nodes, and the channel number to the sorting node.

[0082] After receiving transactions from various nodes, the sorting node does not check the entire content of the transaction, but sorts the transactions according to the channel number in the transaction, and then packages the transactions in the same channel into data blocks. The sorting node broadcasts the packaged data blocks to all members in the channel.

[0083] After the confirmation node receives the transaction data block sent by the sorting node, it checks the transactions in the block one by one. First, check the legitimacy of the transaction and whether the transaction has ever appeared. Then call the system chain code of VSCC (Validation System Chaincode) to verify whether the endorsement signature of the transaction is legal and whether the number of endorsements meets the requirements of the endorsement policy. Next, check the multi-version concurrency control MVCC, that is, check whether the read set of the transaction is consistent with the version in the current ledger (that is, there is no change). If there is no change, it means that the modification of the data in the transaction write set is valid, and the transaction is marked as valid, and the write set of the transaction is updated to the state database. If the data in the current ledger is inconsistent with the read set version, the transaction is marked as invalid and the state database is not updated. The transaction data in the data block is encapsulated into a block after being marked as "valid" or "invalid" and written into the blockchain of the ledger.

[0084] In the above transaction process, MVCC has some limitations. For example, there is a read set lock problem: if two transactions in the same block update a data item one after another, the transaction in the later order will fail because its read set version is inconsistent with the current data item version (because the previous transaction updated the data), and there is a read set lock problem.

[0085] The following example illustrates the read set lock problem: Assume a transaction a, which reads the value of key1 (assuming that the current version of key1 in the state database is v1), and then modifies the value of key2 (assuming that the current version of key2 in the state database is v2), and the new value after modifying key2 is value 2` Then, the read set of transaction a after simulated execution on the endorsement node is: key1[v1] (the current version of key1 is in brackets), and the write set is: key2[value 2` ](The value in brackets is the new value of key2 2` ).

[0086] Next, let's assume another transaction b, which reads key2 and modifies key3 (assuming that the current version of key3 in the state database is v3 and the new value after modification is value 3` Then, the read set of transaction b after simulated execution on the endorsement node is: key2[v2] (the current version of key2 in brackets is v2. The reason is that since transaction a has not been submitted, that is, the world state database has not been updated according to the write set of transaction a, the version of key2 in the state database of the endorsement node is still v2), and the write set is: key3[value 3` ](The value in brackets is the new value of key3 3` ).

[0087] When transactions A and B are included in the block by the confirmation node consensus, assuming that transaction A is ranked before transaction B. Then when transaction A is submitted, the key2 version in the state database of the endorsing node will be changed from v2 to v 2` When transaction b is submitted, its read set key2[v2] records the key2 version as v2, which is different from the key2 version v in the current world state. 2` Inconsistent (ie v2!=v 2` ), so transaction b will be marked as an invalid transaction, and the world state database will not be updated according to the write set of transaction b. It can be seen that transaction a caused a read set lock problem on transaction b, resulting in the inability to correctly upload the transaction data of transaction b to the chain.

[0088] In other words, the current transaction method of Hyperledger Fabric based on read-write set transactions has a read-set lock problem, which affects the transaction data on the chain.

[0089] In order to solve the problem of read set lock, the embodiments of the present disclosure provide a method, device, storage medium and electronic device for generating a read-write set. The following is a detailed example of the embodiments of the present disclosure.

[0090] Figure 1 is a flowchart of a method for generating a read-write set according to an exemplary embodiment of the present disclosure. Figure 1 As shown, the read-write set generation method is applied to the endorsement node, and the read-write set generation method may include the following steps:

[0091] S11. Receive the transaction plan sent by the application.

[0092] The transaction plan can also be called a transaction proposal. The transaction plan can be constructed by the application and sent to the endorsing node.

[0093] S12. Simulate and execute the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set. The target read set is used to determine whether the target write set is valid, and is used to update the world state database when the target write set is valid.

[0094] S13. Cache write-set pre-execution data according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write-set.

[0095] In one implementation, the transaction plan may refer to the first transaction plan. When the transaction plan is the first transaction plan, the implementation method of simulating the execution of the transaction plan to obtain the target read-write set of the transaction plan may be consistent with the method in the related art (i.e., the aforementioned method of determining the read-write set based on the state database of the endorsement node).

[0096] In another implementation, the transaction plan may not be the first transaction plan. If there is a historical transaction plan before the transaction plan, the implementation method of simulating the execution of the transaction plan to obtain the target read-write set of the transaction plan may be to generate the target read-write set corresponding to the transaction plan according to the historical write set pre-execution data determined by the historical transaction plan.

[0097] Furthermore, after generating a target read-write set for each transaction plan, write set pre-execution data can be cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set of the transaction plan.

[0098] Wherein, caching the write-set pre-execution data according to the target read-write set may refer to caching the write-set pre-execution data according to the target write-set in the target read-write set. For example, the implementation method of caching the write-set pre-execution data according to the target write-set in the target read-write set may be to cache the unique key key, the modified value, and the version of the modified value in the target write-set.

[0099] From the example of the read-set lock problem mentioned above, it can be found that the read-write set obtained in the endorsement phase cannot be verified in the submission (entry into the chain) phase. The root cause is that the version of the key read by the transaction during the pre-execution of the endorsement phase has been modified by another exchange when it is submitted. In order to ensure the final consistency of the data, if the read-set version is different when endorsing and submitting, the transaction can only be marked as invalid and refused to be written into the blockchain. This method is similar to the optimistic lock of database operations. If the write verification fails, it will be rolled back. The optimistic lock method is suitable for environments with little data contention and fewer conflicts. However, as a basic system, blockchain provides smart contract functions for various businesses. The unified use of this optimistic lock method is obviously not suitable for some business scenarios with large data conflicts. The inventor found that the idea of ​​optimizing optimistic locks is to reduce the possibility of conflicts. Specifically, for a blockchain system based on the read-write set method, if it can be achieved that the conflicting keys can be perceived between transactions when endorsing in certain scenarios, so that the read set version can be the same as the version when the transaction is submitted during the pre-execution of the endorsement, the read set lock problem can be avoided. Therefore, it is proposed in the present disclosure to cache the write set pre-execution data of historical transaction plans so that when a new transaction plan is received, it is easy to perceive whether there is a historical transaction plan that causes the new transaction plan to generate a read set lock problem, and generate the target read-write set of the new transaction plan based on the historical transaction plan that causes the new transaction plan to generate a read set lock problem, thereby avoiding the read set lock problem.

[0100] For example, taking the above transaction a and transaction b as examples, assume that transaction a reads the value of key1 (assuming that the current version of key1 in the state database is v1), and then modifies the value of key2 (assuming that the current version of key2 in the state database is v2), and the new value after modifying key2 is value 2` If there is no historical transaction before transaction a, then the read set of transaction a after simulated execution on the endorsement node is key1[v1], and the write set is key2[value 2` ]. Further, based on the read-write set of transaction a, generate and cache the write set pre-execution data key2 of transaction a, v 2` ,value 2` Among them, v 2` Characterize according to the write set key2[value 2` ] The version corresponding to key2 after updating the state database (according to the write set key2[value 2` ]After updating the status database, the version corresponding to key2 changes from v2 to v 2` ), where the write set key2[value 2` The steps to update the state database are hypothetical and not real execution.

[0101] Furthermore, suppose that another transaction B after transaction A reads key2 and modifies key3 (assuming that the current version of key3 in the state database is v3 and the modified new value is value 3` ). Then for transaction b, pre-execute data key2 according to the write set of transaction a, v 2` ,value 2` The generated read set can be key2[v 2` ](The v in the brackets 2` It is based on the write set pre-execution data key2, v 2` ,value 2` Generated), the write set is: key3[value 3` ](The value in brackets is the new value of key3 3` ). Further, based on the read-write set of transaction b, generate and cache the write set pre-execution data key3 of transaction b, v 3` ,value 3` Among them, v 3` Characterize according to the write set key3[value 3` ] The version corresponding to key3 after updating the state database (according to the write set key3[value 3` ]After updating the state database, the version of key3 v3 becomes v 3` ).

[0102] When transactions A and B are included in the block by the confirmation node consensus, assuming that transaction A is ranked before transaction B. Then when transaction A is submitted, the key2 version in the endorsing node blockchain world state will be changed from v2 to v 2` When transaction b is submitted, its read set key2[v 2` ] records that the key2 version is v 2` , and the version v of key2 in the current world state 2` Consistent (ie v 2` =v 2` ), so transaction b will be marked as a valid transaction, and the world state database will be updated according to the write set of transaction b. It can be seen that the use of this method disclosed in the present invention can solve the read set lock problem caused by transaction a on transaction b in the related technology, so that the transaction data of transaction b can be correctly uploaded to the chain.

[0103] In this way, the transaction plan sent by the application is received, and the transaction plan is simulated and executed to obtain the target read-write set of the transaction plan. The write set pre-execution data is cached according to the target read-write set to generate a new target read-write set for the new transaction plan before the world state database is updated according to the target write set in the target read-write set. In this way, before the transaction data of the transaction plan is uploaded to the chain (that is, before the world state database is updated according to the target write set in the target read-write set of the transaction plan), the transaction plan can be prevented from causing a read set lock problem on the new transaction plan, so that the transaction data of the new transaction plan can be correctly stored in the blockchain ledger.

[0104] Optionally, the target read set includes a unique key and a corresponding version, and the simulation executes the transaction plan to obtain the target read-write set of the transaction plan, including:

[0105] In the process of simulating the execution of the transaction plan, the unique key is determined; when it is determined that the cache has historical write set pre-execution data including the unique key, the version of the unique key is determined according to the historical version in the historical write set pre-execution data to obtain the target read set.

[0106] Correspondingly, the target write set includes the unique key and the corresponding modification value, and the simulated execution of the transaction plan to obtain the target read-write set of the transaction plan also includes: when it is determined that there is historical write set pre-execution data including the unique key in the cache, determining the modification value according to the historical modification value in the historical write set pre-execution data to obtain the target write set.

[0107] Among them, the unique key refers to the unique key of the data item.

[0108] In order to more simply explain the technical solution of the present disclosure, the following example is taken as an example that the unique key read and modified by the transaction is the same. For example, suppose transaction c reads the value of key2, then modifies the value of key2, and the new value after modifying key2 is value 2` . Then, during the simulated execution of the transaction plan of transaction c on the endorsement node, the unique key can be determined to be key2. Then determine whether there is any historical write set pre-execution data cached that includes the unique key key2. If not, determine the version of the unique key key2 as v2 from the local state database of the endorsement node (assuming that the current version of key2 in the local state database is v2, that is, the world state of key2 is key2, v2, value2). The corresponding read set is key2[v2], and the write set is key2[value 2` ], where value 2`It is calculated based on the value value2 corresponding to the read set key2[v2] through the business logic of the transaction plan. If consensus is uploaded to the chain based on the read set key2[v2], since the version of key2 in the read set key2[v2] is v2, which is consistent with the world state of key2 key2, v2, value2, the write set key2[value 2` ] is marked as valid, and the transaction data of transaction c can be correctly uploaded to the chain. If the world state database is based on the write set key2[value 2` ] to update, the updated world state is key2, v 2` ,value 2` .

[0109] Furthermore, suppose there is a transaction d after transaction c, and transaction d reads the value of key2 and then modifies the value of key2, and the new value after modifying key2 is value 2`` . Then, during the simulated execution of the transaction plan of transaction d, the unique key can be determined to be key2. Then, it is determined whether the historical write set pre-execution data including the unique key key2 is cached. At this time, since the historical write set pre-execution data corresponding to transaction c is key2, v 2` (v 2` Represents the write set key2[value 2` ]The version corresponding to key2 after updating the status database), value 2` Therefore, according to the historical write set, the data key2, v 2` ,value 2` Historical versions in v 2` It can be determined that the version of the unique key key2 is v 2` The corresponding read set is key2[v 2` ], write set is key2[value 2`` ], where value 2`` According to the read set key2[v 2` ] is calculated by the business logic of the transaction plan. 2` ] to reach consensus on the chain, then due to the read set key2[v 2` ]The version of key2 is v 2` , v 2` The world state of key2 after consensus on transaction c is key2, v 2` ,value 2` So write the set key2[value 2``] is marked as valid, and the transaction data of transaction d is correctly uploaded to the chain. If the world state database is based on the write set key2[value 2`` ] to update, the updated world state is key2, v 2`` ,value 2`` .

[0110] It should be noted that in the read set lock problem, if the read set is wrong, it will lead to a write set error accordingly, because the modified value in the write set is calculated based on the value read by the read set through business logic.

[0111] Optionally, the simulating execution of the transaction plan to obtain a target read-write set of the transaction plan includes:

[0112] The transaction plan is simulated for execution to determine an initial read-write set based on a local state database, wherein the initial read-write set includes an initial read set, and the initial read set includes a unique key and a corresponding initial version; when it is determined that the cache has historical write set pre-execution data including the unique key, the initial version in the initial read set is corrected according to the historical version in the historical write set pre-execution data to obtain the target read set.

[0113] Optionally, the initial read-write set also includes an initial write set, which includes the unique key and the corresponding initial modification value; the method also includes: when it is determined that the cache has historical write set pre-execution data including the unique key, correcting the initial modification value in the initial write set according to the historical modification value in the historical write set pre-execution data to obtain the target write set.

[0114] For example, suppose transaction c reads the value of key2 and then modifies the value of key2. The new value after modifying key2 is value 2` , and assuming that the world state of key2 in the local state database is key2, v2, value2. Then the transaction plan of transaction c is simulated and executed on the endorsement node, and the initial read-write set of transaction c can be determined based on the local state database as key2[v2], key2[value 2` ]. Next, determine whether there is any historical write set pre-execution data cached that includes the unique key key2. If not, determine the initial read-write set as the target read-write set. If consensus is uploaded to the chain based on the read set key2[v2], then since the version of key2 in the read set key2[v2] is v2, which is consistent with the world state of key2 key2, v2, value2, the write set key2[value 2` ] is marked as valid, and the transaction data of transaction c can be correctly uploaded to the chain. 2`] to update, the updated world state can be obtained as key2, v 2` ,value 2` .

[0115] Furthermore, before transaction c is uploaded to the consensus chain, assume that transaction d reads the value of key2 and then modifies the value of key2 by adding 1, and assume that the world state of key2 in the local state database is key2, v2, value2. Then the transaction plan of transaction d is simulated and executed on the endorsement node, and the initial read-write set can be determined as key2[v2], key2[value2+1] based on the local state database. Next, determine whether there is any historical write set pre-execution data cached that includes the unique key key2. Since there is historical write set pre-execution data key2, v2 cached according to the target read-write set of transaction c, 2` ,value 2` , so the historical version v in the pre-execution data can be based on the historical write set 2` Modify the initial version v2 in the initial read set key2[v2] to obtain the target read set key2[v 2` ] and modify the historical value value in the historical write set pre-execution data 2` Correct the initial modification value value2+1 in the initial write set to obtain the target write set key2[value 2` +1]. If transaction d is submitted after transaction c is submitted, then according to the target read set key2[v 2` ] consensus on the chain, because the target read set key2[v 2` ]The version of key2 is v 2` , v 2` The world state of key2 after consensus with transaction c is on the chain, key2, v 2` ,value 2` Therefore, the target write set of transaction d is key2[value 2` +1] is marked as valid, and the transaction data of transaction d can be correctly uploaded to the chain. 2` +1], the updated world state can be obtained as key2, v 2`` ,value 2` +1.

[0116] If the historical modification value in the data is not pre-executed according to the historical write set 2` Correct the initial modification value value2+1 in the initial write set, then update the world state database to key2 according to the initial write set key2[value2+1], v 2``, value2+1. Among them, value2+1 is obviously wrong.

[0117] Optionally, the method further includes: after correcting the initial version in the initial read set according to the historical version in the historical write set pre-execution data to obtain the target read set, the correct target write set may be determined according to the corrected target read set. For example, a correct correction value is calculated according to the data corresponding to the corrected target read set to obtain the target write set.

[0118] Optionally, when it is determined that the cache has historical write set pre-execution data including the unique key, determining the version of the unique key according to a historical version in the historical write set pre-execution data to obtain the target read set includes:

[0119] If a plurality of the historical write set pre-execution data including the unique key are cached, the version of the unique key is determined from the most recently cached historical write set pre-execution data to obtain the target read set.

[0120] For example, if the cache has two historical write set pre-execution data A and B including the unique key key1, and the cache time of the historical write set pre-execution data A is earlier than the cache time of the historical write set pre-execution data B, then the historical write set pre-execution data B is the most recently cached historical write set pre-execution data, and the version of the unique key key1 can be determined from the historical write set pre-execution data B to obtain the target read set.

[0121] Similarly, if there are multiple historical write set pre-execution data including the unique key in the cache, the modification value is determined according to the historical modification value in the most recently cached historical write set pre-execution data to obtain the target write set.

[0122] Similarly, if multiple historical write set pre-execution data including the unique key are cached, the initial version in the initial read set is corrected according to the historical version in the historical write set pre-execution data cached most recently to obtain the target read set.

[0123] Similarly, if multiple historical write set pre-execution data including the unique key are cached, the initial modification value in the initial write set is corrected according to the historical modification value in the most recently cached historical write set pre-execution data to obtain the target write set.

[0124] Optionally, the receiving a transaction plan sent by the application terminal includes: receiving a plurality of the transaction plans sent by the application terminal;

[0125] Correspondingly, the step of simulating the execution of the transaction plan to obtain the target read-write set of the transaction plan, and caching the write-set pre-execution data according to the target read-write set includes: executing the simulated execution of the transaction plan for each of the multiple transaction plans in turn to obtain the target read-write set of the transaction plan, and caching the write-set pre-execution data according to the target read-write set.

[0126] In a transaction concurrency scenario, multiple transaction plans sent by the application are received, and each transaction plan is simulated and executed in turn to obtain the target read-write set of the transaction plan, and the write set pre-execution data is cached according to the target read-write set. In this way, the read set lock problem between multiple transaction plans in a concurrent scenario can be solved.

[0127] Optionally, the receiving of multiple transaction plans sent by the application terminal includes:

[0128] Receive multiple transaction plans sent by the same application end, or receive transaction plans sent by multiple application ends respectively.

[0129] If the same application sends multiple concurrent transaction plans, the application can mark the multiple concurrent transaction plans to prompt the endorsement node that there may be a read set lock problem between the multiple concurrent transaction plans if it determines that the multiple concurrent transaction plans have a reference relationship. The application can determine whether the multiple concurrent transaction plans have a reference relationship through the user's front-end operation. The reference relationship between multiple transaction plans means that each transaction plan performs a read and / or write operation on the same data item.

[0130] Then, the step of sorting the plurality of transaction plans to obtain a transaction plan sequence may include:

[0131] Determine target transaction plans with a reference relationship between transaction plans; bundle the target transaction plans into an overall plan; sort the overall plan and other transaction plans except the target transaction plan to obtain the transaction plan sequence.

[0132] For example, suppose there are transactions a, b, c, and d, where a and c have a reference relationship identifier. Then, the endorsement node bundles transactions a and c into an overall plan A (a, c), and then sorts A, b, and d.

[0133] The above sorting method is consistent with the sorting method in the sorting node.

[0134] For example, suppose the current world state of book A in the blockchain is: [A, V(Tx0), 10], which means that A is the key of book A, there are 10 copies of book A, and the current version of A is V(Tx0). Now users A and B have borrowed book A successively, and the librarian now needs to record these two borrowing information to the blockchain.

[0135] Then, the librarian continuously (within a certain time window) sends transactions Tx1 (corresponding to A) and Tx2 (corresponding to B) to the endorsement node. Assume that the timestamp of Tx1 is earlier than the timestamp of Tx2, and the Tx1 and Tx2 tags have a reference relationship (for example, the tag references Tx1 in the transaction plan of Tx2, and / or, the tag is referenced by Tx2 in the transaction plan of Tx1). If the endorsement node receives the transaction plan of Tx1 and can determine that Tx1 is referenced by Tx2 based on the tag, then it can wait for the transaction plan of Tx2, and after receiving the transaction plan of Tx2, endorse Tx1 and Tx2 in turn. It can also take the initiative to obtain the transaction plan of Tx2, and after obtaining the transaction plan of Tx2, endorse Tx1 and Tx2 in turn. It can also endorse Tx1 first without receiving Tx2. Then wait for the transaction plan of Tx2, and endorse Tx2 when receiving Tx2.

[0136] After receiving Tx1 and Tx2, the endorsing node verifies the legitimacy of the two transactions. The endorsing node determines that Tx1 is referenced by Tx2 based on the identifier, sorts Tx1 and Tx2, and first simulates the execution of Tx1's transaction plan to obtain Tx1's read set.<A,V(Tx0)> (The version of book A in the current world state is V(Tx0)); write set<A,9> (After borrowing a book to user A, the number of books A changes from 10 to 9); the endorsement node caches the record of the write set pre-execution data [A, V(Tx1), 9] in the local cache, which is used to indicate that if Tx1 is finally submitted (consensus on the chain), the version of book A in the world state should be V(Tx1), and the value should be 9. Accordingly, the simulated execution of Tx2 results in the read set:<A,V(Tx1)> (The version of book A in the current world state is V(Tx0), and the version after Tx1 execution in the cached write set pre-execution data is V(Tx1)). The write set is<A,8> (After lending a book to user B, the quantity of book A changes from 9 to 8). In the above example, the way in which the endorsing node endorses Tx1 and Tx2 can be called a reference strategy. When sorting, bundling transactions Tx1 and Tx2 with reference relationships together is conducive to the processing of the ledger data of transactions Tx1 and Tx2 in subsequent applications. For example, after user A borrows a book, the inventory of book A is 9, and after user B borrows a book, the inventory of book A is 8. There will not be a situation where both A and B borrow books at the same time, and after A borrows a book, the inventory of book A is 9, and after user B borrows a book, the inventory of book A is 6.

[0137] As another example, assume that the world state of the total number of users T in the current blockchain is: [T, V(Tx0), 10], which means that T is used as the key for the total number of users, the total number of users is now 10, and the current version of T is V(Tx0). Now users C and D register as new users at the same time, and the information of users C and D needs to be recorded in the blockchain.

[0138] User C's registration transaction Tx1 and user D's registration transaction Tx2 are sent to the endorsement node at the same time. Assume that the timestamp of Tx1 is less than the timestamp of Tx2. After receiving Tx1 and Tx2, the endorsement node verifies the legitimacy of the two transactions. Then, by sorting Tx1 and Tx2, pre-execute Tx1 first, and obtain the read set of Tx1<T,V(Tx0)> (The total number of users T in the current world state is V(Tx0)); write set<T,11> (After user C registered, the total number of users T changed from 10 to 11); at the same time, the endorsement node inserts the record of the write set pre-execution data [T, V (Tx1), 11] into the local write set cache to indicate that after Tx1 is executed, if Tx1 is finally submitted, the version of the total number of users T in the world state should be V (Tx1), and the value should be 11. The endorsement node continues to simulate the execution of Tx2 and obtains the read set of Tx2<T,V(Tx1)> (The version of book A in the current world state is V(Tx0), and the version in the cached write set pre-execution data is V(Tx1)), the write set is<A,12> (After user D registered, the total number of users changed from 11 to 12.) In the above example, the way in which the endorsing node endorses Tx1 and Tx2 can be called the latest strategy.

[0139] Optionally, the method further includes: after updating the world state database according to the target write set, deleting the write set pre-execution data cached according to the target read-write set.

[0140] After the world state database is updated according to the target write set, the world state represented by the write set pre-execution data is consistent with the local state database of the endorsing node (because the world state database is updated). Therefore, after the world state database is updated according to the target write set, the write set pre-execution data cached according to the target read-write set can be deleted to avoid memory expansion of the endorsing node.

[0141] Figure 2 is a block diagram of a read-write set generation device according to an exemplary embodiment of the present disclosure. Figure 2 As shown, the device 200 includes:

[0142] The receiving module 210 is used to receive the transaction plan sent by the application end;

[0143] An execution module 220 is used to simulate the execution of the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update the world state database when the target write set is valid; and write set pre-execution data is cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set.

[0144] The above-mentioned device is used to receive the transaction plan sent by the application end, and simulate the execution of the transaction plan to obtain the target read-write set of the transaction plan. The write set pre-execution data is cached according to the target read-write set to generate a new target read-write set for the new transaction plan before the world state database is updated according to the target write set in the target read-write set. In this way, before the transaction data of the transaction plan is uploaded to the chain (that is, the data is stored in the blockchain) (that is, before the world state database is updated according to the target write set in the target read-write set of the transaction plan), the transaction plan can be prevented from causing a read set lock problem on the new transaction plan, so that the transaction data of the new transaction plan can be correctly stored in the blockchain ledger.

[0145] Optionally, the target read set includes a unique key and a corresponding version, and the execution module 220 includes:

[0146] A first determination submodule, used to determine the unique key during the process of simulating the execution of the transaction plan;

[0147] The second determination submodule is used to determine the version of the unique key according to the historical version in the historical write set pre-execution data to obtain the target read set when it is determined that the cache has historical write set pre-execution data including the unique key.

[0148] Optionally, the target write set includes the unique key and the corresponding modified value, and the execution module 220 further includes:

[0149] The third determination submodule is used to determine the modification value according to the historical modification value in the historical write set pre-execution data to obtain the target write set when it is determined that the cache has the historical write set pre-execution data including the unique key.

[0150] Optionally, the execution module 220 includes:

[0151] A generating submodule, for simulating the execution of the transaction plan, to determine an initial read-write set based on a local state database, wherein the initial read-write set includes an initial read set, and the initial read set includes a unique key and a corresponding initial version;

[0152] The first correction module is used to correct the initial version in the initial read set according to the historical version in the historical write set pre-execution data to obtain the target read set when it is determined that the cache has historical write set pre-execution data including the unique key.

[0153] Optionally, the initial read-write set further includes an initial write set, and the initial write set includes the unique key and the corresponding initial modification value;

[0154] The execution module 220 further includes:

[0155] The second correction module is used to correct the initial modification value in the initial write set according to the historical modification value in the historical write set pre-execution data to obtain the target write set when it is determined that the cache has historical write set pre-execution data including the unique key.

[0156] Optionally, the second determining submodule includes:

[0157] The first execution submodule is used to determine the version of the unique key from the most recently cached historical write set pre-execution data to obtain the target read set if multiple historical write set pre-execution data including the unique key are cached.

[0158] Optionally, the receiving module is further used to receive a plurality of the transaction plans sent by the application end;

[0159] Correspondingly, the execution module is also used to execute the simulated execution of the transaction plan for each of the multiple transaction plans in turn, obtain the target read-write set of the transaction plan, and cache the write set pre-execution data according to the target read-write set.

[0160] Optionally, the execution module 220 includes:

[0161] A sorting submodule, used for sorting the plurality of transaction plans to obtain a transaction plan sequence;

[0162] The second execution submodule is used to execute the simulated execution of the transaction plan for each transaction plan in turn according to the transaction plan sequence, obtain the target read-write set of the transaction plan, and cache the write set pre-execution data according to the target read-write set.

[0163] Optionally, the sorting submodule includes:

[0164] A fourth determination submodule is used to determine a target transaction plan having a reference relationship between the transaction plans;

[0165] A bundling submodule, used to bundle the target transaction plans into an overall plan;

[0166] The third execution submodule is used to sort the overall plan and other transaction plans except the target transaction plan to obtain the transaction plan sequence.

[0167] Optionally, the device 200 further includes:

[0168] A deletion module is used to delete the write-set pre-execution data cached according to the target read-write set after updating the world state database according to the target write-set.

[0169] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0170] Figure 3 FIG. 7 is a block diagram of an electronic device 700 according to an exemplary embodiment. Figure 3 As shown, the electronic device 700 may include: a processor 701 and a memory 702. The electronic device 700 may also include one or more of a multimedia component 703, an input / output (I / O) interface 704, and a communication component 705.

[0171] The processor 701 is used to control the overall operation of the electronic device 700 to complete all or part of the steps in the above-mentioned read-write set generation method. The memory 702 is used to store various types of data to support the operation of the electronic device 700, and these data may include, for example, instructions for any application or method used to operate on the electronic device 700, and application-related data, such as contact data, sent and received messages, pictures, audio, video, etc. The memory 702 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (Static Random Access Memory, referred to as SRAM), electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, referred to as EEPROM), erasable programmable read-only memory (Erasable Programmable Read-Only Memory, referred to as EPROM), programmable read-only memory (Programmable Read-Only Memory, referred to as PROM), read-only memory (Read-Only Memory, referred to as ROM), magnetic memory, flash memory, magnetic disk or optical disk. The multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signal may be further stored in the memory 702 or sent through the communication component 705. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 704 provides an interface between the processor 701 and other interface modules, and the other interface modules may be keyboards, mice, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, etc., or a combination of one or more of them, is not limited here. Therefore, the corresponding communication component 705 may include: Wi-Fi module, Bluetooth module, NFC module, etc.

[0172] In an exemplary embodiment, the electronic device 700 can be implemented by one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), controllers, microcontrollers, microprocessors or other electronic components to execute the above-mentioned read-write set generation method.

[0173] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned read-write set generation method are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 702 including program instructions, and the above-mentioned program instructions can be executed by the processor 701 of the electronic device 700 to complete the above-mentioned read-write set generation method.

[0174] Figure 4 1 is a block diagram of an electronic device 1900 according to an exemplary embodiment. For example, the electronic device 1900 may be provided as a server. Figure 4 The electronic device 1900 includes a processor 1922, which may be one or more, and a memory 1932 for storing a computer program executable by the processor 1922. The computer program stored in the memory 1932 may include one or more modules each corresponding to a set of instructions. In addition, the processor 1922 may be configured to execute the computer program to perform the above-mentioned read-write set generation method.

[0175] In addition, the electronic device 1900 may further include a power supply component 1926 and a communication component 1950. The power supply component 1926 may be configured to perform power management of the electronic device 1900, and the communication component 1950 may be configured to implement communication of the electronic device 1900, for example, wired or wireless communication. In addition, the electronic device 1900 may further include an input / output (I / O) interface 1958. The electronic device 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server 2003. TM , Mac OS X TM , Unix TM , Linux TM etc.

[0176] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned read-write set generation method are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 1932 including program instructions, and the above-mentioned program instructions can be executed by the processor 1922 of the electronic device 1900 to complete the above-mentioned read-write set generation method.

[0177] In another exemplary embodiment, a computer program product is further provided. The computer program product includes a computer program executable by a programmable device. The computer program has a code portion for executing the above-mentioned read-write set generation method when executed by the programmable device.

[0178] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings; however, the present disclosure is not limited to the specific details in the above embodiments. Within the technical concept of the present disclosure, a variety of simple modifications can be made to the technical solution of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0179] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0180] In addition, various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

[0181] Example

[0182] 1. A method for generating a read-write set, the method comprising:

[0183] Receive the transaction plan sent by the application;

[0184] Simulate and execute the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update a world state database if the target write set is valid; and

[0185] Write-set pre-execution data is cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write-set.

[0186] 2. According to the method of embodiment 1, the target read set includes a unique key and a corresponding version, and the simulation executes the transaction plan to obtain the target read-write set of the transaction plan, including:

[0187] In the process of simulating the execution of the transaction plan, determining the unique key;

[0188] When it is determined that the cache has historical write set pre-execution data including the unique key, the version of the unique key is determined according to the historical version in the historical write set pre-execution data to obtain the target read set.

[0189] 3. According to the method of embodiment 2, the target write set includes the unique key and the corresponding modified value, and the simulation executes the transaction plan to obtain the target read-write set of the transaction plan, further comprising:

[0190] When it is determined that the cache has historical write-set pre-execution data including the unique key, the modification value is determined according to the historical modification value in the historical write-set pre-execution data to obtain the target write-set.

[0191] 4. According to the method of embodiment 1, the simulating execution of the transaction plan to obtain the target read-write set of the transaction plan includes:

[0192] Simulate and execute the transaction plan to determine an initial read-write set based on a local state database, wherein the initial read-write set includes an initial read set, and the initial read set includes a unique key and a corresponding initial version;

[0193] When it is determined that the cache has historical write set pre-execution data including the unique key, the initial version in the initial read set is corrected according to the historical version in the historical write set pre-execution data to obtain the target read set.

[0194] 5. The method according to embodiment 4, wherein the initial read-write set further includes an initial write set, and the initial write set includes the unique key and the corresponding initial modified value;

[0195] The method further comprises:

[0196] When it is determined that the cache has historical write set pre-execution data including the unique key, the initial modification value in the initial write set is modified according to the historical modification value in the historical write set pre-execution data to obtain the target write set.

[0197] 6. The method according to embodiment 2, wherein when it is determined that the cache has historical write set pre-execution data including the unique key, determining the version of the unique key according to the historical version in the historical write set pre-execution data to obtain the target read set includes:

[0198] If a plurality of the historical write set pre-execution data including the unique key are cached, the version of the unique key is determined from the most recently cached historical write set pre-execution data to obtain the target read set.

[0199] 7. According to any one of the methods of embodiments 1-6, the step of receiving a transaction plan sent by the application terminal includes:

[0200] Receiving a plurality of transaction plans sent by the application end;

[0201] The simulating and executing the transaction plan to obtain a target read-write set of the transaction plan, and caching write-set pre-execution data according to the target read-write set, includes:

[0202] The step of executing the simulated execution of the transaction plan for each of the multiple transaction plans in turn to obtain a target read-write set of the transaction plan, and caching write set pre-execution data according to the target read-write set.

[0203] 8. According to the method of embodiment 7, the step of executing the simulated execution of the transaction plan for each of the multiple transaction plans in turn to obtain a target read-write set of the transaction plan, and caching write set pre-execution data according to the target read-write set includes:

[0204] Sorting the plurality of transaction plans to obtain a transaction plan sequence;

[0205] According to the transaction plan sequence, for each transaction plan in turn, the step of simulating the execution of the transaction plan to obtain a target read-write set of the transaction plan, and caching the write set pre-execution data according to the target read-write set.

[0206] 9. According to the method of embodiment 8, the step of sorting the plurality of transaction plans to obtain a transaction plan sequence comprises:

[0207] Determine target transaction plans that have a reference relationship between transaction plans;

[0208] Bundle the target transaction plans into an overall plan;

[0209] The overall plan and other transaction plans except the target transaction plan are sorted to obtain the transaction plan sequence.

[0210] 10. The method according to embodiment 1, further comprising:

[0211] After updating the world state database according to the target write set, deleting the write set pre-execution data cached according to the target read-write set.

[0212] 11. A read-write set generation device, the device comprising:

[0213] The receiving module is used to receive the transaction plan sent by the application end;

[0214] An execution module is used to simulate the execution of the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update a world state database when the target write set is valid; and write set pre-execution data is cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set.

[0215] 12. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of embodiments 1-10.

[0216] 13. An electronic device, comprising:

[0217] a memory having a computer program stored thereon;

[0218] A processor is used to execute the computer program in the memory to implement the steps of the method in any one of embodiments 1-10.

Claims

1. A method for generating a read-write set, characterized in that: The method comprises: Receive the transaction plan sent by the application; Simulate and execute the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update the world state database if the target write set is valid; and Write set pre-execution data is cached according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set, and the unique key corresponding to the transaction plan is the same as the unique key corresponding to the new transaction plan.

2. The method according to claim 1, characterized in that The target read set includes a unique key and a corresponding version. The simulation executes the transaction plan to obtain a target read-write set of the transaction plan, including: In the process of simulating the execution of the transaction plan, determining the unique key; When it is determined that the cache has historical write set pre-execution data including the unique key, the version of the unique key is determined according to the historical version in the historical write set pre-execution data to obtain the target read set.

3. The method according to claim 2, characterized in that The target write set includes the unique key and the corresponding modified value, and the simulation executes the transaction plan to obtain the target read-write set of the transaction plan, and further includes: When it is determined that the cache has historical write-set pre-execution data including the unique key, the modification value is determined according to the historical modification value in the historical write-set pre-execution data to obtain the target write-set.

4. The method according to claim 1, characterized in that The simulation executes the transaction plan to obtain a target read-write set of the transaction plan, including: Simulate and execute the transaction plan to determine an initial read-write set based on a local state database, wherein the initial read-write set includes an initial read set, and the initial read set includes a unique key and a corresponding initial version; When it is determined that the cache has historical write set pre-execution data including the unique key, the initial version in the initial read set is corrected according to the historical version in the historical write set pre-execution data to obtain the target read set.

5. The method according to claim 4, characterized in that The initial read-write set also includes an initial write set, and the initial write set includes the unique key and the corresponding initial modification value; The method further comprises: When it is determined that the cache has historical write set pre-execution data including the unique key, the initial modification value in the initial write set is corrected according to the historical modification value in the historical write set pre-execution data to obtain the target write set.

6. The method according to claim 2, characterized in that In the case where it is determined that the cache has historical write set pre-execution data including the unique key, determining the version of the unique key according to the historical version in the historical write set pre-execution data to obtain the target read set includes: If a plurality of the historical write set pre-execution data including the unique key are cached, the version of the unique key is determined from the most recently cached historical write set pre-execution data to obtain the target read set.

7. The method according to any one of claims 1 to 6, characterized in that The receiving transaction plan sent by the application terminal includes: Receiving a plurality of transaction plans sent by the application end; The simulating and executing the transaction plan to obtain a target read-write set of the transaction plan, and caching write-set pre-execution data according to the target read-write set, includes: The step of executing the simulated execution of the transaction plan for each of the multiple transaction plans in turn to obtain a target read-write set of the transaction plan, and caching write set pre-execution data according to the target read-write set.

8. The method according to claim 7, characterized in that The step of executing the simulated execution of the transaction plan for each of the multiple transaction plans in turn to obtain a target read-write set of the transaction plan, and caching write set pre-execution data according to the target read-write set includes: Sorting the plurality of transaction plans to obtain a transaction plan sequence; According to the transaction plan sequence, for each transaction plan in turn, the step of simulating the execution of the transaction plan to obtain a target read-write set of the transaction plan, and caching the write set pre-execution data according to the target read-write set.

9. The method according to claim 8, characterized in that The step of sorting the plurality of transaction plans to obtain a transaction plan sequence includes: Determine target transaction plans that have a reference relationship between transaction plans; Bundle the target transaction plans into an overall plan; The overall plan and other transaction plans except the target transaction plan are sorted to obtain the transaction plan sequence.

10. The method according to claim 1, characterized in that The method further comprises: After updating the world state database according to the target write set, deleting the write set pre-execution data cached according to the target read-write set.

11. A read-write set generation device, characterized in that: The device comprises: The receiving module is used to receive the transaction plan sent by the application end; An execution module is used to simulate the execution of the transaction plan to obtain a target read-write set of the transaction plan, wherein the target read-write set includes a target read set and a target write set, wherein the target read set is used to determine whether the target write set is valid, and is used to update a world state database when the target write set is valid; and cache write set pre-execution data according to the target read-write set to generate a new target read-write set for a new transaction plan before updating the world state database according to the target write set, wherein the unique key corresponding to the transaction plan is the same as the unique key corresponding to the new transaction plan.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method described in any one of claims 1 to 10 are implemented.

13. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1 to 10.

Images