Private Transactions: Insights to the Design Principles in ZCash and Aleo

References Zcash - Zcash protocol specification Aleo - Zexe protocol specification

Zcash

1. About Zcash ?

A short video to learn about Zcash.

Features:

• Anonymous version of BTC, UTXO-like model
• Can only be used for payment scenarios with no programmability

2. Main Concepts

Note: Zcash has undergone several protocol upgrades and we only focus on the latest version. This article mainly introduces the core concepts of Zcash.

2.1 Key Components

• sk : spend key, generated uniformly
• ask: spend authorizing key
• ak : spend validating key
• nk : nullifier deriving key
• rivk : randomness
• dk: diversifier key
• ivk : private key / incoming viewing key
• ovk : outgoing viewing key
• pkd : transmission key
• Spending key: secret key
• Full viewing key: decrypt the transaction context
• Incoming viewing key
• Outgoing viewing key
• Shielded payment address: should be different each time

You can learn about the computation methods of thesekeys in the Zcash protocol specification: section 4.2.3, page 36.

2.2 Notes

Note is the basic unit of the Zcash protocol, similar to the UTXO of BTC; in Zcash, the inputs and outputs of all transactions are notes. Of course, Zcash also supports non-anonymous transactions, identical to Bitcoin’s transaction model. Therefore, in order to further understand Zcash, you must know the data structure of note first:

• {d,pk_d}: address information of the owner of the note
• v : the corresponding amount of the note
• {ρ,ψ}: compute the random number of the nullifier
• rcm : being used to compute the random number of the note commitment

In the Zcash protocol, the note cannot be made public due to the requirement of privacy. Therefore, the corresponding commitment needs to be computed to represent the note. The computation method is as follows:

2.3 Action Transfer

A transaction may contain multiple action transfers, and each action transfer will spend the old note and generate a new note. The data structure is as follows:

• cv^{net}: being used for the balance check for action transfer in the form of binding signature without being included in the zk proof
• rt^{Orchard}: the treestate of the previous block, which is used to verify the spent note validity
• nf: the logo of the spent note, which is used to prevent the double spend
• rk: being used to verify that the spender has the right to the spend the note in the form of spendAuthSig signature verification
• cm_x: commitment of generating a new note
• epkepk temporary public key, which is used to decrypt the noteplaint information of the new note
• C^{enc},C^{out}: the encrypted ciphertext of the new note
• enbaleSpends, enableOutputs: indicating the type of the current action transfer
• π: zk proof

2.4 Action Statement

The public inputs are:
The privacy inputs are:
The statements to prove:

• Spent note integrity is uniquely bound to the noteplaint
• Spent note validity, existence proof of the cm tree
• Value commitment integrity is uniquely bound to rcv , old value, and new value
• Nullifier integrity prevents double spend and maintains a spent note set
• Spent note legitimacy
• Address integrity
• New note integrity
• Flag legitimacy

2.5 Transaction Constructions and Examples

2.5.1 Transaction construction

The entire transaction structure consists of four parts:

• Public info (1 - 5)
• Transparent transactions info (6 - 9)
• Sapling transactions info (10 - 16)
• Orchard transaction info (17 - 25)

2.5.2 From Transparent to Shield

The Orchard protocol includes two types of addresses, transparent address (TA) and shield address (SA). Generally, in order to execute a private transaction, it is necessary to transfer from TA to SA first. The corresponding transaction structure should be:

• Public info (1 - 5)
• Transparent transactions info (6 - 9)
  • tx_in _* : actual value
  • tx_out _* : default value
• Sapling transactions info (10 - 16)
  • All : default value
• Orchard transaction info (17 - 25)
  • All: actual value

2.5.3 From Shield to Shield

The Orchard protocol includes two types of addresses, transparent address (TA) and shield address (SA). Generally, in order to execute a private transaction, it is necessary to transfer from TA to SA first. The corresponding transaction structure should be:

• Public info (1 - 5)
• Transparent transactions info (6 - 9)
  • All : default value
• Sapling transactions info (10 - 16)
  • All : default value
• Orchard transaction info (17 - 25)
  • All: actual value

2.5.4 From Shield to Transparent

The Orchard protocol includes two types of addresses, transparent address (TA) and shield address (SA). Generally, in order to execute a private transaction, it is necessary to transfer from TA to SA first. The corresponding transaction structure should be:

• Public info (1 - 5)
• Transparent transactions info (6 - 9)
  • tx_in _* : default value
  • tx_out _* : actual value
• Sapling transactions info (10 - 16)
  • All : default value
• Orchard transaction info (17 - 25)
  • All: actual value

2.6 How is Privacy Achieved?

• Unlinkable
  The generated note is represented by cm, and the spent note is represented by nf. There is no connection between nf and cm. Therefore, no one can know in which transaction any generated note was spent.
• Private
  • Sender address:
    The transaction information does not contain the sender address and the spendAuthSig is a one-time signature (it is different every time, so the public key is different, rk)
• Receiver address:
  The transaction does not contain the receiver’s address and the new note plaint is encrypted by the receiver’s public key (the receiver’s private address is also one-time)
• Value:
  Hide the note in the form of pedersen commitment, and ensure the balance attribute of the transaction by bindsig

Aleo

1. The Similarities and Differences With Zcash

Zcash can only execute private transactions based on the OUTX model and have no programmability; therefore, the main difference between Aleo and Zcash is privacy programmability; and the similarity is that they both support privacy attributes (transaction privacy is not only limited to assets).

2. Aleo vs Zcash

2.1 Unit

Unlike the note of Zcash, the basic operation unit of Aleo is record (UTXO in BTC). Find the main differences between the two below:

Although the names of the specific parameters are different, there is a corresponding relationship between the two from the functional point of view: corresponding to the address information of the note owner, commitment-related information, nf/sn-related information, and value-related information, respectively.
Therefore, the structures of the two are quite similar; the main differences exist in the birth predicate and death predicate of the record, which are two Boolean-type functions, representing the conditions that need to be met when a record is in the birth(generate) and death(spend) stages. This part supports user-defined, so it’s programmable.

2.2 Transaction Construction

There are still some resemblances compared with the main construction of the transaction of Zcash (2.5.1):

• The corresponding serial number sn of the spent record, which is represented by nf in Zcash, is unique
• The commitment of the new record
• The plaint of the new record, including owner information, corresponding birth/death predicate, etc

2.3 Prover Statement

You need to prove:

• The old record validity
• The old record legitimacy (have the right to spend the record)
• The new record validity
• The birth/death predicate validity (similar to the balance check in Zcash)

3. More

3.1 Technologies not mentioned

From the perspective of the paper, the privacy design of Aleo 's programmable privacy design is more similar to the earlier Zcash white paper (zerocash), the similar key structure, the similar note structure and the similar name (nf is called sn in zerocash, serial number). This article makes a comparison based on the latest paper of Zcash and the ZEXE of Aleo. Although there are differences in specific details, such as the key structure and the specific cryptographic methods used, the high-level design is generally the same.
In addition to the technical details described above, there are still some other technical details that have not been mentioned yet, such as the delegate prover scheme, zero-knowledge proof algorithm, recursion/aggregation scheme, and so on. People interested in them can study further.

3.2 Why are they all UTXO -based, not account-based?

Remark 2.3 (Zexe protocol specification: section 2.3, page 11)