Atomicity and Abstraction for Cross-Blockchain Interactions

A blockchain system is a distributed ledger that maintains a continuously growing history of unalterable ordered information. The information is organized in a chain of discrete blocks. The potential benefits of the blockchain are more than just economic-they extend into political, humanitarian and scientific domains (Swan, 2015).

Smart contracts are digital agreements coded and stored within the blockchain (Zheng et al., 2020). Unlike conventional paper-based contracts, smart contracts encode terms and conditions through software. In this inherently decentralized, trustless setting, the immutability of contract code and openness of contract execution (both ensured by the underlying blockchain) develop trust between the parties to a contract. The blockchain mechanism ensures that every smart contract transaction is atomic: i.e., it either completes successfully or (on failure) leaves the blockchain state unchanged.

A wide range of blockchains with diverse use-cases and diverse consensus protocols have been deployed and are in active use. For example, Ethereum supports smart contracts and uses Proof of Stake (PoS) (Nguyen et al., 2019) while Bitcoin is built as a cryptocurrency on Proof of Work (PoW) (Gervais et al., 2016). Looking forward, this heterogeneity will only increase and will lead to a ’multi-chain universe’—a digital environment where data is spread across blockchains and applications combine operations that execute on multiple chains.

To facilitate easy, secure, and accurate interactions between distinct blockchains, several Cross-Chain Communication (CCC) bridges have been established. A fundamental feature of these bridges is the Secure Transfer property, which is described in many works such as (Xie et al., 2022) and formalized later in §III. This property requires that when a receiver chain receives a notification of an event on the sender chain, this event has actually been committed on the sender chain and cannot be rolled back. Without the Secure Transfer property, the sender chain may create a fake message that is not committed on the sender chain. As a result, a user on the receiver chain would lose some assets without a proper counter transaction on the sender chain, thereby creating a fraudulent transaction.

Figure 1 demonstrates the general process for transmitting messages via a CCC bridge.

Smart contracts $SC_{s}$ and $SC_{r}$ are deployed on blockchains $C_{s}$ (sender) and $C_{r}$ (receiver), respectively. Note that a single bridge is usually designed for one direction. For a user to activate a transaction $tx_{r}$ on blockchain $C_{r}$, they must first initiate transaction $tx_{s}$ on blockchain $C_{s}$. (The remote execution may be motivated by superior features on $C_{r}$, such as lower fees, prompting the user to transfer assets from $C_{s}$ to $C_{r}$.) The secure transfer property is guaranteed by the middle CCC bridge (symbolized by the shaded area in Figure 1). The bridge relays the details of $tx_{s}$ and confirms its existence on chain $C_{s}$ before transmitting it to chain $C_{r}$. The above communication flow can be summarized as: 1) User initiates $tx_{s}$ in smart contract $SC_{s}$. 2) $tx_{s}$ undergoes the consensus protocol of chain $C_{s}$ and is subsequently committed. 3) The CCC bridge picks up the message including $tx_{s}$ and sends it to the receiver chain $C_{r}$, facilitated by one or multiple relayers. 4) The CCC bridge validates $tx_{s}$ by examining the associated verified block-header. 5) $tx_{s}$ is confirmed, and its details are available on Chain $C_{r}$. 6) Consequently, smart contract $SC_{r}$ issues $tx_{r}$ accordingly which is then committed on $C_{r}$.

Based on their trust assumptions and security models to verify the transaction from the sender chain we can categorize the CCC bridges in the following two categories:

• •

  Trusted: The “trusted” CCC bridges (Zarick et al., 2021), introduce a third-party trust system, such as an Oracle network or a notary committee, to authenticate and verify the occurrence of specific events on an alternative chain.

• •

  Trustless: The “trustless” CCC bridges, e.g. Cosmos inter-blockchain communication protocol (IBC) (Goes, 2020) and zkbridge (Xie et al., 2022), on the other hand, employ a ‘light client’ approach, where one chain maintains an up-to-date version of the other chain’s block header. For instance, a light client of the sender chain would be implemented within the receiver chain. This method allows the receiver chain to acquire and update block header information from the sender chain, thereby verifying the occurrence of a specific event on the sender chain through a cryptographic (e.g., Merkle proof) method.

However, it should be noted that these CCC bridges primarily focus on the trust layer of the general communication between two blockchains, aiming to maintain the secure transfer property. In contrast, certain application-specific blockchain interoperability protocols, such as the cross-chain atomic swap enabled by Hash Time-locked Contract (HTLC) (Herlihy, 2018), concentrate solely on a distinct communication domain between the two chains.

Given the vast variety of CCC bridges, there have been efforts in prior research to combine or standardize all these bridges such as Multi-Message Aggregation (MMA) (202, [n. d.]). While these approaches tend to blur the boundaries among different bridges, they work at the same low-level as cross-chain bridges. Their main goal is to augment security based on existing bridges, rather than provide a higher-level abstraction of these low-level bridges to enhance better smart contract programmability and portability. The increasing complexity of emerging multi-chain applications, typically constructed on top of these low-level bridges, underscores the challenges in design and verification for correctness. A more abstract representation for these low-level bridges is indeed essential.

The fundamental property of the consensus protocols in a blockchain is that a block is either committed or discarded. This property can be leveraged to achieve atomicity across a set of operations. If we embed all the operations under consideration in a same block then all of them will be committed or all of them will be rejected; i.e. the set of operations will be executed atomically.

Informally speaking, a cross-chain transaction is a sequence of operations where the operations may target different chains. For instance, a cross-chain transaction $T$ may be expressed as the sequence $[c_{0};d_{0};c_{1}]$, where $c_{0},c_{1}$ are operations on a chain $C$ and $d_{0}$ is an operation on a different chain $D$. Atomic execution of such a transaction is not guaranteed. That is because each blockchain operates independently of the others, without a common consensus mechanism. Thus, the sequence of operations in transaction $T$ has no built-in protection against interference from other operations on those chains, which may be initiated independently at any time by other parties. (For example, an operation $c_{2}$ may occur on chain $C$ between the occurrences of $c_{0}$ and $c_{1}$, changing the state of blockchain $C$ in a way that cannot be viewed as the result of an atomic execution – i.e., as the result of $(c_{0};d_{0};c_{1});c_{2}$ or $c_{2};(c_{0};d_{0};c_{1})$.) It is for this fundamental reason that achieving cross-chain atomicity requires a special protocol.

Existing protocols for atomic cross-chain transactions are limited in scope: e.g., pairwise token transfers through gateways (Augusto et al., 2023) or pairwise asset exchanges through atomic swap protocols (Ding et al., 2022; Zakhary et al., [n. d.]). HTLC (Herlihy, 2018) is the most popular solution for ensuring atomicity of a pairwise cryptocurrency swap. It has been extended to multiple chains (Xue et al., 2023), but remains specialized to currency swaps, an important but narrowly defined transaction. As multi-chain applications evolve to handle data spread across several chains, there is a need for an atomicity protocol that handles general transactions that contain arbitrary smart-contract operations defined on multiple chains. That is the fundamental question addressed in this paper.

Some systems use a top-level chain to periodically checkpoint the state of other chains, or to record transactions occurring on other chains in a conveniently accessible location. This is the case, for instance, for Trustboost (Wang et al., 2022), Hyperservice (Liu et al., 2019), and Polkadot (Wood, 2016). This does not, however, suffice to guard against interference, and thus does not provide any guarantee of atomicity.

This is a notification that also provides an acknowledgement of receipt. In order to generate the acknowledgement, we need a bridge in the reverse direction, from $D$ to $C$. Acknowledgements are provided asynchronously; thus, it is necessary to mark messages with sequence numbers to distinguish those that have been acknowledged. The protocol is illustrated in Figure 2 along with the Remote Call Protocol and consists of the following sequence of steps.

1. (1)

   Contract $c$ invokes $\mathsf{anotify}(x,d)$ on the adapter contract $p$ on chain $C$, where $x$ is the data to be notified to contract $d$ on chain $D$.

2. (2)

   Adapter $p$ assigns a fresh identifier $s$ and a “future” $f$ (with state Pending) to this invocation, and returns $f$ to contract $c$. Contract $c$ can check the status of the transmission at any later point by querying the future $f$ through $r:=query(f)$. (The adapter can also provide a facility for contract $c$ to be notified when the future changes state from Pending to Delivered. We do not illustrate this in the figure.)

3. (3)

   Adapter $p$ invokes $\mathsf{send}(m=(\mathsf{anotify},c,x,s,d),q)$ on the bridge from $C$ to $D$, where $q$ is its corresponding adapter contract on chain $D$.

4. (4)

   The bridge communicates the message $m$ to contract $q$ through its $\mathsf{recv}$ method.

5. (5)

   Adapter $q$ parses $m$ as $(\mathsf{anotify},c,x,s,d)$ and notifies contract $d$ by invoking its $\mathsf{notification}$ method with parameters $c$, $C$ and $x$.

6. (6)

   Adapter $q$ then prepares a message $m^{\prime}=(\mathsf{ack},s)$ and sends it to the bridge for the reverse direction from $D$ to $C$ through $\mathsf{send}(m^{\prime},p)$.

7. (7)

   The bridge communicates the message $m^{\prime}$ to contract $p$ through its $\mathsf{recv}$ method.

8. (8)

   Adapter $p$ parses $m^{\prime}$ as $(\mathsf{ack},s)$ and updates the state of the future $f$ associated with $s$ to Delivered.

At any point, contract $c$ may query the future $f$ for the state of the notification. That will be Pending until the final step, when the state changes to Delivered and is then unchanged.

The notify protocol is a simplification and shortening of this protocol. It consists of steps 1-5 of this protocol, i.e., without the additional acknowledgement message transfer. There is also no need to have a future $f$ and fresh identifier $s$ as those are used exclusively for the acknowledgement step.

This is an asynchronous protocol, in that multiple unacknowledged notifications may be issued by the contract $c$. The identifier $s$ is used to track the state of each notification, which is reflected in the future $f$. The smart contract program $c$ may inspect and make decisions based on whether an issued notification has been acknowledged; for instance, blocking any other transactions until a specific notification is acknowledged. As a special case, it is easy to implement synchronous versions of notify and notify-with-acknowledgement.

A remote call invokes a particular method on the target contract. The protocol extends the one for notify-with-acknowledgement by carrying additional information in the messages that identifies the method and its return value. The protocol is illustrated in Figure 2 and consists of the following sequence of steps.

1. (1)

   Contract $c$ invokes $\mathsf{rcall}(a,x,d)$ on the adapter contract $p$ on chain $C$, where $a$ identifies the method on contract $d$ on chain $D$ that is to be executed and $x$ represents the parameters to $a$.

2. (2)

   Adapter $p$ assigns a fresh identifier $s$ and a “future” $f$ (with state $\mathsf{Pending}$) to this invocation, and returns $f$ to contract $c$. Contract $c$ can check the status of the remote call at any later point by querying the future $f$ through $r:=query(f)$. (The adapter can also provide a facility for contract $c$ to be notified when the future changes state from Pending to Completed. We do not illustrate this in the figure.)

3. (3)

   Adapter $p$ invokes $\mathsf{send}(m=(\mathsf{rcall},a,x,s,d),q)$ on the bridge from $C$ to $D$, where $q$ is its corresponding adapter contract on chain $D$.

4. (4)

   The bridge communicates the message $m$ to contract $q$ through its $\mathsf{recv}$ method.

5. (5)

   Adapter $q$ parses $m$ as $(\mathsf{rcall},a,x,s,d)$ and invokes method $a$ on contract $d$ with parameters $x$. Let $y$ represent the result of this invocation.

6. (6)

   Adapter $q$ then prepares a message $m^{\prime}=(\mathsf{ack},s,y)$ and sends it to the bridge for the reverse direction from $D$ to $C$ through $\mathsf{send}(m^{\prime},p)$.

7. (7)

   The bridge communicates the message $m^{\prime}$ to contract $p$ through its $\mathsf{recv}$ method.

8. (8)

   Adapter $p$ parses $m^{\prime}$ as $(\mathsf{ack},s,y)$ and updates the state of the future $f$ associated with $s$ to $\mathsf{Completed}(y)$.

At any point before the final step, contract $c$ may query the future $f$ for the state of the remote call. That will be $\mathsf{Pending}$ until the final step is complete, when the state changes to $\mathsf{Completed}(y)$ and is then unchanged.

This remote call mechanism is also asynchronous, allowing multiple remote calls to be “in flight” concurrently, possibly to contracts on different chains. As before, the fresh identifier $s$ is used to track the status of the remote call, which is reflected in the future $f$. The future/query mechanism can be used to turn the remote call into a synchronous one, by blocking any further actions of contract $c$ until the query returns the $\mathsf{Completed}(y)$ result.

Following the same line of reasoning as the proof of Theorem 2, we obtain this theorem.

For the purposes of defining the atomicity protocol, we may view a blockchain $B$ as an abstract state machine $(V,\Sigma,T)$, where:

• •

  $V$ is a set of typed state variables. This induces a state space $S$ which is the set of assignments of values to variables in $V$. (Notationally, we can say $S=V\rightarrow D$, where $D$ is the type domain. In the formal presentation, all variables have a single domain for simplicity.) The connection to a real blockchain is that $V$ represents the state variables for all contracts on the blockchain. Over time, smart contracts are added to the chain, thus extending $V$ with fresh state variables, but we can ignore this aspect for the formal presentation.

• •

  $\Sigma$ is a set of action names. In a real blockchain, each action represents a contract method along with values for its parameters.

• •

  $T:S\times\Sigma\to S\times D$ is the deterministic transition function of the chain, which transforms the current state, say $s$, to a successor state $t$ on action $a$ ($a\in$ $\Sigma$) and produces a result value. In an actual blockchain, this represents the execution of a smart contract method, which must be deterministic.

• •

  We associate a scope with each action through a function $\nu:\Sigma\to 2^{V}$. The scope $\nu(a)$ of action $a$ is the subset of variables that is affected (read or written to) on a transition labeled by $a$.

• •

  An indexed action is a pair $(B,a)$ where $B$ is a blockchain and $a$ is an action in $B$.

A cross-chain transaction is specified by a finite set of indexed actions that are related by an irreflexive partial order denoted $\prec$. This order reflects data dependencies: for every action $n$, the data that action $n$ relies upon must be produced by actions $m$ such that $m\prec n$. Actions that are not related by $\prec$ are called independent.

A transaction can be partitioned (through a topological sort) into a sequence of layers such that each layer consists of a set of independent actions, and for actions $m,n$ such that $m\prec n$, the layer containing $m$ occurs prior to the layer containing $n$ in the sequence. Formally, we have a set of layers, $\{L_{i}\}$, to represent a cross-chain transaction and

where $L_{i}$ and $L_{j}$ are the $i$’th and $j$’th layer of the transaction, respectively while $m$ and $n$ are indexed actions.

The ideal (sequential and interference-free) execution proceeds as follows, shown in Figure 3. It begins by forming a checkpoint consisting of the current state of all blockchains participating in the transaction, represented as $cp$. At round $k$, operations on the nodes in layer $k$ ($L_{k}$) are issued in some order. (The actual order does not matter as the operations are independent.) If all operations in layer $k$ succeed, the results are saved and the next round (if any) is started. If some operation of layer $k$ fails, the execution is canceled and every blockchain is restored to its checkpointed state $cp$.

Multiple transactions may execute concurrently and may be interleaved with other blockchain actions issued independently of the transactions by other parties. The goal of the atomicity protocol is to ensure that in this concurrent, interference-prone setting, each transaction follows its ideal semantics as shown in Figure 3.

This is a two-phase protocol. A transaction is coordinated by a Proposer which is a smart contract on one of the blockchains. At a high level, the protocol follows the well known two-phase commit template for distributed database transactions. In the first phase, the proposer obtains agreement from all blockchains to “freeze” the portion of their state that is relevant to the operations in the transaction. In the second phase, the proposer executes operations from the transaction layer-by-layer, canceling the transaction if any individual operation fails.

We prove that protocol executions are strictly serializable. In terms of the closely related concept of linearizability, this guarantees that every transaction appears to take effect instantaneously, which provides atomicity with respect to other cross-chain transactions that follow this protocol and any contract operations that may be invoked independently.

Two features sharply distinguish this protocol from two-phase commit protocols on databases. First, as the proposer and all operations operate on blockchains, we may assume that the likelihood of a machine failure is negligible, because of the protections provided by the replication that is built into blockchains. This is in sharp distinction to two-phase commit protocols on distributed databases, which are complex largely because they must handle various machine failure scenarios involving the Proposer and the databases. As a result, our atomicity protocol is significantly simpler than database commit protocols. The second distinction arises from the inherently trustless setting. Thus, any atomic protocol must contend with the potential for malicious behavior. This aspect is absent from traditional database protocols. It has two consequences. First, if the Proposer issues an operation on a remote blockchain, there is no guarantee that this operation will actually be executed. Our protocol therefore relies crucially on cross-chain bridges with the Secure Transfer property and on the abstract interface defined in the prior section, which ensures that operations will eventually be performed and cannot be corrupted. Second, our protocol relies on locking smart contract state. As the locking operations must be public, it is necessary to build in access controls to ensure that a malicious attacker cannot lock smart contracts to create a denial-of-service situation.

To summarize, in the database domain, two-phase commit protocols focus on two types of failure: machine failures (i.e., machine crashes) and semantic failures (i.e., a failure within an operation, such as a divide-by-zero error). In our blockchain domain, machine failures may be ignored but, in their place, we must consider failures of trust, which arises from the potential for malicious attacks that aim to disrupt correctness or deny service.

We assume that two functionalities are provided by each blockchain that participates in transactions.

First, it must be possible to atomically checkpoint and lock a portion of the state of a single blockchain. We assume an abstract function $\mathsf{lock}(W,p)$ which atomically (1) saves the current values of the state variables $W$ to a copy $\overline{W}$ of those variables and (2) blocks access to any action that modifies that state except when the action originates from the Proposer, denoted $p$.

Second, it must be possible to atomically restore and unlock the locked state. We assume an abstract function $\mathsf{unlock}(W,f)$ which, when invoked by the Proposer $p$, atomically does the following: if $f$ is true (denoting a failure), the operation restores the state saved in $\overline{W}$ to $W$; and, regardless of the value of $f$, the operation then removes the block on accessing the state in $W$.

In practice, these abstract operations may be implemented as follows. The variables $W$ represent the state variables of multiple smart contracts on the blockchain. To ensure atomicity for the lock and unlock operations and to prevent the misuse of the locking functionality, we define a transaction executor contract on each blockchain. The executor receives a transaction specification from the proposer and executes the transaction on behalf of the proposer. It also acts as a conduit for remote operation execution, as explained below. Each contract implements its own $\mathsf{lock}$ and $\mathsf{unlock}$ method. In addition, the code of the contract must ensure that every regular contract method is guarded to ensure that when the state variables of the contract are locked, the method can be invoked only by the transaction executor. Restricting the transaction execution to a known executor contract (which may be formally verified to ensure correct behavior) avoids the possibility of malicious behavior that can lock the state of participating contracts, creating a denial of service attack.

Pseudo-code illustrating the assumed smart contract structure is shown in Figure 4. The syntax has its standard interpretation. The caller variable represents the address of the party invoking the method; the require operation cancels execution if the value of its Boolean argument is false in the current contract state. For simplicity, the pseudo-code assumes that the methods in this contract do not invoke methods in other contracts. (Such indirect invocations are handled by relaying the address of the original external caller to the indirectly invoked methods.)

At a high level, our protocol follows the template of a two-phase commit protocol. Such protocols were originally developed for distributed database transactions which, as explained, operate under a different model of trust and failure (Bernstein and Newcomer, 2009; Weikum and Vossen, 2001).

We show that transactions may be viewed as being atomic. This follows from showing that executions are linearizable, in that each transaction appears to take effect (matching its ideal semantics) at some point between its start and finish.

There is, however, no guarantee that every issued transaction will eventually successfully acquire all relevant locks. One can easily construct pathological schedules where two transactions that must acquire locks on the same (or overlapping) sets of variables are issued together so that one transaction always loses the race. However, it is important to note that since every operation on a blockchain incurs a cost, such scenarios cannot persist indefinitely.

Bridges such as LayerZero and IBC protocol typically host endpoint contracts within each blockchain. These endpoints facilitate communication with other blockchains. A challenge arises due to the heterogeneity of these endpoint interfaces across different bridges. To navigate this, we introduce a unified converter interface applicable to all bridges. The structure of our implementation (in Solidity) is shown in Figure 6. The interface includes functions such as notify, notify_ack, and remote_call, which are realized using the lower-level bridge functions. Once a bridge converter is defined on a blockchain, the abstraction simply requires the inclusion of that converter’s address within its contract. This integration allows the abstraction to employ a standardized communication interface, enabling the use of various bridges by invoking distinct bridge converters as needed. Though one interface function may involve several transactions in different chains, the complicated payment for multiple communication is abstracted away, making it possible for an application designer to focus on the application logic.

The implementation of atomic transactions builds on this communication layer. The structure is defined by public function calls such as addLock, addUnlock, addOp, propose, and execute. Application developers must deposit a specified amount to support payment for bridge communications that occur during the transaction execution. Notably, within the atomic execution smart contract, storage provisions are made to retain details of these multi-chain applications. Once an application is documented, it’s stored permanently, allowing for subsequent initialization without the redundancy of re-defining all requisite operations.

The sizes of the contracts that make up the implementation of our abstractions, and the deployment cost on Testnet Fantom, are shown in Table. 1. The abstraction and atomicity smart contracts only need to be deployed once on the blockchain. The implementation is flexible and supports multiple bridges. Supporting a new bridge for connection with another chain requires the creation of a converter (approximately 242 lines of code), and a function call to register the bridge with the converter.

From a programmer’s viewpoint, this abstraction layer considerably simplifies the process of constructing atomic cross-chain transactions. Only a few lines of code are needed to implement an atomic swap and a three-chain exchange, as shown in Table. 2. This code sets up the structure of the transaction (its operations and their ordering), using the interface shown in Figure 6.

We first executed a two-chain atomic swap between the Mumbai and Fantom testnets. Mumbai serves as Polygon’s testnet, mirroring the mainnet functionalities of Polygon. In this process, Fantom testnet plays the role of the proposer. For a successful transaction on the Mumbai blockchain, three operations are essential: lock, transfer, and unlock. Each operation requires a remote call from the fantom testnet and sends back an acknowledgement to indicate the status of execution, which is implemented through the remote_call in the abstraction. The atomic swap transaction, when successful, undergoes the following steps:

• •

  Step 1: Fantom proposes the transaction to Mumbai and self-locks.

• •

  Step 2: Mumbai consents, then locks, and dispatches an acknowledgment.

• •

  Step 3: Fantom initiates a locked-mode transfer while prompting Mumbai to follow suit.

• •

  Step 4: Mumbai completes the transfer and sends an acknowledgment.

• •

  Step 5: Fantom initiates the unlock process, directing Mumbai to do the same.

• •

  Step 6: Mumbai concludes the unlock phase and communicates acknowledgment.

As a result, a successful atomic transfer requires 6 messages between two blockchains.

In addition to the successful case, we experimented with two potential failure scenarios to gauge the resilience of our protocol. The first scenario is a lock conflict in Step 2, where another transaction already claims the lock. The second involves an unsuccessful transfer due to inadequate funds during Step 4. Both situations prompt a transaction termination (Abort), reverting both blockchains to their pre-transaction states. The outcomes of these tests were in line with our expectations.

We also explored a multi-chain scenario involving exchanges across three distinct chains. Imagine Alice possesses token A and aims to trade it for token C with Charlie. However, Charlie lacks an account on Chain A and only accepts token B as a valid trade for token C. Therefore, Alice transfers token A to Bob, who then gives token B to Charlie, resulting in Charlie providing token C to Alice. This scenario is visually depicted in Figure. 7. Since three different tokens are used, three different chains are involved. Such multi-chain exchanges frequently occur in supply chain management systems, as noted in  (Augusto et al., 2023), emphasizing their growing significance in the evolving blockchain landscape.

Though we have successfully deployed contracts across multiple chains and conducted localized function tests, certain multi-chain applications remain challenging due to a shortage of testnet tokens. For instance, following certain updates that ascribed real value to the Goerli token, contract deployment on Goerli became considerably costly. Consequently, for our three-chain exchange experiment, we simulated the application on a single chain, imitating two distinct chains. As cross-chain communication is exclusive between the proposer and participants and absent among participant chains, this approximation does not compromise protocol integrity.

The results of our experiments can be found in Table 3. Fantom acts as the proposer, while Mumbai serves as the participants. For each transaction, we documented the number of cross-chain messages invoked by the LayerZero bridge, as well as the number of operations performed on both chains.

Gas is essential for the execution of all these operations. When calculating gas consumption, two major components come into play: 1) Gas required for bridge functionalities, which include sending and validating messages. 2) Gas necessary for atomic operations. To delineate these different gas requirements, we designed a rudimentary cross-chain application that uses a recursive call with an empty payload. Through this, we measured the basic communication gas consumption between Fantom and Mumbai. Any additional gas was attributed to atomic operations.

Analyzing the data from Table. 3, we observe that the gas consumption for atomic operations is generally less than that for bridge communications. In all listed scenarios, atomic operations account for as little as 20 percent to a maximum of 50 percent of the total gas. This indicates that the primary gas consumption in atomic transactions predominantly arises from bridge communication, while the overhead from atomic operations remains small.

Furthermore, the main contributors to transaction latency are the bridge communication between the two chains and the time required for blockchain confirmations. This is largely due to the atomicity protocol being integrated within on-chain smart contracts. To acquire a more accurate understanding of the average transaction time, we executed a single transaction multiple times and computed the mean duration for a complete transaction. According to the results in Table. 3, transactions involving three communication rounds (as seen in cases 1, 2, and 4) typically conclude in about 5 minutes. In contrast, scenarios like the lock failure in atomic swap, which involve only two communication rounds, might complete in just 3 minutes. These timeframes, spanning a few minutes, are reasonable when compared with other cross-chain transaction durations.