WO2023274409A1 - Method for executing transaction in blockchain system and blockchain node - Google Patents

Abstract

Embodiments of the present description provide a method for executing a transaction in a blockchain system and a blockchain node. A contract is called in a transaction, and an interface function used for confirming the existence of a variable is called in a contract. The method is executed by a blockchain node and comprises: executing an interface function; and before returning a result of the interface function, executing a contract according to a preset existence of a variable.

Description

Method and blockchain node for executing transactions in blockchain system

This application claims the priority of the Chinese patent application with the application number 2021107489771 and the application title "method and blockchain node for executing transactions in a blockchain system" submitted to the State Intellectual Property Office of China on July 02, 2021, The entire contents of which are incorporated by reference in this application.

technical field

The embodiment of this specification relates to the technical field of blockchain, and more specifically, relates to a method and blockchain nodes for executing transactions in a blockchain system.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. Blockchain is a chained data structure that combines data blocks in a sequential manner in chronological order, and is a cryptographically guaranteed non-tamperable and unforgeable distributed ledger. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application.

In a blockchain system such as Ethereum, smart contracts are allowed to be deployed and invoked in the blockchain system. In many smart contracts, in order to prevent repeated creation of the same object or variable (hereafter denoted as key), before creating an object, it will first try to check the existence of the object, and only when the object does not exist will the subsequent operate.

Contents of the invention

The embodiment of this specification aims to provide a more efficient method for executing transactions in the blockchain system, so that while executing the interface for confirming the existence of the key, the transaction is executed in parallel according to the preset existence of the key, reducing The time consumption caused by the key existence check improves the system efficiency.

In order to achieve the above purpose, the first aspect of this specification provides a method for executing a transaction in a blockchain system, in which a contract is called in the transaction, and an interface function for confirming the existence of variables is called in the contract, and the method consists of Blockchain node execution, including:

Execute the interface function;

Before the result of the interface function is returned, the contract is executed according to the preset existence of the variable.

The second aspect of this specification provides a block chain node, the block chain node is used to execute the transaction, the contract is called in the transaction, the interface function used to confirm the existence of the variable is called in the contract, the block Chain nodes include:

a first execution unit, configured to execute the interface function;

The second execution unit is configured to execute the contract according to the preset existence of the variable before the result of the interface function is returned.

A third aspect of the present specification provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed in a computer, the computer is instructed to execute any one of the methods described in the first aspect.

The fourth aspect of this specification provides a blockchain node, including a memory and a processor, the memory stores executable code, and when the processor executes the executable code, any item method.

Through the transaction execution scheme provided by the embodiment of this specification, the execution body that executes the transaction can use the interface provided by the platform to check the existence of the key when executing the transaction for the first time, and send the key existence key to the execution body that executes the platform code. Check the request, and after the platform receives the request, according to the preset existence of the key, let the transaction execution body continue to execute the transaction, and the execution body that executes the platform code performs storage access after receiving the above request and according to the result of the storage access Determine whether to re-execute the transaction, and notify the executive that executed the transaction. In the case where the contract developer can predict the existence of the key with a high accuracy rate, that is, in the case where the actual existence of the key is the same as the preset existence, there is a high probability that there is no need to re-execute the transaction, which can reduce the execution of transactions In the process of waiting for the result of storage access, the transaction execution speed is improved and the system efficiency is improved. In addition, the blockchain platform can reduce the number of generation and sending of system requests by providing interfaces that combine key existence checks and other predetermined operations, and improve system efficiency.

Description of drawings

By describing the embodiments of this specification in conjunction with the accompanying drawings, the embodiments of this specification can be made clearer:

FIG. 1 shows a block chain architecture diagram applied in the embodiment of this specification;

Fig. 2 shows the architecture diagram of the blockchain node provided by the embodiment of this specification;

Fig. 3 shows a flow chart of a method for executing a transaction in a blockchain provided by an embodiment of this specification;

Fig. 4 shows a flow chart of a method for executing a transaction in a blockchain provided by an embodiment of this specification;

Fig. 5 shows an architecture diagram of a blockchain node provided by the embodiment of this specification.

detailed description

Embodiments of this specification will be described below with reference to the accompanying drawings.

Fig. 1 shows a block chain system architecture diagram applied in the embodiment of this specification. As shown in Figure 1, the block chain system (hereinafter referred to as block chain) for example includes A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P has a total of 16 full nodes. The connection between nodes schematically represents a P2P (Peer to Peer, point-to-point) connection. These nodes store a full amount of books, that is, they are responsible for storing all transactions, smart contracts and various states. Among them, each full-scale node in the blockchain generates the same state in the blockchain system by executing the same transaction, that is, each full-scale node in the blockchain performs the same operation and stores the same state database. The following describes the execution of a transaction in a node in the blockchain as an example.

It can be understood that the block chain shown in FIG. 1 is only exemplary, and the embodiment of this description is not limited to be applied to the block chain shown in FIG. 1 , for example, it can also be applied to a block chain system including sharding.

In addition, although it is shown in FIG. 1 that the blockchain includes 16 full nodes, the embodiment of this specification is not limited thereto, but may include other numbers of full nodes. Specifically, the nodes contained in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. The Byzantine fault tolerance requirement can be understood as that there may be Byzantine nodes inside the blockchain, but the blockchain does not reflect Byzantine behavior externally. Generally, some Byzantine fault-tolerant algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the practical Byzantine fault-tolerant algorithm PBFT (Practical Byzantine Fault Tolerance).

Fig. 2 shows the architecture diagram of the blockchain node provided by the embodiment of this specification. As shown in FIG. 2 , a block chain node includes a processing unit 21 and a storage unit 22 . In one embodiment, the blockchain node is a single server, the processing unit 21 can be a plurality of CPUs included in the server, the storage unit 22 can be a storage medium (such as storage) included in the server, and the storage unit 22 For example, a block database and a state database are stored in it. Among them, the block database is used to store the block data in the blockchain, and the state database is used to store the state data in the blockchain. In another embodiment, the blockchain node is a server cluster, the processing unit 21 can be a CPU included in any server in the blockchain node, and the storage unit 22 can be a CPU included in any server in the blockchain node. storage medium. In another embodiment, the blockchain node includes one or more servers and computing hardware (such as FPGA) connected to the server. In addition to the CPU in the server, the processing unit 21 can also include a CPU connected to the server. FPGA. In addition, in the case where the processing unit 21 is the CPU in the server, TEE technology (such as SGX of Intel, SEV of AMD, TrustZone (trusted area) of ARM, etc.) can be used in the server, so that the processing unit 21 can be in the TEE Perform processing such as executing transactions. Among them, in the above-mentioned various embodiments, when the processing unit 21 executes the contract called in the transaction, it usually executes the contract in a virtual machine, and the virtual machine is used to provide an execution environment for the contract. context, a cache for storing data during execution, etc.

In view of the fact that many blockchain platforms and applications are built based on the underlying technology of Ethereum, here we take Ethereum as an example to illustrate the state database. Of course, blockchain systems based on other blockchain technologies may also be applicable to the embodiments of this specification, such as Fabric-based hyperledger (Hyperledger) and enterprise operating system (Enterprise Operating System, EOS), Quorum, Corda, etc. No longer.

Compared with the Bitcoin network, Ethereum has expanded, adopting the account system and world state, and can record the balance and state of the account directly through the account in the state database. Accounts in Ethereum can be divided into two types: Externally owned account: user’s account, such as the account of the owner of Ethereum; contract account: stores the executed smart contract code and the status of the smart contract code value, usually only activated by external account calls. Among them, the value of the state in the smart contract code is the value of the variable defined in the smart contract, and the value of the variable is stored in the state storage of the contract in the state database, for example, stored in the data structure of the MPT tree.

Referring to FIG. 2 , when a blockchain node executes a transaction, the processing unit 21 may assign an execution body (for example, thread 1 ) to execute the transaction. Wherein, the execution body may be implemented by one of the multiple CPUs in the server, or by the aforementioned FPGA. Among them, in the case that thread 1 is implemented by CPU, thread 1 can execute transactions in the TEE environment. In the case of the transaction calling contract, the TEE may be implemented in the form of a virtual machine. When the state database in the storage unit 22 needs to be accessed during the execution of the transaction, in related technologies, thread 1 can send a storage access request to thread 2, and wait for thread 2 to return the access result to the state database, or thread 1 The execution of the transaction can be suspended, and the state database can be accessed, and the execution of the transaction can be resumed after the access result is obtained.

Among them, in many contracts, including the check of the existence of the key. For example, in order to prevent repeated creation of a key (repeated key creation will cause the previous value of the key to be overwritten), (set: create and update) will first check the existence of the key before creating the key, and only execute the creation if it does not exist operate. Or, in order to confirm that the delete action is valid ("Delete a key that does not exist" indicates that the system is abnormal), before deleting the key, first check the existence of the key, and only execute the delete operation if it exists. When the blockchain node executes the transaction that calls the contract, when it is necessary to check the existence of the key, the thread 1 that executes the transaction can send the key existence check request to the thread 2, so that the thread 2 can read the value of the key And return the read result to determine the existence of the key. When reading the key, thread 2 sends the read request to the state database in the hard disk, and waits for the hard disk to return the read result. Thread 1 needs to obtain the reading result through thread 2 before continuing to execute the transaction, which takes a lot of time and reduces the execution efficiency of the transaction.

The embodiment of this specification provides a solution for executing a transaction. When the thread 1 that executes the transaction needs to check the existence of the key, based on the interface provided by the blockchain platform to confirm the existence of the key, it sends a message to the thread 2 to check the existence of the key. The request for a security check executes the transaction based on the preset existence of the key. In the case where the preset existence is likely to be the same as the actual existence of the key, there is a high probability that there is no need to re-execute the transaction, and thread 1 can execute the transaction while thread 2 is performing storage access, which reduces the transaction execution time and improves the transaction efficiency. execution efficiency. It can be understood that in the embodiment of this specification, it is not limited to execute the key existence check interface and transaction in parallel through two execution bodies, but any method that can realize parallel execution can be adopted, for example, two execution bodies in one execution body can be used The module executes the key existence check interface and the transaction. After one module executes the key existence check interface, it sends an access request to the storage (such as a hard disk), so that another module can execute the transaction in parallel while waiting for the result of the access. Follow up. In the following, the parallel execution of two executives will be taken as an example for description.

The scheme for executing a transaction provided by the embodiment of this specification will be described in detail below.

Fig. 3 shows a flow chart of a method for executing a transaction in a blockchain provided by an embodiment of this specification, the flow is executed by threads 1 and 2 in the blockchain node, wherein thread 1 is used to execute transactions, and thread 2 is used to execute the code provided by the blockchain platform, which is used to support the execution of the transaction. A contract is called in the transaction, and an interface function for confirming the existence of variables is called in the contract.

Referring to FIG. 3 , first, thread 1 executes step S301 to execute a transaction and generate a key existence confirmation request.

When executing a transaction that calls a contract, before performing operations related to the key defined in the contract, it is necessary to first confirm the existence of the key. For example, when executing a transaction that calls a contract, before adding a variable, it can first be confirmed whether the variable does not exist, or before deleting the variable, it can first be confirmed whether the variable exists.

In the first case, an interface (ie, a function) for confirming the existence of variables can be provided in the blockchain platform. Assume that a new key will be added to the contract called in the transaction, and the interface used to confirm the existence of the variable is called before the addition to check the existence of the key to confirm whether the key does not exist. Specifically, the contract includes, for example, the following instructions:

If(KeyexistCheck(key1))

{KeyexistHandle(key1)},

Else SetKV(key1, new_value);

Among them, the KeyexistCheck() function is an interface provided by the blockchain platform to check whether the key exists, and the contract can directly call this interface to check the existence of the key. The KeyexistHandle() function is a function defined in the contract, which is used to perform predetermined operations when the key existence returned by the KeyexistCheck() function exists, such as returning transaction failure to the user. "Else" indicates that the SetKV() function is executed when the key existence returned by the KeyexistCheck() function does not exist. The SetKV() function is used to create a new key (such as key1), where new_value is the initial value of key1. After thread 1 starts to execute the contract, after executing the above-mentioned KeyexistCheck() function contained in the contract, it can generate a request corresponding to this function for confirming the existence of the key and send it to thread 2.

In the second case, the AddNewKey interface can be provided in the blockchain platform, which is used to check the existence and add the key when it is determined that the key does not exist. When the key needs to be added in the contract, the above interface can be called in the contract. Similar to the first case above, the contract can be set to perform predetermined operations when the existence of the key returned by the AddNewKey interface exists, such as returning a transaction failure to the user. After thread 1 executes the AddNewKey interface, it can generate a corresponding request for executing the AddNewKey interface to send to thread 2. Thread 2 sends an access request for the key to the storage according to the request, and while waiting for the access result, the operation of adding the key can be performed in parallel. The operation of adding a Key may include, according to the incoming parameters of AddNewKey, recording the key identifier and the initial value of the key in memory for subsequent updates to the storage, for example, updating to the storage after all transactions in the block are executed middle. Among them, when the access result indicates that the existence of the key exists, thread 2 can delete the operation result of the operation of adding the key that has been executed, or can terminate the execution of the contract according to the settings in the AddNewKey interface, end the transaction, and return transaction failed.

In the third case, it is assumed that the existing key will be deleted in the contract called in the transaction, and the interface provided by the blockchain platform for determining the existence of the variable is called before the deletion to check the existence of the key. Check to see if the key exists. Specifically, the contract includes, for example, the following instructions:

If(KeynotexistCheck(key1))

{KeynotexistHandle(key1)},

Else, DelKV(key1);

Among them, the KeynotexistCheck() function is an interface provided by the blockchain platform to check whether the key (such as key1 shown in the code) does not exist, and the interface can be directly called in the contract. The KeynotexistHandle() function is a function defined in the contract, which is used to perform predetermined operations when the existence of the key returned by the KeynotexistCheck() function is non-existent, such as returning a transaction failure to the user. "Else" indicates that the DelKV() function is executed when the key existence returned by the KeynotexistCheck() function exists. The DelKV() function is used to delete the key. After the thread 1 in the processing unit 21 starts to execute the contract in the virtual machine, after executing the above-mentioned KeynotexistCheck() function contained in the contract, it can generate a request for confirming the existence of the key and send it to the thread 2.

In the fourth case, the DelKey interface can be provided in the blockchain platform, which is used to check the existence of the key and delete the key when it is determined that the key exists. When the key needs to be deleted in the contract, the above interface can be called in the contract. After thread 1 in the blockchain node executes the DelKey interface, it can generate a corresponding request to execute the DelKey interface to send to thread 2. Thread 2 sends an access request to the storage according to the request, and waits for the result of the access. At the same time, the operation of deleting the Key can be performed in parallel. Similar to the above, the operation of deleting the key can be performed in memory.

Wherein, in the above-mentioned second and fourth cases, two operations of key existence check and addition/deletion are performed through an interface, and thread 1 may only send a system request to thread 2 when calling the interface. In the case that thread 1 is implemented in FPGA, the communication between thread 1 and thread 2 is the communication between two hardwares (i.e. server and FPGA), and the communication cost is relatively high, so the above-mentioned AddNewkey interface and DelKey interface can be greatly improved. Reduce the resource overhead of generating and sending system requests and improve system efficiency.

In addition, in the case where the interface code and contract code are executed by module 1 and module 2 in one thread, assuming that module 1 is in SGX, when module 1 needs to send a system request to module 2, module 1 needs to perform Switching to switch to module 2 has a high switching cost, so the resource overhead of generating and sending system requests can also be greatly reduced through the above-mentioned AddNewkey interface and DelKey interface.

In step S302, thread 1 sends the generated key existence confirmation request to thread 2.

In step S303, thread 1 continues to execute the transaction according to the preset existence of the key.

In one embodiment, in the contract called in the transaction, in addition to the above-mentioned Key existence check interface, it also includes a query for the number of transaction execution times after the interface, for example, the transaction defines the number of transaction execution times parameter T, the initial value of the parameter is set to T=1, thread 1 can determine that this execution of the transaction is the first execution of the transaction by querying the value of the parameter T, thus, thread 1 executes step S303 after making the determination, Continue to execute the transaction according to the preset existence of the key. For example, referring to the code of the above-mentioned KeyexistCheck interface, thread 1 can use the existence of key1 corresponding to the Else branch as the preset existence, thereby executing the Else branch in the contract. For the above-mentioned AddNewKey interface, KeynotexistCheck interface and DelKey interface, thread 1 can similarly execute the transaction according to the preset existence (that is, execute the contract called in the transaction).

In another embodiment, the code provided by the platform (such as the above-mentioned interface for key existence check) may include the query of the number of transaction executions, for example, the code provided by the platform may define the parameter N indicating the number of transaction executions , the initial value of the parameter is set to N=1, thread 2 can query the value of parameter N after receiving the key existence confirmation request from thread 1, so as to determine that this execution of the transaction is the first execution, thus, thread 2 can immediately A confirmation response to the preset existence is returned to thread 1, and step S304 is executed at the same time to perform storage access to confirm the existence of the key. After thread 1 receives the confirmation response from thread 2, it executes step S303, and continues to execute the transaction according to the preset existence of the key.

Specifically, for the first case above, when thread 1 executes step S303, it continues to execute the subsequent code in the contract, that is, the key creation operation in the transaction, assuming that key1 does not exist. For example, as shown in the code in the first case above, thread 1 can continue to execute the code SetKV(key1, new_value) in the contract, that is, create key1 in the storage.

In the above second case, since thread 2 performs the operation of creating key1 when it is determined that key1 does not exist, and the operation of creating key1 performed by thread 2 will not affect the subsequent operations in thread 1's execution of the transaction, therefore, thread 1 You can follow the thread 2 assumption that key1 does not exist and key1 has been created, and continue to execute subsequent operations in the contract called by the exchange.

In the above third case, thread 1 continues to execute the subsequent code in the contract assuming that the key exists, that is, the operation of deleting the key in the contract. For example, as shown in the code in the third case above, thread 1 may execute the code "DelKV(key1)" according to the existence of key1, that is, delete "key1" in the state database.

In the above fourth case, similar to the second case, thread 1 can continue to perform subsequent operations in the transaction assuming that the key exists and has been deleted.

Thread 2 performs storage access in step S304 to confirm the existence of the key.

Specifically, thread 2 can access the state database in the hard disk to read the value of key1 from the state database to confirm whether key1 exists. If the value of key1 is read, it can be confirmed that key1 already exists. key1 value, it can be confirmed that key1 does not exist. After thread 2 determines the existence of key1 according to the storage access result, it may store the existence of key1 in the memory.

In step S305, thread 1 sends a system service request to thread 2.

Thread 1 may generate a new system service request in the process of continuing to execute the transaction and needs to send it to thread 2 to request system service. The system service requests include, for example, other key existence confirmation requests, transaction completion requests, and other requests. It can be understood that since thread 2 can execute step S306 at any time before the end of the transaction, it is also possible to execute step S306 before thread 1 sends the system service request. Therefore, step S305 is shown with a dotted line in FIG. 3 , indicating that this step is Optional step.

In step S306, thread 2 determines whether to re-execute the transaction.

Thread 2 can execute this step at any time before the end of the transaction, for example, after receiving any system service request, to determine whether to re-execute the transaction. At this time, if thread 2 has not obtained the result of the above storage access, assuming that the system service request is the existence confirmation request of other keys, thread 2 can determine not to re-execute the transaction, so that thread 1 and thread 2 can continue with the above key1. Handle the same process; assume that the system service request is a transaction completion request, that is, thread 1 has executed all the processing in the transaction, and requests to end the execution of the transaction. Thread 2 needs to wait for the result of the storage access, and obtain the result of the storage access Then confirm the existence of key1 to determine whether to re-execute the transaction.

If thread 2 has obtained the result of the storage access and stored the existence of key1 in memory, it can read the existence of key1 from memory and compare the existence of key1 with the above preset existence to determine whether Re-execute the transaction. If the existence of key1 is the same as the preset existence, there is no need to re-execute the transaction. Specifically, if the system server request is an existence confirmation request for other keys, thread 1 and thread 2 can continue to perform the same processing as the above-mentioned processing for key1; assuming that the system service request is a transaction completion request, thread 2 can complete the transaction. processing, and notify thread 1 to end the execution of the transaction.

If the existence of key1 is different from the preset existence, thread 2 executes step S307, and sends a notification to thread 1 to re-execute the transaction.

After thread 1 receives the notification of re-executing the transaction, it executes step S308, discards the execution result data generated during the previous execution of the transaction, and re-executes the transaction. In the process of re-executing the transaction, thread 1 may generate a key (namely key1) existence confirmation request again, and then perform step S309 to send the key existence confirmation request to thread 2.

As mentioned above, in one embodiment, after thread 1 receives the notification of re-executing the transaction, it can add 1 to the parameter T defined in the contract to indicate that the execution of the transaction is the second execution, that is, not the first time Execution, or in another embodiment, after thread 2 sends the notification of re-execution of the transaction, it may add 1 to the parameter N defined in the platform code to indicate that the execution of the transaction is the second execution. Therefore, after thread 1 sends a key existence request to thread 2, it can determine that the execution of the transaction is not the first execution according to the value of parameter T, so it waits for thread 2 to return the response to the request. After thread 2 receives the key existence confirmation request, it can determine that the execution of the transaction is not the first execution according to the value of parameter N. Therefore, thread 2 obtains the existence of key1 from the memory, and executes step S310, according to the existence A request response is returned, and it can be understood that the response here indicates that the existence of key1 is different from the preset existence.

After thread 1 receives the response returned by thread 2, it executes step S311 to end the execution of the transaction. Since the response returned by thread 2 indicates that the existence of key1 is different from the preset existence, the execution of the transaction fails, thread 1 ends the execution of the transaction, and returns the failure of the execution of the transaction to the user.

Figure 4 shows a method for executing a transaction in a blockchain system provided by an embodiment of this specification, in which a contract is called, and an interface function for confirming the existence of a variable is called in the contract, and the method is determined by the block Block chain node execution, including:

Step S401, execute the interface function;

Step S403, before the result of the interface function is returned, execute the contract according to the preset existence of the variable.

For details of step S401 and step S403 in FIG. 4 , reference may be made to the specific description of step S304 and step S303 above, which will not be repeated here.

In an implementation manner, the executing the interface function includes: sending an access request to storage to confirm the existence of the variable.

In an implementation manner, the executing the interface function further includes: performing predetermined processing on the variable according to the preset existence before waiting for the storage to return a result to the access request.

In an implementation manner, the interface function is used to: add the variable in the storage when it is confirmed that the variable does not exist, or delete the variable in the storage when it is confirmed that the variable exists.

In an implementation manner, the method further includes, before the execution of the transaction is completed, obtaining the access result of the access request, and determining the existence of the variable and the preset existence according to the access result In the case of different properties, it is determined to re-execute the transaction.

In one implementation, the contract defines a first parameter indicating the number of transaction execution times, and executing the contract according to the preset existence of the variable includes determining that the transaction is executed according to the first parameter Executing the contract is executed for the first time, executing the contract according to the preset existence of the variable, and the method further includes updating the first parameter after determining to re-execute the transaction.

In an implementation manner, the method further includes, when starting to execute the interface function in the re-execution of the transaction, if the transaction is determined to be executed not for the first time according to the first parameter, when obtaining the execution After the existence of the variable is returned by the interface function, the contract is executed according to the existence of the variable.

In an implementation manner, the code of the interface function defines a second parameter indicating the number of transaction execution times, and the execution of the interface function includes determining that the execution of the transaction is the first execution according to the second parameter Afterwards, returning a confirmation response to the preset existence, the executing the contract according to the preset existence of the variable includes executing the contract according to the preset existence of the variable according to the confirmation response, The method also includes, after determining to re-execute the transaction, updating the second parameter.

Fig. 5 shows an architecture diagram of a block chain node provided by the embodiment of this specification, the block chain node is used to execute a transaction, the contract is called in the transaction, and the contract is called in the contract to confirm the existence of the variable Interface function, the blockchain node includes:

The first execution unit 51 is configured to execute the interface function;

The second execution unit 52 is configured to execute the contract according to the preset existence of the variable before the result of the interface function is returned.

In an implementation manner, the first execution unit 51 is further configured to: send an access request to the storage to confirm the existence of the variable.

In an implementation manner, the first execution unit 51 is further configured to: perform predetermined processing on the variable according to the preset existence before waiting for the storage to return a result to the access request.

In an implementation manner, the interface function is used to: add the variable in the storage when it is confirmed that the variable does not exist, or delete the variable in the storage when it is confirmed that the variable exists.

In an implementation manner, the block chain node further includes a determination unit 53, configured to obtain the access result of the access request before the execution of the transaction is completed, and determine the value of the variable according to the access result If the existence is different from the preset existence, it is determined to re-execute the transaction.

In one implementation, the contract defines a first parameter indicating the number of transaction execution times, and the second execution unit 52 is further configured to determine that the execution of the transaction is the first execution according to the first parameter , execute the contract according to the preset existence of the variable, and the block chain node further includes an updating unit 54, configured to update the first parameter after it is determined to re-execute the transaction.

In an implementation manner, the block chain node further includes a re-execution unit, configured to start executing the interface function in the re-execution of the transaction, when it is determined according to the first parameter that the transaction is not In the case of the first execution, after obtaining the existence of the variable returned by executing the interface function, execute the contract according to the existence of the variable.

In one implementation, the code of the interface function defines a second parameter indicating the number of transaction execution times, and the first execution unit 51 is further configured to determine that the execution of the transaction is the first according to the second parameter. After the second execution, return a confirmation response to the preset existence, and the second execution unit 52 is also used to execute the contract according to the preset existence of the variable according to the confirmation response, and the update unit 54 is further configured to update the second parameter after it is determined to re-execute the transaction.

The embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed in a computer, the computer is instructed to execute the methods shown in FIG. 3 and FIG. 4 .

The embodiment of this specification also provides a block chain node, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, the methods shown in Figure 3 and Figure 4 are implemented .

It should be understood that descriptions such as "first" and "second" in this document are only used to distinguish similar concepts for the sake of simplicity of description, and do not have other limiting functions.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Those of ordinary skill in the art should further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the hardware and software interchangeability, the composition and steps of each example have been generally described in terms of functions in the above description. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Those of ordinary skill in the art may implement the described functionality using different methods for each particular application, but such implementation should not be considered as exceeding the scope of the present application. Among them, the software module can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or technical field Any other form of storage medium known in the art.

The specific embodiments described above have further described the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above descriptions are only specific embodiments of the present invention and are not intended to limit the scope of the present invention. Protection scope, within the spirit and principles of the present invention, any modification, equivalent replacement, improvement, etc., shall be included in the protection scope of the present invention.

Claims (18)

A method for executing a transaction in a blockchain system, wherein a contract is called in the transaction, and an interface function for confirming the existence of a variable is called in the contract, and the method is executed by a blockchain node, including: Execute the interface function; Before the result of the interface function is returned, the contract is executed according to the preset existence of the variable. The method according to claim 1, wherein the executing the interface function comprises: sending an access request to storage to confirm the existence of the variable. The method according to claim 2, the executing the interface function further comprising: performing predetermined processing on the variable according to the preset existence before waiting for the storage to return a result to the access request. The method according to claim 3, wherein the interface function is used to: add the variable in storage if it is confirmed that the variable does not exist, or delete it in the storage if it is confirmed that the variable exists said variable. The method according to claim 2, further comprising, before the execution of the transaction is completed, obtaining the access result of the access request, and determining the existence of the variable according to the access result and the predetermined If there is a difference, it is determined to re-execute the transaction. The method according to claim 5, wherein a first parameter indicating the number of transaction execution times is defined in the contract, and executing the contract according to the preset existence of the variable comprises, in accordance with the first parameter After determining that the execution of the transaction is the first execution, executing the contract according to the preset existence of the variable, the method further includes, after determining to re-execute the transaction, updating the first parameter. The method according to claim 6, further comprising: when the interface function is started to be executed during the re-execution of the transaction, if the transaction is determined to be not executed for the first time according to the first parameter, when obtaining the executed value After checking the existence of the variable returned by the interface function, execute the contract according to the existence of the variable. According to the method according to claim 5, a second parameter indicating the number of transaction executions is defined in the code of the interface function, and the execution of the interface function includes determining that the execution of the transaction is the first according to the second parameter After the second execution, return a confirmation response to the preset existence, the execution of the contract according to the preset existence of the variable includes, according to the confirmation response, execute the contract, the method further includes, after determining to re-execute the transaction, updating the second parameter. A block chain node, the block chain node is used to execute a transaction, a contract is called in the transaction, and an interface function for confirming the existence of a variable is called in the contract, and the block chain node includes: a first execution unit, configured to execute the interface function; The second execution unit is configured to execute the contract according to the preset existence of the variable before the result of the interface function is returned. The blockchain node according to claim 9, wherein the first execution unit is further configured to: send an access request to the storage to confirm the existence of the variable. According to the blockchain node according to claim 10, the first execution unit is further configured to: perform predetermined processing on the variable according to the preset existence before waiting for the storage to return a result to the access request . The blockchain node according to claim 11, wherein the interface function is used to: add the variable in the storage when it is confirmed that the variable does not exist, or add the variable in the storage when it is confirmed that the variable exists The variable is deleted from storage. According to the blockchain node according to claim 10, the blockchain node further comprises a determining unit, configured to acquire the access result of the access request before the execution of the transaction is completed, and determine the access result according to the access result If the existence of the variable is different from the preset existence, it is determined to re-execute the transaction. The blockchain node according to claim 13, wherein a first parameter indicating the number of transaction executions is defined in the contract, and the second execution unit is also used to determine the transaction execution time according to the first parameter After the execution of the first execution, the contract is executed according to the preset existence of the variable, and the block chain node also includes an update unit, which is used to update the first parameter after determining to re-execute the transaction . The blockchain node according to claim 14, further comprising a re-execution unit, configured to determine that the transaction is not the first time according to the first parameter when the interface function is started to be executed during the re-execution of the transaction In the case of execution, after obtaining the existence of the variable returned by executing the interface function, execute the contract according to the existence of the variable. According to the blockchain node according to claim 14, a second parameter indicating the number of transaction executions is defined in the code of the interface function, and the first execution unit is also used to determine the The execution of the transaction is to return a confirmation response to the preset existence after the first execution, and the second execution unit is also used to execute the contract according to the preset existence of the variable according to the confirmation response, so The updating unit is further configured to update the second parameter after it is determined to re-execute the transaction. A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed in a computer, it causes the computer to perform the method described in any one of claims 1-8. A block chain node, comprising a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, the method according to any one of claims 1-8 is realized.

Images