Monero vs. Zcash vs. BEAM on Confidentiality, Scalability, and Auditability  by@Mimblewimble.

Monero vs. Zcash vs. BEAM on Confidentiality, Scalability, and Auditability

April 27th 2020 3,579 reads
Read on Terminal Reader
react to story with heart
react to story with light
react to story with boat
react to story with money
BEAM on Confidentiality, Scalability, and Auditability compares Monero vs. Zcash vs. Bitcoin. Monero scores very well on confidentiality, poorly on scalability and poorly on auditability. Zcash uses zk-SNARKs — a novel and very advanced form of zero-knowledge cryptography. ZCash has excellent privacy features, but there is no complete proof of completeness of the transactions. The size of an average transaction is about 2kB which is still many times greater than in Bitcoin.
Mimblewimble HackerNoon profile picture


Scalable privacy protocol enthusiast.

First, we would like to emphasize that we have a lot of respect for our friends at Zcash and Monero and the activities that these projects have completed so far in order to promote the needed financial confidentiality in crypto.

We will organize our comparison by looking at three parameters: confidentiality, scalability, and auditability. The comparison is quite advanced and does not claim to be complete — there are other played factors besides the three we have chosen to address.

Monero: Confidentiality

Monero enables confidentiality by using Ring Confidential Transactions (a combination of Confidential Transactions and Ring Signatures) and Stealth Addresses. Besides transactional privacy, there is no baked-in Network layer privacy in Monero.

Confidential Transactions hide the transferred amounts. With Ring Signatures, at least six “decoy” coins are added to each transaction, each looking equally likely to be the actual one spent in the transaction, thus making the actual source and destination next to impossible to trace.

That said, there are certain claims (see this study, for example) stating that there are ways to trace transactions on Monero network. We do not aim to confirm or contradict those claims.

Monero: Scalability

Due to the use of Ring Signatures, additional data is attached to each transaction, significantly increasing the size of the blockchain. At the time of this writing, Monero blockchain size is around 63.75 GB and will continue to grow with wider adoption, hurting usability.

We estimate that in Monero, the size of an average transaction is about 2kB which is still many times greater than in Bitcoin. Simply put, when Monero reaches Bitcoin’s current scale concerning the total number of transactions, its blockchain will be about 5 terabytes — hardly sustainable for a regular PC, let alone on smaller devices. It should be noted that Monero team has recently implemented bulletproofs which has improved scalability by up to 80% (which is still about 5 times more than Bitcoin).

Monero: Auditability

Monero offers a ViewKey feature to let a third party review the user’s transactions. However, it only allows seeing incoming transactions, not the outgoing ones, making it not very usable to auditors. Additionally, Monero has implemented Payment Proofs using which sender can prove an individual payment . In order to prove it, sender must provide Transaction key(Payment Proof) /Transaction id & receiver's address.

Monero: Summary

Monero scores very well on confidentiality, poorly on scalability, and poorly on auditability as well.

Zcash: Confidentiality

Zcash uses zk-SNARKs — a novel and very advanced form of zero-knowledge cryptography. Some people call zk-SNARKs “Moon Math” — that’s how arcane and presumably beautiful they are.

With zk-SNARKs, all transaction amounts, inputs, and outputs on the blockchain are entirely hidden. However, transactions on Zcash are not private by default. Previously, zk-SNARKs were computationally heavy to create (it takes 1–3 minutes on a regular PC to create a private transaction on Zcash), most users did not enabled them, hurting overall privacy of the network.

Zcash released the Sapling network upgrade which makes the performance of shielded transactions much more efficient, and allegedly increase the amount of private transaction on the Zcash network.

In addition, zk-SNARKs require a special secret key to set up the entire system. If this key leaks, the perpetrator can print money and thus destroy the coin. Zcash carries out intricate multi-person ceremonies to create this key, and we have no reason to doubt the integrity of the people involved. However, this is still a valid concern.

Zcash: Scalability

At the time of writing, Zcash blockchain size is around 25.82GB. Average size of tx is also many times higher than Bitcoin. While it is better than Monero, it is still much heavier than Bitcoin, which is also not scalable enough in that respect.

Zcash: Auditability

Similar to Monero, Zcash also has Viewing Keys, that allow an external viewer to track incoming transactions. In addition, there is a “payment disclosure” feature, beneficial when proving that a payment to an address was sent. There is no proof of completeness of the transactions.

Zcash: Summary

Zcash has excellent privacy features, but they are computationally heavy and see little use so far. Zcash scalability is better than Monero’s, but still poor, and the auditability is poor as well, although Zcash has plans to improve it.

BEAM: Confidentiality

BEAM is built on Mimblewimble, a very elegant protocol that allows for both confidentiality and scalability. Transaction amount, sender and receiver are hidden using Confidential Transactions, and there are no “addresses” in the system — each user just holds private keys to the UTXOs she owns.

Privacy in BEAM is enabled by default. Actually, there are no “open” transactions at all. Reading the blockchain would not yield any information to the observer.

In addition to Mimblewimble’s default privacy, BEAM also implements Dandelion, a networking policy which significantly improves anonymity. Dandelion prevents someone observing the network traffic to infer any valuable information.

Additionally Beam takes Dandelion implementation even further by adding Decoy (aka Dummy) UTXOs. At every step of Dandelion Stem Phase,Beam nodes check wether the merged transactions (might be only one tx) have atleast 5 outputs.

If not, decoy outputs are added to the merged txs, making sure that the number of outputs is at least 5.
You can view Beam blockchain explorers here or here and see that every block that has at least 2 kernels (meaning blocks that has at least one transaction which isn’t coinbase only) has at least 7 outputs (coinbase, fee, payee’s, 4 dummies).

Each one of the dummy outputs has a value of zero, but it is completely indistinguishable from regular outputs — all outputs look like random numbers.

At a later stage (a randomly chosen block height for each output), the node adds dummy UTXOs as inputs to a random transaction, most likely belonging to a different user, thus spending them and removing them from the blockchain, but also creating a relation between users that are in fact unrelated. Hence the “decoys” name.

It’s important to note that since those decoy outputs are eventually spent, the mechanism doesn’t create any permanent clutter on the blockchain.

BEAM: Scalability

In BEAM, the Mimblewimble cut-through mechanism is used to keep the blockchain small. The cut-through removes all the intermediate states of UTXOs, essentially leaving only unspent outputs on the blockchain. Thus, the blockchain size does not grow with the number of transactions, but with the number of UTXOs, which is overall much slower. The current Beam Blockchain size is ~ 9.111GB with Full sync & ~1.7GB with Fast sync.

We estimate that BEAM Blockchain size will be around 30% of Bitcoin’s, so the blockchain size should be below 70GB when BEAM reaches Bitcoin’s scale, making it possible to run a full node on smaller devices. We are actively researching additional improvements to Mimblewimble to make the blockchain even smaller (see Eliminating Transaction Kernels)

BEAM: Auditability

BEAM introduces the optional Auditability feature. BEAM users can create one or more Auditor keys that can be distributed to the parties of their choice, such as accountants, auditors, and even tax authorities.

Using those keys, the auditing party can review the transactions recorded on the blockchain, and also verify that the list of transactions is complete. Auditability is strictly optional and cannot be enabled retrospectively. See more in “What is Auditability” below.

BEAM: Summary

By implementing Mimblewimble, BEAM achieves excellent confidentiality and scalability, and our extensions to the protocol allow for excellent Auditability as well. We believe that BEAM has the features that any currency should strive to have if it has aspirations for wide adoption, and we are working hard to get there soon.

You can also read another piece of ours comparing Bitcoin, Monero, Zcash, and BEAM.

Learn more about BEAM on our website

Join our developer community: 

Gitter | Telegram | Reddit | Twitter | Discord

react to story with heart
react to story with light
react to story with boat
react to story with money

Related Stories

. . . comments & more!