Method and apparatus for providing atomic transactions on a blockchain

Abstract

Disclosed herein are methods, devices, and apparatus for providing atomic transactions on a blockchain, including a computer program stored on a computer-readable medium. The method includes: receiving a transaction submitted to a blockchain; determining whether the transaction is a fulfillment transaction; in response to determining that the transaction is a fulfillment transaction, identifying a proposed transaction corresponding to the fulfillment transaction; determining whether the proposed transaction is valid and whether the fulfillment transaction satisfies execution conditions specified in the proposed transaction; and in response to determining that the proposed transaction is valid and that the fulfillment transaction satisfies the execution conditions specified in the proposed transaction, executing the fulfillment transaction and the proposed transaction.

Description

Technical Field

[0001] This document relates generally to computer technology, and more particularly to methods and devices for providing atomic transactions on a blockchain. Background Art

[0002] Blockchain systems, also known as distributed ledger systems (DLSs) or consensus systems, enable participating entities to store data securely and immutably. Without reference to any specific use case, blockchain systems can include any DLS and can be used for public, private, and consortium blockchain networks. Public blockchain networks are open to all entities to use the system and participate in the consensus process. Private blockchain networks are provided for specific entities, who centrally control read and write permissions. Consortium blockchain networks are provided for a select group of entities, who control the consensus process and include an access control layer.

[0003] The blockchain system is implemented using a peer-to-peer (P2P) network, in which nodes communicate directly with each other, for example, without the need for a fixed central server. Each node in the P2P network can initiate communication with another node in the P2P network.

[0004] A blockchain system maintains one or more blockchains. A blockchain is a data structure used to store data (e.g., transaction data) that is protected from tampering and manipulation by malicious parties. A blockchain system can support the execution of one or more smart contracts. Each smart contract is a computer protocol in the form of computer code that is incorporated into a blockchain to facilitate, verify, or enforce the negotiation or execution of a contract.

[0005] Blockchain use cases may require two transactions to be processed atomically, meaning that both transactions must either succeed or fail, with no partial processing allowed. However, existing blockchain system implementations do not have built-in mechanisms to support atomic transactions.

[0006] To achieve atomicity, a separate, custom smart contract may need to be deployed as a proxy contract. For example, if a first user wants to exchange a first asset owned by the first user for a second asset owned by a second user, the first user may create a first transaction on the first contract to transfer the first asset from the first user to the second user. The first user may then send the first transaction to the proxy contract. Similarly, the second user may create a second transaction on the second contract to transfer the second asset from the second user to the first user. The second user may then send the second transaction to the proxy contract. After receiving both transactions, the proxy contract may call the first and second contracts to execute both transactions.

[0007] As the number of proxy contracts increases, the consumption of storage space and computing resources will also increase. The proxy contract may also need to obtain authorization to perform certain operations defined by the first and second contracts, further increasing the number of transactions required to execute an atomic transaction. Summary of the Invention

[0008] In one aspect, a computer-implemented method for providing atomic transactions on a blockchain comprises: receiving a transaction submitted to the blockchain; determining whether the transaction is a fulfillment transaction; in response to determining that the transaction is a fulfillment transaction, identifying a proposed transaction corresponding to the fulfillment transaction; determining whether the proposed transaction is valid and whether the fulfillment transaction satisfies an execution condition specified in the proposed transaction; and in response to determining that the proposed transaction is valid and the fulfillment transaction satisfies the execution condition specified in the proposed transaction, executing the fulfillment transaction and the proposed transaction.

[0009] In another aspect, an apparatus for providing atomic transactions on a blockchain includes: one or more processors; one or more computer-readable memories, the one or more computer-readable memories being coupled to the one or more processors and having instructions stored thereon, the instructions executable by the one or more processors to: receive a transaction submitted to the blockchain; determine whether the transaction is a fulfillment transaction; in response to determining that the transaction is a fulfillment transaction, identify a proposed transaction corresponding to the fulfillment transaction; determine whether the proposed transaction is valid and whether the fulfillment transaction satisfies an execution condition specified in the proposed transaction; and in response to determining that the proposed transaction is valid and that the fulfillment transaction satisfies the execution condition specified in the proposed transaction, execute the fulfillment transaction and the proposed transaction.

[0010] In another aspect, a non-transitory computer-readable medium stores instructions that, when executed by a processor of a terminal device, cause the terminal device to perform a method for providing atomic transactions on a blockchain. The method includes: receiving a transaction submitted to the blockchain; determining whether the transaction is a fulfillment transaction; in response to determining that the transaction is a fulfillment transaction, identifying a proposed transaction corresponding to the fulfillment transaction; determining whether the proposed transaction is valid and whether the fulfillment transaction satisfies execution conditions specified in the proposed transaction; and in response to determining that the proposed transaction is valid and that the fulfillment transaction satisfies execution conditions specified in the proposed transaction, executing the fulfillment transaction and the proposed transaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of this document, illustrate embodiments. In the following description of the designated figures, like numerals in different figures represent the same or similar elements unless otherwise indicated.

[0012] Figure 1 is a schematic diagram of a blockchain system according to an embodiment.

[0013] Figure 2 is a schematic diagram of a computing device for implementing a node in a blockchain system according to an embodiment.

[0014] Figure 3 is a block diagram depicting a protocol for providing atomic transactions on a blockchain, according to an embodiment.

[0015] Figure 4 is a flow chart of a method for providing atomic transactions on a blockchain, according to an embodiment.

[0016] Figure 5 is a block diagram of an apparatus for providing atomic transactions on a blockchain according to an embodiment. DETAILED DESCRIPTION

[0017] Embodiments herein provide methods and apparatus for providing atomic transactions on a blockchain. These methods and apparatus can add specific data fields to the data structure of blockchain transactions to support the execution of atomic transactions. Such atomic transactions can be executed atomically on a blockchain without requiring a proxy contract to be deployed on the blockchain. These methods and apparatus can also allow new data fields to be set to nil. Transactions with new data fields set to nil can be executed on the blockchain in a conventional manner, thereby reducing the impact of data structure changes on regular transactions.

[0018] The embodiments disclosed herein have one or more technical effects. In some embodiments, the method and apparatus add specific data fields to the data structure of blockchain transactions. This allows the method and apparatus to support the execution of atomic transactions on a blockchain without requiring the blockchain to deploy a proxy contract, thereby reducing storage space and computing resource consumption. This also allows each contract defined on the blockchain to interact with other contracts, regardless of when the contract was deployed or how it was implemented. In some embodiments, the method and apparatus can handle transactions in which the new data field is set to nil. This allows the method and apparatus to support the creation and execution of transactions that do not utilize the atomicity disclosed herein. This also minimizes the impact of data structure changes on regular transactions. In this way, the method and apparatus can be used in existing blockchain systems without significant modification.

[0019] A blockchain is a data structure for storing data, such as transactions, that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner are immutable and can be subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the immediately preceding block by including a cryptographic hash of the previous block. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in a blockchain system can be hashed and encoded into a data structure, such as a Merkle tree. In a Merkle tree, the data at the leaf nodes is hashed, and all hash values in each branch of the tree are connected at the root of the branch. This process continues along the tree until it reaches the root of the entire tree, where hash values representing all the data in the tree are stored. Hash values purported to be transactions stored in the tree can be quickly verified by determining whether they are consistent with the tree's structure.

[0020] A blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities, can operate in a public blockchain network, with each entity operating at least one node in the public blockchain network. Therefore, a public blockchain network can be considered a public network with respect to participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain network. Examples of public blockchain networks include specialized peer-to-peer payment networks that utilize distributed ledgers (called blockchains).

[0021] Typically, a public blockchain network can support public transactions. Public transactions are shared by all nodes within the public blockchain network and stored in a global blockchain. The global blockchain is a blockchain that is replicated across all nodes, and all nodes are in full consensus with respect to the global blockchain. To reach consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented within the public blockchain network. Examples of consensus protocols include proof-of-work (POW) (e.g., implemented in some cryptocurrency networks), proof-of-stake (POS), and proof-of-authority (POA).

[0022] Typically, a private blockchain network is provided to a specific entity, which centrally controls read and write permissions. This entity controls which nodes can participate in the blockchain network. For this reason, private blockchain networks are often referred to as permissioned networks, restricting who can participate and their level of participation (e.g., only within specific transactions). Various types of access control mechanisms can be used (e.g., existing participants vote to add new entities, and a governing body can control admission).

[0023] Typically, a consortium blockchain network is private among the participating entities. In a consortium blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by the corresponding entity (e.g., a financial institution, an insurance company). For example, a consortium consisting of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, and each entity can operate at least one node in the consortium blockchain network. Therefore, a consortium blockchain network can be considered a private network associated with the participating entities. In some examples, each entity (node) must sign each block in order for the block to be valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each block in order for the block to be valid and added to the blockchain.

[0024] Figure 1 FIG2 shows a schematic diagram of a blockchain system 100 according to an embodiment. Figure 1 , blockchain system 100 may include a plurality of nodes, such as nodes 102-110, configured to operate on blockchain 120. Nodes 102-110 may form a network 112, such as a peer-to-peer network. Each of nodes 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of blockchain 120, or may be software, such as a process or application, running on a computing device. Each of nodes 102-110 may have a unique identifier.

[0025] The blockchain 120 may include, for example Figure 1 Each of the blocks B1-B5 may include a timestamp, a cryptographic hash of the previous block, and the data of the current block, which may be a transaction such as a currency transaction. Figure 1 As shown, block B5 may include a timestamp, a cryptographic hash value of block B4, and the transaction data of block B5. Furthermore, for example, a hash operation may be performed on the previous block to generate a cryptographic hash value of the previous block. The hash operation may convert inputs of various lengths into encrypted outputs of fixed length using a hash algorithm such as SHA-256.

[0026] Nodes 102-110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, the node can generate a new block to be added to blockchain 120 and broadcast the new block to other nodes in network 112, such as nodes 104-110. Based on the legitimacy of the new block, for example, the validity of its signature and transactions, the other nodes can determine to accept the new block, so that node 102 and the other nodes can add the new block to their respective copies of blockchain 120. As this process repeats, more and more blocks of data can be added to blockchain 120.

[0027] Figure 2 The embodiment of the present invention is used to implement a node (e.g., node 102 ( Figure 1 )) is a schematic diagram of a computing device 200. Figure 2 , computing device 200 may include a communication interface 202 , a processor 204 , and a memory 206 .

[0028] The communication interface 202 can facilitate communication between the computing device 200 and other nodes (eg, nodes 104-110) in a network. Figure 1)) between devices. In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, Integrated Services Digital Network (ISDN) standards, etc. In some embodiments, the communication interface 202 may include one or more of the following: a local area network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP)-based communication device, or other communication devices for wired and / or wireless communication. In some embodiments, the communication interface 202 may be based on a public cloud infrastructure, a private cloud infrastructure, or a hybrid public / private cloud infrastructure.

[0029] The processor 204 may include one or more dedicated processing units, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled to the memory 206 and is configured to execute instructions stored in the memory 206.

[0030] The memory 206 may store instructions and data executable by the processor, such as the blockchain 120 ( Figure 1 ). Memory 206 may include any type of volatile or non-volatile memory device or combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, or a magnetic or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

[0031] Figure 3FIG. 1 is a block diagram illustrating a protocol 300 for providing atomic transactions on a blockchain according to an embodiment. Figure 3 As shown, a user may have an account on a blockchain, such as blockchain 120 ( Figure 1 ). Blockchains can be implemented to support various types of users or parties, including, for example, individuals, businesses, banks, financial institutions, hospitals, and other types of companies, organizations, etc.

[0032] To illustrate, Figure 3 A first user 302 and a second user 304 are depicted in FIG. Figure 3 Also depicted are two smart contracts, Contract A and Contract B. A smart contract is a computer protocol implemented in computer code that is incorporated into a blockchain to facilitate, verify, or enforce the negotiation or execution of a contract. For example, blockchain users can program agreed-upon terms into a smart contract using programming languages such as C++, Java, Solidity, or Python. When the terms are met, the smart contract can be automatically executed by the blockchain, for example, by executing a transaction. For another example, a smart contract can include multiple subroutines, functions, or methods, each of which can be a series of program instructions that performs a specific task. A smart contract can be an operational code that executes completely or partially without human interaction. In some embodiments, a first smart contract, such as Contract A, can be incorporated into a blockchain to manage certain assets recorded on the blockchain (e.g., a certain type of digital currency). A second smart contract, such as Contract B, can also be incorporated into the blockchain to manage certain assets recorded on the blockchain (e.g., a certain type of commodity). For illustrative purposes, dashed rectangles are used to represent transactions that may invoke one or more methods defined in Contracts A and B. It should be understood that the dashed rectangles do not represent data structures maintained by the blockchain.

[0033] Assume that a first user 302 owns a first asset managed by contract A and wants to exchange the first asset for a second asset managed by contract B. In this case, the first user 302 can create a first transaction 306, proposing to exchange the first asset for the second asset. The first transaction 306 can be used Figure 3, which in turn defines an event that can be executed on the blockchain. As will be described in detail below, a first transaction 306 can define the event as a call to a method (e.g., "methodA") defined in a smart contract (e.g., "contractA") when certain execution conditions are met. If a second user 304 owns a second asset and is willing to exchange it with the first user 302, the second user 304 can create a second transaction 308 to accept / fulfill the offer. The same data structure can be used to define the second transaction 308. Both user 302 and user 304 may be interested in performing the exchange in an atomic manner, which means that they may be interested in ensuring that both transactions 306 and 308 either succeed or fail. To this end, both user 302 and user 304 can follow Figure 3 The protocol 300 depicted in FIG. 1 is used to perform a first transaction 306 and a second transaction 308 .

[0034] In some embodiments, the first user 302 may specify various data fields 306-1 to 306-10 when creating the first transaction 306. The data fields may include a transaction identifier (transactionID) 306-1, a timestamp (timestamp) 306-2, a "from" data field 306-3, a "to" data field 306-4, a timeout parameter (timeout) 306-5, a status indicator (status) 306-6, a method selector (method) 306-7, an input data field (data) 306-8, a target transaction identifier (tagetTransactionID) 306-9, and one or more execution conditions (executeCondition) 306-10.

[0035] In some embodiments, transaction identifier 306-1 may specify a value uniquely identifying first transaction 306, such as a hash string. Timestamp 306-2 may specify the time when first transaction 306 was created. "From" data field 306-3 may identify the transaction sender, in this case, first user 302. "To" data field 306-4 may identify the transaction recipient, which may be Contract A, the contract that manages the first asset. Timeout parameter 306-5 may specify the time at which first transaction 306 is set to expire. Status indicator 306-6 may indicate the status of first transaction 306, including, for example, "pending," "success," "reverted," or "expired." Method selector 306-7 may specify a method defined in Contract A that will be called if / when first transaction 306 is executed. In some embodiments, this method may include a transfer operation provided by Contract A to transfer the first asset from first user 302 to a specified user (e.g., second user 304). The input data field 306-8 may specify one or more input parameters that are provided to the method specified in the method selector 306-7. In some embodiments, the input data field 306-8 may include serialized input data that can be decoded to be used as input parameters for the method when the first transaction 306 is executed.

[0036] The target transaction identifier 306-9 may indicate which transaction will be executed atomically with the first transaction 306. The transaction to be executed atomically with the first transaction 306 may be referred to as the "target" transaction of the first transaction 306. In some embodiments, if the first user 302 does not know which transaction is the target transaction of the first transaction 306, the target transaction identifier 306-9 may be left blank (e.g., set to nil). For example, when the first user 302 is creating the first transaction 306 as a proposed transaction to exchange a first asset for a second asset, the corresponding target transaction identifier may be left blank. When the first transaction 306 is created, the second transaction 308 may not yet have been created, so the target transaction identifier 306-9 of the first transaction 306 may be left blank.

[0037] The execution condition 306-10 may specify one or more conditions that must be satisfied for the execution of the first transaction 306. In some embodiments, the condition may include certain requirements established for the target transaction of the first transaction 306. In other words, the target transaction of the first transaction 306 may need to satisfy the execution condition 306-10 proposed by the first transaction 306 in order for the target transaction to be executed atomically with the first transaction 306. Continuing with the above example, in the case where the first user 302 wants to exchange a first asset managed by contract A for a second asset managed by contract B, the first user 302 may specify an execution condition 306-10 that specifies that the target transaction of the first transaction 306 must be a transaction that operates on an asset managed by contract B. This execution condition is in Figure 3 306 . This can be represented as "targetTx.to == contractB" in the first transaction. In this way, if the second user 304 wants to accept the first user 302's proposal to exchange the first asset for the second asset, the second user 304 can create a second transaction 308 with the "to" data field 308-4 set to contract B. Otherwise, the second transaction 308 may not satisfy the execution condition 306-10 of the first transaction 306.

[0038] The first user 302 may also require the target transaction of the first transaction 306 to call a specific method provided by contract B when the target transaction is executed. For example, in some embodiments, the first user 302 may require the target transaction of the first transaction 306 to call a method defined in contract B that performs a transfer operation when the target transaction is executed. The execution condition can be expressed as Figure 3 In this manner, if the second user 304 wants to accept the first user 302's proposal to exchange the first asset for the second asset, the second user 304 can create a second transaction 308 with the method selector 308-7 set to method B. Otherwise, the second transaction 308 may not satisfy the execution condition 306-10 of the first transaction 306.

[0039] The first user 302 may also specify additional execution conditions 306-10. For example, Figure 3 As shown, the first user 302 may require that the target transaction of the first transaction 306 call a specified method (eg, "methodB") with a first parameter value greater than 10 and a second parameter value less than 20. Target values for other parameters may be specified in a similar manner.

[0040] In some embodiments, the first user 302 may determine the target value based on the proposal of the first user 302. For example, assuming that the first user 302 proposes to exchange one unit of the first asset for at least eleven units of the second asset, and further assuming that methodB takes parameter param_B(1) as the total number of units of the second asset to be transferred, the first user 302 may specify that param_B(1) must be greater than 10 as the execution condition 306-10. In this way, if the second user 304 wants to accept the proposal of the first user 302 to exchange the first asset for the second asset, the second user 304 may create a second transaction 308 in which the parameter param_B(1) is set to be greater than 10. Otherwise, the second transaction 308 may not satisfy the execution condition 306-10 of the first transaction 306.

[0041] It should be understood that the execution condition 306-10 described above is provided as an example only and is not intended to be limiting. Other execution conditions 306-10 may be specified in a similar manner, and the target value may include a number, a string, and a value represented by other types of data structures. It should be noted that although the specific implementations may be different, the purpose of implementing the execution condition 306-10 may be the same, that is, to give the first user 302 the ability to specify the conditions required for the target transaction of the first transaction 306 (for example, which method of which smart contract is called with what parameters).

[0042] Once the first transaction 306 is created, the first user 302 can submit the first transaction 306 for recording on the blockchain. In some embodiments, the first transaction 306 submitted to the blockchain can be added to a block 310, which is subject to a consensus process. For illustration purposes, Figure 3 The black dots in the figure are used to indicate the transactions contained in each block of the blockchain (for example, these transactions can be contained in Figure 1 ), and first transaction 306 is depicted as included as one of the transactions in block 310. In some embodiments, the addition of first transaction 306 to block 310 may trigger a transaction execution process 316, which may determine, at step 318, that first transaction 306 is a proposed transaction because its target transaction identifier is set to nil and its execution condition is not nil. Transaction execution process 316 may then set the status of first transaction 306 to "pending" at step 320. Alternatively, in some embodiments, first transaction 306 submitted to the blockchain may remain in a pool of pending transactions maintained by the blockchain without being added to any blocks. In some embodiments, first transaction 306 may remain in the pending transaction pool until it is fulfilled or expires.

[0043] Once the first transaction 306 is recorded on the blockchain, the first transaction 306 may be visible to other users (including the second user 304), who may be interested in creating a second transaction 308 to accept / fulfill the offer specified in the first transaction 306. The second user 304 may specify various data fields 308-1 through 308-10 when creating the second transaction 308. The data fields may include a transaction identifier (transactionID) 308-1, a timestamp (timestamp) 308-2, a "from" data field 308-3, a "to" data field 308-4, a timeout parameter (timeout) 308-5, a status indicator (status) 308-6, a method selector (method) 308-7, an input data field (data) 308-8, a target transaction identifier (tagetTransactionID) 308-9, and one or more execution conditions (executeCondition) 308-10.

[0044] Transaction identifier 308-1 may specify a value uniquely identifying transaction 308, such as a hash string. Timestamp 308-2 may specify the time when transaction 308 was created. "From" data field 308-3 may identify the transaction sender, in this case, second user 304. "To" data field 308-4 may identify the transaction recipient, which may be set to Contract B, the contract that manages the second asset. Timeout parameter 308-5 may specify the time when second transaction 308 is set to expire. Status indicator 308-6 may indicate the status of transaction 308, including, for example, "pending," "success," "reverted," or "expired." Method selector 308-7 may specify a method defined in Contract B that will be called if / when second transaction 308 is executed. In some embodiments, this method may include a transfer operation provided by Contract B to transfer the second asset from second user 304 to a specified user (e.g., first user 302). The input data field 308-8 may specify one or more input parameters that are provided to the method specified in the method selector 308-7. In some embodiments, the input data field 308-8 may include serialized input data that can be serialized and decoded to be used as input parameters for the method when the transaction 308 is executed.

[0045] The target transaction identifier 308-9 can indicate which transaction will be executed atomically with the second transaction 308. In this case, the second user 304 can set the target transaction identifier 308-9 to the transaction identifier 306-1 of the first transaction 306 to indicate that it is the first transaction 306 that will be executed atomically with the second transaction 308. In this manner, the second transaction 308 can be considered to have been created to fulfill the first transaction 306. Therefore, the second transaction 308 can be referred to as a fulfilling transaction.

[0046] In some embodiments, the second transaction 308 serving as the fulfillment transaction may leave the execution condition 308-10 blank (e.g., set to nil). In this embodiment, the second transaction 308 may accept the execution condition 306-10 proposed in the first transaction 306. However, in order for the second transaction 308 to be a valid fulfillment transaction, the second transaction 308 must satisfy the execution condition 306-10 proposed in the first transaction 306. In some embodiments, the validity of the second transaction 308 may be verified after the second transaction 308 is submitted to the blockchain. In some embodiments, the second transaction 308 submitted to the blockchain may be added to a block 312, which is subject to the consensus process.

[0047] In some embodiments, adding the second transaction 308 to the block 312 may trigger a transaction execution process 316, which may determine that the second transaction 308 is a fulfillment transaction because its target transaction identifier is not nil at step 318. The transaction execution process 316 may then proceed to step 322.

[0048] At step 322, the transaction execution process 316 may identify the target transaction specified by the target transaction identifier 308-9 of the second transaction 308. Because the transaction execution process 316 has determined that the second transaction 308 is a fulfilling transaction, the transaction execution process 316 may identify the target transaction specified by the target transaction identifier 308-9 as a proposed transaction corresponding to the fulfilling transaction. Continuing with the above example, the target transaction identifier 308-9 of the second transaction 308 may identify the first transaction 306 as a target transaction, thereby allowing the transaction execution process 316 to retrieve the target transaction identifier 308-9 and identify the first transaction 306 as the proposed transaction. If (1) the first transaction 306 is still valid and (2) the second transaction 308 satisfies the execution condition 306-10 set forth in the first transaction 306, the transaction execution process 316 may cause the second transaction 308 to be executed and committed along with the first transaction 306.

[0049] In some embodiments, the transaction execution process 316 may determine whether the first transaction 306 is still valid based on the timeout parameter 306-5 of the first transaction 306. For example, the transaction execution process 316 may calculate the difference between the current timestamp and the timestamp 306-2 of the first transaction 306 and compare the difference with the timeout parameter 306-5 of the first transaction 306. If the difference is greater than the timeout parameter 306-5, the transaction execution process 316 may determine that the first transaction 306 has expired and is therefore no longer valid. Alternatively or additionally, the transaction execution process 316 may determine whether the first transaction 306 is still valid based on the status indicator 306-6 of the first transaction 306. For example, if the transaction execution process 316 determines that the status indicator 306-6 indicates that the first transaction 306 is still "pending", the transaction execution process 316 may determine that the first transaction 306 is still valid. In some embodiments, if the transaction execution process 316 determines that the first transaction 306 is no longer valid, the transaction execution process 316 may revert the second transaction 308 (e.g., by setting the state indicator 308-6 of the second transaction 308 to “reverted”) so that any changes (if any) caused by the second transaction 308 can be restored on the blockchain.

[0050] In some embodiments, if the transaction execution process 316 determines that the first transaction 306 is still valid, the transaction execution process 316 may proceed to determine whether the second transaction 308 satisfies the execution condition 306-10 set forth in the first transaction 306. Continuing with the above example, the execution condition 306-10 may require that the second transaction 308 be sent to contract B and that the second transaction 308 call method B when the second transaction 308 is executed. Thus, if the transaction execution process 316 determines that the "to" data field 308-4 of the second transaction 308 is not set to contract B, or the method selector 308-7 of the second transaction 308 is not set to method B, the transaction execution process 316 may determine that the second transaction 308 does not satisfy the execution condition 306-10. In some embodiments, the execution condition 306-10 may also place certain requirements on the parameters param_B(1) and param_B(2). Thus, if the transaction execution process 316 determines that the input data field 308-8 of the second transaction 308 sets the parameters param_B(1) and param_B(2) to values that do not meet the requirements set forth in the execution condition 306-10, the transaction execution process 316 may determine that the second transaction 308 does not meet the execution condition 306-10.

[0051] In some embodiments, if the transaction execution process 316 determines that the second transaction 308 does not satisfy the execution condition 306-10, the transaction execution process 316 may revert the second transaction 308 (e.g., by setting the status indicator 308-6 of the second transaction 308 to "reverted") so that any changes caused by the second transaction 308 can be reverted on the blockchain. On the other hand, if the transaction execution process 316 determines that the second transaction 308 satisfies the execution condition 306-10, the transaction execution process 316 may continue to execute the first transaction 306 and the second transaction 308. If both the first transaction 306 and the second transaction 308 execute successfully, the transaction execution process 316 may commit the execution of both transactions on the blockchain (e.g., by merging the transactions 306 and 308 into the blockchain and setting the status indicators 306-6 of the transactions 306 and 308-6 of the transactions 308 to "success"). In this manner, the execution results may be included in a new block, such as block 314, which may then be added to the blockchain. On the other hand, if the first transaction 306 or the second transaction 308 is not successfully executed, the transaction execution process 316 can revert the transactions 306 and 308 (e.g., by setting the status indicator 306-6 of the transaction 306 and the status indicator 308-6 of the transaction 308 to "reverted") so that any changes caused by the first transaction 306 or the second transaction 308 can be reverted on the blockchain. In this way, atomicity can be achieved because both transactions 306 and 308 must either succeed or fail, and partial processing is not allowed.

[0052] In some embodiments, the transaction execution process 316 may further support executing transactions that are neither proposed nor fulfilled transactions. Such transactions may set both the target transaction identifier and the execution condition to nil. When the transaction execution process 316 determines that a transaction is neither a proposed nor fulfilled transaction, the transaction execution process 316 may proceed to step 324 and treat the transaction as a "regular" transaction. In some embodiments, the transaction execution process 316 may process regular transactions in a conventional manner. For example, the transaction execution process 316 may execute the transaction and update the transaction's state in the manner in which such transactions are normally executed on the blockchain, thereby minimizing the impact of new data fields (e.g., the target transaction identifier and the execution condition) on regular transactions.

[0053] It should be understood that although the above examples refer to transactions 306 and 308 created by users, such implementation is provided as an example only and is not intended to be limiting. In some embodiments, transactions 306 and 308 may be user-created or system-generated. It should also be understood that although the above examples refer to contracts A and B as two different smart contracts incorporated into the blockchain, such implementation is provided as an example only and is not intended to be limiting. In some embodiments, the first user 302 may be allowed to set the target transaction (e.g., targetTx.to) to contract A, in which case the fulfillment transaction also needs to be a transaction sent to contract A. In addition, it should be understood that the above declarations of functions, variables, and transactions are presented as examples only and are not intended to be limiting.

[0054] Figure 4 400 according to an embodiment of the present invention is a flowchart of a method 400 for providing atomic transactions on a blockchain. The method 400 may be executed by one or more nodes in a blockchain system, such as the blockchain system 100 ( Figure 1 ) in the blockchain system 100. The nodes 102-110 in the blockchain system 100 can perform operations on the blockchain, such as the blockchain 120 ( Figure 1 ). The blockchain 120 may be implemented as the blockchain in the above example.

[0055] At step 402, a node (e.g., node 102) may receive a transaction submitted to blockchain 120. At step 404, node 102 may determine whether the transaction is a proposed transaction, a fulfilled transaction, or a regular transaction.

[0056] In some embodiments, if the transaction specifies one or more execution conditions but does not specify a target transaction identifier, node 102 may determine that the transaction is a proposal transaction. If the transaction specifies a target transaction identifier, node 102 may identify the transaction as a fulfillment transaction. If the transaction specifies neither a target transaction identifier nor an execution condition, node 102 may identify the transaction as a regular transaction.

[0057] In some embodiments, if node 102 determines that the transaction is a proposal transaction, node 102 may set the transaction status to pending. If node 102 determines that the transaction is a regular transaction, node 102 may execute the transaction in a regular manner. If node 102 determines that the transaction is a fulfillment transaction, node 102 may proceed to step 406.

[0058] In step 406, in response to determining that the transaction is a fulfillment transaction (eg, the second transaction 308, Figure 3 ), node 102 may identify a proposed transaction corresponding to the fulfillment transaction (e.g., first transaction 306, Figure 3In some embodiments, node 102 may perform a transaction based on a target transaction identifier specified in the fulfillment transaction (e.g., target transaction identifier 308-9, Figure 3 ) to identify the proposed transaction. Node 102 may retrieve the target transaction identifier specified in the fulfillment transaction and identify the proposed transaction based on the target transaction identifier.

[0059] At step 408 , the node 102 may determine whether the proposed transaction is valid and whether the fulfillment transaction satisfies the execution conditions specified in the proposed transaction.

[0060] In some embodiments, node 102 may determine whether the proposed transaction is valid based on a timeout parameter specified in the proposed transaction. For example, node 102 may calculate the difference between the current timestamp and the timestamp recorded when the proposed transaction was created. Node 102 may compare this difference with the timeout parameter specified in the proposed transaction. If the difference is greater than the timeout parameter, node 102 may consider the proposed transaction to have expired and, therefore, no longer valid. Alternatively or additionally, node 102 may determine whether the proposed transaction is valid based on a status indicator specified in the proposed transaction. For example, if node 102 determines that the status indicator specified in the proposed transaction indicates that the proposed transaction is still pending, node 102 may determine that the proposed transaction is valid. In some embodiments, if node 102 determines that the proposed transaction is no longer valid, node 102 may revert the fulfillment transaction, thereby reverting any changes caused by the fulfillment transaction on blockchain 120.

[0061] In some embodiments, a proposed transaction may specify one or more execution conditions, and node 102 may determine whether a fulfillment transaction satisfies each execution condition specified in the proposed transaction. An execution condition may specify, for example, a smart contract to which the fulfillment transaction should be sent, a method to which the fulfillment transaction should be invoked, or a target value for a parameter to be included in the fulfillment transaction. It should be understood that the target value may be specified as a specific value, a range of values, a minimum value, a maximum value, etc.

[0062] In step 410, in response to determining that the proposed transaction is valid and that the fulfillment transaction satisfies the execution conditions specified in the proposed transaction, node 102 may execute the fulfillment transaction and the proposed transaction. In some embodiments, node 102 may determine whether the fulfillment transaction and the proposed transaction were successfully executed. If both the fulfillment transaction and the proposed transaction were successfully executed, node 102 may commit the execution of both the fulfillment transaction and the proposed transaction on blockchain 120. On the other hand, if at least one of the fulfillment transaction and the proposed transaction was not successfully executed, node 102 may revert the fulfillment transaction and the proposed transaction, thereby reverting any changes to the blockchain caused by the fulfillment transaction or the proposed transaction. In this manner, atomicity can be achieved because both the fulfillment transaction and the proposed transaction must either succeed or fail, and partial processing is not permitted.

[0063] Figure 5 is a block diagram of an apparatus 500 for providing atomic transactions on a blockchain according to an embodiment. The apparatus 500 may be an implementation of a software process and may correspond to the method 400 ( Figure 4 ). refer to Figure 5 , the apparatus 500 may include a receiving module 502 , a determining module 504 , an identifying module 506 and an executing module 508 .

[0064] The receiving module 502 may receive a transaction submitted to the blockchain and provide the received transaction to the determining module 504.

[0065] The determination module 504 can determine whether the transaction is a proposed transaction, a fulfilled transaction, or a regular transaction. If the transaction is a regular transaction, the determination module 504 can provide the transaction to the execution module 508 for execution. If the transaction is a proposed transaction, the determination module 504 can set the status of the transaction to pending. If the transaction is a fulfilled transaction, the determination module 504 can provide the transaction to the identification module 506 for further processing.

[0066] Identification module 506 can identify a proposed transaction corresponding to the fulfillment transaction. In some embodiments, identification module 506 can identify the proposed transaction based on a target transaction identifier specified in the fulfillment transaction. Identification module 506 can retrieve the target transaction identifier specified in the fulfillment transaction and identify the proposed transaction based on the target transaction identifier. Identification module 506 can then provide the identified proposed transaction to determination module 504.

[0067] Determination module 504 can determine whether the proposed transaction is valid and whether the fulfillment transaction satisfies the execution conditions specified in the proposed transaction. In response to determining that the proposed transaction is valid and that the fulfillment transaction satisfies the execution conditions specified in the proposed transaction, determination module 504 can provide the proposed transaction and the fulfillment transaction to execution module 508 for execution. In some embodiments, if both the proposed transaction and the fulfillment transaction execute successfully, execution module 508 can commit both the proposed transaction and the fulfillment transaction for execution on the blockchain. On the other hand, if at least one of the proposed transaction and the fulfillment transaction does not execute successfully, execution module 508 can revert the proposed transaction and the fulfillment transaction so that any changes to the blockchain caused by the proposed transaction and the fulfillment transaction can be restored. In this manner, atomicity can be achieved because both the proposed transaction and the fulfillment transaction can either succeed or fail, disallowing partial processing.

[0068] Each of the above modules can be implemented as software or hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor that executes instructions stored in a memory. Moreover, for example, each of the above modules can be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the described methods. Further, for example, each of the above modules can be implemented using a computer chip or entity, or by using a product with a specific function. In one embodiment, the device 500 can be a computer, and the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0069] For the implementation process of the functions and roles of each module in the apparatus 500, reference may be made to the corresponding steps in the above method. For the sake of simplicity, the details are omitted here.

[0070] In some embodiments, the computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions stored thereon for causing a processor to execute the above method.

[0071] A computer-readable storage medium may be a tangible device that can store instructions for use by an instruction execution device. The computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punched card or raised structure in grooves having instructions recorded thereon, and any suitable combination of the foregoing.

[0072] The computer-readable program instructions for performing the above method can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages and traditional procedural programming languages. The computer-readable program instructions can be executed entirely on a computing device as a standalone software package, or partially executed on a first computing device and partially executed on a second computing device away from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device through any type of network including a local area network (LAN) or a wide area network (WAN).

[0073] Computer-readable program instructions may be provided to a processor of a general-purpose or special-purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions are executed via the processor of the computer or other programmable data processing apparatus, creating means for implementing the above-described methods.

[0074] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architectures, functions and operations of the devices, methods and computer program products according to the various embodiments of this document. In this regard, the boxes in the flowcharts or block diagrams can represent segments or portions of software programs, codes, which include one or more executable instructions for implementing a specific function. It should also be noted that in some optional embodiments, the functions mentioned in the boxes may not occur in the order shown in the figures. For example, the two boxes shown in succession can actually be executed substantially simultaneously, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the diagrams and / or flowcharts and the combination of boxes in the diagrams and flowcharts can be implemented by a hardware-based system for a special purpose that performs a specified function or action, or by a combination of hardware and computer instructions for a special purpose.

[0075] It should be understood that certain features of the specification that are described in the context of a single embodiment for the sake of clarity may also be provided in combination in that single embodiment. Conversely, various features herein that are described in the context of a single embodiment for the sake of brevity may also be provided individually or in any suitable subcombination, or as appropriate in any other described embodiment herein. Unless otherwise indicated, certain features described in the context of various embodiments are not essential features of those embodiments.

[0076] Although this invention has been described in conjunction with specific embodiments, many alternatives, modifications and variations will be apparent to those skilled in the art. It is therefore intended that the following claims encompass all such alternatives, modifications and variations that fall within the scope of the claims.

Claims

1. A computer-implemented method for providing atomic transactions on a blockchain, the method comprising: receiving a transaction submitted to the blockchain; Determining whether the transaction is a fulfillment transaction; In response to determining that the transaction is a fulfillment transaction, identifying a proposed transaction corresponding to the fulfillment transaction; determining whether the proposed transaction is valid and whether the performed transaction satisfies the execution conditions specified in the proposed transaction; In response to determining that the proposed transaction is valid and the perform transaction satisfies the execution condition specified in the proposed transaction, the perform transaction and the proposed transaction are executed.

2. The method according to claim 1, further comprising: determining whether the transaction is a proposed transaction; In response to determining that the transaction is a proposed transaction, setting a status of the transaction to pending.

3. The method according to claim 1, further comprising: determining whether the transaction is a regular transaction; In response to determining that the transaction is a regular transaction, the transaction is executed.

4. The method according to claim 1, wherein Determining that the transaction is a fulfillment transaction further includes: determining whether the transaction specifies a target transaction identifier; In response to determining that the transaction specifies a target transaction identifier, the transaction is identified as a fulfillment transaction.

5. The method according to claim 4, wherein Identifying the proposed transaction corresponding to the fulfillment transaction further includes: Retrieving the target transaction identifier specified in the fulfillment transaction; The proposed transaction is identified based on the target transaction identifier.

6. The method according to claim 1, wherein Determining whether the proposed transaction is valid further includes: A determination is made as to whether the proposed transaction is valid based on a timeout parameter specified in the proposed transaction.

7. The method according to claim 1, wherein Determining whether the proposed transaction is valid further includes: Whether the proposed transaction is valid is determined based on a status indicator specified in the proposed transaction.

8. The method according to claim 1, wherein The execution condition specified in the proposal transaction specifies a smart contract to which the fulfillment transaction is sent.

9. The method according to claim 1, wherein The execution condition specified in the proposal transaction specifies a method to be called by the fulfillment transaction.

10. The method according to claim 1, wherein The execution condition specified in the proposal transaction specifies a target value and how the target value compares to parameters included in the fulfillment transaction.

11. The method according to any one of claims 1 to 10, further comprising: determining whether the performance transaction and the proposed transaction are successfully executed; In response to determining that both the fulfillment transaction and the proposal transaction were successfully executed, committing execution of both the fulfillment transaction and the proposal transaction on the blockchain.

12. The method according to claim 11, further comprising: In response to determining that at least one of the fulfillment transaction and the proposal transaction was not successfully executed, resuming the fulfillment transaction and the proposal transaction.

13. A device for providing atomic transactions on a blockchain, comprising: one or more processors; One or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any one of claims 1 to 12.

14. A device for providing atomic transactions on a blockchain, the device comprising a receiving module, a determining module, an identifying module, and an executing module: The receiving module is configured to receive a transaction submitted to the blockchain; The determining module is used to determine whether the transaction is a fulfillment transaction; the identification module is configured to, in response to determining that the transaction is a fulfillment transaction, identify a proposed transaction corresponding to the fulfillment transaction; The determination module is further configured to determine whether the proposed transaction is valid and whether the performed transaction satisfies the execution conditions specified in the proposed transaction; The execution module is configured to execute the performance transaction and the proposed transaction in response to determining that the proposed transaction is valid and the performance transaction satisfies the execution condition specified in the proposed transaction.

15. A non-transitory computer-readable medium storing instructions, which, when executed by a processor of a device, cause the device to perform the method of any one of claims 1 to 12.

Images