# RZcoin: Ethereum-Based Decentralized Payment with Optional Privacy Service

^{1}

^{2}

^{*}

## Abstract

**:**

## 1. Introduction

#### 1.1. Background

#### 1.2. Motivation and Contribution

- We further improve the privacy protection mechanism called RZcash. For the key redundancy problem, we propose a signature scheme called CEs based on the ciphertext equivalent test scheme [14]. It achieves the creation of secret accounts without regenerating the private key. In addition, compared to ECDSA, its signature size is reduced by 80%. In addition, we use Schnorr signature to reconstruct the zero-knowledge proof of RZcash and reduce the size of proof by 1/3. We also use bulletproof to reduce the size of rangeproofs.
- We combine the improved privacy protection mechanism with Ethereum and propose a decentralized payment called RZcoin with optional privacy services. In RZcoin, the hidden asset can be publicly verifiable and dynamically updated. Users can neither overspend nor forge their assets. All proofs required for transactions involving the privacy service (i.e., secret and semi-secret transactions) are attached to the "extraData" module of transactions.
- We implement the above decentralized payment scheme based on the Ethereum test chain and evaluate its performance. At the same time, we also propose the adversarial model it faces and give the corresponding security analysis. The result shows that the scheme can provide the privacy service to users with good performance while ensuring security.

#### 1.3. Related Work

#### 1.4. Roadmap

## 2. Preliminary

#### 2.1. Ethereum System

#### 2.2. Number Theory Knowledge

**Definition**

**1**

**.**Let g be a generator of the cyclic group $\mathbb{G}$ with prime order, i.e., $\mathbb{G}=\u2329g\u232a$. Randomly select h from $\mathbb{G}$. If there exists a negligible function $negl(\lambda )$ for all probabilistic polynomial time (PPT) adversaries $\mathcal{A}$, where λ is a security parameter, such that

**Definition**

**2**

**.**Let G be the base point of group $E({F}_{q})$. Randomly select point H from $E({F}_{q})$. If for all PPT adversaries $\mathcal{A}$, there exists a negligible function $negl(\lambda )$ such that

**Definition**

**3**

**.**Given an addition cyclic group ${\mathbb{G}}_{1}$ of prime order q and a multiplication cyclic group ${\mathbb{G}}_{2}$, we define a mapping relationship $e:{\mathbb{G}}_{1}\times {\mathbb{G}}_{1}\to {\mathbb{G}}_{2}$ such that it satisfies the following properties:

- Bilinear: $\forall \phantom{\rule{4pt}{0ex}}P,Q\in {\mathbb{G}}_{1}$, $\forall \phantom{\rule{4pt}{0ex}}a,b\in {Z}_{q}^{\ast}$, $e(a\xb7P,b\xb7Q)=e{(P,Q)}^{ab}$ is established, where ${Z}_{q}^{\ast}=\{1,\dots ,q-1\}$;
- Non-degenerate: $\exists \phantom{\rule{4pt}{0ex}}P,Q\in {\mathbb{G}}_{1}$, $e(P,Q)\ne 1\in {\mathbb{G}}_{2}$ is established;
- Computability: $\forall \phantom{\rule{4pt}{0ex}}P,Q\in {\mathbb{G}}_{1}$, there is an efficient polynomial time algorithm for computing $e(P,Q)$.

#### 2.3. Pedersen Commitment

**Definition**

**4**

**.**For the elliptic curve group $E({F}_{q})$, randomly pick $G,H\stackrel{R}{\leftarrow}E({F}_{q})$. $lo{g}_{G}^{H}$ is unknowable. The Pedersen commitment scheme contains the following three algorithms:

- $pp\leftarrow Setup({1}^{\lambda})$. For security parameter ${1}^{\lambda}$, it outputs public parameters $pp$ which will exist as implicit input in the following algorithms.
- $CM\leftarrow Com(s,r)$. For the secret value $s\in {Z}_{q}^{\ast}$, pick the random number $r\stackrel{R}{\leftarrow}{Z}_{q}^{\ast}$, then output:$$CM=s\xb7G+r\xb7H$$
- $\{0,1\}\leftarrow Open(CM,s,r)$. If Equation (3) holds, the output of this algorithm is 1. Otherwise the output is 0.

**Definition**

**5**

**.**For the elliptic curve group $E({F}_{q})$, randomly pick $\{\mathbf{G}=({G}_{1},{G}_{2},\dots ,{G}_{n}),H\}\stackrel{R}{\leftarrow}E({F}_{q})$, where n is the size of vector and $lo{g}_{G}^{H}$ is unknowable. A Pedersen vector commitment scheme contains the following three algorithms:

- $pp\leftarrow Setup({1}^{\lambda})$. For security parameter ${1}^{\lambda}$, it outputs public parameters $pp$ which will exist as implicit input in the following algorithms.
- $CM\leftarrow Com(\mathbf{s},r)$. For the secret vector $\mathbf{s}\in {Z}_{q}^{n}$, pick the random number $r\stackrel{R}{\leftarrow}{Z}_{q}^{\ast}$, then output:$$CM=\mathbf{s}\xb7\mathbf{G}+r\xb7H=r\xb7H+\sum _{i=1}^{n}{s}_{i}\xb7{G}_{i}$$
- $\{0,1\}\leftarrow Open(CM,\mathbf{s},r)$. If Equation (4) holds, the output is 1. Otherwise the output is 0.

**Theorem**

**1**

**.**If a commitment $Com(s,r)$ will not reveal any useful information about s, it is considered to be unconditionally hiding. That is, for any PPT adversary $\mathcal{A}$, his advantage satisfies:

**Remark**

**1.**

**Theorem**

**2**

**.**If a commitment $Com(s,r)$ can be opened to two different messages, ECDLP can be easily solved. That is, for any PPT adversary $\mathcal{A}$, there is a negligible function $negl(\lambda )$ that makes his advantage satisfy:

**Remark**

**2.**

#### 2.4. Zero-Knowledge Proof

#### 2.4.1. Ramgeproof

**Definition**

**6**

**.**For the input value a and global parameters $G,H\in E({F}_{q})$, this scheme can prove that $a\in [0,{2}^{n}-1]$ is true for the commitment $CM=a\xb7G+r\xb7H$. The value a here corresponds to the secret value s to be hidden in our scheme. In this definition, in order to ensure comparability with the details of scheme in [36], we choose to use a to denote the secret value. It mainly contains the following three algorithms:

- $\{\mathbf{G}=({G}_{1},{G}_{2},\dots ,{G}_{n}),\mathbf{H}=({H}_{1},{H}_{2},\dots ,{H}_{n}),G,H\}\leftarrow Setup({1}^{\lambda})$. For security parameter ${1}^{\lambda}$, it outputs public parameters $\{\mathbf{G},\mathbf{H},G,H\}$ which will exist as implicit input in the following algorithms. The definition of these parameters was introduced earlier.
- $proof\leftarrow ProofGen(a,r)$. The prover generates the rangeproof of a according to the following steps:
- (1)
- Convert a to a binary string ${\mathbf{a}}_{L}\in {\{0,1\}}^{n}$ and calculate ${\mathbf{a}}_{R}=\{{\mathbf{a}}_{{L}_{1-1}},\dots ,{\mathbf{a}}_{{L}_{n-1}}\}$;
- (2)
- Choose blinding vectors ${\mathbf{s}}_{L},{\mathbf{s}}_{R}\in {Z}_{q}^{n}$ and random parameters ${r}_{1},{r}_{2}\in {Z}_{q}^{\ast}$ to generate auxiliary parameters $A,S$.
- (3)
- Use Fiat-Shamir heuristic to achieve non-interaction, i.e., use the hash fuction instead of the challenge interaction of $y,z$.
- (4)
- Construct the two linear polynomials $L(x)$, $R(x)$ and calculate:$$T(x)=\left(\right)open="\langle "\; close="\rangle ">L(x),R(x)$$
- (5)
- Use the polynomial identity test protocol to prove that Equation (7) holds and send $proof=\{{\tau}_{x},\mu ,T(x),\mathbf{L},\mathbf{R}\}$.

- $\{0,1\}\leftarrow ProofVer(proof)$. The verifier needs to check that if $\mathbf{L},\mathbf{R}\in proof$ are actually $L(x)$ and $R(x)$ and if Equation (7) holds. If the verification is passed, it means that a is indeed in the range $[0,{2}^{n}-1]$. Otherwise, it means that a is out of range and the commitment $CM$ is illegal.

**Remark**

**3.**

#### 2.4.2. Proof of Account Validity

**Definition**

**7**

**.**The "key-prefixed" variant of Schnorr signature is defined by the following three algorithms:

- $(x,X)\leftarrow KeyGen(x)$. Let G be the base point of $E({F}_{q})$, the public key X is generated by:$$X=x\xb7G$$
- $\sigma \leftarrow Sign(x,m)$. Pick the random number r, the signer calculates the random challenge c and the signature σ by the following steps. Here, $Hash$ denotes a collision-resistant hash function. In this paper, we use SHA256 to achieve it.$$R=r\xb7G,c=Hash(X,R,m),s=r+cx,$$$$\sigma =(R,s)$$
- $\{0,1\}\leftarrow Ver(\sigma ,X,m)$. If Equation (11) holds, the signature σ is valid and the output is 1. Otherwise, the output is 0.$$s\xb7G=R+c\xb7X$$

- $pp\leftarrow Setup({1}^{\lambda})$. For security parameter ${1}^{\lambda}$, it outputs public parameters $pp$ which will exist as implicit input in the following algorithms.
- $z\leftarrow zkpGen(x,m)$. For the value x to be proved and the auxiliary parameter m, this algorithm calls the schnorr signature scheme to generate the corresponding evidence z.$$(x,X)\leftarrow KeyGen(x),\sigma \leftarrow Sign(x,m)$$$$z=\{X,m,\sigma \}$$
- $\{0,1\}\leftarrow zkpVer(z)$. For the input z, if $1\leftarrow Ver(\sigma ,X,m)$, then the verification is passed, this algorithm outputs 1. Otherwise it outputs 0.

## 3. Ciphertext Equivalent Signature Scheme

**Definition**

**8.**

- $(\tilde{sk},\tilde{pk})\leftarrow KGen(sk)$. Let G be the base point of the elliptic curve $E({F}_{q})$. $Has{h}_{1}$ and $Has{h}_{2}$ are collision-resistant hash functions. The key pair $(\tilde{sk},\tilde{pk})$ is generated based on the original private key $sk$:$$\tilde{sk}=sk$$$$\tilde{{b}_{1}}=Has{h}_{1}(\tilde{sk}),\phantom{\rule{4pt}{0ex}}\tilde{{b}_{2}}=Has{h}_{2}(\tilde{sk})$$$$\tilde{pk}=\{\tilde{{b}_{1}}\xb7G\phantom{\rule{4pt}{0ex}}\left|\right|\phantom{\rule{4pt}{0ex}}\tilde{{b}_{2}}\xb7G\}$$In this paper, we implement Hash1 and Hash2 based on SHA256. Their construction methods are: $Has{h}_{1}=SHA256(0||x),Has{h}_{2}=SHA256(1||x)$. That is, we construct these two different hash functions by making simple changes to the input x.
- $Sig\leftarrow SGen(T,\tilde{sk})$. Generate a signature for transaction T by Equation (17). Here, $\tilde{{b}_{1}}$ and $\tilde{{b}_{2}}$ must be positive numbers that are not zero, and $\tilde{{b}_{1}}/\tilde{{b}_{2}}=\tilde{{b}_{1}}({\tilde{{b}_{2}}}^{-1})\phantom{\rule{4pt}{0ex}}mod\phantom{\rule{4pt}{0ex}}q.$$$Sig=Has{h}_{1}(T)(\tilde{{b}_{1}}/\tilde{{b}_{2}})\xb7G$$
- $\{0,1\}\leftarrow SVer(Sig,\tilde{pk})$. For bilinear pairing e, verify:$$e(Sig,\tilde{{b}_{2}}\xb7G)\phantom{\rule{4pt}{0ex}}=e(\tilde{{b}_{1}}\xb7G,Has{h}_{1}(T)\xb7G)$$If Equation (18) holds, the verification of $Sig$ is passed.

**Theorem**

**3**

**.**A adversary cannot successfully forge a valid signature without knowing the signer’s private key. That is, for any PPT adversary $\mathcal{A}$, there is a negligible function $negl(\lambda )$ that makes his advantage satisfy:

**Proof of Theorem**

**3.**

- (1)
- Attack on $\tilde{{b}_{1}}$ and $\tilde{{b}_{2}}$. For the hash function $Has{h}_{1}$, the adversary $\mathcal{A}$ needs to find a pair of collisions with the same hash value $\tilde{{b}_{1}}$. Similarly, $\mathcal{A}$ also needs to find a pair of collisions with the same hash value $\tilde{{b}_{2}}$ for $Has{h}_{2}$. That is, $\mathcal{A}$ needs to launch the strong collision attack on $Has{h}_{1}(T),Has{h}_{2}(T)$ at the same time and all succeed.
- (2)
- Attack on $(\tilde{{b}_{1}}/\tilde{{b}_{2}})$. $\mathcal{A}$ needs to launch an attack on ECDLP to $Sig$.

## 4. Overview of RZcoin

#### 4.1. System Model

- -
- Payer: When the payer wants to initiate a secret transaction, he needs to update the current commitment of secret assets (i.e., its balance commitment) based on the amount spent in this transaction. He also generates the commitment corresponding to the transaction amount. For these commitments, he needs to provide corresponding evidence to prove its legitimacy, such as range proofs. At the same time, he will use the public key of payee to encrypt the transaction amount and corresponding random number. These ciphertexts will be sent to the payee so that he can verify the correctness of the amount. The payer packages the above data into a transaction, signs it and sends it to the network.
- -
- Verifier: For the received secret transaction, the full node will verify the validity of the transaction signature, range proofs and the updated balance commitment. If the verification is passed, the transaction will be packaged into a block and recorded in the blockchain through distributed consensus.
- -
- Payee: For the secret transaction related to him in the blockchain, the payee uses his private key to decrypt the ciphertext in it and verifies the corresponding commitment. If the verification fails, the payee will publish the evidence to the network and declare the secret transaction invalid. If the verification is successful, the payee updates his locally stored balance and random numbers.

#### 4.2. Adversarial Model

#### 4.2.1. Balance Forgery Attack

#### 4.2.2. Signature Forgery Attack

#### 4.2.3. Over-Spending Attack

## 5. Description of RZcoin

#### 5.1. Notations

#### 5.2. Secret Initial Transaction

- (1)
- Call the key generation algorithm $KGen$ in CEs to generate the key pair $(\tilde{sk},\tilde{pk})$. At the same time, $\tilde{ID}$ will be generated based on $\tilde{pk}$. Its generation method is consistent with the same functional in Ethereum.$$(\tilde{sk},\tilde{pk})\leftarrow KGen(sk)$$
- (2)
- Set the initial balance $\tilde{B}=0$ and randomly select $\tilde{r}$ from ${Z}_{q}$ for subsequent commitment construction.
- (3)
- Calculate the commitment $\tilde{CM}$ of $\tilde{B}$. To prove that $\tilde{B}$ is 0, the proof generation algorithm $zkpGen$ in Szkp needs to be called to generate the corresponding evidence ${\tilde{Z}}_{\tilde{CM}}$. m here is set by the system and its value will not affect the generation of evidence.$$\tilde{CM}=\tilde{B}\xb7G+\tilde{r}\xb7H=\tilde{r}\xb7H$$$${\tilde{Z}}_{\tilde{CM}}\leftarrow zkpGen(\tilde{r},m)$$
- (4)
- Integrate the data generated in the above steps into $T{x}_{init}$.$$T{x}_{init}=\{\tilde{ID},\tilde{pk},\tilde{CM},{\tilde{Z}}_{\tilde{CM}}\}$$
- (5)
- Use $\tilde{sk}$ to sign this transaction, i.e., call the signature generation algorithm $SGen$ in CEs to generate the signature ${\tilde{\sigma}}_{init}$. Attach the signature to $T{x}_{init}$ and broadcast $T{x}_{init}$ through the network.$${\tilde{\sigma}}_{init}\leftarrow SGen(T{x}_{init},\tilde{sk})$$$$T{x}_{init}\leftarrow T{x}_{init}\left|\right|{\tilde{\sigma}}_{init}$$

- (1)
- Call the signature verification algorithm $SVer$ in CEs to verify the legality of ${\tilde{\sigma}}_{init}$. If it returns 1, the verification is passed. Otherwise, the algorithm is aborted and $T{x}_{init}$ is discarded.
- (2)
- Call the proof verification algorithm $zkpVer$ in Szkp to verify ${\tilde{Z}}_{\tilde{CM}}$. If it returns 1, the verification is passed. Otherwise, the algorithm is aborted and $T{x}_{init}$ is discarded.
- (3)
- If all above verifications are passed, the algorithm returns 1, otherwise 0.

#### 5.3. Secret Transaction

#### 5.3.1. Payer $\mathcal{A}$

- (1)
- Randomly select ${\tilde{r}}_{pay}\in {Z}_{q}^{\ast}$ to generate the commitment of ${\tilde{A}}_{pay}$, and update the locally saved variables;$${\tilde{B}}_{\mathcal{A}}^{new}={\tilde{B}}_{\mathcal{A}}^{old}-{\tilde{A}}_{pay}$$$${\tilde{r}}_{\mathcal{A}}^{new}={\tilde{r}}_{\mathcal{A}}^{old}-{\tilde{r}}_{pay}$$
- (2)
- For the updated balance ${\tilde{B}}_{\mathcal{A}}^{new}$, ${\tilde{r}}_{\mathcal{A}}^{new}$ is used to generate ${\tilde{CM}}_{\mathcal{A}}^{new}$. At the same time, ${\tilde{r}}_{pay}$ is used to generate ${\tilde{CM}}_{pay}$.$${\tilde{CM}}_{\mathcal{A}}^{new}={\tilde{B}}_{\mathcal{A}}^{new}\xb7G+{\tilde{r}}_{\mathcal{A}}^{new}\xb7H$$$${\tilde{CM}}_{pay}={\tilde{A}}_{pay}\xb7G+{\tilde{r}}_{pay}\xb7H$$
- (3)
- For the two commitments generated in the previous step, the proof generation algorithm $ProofGen$ in bulletproof is used to generate the corresponding evidence.$${\tilde{R}}_{{\tilde{CM}}_{\mathcal{A}}^{new}}\leftarrow ProofGen({\tilde{B}}_{\mathcal{A}}^{new},{\tilde{r}}_{\mathcal{A}}^{new})$$$${\tilde{R}}_{{\tilde{CM}}_{pay}}\leftarrow ProofGen({\tilde{A}}_{pay},{\tilde{r}}_{pay})$$
- (4)
- Use ${\tilde{pk}}_{\mathcal{B}}$ to encrypt ${\tilde{A}}_{pay}$ and ${\tilde{r}}_{pay}$. This operation allows $\mathcal{B}$ to confirm the transaction amount and verify it with the corresponding commitment to ensure that $\mathcal{A}$ has not cheated. The encryption algorithm here is not limited.$$C\leftarrow En{c}_{{\tilde{pk}}_{\mathcal{B}}}({\tilde{A}}_{pay},{\tilde{r}}_{pay})$$
- (5)
- Update the balance commitment of $\mathcal{B}$ and attach it to the transaction.$${\tilde{CM}}_{\mathcal{B}}^{new}={\tilde{CM}}_{\mathcal{B}}^{old}+{\tilde{CM}}_{pay}$$
- (6)
- Construct the secret transaction $T{x}_{\tilde{pay}}$ as follows, use ${\tilde{sk}}_{\mathcal{A}}$ to generate its signature by $SGen$ in CEs, and finally broadcast it through the network.$$T{x}_{\tilde{pay}}=\{{\tilde{ID}}_{\mathcal{A}},{\tilde{ID}}_{\mathcal{B}},{\tilde{CM}}_{\mathcal{A}}^{new},{\tilde{CM}}_{pay},$$$${\tilde{CM}}_{\mathcal{B}}^{new},{\tilde{R}}_{{\tilde{CM}}_{\mathcal{A}}^{new}},{\tilde{R}}_{{\tilde{CM}}_{pay}},C\}$$$${\sigma}_{\tilde{pay}}\leftarrow SGen(T{x}_{\tilde{pay}},{\tilde{sk}}_{\mathcal{A}})$$$$T{x}_{\tilde{pay}}\leftarrow T{x}_{\tilde{pay}}\left|\right|{\sigma}_{\tilde{pay}}$$

#### 5.3.2. Verifier

- (1)
- Call $SVer$ in CEs to verify the validity of ${\sigma}_{\tilde{pay}}$. If it returns 1, the verification is passed and the following steps can be continued. Otherwise the transaction is discarded.
- (2)
- Call the proof verification algorithm $ProofVer$ in bulletproof to verify ${\tilde{R}}_{{\tilde{CM}}_{\mathcal{A}}^{new}}$ and ${\tilde{R}}_{{\tilde{CM}}_{pay}}$. If they all return 1, the verification is passed and the following steps can be continued. Otherwise the transaction is discarded.
- (3)
- Respectively verify the algebraic relationship between these balance commitments. If Equations (37) and (38) hold, the verification is passed and the following steps can be continued. Otherwise the transaction is discarded.$${\tilde{CM}}_{\mathcal{A}}^{new}={\tilde{CM}}_{\mathcal{A}}^{old}-{\tilde{CM}}_{pay}$$$${\tilde{CM}}_{\mathcal{B}}^{new}={\tilde{CM}}_{\mathcal{B}}^{old}+{\tilde{CM}}_{pay}$$
- (4)
- If all above verifications are passed, the algorithm returns 1. Otherwise it returns 0.

#### 5.3.3. Payee $\mathcal{B}$

- (1)
- Use ${\tilde{sk}}_{\mathcal{B}}$ stored locally to decrypt the ciphertext C.$${\tilde{A}}_{pay},{\tilde{r}}_{pay}\leftarrow De{c}_{{\tilde{sk}}_{\mathcal{B}}}(C)$$
- (2)
- Use the decrypted ${\tilde{A}}_{pay}$ and ${\tilde{r}}_{pay}$ to verify the legitimacy of ${\tilde{CM}}_{pay}$. If the equation holds, the algorithm returns 1. Otherwise it returns 0.$${\tilde{CM}}_{pay}={\tilde{A}}_{pay}\xb7G+{\tilde{r}}_{pay}\xb7H$$

#### 5.4. Semi-Secret Transaction

#### 5.4.1. Scene 1

**Payer $\mathcal{A}$**:

- (1)
- Randomly select ${\tilde{r}}_{pay1}\in {Z}_{q}^{\ast}$ for the update operation of the random number saved by $\mathcal{B}$. Since the transaction amount is a public value, only the commitment corresponding to ${\tilde{r}}_{pay1}$ and its zero-knowledge proof need be generated.$${\tilde{CM}}_{{\tilde{r}}_{pay1}}={\tilde{r}}_{pay1}\xb7H$$$${\tilde{Z}}_{{\tilde{r}}_{pay1}}\leftarrow zkpGen({\tilde{r}}_{pay1},m)$$
- (2)
- Use ${\tilde{pk}}_{\mathcal{B}}$ to encrypt ${\tilde{r}}_{pay1}$ to get the ciphertext ${C}_{1}$. The ciphertext is sent to the $\mathcal{B}$ together with $T{x}_{pay1}$, assisting $\mathcal{B}$ to update the local random number.$${C}_{1}\leftarrow En{c}_{{\tilde{pk}}_{\mathcal{B}}}({\tilde{r}}_{pay1})$$
- (3)
- Update ${\tilde{CM}}_{\mathcal{B}}^{old}$ based on ${A}_{pay1}$.$${\tilde{CM}}_{\mathcal{B}}^{new}={\tilde{CM}}_{\mathcal{B}}^{old}+{A}_{pay1}\xb7G+{\tilde{r}}_{pay1}\xb7H$$
- (4)
- $\mathcal{A}$ update his open balance ${B}_{\mathcal{A}}^{old}$.$${B}_{\mathcal{A}}^{new}={B}_{\mathcal{A}}^{old}-{A}_{pay1}$$
- (5)
- Construct $T{x}_{pay1}$ as follows, use $s{k}_{\mathcal{A}}$ to generate the corresponding transaction signature, and finally broadcast $T{x}_{pay1}$ through the entire network. $SigGen$ is the original signature algorithm of the blockchain system (generally ECDSA).$$T{x}_{pay1}=\{I{D}_{\mathcal{A}},I{D}_{\mathcal{B}},{B}_{\mathcal{A}}^{new},{A}_{pay1},{\tilde{CM}}_{\mathcal{B}}^{new},$$$${\tilde{CM}}_{{\tilde{r}}_{pay1}},{\tilde{Z}}_{{\tilde{r}}_{pay1}},{C}_{1}\}$$$${\sigma}_{pay1}=SigGen(T{x}_{pay1},s{k}_{\mathcal{A}})$$$$T{x}_{pay1}\leftarrow T{x}_{pay1}\left|\right|{\sigma}_{pay1}$$

**Verifier**:

- (1)
- Call $SigVer$ to verify the legality of ${\sigma}_{pay1}$, if it returns 1, the verification is passed. Otherwise the transaction is discarded.
- (2)
- Call $zkpVer$ to verify the legality of ${\tilde{Z}}_{{\tilde{r}}_{pay1}}$. If it returns 1, the verification is passed. Otherwise the transaction is discarded;
- (3)
- Verify the correctness of the balance updates of $\mathcal{A}$ and $\mathcal{B}$. If Equations (49) and (50) hold, the verification is passed. Otherwise the transaction is discarded.$${B}_{\mathcal{A}}^{new}={B}_{\mathcal{A}}^{old}-{A}_{pay1}$$$${\tilde{CM}}_{\mathcal{B}}^{new}={\tilde{CM}}_{\mathcal{B}}^{old}+{A}_{pay1}\xb7G+{\tilde{CM}}_{{\tilde{r}}_{pay1}}$$

**Payee $\mathcal{B}$**:

- (1)
- Use the locally saved ${\tilde{sk}}_{\mathcal{B}}$ to decrypt the ciphertext ${C}_{1}$ to obtain the random number corresponding to the transaction.$${\tilde{r}}_{pay1}\leftarrow De{c}_{{\tilde{sk}}_{\mathcal{B}}}({C}_{1})$$
- (2)
- Use the decrypted ${\tilde{r}}_{pay1}$ to update the locally stored variables.$${\tilde{r}}_{\mathcal{B}}^{new}={\tilde{r}}_{\mathcal{B}}^{old}+{\tilde{r}}_{pay1}$$$${\tilde{B}}_{\mathcal{B}}^{new}={\tilde{B}}_{\mathcal{B}}^{old}+{A}_{pay1}$$

#### 5.4.2. Scene 2

**Payer $\mathcal{B}$**:

- (1)
- Randomly select ${\tilde{r}}_{pay2}\in {Z}_{q}^{\ast}$ to update the balance and random number of $\mathcal{B}$’s secret account stored locally.$${\tilde{B}}_{\mathcal{B}}^{new}={\tilde{B}}_{\mathcal{B}}^{old}-{A}_{pay2}$$$${\tilde{r}}_{\mathcal{B}}^{new}={\tilde{r}}_{\mathcal{B}}^{old}-{\tilde{r}}_{pay2}$$
- (2)
- Generate the commitment of ${\tilde{r}}_{pay2}$ and its corresponding zero-knowledge proof.$${\tilde{CM}}_{{\tilde{r}}_{pay2}}={\tilde{r}}_{pay2}\xb7H$$$${\tilde{Z}}_{{\tilde{r}}_{pay2}}\leftarrow zkpGen({\tilde{r}}_{pay2},m)$$
- (3)
- Generate the updated balance and commitment.$${\tilde{CM}}_{\mathcal{B}}^{new}={\tilde{B}}_{\mathcal{B}}^{new}\xb7G+{\tilde{B}}_{\mathcal{B}}^{new}\xb7H$$$${B}_{\mathcal{C}}^{new}={B}_{\mathcal{C}}^{old}+{A}_{pay2}$$
- (4)
- Call bulletproof to generate the corresponding evidence of the updated commitment.$${\tilde{R}}_{{\tilde{CM}}_{\mathcal{B}}^{new}}\leftarrow ProofGen({\tilde{B}}_{\mathcal{B}}^{new},{\tilde{r}}_{\mathcal{B}}^{new})$$
- (5)
- Construct $T{x}_{pay2}$ as follows, use ${\tilde{sk}}_{\mathcal{B}}$ to generate the transaction signature, and finally broadcast $T{x}_{pay2}$ through the entire network.$$T{x}_{pay2}=\{{\tilde{ID}}_{\mathcal{B}},I{D}_{\mathcal{C}},{\tilde{CM}}_{\mathcal{B}}^{new},{A}_{pay2},{B}_{\mathcal{C}}^{new},$$$${\tilde{R}}_{{\tilde{CM}}_{\mathcal{B}}^{new}},{\tilde{CM}}_{{\tilde{r}}_{pay2}},{\tilde{Z}}_{{\tilde{r}}_{pay2}}\}$$$${\sigma}_{pay2}\leftarrow SGen(T{x}_{pay2},{\tilde{sk}}_{\mathcal{B}})$$$$T{x}_{pay2}\leftarrow T{x}_{pay2}\left|\right|{\sigma}_{pay2}$$

**Verifier**:

- (1)
- Call $SVer$ to verify the validity of ${\sigma}_{pay2}$. If it returns 1, the verification is passed. Otherwise the transaction is discarded.
- (2)
- Call $zkpVer$ to verify the validity of ${\tilde{Z}}_{{\tilde{r}}_{pay2}}$. If it returns 1, the verification is passed. Otherwise the transaction is discarded.
- (3)
- Call $ProofVer$ to verify the validity of ${\tilde{R}}_{{\tilde{CM}}_{\mathcal{B}}^{new}}$. If it returns 1, the verification is passed. Otherwise the transaction is discarded.
- (4)
- Verify the correctness of the updated balance of $\mathcal{B}$ and $\mathcal{C}$. If Equations (64) and (65) hold, the verification is passed. Otherwise the transaction is discarded.$${B}_{\mathcal{C}}^{new}={B}_{\mathcal{C}}^{old}+{A}_{pay2}$$$${\tilde{CM}}_{\mathcal{B}}^{new}={\tilde{CM}}_{\mathcal{B}}^{old}-{A}_{pay2}\xb7G-{\tilde{CM}}_{{\tilde{r}}_{pay2}}$$

**Payee $\mathcal{C}$**:

## 6. Security Analysis

#### 6.1. Balance Forgery Attack

**RZcoin can resist the balance forgery attack**.

#### 6.2. Signature Forgery Attack

**RZcoin can resist the signature forgery attacks**.

#### 6.3. Over-Spending Attack

**Therefore, RZcoin can resist the over-spending attacks**.

## 7. Simulation and Performance Evaluation

#### 7.1. Configuration of Simulation Environment

#### 7.2. Evaluation of Improvements

#### 7.2.1. Evaluation of CEs

#### 7.2.2. Evaluation of Szkp

#### 7.2.3. Evaluation of Bulletproof

#### 7.3. Performance Evaluation

## 8. Conclusions

## Author Contributions

## Funding

## Acknowledgments

## Conflicts of Interest

## References

- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2019. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 15 June 2020).
- Wood, G. Ethereum: A Secure Decentralized Generalized Transaction Ledger. Ethereum project yellow paper, 151:1-32. 2014. Available online: https://ljk.imag.fr/membres/Jean-Guillaume.Dumas/Enseignements/ProjetsCrypto/Ethereum/ethereum-yellowpaper.pdf (accessed on 15 June 2020).
- Libra Whitepaper. 2019. Available online: https://libra.org/en-US/white-paper/ (accessed on 15 June 2020).
- Chaum, D. Blind signatures for untraceable payments. In Proceedings of the Advances in Cryptology: Crypto 82, Santa Barbara, CA, USA, 23–25 August 1982. [Google Scholar]
- Dai, W. b-Money. 1998. Available online: www.weidai.com/bmoney.txt (accessed on 15 June 2020).
- Back, A. Hashcash: A Denial of Service Counter-Measure. In Proceedings of the 2002 USENIX Annual Technical Conference, Monterey, CA, USA, 10–15 June 2002. [Google Scholar]
- Finney, H. Reusable Proofs of Work. 2004. Available online: https://cryptome.org/rpow.htm (accessed on 15 June 2020).
- Massias, H.; Avila, X.S.; Quisquater, J.J. Design of a secure timestamping service with minimal trust requirements [C]. In Proceedings of the 20th Symposium on Information Theory in the Benelux, Haasrode, Belgium, 27–28 May 1999. [Google Scholar]
- Haber, S.; Stornetta, W.S. How to time-stamp a digital document. J. Cryptol.
**1991**, 3, 99–111. [Google Scholar] [CrossRef] - Bayer, D.; Haber, S.; Stornetta, W.S. Improving the efficiency and reliability of digital time-stamping. In Sequences II: Methods in Communication, Security and Computer Science; Springer: New York, NY, USA, 1993; pp. 329–334. [Google Scholar]
- Haber, S.; Stornetta, W.S. Secure names for bit-strings. In Proceedings of the 4th ACM Conference on Computer and Communications Security, Zurich, Switzerland, 1–4 April 1997; pp. 28–35. [Google Scholar]
- Merkle, R.C. Protocols for public key cryptosystems. In Proceedings of the 1980 Symposium on Security and Privacy, Oakland, CA, USA, 14–16 April 1980; pp. 122–133. [Google Scholar]
- Bai, X.; Wang, L.C.; Zhou, L.J.; Yang, S.; Li, L. RZcash: A Privacy Protection Scheme for the Account-based Blockchain. In Proceeding ofthe 17th International Conference on Privacy, Security and Trust (PST), Fredericton, NB, Canada, 26–28 August 2019; pp. 1–9. [Google Scholar]
- Zhu, H.J. Research on The Ciphertext-Based Equivalent Test Scheme. Ph.D. Thesis, Beijing University of Posts and Telecommunications, Beijing, China, 2018. [Google Scholar]
- Luongo, M.; Pon, C.; Cardozo, A.S. Keep. Available online: https://github.com/keep-network/whitepaper (accessed on 15 June 2020).
- Microsoft. CCF. Available online: https://github.com/microsoft/CCF/blob/master/CCF-TECHNICAL-REPORT.pdf (accessed on 15 June 2020).
- Duffield, E.; Diaz, D. Dash: A Payments-Focused Cryptocurrency. Available online: https://github.com/dashpay/dash/wiki/Whitepaper (accessed on 15 June 2020).
- Sun, S.F.; Au, M.H.; Liu, J.K.; Yuen, T.H. RingCT 2.0: A Compact Accumulator-based(Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero. Eur. Symp. Res. Comput. Secur.
**2017**, 10493, 456–474. [Google Scholar] - Sasson, E.B.; Chiesa, A.; Garman, C. Zerocash: Decentralized Anonymous Payments from Bitcoin. In Proceedings of the 2014 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 18–21 May 2014. [Google Scholar]
- Rivest, R.L.; Shamir, A.; Tauman, Y. How to Leak a Secret: Theory and Applications of Ring Signatures. In Theoretical Computer Science; Springer: Berlin/Heidelberger, Germany, 2006; pp. 167–186. [Google Scholar]
- Back, A. Bitcointalk, Bitcoins with Homomorphic Value. 2014. Available online: https://bitcointalk.org/index.php?topic=305791.0 (accessed on 15 June 2020).
- Maxwell, G. Coinjoin: Bitcoin Privacy for the Real World. 2013. Available online: https://bitcointalk.org/index.php?topic=279249.0.2013 (accessed on 15 June 2020).
- Maxwell, G. Confidential Transactions. 2015. Available online: https://people.xiph.org/~greg/confidential-values.txt.2015 (accessed on 15 June 2020).
- Goldwasser, S.; Micali, S.; Rackoff, C. The knowledge complexity of interactive proof systems. SIAM J. Comput.
**1989**, 18, 186–208. [Google Scholar] [CrossRef] - Jedusor, T.E. Mimblewimble. 2016. Available online: https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt (accessed on 15 June 2020).
- Gabizon, A.; Zachary, J.W.; Ciobotaru, O. Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge. IACR Cryptol. ePrint Arch.
**2019**, 2019, 953. Available online: https://eprint.iacr.org/2019/953 (accessed on 15 June 2020). - Halo. Available online: https://github.com/haloplatform (accessed on 15 June 2020).
- Maller, M.; Bowe, S.; Kohlweiss, M. Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updatable Structured Reference Strings. In Proceedings of the 2019 ACM SIGSACConference on Computer and Communications Security, London, UK, 11–15 November 2019; pp. 2111–2128. [Google Scholar]
- Meiklejohn, S.; Mercer, R. Mobius: Trustless Tumbling for Transaction Privacy. Nephron Clin. Pract.
**2018**, 2018, 105–121. [Google Scholar] [CrossRef][Green Version] - Bnz, B.; Agrawal, S.; Zamani, M. Zether: Towards Privacy in a Smart Contract World. IACR Cryptol. ePrint Arch.
**2019**, 2019, 191. [Google Scholar] - Zachary, J.; Williamson. The AZTEC Protocol. 2018. Available online: www.aztecprotocol.com/ (accessed on 15 June 2020).
- Yu, C.; Ma, X. PGC: Pretty Good Confidential Transaction System with Accountability. IACR
**2019**, 2019, 319. [Google Scholar] - Li, X. Public-Key Cryptography Based on Elliptic Curve Discrete Logarithm Problem. Com. Eng. App.
**2002**, 38, 20–22. [Google Scholar] - Barreto, P.S.L.M.; Naehrig, M. Pairing-friendly elliptic curves of prime order. In International Workshop on Selected Areas in Cryptography; Spring: Berlin/Heidelberg, Germany, 2005; pp. 319–331. [Google Scholar]
- Torben, P. Pedersen: Non-interactive and information-theoretic secure verifiable secret sharing. In Proceedings of the Advances in Cryptology—CRYPTO 1991, Santa Barbara, CA, USA, 11–15 August 1991; pp. 129–140. [Google Scholar]
- Bunz, B.; Bootle, J.; Boneh, D. Bulletproofs: Short Proofs for Confidential Transactions and More. In 2018 IEEE Symposium on Security and Privacy (SP); IEEE: Piscataway, NJ, USA, 2018; pp. 315–334. [Google Scholar]
- Blum, M.; Feldman, P.; Micali, S. Non-interactive zero-knowledge and its applications (extended abstract). In Proceedings of the 20th Annual ACM Symposium on Theory of Computing, STOC 1988, Chicago, IL, USA, 2–4 May 1988; pp. 103–112. [Google Scholar]
- Bootle, J.; Cerulli, A.; Chaidos, P. Efficient zero-knowledge arguments for arithmetic circuits in the discrete log setting. In Proceedings of the Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, 8–12 May 2016; pp. 327–357. [Google Scholar]
- Maxwell, G.; Poelstra, A.; Seurin, Y. Simple Schnorr multi-signatures with applications to Bitcoin. Des. Codes Cryptogr.
**2019**, 87, 2139–2164. [Google Scholar] [CrossRef] - Bernstein, D.J. Multi-User Schnorr Security, Revisited. IACR Cryptology ePrint Archive. Report. 2015. Available online: http://eprint.iacr.org/2015/996 (accessed on 15 June 2020).
- GNU Multiple Precision Arithmetic Library. Available online: https://github.com/aleaxit/gmpy (accessed on 15 June 2020).

**Figure 2.**Algorithmic Composition of PKEwET-L in [14].

Transaction | |
---|---|

Hash | Hash value of the transaction |

AccountNonce | Total number of transactions initiated by sender |

GasInfo | Information about GAS of the transaction |

Sender | Address of the transaction sender |

Recipient | Address of the transaction recipient |

Amount | Transaction amount |

Timestamp | Creation time of the transaction |

Signature | Signature data for the transaction |

Payload | Other data of the transaction |

Notation | Description |
---|---|

${F}_{p}$ | Finite field with order p |

$G,H$ | Two points of $E({F}_{p})$, where G is the base point |

$(sk,pk)$ | Key pair of open accounts |

$(\tilde{sk},\tilde{pk})$ | Key pair of secret accounts |

$I{D}_{role}$ | Address of open account of $role$ |

${\tilde{ID}}_{role}$ | Address of secret account of $role$ |

${B}_{role}$ | Open balance of $role$ |

${\tilde{B}}_{role}$ | Secret balance of $role$ |

${\tilde{r}}_{role}$ | Random number required for ${\tilde{B}}_{role}$ |

${\tilde{CM}}_{role}$ | Commitment of ${\tilde{B}}_{role}$ |

${A}_{pay}$ | Transaction amount involving open assets |

${\tilde{A}}_{pay}$ | Transaction amount involving secret assets |

${\tilde{r}}_{pay}$ | Random number required for ${\tilde{A}}_{pay}$ |

${\tilde{CM}}_{pay}$ | Commitment of ${\tilde{A}}_{pay}$ |

${\tilde{R}}_{cm}$ | Range proof of $cm$ |

${\tilde{Z}}_{cm}$ | Zero-knowledge proof of $cm$ |

$\tilde{\sigma}$ | Signature generated by secret accounts |

$\sigma $ | Signature generated by open accounts |

**Table 3.**The Hardware and Software Configuration of RZcoin’s Test Environment [41].

Name | Configuration |
---|---|

CPU | 2.60GHz Intel(R) Core (TM) i7-6500U CPU |

OS | Ubuntu 18.04.2 LTS |

RAM | 8 GB |

python | 3.7.4 |

pypbc | 2.1.0 |

Parameter | Recommended Value |
---|---|

p | FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F |

a | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 |

b | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007 |

G | 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 |

N | FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 |

h | 01 |

CEs | ECDSA | |
---|---|---|

Time of KeyGen (/s) | 0.010977 | 0.000087 |

Time of SigGen (/s) | 0.001926 | 0.000452 |

Time of SigVer (/s) | 0.004263 | 0.001930 |

Size of Signature (/byte) | 56 | 296 |

Szkp(RZcoin) | ZKP(RZcash) | |
---|---|---|

Time of proofGen (/s) | 0.008463 | 0.000532 |

Time of proofVer (/s) | 0.005645 | 0.002015 |

Size of zkproof (/byte) | 200 | 304 |

N | 2 | 4 | 8 | 16 | 32 | 64 |

Bulletproof (/byte) | 1694 | 2046 | 2279 | 2521 | 2760 | 3012 |

RP (/byte) | 1604 | 3200 | 6376 | 12764 | 25598 | 51134 |

Name | Function | Caller |
---|---|---|

$AccountGen$ | used to build the secret account | users |

$AccountVer$ | used to verify $T{x}_{init}$ | full nodes |

$SecretPay$ | used to build secret transactions | payer |

$SecretVer$ | used to verify secret transactions | full nodes |

$SecretUpdate$ | used for local updates | payee |

$open2secretPay$ | used to construct semi-secret transactions in Scane1 | payer |

$open2secretVer$ | used to verify semi-secret transactions in Scane1 | full nodes |

$open2secretUpdate$ | used for local updates | payee |

$secret2openPay$ | used to construct semi-secret transactions in Scane2 | payer |

$secret2openVer$ | used to verify semi-secret transactions in Scane2 | full nodes |

N | 2 | 4 | 8 | 16 | 32 | 64 |

$T{x}_{init}$(/byte) | 450 | 449 | 452 | 450 | 454 | 452 |

N | 2 | 4 | 8 | 16 | 32 | 64 |

$T{x}_{\tilde{pay}}$(/byte) | 4036 | 4740 | 5206 | 5690 | 6168 | 6672 |

N | 2 | 4 | 8 | 16 | 32 | 64 |

$T{x}_{pay1}$(/byte) | 890 | 906 | 889 | 894 | 890 | 892 |

$T{x}_{pay2}$(/byte) | 2344 | 2696 | 2929 | 3171 | 3410 | 3662 |

© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Zhao, H.; Bai, X.; Zheng, S.; Wang, L.
RZcoin: Ethereum-Based Decentralized Payment with Optional Privacy Service. *Entropy* **2020**, *22*, 712.
https://doi.org/10.3390/e22070712

**AMA Style**

Zhao H, Bai X, Zheng S, Wang L.
RZcoin: Ethereum-Based Decentralized Payment with Optional Privacy Service. *Entropy*. 2020; 22(7):712.
https://doi.org/10.3390/e22070712

**Chicago/Turabian Style**

Zhao, Hong, Xue Bai, Shihui Zheng, and Licheng Wang.
2020. "RZcoin: Ethereum-Based Decentralized Payment with Optional Privacy Service" *Entropy* 22, no. 7: 712.
https://doi.org/10.3390/e22070712