P2DEX: Privacy-Preserving Decentralized Cryptocurrency Exchange

Abstract

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 efficient universally composable privacy preserving decentralized exchange where a set of servers run private cross-chain exchange order matching in an outsourced manner, while being financially 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 identified and punished, while honest clients do not to lose their funds. For the first time in this line of research, we report experimental results on the MPC building block, showing the approach is efficient enough to be used in practice.

This work was supported by the Concordium Foundation, by Protocol Labs grant S²LEDGE and by the Independent Research Fund Denmark with grants number 9040-00399B (TrA²C) and number 9131-00075B (PUMA).

Appendix A Smart Contract Functionality \(\mathcal {F}_{\mathsf {SC}}\)

We now describe the smart contract on a high level, meaning its different states and state transitions. This is to ease understanding, the full description will be presented later. The Smart Contract will have 7 different states $\mathtt {init},\mathtt {ready},\mathtt {abort},\mathtt {ok1},\mathtt {ok2},\mathtt {reimburse1},\mathtt {reimburse2}$ where $\mathtt {init}$ is the initial state. State transitions are performed whenever the global clock $\mathcal {F}_{\mathsf {Clock}}$ changes and depending on the messages that are present on the ledger that $\mathcal {F}_{\mathsf {SC}}$ acts upon.

Fig. 10.

The stateful smart contract functionality $\mathcal {F}_{\mathsf {SC}}$.

Fig. 11.

The stateful smart contract functionality $\mathcal {F}_{\mathsf {SC}}$.

• $\mathtt {init}$ If a tick happens, then check if all servers signed the same $\mathsf {vk},\widehat{\mathsf {vk}}_{{1}},\dots ,\widehat{\mathsf {vk}}_{{n}}$ using their individual $\widehat{\mathsf {sk}}_{{i}}$ and that $\mathcal {P} _i$ sent $\mathsf {coins}(d)$. If so then change state to $\mathtt {ready}$, otherwise reimburse all servers and stay in $\mathtt {init}$.

• $\mathtt {ready}$ If a tick happens and a message “done” is present, signed by $\mathsf {sk}$, then reimburse all servers and set the state to $\mathtt {init}$. If a tick happens and a message “abort” is present, signed by a $\widehat{\mathsf {sk}}_{{i}}$ that initialized the contract, then change the state to $\mathtt {abort}$.

• $\mathtt {abort}$ If a tick happens and a message “done” is present, signed by $\mathsf {sk}$, then reimburse all servers and set the state to $\mathtt {init}$. Else, if a tick happens and a message “ok”, signed by $\mathsf {sk}$, is present, then change state to $\mathtt {ok1}$. Else, if no such message is present at the tick, then change to $\mathtt {reimburse1}$.

• $\mathtt {ok1}$ Call Test Reveal on each $\mathcal {F}_{\mathsf {Ident}}^{a,b}$. If no parties J are returned as cheaters by Test Reveal then check if for each $\mathcal {P} _i$ and each $\mathcal {F}_{\mathsf {Ident}}^{a,b}$ a message $\mathbf {s}_i^{a,b}$ signed by $\widehat{\mathsf {sk}}_{{i}}$ is present. If indeed, then verify the output for each $\mathcal {F}_{\mathsf {Ident}}^{a,b}$ using Verify. If any of the aforementioned steps fails, then let $I_1$ be the set of cheating servers. If $I_1=\emptyset$ then change the state to $\mathtt {ok2}$. If $I_1\ne \emptyset$ then identify all the m clients by finding all messages of the form $(\mathcal {C} _j|\mathcal {L}_{{j}}^{\mathsf {src}}|\mathsf {am}_{j}^{\mathsf {src}}|\mathsf {vk} _{{j}}^{\mathsf {src}} |\mathsf {vk} _{{j}}^{\mathsf {ex}}|\mathcal {L}_{{j}}^{\mathsf {trg}}|\mathsf {vk} _{{j}}^{\mathsf {trg}} )$ that are signed by $\mathsf {sk}$. Furthermore, identify all the transaction ids $\mathtt {id}_j$ to burner addresses $\mathsf {vk} _{{j}}^{\mathsf {ex}}$ signed by $\mathsf {sk}$. For each party in $I_1$ share the deposit among all m clients. Then return the deposit of the parties in $[n]\setminus I_1$ and change the state to $\mathtt {init}$.

• $\mathtt {ok2}$ Compute for each $\mathcal {L}_a$ in clear text the values $\mathtt {id}_a,\mathsf {In}_a,\mathsf {Out}_a$ from the outputs of each $\mathcal {F}_{\mathsf {Ident}}^{a,b}$ as well as the client registration data and transaction ids using $\mathtt {makeTX}$. For each $\mathcal {L}_a$ check if each $\mathcal {P} _i$ sent shares of $\mathsf {Sig}_a$ signed with $\widehat{\mathsf {sk}}_{{i}}$. If so, then check that each share of $\mathsf {Sig}_a$ is valid using $\mathcal {F}_{\mathsf {TSig}}$ by running Share Combination. If any of the previous steps fails, then let $I_2$ be the set of cheaters. If $I_2=\emptyset$ then reimburse all $\mathcal {P} _i$ with their deposit and change the state to $\mathtt {init}$. Otherwise identify all the m clients by finding all client registration data and transaction ids to burner addresses signed by $\mathsf {sk}$. For each party in $I_2$ share the deposit among all m clients. Then return the deposit of the parties in $[n]\setminus I_2$ and change the state to $\mathtt {init}$.

• $\mathtt {reimburse1}$ If a tick happens, then continue to $\mathtt {reimburse2}$. Intuitively, during this step all clients that get reimbursed are already fixed so the servers will create the signatures on reimbursement transactions.

• $\mathtt {reimburse2}$ If a tick happens, consider all messages provided by each $\mathcal {P} _i$ to $\mathcal {F}_{\mathsf {SC}}$ that are of the form $(\mathcal {C} _j|\mathcal {L}_{{j}}^{\mathsf {src}}|\mathsf {am}_{j}^{\mathsf {src}}|\mathsf {vk} _{{j}}^{\mathsf {src}} |\mathsf {vk} _{{j}}^{\mathsf {ex}}|\mathcal {L}_{{j}}^{\mathsf {trg}}|\mathsf {vk} _{{j}}^{\mathsf {trg}} )$ that are signed by $\mathsf {sk}$ as well as all messages $(\overline{\mathtt {id}}_j|\overline{\mathsf {In}}_j|\overline{\mathsf {Out}}_j,\mathsf {vk} _{{j}}^{\mathsf {src}} )\in \mathcal{M}$ (transaction ids) where $\overline{\mathsf {In}}_j=(\mathsf {vk} _{{j}}^{\mathsf {src}} ,\mathsf {am}_{j}^{\mathsf {src}})$ and $\overline{\mathsf {Out}}_j=(\mathsf {am}_{j}^{\mathsf {src}},\mathsf {vk} _{{j}}^{\mathsf {ex}})$. If there are multiple messages for $\mathcal {C} _j$ then ignore $\mathcal {C} _j$ Locally compute for each $\mathcal {C} _j$ the transaction $\mathsf {tx}_j$ to reimburse $\mathcal {C} _j$. Therefore set $\mathsf {In}_j=(\overline{\mathtt {id}}_j,\mathsf {am}_{j}^{\mathsf {src}})$, $\mathsf {Out}_j=(\mathsf {am}_{j}^{\mathsf {src}},\mathsf {vk} _{{j}}^{\mathsf {src}} )$ and set $\mathtt {id}_j$ as the hash of both. If each $\mathcal {P} _i^j$ provided $\rho _j^i$ then check using Share Combination on $\mathcal {F}_{\mathsf {TSig}}$ that it outputs a valid signature $\mathsf {Sig}_j$ on $\mathtt {id}_j,\mathsf {In}_j,\mathsf {Out}_j$. If all such $\mathsf {Sig}_j$ are valid signatures then reimburse all $\mathcal {P} _i$ and set the state to $\mathtt {init}$. If some signature shares are not valid or some shares $\rho _j^i$ are not present on $\mathcal {F}_{\mathsf {SC}}$ then let J be the set of cheaters. Reimburse all servers $[n]\setminus J$ and distribute the deposit of the parties of J evenly to all $\mathcal {C} _j$. Then set the state to $\mathtt {init}$.

Formalizing the Smart Contract. We use a combined smart contract and public ledger functionality $\mathcal {F}_{\mathsf {SC}}$. It is an extension to $\mathcal {F}_{\mathsf {BB}}$, tailored to be combined with an MPC protocol and similar to the functionality used in [5]. For technical reasons, $\mathcal {F}_{\mathsf {SC}}$ has a hard-coded reference to the publicly verifiable MPC functionality $\mathcal {F}_{\mathsf {Ident}}$ in order to be able to verify outputs. $\mathcal {F}_{\mathsf {SC}}$ is described in Fig. 10 and Fig. 11 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.