Here we briefly compare the two approaches, showing their relative
strengths and weaknesses, first in a summary Table 2, followed by
Confidentiality. Confidential Transactions hide transaction values
whereas Zerocash hides all transaction information (except for timing).
Both Zerocash and Confidential Transactions hide the amount of money
transferred in transactions. However, CT does not hide the address of the
sender and the receiver. So “Transaction Graph Analysis” techniques like
[a], [b], [c], [d], and [e] may still potentially be used to connect
and trace them to endpoints like exchanges.
Transaction graph analysis can potentially be thwarted by mixing, for
example by using CoinJoin. But mixing comes with a variety of other
implementation challenges, security hazards, and costs; in particular, mixing
adds to blockchain bloat, and mixing is not implemented in Elements.
User Flexibility. Zerocash is an “all-or-nothing” protocol. There is
only one level of security, and that provides confidentiality against
unauthorized parties for both amounts and sender/receiver
addresses. Users cannot alter this.
(Note: users of Zerocash can make their transaction records transparent
to chosen authorized parties. The discussion about security levels here
is only about the level of security that the system provides against
snooping by unauthorized parties. Zerocash is designed to provide
nothing but maximal security against snooping by unauthorized parties.)
By contrast, Confidential Transactions allows per-transaction security
tuning, such as by trading off some amount of confidentiality for
smaller overhead .
This is a fundamental difference that affects usability, systemic
behavior, and many implementation issues. A usability difference might be
that in a CT system, a recipient may need to distinguish “how much
privacy” comes with the sender's amount, whereas in Zerocash there is a
known “standard amount of privacy”.
There may be systemic impacts: if many users opt to turn down their
privacy settings, then the few users who leave them high may draw
Finally, there are many implementation details this difference
affects. For example, all Zerocash transactions have the same shape
(number of inputs and outputs) and size to aide in indistinguishability,
whereas each CT transaction may have a different shape. This also may
have usability impact because if a user wants to split a value into many
new values, for example, their software must use multiple Zerocash
transactions, whereas CT software may choose to use either a single
transaction or more depending on other privacy or performance goals.
Transaction Size. Both systems use transactions which contain some
metadata along with one or more proofs related to the inputs or outputs.
Zerocash has only one transaction shape with 2 inputs and 2 outputs,
which is the minimum for splitting and joining values . Note also
that most payments require 2 outputs to account for change back to
For this standard transaction shape, the on-chain cost (blockchain bloat)
of a typical CT transaction is higher than that of Zerocash.
However, for other transactions, especially “sweep” transactions with
1 output and N inputs, a CT transaction is much smaller because range
proofs are unneeded.
Additionally, CT supports transactions with any number of inputs or
outputs, whereas ZC has a fixed shape.
Proof Size. The size of a full CT proof is, by default, 2.5Kb, compared
to 288 bytes for Zerocash. However, when a transaction has only a single
output, range proofs can be omitted from a transaction, and the remaining
proof structure requires only a single 33 byte Pedersen commitment.
The proof size for CT can also be run in ‘reduced size’ modes,
although this comes with a privacy tradeoff since it reveals more
information about balances. The Zerocash proof size reflects “full
privacy” mode, and there is no way to decrease the level of protection.
Finally, some of the CT proof can be recycled for a dual use, since it
can contain an encrypted message from the sender to recipient.
Proving Cost. The time it takes to create a transaction is much
larger in Zerocash than in CT, although both take longer than ordinary
Bitcoin transactions. We believe both are tolerable. Given these two
state-of-the-art approaches, there remains a tradeoff between cost and
Verification Cost. The transaction verification costs for both ZC and
CT transactions are higher than for Bitcoin, but both are likely
tolerable. On a desktop benchmark, a single thread can validate 175 ZC
pour transactions per second.
Pruning Support. CT provides pruning inherently, whereas ZC does
not have pruning currently.
Pruning allows a “full node” (i.e. a node that independently validates
every new transaction block) to reduce its storage costs by forgetting
about previously-spent transactions. In CT, a transaction output is
publicly known to be either spent or unspent, just as in Bitcoin, and
therefore Bitcoin-style pruning works “out of the box”.
By contrast Zerocash requires verifiers to remember a unique identifier
for every spent value, and in the current design this set grows
indefinitely. The paper presents potential optimizations which can
mitigate these storage requirements by making various tradeoffs (Sections
8.3.1 and 8.3.2 of the Zerocash paper in Peer Review).
Choices around pruning involve other nuanced trade-offs. For
example, systems which allow pruning spent outputs necessarily expose
information about the transaction graph and constrain what kinds of
sender/receiver graph confidentiality is possible.
Cryptographic Basis. CT and ZC rely on different cryptography. On the
one hand, CT relies on a variant of Schnorr signatures, whose security
can be based on either the elliptic-curve DL problem (ECDLP) and the
Random-Oracle (RO) assumption. On the other hand, ZC relies
on zkSNARKs whose security is based on variants of the Knowledge Of
Exponent (KoE) assumption for bilinear groups (instantiated via certain
pairing-friendly elliptic curves). Both the RO and KoE assumptions
have been studied by cryptographers for over two decades, but only the
former has seen widespread deployment in practice.
Peer Review. CT is a new application of well-understood cryptographic
primitives, and has been reviewed informally by industry experts.
The Zerocash protocol has been published in a peer reviewed academic
conference, as well as building on prior published work. Additionally
published work on Parameter Setup was presented at a conference this
zkSNARKs have been covered by many peer-reviewed publications.
Code Auditability. CT is open source. The ZC code is not yet
public, although a fundamental component, libsnark is currently
The community behind these projects highly value open source software. It
is crucial that security-related software, especially for critical
infrastructure such as global transaction systems, is auditable by
The ZC authors intend to release an open source prototype.
Parameter Setup. CT has very simple one-time initial parameter
selection which is amenable to common “nothing up my sleeve” selection
techniques. Zerocash has complex one-time initial parameter setup which
is vulnerable to compromise.
The Zerocash authors have presented new research on a secure multi-party
computation to improve the parameter setup security. This new setup
distributed protocol provides the guarantee that if even one party
involved in the setup follows the protocol correctly, then the setup is
secure. (Conversely all participants must be compromised for parameter