P2DEX: Privacy-Preserving Decentralized Cryptocurrency Exchange

. Cryptocurrency exchange services are either trusted central entities that have been routinely hacked (losing over 8 billion USD), or decentralized services that make all orders public before they are settled. The latter allows market participants to “front run” each other, an illegal operation in most jurisdictions. We extend the “Insured MPC” approach of Baum et al. (FC 2020) to construct an eﬃcient universally composable privacy preserving decentralized exchange where a set of servers run private cross-chain exchange order matching in an outsourced manner, while being ﬁnancially incentivised to behave honestly. Our protocol allows for exchanging assets over multiple public ledgers, given that users have access to a ledger that supports standard public smart contracts. If parties behave honestly, the on-chain complexity of our construction is as low as that of performing the transactions necessary for a centralized exchange. In case malicious behavior is detected, users are automatically refunded by malicious servers at low cost. Thus, an actively corrupted majority can only mount a denial-of-service attack that makes exchanges fail, in which case the servers are publicly identiﬁed and punished, while honest clients do not to lose their funds. For the ﬁrst time in this line of research, we report experimental results on the MPC building block, showing the approach is eﬃcient enough to be used in practice.


Introduction
Decentralized cryptocurrencies based on permissionless ledgers such as Bitcoin [53] allow for users to perform financial transactions without relying on central au-thorities.However, exchanging coins among different decentralized cryptocurrency platforms still mainly rely on centralized exchange services which must hold tokens during the exchange process, making them vulnerable to theft.Centralized exchange hacks have resulted in over 8 Billions dollars' worth of tokens being stolen [55], out of which over 250 Million dollars' worth of tokens were stolen in 2019 alone [56] .The main alternative is to use decentralized exchange services (e.g.[14,42,57] ) that do not hold tokens during the exchange process but are vulnerable to front-running attacks, since they make all orders public before they are finalized.This allows for illegal market manipulation, for example by leveraging the discrepancy between the most extreme buying and selling prices to buy tokens at the smallest offered price and immediately selling them at the highest accepted price.
Given the astounding volume of financial losses from centralized exchange hacks, constructing alternatives that are not vulnerable to token theft is clearly of great importance.However, ensuring that exchange orders remain private and avoiding front-running has also been identified as a chief concern [31,11], since this vulnerability reduces user trust and rules out regulatory compliance.In essence, a solution is needed for reconciling order privacy, market fairness and token security.In this work, we address the question: Can we securely & efficiently exchange cryptocurrency tokens while preserving order privacy, avoiding front-running and ensuring users never lose tokens?

Our Contributions
We introduce universally composable privacy preserving decentralized exchanges immune to token theft and front-running, as well as optimizations to make our approach feasible in practice.Our main contributions are summarized as follows: -Privacy: A provably secure privacy preserving decentralized exchange protocol, which is immune to both front-running and secret key theft.-Security: An Universally Composable [19] analysis of our protocol, showing our approach is secure in real world settings.-Efficiency: The first experimental results showing that Multiparty Computation on blockchains can be practical (i.e.faster than block finalization).-Incentive: Our protocol incentivizes servers to participate honestly by allowing them to take a commission on all exchanges, while at the same time allow financial penalization of the servers if they behave maliciously.-Usability: An architecture that allows for deployment of a decentralizedexchange-as-a-service where users only need to do very lightweight computation and complete a single blockchain transfer in connection with a single round of efficient communication with the servers.
As the main building blocks of our work, we use publicly verifiable secure multiparty computation (MPC) [7] and threshold signatures with identifiable abort [41,40,22].MPC allows for users to compute on private data without revealing this data to each other, which is a central concern in our solution.Moreover, using tools for public verifiability [6], it is possible to prove to any third party that a given computation output has been obtained without revealing inputs, which is paramount for proving validity in decentralized permissionless systems.We use standard (public) smart contracts both for identifying and punishing cheaters through publicly verifiable off-chain protocol transcripts and for guaranteeing the cross-chain exchanges.The idea is to have the funds being exchanged temporarily transferred to addresses controlled by threshold signatures in such a way that all servers must cooperate to sign the transactions finalizing the exchange.If any of the servers refuses to complete the order matching or the signing of a transaction, this malicious behavior can be publicly proven to the smart contract, which takes the collateral deposit from the cheating server to reimburse affected clients.This mechanism allows for exchanges among any cryptocurrencies that allow for distributed transaction generation (in particular through threshold signatures).
Another major concern of our work is proving that our solution has solid security guarantees, since flaws in an exchange protocol can cause funds to be lost.Contrary to popular belief, standard techniques for proving security of cryptographic schemes only show that schemes remain secure if they are always executed by themselves, without interacting with other protocols or systems.Instead, we analyse our solution in the Universal Composability framework [19], which guarantees security even in complicated situations where multiple protocols are executed concurrently with each other (i.e.real world scenarios as the Internet or decentralized cryptocurrency systems).
If parties do not cheat, our protocol requires no on-chain communication except for the transactions needed to perform the exchanges and uses MPC only for privately matching orders (to avoid front-running).We prove security against an actively dishonest majority and argue how clients can be refunded in case of malicious behaviour by up to n−1 servers.We analyse our solution in the Universal Composability (UC) framework [19], which guarantees security even in complex situations where multiple protocols are executed concurrently with each other (i.e.real world scenarios as the Internet or decentralized cryptocurrency systems).To that end, we introduce a treatment of decentralized exchanges in the UC framework, allowing us to prove that our protocol is secure even in these realistic scenarios.

Our Techniques
The protocol in a nutshell: Clients C 1 , . . ., C m wish to exchange tokens between ledgers L a and L b using servers P 1 , . . ., P n that facilitate the privacypreserving exchange.Any number of ledgers can be involved, as long as all parties can use a standard smart contract (e.g.Ethereum) on a ledger L Ex .Moreover, all ledger pairs L a , L b must use cryptocurrency systems that allow for publicly proving that a double spend happened, e.g.Bitcoin UTXOs [53] (which can be emulated by attaching unique IDs to coins in account-based systems like Ethereum).Our protocol works as follows: -Smart Contract Setup: The servers send a collateral deposit to a smart contract on ledger L Ex that guarantees that the servers do not cheat.-Off-chain communication: After setup, only off-chain protocol messages are exchanged between the servers unless cheating happens, in which case cheating servers can be identified by publicly verifiable proofs [6] and punished.-Main Protocol Flow: Performing exchanges between client C i who wants to exchange tokens from ledger L a held at their address Addr src i with tokens from C j who holds tokens in ledger L b at address Addr src j (or any other tuple of users/ledgers/addresses): 1. Burner address setup: The servers set up threshold signature addresses Addr ex i and Addr ex j on each ledger L a and L b from which they can transfer assets only if they all cooperate in threshold signing .2. Private order placement: Clients transfer their tokens to server threshold addresses on each ledger (i.e.clients C i and C j transfer their tokens from addresses Addr src i and Addr src j on ledgers L a and L b to addresses Addr ex i and Addr ex j , respectively) and send to the servers the addresses Addr trg j and Addr trg i on L a and L b where they will receive exchanged tokens if their orders match, respectively.They also send secret shared order information, describing the prices they charge for their tokens in a way that the servers do not learn the prices.3. Confirmation: If the servers have correctly received the secret orders and deposits from all the clients on each ledger, they proceed.Otherwise, they generate and send to the smart contract refund transactions transferring tokens from Addr ex i and Addr ex j back to client addresses Addr src i and Addr src j , respectively.C i and C j retrieve these transactions and post them to L a and L b , respectively.4. Private Matching: The servers execute a publicly verifiable MPC protocol (e.g.[7]) to run any order matching algorithm on secret-shared orders so that they can publicly prove that either a given set of orders have been matched or that a server has cheated, never learning non-matched orders.5. Pay out: Servers publish signed transactions for the final exchange operations to addresses Addr trg j and Addr trg i on L a and L b for matched order pairs to pay out the exchange to the clients.If the servers are charging a fee for the exchange they can similarly post transactions matching their fees from Addr src i and Addr src j to their respective accounts on L a and L b .-Cheating Recovery: The main cheating scenario is that a server sent an invalid message or failed to send a message.In that case, an honest server complains to the smart contract on L Ex and all servers have to send valid protocol messages to complete the protocol to the smart contract.If a server P i does not send a valid message, it is identified as a cheater.-Servers double spent the client C's deposit: C sends the proof of double spending to the smart contract on L Ex , identifying all servers as cheaters.If the proof is valid, the servers are punished and C is reimbursed.Any server P i identified as a cheater loses its deposit to the smart contract, which is used to reimburse the clients and the honest servers for their work.
Security Guarantees: Our main protocol achieves security against an actively dishonest majority of servers without requiring the clients to put up expensive collateral deposits, which is the case in previous approaches (e.g.[7]) where all parties must provide such deposits.Moreover, we describe a modification where even in a catastrophic failure where all servers become corrupted, even though the client's orders may leak, all clients are guaranteed to be refunded by the smart contract.
Efficiency: Unless cheating happens, all communication is off-chain and the only information stored on-chain on any ledger are the transactions necessary to perform the exchange itself (improving on [7]).If cheating happens, the smart contract must identify and punish the cheater, but this cost is covered by the cheater's deposit.Moreover, MPC is only used to match orders in the Private Matching phase, while other operations are executed via efficient off-chain protocols.Finally, we do the first full implementation of the MPC component in a secure computation with financial incentives setting, showing that MPC on blockchains is efficient in practice (in particular for our matching application).
Alternative Approaches: Our protocol can be modified in the following ways: -Preventing Denial-of-Service attacks by Clients: In our outlined protocol, either all clients transfer their money after registration or they all get reimbursed.Then, a client who registers but does not transfer funds could participate in a Denial-of-Service attack.We explain in Section 4.3 how to modify our protocol to avoid this.-Client Collateral: If we also charge collateral deposits from the clients, burner addresses can be generated by the clients instead of the servers (saving on server work).In this case, when the output of the Private Matching is obtained, clients must perform the transfers from their burner addresses to the address given by the recipient of the exchange.In case a cheating client fails to do so, the recipient is reimbursed by the cheater's deposit.The idea is to use a cross-chain exchange mechanism where the goal is not to check that transactions are finalized on different chains, but instead to have parties "promise" to do a transfer to a given address and financially punish double spend attempts (in order to reimburse affected parties).This approach allows us to perform cross-chain swaps between any cryptocurrency that allows for publicly verifiable proofs of double spend with the help of a simple smart contract.
-Incentivizing Servers: Clients may pay fees to servers so that it is profitable to execute a server.This can be achieved in a simple manner as part of the pay out step.Concretely the servers will also post transactions to their respective addresses, from the burner addresses used by the clients during the exchange, instead of only posting a transaction paying out the exchange to the recipient.-Exchange-as-a-Service By letting the servers be responsible for posting the transactions resulting from the private matching, we can achieve a fully decentralized "exchange-as-a-service", where users can rely on only a lightweight web-client and wallet, to request an exchange order, and simply wait it to get carried out (if it gets matched) without staying online.-Guaranteed Success with Honest Majority of Servers: Assuming an honest majority of servers, we can obtain a much more efficient protocol by replacing the MPC protocol [7] used for the Private Matching with a much cheaper honest majority MPC protocol.Moreover, in this case we can achieve guaranteed output delivery, meaning that the privacy preserving exchange always works regardless of the minority of malicious servers.-Resilience under full corruption: Even though we consider a dishonest majority where at least one server is honest, our technique can be modified for the setting where all servers may be corrupted.If users are allowed to register their orders (and destination addresses) on the smart contract, they can prove that all servers have misbehaved and get reimbursed with tokens from the exchange smart contract ledger, similarly to the approach of [37].

Related Work
A line of work on protocols for incentivizing fairness in secure computation using cryptocurrencies is the most closely related to our work.Nevertheless, works on privacy preserving smart contracts and other approaches to decentralized exchanges could also be seen as alternative solutions to the question we address.
In this section, we discuss how these lines of work relate to our solution.
MPC with financial incentives: A feature required by the MPC scheme in our applications is that if a cheating party obtains the output, then all the honest parties should do so as well (so all parties learn matching orders).Protocols which guarantee this are also called fair but known to be impossible to achieve with dishonest majorities [28].Recently, [4,12] initiated a line of research that aims at incentivizing fairness in MPC by imposing cryptocurrency based financial penalties on misbehaving parties.Several works [50,49,13,10,7] improved the performance with respect to on-chain storage and the size of the collateral deposits from each party, while others obtained stronger notions of fairness [46,27].None of these works implemented the MPC component of this approach.Moreover, using MPC for computing on private data in permissioned ledgers has been suggested in [10].
In our work, we rely on such techniques to ensure that servers cannot profit from forcing exchange operations to fail.However, even the state-of-the-art [7] of these works only considers the single blockchain setting (not allowing for exchanges) and suffers from indefeasibly high overheads in both off-chain/on-chain complexity that would make exchange operations infeasible.We address these issues with an MPC protocol that operates on multiple blockchains, but building a decentralized exchange service where we only use MPC for matching orders; then later generating matched order transactions via an efficient threshold signature.We propose concrete improvements on the off-chain/on-chain overhead of [7] with the first concrete implementation of techniques from [6,8].Furthermore, we achieve optimal communication (no more than in centralized exchanges) in the optimistic setting, where no party behaves maliciously.For the first time in this line of work [4,12,3,50,49,51,13,10,7] , we fully implement the MPC component of such a solution showing it is efficient in practice, whereas previous works only focused on on-chain efficiency (which is still optimal in our protocol).
Privacy Preserving Smart Contracts: Another related line of work [15,48,17,45,1] has focused on constructing privacy preserving smart contracts that can be checked for correct execution without revealing private inputs on-chain.However, these are intrinsically unfit for our application because they require a trusted party to learn all private inputs in order to generate zero-knowledge proofs showing that a given computation output was obtained.This would allow a corrupted trusted party (or insecure SGX enclave [16]) to perform front running (or even steal funds), i.e. the same issues of centralized exchanges.Another related approach is the Enigma platform, which first proposed [58] to use MPC with passive security (whereas we prove stronger active security) but actually later implemented [1] a scheme based on SGX trusted execution enclaves, which are known to be insecure [16].
Distributed markets and exchanges: The use of MPC in traditional stock market exchanges has been considered in [52,24,25] but these works focus on matching stock market orders and do not address the issue of ensuring that exchange transactions are performed correctly, which we do.Many commercial decentralized exchange services (e.g.[14]) exist, but they are not private and suffer from front-running as discussed before.A front-running resistant approach is suggested in [11] but it relies on insecure trusted hardware [16] and has no privacy.
Fair Two-Party Data Exchange: Dziembowski et al. [37] showed how to use financial incentives and a proof of cheating to enforce honest behaviour when two parties are exchanging pre-images of a hash function using a distributed ledger.Despite showing security in UC, their approach would not directly be efficient for cross-chain token exchange, nor generalize to exchange order matching.Furthermore, their approach require posting auxiliary information to the ledger, however small, even in the optimistic case.

Notation
Throughout this work, we will denote the set of servers with P = {P 1 , . . ., P n } and the set of corrupted servers with I P. The uncorrupted servers will be I = P \ I.We denote the ideal-world simulator as S. We use τ to denote the computational and κ for the statistical security parameter.Let y $ ← F (x) denote running the randomized algorithm F with input x and implicit randomness, and obtaining the output y. y ← F (x) is used for a deterministic algorithm.For a finite set X , let x $ ← X denote x chosen uniformly at random from X .For k ∈ N we write [k] for {1, . . ., k}.Vectors of elements are denoted by bold lowercase letters and matrices by bold upper-case letters.Concatenation of vectors is represented by .For z ∈ F k (or z ∈ R k ), z[i] denotes the i'th entry of the vector, so that e.g.z[1] is the first element of z.We denote by 0 k the column vector of k components where all entries are 0. We denote the scalar product of a scalar α ∈ F with a vector x ∈ F k by α ).For a matrix M ∈ F n×k , we let M[•, j] denote its j'th column and M[i, •] denote its i'th row.We say a function f (x) is negligible in x (or negl(x) to denote an arbitrary such function) if f (x) is positive and for every positive polynomial p(x) ∈ poly(x) there exists a x ∈ N such that ∀x ≥ x : f (x) < 1/p(x).Two ensembles X = {X κ,z } κ∈N,z∈{0,1} * and Y = {Y κ,z } κ∈N,z∈{0,1} * of binary random variables are said to be statistically indistinguishable, denoted by X ≈ s Y , if for all z it holds that | Pr[D(X κ,z ) = 1] − Pr[D(Y κ,z ) = 1] | is negligible in κ for every probabilistic algorithm (distinguisher) D. In case this only holds for computationally bounded (non-uniform probabilistic polynomial-time (PPT)) distinguishers we say that X and Y are computationally indistinguishable and denote it by ≈ c .We define the common variables used in this paper in Tab. 1 and where relevant subscript will be used to indicate the party for which the variable belong and superscript will be used to indicate a source (src), target (trg) or exchange (ex) context.

(Global) Universal Composability and Verifiability
In this work, the (Global) Universal Composability or (G)UC framework [19,21] is used to analyze security.Due to space constraints, we refer interested readers to the aforementioned works for more details.We generally use F to denote an ideal functionality and Π for a protocol.
Several functionalities in this work allow public verifiability.To model this, we follow the approach of Badertscher et al. [5] and allow the set of verifiers V to be dynamic by adding register and de-register instructions as well as instructions that allow S to obtain the list of registered verifiers.All functionalities with public verifiability include the following interfaces, which can also be used by other functionalities to register as a verifier of a publicly verifiable functionality, and which are omitted henceforth for simplicity: Register: Upon receiving (Register, sid) from some verifier V i , set V = V ∪ V i and return (Registered, sid, V i ) to V i .
Deregister: Upon receiving (Deregister, sid) from some verifier V i , set V = V \ V i and return (Deregistered, sid, V i ) to V i .
Get Registered: Upon receiving (Get-Registered, sid) from the ideal adversary S, the functionality returns (Get-Registered, sid, V) to S.

The Global Clock
As some parts of our work are inherently synchronous, we model the different "rounds" of it using a UC clock functionality F Clock as in [5,46,44].This functionality is assumed to be a global functionality, which means that other ideal functionalities will be granted access to it.And while in the real protocol execution all parties send messages to and receive them from F Clock , in the simulated case only the ideal functionality, other global functionalities as well as the dishonest parties will do so.Hybrid functionalities in the simulation might also be given access, but this is not necessary in our setting.For simplicity, we do not introduce a session management in F Clock as it is not necessary to state our result.Throughout this work, we will write "update F Clock " as a short-hand for "send (Update, sid) to F Clock ".
Functionality F Clock F Clock is parameterized by a variable ν, sets P, F of parties and functionalities respectively.It keeps a Boolean variable dJ for each J ∈ P ∪ F , a counter ν as well as an additional variable u.All dJ , ν and u are initialized as 0.
Clock Update: Upon receiving a message (Update) from J ∈ P ∪ F : 1. Set dJ = 1.
2. If dF = 1 for all F ∈ F and dp = 1 for all honest p ∈ P, then set u ← 1 if it is 0.
Clock Read: Upon receiving a message (Read) from any entity: 1.If u = 1 then first send (Tick, sid) to S. Next set ν ← ν + 1, reset dJ to 0 for all J ∈ P ∪ F and reset u to 0.
Fig. 1: Functionality F Clock for a Global Clock.

Client-input MPC with Publicly Verifiable Output
We focus on MPC with security against a static, rushing and malicious adversary A corrupting up to n − 1 of the n servers where m clients provide the actual inputs and where all clients might be malicious.This specific setting of MPC is called out-sourced MPC and can efficiently be realized in a black box manner on top of a "standard" MPC scheme where the servers are providing the output [43].However, regardless of out-sourcing, it is known that fairness cannot be achieved against a malicious adversary corrupting a majority of the servers [28].We let the MPC functionality compute the result y and share its output in a verifiable way such that any potential verifier can either check that the output is correct or identify a cheater, and hence allow for incentivized fairness.In Fig. 2 we formally define functionality F Ident adapted from [7] that captures this style of MPC.We remark that differently from [7], we use a publicly verifiable version [6] of the original protocol of [7] with optimizations from [8] where no homomorphic commitments are needed and, in case no cheating is detected, no interaction with the smart contract is needed apart from the initial deposits from servers executing F Ident and the final output.Intuitively it specified an out-sourced MPC functionality where clients C 1 , . . ., C m supply private input that is computed on in MPC by the servers P 1 , . . ., P n and where the output of the computation is verifiably shared between the servers in such a manner that the shares can verified by an external verifier V after the completion of the protocol to identify any potential malicious behaviour.As F SC will need to interact with F Ident to verify outputs, we consider F Ident as a global functionality.This does, however, not change anything concerning it's implementation or security proof, as F Ident does not keep a common state across multiple sessions and ignores requests from other sessions.

(Threshold) Signatures
In our work we rely on signatures and identifiable threshold signatures to represent transactions on ledgers.Therefore we will assume the existence of two UC functionalities: F Sig which is a standard functionality in UC [20] (with key generation, signature generation and signature verification), as well as our own formalization of general UC identifiable threshold signatures F TSig (which can be seen as a generalization of signatures such as [23,22]).In comparison to normal signatures, F TSig has a two-step process of signature generation, where the parties first generate shares ρ of the overall signature σ which later on are aggregated in a share combination phase.This share combination also exposes parties that generated some shares wrongly.Additionally, F TSig also creates the signing key in a distributed way.We treat both F Sig and F TSig as global UC functionalities, which means that both local and other global UC functionalities can verify signatures on them.This is meaningful as we assume that ledgers are global functionalities too, hence validating their transactions should be consistent among any different session.Functionalities F Sig , F TSig are presented in Appendices A.1 and A.2, respectively.Throughout Init, Input, Evaluate and Share, S can at any point send (Abort, sid) to F Ident , upon which it sends (Abort, sid, ⊥) to all parties and terminates.Throughout Reveal, S at any point is allowed to send (Abort, sid, J) to F Ident .If J ⊆ IP then F Ident will send (Abort, sid, J) to all honest parties and terminate.
Init: Upon first input (Init, sid) by all parties in P set rev, ver, refused ← ∅.
Input: Upon first input (Input, sid, j, x (j) ) by Cj and input (Input, sid, j, •) by all servers the functionality stores the value (j, x (j) ) internally.
Evaluate: Upon first input (Compute, sid) by all parties in P and if the inputs (j, x (j) ) j∈[m] for all clients have been stored internally, compute y ← C(x (1) , . . ., x (m) ) and store y locally.
Share: Upon first input (Share, sid) by Pi ∈ P and if Evaluate was finished: Optimistic Reveal: Upon input (Optimist-Open, sid, i) by each honest Pi and if Share is completed, then send (Output, sid, y) to S. If S sends (Continue, sid) then send (Output, sid, y) to each honest Pi, otherwise send (Output, sid, ⊥).
Reveal: On input (Reveal, sid, i) by Pi, if i ∈ rev send (Reveal, sid, i, s (i) ) to S.
-If S sends (Reveal-Ok, sid, i) then set rev ← rev ∪ {i}, send (Reveal, sid, i, s (i) ) to all parties in P.
-If S sends (Reveal-Not-Ok, sid, i, J) with J ⊆ IP , J = ∅ then send (Reveal-Fail, sid, i) to all parties in P and set refused ← refused ∪ J.
Test Reveal: Upon input (Test-Reveal, sid) from a party in Allow Verify: Upon input (Start-Verify, sid, i) from party Pi ∈ P set ver ← ver ∪ {i}.If ver = [n] then deactivate all interfaces except Test Reveal and Verify.
Fig. 2: Functionality F Ident for MPC with Publicly Verifiable Output.
Post: Upon receiving (Post, m, vk, σ) from some entity contact F Sig or F TSig belonging to vk.If σ verifies for m and vk then send (Post, m, vk, σ) to S and append (m, vk) to M. Read: Upon receiving (Read) from some entity, return M. Fig. 3: The bulletin board functionality F BB that abstractly describes the source and target public ledgers of transactions.

Bulletin Boards and Smart Contracts
Our approach does not require dealing with the specifics of blockchain consensus, since we hold tokens in addresses controlled by threshold signatures in such a way that transactions can only be issued when all servers cooperate.Since at least one server is assumed to be honest, we do not have to confirm whether a transaction is registered.Even when we address the case of total server corruption, our approach only requires identifying an attempt of double spending a client's deposit regardless of which transaction of the double spends gets finalized on the ledger.Hence, in this work we do neither fully formalize distributed ledgers as was done in previous work [5], nor do we use other existing simplified formulations such as [46].Instead, for the sake of simplicity, we use a public bulletin board functionality F BB (see Fig. 3) to represent ledgers.What this functionality affords, is basically to allow storage of authenticated messages as well as make them available for all users.In Appendix B we also define the functionality F SC which describes our needs of the smart contract functionality run by the ledger.

Representing Cryptocurrency Transactions
In order to focus on the novel aspects of our protocol, we represent cryptocurrency transactions under a simplified version of the Bitcoin UTXO model [53].For the sake of simplicity we only consider operations of the "Pay to Public Key" (P2PK) type, even though any other types of transaction can be supported as long as it is possible to publicly prove that a double spend happened and to generate transactions in a distributed manner.In particular, even a privacy preserving cryptocurrency that publicly reveals double spends could be integrated to our approach by constructing a specific purpose multiparty computation protocol for generating transactions in that cryptocurrency.Representing Addresses: An address Addr = vk is simply a signature verification key, where vk and subsequent signatures σ are generated by the signature scheme used in the cryptocurrency (represented by F Sig and F TSig ).
Transaction Validity: A transaction tx = (id, In, Out, Sig) is considered valid if, for all (id i , in i ) ∈ In and (out j , Addr j ) ∈ Out, the following conditions hold: -There exists a valid transaction

Modeling Fair Decentralized Exchanges in UC
In this section we formalize a decentralized exchange on a high level.We assume that there are m clients C 1 , . . ., C m .These clients can exchange between ledgers L 1 , . . ., L .Each C j controls an amount of tokens am src j in an address vk src j which is on ledger L src j .The goal of C j is to acquire am trg j tokens on ledger L trg j which should be transferred to address vk trg j .In order to compute transactions there exist two deterministic poly-time algorithms compSwap and makeTX.On a high level, compSwap takes the exchange order of each client between two specific ledgers, L a and L b , as input and returns the order matches.Whereas makeTX takes as input the order matches computed by compSwap for each possible pair of ledgers along with some metadata and returns a list of all, unsigned, transactions to be carried out to complete the exchange over all ledgers.More concretely, a bit δ j indicates for each client C j whether said client wants to buy am src j tokens on L a using at most am trg j tokens from L b , or if they want to sell am src j tokens from L a for at least am trg j tokens on L b .compSwap then returns a list of transfer orders.More concretely, a list of tuples where each tuple contains two quantities, am j and am j and the identifiers of two clients; client C j who should have am j of its tokens transferred on L a to the other client C j and client C j should transfer am j of its tokens on L b to C j .As our protocol will use individual burner addresses for each C j controlled by the servers, we assume for the computation that the asset was transferred by C j to an address vk ex j using a transaction with id id j .
compSwap computes swaps between two ledgers.It takes as input m ≤ m tuples of the form (C j , δ j , am src j , am trg j ) where C j , am src j , am trg j ∈ N where δ j = 0 if C j wants to swap from the first to the second and δ j = 1 if it wants to swap from the second to the first ledger.It outputs a list of tuples (C j , am j , C j , am j ), where am j , am j ∈ N, which is viewed as a vector y a,b ∈ N g for some g.makeTX takes the • ( − 1) outputs of compSwap for each pair of ledgers L a , L b with 1 ≤ a < b ≤ as well as a tuple (C j , L src j , L trg j , id j , vk ex j , vk src j , vk trg j , am src j ) for each C j as input.It then outputs transaction orders (id a , In a , Out a ) (still missing the signatures however), one for each L a , such that 1.In a = {(id j , am src j )} for some C j where L src j = L a and C j transferred the amount am src j to vk ex j in a transaction with id id j .2. Out a = {(out i a , Addr i a )} where each Addr i a is either vk src j for C j with L src j = L a or vk trg j for C j with L trg j = L a .3. j in j a = out i a and id a is computed as a hash of In a , Out a .
Further discussion on our matching algorithm compSwap is presented in Appendix C. Notice, however, that our approach is not limited to this algorithm, since our MPC component can accommodate any arbitrary matching algorithm.
Algorithms compSwap and makeTX only model the generation of UTXO-style transaction descriptions that can later be turned into valid transactions by creating a signature Sig a for each L a .The exchange security requirements are then modeled in the functionality (e.g.requiring that e.g. each C j either gets its asset back or also an asset on the other ledger according to some matching rule of transactions).The exchange functionality F EX as well as the protocol Π Ex will later use the algorithms compSwap, makeTX to generate the transactions.Looking ahead we note that compSwap will be computed using outsourced MPC through Ident , keeping the input am src j , am trg j from each client hidden from every server whereas makeTX will be computed openly.We furthermore note that since there is always an honest party that can influence the choice of algorithms so that the chosen algorithms are fair.

The Fair Exchange Functionality
Functionality4 F EX as depicted in Fig. 4 & 5 generates the transactions for clients via burner addresses.As our protocol later uses the global clock, F EX also accesses F Clock .The transactions that F EX will generate must be verifiable on other ledgers and its signatures therefore come from a global threshold signing functionality F TSig .F EX accesses F TSig in order to generate these, giving the adversary S extra influence in the process.Notice that F EX implements a fair secure swap given that compSwap and makeTX implement swapping algorithms.S only learns the swap data y a,b after all transactions were determined but does F EX interacts with the set of servers P = {P1, . . ., Pn}, a set of m clients C = {C1, . . ., Cm} as well as the global functionality F Clock to which it is registered.F EX is parameterized by the compensation amount q and the security deposit d = mq.S specifies an adversary controlling a set of corrupted servers I ⊂ [n] and clients J ⊆ C. Let L1, . . ., L be the available ledgers.not learn the input orders like a centralized exchange does.S can only cause an abort before the output is released by causing signature generation to fail.In this case, all clients get reimbursed with either their original assets or with a deposit (here coins) from S. If the functionality progressed far enough that S learned the output, then it can only abort by losing its coins.Otherwise, the swap output transactions will always be given to the clients.

Realizing the Exchange Functionality
We now describe a protocol Π Ex that GUC-realizes F EX , making sketch from Section 1.2 more precise.As the smart contract which is used, abstractly described in F SC (see Appendix B), is rather complex, we outline the interplay between Π Ex and F SC beforehand.Due to space limitations, the smart contract description and its formalization F SC as well as the full protocol Π Ex can be found in Appendix B.

Overview of the Protocol
Π Ex runs between n servers P and m clients C. The clients can exchange between ledgers L. Each C j controls an amount of tokens am src j on an address with public key vk src j on ledger L src j .The goal of C j is to acquire am trg j tokens on L trg j to an address with public key vk trg j .
Smart Contract Setup.Initially, no servers or clients are registered anywhere.
The servers P run a pre-processing step where they use F TSig to (internally) sample a common key sk for threshold-signing along with a public key vk for threshold-signature verification.Each P i also sends its individual verification key vk i to all other servers.Finally the servers set up Ident to accept inputs by clients who want to transfer between L a and L b .
To initiate the protocol each server sends vk, vk 1 , . . ., vk n , coins(d) to F SC .F SC will wait for a certain period and then check if all servers put in enough deposit 5 and signed messages consistently.If so, then the coins are locked and F SC transitions to a state ready, otherwise the servers are reimbursed and F SC goes back to its initial state init.
1. Burner Address Setup.If a client C j wants to exchange an asset from L src j to L trg j it checks if F SC is in state ready.If so then C j sends a registration message to all P, who generate a burner address/public key vk ex j on L src j using F TSig .The servers sign the client's data and vk ex j using sk and send the signature to C j .
2. Private Order Placement.If the signature is correct, then C j transfers am src j from vk src j to vk ex j and inputs its transfer information into the correct F a,b Ident .

Confirmation.
Servers wait until all transfers to burner addresses were made and inputs were provided to F a,b Ident by all clients.They then sign information about the transactions to the burner addresses using sk.If either of this fails, then at least one P i signs an "abort" message using sk i and sends it to F SC .

Private Matching. Afterwards the servers run compSwap on all F a,b
Ident to match transactions.If Share of each F Ident is completed, all servers sign a message "ok" using sk that every server obtains.If this fails then each P i signs an "abort" message and sends it to F SC .If signing succeeded but a server sent "abort", then all P i respond by sending the signed "ok" to F SC .If signing "ok" was successful then all P i use Optimistic Reveal of F a,b Ident , i.e. the swaps.
5. Pay Out.The servers will compute the resulting transactions tx a = (id a , In a , Out a , Sig a ) using makeTX and by making signatures using F TSig under all burner addresses of each L a .These tx a are then sent to clients C j that are touched by the transfer.In case of an error a server sends "abort" to F SC .Once all transactions were signed, the servers sign a message done using sk and send this message to F SC .Upon receiving done signed by sk F SC reimburses all P i .
Cheating Recovery.If any server sends an "abort" to F SC , then F SC waits if any other server publishes an "ok" or "done" signed by sk.If "done" is published after an "abort" then F SC reimburses all P i .If "ok" is published then each P i runs Reveal and Allow Verify for each F a,b Ident and then posts all sk-signed client registrations, transaction ids as well as F Ident -shares s a,b i .This allows each server to compute y a,b = i s a,b i and hence id a , In a , Out a for each L a using makeTX.For each such transaction the server then computes its shares of Sig a which it also posts.All this information allows F SC to check if all servers revealed correct shares and signature shares or not.In case of cheating F SC sends the cheaters' deposit to all registered clients and reimburses all honest servers.If posted data was correct, F SC instead reimburses all servers.Each client C j identifies from F SC the parts necessary to compute its swap transactions locally and then posts these to finalize the swap.
If no "ok" or "done" is published then each server posts all client registrations signed by sk to F SC as well as the transactions that each client C j made to vk ex j from vk src j .After a certain delay passed the servers create reimbursing transactions tx j for each C j .For this, each server P i generates its share of the signature using F TSig and sends this share to F SC , signed under sk i .
F SC parses all signed client registrations and transactions, locally generates id j , In j , Out j for each C j and checks that each P i generated its signature share correctly.If any share is missing or if P i did not provide a valid share, then the deposit of all cheaters is shared among all clients.Finally, each honest server is reimbursed.If all reimbursement transactions can be made, then each C j reads its transactions from F SC and posts them on F BB while F SC reimburses all servers.
Protocol Π Ex (Part 1) We have n servers P and m clients C. The clients exchange between ledgers L known to P. Each Cj starts with an amount of asset am src j signed by vk src j on ledger L src j .The goal of Cj is to acquire am trg j on L trg j by a transfer to vk trg j .The protocol runs in the presence of F Clock , F SC and multiple instances of F Sig , F TSig .

Initialize:
1.All P set up Enroll Client: Upon message (Enroll, sid, am src j , L src j , vk src j , L trg j , vk trg j ) by Cj: 1.If state = ready then all Pi use F TSig to generate a fresh key vk ex j on L src j .Let tj = (Cj, L src j , am src j , vk src j , vk ex j , L trg j , vk trg j ).Then the servers use F TSig to generate a signature σ vk (tj) for the key vk.All Pi send (Ok, sid, tj, σ vk (tj)) to Cj.
2. Upon receiving (Ok, sid, tj, σ vk (tj)) Cj checks if σ vk (tj) is valid using vk from F SC .Then it creates a transaction txj = (idj, Inj, Outj, Sig j ) where idj is fresh for L src j , Inj = (idj, am src j ), Outj = (am src j , vk ex j ) and Sig j = σ vk src j (id|In|Out) where id is the id of an unspent transaction for vk src j and the signature is produced by F Sig for the key vk src j .Finally, Cj sends txj to F BB corresponding to L src j .3. Let La = L src j and L b = L trg j .Each Cj sends (Input, sid, j, (Cj, 0, am src j , am trg j )) to Ident if a < b, otherwise it sends (Input, sid, j, (Cj, 1, am src j , am trg j )) to F b,a Ident .

The Protocol
We discuss the practical deployment considerations of the protocol in Sec. 5 and describe the full protocol in Figures 6-8 and now prove our main theorem: Theorem 1.The protocol Π Ex GUC-implements the functionality F EX in the F SC , F Ident , F Clock , F Sig , F TSig , F BB -hybrid model against any PPT-adversary corrupting at most n − 1 of the n servers statically.

Each Pi runs Reveal and Allow Verify for each F a,b
Ident , followed by sending (Post, sid, s a,b i , σ vk i (s a,b i ), vki) to F SC and updates F Clock .If Pi or Cj obtains coins(d) from F SC then it outputs coins(d) and terminates.

Otherwise
Pi recovers all y a,b from F SC and does the following for each La: (a) Determine ida, Ina, Outa using makeTX from all y a,b as well as all tj, uj.
(b) Compute ρ a,c i by sending (Sign, sid, ida|Ina|Outa) to F TSig for each vk ex c where c ∈ [r] and r is the length of Ina.Set vj = (ρ a,1 i , . . ., ρ a,r i ). 4. Pi sends (Post, sid, vj, σ vk i (vj), vki) for a ∈ [ ] to F SC and updates F Clock .
5. If Pi obtains coins(d) from F SC then it outputs coins(d) and terminates.
6.Each Cj checks if F SC contains data for a transaction txa if La ∈ {vk src j , vk trg j }.If so then Cj reconstructs txa.Otherwise it outputs the coins obtained from F SC .

Abort without Output:
1.For each registered client Cj the servers send (Post, sid, tj, σ vk (tj), vk) to F SC where tj = (Cj, L src j , am src j , vk src j , vk ex j , L trg j , vk trg j ).Furthermore, each client Cj sends (Post, sid, idj|Inj|Outj, σ vk src j (idj|Inj|Outj), vk src j ) to F SC where idj|Inj|Outj are from the transaction txj that Cj made to vk ex j and where σ vk src j (idj|Inj|Outj) is from the signatures Sig j that are part of txj.Then each Pi updates F Clock .

Next, each
Pi for each Cj computes the transaction txj as follows: (a) Set Inj = (idj, am src j ) and Outj = (am src j , vk src j ).(b) Determine idj as the hash of Inj, Outj.Set tj = (idj, Inj, Outj).(c) Compute ρ i j by sending (Sign, sid, tj, vk ex j ) to F TSig .3. Each Pi sends (Post, sid, ρ i j , σ vk i (ρ i j ), vki) to F SC and updates F Clock .4. If Pi obtains coins(d) from F SC then it outputs coins(d) and terminates.
5. Each Cj checks if F SC contains data for a transaction txj.If so then Cj reconstructs txj.Otherwise it outputs the coins coins it obtained from F SC .
Proof.In order to prove the claim we construct a PPT simulator S which will, in the ideal setting, interact with A, F EX and all the hybrid and global functionalities in such a way that F EX • S ≈ Π Ex • A for any PPT environment Z, i.e. that the interaction created by S is indistinguishable from a protocol transcript in a composed setting.Additionally, the global functionalities will be present in both cases and Z will be able to perform queries to these.S, on a high level, runs as follows: - It is easy to see that the messages which an adversary reads during the simulated protocol are consistent with the values that are returned both to the honest parties and servers and with the outputs of the ideal functionality.The state of F Clock during each protocol step is identical with that during the simulated protocol instance.Moreover, whenever the simulated protocol aborts then this also leads to an abort of F EX and when honest servers let F EX abort then this is reflected in F SC .Honest clients never abort in the simulation as they cannot abort in Π Ex either.Finally, the coins that A puts into F SC and obtains from F SC are identical with those that S inputs into F EX or obtains from it.

Preventing Denial of Service Attacks by Clients
In Π Ex as sketched above, any client that registers but does not transfer funds causes an abort of the exchange.This can be avoided with an extension of Π Ex that we outline below.We did not include this extension in the formalization of Π Ex in order to keep the protocol description as small as possible.
To avoid the attack, all P i in Step 3 of the protocol (Confirmation) sign information on which clients will be included and which will be excluded in the exchange, using F TSig .For each excluded C j , the servers send the signed message of exclusion to C j .If C j 's transaction tx j to vk ex j on L src j was confirmed after this signature was generated, then C j sends this signature together with tx j and its registration information to F SC as proof that it should be reimbursed 7 .Upon having obtained this, F SC requires all P i to create a signature on a reimbursement transaction to C j .If a server P i does not send it's signature share, then C j will be reimbursed from the collateral of P i on the exchange ledger.
Observe that tx j might not be a valid transaction on L src j , but the reimbursement transaction will only be valid if tx j was valid (as it spends tx j ), hence a malicious C j cannot obtain funds of an honest party.Also, if a dishonest P i refuses to sign an honest C j 's reimbursement transaction, then C j will be reimbursed on the exchange ledger with funds of P i .

Implementation
To demonstrate feasibility of our approach, we describe a simple algorithm for order matching, i.e. compSwap, along with an efficient MPC-based privacy preserving implementation of this, based on the ring-variant of the SPDZ protocol [35,34] , called SPDZ 2 k [33].
We implemented a limited order-matching function, C compSwap realizing the algorithm compSwap, which we describe in full detail in Fig. 15 in Appendix C 7 All this information was signed by F TSig and must therefore be valid.
. We note that C compSwap is a simplified version of standard limit-order pricefocused matching algorithms, in the sense that it assumes all orders are for a constant amount of tokens from ledger L a and only matches according to price.That is, the algorithm sorts the buy and sell orders according to their maximum and minimum limits respectively.Then the largest acceptable buy price is then matched with the smallest acceptable sell price, assuming the buy price is larger than the sell price.The clearing price will then be the average of the two prices.The price describes how many tokens of L b must be swapped to get a constant amount of the tokens on L a .Orders which are not matched are simply discarded, without disclosing their price limits.We chose to implement this simple matching algorithm as it provides a minimally useful example of what is required by compSwap by performing oblivious sorting and selecting, which are they key aspects we can expect from any reasonable choice of algorithm.
Furthermore, based on benchmarks of the most efficient implementation for full-threshold ECDSA [32,36], we provide estimates for an implementation of our full protocol showing that it can be realized efficiently, with the bottleneck being the time it takes a transaction to be confirmed on the underlying ledgers.2.
Implementation of Matching.We implemented and ran C compSwap using the Fresco framework [2], which is an open-source MPC framework in Java for secure computation in the dishonest majority setting.We chose Fresco as it offers a simple API allowing quick construction of MPC applications.Furthermore, since it is Java-based, it also allows for easy cross-platform deployment and integration with other software.Additionally, Fresco is a commonly used framework for prototyping MPC applications [33,30] and supports a bring-your-own-backend approach, allowing easy switching of the underlying MPC scheme without having to modify the program to be executed.Most importantly however, Fresco is actively maintained, has high test coverage and offers an extensive API of operations, making it a great choice for prototyping MPC protocols, with a focus on potential real-world deployment, despite it not being the fastest option available.We chose to base our implementation on arithmetic MPC instead of binary MPC to closer reflect the domain where real-world matching algorithms work.This also allows for more advanced computation of matches and prices through arithmetic computation on the orders.This also avoids the large overhead there would otherwise be present when doing arithmetic calculations on large integers using an MPC protocol working over binary values.Furthermore, we also chose SPDZ 2 k [29] as our MPC protocol to closer reflect the real-world setting.In particular SPDZ 2 k can work over the same domain as standard processors, i.e. 32 or 64 bit integers, and hence allows for simple integration with already existing algorithms, and systems that have been optimized for working over these domains.Because of this, the online computation of SPDZ 2 k is significantly faster than for SPDZ when computing comparison [33].
We note that we could have optimized our implementation by using newer and more efficient approaches to MPC, such as approaches mixing both the binary and arithmetic setting [39].However, the goal of our implementation has been to show feasibility and an upper bound on the time it would require to execute our protocol using a fully tested, documented and maintained framework.Thus we leave such possible optimizations as future work.Benchmarking Matching.We benchmarked the online execution of the matching protocol in several different settings using Amazon's Web Services EC2.We show these benchmarks in Fig. 9 based on the average of 30 iterations (executed after 30 "warm-up" iterations) and note that memory usage never gets above 536 MB regardless of test.For all tests we used m5.xlarge instances running Ubuntu 18.04 LTS.This means that each instance has 4 virtual CPUs and 16 GiB of RAM along with a LAN connections of up to a 10 Gbps with less than 0.1 ms latency, when running instances in the same data-center.For the WAN setting we also used m5.xlarge instances, but data centers in different countries.For the setting with 2 servers, one was located in Ireland and another in the U.K., with a latency of around 10 ms.For the setting with 3 servers, we kept the servers in Ireland and the U.K., but added a third server in Germany, with a latency of up to 25 ms between the Germany and Ireland servers.
When working over 32-bit integers (k = 32), the statistical security parameter is κ = 26, whereas when working over the 64-bit integers (k = 64) we have κ = 57.This is due to the underlying implementation of SPDZ 2 k in Fresco, and was originally made for efficiency choices [33].
From Fig. 9 we notice a steep increase in execution time when expanding the amount of orders and when moving from 2 to 3 servers.This is especially true in the WAN setting.This is to be expected due to the underlying SPDZ 2 k protocol having round complexity in the multiplicative depth of the circuit being computed and where each round involves every party sending two ring elements to all other parties.Thus the overall execution time of the protocol becomes highly depended on the underlying network, in particular its latency, when increasing the amount of servers.This is also the case when increasing the amount of orders as the round complexity is bounded by O(log(k) • log 2 (m)) and multiplication gate complexity is bounded by O(k • m log 2 (m)).
We imagine our protocol being run by a small set of servers, either run by a single or a few public organizations, whose servers will be in physically distinct locations, running distinct systems and administered by different people.For this reason we only benchmark for 2-3 servers, but note that if high scalability is desired one can simply change the underlying MPC scheme to a constant round scheme such as BMR [9] as done in "Insured MPC" [7].
We note that Figure 9 only shows the online execution time.However, each multiplication gate used for such an execution requires to be preprocessed in advance in SPDZ 2 k .This preprocessing is independent of the input of the function to be computed and can thus be done before the clients even submit their exchange orders.The most efficient SPDZ 2 k triple generation protocol with benchmarks is due to Damgård et al. [33], offering a throughput of 26,455 triples/second for k = 32 and 9,496 triples/second for k = 64 in the 2 server setting on LAN.Thus this can be done completed in about 1.5 minutes for m = 128 and k = 64.However, a more band-width friendly solution has since been introduced by Orsini et al. [54] that will most likely be more efficient for both the LAN and WAN, but has currently not been implemented with benchmarks.Signatures.We outline the computational need and timing estimates of F TSig and F Sig , which is required by our protocol Π Ex in Table 3.Note timings in this table are estimates based on benchmark of a the recent work by Gennaro and Goldfeder [41] for threshold ECDSA (currently the most popular scheme in use by cryptocurrencies) with identifiable abort (which is needed for our protocol).The estimates are computed by adding the raw, single-core computation benchmarks of Gennaro and Goldfeder and combine it with the latency between the servers we used in Sec. 5 required for all rounds of the signing protocol (including preprocessing time).We note that Gennaro and Goldfeder do not include benchmarks for the key generation phase so we have benchmarked this as signing.This is quite conservative since the key generation phase of their protocol is faster then the signing phase.
Total Execution Time.We only implemented and benchmarked the MPC implementation of the C compSwap algorithm since it is clearly going to be the computation and communication related bottleneck when realizing F Ident in the way discussed in Sec.2.4.The only other cryptographic computation of this realization is limited to committing and opening of O(n(m + s)) commitments and sampling an equivalent amount of random elements in the MPC computation.Such commitments can be constructed very simply and efficiently in the ROM [18].In particular in the order of microseconds, when using a standard hash function like SHA-256 to realize the random oracle.Furthermore, we note that besides the realization of F Ident and F TSig there are no other heavy communication or computation involved in realizing Π Ex , since the other parts is basically straight-line executable business logic.
Taking the above discussion into account, it is easy to see that in a full online execution, the execution C compSwap with no malicious behaviour, will be slower than the time required for computing the threshold signatures 8 .
However, we now argue that even with the unoptimized implementation of C compSwap and F TSig these are not going to be the bottle-neck in regards to wall-clock execution time in practice.The reason being the time it takes to finalize transactions on the ledgers, which is necessary for any cross-ledger exchange.A block has been finalized once it has been written to the ledger and a certain amount of other blocks have been written afterwards to the same chain.This ensures that one can be reasonably certain that the block with the transaction will not be overwritten, by another, longer branch of blocks.The frequency at which blocks are constructed, and how many should be constructed before a transaction can be considered finalized, depends highly on the specific choice of ledger.
For Bitcoin, a new block is expected to be constructed every 10 minutes, and a rule of thumb is that 6 further blocks must be written before a transaction can be considered finalized.On Ethereum a block is constructed every 10-20 seconds and can optimistically be considered finalized after 3 minutes.In case of Cardano, blocks are considered finalized after 10 minutes.This means that each round of ledger I/O will generally involve a latency of several minutes and hence be the bottleneck in practice.

Conclusion
Comparison to current solutions.As discussed in Sec. 1, besides our solution, there are generally only two other approaches to cross-chain exchange: 1) A centralized exchange where a trusted party receives tokens on the different ledgers and transfers the exchanged tokens accordingly based on some centrally decided exchange rate.An example of this is Coinbase or Kraken.2) A solution using atomic-swap as employed by current decentralized exchanges [14,42,57], where hash time locked contracts are used to ensure that the required transfers actually get carried out.Only considering efficiency, even in the case of the centralized exchange, two transactions must be carried out and finalized on the underlying ledgers; one transfer from ledger L a to the exchange and one from the exchange to ledger L b .This means that we can expect a centralized exchange to take an order of tens of minutes to hours before it is has been fully finalized.If a system based on atomic swaps is used, an extra transaction is required, so 3 sequential transactions are used to finalize before the exchange can be considered complete.
When there is no malicious behaviour occurring, our system uses the optimal 2 sequential transactions 9 similarly to centralized exchanges.Specifically our system involves the transaction by clients transferring their tokens to the burner addresses and then the transaction of paying out the exchanged tokens.Furthermore, we note that while waiting for the first transaction to finalize the servers are sitting idle.This means that they could optimistically leverage this finalization time and start the actual matching computation.If the tokens are not transferred by all clients, the servers will generate refund transactions instead of opening the transactions computed by the private matching.Since the total computation time of Π Ex is less than the finalization time of most blockchains, it means that its execution time will not be noticeable in the time it takes to carry out and finalize a complete exchange.Hence using our protocol will not add any time overhead to the current solutions (centralized or swapping).Furthermore, since nothing (besides the one-time initialization of the server) is written to the ledger, or executed by smart contracts, unless malicious behaviour occurs, it means that there will be no added mining-related cost by our approach.Thus achieving the added distributed security comes with no penalty in price or execution time as long as no malicious behaviour occurs.The only actual cost is what is needed to keep the servers running and the one-time cost of initialization.
Deployment Considerations.Despite increasing the latency of an exchange, we note that in a real-world deployment the servers would likely want to wait for the clients' transfers to the burner addresses get finalized before starting the matching computation to prevent wasting computation and transfer/smart contract fees.The reason being that it is unlikely that a client manages to enroll in the exchange with the servers but fails to publish a transaction to its source ledger.Even though it is formally considered a malicious deviation this could happen without malice in many real world situations, either where the client simply loses Internet connectivity or where miners chose to block a specific client's transfer.Thus the servers would only do an exchange on the request from clients that have actually been finalized at a certain point in time (and refund any transactions that happen to complete afterwards).This way it is possible to prevent a single unstable client from delaying the entire protocol.More importantly it will also prevent malicious clients from forcing the servers (and honest clients) to spend money on smart contract and transaction fees of exchanges that cannot be completed as discussed in Sec.4.3.In regards to creating a highly usable deployment we note that the clients actually don't need to be involved during the payout phase of the protocol.Instead of having each client C j post the signed transaction transferring their exchanged tokens to vk trg j on ledger L trg j themselves, we can simply have one of the honest servers post this transaction on their behalf.This means that they do neither need to wait for all other clients' transfers of source tokens to be finalized, nor for all the servers to finish computing the order-matching.This means that, unless one or more servers are malicious, the only time the clients need to interact with the protocol is during enrollment where they must register at the servers (and receive a signed confirmation).For clients this only involves giving outsourced input to F a,b Ident , which can be done very efficiently and independently of other clients or the size of the circuit to compute [43].Thus this is something that can easily be done in the user's browser using a JavaScript web-app that integrates with a user's browser-wallet (e.g.MetaMask for Ethereum), where the server's signed response can be saved in the local web-page cache.Even if some servers act maliciously and the abort branch of the protocol ends up being executed, assuming there is still a single honest server, that honest server could simply act on behalf of the client to ensure they get refunded.This is because all the information the client would need to post to F SC is actually constructed and known by all the servers.Future Work.Certain centralized exchanges are able to carry out huge amounts of exchanges per second, without barely any latency in reception of the exchanged tokens.This is through a state-channel [38] approach where they hold the client's tokens persistently and simply carry out the transactions "in-thehead", keeping an internal ledger of which client owns what amount of tokens on which ledger.However, such approaches necessarily require the same 2 sequential finalized transactions when they are to be committed on their respective ledgers.We consider generalizing our approach to this setting, by implementing a state-channel in MPC, an interesting direction for future work.
Even without realizing state-channels, simply employing a reactive MPC functionality to carry out unmatched orders into a future iteration of compSwap would be interesting.Along with adding more advanced features to C compSwap , such as expiration time and fully variable quantities to exchange, this would allow for a complete and continues decentralized exchange platform that clients can use "as-a-service" through a simple web-platform and a standard cryptowallet.

Functionality F Sig
Given ideal adversary S, verifiers V and a signer Ps, F Sig performs: (This condition guarantees completeness: If the verification key SIG.vk is the registered one and σ is a legitimately generated signature for m, then the verification succeeds.)2. Else, if SIG.vk = SIG.vk, the signer Ps is not corrupted, and no entry (m, σ , SIG.vk, 1) for any σ is recorded, then set f = 0 and record the entry (m, σ, SIG.vk, 0).(This condition guarantees unforgeability: If SIG.vk is the registered one, the signer is not corrupted, and never signed m, then the verification fails.) 3. Else, if there is an entry (m, σ, SIG.vk , f ) recorded, then let f = f .(This condition guarantees consistency: All verification requests with identical parameters will result in the same answer.)4. Else, let f = φ and record the entry (m, σ, SIG.vk , φ).Output (verified, sid, m, f ) to Vi. Fig. 10: Functionality F Sig for Digital Signatures [20].
Functionality F TSig F TSig is parameterized with an ideal adversary S, a set of signers P and functionalities F, a verifiers V (which automatically contains P and F) and a set of corrupted signers I ⊂ P. F TSig has two internal lists Sh and Sig.S to a certain consistent set of dishonest parties that are exposed via Share Combination.In F TSig S will always be able to make Share Generation output dishonest shares that lead to a signature that is valid (if the set of cheating parties J is empty), but it never can make an invalid signature in an honest instance of Share Generation.

Functionality F TSig (different version)
F TSig is parametrized with an ideal adversary S, verifiers V (which can also be functionalities), a set of signers P and a set of corrupted signers I ⊂ P. F TSig has two internal lists Sh and Sig.F SC interacts with the global functionalities F Ident , F Clock , F Sig , F TSig .It is parameterized by the compensation q, the maximal number of exchange clients m and the security deposit d = m • q.F SC has an initially empty list M of messages posted to the authenticated bulletin board and a public state state which is initially init.It furthermore has the sets P of servers which is initially empty.Upon each activation F SC first sends a message (Read, sid) to F Clock .If ν has changed since the last call to F Clock then it does the following: Ident .If any of the aforementioned steps fails, then let I1 be the set of cheaters.If I1 = ∅ then set state to ok2, else let C be the set of clients, run CC(I1, C) and change state to init.state = ok2: For each ledger La compute ida, Ina, Outa from y a,b as well as the client registrations and transaction ids using makeTX.Let vk ex a,1 , . . ., vk ex a,r be the source transactions in ina.For each La check if ((ρ a,1 i , . . ., ρ a,r i ), vki) ∈ M and send (combine, sid, ida|Ina|Outa, ρ a,c i , vk ex Finally change state to init.state = reimburse1: Change state to reimburse2.state = reimburse2: Parse all messages (Cj|L src j |am src j |vk src j |vk ex j |L trg j |vk trg j , vk) ∈ M (i.e.client registrations) as well as (idj|Inj|Outj, vk src j ) ∈ M (transaction ids) where Inj = (vk src j , am src j ) and Outj = (am src j , vk ex j ).If there are multiple messages for Cj then ignore Cj.Compute for Cj the values idj, Inj, Outj for reimbursement by setting Inj = (idj, am src j ), Outj = (am src j , vk src j ) and idj as the hash of Inj, Outj.Check if (ρ i j , vki) ∈ M for each Cj and each Pi, then send (combine, sid, idj|Inj|Outj, ρ i j , vk ex j ) to F TSig for each i ∈ [n].If all values were present on M and all queries to F TSig were positive then run CC(∅, ∅) and set state to init.Otherwise let J be the set of cheaters and C be the set of all clients.Run CC(J, C) and set state to init.
Afterwards it executes the operation and finalizes by sending (Update, sid) to F Clock .Ident as well as the client registration data and transaction ids using makeTX.For each L a check if each P i sent shares of Sig a signed with sk i .If so, then check that each share of Sig a is valid using F TSig by running Share Combination.If any of the previous steps fails, then let I 2 be the set of cheaters.If I 2 = ∅ then reimburse all P i with their deposit and change the state to init.Otherwise identify all the m clients by finding all client registration data and transaction ids to burner addresses signed by sk.For each party in I 2 share the deposit among all m clients.Then return the deposit of the parties in [n] \ I 2 and change the state to init.reimburse1 If a tick happens, then continue to reimburse2.Intuitively, during this step all clients that get reimbursed are already fixed so the servers will create the signatures on reimbursement transactions.reimburse2 If a tick happens, consider all messages provided by each P i to F SC that are of the form (C j |L src j |am src j |vk src j |vk ex j |L trg j |vk trg j ) that are signed by sk as well as all messages (id j |In j |Out j , vk src j ) ∈ M (transaction ids) where In j = (vk src j , am src j ) and Out j = (am src j , vk ex j ).If there are multiple messages for C j then ignore C j Locally compute for each C j the transaction tx j to reimburse C j .Therefore set In j = (id j , am src j ), Out j = (am src j , vk src j ) and set id j as the hash of both.If each P j i provided ρ i j then check using Share Combination on F TSig that it outputs a valid signature Sig j on id j , In j , Out j .If all such Sig j are valid signatures then reimburse all P i and set the state to init.If some signature shares are not valid or some shares ρ i j are not present on F SC then let J be the set of cheaters.Reimburse all servers [n] \ J and distribute the deposit of the parties of J evenly to all C j .Then set the state to init.
Formalizing the Smart Contract.We use a combined smart contract and public ledger functionality F SC .It is an extension to F BB , tailored to be combined with an MPC protocol and similar to the functionality used in [7].For technical reasons, F SC has a hard-coded reference to the publicly verifiable MPC functionality F Ident in order to be able to verify outputs.F SC is described in Fig. 13 and Fig. 14 and considered as an ordinary UC functionality in our work.Again, this is due to technical limitations of UC, which would not make it possible for the simulator we construct in our security proof to equivocate the necessary outputs.
Concretely our prototype implementation could for example perform exchanges between Bitcoin and Ethereum and each exchange would be of, say of 1 BTC.Hence a buy order would only contain the upper limit of Ether one would maximally be willing to pay for 1 BTC, which could for example be 30 ETH.Similarly a sell order would contain the lower limit of Ether one would minimally be willing to accept in exchange for 1 BTC.To get higher granularity the units can of course be changed so that one rather express how many 0.00001 ETH one will pay for 1 BTC, for example 2, 985, 184 • 10 −4 ETH.To buy more than 1 BTC, one could simply issue multiple orders.
Orders are matched such that the largest buy limit is matched with the smallest sell limit, under the constraint that buy limit is larger than, or equal to, the sell limit.This match is removed from the set of orders, and the new remaining largest buy limit is matched with the new remaining smallest sell order.This continues until all orders are fulfilled, or the remaining largest buy order is smaller than the smallest sell order, when the remaining orders are discarded.
The clearing price of an order is then defined to be the average of the buy limit of this specific order's buyer and the sell limit of this specific order's seller.This means that all matched orders will likely have different clearing prices.To implement this securely we require that the buy/sell limits of every client's order is hidden and only the clearing price is leaked, and only after all orders in the set have matched or discarded.
Since the buy/sell limits are hidden, orders must be distinguished, thus each order is assigned a distinct, yet public ID, that is then linked to their client's identity outside of the matching protocol, vk src j .However, this must then be oblivious to the servers during execution as this would otherwise leak information about the relative difference between the different client's limits during execution, thus giving the servers a potential advantage in front-running the client's in other exchanges.But it could simply just be the client's public key vk src j , however, for efficiency reason it makes sense to map this to a small index such that it can be represented by a single element in the MPC computation.
With this description in mind we see that the matching protocol is simply to sort, based on the buy limits and the sell limits, in parallel, followed by an iteration through the sorted buy/sell limits, matching as long as the i'th buy limit is greater than the i'th sell limit.However, even doing this in a secure way becomes non-trivial since we cannot allow branching in MPC without requiring all branches being executed.Hence it will not be efficient to use a standard approach to sorting, such as quick-sort.Even merge-sort will be highly inefficient since a trivial approach to oblivious merging would require O(m 2 ) time for m elements.For this reason an oblivious sorting algorithm (sorting network) must be used.For example Batcher's Odd-Even Merge sort [47,Sec. 5.4.3], which we used in our implementation.This algorithm requires O(m log 2 (m)) comparisons and has depth O(log 2 (m)) for m elements.
We describe the secure computation logic of our matching algorithm in Fig. 15, using the common notation of • to indicate values hidden in MPC.
We include a subscript, • i , to indicate a specific index of the internal representation hiding the value when this would otherwise not be known to the server.In particular, this is the case after obliviously sorting the the input elements.
We note that in this protocol we assume that clients can send secret input to the servers in a consistent way.We will not dwell on how exactly this is done, but simply mention that this can be done efficient, black-box in the underlying MPC scheme (assuming that it allows for reactive computation) using an approach called out-sourced MPC [43].
In our algorithm we assume access to an algorithm, Sort, for oblivious sorting of a list in increasing order and an algorithm Rev for reversing the order of a list.Thus Rev(Sort(•)) returns a list in decreasing order.We also assume that we have an oblivious method for comparison, that is z := x ≥ ?y where z = 1 if x ≥ y and z = 0 otherwise.Finally we abuse notation and assume the permutations sort buy (j), sort sell (j) map an index j in an unsorted list to its sorted position in said list, for the buy, respectively sell orders.
We note that in a real-world deployment, more logic would probably be added to the matching.In particular, allowing for exchanges of variable amounts and include time-stamps such that the oldest orders get priority in case of multiple possible matches.

Functionality F Ident
For each session, F Ident interacts with servers P = {P1, . . ., Pn}, clients C = {C1, . . ., Cm} and also provides an interface to register external verifiers V.It is parameterized by a circuit C with inputs x (1) , . . ., x (m) and output y ∈ F g .S provides a set IP ⊂ [n] of corrupt parties and IC ⊆ [m] of corrupt clients.F Ident only interacts with P, C, V and S of the respective session sid.

3 . 4 .
Send (sign, sid, Cj|idj, vk) (receiving ρj) and (combine, sid, Cj|idj, ρj, vk) to F TSig for each Cj ∈ C. If any of them aborts then enter Abort without Output.For each a, b ∈ [ ], 1 ≤ a < b ≤ let C a,b be the clients swapping between La and L b .For Cj ∈ C a,b define the m ≤ m values hj = (Cj, δj, am src j , am trg j ) where δj is 0 if L src j = La and 1 otherwise.Compute y a,b ← compSwap(h1, . . ., h m ).If S sends (Abort, sid) enter Abort without Output.

FunctionalityF
SC (Part 1) a,c ) to F TSig for each c ∈ [r] and i ∈ [n].If any of the steps fails, then let I2 be the set of cheaters.Let C be the set of clients.If I2 = ∅ then run CC(∅, ∅), otherwise run CC(I2, C).
the public ledger (in our case represented by F BB and F SC ) such that (in i , Addr i ) ∈ Out i .-Thereexistsσ i ∈ Sig such that σ i is a valid signature of id|In|Out under Addr i according to the cryptocurrency's signature scheme (F Sig or F TSig ).Generating Transactions: A party controlling the corresponding signing keys for valid UTXO addresses Addr 1 , . .., Addr m containing values in 1 , . .., in m can generate a transaction that transfers the funds in these addresses to output addresses Addr out,1 , . .., Addr out,n by proceeding as follows:1.Choose a unique id ∈ {0, 1} τ .2. Choose values out 1 , . . ., out n such that Generate In, Out as described above and sign id|In|Out with the instances of F Sig or F TSig corresponding to Addr 1 , . . ., Addr m , obtaining Sig = {σ 1 , . . ., σ m }. 4. Output tx = (id, In, Out, Sig).
sid, coins(d)) by each honest Pi: 1. Send (keygen, sid) to F TSig .If F TSig returns a key vk then save it internally and continue, if it instead aborts then return coins(d) to each honest Pi and stop.
2. Update F Clock and wait for a message from S. If S sends coins(|I| • d) send (key, sid, vk) to each honest Pi, otherwise reimburse all honest Pi with coins(d).Enroll Client: Upon input (Enroll, sid, L src j , vk src j , am src j , L trg j , vk trg j ) from a client Cj ∈ C \ J or S if Cj ∈ J and if Init finished:1.If Cj was enrolled already then return.2.Send (Enroll, sid, L src j , vk src j , am src j , L trg j , vk trg j ) to S. If S sends (Ok, sid) then send (keygen, sid) to F TSig to generate vk ex j as well as (sign, sid, m) (obtaining ρ) and (combine, sid, m, ρ, vk) to obtain σ.3.If F TSig aborts then send (Abort, sid) to Cj.If it did not abort then send (Proceed?, sid, σ, vk ex j ) to the caller.If the caller was an honest Cj then wait for input (value, sid, am trg j , idj) where idj is a transaction id of an honestly generated transaction on L src j from vk src j to vk ex j with amount am src j .Send (InputProvided, sid, Cj) to S.Exchange: Upon input (Exchange, sid) by all honest Pi and if Init finished:1.Send (Clients?, sid) to S and wait for am src j , idj for each Cj ∈ J or alternatively for a message that Cj did not transfer to vk ex j .2. Send (Confirm, sid, {am src i , idi} i∈[m] ) to all servers in P. If no honest server Pi for i / ∈ I answers with (Confirmed, sid, {am src i , idi} i∈[m] ) (meaning a client did not make a transaction) enter Abort without Output.
5. Update F Clock .Then send (Success, sid, txa) to each Cj with La ∈ {vk src j , vk trg j }, send coins(d) back to each honest Pi and coins(|I| • d) to S. Then send (combine, sid, ta, ρ c a , vk ex c ) to F TSig .If F TSig aborted overall with the set of parties I2 ⊂ I cheating update F Clock .Afterwards send coins(d) to each honest Pi, coins((|I| − |I2|)d) to S, coins(|I |d/m) to each client Cj and return.3. Otherwise update F Clock , compute txa for each La, send (Success, sid, txa) to each Cj with La ∈ {vk src vk src j ) and determining idj as the hash of Inj, Outj. 4. For each Cj send (sign, sid, tj, vk ex j ) to F TSig and obtain ρj.Then send (combine, sid, tj, ρj, vk ex j ) to F TSig .If F TSig aborted overall with the set of parties I2 ⊂ I cheating then update F Clock .Afterwards send coins(d) to each honest Pi, coins((|I| − |I2|)d) to S and coins(|I2|d/m) to each client Cj. 5.If F TSig did not abort update F Clock .Compute txj for each Cj and send (Reimburse, sid, txj) to Cj, coins(d) to each honest Pi and coins(|I| • d) to S.
Clock twice and send (Abort?, sid) to S. If S responds with (Abort, sid, I1) where ∅ = I1 ⊆ I then update F Clock .Afterwards send coins(d) to each honest Pi, coins((|I| − |I1|)d) to S and coins(|I |d/m) to each client Cj. 2. If S did not abort then update F Clock .Afterwards for each La and c ∈ [r] send (sign, sid, ta, vk ex c ) to F TSig to obtain ρ c a (with the same notation as Open).j , vk trg j }, coins(d) to each honest Pi and coins(|I| • d) to S. Abort without Output: 1. Update F Clock twice.2. Send (AbortC?, sid) to S which responds with (AbortC, sid, J1, {idj} j∈J\J 1 ) where J1 ⊆ J. Then send (Abort?, sid) to S. If S responds with (Abort, sid, I1) where ∅ = I1 ⊆ I update F Clock , send coins(d) to each honest Pi, send coins((|I| − |I1|)d) to S and coins(|I |d/(m − |J1|)) to each Cj ∈ C \ J1. 3. If S did not abort then update F Clock .Afterwards for each Cj compute tj = (idj, Inj, Outj) by setting Inj = (idj, am src j ) and Outj = (am src j , • ( − 1) instances F a,b Ident where 1 ≤ a < b ≤ to accept inputs by clients who want to transfer between La and L b and run Init on each F a,b Ident .2. The servers P use F TSig to sample a common key vk.Furthermore each Pi uses F Sig to generate an individual public verification key vki, which it shares with all P. SC is in state init then each Pi first computes a signature σ vk i (t) on t using F Sig for the key vki and then sends (Post, sid, t, vki, σ vk i (t)) to F SC .Afterwards, each Pi sends (Lock-In, sid, coins(d)) to F SC updates F Clock .
3. Let t = (vk, { vki} i∈[n] , {Lj} j∈[ ] , {F a,b Ident } a<b a,b∈[ ] ).If F Upon learning the sets I, J of corrupted servers and clients S simulates honest servers P i and honest clients C j in a simulated instance of Π Ex .-S follows the protocol Π Ex but with dummy inputs for P i and C j .S will observe A's behaviour during the protocol execution and from it extract inputs that it sends to F EX on behalf of the dishonest servers and clients.-During Initialize S will forward all messages sent by A to F TSig for generating the key vk.It generates keys vk i for all the simulated servers and sends these to A. It then for each party sends a signature on t as in the protocol, where different values are signed by different honest parties if A sent different keys to different honest servers.S will additionally provide messages coins(d) by each simulated honest party to F SC .If F EX activates the clock and time progresses then it sends coins(|I| • d) to F EX , otherwise it aborts.During Exchange S follows what the honest servers would do in the protocol and forwards messages to F TSig accordingly.It aborts if the computation on any F Ident fails or if the sharing fails.Finally, it sends the respective message to F EX .-During Open either start the abort if F EX does so or obtain the outputs y a,b from F EX .In case that S obtains the output then make the output from F Ident to A appear to be the correct corresponding output and run their output phases 6 .Then forward all interactions towards F TSig of A. If a "done" message gets signed then let each honest server send it to F SC .Upon obtaining coins(|I| • d) back from F EX let F SC forward these to A. -If F EX runs Abort without Outputs S simulates the behavior of the honest servers by sending the signed messages that they learned during Enroll Client to F SC .Furthermore it fetches the transaction tx from F BB that the honest client made to send money to the burner address and puts it on F SC as an honest client does in the protocol.If A does not send certain messages to F SC then identify the respective sets J 1 , I 1 and send them to F EX .If F EX sends any coins(d) back to S then let F SC distribute these accordingly.-Simulate Abort with Output like Output without Abort is simulated.
-During Enroll Client S will simulate sign-up of honest clients based on the output of F EX by sending the respective message to A. It forwards all interactions of A to F TSig concerning the burner address.Ultimately it creates "fake" inputs for each honest C j to the respective F Ident instance.For all the dishonest clients S observes F SC as well as the instances of F BB .Upon receiving an enrollment message to all simulated honest servers it sends the respective message to F EX .Their inputs will be extracted from the respective instances of F Ident which can be observed by S. Alternatively send a message to F EX if a dishonest client neither provided any input nor made a transfer.-

Table 2 :
Complexity of the matching protocol implementation in SPDZ 2 k .
[26,33]puted on[26,33].Besides being used for deciding whether a buy and sell order should be matched, comparison is also the key component in most oblivious sorting algorithms.In particular, Batcher's Odd-Even Merge-sort [47, Sec.5.4.3], which our implementation uses, has comparison depth O(log 2 (m))) and uses a total of O(m log 2 (m)) comparisons.For this reason the overall round complexity of our concrete order-matching algorithm, C compSwap , ends up at O(log(k) • log 2 (m)) with multiplication gate complexity of O(k • m log 2 (m)).The communication complexity associated with a multiplication gate is O(k+κ) bits for SPDZ 2 k [33].Hence we get at most O((k + κ) • m) bit in bandwidth usage per round.The total amount used for each of the different choices of m and k by our implementation, including overhead by the framework, is expressed in Table

Table 3 :
Complexity of the (threshold) signatures required by Π Ex for its different phases.Time estimates are based on [41, Table 1].
Key Generation: Upon receiving a message (keygen, sid) from each Pi ∈ P or a functionality Fj ∈ F hand (keygen, sid) to the adversary S. Upon receiving (verification key, sid, SIG.vk) from S, if (•, SIG.vk) was not recorded yet then output (verification key, sid, SIG.vk) to each Pi ∈ P (or to Fj), and record the pair (P, SIG.vk).If SIG.vk was recorded before then output (Abort, sid) to S and stop.Share Generation: Upon receiving a message (sign, sid, m, SIG.vk) from all hon-If either is, then output an error message to S and halt.Else, let f = 1 if J = ∅ and f = f otherwise, record the entry (m, ρ, J, SIG.vk) in Sh, (m, σ, SIG.vk, f ) in Sig and return (shares, sid, m, ρ).Share Combination: Upon receiving a message (combine, sid, m, ρ, SIG.SIG.vk,0) in Sig.3.Else, if there is an entry (m, σ, SIG.vk , f ) ∈ Sig recorded, then let f = f .4. Else, let f = φ and record the entry (m, σ, SIG.vk , φ) in Sig.Return (verified, sid, m, f ).