Transaction execution method and device

Abstract

Provided in the present application are a transaction execution method and device. The method comprises: for a target block to be executed and forward blocks that need to be executed before the target block, when there is at least one forward block that has not yet been executed, determining a first read set of the target block on the basis of each transaction in the target block, wherein the first read set comprises data identifiers of first target data required to execute each transaction in the target block; on the basis of the data identifiers, reading the first target data from persistently stored state data and caching same; and when all the forward blocks have been executed, executing each transaction in the target block on the basis of the cached first target data.

Description

Transaction execution method and device Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly, to a method and device for executing a transaction. Background Art

[0002] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing that the distributed ledger is tamper-proof and unforgeable. Users can participate in blockchain-related transactions through blockchain nodes. For example, multiple blockchain nodes corresponding to different users in a blockchain system can perform secure multi-party computation (SMPC) on a node's private data using privacy technologies such as homomorphic encryption and zero-knowledge proofs. Another example is that blockchain networks can facilitate transfers between different user accounts. Furthermore, blockchain networks can also be used to issue NFTs (non-fungible tokens) corresponding to digital collectibles such as digital paintings, digital avatars, and GIFs. This allows the ownership of the digital collectibles carried by the NFTs to circulate among users on the blockchain network, thereby generating corresponding value for the digital collectibles.

[0003] Once consensus is reached on a block, the transactions contained in the block and the predetermined order of transactions are recognized by the majority of the blockchain nodes in the system. Each blockchain node can then execute the block, executing each transaction in the block in that predetermined order, and persisting the corresponding state data after execution is complete.

[0004] Each block in the blockchain needs to be executed in order from low to high block height. In related technologies, for any pending block to be executed after consensus is completed (hereinafter referred to as the next block), the blockchain node will respond to the completion of the execution of the previous block of the block, read the state data required for executing the next block from the persistently saved state data, and use this state data to execute the next block, and then persist the new state data obtained by execution, thereby completing the processing process for the block. However, since the read / write performance of the storage space used to persist the state data is usually poor, the state data reading process is slow, and the overall execution of the next block takes a long time, which seriously affects the block processing efficiency of the pipeline and results in a low transaction throughput of the blockchain system as a whole.

[0005] Summary of the Invention

[0006] This specification provides a transaction execution method and device. Specifically, this specification is implemented through the following technical solutions.

[0007] According to a first aspect of an embodiment of the present specification, a transaction execution method is provided, comprising: for a target block to be executed and a forward block to be executed before the target block, if there is at least one forward block that has not been completely executed, determining a first read set of the target block based on each transaction in the target block, wherein the first read set includes a data identifier of first target data required to execute each transaction in the target block; and reading and caching the first target data from persistently stored state data based on the data identifier;

[0008] When all the forward blocks are executed, each transaction in the target block is executed according to the cached first target data.

[0009] According to a second aspect of an embodiment of this specification, a transaction execution device is provided, comprising: a read set determination unit for determining, for a target block to be executed and a forward block to be executed before the target block, a first read set of the target block according to each transaction in the target block, when there is at least one forward block that has not yet been executed, wherein the first read set includes a data identifier of first target data required to execute each transaction in the target block; a data cache unit for reading and caching the first target data from persistently stored state data according to the data identifier; and a transaction execution unit for executing each transaction in the target block according to the cached first target data, when all the forward blocks have been executed.

[0010] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the steps of the method as described in any one of the first aspects are implemented.

[0011] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any one of the first aspects are implemented.

[0012] In the technical solution provided in this specification, for a target block to be executed and a forward block that needs to be executed before the target block, when there is at least one forward block that has not been fully executed, the blockchain node determines a first read set of the target block based on each transaction in the target block, wherein the first read set includes a data identifier of the first target data required to execute each transaction in the target block; then, according to the data identifier, the first target data is read and cached from the persistently stored state data; and further, when all the forward blocks are fully executed, each transaction in the target block is executed according to the cached first target data.

[0013] When at least one forward block (i.e., a block that needs to be executed before the target block) has not yet been executed, the blockchain node reads and caches the first target data required to execute the target block from the persistently saved state data; based on this, when all forward blocks have been executed, the target block is executed using the first target data that has been pre-read and cached. It can be seen that this solution abandons the method of temporarily reading the first target data when executing the target block, but pre-reads and caches the first target data before executing the target block (such as when executing the forward block or before executing the forward block), that is, uses the time waiting for the forward block to be executed to pre-read and cache the first target data (required for executing the target block), and then after executing each forward block (because each block is executed in sequence, it is actually after the previous forward block adjacent to the target block is executed), the cached first target data can be used immediately to execute the target block. This solution pre-reads and caches the first target data required to execute the target block during the execution of the forward block. It not only realizes the parallel processing of different blocks by reusing this time, effectively avoiding waiting for the forward block to be executed before executing the target block, but also advances the process of reading the first target data, so that the target block can be executed immediately (based on the cached first target data) after the forward block is executed, effectively shortening the overall execution time of the target block and improving execution efficiency, thereby helping to improve the transaction throughput of the blockchain system.

[0014] 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 disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0016] FIG1 is a flow chart of a transaction execution method provided by an exemplary embodiment;

[0017] FIG2 is a schematic diagram of a pipeline architecture provided by an exemplary embodiment;

[0018] FIG3 is a schematic structural diagram of a device provided by an exemplary embodiment;

[0019] FIG4 is a schematic diagram of a transaction execution device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0020] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of this specification.

[0021] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments. It should be understood that although this specification may use terms such as first, second, and third to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish between information of the same type. For example, first information may also be referred to as second information, and similarly, second information may be referred to as first information, without departing from the scope of this specification. Depending on the context, the term "if" as used herein can be interpreted as "when," "when," or "in response to a determination."

[0022] Once consensus is reached on a block, the transactions contained in the block and the predetermined order of transactions are recognized by the majority of the blockchain nodes in the system. Each blockchain node can then execute the block, executing each transaction in the block in that predetermined order, and persisting the corresponding state data after execution is complete.

[0023] Each block in the blockchain needs to be executed in order from low to high block height. In related technologies, for any pending block to be executed after consensus is completed (hereinafter referred to as the next block), the blockchain node will respond to the completion of the execution of the previous block of the block, read the state data required for executing the next block from the persistently saved state data, and use this state data to execute the next block, and then persist the new state data obtained by execution, thereby completing the processing process for the block. However, since the read / write performance of the storage space used to persist the state data is usually poor, the state data reading process is slow, and the overall execution of the next block takes a long time, which seriously affects the block processing efficiency of the pipeline and results in a low transaction throughput of the blockchain system as a whole.

[0024] In this regard, this specification provides a new transaction execution method, which is described in detail below with reference to the accompanying drawings.

[0025] Figure 1 is a flowchart of a transaction execution method provided by an exemplary embodiment. As shown in Figure 1, this method can be applied to any blockchain node in a blockchain system. The blockchain node described in this specification can be the node that initiates a consensus proposal in the blockchain system (e.g., a master node), or it can be another blockchain node other than the master node (e.g., a slave node). Regardless of whether it is a master node or a slave node in the blockchain system, each node can be implemented as any device, platform, equipment, or device cluster with computing / processing capabilities. The method includes the following steps 102-106.

[0026] Step 102: For a target block to be executed and a forward block to be executed before the target block, if there is at least one forward block that has not been fully executed, determine a first read set of the target block based on each transaction in the target block, wherein the first read set includes data identifiers of first target data required to execute each transaction in the target block.

[0027] First of all, it should be noted that the various blocks described in this specification need to be executed one by one in sequence. Taking the block height as an example, each block can be executed in order from low to high according to the block height, such as after executing any block i (i.e., the block with a block height of i, the same below) is completed, then the next block i+1 is executed. The target block described in this specification is any block to be executed, and the forward blocks are the blocks that need to be executed before the target block; in other words, the forward blocks of the target block need to be executed before the target block. Of course, the execution of each forward block also needs to meet the corresponding order, which will not be repeated here.

[0028] Furthermore, in this specification, "executing" a block refers to the process of executing each transaction in that block sequentially according to their pre-determined order. This pre-determined order is the order determined during the consensus process for that block. For simplicity, "executing each transaction in a block" will be referred to as "executing the block."

[0029] In one embodiment, blockchain nodes can process each block according to a pipeline architecture. For example, the pipeline architecture may include multiple pipelines, each of which is used to complete specific processing tasks for each block, namely, processing each block sequentially according to its own processing logic. Exemplarily, the multiple pipelines in the pipeline architecture, in the order in which they process a given block, may include, but are not limited to, a block generation pipeline, a consensus pipeline, an execution pipeline, a persistence pipeline, and a verification pipeline. Thus, a block generated by the generation pipeline can undergo consensus processing in the consensus pipeline. Once consensus is reached, the block becomes a pending block and can be executed by the execution pipeline. After execution is complete, the persistence pipeline can persist the resulting state data. Finally, the verification pipeline verifies the execution and persistence results. If the verification is correct, the block is considered complete. If the verification is incorrect, the block can be re-verified after multiple consecutive blocks have been persisted, or a rollback can be performed, according to pre-set logic.

[0030] In addition, each pipeline in the pipeline architecture can be implemented by a different process to avoid mutual influence between different pipelines. The processes can be discrete concepts, and these processes logically belong to the blockchain node. Among them, the node program of the blockchain node (used to implement the control logic of the node) can be deployed in any physical device, and the above-mentioned process can be deployed in the physical device or in other physical devices different from the physical device (such as each process can be deployed in different cloud servers in the form of a cluster). Regardless of the deployment method, the above-mentioned different processes can be regarded as "remote", and information and data exchange can be achieved between different processes through corresponding inter-process communication technologies, such as RPC (Remote Procedure Call, Remote Procedure Call) technology, PIPE (pipeline) technology, message queue (Message Queue) technology, etc. This specification does not limit this.

[0031] It should be noted that the above-mentioned block pipeline, consensus pipeline, etc. are only for illustrative purposes to illustrate the working principle of the pipeline architecture. During the implementation of the solution, the pipeline architecture can also adjust the number, order, and / or processing logic of the pipelines included according to actual needs. This specification does not limit the specific content of the pipeline architecture. It is understandable that the pipeline architecture can achieve serial processing of any block while achieving parallel processing of multiple blocks. Taking the above-mentioned exemplary pipeline architecture as an example, any block i can be processed sequentially by the block pipeline, consensus pipeline, execution pipeline, persistence pipeline, and verification pipeline, thereby achieving serial processing of the block; and multiple adjacent blocks can be processed separately by different pipelines at the same time. For example, at any time t, the consensus pipeline is participating in the consensus process for block i, the execution pipeline is executing block i-1, and the persistence pipeline is persisting the state data obtained by executing block i-2, etc., which will not be further described. As can be seen, compared to processing each block sequentially, the above pipeline architecture can process multiple blocks in parallel, significantly improving the transaction throughput of the blockchain system. The transaction execution method described in this specification can be implemented in conjunction with this pipeline architecture. The specific implementation method can be found in the examples below and will not be detailed here.

[0032] As previously mentioned, any target block contains at least one transaction, and the target block may contain one or more blocks. Therefore, if there is at least one uncompleted forward block, the blockchain node can determine the first read set of the target block based on the transactions in the target block. The uncompleted forward block may include a forward block that has not yet begun execution and / or a forward block that is currently executing (but not yet completed).

[0033] In one embodiment, in response to consensus on the target block, if there is at least one unexecuted forward block, the block can determine the first read set of the target block based on the transactions contained in the target block. The target block consensus completion indicates that the block needs to be executed. In other words, the target block on which consensus has been reached is referred to as the pending block. In response to consensus on the target block, the blockchain node can check whether there is an unexecuted forward block (of the target block) and, if there is at least one such forward block, determine the first read set of the target block.

[0034] FIG2 is a schematic diagram of a pipeline architecture provided by an exemplary embodiment. As shown in FIG2 , the consensus pipeline can participate in the consensus process for block BLOCKn. After consensus is completed, BLOCKn becomes a block to be executed. At this time, the consensus pipeline can pass BLOCKn to the waiting execution block queue managed by the execution pipeline as the last block in the queue. In the waiting execution block queue, BLOCKn is preceded by BLOCKn in sequence by BLOCKn-1, BLOCKn-2, and BLOCKn-3. At this moment, BLOCKn-4, which has been removed from the waiting execution block queue, is being executed. Executing this block can obtain state data that needs to be persisted. Correspondingly, for BLOCKn-5, which has been executed at this moment, the persistence pipeline is persisting the state data obtained by executing this block. It can be understood that each block in the queue of waiting blocks will be removed in sequence according to their arrangement order for execution. For example, after BLOCKn-4 is executed, all forward blocks of BLOCKn-3 are executed. At this time, BLOCKn-3 can be removed from the queue for execution.

[0035] During the execution of each transaction in the target block, the currently persisted state data is used. This state data is hereinafter referred to as the first target data. The first read set, determined before the forward block is fully executed, contains the data identifiers of each first target data item. In other words, the first read set is a collection of the data identifiers of each first target data item corresponding to the target block. Therefore, blockchain nodes can determine the data identifier of the corresponding first target data item based on each transaction in the target block, and the data identifiers of the first target data item required for each transaction constitute the first read set of the target block.

[0036] In one embodiment, given that transactions to be executed typically have input parameters and / or invoke already deployed smart contracts, when determining the first read set, blockchain nodes can determine the data identifier of the first target data required to execute any transaction based on the input parameters of that transaction and / or the invoked smart contract. The data identifier of the first target data required for each transaction in the target block constitutes the first read set of the target block. In this way, blockchain nodes can accurately determine the first target data required for each transaction based on its input parameters and / or invoked smart contract, laying a solid data foundation for achieving correct execution results in the subsequent execution process.

[0037] Among them, the data identifier of any first target data determined in the above manner can be the data name, data number, storage address (after persistent storage), etc. of the data. Exemplarily, when the state data is persistently stored in the form of key-value pairs (key-value or KVs), the data identifier of any first target data can be the corresponding key (key), and the any first target data is the value (value) corresponding to the key (key). In addition, since there may be multiple transactions in the target block that require the same state data, after determining the data identifier of the required first target data according to each transaction, these data identifiers can also be deduplicated to avoid subsequent repeated reading of a certain persistently stored first target data or caching of multiple copies of the same first target data.

[0038] Taking any smart contract called by a transaction as an example, the contract's input parameter information can be determined based on the function recorded in the contract's API (Application Programming Interface) or ABI (Application Binary Interface), and then the key corresponding to each input parameter can be queried based on this information.

[0039] At this point, for the target block to be executed, the blockchain node has determined the first read set of the block, that is, it has determined the data identifiers of the various first target data required to execute the block. It should be emphasized that the first read set only contains the identifiers of the first target data, and does not contain the first target data itself. In view of the fact that the subsequent execution of the target block requires the use of each first target data (itself), the blockchain node also needs to read and cache the first target data from the persistently saved state data according to the various data identifiers in the first read set. It is understandable that for the target block, the persistently saved state data can be uniformly set by the blockchain system and / or obtained by executing the forward block (this part of the forward block has completed execution and persistence processing at the current moment).

[0040] Step 104: Read and cache the first target data from the persistently stored state data according to the data identifier.

[0041] In one embodiment, in addition to persistently storing the state data, the blockchain system may also persistently store the data identifiers of these state data. For example, the corresponding relationship between each state data item obtained by executing the forward block and its data identifier may be persistently stored. Based on this, the blockchain node may query any data identifier in the first read set within the corresponding relationship, and then determine the state data corresponding to the queried data identifier as the first target data, and then read and cache the first target data. The corresponding relationship between the state data item and its data identifier may be in the form of a list, a key-value pair, or the like, and this specification is not limited thereto.

[0042] Exemplarily, when the state data to be read is persistently stored in the form of a key-value pair, the key corresponding to any state data is the data identifier of the state data, and the corresponding value is the data value of the state data (i.e., the state data itself). Based on this, when the blockchain node reads the first target data according to the data identifier, it can first query the target key that is the same as the data identifier from the key of the persistently stored key-value pair, and then read the target value corresponding to the target key as the first target data. In this way, the blockchain node can accurately read the first target data from the persistently stored key-value pair.

[0043] The state data described in this specification can be persistently stored in the database of the blockchain node. The database can specifically be a disk accessible to the blockchain node, such as a local disk of the node device where the blockchain node is located or a virtual disk mounted by the node device. The database can also be a remote storage space such as a network database accessible to the blockchain node. In addition, the storage space used to cache the first target data can be the memory or local cache (or buffer) of the node device where the blockchain node is located. Accordingly, "persistently save any state data" means storing (i.e., writing) the state data in the above-mentioned database of the blockchain node; "caching any first target data" means storing (i.e., writing) the first target data in the above-mentioned cache space.

[0044] This specification does not limit the form of the database used for persistent storage and the form of the cache space for the first target data, which can be selected according to actual needs. However, it should be noted that the read / write performance of the cache space is usually better than the read / write performance of the database (such as the read / write performance of the memory of the node device where the blockchain node is located is better than the read / write performance of the local disk of the device), so the time taken to read the (cached) first target data from the cache space is usually less than the time taken to read the (persistently stored) first target data from the database. Because of this, this solution pre-reads the persistently stored first target data from the above-mentioned database and caches it in the cache space, and then reads the (cached) first target data from the cache space during the execution of the target block, rather than directly reading the (persistently stored) first target data from the above-mentioned database. This can significantly shorten the time taken to read the first target data during the execution of the target block, thereby improving the overall execution speed of the block.

[0045] At this point, the process of reading and caching the first target data required to execute the target block is complete. It should be noted that while executing steps 102 and 104, the blockchain node can also execute forward blocks. Moreover, after completing steps 102 and 104 (i.e., caching the first target data), if there are still forward blocks that have not been fully executed, the blockchain node needs to continue executing these forward blocks until all forward blocks are fully executed, and then start executing the target block using the cached first target data.

[0046] In one embodiment, after the execution of any forward block in the aforementioned "unfinished forward blocks", state data that needs to be persisted will be generated. If there is at least one state data in this part of the state data that also belongs to the first target data, then when the target block is subsequently executed, the corresponding transaction needs to be executed according to the state data, and the cached first target data should not be used to execute the corresponding transaction to ensure the correctness of the transaction execution result. To this end, the blockchain node can update the cached first target data. For example, when the execution of any forward block is completed, the forward write set of any forward block can be determined. The forward write set contains the forward state data and its data identifier that need to be persisted obtained by executing each transaction in the forward block. It can be understood that after the execution of any forward block is completed, the forward state data and its data identifier that need to be persisted obtained during the execution process can be used to form the forward write set. As previously mentioned, the first read set contains the data identifier of the first target data. Based on this, the data identifiers contained in the forward write set and the first read set can be compared one by one to see if they are the same: if the forward write set and the first read set contain the same data identifier (hereinafter referred to as the data identifier to be updated), the cached first target data represented by the data identifier to be updated is updated to the forward state data represented by the data identifier to be updated; in other words, for any first target data corresponding to the data identifier to be updated in the first write set and the forward state data corresponding to the data identifier to be updated in the forward write set, the forward state data can be used to update the persistently stored first target data. The updated target data can then be used to execute the corresponding transaction in the target block. In this way, for all the first target data required for a block that was cached before the execution of any forward block is completed, the portion that needs to be updated can be updated after the execution of the forward block is completed, so that the updated state data can be used to execute the corresponding transaction when the target block is subsequently executed, thereby effectively ensuring the correctness of the execution process and execution results of this part of the transaction.

[0047] In addition, in addition to updating the cached first target data, the corresponding persistently stored state data can also be updated. For example, if the forward write set and the first read set contain the same data identifier to be updated, the persistently stored first target data represented by the data identifier to be updated can be updated to the forward state data represented by the data identifier to be updated. In other words, for any state data corresponding to the data identifier to be updated in the aforementioned database (i.e., the state data read in the aforementioned step 104) and the corresponding forward state data in the forward write set, the forward state data can be used to update the corresponding state data in the database. The update process can be completed by the aforementioned persistence pipeline.

[0048] Among them, using any forward state data to update any data (i.e., any first target data or any state data) can be specifically achieved through a write operation, such as writing any forward state data at the original address of any data, thereby overwriting any data; or writing any forward state data at other addresses, and pointing the access pointer for any data to the other addresses. This specification does not limit the specific update method.

[0049] As shown in Figure 2, let's assume that disk represents the local disk of the blockchain node (accessible to the blockchain node) and storage cache represents the cache space allocated from the node's memory. If block BLOCKn is the target block, it can be transferred to the queue of pending blocks after consensus on BLOCKn is completed (as shown in step "1. After consensus is completed" in Figure 2). At this point, there are four unexecuted blocks before BLOCKn, namely BLOCKn-1 through BLOCKn-4. The blockchain node can determine the first read set for BLOCKn and read the corresponding first target data from disk. It then writes each read first target data to the storage cache (as shown in steps "2. Pre-read" and "3 / 4. Read data from disk into cache" in Figure 2), completing the caching of this data.

[0050] At the same time, the execution pipeline is also executing BLOCKn-4: it loads the pre-cached first target data for BLOCKn-4 from the storage cache (as shown in step "5. Loading data from cache" in Figure 2) and executes each transaction in that block (as shown in "Executing block" in Figure 2). After the execution of this block is completed, a forward write set (relative to BLOCKn) can be obtained. At this time, it can be determined whether there is a data identifier to be updated in the forward write set that is identical to the data identifier in the first read set. If so, the forward state data in the forward write set represented by the data identifier to be updated is used to update the first target data (corresponding to BLOCKn) in the storage cache represented by it (as shown in step "6. Update cache" in Figure 2). Of course, if there is a data identifier to be updated in the forward write set that is identical to the data identifier in the first read set corresponding to BLOCKn-1 to BLOCKn-3, then this cached portion of the first target data can be updated in the same manner, which will not be repeated here.

[0051] Step 106 : When all the forward blocks are executed, execute each transaction in the target block according to the cached first target data.

[0052] As previously described, step 102 is a first read set determined when there is at least one forward block that has not yet been executed. The blockchain node can execute the forward blocks simultaneously during or after executing steps 102 and 104 until all forward blocks are executed. At this point, the blockchain node can begin executing the target block using the cached first target data.

[0053] As previously mentioned, blockchain nodes can process blocks using a pipeline architecture. In this scenario, steps 102-106 can be completed by the execution pipeline within this architecture. In other words, steps 102 and 104 can be executed by the execution pipeline within the pipeline framework.

[0054] In the technical solution provided in this specification, for a target block to be executed and a forward block that needs to be executed before the target block, when there is at least one forward block that has not been fully executed, the blockchain node determines a first read set of the target block based on each transaction in the target block, wherein the first read set includes a data identifier of the first target data required to execute each transaction in the target block; then, according to the data identifier, the first target data is read and cached from the persistently stored state data; and further, when all the forward blocks are fully executed, each transaction in the target block is executed according to the cached first target data.

[0055] When at least one forward block (i.e., a block that needs to be executed before the target block) has not yet been executed, the blockchain node reads and caches the first target data required to execute the target block from the persistently saved state data; based on this, when all forward blocks have been executed, the target block is executed using the first target data that has been pre-read and cached. It can be seen that this solution abandons the method of temporarily reading the first target data when executing the target block, but pre-reads and caches the first target data before executing the target block (such as when executing the forward block or before executing the forward block), that is, uses the time waiting for the forward block to be executed to pre-read and cache the first target data (required for executing the target block), and then after executing each forward block (because each block is executed in sequence, it is actually after the previous forward block adjacent to the target block is executed), the cached first target data can be used immediately to execute the target block. This solution pre-reads and caches the first target data required to execute the target block during the execution of the forward block. It not only realizes the parallel processing of different blocks by reusing this time, effectively avoiding waiting for the forward block to be executed before executing the target block, but also advances the process of reading the first target data, so that the target block can be executed immediately (based on the cached first target data) after the forward block is executed, effectively shortening the overall execution time of the target block and improving execution efficiency, thereby helping to improve the transaction throughput of the blockchain system.

[0056] Since the aforementioned first read set is determined under the condition that "there is at least one forward block that has not been executed", the corresponding cached first data identifier is read from the persistently saved state data after the first read set is determined, and at least one forward block is executed before the target block is executed. In view of the fact that the execution process of the forward block may affect the target data required for the transaction in the target block, such as the execution process of the forward block changes the key of a state parameter of a smart contract, and the target block needs to call the state parameter. In this case, if the pre-stored read and cached first target data is still used to execute the corresponding transaction, it may cause the execution result of the transaction to be erroneous. In short, because the first target data corresponding to the state data is pre-read and cached before the forward block is executed, and the execution process of the forward block may affect the state data that the target block needs to call, the target data required when the target block is actually executed may be different from the first target data.

[0057] To avoid transaction execution errors, a corresponding second read set can be determined before executing the target block and compared with the first read set to identify the changed parts and process them accordingly. For example, when executing each transaction in the target block, a second read set for the target block can be determined based on each transaction in the target block, wherein the second read set contains the data identifiers of the second target data required to execute each transaction in the target block. The specific method for determining the second read set can be the same as that for the first read set, and will not be repeated here. It can be understood that the first read set and the second read set have the same form, but because they are determined at different times, their contents (i.e., the data identifiers contained in them) may be the same or different: if the data identifier of (at least one) first target data is updated when the state data corresponding to the forward block is persistently saved, the second read set will be different from the first read set; conversely, if the data identifier of the first target data is not updated, the second read set will be the same as the first read set. Therefore, after determining the second read set, the first read set and the second read set can be compared to determine whether they are the same, that is, to compare whether the data identifiers contained in the first read set and the second read set are the same. Among them, the comparison process can compare each data identifier contained in the two sets one by one; or, in order to improve efficiency, the overall hash of the two sets can be calculated and compared first to quickly exclude the special case where the two sets are the same, and when it is determined that there are different data identifiers between the two sets (the overall hash of the two sets is different), then compare them to further determine which specific data identifiers are different; or, a bloom filter can be used for a quick comparison. The specific comparison process can be found in the records in the relevant technology and will not be repeated here.

[0058] According to the comparison results, if the data identifiers contained in the first read set and the second read set are exactly the same, it means that the second target data (determined after the forward block is fully executed) and the first target data (determined before the forward block is fully executed) are exactly the same. At this time, each transaction in the target block can be directly executed according to the cached first target data. On the contrary, if the data identifiers contained in the first read set and the second read set are not exactly the same, it means that the second target data and the first target data are not exactly the same. At this time, the data identifiers contained in the second read set can be divided into two parts: an unchanged identifier that is the same as the data identifier contained in the first read set, and a changed identifier that is different from the data identifier contained in the first read set (such as a data identifier that has changed relative to the data identifier in the first read set, or a data identifier that has been added relative to the first read set, etc.). Furthermore, the second target data represented by the changed identifier can be read from the persistently saved state data; then, each transaction in the target block can be executed according to the first target data represented by the cached unchanged data identifier and the second target data represented by the read changed data identifier. Among them, the "second target data represented by the changed data identifier" can be cached in the cache space after being read, so as to be loaded from the cache space when the corresponding transaction is executed; or, in order to save cache space, it can also be temporarily read during the execution of the transaction, so that this part of the data does not need to be cached.

[0059] In this way, when the execution process of the forward block causes the target data required by the target block to change, the second target data actually required to execute the target block at the current moment (i.e., after all forward blocks have been executed) can be accurately determined, and then the various transactions in the target block are executed according to this part of the target data to obtain accurate execution results, thereby avoiding the above-mentioned changes causing errors in the execution results of the target block. Among them, when the interval between the target block and the forward block is small, the execution process of the target block usually only causes a small part of the target data required by the target block to change or even all the target data to remain unchanged. Therefore, by reasonably setting the length of the queue of waiting blocks for execution in the aforementioned pipeline architecture (i.e., the maximum number of blocks that the queue can accommodate at the same time), the target block and the forward block can be limited to be as small as possible, so as to effectively reduce the number of changed identifiers in the second read set (try to make this number close to 0), so that the first target data that has been pre-read and cached can be used as much as possible during the execution of the target block, thereby reducing the execution time of the target block.

[0060] By calculating each transaction in the target block in the aforementioned manner, a target write set for the target block can be obtained. This target write set contains the data to be written (i.e., the state data generated by executing each transaction and to be persisted) and its data identifiers. At this point, the data to be written and its data identifiers in the target write set can be persisted. This persistence process can be accomplished by the persistence pipeline in the aforementioned blockchain architecture.

[0061] In one embodiment, the above-mentioned persistence process can be implemented in a variety of ways. For example, when any transaction in the target block is executed, the data to be written and its data identifier obtained by executing the transaction can be determined and cached, wherein the data to be written and its data identifier obtained by executing each transaction in the target block constitute the target write set; then, when each transaction in the target block is executed, the cached target write set (that is, the data identifier and data value of the target data corresponding to each transaction in the cached target block) is persisted. In this way, all the data to be written and its data identifier obtained by executing a block can be batch-persistently stored in the database of the blockchain node, thereby reducing the number of interactions between the upper-level logic of the blockchain node (such as the persistence pipeline) and the underlying database (such as the disk), and improving the persistence efficiency.

[0062] For another example, when any transaction in the target block is completed, the data to be written and its data identifier obtained by executing the transaction can be determined and persistently saved. It can be understood that when all transactions in the target block are executed, the data identifiers and data values ​​of the target data corresponding to each of the transactions that have been persistently saved constitute the target write set. As shown in Figure 2, after BLOCKn-5 is executed, the data to be written and the data identifier in its target write set can be written to the disk of the node device where the blockchain node is located (such as step "7. Persistence of cached data to disk" in Figure 2). In this way, the data to be written and its data identifier obtained by executing the transaction can be persistently saved in a timely manner, thereby reducing the management pressure on this part of the data and saving cache space, and even this part of the data does not need to be cached.

[0063] It is understandable that the first target data pre-read and cached in the aforementioned manner is used to execute the target block. Since it occupies the valuable cache space of the blockchain node (such as the memory of the node device, etc.), when the execution of each transaction in the target block is completed, the cached first target data can be deleted in time to reclaim the cache space occupied by this part of the data in time. Of course, some of the aforementioned embodiments need to read and cache the second target data represented by the changed data identifier. In this regard, when the execution of each transaction in the target block is completed, this cached part of the target data can also be deleted, which will not be repeated. In short, after the execution of any block is completed, all target data cached for the execution of the block can be deleted.

[0064] As mentioned above, the blockchain node can determine the first read set of the target block in response to the completion of the consensus on the target block, in the case that there is a forward block that has not been executed. In fact, the blockchain node can also determine the first read set of the target block in response to the completion of the consensus on the target block, in the case that there is no forward block that has not been executed; further, the first target data can be read from the persistently saved state data according to the data identifier contained in the first read set, and each transaction in the target block can be executed according to the read first target data. The method for determining the first read set, the method for determining the first target data, and the method for executing the first block can be referred to the aforementioned embodiment and will not be repeated here. It can be seen that the blockchain node can directly determine the first read set of the block in response to the completion of the consensus on the target block, without having to determine whether there is a forward block that has not been executed, and will not be repeated here.

[0065] FIG3 is a schematic structural diagram of a device provided by an exemplary embodiment. Referring to FIG3 , at the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, a memory 308, and a non-volatile memory 310, and may also include hardware required for other functions. One or more embodiments of this specification may be implemented based on software, such as the processor 302 reading the corresponding computer program from the non-volatile memory 310 into the memory 308 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or logic devices.

[0066] As shown in FIG4 , FIG4 is a block diagram of a transaction execution device provided by this specification according to an exemplary embodiment. The device can be applied to the device shown in FIG3 as a functional module of a blockchain node to implement the technical solution of this specification. The device includes: a read set determination unit 401, for determining a first read set of the target block according to each transaction in the target block for a target block to be executed and a forward block that needs to be executed before the target block, when there is at least one forward block that has not been executed, wherein the first read set contains a data identifier of the first target data required to execute each transaction in the target block; a data cache unit 402, for reading and caching the first target data from the persistently stored state data according to the data identifier; and a transaction execution unit 403, for executing each transaction in the target block according to the cached first target data when all forward blocks have been executed.

[0067] Optionally, it also includes: a forward write set determination unit 404, which is used to determine the forward write set of any forward block when any forward block is executed, and the forward write set contains the forward state data and its data identifier that need to be persisted and obtained by executing each transaction in the forward block; a cache update unit 405, which is used to update the cached first target data represented by the data identifier to be updated to the forward state data represented by the data identifier to be updated if the forward write set and the first read set contain the same data identifier to be updated.

[0068] Optionally, it also includes: a persistent update unit 406, which is used to update the persistently saved state data represented by the data identifier to be updated to the forward state data represented by the data identifier to be updated if the forward write set and the first read set contain the same data identifier to be updated.

[0069] Optionally, the transaction execution unit 403 is specifically used to: determine a second read set of the target block based on each transaction in the target block, wherein the second read set contains data identifiers of second target data required to execute each transaction in the target block; if the data identifiers contained in the first read set and the second read set are exactly the same, then execute each transaction in the target block according to the cached first target data; if the data identifiers contained in the first read set and the second read set are not exactly the same, then divide the data identifiers contained in the second read set into unchanged identifiers that are the same as the data identifiers contained in the first read set and changed identifiers that are different from the data identifiers contained in the first read set, and read the second target data represented by the changed identifiers from the persistently saved state data; and, execute each transaction in the target block according to the first target data represented by the cached unchanged data identifiers and the second target data represented by the read changed data identifiers.

[0070] Optionally, the read set determination unit 401 is specifically configured to: in response to the target block consensus being completed, when there is at least one forward block that has not been fully executed, determine the first read set of the target block according to each transaction included in the target block.

[0071] Optionally, the read set determination unit 401 is specifically used to determine the data identifier of the first target data required to execute the transaction based on the input parameters of any transaction and / or the called smart contract, wherein the data identifier of the first target data required for each transaction in the target block constitutes the first read set of the target block.

[0072] Optionally, the state data is persistently stored in the form of a key-value pair, where the key corresponding to any state data is the data identifier of the state data, and the corresponding value is the data value of the state data. The data cache unit 402 is specifically used to: query the target key that is the same as the data identifier from the key of the persistently stored key-value pair, and read the target value corresponding to the target key as the first target data.

[0073] Optionally, it further includes: a persistence unit 407, which is used to determine the target write set of the target block obtained by executing each transaction in the target block, and persistently save the to-be-written data and its data identifier contained in the target write set.

[0074] Optionally, the persistence unit 407 is specifically configured to: upon completion of any transaction in the target block, determine and cache the to-be-written data and its data identifier obtained by executing the transaction, wherein the to-be-written data and its data identifier obtained by executing each transaction in the target block constitute the target write set; and upon completion of execution of each transaction in the target block, persistently store the cached target write set; or

[0075] When any transaction in the target block is completed, the data to be written and its data identifier obtained by executing the transaction are determined and persistently saved.

[0076] Optionally, the method further includes: a cache recovery unit 408, configured to delete the cached first target data when each transaction in the target block is completed.

[0077] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0078] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0079] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0080] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0081] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0082] The present application is described with reference to the flowchart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, and the combination of the process and / or box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the function specified in one process or multiple processes in the flowchart and / or one box or multiple boxes in the block diagram.

[0083] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0084] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0085] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0086] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0087] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0088] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0090] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0091] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A method for executing a transaction, comprising: For a target block to be executed and a forward block to be executed before the target block, if there is at least one forward block that has not been completely executed, determine a first read set of the target block according to each transaction in the target block, wherein the first read set includes a data identifier of a first target data required to execute each transaction in the target block; Reading and caching first target data from persistently stored state data according to the data identifier; When all the forward blocks are executed, each transaction in the target block is executed according to the cached first target data.

2. The method according to claim 1, further comprising: When any forward block is executed, determine a forward write set of the forward block, wherein the forward write set includes forward state data and data identifiers thereof obtained by executing each transaction in the forward block and need to be persisted; If the forward write set and the first read set contain the same to-be-updated data identifier, the cached first target data represented by the to-be-updated data identifier is updated to the forward state data represented by the to-be-updated data identifier.

3. The method according to claim 2, further comprising: If the forward write set and the first read set contain the same identifier of data to be updated, the persistently stored state data represented by the identifier of data to be updated is updated to the forward state data represented by the identifier of data to be updated.

4. The method according to claim 1, wherein executing each transaction in the target block according to the cached target data comprises: Determine a second read set of the target block according to each transaction in the target block, wherein the second read set includes a data identifier of second target data required to execute each transaction in the target block; If the data identifiers included in the first read set and the second read set are exactly the same, then executing each transaction in the target block according to each cached first target data; If the data identifiers contained in the first read set and the second read set are not exactly the same, the data identifiers contained in the second read set are divided into unchanged identifiers that are the same as the data identifiers contained in the first read set and changed identifiers that are different from the data identifiers contained in the first read set, and the second target data represented by the changed identifiers are read from the persistently saved state data; and, each transaction in the target block is executed according to the cached first target data represented by the unchanged data identifier and the read second target data represented by the changed data identifier.

5. The method according to claim 1, in the case where there is at least one forward block that has not been executed, determining the first read set of the target block according to each transaction included in the target block, comprising: In response to the target block consensus being completed, in the case where there is at least one forward block that has not been fully executed, a first read set of the target block is determined according to each transaction included in the target block.

6. According to the method of claim 1, determining the first read set of the target block according to each transaction included in the target block comprises: According to the input parameters of any transaction and / or the called smart contract, the data identifier of the first target data required to execute the transaction is determined, wherein the data identifiers of the first target data required for each transaction in the target block respectively constitute the first read set of the target block.

7. According to the method of claim 1, the state data is persistently stored in the form of a key-value pair, wherein the key corresponding to any state data is a data identifier of the state data, and the corresponding value is a data value of the state data, and the reading of the first target data from the persistently stored state data according to the data identifier comprises: A target key identical to the data identifier is searched from the key of the persistently stored key-value pair, and a target value corresponding to the target key is read as the first target data.

8. The method according to claim 1, further comprising: A target write set of the target block obtained by executing each transaction in the target block is determined, and the data to be written and its data identifier contained in the target write set are persistently saved.

9. According to the method of claim 8, determining a target write set of the target block obtained by executing each transaction in the target block, and persistently storing the data to be written and its data identifier contained in the target write set, comprises: When any transaction in the target block is executed, determine and cache the data to be written and its data identifier obtained by executing the transaction, and the data to be written and its data identifier respectively obtained by executing each transaction in the target block constitute the target write set; and when each transaction in the target block is executed, persist the cached target write set; or, When any transaction in the target block is completed, the to-be-written data and its data identifier obtained by executing the transaction are determined and persistently saved.

10. The method according to claim 1, further comprising: When each transaction in the target block is executed, the cached first target data is deleted.

11. A transaction execution device, comprising: a read set determining unit, configured to determine, for a target block to be executed and a forward block to be executed before the target block, a first read set of the target block according to each transaction in the target block when there is at least one forward block that has not been completely executed, wherein the first read set includes a data identifier of first target data required to execute each transaction in the target block; A data cache unit, configured to read and cache first target data from persistently stored state data according to the data identifier; The transaction execution unit is used to execute each transaction in the target block according to the cached first target data when the forward block is fully executed.

12. An electronic device comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 10 by running the executable instructions.

13. A computer-readable storage medium having computer instructions stored thereon, wherein the instructions are executed by a processor to implement the method according to any one of claims 1 to 10.

Images