Blockchain smart contract-based verification method and device

Abstract

The application discloses a verification method and device based on a blockchain smart contract, and relates to the technical field of blockchains.The method comprises the following steps: receiving a verification request of a target smart contract, wherein the target smart contract is a smart contract after repairing a first smart contract, and the first smart contract is a smart contract with errors; generating a target account and a target random number according to the verification request, wherein the target account and the target random number are used for verifying the target smart contract; and reproducing errors that have occurred in the first smart contract by using the target account and the target random number, so as to verify the target smart contract. Through the application, the problem that offline coordination is needed when verifying a repaired smart contract in the related art, leading to low verification efficiency, is solved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a verification method and apparatus based on blockchain smart contracts. Background Technology

[0002] Blockchain is a collaborative ledger solution that uses cryptography to ensure access security, peer-to-peer communication technology to achieve peer-to-peer communication, consensus mechanisms to ensure the legitimacy of record-keeping, and a chain structure to store data. With the continuous expansion of blockchain applications, it has found widespread use in finance, public services, and product traceability. During application, production issues inevitably arise among participating parties, requiring targeted analysis and improvements to technical implementation solutions to resolve these problems. This process is typically led by the participating party with the need for repair, conducted in an informal operating environment (internal development environment). First, the operational phenomena in the production environment are reproduced; then, the problem is analyzed and located, and a repair plan is formulated. Finally, the programs or data involved in the repair plan are updated to the production environment. If the solution resolves the error as expected, the repair is considered successful. Verifying the repair plan in the production environment requires prior coordination among all relevant parties, clarifying that the repaired data will not be used as official business data. This leads to a large workload for offline coordination and low verification efficiency.

[0003] There is currently no effective solution to the problem that offline coordination is required when verifying and repairing smart contracts in related technologies, which leads to low verification efficiency. Summary of the Invention

[0004] The main purpose of this application is to provide a verification method and device based on blockchain smart contracts, so as to solve the problem that offline coordination is required when verifying and repairing smart contracts in related technologies, resulting in low verification efficiency.

[0005] To achieve the above objectives, according to one aspect of this application, a verification method based on a blockchain smart contract is provided. The method includes: receiving a verification request for a target smart contract, wherein the target smart contract is a repaired version of a first smart contract, wherein the first smart contract is a smart contract that has encountered an error; generating a target account and a target random number based on the verification request, wherein the target account and the target random number are used for verifying the target smart contract; and reproducing the error that occurred in the first smart contract using the target account and the target random number to verify the target smart contract.

[0006] Furthermore, generating the target account and the target random number based on the verification request includes: generating the target account through a first device of the blockchain node; performing consensus work on the verification request and the target account through a second device of the blockchain node; if the consensus is successful, generating the target random number through the first device and establishing a correspondence between the target account and the target random number.

[0007] Furthermore, after generating the target account and the target random number based on the verification request, the method further includes: saving the target account and the target random number to the configuration file of the blockchain node.

[0008] Furthermore, before generating the target account and the target random number based on the verification request, the method further includes: performing a legality check on the verification request to obtain a first verification result; if the first verification result is passed, then checking the format of the verification request to obtain a second verification result; if the second verification result is passed, then generating the target account and the target random number based on the verification request.

[0009] Furthermore, before receiving a verification request from the target smart contract, the method further includes: starting the blockchain node and deploying a configuration file for the blockchain node, wherein the configuration file is used to indicate the running status of the smart contract on the blockchain node, with the default running status being the formal running status; if a verification request from the target smart contract is detected, the running status of the target smart contract on the blockchain node is changed to the repair status.

[0010] Furthermore, the verification of the target smart contract involves reproducing the errors that occurred in the first smart contract using the target account and the target random number, thereby identifying the target transaction in the first smart contract where the error occurred; executing the target transaction through the target smart contract to obtain an execution result; and verifying whether the target smart contract has been successfully repaired based on the execution result.

[0011] Furthermore, after reproducing the errors that occurred in the first smart contract using the target account and the target random number to verify the target smart contract, the method further includes: if the target smart contract passes verification, receiving a verification end request from the target smart contract; and canceling the target account and the target random number based on the verification end request.

[0012] Further, canceling the target account and the target random number based on the verification end request includes: obtaining the target random number based on the verification end request; obtaining the target account from the configuration file of the blockchain node based on the target random number; and canceling the target account and the target random number.

[0013] Furthermore, after cancelling the target account and the target random number according to the verification end request, the method further includes: reaching consensus on the verification end request; if the consensus is successful, changing the running state of the target smart contract on the blockchain node to the officially running state.

[0014] To achieve the above objectives, according to another aspect of this application, a verification device based on a blockchain smart contract is provided. The device includes: a first receiving unit, configured to receive a verification request for a target smart contract, wherein the target smart contract is a repaired version of a first smart contract, and wherein the first smart contract is a smart contract that has encountered an error; a first generating unit, configured to generate a target account and a target random number based on the verification request, wherein the target account and the target random number are used for verifying the target smart contract; and a processing unit, configured to reproduce the error that occurred in the first smart contract using the target account and the target random number, thereby verifying the target smart contract.

[0015] Further, the first generation unit includes: a setting module, used to generate the target account through a first device of the blockchain node; a consensus module, used to perform consensus work on the verification request and the target account through a second device of the blockchain node; and a construction module, used to generate the target random number through the first device and construct the correspondence between the target account and the target random number if the consensus is successful.

[0016] Furthermore, the device further includes a storage unit, used to save the target account and the target random number to the configuration file of the blockchain node after generating the target account and the target random number according to the verification request.

[0017] Furthermore, the device further includes: a first verification unit, configured to perform a legality verification on the verification request before generating the target account and the target random number according to the verification request, and obtain a first verification result; a second verification unit, configured to verify the format of the verification request if the first verification result is passed, and obtain a second verification result; and a second generation unit, configured to generate the target account and the target random number according to the verification request if the second verification result is passed.

[0018] Furthermore, the device further includes: a deployment unit, configured to start the blockchain node and deploy the configuration file of the blockchain node before receiving a verification request from the target smart contract, wherein the configuration file is used to indicate the running status of the smart contract on the blockchain node, and the default running status is the formal running status; and a first modification unit, configured to change the running status of the target smart contract on the blockchain node to the repair status if a verification request from the target smart contract is detected.

[0019] Furthermore, the processing unit includes: a determination module, used to reproduce the errors that occurred in the first smart contract using the target account and the target random number, and determine the target transaction in the first smart contract that has an error; an execution module, used to execute the target transaction through the target smart contract and obtain an execution result; and a verification module, used to verify whether the target smart contract has been successfully repaired based on the execution result.

[0020] Furthermore, the device further includes: a receiving unit, configured to receive a verification end request from the target smart contract if the target smart contract passes verification after the target smart contract is verified by reproducing the errors that occurred in the first smart contract using the target account and the target random number; and a cancellation unit, configured to cancel the target account and the target random number according to the verification end request.

[0021] Furthermore, the cancellation unit includes: a first acquisition module, used to acquire the target random number based on the verification end request; a second acquisition module, used to acquire the target account from the configuration file of the blockchain node based on the target random number; and a cancellation module, used to cancel the target account and the target random number.

[0022] Furthermore, the device further includes: a consensus unit, configured to reach consensus on the verification end request after canceling the target account and the target random number according to the verification end request; and a second modification unit, configured to change the running state of the target smart contract on the blockchain node to the formal running state if the consensus is successful.

[0023] To achieve the above objectives, according to one aspect of this application, a processor is provided for running a program, wherein the program executes the blockchain-based smart contract verification method described in any one of the preceding claims.

[0024] To achieve the above objectives, according to one aspect of this application, an electronic device is provided, comprising one or more processors and a memory, the memory being used to store the verification method based on blockchain smart contracts implemented by the one or more processors as described above.

[0025] This application employs the following steps: receiving a verification request from a target smart contract, wherein the target smart contract is a repaired version of a first smart contract, and the first smart contract is the one that encountered the error; generating a target account and a target random number based on the verification request, wherein the target account and the target random number are used for verifying the target smart contract; and reproducing the error that occurred in the first smart contract using the target account and the target random number to verify the target smart contract. This solves the problem in related technologies where offline coordination is required when verifying repaired smart contracts, resulting in low verification efficiency. By generating a target account and a target random number for verification based on the verification request of the target smart contract, and reproducing the error using the target account and the target random number, the verification of the target smart contract is achieved, avoiding offline coordination and thus improving the efficiency of smart contract verification. Attached Figure Description

[0026] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 This is a flowchart of a blockchain-based smart contract verification method provided according to an embodiment of this application;

[0028] Figure 2 This is a flowchart of an optional blockchain-based smart contract verification method provided according to an embodiment of this application;

[0029] Figure 3 This is a schematic diagram of a blockchain-based smart contract verification device provided according to an embodiment of this application;

[0030] Figure 4 This is a schematic diagram of a blockchain smart contract-based verification system provided according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of a blockchain node provided according to an embodiment of this application;

[0032] Figure 6 This is a schematic diagram of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0033] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0036] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving consent information from the aforementioned user or organization.

[0037] The present invention will now be described in conjunction with preferred implementation steps. Figure 1 This is a flowchart of a blockchain-based smart contract verification method provided in the embodiments of this application, such as... Figure 1 As shown, the method includes the following steps:

[0038] Step S101: Receive a verification request from the target smart contract, wherein the target smart contract is the smart contract after repairing the first smart contract, and the first smart contract is the smart contract that has malfunctioned.

[0039] Specifically, when a consortium member on the blockchain has a smart contract verification requirement, it can initiate a verification request for the target smart contract through the verification node solution management system. The format of this verification request can be as follows: Invoke(stubId, function, args). stubId is the ID of the target smart contract, function is update to indicate an update, and args represents information such as adjusted parameters.

[0040] Step S102: Based on the verification request, generate a target account and a target random number, wherein the target account and the target random number are used for the verification of the target smart contract.

[0041] Specifically, based on the verification request of the target smart contract, a target account and a target random number are generated. After successful generation, the target account and target random number are returned to the aforementioned verification node scheme management system so that the consortium members on the blockchain can use the data subsequently.

[0042] Step S103: Reproduce the errors that occurred in the first smart contract using the target account and target random number to verify the target smart contract.

[0043] Specifically, the alliance member who needs to verify the target smart contract initiates an error reproduction using the target account and the target random number to verify whether the target smart contract has resolved the error.

[0044] In summary, by generating a target account and a target random number for verification through the verification request of the target smart contract, and using the target account and target random number to reproduce errors, the verification of the target smart contract can be achieved, avoiding offline coordination and improving verification efficiency.

[0045] Optionally, in the blockchain smart contract-based verification method provided in this application embodiment, generating a target account and a target random number according to the verification request includes: generating a target account through a first device of the blockchain node; performing consensus work on the verification request and the target account through a second device of the blockchain node; if the consensus is successful, generating a target random number through the first device and constructing a correspondence between the target account and the target random number.

[0046] Specifically, a target account A for verification is generated through the business contract consensus and execution device of the blockchain node (i.e., the first device mentioned above). Then, the dynamic scheme verification contract device of the blockchain node (i.e., the second device mentioned above) performs consensus work on the verification request and the target account. If the consensus is successful, a target random number B is generated through the business contract consensus and execution device. Initiating error reproduction using the target account and the target random number does not affect its own broadcast consensus work in the blockchain network, and the entire blockchain network can still maintain normal operation.

[0047] Optionally, in the blockchain smart contract-based verification method provided in this application embodiment, after generating the target account and target random number according to the verification request, the method further includes: saving the target account and target random number to the configuration file of the blockchain node.

[0048] Specifically, the target account, target random number, and related generation records are stored in the configuration file of the blockchain node. The target account and target random number can also be returned to the verification node solution management system so that the alliance members who need it can use the target account and target random number to verify the target smart contract.

[0049] Optionally, in the blockchain smart contract-based verification method provided in this application embodiment, before generating the target account and target random number according to the verification request, the method further includes: performing a legality verification on the verification request to obtain a first verification result; if the first verification result is passed, then verifying the format of the verification request to obtain a second verification result; if the second verification result is passed, then generating the target account and target random number according to the verification request.

[0050] Specifically, the blockchain node's request sending and receiving device verifies the legitimacy of the verification request for the target smart contract, that is, it verifies whether the initiator has the authority to initiate the verification request. After the verification passes, the blockchain node's dynamic scheme verification device verifies the format of the verification request, that is, it verifies whether the necessary information in the verification request is complete. Through the above two-step verification process, the legitimacy and accuracy of the verification request are ensured.

[0051] Optionally, in the blockchain smart contract verification method provided in this application embodiment, before receiving the verification request of the target smart contract, the method further includes: starting a blockchain node and deploying a configuration file of the blockchain node, wherein the configuration file is used to indicate the running status of the smart contract on the blockchain node, and the default running status is the formal running status; if the verification request of the target smart contract is detected, the running status of the target smart contract on the blockchain node is changed to the repair status.

[0052] Specifically, upon startup, the blockchain node loads its parameter configuration file. This file, organized by smart contract, records the runtime status parameters of each smart contract on the blockchain node. The default status is 0, indicating that the smart contract is officially running. The runtime status parameters only determine whether a smart contract on the node is in the scheme verification state and do not affect its broadcast consensus operation within the blockchain network. The configuration file format is: Node Status = 0 [0: Officially Running 1: Repair Phase]; Con Name = Smart Contract ID. When a verification request for a target smart contract is detected, the runtime status of the target smart contract on the blockchain node is updated to the repair state based on the verification request. Through these steps, the runtime status of smart contracts can be accurately set without affecting other business operations.

[0053] Optionally, in the blockchain-based smart contract verification method provided in this application embodiment, verifying the target smart contract by reproducing the errors that occurred in the first smart contract using a target account and a target random number includes: reproducing the errors that occurred in the first smart contract using a target account and a target random number to determine the target transaction in the first smart contract that has an error; executing the target transaction through the target smart contract to obtain the execution result; and verifying whether the target smart contract has been successfully repaired based on the execution result.

[0054] Specifically, the consortium member needing to verify the smart contract uses the target account and target random number to reproduce the error, identify the problematic target transaction, and execute the target smart contract to see if the error persists. If no error is found, the target smart contract has been repaired. Although the running status parameter indicates that the target smart contract in the blockchain node is in the repair phase, it does not affect its broadcast consensus work in the blockchain network. The entire blockchain remains operational, and transactions of other consortium members are unaffected. Furthermore, the data generated during this repair phase originates from target account A and can be completely deleted after the repair is completed. Through these steps, when verifying smart contracts, it is unnecessary to coordinate with relevant parties in advance to clarify that repaired data will not be used as formal business data, thus improving the efficiency of smart contract verification.

[0055] Optionally, in the blockchain smart contract verification method provided in this application embodiment, after reproducing the errors that occurred in the first smart contract using the target account and target random number to verify the target smart contract, the method further includes: if the target smart contract passes verification, receiving a verification end request from the target smart contract; and canceling the target account and target random number according to the verification end request.

[0056] Specifically, once the target smart contract is repaired, the consortium initiates a verification termination request through the verification node management system. Based on this request, the target account, the target random number, and all data generated during the verification process are deleted. By removing unnecessary data through these steps, the storage pressure on the blockchain can be effectively alleviated.

[0057] Optionally, in the blockchain smart contract-based verification method provided in this application embodiment, canceling the target account and target random number according to the verification end request includes: obtaining the target random number according to the verification end request; obtaining the target account from the configuration file of the blockchain node according to the target random number; and canceling the target account and target random number.

[0058] Specifically, the verification completion request also needs to undergo legality and format verification. After successful verification, the corresponding target account is obtained from the blockchain node's configuration file using the target random number B. Then, the target account and target random number are deactivated using the blockchain node's business contract consensus and execution mechanism. These steps prevent situations where, after the smart contract is repaired, corresponding operations can still be initiated using the target account and target random number.

[0059] Optionally, in the blockchain smart contract verification method provided in this application embodiment, after canceling the target account and target random number according to the verification end request, the method further includes: reaching consensus on the verification end request; if the consensus is successful, changing the running state of the target smart contract on the blockchain node to the formal running state.

[0060] Specifically, a consensus process is initiated for the verification completion request. Once consensus is reached, the running state of the target smart contract on the blockchain node is changed to the officially running state. Within a smart contract verification cycle, the accounts used for verification, from their creation and use to their eventual destruction, are all subject to consensus and execution through the blockchain. This allows limited operations by participating parties with verification needs, and these operations are agreed upon by all blockchain nodes, enabling traceability in case of disputes. The initiation and termination of smart contract verification are both initiated by participating parties, ensuring the security of the verification process.

[0061] The blockchain smart contract verification method provided in this application receives a verification request from a target smart contract, which is a repaired version of a first smart contract, where the first smart contract is the one that encountered an error. Based on the verification request, a target account and a target random number are generated, which are used to verify the target smart contract. The target account and the target random number are used to reproduce the error that occurred in the first smart contract, thereby verifying the target smart contract. This solves the problem in related technologies where offline coordination is required when verifying a repaired smart contract, resulting in low verification efficiency. By generating a target account and a target random number based on the verification request of the target smart contract, and using the target account and the target random number to reproduce the error, the verification of the target smart contract is achieved, avoiding offline coordination and thus improving the efficiency of smart contract verification.

[0062] like Figure 2The diagram shows a flowchart of an optional blockchain smart contract verification method provided according to an embodiment of this application. Step S201: The blockchain node starts up. Upon startup, it loads the parameter configuration file param.ini. The configuration file records the running status parameters of each smart contract on the blockchain node, with a default value of 0, indicating that all smart contracts on the node are running. The running status parameters only determine whether the smart contracts on the node are in the scheme verification state and do not affect their broadcast consensus work in the blockchain network.

[0063] Step S202: When a consortium member on the blockchain needs to verify a smart contract, a verification request for the target smart contract is initiated through the verification node scheme management system. The verification request format is Invoke(stubId, function, args), where stubId is the ID of the smart contract being verified in the dynamic scheme, function is update to indicate an update, and args are the specific adjustment parameters.

[0064] Step S203: The blockchain node verifies the verification request. After the verification is successful, the dynamic scheme verification contract consensus and execution device performs a basic verification of the request format. After the verification is successful, the business contract consensus and execution device will generate a target account A for it. Then, consensus is reached on the dynamic scheme verification request. After the consensus is successful, a target random number B is generated. The target account A and the target random number B are updated to the parameter configuration file param.ini and the verification node scheme management system.

[0065] Step S204: The alliance party that needs to verify the solution initiates a business smart contract transaction using target account A and target random number B to reproduce the error and verify whether the target smart contract has been successfully repaired.

[0066] Step S205: After the alliance completes the scheme verification, it initiates a verification end request Invoke(stubId, function, args) through the verification node scheme management system. stubId is the target smart contract ID, function means reopen, and args are the specific adjustment parameters, such as the target random number B.

[0067] Step S206: After the verification completion request passes, the target account A corresponding to the target random number B is obtained from the parameter configuration file param.ini. The business contract consensus and execution device cancels the target account A and the target random number B. Consensus is reached on the verification completion request. After successful consensus, the running status of the target smart contract on the blockchain node is changed to the officially running status.

[0068] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0069] This application also provides a blockchain smart contract verification device. It should be noted that the blockchain smart contract verification device of this application can be used to execute the blockchain smart contract verification method provided in this application. The following describes the blockchain smart contract verification device provided in this application.

[0070] Figure 3 This is a schematic diagram of a blockchain smart contract-based verification device according to an embodiment of this application. Figure 3 As shown, the device includes: a first receiving unit 301, a first generating unit 302, and a processing unit 303.

[0071] The first receiving unit 301 is used to receive a verification request for a target smart contract, wherein the target smart contract is a smart contract that has been repaired from the first smart contract, and the first smart contract is the smart contract that has encountered an error.

[0072] The first generation unit 302 is used to generate a target account and a target random number based on the verification request, wherein the target account and the target random number are used for the verification of the target smart contract.

[0073] Processing unit 303 is used to reproduce errors that have occurred in the first smart contract using the target account and the target random number, in order to verify the target smart contract.

[0074] The blockchain smart contract verification device provided in this application embodiment receives a verification request for a target smart contract through a first receiving unit 301. The target smart contract is a repaired version of a first smart contract, which is the smart contract that encountered an error. A first generating unit 302 generates a target account and a target random number based on the verification request. The target account and target random number are used for verifying the target smart contract. A processing unit 303 uses the target account and target random number to reproduce the error that occurred in the first smart contract, thereby verifying the target smart contract. This solves the problem in related technologies where offline coordination is required when verifying repaired smart contracts, resulting in low verification efficiency. By generating a target account and target random number for verification through the verification request of the target smart contract, and using the target account and target random number to reproduce the error, the verification of the target smart contract is achieved, avoiding offline coordination and thus improving the verification efficiency of smart contracts.

[0075] Optionally, in the blockchain smart contract-based verification device provided in this application embodiment, the first generation unit 302 includes: a setting module, used to generate a target account through a first device of the blockchain node; a consensus module, used to perform consensus work on the verification request and the target account through a second device of the blockchain node; and a construction module, used to generate a target random number through the first device and construct the correspondence between the target account and the target random number if the consensus is successful.

[0076] Optionally, in the blockchain smart contract-based verification device provided in this application embodiment, the device further includes: a storage unit, used to save the target account and target random number to the configuration file of the blockchain node after generating the target account and target random number according to the verification request.

[0077] Optionally, in the blockchain smart contract-based verification device provided in this application embodiment, the device further includes: a first verification unit, used to perform a legality verification on the verification request before generating the target account and target random number according to the verification request, and obtain a first verification result; a second verification unit, used to verify the format of the verification request if the first verification result is passed, and obtain a second verification result; and a second generation unit, used to generate the target account and target random number according to the verification request if the second verification result is passed.

[0078] Optionally, in the blockchain smart contract verification device provided in this application embodiment, the device further includes: a deployment unit, configured to start a blockchain node and deploy a configuration file of the blockchain node before receiving a verification request of the target smart contract, wherein the configuration file is used to indicate the running state of the smart contract on the blockchain node, and the default running state is the formal running state; and a first modification unit, configured to change the running state of the target smart contract on the blockchain node to the repair state if a verification request of the target smart contract is detected.

[0079] Optionally, in the blockchain smart contract verification device provided in this application embodiment, the processing unit 303 includes: a determination module, used to reproduce the errors that have occurred in the first smart contract by using a target account and a target random number, and determine the target transaction in the first smart contract that has an error; an execution module, used to execute the target transaction through the target smart contract and obtain the execution result; and a verification module, used to verify whether the target smart contract has been successfully repaired based on the execution result.

[0080] Optionally, in the blockchain smart contract verification device provided in this application embodiment, the device further includes: a receiving unit, used to receive a verification end request from the target smart contract if the target smart contract is verified after the error that occurred in the first smart contract is reproduced by using the target account and the target random number; and a cancellation unit, used to cancel the target account and the target random number according to the verification end request.

[0081] Optionally, in the blockchain smart contract-based verification device provided in this application embodiment, the cancellation unit includes: a first acquisition module, used to acquire a target random number based on the verification end request; a second acquisition module, used to acquire a target account from the configuration file of the blockchain node based on the target random number; and a cancellation module, used to cancel the target account and the target random number.

[0082] Optionally, in the blockchain smart contract verification device provided in this application embodiment, the device further includes: a consensus unit, used to reach consensus on the verification end request after canceling the target account and the target random number according to the verification end request; and a second modification unit, used to change the running state of the target smart contract on the blockchain node to the formal running state if the consensus is successful.

[0083] It should be noted that the first receiving unit 301 in this embodiment can be used to execute step S101 in this application embodiment, the first generating unit 302 in this embodiment can be used to execute step S102 in this application embodiment, and the processing unit 303 in this embodiment can be used to execute step S103 in this application embodiment. The examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments.

[0084] The blockchain-based smart contract verification device includes a processor and a memory. The first receiving unit 301, the first generating unit 302, and the processing unit 303 are all stored in the memory as program units. The processor executes the program units stored in the memory to achieve the corresponding functions.

[0085] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and the verification of smart contracts can be performed by adjusting kernel parameters.

[0086] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0087] like Figure 4The diagram shown is a schematic of a blockchain smart contract-based verification system provided according to an embodiment of this application. The system includes a business chain 1, a blockchain node 2, a verification node scheme management system 3, and a business system 4.

[0088] Business Chain 1: It is constructed based on the on-chain business requirements of Business System 4. It includes multiple blockchain nodes 2, all of which are member nodes of the business chain.

[0089] Blockchain Node 2: Receives system operation requests initiated by the verification node solution management system 3 and business requests initiated by the business system 4. All verification nodes have the same internal structure. It performs permission verification on transactions and completes duplicate and parameter validity checks. After successful verification, it broadcasts the transaction to all other verification nodes in the business chain 1. It also receives block broadcast notifications from Blockchain Node 2 awaiting consensus and performs parameter validity checks on transactions awaiting consensus. When Blockchain Node 2 starts, its operating status is set according to parameters. The operating status is designed with two types: "Official Operating Status" and "Repair Status." The Official Operating Status represents that Blockchain Node 2 is in normal external operation; the Repair Status represents that Blockchain Node 2 has entered the problem analysis and verification stage. During normal system operation, this parameter is set to "Official Operating Status." The parameter configuration file for Blockchain Node 2, param.ini, has the following format:

[0090] Node Status = 0 [0: Fully operational; 1: Repair phase]

[0091] Con Name = Smart Contract ID.

[0092] Verification Node Solution Management System 3: This is a supporting solution management system for Blockchain Node 2, typically deployed by different members of the Business Chain 1 consortium. One Verification Node Solution Management System 3 can operate and manage one or more Blockchain Nodes 2 according to the consortium operation agreement of Business Chain 1. That is, multiple Blockchain Nodes 2 of Business Chain 1 are simultaneously supported by multiple Verification Node Solution Management Systems 3. The internal structure of each Verification Node Solution Management System 3 is identical; only the information of the managed Blockchain Nodes 2 differs. The Verification Node Solution Management System 3 can initiate solution verification commands from the business chain blockchain network to the Blockchain Nodes 2.

[0093] Business System 4: Business Transaction Request Initiation System. This system initiates business transaction requests to blockchain node 2 of business chain 1, including update transactions and query transactions. It also receives transaction request processing and return information from blockchain node 2 and performs related business logic loop closure.

[0094] like Figure 5The diagram shown is a schematic of a blockchain node provided according to an embodiment of this application. The blockchain node includes a request sending and receiving device 11, a transaction routing device 12, a dynamic scheme verification contract consensus and execution device 13, and a business contract consensus and execution device 14.

[0095] Request transceiver device 11: Responsible for receiving dynamic scheme verification and verification end requests initiated by the verification node scheme management system 3 and business requests initiated by the business system 4. It performs legality verification on the transaction request Invoke(stubId, function, args). Transaction requests that pass the verification will be forwarded to the transaction routing device 12.

[0096] Transaction routing device 12: responsible for controlling the entry of transactions into the corresponding contract consensus routing, for example, forwarding the dynamic scheme verification request and verification completion request initiated by the verification node scheme management system 3 to the dynamic scheme verification contract consensus and execution device 13, or forwarding the business update request and query request initiated by the business system 4 to the business contract consensus and execution device 14.

[0097] Dynamic scheme verification contract consensus and execution device 13: This is the core working device for dynamic scheme verification in the business chain. It is responsible for reaching consensus on the scheme verification instructions initiated by the verification node scheme management system 3, triggering user management operations in the business chain blockchain network according to the dynamic scheme verification contract rules, and feeding back the adjustment results to the verification node scheme management system 3. Specifically, it includes an instruction verification module 131, an instruction consensus module 132, and an instruction notification transmission module 133.

[0098] Instruction verification module 131: This module verifies dynamic scheme verification and verification completion requests, and performs instruction consensus preprocessing. It is responsible for verifying transaction request parameters and source information.

[0099] Command Consensus Module 132: This is the core module for completing the dynamic scheme verification and state adjustment command consensus. It uses the Byzantine consensus algorithm to perform a three-stage consensus process for transactions.

[0100] Instruction notification transmission module 133: This is a workflow module that executes dynamic scheme verification status adjustment instructions and consensus results flow.

[0101] Business Contract Consensus and Execution Device 14: This is the core working device for processing business transaction requests in the business chain. It is responsible for verifying the legality of business requests initiated by business system 4 and responding to business requests according to business contract logic. Specifically, it includes a transaction verification module 141, a transaction query module 142, a transaction consensus module 143, and an instruction notification processing module 144.

[0102] Transaction verification module 141: This module verifies business request parameters and performs transaction consensus preprocessing. It is responsible for verifying transaction request parameters and source information.

[0103] Transaction query module 142: This is a transaction processing module that completes query-type business requests. It is responsible for returning the latest block information in the current business contract to the business system 3 based on the business request. Data queries are obtained directly from the local ledger without the need for consensus.

[0104] Transaction consensus module 143: This is the core module for completing transaction consensus for update-type business transactions. During non-system security restart time windows, the Byzantine consensus algorithm is used to perform three-stage consensus processing on transactions.

[0105] Instruction notification processing module 144: This is a workflow module that receives dynamic scheme verification status adjustment instructions. It is responsible for receiving and processing business user addition and deletion instruction notifications sent by the dynamic scheme verification contract consensus and execution device 13, and finally returning the processing results to the instruction notification transmission module 133.

[0106] This invention provides a processor for running a program, wherein the program executes a verification method based on a blockchain smart contract during runtime.

[0107] like Figure 6 As shown, this embodiment of the invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: receiving a verification request for a target smart contract, wherein the target smart contract is a smart contract that has been repaired from a first smart contract, wherein the first smart contract is a smart contract that has encountered an error; generating a target account and a target random number based on the verification request, wherein the target account and the target random number are used for verifying the target smart contract; and reproducing the error that occurred in the first smart contract using the target account and the target random number to verify the target smart contract.

[0108] Optionally, generating the target account and target random number based on the verification request includes: generating the target account through the first device of the blockchain node; performing consensus work on the verification request and target account through the second device of the blockchain node; if the consensus is successful, generating the target random number through the first device and establishing the correspondence between the target account and the target random number.

[0109] Optionally, after generating the target account and target random number based on the verification request, the method further includes saving the target account and target random number to the configuration file of the blockchain node.

[0110] Optionally, before generating the target account and target random number based on the verification request, the method further includes: performing a validity check on the verification request to obtain a first verification result; if the first verification result is successful, then performing a format check on the verification request to obtain a second verification result; if the second verification result is successful, then generating the target account and target random number based on the verification request.

[0111] Optionally, before receiving a verification request from the target smart contract, the method further includes: starting a blockchain node and deploying a configuration file for the blockchain node, wherein the configuration file is used to indicate the running status of the smart contract on the blockchain node, with the default running status being the formal running status; if a verification request from the target smart contract is detected, the running status of the target smart contract on the blockchain node is changed to the repair status.

[0112] Optionally, reproducing the errors that occurred in the first smart contract using the target account and the target random number to verify the target smart contract includes: reproducing the errors that occurred in the first smart contract using the target account and the target random number to identify the target transaction in the first smart contract that has an error; executing the target transaction through the target smart contract to obtain the execution result; and verifying whether the target smart contract has been successfully repaired based on the execution result.

[0113] Optionally, after reproducing the errors that occurred in the first smart contract using the target account and the target random number to verify the target smart contract, the method further includes: if the target smart contract passes verification, receiving a verification end request from the target smart contract; and canceling the target account and the target random number based on the verification end request.

[0114] Optionally, canceling the target account and target random number based on the verification completion request includes: obtaining the target random number based on the verification completion request; obtaining the target account from the configuration file of the blockchain node based on the target random number; and canceling the target account and target random number.

[0115] Optionally, after deregistering the target account and target random number based on the verification completion request, the method further includes: reaching consensus on the verification completion request; if the consensus is successful, changing the running state of the target smart contract on the blockchain node to the officially running state. The device mentioned in this article can be a server, PC, PAD, mobile phone, etc.

[0116] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having the following method steps: receiving a verification request for a target smart contract, wherein the target smart contract is a smart contract after repairing a first smart contract, wherein the first smart contract is a smart contract that has encountered an error; generating a target account and a target random number based on the verification request, wherein the target account and the target random number are used for verifying the target smart contract; and reproducing the error that occurred in the first smart contract using the target account and the target random number to verify the target smart contract.

[0117] Optionally, generating the target account and target random number based on the verification request includes: generating the target account through the first device of the blockchain node; performing consensus work on the verification request and target account through the second device of the blockchain node; if the consensus is successful, generating the target random number through the first device and establishing the correspondence between the target account and the target random number.

[0118] Optionally, after generating the target account and target random number based on the verification request, the method further includes saving the target account and target random number to the configuration file of the blockchain node.

[0119] Optionally, before generating the target account and target random number based on the verification request, the method further includes: performing a validity check on the verification request to obtain a first verification result; if the first verification result is successful, then performing a format check on the verification request to obtain a second verification result; if the second verification result is successful, then generating the target account and target random number based on the verification request.

[0120] Optionally, before receiving a verification request from the target smart contract, the method further includes: starting a blockchain node and deploying a configuration file for the blockchain node, wherein the configuration file is used to indicate the running status of the smart contract on the blockchain node, with the default running status being the formal running status; if a verification request from the target smart contract is detected, the running status of the target smart contract on the blockchain node is changed to the repair status.

[0121] Optionally, reproducing the errors that occurred in the first smart contract using the target account and the target random number to verify the target smart contract includes: reproducing the errors that occurred in the first smart contract using the target account and the target random number to identify the target transaction in the first smart contract that has an error; executing the target transaction through the target smart contract to obtain the execution result; and verifying whether the target smart contract has been successfully repaired based on the execution result.

[0122] Optionally, after reproducing the errors that occurred in the first smart contract using the target account and the target random number to verify the target smart contract, the method further includes: if the target smart contract passes verification, receiving a verification end request from the target smart contract; and canceling the target account and the target random number based on the verification end request.

[0123] Optionally, canceling the target account and target random number based on the verification completion request includes: obtaining the target random number based on the verification completion request; obtaining the target account from the configuration file of the blockchain node based on the target random number; and canceling the target account and target random number.

[0124] Optionally, after canceling the target account and target random number based on the verification completion request, the method further includes: reaching consensus on the verification completion request; if the consensus is successful, changing the running state of the target smart contract on the blockchain node to the officially running state.

[0125] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0126] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0127] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0128] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0130] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

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

[0132] 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.

[0133] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0134] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A verification method based on blockchain smart contracts, characterized in that, include: Receive a verification request for a target smart contract, wherein the target smart contract is a smart contract that has been repaired from a first smart contract, wherein the first smart contract is a smart contract that has encountered an error; Based on the verification request, a target account and a target random number are generated, wherein the target account and the target random number are used for the verification of the target smart contract; The first smart contract is used to reproduce errors by using the target account and the target random number, thereby verifying the target smart contract. The method further includes, before receiving the verification request from the target smart contract: Start the blockchain node and deploy the configuration file of the blockchain node, wherein the configuration file is used to indicate the running status of the smart contracts on the blockchain node, and the default running status is the formal running status; If a verification request for the target smart contract is detected, the running status of the target smart contract on the blockchain node will be changed to the repair status.

2. The method according to claim 1, characterized in that, Based on the verification request, generating the target account and target random number includes: The target account is generated through the first device of the blockchain node; The second device of the blockchain node performs consensus work on the verification request and the target account. If consensus is successful, the target random number is generated through the first device, and a correspondence between the target account and the target random number is established.

3. The method according to claim 2, characterized in that, After generating the target account and target random number based on the verification request, the method further includes: The target account and the target random number are saved to the configuration file of the blockchain node.

4. The method according to claim 1, characterized in that, Before generating the target account and target random number based on the verification request, the method further includes: The validity of the verification request is checked to obtain a first verification result; If the first verification result is passed, the format of the verification request is verified to obtain the second verification result; If the second verification result is successful, then the target account and the target random number are generated according to the verification request.

5. The method according to claim 1, characterized in that, By using the target account and the target random number, errors that occurred in the first smart contract are reproduced to verify that the target smart contract includes: By using the target account and the target random number, the errors that occurred in the first smart contract are reproduced to determine the target transaction in the first smart contract where the error occurred. The target transaction is executed through the target smart contract to obtain the execution result; Based on the execution results, verify whether the target smart contract has been successfully repaired.

6. The method according to claim 1, characterized in that, After reproducing the errors that occurred in the first smart contract using the target account and the target random number to verify the target smart contract, the method further includes: If the target smart contract passes verification, then receive the verification completion request from the target smart contract. Based on the verification completion request, the target account and the target random number are cancelled.

7. The method according to claim 6, characterized in that, Based on the verification completion request, canceling the target account and the target random number includes: Based on the verification end request, obtain the target random number; Based on the target random number, the target account is obtained from the configuration file of the blockchain node; Cancel the target account and the target random number.

8. The method according to claim 7, characterized in that, After deregistering the target account and the target random number based on the verification completion request, the method further includes: A consensus is reached on the verification completion request; If consensus is successful, the running state of the target smart contract on the blockchain node will be changed to the officially running state.

9. A verification device based on blockchain smart contracts, characterized in that, include: The first receiving unit is configured to receive a verification request for a target smart contract, wherein the target smart contract is a smart contract after repairing a first smart contract, wherein the first smart contract is a smart contract that has encountered an error. The first generation unit is used to generate a target account and a target random number based on the verification request, wherein the target account and the target random number are used for the verification of the target smart contract; The processing unit is used to reproduce the errors that occurred in the first smart contract using the target account and the target random number, so as to verify the target smart contract; The device further includes: a deployment unit, configured to start a blockchain node and deploy a configuration file of the blockchain node before receiving a verification request from the target smart contract, wherein the configuration file is used to indicate the running state of the smart contract on the blockchain node, and the default running state is the formal running state; and a first modification unit, configured to change the running state of the target smart contract on the blockchain node to the repair state if a verification request from the target smart contract is detected.

10. A processor, characterized in that, The processor is used to run a program, wherein the program executes the blockchain-based smart contract verification method according to any one of claims 1 to 8 when it runs.

11. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the blockchain-based smart contract verification method according to any one of claims 1 to 8.

Images