Smart contract processing method, device, equipment and computer-readable storage medium

Abstract

The present application discloses a smart contract processing method, apparatus, device, and computer-readable storage medium. The method includes: receiving target transaction information and a first MPT read record sent by a pre-execution node, wherein the first MPT read record is a record of the key names corresponding to multiple first MPT nodes in a first MPT branch read by the pre-execution node based on the target transaction information, wherein the first MPT branch is the MPT branch corresponding to the target transaction information; determining a target smart contract based on the target transaction information; determining a second MPT branch corresponding to the target transaction information from the MPT corresponding to the target smart contract, wherein the second MPT branch includes multiple second MPT nodes with a parent-child relationship; and, when the first MPT branch and the second MPT branch are the same, reading data corresponding to multiple second MPT nodes in parallel based on the key names corresponding to the multiple first MPT nodes. According to an embodiment of the present application, the execution speed of smart contracts can be improved, thereby improving the overall performance of the blockchain.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a smart contract processing method, apparatus, device, and computer-readable storage medium. Background Art

[0002] Typically, a smart contract controls a storage area that stores data associated with the smart contract. Currently, the most widely used data structure for storage areas is based on the Merkle Patricia Trie (MPT). MPT offers numerous advantages, including easy detection of data changes, rapid verification of data correctness, and reduced storage overhead, making it crucial in blockchains.

[0003] In existing technologies, smart contracts read data from their own storage during operation. Because smart contract execution is serial, their access to the storage is also serial. When the storage uses the MPT data structure, each read must start from the MPT root node and read through the tree nodes layer by layer until the corresponding data is found or it is determined that the data is not included in the MPT tree. This process is also serial.

[0004] As a result, each smart contract execution requires multiple serial reads of data, and each read involves serial reads from multiple MPT nodes, resulting in a large number of serial hard drive reads. Because hard drive read speeds are significantly lower than those of hardware like the CPU and memory, smart contract execution is slow, impacting the overall performance of the blockchain. Summary of the Invention

[0005] The embodiments of the present application provide a smart contract processing method, apparatus, device, computer-readable storage medium, and computer program product, which can increase the execution speed of smart contracts and thereby improve the overall performance of the blockchain.

[0006] In a first aspect, an embodiment of the present application provides a smart contract processing method, which is applied to a consensus node, and the method includes:

[0007] receiving target transaction information and a first Merkle Patricia tree (MPT) read record sent by a pre-execution node, where the first MPT read record is a record of key names corresponding to multiple first MPT nodes in a first MPT branch read by the pre-execution node based on the target transaction information, wherein the first MPT branch is the MPT branch corresponding to the target transaction information;

[0008] Determining a target smart contract based on the target transaction information;

[0009] Determining, from the MPT corresponding to the target smart contract, a second MPT branch corresponding to the target transaction information, wherein the second MPT branch includes a plurality of second MPT nodes having a parent-child relationship;

[0010] In a case where the first MPT branch is the same as the second MPT branch, data corresponding to multiple second MPT nodes are read in parallel according to key names corresponding to multiple first MPT nodes.

[0011] In one possible implementation, the first MPT node includes a first MPT root node, and the second MPT node includes a second MPT root node;

[0012] When the first MPT branch is the same as the second MPT branch, reading data corresponding to multiple second MPT nodes in parallel according to key names corresponding to multiple first MPT nodes includes:

[0013] Obtaining a first MPT root node in the first MPT branch and a second MPT root node in the second MPT branch;

[0014] determining whether the first MPT root node is the same as the second MPT root node;

[0015] In a case where the first MPT root node is the same as the second MPT root node, data corresponding to multiple second MPT nodes are read in parallel according to key names corresponding to multiple first MPT nodes.

[0016] In a possible implementation, the method further includes:

[0017] If the first MPT root node is different from the second MPT root node, reading data corresponding to the second MPT root node;

[0018] Obtain a first MPT child node of the first MPT root node and a second MPT child node of the second MPT root node;

[0019] determining whether the first MPT child node is the same as the second MPT child node;

[0020] When the first MPT child node is the same as the second MPT child node, data corresponding to multiple target second MPT nodes are read in parallel according to key names corresponding to multiple first MPT nodes, and the target second MPT nodes are the second MPT nodes except the second MPT root node.

[0021] In a possible implementation, the method further includes:

[0022] In the case that the first MPT child node is different from the second MPT child node, the process returns to read the data corresponding to the second MPT child node until the data corresponding to the plurality of second MPT nodes are all read.

[0023] In a second aspect, an embodiment of the present application provides a smart contract processing method, which is applied to a pre-execution node, and the method includes:

[0024] Upon receiving the target transaction information, determining a target smart contract based on the target transaction information;

[0025] Determine, from a Merkle Patricia tree (MPT) corresponding to the target smart contract, a first MPT branch corresponding to the target transaction information, wherein the first MPT branch includes a plurality of first MPT nodes having a parent-child relationship, and the first MPT nodes include a first MPT root node;

[0026] Based on the parent-child relationship, starting from the first MPT root node, sequentially reading key names corresponding to the plurality of first MPT nodes according to a target reading direction, wherein the target reading direction includes a reading direction from the MPT parent node to the MPT child node;

[0027] Recording multiple key names corresponding to the first MPT nodes to obtain a first MPT reading record;

[0028] The first MPT read record and the target transaction information are sent to a consensus node, so that the consensus node reads data corresponding to multiple first MPT nodes in parallel based on the first MPT read record and the target transaction information.

[0029] In a third aspect, an embodiment of the present application provides a smart contract processing device, which is applied to a consensus node. The device includes:

[0030] a receiving module, configured to receive target transaction information and a first Merkle Patricia tree (MPT) read record sent by a pre-execution node, wherein the first MPT read record is a record of key names corresponding to multiple first MPT nodes in a first MPT branch read by the pre-execution node based on the target transaction information, wherein the first MPT branch is the MPT branch corresponding to the target transaction information;

[0031] A first determination module, configured to determine a target smart contract based on the target transaction information;

[0032] A second determining module is configured to determine, from the MPT corresponding to the target smart contract, a second MPT branch corresponding to the target transaction information, wherein the second MPT branch includes a plurality of second MPT nodes having a parent-child relationship;

[0033] The first reading module is configured to read data corresponding to multiple second MPT nodes in parallel according to key names corresponding to multiple first MPT nodes when the first MPT branch is the same as the second MPT branch.

[0034] In a fourth aspect, an embodiment of the present application provides a smart contract processing device, which is applied to a pre-execution node, and includes:

[0035] A third determination module is configured to, upon receiving the target transaction information, determine a target smart contract based on the target transaction information;

[0036] a fourth determining module, configured to determine, from a Merkle Patricia tree (MPT) corresponding to the target smart contract, a first MPT branch corresponding to the target transaction information, wherein the first MPT branch includes a plurality of first MPT nodes having a parent-child relationship, and the first MPT nodes include a first MPT root node;

[0037] a second reading module configured to read, based on the parent-child relationship and starting from the first MPT root node, key names corresponding to the plurality of first MPT nodes in sequence according to a target reading direction, wherein the target reading direction includes a reading direction from the MPT parent node to the MPT child node;

[0038] a first recording module, configured to record key names corresponding to the plurality of first MPT nodes to obtain a first MPT reading record;

[0039] A sending module is used to send the first MPT reading record and the target transaction information to a consensus node, so that the consensus node reads data corresponding to multiple first MPT nodes in parallel based on the first MPT reading record and the target transaction information.

[0040] In a fifth aspect, an embodiment of the present application provides an electronic device, the device comprising: a processor and a memory storing computer program instructions;

[0041] When the processor executes the computer program instructions, the method in any possible implementation method of the first aspect or the second aspect is implemented.

[0042] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the method of any possible implementation method in the first aspect or the second aspect mentioned above is implemented.

[0043] In the seventh aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device executes a method in any possible implementation method of the first aspect or the second aspect mentioned above.

[0044] The smart contract processing method, apparatus, device, computer-readable storage medium, and computer program product of the embodiments of the present application, by receiving a first MPT read record including key names corresponding to multiple first MPT nodes, can, when the first MPT branch is the same as the second MPT branch (i.e., the multiple first MPT nodes are the same as the multiple second MPT nodes), read data corresponding to multiple second MPT nodes in parallel based on the key names corresponding to the multiple first MPT nodes. In this way, according to the embodiments of the present application, the reading efficiency of reading data corresponding to multiple second MPT nodes can be improved, that is, the execution speed of the smart contract can be increased, and the overall performance of the blockchain can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0046] Figure 1 This is a flow chart of a smart contract processing method applied to a consensus node provided in an embodiment of the present application;

[0047] Figure 2 is a schematic diagram of a simplified MPT provided in an embodiment of the present application;

[0048] Figure 3 This is a flow chart of a pre-execution node serially reading key names corresponding to multiple first MPT nodes provided by an embodiment of the present application;

[0049] Figure 4 This is a flow chart of a consensus node reading data corresponding to multiple second MPT nodes in parallel, provided by an embodiment of the present application;

[0050] Figure 5 is a schematic diagram of a modified MPT provided in an embodiment of the present application;

[0051] Figure 6 This is a flow chart of a consensus node reading key names corresponding to multiple second MPT nodes provided by an embodiment of the present application;

[0052] Figure 7 This is a flowchart of a smart contract processing method applied to a pre-execution node provided in an embodiment of the present application;

[0053] Figure 8 This is a schematic diagram of the structure of a smart contract processing device applied to a consensus node provided in an embodiment of the present application;

[0054] Figure 9 This is a schematic diagram of the structure of a smart contract processing device applied to a pre-execution node provided in an embodiment of the present application;

[0055] Figure 10 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating the examples of the present application.

[0057] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, the elements defined by the phrase "comprising..." do not exclude the presence of other identical elements in the process, method, article, or device comprising the elements.

[0058] Blockchain is a decentralized, distributed system and a specific implementation of distributed ledger technology. The information and data recorded in the blockchain are shared and cannot be tampered with, allowing independent verification and audit by all participants. Through a consensus mechanism, all participants on the blockchain reach agreement on changes to the data stored in the blockchain.

[0059] Smart contracts are programs stored on a blockchain that are replicated and executed across all blockchain nodes according to predetermined rules. Smart contracts typically function as digital agreements that adhere to specific, enforceable rules. All parties involved can determine the outcome of a smart contract, eliminating the need for mutual knowledge or trust.

[0060] Typically, a smart contract controls a storage area that stores data associated with the smart contract. Currently, the most widely used data structure for storage areas is based on the Merkle Patricia Trie (MPT). MPT offers numerous advantages, including easy detection of data changes, rapid verification of data correctness, and reduced storage overhead, making it crucial in blockchains.

[0061] The MPT is essentially a hexadecimal trie, where parent and child nodes are connected by hashes—that is, the parent node contains the hash of the child node. When the MPT is stored in a database, each tree node is keyed by its own hash. To read data from the MPT, one must first obtain the MPT's root node. Then, following the path indicated by the key corresponding to the data, one reads the tree nodes layer by layer until the desired data is found or confirmed to be absent from the MPT. This process is serial, as only after obtaining the parent node can the hash of the corresponding child node be obtained, and this hash can be used as the key to retrieve the child node from the database. Each smart contract uniquely corresponds to an MPT, and all data for that contract is stored in that MPT.

[0062] As described in the background technology section, in order to solve the problems of the existing technology, the embodiments of the present application provide a smart contract processing method, device, equipment, computer-readable storage medium and computer program product.

[0063] The following is an introduction to the smart contract processing method applied to the consensus node provided in the embodiment of the present application.

[0064] Figure 1 The following is a flow chart showing a method for processing smart contracts applied to consensus nodes provided by an embodiment of the present application. Figure 1 As shown, the smart contract processing method applied to the consensus node provided in the embodiment of the present application includes the following steps:

[0065] S110: Receive target transaction information and a first Merkle Patricia Tree (MPT) read record sent by a pre-execution node, where the first MPT read record is a record of key names corresponding to multiple first MPT nodes in a first MPT branch read by the pre-execution node based on the target transaction information, wherein the first MPT branch is the MPT branch corresponding to the target transaction information;

[0066] S120. Determine a target smart contract based on the target transaction information.

[0067] S130. Determine, from the MPT corresponding to the target smart contract, a second MPT branch corresponding to the target transaction information, where the second MPT branch includes a plurality of second MPT nodes having a parent-child relationship.

[0068] S140 : When the first MPT branch is the same as the second MPT branch, read data corresponding to the plurality of second MPT nodes in parallel according to the key names corresponding to the plurality of first MPT nodes.

[0069] The smart contract processing method of the embodiment of the present application receives a first MPT read record including key names corresponding to multiple first MPT nodes. When the first MPT branch is the same as the second MPT branch (i.e., the multiple first MPT nodes are the same as the multiple second MPT nodes), the method can concurrently read data corresponding to multiple second MPT nodes based on the key names corresponding to the multiple first MPT nodes. Thus, according to the embodiment of the present application, the efficiency of reading data corresponding to multiple second MPT nodes can be improved, that is, the execution speed of the smart contract can be increased, thereby improving the overall performance of the blockchain.

[0070] The specific implementation methods of the above steps are introduced below.

[0071] In some embodiments, in S110, the pre-execution node may be a special non-consensus node. After receiving the target transaction information, the pre-execution node may execute the target smart contract based on the target transaction information. In the process of the pre-execution node executing the target smart contract, the key names corresponding to multiple first MPT nodes may be serially read and recorded to obtain a first MPT read record. In addition, in the process of reading the key names corresponding to multiple first MPT nodes, the data corresponding to multiple first MPT nodes may also be read and recorded accordingly, that is, the first MPT read record may also include data corresponding to multiple first MPT nodes. Among them, the first MPT node may be an MPT node in the first MPT branch. The first MPT branch may be an MPT branch determined by the pre-execution node from the MPT corresponding to the target smart contract and corresponding to the target transaction information. In addition, the key name corresponding to the node may be the hash value corresponding to the node.

[0072] It should be noted that although non-consensus nodes can read data corresponding to multiple first MPT nodes, based on the characteristics of blockchain, only consensus nodes can confirm the data written into the blockchain.

[0073] As an example, a simplified MPT diagram can be as follows Figure 2 As shown. Based on Figure 2 In the MPT diagram shown, the first MPT branch may include four MPT nodes, namely, ABCDEFGH, EFGH, EF, and F. That is, the first MPT node may include ABCDEFGH, EFGH, EF, and F. The first MPT read record may include key names corresponding to the four MPT nodes, namely, ABCDEFGH, EFGH, EF, and F.

[0074] Based on this, the flowchart of the pre-execution node serially reading the key names corresponding to multiple first MPT nodes can be as follows: Figure 3 shown.

[0075] As an example, after receiving the first MPT read record, the consensus node may perform a preliminary verification on the first MPT read record. If the verification fails, the first MPT read record may be discarded. The verification may include, for example, checking whether the path corresponding to the first MPT branch matches the key name of the data.

[0076] As another example, after receiving the target transaction information, the consensus node can package the target transaction information into a block and execute the target smart contract corresponding to the target transaction information.

[0077] In some embodiments, in S120, the target transaction information may include at least parameter information such as the transaction initiator, the target smart contract address, and the transaction data. Based on this parameter information, the target smart contract corresponding to the target transaction information may be determined. Specifically, the target smart contract may be determined by combining the target transaction information with the world state.

[0078] In some embodiments, in S130, the target smart contract may correspond to an MPT, which may include multiple MPT branches. The consensus node may determine a second MPT branch corresponding to the target transaction information based on the target transaction information and the target smart contract.

[0079] As an example, based on Figure 2 In the MPT diagram shown, the second MPT branch may include four MPT nodes: ABCDEFGH, EFGH, EF, and F. That is, the second MPT nodes may include ABCDEFGH, EFGH, EF, and F. ABCDEFGH may be the parent MPT node of EFGH, and accordingly, EFGH may be the child MPT node of ABCDEFGH. The parent-child relationships between the remaining second MPT nodes are not further described.

[0080] In some embodiments, in S140 , the first MPT branch and the second MPT branch may be the same or different.

[0081] As an example, during the process of executing the target smart contract on the pre-execution node, if the first MPT node does not change, the second MPT branch is the same as the first MPT branch. Conversely, if the first MPT node changes, the second MPT branch is different from the first MPT branch.

[0082] Specifically, the pre-execution node and the consensus node can each execute the target smart contract based on their local databases. The pre-execution node's database can essentially represent the state of the consensus node's database at a specific historical point in time, so there may be differences between the two. Consequently, the MPT trees corresponding to the same smart contract may differ between the pre-execution node and the consensus node, meaning the first and second MPT branches may differ.

[0083] Based on this, if the first MPT branch is the same as the second MPT branch, that is, the multiple first MPT nodes are the same as the multiple second MPT nodes, then the key values ​​corresponding to the multiple first MPT nodes are the same as the key values ​​corresponding to the multiple second MPT nodes. In this way, since the consensus node has obtained the key names corresponding to the multiple first MPT nodes, it can read the data corresponding to the multiple second MPT nodes in parallel based on the key names corresponding to the multiple first MPT nodes. The data corresponding to the second MPT nodes may include the key names corresponding to the second MPT nodes.

[0084] As an example, the flow chart of the consensus node reading the data corresponding to multiple second MPT nodes in parallel according to the key names corresponding to multiple first MPT nodes can be as follows: Figure 4 shown.

[0085] To determine whether the first MPT branch is the same as the second MPT branch, in some embodiments, the first MPT node may include a first MPT root node, and the second MPT node may include a second MPT root node. Based on this, the above S140 may specifically include:

[0086] Obtaining a first MPT root node in the first MPT branch and a second MPT root node in the second MPT branch;

[0087] Determining whether the first MPT root node and the second MPT root node are the same;

[0088] In the case that the first MPT root node is the same as the second MPT root node, data corresponding to the plurality of second MPT nodes are read in parallel according to the key names corresponding to the plurality of first MPT nodes.

[0089] Here, if the key name of the first MPT root node is the same as the key name of the second MPT root node, that is, the hash value of the first MPT root node is the same as the hash value of the second MPT root node, then the first MPT root node and the second MPT root node can be determined to be the same. Thus, based on the characteristics of the hash values ​​and the parent-child relationship of the multiple second MPT nodes, if the first MPT root node and the second MPT root node are the same, then the multiple first MPT nodes and the multiple second MPT nodes can be determined to be the same, that is, the first MPT branch and the second MPT branch are the same.

[0090] In this way, by determining whether the first MPT root node is the same as the second MPT root node, it is possible to determine whether the first MPT branch is the same as the second MPT branch.

[0091] Based on this, in order to read data corresponding to part of the second MPT node in parallel when the first MPT branch and the second MPT branch are not completely the same, thereby improving reading efficiency, in some embodiments, the following may also be included:

[0092] If the first MPT root node is different from the second MPT root node, read data corresponding to the second MPT root node;

[0093] Obtain a first MPT child node of the first MPT root node and a second MPT child node of the second MPT root node;

[0094] determining whether the first MPT child node is the same as the second MPT child node;

[0095] In the case that the first MPT child node is the same as the second MPT child node, data corresponding to multiple target second MPT nodes are read in parallel according to the key names corresponding to the multiple first MPT nodes. The target second MPT node is a second MPT node other than the second MPT root node.

[0096] Here, because the first MPT root node is different from the second MPT root node, the data corresponding to the second MPT root node cannot be read using the key name corresponding to the first MPT root node. Therefore, the data corresponding to the second MPT root node can be read separately. If the first MPT child node and the second MPT child node are the same, the data corresponding to the remaining second MPT nodes can be read in parallel using the key names corresponding to multiple first MPT nodes.

[0097] As an example, if the first MPT node changes, the entire MPT may change. Figure 5 As shown, since the first MPT node D becomes the second MPT node D', the first MPT root node ABCDEFGH can become the second MPT root node ABCD'EFGH. According to the characteristics of MPT, most of the nodes in the two MPT trees before and after the change are still the same.

[0098] Based on this, Figure 3 Take the MPT branch in as an example, that is, the consensus node attempts to read the data corresponding to the MPT node F. Since the first MPT node D becomes the second MPT node D', the multiple second MPT nodes can be ABCD'EFGH, EFGH, EF and F, that is, except for ABCDEFGH and ABCD'EFGH, the other MPT nodes are the same. In this way, the flow chart of the consensus node reading the key names corresponding to multiple second MPT nodes can be as follows Figure 6That is, after the consensus node obtains the key value of the child MPT node from the ABCD'EFGH node, it finds that the key value of the MPT node is included in the first MPT read record. Therefore, it can read the data corresponding to the remaining second MPT nodes in parallel.

[0099] In this way, by reading the data corresponding to multiple target second MPT nodes in parallel according to the key names corresponding to multiple first MPT nodes when the first MPT sub-node and the second MPT sub-node are the same, it is possible to read the data corresponding to some second MPT nodes in parallel when the first MPT branch and the second MPT branch are not exactly the same, thereby improving the reading efficiency.

[0100] Based on this, in order to improve the data reading efficiency, in some embodiments, the following may also be included:

[0101] In the case that the first MPT child node is different from the second MPT child node, the process returns to read the data corresponding to the second MPT child node until the data corresponding to the plurality of second MPT nodes are all read.

[0102] Here, the implementation process of the above steps is the same as above and will not be repeated here.

[0103] In addition, Figure 5 For example, if a consensus node attempts to read data corresponding to MPT node D, since the first MPT node D becomes the second MPT node D', the multiple second MPT nodes can be ABCD'EFGH, ABCD', CD', and D'. This means that the second MPT nodes are all different from the first MPT node. This allows serial reading of multiple second MPT nodes.

[0104] In this way, by reading the data corresponding to the same part of the MPT nodes in parallel when some MPT nodes in the first MPT branch and the second MPT are the same, and serially reading the data corresponding to the MPT nodes when the MPT nodes in the first MPT branch and the second MPT are different, the data reading efficiency can be improved.

[0105] It should be noted that the data corresponding to the MPT nodes mentioned above can all be read from the database.

[0106] Based on this, in order to further improve the data reading efficiency, in some embodiments, the above S140 may further include:

[0107] In the case that the first MPT branch is the same as the second MPT branch, data corresponding to the plurality of second MPT nodes are read in parallel from the first MPT read record according to the key names corresponding to the plurality of first MPT nodes.

[0108] Here, the first MPT read record can also record data corresponding to multiple first MPT nodes. Since the tree nodes in an MPT branch can all be connected through hashing, due to the characteristics of the hash function, it is extremely difficult to forge an MPT branch, almost impossible. Therefore, in general, after verifying that the MPT branch is correct, the consensus node can directly trust the MPT branch.

[0109] In this way, when the first MPT branch is the same as the second MPT branch, data corresponding to multiple second MPT nodes can be read in parallel from the first MPT read record, thereby further improving data reading efficiency.

[0110] Based on this, in order to further improve the overall performance of the blockchain, in some embodiments, the following may also be included:

[0111] Recording key names of multiple second MPT nodes to obtain second MPT reading records;

[0112] Broadcast the second MPT read record to the remaining blockchain nodes so that the remaining blockchain nodes can read the data corresponding to multiple second MPT nodes in parallel based on the second MPT read record.

[0113] Here, when executing a smart contract, a consensus node can record the key names of multiple second MPT nodes, obtain a second MPT read record, and broadcast the second MPT read record along with the block to other blockchain nodes. After receiving the block and the second MPT read record, the other blockchain nodes can execute the transactions in the block based on the second MPT read record and update their local database.

[0114] In this way, by broadcasting the second MPT reading record to the remaining blockchain nodes, the remaining blockchain nodes can read the data corresponding to multiple second MPT nodes in parallel based on the second MPT reading record, further improving the overall performance of the blockchain.

[0115] The following is an introduction to the smart contract processing method applied to the pre-execution node provided in the embodiment of the present application.

[0116] Figure 7 The following is a flow chart showing a method for processing smart contracts in a pre-execution node according to an embodiment of the present application. Figure 7 As shown, the smart contract processing method applied to the pre-execution node provided in the embodiment of the present application includes the following steps:

[0117] S710. Upon receiving the target transaction information, determine a target smart contract based on the target transaction information.

[0118] S720: Determine a first MPT branch corresponding to the target transaction information from the Merkle Patricia tree (MPT) corresponding to the target smart contract, where the first MPT branch includes a plurality of first MPT nodes having a parent-child relationship, and the first MPT nodes include a first MPT root node.

[0119] S730: Based on the parent-child relationship, starting from the first MPT root node, sequentially read the key names corresponding to the plurality of first MPT nodes according to a target reading direction, where the target reading direction includes a reading direction from the MPT parent node to the MPT child node;

[0120] S740. Record key names corresponding to multiple first MPT nodes to obtain a first MPT read record.

[0121] S750: Send the first MPT read record and the target transaction information to the consensus node, so that the consensus node reads data corresponding to multiple first MPT nodes in parallel based on the first MPT read record and the target transaction information.

[0122] Here, upon receiving the target transaction information, the data key name can also be determined based on the target transaction information. Based on this, the first MPT branch corresponding to the target transaction information can be determined from the MPT corresponding to the target smart contract based on the data key name. Furthermore, while sequentially reading the key names corresponding to multiple first MPT nodes according to the target read direction, the data corresponding to multiple first MPT nodes can also be read accordingly. Thus, the first MPT read record can specifically include the smart contract address, the data key name, and the first MPT branch. The first MPT branch can include the key names and data corresponding to multiple first MPT nodes.

[0123] In addition, if the pre-execution node receives multiple target transaction information, there may be multiple first MPT read records. These multiple target transaction information and multiple first MPT read records may be sent to the consensus node as pre-execution results. It should be noted that one target transaction information may correspond to multiple first MPT read records.

[0124] In addition, the above steps of the method in the embodiment of the present application can be referred to the relevant description of the embodiment shown above, and will not be elaborated here.

[0125] Thus, the pre-execution node pre-executes the target smart contract, records the key names corresponding to multiple first MPT nodes, obtains a first MPT read record, and sends the first MPT read record to the consensus node, so that the consensus node can determine the key names corresponding to multiple first MPT nodes based on the first MPT read record, and then read the data corresponding to the multiple first MPT nodes in parallel. In this way, according to the embodiment of the present application, the efficiency of the consensus node in reading the data corresponding to multiple first MPT nodes can be improved, that is, the execution speed of the target smart contract can be increased, and the overall performance of the blockchain can be improved.

[0126] Based on the smart contract processing methods provided in the above embodiments, this application also provides specific implementations of smart contract processing devices. Please refer to the following embodiments.

[0127] like Figure 8 As shown, the smart contract processing device 800 applied to the consensus node provided in the embodiment of the present application includes the following modules:

[0128] a receiving module 810 configured to receive target transaction information and a first Merkle Patricia Tree (MPT) read record sent by a pre-execution node, wherein the first MPT read record is a record of key names corresponding to multiple first MPT nodes in a first MPT branch read by the pre-execution node based on the target transaction information, wherein the first MPT branch is the MPT branch corresponding to the target transaction information;

[0129] A first determination module 820 is configured to determine a target smart contract based on target transaction information;

[0130] A second determining module 830 is configured to determine a second MPT branch corresponding to the target transaction information from the MPT corresponding to the target smart contract, where the second MPT branch includes a plurality of second MPT nodes having a parent-child relationship;

[0131] The first reading module 840 is configured to read data corresponding to multiple second MPT nodes in parallel according to key names corresponding to multiple first MPT nodes when the first MPT branch is the same as the second MPT branch.

[0132] The smart contract processing device 800 is described in detail below.

[0133] In some of these embodiments, the first MPT node may include a first MPT root node, and the second MPT node may include a second MPT root node;

[0134] Based on this, the first reading module 840 may specifically include:

[0135] A first acquisition submodule is configured to acquire a first MPT root node in a first MPT branch and a second MPT root node in a second MPT branch;

[0136] A first determining submodule, configured to determine whether the first MPT root node is the same as the second MPT root node;

[0137] The first reading submodule is configured to read data corresponding to multiple second MPT nodes in parallel according to key names corresponding to multiple first MPT nodes when the first MPT root node is the same as the second MPT root node.

[0138] In some embodiments, the first reading module 840 may further include:

[0139] A second reading submodule is configured to read data corresponding to the second MPT root node when the first MPT root node is different from the second MPT root node;

[0140] A second acquisition submodule, configured to acquire a first MPT child node of a first MPT root node and a second MPT child node of a second MPT root node;

[0141] a second determining submodule, configured to determine whether the first MPT child node is the same as the second MPT child node;

[0142] The third reading submodule is used to read data corresponding to multiple target second MPT nodes in parallel according to the key names corresponding to the multiple first MPT nodes when the first MPT child node is the same as the second MPT child node. The target second MPT node is a second MPT node other than the second MPT root node.

[0143] In some embodiments, the first reading module 840 may further include:

[0144] The return execution submodule is used to return to execute reading of data corresponding to the second MPT subnode when the first MPT subnode is different from the second MPT subnode, until the data corresponding to the plurality of second MPT nodes are all read.

[0145] In some embodiments, the first reading module 840 may further include:

[0146] The fourth reading submodule is configured to read data corresponding to multiple second MPT nodes in parallel from the first MPT read record according to key names corresponding to multiple first MPT nodes when the first MPT branch is the same as the second MPT branch.

[0147] In some embodiments, the smart contract processing device 800 may further include:

[0148] A second recording module is used to record key names of multiple second MPT nodes to obtain a second MPT reading record;

[0149] The broadcast module is used to broadcast the second MPT read record to the remaining blockchain nodes, so that the remaining blockchain nodes can read the data corresponding to multiple second MPT nodes in parallel based on the second MPT read record.

[0150] The smart contract processing device of the embodiment of the present application receives a first MPT read record including key names corresponding to multiple first MPT nodes. When the first MPT branch is the same as the second MPT branch (i.e., the multiple first MPT nodes are the same as the multiple second MPT nodes), the device can concurrently read data corresponding to multiple second MPT nodes based on the key names corresponding to the multiple first MPT nodes. Thus, according to the embodiment of the present application, the efficiency of reading data corresponding to multiple second MPT nodes can be improved, that is, the execution speed of the smart contract can be increased, thereby improving the overall performance of the blockchain.

[0151] like Figure 9 As shown, the smart contract processing device 900 applied to the pre-execution node provided in the embodiment of the present application includes the following modules:

[0152] A third determination module 910 is configured to determine a target smart contract based on the target transaction information when the target transaction information is received;

[0153] a fourth determining module 920, configured to determine, from the Merkle Patricia tree MPT corresponding to the target smart contract, a first MPT branch corresponding to the target transaction information, the first MPT branch including a plurality of first MPT nodes having a parent-child relationship, the first MPT nodes including a first MPT root node;

[0154] A second reading module 930 is configured to read key names corresponding to multiple first MPT nodes in sequence according to a target reading direction, starting from the first MPT root node based on the parent-child relationship. The target reading direction includes a reading direction from the MPT parent node to the MPT child node.

[0155] A first recording module 940 is configured to record key names corresponding to a plurality of first MPT nodes to obtain a first MPT reading record;

[0156] The sending module 950 is used to send the first MPT reading record and the target transaction information to the consensus node, so that the consensus node reads the data corresponding to the plurality of the first MPT nodes in parallel based on the first MPT reading record and the target transaction information.

[0157] The smart contract processing device of the embodiment of the present application pre-executes the target smart contract, records the key names corresponding to multiple first MPT nodes, obtains a first MPT read record, and sends the first MPT read record to the consensus node, so that the consensus node can determine the key names corresponding to the multiple first MPT nodes based on the first MPT read record, and then read the data corresponding to the multiple first MPT nodes in parallel. In this way, according to the embodiment of the present application, the efficiency of the consensus node in reading the data corresponding to the multiple first MPT nodes can be improved, that is, the execution speed of the target smart contract can be increased, and the overall performance of the blockchain can be improved.

[0158] Based on the smart contract processing method provided in the above embodiment, the embodiment of the present application also provides a specific implementation of the electronic device. Figure 10 A schematic diagram of an electronic device 1000 provided in an embodiment of the present application is shown.

[0159] The electronic device 1000 may include a processor 1010 and a memory 1020 storing computer program instructions.

[0160] Specifically, the processor 1010 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0161] The memory 1020 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 1020 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 1020 may include removable or non-removable (or fixed) media. Where appropriate, the memory 1020 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 1020 is a non-volatile solid-state memory.

[0162] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present application.

[0163] The processor 1010 implements any one of the smart contract processing methods in the above embodiments by reading and executing computer program instructions stored in the memory 1020.

[0164] In one example, the electronic device 1000 may further include a communication interface 1030 and a bus 1040. Figure 10 As shown, the processor 1010, the memory 1020, and the communication interface 1030 are connected via a bus 1040 and communicate with each other.

[0165] The communication interface 1030 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0166] Bus 1040 includes hardware, software or both, couples the parts of electronic equipment to each other.For example, and not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 1040 may include one or more buses. Although the present application embodiment describes and shows specific bus, the application considers any suitable bus or interconnection.

[0167] Illustratively, the electronic device 1000 may be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, an ultra-mobile personal computer (UMPC), a netbook, or a personal digital assistant (PDA).

[0168] The electronic device can execute the smart contract processing method in the embodiment of the present application, thereby realizing the combination Figure 1 、 Figures 7 to 9 Described smart contract processing method and device.

[0169] In addition, in conjunction with the smart contract processing methods in the above embodiments, embodiments of the present application may provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any of the smart contract processing methods in the above embodiments is implemented.

[0170] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0171] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0172] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0173] Aspects of the present application have been described above with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed via the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. This processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It is also understood that each box in the block diagram and / or the flowchart and the combination of the boxes in the block diagram and / or the flowchart can also be implemented by the dedicated hardware that performs the specified function or action, or can be implemented by the combination of dedicated hardware and computer instructions.

[0174] The above description is only a specific embodiment of the present application. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A smart contract processing method, applied to a consensus node, characterized in that: include: Receive target transaction information and a first Merkle-Patricia tree (MPT) read record sent by a pre-execution node, where the first Merkle-Patricia tree (MPT) read record is a record of key names corresponding to multiple first Merkle-Patricia tree (MPT) nodes in a first Merkle-Patricia tree (MPT) branch read by the pre-execution node based on the target transaction information, wherein the first Merkle-Patricia tree (MPT) branch is a Merkle-Patricia tree (MPT) branch corresponding to the target transaction information; Determining a target smart contract based on the target transaction information; Determining, from the Merkle Patricia tree MPT corresponding to the target smart contract, a second Merkle Patricia tree MPT branch corresponding to the target transaction information, where the second Merkle Patricia tree MPT branch includes a plurality of second Merkle Patricia tree MPT nodes having a parent-child relationship; When the first Merkle Patricia tree MPT branch is the same as the second Merkle Patricia tree MPT branch, data corresponding to multiple second Merkle Patricia tree MPT nodes are read in parallel according to key names corresponding to multiple first Merkle Patricia tree MPT nodes.

2. The method according to claim 1, characterized in that The first Merkle Patricia tree MPT node includes a first Merkle Patricia tree MPT root node, and the second Merkle Patricia tree MPT node includes a second Merkle Patricia tree MPT root node; The method of reading data corresponding to multiple second Merkle Patricia tree MPT nodes in parallel according to key names corresponding to multiple first Merkle Patricia tree MPT nodes when the first Merkle Patricia tree MPT branch is the same as the second Merkle Patricia tree MPT branch includes: Obtain a first Merkle-Patricia tree (MPT) root node in the first Merkle-Patricia tree (MPT) branch and a second Merkle-Patricia tree (MPT) root node in the second Merkle-Patricia tree (MPT) branch; Determining whether the first Merkle Patricia tree (MPT) root node is the same as the second Merkle Patricia tree (MPT) root node; When the first Merkle Patricia tree MPT root node is the same as the second Merkle Patricia tree MPT root node, data corresponding to multiple second Merkle Patricia tree MPT nodes are read in parallel according to key names corresponding to multiple first Merkle Patricia tree MPT nodes.

3. The method according to claim 2, characterized in that The method further comprises: When the first Merkle-Patricia tree MPT root node is different from the second Merkle-Patricia tree MPT root node, reading data corresponding to the second Merkle-Patricia tree MPT root node; Obtain a first Merkle-Patricia tree (MPT) child node of the first Merkle-Patricia tree (MPT) root node and a second Merkle-Patricia tree (MPT) child node of the second Merkle-Patricia tree (MPT) root node; Determining whether the first Merkle Patricia tree MPT child node is the same as the second Merkle Patricia tree MPT child node; When the first Merkle-Patricia tree MPT child node is the same as the second Merkle-Patricia tree MPT child node, data corresponding to multiple target second Merkle-Patricia tree MPT nodes are read in parallel according to the key names corresponding to multiple first Merkle-Patricia tree MPT nodes, and the target second Merkle-Patricia tree MPT nodes are the second Merkle-Patricia tree MPT nodes except the second Merkle-Patricia tree MPT root node.

4. The method according to claim 3, characterized in that The method further comprises: If the first Merkle Patricia tree MPT child node is different from the second Merkle Patricia tree MPT child node, return to executing reading data corresponding to the second Merkle Patricia tree MPT child node until data corresponding to multiple second Merkle Patricia tree MPT nodes are all read.

5. A smart contract processing method, applied to a pre-execution node, characterized in that: include: Upon receiving the target transaction information, determining a target smart contract based on the target transaction information; Determining, from the Merkle Patricia tree MPT corresponding to the target smart contract, a first Merkle Patricia tree MPT branch corresponding to the target transaction information, wherein the first Merkle Patricia tree MPT branch includes a plurality of first Merkle Patricia tree MPT nodes having a parent-child relationship, and the first Merkle Patricia tree MPT nodes include a first Merkle Patricia tree MPT root node; Based on the parent-child relationship, starting from the first Merkle Patricia tree MPT root node, sequentially reading key names corresponding to multiple first Merkle Patricia tree MPT nodes according to a target reading direction, wherein the target reading direction includes a reading direction from the Merkle Patricia tree MPT parent node to the Merkle Patricia tree MPT child node; Recording key names corresponding to a plurality of the first Merkle Patricia tree MPT nodes to obtain a first Merkle Patricia tree MPT reading record; The first Merkle Patricia tree MPT read record and the target transaction information are sent to a consensus node, so that the consensus node reads data corresponding to multiple first Merkle Patricia tree MPT nodes in parallel based on the first Merkle Patricia tree MPT read record and the target transaction information.

6. A smart contract processing device, applied to a consensus node, characterized in that: The device comprises: a receiving module, configured to receive target transaction information and a first Merkle-Patricia tree (MPT) read record sent by a pre-execution node, where the first Merkle-Patricia tree (MPT) read record is a record of key names corresponding to multiple first Merkle-Patricia tree (MPT) nodes in a first Merkle-Patricia tree (MPT) branch read by the pre-execution node based on the target transaction information, wherein the first Merkle-Patricia tree (MPT) branch is a Merkle-Patricia tree (MPT) branch corresponding to the target transaction information; A first determination module, configured to determine a target smart contract based on the target transaction information; A second determining module is configured to determine, from the Merkle Patricia tree MPT corresponding to the target smart contract, a second Merkle Patricia tree MPT branch corresponding to the target transaction information, wherein the second Merkle Patricia tree MPT branch includes a plurality of second Merkle Patricia tree MPT nodes having a parent-child relationship; The first reading module is used to read data corresponding to multiple second Merkle Patricia tree MPT nodes in parallel according to key names corresponding to multiple first Merkle Patricia tree MPT nodes when the first Merkle Patricia tree MPT branch is the same as the second Merkle Patricia tree MPT branch.

7. A smart contract processing device, applied to a pre-execution node, characterized in that: The device comprises: A third determination module is configured to, upon receiving the target transaction information, determine a target smart contract based on the target transaction information; a fourth determining module, configured to determine, from the Merkle-Patricia tree MPT corresponding to the target smart contract, a first Merkle-Patricia tree MPT branch corresponding to the target transaction information, wherein the first Merkle-Patricia tree MPT branch includes a plurality of first Merkle-Patricia tree MPT nodes having a parent-child relationship, and the first Merkle-Patricia tree MPT nodes include a first Merkle-Patricia tree MPT root node; a second reading module, configured to read, based on the parent-child relationship and starting from the first Merkle Patricia tree MPT root node, key names corresponding to the plurality of first Merkle Patricia tree MPT nodes in sequence according to a target reading direction, wherein the target reading direction includes a reading direction from the Merkle Patricia tree MPT parent node to the Merkle Patricia tree MPT child node; A first recording module is configured to record key names corresponding to a plurality of the first Merkle Patricia tree MPT nodes, and obtain a first Merkle Patricia tree MPT reading record; A sending module is used to send the first Merkle Patricia tree MPT reading record and the target transaction information to a consensus node, so that the consensus node reads data corresponding to multiple first Merkle Patricia tree MPT nodes in parallel based on the first Merkle Patricia tree MPT reading record and the target transaction information.

8. An electronic device, characterized in that: The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the smart contract processing method according to any one of claims 1 to 4 or 5.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the smart contract processing method according to any one of claims 1 to 4 or 5.

10. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the smart contract processing method as described in any one of claims 1-4 or 5.

Images