Systems, methods and non-transitory computer-readable storage mediums for atomic cross-blockchain transactions

Abstract

A system for performing an atomic cross-blockchain transaction includes at least one memory configured to store instructions and at least one processor configured to execute the instructions to cause the system to define (S402) a transaction involving a first blockchain and at least one second blockchain and to execute (S404) the transaction. The transaction includes one or more operations on each of the first blockchain and the at least one second blockchain. The at least one operation of the one or more operations of the transaction is executed on the at least one second blockchain via a cross-chain bridge.

Description

SYSTEMS, METHODS AND NON-TRANSITORY COMPUTER- READABLE STORAGE MEDIUMS FOR ATOMIC CROSS-BLOCKCHAIN TRANSACTIONSTECHNICAL FIELD

[0001] One or more example embodiments relate to methods, systems, and / or non- transitory computer-readable storage mediums for atomic cross-blockchain transactions and inter-chain communication.BACKGROUND

[0002] A blockchain maintains a continuously growing history of unalterable ordered information. This unaltered ordered information is organized in discrete blocks. A blockchain may also include one or more smart contracts that are digital agreements coded and stored within the blockchain.

[0003] Blockchains are independent and it is necessary to enable communication and computation across chains. Cross-chain communication bridges facilitate easy, secure, and accurate interactions between distinct blockchains.SUMMARY

[0004] The scope of protection sought for various example embodiments is set out by the independent claims. The example embodiments and / or features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments.

[0005] In at least one example embodiment a system for performing an atomic crossblockchain transaction is described. The system may include at least one memory configured to store instructions and at least one processor configured to execute the instructions to cause the system to define a transaction involving a first blockchain and at least one second blockchain and to execute the transaction. The transaction may include one or more operations on each of the first blockchain and the at least one second blockchain. The at least one operation of the one or more operations of the transaction may be executed on the at least one second blockchain via a cross-chain bridge.

[0006] In at least one example embodiment, the at least one processor may be configured to execute the instructions to cause the system to execute the transactionby locking a state of a contract of each of the first blockchain and the at least one second blockchain that is involved in the transaction and checkpointing the locked state of the contract of the first blockchain and the at least one second blockchain. In at least one example embodiment, the at least one processor may be further configured to execute the instructions to cause the system to execute the transaction by performing the one or more operations on each of the first blockchain and the at least one second blockchain. In at least one example embodiment, the at least one processor may be further configured to execute the instructions to cause the system to abort the transaction in response to any of the one or more operations failing. In at least one example embodiment, the at least one processor may be further configured to execute the instructions to cause the system to abort the transaction by restoring each contract of the first blockchain and the at least one second blockchain to the locked state in response to any of the one or more operations on each of the first blockchain or the at least one second blockchain failing and unlocking the locked state of each of the first blockchain and the at least one second blockchain after the restoring. In at least one example embodiment, the at least one processor may be further configured to execute the instructions to cause the system to complete the transaction in response to all of the one or more operations succeeding. In at least one example embodiment, the at least one processor may be further configured to execute the instructions to cause the system to complete the transaction by committing each of the one or more operations to the first blockchain and the at least one second blockchain and unlocking the locked state of each of the first blockchain and the at least one second blockchain after the committing. In at least one example embodiment, the locking the state of the contract of each of the first blockchain and the at least one second blockchain may prevent a second proposer from performing operations on the locked state of the contract of each of the first blockchain and the at least one second blockchain.

[0007] In at least one example embodiment, the one or more operations may be sorted into a plurality of groups, a first group of the plurality of groups including operations that are independent of any other operations of the one or more operations and operations within each group of the plurality of groups other than the first group being mutually independent and depending only on operations of prior groups in the sorting. In at least one example embodiment, the at least one processor may be further configured to execute the instructions to cause the system to execute the transactionby executing all of the operations of the first group prior to executing the operations of a next group of the plurality of groups. In at least one example embodiment, a proposer may be configured to sort the one or more operations of the transaction into the plurality of groups and mechanisms for the proposer to sort the one or more operations of the transaction into the plurality of groups may be stored in a smart contract code of the proposer.

[0008] In at least one example embodiment, the transaction may be defined by a smart contract of the first blockchain and may be sent, via the smart contract, to a proposer of the first blockchain to execute the transaction on the first blockchain and the at least one second blockchain, the transaction being executed on the at least one second blockchain via the cross-chain bridge. In at least one example embodiment, executing the transaction via a cross-chain bridge may include sending, from the proposer of the first blockchain to a bridge between the first blockchain and a second blockchain of the at least one second blockchain, one or more functions including one or more operations for the second blockchain and sending, from the bridge between the first blockchain and the second blockchain to a proposer of the second blockchain, the one or more functions including the one or more operations for the second blockchain, an executor of the second blockchain being configured to execute the one or more functions on the second blockchain. In at least one example embodiment, one of the one or more functions may be a notify function. The notify function may provide a message from the first blockchain to the second blockchain. In at least one example embodiment, one of the one or more functions may be a notify with acknowledgement function. The notify with acknowledgement function may provide a message from the first blockchain to the second blockchain and may provide an acknowledgement of receipt of the message by the second blockchain to the first blockchain. In at least one example embodiment, one of the one or more functions may be a remote call function. The remote call function may invoke a method on the second blockchain based on instructions from the first blockchain. In at least one example embodiment, one of the one or more functions may be a status check. The status check may enable the first blockchain to check a status of the one or more functions on the second blockchain.

[0009] In at least one example embodiment, one or more second transactions may be executed at a time overlapping the executing the transaction on the first blockchain or the at least one second blockchain. In at least one example embodiment, the one ormore second transactions may be executed on a portion of the first blockchain or the at least one second blockchain independent of a portion of the first blockchain or the at least one second blockchain involved in the transaction.[OO1O] Also described herein is a method for performing an atomic blockchain transaction. The method may include defining a transaction involving a first blockchain and at least one second blockchain, the transaction including one or more operations on each of the first blockchain and the at least one other blockchain and executing the transaction, at least one operation of the one or more operations of the transaction being executed on the at least one second blockchain via a cross-chain bridge.

[0011] Also described herein is a non-transitory computer-readable storage medium storing computer- executable instruction that, when executed by the at least one processor of a system, may cause the system to perform a method for performing an atomic blockchain transaction. The method may include defining a transaction involving a first blockchain and at least one second blockchain, the transaction including one or more operations on each of the first blockchain and the at least one other blockchain and executing the transaction, at least one operation of the one or more operations of the transaction being executed on the at least one second blockchain via a cross-chain bridge.

[0012] At least one other example embodiment provides an apparatus for performing an atomic blockchain transaction. The apparatus may include mean for defining a transaction involving a first blockchain and at least one second blockchain, the transaction including one or more operations on each of the first blockchain and the at least one other blockchain and executing the transaction, at least one operation of the one or more operations of the transaction being executed on the at least one second blockchain via a cross-chain bridge.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Example embodiments will become more fully understood from the detailed description given herein below and the accompanying drawings, wherein like elements are represented by like reference numerals, which are given by way of illustration only and thus are not limiting of this disclosure.

[0014] FIG. 1 illustrates an example embodiment of a system that may implement the methods for performing blockchain transactions described herein.

[0015] FIG. 2 illustrates an example embodiment of a communication flow through a cross-chain communication bridge.

[0016] FIG. 3 illustrates a flow diagram of cross-chain communication functions according to an example embodiment.

[0017] FIG. 4 is a flow chart illustrating a method of performing an atomic blockchain transaction according to an example embodiment.

[0018] FIG. 5 is a flow chart illustrating step S404 of the method of FIG. 4 according to an example embodiment.

[0019] FIG. 6 is a flow chart illustrating step S408 of the method of FIG. 4 according to an example embodiment.

[0020] FIG. 7 is a flow chart illustrating step S410 of the method of FIG. 4 according to an example embodiment.

[0021] It should be noted that these figures are intended to illustrate the general characteristics of methods, structure and / or materials utilized in certain example embodiments and to supplement the written description provided below. These drawings are not, however, to scale and may not precisely reflect the precise structural or performance characteristics of any given embodiment, and should not be interpreted as defining or limiting the range of values or properties encompassed by example embodiments. The use of similar or identical reference numbers in the various drawings is intended to indicate the presence of a similar or identical element or feature.DETAILED DESCRIPTION

[0022] Various example embodiments will now be described more fully with reference to the accompanying drawings in which some example embodiments are shown.

[0023] Detailed illustrative embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposesof describing example embodiments. The example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

[0024] It should be understood that there is no intent to limit example embodiments to the particular forms disclosed. On the contrary, example embodiments are to cover all modifications, equivalents, and alternatives falling within the scope of this disclosure. Like numbers refer to like elements throughout the description of the figures.

[0025] While one or more example embodiments may be described from the perspective of a function or system element, it should be understood that one or more example embodiments discussed herein may be performed by one or more processors (or processing circuitry) at the applicable device, apparatus, element, or system. For example, according to one or more example embodiments, at least one memory may store instructions that, when executed by one or more processors, cause the system, or the like, to perform the operations discussed herein.

[0026] As discussed herein, the term "mechanism," in addition to its plain and ordinary meaning, may refer to methods, apparatuses and / or non-transitory computer readable storage mediums where applicable.

[0027] As discussed herein, the terminology “one or more” and “at least one” may be used interchangeably.

[0028] It will be appreciated that a number of example embodiments may be used in combination.

[0029] FIG. 1 illustrates an example embodiment of a system 100. The system 100 includes: a processor 110, a memory 120 connected to the processor 110, and various communication interfaces 130 connected to the processor 1 10. The various communication interfaces 130 may constitute a transceiver for transmitting / receiving data from / to other system elements. The system 100 may implement the systems and methods described herein in FIGs. 2-7.

[0030] As will be appreciated, depending on the implementation of the system 100, the system 100 may include many more components than those shown in FIG. 1. However, it is not necessary that all of these generally conventional components be shown in order to disclose the illustrative example embodiment. For example purposes, the example embodiment shown in FIG. 1 will be discussed with regard to the processor 110. However, it should be understood that the system 100 shown in FIG. 1 mayinclude one or more processors or other processing circuitry, such as one or more Application Specific Integrated Circuits (ASICs).

[0031] The memory 120 may be a computer readable storage medium that generally includes a random access memory (RAM), read only memory (ROM), and / or a permanent mass storage device, such as a disk drive. The memory 120 may also store an operating system and any other routines / modules / applications for providing the functionalities of the system 100 to be executed by the processor 110. These software components may also be loaded from a separate computer readable storage medium into the memory 120 using a drive mechanism (not shown). Such separate computer readable storage medium may include a disc, tape, DVD / CD-ROM drive, memory card, or other like computer readable storage medium (not shown). In some example embodiments, software components may be loaded into the memoiy 120 via one of the various communication interfaces 130, rather than via a computer readable storage medium.

[0032] The processor 110 or other processing circuitry may be configured to carry out instructions of a computer program by performing the arithmetical, logical, and input / output operations of the system. Instructions may be provided to the processor 110 by the memoiy 120.

[0033] The various communication interfaces 130 may be wired and may include components that interface the processor 110 with the other input / output components. As will be understood, the various communication interfaces 130 and programs stored in the memory 120 to set forth the special purpose functionalities of the system 100 will vary depending on the implementation of the network node.

[0034] The various communication interfaces 130 may also include one or more user input devices (e.g., a keyboard, a keypad, a mouse, or the like) and user output devices (e.g., a display, a speaker, or the like).

[0035] FIG. 2 illustrates an example embodiment of a communication flow 200 through a cross-chain communication bridge according to the related art. A cross-chain communication bridge may also be referred to herein as a cross-chain bridge. A crosschain communication bridge facilitates communication between a sender chain and a receiver chain. A secure transfer property may be facilitated by the cross-chain communication bridge. The secure transfer property requires that a receiver chain ensure that an event has been committed on a sender chain and cannot be rolled back.This secure transfer property ensures that actions are performed and no unjust benefits are received by actions not being fulfilled on one blockchain when there is communication between more than one blockchain.

[0036] Communication may be facilitated by a cross-chain communication bridge when a transaction must occur on one chain prior to a second transaction occurring on a second chain. For example, as shown in the communication flow 200, a user 202 may want to perform a transaction txr204 on a blockchain Cr206. In at least one example embodiment, in order to perform the transaction txr204, a transaction txs208 must be initiated on blockchain Cs210 first. A cross-chain communication bridge 212 is used to ensure the secure transfer property between the blockchain Cr206 and the blockchain Cs210. In at least one example embodiment, each blockchain may have an associated smart contract. For example, the blockchain Cr206 may have a smart contract SCr214 and the blockchain Cs210 may have a smart contract SCs216. A smart contract is a digital agreement coded and stored within the blockchain. A smart contract may be referred to herein as a contract.

[0037] Still referring to FIG. 2, the communication flow 200 may start when the user 202 initiates a transaction. Initiating the transaction may initiate the transaction txs208 in the smart contract SCs216. The transaction txs208 may then undergo a consensus protocol which may commit the transaction txs208 on the blockchain Cs210. Once the transaction txs208 is committed to the blockchain Cs210, the cross-chain communication bridge 212 may receive an indication of the transaction txK208 from the blockchain Cs210 and may send the indication to the blockchain Cr206. The crosschain communication bridge 212 may also validate the transaction txs208. In at least one example embodiment, the transaction txs208 may be validated by examining an associated verified block-header of the transaction txs208. Once the transaction txs208 is verified, details of the transaction txs208 may be available to the blockchain C, 206. This may allow the smart contract SCr214 to receive details of the transaction txs208 which may prompt the smart contract SCr214 to initiate the transaction txr204. After the transaction txr204 is initiated and completed, the transaction txr204 may be committed to the blockchain C, 206.

[0038] The indication may be communicated from the blockchain Cs210 to the blockchain Cr206 by one or more relayers in at least one example embodiment. Relayers may facilitate communication between one or more blockchains via smart contracts ofthe one or more blockchains.

[0039] As known in the art, there are different types of cross-chain communication bridges which are not standardized and which have different levels of trust when used for communication between blockchains. One or more example embodiments provide a relatively high-level interface that one or more blockchains may utilize to communicate over a cross-chain communication bridge.

[0040] FIG. 3 illustrates a protocol 300 for communication between a first blockchain C 302 and a second blockchain D 304, according to an example embodiment. The first blockchain C 302 includes a first contract c 306 and a first adapter p 308. The second blockchain D 304 includes a second contract d 310 and a second adapter q 312. The first adapter p 308 and the second adapter q 312 may be configured to interact with a first cross-chain bridge 314 between the first blockchain C 302 and the second blockchain D 304 and a second cross-chain bridge 316 between the first blockchain C 302 and the second blockchain D 304. The protocol 300 utilizes a high-level interface which enables one or more blockchains to communicate over a cross-chain communication bridge. This high-level interface is independent of the particular blockchains and can be ported from one cross-chain communication bridge to a second cross-chain bridge.

[0041] The high-level interface includes three communication functions. A first communication function is a notify function, a second communication function is a notify with acknowledgement function, and a third communication function is a remote call function. The notify function may be used by a first contract of a first blockchain to send a message to a second contract of a second blockchain. The notify with acknowledgement function may be used by a first contract of a first blockchain to send a message to a second contract of a second blockchain and to receive an acknowledgement that the message was successfully delivered to the second contract of the second blockchain. The remote call function may be used by a first contract of a first blockchain to invoke a method of a second contract of a second blockchain and to receive an acknowledgement that the method was performed successfully with values produced by the method. The high-level interface allows functionalities to be implemented in an asynchronous manner such that the first contract of the first blockchain may continue execution without having to wait for completion of a communication process with the second blockchain. This asynchronous applicationmay allow remote operations to be performed on multiple blockchains at once.

[0042] The communication functions may be implemented by smart contracts on blockchains involved in the communication. In at least one example embodiment, the smart contracts used to implement the communication functions may be auxiliary adapter smart contracts. The auxiliary adapter smart contracts may be referred to as adapters herein. For example, if the communication function is between a first blockchain and a second blockchain, a first adapter of the first blockchain may be an intermediary between the first blockchain and a cross-chain communication bridge and a second adapter of the second blockchain may be an intermediary between the second blockchain and the cross-chain communication bridge.

[0043] The adapters may provide an abstraction layer which may insulate a source and receiver contract from low-level details of a cross-chain communication bridge interface. The adapters may also ensure that notifications are delivered and methods are carried out on a destination contract. The adapters may also be configured to track progress of a communication function.

[0044] Each of the communication functions will be described below with reference to a communication between a first blockchain C and a second blockchain D. It should be understood that the communication functions may be performed between additional or different blockchains. The first blockchain C includes a first contract c and a first adapter p and the second blockchain D includes a second contract d and a second adapter q.

[0045] In a notify function, the first contract c of the first blockchain C invokes a notify function notify (x,d) where x is data to be notified to the second contract d on the second blockchain D. Then, the first adapter p invokes send(m = (notify, c, x, d), q) on a cross-chain bridge between the first blockchain C and the second blockchain D. The cross-chain bridge then communicates the message m to the second adapter q via a receive function of the second adapter q. The second adapter q then parses the message m as (notify, c, x, d) and notifies the second contract d by invoking a notification method with parameters of the first contract c, the first blockchain C, and the data x. After the second contract is notified, the notify function is complete and the second contract d has received a message from the first contract c via a cross-chain bridge.

[0046] Still referring to FIG. 3, in the notify with acknowledgement function, anotify, in a first step, the first contract c 306 of the first blockchain C 302 invokes a notify withacknowledgement function anotify(x, d) where x is data to be notified to the second contract d 310 on the second blockchain D 304. The data to be notified may be a payload in at least one example embodiment. For example, a calculation may be performed on a first blockchain and results of that calculation may need to be communicated to a second blockchain. Thus, the data x may be the result of the calculation that was performed on the first blockchain. As another example, in a cryptocurrency exchange between a first cryptocurrency and a second cryptocurrency, an amount of a first cryptocurrency of a first blockchain to be exchanged for a second cryptocurrency of a second blockchain may be the data to be communicated.

[0047] In a second step, the first adapter p assigns a fresh identifier s and a future state identifier f to the notify with acknowledgement function and returns the future state identifier f to the first contract c 306. The fresh identifier s is a positive number representing an index of a stable block of the first blockchain C 302. The future state identifier f is assigned a state of “pending” when it is assigned. The first contract c 306 may use the future state identifier f to check a status of the notify with acknowledgement function at any later point. In order to use the future state identifier f the first contract c 306 may use r := query(f). In at least one example embodiment, the first adapter p 306 may be configured to notify the first contract c 306 when a state of the future state identifier / changes from “pending” to “delivered.”

[0048] In a third step, the first adapter p 308 invokes send(m = (anotify, c, x, s, d), q) on the cross-chain bridge 314 between the first blockchain C 302 and the second blockchain D 304.

[0049] In a fourth step, the cross-chain bridge 314 communicates the message m to the second adapter q 312 via a receive function recv(m) of the second adapter q 312.

[0050] In a fifth step, the second adapter q 312 parses the message m as (anotify, c, x, s, d) and notifies the second contract d 310 by invoking a notification method d.notification(c, C, x) with parameters of the first contract c 306, the first blockchain C 3-2, and the data x.

[0051] In a sixth step, the second adapter q 312 prepares a return message m’ = (ack, s). The return message is sent, by the second adapter q 312, via the cross-chain bridge 316. The return message is sent by a send function send(m’, p).

[0052] In a seventh step, the cross-chain bridge 316 communicates the message m’ to the first adapter p 308 through a receive function of the first adapter p 308.

[0053] In an eighth step, the first adapter p 308 parses the message m’ as (ack, s) and updates the state of the future state identifier to “delivered.”

[0054] The remote call function, rcall, begins with a first step where the first contract c 306 of the first blockchain C 302 invokes a remote call function rcall(a, x, d) where a identifies a method on the second contract d 310 on the second blockchain D 304 that is to be executed and where x represents parameters to a.

[0055] In a second step, the first adapter p assigns a fresh identifier s and a future state identifier f to the remote call function and returns the future state identifier f to the first contract c 306. The fresh identifier s is a positive number representing an index of a stable block of the first blockchain C 302. The future state identifier is assigned a state of “pending” when it is assigned. The first contract c 306 may use the future state identifier / to check a status of the remote call function at any later point. In order to use the future state identifier / the first contract c 306 may use r := queryff). In at least one example embodiment, the first adapter p 306 may be configured to notify the first contract c 306 when a state of the future state identifier / changes from “pending” to “completed.”

[0056] In a third step, the first adapter p 308 invokes send(m = (rcall, c, a, x, s, d), q) on the cross-chain bridge 314 between the first blockchain C 302 and the second blockchain D 304.

[0057] In a fourth step, the cross-chain bridge 314 communicates the message m to the second adapter q 312 via a receive function recv(m) of the second adapter q 312.

[0058] In a fifth step, the second adapter q 312 parses the message m as (rcall, c, a, x, s, d) and invokes the method a on the second contract d 310 with parameters x as y:=d.a(x). A result of the method a is denoted by y.

[0059] In a sixth step, the second adapter q 312 prepares a return message m’ = (ack, s, y). The return message is sent, by the second adapter q 312, via the cross-chain bridge 316. The return message is sent by a send function send(m’, p).

[0060] In a seventh step, the cross-chain bridge 316 communicates the message m’ to the first adapter p 308 through a receive function of the first adapter p 308.

[0061] In an eighth step, the first adapter p 308 parses the message m’ as (ack, s, y) and updates the state of the future state identifier / to “completed(y).”

[0062] At any point of the notify with acknowledgement function or the remote call function, the first contract c 306 may query the future state identifier / for a state of thenotify with acknowledgement function. The state of the future state identifier / will remain “pending” until the final step of the notify with acknowledgement function where the state is changed to “delivered” and until the final step of the remote call function where the state is changed to “completed(y).” In at least one example embodiment, the remote call function may be used to block any further actions of the first contract c 306 until the state of the future state identifier / is changed to “completed(y).”

[0063] The above-described functions may be executed between two blockchains as described above. Traditionally, there is no guarantee that a series of actions or functions may be guaranteed to be completed prior to other actions being taken with respect to the involved blockchains. Example embodiments described herein provide protocols that ensure a series of cross-chain transactions are all successfully completed before allowing any other transactions outside of the series of cross- chain transactions to be performed on a portion of the blockchain impacted by the series of cross-chain transactions.

[0064] FIG. 4 is a flow chart illustrating a method 400 of performing an atomic blockchain transaction according to an example embodiment. An atomic blockchain transaction may include one or more cross-chain transactions. A cross-chain transaction is a finite set of indexed actions that are related by an irreflexive partial order. The order reflects data dependency of the indexed actions. For example, an action n may rely on data produced by action m. If an action is not dependent upon another action, then that action is considered independent. An example of an atomic blockchain transaction may be a cryptocurrency exchange. If a first user and a second user agree to exchange a first amount of a first cryptocurrency on a first blockchain for a second amount of a second cryptocurrency on a second blockchain, the exchange is an atomic transaction that occurs via the method 400 as described below to ensure that the transaction happens as desired and to ensure that neither party has an unfair advantage in the transaction.

[0065] Referring to FIG. 4, the method 400 may start at S402 where a transaction is defined by a first smart contract of a first blockchain. The transaction may include one or more operations. The one or more operations may be referred to herein as one or more actions. The one or more operations may include cross-chain transactions. The one or more operations may involve at least the first blockchain and one or more additional blockchains. The one or more operations may be partitioned into one or morelayers where each layer includes only operations that are pairwise independent. Independent operations are operations that do not depend on another action occurring prior to execution. For example, if action n relies on data produced by action m, then action n is dependent on action m. Actions m is and n are independent if there is no dependency either way. When executing the transaction, as described in further detail below, each layer is executed in its entirety before moving on to a next layer of the one or more layers. The one or more operations may each involve one or more contracts of a blockchain.

[0066] After the transaction is defined, at S404 the transaction may be executed.

[0067] FIG. 5 illustrates a flow chart of the step S404 of executing a transaction according to an example embodiment.

[0068] Referring to FIG. 5, as a first step in executing the transaction, at S502 a proposer of the first blockchain may define a checkpoint of the first blockchain and may instruct a proposer of every other blockchain involved in the transaction to define a checkpoint of its associated blockchain. A checkpoint may be an image or snapshot of a state of a blockchain prior to any portion of the transaction being executed.

[0069] In at least one example embodiment, a proposer of a blockchain is a smart contract that is configured to communicate with one or more cross-chain bridges in order to execute the actions and operations described herein. More specifically, a proposer may be configured to communicate with an adapter of a blockchain which is configured to implement cross- chain communication functions as described above in FIG. 3. In at least one example embodiment the proposer may be configured to partition the one or more operations of the transaction into the one or more layers. Mechanisms for a proposer to partition the one or more operations of the transaction may be stored in a smart contract code of the proposer.

[0070] In at least one example embodiment, only a portion of each of the involved blockchains may be involved in the transaction. For example, one or more contracts of a particular blockchain may be involved in the transaction. The checkpoint that is defined may be a checkpoint of the one or more contracts of a particular blockchain that is involved in the transaction.

[0071] At S504, the proposer may lock the state of the one or more contracts of the first blockchain and may instruct a proposer of every other blockchain involved in the transaction to lock the state of the one or more contracts of its associated blockchain.In at least one example embodiment, locking and checkpointing the state of each blockchain involved in the transaction may occur simultaneously or in parallel. In at least one other example embodiment, either the locking or the checkpointing may occur first with the other operation following. Both the locking and the checkpointing occur prior to any additional steps of the execution of the transaction.

[0072] At S506, the one or more operations may be executed. As described above, the one or more operations may be grouped into layers of independent operations. For example, a first layer may include all independent operations. A second layer may include operations that are dependent on only operations of the first layer. Accordingly, once the operations of the first layer are executed, the operations of the second layer become independent operations and are then executed. This process is repeated for as many layers as there are to complete all of the operations of the transaction.

[0073] Each operation of the transaction to be executed on the first blockchain may be executed by the proposer. In at least one example embodiment, the proposer may execute each operation of the transaction on the first blockchain via an executor. The executor may be a smart contract of the first blockchain configured to execute operations on the first blockchain. Each operation of the transaction that involves only the first blockchain may be performed on the first blockchain by methods known in the art. Each operation of the transaction that involves a blockchain other than the first blockchain may be initiated by the proposer and may involve one or more of the crosschain communication bridge functions described above with respect to FIG. 3. For example, if an operation of the transaction is to be executed on a contract of a second blockchain, the remote call function may be executed by the proposer of the first blockchain to invoke an adapter of the first blockchain and an adapter of the second blockchain to communicate via a cross-chain bridge to perform the operation on the second blockchain. Similar to the first blockchain, the second blockchain may include an executor that may be a smart contract of the second blockchain configured to execute operations on the second blockchain. Thus, the proposer of the second blockchain may execute the operations to be performed on the second blockchain via the executor of the second blockchain.

[0074] Referring to FIG. 4, at S406, the proposer of the first blockchain may determine whether any operation of the one or more operations of the transaction has failed. If any of the operations is unable to be executed on one of the blockchains involved in thetransaction, the operation has failed. Additionally, if a state of a contract of a blockchain is unable to be locked, the locking fails and the transaction has therefore failed. In at least one example embodiment, a state of a contract of a blockchain may be unable to be locked if an operation or transaction on that state of the contract of the blockchain is being executed while attempting to lock the state.

[0075] If an operation has failed, the transaction is aborted at S408.

[0076] FIG. 6 illustrates a flow chart of the step S408 of aborting the transaction if any of the one or more operations of the transaction fails according to an example embodiment.

[0077] Referring to FIG. 6, at S602 each locked state of any blockchain involved in the transaction may be reverted to the checkpointed state. Thus, if any operation of the transaction is unable to be completed, no operation of the transaction will be completed and each blockchain will remain in a condition that existed prior to execution of the transaction.

[0078] At S604, after each of the locked states is reverted to the associated checkpointed state, each of the locked states is unlocked. Once each of the states is unlocked, each of the blockchains is in a state prior to the attempted execution of the contract. Thus, the first smart contract and the proposer are able to repeat the method 400 to re-attempt the transaction if it is desired for the transaction to be completed.

[0079] Returning to S406 in FIG. 4, if none of the one or more operations has failed, then the transaction is completed at S410.

[0080] FIG. 7 illustrates a flow chart of the step S410 of completing the transaction according to an example embodiment.

[0081] Referring to FIG. 7, at S702 each of the operations is committed to a respective blockchain. Thus, each of the operations is completed which completes the transaction in its entirety. Once each of the operations is committed to its respective blockchain, each of the locked states is unlocked at S704. Once each of the states is unlocked, any further transactions are able to be performed on any state of the blockchains.

[0082] The method 400 of FIG. 4 is linearizable or, alternatively, is strictly serializable which guarantees that every operation of a transaction appears to take effect instantaneously at a point between the start point of the transaction and the end point of the transaction. This property establishes atomicity with respect to other cross-chain transactions.

[0083] Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of this disclosure. As used herein, the term "and / or," includes any and all combinations of one or more of the associated listed items.

[0084] When an element is referred to as being "connected," or "coupled," to another element, it can be directly connected or coupled to the other element or intervening elements may be present. By contrast, when an element is referred to as being "directly connected," or "directly coupled," to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., "between," versus "directly between," "adjacent," versus "directly adjacent," etc.).

[0085] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the," are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes," and / or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0086] It should also be noted that in some alternative implementations, the functions / acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality / acts involved.

[0087] Specific details are provided in the following description to provide a thorough understanding of example embodiments. However, it will be understood by one of ordinary skill in the art that example embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams so as not to obscure the example embodiments in unnecessary detail. In other instances, well- known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring example embodiments.

[0088] As discussed herein, illustrative embodiments are described with reference to acts and symbolic representations of operations (e.g., in the form of flow charts, flow diagrams, data flow diagrams, structure diagrams, block diagrams, etc.) that may be implemented as program modules or functional processes include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be implemented using existing hardware at, for example, existing servers or other system elements and / or hardware. Such existing hardware may be processing or control circuitry such as, but not limited to, one or more processors, one or more Central Processing Units (CPUs), one or more controllers, one or more arithmetic logic units (ALUs), one or more digital signal processors (DSPs), one or more microcomputers, one or more field programmable gate arrays (FPGAs), one or more System-on-Chips (SoCs), one or more programmable logic units (PLUs), one or more microprocessors, one or more Application Specific Integrated Circuits (ASICs), or any other device or devices capable of responding to and executing instructions in a defined manner.

[0089] Although a flow chart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0090] As disclosed herein, the term "storage medium," "computer readable storage medium" or "non-transitory computer readable storage medium” may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and / or other tangible machine-readable mediums for storing information. The term "computer-readable medium" may include, but is not limited to, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instruction (s) and / or data.

[0091] Furthermore, example embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or anycombination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a computer readable storage medium. When implemented in software, a processor or processors will perform the necessary tasks. For example, as mentioned above, according to one or more example embodiments, at least one memory may include or store computer program code, and the at least one memory and the computer program code may be configured to, with at least one processor, cause a network element or network device to perform the necessary tasks. Additionally, the processor, memory and example algorithms, encoded as computer program code, serve as means for providing or causing performance of operations discussed herein.

[0092] A code segment of computer program code may represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable technique including memory sharing, message passing, token passing, network transmission, etc.

[0093] The terms “including” and / or “having,” as used herein, are defined as comprising (i.e., open language). The term “coupled,” as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. Terminology derived from the word “indicating” (e.g., “indicates” and “indication”) is intended to encompass all the various techniques available for communicating or referencing the object / information being indicated. Some, but not all, examples of techniques available for communicating or referencing the object / information being indicated include the conveyance of the object / information being indicated, the conveyance of an identifier of the object / information being indicated, the conveyance of information used to generate the object / information being indicated, the conveyance of some part or portion of the object / information being indicated, the conveyance of some derivation of the object / information being indicated, and the conveyance of some symbol representing the object / information being indicated.

[0094] According to example embodiments, hardware, firmware, hardware executing software or any combination thereof may be used to implement the systems and methods described herein. Such hardware may include processing or control circuitry such as, but not limited to, one or more processors, one or more CPUs, one or more controllers, one or more ALUs, one or more DSPs, one or more microcomputers, one or more FPGAs, one or more SoCs, one or more PLUs, one or more microprocessors, one or more ASICs, or any other device or devices capable of responding to and executing instructions in a defined manner.

[0095] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments of the invention. However, the benefits, advantages, solutions to problems, and any element(s) that may cause or result in such benefits, advantages, or solutions, or cause such benefits, advantages, or solutions to become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

Claims

WHAT IS CLAIMED IS:

1. A system for performing an atomic cross-blockchain transaction, the system comprising: at least one memory configured to store instructions; and at least one processor configured to execute the instructions to cause the system to define a transaction involving a first blockchain and at least one second blockchain, the transaction including one or more operations on each of the first blockchain and the at least one second blockchain, and execute the transaction, at least one operation of the one or more operations of the transaction being executed on the at least one second blockchain via a cross-chain bridge.

2. The system of claim 1 , wherein the at least one processor is configured to execute the instructions to cause the system to execute the transaction by locking a state of a contract of each of the first blockchain and the at least one second blockchain that is involved in the transaction; and checkpointing the locked state of the contract of the first blockchain and the at least one second blockchain.

3. The system of claim 2, wherein the at least one processor is further configured to execute the instructions to cause the system to execute the transaction by performing the one or more operations on each of the first blockchain and the at least one second blockchain.

4. The system of claim 2 or claim 3, wherein the at least one processor is configured to execute the instructions to cause the system to abort the transaction in response to any of the one or more operations failing.

5. The system of claim 4, wherein the at least one processor is configured to execute the instructions to cause the system to abort the transaction byrestoring each contract of the first blockchain and the at least one second blockchain to the locked state in response to any of the one or more operations on each of the first blockchain or the at least one second blockchain failing; and unlocking the locked state of each of the first blockchain and the at least one second blockchain after the restoring.

6. The system of any one of claims 2-5, wherein the at least one processor is configured to execute the instructions to cause the system to complete the transaction in response to all of the one or more operations succeeding.

7. The system of claim 6, wherein the at least one processor is configured to execute the instructions to cause the system to complete the transaction by committing each of the one or more operations to the first blockchain and the at least one second blockchain; and unlocking the locked state of each of the first blockchain and the at least one second blockchain after the committing.

8. The system of any one of claims 2-7, wherein the locking the state of the contract of each of the first blockchain and the at least one second blockchain prevents a second proposer from performing operations on the locked state of the contract of each of the first blockchain and the at least one second blockchain.

9. The system of any one of the preceding claims, wherein the one or more operations are sorted into a plurality of groups, a first group of the plurality of groups including operations that are independent of any other operations of the one or more operations and operations within each group of the plurality of groups other than the first group being mutually independent and depending only on operations of prior groups in the sorting.

10. The system of claim 9, wherein the at least one processor is configured to execute the instructions to cause the system to execute the transaction byexecuting all of the operations of the first group prior to executing the operations of a next group of the plurality of groups.

11. The system of claim 9 or claim 10, wherein a proposer is configured to sort the one or more operations of the transaction into the plurality of groups and mechanisms for the proposer to sort the one or more operations of the transaction into the plurality of groups are stored in a smart contract code of the proposer.

12. The system of any one of the preceding claims, wherein the transaction is defined by a smart contract of the first blockchain and is sent, via the smart contract, to a proposer of the first blockchain to execute the transaction on the first blockchain and the at least one second blockchain, the transaction being executed on the at least one second blockchain via the cross-chain bridge.

13. The system of claim 12, wherein the executing the transaction via the crosschain bridge comprises: sending, from the proposer of the first blockchain to an adapter of the first blockchain, one or more functions including one or more operations for a second blockchain of the at least one the second blockchain; sending the one or more functions from the adapter of the first blockchain to a bridge between the first blockchain and the second blockchain; sending the one or more functions from the bridge between the first blockchain and the second blockchain to an adapter of the second blockchain; and sending, from the adapter of the second blockchain to a proposer of the second blockchain, the one or more functions including the one or more operations for the second blockchain, an executor of the second blockchain being configured to execute the one or more functions on the second blockchain.

14. The system of claim 13, wherein one of the one or more functions is a notify function, the notify function providing a message from the first blockchain to the second blockchain.

15. The system of claim 13 or claim 14, wherein one of the one or more functions is a notify with acknowledgement function, the notify with acknowledgement function providing a message from the first blockchain to the second blockchain and providing an acknowledgement of receipt of the message by the second blockchain to the first blockchain.

16. The system of any one of claims 13- 15, wherein one of the one or more functions is a remote call function, the remote call function invoking a method on the second blockchain based on instructions from the first blockchain.

17. The system of any one of claims 13- 16, wherein one of the one or more functions is a status check, the status check enabling the first blockchain to check a status of the one or more functions on the second blockchain.

18. The system of any one of preceding claims, wherein one or more second transactions are executed at a time overlapping the executing the transaction on the first blockchain or the at least one second blockchain.

19. The system of claim 18, wherein the one or more second transactions are executed on a portion of the first blockchain or the at least one second blockchain independent of a portion of the first blockchain or the at least one second blockchain involved in the transaction.

20. A method for performing an atomic blockchain transaction, the method comprising: defining a transaction involving a first blockchain and at least one second blockchain, the transaction including one or more operations on each of the first blockchain and the at least one second blockchain; and executing the transaction, at least one operation of the one or more operations of the transaction being executed on the at least one second blockchain via a crosschain bridge.

Images