Atomic cross-chain swap based on private key exchange

Atomic Cross-Chain Swap (ACCS) is one important topic in cryptocurrency, where users can securely and trustlessly exchange assets between two different blockchains. However, most known ACCS schemes assume specific scripting functionalities of the underlying blockchains, such as Hash Time Locked Contracts (HTLC). In addition, these schemes are typically only applicable to certain digital signature schemes, like Schnorr or Elliptic Curve Digital Signature Algorithm (ECDSA) signatures. In this paper, we propose a generic ACCS scheme, independent from the underlying blockchains. To the best of our knowledge, this is the first solution of this kind. Our results are as follows. First, we define a formal system model of ACCS. Next, we present a generic ACCS scheme meets our model. This scheme admits atomicity in cross-chain swaps without the need for a Trusted Third Party (TTP) and protects users’ privacy. Finally, by using the Non-Interactive Zero-Knowledge (NIZK) proof protocol as a tool, we instantiate our generic scheme for Elliptic Curve Discrete Logarithm Problem-based (ECDLP-based) signatures. In addition, we implement our scheme, and the experimental results show that our protocol outperforms the existing ACCS schemes, such as the HTLC-based schemes.


Introduction
Atomic cross-chain swap (Herlihy 2018) is used to directly exchange assets between two different blockchains without additional trust assumptions, such as trusted hardware or TTP.In ACCS, user A holds asset x on blockchain B 1 , while user B holds asset y on block- chain B 2 , and both intend to exchange their assets.The main goal of ACCS is to ensure that if the swap is successful, user A receives asset y and user B receives asset x.Otherwise, all assets are refunded to both users.
In recent years, with the maturity of blockchain technology, ACCS has gained much attention.The main reason is that in the early stages of blockchain development, the necessity of interoperability between different blockchains was not considered.Therefore, each blockchain operated in isolation, lacking efficient communication mechanisms, which led to what is commonly known as the "blockchain islands" phenomenon.This makes it difficult to exchange data and assets between different blockchains, thereby hindering the further development of blockchain technology.To address this limitation, ACCS emerged as a solution for achieving interoperability between various blockchains.Its primary goal is to enable the transfer and exchange of data and value across different chains.By implementing ACCS, the "blockchain islands" phenomenon has been effectively broken, promoting the continued progress of blockchain technology.
However, with the application of blockchain technology in various industries, such as financial services (Guo and Liang 2016), healthcare (Agbo et al. 2019), and Internet of Things (IoT) (Reyna et al. 2018), the mere circulation of data and value is no longer sufficient to meet the practical requirements for cross-chain interactions.Realworld application scenarios present additional requirements for ACCS.For example, different enterprises often choose different blockchain platforms based on their industry characteristics.Therefore, they may require that the ACCS scheme can be used on any blockchain platform.Moreover, the cross-chain interaction process often involves sensitive private data.Thus, users or companies typically want to prevent the leakage of sensitive information in ACCS.Finally, for some enterprises with high security requirements, they usually hope to implement ACCS without the need for TTP.These emerging requirements make it meaningful to conduct further research on ACCS.

Related work
Up to now, there were two popular ways to achieve trustless cross-chain swaps.The first approach uses on-chain scripts to simulate a TTP.It admits atomicity in crosschain swaps through the automatic execution of on-chain scripts, such as smart contracts.A seminal early work in this field is the HTLC proposed by TierNolan (2013).Subsequently, in 2016, Poon used HTLC to execute atomic swaps between payment channels in the Lightning Network (Poon and Dryja 2016).Later, in 2018, Herlihy formalized the theory of such ACCS (Herlihy 2018).However, ACCS schemes that rely on on-chain scripts may not be compatible with all blockchain platforms, as they depend on specific functionalities provided by each blockchain script.For example, a HTLC-based ACCS scheme requires that both blockchain scripts must support the same hash function.In addition, due to the fact that on-chain scripts are public, using them may compromise users' privacy (Deshpande and Herlihy 2020;Thyagarajan et al. 2022).
In contrast, the second approach uses cryptographic techniques to simulate a TTP.It is more compatible than the first one and can protect users' privacy.However, it typically relies on more complex cryptographic primitives, such as adaptor signatures (Fournier 2019) or lockable signatures (Thyagarajan and Malavolta 2021).In recent years, the ACCS schemes based on cryptographic techniques have been thoroughly studied, and many practical schemes have been proposed.For example, in 2020, Shlomovits designed a scriptless ACCS scheme (Shlomovits and Leiba 2020), where both players gradually released their private key shares.His scheme protected the users' privacy, but was limited to blockchains utilizing ECDLP-based signatures.In addition, it required a TTP called Provider to enhance system security.Subsequently, in 2021, Thyagarajan proposed lockable signatures (Thyagarajan and Malavolta 2021), and in 2022, he further presented a generic scriptless ACCS based on lockable signatures (Thyagarajan 2022).His protocol enables fair exchange of coins among any currencies, while only requiring the minimal script from the underlying blockchain to verify payments, i.e. the verification of digital signatures.Unfortunately, his protocol does not provide an efficient solution for blockchains that do not support adaptor signatures (Erwig et al. 2021;Hanzlik et al. 2022).
Tumblebit (Heilman et al. 2017), A 2 L (Tairi et al. 2021), and BlindHub (Qin et al. 2023) are atomic swap protocols that use an alternate route.In these protocols, a participant exchanges his coins through an untrusted intermediate party.When multiple swaps occur simultaneously, these protocols guarantee that neither intermediary nor any other participant can link the specific coins being exchanged, thereby protecting user privacy.However, Tumblebit relies on the HTLC scripts of the underlying blockchains, which results in poor compatibility and privacy.A 2 L improved this issue, but a later work (Glaeser  et al. 2022) found that A 2 L 's security model had a gap that allowed key recovery attacks on specific instantiations.Subsequently, Glaeser improved A 2 L and proposed A 2 L + and A 2 L UC (Glaeser et al. 2022).However, neither of them is compatible with systems that lack adaptor signature support.In addition, since BlindHub also relies on adaptor signatures, it faces a similar compatibility issue (Hanzlik et al. 2022).

Challenges of the the previous work
To summarize, the known ACCS solutions have three limitations thus are desirable to overcome the following challenges: -Generality.It means that the ACCS scheme is independent of the underlying blockchain platforms.The main reason for the formation of blockchain islands is that the underlying architecture and data structure of each blockchain are different.For example, Bitcoin uses the Unspent Transaction Output (UTXO) model (Nakamoto 2008), while Ethereum uses the account-based transaction model (Buterin 2013).
The heterogeneity between blockchains leads to the complexity and incompatibility of cross-chain interactions.-Privacy.In ACCS, users' privacy includes: (i) Onchain data privacy (Deshpande and Herlihy 2020).The process of cross-chain swap may leak users' on-chain data.For instance, the utilization of public smart contracts could disclose sensitive information such as transaction amounts or participant identities.(ii) Transaction privacy, which includes transaction unlinkability and transaction indistinguishability.
The former means that adversaries who do not par-ticipate in ACCS cannot associate two cross-chain transactions.For example, HTLC-based ACCS cannot achieve transaction unlinkability, because two cross-chain transactions use the same hash value, which makes it easy for adversaries to infer that they may come from the same user.The latter means that observers who do not participate in ACCS cannot distinguish the cross-chain transactions from standard transactions (Thyagarajan et al. 2022).-Atomicity without TTP.It means that the scheme admits atomicity in cross-chain swaps without relying on a TTP.ACCS can be easily implemented using a TTP.However, introducing TTP contradicts the decentralized nature of blockchain.In addition, TTP may bring additional security threats, such as single point of failure or trust problems.Unfortunately, Zamyatin et al. (2021) pointed out that in the deterministic system model of distributed ledgers, achieving Correct Cross-Chain Communication (CCC) is impossible in asynchronous settings without a TTP.Therefore, one of the technical challenges in this field is to design an ACCS scheme in which the distributed ledger platform, on-chain scripts or cryptographic primitives within the system serve as an implicit TTP, thereby guaranteeing atomicity in cross-chain swaps.
Hence, we raise the following question: "Is it possible to design an ACCS scheme without the above three limitations, namely, to meet generality, privacy and atomicity without TTP?"

Our contribution
In this paper, we focus on designing a generic ACCS scheme without TTP, and give an affirmative answer to the above question.Our contributions are summarized as follows: Model for ACCS.We give a formal system model of ACCS and the corresponding security definitions.Our model is applicable to one-to-one ACCS scenarios on any blockchain.To the best of our knowledge, this is the first work in this field.
Generic Atomic Cross-Chain Swaps Scheme.We present a generic ACCS scheme that solves all abovementioned challenges, namely, generality, privacy and atomicity without TTP.In addition, this scheme has been proven to be secure in our model.We outline the comparison between our scheme and other existing schemes in Table 1.Notably, our scheme is not only applicable to existing blockchain platforms, but can also be adapted to potential future platforms.
New Tool: NIZK for the Correct Commitment of Discrete Logarithm (DL).To show the practicability of our generic scheme, we instantiate it in ECDLP-based blockchains.To achieve this instantiation, we present a NIZK protocol CCNIZK for the correct commitment of DL, which is an effective tool to instantiate our scheme.It is used to verify the correctness of the secret segments released by each player, thereby achieving fair exchange of private key shares.We regard this zero-knowledge proof as an independent property, which may bring other interesting applications.

Technical overview
We briefly review our technical treatments below.
Model for ACCS.In our system model, there are two entities, player P 1 and player P 2 , and we focus on a one- to-one ACCS between these two entities.To ensure the generality of this model, we represent each blockchain as a distributed ledger, independent of the specific The "Security" indicator is used to evaluate whether the scheme provides a security model, security analysis, or security proof.The specific evaluation contents of "Generality", "Privacy" and "Atomicity without TTP" indicators are shown in this section.In addition, unless the scheme indicates that the introduced third party does not need to be trusted, we will treat it as a TTP.Including but not limited to third-party blockchain, trusted execution environment, trusted execution hardware, etc

Schemes
Security Generality Privacy Atomicity without TTP

Ours
blockchain implementation.To better describe the ACCS in the real world, we divide it into five phases: setup, freeze, exchange, complete and timeout.In terms of security, we consider possible security threats from a malicious adversary, and formally define the security of ACCS.Therefore, once our scheme is proven in this model, it means that the scheme is sufficiently secure.Generic Construction of Atomic Cross-Chain Swaps.The technical difficulty in building our generic ACCS scheme lies in solving the three above-mentioned challenges, namely generality, privacy and atomicity without TTP.
To solve the first and second challenges, we move private key exchange off-chain.Our scheme uses cryptographic techniques instead of on-chain scripts, making it independent of the specific blockchain architecture.Specifically, we use a Fair Exchange (FE) protocol to achieve off-chain private key exchange, and utilize Verifiable Timed Signatures (VTS) (Thyagarajan et al. 2020) for asset refund.As a result, the cross-chain transactions generated by our scheme are indistinguishable from the standard one-to-one transactions.
Then, to solve the third challenge, we use the idea of gradual release to achieve fair exchange of private keys.Zamyatin et al. (2021) pointed out the similarity between the ACCS problem and the FE problem (Asokan 1998).Specifically, their properties of effectiveness (Asokan 1998) and timeliness (Zamyatin et al. 2021) are similar, and the fairness (Asokan 1998) in FE is similar to the atomicity (Zamyatin et al. 2021) in ACCS.Therefore, we can regard the atomicity property in ACCS as the fairness property in private key fair exchange.However, unlike the fair exchange of items, in ACCS, the sender does not lose the knowledge of the private key after the swap.Due to the fact that private key represents ownership of asset in blockchain, this will result in both players eventually owning the asset.To solve this problem, we let the players exchange the private key shares rather than the complete private keys.Specifically, we introduce a joint address (Thyagarajan et al. 2022) that is jointly controlled by both players, and each player holds a private key share.Then, they exchange their private key shares fairly to gain ownership of the joint address.
Unfortunately, it has been shown by Cleve (1986) that without a majority of honest parties, it is generally impossible to achieve complete fairness.However, achieving partial fairness (Gordon and Katz 2012) is possible, and gradual release is one of the widely used ideas.It allows both parties to exchange their secrets little by little, where one party can obtain an advantage over the other party, but this advantage is polynomially bounded.Our generic scheme is based on this idea.In our scheme, both players first divide the private key shares into multiple segments, then exchange the commitments of these segments and their corresponding proofs, and finally alternately release each segment.In this way, a player can only have at most one segment advantage over the other player.
Next, we give a high-level overview of our generic scheme.First, both players transfer their assets to joint addresses.To prevent indefinite locking of assets, we introduce a timeout mechanism for refund.Next, using the FE protocol with gradual release, players exchange their private key shares.Finally, they can reconstruct the complete private keys of the joint addresses to transfer assets.In addition, this scheme is proven to be secure in our system model.
New Tool: NIZK for the Correct Commitment of DL.We borrow the idea from Camacho (Camacho 2013) to build a new zero-knowledge proof protocol.Camacho (2013) proposed a short signature exchange without TTP by gradually releasing the blinding factor of the signature.However, his scheme can only achieve bit-by-bit private key exchange.We replace the bit commitment proof in the original protocol with Bulletproofs range proof, enabling it to support segment-by-segment private key share exchange.

Preliminaries
In this section, we review some useful notations and notions.
Notations.For m, n ∈ N , where m < n , [n] repre- sents the set of integers {1, ..., n} , and [m..n] represents the set of integers {m, m + 1, ..., n − 1, n} .Let ∈ N be a security parameter, 1 denotes a unary string with ones, and p represents a prime number with bits.We say that the function negl : N → [0, 1] is negligible in , if for every polynomial q(•) there exists 0 such that ∀ > 0 : negl( ) < 1/q( ) .We use x R ←−X to rep- resent an element x randomly and uniformly chosen from the set X, and use x ← v to represent the vari- able x assigned the value v.We represent a protocol as (output 1 , output 2 ) ← Protocol�P 1 (input 1 ), P 2 (input 2 )� , where P 1 inputs input 1 and obtains output output 1 , and P 2 inputs input 2 and obtains output output 2 .
Let G and G T be two groups with the same prime order p, i.e., p = |G| = |G T | , where G is an additive group and G T is a multiplication group.Let G represents a random generator in G , and Z p represents a ring of integer mod- ule p.The notation Z p \{0} is defined as , where each com- ponent v i represents a value associated with the corre- sponding index i.If the vector contains elements in Z n p , it can also be written as ) .We define l and κ as symbols that satisfy κ = ⌈ l ⌉ .Let θ ∈ Z * p , and the κ-Segmentation of θ refers to dividing θ into κ segments.Each segment has a length of l bits, and if the length is less than l, leading zeros are added.We denote the vector of κ-Segmentation of θ as θ , where θ can be expressed as θ = i∈[κ] θ[i]2 (i−1)l .Addi- tionally, let P(•) represent a formal polynomial with coefficients in Z p , and P[•] represent the vector of its coefficients.If the degree of polynomial P(•) is denoted as

Number theoretic assumptions
Bilinear Maps.Consider the G , G T , p and G defined above, assuming that ECDLP in G and G T is difficult.We define e : G × G → G T as a bilinear map, which satisfies the following properties: there is e(aP, bQ) = e(P, Q) ab .
-Non-degenerate: Let P be the generator of G .
Then, e(P, P) is the generator of G T , which means e(P, P) = 1.-Efficiently computable: Let G be the generator of G , Ĝ and ĜT be groups of size p (p is a prime number of bits), with ê being an efficient algorithm to compute the map.There exists an algorithm BMGen that takes as input 1 , and outputs (p, Ĝ, ĜT , ê, G) .For sim- plicity, we will not distinguish between Ĝ, ĜT , ê and G, G T , e.
Let N ∈ N .The common public parameters of the following assumptions are denoted by we have G i = s i G , where s is randomly chosen from Z * p .
Definition 1 (N-Diffie-Hellman Inversion (N-DHI) Assumption (Mitsunari et al. 2002)).The N-DHI problem is to compute 1 s G given pp .For any Probabilistic Poly- nomial-Time (PPT) adversary A , we say that the N-DHI assumption holds, if we have:

Definition 2 (N-Bilinear Diffie-Hellman Inversion (N-BDHI) Assumption). The N-BDHI problem is to compute e(G, G)
1 s given pp .For any PPT adversary A , we say that the N-BDHI assumption holds, if we have:

Definition 3 (N-Strong Diffie-Hellman (N-SDH)
Assumption (Boneh and Boyen 2008)).The N-SDH problem is to compute (c, 1 s+c G) given pp .For any PPT adversary A , we say that the N-SDH assumption holds, if we have:

Digital signatures schemes
Digital Signatures Scheme.A digital signature scheme DS consists of three algorithms.A key generation algorithm (pk, sk) ← KGen(1 ) takes as input a security parameter 1 , and outputs the public-private key pair (pk, sk) .A signature algorithm σ ← Sign(sk, m) takes as input the private key sk and message m ∈ {0, 1} * , and outputs the signature σ .A verification algorithm 0/1 ← Vf(pk, m, σ ) , outputs 1 if σ is a valid signature for the message m under the public key pk , otherwise it out- puts 0.
Threshold Secret Sharing.A (t, n)-threshold secret sharing scheme TSS of a secret x consists of n shares x 1 , ..., x n .For any set |S| ≥ t + 1 , there exists an efficient algorithm x ← Recon({x i } i∈ [S] ) that takes as input t + 1 of these shares and outputs the secret x.However, if only t or fewer shares are provided, no information about the secret x will be revealed.
Threshold Signatures.The (t, n)-threshold signature scheme Th is used to distribute signatures to a group of n players P 1 , ..., P n , such that any at least t + 1 players can co-generate a signature, while t or fewer players cannot.More formally, a (t, n)-threshold signature scheme Th for a signature scheme � DS = (KGen, Sign, Vf) consists of two parts (Gennaro and Goldfeder 2018): uted key generation protocol takes as input a security parameter 1 , and outputs a public key pk and P i 's private key share sk i to each player P i .The private key shares sk 1 , ..., sk n form a (t, n)-threshold secret shar- ing of the private key sk.
distributed signing protocol takes as public input a message m ∈ {0, 1} * to be signed as well as a private input sk i from each player P i , and outputs a signature σ ∈ {� DS .Sign(sk, m)}.
Notice that Th .ThSign will output a valid signature under the centralized signing protocol DS .Sign .There- fore, the verification algorithm of both Th and DS remains the same, denoted as DS .Vf.Verifiable Timed Signatures.The VTS algorithm (Thyagarajan et al. 2020) is a variant of verifiably encrypted signatures (Boneh et al. 2003;Hanser et al. 2015), designed to decrypt and reveal the signature without TTP.In VTS, the committer generates a timed commitment C for a signature σ of a message m under the public key pk .This commitment C can only be opened after a predefined time T (chosen arbitrarily by the committer).In addi- tion, the committer generates a proof π to prove that C contains a valid signature σ .Its formal definition is as follows: Definition 4 (Verifiable Timed Signatures (Thyagarajan et al. 2020)).A VTS scheme VTS for a signature scheme � DS = (KGen, Sign, Vf) consists of the following four operations:

The model of ACCS
In this section, we give the model and the security definitions of ACCS.

System model
Consider two distributed ledgers represented as B 1 and B 2 .We assume that there are two players, P 1 and P 2 , where P 1 owns asset v 1 on B 1 , and P 2 owns asset v 2 on B 2 , and they want to exchange assets.The players communicate using secure and authenticated channels, where messages are public and sent sequentially.We assume the network to be synchronous, which is widely adopted by blockchain protocols (Garay et al. 2015;Zamani et al. 2018;Kiayias et al. 2017;Luu et al. 2016).
In this model, we use the public key to represent the wallet address and the private key to represent asset ownership.Moreover, a transaction is used to represent the process of transferring assets between addresses.For example, tx(pk, pk ′ , v) denotes the transfer of asset v from the address corresponding to pk to the address cor- responding to pk ′ .A valid transaction must be signed by a private key corresponding to the source address of the asset.
Our system model consists of 8 algorithms and 2 protocols: -pp ← Setup(1 ) .On input a security parameter 1 , the algorithm outputs public parameters pp.-(pk, sk) ← KeyGen(1 ) .On input a security param- eter 1 , the algorithm outputs a public-private key pair (pk, sk). 1) .On input a security parameter 1 , the algorithm outputs a public key pk ′ to each player, and a private output sk ′ i to P i as his private key share.
2 , pk ′ , tx)� .When P 1 inputs a timed param- eter T , a private key share sk ′ 1 , a public key pk ′ and a transaction tx , and P 2 inputs a timed parameter T , a private key share sk ′ 2 , a public key pk ′ and a trans- action tx , the protocol outputs a timed commitment com , which commits to the signature of the transac- tion, and its corresponding proof π to P 1 .It also out- puts a signature σ of the transaction to P 2 .-0/1 ← Verify(pk ′ , tx, com, π) .On input a public key pk ′ , a transaction tx , a timed commitment com and its corresponding proof π , the algorithm outputs 0 to indicate validation failure, and outputs 1 to indicate validation success.-σ ′ ← Freeze(sk, tx ′ ) .On input a private key sk and a transaction tx ′ , the algorithm outputs a signature σ ′ of the transaction.-((sk ′′ 2 ), (sk ′ 1 )) ← Exchange�P 1 (sk ′ 1 ), P 2 (sk ′′ 2 )� .When P 1 and P 2 respectively input their private key shares sk ′ 1 and sk ′′ 2 , the protocol outputs sk ′′ 2 to P 1 and sk ′ 1 to P 2 .-σ ′′ ← Complete(sk ′ 1 , sk ′ 2 , tx ′′ ) .On input private key shares sk ′ 1 and sk ′ 2 , and a transaction tx ′′ , the algo- rithm outputs a signature σ ′′ of the transaction.
-σ ← UnFreeze(com) .On input a timed commit- ment com , the algorithm outputs a signature σ embedded in the commitment.

Security definition
In this section, we discuss the security threats and give the formal security definitions of ACCS.We consider a PPT adversary who corrupts one of the players.The corrupt player can deviate from the protocol in any arbitrary manner, e.g., by sending invalid or inconsistent messages, or aborting interactions.We assume that once a player obtains the private key share of joint address from the other player, he will immediately generate a signature of the swap transaction and publish it on distributed ledger to transfer assets in the joint address.We denote the player's state using a state set state = {0, 1} , where state A = 0 represents a failed swap for player A, meaning that player A does not obtain player B's asset and successfully refund, while state A = 1 represents a successful swap for player A, meaning that player A obtains player B's asset and loses his own asset.We now give the formal security definitions as follows.
Definition 5 (Completeness).The completeness of ACCS guarantees that there exists a negligible function negl( ) , such that when all players execute honestly, the execution result of ACCS is: Intuitively, it means that if both players are honest, then ACCS must end with both players' states being either all 0 or all 1.To better understand this definition, we discuss two situations: timeout and no timeout.Timeout means that a player fails to complete the asset swap within the predefined time.In this case, the completeness requires the states of both players are 0, i.e., state A = 0 ∧ state B = 0 .On the contrary, no timeout means that the players complete the asset swap within the predefined time.In this case, the completeness requires the states of both players are 1, i.e., Definition 6 (Soundness).The soundness of ACCS guarantees that there exists a negligible function negl( ) , such that for all PPT adversaries A and all ∈ N , given the correct public key pk , transaction tx and timed parameter T generated during protocol execution, we have: Intuitively, it means that a PPT adversary A cannot generate a commitment com * and its corresponding proof π * such that they can be successfully verified by the Verify algorithm.However, when using the UnFreeze algorithm to open the commitment after the predefined time, the obtained result is not the correct signature.
Definition 7 (Timed Privacy).We use the symbols ≪ to represent "much less than", and ≫ to represent "much greater than", where b ≪ a implies that the result of a + b is approximately equal to a.In addition, the symbol const 1 represents a constant, specified by the system in the setup phase.We say that an ACCS satisfies timed privacy if both of the following conditions hold: -There exists a negligible function negl( ) such that for all PPT adversaries A with running time t ≪ T − const 1 , all transaction messages m ∈ {0, 1} * and all ∈ N , given the correct public key pk and transaction tx generated during protocol execution, we have: -There exists a negligible function negl( ) such that for all honest players A with running time t ≫ T + const 1 , all transaction messages m ∈ {0, 1} * and all ∈ N , given the correct public key pk , trans- action tx and commitment com generated by the pro- tocol, we have: Intuitively, the former condition implies that a PPT adversary A cannot obtain a valid signature when the running time t is much less than T − const 1 .The latter condition implies that an honest player A will not obtain an invalid signature after running the UnFreeze algo- rithm when the running time t is much greater than T + const 1 .
Definition 8 (Partial Fairness).We define the partial fairness of ACCS through the following experiment.Assuming that the adversary A corrupts player B. Therefore, player A is honest.If A aborts before the end of ACCS, let sk * B [1...i] represents the partial private key share obtained by player A. At this point, we assume that player A will randomly select some elements in the remaining space of size 2 −i as B's tentative private key share, denoted as sk ′ B .Similarly, A will also output the tentative private key share of A, denoted as sk ′ A .We use const 2 to represent a constant, specified by the system in the setup phase.
The partial fairness of ACCS guarantees that there exists a negligible function negl( ) such that for all PPT adver- saries A , we have:

Our generic atomic cross-chain swaps scheme
In this section, first we present a generic scheme for one-to-one atomic swap, which shows the feasibility and be seen as a framework for further optimizations.Second, we explain the entire process of an atomic swap between user A and B as a concrete example.Finally, we prove the security of the scheme in our model.Given the digital signature scheme DS , commitment scheme Com , threshold signatures scheme Th , threshold secret sharing scheme TSS , VTS scheme VTS , range proofs protocol RP and NIZK protocol NIZK , we constructed our generic scheme based on the system model, which consists of 8 algorithms and 2 protocols.The complete generic scheme is shown in Figs. 1 and 2, where the complete Exchange protocol is postponed to Appendix A.

| Pr[sk
Here, we provide an example of the generic construction that considers an atomic swap between two users, namely user A and user B. In this scenario, A owns asset v 1 on B 1 , while B owns asset v 2 on B 2 .To simplify the description, we define that the payment from A to B involves the keys, transactions and signatures with (AB), while the payment from B to A involves the keys, transactions and signatures with (BA).The complete process is postponed to Appendix B.
Theorem 1 Assume the underlying digital signature scheme DS , commitment scheme Com , threshold signatures scheme Th , threshold secret sharing scheme TSS , VTS scheme VTS , range proofs protocol RP and NIZK protocol NIZK are secure, the atomic swap protocol described in Appendix B is secure, and has the properties of completeness, soundness, timed privacy and partial fairness.
The proof is postponed to Appendix C.

NIZK for the correct commitment of DL
In this section, we propose a tool, the NIZK protocol for the correct commitment of DL, to instantiate our generic scheme for ECDLP-based signatures.It is designed to prove that the commitment vector (C i ) i∈[κ] encrypts the κ-Segmentation of θ without revealing any additional knowledge.Here, θ represents the DL of a group element D in the group G .This proof consists of two parts: the segmented range proof, denoted as BulletRP , and the NIZK proof of correct commitment, denoted as CCNIZK .Moreover, since our scheme only involves cross-chain swap between two parties, the zero-knowledge proof protocol does not need the property of non-malleability (Sahai 1999).

Segmentation range proofs
Our construction is based on a slight variation of the Pedersen commitment scheme.Consider a common reference string p is a trapdoor.Here, we require that s contains a factor 2 l .To commit the segment θ[i] at position i using the randomness r i ∈ Z p , we compute ) is realized through a vector formed by the commitment to each segment in position i.This vector is denoted as � . Alternatively, we can express this relationship as � C = Commit(θ[•], � r) .For each commitment C i , we use the Bulletproofs range proof BulletRP to prove that it encrypts a segment with a binary length of l (if the length is less than l, we fill in the Fig. 3 The NIZK protocol CCNIZK leading zeros), indicating that the value of the segment falls within the interval [0, ..., 2 l − 1].

Zero-knowledge proof protocol of correct commitment
In this section, we present a NIZK protocol CCNIZK .Let θ R ←−Z * p .Consider the commitment to the κ -Segmentation of θ .This commitment is denoted as , where r i ∈ Z * p for each i ∈ [κ] .Additionally, D = θ G .CCNIZK is used to prove that each commitment item C i at position i indeed encrypts the i-th item in the κ-Segmentation of θ .Here, θ represents the DL of D, which is denoted as D = θG .This proof enables us to create segmented commitments to the private key share of the joint address, and gradually release each segment of the private key share without revealing any additional knowledge.The complete NIZK protocol CCNIZK is shown in Fig. 3.
For the given θ ∈ Z * p and � , our proof protocol does as follows: (1) The prover computes In this step, the prover obtains a compressed representation of the segmented vector commitment, and removing the randomness.
(2) Using the common reference string CRS and the segmented vector θ[•] , the prover computes , where G 0 = G .This step ensures that once the equation e(D ′ , G) = e(U, G 1 ) holds, it can be proven that r is indeed the accumulation of the randomness in the segmented vector commitments.If r = i∈[κ] r i , it would imply a break in certain assumptions, which is impossible.
• Computes V = W (s)G using the common refer- ence string CRS.
holds, it can be ensured that the coefficients of the polynomial P(•) correspond to the κ-Segmentation of θ (that is, θ = P(2 l )).

Theorem 2
The protocol in Fig. 3 is a NIZK proof that proves the κ-Segments of D's elliptic curve DL correspond to the committed segment vectors in (C i ) i∈ [κ] .This NIZK proof has perfect completeness, computational soundness and perfect zero-knowledge under the assumption of κ -SDH.
The proof is postponed to Appendix D.

Instantiation of the generic construction
To show the practicability of our generic construction, we instantiate it in ECDLP-based blockchains.Specifically, we use the ECDSA signature scheme to instantiate it, where we instantiate DS as ECDSA .In addition, we instantiate each algorithm in the Exchange protocol as follows: First, we employ the Bulletproofs range proof protocol (Bünz et al. 2018) to implement the range proof protocol, resulting in RP being instantiated as BulletRP .Second, we utilize the Pedersen commitment scheme to implement the commitment scheme, leading to Com being instantiated as PedCom .Third, we use the NIZK protocol DLNIZK proposed in (Camenisch and Stadler 1997) to generat the proof π pk .Finally, we use the NIZK protocol CCNIZK described in Sect. to generate the proof π cc .

Extensions
In this section, we propose some possible extensions of our scheme.
Replace the VTS Algorithm with the Verifiable Timed Discrete Logarithm (VTD) Algorithm.To enhance the efficiency of our scheme, we can replace the VTS algorithm with the VTD algorithm (Thyagarajan et al. 2020).In VTD, the committer no longer needs to prove that the signature of the commitment is valid, but only needs to prove that the commitment value is the DL of a known group element in the group, which is a simpler algebraic statement (Thyagarajan et al. 2022).Therefore, the VTD algorithm is more efficient in commitment generation and verification than VTS, which can significantly improve the efficiency in freeze phase.
In our ECDLP-based ACCS scheme, using the VTD algorithm, players can make a commitment to their own private key share associated with the joint address.Specifically, user B generates a commitment com (A) for his private key share sk (AB) B and sends it to user A, while user A generates a commitment com (B) for his private key share sk (BA) A and sends it to user B. After timeout, they can forcibly open the commitment to obtain the other user's private key share.By combining their own private key share with the obtained one, each user can reconstruct the complete private key of the joint address, allowing them to refund their respective assets.
In terms of security, replacing VTS with the VTD algorithm will not compromise the security of our protocol, as both VTS and VTD have the same properties of soundness and privacy (Thyagarajan et al. 2020;Thyagarajan 2022).
Multi-Asset Atomic Swaps.The existing HTLC has functional limitations as it only supports one-to-one asset swaps.However, the current cryptocurrency prices vary greatly, making it more difficult for two exchanges on different blockchains to match.In addition, there are also many users who have a need for multi-asset swaps, such as the exchanges.They hold assets in different blockchains and have different combinations of swap needs.This makes further research on multi-asset ACCS meaningful, where A can exchange his Nakamoto (2008), Buterin (2013) and Litecoin ( 2011) for B's Noether (2014) and Schwartz et al. ( 2014) through a single ACCS.Therefore, we provide two ways to achieve multi-asset ACCS for our scheme, one is to swap assets on the same curve, and the other is to swap assets cross different curves.
• The same curve swaps.First, we consider the case where all coins to be swapped between A and B are on blockchains that use the same elliptic curve. .In this case, we can still use the solution employed in the same curve swaps.However, it's important to note that the parameters of the elliptic curves used for each coin are different, resulting in different generated public key shares even when the same private key share are used.Therefore, it is difficult to verify whether two joint addresses are generated by the same private key share.To deal with this challenge, we introduce an additional zero-knowledge proof to prove that different public key shares on different curves have the same DL (i.e., private key share), thereby ensuring the correctness of the generated joint address.This proof can be implemented using NIZK proof mechanism proposed in Noether (2018) or Chase et al. (2022).

Experimental analysis
In this section, we evaluate and analyze our scheme through experiments.First, we evaluate the performance of our NIZK protocol.Next, we instantiate our ACCS scheme for ECDLP-based signatures, and compare it with other ACCS schemes.All experiments are run on the Windows 10 Enterprise LTSC operating system, utilizing an Intel Core i5-6200U CPU @ 2.30GHz, with 8GB of memory and a 465GB hard disk capacity.

Performance analysis of NIZK protocol
Implementation details.To evaluate the practical performance of our NIZK protocol CCNIZK , we give a reference implementation of python language.It relies on the ecpy library (Midorikawa 2019) for elliptic curve related operations, and the sympy library (Smith 2023) for scientific calculations.The code runs on the elliptic curve secp256k1, which is also used in Bitcoin.The experimental results show that segment lengths longer than 50 bits have no significant impact on the experimental results, so we set the segment length in the range of 1 bit to 50 bits.We measure the average time of over 1000 runs and report our results in milliseconds.Time costs and communication costs.We evaluate the time costs of the proof phase and verification phase of the NIZK protocol under different segment lengths, considering both cases of 256-bit and 128-bit private keys.Our experimental results are shown in Fig. 4. The results show that in the case of a 128-bit private key, the running time of the proof phase does not exceed 1100 ms, and the verification phase can be completed within 50 ms.In the case of a 256-bit private key, the running time of the proof phase does not exceed 2300 ms, and the verification phase can be completed within 80 ms.
In addition, we also calculate the communication cost of our protocol.We measure the communication cost as the amount of information that each party needs to exchange during protocol execution, which in our protocol is the size of the proof π cc .Specifically, it includes an element on Z * p and two elements on G .When we set the elliptic curve to the secp256k1 curve with a 256-bit group order, the experimental results show that the communication cost of our protocol is approximately 160 bytes.
Comparison.Compared with the original protocol proposed by Camacho (Camacho 2013), for the proof phase, our protocol can reduce the time cost by up to about 91.62% (set 128-bit private key and 50-bit segment length) and 94.56% (set 256-bit private key and 50-bit segment length).For the verification phase, our protocol can reduce the time cost by up to about 76.28% (set 128bit private key and 45-bit segment length) and 86.44% (set 256-bit private key and 50-bit segment length).In addition, the communication costs of the two protocols are similar.It can be seen that our NIZK protocol greatly reduces the time cost without increasing the communication cost of the original protocol.

Comparison with other schemes
(1) On-chain costs Implementation details.According to Hanzlik et al. ( 2022), a typical metric to measure on-chain costs is to evaluate the transaction fees associated with all transactions that appear on-chain in the protocol.Therefore, we define on-chain execution costs measured in USD1 as the amount of Ethereum transaction fees required to execute each operation: create, redeem and refund.The create operation represents the process of creating an HTLC contract or generating a joint address and depositing assets into it.The redeem operation represents the transfer process of assets in the case of successful swap, and the refund operation represents the transfer process of assets in the case of timeout.We implement and execute our ACCS scheme designed for ECDLP-based signatures on the Ethereum platform, and calculate the gas cost for each operation and an ACCS (including two create operations and two redeem operations).For each experimental result, we conduct 100 tests and take the average.
The gas costs of three operations for different scheme are shown in Fig. 5, and the gas costs of an ACCS are shown in Fig. 6.The experimental results show that compared with other schemes, our scheme reduces the gas costs by approximately 84.37% to 96.67% in the create operation.In the redeem operation, our scheme reduces gas costs by approximately 39.54% to 77.17%.In the refund operation, our scheme can reduce gas costs by up to approximately 63.83%.When performing an ACCS, compared with other schemes, our scheme reduces gas costs by approximately 77.91% to 94.17%.This is because our ACCS scheme requires only a standard ETH transfer between two players, which is a basic inexpensive operation in Ethereum.However, HTLC implementations often require significant gas costs to perform the create operation.Therefore, compared to existing schemes, the on-chain gas costs of our scheme are very low.
(2) Off-chain costs Implementation details.Li et al. (2022) showed that the time costs of ACCS can be roughly divided into onchain transaction confirmation time and other time overhead of off-chain protocol execution.Since transaction confirmation time is specific to the blockchain platform used, we only consider the off-chain time costs.According to Heilman et al. (2017), we calculate the off-chain time costs of our scheme without considering network latency.We use the libsecp256k1 library (Poelstra 2018) to implement bulletproofs range proofs, and the liblhtlp library (Bhat 2020) to implement the VTS scheme.All experimental results are averages of 1000 runs, and we report the results in seconds.
Time costs of Exchange phase.We evaluate the off-chain time cost of the Exchange phase under different segment lengths, considering both cases of 256-bit and 128bit private keys.Our experimental results are shown in Fig. 7.The results show that when the private key length is 128 bits, the off-chain time cost in the Exchange phase does not exceed 2.7 s.When the private key length is 256 bits, the off-chain time cost does not exceed 5.3 s.
Comparison I.In the case of a 256-bit private key, we compare the off-chain time costs of our scheme with other schemes in the Exchange phase.Such as, Li's ZeroCross scheme (Li et al. 2022) (denoted as LWL22-I and LWL22-II), Chen's scheme (Chen et al. 2023) (denoted as CYS23), Qin's Blindhub scheme and its optimized scheme (Qin et al. 2023) (denoted as QPM23-I and QPM23-II), Tairi's A 2 L scheme (Tairi et al. 2021)  (denoted as TMM21), and Hanzlik's Sweep-UC scheme (Hanzlik et al. 2022) (denoted as HLT22).Our experimental results are shown in Fig. 8.The results show that the average time cost of our scheme in the Exchange phase is better than other schemes.
Time costs of an ACCS.In the case of a 256-bit private key, we calculate the time costs of our scheme to execute an ACCS.The average off-chain time cost of our scheme is 16.85 s, which has no significant impact on the efficiency of ACCS according to (Li et al. 2022).Because compared with the on-chain transaction confirmation time2 , the off-chain time cost of our scheme is very low.Therefore, its impact on the existing system is very small.
Comparison II.In the case of a 256-bit length private key, we compare the off-chain time costs of our scheme with other schemes in executing an ACCS.Such as, Qin's Blindhub scheme and its optimized scheme (Qin et al. 2023) (denoted as QPM23-I and QPM23-II), Zamyatin's XCLAIM scheme (Zamyatin et al. 2019) (denoted as ZHL19), and Hanzlik's Sweep-UC scheme (Hanzlik et al. 2022) (denoted as HLT22).Our experimental results are shown in Table 2.The results show that the off-chain time cost of our scheme is as practical as other schemes.
(3) Experimental conclusion In summary, although ACCS functionality is easy to be implemented using smart contracts such as HTLC, our protocol is preferable due to its advantages, such as lower on-chain overhead, and practical off-chain time costs similar to other schemes.

Conclusion
In this paper, we propose a generic ACCS scheme, independent from the underlying blockchains.To the best of our knowledge, this is the first solution of this kind.Our results are as follows.First, we define a formal system model of ACCS.Next, we present a generic ACCS scheme meets our model.This scheme admits atomicity in cross-chain swaps without the need for a TTP and protects users' privacy.Finally, by using the NIZK protocol as a tool, we instantiate our generic scheme for ECDLP-based signatures.In addition, we implement our scheme, and the experimental results show that our protocol outperforms the existing ACCS schemes, such as the HTLC-based schemes.However, although our research provides some insights into the field of ACCS, we must also acknowledge the limitations and unresolved issues of this research.Therefore, we propose some possible future work here.On the one hand, we will further improve the efficiency of our scheme in the future.The current scheme can meet the requirements of generality, privacy, and atomicity without TTP at the same time.However, there is still room for improvement in efficiency of our scheme.In the future, we will explore more effective cross-chain protocols to improve the real-time nature of transactions.On the other hand, we will expand the cross-chain functionality of the scheme in the future.Our scheme is mainly applicable to ACCS, however, the transfer of assets and data between different chains is also a common application scenario.Here, we take ACCS as a starting point, and in our future work, we will further study solutions that can achieve other cross-chain functions to meet the constantly evolving market demand.
In a word, we believe these future works will contribute to the development of the blockchain and cryptocurrency fields.We encourage more researchers to participate in this field to unlock its potential value and promote its further development.

Appendix A Exchange protocol
The Exchange protocol consists of 6 algorithms.
-sk 1 [•] ← DivideSegment(sk 1 , l, κ) .Given a private key share sk 1 , the algorithm divides it into κ seg- ments, denoted as sk 1 ) .Each segment's length is l bits (with leading zeros added if the length is less than l).
. Given κ-Segmentation of sk 1 , the algorithm outputs a commitment vector com for each segment in sk 1 [•] , its corresponding range proofs (π rpi ) i∈[κ] , a correct commitment proof π cc , and a Zero-Knowledge Proof of Knowledge (ZKPoK) for the private key share sk 1 , denoted as π pk .Specifically, the algorithm does the following: to generate commitment com i for the i-th seg- ment of the private key share.Next, it runs π rpi ← � RP .Proof(com i ) to generate a range proof π rpi for the i-th commitment.This range proof is used to verify that the commitment com i encrypts a segment with a binary length of l (if the length is less than l, leading zeros are filled).com) to generate a proof of correct commitment.This proof is used to verify that each commitment item com i at position i indeed encrypts the i-th item in the κ -Segmentation of sk 1 .3. Runs π pk ← � NIZK .Proof(sk 1 ) to generate a ZKPoK for sk 1 , where sk 1 is the correct private key share corresponding to the public key.4. Takes (� r, � com, (π rpi ) i∈[κ] , π cc , π pk ) as the output.
-(sk 1 [i], r i ) ← SegComOpen(sk 1 , � r, i) .Given a pri- vate key share sk 1 , a random value vector r , and the index i of the commitment to be opened, the algorithm outputs the opening value (sk Given a public value h of the commitment, the i-th segment of a private key share, a commitment com , and a corresponding open- ing value (sk mentation, the algorithm outputs sk 1 .
1.No timeout.Assuming that both users participating in ACCS follow the protocol, in the case of no timeout, they freeze their assets to the joint addresses and successfully exchange their private key shares.Therefore, they can sign the swap transactions and publish the signatures to swap their assets.This results in both users' states being 1 at the end of the protocol, i.e., state A = 1 ∧ state B = 1. 2. Timeout.Assuming that both users participating in ACCS follow the protocol, the timeout is usually caused by one user being offline, resulting in the failure of the Exchange protocol.In the case of timeout, users will be unable to reconstruct the complete private key corresponding to the joint address.Consequently, they will not execute the complete phase but execute the unfreeze phase to obtain the signature of the refund transaction, and then publish it for refund.This results in both users' states being 0 at the end of the protocol, i.e., state A = 0 ∧ state B = 0. can pass the ComProofCheck and SegComCheck algorithms.This implies that the adversary has broken the soundness property of the underlying zeroknowledge proof module RP and/or NIZK , and/ or the binding property of the underlying commitment scheme module Com .

Appendix D Proof of Theorem 2
Before proceeding with formal proof, we first emphasize the role of range proofs, which use Bulletproofs for efficient instantiation.To intuitively understand the reasons behind this, first we describe a possible attack.Subsequently, we will explain why Bulletproofs range proofs can effectively resist such attack.The zero-knowledge proof protocol of correct commitment proves that C i encrypts θ[i] , such that P(2 l ) = i∈[κ] θ [i]2 l(i−1) = θ , where θ is the DL of D. However, this alone does not guarantee the correctness of the protocol, as there exists a simple attack that involves generating commitments for shifted segments, such that C i encrypts plaintext that shifts θ[i] .In this attack, the final sum of plaintext remains the same, i.e., θ , but each C i will be opened incorrectly.Specifically, the meaning of this attack is that if the malicious user A aborts during the gradual release of secret segments, then the honest user B will have nothing, while A will have all the correct secret segments that have already been released by B.
We use an example to illustrate the harm of this attack.Assuming that the adversary only changes two secret segments, namely the i-th segment and the i + 1 -th segment However, this attack can be avoided with a high probability by generating Bulletproofs range proof for commitment C i .Next, we show how Bulletproofs range proofs prevent this specific attack, and extend it to all possible changes to the encrypted segments θ [•] .There are four cases of this attack: For the latter three cases, there is a high probability that at least one Bulletproofs range proof cannot be verified.In the first case, in order to pass the verification of the zero-knowledge proof protocol of correct commitment, it is necessary to satisfy Computational Soundness.We assume that the one who breaks the soundness of the protocol is the PPT adversary A , and B is an adversary we built.B receives (G 0 , G 1 , G 2 , ..., G κ ) and uses this tuple as the CRS , then sends it to A .A returns the following values: The proof is divided into two steps.First we assume that r = i∈[κ] r i mod p .In this case, we can deduce that ) can be easily computed, thus breaking the κ-DHI assumption.
Next, we assume that i∈[κ] r i = r .When the verifi- cation of V passes, it implies that we have V = i∈[κ] (θ[i]s i−1 −θ * [i]2 l(i−1) ) s−2 l G .If the adversary A wins, it means that there exists some j ∈ [κ] such that θ [j] � = θ * [j] .Further analysis reveals that Bulletproofs T) : This randomized commit algorithm takes as input a signature σ (generated using � DS .Sign(sk, m) ) and a hiding time T , and outputs a commitment C and a proof π. -0/1 ← Verify(pk, m, C, π) : This verify algorithm takes as input a public key pk , a message m, a com- mitment C of hardness T and a proof π .It outputs 1 if and only if the value σ embedded in C satisfies � DS .Vf(pk, m, σ ) = 1 , otherwise it outputs 0. -(σ , r) ← Open(C) : This open algorithm is run by the committer, takes as input a commitment C, and outputs the committed signature σ and the randomness r used in generating C. -σ ← ForceOp(C) : This force open algorithm takes as input a commitment C, and outputs the committed signature σ.Commitment schemes A commitment scheme Com consists of three algorithms.A generation algorithm h ← Gen(1 ) takes as input a security parameter 1 , and outputs a public value h.A commit algorithm (c, d) ← Com(h, m) takes as input a public value h and a message m ∈ {0, 1} * , and outputs a commitment c and an opening value d.A verification algorithm 0/1 ← Vf(h, m, c, d) , outputs 1 if the verifica- tion succeeds, otherwise, it outputs 0.

Fig. 1
Fig.1Generic atomic cross-chain swaps scheme -Part I 2 Note: In the practical application of the system model, variables are usually defined to represent various parameters and are initially set to default values, such as 0, and then assigned to the actual values of specific parameters at runtime.To simplify the representation, the variables are directly assigned values in the Setup algorithm

Fig. 5
Fig. 5 Gas costs of three operations for different schemes

Fig. 7
Fig. 7 Time costs of Exchange phase

Table 1
Comparison with existing schemes 1 That is, all coins of A are on blockchains that use the elliptic curve cyclic group G 1 , with generator G 1 and prime order value p 1 .And all coins of B are on blockchains that use the elliptic curve cyclic group G 2 , with generator G 2 and prime order value p 2 .Cross-curve swaps.Next, we consider the case where all coins to be swapped between user A and user B are on blockchains that use different elliptic curves.Specifically, all coins of A are on blockchains that use the elliptic curve cyclic groups (G 1i ) i∈[n] , with gen- erators (G 1i ) i∈[n]and prime order values (p 1i ) i∈[n].All coins of B are on blockchains that use the elliptic curve cyclic groups (G 2i ) i∈[ n] , with generators (G 2i ) i∈[ n]and prime order values (p 2i ) i∈[ n]

Table 2
Time costs of an ACCS for different schemes