References
Zcash - Aleo - Zcash protocol specification Zexe protocol specification Zcash 1. About Zcash ? A to learn about Zcash. short video 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 and we only focus on the latest version. This article mainly introduces the core concepts of Zcash. protocol upgrades 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? 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. Unlinkable Private 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) Sender 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) Receiver address: Hide the note in the form of pedersen commitment, and ensure the balance attribute of the transaction by bindsig Value: 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 ( ), 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. zerocash 3.2 Why are they all UTXO -based, not account-based? Remark 2.3 (Zexe protocol specification: section 2.3, page 11)

Zcash

All About OlaVM and What Lies Ahead!

Going Deep into the Specification for Marlin

Nominated for 2022 - HackerNoon Contributor of the Year - Optimization

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Nominated for 2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Blockchain

Too Long; Didn't Read

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

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Study on Parallel Execution: Everything You Need to Know

A Complete Overview of Cryptography

Masks and Mysteries: Understanding Zero-Knowledge Proofs in a Halloween-Themed Costume Party

Could Banning Cryptography Keep the Country Safe?

Exploring Crypto-Anarchism: From Privacy to Cryptocurrencies and Beyond

How Does Google's Cryptographic Key Management Service Work?

A Study on Parallel Execution: Everything You Need to Know

A Complete Overview of Cryptography

Masks and Mysteries: Understanding Zero-Knowledge Proofs in a Halloween-Themed Costume Party

Could Banning Cryptography Keep the Country Safe?

Exploring Crypto-Anarchism: From Privacy to Cryptocurrencies and Beyond

How Does Google's Cryptographic Key Management Service Work?

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps