Decentralized cross-blockchain asset transfers with transfer confirmation

Today, several solutions for cross-blockchain asset transfers exist. However, these solutions are either tailored to specific assets or neglect finality guarantees that prevent assets from getting lost in transit. In this paper, we present a cross-blockchain asset transfer protocol that supports arbitrary assets, is adaptable to different means of cross-blockchain communication, and adheres to requirements such as finality. The ability to freely transfer assets between blockchains may increase transaction throughput and provide developers with more flexibility by allowing them to design digital assets that leverage the capacities and capabilities of multiple blockchains. We define the general requirements and specifications for a cross-blockchain asset transfer protocol and provide a proof-of-concept implementation for EVM-based blockchains. Further, we evaluate the protocol concerning costs, transfer duration, and security.


Introduction
With its ability to store data and perform computations in a decentralized and immutable manner, blockchain technology shows potential in application areas such as finance [1], supply chain management [2], healthcare [3], business process management [4], smart cities [5], the Internet of Things [6,7] and others [8]. Multiple independent and unconnected blockchains have been developed [9] to address the diverse requirements of these areas. As it is unlikely that a single blockchain caters to the requirements of all different areas [10], there is a strong need for interoperability between distinct blockchains.
Especially in scenarios where assets, i.e., digital representations of value, are managed on-chain, the lack of interoperability leads to a vendor lock-in as assets cannot leave the blockchain platform on which they were issued. Users would have to continue using the blockchain they initially chose since switching to another blockchain would only be possible with considerable effort or not at all. This vendor lock-in exposes projects to significant risks such as limited scalability [11], the danger that the underlying blockchain sinks into insignificance, and the inability to take advantage of new features offered by novel blockchains [9]. Of course, a centralized entity can be deployed to migrate assets from one blockchain to another. However, this contradicts the blockchain's original idea of decentralization [12].
The ability to transfer assets to arbitrary blockchains in a decentralized way would remove the need to commit to a particular blockchain. Instead, assets could be migrated to new blockchains offering novel functionality or better security at any time [9]. Another potential use case of crossblockchain asset transfers arises in the context of sidechains [13,14]. The idea is that an asset can be transferred to and processed on multiple ''side'' blockchains, thus reducing the workload of the original blockchain.
One way to exchange assets between independent blockchains is via atomic swaps [15]. With atomic swaps, multiple parties can atomically exchange assets, whereby no party ends up worse off if one of them misbehaves. However, atomic swaps do not constitute actual cross-blockchain asset transfers. The different assets are not leaving their respective blockchain but rather ownership of assets changes in an atomic fashion. Cross-blockchain asset transfers, on the contrary, achieve that an asset moves from one blockchain to the other, enabling users to hold different denominations of the same asset type on multiple blockchains. While schemes for cross-blockchain asset transfers have been proposed before, most of these solutions are designed with specific assets in mind and neglect important requirements for cross-blockchain asset transfers, such as finality to prevent assets from getting lost in transit.
Thus, in this paper, we formally define a set of general requirements that need to be fulfilled by cross-blockchain asset transfers and then propose a protocol that complies with the defined requirements.
This paper extends our previous work [16] by (i) providing more background information about cross-blockchain communication, (ii) adding additional functionality to the protocol, (iii) conducting a more detailed evaluation of the extended protocol while using different crossblockchain communication mechanisms, and (iv) updating the related work.
The contributions of this paper can be summed up as follows: • We formally define functional requirements for crossblockchain asset transfers. • We define a protocol specification for enabling crossblockchain asset transfers that are decentralized, secure, and not tailored to specific assets. • We evaluate the protocol on public Ethereum test networks using a proof-of-concept implementation for blockchains based on the Ethereum Virtual Machine (EVM).
To this end, Sect. 2 provides important background information. In Sect. 3, we formally define the requirements and specify the protocol for cross-blockchain asset transfers. Section 4 evaluates the proposed protocol concerning costs, duration, security, and features using a proof-of-concept implementation. Section 5 provides an overview of the related work. Finally, Sect. 6 concludes the paper.

Background
This section introduces some notations and definitions necessary for describing the requirements and specifications of the proposed cross-blockchain asset transfer protocol. Further, we look into different means of crossblockchain communication, which is an essential building block of the protocol proposed in Sect. 3.

Notations and definitions
As has already been mentioned in Sect. 1, cross-blockchain asset transfers ideally enable users to hold different denominations of the same asset on multiple blockchains simultaneously. By that, users are free to choose on which blockchain they want to keep their assets. An asset can be seen as anything holding some value with a corresponding representation on a blockchain. Assets can generally be divided into fungible and nonfungible assets [17]. Fungibility implies that two entities of the same asset are interchangeable. Cryptocurrencies like Bitcoin or Ether are fungible assets. Another example of fungible assets is Ethereum tokens following the ERC20 standard [18]. In contrast, non-fungible assets are uniquely identifiable, i.e., one entity cannot be substituted by another entity. For instance, ERC721 tokens (e.g., Cryptokitties) are non-fungible assets [19].
One can further distinguish between native and user-defined assets [17]. Native assets are inherently part of a particular blockchain. One cannot exist without the other, e.g., the Bitcoin and Ether cryptocurrencies and the Bitcoin and Ethereum blockchains, respectively. On the other hand, certain blockchains allow the implementation of use case-specific assets with their own set of rules, e.g., the already mentioned ERC20 or ERC721 tokens. Contrary to native assets, these user-defined assets are not bound to specific blockchains. Instead, they are implemented using smart contracts and can thus be potentially deployed on any blockchain with the necessary scripting capabilities to express the asset's rules.
This work concentrates on user-defined assets since the goal is to provide an asset that allows users to hold different amounts of the same asset on multiple blockchains at the same time. We formally define an asset A as a set where the set's members represent the asset's smallest indivisible entities (asset entities). For instance, the smallest indivisible entity of a fungible asset like Bitcoin is a Satoshi (i.e., 0.00000001 BTC). For a non-fungible asset like Cryptokitties, the smallest indivisible entity is a single ''cryptokitty''.
We define the set of blockchains between which asset transfers can take place by the finite set B (also referred to as the cross-blockchain ecosystem). Each blockchain b 2 B can host multiple smart contracts. Out of these smart contracts, one contract is responsible for managing asset A on b. We denote this particular smart contract as c b for each b 2 B.
We assume blockchains to roughly follow the model devised by Satoshi Nakatomo [1]: The state of the blockchain is updated through transactions that can be used to transfer the native asset of the blockchain, store arbitrary data, or trigger the execution of smart contracts. In the latter case, the transaction's payload contains parameters based on which the smart contracts may change their associated state. For instance, a transaction payload containing a sender, a recipient, and an amount could trigger a smart contract causing the transfer of some user-defined asset from the sender to the recipient.
We specify transactions as a tuple containing the elements of the payload, which serve as parameters for the invoked contract. In particular, we use tx :¼ hparam 1 ; . . .; param n i to denote a transaction tx with a payload containing n parameters. Further, we define the function calledContractðtxÞ to return the address of the smart contract that was triggered by transaction tx. The execution of transactions may fail, for instance, if a user does not have enough funds for a transfer. For this, we define the function isSuccessfulðtxÞ to return true or false depending on whether the transaction has been executed successfully or not.
Every transaction is signed by some off-chain user u 2 U before being submitted to the blockchain. The function submitterðtxÞ denotes the user that signed tx. Users can be the owners of a subset of asset A on each participating blockchain b 2 B. Subsequently, the set A b u A defines the entities of asset A that are owned by a particular user u 2 U on blockchain b.
Finally, for two blockchains src; dest 2 B, and two users sender, recipient 2 U, we define a cross-blockchain asset transfer as the transfer of some X A from user sender on source blockchain src to user recipient on destination blockchain dest.

Cross-blockchain communication
Fundamental to the protocol proposed in Sect. 3 is the ability to communicate state information between blockchains. In particular, the protocol relies on the ability to verify the inclusion of transactions across blockchains, i.e., the destination blockchain dest must be able to verify that certain transactions are included in the source blockchain src. Ideally, this cross-blockchain communication is decentralized such that no trust in a centralized party is required to ensure the validity of the information.

Oracles
Oracles, or more generally, data on-chaining solutions [20], offer one way to realize cross-blockchain communication. An oracle acts as a bridge between a blockchain and external data sources. The task of the oracle is to retrieve the data from the external data source (e.g., another blockchain) and submit it to a smart contract. While different oracle solutions exist, one approach to verify the inclusion of transactions is voting-based oracles. Several concepts and solutions for voting-based oracles have already been proposed [21][22][23][24][25].
A voting-based oracle requires a special oracle contract on the destination blockchain. Clients can call the oracle contract to get state information about the source blockchain src, e.g., to check for the inclusion of a specific transaction. The oracle contract starts a voting period during which other users can post their votes (''yes'' or ''no''). The answer which reaches a previously defined threshold (e.g., the majority) wins. Users are encouraged to participate in the voting process through crypto-economic incentives. Unfortunately, the voting mechanism incurs high costs if the aggregation of the votes is done on-chain. However, there are already oracle solutions, e.g. [25], that use an off-chain aggregation mechanism and only submit the aggregated result to the oracle contract. The oracle contract then only has to verify the validity of the aggregated result, which is cheaper since it requires only a single transaction.

Blockchain relays
Another technique for realizing transaction inclusion verifications is using blockchain relays [26]. Blockchain relays operate by having a set of off-chain clients relay block headers (see Fig. 1) from a source blockchain to a destination blockchain, replicating the source blockchain within the destination blockchain. Each relayed block header is validated on the destination blockchain according to the validation rules of the source blockchain. As block headers do not contain any transactions, only a small fraction of the space needed to store full blocks is consumed on the destination blockchain.
With the block headers of the source blockchain replicated, clients can query state information about the source blockchain on the destination blockchain, e.g., the current longest branch of the source blockchain, or if a certain block header is confirmed by at least x succeeding block headers.
Further, transactions in a blockchain (i.e., in a block) are stored in a special data structure called Merkle tree [27], or variants thereof. Since the root hash of the Merkle tree is also stored in the block header, it becomes possible on the destination blockchain to verify whether some transaction is included within a particular block of the source blockchain. For that, users construct a so-called Merkle proof of membership [27]. The proof is submitted to the destination blockchain, on which the proof is used to recalculate the root hash of the corresponding Merkle tree. If the calculated root hash matches the root hash of the stored block header, the destination blockchain can be certain that the transaction is included within the corresponding block of the source blockchain. This technique is also known as Simplified Payment Verification (SPV) [1].
Blockchain relays provide an on-chain answer to whether a certain transaction is included in the source blockchain. Contrary to voting-based oracles where multiple clients have to act honestly, blockchain relays only require one honest participating client [28]. However, blockchain relays cause higher costs since relayers have to continuously submit block headers to keep the relay up to date. In the following section, we use blockchain relays and oracles to realize the proposed asset transfer protocol.

Cross-blockchain asset transfers
In this section, we define the requirements for crossblockchain asset transfers. Then, we use these requirements as the foundation to define a decentralized cross-blockchain asset transfer protocol.

Requirements
As defined in Sect. 2, a cross-blockchain asset transfer for an asset A constitutes the transfer of ownership of some subset X A from some user sender on a source blockchain src to another user recipient on a destination blockchain dest.
Before the transfer, X must only exist on blockchain src, and after the transfer, the asset must only exist on blockchain dest. At no point should X exist on both blockchains in parallel since the accidental duplication of asset entities can potentially lead to a deflation of the asset's value. Hence, a cross-blockchain asset transfer should only be successful, i.e., X is created on dest, if X has been burned (i.e., destroyed) before by its owner on src.
Therefore, before X can be recreated on dest, dest needs some kind of evidence that X has already been burned on src. If we assume that it is possible to provide such evidence guaranteeing that X has been burned on src and that this evidence can be used to recreate X on dest, two further requirements emerge. First, faking the evidence needs to be prevented at all costs. Users should not be able to counterfeit evidence certifying that X has been burned on src without it having occurred. Second, if the evidence is correct, it should only be used once to recreate X on a different blockchain, i.e., on blockchain dest. Hence, evidence of X having been burned on src cannot be used multiple times to recreate X on other blockchains. Essentially, disregard of any of these requirements would enable users to illegally create new entities of asset A out of nothing-again potentially deflating the value of the asset and decreasing trust in this particular asset.
A further requirement comes up when trying to prevent the opposite, accidental inflation of the asset's value. Accidental inflation could take place if X is burned on src without ever being recreated on dest. This reduces the total supply of A. Hence, cross-blockchain asset transfers need to be eventually finalized to not decrease the total supply of A over time. That is, either the transfer is executed completely or it fails with no intermediate state persisting.
Finally, the source blockchain src possibly needs to perform some action if a certain cross-blockchain asset transfer has been executed successfully (i.e., X has been successfully recreated on destination blockchain dest). For instance, imagine a business deal where some user buyer wants to buy asset entities Y A 0 , with A 0 \ A ¼ ;, from another user seller. While asset A 0 lives exclusively on the source blockchain src, user buyer aims to buy Y with cross-blockchain asset A, transferring X from themselves on blockchain src to user seller on blockchain dest. Therefore, ownership of Y can change on src if it is ensured that the transfer of X was successful, i.e., blockchain src must retrieve a confirmation of the successful transfer.
To sum up, we define the general requirements for a cross-blockchain asset transfer as follows: Requirement 1 When a user sender wants to burn X on blockchain src, X should only be burned if X A src sender . Requirement 2 When transferring some X A from the source blockchain src to the destination blockchain dest, X should only be recreated on dest if it can be proven that X has already been burned on src. That is, it should not be possible to counterfeit the burning of asset entities.
Requirement 3 Double spending must be prevented at all times. That is, if X is burned on one blockchain, X can only be recreated once on one other blockchain.

Requirement 4
If X is burned on one blockchain, X is always recreated on another blockchain within a certain  Fig. 1 Blockchain relay time limit t. Further, finality should not be dependent on a single actor (i.e., not be centralized).

Requirement 5
After burning X on source blockchain src, src will eventually receive a confirmation that X has been successfully recreated on another blockchain. Analogous to decentralized finality, any user should be able to submit confirmations. This requirement is optional since not every use case requires that the source blockchain knows whether a crossblockchain asset transfer has been completed successfully.
In the next subsection, we define a cross-blockchain asset transfer protocol that fulfills these requirements. To this end, we first define a base protocol that fulfills Requirements 1 to 4 (Sect. 3.2). We then provide an extension of the protocol to also account for Requirement 5 (Sect. 3.3).

Protocol 1 Protocol for cross-blockchain asset transfers
Goal: For two blockchains src, dest ∈ B and two users sender, recipient ∈ U , transfer X ⊆ A from src to dest and change ownership of X from sender to recipient.
1. Burn. User sender creates a new burn transaction tx burn := recipient, dest, X .
(a) User sender signs and submits tx burn to source blockchain src invoking contract c src , i.e., the contract managing asset A on src. (b) When being invoked, contract c src performs the following operations.
i. Verify dest ∈ B to make sure that the specified blockchain dest is part of the crossblockchain ecosystem. ii. Verify X ⊆ A src sender to make sure that user sender owns the asset entities it wants to transfer on blockchain src. iii. When all checks are successful, the asset entities to be transferred are burned, i.e., A src sender = A src sender \ X. i. Verify b = dest to ensure that the executing blockchain b is the intended destination blockchain dest. Note that dest, recipient, and X are available within c b as these variables are contained within the payload of tx burn . ii. Verify tx burn / ∈ T burn where T burn is the set of burn transactions that have already been used to claim entities of asset A on dest. This ensures that burn transactions cannot be used multiple times for claiming. iii. Verify calledContract(tx burn ) = c src to make sure that the contract that has been invoked by tx burn is a contract authorized for managing asset A on blockchain src. iv. Verify that isSuccessful(tx burn ) returns true to ensure that the execution of c src has been completed without error. v. If c verifier .confirmations(tx burn , src) > t, user recipient has not submitted tx claim within time t. Hence, the user u = submitter(tx claim ) that submitted tx claim receives a transfer fee X fee ⊆ X as reward for finalizing the transfer, i.e., A dest Otherwise, no fee will be paid to u (i.e., X fee = ∅), resulting in all asset entities being transferred to recipient. vi. (Re-)create the asset entities and assign ownership to user recipient, i.e., A dest recipient = A dest recipient ∪ (X \ X fee ). vii. Add tx burn to the set of already used burn transactions, i.e., T burn = T burn ∪ {tx burn }.
As mentioned above, a cross-blockchain asset transfer should only be successful if the asset is first burned on the source blockchain and then recreated on the destination blockchain ( Requirement 2). Therefore, the transfer requires at least two steps: one ''burn'' step on the source blockchain and one ''claim'' step on the destination blockchain. The protocol uses oracles or blockchain relays for decentralized cross-blockchain communication to verify the ''burn'' step. In particular, these provide an on-chain answer to whether a specific transaction is included in the source blockchain via SPV [1]. With this in mind, we can outline a minimal protocol for cross-blockchain asset transfers (see Fig. 2).
The protocol consists of a BURN transaction tx burn submitted to source blockchain src and a CLAIM transaction tx claim submitted to destination blockchain dest. Further, a verifier contract allows the asset contract on blockchain dest to verify the inclusion of BURN transactions in blockchain src. The exact specification is outlined in Protocol 1.
Initially, some user sender creates transaction tx burn . The payload of tx burn contains the user intended as the recipient of the transfer (recipient), an identifier representing the desired destination blockchain (dest), and the asset entities to be transferred (X). It may also be that additional data is required, as is the case with ERC721 tokens, which have a tokenID or tokenURI. These must also be part of tx burn or an additional data structure (e.g., the transaction receipt) that can be verified on the destination blockchain.
User sender then signs and submits tx burn to the source blockchain src invoking smart contract c src , which manages asset A on blockchain src (Step 1a). The smart contract then verifies that the specified destination blockchain dest is part of the cross-blockchain ecosystem (Step 1(b)i). Second, the contract ensures that the user sender is the current owner of X on blockchain src (Step 1(b)ii). If both checks are successful, X is burned on src (Step 1(b)iii).
Once tx burn is included in blockchain src, any user u 2 U can construct the CLAIM transaction tx claim . The payload of tx claim consists of transaction tx burn and a Merkle proof of membership of tx burn (proof tx burn ). The verifier contract c verifier on blockchain dest uses the proof to verify the inclusion of tx burn in blockchain src. Note that if only the sender or only the recipient of the transfer were allowed to submit tx claim , the finality of the transfer (Requirement 4) would be entirely dependent on that particular user, e.g., the user could decide not to submit tx claim .
User u then signs and submits tx claim to some blockchain b 2 B invoking the contract c b managing A on blockchain b (Step 2a).
By invoking the verifier contract c verifier , the contract c b checks whether tx burn is included and confirmed in blockchain src (Step 2b). If the verifier contract does not confirm the inclusion of tx burn , the claim request is rejected. Otherwise, contract c b performs the following steps: First, it verifies that b is the intended destination blockchain dest (Step 2(c)i). Second, it is verified that tx burn has not been used to claim X on b before (Step 2(c)ii). Third, if both checks are successful, contract c b verifies that the contract that burned X on src is a valid contract authorized for managing A on src (Step 2(c)iii). If this is the case, contract c b further checks that tx burn was successful, i.e., the execution of contract c src has been completed without any error, e.g., constraint violations (Step 2(c)iv). This check covers the case in which some blockchains transactions may be included even if the triggered smart contract execution was not successful. While Ethereum also includes failed transactions, other blockchains may not include such transactions at all.
The above checks ensure that tx claim is only successful if the corresponding tx burn was also executed successfully. To further account for Requirement 4 (transfer finality), the protocol must ensure that when transaction tx burn takes place on blockchain src, the corresponding tx claim is eventually submitted to destination blockchain dest.
Usually, the incentive for transfer finalization lies with the recipient of the transfer since the recipient wants to receive the transferred asset entities. However, in case the recipient is indisposed to submit tx claim for some reason, the protocol offers an incentive in the form of a transfer fee to other users. That is, any user u that successfully submits tx claim gets assigned a subset X fee X as a reward (-Step 2(c)v). However, to provide the user recipient with the chance to receive all entities of X, other users are only eligible to receive the fee if they submit tx claim after a certain time t has elapsed. Time t is defined by the number of blocks that succeed the block containing tx burn on source blockchain src. Hence, when being invoked by tx claim , c b additionally queries the verifier contract c verifier whether the block containing tx burn is confirmed by more than t succeeding blocks. If this is the case, the time t is considered elapsed, and the user that submitted tx claim receives the transfer fee  Fig. 2 Base protocol for cross-blockchain asset transfers leveraging a blockchain relay X fee , while user recipient receives the rest X n X fee . If not, the user recipient always receives the entire set X (i.e., X fee ¼ ;), even if another user submitted tx claim (Step 2(c)vi). Asset entities are (re-)created on blockchain b (¼ dest) by incrementing the balance of the recipient (in case of fungible assets) or by copying the transferred asset's data structure from tx burn into the storage of contract c b (in case of non-fungible assets).
Finally, to ensure that tx burn cannot be used to claim X on b again, tx burn is added to the set of already used BURN transactions T burn (Step 2(c)vii).

Protocol extension for transfer confirmations
Protocol 2 Extension for transfer confirmations on the source blockchain Goal: For two blockchains src, dest ∈ B and two users sender, recipient ∈ U , transfer X ⊆ A from src to dest and change ownership of X from sender to recipient. Confirm finalization of transfer on src.
1. Burn. Contrary to Protocol 1, tx burn contains an additional variable Y ⊆ A representing the stake that will act as reward for users submitting a confirmation transaction to src once the transfer has been completed on dest.
(a) User sender signs and submits tx burn to source blockchain src invoking contract c src . (b) When being invoked, contract c src performs the following steps. i. Perform all verification steps from Step 1b of Protocol 1.
ii. Verify Y ⊆ A src sender to make sure that user sender owns the asset entities she wants to use as stake on blockchain src. iii. Verify Y ∩ X = ∅, i.e., X and Y are disjoint, to ensure that the asset entities intended to be transferred are not used as stake and vice versa. iv. When all checks are successful, the asset entities to be transferred are burned and the stake is locked, i.e., A src To claim the entities of asset A on destination blockchain dest, the same steps as for tx claim in Protocol 1 are performed. 3. Confirm. Once tx claim is included in blockchain dest, any user u ∈ U can construct the confirm transaction tx confirm := tx claim , proof tx claim . Variable proof tx claim contains the Merkle proof of membership of tx claim certifying the inclusion of tx claim in blockchain dest. i. Verify tx claim / ∈ T claim where T claim is the set of claim transactions that have already been used for confirming transfer finalization on src. This ensures that claim transactions cannot be used multiple times. ii. Verify calledContract(tx burn ) = c src to ensure that tx confirm invokes the same contract that has been invoked by tx burn . iii. Verify calledContract(tx claim ) = c dest to make sure that the contract that has been invoked by tx claim is the contract managing asset A on dest as intended by tx burn . iv. Verify that isSuccessful(tx claim ) returns true to ensure that the execution of c dest has been completed without any error. v. Check if timeout for submitting tx confirm is reached. If so, user sender has not submitted tx confirm in time. Hence, the user u = submitter(tx confirm ) that submitted tx confirm receives the locked stake from tx burn as reward for providing the confirmation of the corresponding claim, i.e., A src u = A src u ∪ Y . If not, user sender gets back control of the locked stake, i.e., A src sender = A src sender ∪ Y , regardless of which user submitted tx confirm . vi. Add tx claim to the set of already used claim transactions, i.e., T claim = T claim ∪ {tx claim }. Protocol 1 provides finality by incentivizing users to submit tx claim for each tx burn . However, only the destination blockchain dest knows whether a cross-blockchain asset transfer has been completed successfully. Source blockchain src never actually learns about the finalization of the transfer. To circumvent this, we can augment Protocol 1 by adding a third kind of transaction (CONFIRM) to confirm the successful cross-blockchain asset transfer on src, as displayed in Fig. 3.
The extension of the protocol is specified in Protocol 2. At first, transaction tx burn is submitted to the source blockchain src. The payload of tx burn is the same as presented in Protocol 1-except for one additional field defined as Y. Y is a subset of asset A and represents a certain amount of stake that will act as a reward for users submitting a CONFIRM transaction to src.
When user sender submits tx burn to src (Step 1a), c src first performs the same verifications as in Protocol 1 (Step 1(b)i). Additionally, a couple of checks concerning the stake Y are performed. First, it is verified that user sender is the owner of Y on blockchain src (Step 1(b)ii). Second, it is verified that the sets X and Y are disjoint (Step 1(b)iii). That is, the asset entities intended to be transferred should not be used as a stake and vice versa. If all verifications are successful, X is burned on src, and Y is locked (Step 1(b)iv).
Once tx burn is included in src, any user can create and submit transaction tx claim containing tx burn and a corresponding proof data proof tx burn to the destination blockchain dest. The steps performed when the corresponding smart contract c dest is invoked are identical to those in Protocol 1 (Step 2).
With tx claim being successfully executed and included in blockchain dest, the successful transfer is reported back to source blockchain src. For that, any user can submit a CONFIRM transaction tx confirm to src (Step 3a).
When being invoked by tx confirm , contract c src verifies that tx claim is included in dest using transaction inclusion verification (Step 3b). If the verifier contract does not confirm the inclusion of tx claim , the confirm request is rejected. Otherwise, contract c src performs the following steps. First, it verifies that tx claim has not already been used for confirming transfer finalization (Step 3(c)i). Second, it checks that contract c src is the contract that has burned X, i.e., whether c src has been invoked by tx burn (Step 3(c)ii). This check ensures that contract c src is the intended receiver of the confirmation. Third, c src verifies that the contract invoked by tx claim is the correct contract managing asset A on the intended destination blockchain dest (Step 3(c)iii). dest can be extracted from tx burn included in the payload of the provided tx claim . Fourth, contract c src checks that tx claim was successful, i.e., the execution of contract c dest has been completed without any error (Step 3(c)vi).
If all checks are successful, contract c src not only has the information about the successful execution of tx burn but also that the corresponding tx claim finalized the transfer on blockchain dest. To reward user u for submitting tx confirm to src, the locked stake Y from tx burn is assigned to u (Step 3(c)v). This provides an incentive for users to submit tx confirm to src for finalized cross-blockchain asset transfers.
The protocol uses a similar approach for the locked stake as for the transfer fee. The initiator of the transfer can withdraw its locked stake with certain conditions. A timeout determines who is eligible to retrieve the locked stake Y when tx confirm is submitted. Before the timeout, only sender is eligible for the stake. After the timeout, anyone submitting tx confirm earns Y as a reward. As contract c src executes both the burning of entities and confirmations, it can track the time difference between the two events.
Finally, to ensure that tx claim cannot be used several times, tx claim is added to the set of already used CLAIM transactions T claim (Step 3(c)vi).

Evaluation
In this section, we evaluate the proposed cross-blockchain asset transfer protocol and its extension with regard to the defined requirements and conduct a quantitative analysis evaluating transfer costs and duration. For the evaluation, we provide a proof-of-concept implementation for EVMbased blockchains such as Ethereum and Ethereum Classic. The prototype, as well as the evaluation scripts used for obtaining the results presented in Sect. 4 Fig. 3 Protocol extension to provide transfer confirmations leveraging blockchain relays

Prototype
As mentioned above, the prototype is implemented for EVM-based blockchains. The advantages of targeting EVM-based blockchains in a first proof-of-concept are twofold. First, EVM-based blockchains such as Ethereum are among the most popular blockchains concerning decentralized applications (DApps) and digital assets [11,29]. Cross-blockchain transfer capabilities for EVMbased blockchains can thus enhance the utility of a majority of available assets. The second reason is rather practical.
As quite a few EVM-based blockchains exist, multiple blockchains can be targeted with a single implementation. However, as long as a blockchain provides sufficient scripting capabilities to implement the concepts of the protocol, as well as some means of transaction inclusion verification (e.g., via oracles or relays), the solution can be adopted beyond EVM-based blockchains.
For our analysis, we use the ERC20 token standard as asset representation. For transaction inclusion verification, we use two different means of cross-blockchain communication. Initially, we implemented the prototype to work with ETH Relay, a blockchain relay specifically targeting EVM-based blockchains [28]. ETH Relay follows a validation-on-demand pattern where relayers can issue a dispute during a certain lock time to trigger the validation of a block header. This approach saves costs since not every block has to be validated. For simplicity, we set the lock time to 0 as it would only lengthen the experiments and add a constant value to the transfer duration.
Additionally, we apply the oracle solution proposed in [25], which uses an off-chain aggregation mechanism based on threshold signatures. We extended the oracle to return block headers instead of single transactions such that it implements the same interface as ETH Relay. We run three oracle nodes, the majority of which have to agree on the same outcome to construct the threshold signature. With the application of both mechanisms, we can also observe how the asset transfer protocol works with different approaches to cross-blockchain communication.
A transaction in Ethereum consists of the fields nonce, gasPrice, gasLimit, to, value, data, and a signature (v, r, s) [30]. The field data contains the payload (e.g., the parameters for a smart contract invocation) of the transaction. The field to contains the address of the smart contract that has been invoked by the transaction (i.e., function calledContractðtxÞ in our protocol). The submitter submitterðtxÞ of the transaction can be calculated out of the signature fields v, r, and s.
It should be noted that the transaction data does not contain information about the transaction status, i.e., whether the execution succeeded or failed. In Ethereum, this information is stored in another data structure, the socalled transaction receipt. For each transaction, there exists a corresponding receipt. The receipt contains all events that were emitted during the execution of the transaction. Further, a status flag indicates the successful execution of the transaction. Thus, when evaluating the function isSuccessfulðtxÞ in our protocol, the asset contract must have access to the receipt of tx as well.
In Ethereum, a block's transactions and receipts are kept in separate Merkle trees, which do not contain references to each other. However, transaction and receipt are logically linked together as their position in their respective trees is identical. Both the inclusion of the transaction and the receipt can be verified via Merkle proofs of membership using the respective Merkle trees.
Both Merkle proofs must be evaluated along the same path to ensure that a transaction and receipt belong together. Hence, in our prototype, the proof data certifying the inclusion of a transaction (e.g., proof tx burn ) contains a Merkle proof for the transaction and the transaction receipt. Further, it includes the path for the evaluation of the Merkle proofs.

Requirements analysis
This section evaluates the protocol with regard to the requirements defined in Sect. 3.1.

Requirement 1 (ownership)
When user sender submits a BURN transaction tx burn invoking contract c src , the contract verifies that X A src sender (see Step 1(b)ii of Protocol 1), thus making sure that user sender is the owner of X on src. Hence, we consider Requirement 1 as fulfilled.

Requirement 2 (no claim without burn)
To claim X on dest, a user u submits a CLAIM transaction tx claim . As defined by the protocol, the user provides tx burn as well as some proof data in the payload of tx claim . Before recreating X, the asset contract c dest on blockchain dest performs several checks.
First, it is verified that tx burn is included in the source blockchain src and confirmed by enough blocks (Step 2b). Second, the protocol checks that tx burn indeed invoked asset contract c src on the source blockchain src (Step 2(c)iii). Third, contract c dest verifies that the execution of tx burn was successful (Step 2(c)iv).
These three checks ensure that assets are created on the destination blockchain dest if they have been successfully burned by the contract c src on the source blockchain src.
Notably, the fulfillment of this requirement strongly depends on the security of the used transaction inclusion verification mechanism. A security analysis of the blockchain relay (ETH Relay), as well as the oracle used in our proof-of-concept implementation, can be found in [25,28], respectively.

Requirement 3 (double spend prevention)
To ensure that burned assets can not be claimed multiple times, all BURN transactions that have already been used within CLAIM transactions are stored in a set T BURN within asset contract c dest . When c dest is invoked by a new CLAIM transaction tx claim , it only executes the claim if the provided BURN transaction tx burn is not yet included in T BURN (Step 2(c)ii).
Further, by encoding an identifier of the desired destination blockchain dest within BURN transactions, a burned asset can not be claimed on multiple different blockchains. When an asset contract c b on some blockchain b is invoked by a CLAIM transaction containing tx burn , c b can verify whether it is the intended destination contract by comparing b ¼ dest (Step 2(c)i). If not, the claim is rejected. Therefore, Requirement 3 can be considered fulfilled as well.

Requirement 4 (decentralized finality)
For the analysis of finality, we make use of the BAR (Byzantine, Altruistic, Rational) model [31], which has found application in security analysis for blockchain protocols and extensions before, e.g., [28,32,33]. Under this model, Byzantine users may depart arbitrarily from the protocol for any reason; altruistic users always adhere to the protocol rules, and rational users will deviate from the protocol to maximize their profit.
The protocol in this paper offers a reward to users submitting the CLAIM transaction. As the reward is at least as high as the submission costs of CLAIM transactions (see Sect. 4.3), rational users have an economic incentive to finalize transfers. However, in any protocol, rational users according to the BAR model, cannot be fully trusted to act rationally in the sense of the protocol's incentive structure since seemingly irrational behavior might be perfectly rational in the context of a larger ecosystem with the protocol being part of it [34]. For instance, rational users might aim at yielding profit in the larger ecosystem by finding ways to bet against the protocol or the value of the asset.
Therefore, rational users are not guaranteed to comply with the protocol rules even with perfectly aligned incentives. Building an open and permissionless system that withstands all participants potentially deviating from the protocol rules appears fundamentally impossible [34]. Thus, in our protocol, not only the users directly involved in a transfer are allowed to post the CLAIM transaction, but rather any user of the system can do it. This provides stronger finalization guarantees as finalization does not depend on a single user acting honestly. It is sufficient if one user out of all users is altruistic to ensure finalization. Notably, the protocol only relies on an altruistic user in case rational users see an incentive in deviating from the proposed protocol.

Requirement 5 (transfer confirmation)
With Requirements 1to 4 fulfilled, cross-blockchain asset transfers with decentralized finality can be realized. However, in Protocol 1, only the destination blockchain dest knows when a transfer is finalized. The source blockchain src has no way of knowing about the finalization. We have thus proposed Protocol 2 as an extension of Protocol 1 to fulfill the additional requirement of providing src with a finalization confirmation. The confirmation takes place in the form of an additional transaction tx confirm being submitted to src.
The CONFIRM transaction also has to comply with Requirements 2 to 4. The execution of tx confirm should only be successful if there exists a corresponding CLAIM transaction tx claim successfully executed on dest (Requirement 2). Further, it should not be possible to confirm tx claim multiple times (Requirement 3). Additionally, after the successful execution of a CLAIM transaction tx claim on dest, the corresponding CONFIRM transaction tx confirm is eventually submitted to src (Requirement 4).
The requirements are fulfilled by Protocol 2 using the same approach that is used for CLAIM transactions. That is, similar to how a CLAIM transaction's payload contains a BURN transaction and corresponding proof data, tx confirm consists of a CLAIM transaction tx claim and corresponding proof data proof tx claim .
The asset contract c src performs the following checks when being invoked by a CONFIRM transaction tx confirm to fulfill Requirement 2: First, c src verifies that tx claim is included in blockchain dest and confirmed by enough blocks (see Step 3b of Protocol 2). Second, the contract verifies that the provided CLAIM transaction tx claim has invoked asset contract c dest on blockchain dest (see Step 3(c)iii of Protocol 2). Third, c src checks that tx claim has been successfully executed on blockchain dest (see Step 3(c)iv of Protocol 2). With these checks in place, Requirement 2 also holds for CONFIRM transactions.
It should not be possible to reuse the same CLAIM transaction tx claim on blockchain src to fulfill Requirement 3. Further, it should not be possible to use tx claim on any blockchain other than src for confirming transfer finalization. The first condition is ensured by adding each confirmed CLAIM transaction tx claim to a set T CLAIM (see Step 3(c)vi of Protocol 2). Whenever c src is invoked, it checks whether tx claim provided within tx confirm is included in T CLAIM (see Step 3(c)i of Protocol 2). If so, the request is rejected. To ensure the second condition, the asset contract that has been invoked by the BURN transaction contained within tx claim is compared to c src (see Step 3(c)ii of Protocol 2). If they match, c src is the intended receiver of the confirmation.
The applied incentive structure ensures the confirmation of each transfer finalization on src (Requirement 4). Essentially, whenever some user sender submits a BURN transaction tx burn to blockchain src, it has to provide some stake Y. If user sender does not submit tx confirm before a timeout, any user can redeem Y by submitting tx confirm to src. Hence, there is an economic incentive to confirm transfer finalizations on src. Applying the same chain of reasoning for analyzing eventual finality reveals that as long as at least one altruistic user is participating, each transfer finalization on blockchain dest is eventually confirmed on blockchain src.
As the CONFIRM transaction tx confirm complies with Requirements 2 to 4, we consider the requirement for transfer confirmations fulfilled by Protocol 2.

Quantitative analysis
This section analyzes transfer costs and duration using the proof-of-concept implementation. We conduct crossblockchain asset transfers between the public Ethereum test networks Rinkeby and Ropsten. Rinkeby and Ropsten are identical concerning the underlying EVM and the applied inter-block time (about 15 seconds). The main difference is the used consensus algorithm. Rinkeby uses Proof of Authority (PoA), while Ropsten uses Proof of Work (PoW). However, the execution of smart contracts is independent of the consensus algorithm. Therefore, evaluating transfers in one direction provides a sufficient estimation of transfer costs and duration.
Our evaluation consists of conducting 100 transfers of 1 ERC20 token from Rinkeby to Ropsten, i.e., BURN (CON-FIRM) transactions are submitted to Rinkeby, whereas CLAIM transactions are executed on Ropsten. We repeat the experiment for both means of transaction inclusion verification, i.e., the oracle and the blockchain relay. Additionally, we also repeat the experiment without transaction inclusion verification to measure the overhead of the respective mechanisms. These mechanisms usually charge a fee to reward the relayers or the oracle nodes. For simplicity, we set the fee to zero. Further, as the protocol extension also includes the steps of Protocol 1, we only use the implementation of Protocol 2 for our experiment.

Transfer costs
For every performed transfer, we measure the gas consumption of all three transaction types, i.e., BURN, CONFIRM, and CLAIM. The obtained results (see Table 1) are outlined in Figs. 4 and 5. Note that the respective figures contain the gas consumption for the protocol and transaction inclusion verification.
First, we examine the gas consumption of the protocol while using the blockchain relay. Here, we get a total gas consumption of 450.02 kGas (standard deviation of 17.16 kGas) for Protocol 1, calculated as the sum of tx burn and tx claim . The total gas consumption of Protocol 2 is about 1018.09 kGas (standard deviation of 34.8 kGas) and includes the gas consumption of tx confirm , which accounts for the higher overall costs. With an exemplary exchange rate of about 3030.68 EUR per ETH (as of March 2022) and a gas price of 10 GWei, the transfer costs amount to 13.64 EUR for Protocol 1 and 30.86 EUR for Protocol 2.
After examining the gas consumption with the blockchain relay, we look at the gas consumption with the oracle. Here, we get a total gas consumption of 427.31 kGas (standard deviation of 8.75 kGas) for Protocol 1 and 976.35 kGas (standard deviation of 21.21 kGas) for Protocol 2. Using the same exchange rate and gas price leads to transfer costs of 12.95 EUR for Protocol 1 and 29.6 EUR for Protocol 2.
The execution of tx burn is the cheapest, followed by tx claim and by tx confirm . The differences can be explained by the different payloads of each transaction type. As the payload of tx burn does not consist of any other transaction and proof data, less data needs to be passed to and processed by the asset contract leading to lower gas consumption. On the contrary, tx claim contains tx burn , as well as proof data for tx burn , and tx confirm contains tx claim together with the corresponding proof data, which leads to higher gas consumption. The gas consumption of transaction inclusion verification depends on the concrete means of cross-blockchain communication. The oracle checks off-chain if the block header is part of the main chain, thus resulting in lower gas costs than the blockchain relay. Nevertheless, the client has to issue the requests to the oracle separately to provide the hashes of the block headers needed for the proofs. These requests additionally consume 23.4 kGas per request as there are no independent relayers that continuously provide the data. However, an oracle is much cheaper to operate than a blockchain relay since it does not cause any ongoing costs [25]. These operating costs heavily influence the fees charged by the relay or the oracle.

Transfer duration
In this subsection, we analyze the duration of asset transfers, which depends on a few core factors. The current network status and the selected gas price greatly influence the inclusion and confirmation time of a transaction. Therefore, we conduct the experiments at different times over a period of 3 days, while the gas price is estimated automatically to ensure the inclusion of a transaction with a high probability in the next block.
Further, after submitting a BURN transaction, the submitter may wait before posting the corresponding CLAIM transaction. The same applies to a CLAIM transaction, after which the submitter can wait to submit the following CONFIRM transaction. Hence, the overall transfer duration depends on the user executing the transfer. However, despite this uncertainty, we can measure the lowest possible transfer duration by submitting each transaction at the earliest possible time, i.e., as soon as the previous transaction is included in the blockchain and confirmed by enough blocks. In our experiment, we require each transaction on Rinkeby as well as on Ropsten to be confirmed by at least five succeeding blocks.
Finally, the transfer duration also depends on the used transaction inclusion verification mechanism. Therefore, we examine the influence of different transaction inclusion verification mechanisms by measuring the transfer duration using a blockchain relay and an oracle.
As described above, in our experiment, assets are transferred from Rinkeby to Ropsten. Therefore, BURN and CONFIRM transactions are submitted to Rinkeby while CLAIM transactions are submitted to Ropsten. Hence, durations for BURN and CONFIRM transactions were measured on Rinkeby, whereas for CLAIM transactions on Ropsten.
Essentially, CLAIM (CONFIRM) transactions are submitted to Ropsten (Rinkeby) as soon as the corresponding BURN (CLAIM) transactions are included and confirmed on Rinkeby (Ropsten). However, users need to wait until the relay running on Ropsten (Rinkeby) has been brought up to date or the oracle has submitted the data before they can submit the corresponding CLAIM (CONFIRM) transactions. Otherwise, the transactions would not be successful as the transaction inclusion verifier does not have enough information to verify the inclusion of transactions.
To this end, D Inclusion denotes the duration from the moment a transaction is submitted to Rinkeby (Ropsten) until it is included in some block. D Confirmation specifies the time it takes for an already included transaction to be confirmed by enough succeeding blocks. Further, D Relay denotes the time it takes for the relay to collect enough information to verify the inclusion of transactions. Alternatively, D Oracle specifies the time the oracle takes to query the other blockchain and submit the result. Figure 6 shows the average transfer duration for each transaction type for both protocols while leveraging a blockchain relay. With an average duration of 55 seconds (standard deviation of 19 seconds), BURN transactions achieve the lowest duration, followed by CONFIRM transactions (average duration of 134 seconds, standard deviation of 49 seconds), and CLAIM transactions (average duration of 210 seconds, standard deviation of 138 seconds). The total duration of Protocol 1 is calculated by summing up the duration of BURN and CLAIM transactions, while the total duration of Protocol 2 also contains the duration of CONFIRM transactions. This calculation leads to an average transfer duration of 265 seconds (standard deviation of 145 seconds) for Protocol 1 and an average duration of 400 seconds (standard deviation of 160 seconds) for Protocol 2. Transfers with Protocol 2 take longer since an additional transaction is required.
The results depicted in Fig. 7 also show the average duration for each transaction type for both protocols. However, an oracle instead of a blockchain relay is used for transaction inclusion verification. Here also, BURN transactions show the lowest transfer duration with 89 seconds (standard deviation of 3 seconds). CLAIM transactions consume on average 248 seconds (standard deviation of 137 seconds), and the execution of CONFIRM transactions averages 117 seconds (standard deviation of 12 seconds). The total duration for Protocol 1 averages 337 seconds (standard deviation of 138 seconds) and 454 seconds (standard deviation of 137 seconds) for Protocol 2.
The results (see Table 2) initially indicate that using a relay leads to a shorter transfer duration. However, looking at the different durations for the inclusion and confirmation of the transactions and the time it takes for the relay and the oracle to include the data, we can discover different results. Further, we also have to consider the lock time, which was set to 0 for the experiments.
Although the inclusion and confirmation times are higher due to the network status, the time it takes for the oracle to provide the necessary data is less than the time it takes for the blockchain relay. This difference is due to the fact that the relay has to be kept up-to-date through the continuous submission of new block headers, which can lead to delays. With the oracle, on the other hand, only two transactions are needed to get the necessary data into the blockchain. The original implementation of ETH Relay foresees a lock time of 5 minutes to allow relayers to dispute invalid block headers. This mechanism causes another delay of at least 5 minutes for Protocol 1 and 10 minutes for Protocol 2. Therefore, using an oracle results in a considerably shorter transfer duration. Overall, the oracle is cheaper and faster, but the blockchain relay provides a higher degree of decentralization. Therefore, it depends on the use case which solution is more viable. In any case, the protocol can support both types of cross-blockchain communication.

Related work
Several solutions for cross-blockchain asset transfers have been proposed in the literature [12]. Evaluating the most important existing solutions against the requirements defined in Sect. 3.1 reveals that solutions generally fulfill Requirements 1 to 3. However, they lack with regards to decentralized finality (Requirement 4) or do not provide implementations of the proposed protocols. A summary of the different cross-blockchain asset transfer solutions is provided in Table 3.
In XClaim [35], cross-blockchain asset transfers are realized by first locking assets with a client called ''vault'' on a ''backing'' blockchain and reissuing the assets on another ''issuing'' blockchain. Locking of the assets on the backing blockchain is verified on the issuing blockchain via blockchain relays. However, the locked assets remain with the vault on the backing blockchain. While malicious vaults are penalized, transfer finality still depends on this single actor. In contrast, our protocol enables any clientwhether directly involved in the transfer or not-to finalize transfers. Further, transfer confirmations are not foreseen by the XClaim protocol.
Metronome [36] implements cross-blockchain asset transfers for their MET token. Token holders can export MET from one blockchain and then import them on another blockchain via receipts where validators vote on the validity of receipts. While this can prevent illegal transfers, at the time of writing, Metronome cannot be considered decentralized since only authorized nodes can participate as validators. Further, Metronome does not provide concepts for transfer finality and confirmations.
In [37], the authors define a proof-of-burn protocol. The protocol consists of two functions: GenBurnAddr and BurnVerify. With the former, users can generate new burn addresses with an encoded tag, while the latter allows users to verify the tagged burn. For the verification of the proof-  of-burn, the protocol foresees the usage of Noninteractive Proofs of Proof of Work (NiPoPoWs), oracles, or direct observation of the source blockchain by the miners. In the course of this, the authors show how users can acquire target cryptocurrency (e.g., ERC-20 tokens) by burning the source cryptocurrency. However, the protocol does not provide decentralized finality and transfer confirmations. Pillai et al. [38] propose a burn-to-claim asset transfer protocol. Also, similar to the protocol presented in Sect. 3, it comprises a burn operation on the source blockchain and a claim operation on the target blockchain. However, to access the transaction on the source blockchain to verify the correct execution of the burn transaction, the protocol requires nodes that can mine in multiple networks and act as gateways. Furthermore, the protocol does not take decentralized finality and transfer confirmations into account.
In [39], the authors present AucSwap, a cross-blockchain token transfer protocol modeled as an auction process. More specifically, the authors leverage the Vickery auction process and atomic swap technology to enable cross-blockchain asset transfers. The protocol consists of two parts: bidding collection and asset exchange. Initially, the seller broadcasts the bidding information and waits for the buyers to return their bids. After receiving all bids, the seller provides the buyers with a list of all bids. Having this information, the buyers can determine who won the auction. After that, the parties use Hash Time-Locked Contracts (HTLCs) to perform the actual exchange of the assets. Compared to our protocol, this solution has more similarities with asset exchanges than asset transfers.
The authors of [40,41] propose approaches for realizing cross-blockchain transfers between PoW and Proof of Stake (PoS) blockchains, respectively. While [40] verifies transaction inclusions via NiPoPoWs [41,42] enables transaction inclusion verifications via a novel cryptographic construction called ad-hoc threshold multisignatures (ATMS) ATMS. As such, NiPoPoW and ATMS are used to prove events (e.g., BURN transactions) that occurred on the source blockchain to the destination blockchain. While this satisfies Requirements 1 and 2, Requirements 3 and4 are generally not covered by the protocol. Further, NiPoPoWs currently cannot be implemented in existing PoW blockchains like Bitcoin or Ethereum without introducing a so-called velvet fork, which requires adoption from at least a subset of miners.
Similarly, Zendoo [43] provides a protocol for crossblockchain asset transfers focussing on zero-knowledge proofs as a method for transaction inclusion verification. However, requirements such as transfer finality are not discussed. Further, the protocol relies on a special sidechain construction and can thus not be easily implemented on existing blockchains. An approach that takes transfer finality into account is presented by van Glabbeck et al. [44]. The paper proposes a generic protocol for payments across blockchains similar to how multi-hop payment channels operate [45]. The work has a strong focus on finality. Requirements such as double spend prevention are mentioned though not further specified. Also, the protocol has not been implemented and evaluated yet. It does not become clear whether the protocol allows cross-blockchain asset transfers as defined in Sect. 3.1, or only value transfers similar to atomic swaps.
An alternative approach for cross-blockchain asset transfers is introduced in DeXTT [46]. DeXTT describes an asset that can exist on different blockchains at the same time. However, users cannot keep different denominations of the asset on each blockchain. Rather, balances are synchronized across all participating blockchains. While the synchronization process itself is decentralized, the protocol uses a concept called claim-first transactions, where assets are claimed on the other blockchains before being burned on the blockchain on which the transfer was initiated. This clearly violates Requirement 2. Transfer confirmations (Requirement 5) are also not foreseen.
Other works [15,32,47] focus on the transfer of value across different blockchains. However, these solutions rather focus on atomic swaps where two different assets are exchanged and do not constitute true cross-blockchain asset transfers as defined by our requirements in Sect. 3.1.
Finally, projects such as Polkadot [48] and Cosmos [49] also aim for generic cross-blockchain interactions. Polkadot implements a Cross-chain Message Passing (XCMP) protocol that enables two separate parachains to communicate with each other. To accomplish this, it makes use of a simple queuing mechanism based on Merkle trees. Cosmos implements the Interblockchain Communication (IBC) protocol proposed in [50]. The IBC protocol is inspired by the TCP/IP protocol and enables the communication between separate ledgers which implement the same interface. Multiple ledgers can establish a connection with each other to create channels over which packages can be transmitted to modules (e.g., smart contracts) on the other ledger. Both protocols have already been implemented by the respective projects. While cross-blockchain asset transfers are mentioned as example use cases, the documentation does not mention specifics on how these transfers are implemented. Further, these projects aim to provide interoperability primarily between specialized blockchains that adhere to certain structures and consensus protocols.
To the best of our knowledge, this work is the first to provide requirements, a specification, and a proof-of-concept implementation of a cross-blockchain asset transfer protocol that also takes transfer finality and transfer confirmations into account.

Conclusion
Decentralized cross-blockchain asset transfers are one way to provide interoperability between blockchains. In particular, they prevent vendor lock-ins by allowing blockchain assets to be moved away from the blockchains on which they were originally issued in a completely decentralized way. While a number of solutions for enabling cross-blockchain asset transfers have been proposed, these solutions often focus on specific assets and neglect the fundamental functionality that cross-blockchain asset transfers should offer. In this work, we defined general requirements and specifications for cross-blockchain asset transfer protocols. Providing a proof-of-concept implementation of the proposed protocol, we have shown that requirements such as decentralized finality and transfer confirmations can be fulfilled.
In future work, we will investigate how the concepts of this work can be extended to provide interoperability beyond cross-blockchain asset transfers, e.g., generic message passing between blockchains.

Declarations
Conflict of interest The authors have no relevant financial or nonfinancial interests to disclose.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons. org/licenses/by/4.0/.