Cryptocurrency systems based on decentralized ledgers, require each participant to keep a local copy of the transaction history, in order to prevent double-spending without relying on a centralized party. This design however exposes users to privacy concerns, as all transaction information becomes publicly available .
To address this problem, several solutions (e.g., Cryptonote , Zcash , Monero , and Grin ), proposed the use of encrypted notes (or UTXOs), and focus on privacy issues at the individual payment transaction level, by preventing the disclosure of payment related information, e.g., the recipient wallet address, and the amount of cryptocurrency transferred. However, privacy preserving or oblivious fair exchange of crypto coins/assets, which is essential for a thriving ecosystem, have been so far largely ignored.
In this paper, we develop a unified framework to support both privacy enhanced payment transactions and a fair exchange of crypto assets without using centralized mixing services, escrow based or off-chain/site-chain approaches . By exchange we mean giving a certain digital asset and receiving another asset in return. The giving and the receiving can be of identical types, e.g., Alice exchanges a ten-dollar note in several one-dollar notes with Bob. They can also be different types of digital assets, for instance, the exchange between one type of crypto asset with another type of crypto asset. Such exchanges are essential for ICOs, as investors need to buy a newly created currency using other currencies. In 2018 alone, there were more than 1,000 ICOs, with a total value of exchange transactions of about 8 billion USD 111https://www.icodata.io/stats/2018.
More specifically, we propose a ledger-based multi-asset system, designed to support both the private exchange (swap) of crypto-assets and regular spending operations. Our solution aims at satisfying several requirements. First, the exchange should to be atomic, i.e., either both or none of the transfers are executed. Second, the system should support exchange between different types of assets, which we call private notes. Third, the exchange needs to be private, i.e., information posted on the blockchain should not leak the identities of the parties involved in the exchange, or the nature of the exchange (e.g., types and amount of assets, status of the success of the exchange). The proposed scheme introduces the concept of sibling note and negative value to allow the linkage of discrete steps in an exchange to guarantee the fairness, and leverages zero-knowledge proof to hide information of exchange transactions while allowing the public to verify the validity. Since a different zero-knowledge proof is required for each step in the exchange, we also utilize a mechanism to merge different types of zero-knowledge proofs into a single format so an adversary cannot learn even the type information of a step in the exchange process.
In summary, the paper provides the following contributions:
We develop a unified and formal framework of privacy preserving exchanges and payment transactions of crypto assets on a decentralized ledger that satisfies security and privacy requirements;
We propose a concrete construction of privacy-preserving asset exchange scheme that supports multiple types of crypto assets and meets the formal definitions; and
We describe and discuss implementation details of the designed scheme using zero-knowledge based cryptocurrency as an exemplary platform.
2 Related Work
In this section, we briefly review related works. Typically, the exchange of privacy coins can be completed using a centralized intermediary or escrow service provider. The escrow services are basically third party implementations which allow for fast off-chain completion of the transaction and it has been also implemented in TumbleBit .
Information exchange. For fair information exchange, Alice and Bob exchange their secret information in a fair way: either they learn each others secret at the same time, or they both keep their secrets undisclosed. It has been proved that this is not feasible without the involvement of a third party , and some works have been done on utilizing the blockchain as a broker to facilitate such exchange . An important difference between information exchange and crypto-asset exchange is that the latter requires the transfer of ownership, which is more than fair information exchange. For example,
If Alice and Bob exchange information of their assets, they still own their own assets and an extra protocol is required to enforce the transferring of ownership;
If Alice and Bob exchange information that controls the assets (e.g., private key to spend the asset), they are facing a racing condition as both of them still hold their own information after the exchange.
Furthermore, most information exchange methods do not consider the requirement of privacy. Without loss of generality, in this paper, crypto assets include cryptocurrencies and tokenized assets. Exchange can occur between any type of digital assets secured by a distributed ledger based transaction system. Further, we assume an environment of privacy assets, for instance, systems based on encrypted notes. The notes and payment transactions are protected with privacy enhancement such as zero-knowledge proving protocols. Towards these objectives, we extend data models and protocols of existing privacy coin schemes, for instance, Zcash/Zerocoin by introducing asset types as an extension to note format for supporting multiple asset types. In addition, we modify the data models and transaction protocols to support oblivious and fair exchanges of crypto notes between users. Our goal is to enable the exchange of privacy enhanced crypto assets with the following main characteristics: exchange operations are atomic; transactions are publicly verifiable; they are oblivious without disclosing information of the exchange operations.
Zero knowledge execution (). Zero knowledge can protect the privacy from not only the transaction information but also computation (if it exists). Sean Bowe et al. propose a decentralized-ledger-based system that allows transactions to hide all information about the offline computations but any node can still validate the computations even without whole details . A use case of cryptocurrency exchange is mentioned in their research. It leverages and supports exchange. However, the system needs to execute a script to verify a preset list of conditions before sending the notes. In another word, it has to wait until it gets expected results from the commitment pool. In contrast, in our approach, notes are sent right away. It reduces the delay of transactions. And we have seen a lot of implementations of the Zero-Knowledge proof in different areas like in the Privacy preserving Auditing. There also have been research on having a confidential asserts, scheme where a single node can handle multiple assert types
Decentralized exchange. Zcash and Zcoin represent a few of the implementations of the zero-Knowledge proof for privacy where connection between the sender and receivers is cut off. It leaves no trails of both the entities involved in payment transaction. In recent times, we have seen several exchange systems built over the blockchain that somewhere in their systems implements the zero-knowledge proof. TEX  is one of the proposed exchange systems which claims to be better than the existing decentralized exchanges (DEX). The proposed TEX system operates in two layers and proposes to execute a trade without the requirement of withholding assets. Other than the exchange mentioned above we have seen a rising number of exchange systems being introduced, and one of them is the Zerocoin Decentralized Exchange (ZDex) which is built over the PIVX platform which in turn, in theory, is a cold fork of the Dash. In its current state, it can support the Bitcoin cash, Litecoin, Dash, Zcash. However, one of the significant drawbacks in this implementation that we have gone ahead and addressed in our approach is that ZDex in its current state doesn’t support atomic swap of digital assets. There are also works on utilizing trusted computing technology to improve the performance and security of smart contract , which can be leveraged to implement exchange or even provide privacy protection. However, this type of approaches rely on the trust of the hardware and the vendor behind.
3 Overview of Publicly Verifiable Oblivious and Fair Exchange
In this section, we provide an overview of the proposed privacy preserving exchange mechanism on a decentralized ledger.
3.1 Problem Statement
At a high level, the system is aimed to meet the following requirements.
Decentralized privacy ledger with multi-asset support (for instance zero-knowledge based system with the capability to support multiple types of coins, currencies, or tokens).
Support of privacy protected payment transactions similar to Zcash/Zerocoin (e.g., shielded to shielded payment transactions).
Publicly verifiable means that the public should be able to verify the validity of all transactions including privacy protected payment transactions.
Fair exchange. Fairness means that an asset exchange operation between two users is atomic. Although the operation may involve multiple payment steps. At the end, either the exchange succeeds with ownership swap of each participants digital asset, or the operation terminates so that each participant still keeps his/her own asset before the exchange.
Oblivious exchange. Oblivious means that all transactions (both payment transactions and exchange transactions) recorded on the ledger and verified by the public should appear to be identical (indistinguishable from one another) and reveal no information or knowledge about the exchange operation including: the presence of exchange operation, users/accounts involved in the exchange, types of assets and corresponding amounts in the exchange. This means that exchange transactions should be hidden from the shielded payment transactions. Based on history of transactions, an adversary should not be able to separate transactions for fulling exchanges from other shielded payment transactions.
Unified transaction system for both payment and exchange operation. The system should not use separate protocols or algorithms that are unique for payment transactions and exchange operations. All transactions should be verified using the same mechanism and an identical procedure.
We assume that there are more than one type of crypto assets in the system and owners of two different types of assets, Alice and Bob, who do not fully trust each other decide to exchange the ownership of digital assets (e.g., privacy coins, privacy tokens) on the decentralized ledger.
If privacy is not a concern, we can easily implement a fair exchange operation using a smart contract, and the distributed ledger can guarantee the atomic property of the operation, i.e., either the operation succeeds that Alice and Bob get the other’s digital asset, or the operation fails that each one still keeps his/her own assets. However, such an approach does not provide any privacy protection. Every node in the system can see the exchange information.
It is worth mentioning that all transactions involved in an exchange operation should be publicly verifiable (verified on the chain by nodes of the ledger network using consensus) and all transactions should be oblivious. In other words, all transactions, regardless of their nature (e.g., payment transactions, different steps of exchange operations) should be indistinguishable to the public who verify them. These requirements exclude alternatives such as setting an off-chain payment channel for exchange.
To simplify discussions and experiments, we use zero-knowledge proof based privacy coin (e.g., Zcash, Zerocoin) as baseline design. We extend the privacy coin data models and proving systems to support multiple assets, and oblivious fair exchange. Exchange is realized by a pre-defined sequence of privacy protected (shielded) payment transactions.
3.2 Zero Knowledge Proof based Currencies
A zero-knowledge proof of knowledge is a protocol in which a prover can convince a verifier that some statement holds without revealing any information. Roughly speaking, a zero-knowledge proof involves two parties, the prover and the verifier. For a statement, the prover can generate a proof to convince the verifier of the correctness of the statement. In this process, the verifier cannot learn anything except the fact that the statement is true (zero-knowledge feature). Zero-knowledge proofs can be either interactive or non-interactive. Interactive zero-knowledge proofs [16, 17] requires the prover to communicate with the verifier over multiple rounds to finish the proof. Non-interactive zero-knowledge proofs (NIZK) [18, 19, 20] do not require multiple rounds of interactions between prover and verifier and are more suitable for scenarios where it is difficult for these parties to be online at the same time.
An important tool related to NIZK is zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARK) [21, 22, 23]. We refer the readers to  for a formal definition of zk-SNARK. Leveraging practical ZK-SNARK, Zcash implements a Decentralized Payment System with strong protection of transaction integrity and anonymity built from collision-resistant hash (CRH) functions, commitment schemes, and pseudo-random functions. When a crypto-note (UTXO) is spent, the spender needs to create a zero-knowledge proof that there is a corresponding note commitment in the pool of commitments without disclosing which one it is. The proof also shows that the transaction is consistent and that the user knows all the secret keys, without revealing any additional information.
3.3 An Example of Exchange Operation
The proposed oblivious and fair exchange scheme extends Zcash data models, for instance, crypto-note definition, referred as a note for simplification, and the payment protocol. This subsection describes the high-level design concept with a concrete exchange example.
To support multiple assets, the note format is expanded to include a new integer attribute that specifies the types of digital assets (e.g., coins, tokens). Here we use colors to represent different types of assets (e.g., red coin, green coin, yellow coin). In addition, there are two types of notes, called primary note and sibling note. In Figure 1, note with a green surrounding box is a primary note; and note with a red surrounding box is a sibling note. A sibling note is uniquely associated with a primary note. Each payment transaction includes input notes and output notes where input notes are consumed and output notes are created. A primary note can be consumed by itself in a payment transaction while the associated sibling note can only be consumed either after the primary note has been consumed already in the past or together with the primary note in a transaction.
Furthermore, each note contains a debt part (the type of asset and amount) which requires that when the note is consumed in a transaction, the debt part has to be canceled out by additional note with sufficient value that matches with the debt (both asset type and amount). For instance, if a note contains a debt of five red coins, when it is consumed (spent), the user has to mix it with a note containing at least five red coins as inputs.
Assume that Alice wants to exchange five green coins with Bobs three yellow coins. The sequence of actions may be the following:
Alice initiates the exchange operation by converting her assets into a pair of notes. In the first transaction, she provides two input notes (one with three green coins and one with two green coins). The transaction outputs two notes, one primary note with five green coins and three yellow coins as debt; and a sibling note with three yellow coins. Nodes in the ledger network verify the transactions and store the notes on the ledger.
The primary note is encrypted and shared between Alice and Bob. Either Alice or Bob can spend the primary note.
If Bob wants to complete the exchange, he issues a new transaction using the received primary note from Alice and one of his notes as inputs. In this case, his input note contains four yellow coins. The transaction produces two output notes, one with five green coins and the second one with one yellow coin (after canceling the three yellow coin debt embedded in the note received from Alice).
After Bob spends the note sent by Alice, Alice can spend the associated sibling note that contains three yellow coins, which completes the exchange.
In case that Bob does not spend the note received from Alice within a bounded time limit, Alice can cancel the exchange by creating a new transaction that spends both the primary note and the associated sibling note, which cancels out the three yellow coin debt. The output notes will contain the five green coins that she puts in the primary note shared with Bob. As a result, the exchange is terminated. Bob can no longer spend the primary note received from Alice.
Here in this section, we skip discussions on how the protocol can protect the privacy of each transaction step, ensure fairness and exchange atomicity, and prevent cheating by either Alice or Bob. Details of the protocol design and verification algorithms, as well as security analyses, are provided in the following sections of the paper.
4 Definition of Oblivious Multi-Asset Protocol (OMAP) with Fair Exchange Support
The notations of OMAP are based on extending the notations in Zcash [13, 24]. In this paper, for simplification, we apply zk-SNARK and original Zcash design [13, 24] to achieve exemplary implementation of OMAP. However, it is worthwhile pointing out that it is possible to realize OMAP using other zero-knowledge proof systems, for instance, zk-STARK , bulletproof , or alternative approaches such as . Discussion applying these different systems is orthogonal to the scope of this work, which focuses primarily on protocol design of privacy preserving multi-asset transaction and exchange system.
4.1 Data Models
We extend the definition and data format of Zerocoin and Zcash. The notations are based on Zcash specifications. CRH stands for collision-resistant hash algorithm and PRF stands for pseudo-random function.
Multi asset ledger: There is a multi-asset ledger, , which records a sequence of transactions in append-only mode. The ledger supports multiple types of tokens or assets using extended note format, described below. The ledger comprises ordered blocks created from a genesis block under a consensus mechanism. Each block has a block height. Further, we assume that blocks are generated with a relatively constant speed. Details of consensus mechanism and block generation can be either based on or follow Zcash design. Although our experiments are based on Zcash implementation, OMAP and can be adapted to any distributed ledger based systems such as one based on PoS.
Public parameters: In the case of the experiments in this paper, the system uses the same set of public parameters as Zcash design. They are generated either by a trusted party at the beginning or through a Multi-Party Computation ceremony [28, 29]. If OMAP is implemented over a proving system that doesn’t require trusted setup, the public parameters can be based on common public strings appropriate for the proving system.
Payment address and note format: In this work, we use the same design of payment address pair (, ) where is used as spending key. For receiving shielded payment, a user needs to scan ledger using . The algorithm is similar to the one described in Zcash blockchain scanning. For each type of asset or token, there is a . In this experimental implementation, the value is stored in levelDB.
An OMAP note, , is similar to Zcash note with extensions to support multiple assets and oblivious exchange. A note is associated with the following attributes:
: spending key
: type of note (primary or sibling note)
: color of primary coin (type of asset)
: value of primary coin
: color of debt coin (type of asset)
: debt coin amount
: block height threshold
: used to compute nullifier (disclosed to the public after spending)
: unique value for a pair of matching notes
: note commitment
Figure 2 shows an example note. Attributes including , , , are the same as defined by Zcash design. For each note, attribute specifies the type of note (primary or sibling). For simplifying the discussion, we refer the type of asset as color, for instance, black coin, red coin, which means that black coin and red coin represent different types of assets. The type and amount of primary asset are represented as: and . Size of field determines the maximum number of assets supported by OMAP. For each note, there is a second pair of asset type and the amount that represent debt embedded in a note, (, ). When both and are zero, it means that the note is a regular note. When both and are not zero, it means that when the note is spent, it has to be paired with a note with primary asset type matching with and the amount greater than or equal with . The second pair (, ) is introduced for the purpose to support the atomic exchange of different types of assets between two OMAP users.
Attribute is a block height threshold, which is used for setting a time limit of asset exchange or swap. It is a threshold value that can be configured to decide when the counterparty in exchange has to spend a received note in order to move forward to the next step. When a user initiates an exchange, the user will create a note pair, see example in Figure 3. One note has set as zero (primary note) and the second one with set to 1 (sibling note). Attribute is a unique value for each pair of matching notes, which means that a primary note and its sibling note share the same value . Calculation of is based on a CHR with a unique random input computed from the input notes (specific to a transaction). In addition, for each pair of notes (primary and its sibling), the value of needs to be the same; = = ; and = 0.
When a note is spent, a nullifier value, , will be created using attribute as input where is determined by . OMAP enforces that nullifiers must be unique in order to prevent double-spending. In addition, uniqueness of nullifiers are used to support the atomic exchange of assets (see section 5).
Note commitment and nullifier Tree. OMAP uses incremental Merkle tree of fixed depth for note commitments and nullifiers. Different from Zcash where nullifiers are kept only for preventing double-spending, OMAP maintains a joint Merkle tree, , that includes both note commitments and nullifiers. Alternatively, there could be separate note commitment tree and nullifier tree so that there will be two roots, one for note commitment tree and the second one for nullifier tree. In this work, we assume that the two trees are combined.
Each commit or nullifier has a (path, pos) where pos is position in the tree. Leaf node is in the tree with given root rt = , where M .
An Oblivious Multi-Asset Protocol with Exchange Support consists of algorithms (, , , , , ) defined below.
: Based on security parameter , it creates public parameters defined as (, , , ) where and are a pair of proving and verifying key for JoinSplit transactions (also see section 5).
: Given public parameters , it creates payment address pair (, ) where is used as spending key. A user can create arbitrary number of such address pairs.
: Given public parameters , a note , asset type color, value , a proof , it appends note to the ledger , or output .
: It takes as inputs, public parameters , Merkle tree root , two input notes and , the corresponding spending keys and , two output addresses and , public value and asset type (color), and , ledger , it creates two output notes, and , and a transaction .
(, , , ): Given public parameters , Merkle tree root , a JoinSplit transaction , two notes and , and ledger , it appends , and to the ledger, or output .
(, , ): Given public parameters , Merkle tree root , recipient key pair (, ), and the ledger , it outputs received note , or output .
Note that in this work, we restrict to cases of two input notes and two output notes. Spending cases of more than two input notes or two output notes can be reduced to transactions with two notes as input and output, subject of future extension and research. Similar to the Zcash design, input note or output note can be dummy note (without associated note commitment). In the case of dummy note, the asset type is zero.
Refer to  for a complete description of notations in the zero-knowledge proving system used by Zcash. The description is based on extending Zcash note format and operations. Here we focus on algorithms and definitions that are extended or modified to support oblivious and fair exchange through transactions. Definitions that are not changed can be found in the original Zcash publication and implementation specification.
5 OMAP Protocol
The protocol is built by extending the design of zero-knowledge based privacy payment system such as Zcash. These privacy oriented cryptocurrencies apply zero-knowledge proving system as the underlying building block to protect privacy. A zero-knowledge proving system is a cryptography protocol that allows proving a particular claim/statement, dependent on two input datasets, public and witness, without disclosing information about the witness input other than that included in the claim/statement,
A zero-knowledge instance ZK defines :
ZK proving key, ZK.ProvingKey -
ZK verifying key, ZK.VerifyingKey -
a key generation algorithm for creating and
public input, ZK.PublicInput -
witness, ZK.Witness -
proofs ZK.Proof -
set of satisfying inputs where ZK.SatisfyingInputs ZK.PublicInput ZK.Witness
a proving algorithm ZK.Prove that produces ZK.Proof from and ZK.SatisfyingInputs
a verifying algorithm ZK.Verify that accepts or rejects a statement based on ZK.PublicInput ZK.Proof
A zero-knowledge proving system needs to satisfy the following security requirements:
Completeness: for security parameter , a , arithmetic circuit , and any (, )
(satisfying inputs), honest prover can convince the verifier with probability.
Succinctness: honestly generated proof has bits and Verify(, , ) runs in the ().
Proof-of-knowledge: If the verifier accepts a proof output by a bounded prover, then the prover knows witness for the given statement.
5.2 Transaction Algorithms
For completeness, this subsection lists the main algorithms. Additional details and definitions can be found in Zcash specification. The main extensions are related to JoinSplit transaction. In addition to one-way payment (shielded to the shielded transaction of Zcash note), JoinSplit is expanded to support additional spending/transaction cases for achieving atomic and oblivious exchange of different types of assets (notes). As described earlier, the design is extended to support multiple types of assets such as a variety of coins or tokens.
: It takes as security parameter and outputs public parameters as following.
compute at security parameter
compute (, ) = KeyGen(, )
output = (, , , )
and are a pair of proving and verifying key for JoinSplit transactions. In the design and experiment described in this paper, follows the same Zcash algorithm for constructing public parameters.
: It takes public parameters as input and creates a pair of transmission key (, ) and receiving key (, ) where a note sent to a recipient is encrypted using and it is retrieved by the recipient from the ledger using .
In case of initializing the first JoinSplit transaction for an exchange operation, sender and recipient share the same spending key for spending the primary note. In this case, can be created from a shared secret between the sender who initiates the exchange and recipient, for instance = where = and PRF can be SHA-256.
: It takes public parameters , public address pair (, ), , asset , value where (1, …, ) and (0, …, ). It appends note to the ledger , or output . This algorithm is used to mint notes of different asset types based on the public values (each asset type and amount) and put the notes on .
: It takes as inputs, public parameters , Merkle tree root , two input notes and , the corresponding spending keys and , two output addresses and , public value and asset type (color), and , ledger . it creates two output notes, and , and a transaction .
To support asset exchange, there are different spending cases for JoinSplit transaction. Combination of these cases can be applied to achieve atomic exchange of assets between users. The list of JoinSplit spending cases and details are described in the following section. Here we focus on operations and procedures common to all the spending cases. These include:
for each input note, compute nullifier = () = SHA-256()
create signature key pair = where signature scheme is sUF-CMA (e.g., Ed25519)
for each new note, sample
set = = SHA-256()
compute note commitment = (, , , , , , , , , ) where COMM can be SHA-256
set new note as = (, , , , , , , , , , )
compute old note spending signature =
encrypt new note as =
set public input = (, , , , , , , , , , )
set witness = (, , , , , , , , , , , , , , , , , , , )
compute proof = Prove(, , )
set transaction message = (, , , , )
set message signature =
= (, , , , , , , , ) where
* = (, , , , , , )
In , the data fields are defined as:
and , N=1 or 2: Merkle tree paths of old notes
, N=1 or 2: old notes
, N=1 or 2: old note spending key
: random seed
: old note is dummy note or not
: new notes
and : Merkle tree path and position of associated note with one of the old notes (primary and sibling pair)
: associated note with one of the old notes (primary and sibling pair)
: spending key of the associated note (primary and sibling pair)
and : Merkle tree path and position of associated note nullifier (primary and sibling pair)
: associated note nullifier (primary and sibling pair)
When generating , the circuit verifies spending case specific constraints that will be described in the next section. There are checks common to all JoinSplit spending cases including:
Merkle path validity: valid tree path from NoteCommit to rt
Nullifier integrity: =
Spending key validity: =
Uniqueness of : =
Note commit: = NoteCommit
: It takes public parameters , Merkle tree root , a JoinSplit transaction , two notes and , and ledger , it appends , and to the ledger, or output . The algorithm does the following:
output if any of the following is true:
or appears on
Merkle root rt not on
doesn’t match with
: Given public parameters , Merkle tree root , recipient key pair (, ), and the ledger , it outputs received note , or output . The algorithm follows Zcash design. It scans the ledger and outputs received note for each JoinSplit transaction.
6 Design of Privacy Preserving Fair Exchange
In this section, we provide the details of a concrete privacy preserving exchange scheme implemented over ZK based privacy multi-asset ledger. A fair exchange between users is achieved through multiple JoinSplit payment transactions of private assets.
6.1 Overview of Transaction Workflow
Asset exchange is achieved using a sequence of extended JoinSplit transactions. The scheme is designed to ensure fairness, correctness, and privacy of the exchange operations. Fairness means that the entire operation (sequence of JoinSplit payments) satisfies atomicity. Correctness requires that the system should maintain a balance of assets during exchange transactions. Privacy means that all JoinSplit transactions recorded on the ledger and verified by the public should appear to be identical (indistinguishable from one another) and reveal no information about the exchange (e.g., users involved, asset types, amounts, exchange status).
Atomicity is critical for the privacy-preserving exchange operation. It does not mean that the exchange of assets needs to be completed using one step. It requires the exchange/swap to be fair, i.e., at the end of the exchange, the operation either fails and two parties get their notes back, or succeeds that each party gets the other’s note. Figure 5 illustrates the workflow of an exchange, where each step involves a shielded JoinSplit transaction. The flow may be affected by actions of the participating parties. Further details of each transaction case are described next.
6.2 Transactions for Supporting Exchange
OMAP achieves exchange of assets with privacy between two parties using JoinSplit transactions. In order to support fair exchange, the JoinSplit transaction protocol described in Zcash design is extended with new spending scenarios. Accordingly, the zero-knowledge proving system for JoinSplit instance is also extended to include new constraints for each new type of JoinSplit spending scenario.
OMAP extends note format with new attributes. As a result, it creates multiple JoinSplit spending types. The number of JoinSplit scenarios depends on, type of each input note (primary or sibling), type of each output note (primary or sibling), the value of the debt part in input notes (no debt or with debt). With the restriction of two input notes and two output notes, there are eighteen spending scenarios when ignoring the order of note types. This means that changing the position of a note within inputs or outputs will not affect the spending scenario (otherwise there will be total of thirty-two spending scenarios. Of the eighteen spending scenarios, there are eight allowed cases. They are shown in Table 1. The subsequent discussion provides details of each new spending case, in particular, constraints that must be satisfied by the zero-knowledge proof.
|Input Types||Debt?||Output Types||Cases|
|No||Default shielded payment transaction|
|YES||Case 5 or Case 2|
Default shielded payment transaction: This is the case of the original JoinSplit transaction where one user sends notes to another user. Its definition is identical to JoinSplit transaction described in the Zcash design.
Exchange initialization: Without loss of generality, we assume that Alice initializes an exchange process. In this case, the ZK proving algorithm needs to show that the satisfying instance can meet the following constraints in addition to the requirements common to all JoinSplit transactions. Satisfying conditions for the transaction instance include:
Satisfying conditions determine specific requirements for the input and output notes during a transaction. During proof generation, it also helps the system to select an appropriate routine (sub arithmetic circuit) to execute. Suppose a note can be denoted simply as ; and Alice creates 5 units of green note (color code: 3) to exchange 7 units of red note (color code: 2) with Bob, we have:
Note that output note (sibling note) cannot be spent unless output note is spent already or spent at the same time. has a negative part where and . Additional satisfying conditions for this case, besides the original verification of privacy JoinSplit : When , and the second note is not a dummy note, the proving algorithm verifies:
When or , the proving algorithm verifies similar sets of satisfying conditions as additional sub-cases under this transaction scenario.
Either Alice or Bob can spend the created primary note. This means that both of them have access to the same note spending key. This can be achieved using several approaches. Both can either run a secret sharing protocol offline or encrypt exchanged messages using each other’s address public key and store ciphertexts on the ledger or as part of the encrypted memo associated with a note.
Exchange cancellation by the initiator: The initiator, Alice, is free to cancel the swap before the other party takes actions (the system can enforce that Alice can only cancel after a pre-determined time limit specified as block height threshold). This is equivalent to the case that Alice starts a second JoinSplit transaction to get her notes back before Bob does anything. In case of a cancellation transaction, the proving algorithm verifies the following satisfying conditions for the transaction instance:
If Alice issues a new transaction to recover 5 units of green note and cancel the exchange, we have:
When , the proving algorithm verifies the sets of satisfying conditions.
Similarly, additional transaction sub-cases cover when and due to the situation that notes may change order of positions.
Counterparty response with transaction: In order to spend the note that he receives and complete the exchange, Bob needs to handle the note from Alice with debt. He must spend one of his notes that can cancel out the debt encoded in the note (both type of asset and amount). The requirement is reflected in the following satisfying conditions by the proving algorithm for the transaction instance that Bob creates:
In this transaction, Bob receives 5 units of green coins by sending 9 units of red coins in order to finish the exchange operation:
When and , the proving algorithm verifies:
The last condition means that Bob can only spend the note before a block height of . If not, Alice can cancel the exchange. This prevents the scenario that exchange neither completes nor terminates by a cancellation. The proving algorithm also needs to verify other sub-cases under this spending scenario when the order of notes changes, e.g., when and , etc. After Bob spends, a nullifier will be created and inserted to the pool of nullifiers and combined Merkle tree, which Alice can use for completing the exchange.
Exchange completion by the initiator: In this scenario, Alice spends after Bob. Alice knows when she can spend by scanning the pool of nullifiers. When she detects the expected nullifier, she can complete the exchange by creating a new transaction to spend the matching sibling note. The proving algorithm verifies the following satisfying constraints by the transaction instance:
Alice completes the exchange with a new transaction:
Note that the first input note can only be spent if there is a matching nullifier for a note already spent by Bob that is the primary note associated with the first input note (See Case 3 transaction example). Additional satisfying requirements for this transaction scenario include:
Similar to Case 3 transaction, one can set a threshold using block height to restrict the spending period of the note. In addition, the proving algorithm needs to verify additional sub-cases of transaction instances such as and , etc.
Exchange completion by the initiator (a second scenario): In this scenario, Alice spends after Bob to complete the exchange. The proving algorithm needs to verify the following constraints on input notes and output notes:
Additional conditions that need to be satisfied by this scenario: When , the proving algorithm needs to verify:
7 Security Model and Analysis
In this paper, the described OMAP protocol for supporting the oblivious and fair exchange of privacy digital assets is based on extending data models and transaction definitions of Zcash protocol. It achieves fair and privacy-preserving exchange through orchestrated payment transactions. Since the OMAP algorithms are within the Zcash framework, most of the properties shown in Zcash and related publications still hold for OMAP [13, 30, 31, 27], for instance, completeness. The security proofs for Zcash are mostly applicable to OMAP with trivial extensions. Here the discussions focus on properties or requirements unique to the proposed exchange protocol. Note that it is assumed that the underlying distributed ledger system to support consensus and network communications is assumed to be secure and reliable, which is outside the scope of OMAP. We further assume that measures are taken to prevent attacks that may happen at different layers. Such attacks include but not limited to, for instance, 51% attack, privacy compromise through analysis of network traffic patterns, attack to DNS, hard forks, quantum attack, etc. In addition, we assume that the underlying zero knowledge proving system is secure.
The original Zcash privacy coin defines security as: ledger indistinguishability, transaction non-malleability, and balance.
Ledger indistinguishability: ledger L reveals no information to the adversary beyond publicly disclosed information.
Transaction non-malleability: no bounded adversary can alter any of the data stored within a valid transaction. It prevents the adversary from modifying others’ transactions before they are added to the ledger.
Balance: no bounded adversary can own more notes than what he minted or received via transactions from others.
Specific to OMAP, we define the following security requirements:
Fairness. When users agree to conduct an exchange of assets, represented as privacy notes that support multiple asset types, the operation leads to two possibilities: it fails that each one still has his/her note (asset), or it succeeds that each one possesses the other’s note (asset type and amount). In other word, the exchange either completes or aborts.
Privacy. Though all transaction information is stored on the decentralized ledger, other users should not be able to learn any useful information about the exchange transaction. For payment, Zcash is already shown to meet the requirement of transaction indistinguishability. OMAP extends JoinSplit transaction with multiple spending cases. Therefore, transaction indistinguishability is extended to cover the requirement that, no bounded adversary can distinguish different scenarios of JoinSplit transactions. This means that OMAP ledger reveals no information to the adversary of transactions so that can tell if a JoinSplit transaction is a regular payment, exchange initialization, exchange cancellation, etc.
Balance. No bounded adversary can own more notes than what he minted, or received via direct payment from others or via exchange.
Next, we show that the constructed scheme satisfies all the features defined above, including, fairness, indistinguishability, and balance.
Fairness: This property requires that after an exchange is initiated, it either completes or aborts. At a high level, OMAP achieves fairness by reducing this requirement to assurance that double spending can be detected and prevented by the underlying ledger. According to OMAP, to start an exchange, Alice creates a pair of notes (one primary note and one sibling note). The primary note is shared between Alice and Bob, so either one of them can spend. If fairness is not satisfied, this means that the system reaches a state that either both Alice and Bob succeeded in spending the primary note; or none of them can spend the primary note. For the first case, it is clear that it is equivalent to double spending and is prohibited by the consensus mechanism of the underlying ledger. For the second case, if neither Alice nor Bob has spent the primary note yet, then one of them can spend in the future. In case, there is a time limit, Alice can eventually spend the primary note, which terminates the exchange operation. The likelihood that someone else besides Alice and Bob spends the primary note is negligible and ensured by the security of the base protocol. Therefore, one can conclude, that with probability 1-negl, the exchange will either succeed or terminate.
Privacy: In OMAP, the exchange is achieved through multiple JoinSplit transactions (shielded to shielded payment transactions). Although OMAP defines multiple JoinSplit transaction scenarios, there is only one combined circuit for proving ZK satisfiability of a JoinSplit transaction instance. This guarantees that different JoinSplit spending cases within an exchange operation or between exchange operations or between an exchange operation and regular payment should be indistinguishable. They are different ZK satisfying instances of the same proving circuit. If an adversary can break the indistinguishability property, it means that can distinguish different proofs, which contradicts to the assumption that the underlying zero-knowledge proving system is secure.
Balance: This requires that no bounded adversary can own more notes than what he receives via direct payment or an exchange. Note that OMAP implements fair exchange using JoinSplit payment transactions. The original Zcash protocol already shows that the balance requirement is satisfied by JoinSplit transactions. OMAP introduces sibling note. Somehow, the asset in a sibling note can be viewed as borrowed from the system. A sibling note cannot be spent by itself. According to JoinSplit algorithm, the condition to spend a sibling note is that either the associated primary note is spent already or it is spent together with the paired primary note in a JoinSplit transaction. This guarantees balance during the exchange operation. Assume that adversary can spend a sibling note itself independent of the associated primary note. According to the OMAP JoinSplit ZK proof algorithm, this means that the adversary must find another primary note with matching sequence number . For a pair of primary note and sibling note, is created by a CRH using input value unique to the transaction. If adversary can spend a sibling note by pairing it with another note, it means that adversary can break the CRH by finding a collision, which contradicts the assumption that CRH is collision resistant.
Exchanging different types of crypto assets on distributed ledger/ blockchain is a natural extension of privacy-preserving cryptocurrency systems. In response to this demand, we develop a novel multi-asset and privacy protected asset exchange framework on blockchain and apply zero-knowledge proof to enhance privacy protection for exchange operations.
In addition, we discuss the implementation of the unified zero-knowledge proving system used to support both payment transactions and multi-asset exchanges with privacy; and a formal definition of oblivious and privacy-preserving exchange scheme on the public ledger.
We extend the data formats and proving system of existing privacy coin to support the designed protocol. We have so far implemented circuits for handling extension and different payment spending scenarios in order to support fair asset exchanges using libsnark library. Furthermore, many new zero-knowledge proving systems are proposed recently, our current work includes experimenting and porting the scheme to zero-knowledge proving systems such as zk-STARK  and Bulletproofs . Different from zk-SNARK, recent schemes (e.g., Bulletproofs) do not require a security setup. Implementing our multi-asset and oblivious exchange protocol over these new zero-knowledge proving systems may help increase both trustworthiness and performance of the proposed protocol.
-  Dorit Ron and Adi Shamir. Quantitative analysis of the full bitcoin transaction graph. IACR Cryptology ePrint Archive, 2012:584, 2012.
-  Nicolas Van Saberhagen. Cryptonote v 2.0, 2013.
-  Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized anonymous payments from bitcoin. In 2014 IEEE Symposium on Security and Privacy, pages 459–474. IEEE, 2014.
-  Shen Noether. Ring signature confidential transactions for monero. IACR Cryptology ePrint Archive, 2015:1098, 2015.
-  Ryan Henry, Amir Herzberg, and Aniket Kate. Blockchain access privacy: challenges and directions. IEEE Security & Privacy, 16(4):38–45, 2018.
-  Merve Can Kus Khalilov and Albert Levi. A survey on anonymity and privacy in bitcoin-like digital cash systems. IEEE Communications Surveys & Tutorials, 20(3):2543–2585, 2018.
-  Ethan Heilman, Leen AlShenibr, Foteini Baldimtsi, Alessandra Scafuro, and Sharon Goldberg. Tumblebit: an untrusted bitcoin-compatible anonymous payment hub, 2017.
-  Henning Pagnia. On the impossibility of fair exchange without a trusted third party. Technical report, 1999.
-  Stefan Dziembowski, Lisa Eckey, and Sebastian Faust. Fairswap: How to fairly exchange digital goods. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 967–984. ACM, 2018.
-  S Bowe, A Chiesa, M Green, I Miers, P Mishra, and H Wu. Zexe: Enabling decentralized private computation. IACR ePrint, 962, 2018.
-  Neha Narula, Willy Vasquez, and Madars Virza. zkledger: Privacy-preserving auditing for distributed ledgers. In 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18), pages 65–80, Renton, WA, 2018. USENIX Association.
-  Andrew Poelstra, Adam Back, Mark Friedenbach, Gregory Maxwell, and Pieter Wuille. Confidential assets. In Aviv Zohar, Ittay Eyal, Vanessa Teague, Jeremy Clark, Andrea Bracciali, Federico Pintore, and Massimiliano Sala, editors, Financial Cryptography and Data Security, pages 43–63, Berlin, Heidelberg, 2019. Springer Berlin Heidelberg.
-  Ian Miers, Christina Garman, Matthew Green, and Aviel D Rubin. Zerocoin: Anonymous distributed e-cash from bitcoin. In Security and Privacy (SP), 2013 IEEE Symposium on, pages 397–411. IEEE, 2013.
-  Rami Khalil, Arthur Gervais, and Guillaume Felley. TEX - A securely scalable trustless exchange. IACR Cryptology ePrint Archive, 2019:265, 2019.
-  Poulami Das, Lisa Eckey, Tommaso Frassetto, David Gens, Kristina Hostáková, Patrick Jauernig, Sebastian Faust, and Ahmad-Reza Sadeghi. Fastkitten: Practical smart contracts on bitcoin. IACR Cryptology ePrint Archive, 2019:154, 2019.
-  Shafi Goldwasser, Silvio Micali, and Charles Rackoff.