Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.
The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The intelligent contract verification scheme provided by the specification can be applied to a blockchain and can also be applied to a non-blockchain.
Taking the application as an example of a blockchain, a Smart contract (Smart contract) is a computer protocol intended for application of an informative propagation, verification or execution contract that can be deployed on a blockchain. Performing the corresponding operation can be realized by declaring the business logic in the smart contract. Smart contracts allow trusted transactions to be conducted without third parties. These transactions are traceable and irreversible. Smart contracts can provide security over traditional contract methodologies and reduce other transaction costs associated with contracts.
First, the deployment of intelligent contracts in a traditional blockchain is introduced. The traditional intelligent contract is directly deployed on node equipment in a block chain, and when the node equipment executes a transaction request, the locally deployed corresponding intelligent contract is directly operated; and the node device also stores the full amount of transaction data. To avoid tampering with, e.g., data by a single node device; as shown in fig. 1a, the intelligent contract checking process of the conventional blockchain is as follows:
1. the blockchain system sends the transaction to a plurality of node devices.
2. Each node device performs a pre-execution of the transaction and returns a result set of the pre-execution (usually with a signature of the corresponding node device).
3. And checking each result set, and if each pre-execution result is consistent, determining that the check is passed.
4. And after the verification is passed, broadcasting the pre-execution result to the whole network for consensus (verifying the data state).
As can be seen, in the existing intelligent contract verification, multiple node devices are required to repeatedly pre-execute an intelligent contract, and each pre-execution may require accessing a world state of a block chain to obtain a corresponding data state, and frequent accessing of the data state may consume many resources and is inefficient.
The present specification provides an intelligent contract checking scheme based on a block chain, which divides the block chain into a contract management system and a data storage system, wherein the contract management system only stores an intelligent contract of the block chain, and the data storage system only stores a data state of the block chain.
The read-write set generated by the target intelligent contract is pre-executed by one intelligent contract node, so that other intelligent contract nodes do not need to access the data storage node again, and the target intelligent contract can be simulated and executed by utilizing the read-write set; and if the simulation execution result returned by the other intelligent contract nodes is consistent with the previous pre-execution result, the verification is determined to be passed. Therefore, on one hand, the safety of executing the intelligent contract can be improved through logic verification, and the single intelligent contract node is prevented from doing badness. On the other hand, the intelligent contract node for logic verification does not need to acquire the data state again, so that the times of accessing the data storage node are reduced. On the other hand, the contract verification and the data verification in the transaction process are decoupled and divided into two independent parts; the node equipment in the contract management system is only responsible for contract logic verification, and the node equipment in the data storage system is only responsible for data verification; the verification execution logic is simplified, and the verification operation period is shortened.
The blockchain described in this specification may specifically include a private chain, a common chain, a federation chain, and the like, and is not particularly limited in this specification. Node devices in the block chain can be added without limitation, and each node device can synchronize a system time to ensure timeliness of execution of the intelligent contract.
It should be noted that the Transaction (Transaction) described in this specification refers to a piece of data that is created by a client of the blockchain and needs to be finally distributed to the data storage system of the blockchain.
Transactions in a blockchain, generally have a narrow sense of transaction and a broad sense of transaction score. A narrowly defined transaction refers to a transfer of value issued by a user to a blockchain; for example, in a conventional bitcoin blockchain network, the transaction may be a transfer initiated by the user in the blockchain. The broad transaction refers to a piece of business data with business intention, which is issued to the blockchain by a user; for example, an operator may build a federation chain based on actual business requirements, relying on the federation chain to deploy some other types of online business unrelated to value transfer (e.g., broadly classified as query business, call business, etc.), and in such federation chain, the transaction may be a business message or business request with a business intent issued by a user in the federation chain.
The client may include any type of upper layer application that uses the bottom layer service data stored in the blockchain as a data support to implement a specific service function.
The pre-execution described in this specification may refer to a process of executing an intelligent contract without recording an execution result, and may be understood as a logic execution. A complete execution process including intelligent contract execution and recording of execution results; but pre-execution is only intelligent contract execution.
Referring to fig. 1b, fig. 1b is a schematic diagram of a block chain system provided in the present specification:
the block chain is divided into a contract management system 11 and a data storage system 12, the contract management system 11 stores intelligent contracts, and the data storage system 12 stores business data.
The contract management system 11 includes a plurality of devices of intelligent contract nodes, and the data storage system 12 includes a plurality of devices of data storage nodes.
The contract management system 11 and the data storage system 12 are connected through the SDK13 to complete data interaction.
Specifically, the contract management system 11 may be a set of independent blockchain systems, and is mainly responsible for deployment (creation), upgrade (update), and operation of intelligent contracts. Moreover, the contract management system 11 also needs to perform logical check on the execution of the intelligent contract.
The data storage system 12 may be another independent block chain system different from the contract management system 11, and is mainly responsible for storing data states and changes corresponding to the intelligent contracts. In addition, the data storage system 12 also needs to perform data verification on the data state change.
Referring to fig. 2, fig. 2 is a flowchart of a method for checking an intelligent contract based on a blockchain according to an embodiment of the present disclosure. As shown in fig. 1b, the blockchain may be divided into a contract management system and a data storage system.
1. A user initiates a transaction to any data storage node in the data storage system; set as data storage node 1.
2. The data storage node 1 broadcasts the transaction to any intelligent contract node in the contract management system; set to intelligent contract node 1.
In particular, the data storage node 1 may broadcast the transaction to any one of the intelligent contract nodes in the contract management system by engaging the SDK.
3. After the intelligent contract node 1 executes the intelligent contract in advance, a result set of the signature is returned.
After receiving the transaction broadcast by the data storage node 1, the intelligent contract node 1 responds to the transaction and can pre-run a target intelligent contract corresponding to the transaction; and packing read-write sets and other information generated in the process of pre-executing the target intelligent contract into a result set; the result set is then signed to endorse the result set. Likewise, the intelligent contract node 1 returns the signed result set to the data storage node 1 by engaging the SDK.
4. The data storage node 1 sends the result set returned by the intelligent contract node 1 to other intelligent contract nodes.
The data storage node 1, after receiving the result set returned by the intelligent contract node 1, may also send the result set to other intelligent contract nodes except the intelligent contract node 1 through the engagement SDK.
5. Other intelligent contract nodes carry out logic verification on the result set; if the verification passes, self-signature is added to the result set and returned to the data storage node 1.
The logical check includes: simulating and executing the intelligent contract to obtain a simulation read-write set; and judging whether the simulation read-write set is consistent with the read-write set in the result set. If the two are consistent, the verification is passed; if not, the check fails.
6. And the data storage node 1 performs validity check on the result set returned by the other intelligent contract nodes.
The validity check here may refer to checking the signature of the result set, and if the signatures of all other intelligent contract nodes are included, the validity check may be considered to be passed.
7. And after the validity check is passed, the data storage node 1 transmits the transaction to other data storage nodes for consensus.
After the result set is verified to be valid, the data state change result can be extracted from the read-write set, and the data state change result is sent to other data storage nodes for consensus.
8. The data storage section performs data verification on the data state change; and if the verification is passed, modifying the corresponding data state, and setting the transaction as an effective transaction.
The consensus mechanism is mainly used for carrying out data verification on data state change; if the data state change is consistent with the locally stored data state, the verification is passed. Thereby modifying the corresponding data state and setting the transaction as a valid transaction.
9. After the consensus passes, the data storage node 1 returns a prompt.
After the consensus passes, the data storage node 1 may return prompt information to the user, such as execution results or occurrence of a block event. Such a complete transaction flow ends.
A flow chart of the intelligent contract node 1 obtaining the data state from the data storage node 1 is described below with reference to the example shown in fig. 3.
1. The data storage node 1 sends the transaction to the intelligent contract node 1 by engaging the SDK.
Wherein the transaction carries execution parameters. The execution parameters may specifically include contract parameters and business parameters.
The contract parameters may be used to locate a target intelligent contract. The contract parameters may include contract identification, calling function name, contract version number, input parameters, transaction ID, timestamp, etc. information.
2. The intelligent contract node 1 responds to the transaction and executes the intelligent contract corresponding to the transaction; during execution of the intelligent contract, the data state is retrieved to the data storage node 1.
The intelligent contract node 1 can determine a calling function interface method based on the contract identification, calling function name and other information in the contract parameters.
The business parameters may be used to locate the data state needed to execute the contract logic.
The following illustrates the differences in traffic parameters and data states:
let a +1 be assumed as the transaction sent by the client. The fields a and plus 1 are the traffic parameters and the current value of a is the data state. In the actual operation of a +1, the original value (service data) of a needs to be acquired first, and then 1 is added on the basis of the original value to obtain the execution result.
As shown in FIG. 3, intelligent contract node 1 may generate a read-write set (r/w set) during execution of the contract logic. The read-write set may include contract identification, status reads, and status writes.
The contract identification here is used to indicate which intelligent contract the read-write set corresponds to. The state read here refers to the data state read by the intelligent contract node 1 accessing the data storage node 1 by engaging the SDK. The status write here refers to the changed data status calculated from the read data status.
Typically, for complex intelligent contracts, there are multiple sets of state reads and state writes; that is, the read-write set may be a data set formed by all state reads and state writes during execution of the smart contract. The whole execution calculation process of the intelligent contract can be truly reflected through the reading and writing set.
3. After the intelligent contract node 1 executes the intelligent contract, the execution result may be returned to the data storage node 1.
The execution result here may be a result set formed by packing contract parameters and read-write sets, and signing endorsements for the result set.
In addition to the application of the blockchain system shown in fig. 1b, the embodiments of the present disclosure can also be applied to a conventional blockchain system, as shown in fig. 4:
1. the blockchain system sends the transaction initiated by the user to any one of the node devices.
2. The node device pre-executes the intelligent contract corresponding to the transaction and returns a result set (containing information such as read-write set, return value, signature and the like). The specific process is shown in fig. 5 a:
2.1. the transaction carries execution parameters.
SDK passes parameters into node device.
2.3. The node device executes contract logic to retrieve data or modify data from the data store and generates a read-write set.
2.4. Signing the record when the contract is successfully executed; and returning a result set.
3. And sending the result set to other node equipment so as to enable the other node equipment to carry out logic check.
Performing simulation execution of the intelligent contract according to the data in the read-write set to obtain a simulation read-write set generated in the simulation execution process; if the analog read-write set is consistent with the read-write set in the result set, the verification is passed; otherwise, the verification fails if the two are inconsistent. The specific process is shown in fig. 5 b:
SDK passing result set to other node device.
3.2. And other node equipment executes contract logic, acquires data or modifies data from the read-write set and performs logic verification.
3.3. The logic checks pass and the record is signed.
4. If the verification is passed, the correct signature information is returned.
5. The result set and signature information are collected.
In this embodiment, when other node devices perform simulation execution through the result set, the node devices do not need to access the corresponding world states again, but directly acquire the required data states from the result set. Because the execution results of each node device for the same transaction are consistent, and the data states accessed by the node devices in the process are also consistent, the correct results can be obtained by reading and writing the sets as long as the logic is correct.
An embodiment of the method for the data storage node in the data storage system as an execution subject in the present specification is described below with reference to fig. 6, where the embodiment may be applied to the system shown in fig. 1b, and corresponds to the embodiment of the method shown in fig. 2, and the method includes:
step 210: the data storage node receives a target transaction initiated by a client;
step 220: and broadcasting the target transaction to any intelligent contract node.
Step 230: and receiving a pre-execution result returned after the intelligent contract node pre-executes the target intelligent contract corresponding to the target transaction.
Step 240: and sending the pre-execution result to other intelligent contract nodes so that the other intelligent contract nodes simulate to execute the target intelligent contract.
Step 250: and when the simulation execution result returned by the other nodes is consistent with the pre-execution result, determining that the pre-execution result passes verification.
In one embodiment, the intelligent contract node is located in a contract management system, and the contract management system is a block chain system for storing intelligent contracts;
the data storage nodes are located in a data storage system, and the data storage system is a block chain system for storing data states.
In an embodiment, the pre-execution result is a result set formed by packing read-write sets generated in the process of pre-executing the target intelligent contract by the intelligent contract node; the simulation execution result is a result set formed by packaging read-write sets generated in the process of simulating and executing the target intelligent contract by other intelligent contract nodes; the result set carries the signature of each node device;
the method further comprises the following steps:
and when the simulation execution result is consistent with the pre-execution result, sending the pre-execution result to other node equipment in the data storage system for consensus.
In one embodiment, the consensus mainly performs data verification on the read-write set data state change; if the data state change is consistent with the locally stored data state, the verification is passed. Thereby modifying the corresponding data state and setting the transaction as a valid transaction.
In an embodiment, after the consensus passes, the data storage node may also return a prompt message to the client. Such as execution results or block events.
An embodiment of a method for using an intelligent contract node in a contract management system as an execution subject, which can be applied to the system shown in fig. 1b and corresponds to the embodiment of the method shown in fig. 2, is described below with reference to fig. 7, where the method includes:
step 310: the intelligent contract node receives a pre-execution result sent by the data storage node; the pre-execution result is a result obtained after other intelligent contract nodes respond to a target transaction initiated by a client and pre-execute a target intelligent contract corresponding to the target transaction;
step 320: simulating and executing the target intelligent contract according to the pre-execution result, and returning a simulated pre-execution result obtained after the target intelligent contract is simulated and executed to the data storage node; for the data storage node to verify.
In an embodiment, the other intelligent contract nodes respond to the target transaction to pre-execute the target intelligent contract corresponding to the target transaction, specifically including:
acquiring a target intelligent contract corresponding to the contract parameters according to the contract parameters carried in the target transaction;
contract logic to pre-execute the target intelligent contract.
In this embodiment, the target transaction may carry contract parameters for locating the intelligent contract required to execute the target transaction.
The contract parameters may include contract identification, calling function name, contract version number, input parameters, transaction ID, timestamp, and other information.
Based on the contract identification in the contract parameters, acquiring an intelligent contract address corresponding to the contract identification from the contract management system;
and determining a calling function interface method under the intelligent contract address according to the calling function name.
However, in general, one smart contract may be externally provided with a plurality of function interface methods. Each function interface method corresponds to a specific service logic, so that after an intelligent contract address is determined according to a contract identifier, a calling function interface method under the intelligent contract address needs to be determined according to a calling function name.
In an embodiment, the other intelligent contract nodes respond to a target transaction initiated by a client, and pre-execute a result obtained after the target transaction corresponds to a target intelligent contract, which specifically includes:
and other intelligent contract nodes respond to the target transaction initiated by the client, and if the target intelligent contract corresponding to the target transaction is pre-executed needs a data state, the data state is acquired from the data storage equipment according to the transaction parameters carried in the target transaction.
In practical applications, in conjunction with the aforementioned FIG. 3, some transactions may not require data state entry, and data state may not be retrieved to the data storage system for such transactions. For some complex transactions, however, data states are needed; the service parameters corresponding to the data states need to be provided for the target transaction.
The following illustrates the differences in traffic parameters and data states:
let a +1 be assumed as the transaction sent by the client. The fields a and plus 1 are the traffic parameters and the current value of a is the data state. In the actual operation of a +1, the original value (service data) of a needs to be acquired first, and then 1 is added on the basis of the original value to obtain the execution result.
It should be noted that the read-write set is also generated in the process of executing the business logic of the intelligent contract. The read-write set may include input data (including data states) required to pre-execute the smart contract and output data corresponding to the input data. For a complex intelligent contract, the input data and the output data can contain multiple groups, namely, the read-write set is a data set formed by all input data and corresponding output data required in the execution process of the intelligent contract, and the data set can truly reflect the whole execution calculation process of the intelligent contract.
It is worth mentioning that when the intelligent contract node sends an execution result obtained after pre-executing the target intelligent contract to the data storage system, the signature of the node device needs to be added to the execution result; to endorse the execution result.
In an embodiment, the pre-execution result is a result set formed by packing read-write sets generated in the process of pre-executing the target intelligent contract by the intelligent contract node; the simulation execution result is a result set formed by packaging read-write sets generated in the process of simulating and executing the target intelligent contract by other intelligent contract nodes; the result set carries the signatures of the node devices.
It is worth mentioning that the node device performing the logic verification does not need to acquire the data state required for executing the target transaction from the data storage system again, so that the target intelligent contract can be simulated and operated according to the read-write centralized data.
It should be noted that, as long as the intelligent contract logic in the contract management system is successfully operated, the node device in the contract management system records the node device. According to the principle that the node equipment only performs logic verification, a unique value formed by transaction id + result set hash is recorded. Each transaction record is collected and packed into a block within a certain time range. There is a packed timestamp in this block. The records are not ordered in sequence, but rather are executed to complete certain transactions within the time period.
In an embodiment, the verifying the data storage node specifically includes:
the data storage node compares the pre-execution result with a simulation pre-execution result;
and if the pre-execution result is consistent with the simulation pre-execution result, determining that the verification is passed.
In one embodiment, the intelligent contract node is located in a contract management system, and the contract management system is a block chain system for storing intelligent contracts;
the data storage nodes are located in a data storage system, and the data storage system is a block chain system for storing data states.
In an embodiment, the simulating and executing the target intelligent contract according to the pre-execution result, and returning a simulated pre-execution result obtained after the target intelligent contract is simulated and executed to the data storage node, specifically includes:
simulating and executing the target intelligent contract according to the read-write centralized data of the pre-execution result;
and returning a simulation result set simulating the execution target intelligent contract to the data storage node.
The read-write set generated by the target intelligent contract is pre-executed by one intelligent contract node, so that other intelligent contract nodes do not need to access the data storage node again, and the target intelligent contract can be simulated and executed by utilizing the read-write set; and if the simulation execution result returned by the other intelligent contract nodes is consistent with the previous pre-execution result, the verification is determined to be passed. Therefore, on one hand, the safety of intelligent contract execution can be improved through logic verification. On the other hand, the intelligent contract node for logic verification does not need to acquire the data state again, so that the times of accessing the data storage node are reduced. On the other hand, the contract verification and the data verification in the transaction process are decoupled and divided into two independent parts; the node equipment in the contract management system is only responsible for contract logic verification, and the node equipment in the data storage system is only responsible for data verification; the verification execution logic is simplified, and the verification operation period is shortened.
Corresponding to the foregoing embodiment of the intelligent contract verification method, the present specification further provides an embodiment of an intelligent contract verification apparatus. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. The software implementation is taken as an example, and as a logical device, the device is formed by reading corresponding computer business program instructions in the nonvolatile memory into the memory for operation through the processor of the device in which the device is located. In terms of hardware, as shown in fig. 8, the hardware structure diagram of the device in which the intelligent contract checking apparatus of this specification is located is shown, except for the processor, the network interface, the memory, and the nonvolatile memory shown in fig. 8, the device in which the apparatus is located in the embodiment usually checks an actual function according to the intelligent contract, and may further include other hardware, which is not described again.
Referring to fig. 9, a block diagram of an intelligent contract checking apparatus provided in an embodiment of the present disclosure, where the apparatus corresponds to the embodiment shown in fig. 6, includes:
a first receiving unit 410, where the data storage node receives a target transaction initiated by a client;
a broadcasting unit 420, which broadcasts the target transaction to any one intelligent contract node;
a second receiving unit 430, configured to receive a pre-execution result returned after the intelligent contract node pre-executes the target intelligent contract corresponding to the target transaction;
the sending unit 440 is used for sending the pre-execution result to other intelligent contract nodes so that the other intelligent contract nodes simulate to execute the target intelligent contract;
the checking unit 450 determines that the pre-execution result passes the checking when the simulation execution result returned by the other node is consistent with the pre-execution result.
Optionally, the method further includes:
and the consensus unit is used for sending the pre-execution result to other node equipment in the data storage system for consensus.
Optionally, the pre-execution result is a result set formed by packing read-write sets generated in the process of pre-executing the target intelligent contract by the intelligent contract node; the simulation execution result is a result set formed by packaging read-write sets generated in the process of simulating and executing the target intelligent contract by other intelligent contract nodes; the result set carries the signatures of the node devices.
Optionally, the intelligent contract node is located in a contract management system, and the contract management system is a blockchain system for storing intelligent contracts;
the data storage nodes are located in a data storage system, and the data storage system is a block chain system for storing data states.
Referring to fig. 10, a block diagram of an intelligent contract checking apparatus provided in an embodiment of the present disclosure, where the apparatus corresponds to the embodiment shown in fig. 7, includes:
the receiving unit 510, where the intelligent contract node receives a pre-execution result sent by the data storage node; the pre-execution result is a result obtained after other intelligent contract nodes respond to a target transaction initiated by a client and pre-execute a target intelligent contract corresponding to the target transaction;
the execution unit 520 simulates and executes the target intelligent contract according to the pre-execution result, and returns a simulated pre-execution result obtained after the target intelligent contract is simulated and executed to the data storage node; for the data storage node to verify.
Optionally, the verifying the data storage node specifically includes:
the data storage node compares the pre-execution result with a simulation pre-execution result;
and if the pre-execution result is consistent with the simulation pre-execution result, determining that the verification is passed.
Optionally, the pre-execution result is a result set formed by packing read-write sets generated in the process of pre-executing the target intelligent contract by the intelligent contract node; the simulation execution result is a result set formed by packaging read-write sets generated in the process of simulating and executing the target intelligent contract by other intelligent contract nodes; the result set carries the signatures of the node devices.
Optionally, the simulating and executing the target intelligent contract according to the pre-execution result, and returning a simulated pre-execution result obtained after the target intelligent contract is simulated and executed to the data storage node, specifically including:
simulating and executing the target intelligent contract according to the read-write centralized data of the pre-execution result;
and returning a simulation result set simulating the execution target intelligent contract to the data storage node.
Optionally, the other intelligent contract nodes respond to the target transaction initiated by the client, and pre-execute the result obtained after the target transaction corresponds to the target intelligent contract, which specifically includes:
and other intelligent contract nodes respond to the target transaction initiated by the client, and if the target intelligent contract corresponding to the target transaction is pre-executed needs a data state, the data state is acquired from the data storage equipment according to the transaction parameters carried in the target transaction.
Optionally, the intelligent contract node is located in a contract management system, and the contract management system is a blockchain system for storing intelligent contracts;
the data storage nodes are located in a data storage system, and the data storage system is a block chain system for storing data states.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
Fig. 9 above describes the internal functional modules and the structural schematic of the execution apparatus of the intelligent contract in the blockchain, and the execution subject may be an electronic device, which includes:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured to:
the data storage node receives a target transaction initiated by a client;
broadcasting the target transaction to any one intelligent contract node;
receiving a pre-execution result returned after the intelligent contract node pre-executes the target intelligent contract corresponding to the target transaction;
sending the pre-execution result to other intelligent contract nodes so that the other intelligent contract nodes simulate and execute the target intelligent contract;
and when the simulation execution result returned by the other nodes is consistent with the pre-execution result, determining that the pre-execution result passes verification.
Fig. 10 above describes an internal functional module and a structural schematic of the checking apparatus of the intelligent contract in the blockchain, and the substantial execution subject may be an electronic device, including:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured to:
the intelligent contract node receives a pre-execution result sent by the data storage node; the pre-execution result is a result obtained after other intelligent contract nodes respond to a target transaction initiated by a client and pre-execute a target intelligent contract corresponding to the target transaction;
simulating and executing the target intelligent contract according to the pre-execution result, and returning a simulated pre-execution result obtained after the target intelligent contract is simulated and executed to the data storage node; for the data storage node to verify.
In the above embodiments of the electronic device, it should be understood that the Processor may be a Central Processing Unit (CPU), other general-purpose processors, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, and the aforementioned memory may be a read-only memory (ROM), a Random Access Memory (RAM), a flash memory, a hard disk, or a solid state disk. The steps of a method disclosed in connection with the embodiments of the present invention may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the embodiment of the electronic device, since it is substantially similar to the embodiment of the method, the description is simple, and for the relevant points, reference may be made to part of the description of the embodiment of the method.
Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This specification is intended to cover any variations, uses, or adaptations of the specification following, in general, the principles of the specification and including such departures from the present disclosure as come within known or customary practice within the art to which the specification pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.
It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.