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 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.
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.
Monero scores very well on confidentiality, poorly on scalability, and poorly on auditability as well.
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.
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.
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 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.
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.
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 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.
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.
Learn more about BEAM on our website
Join our developer community: