Kalpana Singh
email: kalpana.singh@irt-systemx.fr

Nicolas Heulot
email: nicolas.heulot@irt-systemx.fr

Elyes Ben Hamida
email: elyes.ben-hamida@irt-systemx.fr

Towards Anonymous, Unlinkable, and Confidential Transactions in Blockchain

In this paper, we investigate the issues of data and users' privacy in decentralized environments. We propose a novel security and privacy-preserving protocol for the blockchain that addresses the limitations of existing approaches, mainly the anonymity and unlinkability of users' identities and the privacy of transactions. We highlight the benefits of our proposed protocols across various use cases and we theoretically analyze its efficiency and robustness.

I. INTRODUCTION

The concept of blockchain was introduced in 2008 by Satoshi Nakamoto [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF] which offered a practical model for anonymous monetary transactions. It is a fastest growing revolutionary technology that is expected to disrupt businesses in key domains, including finance, energy, mobility, logistics, and insurance. More recently, smart contracts have emerged as a new feature enabling the automation of business workflows and rules over the blockchains and whose proper execution is enforced by the consensus mechanism. A blockchain is secure by design and relies on well-known cryptographic algorithms to provide key properties, such as resistance to tampering, pseudo-anonymity, fault-tolerance, auditability, resilience, and non-repudiation. However, privacy remains a fundamental obstacle for individuals, organizations, and industries as features of the blockchain's transparency and permanency. The blockchain technologies have several major technical barriers that make them impractical for mainstream use today. Given that anyone in the world can create a new wallet anonymously and transact using it. On one hand, the great promise of blockchain is pseudonymity: transactions are recorded and stored in a public ledger, but they are linked to an account address. There is no real-world identity attached to this address. However, this advent of total security is ambiguous. On the blockchain, a person can preserve his or her privacy as long as the pseudonym is not linked to the individual, but as soon as someone makes the connection, the secret is revealed. One instance of such an occurrence was revealed when law enforcement agencies admitted that they were able to identify specific Bitcoin users during investigations, thus "de-anonymizing" them and breaking with the overall premise of a blockchain's total transactional invisibility [START_REF] Kasireddy | Fundamental challenges with public blockchains[END_REF].

A. Privacy on the Blockchain

In the blockchain platforms, like Ethereum [START_REF] Wood | Ethereum: A secure decentralised generalised transaction ledger[END_REF], users are interacting with smart contracts that handle not just simple value transfers but also data sharing and process automation. By design, all details about these smart contracts are accessible by anyone through the blockchain ledger, including senders and recipients, transaction data itself, the bytecode executed, and the state of each variable stored inside the contract. Privacy and security issues continue to be major barriers in the blockchain, since revealing sensitive data over the blockchain can present a serious threat. Anonymity and unlinkability of individuals' identity and privacy of transaction are the crucial issues in a decentralized network. In this line of research, T. Okamoto and K. Ohta [START_REF] Okamoto | Universal electronic cash[END_REF] described six criteria for privacy, which included the relationship between the user and his purchases must be fully anonymous by anyone. In the paper [START_REF] Van Saberhagen | Cryptonote v 2.0[END_REF], authors developed a fully anonymous model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta. In addition to this line of research work, we find the careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. It means the existing solutions did not satisfy the fully anonymous requirements. Since all the transactions that take place between the network's participants are public, any transaction can be evidently linked to the individuals.

From the descriptions of these papers [START_REF] Okamoto | Universal electronic cash[END_REF] and [START_REF] Van Saberhagen | Cryptonote v 2.0[END_REF], we determine our privacy notion. By privacy, we mean the unlinkability and anonymity in the sense that even an infinitely powerful an adversary with access to an unbounded number of transactions (same sender) cannot guess his identity with an advantage and cannot link the transactions to the same sender. We also achieve confidentiality during the transaction on the blockchain which adds an extra layer of privacy in our protocol.

B. Contribution

This paper proposes a solution which efficiently reduces the overhead and maintains levels of security and privacy of sensitive information and individual's identity during transactions on the blockchain platform. The solution has simpler and more intuitive design and improved efficiency than existing linkable and traceable ring signatures. Our objective is to obtain three privacy requirements. First is 'anonymity': for each transaction senders are not identified. Second is 'unlinkability': for any outgoing transactions, it is impossible to prove they were sent by the same sender (for example. if a sender has a number of accounts then it is not possible to link the transactions of the same sender). The third is a 'confidential transaction' which means hiding transaction value. The solution also attains security from malicious individuals. We acknowledge our solution on different use cases of decentralized systems.

C. Paper Organization

The rest of the paper is organized as follows. Section II gives background on privacy techniques for the blockchain.

Section III presents the basis of our solution, assumptions, definitions and notations for subsequent parts of the paper. Section IV describes the use cases and our contribution which provides a solution for the anonymous and confidential transaction in the Blockchain by accomplishing anonymity, unlinkability, and confidentiality features. Section V presents privacy and security proofs, and the comparison with analogous existing solutions in terms of privacy, security and computation costs. Finally, section VI concludes the paper.

II. RELATED WORK

As discussed in Subsection I-A privacy is a hurdle in the blockchain applications. Several studies analyzing the privacy implications of blockchain technology and indicate that builtin privacy guarantees are not satisfactory. The solutions to the privacy difficulties are studied in the literature.

1) Mixing Schemes: In the direction of privacy solution in the blockchain, Mixcoin [START_REF] Bonneau | Mixcoin: Anonymity for bitcoin with accountable mixes[END_REF] allows to hold mixing services accountable in a reactive manner; however, the mixing services still remain single points of failure. Mixing schemes suffer from two drawbacks: First, the mix might just steal the money and never return it to the users. Second, the mix learns the permutation of the output addresses. To solve the problem Maxwell proposes CoinJoin [START_REF] Maxwell | Coinjoin: Bitcoin privacy for the real world[END_REF]. With CoinJoin, it is similarly possible to hide the originator of a given transaction, however, these techniques in practice need a centralized server. If the trusted party is compromised, the anonymity of the transaction is also compromised. Another example of a mixing solution is CoinShuffle [START_REF] Ruffing | CoinShuffle: Practical decentralized coin mixing for bitcoin[END_REF]. CoinShuffle tried to improve upon CoinJoin by not requiring a trusted third party to assemble the mixing transactions. CoinShuffle relies on the interaction between the users in the mixing to achieve unlinkability against malicious servers, verifiability, robustness, and cost-effectiveness.

2) Cryptographic Privacy Schemes: These mixing solutions did not provide complete privacy. In respect to these privacy drawbacks, there are cryptographic privacy solutions such as zerocoin. Zerocoin [START_REF] Miers | Zerocoin: Anonymous distributed e-cash from bitcoin[END_REF], an extension to Bitcoin, was among the first proposals to provide unlinkability between individual Bitcoin transactions without introducing a trusted party. Zerocoin [START_REF] Miers | Zerocoin: Anonymous distributed e-cash from bitcoin[END_REF] and its successors [START_REF] Ben-Sasson | Zerocash: Decentralized anonymous payments from bitcoin[END_REF] provide strong anonymity without any third party, but lack compatibility with the current Bitcoin system. Another attempt to provide privacy in cryptocurrency is ZCash [START_REF] Hopwood | Zcash protocol specification, version[END_REF], which uses the zeroknowledge succinct non-interactive argument of knowledge (zk-SNARKs) [START_REF] Hopwood | Zcash protocol specification, version[END_REF]. There are few problems are examined in the literature. The first problem is the efficiency which is much worse than the normal bitcoin transaction (takes a few minutes to perform a spent computation). Another problem with ZCash is the "trusted setup". Zcash has some serious issues related to the "toxic waste" during the "trusted setup" and has many additional risks due to the very new cryptography that is being applied. However, we can not find the malicious sender/receiver due to complete anonymity feature.

3) Recent Studies on Cryptographic Privacy Schemes:

The anonymous addresses on the blockchain have been described before in [START_REF] Bitcoinwiki | Zero knowledge contingent payment[END_REF] and implemented in [START_REF] Maxwell | The first successful zeroknowledge contingent payment[END_REF] for Monero cryptocurrency. The original Monero protocol was based on CryptoNote, which uses ring signatures and one-time keys to hide the transactions. Recently the technique of using a commitment scheme is proposed to hide the amount of a transaction [START_REF] Noether | Ring signature confidential transactions for Monero[END_REF]. Monero further improves the protocol by using a variant of linkable ring signature, which is called Ring Confidential Transactions (RingCT) [START_REF] Noether | Ring signature confidential transactions for Monero[END_REF]. The RingCT protocol is studied to protect the anonymity of an individual as well as the privacy of transactions. In the paper [START_REF] Sun | RingCT 2.0: A compact accumulator-based (linkable ring signature) protocol for blockchain cryptocurrency Monero[END_REF], a new efficient RingCT protocol is proposed known as RingCT 2.0. In comparison with the original RingCT protocol, RingCT 2.0 protocol presents a significant space saving, namely, the transaction size is independent of the number of groups of input accounts included in the generalized ring while the original RingCT suffers a linear growth with the number of groups, which would allow each block to process more transactions.

We observe the possible research direction for our work from the identified shortcomings on anonymity, unlinkability, scalability, and security from the Section II. We find the Zeroknowledge proofs (ZKP) based solutions [START_REF] Miers | Zerocoin: Anonymous distributed e-cash from bitcoin[END_REF], [START_REF] Ben-Sasson | Zerocash: Decentralized anonymous payments from bitcoin[END_REF], [START_REF] Hopwood | Zcash protocol specification, version[END_REF], are best in privacy. However, these schemes are based on a trusted group. Ring signature based solution [START_REF] Noether | Ring signature confidential transactions for Monero[END_REF] has no trusted group. However, ring signature scheme has not achieved the privacy as ZKP based schemes [START_REF] Miers | Zerocoin: Anonymous distributed e-cash from bitcoin[END_REF], [START_REF] Ben-Sasson | Zerocash: Decentralized anonymous payments from bitcoin[END_REF], [START_REF] Hopwood | Zcash protocol specification, version[END_REF]. In addition to this, ZKP protocols suffered from the malicious activities due to complete anonymous property. This paper presents a solution to solve these drawbacks by achieving the transactional privacy (confidentiality) and user's anonymity and unlinkability features in an efficient manner.

III. PRELIMINARIES

Our scheme is based on the cryptographic assumptions and on cryptographic privacy solutions. We give the background details in this section.

A. Cryptographic Assumptions

An elliptic curve E(F q ) is defined as the total number of points (x, y) ∈ E(F q ). Consider a cyclic group G of prime order q with a generator g ∈ E(F q ), we have g n = 1 where n = E(F q ). We define our assumptions with respect to an adversary Ȃ in Definitions 1, 2, and 3.

Y , G ∈ E(F q ), find x ∈ Z q such that Y = x • G.
Definition 2: Computational Diffie-Hellman Assumption (EC-CDH): Ȃ has no advantage in the following:

Given a • G, b • G, ∈ E(F q ), a, b ∈ Z q , compute ab • G.
a • G, b • G, c • G, ∈ E(F q ), a, b, c ∈ Z q , decide whether c • G = ab • G.

B. Cryptographic Building Blocks

1) Zero-Knowledge Proof: The purpose of the ZKP is for a party to prove to a verifier that they know some secret information x without revealing anything about the secret in the process. Goldwasser et al. introduced zero-knowledge proof of knowledge schemes in 1985 [START_REF] Goldwasser | The knowledge of interactive proof systems[END_REF]. Goldwassers Scheme: Prover and verifier both know (g, h, y 1 , y 2 ), with g, h = 1, g, h ∈ G, y 1 = g x , y 2 = h x , for exponent x ∈ Z q . The scheme runs as follows [START_REF] Goldwasser | The knowledge of interactive proof systems[END_REF]:

1) Prover chooses r ← R Z q , sends a ← g r , b ← h r to the verifier. 2) Verifier responds with challenge c ← R Z q for the prover.

3) Prover responds, sending t ← r-c x modq to the verifier. 4) Verifier accepts if and only if a = g t y c

1 and b = h t y c 2 For g and h in a cyclic group G where the discrete logarithm problem is assumed hard, the scheme above is both sound and honest-verifier zero-knowledge.

We use non-interactive zero-knowledge proof (NIZKP) version of Goldwasser et al. [START_REF] Goldwasser | The knowledge of interactive proof systems[END_REF] scheme (NI-Goldwasser) in our proof of signature step of the protocol. This is known as NI proof of membership (NI-Goldwassers PoM).

2) Non-Interactive Schnorr proof of knowledge: We also use Fiat-Shamir [START_REF] Fiat | How to prove yourself: Practical solutions to identification and signature problems[END_REF] to transform -protocols such as the Schnorr proof of knowledge (Schnorr PoK) of a discrete logarithm [START_REF] Schnorr | Efficient signature generation by smart cards[END_REF] into non-interactive-Schnorr PoK (NI-Schnorr PoK). Let H(•) be an ideal hash function. Here, we consider a single column v instead of columns v j of a data matrix D, where j = 1, 2, 3, ...n and n is the number of columns. We choose the single column to simplify the NI-Schnorr PoK using the Fiat-Shamir heuristic is defined below: Statement: Prover (P ) knows a v such that y = g v Public information: y, g, where g is a generator of a group G prime order q. Private information: v

1) P → V : P Chooses random r ∈ Z q . Calculates t = g r . Calculates c = H(t). Calculates s = c.v + r. Sends the tuple (t, s). 2) V : V Calculates c = H(t). Checks if g s = y c .t. If true,
accepts proof. The proof π is the tuple (t, s).

We use this scheme during the commitment and proof of correctness (PoC) on committed data steps on a blockchain platform.

3) Verifiable Random Function: A verifiable random function (VRF) [START_REF] Franklin | A framework for unique ring signatures[END_REF] is a pseudo-random function (PRF) that provides a non-interactively verifiable proof of correctness of its output. A PRF is denoted as an F (•) in our solution during the URS scheme. Consider a random public group element y = g x , the function F (m) = H(m) x is a PRF if we model the hash function H(•) as a random oracle. Given the above PRF and NIZK proof system (defined in Goldwasser et al. [START_REF] Goldwasser | The knowledge of interactive proof systems[END_REF]), we apply the BG paradigm [START_REF] Franklin | A framework for unique ring signatures[END_REF] to obtain a VRF in our solution as the URS scheme. This is an important function in our ring signature step where we use PRF on the identity attributes.

4) Elliptic curve based Pedersen Commitment:

In Pedersen commitments [START_REF] Franc | Privacy and pruning in the mini-blockchain[END_REF], the public parameters are a group G of prime order q, and generators (g 0 , ..., g n ). In order to commit to the values (v 1 , ..., v n ) ∈ Z q , pick a random r ∈ Z q and set C

= P edCom(v 1 , ..., v n ; r) = (g r 0 n i=1 (g vi i )
). We use a variant of the Pedersen commitment scheme based on the elliptic curve (EC) to reduce computation cost [START_REF] Franc | Privacy and pruning in the mini-blockchain[END_REF] during the blockchain transactions. We use "ec-Com" notation to represent this terminology in subsequent parts of the paper. Let G of large prime order q be the group of elliptic curve points. We choose n the number of values to commit to, and pick n + 1 random points P 1 , ..., P n , Q in G q . The commitment key is the tuple (P 1 , ..., P n , Q). To commit to the values (v 1 , ..., v n ) ∈ Z q , where v 1 , ..., v n are numbers of column values. We pick a random integer r ∈ Z q and calculate the commitment as:

Com(v 1 , ..., v n , r) = v 1 • P 1 , ..., v n • P n + r.Q.
To open the commitment we simply reveal the values v 1 , ..., v n and r. The EC-Pedersen commitment scheme is additively homomorphic, so it has the following properties:

Com(v 1 + y 1 , ...., v n + y n , r v + r y ) = Com(v 1 , ..., v n , r v ) • Com(y 1 , ..., y n , r y ) Com(k • v 1 , ..., k • v n , k • r) = Com(v 1 , ..., v n , r) k , Where, y 1 , ..., y n , r v , r y , k ∈ Z q .
5) Ring Signature: To produce a ring signature, the actual signer declares an arbitrary set of possible signers that includes himself and computes the signature entirely by himself using only his secret key and the others public keys. A ring signature RS scheme consists of a quadruple of probabilistic polynomial time (PPT) algorithms (Setup, RingKGen, RingSig, RingV f y). We refer to a ring R = (pk 1 , pk 2 , ..., pk n ) of public keys as a ring. We utilize these quadruple (Setup, RingKGen, RingSign, RingV f y) in our ring signature scheme with the privacy and security features if it is correct, unforgeable and anonymous in the Algorithm 1.

IV. OUR SOLUTION

The protocol we present in this section is designed to maintain the level of privacy as discussed in the above Section II, and to improve on existing efficiency by using elliptic curve based schemes. For the most part, our protocol is based on the Franklin and Zhangs URS [START_REF] Franklin | A framework for unique ring signatures[END_REF]. Our protocol offers the usual expected features of anonymity and unlinkability of the sender but can reveal the identity of a sender who maliciously tries to use the system. Additionally, we provide the confidential transaction between the users on the blockchain. In addition to the privacy, our protocol provides unforgeability, undeniable sender identity, satisfies 'once concealed, twice revealed', defined and proved in Subsection V-A.

A. Use Cases Overview

We consider an architecture based on the Ethereum technology (Ethereum Virtual Machine 'EVM') [START_REF] Wood | Ethereum: A secure decentralised generalised transaction ledger[END_REF]. This architecture can be either a public or consortium blockchain [START_REF] Hamida | Blockchain for enterprise: Overview, opportunities and challenges[END_REF]. We use this technology because it implements a smart contract. So, this technology can make sure that only honestly generated transactions will be finally immutably stored in the blockchain ledger. We consider a process of information exchange based on the blockchain using smart contract with the following participants and delineated in the Figure (Figure 1):

• Sender (S): The sender information/data requires privacy. For example, an individual who wants to buy tickets for a sport's event in a stadium.

• Receiver (R): A receiver information/data which is supposed to be publicly known. For example, a ticket seller who is in charge of promoting an event.

• Verifier (V ): The blockchain with its Smart contract in charge of verifying and validating the protocol.

• Authority (A): The authorities legally in charge of controlling the interactions between the different users. For example, a registration authority in charge of controlling the identities of people entering a stadium.

As we mentioned previously, our protocol provides the anonymity and unlinkability of a sender. However, it does not address the same properties for the recipient during data exchange on the blockchain. So, we consider only use cases where the recipient is public such as a marketplace on the blockchain. In particular, the following use cases can be demonstrated in our protocol: Ticket selling: the sale of tickets for a sporting event is publicly announced. However, each buyer of a ticket has to protect his privacy. So, each buyer will keep his identity private. Nevertheless, he has to share his identity information to the security authorities who are able to refuse the sell to the blacklisted individuals (for example, to refuse an access from dangerous hooligans to a stadium).

Bond market: This is a financial market where participants can issue a new debt, known as the primary market. This is usually in the form of bonds. When a participant issues bonds to raise money, all the details of his issuance project are publicly shared on a marketplace in order to bring investors. However, these investors who place an order have to protect both their identity and the amount of their investment. In this example, regulation authority appoints an investor's identity which is shared during a legal process named "Know Your Customer" (KYC).

The anonymity and unlinkability of each user and confidentiality of data during transactions should be preserved in these three use cases. These are the main focus of our protocol. In these use cases, legal authorities often impose to be able to ask to reveal the identity of users to prevent the malicious activity. Additionally, each sender can have more than one account in all use cases. However, senders can not use same data for the different transaction using distinct accounts.

In our protocol, we use I denoted as the identity attributes, such as ID card number, social security number or contact address. We use D denoted as the exchanged information which requires privacy according to the use cases (defined above) such as technical details, cost proposal or investment proposal. The proofs are presented in SubsectionV-A. We consider the same participants (as described in the above SectionIV-A) in following parts of the paper.

B. Protocol Description

We assume the data to be sent contains sensitive information about individuals. We maintain the privacy of these individuals by ensuring that an attacker who obtains the data cannot connect this sensitive information with the individual it describes. Thus, in the setup, a sender S wants to send data D to a receiver R in a secure and an efficient manner in such a way that the privacy of the data and sender's identity are preserved. S first determines which portion of data should be considered to be the 'identity attributes' (social security number) and 'other sensitive attributes' (cost proposal or investment proposal) in need of privacy maintenance. We use I to refer to 'identity attributes' data, as determined by S, and D to refer to the 'other sensitive attributes' data. This is an essential assumption in our use case. The privacy of the complete data is very crucial. 1) The Data Setup: Each sender S accounts data in a matrix format, which we refer to as D. Over time, the dimensions of D will vary; however, to simplify our explanation, we suppose that at this time, D has m rows, numbered 1 to m, and n columns, numbered 1 to n. Thus, in the setup, a sender S wants to send data D to another user (receiver) R. Let D = [v ij ], i = 1; m, j = 1; n be a matrix with values v ij , where i = 1, 2, 3, ..., m and j = 1, 2, 3, ..., n. We use the notation v j to refer to a column of D. The S uses a commitment on each column data v j to hide the data values. In addition to this data S has the identity attributes I. The I attributes are generated by an authority depending on the targeted case scenarios defined in Subsection IV-A.

2) The Protocol Setup: Sender S is the i th user in the ring. We use the notation ← R , to indicate choosing an element at random from a set, for example, t j ← R Z q shows t j chosen at random from Z q . We begin by recalling the definition of a ring signature scheme RS = (setup, RingKGen, RingSig, RingV f y) that consists of four algorithms. This signature is based on the Franklin and Zhangs URS in the random oracle [START_REF] Franklin | A framework for unique ring signatures[END_REF]. We use this signature scheme to get user's anonymity. The NI-Goldwassers PoM scheme is used for the proof of signature in our protocol. These schemes are used for anonymity of a sender in the paper [START_REF] Franklin | A framework for unique ring signatures[END_REF]. We use ec -Com commitment scheme (defined in Section III-B) to hide data exchanged, and generate the NI-Schnorr PoK to prove the correctness (PoC) of committed data. The in-depth security proof shows that our proposed scheme is provably secure under the random oracle model [START_REF] Franklin | A framework for unique ring signatures[END_REF]. This ec -Com protocol is utilized on data D and generates the committed data. D is first processed on the sender side by the privacy-enhancing protocols of ec -Com with NI-Schnorr PoK. The Franklin and Zhangs URS with NI-Goldwassers

Data: A data matrix D = [vij ]i=1,m j=1,n
with columns v j , where j = 1, 2, 3, ..., n, Private information: v1, v2, ..., vn, r and r is a commitment key, S is in a ring with the public keys R = (pk1, pk2, ..., pkn). Identity attributes I. Result: RingVfy Proof of correctness (PoC) of committed data π STEP-1: S calculates committed data using EC-commitment ec-Com ((v1, v2, ..., vn), r) of data v j , define in Algorithm-phase 2. STEP-2: S calculates PoC of committed data π using NI-Schnorr PoK scheme, define in Algorithm-phase 2. ;

// The URS scheme on identity attributes I STEP-3: S generates URS setup Setup (1 λ ), define in Algorithm-phase 3. STEP-4: S generates a Key generation of URS (1 λ , pp), define in Algorithm-phase 3. STEP-5: S calculates signature on I using URS RingSig(ski, R = (pk1, pk2, ..., pkn), I), define in Algorithm-phase 3. ; // S sends committed and signed data to the V (smart contract). STEP-6: V Verifies signature RingVfy(R, I, σ), define in Algorithm-phase 4. STEP-7: V verifies PoC of committed data pi, define in Algorithm-phase 4. STEP-8, 9, 10 R receives signed data and verifies (if needed) RingVfy(R, I, σ), define in Algorithm-phase 4, and PoC also define in Algorithm-phase 4. STEP-11 R asks to open commitment on the blockchain. STEP-12 -13: Sender i receives queries and sends private information via the off-chain communication channel to R. STEP-14: R opens the commitment and stores on its private cloud. STEP-15 I is only seen by the authority if asked.

Algorithm 1: Our Protocol: A Solution for Anonymous, Unlinkable and Confidential Transactions in Blockchain

PoM schemes in the random oracle are used for sender's anonymity on the identity attributes I. The privacy of the scheme relies on ECDDH, which itself is closely related to ECDLP, which has been described as "the hardest math problem ever" [START_REF] Petit | Algebraic approaches for the elliptic curve discrete logarithm problem over prime fields[END_REF]. In the protocol, we consider four users: sender S, verifier V known as 'smart contract', receiver R, and authority A, defined in detail in Subsection IV-A. Our protocol is now described in Figure 1. The sensitive data D is passed by the S into the ec -Com privacy-enhancement process box in

Step-1 of Figure 1 and the EC-commitment protocol is applied to it. In addition to validate this commitment, S generates proof of correctness which is based on NI-Schnorr PoK in Step-2. for verification and validation. V verifies the signature and PoC of committed data in Steps 6 and 7. Then, V publishes this validated information on the blockchain. We use a smart contract as a verifier V .

Data: R, Identity attributes I Result: Ring signature RingSig(R, I, H(I R) x i , c1t1, ..., cntn) STEP-3: Ring Setup:Setup (1 λ ): For each User i (is a sender), 1 ≤ i ≤ n choose λ the security parameter, choose multiplicative group G with prime order q, and randomly chosen generator g of G. Choose also two hash functions H and H such that:

(I) H : {0, 1} * → G.

(II) H {0, 1} * → Zq.

Output public parameters pp = (1 λ , q, G, H, H ) STEP-4:Ring Key Generation: RingKGen(1 λ , pp) (I) Sender i generates secret key ski and public key pki.

(II) xi ← R Zq. (III) yi ← g x i .
Output public key pki = (pp, yi), secret key ski = (pp, xi). ; // The URS with NI-Goldwassers PoM schemes to sign on identity attribute I. STEP-5:Ring Signature: RingSig(ski, R = (pk1, pk2, ..., pkn), I)

foreach j ∈ [n], j = i do tj , cj ← R Zq; aj ← g t j y c j j ; bj ← H(I R) t j (H(I R) x j ) c j ; foreach j ∈ [n], j = i do ri ← R Zq; ai ← g r i ; bi ← H(I R) r i ; Calculate ci ← H (I, R, H(I R) x i , {aj , bj } n 1 ) -j =i cj ] modq. ti ← ri -cixi modq.
Return (R, I, H(I R) x i , c1t1, ..., cntn). S sends (R, I, H(I R) x i , c1t1, ..., cntn) for the ring verification in STEP-6 of Algorithm-phase 4.

Algorithm-Phase 3: STEPS 3, 4, 5: Signed data with PoM (R, I, H(I R) x i , c 1 t 1 , ..., cntn) for the V in STEP 6 of Algorithm-phase 4. Algorithm-Phase 4: STEPS-6 and 7: Verifying Signature and PoC So, the receiver's address is mentioned on the transaction (receiver address is visible to this work as described in Subsection IV-A. R receives data and signature on the data. R can verify both the signature and committed data using ring verification and proof of correctness in Steps 9 and 10. Then, R asks to open commitment from S. R receives this secret information via off-chain communication channels, it reconstitutes the data D by opening the commitment. Thus, data D is finally in R's hands. The identification tag is H(I R) xi , which corresponds to x i .H(I R) when defined over an elliptic curve group (only seen by an authority in our scenario in Subsection IV-A). These steps are designed in detail in our proposed Algorithm in 1. We use the Figure 1 to simplify the operations which are utilized in the Algorithm 1. The Algorithm 1 has three algorithm-phases to commit and generate proofs of committed data, to sign on the identity and proof of membership, to verify the signature and correctness of committed data in the Algorithm-phases 2, 3, and 4 respectively. If a valid sender's signature and the correct proof of committed data are received, V accepts the data request and publish on the blockchain. In our protocol, we assume that the receiver is looking for some important data on the blockchain. When receiver will see the transaction has its public address. R gets the transactions and again validates the signature and PoC of committed data as Steps 6 and 7 Algorithm 1. When both verification steps are done successfully. R needs to open committed data D. R sends a message using RingSig(sk i , R = (pk 1 , pk 2 , ..., pk n ), I) along with its public address on the blockchain. S is actively available on the blockchain (our assumption). S receives a message and sends the private information ũ, s u , r using off-chain communication channels (secure channel) to the R. R opens the commitment and stores on the private cloud. I is only visible to the authority if asked to the S. S can not send secret key sk i at any cost to the R (assumption). This communication is delineated in Figure 2. This section analyses the privacy and security of our protocol. The privacy of the protocol is defined by conditional sender anonymity, confidential transaction, and unlinkability. The security is defined by unforgeability, satisfies "once concealed, twice revealed" and undeniable signer identity. We define privacy and security features by means of a game between a challenger C and an adversary Ȃ, the latter who may be a sender S, a receiver R. We define the advantage of an adversary Ȃ in breaking the sender anonymity of the protocol as the probability that the adversary Ȃ guesses private information correctly.

[Definition]Adversary with an Advantage The protocol has the sender anonymity if the advantage of any Probabilistic Polynomial Time (PPT) adversary is not more than 1 2 plus any non-negligible value.

A. Privacy and Security Proofs

Theorem 1: Assume that the Franklin and Zhangs URS has the sender anonymity and commitment protocol also has the unconditionally hiding (i.e., a receiver does not learn anything about the values (v 1 , v 2 , ..., v n , r during the commit step. In this case, our protocol achieves sender anonymity and data confidentiality during the transaction. We consider any PPT adversary Ȃ generates a committed data by considering u 1 , u 2 , ..., u n ∈ Z q , s u ∈ Z q and calculates w 1 = z .v 1 +u 1 for each data values u 1 , u 2 , ..., u n , where z ∈ Z q . Committed key r is a secret key define in Algorithm-phase 2. This is a useful step to calculate s = z.r + s u . This step is a required in a verification step (Step 7 of an Algorithm-phase 4). Ȃ calculates π as: π = ec -Com(u 1 , u 2 , ..., u n , s u ), w 1 , w 2 , ..., w n . However, r is a secret key. Ȃ can not calculate s . Hence, Ȃ can not generate the parameters for PoC of committed data. V never accepts a bad PoC of committed data, and also commitments reveal no information whatsoever about the committed values. Thus, we achieve perfectly hiding commitments. Sender anonymity proof is illustrated in detail in the Appendix F , [START_REF] Mercer | Privacy on the blockchain: Unique ring signatures[END_REF]. In our case, the identity of S can reveal to Authority A only. This proof is applicable in our sender anonymity because we utilize the Franklin and Zhangs URS and EC-commitment schemes. Proof: As defined in the use case section IV-A, given two distinct bonds/tickets managed by the same sender S, an adversary Ȃ, who may be the verifier V , or the receiver R, has two ways to link the transaction by the same sender S.

1) Ȃ links the two tickets/bonds according to their identity attributes I. In our protocol, each identity (i.e. H(I R) xi = τ ) is used by a S only once. Ȃ first has to identify the S from the identity attributes and then link the two tickets/bonds with the identity. Our signature protocol is built on the Franklin and Zhangs URS protocol in random oracle to get a VRF (illustrated in the Subsection III-B) i.e truly random value. This URS is based on the DDH assumption (defined in Theorem 2 of the Paper [START_REF] Franklin | A framework for unique ring signatures[END_REF]) which is the hardest math problem ever [START_REF] Petit | Algebraic approaches for the elliptic curve discrete logarithm problem over prime fields[END_REF]. So, Ȃ can not guess/ calculate the identity values due to hardness solution of DDH and BG paradigm. If the Franklin and Zhangs signature provides sender anonymity. Therefore, this link attack can be prevented. 2) Ȃ traces the source of the S who sends the Bond/ticket, as defined in the Ethereum address of the sender (explain in the EVM [START_REF] Wood | Ethereum: A secure decentralised generalised transaction ledger[END_REF]). If two bonds come from the same source, they are most likely transact by the same S. Because S sends the bond to V using EC-commitment protocol and PoC of committed bond using NI-Schnorr PoK, this link attack can be prevented.

Theorem 3: Assume that the Franklin and Zhangs URS scheme has unforgeability; then our protocol has unforgeability.

Proof: In Step 5 of Algorithm-phase 3, S sends signature (R, I, H(I R) xi with proof of signature c 1 t 1 , ..., c n t n ) to the V . Additionally, S sends proof of correctness of data Com(ũ, s u ), w, s (stated in Step 2 of Algorithm-phase 2) to V . We assumed that An adversary should be unable to verify the signature unless either a PPT adversary Ȃ has chosen one of the public keys in a ring or a sender whose public key is in ring explicitly signed the message previously (with respect to the same ring). S is controlled by Ȃ. Therefore, Ȃ can construct any signature by considering the URS in random oracle. If Ȃ can produce a signature with the same ring, same identity for the same bond/ticket, he is able to forge a signature of S which contradicts the assumption that the Franklin and Zhangs URS scheme has unforgeability. Therefore, Theorem V-A holds.

Theorem 4: Assume that the Franklin and Zhangs URS scheme satisfies completeness and uniqueness, then our protocol detects malicious signer identity by the Authority which satisfies the feature "once concealed, twice revealed".

Proof: Based on the Theorem 1 and our assumptions III-A, we know that our protocol has sender anonymity and data confidentiality. Our protocol identifies the malicious sender in the same way as the Franklin and Zhangs URS scheme.

Here, S is controlled by Ȃ as stated in Theorem . S has more than one accounts (our assumptions defined in Subsection IV-A). If S can performs a transaction for the same bond/ticket using different accounts by using identity H(I R) xi = τ then S is able to cheat the protocol which contradicts the assumption that the Franklin and Zhangs URS scheme has completeness and uniqueness. Therefore, Theorem 4 holds. Proof: Based on the properties of Franklin and Zhangs URS, NI-Goldwassers PoM, EC-commitment and NI-Schnorr PoK, Theorem security:undeniable can be proved with ease. Franklin and Zhangs URS has utilized the NI-Goldwassers PoM scheme which is used to prove that the S knows the identity I. We also commit our data using EC-commitment scheme. Now, S can not refuse on the committed data. S also generates the PoC of committed data. If S is controlled by an adversary and denies that he has not committed to the data which contradicts the protocols of Franklin and Zhangs URS, EC commitment, and NI-Schnorr PoK. Therefore, Theorem 5 holds.

Table I specifies the main differences between our scheme, and that of Franklin and Zhangs URS [START_REF] Franklin | A framework for unique ring signatures[END_REF]. However, our scheme and Franklin and Zhangs URS have achieved Sender anonymity, Unforgeability, and Scalable features.

B. Computational Cost Comparison

As a measure of the practicality of our protocol, we calculate the computational costs of a sender, verifier/receiver in our protocol. We also compare our protocol with existing schemes on the blockchain. We follow the method of measurement used by [START_REF] Juang | Ro-cash: An efficient and practical recoverable pre-paid offline e-cash scheme using bilinear pairings[END_REF]; thus, we assume that H is the computational time of one hashing operation, M is the computational time of one modular multiplication, E is the computational time of one modular exponential operation. EC M , EC P , and EC A are the computation time of the multiplication, bilinear pairing, and addition operations respectively over an elliptic curve. Again following [START_REF] Juang | Ro-cash: An efficient and practical recoverable pre-paid offline e-cash scheme using bilinear pairings[END_REF], we assume that E ≈ 240M , E ≈ 3.2EC P , H ≈ 2 5 M , and E ≈ 8.24EC M . The cost of inverting an element was calculated as for multiplication. Table II shows the features of selected schemes and computes the cost of the protocols needed in the blockchain communication: signature and commitment by the S, transactions and verification by the V and R. We consider n number of users in the ring and assume that each user has only one account for computation cost only. Our protocol is applicable to a number of accounts of each user. The computation costs of each scheme are presented in the Table II. We perform comparisons with these two schemes: RingCT [START_REF] Noether | Ring signature confidential transactions for Monero[END_REF] and RingCT 2.0 [START_REF] Sun | RingCT 2.0: A compact accumulator-based (linkable ring signature) protocol for blockchain cryptocurrency Monero[END_REF]. These only two solutions are close to our protocol (according to our knowledge) which addressed privacy of a user, the privacy of transaction and security on the blockchain. The maximum number of EC M is in the RingCT 2.0, which is the costliest operation in the protocol according to the analysis in the paper [START_REF] Juang | Ro-cash: An efficient and practical recoverable pre-paid offline e-cash scheme using bilinear pairings[END_REF]. The sequence success of the blockchain schemes in the computation costs are: RingCT 2.0 [START_REF] Sun | RingCT 2.0: A compact accumulator-based (linkable ring signature) protocol for blockchain cryptocurrency Monero[END_REF] < RingCT [START_REF] Noether | Ring signature confidential transactions for Monero[END_REF] < Our protocol. In this study, we achieve the low computation cost in our protocol better than the both RingCT 2.0 and RingCT schemes.

VI. CONCLUSION AND FUTURE WORK

This paper has examined the existing solutions to the lack of inherent privacy for individuals and transaction. The work is designed for the number of general use cases on the blockchain such as ticket selling, and bond market. We present a new solution with the ability to provide anonymity and unlinkability of a sender, the privacy of transaction (confidentiality), and security from the malicious behavior of entities on the blockchain. Our protocol also eliminates the relatively inefficient one-time signature. The security of the proposed system is ensured by a series of theorems. We have illustrated our solution with real uses cases such as ticket selling, and bond market. We compare our solutions with Franklin and Zhangs unique ring signatures, RingCT, and RingCT 2.0 in terms of privacy, security, and computation costs.

Future work: Our solution has some limitations such as lack of receivers anonymity and complete implementation. At present, our solution requires only basic implementations of elliptic curve arithmetic. Our future work will thus to implement our complete protocol using Ethereum Virtual Machine and address receivers anonymity.

Definition 1 :

 1 Elliptic Curve Discrete Logarithm Problem (ECDLP): Ȃ has no advantage in solving following: Given

Definition 3 :

 3 Decisional Diffie-Hellman Assumption (EC-DDH): Ȃ has no advantage in the following: Given

Fig. 1 :

 1 Fig. 1: The Protocol Overview

  Data: A data matrix D = [vij ]i=1,m j=1,n with columns v j , where j = 1, 2, 3, ..., n, Private information: v1, v2, ..., vn, r and r is a commitment key. Result: committed data w, and s PoC of committed data π STEP-1: S Calculates ec-Com ((v1, v2, ..., vn), r) ; // To simplify notation we use ṽ = (v1, v2, ..., vn) S chooses a r is a commitment key r ∈ Zq. S picks random values u1, u2, ..., un ∈ Zq, su ∈ Zq. ; // To simplify notation we use ũ = (u1, u2, ..., un) Calculates: Com(ũ, su) (I) Calculates H(Com(ũ, su)). (II) Transform the output into an integer z ∈ Z * q . foreach j ∈ {1, ..., n} do wj = z.vj + uj ; s = z.r + su; Output: {w1, w2, ..., wn}, s . ; // To simplify notation we use w = (w1, w2, ..., wn) ; // Calculates proof of correctness (PoC) π STEP-2: Generates PoC π. π(Com(ũ, su), w, and s ). S sends Com(ũ, su), w, s to the V for verifying PoC π in Step 7 of Algorithm-phase 4. Algorithm-Phase 2: STEPS 1 and 2: Calculation of Committed data and generation of PoC for verification in Step 7 of Algorithm-phase 4. Now S uses URS protocol on attributes I from Steps 3-5. The two results are then sent to verifier V (smart contract)

  Data: π((R, I, H(I R) x i , c1t1, ..., cntn) Com(ũ, su), w, s Result: RingVfy Verify the PoC of committed data π ; // π(Com(ũ, su), w, and s ) from STEP 2 of Algorithm-phase 2 to verify the PoC using NI-Schnorr PoK. ; // (R, I, H(I R) x i , c1t1, ..., cntn) from STEP 5 Algorithm-phase 3 to verifying signature anonymously. STEP-6:RingVfy(R, I, σ) and Com(ũ, su), w, s .(I) Parsing the output of RingSig, and using the notation H(I R) x i = τ . (II) Perform the comparison:n 1 cj = H (I, R, {g t j y c j j , H(I R) t j τ c j } n 1). If satisfies the comparison, a signature is verified. Otherwise, an unauthorized user. STEP-7: V verifies proof of correctness of committed data. (I) Calculates: Com( w, s ). (II) Calculates: H(Com(ũ, su)) and the output z into Zq. ForEachj ∈ {1, ..., n} Com(wj , s ) = Com(vj , r).z + Com(uj , su) ; If satisfies the comparison, PoC of data is verified. Otherwise, Unvalidated committed data. If both STEPS 6 and 7 are validated by the V then it will publish on the blockchain.

C

  . Communication between Sender S, Verifier V (Smart Contract), Receiver R and Authority A The flow of data in our protocol is shown in Figure 2. The protocol starts with commitment and PoC of committed data using EC-commitment protocol and NI-Schnorr PoK define in detail in Steps 1 and 2 of Algorithm 1. To authenticate anonymously S uses URS with NI-Goldwassers PoM schemes define in Steps 3, 4, and 5 of Algorithm 1. The V verifies the ring signature and PoC of committed data in Steps 6 and 7 respectively of Algorithm 1.

Fig. 2 :

 2 Fig. 2: Flow Diagram of the Proposed Protocol

Proof:

  In Section IV, Algorithm 1, S uses ECcommitment scheme and generates NI-Schnorr PoK for PoC of committed data. S sends committed data ec-Com ((v 1 , v 2 , ..., v n ), r) with PoC π to V for verification the correctness of committed data.

Theorem 2 :

 2 Assume that the Franklin and Zhangs URS scheme has sender anonymity in random oracle, the NI-Schnorr PoK of committed data satisfies 'Honest verifier zeroknowledge'. Then our protocol satisfies the unlinkability.

Theorem 5 :

 5 Assume that the Franklin and Zhangs URS scheme has NI-Goldwassers PoM of identity I, and PoC of committed data is verified by the NI-Schnorr PoK. Then our protocol satisfies the 'undeniable signer identity' feature.

TABLE I :

 I A comparison of our scheme with the Franklin and Zhang URS scheme

	Feature	Malicious	Unlink-	Proof	of	Confidential	Undeniable
		sender is	ability	Correctness	data	sender
		detected		of Data			identity
	Franklin	Not	Not	NO		NO	NO
	and Zhangs	proved	Proved
	URS[19]
	Our Proto-	YES	YES	YES		YES	YES
	col

TABLE II :

 II Comparative Evaluation Of Schemes on the Blockchain• EC M + EC P + 8 • EC M ≈ 3 • (n + 1) • EC M + 10 • EC M 2 • n • EC A + 8 • n • EC M + 5 • n • H EC M ≈ 3 • n • EC M + 81 • EC M 7 • n • EC A + 6 • n • EC MNote: n: the number of users of input accounts

	Properties	RingCT [14]	RingCT 2.0 [15]	Our Protocol
	Computational cost to the sender 3 • (n + 1) Computational 17 • n • EC M + n • H 18 • n • EC M + 9•E +3•EC P +3•
	cost to the verifier	n • H	n •

ACKNOWLEDGMENT

This research work has been carried out under the leadership of the Institute for Technological Research SystemX, and therefore granted with public funds within the scope of the French Program Investissements d'Avenir.