Blockchain-based smart contract asynchronous execution method, system, device and medium

Abstract

The application discloses a kind of blockchain-based smart contract asynchronous execution method, system, equipment and medium, mainly related to smart contract asynchronous execution technical field, to solve the problem of slow efficiency of existing smart contract execution. It includes: generating Pre-Prepare message, sending to all nodes;When any node receives external Pre-Prepare message, the legality verification and correctness verification of external Pre-Prepare message are carried out, to be cached to local after the verification result is legal and correct, and Prepare message is sent to all nodes;When any node receives external Prepare message, the legality verification of external Prepare message is carried out, to obtain the verification result after verification is legal, to send Commit message to all nodes after the verification result meets preset rule;After any node is verified legal and correct, the Pre-Prepare message corresponding to external Prepare message in local cache is read, and the block data in the corresponding Pre-Prepare message is put into the waiting execution queue.

Description

Technical Field

[0001] This application relates to the field of asynchronous execution technology of smart contracts, and in particular to a method, system, device and medium for asynchronous execution of smart contracts based on blockchain. Background Technology

[0002] Optimizing energy market management within the regional energy internet to maximize the revenue from energy transactions and related services is a core issue for the blockchain industry. However, due to issues such as supply-demand imbalances, constraints from physical operating conditions, and cybersecurity limitations, traditional centralized power management models are increasingly unable to meet the data security requirements of today's regional energy internet.

[0003] Emerging blockchain technology offers enhanced security for power and energy systems. In a blockchain environment, identities are not directly linked to the identities of specific consumers / producers, reducing vulnerability to malicious attacks and making power and energy blockchain systems more resilient. Smart contract technology in blockchain makes transactions more scalable; energy trading between parties becomes more flexible through customized smart contracts, making the security and execution efficiency of smart contracts particularly important.

[0004] Energy service data is characterized by its large volume, especially energy consumption data, which often experiences surges at a single point in time. This is particularly true in energy trading scenarios, where millions of users transact energy through smart contracts. Existing blockchain systems are highly coupled with consensus mechanisms when processing smart contract requests. When a large number of new smart contract requests are added at any given time, the efficiency of consensus mechanisms can lead to a backlog of contract request executions, resulting in slow execution speeds. Summary of the Invention

[0005] In view of the above-mentioned shortcomings of the prior art, the present invention provides a method, system, device and medium for asynchronous execution of smart contracts based on blockchain to solve the above-mentioned technical problems.

[0006] Firstly, this application provides a blockchain-based asynchronous execution method for smart contracts. The method includes: obtaining block data through a master node to generate a Pre-Prepare message and sending the Pre-Prepare message to all nodes; when any node receives an external Pre-Prepare message, performing legality and correctness verification on the external Pre-Prepare message, caching it locally after the verification result is legal and correct, and sending a Prepare message containing the verification result to all nodes; when any node receives an external Prepare message, performing legality verification on the external Prepare message, obtaining the verification result in the external Prepare message after the verification result meets preset rules, and sending a Commit message to all nodes; after any node verifies legality and correctness, reading the Pre-Prepare message corresponding to the external Prepare message from the local cache, and placing the block data in the corresponding Pre-Prepare message into a waiting execution queue.

[0007] Furthermore, obtaining block data through the master node to generate a Pre-Prepare message specifically includes: when the master node receives request parameters corresponding to a contract transaction, checking if a corresponding verification cache has been generated in the verification cache pool; if a verification cache has been generated, determining that the request parameters and the verification cache are block data to generate a Pre-Prepare message; if no verification cache has been generated, determining that the request parameters are block data to generate a Pre-Prepare message; wherein, the request parameters include the block number, and the verification cache in the verification cache pool includes the block number, read set hash, write set hash, read set, write set, and result set; when the master node does not receive request parameters corresponding to a contract transaction within a preset time period, checking if a new verification cache has been generated in the verification cache pool; if a new verification cache has been generated, determining that the new verification cache is block data to generate a Pre-Prepare message.

[0008] Furthermore, the external Pre-Prepare message is validated for both legality and correctness. If the validation results are valid and correct, the message is cached locally. Specifically, this includes: obtaining the signature from the external Pre-Prepare message; if the signature is correct, the external Pre-Prepare message is considered valid; obtaining the verification cache of the block data from the external Pre-Prepare message; retrieving the corresponding local verification cache from the local verification cache pool based on the block number in the block data; comparing the verification cache of the block data with the local verification cache; if they match, the external Pre-Prepare message is considered correct.

[0009] Furthermore, after verifying the legality and correctness of the external Pre-Prepare message, the method also includes: obtaining the verification cache of the block data in the external Pre-Prepare message; retrieving the corresponding local verification cache from the local verification cache pool based on the block number in the block data; comparing whether the verification cache of the block data is consistent with the local verification cache; if inconsistent, determining the existence of a malicious node; sending a prepare message with a verification failure result; pre-setting a maximum of f errors allowed; receiving external prepare messages; determining the number F of prepare messages with verification failure results and the number H of prepare messages with verification success results; when H is greater than or equal to 2f+1, determining that the node corresponding to the prepare message with verification failure result is a malicious node, and the node corresponding to the prepare message with verification success result is an honest node; when H is less than 2f+1 and the master node's verification result is a prepare message with verification failure result, determining that the block data obtained by the master node is erroneous data, triggering a view switch, setting the next node as the master node, and re-obtaining the block data.

[0010] Furthermore, the validity of the external Prepare message is verified, specifically by obtaining the signature in the external Prepare message, and determining the external Prepare message to be valid when the signature is correct.

[0011] Furthermore, the verification results in the external Prepare message are obtained so that a Commit message is sent to all nodes after the verification results meet the preset rules. Specifically, this includes: obtaining the verification results in the external Prepare message through any node; determining the number of prepare messages with verification failure F and the number of prepare messages with verification success H; when H is greater than or equal to 2f+1, determining that the verification results meet the preset rules and sending a Commit message to all nodes.

[0012] Furthermore, the block data in the corresponding Pre-Prepare message is placed into the waiting execution queue. Specifically, this includes: obtaining the block number from the block data; if the block number is greater than the preset sorting number, caching the block number in the block data first; placing the block data into the cache queue in the order of the block number within the preset sorting time period to wait for execution; and after the block data is executed, placing the read set, write set, and result set generated during the execution process into the verification cache pool.

[0013] Secondly, this application provides a blockchain-based asynchronous smart contract execution system, comprising: a sending module, used to obtain block data through a master node to generate a Pre-Prepare message and send the Pre-Prepare message to all nodes; when any node receives an external Pre-Prepare message, it performs legality and correctness verification on the external Pre-Prepare message, caches the message locally after the verification result is legal and correct, and sends a Prepare message containing the verification result to all nodes; when any node receives an external Prepare message, it performs legality verification on the external Prepare message, obtains the verification result in the external Prepare message after the verification is legal, and sends a Commit message to all nodes after the verification result meets preset rules; and an placing module, used to read the Pre-Prepare message corresponding to the external Prepare message from the local cache after any node verifies that the message is legal and correct, and place the block data in the corresponding Pre-Prepare message into a waiting execution queue.

[0014] Thirdly, this application provides a blockchain-based asynchronous smart contract execution device, the device including: a processor; and a memory storing executable code thereon, wherein when the executable code is executed, the processor executes any of the above-mentioned asynchronous smart contract execution methods.

[0015] Fourthly, this application provides a non-volatile computer storage medium storing computer instructions, which, when executed, implement an asynchronous execution method for a blockchain-based smart contract as described above.

[0016] Those skilled in the art will understand that the present invention has at least the following beneficial effects:

[0017] This application proposes a method for separating contracts (request parameters corresponding to contract transactions) and consensus. Contract execution no longer depends on the consensus process, which can improve the execution efficiency of contracts and decouple them from the consensus module. At the same time, consensus no longer depends on the execution result of contracts, which can also improve the execution efficiency of consensus.

[0018] Asynchronous contract verification (multi-node verification of external Pre-Prepare messages and external Prepare messages) can ensure the consistency of contract execution results. Even if there are faulty nodes, the erroneous data can be synchronized to the correct data through asynchronous verification, ensuring the consistency of data across all nodes. Attached Figure Description

[0019] The following description refers to some embodiments of this disclosure, in which:

[0020] Figure 1 This is a flowchart of an asynchronous execution method for a blockchain-based smart contract, provided in an embodiment of this application.

[0021] Figure 2 This is a schematic diagram of the internal structure of a blockchain-based asynchronous smart contract execution system provided in an embodiment of this application.

[0022] Figure 3 This is a schematic diagram of the internal structure of a blockchain-based asynchronous smart contract execution device, provided as an embodiment of this application. Detailed Implementation

[0023] Those skilled in the art should understand that the embodiments described below are merely preferred embodiments of this disclosure and do not imply that this disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely used to explain the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure. Based on the preferred embodiments provided by this disclosure, all other embodiments obtained by those skilled in the art without inventive effort should still fall within the scope of protection of this disclosure.

[0024] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0025] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] This application provides a blockchain-based method for asynchronous execution of smart contracts, such as... Figure 1 As shown in the embodiments of this application, the method mainly includes the following steps:

[0027] Step 110: Obtain block data through the master node to generate a Pre-Prepare message, and send the Pre-Prepare message to all nodes.

[0028] It should be noted that block data can be the request parameters corresponding to the contract transaction received by the master node and / or newly added verification cache in the verification cache pool. The verification cache pool is a database. Pre-Prepare messages are messages sent by the master node to each slave node during the pre-prepare phase, and these messages include block data and signatures. Furthermore, the Pre-Prepare messages, Prepare messages, and Commit messages used in this application are all messages defined in existing blockchain consensus processes, and this application does not impose further limitations on them.

[0029] Specifically, obtaining block data through the master node to generate a Pre-Prepare message can be achieved as follows: When the master node receives request parameters corresponding to a contract transaction, it checks if a corresponding verification cache has been generated in the verification cache pool. If a verification cache has been generated, the request parameters and the verification cache are determined to be block data to generate a Pre-Prepare message. If no verification cache has been generated, the request parameters are determined to be block data to generate a Pre-Prepare message. The request parameters include the block number, and the verification cache in the verification cache pool includes the block number, read set hash, write set hash, read set, write set, and result set. If the master node does not receive request parameters corresponding to a contract transaction within a preset time period, it checks if a new verification cache has been generated in the verification cache pool. If a new verification cache has been generated, it is determined to be block data to generate a Pre-Prepare message.

[0030] Step 120: When any node receives an external Pre-Prepare message, it performs legality and correctness verification on the external Pre-Prepare message. If the verification result is legal and correct, it is cached locally and a Prepare message containing the verification result is sent to all nodes.

[0031] Specifically, the external Pre-Prepare message undergoes validity and correctness verification. If the verification result is valid and correct, it is cached locally. This can be achieved by: obtaining the signature from the external Pre-Prepare message; if the signature is correct, the external Pre-Prepare message is considered valid; obtaining the verification cache of the block data in the external Pre-Prepare message; retrieving the corresponding local verification cache from the local verification cache pool based on the block number in the block data; comparing the verification cache of the block data with the local verification cache; if they match, the external Pre-Prepare message is considered correct.

[0032] Furthermore, even if a malicious node exists in the blockchain, all nodes in this application will still receive the correct block data when an erroneous node is present. In this case, the erroneous node will also synchronize the correct block data, thus synchronizing the erroneous data to the correct data. Specifically, after verifying the legality and correctness of the external Pre-Prepare message, the method further includes:

[0033] The system retrieves the verification cache of block data from external Pre-Prepare messages. Based on the block number in the block data, it retrieves the corresponding local verification cache from the local verification cache pool and compares it with the local verification cache. If they are inconsistent, a malicious node is identified. A prepare message indicating verification failure is sent. A maximum of f errors are allowed. The system receives external prepare messages and determines the number of prepare messages with verification failure (F) and the number of prepare messages with verification success (H). When H is greater than or equal to 2f+1, the node corresponding to the prepare message with verification failure is identified as a malicious node, and the node corresponding to the prepare message with verification success is identified as an honest node. When H is less than 2f+1 and the master node's verification result is a prepare message with verification failure, the block data obtained by the master node is identified as erroneous data. A view switch is triggered, and the next node is set as the master node to obtain block data again.

[0034] It's important to note that the data in the verification cache of the verified block must be consistent with the data in the local verification cache. If they are inconsistent, a prepare message indicating verification failure is sent. Taking the PBFT algorithm as an example, if a maximum of f errors are allowed, at least 2f+1 successful verification messages must be received to prove that the node sending the verification failure message has made an error (H is greater than or equal to 2f+1). Furthermore, in this application, each node must ensure that it has received at least 2f+1 correct messages before sending a commit message; nodes that have made errors will not send commit messages. Therefore, even if there are F erroneous nodes, the entire consensus process can still proceed normally, ensuring that all nodes receive the correct block data. All nodes must synchronize the write set in their verification cache, and at this time, erroneous nodes will also synchronize the correct write set.

[0035] If the master node's data is incorrect, meaning the packaged block data is faulty, and the master node's execution result is incorrect, then the generated block will also contain incorrect block data. In this case, upon receiving the pre-prepare message, all slave nodes send a verification failure prepare message; since all nodes receive verification failure prepare messages (H less than 2f+1), they cannot enter the commit phase, triggering a view switch, setting the next node as the master node, and regenerating the block data.

[0036] Step 130: When any node receives an external Prepare message, it performs a validity verification on the external Prepare message. After the verification is valid, it obtains the verification result in the external Prepare message. If the verification result meets the preset rules, it sends a Commit message to all nodes.

[0037] Specifically, validating the external Prepare message can involve obtaining the signature from the external Prepare message and determining its validity if the signature is correct.

[0038] Specifically, obtaining the verification result from the external Prepare message and sending a Commit message to all nodes after the verification result meets the preset rules can be done as follows: obtaining the verification result from the external Prepare message through any node; determining the number of prepare messages with verification failure F and the number of prepare messages with verification success H; when H is greater than or equal to 2f+1, determining that the verification result meets the preset rules and sending a Commit message to all nodes.

[0039] Step 140: After verifying that the message is valid and correct at any node, read the Pre-Prepare message corresponding to the external Prepare message from the local cache and put the block data in the corresponding Pre-Prepare message into the waiting execution queue.

[0040] Specifically, the block data in the corresponding Pre-Prepare message is placed into the waiting execution queue. This can be done by: obtaining the block number from the block data; if the block number is greater than the preset sorting number, caching the block number in the block data first; placing the block data into the cache queue in the order of the block number within the preset sorting time period to wait for execution; and after the block data is executed, placing the read set, write set, and result set generated during the execution process into the verification cache pool.

[0041] besides, Figure 2 This application provides an embodiment of a blockchain-based asynchronous smart contract execution system. For example... Figure 2As shown in the embodiments of this application, the system mainly includes:

[0042] The sending module 210 is used to obtain block data through the master node to generate a Pre-Prepare message and send the Pre-Prepare message to all nodes. When any node receives an external Pre-Prepare message, it performs legality and correctness verification on the external Pre-Prepare message. If the verification result is legal and correct, it caches the message locally and sends a Prepare message containing the verification result to all nodes. When any node receives an external Prepare message, it performs legality verification on the external Prepare message. If the message is legal, it obtains the verification result from the external Prepare message and sends a Commit message to all nodes if the verification result meets the preset rules.

[0043] The module 220 is used to read the Pre-Prepare message corresponding to the external Prepare message from the local cache after verifying that the message is valid and correct at any node, and put the block data in the corresponding Pre-Prepare message into the waiting execution queue.

[0044] Furthermore, embodiments of this application also provide a device for asynchronous execution of blockchain-based smart contracts. For example... Figure 3 As shown, the device includes a processor and a memory storing executable code. When the executable code is executed, the processor performs an asynchronous execution method for blockchain-based smart contracts as described in the above embodiment. Specifically, the server obtains block data through the master node to generate a Pre-Prepare message and sends it to all nodes. When any node receives an external Pre-Prepare message, it performs legality and correctness verification on the message. If the verification result is legal and correct, the message is cached locally, and a Prepare message containing the verification result is sent to all nodes. After receiving the external Prepare message, the node performs legality verification on it. If the message is legal, the node obtains the verification result from the message and sends a Commit message to all nodes if the verification result meets preset rules. After any node verifies the message as legal and correct, it reads the Pre-Prepare message corresponding to the external Prepare message from its local cache and places the block data in the corresponding Pre-Prepare message into a waiting execution queue.

[0045] In addition, embodiments of this application also provide a non-volatile computer storage medium storing executable instructions, which, when executed, implement the asynchronous execution method for blockchain-based smart contracts as described above.

[0046] The technical solutions of this disclosure have been described in conjunction with the preceding embodiments. However, it will be readily understood by those skilled in the art that the scope of protection of this disclosure is not limited to these specific embodiments. Without departing from the technical principles of this disclosure, those skilled in the art can disassemble and combine the technical solutions in the above embodiments, and can also make equivalent changes or substitutions to the relevant technical features. Any changes, equivalent substitutions, improvements, etc., made within the technical concept and / or technical principles of this disclosure will fall within the scope of protection of this disclosure.

Claims

1. A method for asynchronous execution of smart contracts based on blockchain, characterized in that, The method includes: Obtaining block data from the master node to generate a Pre-Prepare message involves the following steps: When the master node receives request parameters corresponding to a contract transaction, it checks if a corresponding verification cache has been generated in the verification cache pool. If a verification cache has been generated, the request parameters and the verification cache are determined to be block data to generate a Pre-Prepare message. If no verification cache has been generated, the request parameters are determined to be block data to generate a Pre-Prepare message. The request parameters include the block number, and the verification cache in the verification cache pool includes the block number, read set hash, write set hash, read set, write set, and result set. When the master node does not receive request parameters corresponding to a contract transaction within a preset time period, it checks if a new verification cache has been generated in the verification cache pool. If a new verification cache has been generated, the new verification cache is determined to be block data to generate a Pre-Prepare message, and the Pre-Prepare message is sent to all nodes. When any node receives an external Pre-Prepare message, it performs validity and correctness verification on the external Pre-Prepare message. If the verification result is valid and correct, it caches the message locally and sends a Prepare message containing the verification result to all nodes. When any node receives an external Prepare message, it performs a validity verification on the external Prepare message. After the verification is valid, it obtains the verification result in the external Prepare message. If the verification result meets the preset rules, it sends a Commit message to all nodes. After any node verifies that the message is valid and correct, it reads the Pre-Prepare message corresponding to the external Prepare message from the local cache, and puts the block data in the corresponding Pre-Prepare message into the waiting execution queue, specifically including: Obtain the block number from the block data. If the block number is greater than the preset sort number, cache the block number in the block data first. Within the preset sorting time period, put the block data into the cache queue in the order of block number to wait for execution. After the block data is executed, put the read set, write set and result set generated during the execution into the verification cache pool.

2. The asynchronous execution method for blockchain-based smart contracts according to claim 1, characterized in that, Perform validity and correctness verification on external Pre-Prepare messages, and cache them locally only after the verification results are valid and correct. Specifically, this includes: Obtain the signature from the external Pre-Prepare message. If the signature is correct, determine that the external Pre-Prepare message is valid. Retrieve the verification cache of block data in the external Pre-Prepare message, and retrieve the corresponding local verification cache from the local verification cache pool based on the block number in the block data. Compare the verification cache of the block data with the local verification cache to see if they are consistent. If they are consistent, the external Pre-Prepare message is confirmed to be correct.

3. The asynchronous execution method for blockchain-based smart contracts according to claim 2, characterized in that, After validating the validity and correctness of the external Pre-Prepare message, the method further includes: Retrieve the verification cache of block data from the external Pre-Prepare message, retrieve the corresponding local verification cache from the local verification cache pool based on the block number in the block data, and compare whether the verification cache of the block data is consistent with the local verification cache. If they are inconsistent, it is determined that there is a malicious node; send a prepare message with the verification result of verification failure. The maximum number of errors is preset to be f. Receive external prepare messages and determine the number of prepare messages with verification failure result F and the number of prepare messages with verification success result H; When H is greater than or equal to 2f+1, the node corresponding to the prepare message whose verification result is verification failure is determined to be a malicious node, and the node corresponding to the prepare message whose verification result is verification success is an honest node. When H is less than 2f+1 and the master node's verification result is a verification failure prepare message, it is determined that the block data obtained by the master node is erroneous data, triggering a view switch, setting the next node as the master node, and obtaining block data again.

4. The asynchronous execution method for blockchain-based smart contracts according to claim 1, characterized in that, Performing validity verification on external Prepare messages specifically includes: Retrieve the signature from the external Prepare message. If the signature is correct, determine that the external Prepare message is valid.

5. The method for asynchronous execution of smart contracts based on blockchain according to claim 1, characterized in that, Retrieve the verification result from the external Prepare message, and send a Commit message to all nodes after the verification result meets the preset rules. Specifically, this includes: Retrieve the verification result from the external Prepare message through any node; Determine the number of prepare messages that fail verification (F) and the number of prepare messages that succeed verification (H); when H is greater than or equal to 2f+1, it is determined that the verification result meets the preset rules, and a Commit message is sent to all nodes.

6. A blockchain-based asynchronous smart contract execution system, characterized in that, The system includes: The sending module is used to obtain block data from the master node to generate a Pre-Prepare message. Specifically, it includes: when the master node receives request parameters corresponding to a contract transaction, checking if a corresponding verification cache has been generated in the verification cache pool; if a verification cache has been generated, determining that the request parameters and the verification cache are block data to generate a Pre-Prepare message; if no verification cache has been generated, determining that the request parameters are block data to generate a Pre-Prepare message; wherein, the request parameters include the block number, and the verification cache in the verification cache pool includes the block number, read set hash, write set hash, read set, write set, and result set; when the master node does not receive request parameters corresponding to a contract transaction within a preset time period, checking if a new verification cache has been generated in the verification cache pool. The process involves several steps: First, when a new verification cache is generated, it is identified as block data, and a Pre-Prepare message is generated. This message is then sent to all nodes. Second, when any node receives an external Pre-Prepare message, it performs validity and correctness verification on the message. If the verification result is valid and correct, the message is cached locally, and a Prepare message containing the verification result is sent to all nodes. Third, when any node receives an external Prepare message, it performs validity verification on the message. If the message is valid, the node retrieves the verification result from the message and sends a Commit message to all nodes if the verification result meets preset rules. The module is used to read the Pre-Prepare message corresponding to the external Prepare message from the local cache after any node has verified its validity and correctness, and put the block data in the corresponding Pre-Prepare message into the waiting execution queue. Specifically, it includes: obtaining the block number in the block data; if the block number is greater than the preset sorting number, caching the block number in the block data first; putting the block data into the cache queue in the order of block number within the preset sorting time period to wait for execution; and after the block data is executed, putting the read set, write set and result set generated during the execution into the verification cache pool.

7. A blockchain-based asynchronous smart contract execution device, characterized in that, The device includes: processor; And a memory having executable code stored thereon, which, when executed, causes the processor to perform an asynchronous execution method for a blockchain-based smart contract as described in any one of claims 1-5.

8. A non-volatile computer storage medium, characterized in that, It stores computer instructions, which, when executed, implement a blockchain-based asynchronous smart contract execution method as described in any one of claims 1-5.

Images