CN114930374A

CN114930374A - Method and apparatus for providing atomic transactions over blockchains

Info

Publication number: CN114930374A
Application number: CN202080092109.6A
Authority: CN
Inventors: 杨伟涛; 曹圣皎; 袁园; 方晖
Original assignee: Alipay Labs Singapore Pte Ltd
Current assignee: Alipay Labs Singapore Pte Ltd
Priority date: 2020-01-07
Filing date: 2020-12-26
Publication date: 2022-08-19
Also published as: SG10202000133TA; WO2021139542A1

Abstract

Methods, apparatus, and devices, including computer programs stored on computer readable media, for providing atomic transactions over blockchains are disclosed. One of the methods 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 an offer 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 that the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing the replacement instruction specified in the quote transaction and executing the fulfillment transaction and the quote transaction.

Description

Method and apparatus for providing atomic transactions over blockchains

Technical Field

The present disclosure relates generally to computer technology and, more particularly, to methods and apparatus for providing atomic transactions over blockchains.

Background

A blockchain system, also known as a Distributed Ledger System (DLS) or consensus system, may enable participating entities to store data securely and immutably. The blockchain system may include any DLS without reference to any specific use case and may be used for public, private, and federated blockchain networks. The common blockchain network is open to all entities to use the system and participate in the consensus process. A private blockchain network is provided for a specific entity that centrally controls read and write permissions. A federated blockchain network is provided for a selected set of entities that control a consensus process, and the federated blockchain network includes an access control layer.

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 may initiate communication with another node in the P2P network.

The blockchain system maintains one or more blockchains. Blockchains are data structures used to store data (such as transactions) that can prevent malicious parties from tampering with and manipulating the data. The blockchain system may support the execution of one or more intelligent contracts. Each intelligent contract may be a computer protocol in the form of computer code incorporated into a blockchain to facilitate, verify, or enforce negotiation or execution of contracts.

The blockchain use case may require that both transactions be processed atomically, meaning that both transactions succeed or fail, while not allowing partial processing. However, current implementations of blockchain systems do not have built-in mechanisms to support atomic transactions.

To achieve atomicity, a separate custom intelligent 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 that operates on a 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 agent contract. Likewise, the second user may need to create a second transaction that operates on a 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 agent contract. After two transactions have been received, the proxy contract may invoke a pair of a first contract and a second contract to execute the two transactions.

As the number of agent 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, thereby further increasing the number of transactions required to perform atomic transactions.

Disclosure of Invention

In one aspect, a computer-implemented method for providing atomic transactions over 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 an offer 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 that the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing the replacement instructions specified in the quote transaction and executing the fulfillment transaction and the quote transaction.

In another aspect, an apparatus for providing atomic transactions over a blockchain includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to: 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 an offer 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 that the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing the replacement instruction specified in the quote transaction and executing the fulfillment transaction and the quote transaction.

In yet another aspect, a non-transitory computer-readable medium has instructions stored therein, which when executed by a processor of a device, cause the device to perform a method for providing atomic transactions over a blockchain. The method comprises the following steps: 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 an offer 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 that the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing the replacement instructions specified in the quote transaction and executing the fulfillment transaction and the quote transaction.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description with reference to the drawings, the same reference numerals in different drawings denote the same or similar elements, unless otherwise indicated.

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment.

Fig. 2 is a schematic diagram of a computing device for implementing a node in a blockchain system, according to an embodiment.

Fig. 3 is a schematic diagram depicting a protocol for providing atomic transactions over a blockchain, according to an embodiment.

Fig. 4 is a flow diagram of a method for providing atomic transactions over a blockchain, according to an embodiment.

Fig. 5 is a block diagram of an apparatus for providing atomic transactions on a blockchain, according to an embodiment.

Detailed Description

Embodiments of the present specification provide methods and apparatus for providing atomic transactions over blockchains. The method and apparatus may add certain data fields to the data structure of a blockchain transaction to support the execution of atomic transactions. Such atomic transactions may be performed atomically over the blockchain without requiring the blockchain to deploy agent contracts. The methods and apparatus may also support the replacement of certain parameters specified in an atomic transaction, thereby providing flexibility for such atomic transactions. The method and apparatus may also allow the new data field to be set to zero. Transactions with a new data field set to zero may be performed on the blockchain in a conventional manner, thereby minimizing the impact of changes to the data structure on conventional transactions.

The embodiments disclosed in this specification have one or more technical effects. In some embodiments, the methods and apparatus add certain data fields to the data structure of a blockchain transaction. This allows the method and apparatus to support performing atomic transactions on blockchains without requiring blockchain deployment of proxy contracts, which in turn reduces consumption of memory space and computing resources. This also allows each contract defined on the blockchain to have the ability to interact with other contracts regardless of when the contract is deployed and how the contract is implemented. In some embodiments, the methods and apparatus support the replacement of certain parameters specified in an atomic transaction. This allows the atomic transaction to have a level of flexibility which, in turn, allows the user to set up the atomic transaction without having to specify predetermined values for all parameters in the atomic transaction. In some embodiments, the method and apparatus may process transactions where the new data field is set to zero. This allows the method 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 changes to the data structure on regular transactions. In this way, the method and apparatus can be used in existing blockchain systems without significant modification.

Blockchains are data structures that store data (e.g., transactions) in a manner that can prevent malicious parties from tampering with and manipulating the data. Transactions stored in this manner may be immutable and subsequently verified. A block chain includes one or more blocks. Each block is linked to the previous block immediately preceding it in the chain of blocks by including a cryptographic hash of the previous block. Each tile may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes of a blockchain system may be hashed and encoded into a data structure, such as a merkel (Merkle) tree. In a Merkle tree, data at leaf nodes of the tree is hashed, and all hashes in each branch of the tree may 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 of the data in the tree. The hash of a transaction purported to be stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

The blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. For example, many entities (such as hundreds, thousands, or even millions of entities) may operate in a common blockchain network, and each entity operates at least one node in the common blockchain network. Thus, a common blockchain network may be considered a common network with respect to participating entities. Sometimes, most entities (nodes) must sign each chunk in order for the chunk to be valid and added to the blockchain of the blockchain network. Examples of common blockchain networks include certain peer-to-peer payment networks that utilize a distributed ledger, referred to as blockchains.

In general, a common blockchain network may support common transactions. The common transactions are shared by all nodes in the common blockchain network and are stored in the global blockchain. A global blockchain is a blockchain that is replicated across all nodes, and all nodes are in perfect state consensus with respect to the global blockchain. To enable consensus (e.g., agree to add a block to a blockchain), a consensus protocol is implemented in a common blockchain network. Examples of consensus protocols include proof of work (POW) (e.g., implemented in some cryptocurrency networks), proof of interest (POS), and proof of authorization (POA).

Typically, a private blockchain network may be provided for a particular entity that centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as licensed networks, which impose restrictions on who is allowed to participate in the network and its level of participation (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants voting on adding a new entity, regulatory agencies may control admission).

In general, a federated blockchain network may be private between participating entities. In a federated blockchain network, the consensus process is controlled by an authorized set of nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, each operating at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network with respect to participating entities. In some examples, each entity (node) must sign each chunk to make the chunk valid and added to the chain of chunks. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each chunk to make the chunk valid and added to the chunk chain.

Fig. 1 shows a schematic diagram of a blockchain system 100 according to an embodiment. Referring to fig. 1, a blockchain system 100 may include a plurality of nodes, such as

nodes

102 and 110, configured to operate on a blockchain 120. The

nodes

102 and 110 may form a network 112, such as a peer-to-peer (P2P) network. Each

node

102 and 110 may be a computing device, such as a computer or computer system, configured to store a copy of block chain 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 identification.

Block chain 120 may include an ever-increasing list of records in the form of data blocks, such as blocks B1-B5 in FIG. 1. Each tile B1-B5 may include a timestamp, a cryptographic hash of the previous tile, and data for the current tile, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, chunk B5 may include a timestamp, a cryptographic hash of chunk B4, and transaction data of chunk B5. Further, for example, a hash operation may be performed on the previous chunk to generate a cryptographic hash of the previous chunk. The hash operation may convert inputs of various lengths into fixed-length encrypted outputs through a hash algorithm, such as SHA-256.

Nodes

102 and 110 may be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto blockchain 120, the node may generate a new block to be added to blockchain 120 and broadcast the new block to other nodes (e.g., node 104) in network 112. Based on the validity of the new tile, e.g., its signature and transaction validity, other nodes may determine to accept the new tile so that node 102 and other nodes may add the new tile to their respective copies of the blockchain 120. As this process repeats, more and more data blocks may be added to the blockchain 120.

Fig. 2 illustrates a schematic diagram of a computing device 200 for implementing a node (e.g., node 102 (fig. 1)) in a blockchain system, according to an embodiment. Referring to fig. 2, computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

The communication interface 202 may facilitate communication between the computing device 200 and devices implementing other nodes in the network, such as node 104 and 110 (FIG. 1). In some embodiments, communication interface 202 is configured to support one or more communication standards, such as an internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, and so on. In some embodiments, 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, a hybrid public/private cloud infrastructure.

Processor 204 may include one or more special-purpose 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.

Memory 206 may store processor-executable instructions and data, such as a copy of blockchain 120 (fig. 1). The memory 206 may include any type or combination of volatile or non-volatile memory devices, 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 the instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

Fig. 3 shows a schematic diagram depicting a protocol 300 for providing atomic transactions over a blockchain according to an embodiment. Referring to fig. 3, multiple users may have accounts on a blockchain, such as blockchain 120 (fig. 1). Blockchains may 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, and the like.

For purposes of illustration, a first user 302 and a second user 304 are depicted in FIG. 3. Also depicted in FIG. 3 are two intelligent contracts, contract A and contract B. An intelligent contract is a computer protocol implemented in the form of computer code incorporated into a blockchain to facilitate, verify, or implement negotiation or execution of contracts. For example, a user of the blockchain may program agreement terms into the smart contract using a programming language (such as C + +, Java, Solidity, Python, etc.), and when the terms are satisfied, the smart contract may be automatically executed on the blockchain, e.g., to perform a transaction. Further, for example, a smart contract may include a number of subroutines, functions, or methods, each of which may be a sequence of program instructions that perform a particular task. A smart contract may be an operation code that executes in whole or in part without human interaction. In some embodiments, a first intelligent contract (e.g., contract a) may be incorporated into a blockchain to manage some assets (e.g., some type of digital currency) recorded on the blockchain. A second intelligent contract (e.g., contract B) may also be incorporated into the blockchain to manage some assets (e.g., certain types of goods) recorded on the blockchain. For illustrative purposes, a dashed rectangle is used to indicate a transaction that may invoke one or more methods defined in contracts A and B. It should be understood that the dashed rectangle does not indicate a data structure maintained by the blockchain.

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 may create a first transaction 306 that offers to exchange the first asset for the second asset. The first transaction 306 may be defined using the data structure shown in fig. 3, which in turn defines events that may be performed on the blockchain. As will be described in detail below, first transaction 306 may define an event as the invocation of a method (e.g., "method A") defined in a smart contract (e.g., "contract A") if certain execution conditions are met. If second user 304 owns the second asset and is willing to perform an exchange with first user 302, second user 304 may create a second transaction 308 that accepts/fulfills the offer. The same data structure may be used to define the second transaction 308. Both

users

302 and 304 may be interested in performing the exchange in an atomic manner, meaning they may be interested in ensuring that both

transactions

306 and 308 succeed or fail. To this end, both

users

302 and 304 may follow the protocol 300 shown in FIG. 3 to perform a first transaction 306 and a second transaction 308.

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 identification 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 identification 306-9, one or more execution conditions 306-10, and one or more replacement instructions 306-11.

In some embodiments, the transaction identification 306-1 may specify a value, e.g., a hashed string, that uniquely identifies the first transaction 306. The timestamp 306-2 may specify the time at which the first transaction 306 was created. The "from" data field 306-3 may identify the transaction sender, which in this case is the first user 302. The "to" data field 306-4 may identify a transaction recipient, which may be set to contract a, i.e., a contract that manages a first asset. The timeout parameter 306-5 may specify a time at which the first transaction 306 is set to expire. The status flag 306-6 may indicate the status of the first transaction 306, including, for example, "pending," successful, "" recovery, "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 the first user 302 to a specified user (e.g., the 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, which may be decoded for use as an input parameter to a method when executing the first transaction 306.

Target transaction identification 306-9 may indicate which transaction is to be executed atomically with first transaction 306. The transaction that will be executed atomically with first transaction 306 may be referred to as a "target" transaction of first transaction 306. In some embodiments, the target transaction identification 306-9 may be left blank (e.g., set to zero) if the first user 302 does not know which transaction is the target transaction for the first transaction 306. This may occur, for example, when the first user 302 is creating a first transaction 306 as an offer transaction (offering transaction) that exchanges the first asset for the second asset. When first transaction 306 is created, second transaction 308 may not have been created, and thus target transaction identification 306-9 of first transaction 306 may be left blank.

The execution conditions 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 a target transaction of the first transaction 306. In other words, a target transaction of the first transaction 306 may be required to satisfy the execution conditions 306-10 set forth by the first transaction 306 for the target transaction to execute atomically with the first transaction 306. Continuing with the above example, in the event that first user 302 wants to exchange a first asset managed by contract A for a second asset managed by contract B, first user 302 may designate as execution condition 306-10 a transaction for which the target transaction of first transaction 306 must be an operation on the asset managed by contract B. This execution condition may be expressed as "targettx. In this manner, if second user 304 wants to accept first user's 302 offer to exchange a first asset for a second asset, second user 304 may create second transaction 308 having "to" data field 308-4 set to contract B. Otherwise, second transaction 308 may not satisfy execution conditions 306-10 for first transaction 306.

The first user 302 may also ask a target transaction of the first transaction 306 to invoke a particular method provided by the contract B when executing the target transaction. For example, in some embodiments, the first user 302 may require a target transaction of the first transaction 306 to invoke a method defined in contract B that performs the transfer operation when the target transaction is executed. This execution condition may be expressed as "targettx. In this manner, if second user 304 wants to accept first user 302's offer to exchange a first asset for a second asset, second user 304 may create second transaction 308 with 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.

The first user 302 may also specify additional execution conditions 306-10. For example, as shown in FIG. 3, the first user 302 may request that the target transaction of the first transaction 306 invoke 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. The target values of the other parameters may be specified in a similar manner.

In some embodiments, the first user 302 may establish the target value based on an offer provided by the first user 302. For example, assuming that first user 302 bid to exchange one unit of a first asset for at least eleven units of a second asset, and further assuming that methodB employs parameter param _ B (1) as the total units of the second asset to be transferred, first user 302 may designate param _ B (1) as necessarily greater than 10 as execution conditions 306-10. In this manner, if second user 304 wants to accept first user's 302 offer to exchange a first asset for a second asset, second user 304 may create second transaction 308 with parameter param _ B (1) set greater than 10. Otherwise, the second transaction 308 may not satisfy the execution condition 306-10 of the first transaction 306.

It should be understood that the above-described execution conditions 306-10 are provided as examples only and are not meant to be limiting. It is contemplated that other execution conditions 306-10 may be specified in a similar manner and that the target value may include numbers, strings, and values represented in other types of data structures. Note that while the particular implementation may vary, the purpose of implementing the execute condition 306-10 may be the same, providing 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 invoked with what parameters).

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

It is contemplated that the first user 302 may choose to accept alternative values for one or more parameters of the first transaction 306 for various reasons. For example, if the first user 302 is bidding to swap X units of the first asset, but is willing to accept a trade proposing a swap of Y units, the first user 302 may specify a parameter having an initial value of X and also specify the replacement instructions 306-11 that allow for the value of the replacement parameter. Similarly, if the first user 302 is unsure of how to set the parameter when creating the first transaction 306, the first user 302 may leave the parameter unspecified, but instead choose to set the value of the parameter later, for example, when accepting the target transaction. It should be appreciated that the first user 302 may have other reasons to choose to accept alternative values for certain parameters, or to leave certain parameters unspecified when creating the first transaction 306. The first user 302 may also set the replacement instruction 306-11 to zero, indicating that no parameters of the first transaction 306 need to be replaced.

It should be understood that the replacement instructions 306-11 depicted above are provided as examples only and are not meant to be limiting. It is contemplated that replacement instructions 306-11 may be specified in various manners or formats. In some embodiments, the replacement instructions 306-11 may also include additional instructions to be executed if the execution conditions 306-10 set forth by the first transaction 306 are met. Such instructions may be written in any combination of one or more programming languages.

Once the first transaction 306 is created, the first user 302 may submit the first transaction 306 to be recorded on the blockchain. In some embodiments, the first transaction 306 submitted to the blockchain may be added to block 310, which is subjected to a consensus process. For purposes of illustration, the dark dots are used to indicate the transactions contained in the various blocks of the blockchain (these transactions are contained in blocks similar to those contained in block B5 of fig. 1), and first transaction 306 is depicted as being contained in block 310 as one of the transactions. In some embodiments, adding the first transaction 306 to block 310 may trigger a transaction execution process 316, which may determine at step 318 that the first transaction 306 is a bid transaction because its target transaction identification is set to zero and its execution condition is not zero. The transaction execution process 316 may then set the status of the first transaction 306 to "pending" at step 320. Alternatively, in some embodiments, the first transaction 306 submitted to the blockchain may remain in the pending transaction pool maintained by the blockchain, without being added to any of the blocks. In some embodiments, the first transaction 306 may remain in the pending transaction pool until its fulfillment or expiration.

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 the second transaction 308 to accept/fulfill the offer specified in the first transaction 306. Second user 304 may specify various data fields 308-1 through 308-10 when creating second transaction 308. The data fields may include a transaction identification 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 identification 308-9, one or more execution conditions 308-10, and one or more replacement instructions 308-11.

Transaction identification 308-1 may specify a value, e.g., a hash string, that uniquely identifies transaction 308. The timestamp 308-2 may specify the time at which the transaction 308 was created. The "slave" data field 308-3 may identify the transaction sender, which in this case is the second user 304. The "to" data field 308-4 may identify a transaction recipient, which may be set to contract B, i.e., a contract that manages a second asset. The timeout parameter 308-5 may specify a time at which the second transaction 308 is set to expire. Status flags 308-6 may indicate the status of transaction 308 including, for example, "pending," successful, "" recovery, "or" expired. Method selector 308-7 may specify a method defined in contract B to invoke if/when executing second transaction 308. In some embodiments, the method may include a transfer operation provided by contract B to transfer the second asset from the second user 304 to a specified user (e.g., the first user 302). The input data field 308-8 may specify one or more input parameters to be 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, which may be decoded for use as an input parameter to a method when executing the transaction 308.

The target transaction identification 308-9 may indicate which transaction is to be performed atomically with the second transaction 308. In this case, second user 304 may set target transaction identification 308-9 to transaction identification 306-1 of first transaction 306, indicating that first transaction 306 is to be performed atomically with second transaction 308. In this manner, the second transaction 308 may be considered to have been created to fulfill the first transaction 306. Thus, the second transaction 308 may be referred to as a filling transaction.

In some embodiments, the second transaction 308 used as a fulfillment transaction may leave the execution conditions 308-10 and the replacement instructions 308-11 empty (e.g., set to zero). In such an embodiment, second transaction 308 may accept execution conditions 306-10 and replacement instructions 306-11 set forth in first transaction 306. However, in order for second transaction 308 to be a valid fulfillment transaction, second transaction 308 must satisfy execution conditions 306-10 set forth in 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 is subject to a consensus process.

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

At step 322, the transaction execution process 316 may identify the target transaction specified by the target transaction identification 308-9 of the second transaction 308. Because the transaction execution process 316 has determined that the second transaction 308 is a redemption transaction, the transaction execution process 316 may identify the target transaction specified by the target transaction identification 308-9 as an offer transaction corresponding to a redemption transaction. Continuing with the above example, the target transaction identification 308-9 of the second transaction 308 may identify the first transaction 306 as the target transaction, thereby allowing the transaction execution process 316 to obtain the target transaction identification 308-9 and identify the first transaction 306 as an 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 committed 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.

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 a difference between the current timestamp and the timestamp 306-2 of the first transaction 306 and compare the difference to 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 resume the second transaction 308 (e.g., by setting the status flag 308-6 of the second transaction 308 to "resume") so that any changes (if any) made by the second transaction 308 may be resumed on the blockchain.

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 conditions 306-10 set forth in the first transaction 306. Continuing with the above example, execution conditions 306-10 may require that second transaction 308 be sent to contract B, and that second transaction 308 invoke method B when 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 that 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, execution conditions 306-10 may further set forth certain requirements for 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 the parameters param _ B (1) and param _ B (2) to values that do not comply with the requirements set forth in the execution conditions 306-10, the transaction execution process 316 may determine that the second transaction 308 does not satisfy the execution conditions 306-10.

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 resume the second transaction 308 (e.g., by setting the status flag 308-6 of the second transaction 308 to "resume") so that any changes made by the second transaction 308 may be resumed 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.

In some embodiments, the transaction execution process 316 may determine whether the first transaction 306 contains any replacement instructions 306-11 prior to executing the first transaction 306 and the second transaction 308. If the first transaction 306 does not contain 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 contains 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. Continuing with the example depicted in FIG. 3, the transaction execution process 316 may determine that the replacement instruction 306-11 is not set to zero. The transaction execution process 316 may execute the replacement instruction 306-11 and replace a first parameter (e.g., 20 (the first parameter specified in the data field 306-8)) of the first transaction 306 with a second parameter (e.g., 5 (the second parameter specified in the data field 308-8)) of the second transaction 308. After executing the replacement instructions 306-11, 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 were successfully executed, the transaction execution process 316 may submit the execution of both transactions on the blockchain (e.g., by merging the

transactions

306 and 308 into the blockchain and setting the status flags 306-6 and 308-6 of the

transactions

306 and 308 to "successful"). 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 chain of blocks. On the other hand, if the first transaction 306 or the second transaction 308 is not successfully executed, the transaction execution process 316 may resume both transactions 306 and 308 (e.g., by setting the status flags 306-6 and 308-6 of the

transactions

306 and 308 to "resume") so that any changes made by the first transaction 306 or the second transaction 308 may be resumed on the blockchain. In this way, atomicity may be achieved because both

transactions

306 and 308 succeed or fail, while partial processing is not allowed.

In some embodiments, the transaction execution process 316 may also support the execution of transactions that are neither bid transactions nor fulfillment transactions. Such a transaction may have a target transaction identification, 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 fulfill 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 conventional transactions in a conventional manner. For example, the transaction execution process 316 may execute the transaction and update the status of the transaction, as the transaction is typically executed on a blockchain, thereby minimizing the impact of new data fields (e.g., target transaction identification and execution conditions) on the regular transaction.

It should be understood that while the above examples refer to user-created

transactions

306 and 308, such embodiments are provided as examples only and are not meant to be limiting. In some embodiments,

transactions

306 and 308 may be user-created or system-generated. It should also be understood that while the above examples refer to contracts a and B as two different intelligent contracts incorporated into a blockchain, such embodiments are provided as examples only and are not meant to be limiting. In some embodiments, the first user 302 may be allowed to set a target transaction (e.g., targettx. to) as contract a, in which case the fulfillment transaction would also need to be the transaction sent to contract a. Further, it should be understood that the above statements of functions, variables, and transactions are presented as examples only and are not meant to be limiting.

Fig. 4 illustrates a flow diagram of a method 400 for providing atomic transactions over a blockchain, according to an embodiment. The method 400 may be performed by one or more nodes in a blockchain system, such as the node 102 and 110 (fig. 1) in the blockchain system 100. Nodes 102-110 in the blockchain system 100 may perform operations on blockchains, such as blockchain 120 (fig. 1). Block chain 120 may be implemented as the block chain in the above example.

At step 402, a node (e.g., node 102) may receive a transaction submitted to blockchain 120. At step 404, node 102 may determine that the transaction is a bid transaction, a fulfillment transaction, or a regular transaction.

In some embodiments, node 102 may determine that the transaction is an offer transaction if the transaction specifies one or more execution conditions but does not specify a target transaction identification. If the transaction specifies a target transaction identification, the node 102 may identify the transaction as fulfilling the transaction. If the transaction specifies neither the target transaction identification nor the execution condition, the node 102 may identify the transaction as a regular transaction.

In some embodiments, if the node 102 determines that the transaction is a bid transaction, the node 102 may set the status of the transaction 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.

At step 406, in response to determining that the transaction is a fulfillment transaction (e.g., the second transaction 308, fig. 3), the node 102 may identify a bidding transaction (e.g., the first transaction 306, fig. 3) corresponding to the fulfillment transaction. In some embodiments, node 102 may identify the bid transaction based on a target transaction identification (e.g., target transaction identification 308-9 in fig. 3) specified in the fulfillment transaction. Node 102 may obtain a target transaction identification specified in the fulfillment transaction and identify the offer transaction based on the target transaction identification.

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.

In some embodiments, the node 102 may determine whether the bid transaction is valid based on a timeout parameter specified in the bid transaction. For example, the node 102 may calculate the difference between the current timestamp and the timestamp recorded when the bid transaction was created. Node 102 may compare the difference to a timeout parameter specified in the bid transaction. If the difference is greater than the timeout parameter, the node 102 may consider the bid transaction to have expired and thus no longer valid. Alternatively or additionally, node 102 may determine whether the bid transaction is valid based on a status flag specified in the bid transaction. For example, if the node 102 determines that the status flag specified in the bid transaction indicates that the bid transaction is still pending, the node 102 may determine that the bid transaction is valid. In some embodiments, if the node 102 determines that the bid transaction is no longer valid, the node 102 may resume the fulfillment transaction such that any changes made by the fulfillment transaction may be resumed on the blockchain 120.

In some embodiments, the bid transaction may specify one or more execution conditions, and the node 102 may determine whether each execution condition specified in the bid transaction is satisfied by the fulfillment transaction. The execution condition may specify, for example, an intelligent contract to which the fulfillment transaction should be sent, a method call that the fulfillment transaction should call, or a target value of a parameter that should be included in the fulfillment transaction. It is understood that the target value may be specified as a particular value, a range of values, a minimum value, a maximum value, and the like.

At step 410, in response to determining that the bid transaction is valid and that 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., replacement instructions 306-11 in fig. 3). If the bid transaction does not contain any replacement instructions, node 102 may proceed to step 412. On the other hand, if the bid transaction contains one or more replacement instructions, node 102 may execute the replacement instructions and proceed to step 412.

At step 412, node 102 may execute a fulfillment transaction and a bid 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 are successfully executed, node 102 may submit the execution of the fulfillment transaction and the offer transaction over blockchain 120. On the other hand, if at least one of the redemption transaction and the bid transaction is not successfully executed, the node 102 may resume both the redemption transaction and the bid transaction so that any changes made by either the redemption transaction or the bid transaction may be resumed on the blockchain 120. In this way, atomicity may be achieved because the fulfillment transaction and the offer transaction may both succeed or fail without allowing partial processing.

Fig. 5 is a block diagram of an apparatus 500 for providing atomic transactions over a blockchain, according to an embodiment. Apparatus 500 may be an embodiment of a software process and may correspond to method 400 (fig. 4). Referring to fig. 5, the apparatus 500 may include a receiving module 502, a determining module 504, an identifying module 506, and an executing module 508.

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

The determination module 504 may determine whether the transaction is an offer transaction, a fulfillment transaction, or a regular transaction. If the transaction is a regular transaction, the determination module 504 may provide the transaction to the execution module 508 for execution. If the transaction is an offer transaction, the determination module 504 may set the status of the transaction as pending. If the transaction is a fulfillment transaction, determination module 504 may provide the transaction to identification module 506 for further processing.

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

The determination module 504 may determine whether the quote transaction is valid and whether the fulfillment transaction satisfies the execution conditions specified in the quote transaction. In response to determining that the quote transaction is valid and that the fulfillment transaction satisfies the execution conditions specified in the quote transaction, the determination module 504 may also determine whether the quote transaction contains any replacement instructions. If the quote transaction does not contain any replacement instructions, the determination module 504 may provide the quote transaction and the fulfillment transaction to the execution module 508 for execution. On the other hand, if the bid transaction contains 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.

In some embodiments, the execution module 508 may submit the execution of the quote transaction and the fulfillment transaction on the blockchain if both the quote transaction and the fulfillment transaction were successfully executed. On the other hand, if at least one of the bid transaction and the fulfillment transaction is not successfully executed, the execution module 508 may recover both the bid transaction and the fulfillment transaction such that any changes made by either of the bid transaction and the fulfillment transaction may be recovered over the blockchain. In this way, atomicity may be achieved because both the offer transaction and the fulfillment transaction may succeed or fail without allowing partial processing.

Each of the above modules may be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above modules may be implemented using a processor executing instructions stored in a memory. Further, for example, each of the above described modules may 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, micro-controllers, microprocessors, or other electronic components for performing the described methods. Further, each of the above-described modules may be implemented by using a computer chip or an entity, or by using a product having a specific function, for example. In one embodiment, the apparatus 500 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a gaming console, a tablet computer, a wearable device, or any combination of these devices.

For the implementation of the functions and actions of each module in the apparatus 500, reference may be made to the corresponding steps in the above method. Details are omitted here for simplicity.

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

The 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, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, semiconductor memory device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes: 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 (e.g., a punch card or an in-groove raised structure on which instructions are recorded), and any suitable combination of the foregoing.

The computer-readable program instructions for performing the above-described methods may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language and a conventional procedural programming language. The computer-readable program instructions may execute entirely on the computing device as a stand-alone software package or partially on a first computing device and partially on a second computing device remote from the first computing device. In the latter case, the second remote computing device may be connected to the first computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

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 methods described above.

The flowcharts and diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present description. In this regard, a block in the flowchart or illustration may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing the specified function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the illustrations and/or flowchart illustration, and combinations of blocks in the illustrations and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features of the specification, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the specification that are, for brevity, 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 the specification. Certain features described in the context of various embodiments are not essential features of those embodiments unless so stated.

While the present description has been described in conjunction with specific embodiments, many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the appended claims encompass all such alternatives, modifications, and variations as falling within the claim terms.

Claims

1. A computer-implemented method for providing atomic transactions over 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 an offer 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 that the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing the replacement instructions specified in the quote transaction and executing the fulfillment transaction and the quote transaction.

2. The method of claim 1, wherein executing the replacement instructions specified in the quote transaction further comprises:

replacing a parameter specified in the offer transaction with another parameter specified in the fulfillment transaction.

3. The method of claim 1, further comprising:

determining whether the replacement instruction is set to zero; and

in response to determining that the replacement instruction is set to zero, that the quote transaction is valid, and that the fulfillment transaction satisfies the execution condition specified in the quote transaction, executing the fulfillment transaction and the quote transaction.

4. The method of claim 1, further comprising:

determining whether the transaction is an offer transaction; and

in response to determining that the transaction is an offer transaction, setting a status of the transaction as pending.

5. The method of claim 1, further comprising:

determining whether the transaction is a regular transaction; and

in response to determining that the transaction is a regular transaction, performing the transaction.

6. The method of any of the preceding claims, wherein determining whether the transaction is a fulfillment transaction further comprises:

determining whether the transaction specifies a target transaction identification; and

identifying the transaction as fulfilling the transaction in response to determining that the transaction specifies a target transaction identification.

7. The method of claim 6, wherein identifying the offer transaction corresponding to the fulfillment transaction further comprises:

obtaining the target transaction identification specified in the fulfillment transaction; and

identifying the quote transaction based on the target transaction identification.

8. The method of any of the preceding claims, wherein determining whether the quote transaction is valid further comprises:

determining whether the offered transaction is valid based on at least one of a timeout parameter specified in the offered transaction or a status flag specified in the offered transaction.

9. A method according to any preceding claim, wherein the execution conditions specified in the quote transaction specify a smart contract and a method defined in the smart contract to be invoked by the fulfillment transaction.

10. The method of any preceding claim, wherein the execution conditions specified in the offer transaction specify a target value and how the target value is compared to parameters contained in the fulfillment transaction.

11. The method of any preceding claim, further comprising:

determining whether the fulfillment transaction and the offer transaction were successfully executed; and

in response to determining that both the fulfillment transaction and the offer transaction were successfully executed, submitting execution of both the fulfillment transaction and the offer transaction on the blockchain.

12. The method of claim 11, further comprising:

in response to determining that at least one of the fulfillment transaction and the offer transaction was not successfully executed, resuming both the fulfillment transaction and the offer transaction.

13. An apparatus for providing atomic transactions over a blockchain, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-12.

14. An apparatus for providing atomic transactions over a blockchain, the apparatus comprising a plurality of modules for performing the method of any one of claims 1 to 12.

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