DeCoTa: a lightweight decentralized cross-chain transfer scheme based on hash-locking

Abstract

With the wide application of blockchain comes the challenge of cross-chain interaction. For example, the isolation between the information stored in different blockchains can result in the ”isolated islands of value” effect in blockchains. In addition, conventional cross-chain methods have a number of drawbacks such as centralization, or have a very restricted application scope. (e.g., hash-locking can only be utilized for asset exchanges, but asset transfer is a more common and demanding requirement). Other solutions like sidechain may be an overkill (e.g., too complex) for simple applications. To address these challenges, we propose an cross-chain transaction scheme that integrates hash-locking with notary mechanisms to enable decentralized asset transfers. By embedding notary scheme within the hash-lock structure, our approach ensures support for asset transfers while mitigating centralization risks. Additionally, we enhance the traditional hash-locking mechanism, making it more flexible and suitable for diverse cross-chain scenarios. This combination of hash-locking and notary scheme allows our scheme to overcome the original shortcomings of them both, while maintaining high efficiency and security. In addition to designing the transaction method, we also constructed a transaction model, conducted experiments on transaction gas consumption, performed a detailed security analysis, and presented an in-depth discussion of our scheme while proposing directions for future work. Experiment and analysis demonstrate the practicability of our scheme in terms of performance and security.

Introduction

Cross-chain technology allows us to support the interactions of values directly between blockchains (note that blockchain networks can be considered as separate information silos that are interconnected through cross-chain mechanisms). The notary scheme, the first proposed method to deal with cross-chain situation¹, comprises a third party who is in charge of forwarding messages and assets. One disadvantage of the scheme is the risk of centralization, and one countermeasure is hash-locking. The latter approach can also provide atomicity. However, such an approach may not be suitable for asset transfer. Centralization and application limitations are two other key challenges associated with these solutions. In practice, complex solutions like sidechain may be an overkill for simple application scenarios. For example, Fig. 1 illustrates a simple transfer scenario. Specifically, if user A in blockchain I (e.g. Bitcion) is willing to transfer 10 BTC to user B in blockchain II (e.g. Ethereum), A have to find someone with an account in both blockchains I and II, say C. In this example, A transfers 10 BTC to C in blockchain I, and C will transfer equivalent 10 BTC in ETH to B. However if C decides not to forward on the BTC, there is no recourse for A (i.e., A will lose the 10 BTC).

Figure 1.

A simple transfer scenario.

Thus, in this paper, we propose a scheme where we use hash-locking to limit the notary’s power so that a malicious notary would not obtain the asset if there is an issue with the contract(s) he deployed. In the meantime, the introduction of notary scheme enables our scheme to transfer assets based on hash-locking. A summary of our approach is as follows:

1. We demonstrate that by combining both notary scheme and hash-locking will allow us to minimize the risk of centralization to the minimum.

2. We improve the structure of hash-locking, making it feasible for cross-chain asset transfer, and perform a comprehensive security analysis.

3. We propose an algorithm that can be implemented in smart contract, which is more secure, efficient, and highly portable for any blockchain that supports smart contracts.

Extant literature

Cross-chain methods

Since blockchain has become more important than ever, the isolation between different blockchains has caused an issue cannot be ignored. Ripple first proposed “Interledeger Protocol” in 2012, which can be seen as the earliest appearance of cross-chain technology¹. Three years later, the white paper of the Interledeger was also released². Interledeger implemented cross-chain transactions using a trusted notary, like a connector or a validator. The concept of hash-locking was brought up in Bitcoin Lightning Network³, and widely used in cross-chain technology now. Sidechain protocol was first publicized in the white paper “Enabling Blockchain Innovations with Pegged Sidechains”⁴, this protocol creates an independent blockchain as sidechain to support its main chain.

In addition to these existing applications, research on cross-chain methods has becoming a trending topic nowadays. The basic cross-chain methods can be categorized into notary technology, hash-locking, sidechain, etc., and there are some excellent solutions in each category. Xiong et al.⁵ presented a notary group-based cross-chain interaction model, introducing a margin pool and incentive mechanism to limit and encourage the notary group, and a reputation mechanism to select notaries. Ren et al.⁶ proposed HCNCT, a cross-chain transaction method based on hash-locking that can solve the problem of transaction channel blocking and centralization. They utilized a credibility evaluation mechanism and notary group based on threshold secret sharing to grantee fairness. Hei et al.⁷ implemented a cross-chain exchange system Practical AgentChain, on which various coins can be mapped to the tokens for trading. The system has the advantages of efficient, low-cost and highly portable. Xie et al.⁸ constructed an efficient cross-chain bridge called zkBridge that supports message passing, token transferring, and some other operations across chains. This method guarantees strong security while reducing on-chain verification costs. Li et al.⁹ proposed a sidechain-based unlinkable, fair and confidential scheme ZeroCross as well as a cross-chain protocol to ensure the interests of the honest parties. Xie et al.¹⁰ proposed a cross-Chain (RAC-Chain) model, which utilized the relay chain and cross-chain gateways to realize message and asset transmission in multiple chains. Bentov et al.¹¹ introduced a cryptocurrency exchange service that is primarily intended to solve the latency problem and frontrunning attacks. Moreover, it supports secure connection to existing cryptocurrency assets like Bitcoin. Garoffolo et al.¹² presented a scheme that can construct sidechains for blinded main chains, and made a reasonable design with full consideration of the relationship between main chain and sidechain. Besides, the side chains are allowed to build their own authentication and verification rules, and thus give the scheme great generality.

Protocols are the basic form of communication, and in on-chain or cross-chain technologies, their structure is often an important factor affecting the security and efficiency of communications or transactions. Herlihy¹³ introduced an effective atomic cross-chain swap protocol, supporting multiple parties exchange assets across multiple blockchains. This paper modeled a cross-chain swap as a directed graph and analyzed the time complexity of the protocol. Afterwards, Imoto et al.¹⁴ improved the time complexity and space complexity of the protocol based on Herlihy’s work¹³. Glabbeek et al.¹⁵ formally defined the time-bounded cross-chain payment problem, and discussed the solution under different synchronization conditions. Herlihy et al.¹⁶introduced the concept of a cross-chain deal that manages assets in an adversarial setting, in the mean time, can adopt the decentralized and untrusting nature of the exchange.

Cross-chain security

Blockchain as a kind of distributed ledger, is always connected to cryptocurrency or confidential data. Similarly, cross-chain transfers also tend to have these as their content. Therefore, security is an issue that cannot be underestimated in cross-chain technology. Apart from ZeroCross, Li et al.⁹ also disscussed the influence of the remote side-channel attack in cross-chain exchange along with the defense mechanism. Xue et al.¹⁷ disscussed sore loser attack based on atomicity, then described some of the ways in which this attack can be resisted. In addition, their protocol can also protect the honest parties’s asset.

Apart from the above researches on attacks, Yang et al.¹⁸ introduced a cross-chain privacy protection protocol based on relay chains. This protocol maps each user’s transaction to a diferent external address and can effectively protect privacy. Jin et al.¹⁹ believed that fork fraud was ignored by most cross-chaining methods while jeopardizing the safety of users’ property. For this reason, they introduced a scheme to resist fork fraud by redesigning the cross-chain process called EAC3. Mohanty et al.²⁰ proposed Neo Hashed Time-Lock Commitment to anonymize the sender’s identity in a transaction process, and an efficient symmetric key encryption-based payment protocol that can interact with existing methodologies. Tsabary et al.²¹ presented a Mutual-Assured-Destruction Hashed Time-Locked Contract (MAD-HTLC) to ensure fairness. Furthermore, they also disscussed bribery attacks about HTLC. Zhang et al.²² focused on the security of cross-chain bridges, they devised a new set of methods for defining security problems, on the basis of which a cross-chain bridge vulnerability detection tool, Xscpoe, is developed. Yi et al.²³ studied on usage-based insurance (UBI), introduced a cross-chain-based premium competition scheme to resist the dilemma of realizing intelligent UBI systems. This scheme was positive to user privacy protection and can be integrated with privacy-preserving data aggregation methods. Liang et al.²⁴ proposed a scalable cross-chain approach in IoT application scenarios that is effective against tampering and eavesdropping by adversaries, in the mean time, they also presented IoMT device querying methods capable of utilizing encrypted location information and trust evidence.

Related work discussion and our motivation

After analyzing the methods and security, it can be concluded that although there has been a lot of research on this, it does not apply to all scenarios or is not the optimal solution for the specific scenario. The notary technology has one fatal problem: centralization, which greatly affects its usability. The most commonly used solution is to set up a group of notaries instead of a single one in order to constrain their power while applying advanced signatures or other mechanisms to ensure security. This approach mitigates the above problem to some extent, but introduces both management and efficiency issues, with an increase in complexity. Hash-locking is both easy to implement and immutable, which is why it is often deployed as an auxiliary tool. However, a complete hash-locking protocol can only be applied to the exchange of assets, which greatly reduces scalability and its applicability in realistic scenarios. As for sidechain technology, which can provide powerful and comprehensive functionalities, it is however more suitable for large scale interactions between two blockchains. Moreover, since sidechains are usually customized based on the features of the main chain, it offers lower scalability and higher costs compared to other technologies.

All in all, an excellent cross-chain method should be able to combine the advantages of scalability, efficiency, ease of implementation, and security. Table 1 is a summary of the flaws of existing methods along with our solutions to address them. We aim to design a low-cost, lightweight method suitable for individual or small cross-chain transfer scenarios. In this paper, we propose a hash-locking based cross-chain transfer scheme, a notary is introduced to divide the structure of the hash lock into two halves to enable the transfer of assets. Simultaneously, the existence of the revised hash lock can effectively prevents centralization.

Table 1.

Limitations of other methods and our solution.

Methods	Limitation	Our Solution
Notary schemes	Centralization	Limit the notary’s power by utilizing the atomicity of HTLC contract
Sidechains/relays	More suitable for large-scale interactions	Design a lightweight cross-chain approach

Preliminaries

Elliptic curves cryptography

Elliptic Curves Cryptography is a commonly used cryptographic algorithm for encryption and signatures. Compared with other well-known public-key algorithms, ECC has some advantages on efficiency and security, which leads a widespread application of it, such as bitcoin and blockchain.

For a given big prime number q, generates a finite field . An elliptic curve :

1

satisfies , where G could be chosen as a basic point out of order n. Discrete logarithm problem means that for a known random point P, it is hard to find a that makes Eq. (2) holds.

2

Cross-chain technologies

In the cross-chain system, different users can conduct cross-chain transactions in it, and in the mean time, the process of cross-chain does not change the total value on any blockchain, but only completes the exchange of value between different users in the same blockchain. The cross-chain process can also be considered as a protocol that solves the challenge of how assets and other states on two or even more different chains can be circulated with each other. The existing cross-chain payment methods mainly contains four types: notary schemes, hash-locking, sidechains/relays, and distributed private key control.

1. Notary schemes: The easiest way to implement a cross-chain transaction is to find a third-party currency that both parties in this transaction can operate with. However, in a practical scenario, the exchange rate can be unstable, which could lead to unavoidable value loss. The notary schemes are the perfect treat to this situation. To be specific, in a notary scheme, users in different blockchains communicate with each other through a trusted third-party, all massages and asset need to be transferred to the notary and then forwarded by them. Apparently, the trusted third-party is the moat vital role of this method, and according to the signature algorithm applied by the notary, this approach can be divided into three categories: single-signature notary, multi-signature notary and distributed-signature notary. The notary schemes are flexible and easy to implement, but with the risk of centralization at the same time.

2. Hash-locking: In a real cross-chain transaction procedure, there are always several sub-processes that involve asset transfer. If for some reason, such as network delay, some sub-transactions are completed while others are not, this situation will lead to the loss of property of the user. The easiest way to prevent this from happening is hash-locking, which is shown in Fig. 2. Hash-locking is a method that used hash algorithm, generally in the form of smart contracts, to realize the exchange of resources. This method introduces the concept of time lock, which guarantees atomicity of the asset. Hash-locking cannot be tampered with once it is deployed, however, there is only exchange of information or asset in this method instead of transfer.

3. Sidechains/relays: Sidechain can read the events and status of the main chain as well as being able to verify the information on the blocks of the main chain. In essence, it is another blockchain that independent from the main chain, performing the transfer of assets through bidirectional anchoring technology. When too many transactions on the main chain are waiting to be processed or even worse, performance and safety are at risk, the businesses on the main chain can be transferred to the side chain for processing, thus reducing the pressure on the main chain while achieving the purpose of extending the function and performance of the main chain. Relays can be seen as a kind of sidechain that connects two or more non-communicating heterogeneous or homogeneous blockchains. Sidechain is subordinate to the main chain and mainly focuses on optimizing the scalability of the blockchain; On the other hand, relays have no affiliation and focuses on the data transmission among blockchains. This technology has a high level of security since the main chain cannot be effected even if the sidechain goes wrong, while facing the problem of high complexity and low portability.

4. Distributed private key control: Using multiparty computation and threshold key sharing algorithm²⁵ in relay technology to separate the signing power of the verifiers. This method divides the private keys of authorized accounts into redundant multiple copies and then distributes them to the verifiers, which can prevent a single verifier from unilaterally committing mischief during the cross-chain asset exchange phase since the private key can only be synthesized by a specified number of verifiers. This method enhances the security of other methods.

The comparison between the four methods above can be seen in Table 2.

Figure 2.

Flowchart of hash-locking.

Table 2.

Comparison between different cross-chain methods.

	Notary schemes	Hash-locking	Sidechains/relays	Distributed private key control
One-way asset transfer	Yes	No	Yes	Yes
Risk of centralization	Yes	No	No	No
Implementation	Medium	Easy	Difficult	Difficult
Scalability	Medium	High	Low	Low
Application example	Ripple Interledger1,2	Bitcoin Lightning Network3	Polkadot26	Wanchain27

Problem formulation

System model

The system model of the proposed cross-chain payment method is depicted in Fig. 3. The whole scheme consists of three entities and corresponding clients: initiator, intermediary, and recipient, and two kinds of communication environment: blockchain and network.

Figure 3.

System model.

1. Initiator Client: Transaction originator which exists only in Blockchain I. An initiator client proposes a transaction application to the intermediary client if the user wants to make a transfer to a recipient client.

2. Intermediary Client: A proxy that exists in both Blockchain I and Blockchain II. An initiator client initiates a signature process after receiving a valid transaction application from an initiator client.

3. Recipient Client: Transaction recipient that exists only in Blockchain II. A recipient client initiates a conversation with the intermediary client to apply for payment after receiving a token from the initiator client.

4. Network Environment: All of the clients are able to communicate with each other in the network, which won’t be recorded in blockchain. Meanwhile, network communication is in open channel.

5. Blockchain I/Blockchain II: Two separate P2P network blockchains which allow users communicate on the same blockchain. Meanwhile, on-chain communication will be recorded in blockchain. Data in both blockchains is publicly accessible. Clients software in Blockchain I are installed in two peers: Initiator and intermediary, similarly, clients software in Blockchain II are installed in intermediary and recipient.

Adversary model

As a decentralized public ledger, blockchain promises immutability and traceability instead of privacy and security. To address this issue, we analyze two types of users to define the adversary model.

The first type consists of users who do not directly participate in the transaction. Malicious users in this group typically cannot access the assets involved in the transaction. Instead, they are more likely to attempt to eavesdrop on the messages exchanged between the participants to obtain private information about other users. We define this as Eavesdropping Attack.

The second type includes users directly involved in the transaction, the initiator, the intermediary, and the recipient.

• A malicious initiator might try to claim to have already paid the intermediary without actually doing so or deploy a fake contract to extract the contract’s preimage s. Fortunately, since the content of the hash-locking contract is visible to users, the mechanism itself prevents such issues. The intermediary will only unlock the contract after verifying, ensuring this situation does not occur. If a user exploits vulnerabilities in the smart contract to extract the secret, it would be a more complex issue and beyond the primary scope of this paper.

• A malicious intermediary could attempt to acquire the initiator’s assets without transferring the corresponding assets to the recipient by providing the initiator with a false hash value H(s). Although hash values for hash-locking contracts are generally publicly verifiable, but since the two hash-locking contracts are not on the same blockchain, we have also taken this into account in the adversary model as Forgery Attack.

• The recipient, in most cases, only needs to receive the asset and thus has little incentive to conduct an attack alone. However, a malicious recipient might collude with the intermediary to defraud the initiator’s assets, and we also consider this scenario in the adversary model as Conspiracy Attack.

In summary, the model is exposed to the following risks:

1. Eavesdropping Attack: Assume an attacker tries to steal specific information about the transaction, including transaction amount and transaction time, etc, or the identity information of the traders.

2. Forgery Attack: Assume a malicious intermediary gives the initiator a forge hash value so that he/she can unlock the initiator’s HTLC (hash timelock contract) while no one else can unlock his/hers.

3. Conspiracy Attack: Assume a malicious intermediary tries to conspire with another user m on Blockchain II by giving m the secret s and making m unlock the asset after he/she sends the proof of the HTLC to the initiator.

Design goals

The overall goal of this scheme is to implement the cross-chain transfer between initiator and recipient using intermediary’s identity. Through the mutual communication and transfer between entities in the network or on the blockchain, the flow of equal or differential (intermediary’s agency fee) tokens from initiator to recipient is realized.

The specific goals include: availability, confidentiality, immutability, undeniability, synchronicity and Atomicity.

1. Availability: Cross-chain transactions are feasible using this method.

2. Confidentiality: For any malicious user, the specific information of the transaction and the identity information of both parties are not available.

3. Immutability: It’s unrealistic for anyone to modify the transactions that have completed.

4. Undeniability: None of the entities in the scheme can deny his/her own signature or transaction information.

5. Synchronicity: Once the transaction between initiator client and the intermediary client is written into blockchain by any miner in Blockchain I , the transaction between the intermediary client and the recipient client will be written into blockchain by any miner in Blockchain II.

6. Atomicity: The transaction process either all succeed or all fail, which means there is no intermediate state.

Methods

Overview

After initialization, the initiator is capable of starting a transaction to the recipient through the intermediary, which could be divided into three steps. The steps involving asset transfer are all implemented by hash time lock, all encryption and signature are implemented using ECC algorithm to ensure security. The flowchart of the scheme is shown in Fig. 4.

Figure 4.

Overall flowchart of proposed scheme.

System initialization

In this phase, all users in the system generate their own public key and private key according to the security parameters.

For a chosen curve E(a, b) and a prime number p, generates a finite field and an elliptic curve . Now a user u first choose a base point G of order n, then select a random and calculate Eq. (3).

3

At this point u has generated a key pair with private key and public key . Each user keeps in secret while publicizing and G.

4

5

The parameters used in the scheme are listed in Table 3.

Table 3.

Parameters used in the scheme.

Parameters	Explanation
	Public key of the initiator
	Private key of the initiator
	Public key of the intermediary
	Private key of the intermediary
	Public key of the recipient
	Private key of the recipient
	Encryption algorithm using
	Decryption algorithm using
	Signature algorithm using
	Verification algorithm using

Transaction procedure

Transaction request

The initiator sends a message to the intermediary through the internet, which contains amount of the transaction Amount and identity of the recipient . The details are encrypted with the intermediary’s public key.

6

Generation of hash locks

Since all the asset transfers are accomplished by hash time lock, the whole generation step consists of three parts.

1. After the intermediary decrypts the message to acquire the information Amount, of this transaction, he/she selects a secret number s by random, calculating its hash value H(s), and then deploys a HTLC on Blockchain II using H(s). The HTLC locks the asset equals to the amount of the transaction Amount that the initiator mentioned in transaction request, only the user who is authenticated and capable of providing the correct s can unlock the asset.

   7
2. The intermediary signs the proof of the HTLC using his/her own secret key , then sends the signature and H(s) to the initiator. In this case, the proof of the HTLC is the .

   8

   The initiator now is capable of calculating the hash value of certain parameters to verify the . The whole message is encrypted using the initiator’s public key and broadcast in Blockchain I.

   9
3. The initiator first decrypts the message to obtain , H(s), Address, and .

   10

   Then he/she checks if Eq. (11) holds and then verify the HTLC. If these are all valid, the initiator deploys another HTLC in Blockchain I using H(s), and sends the contract ID to the intermediary. The HTLC locks the asset that the initiator mentioned in transaction request, only the user who can provide the correct s can unlock the asset.

   11

Asset unlocking

Both the HTLCs are locked by H(s), therefore, both the recipient and the intermediary have to unlock the HTLC using the secret number s. The unlocking step also contains transmission of s.

1. Since the secret number s is generated by the intermediary at the first place, it is also for him/her to unlock the first HTLC. Once the intermediary can access the HTLC the initiator generated using , he/she can uses s to unlock the contract and obtain the asset.

2. Now that the first HTLC is unlock, the intermediary gets the asset while the initiator gets the secret s. The initiator next encrypts the secret number s with the recipient’s public key to form a message ,

   12

   signs it with his/her own private key , and then sends the signature to the recipient through the network. Besides, this message is also needed to be broadcast in Blockchain I.

   13
3. The recipient decrypts the message send by the initiator and obtains the secret s, now he/she is capable of accessing the contract deployed by the intermediary using and unlocking it. Only the recipient with specified address can gets the asset locked in HTLC.

   14

Discussion

Now let’s roll back to the asset transfer from A to B. Assume that they just find an user C in both blockchains to help them, all they can do is to trust C, which means there is no mathematical guarantee of this transaction. However, in our scheme above, A and B can totally trust the immutable, verifiable one-way HTLC.

Most solutions to the centralization problem fall into two categories: turn one notary into a group, or no notary at all. Hash-locking is a simple but classic example for the latter. Notary group^5,6 usually apply signatures or key sharing method to realize decentralization, which leads to the increase in computational complexity while enhancing security. In this paper, we found another way to solve centralization without extra cost: using the immutability of HTLC to prevent a malicious notary.

Moreover, for the six design goals we raised in problem formulation, we can now analyze them individually based on the proposed scheme.

1. Availability: The comprehensive procedure and experimental results demonstrate the availability of our scheme in real applications. The process design described above ensures that the scheme is functional in lightweight cross-chain transaction scenarios, addressing common challenges such as independence and compatibility between different blockchain networks.

2. Confidentiality: Ensuring confidentiality is a critical aspect of our scheme, particularly with sensitive transaction data. By employing the ECC encryption algorithm, the scheme protects transaction details from unauthorized access. This has been listed within the adversary model and will be thoroughly analyzed in detail in the next section.

3. Immutability: As our scheme is designed for cross-chain scenarios, all communications between users are broadcast and permanently recorded on blockchains. The immutable nature of blockchain makes it impossible for anyone to alter completed transactions.

4. Undeniability: Since all broadcast messages include the identities and signatures of the users involved, every transaction record is fully traceable. As a result, no entity can deny their participation or actions in the transactions.

5. Synchronicity: The transaction phase involves two hash-locking contracts. Once the intermediary unlocks the second contract, the recipient will inevitably unlock the first one. If an issue arises, no assets in either hash-locking contract will be transferred. Furthermore, transaction proofs are only submitted to the blockchain’s buffer pool after the entire transaction process has been successfully completed. Once submitted, these proofs are guaranteed to be uploaded to the blockchain, thereby ensuring synchronicity.

6. Atomicity: The dual hash-locking mechanism ensures atomicity. The unlocking of one hash lock directly triggers the unlocking of the other. If either fails, the assets in both locks remain untransferred, preserving the integrity of the transaction.

There are also certainly areas where our scheme can continue to be improved and extended. We summarize the limitations of our scheme and future work in the following three aspects:

1. Our scheme process introduces only one notary (intermediary), which may lead to certain limitations in the way transactions are conducted. In traditional notary schemes, a single-signature notary can be extended to a multi-signature or distributed-signature notary. Although this approach aims to address the centralization issue, our proposed scheme has already resolved this problem using hash-locking technology. However, in certain scenarios, such as when the initiator needs to conduct multiple transactions simultaneously or when the transaction amount is too large for a single asset transfer, the single intermediary in the model can also be extended to a multi-signature or distributed-signature approach. Future exploration and research can be conducted in this direction.

2. Our scheme is based on notary schemes and hash-locking. While hash-locking is a simple and efficient foundational method for cross-chain transactions, it does have certain limitations, such as compatibility requirements (in terms of hash algorithms, programmable functionalities, etc.), which are also reflected in our scheme. However, hash-locking technology has been evolving alongside blockchain development, from the HTLC to more advanced iterations like HTLA and HTLR, with improvements in scalability and other performance aspects. In our experiments, we utilized the relatively basic HTLC, but there will be more advanced hash-locking techniques available. Future research can explore and compare these different hash-locking technologies to enhance our scheme.

3. Due to equipment limitations, the experiments in this study could not simulate a complete blockchain network or scenarios where all transaction nodes operate simultaneously. Therefore, we focused solely on calculating the gas consumption of each function and compared the results with some existing schemes. In the future, with more advanced experimental environments, we aim to simulate transaction processes within a complete blockchain network to evaluate performance metrics such as throughput and latency. Additionally, we observed that while the gas consumption of our generation function is significantly lower than that of other schemes, the withdraw and refund functions consume more gas compared to their counterparts. Although our total gas consumption outperforms other methods, further analysis and optimization of these functions remain a potential direction for improvement.

4. Our scheme is lightweight, suitable for a small application scenario, which means it would be hard to be applied to a complex environment. To address this problem, we propose two different solutions.

   1. One is to introduce the concept of a notary center. In this model, notaries act as service providers who can select transaction requests published by users in need of cross-chain asset transfers. Similarly, users are empowered to choose a notary based on their reputation, reliability, and past performance metrics. The reputation system plays a crucial role in ensuring trust and accountability, as it allows users to evaluate notaries based on feedback from previous transactions. This creates a competitive environment where notaries are incentivized to maintain high standards of service to attract more users. Additionally, mechanisms such as rating systems, audits, or blockchain-based proof-of-performance records could further enhance transparency and trust in this decentralized notary selection process. Since the credibility of notary center is significantly higher than that of individual users, this approach can substantially increase the number and volume of transactions. It will also greatly increase the number of initiators and recipients who choose to conduct transactions through a trusted center.
   2. The other is to add other roles or technologies to the scheme. For example, Sprite channels are an improved payment channel technology that enhances the efficiency and flexibility of transactions. Traditional transactions require both parties to be online to complete fund settlements, but Sprite channels address this limitation by introducing relay nodes. The Primitive Manager (PM) is a tool or mechanism for managing cross-chain transactions, responsible for coordinating and executing operations between blockchains. PM can be regarded as an arbitrator for HTLC, delegating the contract expiration decision of any single node to the corresponding software, preventing participants from going offline and losing funds. These two technologies can work in collaboration, complementing each other. Observers in the Geo protocol are auxiliary nodes that do not directly participate in transaction processing but act as third-party nodes to monitor and record transactions and state changes within the network. Similar roles can be introduced into our scheme, serving as regulators and record keepers. They can respond promptly to issues and penalize malicious nodes. These technologies and roles can enhance the security, transparency, and consistency of transactions, making our scheme more reliable and better suited for large-scale applications.

Hash timelock contract

The transaction procedure is based on the generation and release of HTLC, in which asset can only be transferred. A whole contract could be divided into three parts: generation, withdraw and refund.

1. Generation. To generate a HTLC, the user need to provide the address of the receiver, a hash value and a time lock. Once the contract is deployed, all the parameters will be immutable. Every deployed contract has a unique conID, which can be used to identify and access contracts.

   Algorithm 1.

   

   newContract (receiver, hashlock, timelock)

2. Withdraw. After a HTLC is deployed, the receiver with the correct s (preimage of the hash lock) will be able to withdraw the asset locked in the HTLC. Only the specified receiver who is defined in the contract has the authority to unlock it.

   Algorithm 2.

   

   withdraw (conID, preimage)

3. Refund. If the HTLC hasn’t been unlocked when the time lock passed, the generator of the HTLC will be able to refund the asset. The refund process also needs the correct s.

   Algorithm 3.

   

   refund (conID)

Results and analysis

To evaluate the scheme we proposed, we implemented the contract in Solidity 0.8.18 using Remix. The system configuration is Windows 10, 64 bits, 2.90 GHz Intel(R) Core(TM) i7-10700 CPU with 16GB RAM.

Performance analysis

We deployed the smart contract on Remix VM, which allows us to generate contracts and operate on asset. The results are about gas consumption of the main functions in different code environment.

As is known to all, the gas cost in one transaction consists of many items, for example, execution of the code, transaction fee, or tips to the miner. In this section, since the other items are uncontrollable, we only discuss the execution cost. Considering real-world scenarios, each invocation may involve different conditions. For example, if a user provides an incorrect preimage s when attempting to unlock a contract, the unlocking process will include an additional hash computation compared to the normal flow. Since it is impractical to account for all possible situations in our experiments, we introduced two test functions to ensure that our results are not overly simplistic. We tested the execution cost of the whole contract, the Generation function, the Withdraw function and the Refund function under four different conditions.

During the test, we notice that as the code changes, so does the gas consumption of a certain function even though it is not included in the changed part. In this case, we created four different conditions with two test functions: getHash() and getTime(), while the former one is applied to calculate hash value and the other is to get the current timestamp. The details of this four conditions are shown in Table 4.

Table 4.

Four test conditions.

	getHash()	getTime()
Test A	Y	N
Test B	Y	Y
Test C	N	Y
Test D	N	N

The gas consumption is shown in Fig. 5.

Figure 5.

Gas consumption.

As the figure shows, the total gas consumption shows a noticeable difference between Test A and Test D, indicating that changes in code structure can significantly impact overall gas usage. Test B, which handles the most operations, consumes the highest amount of gas, while Test D, which handles the least, has the lowest gas consumption. However, overall gas consumption remains relatively stable within the range shown in the figure.

The gas consumption of the generation function is relatively consistent. This function is minimally affected by external factors due to its simple code logic, resulting in negligible variations under different conditions and demonstrating high stability.

The gas consumption of the withdraw function is generally stable, around 65,900, with slight differences across testing environments. Compared to the generation function, the withdraw function shows a higher variation in gas consumption, though the differences are within 45 units. This indicates that the algorithm is stable and reliable.

The gas consumption pattern for the refund function is similar to that of the withdraw function, with identical trends in the bar chart. Test A and Test D exhibit the same consumption, Test B is slightly lower, and Test C has the highest consumption. This similarity may be attributed to the fact that both functions involve the transfer of assets, resulting in comparable logic at the structural level. Overall, the refund algorithm also demonstrates stable performance.

In summary, these results suggest that gas consumption is primarily influenced by the code structure and the complexity of the algorithm’s functionality. More complex functions that handle larger amounts of data naturally incur higher gas costs. At the same time, the minimal variation in gas consumption across different test conditions highlights the proposed scheme’s efficiency, stability, and consistency.

We also compare the gas consumption of several existing schemes with ours and present the results in Table 5. AMHL²⁸, MAD-HTLC²¹ and ASBRS²⁹ are all based on hash-locking and have similar structures to our scheme, thus making them comparable. Unavailable data is denoted by N/A. For values with multiple outcomes, we take the average value for comparison.

Table 5.

Gas consumption comparison.

schemes	Generation	Withdraw	Refund
AMHL28	350,849	N/A	N/A
MAD-HTLC21	600,000	52,405	N/A
ASBRS29	500,000	58,000	21,000
DeCoTa	122,628	65,903	38,607

As shown in Table 5, the gas consumption of the Generation function in our proposed scheme is significantly lower than that of the other three schemes. While the Withdraw and Refund functions consume slightly more gas compared to the alternatives, in practical scenarios, each contract requires at most one invocation of the withdrawal or refund function. Consequently, the overall gas consumption of our scheme should be substantially lower than that of the other schemes.

Security analysis

We raised three attacks in Adversary Model, which will be analyzed next.

Proposition 1

Our scheme is capable of resisting eavesdropping attack if it is hard to solve the discrete logarithm problem and the hash function is weak-collision-resistant.

Proof

Assume a malicious M in blockchain I eavesdropped on a message, e.g., in Eq. (6), and attempts to extract valid content from this message. Since M is in the same environment as the transaction parties, he/she can easily acquire all of other users’ public key. Now this message is encrypted using the intermediary’s public key , suppose that M would obtain Amount and using by Eq. (15),

15

then this indicates Eq. (16) holds,

16

which means M is able to calculate from the public keys of other users, especially the intermediary’s public key . It is already know that there exist a G in curve E that satisfy Eq. (17) where it is impossible to calculate by in polynomial time,

17

in this case, if the malicious M have the that satisfy Eq. (16), he/she would have the ability of solving the discrete logarithm problem, which is too hard to be true.

In another situation, the message M eavesdropped was H(s) in the communication between the initiator and the intermediary. In the transfer process, the secret s is the key to unlock the HTLC, which leads to the curiosity of M about s. If M is able to find a parameter that makes Eq. (18) holds, in other words, it is feasible to find another value different from s that equalizes their hash values, then this hash function would not be weak-collision-resistant.

18

Based on the two arguments above, our scheme is capable of resisting eavesdropping attack.

Proposition 2

Our scheme is capable of resisting forgery attack if the hash function is strong-collision-resistant.

Proof

Assume a malicious intermediary M gives the initiator a forge hash value during step 3 in the transaction of the Fig. 3. In a normal transaction procedure, the initiator will deploy a HTLC based on the H(s) sent by the intermediary. Obviously, M is attempting to trick the initiator into deploying the HTLC with the , which will in turn make it unavailable for the initiator to obtain the correct s and for the recipient to obtain the asset locked using s.

Fortunately, the intermediary is acquired to send a proof of the HTLC that he/she deployed in blockchain II. This proof of the contract is a hash value conID of all information about the HTLC, including address of the sender , address of the receiver , transaction amount Amount, hash lock value H(s) and time lock value t.

19

Apart from H(s) generated by the intermediary, all of the above parameters are visible to the initiator, so when the initiator receive the from the intermediary, the first step is to calculate conID and compare it with the real value.

If M manages to deceive the initiator successfully, he/she must ensure that the initiator will reach the same result in Eq. (20) as in Eq. (19),

20

which means, M has to find two different values s and that satisfy Eq. (21). If M indeed succeeds, then the hash function would not be strong-collision-resistant.

21

Thus, our scheme is capable of resisting forgery attack as long as the hash function is strong-collision-resistant.

Proposition 3

Our scheme is capable of resisting conspiracy attack if addresses of users in the blockchain are random and non-repeating.

Proof

Assume a malicious intermediary M attempts to withdraw the asset the initiator locked in the HTLC while preventing the recipient from accessing the asset he/she is entitled to. In order to accomplish this, M has previously made some form of agreement with another user on the blockchain II, e.g., N, with whom M shares the value of s. Therefore, after the initiator has deployed the HTLC, M will first notify N to unlock his/her own HTLC deployed on blockchain II instead of just handing s to the initiator by unlocking his/her HTLC. After the HTLC in blockchain II is unlocked by N, there is nothing that the initiator would be able to do even if he/she finds out about the deception since the HTLC in blockchain I is still under a locking state and the time lock has not passed.

However, in our scheme, a user must be authenticated before withdrawing the assets. The withdraw algorithm requires that the address of the user who withdraws the asset must be the same as the address defined within the contract. Consequently, if M attempts to steal the assets that should belong to the recipient, M must locate a user with the same address as the recipient, which is impossible under the stated conditions. Therefore, our scheme is capable of resisting conspiracy attack.

Conclusion

In this paper, we proposed an improved hash-locking cross-chain transaction scheme involving a notary, implementing one-way transfer of the asset while avoiding centralization in traditional notary schemes. Besides, we tested the gas consumption of each function in our scheme under four different conditions and compared the results with some existing schemes. The experiments demonstrated that our scheme is stable and reliable, and its overall performance surpasses that of other methods. Additionally, we gave a detailed security analysis based on three adversary models, the experiment and analysis showed that our scheme is feasible and secure. Furthermore, we examined the limitations of our approach and proposed strategies for improvement, outlining potential directions for future work.

Author contributions

H.Z. and W.R. conceived the presented idea and developed the theoretical formalisms. H.Z., H.S. and S.C. planned and carried out the experimental realization of our scheme. The manuscript draft was written by H.Z., all authors reviewed the manuscript.

Data availability

The datasets used and/or analysed during the current study are available from the corresponding author on reasonable request.

Declarations

Competing interests

The authors declare no competing interests.