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. One of the methods 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 bid transaction corresponding to the fulfillment transaction; determining whether the bid transaction is valid and whether the fulfillment transaction satisfies an execution condition specified in the bid transaction; and in response to determining that the bid transaction is valid and the fulfillment transaction satisfies the execution condition specified in the bid transaction, executing a replacement instruction specified in the bid transaction and executing the fulfillment transaction and the bid transaction.

Description

Technical Field

[0001] The present disclosure relates generally to computer technology, and more particularly to methods and apparatus 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. Blockchain systems can include any DLS, regardless of any specific use case, and can be used in 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 designed for specific entities, with read and write permissions centrally controlled. Consortium blockchain networks are designed 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, e.g., 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 for storing data, such as transactions, 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 can be a computer protocol in the form of computer code incorporated into a blockchain to facilitate, verify, or enforce the negotiation or execution of a contract.

[0005] A blockchain use case may require two transactions to be processed atomically, meaning that either both transactions succeed or both fail, without allowing partial processing. However, current implementations of blockchain systems do not have built-in mechanisms to support atomic transactions.

[0006] To achieve atomicity, a separate custom smart contract may need to be deployed to serve 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 need to create a first transaction operating on the first contract to transfer the first asset from the first user to the second user. The first user can then send the first transaction to the proxy contract. Similarly, the second user may need to create a second transaction operating on the second contract to transfer the second asset from the second user to the first user. The second user can then send the second transaction to the proxy contract. After receiving both transactions, the proxy contract can 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 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 quote transaction corresponding to the fulfillment transaction; determining whether the quote transaction is valid and whether the fulfillment transaction satisfies an execution condition specified in the quote transaction; and in response to determining that the quote transaction is valid and the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing a replacement instruction specified in the quote transaction and executing the fulfillment transaction and the quote transaction.

[0009] In another aspect, an apparatus for providing atomic transactions on a blockchain comprises: one or more processors; and one or more computer-readable memories 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 quote transaction corresponding to the fulfillment transaction; determine whether the quote transaction is valid and whether the fulfillment transaction satisfies an execution condition specified in the quote transaction; and in response to determining that the quote transaction is valid and the fulfillment transaction satisfies the execution condition specified in the quote transaction, execute a replacement instruction specified in the quote transaction and execute the fulfillment transaction and the quote transaction.

[0010] In another aspect, a non-transitory computer-readable medium has instructions stored therein that, when executed by a processor of a device, cause the 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 bid transaction corresponding to the fulfillment transaction; determining whether the bid transaction is valid and whether the fulfillment transaction satisfies an execution condition specified in the bid transaction; and in response to determining that the bid transaction is valid and the fulfillment transaction satisfies the execution condition specified in the bid transaction, executing a replacement instruction specified in the bid transaction and executing the fulfillment transaction and the bid transaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description referring to the accompanying drawings, like reference numerals in different drawings 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 schematic 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 of this specification provide methods and apparatus for providing atomic transactions on a blockchain. The methods and apparatus can add certain data fields to the data structure of blockchain transactions to support the execution of atomic transactions. Such atomic transactions can be executed atomically on the blockchain without requiring the blockchain to deploy a proxy contract. The methods and apparatus can also support the replacement of certain parameters specified in the atomic transaction, thereby providing flexibility for such atomic transactions. The methods and apparatus can also allow new data fields to be set to zero. Transactions with new data fields set to zero can be executed on the blockchain in a conventional manner, thereby minimizing the impact of changes to the data structure on normal transactions.

[0018] The embodiments disclosed herein have one or more technical effects. In some embodiments, the methods and apparatus add certain data fields to the data structure of blockchain transactions. This allows the methods and apparatus to support the execution of atomic transactions on a blockchain without requiring the deployment of proxy contracts on the blockchain, 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 is deployed or how it is implemented. In some embodiments, the methods and apparatus support the replacement of certain parameters specified in atomic transactions. This allows a certain level of flexibility in atomic transactions, allowing users to configure atomic transactions without having to specify predetermined values for all parameters in the atomic transaction. In some embodiments, the methods and apparatus can handle transactions in which the new data fields are set to zero. This allows the methods and apparatus to support the creation and execution of transactions that do not utilize the atomic features disclosed herein. This also minimizes the impact of data structure changes on regular transactions. In this way, the methods and apparatus can be used in existing blockchain systems without significant modification.

[0019] A blockchain is a data structure that stores data (e.g., transactions) in a way that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner can be immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the immediately preceding block in the blockchain 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, data at the leaf nodes of the tree are hashed, and all hashes in each branch of the tree can be concatenated at the root of the branch. This process continues up the tree to the root of the entire tree, which stores hashes representing all the data in the tree. Hashes 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 comprises 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. Thus, 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, known as blockchains.

[0021] Typically, a public blockchain network can support public transactions. Public transactions are shared by all nodes in 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 reach a perfect consensus on the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented in 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, which impose restrictions on who is allowed to participate and their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on the addition of new entities, and a governing body can control admission).

[0023] Typically, a consortium blockchain network can be private between participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, one or more of which are operated by the corresponding entity (e.g., a financial institution, an insurance company). For example, a consortium of ten (10) entities (e.g., a financial institution, an insurance company) can operate a consortium blockchain network, each of which operates at least one node in the consortium blockchain network. Therefore, a consortium blockchain network can be considered a private network with respect to 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 , the blockchain system 100 may include a plurality of nodes, such as nodes 102-110, configured to operate on a blockchain 120. The nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each node 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of the blockchain 120, or may be software, such as a process or application, running on a computing device. Each node 102-110 may have a unique identifier.

[0025] The blockchain 120 may include a continuously growing list of records in the form of data blocks, such as Figure 1Each block B1-B5 may include a timestamp, a cryptographic hash of the previous block, and data of the current block, which may be a transaction such as a currency transaction. For example, Figure 1 As shown, block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data for block B5. Furthermore, for example, a hash operation may be performed on a previous block to generate a cryptographic hash of the previous block. A hash operation may convert inputs of varying 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 (e.g., nodes 104-110) in network 112. 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 102 ( FIG. 103 ) is a block chain system according to an embodiment of the present invention. 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 the implementation 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 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] Memory 206 may store processor-executable instructions and data, such as a copy of 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 memory, 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 3 A schematic diagram depicting a protocol 300 for providing atomic transactions on a blockchain according to an embodiment is shown. Figure 3 , multiple users can be on a blockchain (e.g., blockchain 120 ( Figure 1 )) has an account on the blockchain. The blockchain 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 and organizations.

[0032] For the purpose of illustration, Figure 3 A first user 302 and a second user 304 are depicted in FIG. Figure 3Also depicted are two smart contracts, Contract A and Contract B. A smart contract is a computer protocol implemented in the form of computer code incorporated into a blockchain to facilitate, verify, or enforce the negotiation or execution of a contract. For example, blockchain users can program the terms of an agreement into a smart contract using a programming language (such as C++, Java, Solidity, Python, etc.), and when the terms are satisfied, the smart contract can be automatically executed on the blockchain, for example, to execute a transaction. Furthermore, for example, a smart contract may include multiple subroutines, functions, or methods, each of which may be a sequence of program instructions that performs a specific task. A smart contract may be an operational code that is executed in whole or in part without human interaction. In some embodiments, a first smart contract (e.g., Contract A) may 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 (e.g., Contract B) may 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 indicate transactions that may invoke one or more methods defined in Contract A and Contract B. It should be understood that the dashed rectangles do not indicate 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 offering to exchange the first asset for the second asset. Figure 3 The data structure shown is used to define a first transaction 306, which in turn defines an event that can be executed on the blockchain. As will be described in detail below, the first transaction 306 can define an event as the call of a method (e.g., "Method A") defined in a smart contract (e.g., "Contract A") if certain execution conditions are met. If a second user 304 owns a second asset and is willing to execute an exchange with the first user 302, the second user 304 can create a second transaction 308 that accepts / fulfills the offer. The same data structure can be used to define the second transaction 308. Both users 302 and 304 can be concerned with executing the exchange in an atomic manner, which means that they can be concerned with ensuring that both transactions 306 and 308 succeed or both fail. To do this, both users 302 and 304 can follow Figure 3 The protocol 300 is shown 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 through 306-11 when creating the first transaction 306. The data fields may include a transaction identifier 306-1, a timestamp 306-2, a "from" data field 306-3, a "to" data field 306-4, a timeout parameter 306-5, a status flag 306-6, a method selector 306-7, an input data field 306-8, a target transaction identifier 306-9, one or more execution conditions 306-10, and one or more replacement instructions 306-11.

[0035] In some embodiments, transaction identifier 306-1 may specify a value uniquely identifying first transaction 306, such as a hashed string. Timestamp 306-2 may specify the time when first transaction 306 was created. "From" data field 306-3 may identify the transaction sender, which in this case is first user 302. "To" data field 306-4 may identify the transaction recipient, which may be set to Contract A, the contract that manages the first asset. Timeout parameter 306-5 may specify the time when first transaction 306 is set to expire. Status flag 306-6 may indicate the status of first transaction 306, including, for example, "pending," "successful," "recovered," or "expired." Method selector 306-7 may specify a method defined in Contract A to be invoked if / when first transaction 306 is executed. In some embodiments, the 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 to be 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 may be decoded for use as input parameters to the method when executing the first transaction 306.

[0036] The target transaction identifier 306-9 may indicate which transaction will be executed atomically with the first transaction 306. The transaction that will 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 zero). For example, this may occur when the first user 302 is creating the first transaction 306 as an offering transaction that offers to exchange a first asset for a second asset. 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 first transaction 306 to execute. In some embodiments, the conditions 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 be required to satisfy the execution condition 306-10 set forth by the first transaction 306 for the target transaction in order 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 as an execution condition 306-10 that the target transaction of the first transaction 306 must be a transaction that operates on the asset managed by contract B. This execution condition may be specified in the Figure 3 306 as "targetTx.to==contractB". In this way, if the second user 304 wants to accept the first user 302's offer to exchange the first asset for the second asset, the second user 304 may 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 executing the target transaction. 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 executing the target transaction. This execution condition may be in Figure 3 , as "targetTx.method == methodB" in the first transaction 306. In this manner, if the second user 304 wishes to accept the first user 302's offer to exchange the first asset for the second asset, the second user 304 may create a second transaction 308 with the method selector 308-7 set to methodB. 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, such as "methodB", where the value of the first parameter is greater than 10 and the value of the second parameter is less than 20. Target values for other parameters may be specified in a similar manner.

[0040] In some embodiments, the first user 302 may establish a target value based on a bid provided by the first user 302. For example, assuming that the first user 302 bids to exchange one unit of the first asset for at least eleven units of the second asset, and further assuming that methodB employs parameter param_B(1) as the total units of the second asset to be transferred, the first user 302 may specify as an execution condition 306-10 that param_B(1) must be greater than 10. In this manner, if the second user 304 wants to accept the first user 302's bid to exchange the first asset for the second asset, the second user 304 may create a second transaction 308 with parameter param_B(1) 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 above execution conditions 306-10 are provided as examples only and are not intended to be limiting. It is contemplated that other execution conditions 306-10 may be specified in a similar manner, and that target values may include numbers, strings, and values represented by other types of data structures. Note that while the specific implementation may vary, the purpose of implementing the execution conditions 306-10 may be the same, which is to provide the first user 302 with the ability to specify the conditions required for the target transaction of the first transaction 306 (e.g., in terms of which method of which smart contract is called with what parameters).

[0042] The replacement instructions 306-11 may provide instructions on how to replace one or more parameters (e.g., parameters specified in the input data field 306-8) of the first transaction 306. In some embodiments, if the execution condition 306-10 set forth by the first transaction 306 is satisfied, the instructions contained in the replacement instructions 306-11 may be executed. For example, Figure 3 As shown, the replacement instruction 306-11 can specify that if the target transaction satisfies the execution condition 306-10, the first parameter specified in the input data field 306-8 of the first transaction 306 can be replaced by the second parameter provided in the input data field of the target transaction. In this way, the first user 302 can specify the initial value of the first parameter in the input data field 306-8 and also set Figure 3 The first user 302 may indicate a willingness to accept the replacement value of the parameter by using the replacement instruction 306-11 shown in FIG. The first user 302 may also not specify an initial value for the first parameter and choose to accept the replacement value of the parameter.

[0043] It is contemplated that first user 302 may choose to accept alternate values for one or more parameters of first transaction 306 for various reasons. For example, if first user 302 is offering to exchange X units of a first asset, but is willing to accept an exchange offering Y units, first user 302 may specify a parameter with an initial value of X and also specify an alternate instruction 306-11 that allows for alternate values of the parameter. Similarly, if first user 302 is unsure how to set a parameter when creating first transaction 306, first user 302 may leave the parameter unspecified and choose to set the value of the parameter later, e.g., upon accepting the target transaction. It should be understood that first user 302 may have other reasons for choosing to accept alternate values for certain parameters, or for leaving certain parameters unspecified when creating first transaction 306. First user 302 may also set alternate instruction 306-11 to zero, indicating that no parameters of first transaction 306 require replacement.

[0044] It should be understood that the replacement instructions 306-11 depicted above are provided by way of example only and are not intended to be limiting. It is contemplated that the replacement instructions 306-11 may be specified in a variety of ways or formats. In some embodiments, the replacement instructions 306-11 may also include additional instructions to be executed if the execution condition 306-10 set forth by the first transaction 306 is satisfied. Such instructions may be written in any combination of one or more programming languages.

[0045] Once the first transaction 306 is created, the first user 302 may submit the first transaction 306 for recording on the blockchain. In some embodiments, the first transaction 306 submitted to the blockchain may be added to a block 310, which is subject to a consensus process. For illustrative purposes, black dots are used to indicate transactions included in various blocks of the blockchain (these transactions are included in the same Figure 1 ), and first transaction 306 is depicted as included in block 310 as one of the transactions. In some embodiments, the addition of first transaction 306 to block 310 may trigger transaction execution process 316, which may determine, in step 318, that first transaction 306 is a quote transaction because its target transaction identifier is set to zero and its execution condition is non-zero. Then, in step 320, transaction execution process 316 may set the status of first transaction 306 to "pending." Alternatively, in some embodiments, first transaction 306 submitted to the blockchain may remain in a pending transaction pool maintained by the blockchain without being added to any block. In some embodiments, first transaction 306 may remain in the pending transaction pool until it is fulfilled or expires.

[0046] Once the first transaction 306 is recorded on the blockchain, the first transaction 306 may become 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 308-1, a timestamp 308-2, a "from" data field 308-3, a "to" data field 308-4, a timeout parameter 308-5, a status flag 308-6, a method selector 308-7, an input data field 308-8, a target transaction identifier 308-9, one or more execution conditions 308-10, and one or more replacement instructions 308-11.

[0047] 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, which in this case is second user 304. "To" data field 308-4 may identify the transaction recipient, which may be Contract B, the contract that manages the second asset. Timeout parameter 308-5 may specify the time at which second transaction 308 is set to expire. Status flag 308-6 may indicate the status of transaction 308, including, for example, "pending," "successful," "reverted," or "expired." Method selector 308-7 may specify a method defined in Contract B to be invoked if / when second transaction 308 is executed. In some embodiments, the method may include a transfer operation provided by Contract B that transfers the second asset from second user 304 to a specified user (e.g., first user 302). Input data field 308-8 may specify one or more input parameters to be provided to the method specified in method selector 308-7. In some embodiments, the input data field 308 - 8 may include serialized input data that may be decoded for use as an input parameter to a method when executing the transaction 308 .

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

[0049] In some embodiments, the second transaction 308 serving as a fulfillment transaction may leave the execution condition 308-10 and the replacement instruction 308-11 empty (e.g., set to zero). In such an embodiment, the second transaction 308 may accept the execution condition 306-10 and the replacement instruction 306-11 set forth 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 set forth 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 block 312, which undergoes a consensus process.

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

[0051] 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 fulfillment transaction, the transaction execution process 316 may identify the target transaction specified by the target transaction identifier 308-9 as the offer transaction corresponding to the fulfillment 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 obtain the target transaction identifier 308-9 and identify the first transaction 306 as the offer transaction. The transaction execution process 316 may then execute the replacement instructions 306-11 (if any) specified in the first transaction 306 and cause the second transaction 308 to be executed and submitted along with the first transaction 306 if (1) the first transaction 306 is still valid and (2) the second transaction 308 satisfies the execution conditions 306-10 set forth in the first transaction 306.

[0052] 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 flag 306-6 of the first transaction 306. For example, if the transaction execution process 316 determines that the status flag 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 status flag 308-6 of the second transaction 308 to "revert"), such that any changes made by the second transaction 308 (if any) may be reverted on the blockchain.

[0053] 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. Therefore, 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 further set forth certain requirements for 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 is setting 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.

[0054] 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 flag 308-6 of the second transaction 308 to "revert") so that any changes made 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 both the first transaction 306 and the second transaction 308.

[0055] In some embodiments, the transaction execution process 316 may determine whether the first transaction 306 includes any replacement instructions 306-11 before executing the first transaction 306 and the second transaction 308. If the first transaction 306 does not include any replacement instructions 306-11 (e.g., the replacement instructions 306-11 are set to zero), the transaction execution process 316 may execute the first transaction 306 and the second transaction 308. On the other hand, if the first transaction 306 includes one or more replacement instructions 306-11 (e.g., the replacement instructions 306-11 are not set to zero), the transaction execution process 316 may execute the replacement instructions 306-11. Figure 3 In the example depicted in FIG, the transaction execution process 316 may determine that the replace instruction 306-11 is not set to zero. The transaction execution process 316 may execute the replace instruction 306-11 and replace the first parameter of the first transaction 306 (e.g., 20 (the first parameter specified in the data field 306-8)) with the second parameter of the second transaction 308 (e.g., 5 (the second parameter specified in the data field 308-8)). After executing the replace instruction 306-11, the transaction execution process 316 may continue to execute the first transaction 306 and the second transaction 308.

[0056] If both first transaction 306 and second transaction 308 execute successfully, transaction execution process 316 may commit the execution of both transactions on the blockchain (e.g., by merging transactions 306 and 308 into the blockchain and setting status flags 306-6 and 308-6 of transactions 306 and 308 to "success"). In this manner, the results of the execution may be included in a new block, e.g., block 314, which may then be added to the blockchain. On the other hand, if either first transaction 306 or second transaction 308 executes unsuccessfully, transaction execution process 316 may revert both transactions 306 and 308 (e.g., by setting status flags 306-6 and 308-6 of transactions 306 and 308 to "revert"), so that any changes made by first transaction 306 or second transaction 308 can be reverted on the blockchain. In this manner, atomicity can be achieved because both transactions 306 and 308 either succeed or fail, without allowing for partial processing.

[0057] In some embodiments, the transaction execution process 316 may also support the execution of transactions that are neither quote transactions nor fulfillment transactions. Such transactions may have a target transaction identifier, an execution condition, and a replacement instruction set to zero. When the transaction execution process 316 determines that the transaction is neither a quote transaction nor a fulfillment 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 status, as transactions are typically executed on a blockchain, thereby minimizing the impact of new data fields (e.g., target transaction identifier and execution condition) on regular transactions.

[0058] It should be understood that although the above examples reference transactions 306 and 308 created by users, such implementation is provided by way of 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 reference contracts A and B as two different smart contracts incorporated into the blockchain, such implementation is provided by way of 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 will also need to be a transaction sent to contract A. Furthermore, it should be understood that the above declarations of functions, variables, and transactions are presented by way of example only and are not intended to be limiting.

[0059] Figure 4 4 is a flow chart of a method 400 for providing atomic transactions on a blockchain according to an embodiment. The method 400 may be performed by one or more nodes in a blockchain system, such as nodes 102-110 ( Figure 1 ). The nodes 102-110 in the blockchain system 100 may be on the blockchain (e.g., blockchain 120 ( Figure 1 The blockchain 120 may be implemented as the blockchain in the above example.

[0060] 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 quote transaction, a fulfillment transaction, or a regular transaction.

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

[0062] In some embodiments, if node 102 determines that the transaction is a quote 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.

[0063] 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 bid transaction (e.g., first transaction 306, Figure 3 In some embodiments, node 102 may identify the target transaction based on the target transaction identifier specified in the fulfillment transaction (e.g., Figure 3 The node 102 may obtain the target transaction identifier specified in the fulfillment transaction and identify the quotation transaction based on the target transaction identifier.

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

[0065] In some embodiments, node 102 may determine whether the quote transaction is valid based on a timeout parameter specified in the quote transaction. For example, node 102 may calculate the difference between the current timestamp and the timestamp recorded when the quote transaction was created. Node 102 may compare the difference with the timeout parameter specified in the quote transaction. If the difference is greater than the timeout parameter, node 102 may consider that the quote transaction has expired and is therefore no longer valid. Alternatively or additionally, node 102 may determine whether the quote transaction is valid based on a status flag specified in the quote transaction. For example, if node 102 determines that the status flag specified in the quote transaction indicates that the quote transaction is still pending, node 102 may determine that the quote transaction is valid. In some embodiments, if node 102 determines that the quote transaction is no longer valid, node 102 may resume the fulfillment transaction so that any changes made by the fulfillment transaction can be restored on blockchain 120.

[0066] In some embodiments, the bid transaction may specify one or more execution conditions, and node 102 may determine whether the fulfillment transaction satisfies each execution condition specified in the bid transaction. The execution condition may specify, for example, a smart contract to which the fulfillment transaction should be sent, a method call 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.

[0067] In step 410, in response to determining that the bid transaction is valid and the fulfillment transaction satisfies the execution conditions specified in the bid transaction, node 102 may determine whether the bid transaction contains any replacement instructions (e.g., Figure 3 If the bid transaction does not include any substitution instructions, node 102 may proceed to step 412. On the other hand, if the bid transaction includes one or more substitution instructions, node 102 may execute the substitution instructions and proceed to step 412.

[0068] At step 412, node 102 may execute the fulfillment transaction and the offer transaction. In some embodiments, node 102 may determine whether the fulfillment transaction and the offer transaction were successfully executed. If both the fulfillment transaction and the offer transaction were successfully executed, node 102 may commit the execution of the fulfillment transaction and the offer transaction on blockchain 120. On the other hand, if at least one of the fulfillment transaction and the offer transaction was not successfully executed, node 102 may revert both the fulfillment transaction and the offer transaction so that any changes made by the fulfillment transaction or the offer transaction can be reverted on blockchain 120. In this manner, atomicity can be achieved because both the fulfillment transaction and the offer transaction can succeed or fail, without allowing partial processing.

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

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

[0071] The determination module 504 can determine whether the transaction is a quote transaction, a fulfillment 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 quote transaction, the determination module 504 can set the transaction status to pending. If the transaction is a fulfillment transaction, the determination module 504 can provide the transaction to the identification module 506 for further processing.

[0072] Identification module 506 may identify a bid transaction corresponding to a fulfillment transaction. In some embodiments, identification module 506 may identify the bid transaction based on a target transaction identifier specified in the fulfillment transaction. Identification module 506 may obtain the target transaction identifier specified in the fulfillment transaction and identify the bid transaction based on the target transaction identifier. Identification module 506 may then provide the identified bid transaction to determination module 504.

[0073] The determination module 504 may determine whether the bid transaction is valid and whether the fulfillment transaction satisfies the execution conditions specified in the bid transaction. In response to determining that the bid transaction is valid and the fulfillment transaction satisfies the execution conditions specified in the bid transaction, the determination module 504 may also determine whether the bid transaction includes any replacement instructions. If the bid transaction does not include any replacement instructions, the determination module 504 may provide the bid transaction and the fulfillment transaction to the execution module 508 for execution. On the other hand, if the bid transaction includes one or more replacement instructions, the determination module 504 may request the execution module 508 to execute the replacement instructions. The determination module 504 may then provide the bid transaction and the fulfillment transaction to the execution module 508 for execution.

[0074] In some embodiments, if both the bid and fulfillment transactions are successfully executed, the execution module 508 can commit the bid and fulfillment transactions to the blockchain. On the other hand, if at least one of the bid and fulfillment transactions is unsuccessful, the execution module 508 can revert both the bid and fulfillment transactions, allowing any changes made by either transaction to be reverted on the blockchain. In this manner, atomicity can be achieved because both the bid and fulfillment transactions can succeed or fail, without allowing for partial processing.

[0075] 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. In addition, for example, each of the above modules can be implemented by 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 method. In addition, for example, each of the above modules can be implemented by using a computer chip or entity, or by using a product with a specific function. In one embodiment, 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 receiving and sending device, a game console, a tablet computer, a wearable device or any combination of these devices.

[0076] For the implementation process of the functions and effects 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.

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

[0078] A computer-readable storage medium may be a tangible device that can store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: a portable computer disk, 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 (e.g., a punch card or raised structures in grooves with instructions recorded thereon), and any suitable combination thereof.

[0079] 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 (comprising object-oriented programming languages and conventional process programming languages). The computer-readable program instructions can be performed completely on a computing device as an independent software package, or partly on a first computing device and partly on a second computing device away from the first computing device. In the latter's case, the second remote computing device can be connected to the first computing device by a network of any type (comprising a local area network (LAN) or a wide area network (WAN)).

[0080] 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, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the above-described methods.

[0081] The flowcharts and diagrams in the accompanying drawings illustrate the architecture, functions and operations of possible implementations of the devices, methods and computer program products according to the various embodiments of this specification. In this regard, the boxes in the flowcharts or diagrams may represent a portion of a software program, code segment or code, which includes one or more executable instructions for implementing a specific function. It should also be noted that in some alternative embodiments, the functions marked in the boxes may also occur in an order different from that marked in the figures. For example, two boxes shown in succession can actually be executed substantially in parallel, and they 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 the boxes in the diagrams and flowcharts, can be implemented by a dedicated hardware-based system that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0082] It will be appreciated that certain features of this specification that, for the sake of clarity, are described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of this specification that, for the sake of brevity, are described in the context of a single embodiment may also be provided separately or in any suitable subcombination or in any other described embodiment of this specification as appropriate. Certain features described in the context of various embodiments are not essential features of those embodiments unless so indicated.

[0083] Although the present specification 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 appended claims encompass all such alternatives, modifications and variations that fall within the terms 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 quote transaction corresponding to the fulfillment transaction; determining whether the bid transaction is valid and whether the fulfillment transaction satisfies the execution conditions specified in the bid transaction; as well as In response to determining that the bid transaction is valid and the fulfillment transaction satisfies the execution condition specified in the bid transaction, executing the replacement instruction specified in the bid transaction and executing the fulfillment transaction and the bid transaction.

2. The method according to claim 1, wherein Executing the replacement instruction specified in the quote transaction further includes: A parameter specified in the bid transaction is replaced with another parameter specified in the fulfillment transaction.

3. The method according to claim 1, further comprising: determining whether the replacement instruction is set to zero; as well as In response to determining that the replacement instruction is set to zero, the quote transaction is valid, and the fulfillment transaction satisfies the execution condition specified in the quote transaction, the fulfillment transaction and the quote transaction are executed.

4. The method according to claim 1, further comprising: determining whether the transaction is a quoted transaction; as well as In response to determining that the transaction is a quote transaction, setting a status of the transaction to pending.

5. The method according to claim 1, further comprising: determining whether the transaction is a regular transaction; as well as In response to determining that the transaction is a regular transaction, executing the transaction.

6. The method according to any one of the preceding claims 1 to 5, wherein Determining whether the transaction is a fulfillment transaction further includes: determining whether the transaction specifies a target transaction identifier; and In response to determining that the transaction specifies a target transaction identifier, the transaction is identified as a fulfillment transaction.

7. The method according to claim 6, wherein: Identifying the quote transaction corresponding to the fulfillment transaction further comprises: Obtaining the target transaction identifier specified in the fulfillment transaction; and The quoted transaction is identified based on the target transaction identifier.

8. The method according to any one of the preceding claims 1 to 5 and 7, wherein Determining whether the quoted transaction is valid further includes: Whether the quote transaction is valid is determined based on at least one of a timeout parameter specified in the quote transaction or a status flag specified in the quote transaction.

9. The method according to any one of the preceding claims 1 to 5 and 7, wherein The execution condition specified in the offer transaction specifies a smart contract and a method defined in the smart contract to be called by the fulfillment transaction.

10. The method according to any one of the preceding claims 1 to 5 and 7, wherein The execution conditions specified in the bid transaction specify a target value and how the target value is compared to the parameters included in the fulfillment transaction.

11. The method according to any one of the preceding claims 1 to 5 and 7, further comprising: determining whether the fulfillment transaction and the quote transaction are successfully executed; as well as In response to determining that both the fulfillment transaction and the offer transaction were successfully executed, committing execution of both the fulfillment transaction and the offer 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 quote transaction was not successfully executed, both the fulfillment transaction and the quote transaction are resumed.

13. A device for providing atomic transactions on a blockchain, comprising: one or more processors; as well as 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 plurality of modules for executing the method according to any one of claims 1 to 12, the plurality of modules comprising: A receiving module, configured to receive a transaction submitted to the blockchain; a determination module, configured to determine whether the transaction is a fulfillment transaction; an identification module for, in response to determining that the transaction is a fulfillment transaction, identifying a quote transaction corresponding to the fulfillment transaction; an execution module, configured to determine whether the quoted transaction is valid and whether the fulfillment transaction satisfies the execution conditions specified in the quoted transaction; and in response to determining that the offer transaction is valid and the fulfillment transaction satisfies the execution condition specified in the offer transaction, executing the replacement instruction specified in the offer transaction and executing the fulfillment transaction and the offer transaction.

15. A non-transitory computer-readable medium having stored therein 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