See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/343982243

On Privacy Preserving Blockchains and zk-SNARKs

Thesis · August 2019

DOI: 10.13140/RG.2.2.28164.55681

CITATIONS READS

0 501

1 author:

Shahla Atapoor
KU Leuven
4 PUBLICATIONS 7 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

On Privacy-Preserving Blockchains and zk-SNARKs View project

All content following this page was uploaded by Shahla Atapoor on 30 August 2020.

The user has requested enhancement of the downloaded file.

 UNIVERSITY OF TARTU
Institute of Computer Science
Computer Science Curriculum

Shahla Atapoor

On Privacy Preserving Blockchains and

zk-SNARKs

Master’s Thesis (30 ECTS)

Supervisor: Helger Lipmaa, PhD

Co-Supervisor: Janno Siim, MSc
Co-Supervisor: Karim Baghery, MSc

Tartu 2019
On Privacy Preserving Blockchains and zk-SNARKs

Abstract:
During last few years, along with blockchain technology, cryptocurrencies have found huge
attention from both commercial and scientific perspectives. Cryptocurrencies are digital coins
which use cryptographic tools to allow secure peer-to-peer monetary transactions. Bitcoin is the
most well-known cryptocurrency that allows direct payments between pseudonyms without any
third party. If a user’s pseudonym is linked to her identity, all her transactions will be traceable,
which will violate her privacy. To address this, various privacy-preserving cryptocurrencies
have been proposed that use different cryptographic tools to achieve anonymous transactions.
Zerocash is one of the most popular ones that uses zero-knowledge proofs to hide the source,
destination and value of each transaction.
This thesis consists of two main parts. In the first part, after a short overview of some
cryptocurrencies (precisely Bitcoin, Monero and Zerocoin), we will explain the construction
of Zerocash cryptocurrency and discuss the intuition behind the construction. More precisely,
we will introduce the deployed primitives and will discuss the role of each primitive in the
construction of the coin. In particular, we explain zero-knowledge Succinct Non-Interactive
Arguments of Knowledge (a.k.a. zk-SNARKs) that play the main role in achieving strong
privacy in Zerocash. Due to the importance of zk-SNARKs in privacy-preserving applications,
in the second part of the thesis, we will present a new variation of Groth’s 2016 zk-SNARK that
currently is the most efficient pairing-based scheme. The main difference between the proposed
variation and the original one is that unlike the original version, new variation guarantees non-
malleability of generated proofs. Our analysis shows that the proposed changes have minimal
effects on the efficiency of the original scheme and particularly it outperforms Groth and Maller’s
2017 zk-SNARK that also guarantees non-malleability of proofs.
Keywords:
Privacy preserving coin, Zerocash, Zero-knowledge proof, zk-SNARK
CERCS: P175 Computer Science

2
Privaatsed plokiahelad ja zk-SNARKid
Lühikokkuvõte: Viimastel aastatel on krüptoraha ja plokiahela tehnoloogia leidnud suurt
tähelepanu nii kaubanduslikust kui ka teaduslikust vaatenurgast. Krüptoraha kujutab endast
digitaalseid münte, mis kasutades krüptograafilisi vahendeid võimaldab turvalisi tehinguid
võrdvõrkudes. Bitcoin on kõige tuntum krüptoraha, mis võimaldab otsetehinguid kasutajate
pseudonüümide vahel ilma, et oleks vaja kolmandaid osapooli. Paraku kui kasutaja pseudonüüm
on seotud tema identiteediga, on kõik tema tehingud jälgitavad ning kaob privaatsus. Selle
lahendamiseks on välja pakutud erinevaid privaatsust säilitavaid krüptorahasi, mis kasutavad
anonüümsete tehingute saavutamiseks krüptograafilisi tööriistu. Zerocash on üks populaarseima-
test privaatsetest krüptorahadest, mis kasutab iga tehingu allika, sihtkoha ja väärtuse varjamiseks
nullteadmustõestust.
Antud töö koosneb kahest peamisest osast. Esimeses osas kirjeldame, pärast lühikest ülevaa-
det mõnest privaatsest krüptorahast (Bitcoin, Monero ja Zerocoin), Zerocashi konstruktsiooni ja
anname intuitsiivse seletuse selle tööpõhimõttele. Me tutvustame kasutuselevõetud primitiive
ja arutleme iga primitiivi rolli üle mündi konstruktsioonis. Erilist tähelepanu pöörame kom-
paktsetele nullteadmustõestusetele (zk-SNARKidele), millel on peamine roll Zerocashis. Kuna
nullteadmustõestus on niivõrd olulisel kohal Zerocashis (ja teistes privaatsetes rakendustes) siis
töö teises osas pakume välja uue variatsiooni Grothi 2016. aasta zk-SNARKile, mis on seni
kõige tõhusam. Erinevalt Grothi konstruktsioonist, meie variatsioonis ei ole võimalik tõestusi
modifitseerida. Muudatused mõjutavad nullteadmustõestuse tõhusust vaid minimaalselt ning
meie konstruktsioon on kiirem kui Grothi ja Malleri 2017. nullteadmustõestus, mis samuti
välistab muudetavuse.
Võtmesõnad:
Privaatne krüptoraha, Zerocash, Nullteadmustõestus, zk-SNARK
CERCS: P175 Informaatika

3
Dedication

Dedicated to the memory of my Mam,

Maliheh Hadbi

who always believed in my ability to be

successful in the academic arena.

4
Publications.
- Shahla Atapoor and Karim Baghery. Simulation Extractability in Groth’s zk-SNARK;
Data Privacy Management, Cryptocurrencies and Blockchain Technology - ESORICS
2019 International Workshops, DPM 2019 and CBT 2019, September 26-27, 2019,
Luxembourg [AB19].

5
Acknowledgments.
I would like to express my deep and sincere gratitude to my research supervisor Prof. Helger
Lipmaa and co-supervisors Karim Baghery and Janno Siim for giving me the opportunity to do
research and providing invaluable guidance throughout this research.
In addition to supervisors, my thanks go to Dr. Kateryna Pavlyk, Dr. Liina Tammekänd,
all my kind friends and my classmates that have contributed immensely to my personal and
professional time at Tartu university and without their support, I would not be able to continue
studying.
I am extremely grateful to my family specially my sister for their love, caring and sacrifices
for educating and preparing me for my future.
Finally, I would like to thank my Mom for her rare and unassuming love. I am following my
Mom’s dream of study and I hope she is happy in the sky.
The author was supported by the Estonian Research Council grant (PRG49) and the IT
academy Specialization Stipend of academic year 2017/2018.

6
Contents
1 Introduction 9
1.1 Goals and Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Preliminaries 13
2.1 Commitment Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Pedersen Commitment Scheme. . . . . . . . . . . . . . . . . . . . . . 14
2.2 Key-Private Public-Key Encryption . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 IND-CCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 IK-CCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 One-Time Secure Digital Signatures . . . . . . . . . . . . . . . . . . . 16
2.3.2 Linkable Ring Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 One-Way Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Universal One-Way Hash Functions . . . . . . . . . . . . . . . . . . . 18
2.4.2 Pseudo-Random Functions . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Nakamoto Consensus and Proof-of-Work . . . . . . . . . . . . . . . . . . . . 19
2.6 Decentralized Anonymous Payment (DAP) Schemes . . . . . . . . . . . . . . 20
2.6.1 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.2 Definition of Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.3 Requirements in a DAP Scheme . . . . . . . . . . . . . . . . . . . . . 23
2.7 Non-Intractive Zero-Knowledge (NIZK) Proofs . . . . . . . . . . . . . . . . . 24
2.7.1 zk-SNARKs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.2 Groth’s zk-SNARK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Privacy in Digital Coins 29

3.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.3 Security and Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Monero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 MLSAG Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Ring Confidential Transaction . . . . . . . . . . . . . . . . . . . . . . 32
3.2.3 Privacy of Ring CT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Zerocoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Zerocash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.4 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7
4 An Efficient Simulation Extractable zk-SNARK 43
4.1 A Variation of Groth’s zk-SNARK . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1 New Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2 Security Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Instantiation and Efficiency Evaluation . . . . . . . . . . . . . . . . . . . . . . 51

5 Conclusion 53

References 58
II. Licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8
1 Introduction
Distributed ledger and blockchain is a technology which stores data on a distributed blocks
are only in blockchain. In general distributed ledgers might not contain blocks that are linked
together by can it ever be anything else than hash function?. Due to distributed nature of the
network, there is no central node and central storage, while there is a consensus protocol to
extend the ledger concurrently continuously. As a ledger is kept by all nodes of the network, so
once a piece of data is entered to the ledger, it is difficult to remove or modify the data. Among
various application that this technology offers, the most known one is cryptocurrencies such as
Bitcoin [Nak08].
A cryptocurrency is a digital asset which allows one payer to perform direct payments
(transactions) without interference of a third party, unlike in classic electronic payment systems.
Cryptocurrencies use various cryptographic operations and primitives, but the main technology
behind them is the blockchain. Namely, a chain of blocks (a.k.a. ledger) is shared between
a large number of nodes that is write-only and records list of transactions between addresses
(e.g. account numbers) of individual users. Nodes of the network run a consensus protocol to
get agreement on the transactions that should be recorded in the ledger. As a result there is
no central point to make a decision about a transaction to be recorded, instead if majority of
nodes (more precisely computation power of nodes) confirm a valid transaction, then it will
be recorded in the ledger and the ledger will be extended. The most famous and widely used
cryptocurrency is Bitcoin (at time of writing the thesis) that was proposed by an unknown person
or a group of people; known as Satoshi Nakamoto [Nak08].
In Bitcoin, each user has an address and a secret key to control the address. Strictly speaking,
a user can get a direct transaction on her public address, but in order to be able to spend the
received coin, she must know the secret key of that address. These public addresses of users
are known as pseudonyms. The system avoids double spending a coin with broadcasting all
transactions to all nodes and recording them on a public distributed ledger. As the ledger of
Bitcoin is distributed and public, and transactions are done between pseudonyms, then once a
user’s pseudonym is linked to her identity, all her transactions will be traceable which violates her
privacy. Indeed, there are various studies [RH11, RS13, FKP15] that looking at the transactions’
graph, by some empirical analysis, can extract lots of information about the goal of transaction,
amount of money and the sender of the transaction, which means that system leaks some personal
information. In practice, such attacks can have different negative effects. As an example, if you
are a merchants, once your competitor knows what your address is, they can track your cash
flow, track your costumers and a lot of valuable business information may be leaked.
To address this concern, various privacy preserving cryptocurrencies have been proposed
[MGGR13, BCG+ 14a, Noe15] that use different cryptographic techniques to provide strong
security for end-users. For instance by hiding the source, destination and the value of a
transaction. A possible solution for hiding the sender of a transaction is mixing the transactions
by a trusted party, but this would require trust in a third party. In this scenario, the Bitcoin users
need to send their coins to a third party, to use laundry for mixing the coins, and wash them
up, and get them back. (They get different coins but with the same value). This approach still
has some problems including that the time which is needed to have the coins completely mixed
must be large enough and the possibility of stealing and tracing the coin by the mixer. On the
other hand, the legitimate users require following: (1) they want to have secure transactions, (2)
they want to it without having much effort, and (3) sometimes they may even not be aware of

9
weakness of privacy.
Zerocoin that is presented by Mires et al. [MGGR13] tackled the mentioned problems with an
interesting cryptographic technique. In their system, the users who wish to have their transaction
history hidden can use the help of Mixes (laundries). Zerocoin Created an anonymous protocol
that users do not need to trust to the third party, since there is a single party (third party) that
uses cryptographic proofs to ensure that the mixing was done correctly. Zerocoin does have
some constrains in performance and functionality. Regarding performance, one problem is that,
those proofs that are required to ensure the correct operation of the mix are about 45 KB per
transaction (for 128-bit security) and they take about half a second to verify. Moreover these
mixes can only work on the values of the same denomination, which means that one cannot split
values and just can spend multiple coins of the same denominations. It is discussed that this can
leak information about the transactions [BCG+ 14a]. In Zerocoin each user still has to take his
coins, load them to laundry service and wash them clean and get them back, which still requires
partial trust to a third party.
Monero [Noe15] is another elegant cryptocurrency that deals with privacy concern in Bitcoin.
Monero uses ring signatures which allows a spender remain hidden in a group of potential signers.
Technically speaking, a ring signature mixes the spender’s input with a group of individuals,
which makes it computationally hard to make a connection or link between each subsequent
transaction [Noe15]. To guarantee privacy of recipient of a transaction, Monero generates stealth
address for each transaction that make the transaction anonymous to anyone except the spender
and recipient. The value of each transaction is hidden by committing to the values.
A recent proposal Quisquis [FMMO18] aims to solve the same privacy concern in Bitcoin
by combining various cryptographic tools including updatable public keys, shuffle arguments
and zero-knowledge proofs. Intuitively, in their coin, a spender gives a zero-knowledge shuffle
proof for updating commitments and public key of two coins (coins of sender and receiver)
among a set of coins.
Ben-Sasson et al. [BCG+ 14a] presented an improved version of Zerocoin [MGGR13] and
Pinocchio Coin [DFKP13] that also allows completely anonymous transactions. Zerocash uses
an efficient type of zero-knowledge proofs [GMR89] that are known as zero-knowledge Succinct
Non-interactive ARguments of Knowledge (zk-SNARK) [PHGR13].
Among various type of Non-Interactive Zero-Knowledge (NIZK) arguments, zk-SNARKs
[Gro10, Lip12, PHGR13, BCTV13, Gro16, GM17] are the most efficient and practically in-
teresting zero-knowledge proofs that have appeared in various applications including cloud
computing [PHGR13], privacy-preserving cryptocurrencies [BCG+ 14a], privacy-preserving
smart contracts [KMS+ 16, JKS16, Bag19], distributed storage [BG18a] and faster ledger ver-
ification [MS18]. Majority of known zk-SNARKs are designed to guarantee completeness,
zero-knowledge and (non-black-box) knowledge soundness [PHGR13, BCTV13, Gro16]. Com-
pleteness guarantees that an honest prover always convinces an honest verifier. Non-black-box
knowledge soundness ensures that a malicious prover cannot convince the honest verifier, unless
she knows the witness. Equivalently, if an adversarial prover can convince a verifier, she must
know the witness. Zero-knowledge property assures that the proof generated by prover does not
leak any information about the witness other than the validity of the statement. Formal defini-
tions will be given later in Sec. 2.7.1. Currently the most efficient zk-SNARK is the one that is
proposed by Groth in Eurocrypt 2016 [Gro16]. Groth’s zk-SNARK is constructed for Quadratic
Arithmetic Programs 1 (QAPs) and works over bilinear groups. While using zk-SNARKs in prac-
1
As an NP language where for an input x and witness w, (x, w) ∈ R can be verified by using a parallel quadratic

10
tical systems, their knowledge soundness property is not enough to guarantee non-malleability of
proofs. In other words, knowledge-sound proofs are vulnerable to the man-in-the-middle attacks
where adversary modifies and reuses an existing proof. Due to this fact, zk-SNARKs that only
guarantee knowledge-soundness cannot be deployed in many of practical applications straightfor-
wardly [BCG+ 14a, KMS+ 16, JKS16, Bag19]. For instance, privacy-preserving crypocurrencies
such as Zerocash that uses zk-SNARKs [BCTV13, Gro16] as a subroutine, takes extra steps to
prevent malleability attacks in the SNARK proofs for pour transactions [BCG+ 14a]. Similarly,
privacy-preserving smart contract systems [KMS+ 16, JKS16] show that knowledge-soundness
of zk-SNARKs is not enough for their systems. Simulation-knowledge soundness which also
is known as simulation extractability, is an amplified version of knowledge-soundness that is
proposed to achieve extractable and non-malleable proofs. A Simulation-Extractable (SE) zk-
SNARK guarantees the proof is succinct, zero-knowledge and simulation-extractable, meaning
that an adversarial prover is unable to come out with a new proof unless he knows a witness,
even if he has already seen arbitrary number of simulated proofs.
As mentioned before, Groth’s zk-SNARK [Gro16] is the most efficient zk-SNARK in the
CRS model which requires a trusted third party to generate a common reference string shared
between prover and verifier, but it does not guarantee non-malleability of proofs. In Crypto
2017, Groth and Maller [GM17] proposed the first SE zk-SNARK that is constructed for Square
Arithmetic Programs 2 (SAPs) and guarantees non-malleability of proofs. In practice, Groth
and Maller’s SAP-based SE zk-SNARK[Gro16] is significantly more inefficient than Groth’s
QAP-based zk-SNARK [KZM+ 15]. Later in Sec. 4 we will compare empirical performance of
both zk-SNARKs. To recap, we construct an efficient version of Groth’s zk-SNARK which will
guarantee non-malleability of proofs and will act better than Groth and Maller’s SE zk-SNARK
[GM17] in all efficiently metrics, which can be used in practically interesting constructions.

1.1 Goals and Contribution

Roughly speaking, this thesis chases two main goals. The First part focuses on the privacy-
preserving cryptocurrencies and the second part considers achieving simulation extractability in
the stat-of-the-art zk-SNARK.
During last few years various practical systems [KMS+ 16, JKS16, CMP+ 19] have started
to use Zerocash protocol to enable privacy-preserving payments. Initial goal of the thesis is to
present a high level explanation of Zerocash cryptocurrency while describing the main ideas
behind its structure. We additionally highlight main differences between Zerocash and some
other cryptocurrencies. To this aim, after a short overview of some cryptocurrencies including
Bitcoin and Monero, we will go trough the construction of Zerocash step-by-step and describe
the main ideas and intuition behind the structure of each part (or algorithm) of the coin. Precisely
speaking, we will introduce the primitives deployed in the construction of coin and will discuss
the role of each one. In particular, we will explain zk-SNARKs that is the main primitive in
construction of Zerocash to achieve strong anonymity. We will introduce the state-of-the-art
zk-SNARK that recently Zerocash has started to use.
In the second part of the thesis, due to importance of zk-SNARKs in privacy preserving
applications, we propose a variation of Groth’s zk-SNARK [Gro16] that can achieve simulation-
check.
2
As an NP language where for an input x and witness w, (x, w) ∈ R can be verified by using a parallel squaring
check.

11
extractability and consequently can gaurantee non-malleability of proofs. To this aim, we show
that one can define a new language L0 , using an OR-based construction, based on original
language L in Groth’s zk-SNARK that is appended with a pseudo-random function fs (·) and
a commitment of the secret randomness s. The secret randomness s will act as a key for a
pseudorandomn function. Based on new language L0 we construct a variation of original scheme
that can achieive simulation extractability. The intuition for a pseudo-random function fs (·) is
that without the knowledge of the key s, fs (·) behaves like a true random function. However,
given s, one can compute fs (·) easily. In new language L0 , for a statement-witness pair to be
valid, either a witness for RL is provided (by honest prover) or an opening to commitment of s
together with the value of fs (pkSign ) is provided (by simulator), where pkSign is the public key of
a signature scheme. One may note that in order for a statement to pass the verification without a
valid witness, the prover must generate fs (pkSign ) without the knowledge of s which requires to
break the pseudo-random function fs .
Analysis and implementations show that in practical cases overload has minimal effects on
the efficiency of the original scheme.

Publications. Our results in Sec. 4 is accepted to be published in proceeding of 3rd Inter-

national Workshop on Cryptocurrencies and Blockchain Technology - CBT’19 3 [AB19]. In
the published paper, the author of this thesis read related literature, participated in several
discussions and wrote initial version of security proofs for the proposed construction. Moreover,
the author had active contribution in writing and revising the paper.

1.2 Outline
The structure of thesis is as follows: Section 2 presents an overview on some background
concepts that are used in the later sections. We consider privacy in cryptocurrencies and
introduce some known anonymous cryptocurrencies in Section 3. In the same section, we will
explain Zerocash and the underlying algorithms with more details and explanations. As the
second contribution of the thesis, in Section 4, we present a variation of Groth’s zk-SNARK that
can achieve simulation-extractability efficiently. Finally, we conclude the thesis in Section 5.

3
http://deic.uab.cat/conferences/cbt/cbt2019/

12
2 Preliminaries
This section presents an overview of cryptographic primitives involved in the rest of thesis. We
review the cryptographic primitives such as commitment schemes, key-private public key encryp-
tion, one-time secure digital signatures, one-way functions, Non-Interactive Zero-Knowledge
(NIZK) arguments and particularly zero-knowledge Succinct Non-Interactive Arguments of
Knowledge (zk-SNARKs) that are an efficient type of NIZK arguments.

Notations. Let n ∈ N is the security parameter, say n = 128, and 1n shows its unitary
representation. We use Pr[x : y] to show the probability that y happens for experiment x. A
function f : F → R with F = N, R is negligible (shown with negl(n)) iff for all c > 0 such
that f (x) ≤ x−c for sufficiently large x. Let PPT denote probabilistic polynomial-time, and
NUPPT denote non-uniform PPT. All adversaries will be stateful. For an algorithm A, let
im(A) be the image of A, i.e. the set of valid outputs of A, let RND(A) denote the random
tape of A, and let r ← RND(A) denote sampling of a randomizer r of sufficient length for
A’s needs. By y ← A(x; r) we denote the fact that A, given an input x and a randomizer r,
outputs y. For algorithms A and ExtA , we write (y||y 0 ) ← (A||ExtA )(x; r) as a shorthand for
y ← A(x; r), y 0 ← ExtA (x; r). We denote by negl(n) an arbitrary negligible function. For
distributions A and B, A ≈c B means that they are computationally indistinguishable.

2.1 Commitment Scheme

Commitment schemes are one of the key tools in cryptography that are deployed in various
applications and larger cryptographic systems. A commitment scheme usually has two phases:
committing phase and opening phase. At the committing phase, a committer commits to a secret
value. After a while, in the opening phase, committer opens the commitment and reveals the
committed value (and some secret information) that allows a verifier to check whether the same
value has been committed.
The nature of a commitment scheme requires two essential properties that are known as
hiding and binding. First requirement is that, the receiver of a commitment should not be
able to learn any information about the committed value before opening it by the committer
itself; this property is known as hiding. The second requirement from a commitment scheme is
that the committer can not change the committed value after committing. In other words, the
committer should not be able to commit a message in first phase and then open it to a different
message; this property is known as binding. Later we will see that, commitment schemes play an
essential role in construction of the DAP scheme behind the Zerocash to provide strong privacy.
A commitment scheme formally can be defined as follows.

Definition 1 (Commitment Schemes). A commitment scheme is a tuple of efficient algorithms

ΠCom = (KGen, Com, OpenVerify) such that,

• Key Generation Phase, ck ← KGen(1n ):Generates a commitment public key ck. It

specifies a message space Mck , a randomness space Rck , and a commitment space Cck .
Given 1n , the algorithm computes a commitment key ck.

• Committing Phase, (cm, op) ← Com(ck, m): Outputs a commitment cm and an opening
information op. This algorithm specifies a function Com :Mck × Rck → Cck . Given a

13
 message m ∈ Mck , the sender picks a randomness ρ ∈ Rck and computes the commitment
(cm, op) = Com(ck, m).

• Opening Phase, 0/1 ← OpenVerify(ck, cm, m, op): Outputs 1 if the value m ∈ Mck is
the committed message in the commitment cm and 0 if (m, op, cm) does not correspond
to a valid opening.

The commitment scheme ΠCom = (KGen, Com, OpenVerify) is secure if it satisfies the
following properties:

Correctness. Let ck ← KGen(1n ). Any honestly generated commitment of m ∈ Mck as

(cm, op) ← Com(ck, m), will successfully pass the verification by OpenVerify(ck, cm, m, op).

Hiding. For any adversary A, it is difficult to generate two messages m0 , m1 ∈ Mck such that
A can distinguish between their corresponding commitments cm0 and cm1 where (cm0 , op0 ) ←
Com(ck, m0 ) and (cm1 , op1 ) ← Com(ck, m1 ). In the other term, the probability of winning the
game depicted below for the adversary is negl(n). Meaning that the advantage of adversary A
in the following game is negligible:

ck ←$ KGen(1n ), (m0 , m1 ) ← A(ck), b ←$ {0, 1},

 
1
Pr = + negl(n) .
(cmb , opb ) ← Com(ck, mb ), b0 ← A(ck, cmb ) : b = b0 2

where b ←$ {0, 1} denotes uniformly sampling a bit.

Binding. It is computationally hard, for any adversary A, to come up with a collision

(cm, m0 , op0 , m1 , op1 ), such that op0 and op1 are valid opening values for two different pre-
images m0 6= m1 for cm. Formally speaking, the success probability of polynomial time A is
negligible in the following game,

ck ←$ KGen(1n ), (cm, (m0 , op0 ), (m1 , op1 )) ← A(ck) : (m0 6= m1 )∧

 
Pr = negl(n) .
(OpenVerify(ck, cm, m0 , op0 ) = 1) ∧ (OpenVerify(ck, cm, m1 , op1 ) = 1)
In the later sections, we will see that Zerocash instantiates commitment schemes with some
collisions resistant hash functions.

2.1.1 Pedersen Commitment Scheme.

One of the most known and widely used commitment schemes is Pedersen commitment
scheme [Ped91], that guarantees computationally binding and perfectly hiding. The bind-
ing property of the scheme relies on the discrete logarithm problem. The definition of this
commitment scheme is summarized below.

Definition 2 (Pedersen Commitment). Pedersen commitment scheme is a tuple of efficient

algorithms as ΠCom = (KGen, Com, OpenVerify) such that,

• Key Generation Phase, ck ← KGen(1n ): Generates the description of a group G of

prime order p together with two generators (g, h) ← G2 . It specifies a message space
Mck , a randomness space Rck , and a commitment space Cck . It returns ck := (G, p, g, h);

14
 • Committing Phase, (cm, op) ← Com(ck, m): Let Zp be a multiplicative group of integers
modulo p, where p is a prime number. Given ck and the message m ∈ Zp , it samples a
randomness r ←$ Zp and computes and returns the commitment (cm, op) := (g m hr , r).

• Opening Phase, 0/1 ← OpenVerify(ck, cm, m, op): Outputs 1 if the value m ∈ Mck is
the committed message in the commitment cm by checking g m hr = c; otherwise returns 0.

2.2 Key-Private Public-Key Encryption

Public-key encryption is one of the key concepts in cryptography that allows two parties to
communicate securely on a public channel without sharing a secret key. A standard public-key
encryption scheme is a set of three algorithms ΠEnc = (KGen, Enc, Dec) that are defined as
follows,

• Key Generation Phase, (pkEnc , skEnc ) ← KGenEnc (1n , ppEnc ): Given public parameters
ppEnc , KGenEnc samples a public key and a secret key for a user.

• Encryption Phase, c ← Enc(pkEnc , m): Given a public key pkEnc and a message m,
algorithm Enc encrypts m and outputs a ciphertext c.

• Decryption Phase, m ← Dec(skEnc , c): Given a secret key skEnc and a ciphertext c,
algorithm Dec decrypts ciphertext c an outputs the message m (or ⊥ if decryption fails).

Zerocash uses a particular type of public key encryption scheme that is called key-private
public-key encryption (proposed by Bellare et al. [BBDP01]) and provides slightly more security
than the a standard public key encryption scheme. A key-private public-key encryption scheme
ΠEnc is required to satisfy two security properties. First, ciphertext indistinguishability under
chosen-ciphertext attack (IND-CCA security), and second key indistinguishability under chosen-
ciphertext attack (IK-CCA security). However the first property is quite known about encryption
schemes, but the second one is defined particularly for a key-private public-key encryption
scheme and intuitively an IK-CCA notion requires that ciphertexts cannot be linked to the public
key used to encrypt them, or to other ciphertexts encrypted with the same public key. Precise
definitions of these two properties are explained in the rest of the subsection.

2.2.1 IND-CCA
IND-CCA stands for Indistinguishability Under Chosen Ciphertext Attack and the formal
definition is as follows,

Definition 3 (IND-CCA security). A public key encryption scheme ΠEnc = (KGenEnc , Enc, Dec),
consisting of a key-generation algorithm KGen, an encryption algorithm Enc, and a decryption
algorithm Dec, is IND-CCA (indistinguishable under chosen ciphertext attacks) if for any
polynomial time algorithm A, we have that

(pk, sk) ← KGenEnc (1n ), (m0 , m1 ) ← ADec(sk,·) (pk), b ←$ {0, 1},

 
1
Pr 0 0
= + negl(n) .
c ← Enc(pk, mb ), b ← A(c) : b = b 2

where c is a some arbitrary information that A wants to send.

15
2.2.2 IK-CCA
IK-CCA stands for Key Indistinguishable Under Chosen Ciphertext Attack and the formal
definition is as follows,

Definition 4 (IK-CCA Security). Let ΠEnc = (KGenEnc , Enc, Dec) be an encryption scheme. Let
A be an adversary which has access to the oracles Dec(sk0 , ·) and Dec(sk1 , ·). By considering
this, an encryption scheme ΠEnc is said to be IK-CCA secure if the success probability of any
polynomial time adversary A is negligible in the following game,

(pk0 , sk0 ) ← KGenEnc (1n ), (pk1 , sk1 ) ← KGen(1n ),

 
 1
Pr (x, s) ← ADecsk0 (.),Decsk1 (.) (pk0 , pk1 ), b ←$ {0, 1},  = + negl(n) .

2
y ← Encpkb (x), b0 ← A(y, s) : b = b0

where s is a some arbitrary information that A wants to send.

2.3 Digital Signatures

Digital signature is a cryptography tool for providing data integrity and non-malleability. A
digital signature is used to authenticate the real sender of a message on a public channel. In a
public-key based digital signature scheme, there is a pair of public and secret key, where the
secret key is used to sign a message by a sender, and receiver can use the public key to verify
the validity of a given message-signature pair.

2.3.1 One-Time Secure Digital Signatures

The standard security requirement for a signature scheme is unforgeability which is defined
as "strong unforgeability" property of signatures meaning that, there is no bounded adversary
who can forge a valid signature without knowing the secret key. Formal definition and strong
unforgeability of digital signatures and property of this schemes are described bellow.

Definition 5 (Digital Signature). A digital signature scheme ΠΣ is a tuple of algorithms as

ΠΣ = (KGenSign , Sign, Vf) working as follows:

• Key Generation Phase, (sk, vk) ← KGenSign (1n ): given the security parameter 1n as
input to the key generation, it will produce a pair of keys (sk, vk) where sk is the secret key
for signing the message and vk is the public key for verifying a message-signature pair.

• Signing Phase, σ ← Sign(sk, m): given a secret key sk and a message m to the the
signing algorithm Sign as input, the output will be a signature σ.

• Verification Phase, 0/1 ← Vf(vk, m, σ): given a triple vk, m, σ to the verification algo-
rithm Vf, it will output 1, checking with verification key vk, if σ is the valid signature of
the massage m, otherwise it will output 0.

16
UF-CMA Security. As mentioned above an essential security requirement from a signature
scheme ΠΣ is unforgeability against chosen-message attacks (UF-CMA security) which its
formal definition can be expressed as follows.

Definition 6 (UF-CMA security). A digital signature scheme ΠΣ is UF-CMA-secure if the

probability of winning for any forger F running in time poly (n) and making Q = poly (n)
signing queries, in the following game is negligible:
" #
n ∗ ∗ Sign(vk,·)
(pk, vk) ← KGen Sign (1 ), (m , σ ) ← F (pk) :
Advuf−cma
ΠΣ ,F (n) = Pr = negl(n) .
Vf(vk, m∗ , σ ∗ ) = 1 ∧ (m∗ is "new")

As a strengthened version, strong unforgeability against chosen-message attacks (SUF-CMA)

is a bit stronger than just UF-CMA. In SUF-CMA signatures there is a checking for freshness
of both message and signature. In the other words, the verification algorithm checks whether
the pair (m∗ , σ ∗ ) is "new", i.e. if (m∗ , σ ∗ ) is different from all the pairs (mi , σi ) obtained by F
from the signing oracle.

Zerocash uses a one-time strong unforgeability against chosen-message attacks (SUF-1CMA

security) signature scheme to prevent malleability attacks on transactions. SUF-1CMA security
is a particular case of SUF-CMA which the scheme only is secure for one time using.

2.3.2 Linkable Ring Signatures

Linkable ring signatures are one type of digital signatures that allows anonymous signing and
is proposed by Rivest et al. [?] in 2001. Later we will observe that linkable ring signatures
are the main primitives in Monero cryptocurrency to achieve unlinkability in transactions. In a
short comparison, common cryptographic digital signatures allow to link transactions to their
respective senders and receivers. But a protocol based on linkable ring signatures allows users
to achieve unlinkability. A linkable ring signature can be formally defined as the following.

Definition 7 (Linkable Ring Signatures). A linkable ring signature consists of four algorithms
(KGenSign , Sign, Vf, Link) defined as,

• Key Generation Phase, (sk, vk) ← KGenSign (1n ): given the security parameter 1n as
input to the key generation, it will produce a pair of keys (sk, vk) where sk is the secret
key for signing the message and vk is the public key for verifying a signature.

• Signing Phase, σ ← Sign(ski , T, m): given a secret key ski where i ∈ N , tag T =
(issue, vkN ) and message m ∈ {0, 1}∗ to the signing algorithm Sign as input, it outputs a
signature σ.

• Verification Phase, 0/1 ← Vf(vk, T, m, σ): given tag T = (issue, vkN ), message m ∈
{0, 1}∗ and a signature σ to the verification algorithm Vf, it will output 1, checking with
verification key vk, if σ is the valid signature of the massage m, otherwise it will output 0.

• Link Phase, "indep", "linked", or vk ← Link(vk, T, {(m, σ), (m0 , σ 0 )}): given tag T =
(issue, vkN ), two message/signature pairs, {(m, σ), (m0 , σ 0 )} to the link algorithm Link,
it will output one of the following strings: "indep" if they σ and σ 0 are from different
parties of the group; "linked" if m = m0 ; or vk otherwise, where vk ∈ vkN .

17
 Generally, a linkable ring signature satisfies the following security properties [FS07].
• Public Traceability: Anyone who creates two signatures for different messages w.r.t. the
same tag can be traced, where the trace can be done only with pairs of message/signature
pairs and the tag.
• Tag-Linkability: Every two signatures generated by the same signer w.r.t. the same tag
are linked, that is, the total number of signatures w.r.t. the same tag cannot exceed the
total number of ring members in the tag, if any two signatures are not linked.
• Anonymity: As long as a signer does not sign on two different messages w.r.t. the same
tag, the identity of the signer is indistinguishable from any of the possible ring members.
Additionally, any two signatures generated with respect to two distinct tags are always
unlinkable. Namely, it is infeasible for anyone to determine whether they are generated by
the same signer.
• Exculpability A honest ring member cannot be accused of signing twice w.r.t. the same
tag — Namely, an adversary cannot produce a traceable ring signature such that, along
with one generated by the target, it can designate the target member in the presence of
the publicly traceable mechanism. This should be infeasible even after the attacker has
corrupted all ring members but the target.

2.4 One-Way Functions

One-way functions (OWFs) are another prominent cryptographic primitives that is used in
construction of Zerocash. A OWF is a function that can be computed efficiently, but, as it can
be guessed from the word one-way, finding any pre-image of a random image can not be done
efficiently (finding pre-image means inverting). The formal definition of one-way functions is as
follows,
Definition 8 (One-Way Function). A function f : {0, 1}∗ → {0, 1}∗ is a one-way function if,
• Efficient: f can be evaluated in polynomial time
• One-Way: For every polynomial time adversary A, the following probability is negligible
in security parameter n:

Pr[A(1n , f (x)) ∈ f −1 (f (x)) : x ←$ {0, 1}n ] = negl(n) .

We will later see that Zerocash instantiates OWFs with hash functions. So in the rest, we
recall definition of Universal One-Way Hash Functions that are closely related to OWFs.

2.4.1 Universal One-Way Hash Functions

Universal one-way hash functions are a flavour of cryptographic one-way functions that have
appeared in various applications.
Definition 9 (Universal One-Way Hash Family). A collection of function families H = {Hn }
where each Hn is a function family Hn = {h : {0, 1}l(n) → {0, 1}q(n) } is an universal one-way
hash family if:

18
 • Efficient: The functions q(n) and `(n) are polynomially-bounded; furthermore, given n
and x ∈ {0, 1}q(n) the value h(x) can be computed in polynomial time.

• Compressing: For all n we have that q(n) > `(n).

• Universal one-way: For all polynomial time adversary A, the following probability is
negligible in the security parameter n:
" #
x ← A(1n ), h ←$ Hn , x0 ← A(1n , h, x) :
Pr = negl(n) .
x, x0 ∈ {0, 1}q(n) ∧ x 6= x0 ∧ h(x) = h(x0 )

2.4.2 Pseudo-Random Functions

A pseudo-random function family, abbreviated PRF, is a collection of efficiently-computable
functions which emulate a random oracle in the following way: no efficient algorithm can
distinguish (with significant advantage) between a function chosen randomly from the PRF
family and a random oracle (a function whose outputs are fixed completely at random). It can
be formally defined as below.

Definition 10. A function f : K × M → N (where f, K, M , and N may depend on the security

parameter n) is a (, q, τ )-pseudo-random function (PRF) if for all τ -time algorithms A that
make at most q queries we have that,

Pr b∗ = 1 : k ←$ K, b∗ ← Af (k,·) () ≈c Pr b∗ = 1 : π ←$ F unM →N , b∗ ← Aπ ()
   

where F unM →N denotes the set of all functions from M to N .

2.5 Nakamoto Consensus and Proof-of-Work

Consensus protocols are essential to check the authenticity of distributed ledgers and making
agreement among nodes of a a distributed network. Strictly speaking, in Bitcoin, in order to
extend the ledger and add a new block, nodes of the network need to participate in a consensus
protocol that is known as Nakamoto consensus protocol. Nakamoto Consensus protocol, that
is proposed by Satoshi Nakomoto, allude to the Proof-of-Work (PoW) consensus model in
conjunction with a set of rules in Bitcoin network, that govern the procedure of consensus and
guarantees its security. Bitcoin is the first practical open and distributed peer-to-peer network
that uses a distributed network of anonymous nodes that can leave or join at will.
Briefly speaking, Nakamoto consensus protocol can be expressed in four blocks as follows:

• Proof-of-Work (PoW): In comparison with other parts, PoW is the most important part
that drives consensus in Bitcoin. In a PoW work system, a particular work (or puzzle) is
given to a user and then is asked to give a proof that the work is done (provide a solution).
Similarly, in Bitcoin a miner uses a specific node to compete in a PoW competition to
mine new blocks and earn the block reward, that is issued for each successfully mined
and validated block. Contributing in the competition of mining is based on node’s
computational power, as nodes need to solve a puzzle which needs huge computations.
Precisely speaking, nodes are given a task that "For given random challenge c find a nonce
such that first x bits of Hash(c || nonce) are zero bits." So, the more power a node assigns

19
 to the competition, the more likely she will be selected to mine the next block. One may
note that the process of PoW is stochastic, so it basically is sort of a lottery with random
chance of wining, so it is not determined who will win the next round. The longest chain
is considered the valid chain as it came from the pool with largest computational power.
We note that given c and nonce, verifying whether Hash(c || nonce) = target value can
be done efficiently, as it is the case in verification of PoW puzzle’s solution. The validation
ensures that proposed blocks have the requisite computational work performed to be
accepted and as long as honest parties controls majority of the network’s computational
power the main ledger will remain secure.

• Block Selection: In the PoW, the miners in the network all compete to solve the given
puzzle and the first one who managed to solve it wins the round of the lottery. In other
words, the result of PoW is that when puzzle is solved by a particular miner, the miner
proposes next block to the network, and then the network verifies the validity of the
proposed block before adding to the ledger. If all the transactions within the proposed
block are valid, and the block is added to the longest chain, the proposed block will be
added to the ledger.

• Scarcity: Traditionally precious metals were the main form of value storage and com-
merce. Two main reason that they were used, and still keep their value (e.g. gold), are that
they are scarce and also require so much effort (similar to PoW in Bitcoin) to mine and
then use them.
In Bitcoin, scarcity is based on the fact that the total number of Bitcoins that will be mined
will be restricted to 21 million. More importantly, new Bitcoin are inserted into the system
by geometric rewinding, meaning that the reward for mining a block reward is halved
every 210,000 blocks which by considering the fact that currently each block of Bitcoin is
constructed in 10 minutes, and every 4 years the block reward will be divided by 2.

• Incentive Structure: Having a incentive structure in a digital coin allows to long-term

vested owners and participants in the network of coin to further secure and validate the
network of coin. Block rewarding is the strategy that Bitcoin uses to incentivise miners to
validate and support the network. By this strategy, in the case of drop in value of Bitcoin
or other related concerns, they also will be affected.

2.6 Decentralized Anonymous Payment (DAP) Schemes

In order to construct Zerocash, initially Ben Sasson et al. defined the notion of Decentralized
Anonymous Payment scheme (DAP scheme) that is an extended version of the notion of decen-
tralized e-cash proposed in [MGGR13]. In this section, we review their DAP scheme and later
show that Zerocash is a construction for this notion. Initially, we review data structures deployed
in the scheme and then introduce its algorithms and properties.

2.6.1 Data Structures

Later we will observe that their proposed DAP scheme (denoted by DAP) uses the following
data structures.

20
Basecoin ledger. The DAP scheme is constructed to act on top of a ledger-based digital coin,
e.g. Bitcoin, which is called basecoin. At time T , all nodes have access to an append-only ledger
LT . Extra from provided transactions in basecoin (precisely Bitcoin), new DAP scheme allows
two new type of transactions called TranMint and TranPour that will be introduced later.
Public parameters. The DAP scheme has a list of public parameters pp that are generated
once by a trusted third party and shared with all users (nodes). Later we will see that these are
some public parameters for the deployed primitives (e.g. signature scheme, encryption scheme
and zero-knowledge proof system).
Addresses. In the DAP scheme, each user generates two address keys as public address key
addrpk and secret address key addrsk . To do a direct payment one needs addrpk of the receiver
and to receive a payment, the addrsk corresponding to the addrpk is required. Each node requires
to generate at least one key pair.
Coins. In the DAP scheme, each coin is shown with c that contains following four piece of
information. 1) Coin commitment cm: In the minting process of a coin, a string will be pro-
duced which is called coin commitment, denoted with cm, and will appear on the ledger.
2) Coin value v: Each coin has a positive value which is an integer less equal than Vmax
(i.e. 0 ≤ V ≤ Vmax , where Vmax is maximum possible coin value allowed in the scheme).
3) Coin serial number sn: To prevent double spending of coins, each coin has a unique serial
number that will be determined in (minting) coin c and will be revealed when the coin is spent.
4) Coin address addrpk : Each coin has public address which belongs to the owner.
New transactions. As briefly mentioned above, extra from Bitcoin, new DAP scheme provides
two more type of transactions that are called TranMint and TranPour . 1) Mint transaction, TranMint :
A mint transaction is required in the case of minitng new coin and is defined as a tuple (cm, v, ∗),
where cm is a coin commitment, v is a coin value, and ∗ is some extra information related to
the transaction. Each transaction TranMint shows that a coin c with the coin commitment cm
and the value v has been minted. 2) Pour transaction, TranPour : A pour transaction is required in
anonymous payments and is defined a tuple (rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , info, ∗), where
rt is a root of the Merkle tree containing all coin commitments, snold old
1 and sn2 are serial numbers
of two coins that are going to be spent, cmnew 1 and cmnew
2 are commitments of two new coins
that are going to be created, Vpub is a coin value which is public, info is a string to determine
the destination of Vpub , and ∗ is extra information used in implementation. Each transaction
TranPour takes two old coins cold old old old
1 and c2 with the serial numbers sn1 , sn2 respectively and
mints (produces) two new coins cnew 1 and cnew
2 with respective coin commitments cmnew 1 and
new
cm2 . Note that Vpub is considered to pay transaction fee and could be zero as well. The info
string determines who is the recipient of Vpub , and mentioned above rt is the root of the Merkle
tree over all coin commitments when the transaction was produced.
Commitments of minted coins (CMListT ) and serial numbers of spent coins (SNListT ). In
the DAP scheme, at each time T , there are two universal lists which are shared with all nodes
and updated frequently. First one is CMListT that contains the list of all coin commitments
which are created after each mint or pour transactions and appeared on the ledger. Second one is
SNListT that contains serial numbers of all the spent coins by time T (that appear on the ledger).
Merkle tree over coin commitments. Recall that a Merkle tree [Mer] is a tree in which
every leaf node is labelled with the hash of a data block and every non-leaf node is labelled
with the cryptographic hash of the labels of its child nodes. A Merkle tree allows efficient

21
and secure verification of the contents of large data structures. A graphical representation
of a sample Merkle tree is shown in Fig.1. In the DAP scheme, in each pour transaction, to
spend a coin, a spender needs to prove that she knows the secret information about the target
coin. In order to make that procedure efficient, at any time T , TreeT shows a Merkle tree over
all coin commitments in CMListT and rtT shows its root. The function PathT (cm) gives the
authentication path from a coin commitment cm appearing in CMListT to the root rtT .

Figure 1. A Merkle tree over commitments cmi for i = 1, 2, . . . , 8. Each inner node of the tree
is the hash value of the concatenation of its two children.

2.6.2 Definition of Algorithms

A DAP scheme ΠDAP is a tuple of polynomial time algorithms ΠDAP = (Setup, CreateAddress,
Mint, Pour, VerifyTransaction, Receive) which are defined as below,

• Setup Algorithm, pp ← Setup(1n ): Given a security parameter n generates public

parameter pp needed in other algorithms. This algorithm is executed only once by a
trusted third party or by some distributed authorities.

• Create Address, (addrpk , addrsk ) ← CreateAddress(pp): Given the public parameters

pp, it generates a key pair (addrpk , addrsk ), where addrpk is public address and addrsk is
the corresponding secret address. In the DAP scheme, the sender sends coins to the addrpk
of receiver and receiver used addrsk to redeem coins sent to addrpk .

• Minting Coin, (c, TranMint ) ← Mint(pp, v, addrpk ): This algorithm is used to create
a new coin with a special value. Given the public parameters pp, coin value v ∈
[0, . . . , Vmax ], and receiver’s addrpk it produces a coin c and a mint transaction TranMint to
record the coin c in the ledger. The mint transaction TranMint consists of (cm, v, ∗), where
cm is the coin commitment, v is the value of coin and ∗ some extra information required
to register on the ledger (e.g. randomnesses used in generating cm).
old
• Pour (Spending) Algorithm, (cnew new old old
1 , c2 , TranPour ) ← Pour(pp, rt, c1 , c2 , addrsk,1 ,
addrold new new new new
sk,2 , Path1 , Path2 , V1 , V2 , addrpk,1 , addrpk,2 , Vpub , info): This algorithm is used to
spend two old coins and produce two new coins along with a pour transaction TranPour
to record the procedure on the ledger. To do so, given public parameters pp, the Merkle
old old
root rt, old coins cold old
1 and c2 , old address secret keys addrsk,1 and addrsk,2 , path Path1
from commitment cm(cold old
1 ) to the root rt and path Path2 from commitment cm(c2 ) to the
new new new new
root rt, new values V1 and V2 , new addresses public keys addrpk,1 and addrpk,2 , public

22
 value Vpub , and transaction string info, it produces two new coins cnew1 and cnew
2 for the
new new
public address keys addrsk,1 and addrsk,2 , respectively. It also outputs some public value
which can be spend as the transaction fee.
This algorithm allow to merge coins, subdivide coins into smaller denominations and also
do public payments. To check the validity of spent coins, the algorithm takes the root rt of
the Merkle tree over all the coin commitments and verifies the authentication paths Path1
and Path2 which should go to two spent coins. The algorithm also takes values v1new and
v2new as values of two new anonymous coins cnew 1 and cnew
2 with the corresponding address
new new
public keys addrpk,1 and addrpk,2 . The input Vpub shows the amount which is publicly
spent, for instance for transaction fees. The summation of the new coins’ value plus the
Vpub must be exactly equal to the the summation of the old coins’ value. The input info is
an arbitrary string related to destination of Vpub .
The output of algorithm consists of two new coins cnew 1 and cnew
2 and a pour transaction
TranPour . The transaction TranPour contains the root rt, two old coins’ serial numbers
snold old
1 and sn2 , two commitments’ of new coins cm1
new
and cmnew
2 , the public value Vpub , a
arbitrary string info and ∗, where ∗ is some related information (e.g. randomnesses).

• Verifying Transactions, {0, 1} ← VerifyTransaction(pp, Tran, L): This algorithm is

used to check if a transaction is valid. Given the public parameters pp, a mint or pour
transaction Tran and the current ledger L, it returns either 1 (if the transaction is valid) or
0 (if the transaction is invalid). In practice, this algorithm is executed by the nodes of the
distributed network to verify the transactions.

• Receiving Transactions, {a set of received coins} ← Receive(pp, addrpk , addrsk , L): This
algorithm is used to receive the coins sent to a particular public address. More precisely,
given public parameters pp, an address key pair (addrpk , addrsk ) and the current ledger L,
it scans the ledger and returns the set of coins sent to the (target) public address addrpk .
The algorithms returns the corresponding coins that their serial number have not published
on the list of serial numbers SNList.

2.6.3 Requirements in a DAP Scheme

Based on the definition of Ben Sasson et al. [BCG+ 14a], a DAP scheme should guarantee
completeness, ledger indistinguishability, transaction non-malleability, and balance that we
briefly introduce in the rest (in later sections we will consider these notions more formally):
Completeness of a DAP scheme. Intuitively the completeness of a DAP scheme requires
that unspent coins can be spent. Namely, running algorithm Pour results in a pour transaction
TranPour that VerifyTransaction accepts it, and the new coins can be received by the target
recipients by running the algorithm Receive; additionally, TranPour correctly records the intended
Vpub and transaction string info on the ledger.
Ledger indistinguishability in a DAP scheme. This property captures the requirement that
the ledger reveals no new information to the adversary beyond the publicly-revealed information
(values of minted coins, public values, information strings, total number of transactions, etc.),
even when the adversary can adaptively induce honest parties to perform DAP operations of
his choice. That is, no bounded adversary A can distinguish between two ledgers L0 and L1 ,

23
constructed by A using queries to two DAP scheme oracles, when the queries to the two oracles
are publicly consistent: they have matching type and are identical in terms of publicly-revealed
information and the information related to addresses controlled by A.
Transaction non-malleability. This property requires that no bounded adversary A can alter
any of the data stored within a (valid) pour transaction TranPour . This transaction non-malleability
prevents malicious attackers from modifying others’ transactions before they are added to the
ledger (e.g., by re-targeting the Basecoin public output of a pour transaction).
Balance. This property requires that no bounded adversary A can own more money than what
he minted or received via payments from others.

2.7 Non-Intractive Zero-Knowledge (NIZK) Proofs

Zero Knowledge (ZK) proofs is a cryptographic tools that has recently appeared in various
applications for different reasons including users privacy or efficient verification. A ZK proof
allows a prover to convince a verifier that some statement is correct without revealing any
information except the truth of the statement. For example, a prover can prove that she lives in
a European country without revealing her personal information or name of her home country.
ZK proofs can be either interactive or non-interactive. Usually non-interactive proofs are more
convenient and popular, as they can be generated without verifier’s participation and verifier
or verifiers can check the proof whenever they are available. In other words, in the real world,
any interactivity between prover and verifier needs some communication over a network, which
raises some latency issues.
It has been shown that Non-Interactive Zero-Knowledge (NIZK) arguments can be con-
structed in the Random Oracle (RO) model or Common Reference String (CRS) model. In the
RO model, we assume that both prover and verifier have access to a RO, which does not exists
and in practice and it is instantiated instead with a collision-resistant hash function.
On the other hand, in the CRS model there is a trusted third party who generates a CRS
containing: proving key pk for prover and verification key vk for verifier. Prover uses pk and
generates a proof π which can be verified by any verifier (in publicly verifiable proofs).
Among various techniques for NIZK proofs, zero-knowledge Succinct Non-interactive
ARguments of Knowledge (zk-SNARKs) are the most practical and popular one. These types
of zero-knowledge proofs are the main primitives in the structure of Zerocash, so in the rest of
section, we introduce this type of NIZK arguments with an example that currently is used in
Zerocash protocol.

2.7.1 zk-SNARKs
As already mentioned zk-SNARKs are the most popular and practical type of NIZK proofs.
Indeed, this comes form the fact that they generate succinct proofs which allows very fast
verification. Due to high efficiency, beside Zerocash, recently zk-SNARK are found in various
applications that aims to guarantee strong privacy (e.g. smart contracts). As in the rest of thesis,
we will talk about zk-SNARKs and using them in Zerocash, so in this we recall the definition of
zk-SNARKs and then briefly summarize the state-of-the-art zk-SNARK which was proposed by
Groth [Gro16] and recently deployed in Zerocash.

24
Definition of zk-SNARKs Initially, we recall the definition of zk-SNARKs for arithmetic
circuit satisfiability. For a field F, an F-arithmetic circuit4 takes some elements in F as input, and
output some elements in F. A circuit is associated with the function that the circuit computes.
In Zerocash, they consider the circuits that have an input x ∈ Fn and an auxiliary input or a
witness w ∈ Fh . It is assumed that the circuits only have bilinear gates. A gate with inputs
w, (1, y1 , · · · , ym )i h · h~b, (1, y1 , · · · , ym )i for some
y1 , · · · , ym ∈ F is bilinear if the output is h~
~ , ~b ∈ F
w m+1
, where h·, ·i shows the inner product. These support addition, multiplication,
negation, and constant gates. By considering this, for the boolean case, the arithmetic circuit
satisfiability is defined as below,

Definition 11 (zk-SNARK). The arithmetic circuit satisfiability problem of an F-arithmetic

circuit C : Fn × Fh → Fl is captured by the relation RC = {(x, w) ∈ Fn × Fh : C(x, w) = 0l };
its language is LC = {x ∈ Fn : ∃w ∈ Fh s.t. C(x, w) = 0l }. By considering above relation
and language, given a field F, a zk-SNARK for F-arithmetic circuit satisfiability is a triple of
polynomial-time algorithms (KGen, P, Vf), that are defined as below:

• Public Parameter Generation, (pk, vk) ← KGen(1n , C): Given a security parameter n
and an arithmetic circuit C, the CRS generator KGen samples a CRS which contains
proving and verification keys crs = (pk, vk) and publishes them. Now these keys, can be
used to give/verify a proof for a membership in LC .

• Proof Generation, π ← P(pk, x, w): Given a proving key pk and any (x, w) ∈ RC , the
algorithm P generates a succinct NIZK proof π for the statement x ∈ LC .

• Proof Verification, b ← Vf(vk, x, π): Given a verification key vk, an input x, and a proof
π, the algorithm Vf returns b = 1 if verification passed (x ∈ LC ), else returns 0.

Generally, a zk-SNARK should guarantee the following properties.

• Completeness: For any security parameter n, any F-arithmetic circuit C, and any (x, w) ∈
RC , the honest prover can convince honest verifier. Namely,
" #
(pk, vk) ← KGen(1n , C), (x, w) ← P(pk, vk),
Pr = 1 − negl(n) .
π ← P(pk, x, w) : Vf(vk, x, π) = 1

• Knowledge Soundness: If verifier Vf accepts a proof output by a computationally

bounded prover P, then the prover knows a witness for the given instance. More formally,
for every poly(n)-time adversarial P, there exists a poly(n)-time extractor Ext such that,
" #
(pk, vk) ← KGen(1n , C), (x, w) ← P(pk, vk), (x, π) ← A(pk, vk; r),
Pr = negl(n) .
w ← ExtA (pk, vk; r) : (x, w) 6∈ RC ∧ Vf(vk, x, π) = 1

• Perfect Zero-Knowledge: An honestly-generated proof is perfect zero knowledge, mean-

ing that the proof does not reveal any information about witness w. More formally, there
4
An F-arithmetic circuit is a circuit that performs arithmetic functions like Addition, Subtraction and Multipli-
cation on elements from field F.

25
 is a polynomial-time simulator Sim, such that for all distinguishers D, the following two
probabilities are equal:
" #
(pk, vk) ← KGen(1n , C), (x, w) ← D(pk, vk),
Pr
π ← P(pk, x, w) : (x, w) ∈ RC ∧ D(π) = 1

(the probability that D(π) = 1 on an honest proof) and

" #
(pk, vk, tr) ← Sim(1n , C), (x, w) ← D(pk, vk),
Pr
π ← Sim(x, tr) : (x, w) ∈ RC ∧ D(π) = 1

(the probability that D(π) = 1 on a simulated proof).

• Succinctness: An honestly-generated proof π has On (1) bits and Vf(vk, x, π) runs in time
On (| x |), where On hides a fixed polynomial factor in n.

Usually a common NIZK only satisfies, completeness, zero-knowledge and soundness;

soundness is a weaker notion than knowledge soundness. Below we define non-black-box
simulation knowledge soundness (a.k.a. simulation extractability) that is an amplified version
of knowledge soundness that guarantees non-malleability of proofs. Intuitively, simulation
extractability guarantees that knowledge soundness holds even if adversary has seen arbitrary
number of simulated proofs. This notion can be defined formally as bellow.

Definition 12 ((Non-Black-Box) Simulation Extractability [GM17] or Simulation-knowledge

soundness). A non-interactive argument Ψ is (non-black-box) simulation-extractable for R, if
for any NUPPT A, there exists a NUPPT extractor ExtA s.t. for all n,
" #
crs ← KGen(R, ξ), r ←r RND(A), ((x, π)||w) ← (AO(.) ||ExtA )(R, ξ, crs; r) :
Pr ≈n 0 ,
(x, π) 6∈ Q ∧ (x, w) 6∈ R ∧ V(R, ξ, crsV , x, π) = 1

where, Q is the set of (x, π)-pairs generated by the adversary’s queries to O(.) and O(.) generates
simulated proofs for arbitrary statements submitted by the adversary. Note that (non-black-box)
simulation extractability implies knowledge-soundness, as the earlier additionally allows the
adversary to send query to the proof simulation oracle. Note that in Def. 12 the extractor is
non-black-box and to be able to extract the witness, it should have access to the source code and
the random coins of A. Later in sec. 4, we present a variation of the stat-of-the-art zk-SNARK
that can achieve this notion.
While using a zk-SNARK in Zerocash, knowledge soundness and zero-knowledge play
essential role to achieve privacy and checking the validity of transactions. Later we will discuss
with more details that, Zerocash considers a circuit C for privacy-preserving transactions. The
circuit mostly verifies knowledge of SHA256 pre-image as a binding commitment. Knowledge
soundness implies that if a prover can give a valid proof for that circuit with a particular
statement, so she must know the witness (pre-image of SHA256) for the statement. The word
know is formalized by extracting the witness from the prover.
About the role of zero knowledge in Zerocash, it guarantees that the proof (attached to each
transaction) does not reveal any secret information about the spender, transferred values and
receiver, beyond the fact that x ∈ LC .

26
Remark. While proving security of Zerocash, authors deal with an extended version of
knowledge soundness for the case that a prover outputs a vector pairs of inputs and proofs,
(~x, ~π ). Consequently, they consider an extractor which extracts a vector w ~ . Strictly speaking, if
(KGen, P, Vf) is a zk-SNARK, then for any poly(n)-size adversary A, there exists a poly(n)-size
extractor Ext such that,
" #
(pk, vk) ← KGen(1n , C), (~x, ~π ) ← A(pk, vk), w~ ← Ext(pk, vk) :
Pr ≤ negl(n) .
∃ i s.t. Vf(vk, xi , πi ) = 1 ∧ (xi , wi ) 6∈ RC

From the beginning till April 2018, Zerocash was using a variation of Pinocchio zk-
SNARK [PHGR13] which is proposed by Ben Sasson et al.’s in [BCTV13]. Due to better
efficiency, from April 2018 they switched to use Groth’s zk-SNARK [Gro16] that is the state-of-
the-art by the date of writing the thesis. We review Groth’s zk-SNARK in next subsection.

2.7.2 Groth’s zk-SNARK

As recently Zerocash started to use Groth’s zk-SNARK, so this section reviews the construction
of the scheme which is proposed by Groth in [Gro16]. As Groth zk-SNARK is constructed for
Quadratic Arithmetic Programs (QAPs), so before going through the structure of the scheme we
recall the definition of QAPs.

Quadratic Arithmetic Program (QAP). Let Zp is a multiplicative group of integers modulo

p, where p is a prime number. The multiplicative group Z∗p uses only integers between 1 and
p − 1. A QAP instance Qp is specified by the so defined (Zp , m0 , {uj , vj , wj }m j=0 ). This instance
defines the following relation, where we assume that A0 = 1:
> >
 

 (x, w) : x = (A 1 , . . . , A m0 ) ∧ w = (A m 0 +1 , . . . , A m ) ∧ 

m m m
RQp = X X X
( Aj uj (X))( Aj vj (x)) ≡
 Aj wj (x) (mod `(x)) 
j=0 j=0 j=0

Alternatively, (x, w) ∈ R if there exists a (degree ≤ n − 2) polynomial h(x), s.t.

Xm Xm m
X
( Aj uj (x))( Aj vj (x)) − Aj wj (x) = h(x)`(x) .
j=0 j=0 j=0

Clearly, RQ = RQp , given that Qp is constructed from Q as above. We note that QAP language
has an efficient reduction from the circuit satisfiability language. As a result, an efficient zk-
SNARK constructed for a QAP, can be used as an efficient zk-SNARK for circuit satisfiability.
This is the key point that has led to use zk-SNARKs in verifying various computations, including
verifying the computations that are done in each Pour transaction of Zerocash.
Groth’s zk-SNARK is a pairing based scheme. In this thesis, in reviewing of the scheme, we
use additive notation together with the bracket notation, i.e., in group G2 , [a]2 = a [1]2 , where
[1]2 is a fixed generator of G2 . A bilinear group generator BGgen(1n ) returns (p, G1 , G2 , GT , ê,
[1]1 , [1]2 ), where p (a large prime) is the order of cyclic abelian groups G1 , G2 , and GT . Finally,
ê : G1 × G2 → GT is an efficient non-degenerate bilinear pairing, s.t. ê([a]1 , [b]2 ) = [ab]T .
Denote [a]1 • [b]2 = ê([a]1 , [b]2 ).

27
 On input a QAP instance Qp = (Zp , m0 , {uj , Vj , wj }m
j=0 ), its algorithms act as follows:

KGen(RQp , C): Generate tr = (χ, α, β, γ, δ) ←$ (Z∗p )5 and compute (pk, vk) such that,
uj (χ)β+Vj (χ)α+wj (χ) m
!
[α, β, δ, ( δ
)j=m0 +1 ]1 ,
pk ← ,
[(χi `(χ)/δ)n−2 m m
i=0 , (uj (χ), Vj (χ))j=0 ]1 , [β, δ, (Vj (χ))j=0 ]2
 
u (χ)β+Vj (χ)α+wj (χ) m0
vk ← [( j γ
)j=0 ]1 , [γ, δ]2 , [αβ]T .

Return (pk, vk).

P(RQp , pk, x = (A1 , · · · , Am0 ), w = (Am0 +1 , · · · , Am )): Act as follows,

1. Let a† (χ) ← m
P †
Pm
j=0 Aj uj (χ), b (χ) ← j=0 Aj Vj (χ),

2. Let c† (χ) ← m
P
j=0 Aj wj (χ),

3. Set h(χ) = n−2 i † † †

P
i=0 hi χ ← (a (χ)b (χ) − c (χ))/`(χ),
4. Set [h(χ)`(χ)/δ]1 ← n−2 i
P
i=0 hi [χ `(χ)/δ]1 ,
Pm
5. Set ra ←r Zp ; Set a ← j=0 Aj [uj (χ)]1 + [α]1 + ra [δ]1 ,
6. Set rb ←r Zp ; Set b ← m
P
j=0 Aj [Vj (χ)]2 + [β]2 + rb [δ]2 ,
Pm
7. Set c ← P rb a + ra ( j=0 Aj [Vj (χ)]1 + [β]1 )+
m
j=m0 +1 Aj [(uj (χ)β + Vj (χ)α + wj (χ))/δ]1 + [h(χ)`(χ)/δ]1 ,
8. Return π ← (a, b, c).
Vf(RQp , vk, x = (A1 , · · · , Am0 ), π = (a, b, c)): Check that
m0
X uj (χ)β + Vj (χ)α + wj (χ)
a • b = c • [δ]2 + ( Aj [ ]1 ) • [γ]2 + [αβ]T .
j=0
γ

Sim(RQp , pk, x = (A1 , · · · , Am0 ), tr): Pick a0 , b0 ← Z∗p , and compute π = (a, b, c)
such that
"
0 0
Pm0 #
a b − αβ − A
j=0 j (u j (χ)β + Vj (χ)α + w j (χ))
a ← [a0 ]1 , b ← [b0 ]2 , c ←
δ
1

Figure 2. The structure of Groth’s zk-SNARK [Gro16]

By considering the above preliminaries, Fig. 2 summarizes the construction of scheme which
gets a QAP instance and executes the algorithms (KGen, P, Vf), where KGen generates the
public parameters (a.k.a. CRS), P generates a proof for given statement, and Vf verifies if the
proof is valid. The figure also describes the simulation procedure (algorithm Sim) of the scheme
which is used in proof of zero-knowledge property.

28
3 Privacy in Digital Coins
The aim of this section is to first give a short overview on Bitcoin and its privacy concerns, and
then introduce some of privacy-preserving cryptocurrencies that are proposed to improve privacy
in Bitcoin.
We begin with describing construction of Bitcoin and some privacy flaws in the coin. Then,
we continue with introducing Monero [Noe15], Zerocoin [MGGR13] and Zerocash [BCG+ 14a]
that are some known privacy-preserving cryptocurrencies that are proposed to improve privacy
of in Bitcoin. Similar to original coin, all the mentioned coins are constructed based on PoW
consensus protocol and run on top of Bitcoin.

3.1 Bitcoin
Bitcoin was the first distributed peer-to-peer electronic cash system that can be used for online
direct payments. It uses various cryptographic primitives to enable secure and direct payments.
Roughly speaking, transactions are made by digitally signing the transferred value and the public
key of the target receiver, and a public distributed ledger records all transactions. This public
ledger is the key point in eliminating the need for a trusted third party (e.g. central banks). The
founder is unknown and Satoshi Nakamoto [Nak08] is a pseudonym.

3.1.1 Overview
As briefly mentioned before, Bitcoin operates in a distributed network with a large number
of nodes. To transfer coins, nodes of the network require to perform public transactions
between pseudonyms. A Bitcoin transaction sends coins by signing a hash of the public
key of the target receiver and the transferred value. The hash of the target receiver’s public
key is known as her address. In Bitcoin, this hash is displayed in a Base58 format, e.g.
3D2oetdNuZUqQHPJmcMDDHYoqkyNVsFk9r. In practice, each user has several addresses (public
keys) of digital signature scheme that are linked to electronic online wallets. An individual node
of the network, can perform the transactions between one address that has enough money to
the target address or addresses (public keys). To show that a particular user is the legitimate
owner of the source address, and to validate the transaction, the particular user should sign the
transaction with her secret key, such that other nodes in the network can verify the signature
with her public key. There is a particular type of nodes that are called miners, which verify
all transactions and construct new blocks to append to the ledger. Once a miner received a
transaction and successfully verified it, they add the transaction to the upcoming block that they
(miner or group of miners) will make and add to the ledger (blockchain). Once a miner is elected
to make the next block (by a PoW lottery), she verifies the transaction and putd it to a new block
and announces to the Bitcoin network to be confirmed by other nodes and users. Other nodes and
miners, receive new blocks and append to the their local ledgers if their verification successfully
passed. For each transaction, the payer needs to pay a transaction fee which corresponds to the
cost of a transaction that should be paid to the miners. Additionally, to incentive the miners, the
network adaptively gives rewards to the miners that construct the new block. Currently mining
has a reward, so miners get reward and transaction fee, but later since the number of coins would
be constant, so the reward for miners will be provided by transaction fees. Finally, the ledger is
a chain of blocks where each block is connected to previous block with a cryptographic hash

29
 Block 2000 Block 2001 Block … Block 3001
Proof of work: Proof of work: Proof of work:
0000009857vvv 0000009718e3 0000002018dec
Previous block: Previous block: Previous block:
000000432qrza1 0000009857vvv … 0000001238e6
A → B 3B G → H 4B F → M 1B
C → D 9B D → M 5B U → T 3B
E → F 2B N → P 5B M → B 3B
… … …

Figure 3. A graphical representation of Bitcoin’s ledger

function, except the genesis block. A graphical representation is shown in Fig. 3.

We note that since the network is distributed, there would be cases that local copies of ledgers
of nodes are different from each other. This issue is addressed with Nakamoto’s consensus
protocol that is reviewed in section 2.5. At the end of each transaction, the output is the amount
of coins which is sent to a Bitcoin address (wallet) that is named “unspent transaction output”
(UTXO). It is worth to mention that sum of UTXOs for a particular address, gives us the balance
of that address (the unspent ones).

3.1.2 Construction
In summary, each block of Bitcoin’s ledger contains the following information,

• hpb: Hash of the previous block in ledger, which is sort of a reference to the previous
block (intuitively sticks blocks to each other)

• A list of transactions

• hcb: Hash of current block

• A solution to a PoW (described in section 2.5) puzzle consists of a value called nonce, s.t.
H(hpbkhcbknonce) ≤ tv, where H is a cryptographic hash function and tv is a 256-bit
target value announced to all the miners in the network.

Assuming that the output of cryptographic hash function H is indistinguishable from a

random value, there is no way to solve above puzzle better than trying all possible input values
for the given nonce, until finding a proper input value which would be the answer for the given
puzzle. The difficulty of finding such an answer for the PoW puzzle depends on value of tv
which specifies the number of zeros at the beginning of the 256-bit value (e.g. find a tv value
that has 5 zeros at its left bits, e.g. tv = 2251 − 1).
We note that as the number of zeros increases the set of possible answers decreases and as a
result the problem gets more difficult. Indeed this is one of parameters of the Bitcoin network
to control the level of difficulty in PoW puzzle. With current setting in Bitcoin (at the time of
writing the thesis), the value of tv updates every 2016 blocks which increases the difficulty of
the PoW puzzle. Changing this parameter allows to have constant block generation time on
average. With current setting, in Bitcoin a new block is constructed roughly every 10 minutes.

30
3.1.3 Security and Privacy Concerns
Since Bitcoin’s consensus protocol works based on PoW, so security of Bitcoin and its ledger
relies on the assumption that majority of computational power in the network is under the
control of honest miners. Attacks such as double spending are prevented if honest miners have
more than half of total computation power in the network. Security of Bitcoin is formalized
and studied in several works including [GKL15, PSS17, BMTZ17, GKL17]. In one research
done in [BGM+ 18], it is shown that a miner who aims to maximize her rewards (a.k.a. rational
miner), should behave honestly, as this case gives the maximum benefit for her. Due to nature of
Bitcoin network which is distributed, DoS attacks are applicable by publishing a huge number
of transactions, but this attack is mitigated due to transaction fees.
From privacy point of view, as briefly discussed in Sec. 1, different research have shown that
transactions on Bitcoin are linkable [RH11]. Strictly speaking, graph analysis of Bitcoin’s ledger
has shown that, although transactions are between pseudonyms, if a user uses a fixed address
for long time, one can easily link their transactions to each other. So, once a monitored address
(pseudonym) is linked to an identity (a person), the sources and destinations of their coins, as
well as the balance of their wallet, is laid bare. This is a serious loss of privacy, with potentially
catastrophic real-world consequences. For instance, suppose Alice has her salary paid in Bitcoin.
Later, Alice sends Bob, a coworker, some Bitcoin to pay for coffee. Bob now knows Alice’s
Bitcoin address. If Bob runs a Bitcoin node, he necessarily knows the total spendable balance
of Alice’s wallet. In addition, he can see all incoming transactions to Alice’s wallet, and their
amounts. From this he can surmise the amount of Alice’s salary.
To address the discussed security and privacy concerns, several solution have been pro-
posed that use various cryptographic techniques to provide secure and privacy-preserving
payments [MGGR13, BCG+ 14a, Noe15, FMMO18]. In the rest of section, we present a short
overview of the Monero [Noe15], Zerocoin [MGGR13] and Zerocash [BCG+ 14a] that are
three prominent alternatives. We will observe that, actually Zerocash is an improved version
of Zerocoin. Beside the privacy preserving coins that we briefly explain in this thesis there
exists more privacy preserving coins namely, Dash 5 , PIVXS 6 , NavCoin 7 , CloakCoin 8 and
DeepOnion 9 .

3.2 Monero
Monero [Noe15] is a privacy-preserving cryptocurrency that works based on PoW and aims
to provide anonymous payments by hiding the source and destination of a transaction along
with the value of transferred coins. Although, some research has shown that Monero is not
successful in hiding the source and value of transactions, and one can learn information about
them; more detailed discussions can be found in [KFTS17, MSH+ 18] but in the rest we provide
a brief overview on the coin [KCA+ 18].
In order to hide the source and destination of transactions, Monero’s protocol uses one-
time keys and a ring signature [RST01]. They extended their protocol to hide the value of
transactions in 2017. To this end, Monero moved to use Ring Confidential Transaction (Ring
5
Available at https://www.dash.org
6
Available at https://pivx.org
7
Available at https://cryptorating.eu
8
Available at https://www.cloakcoin.com
9
Available at https://deeponion.org

31
CT) protocol [Noe15]. Hiding source, destination, and values of transactions is something that
Bitcoin does not support.

3.2.1 MLSAG Signature

The main tools in Ring CT protocol is Multi Layered Linkable Spontaneous Anonymous Group
(MLSAG) signature. Intuitively, a ring signature allows an individual user from a big group to
sign a message in an anonymous way, such that no polynomial time adversary can distinguish
which member of that group has signed the message. They deploy MLSAG signature, but we
note that it still is a ring signature. MLSAG has some extra properties in comparison to the
common ring signatures, which make them useful for cryptocurrencies. As one of the prominent
properties is that MLSAG is linkable which allows to determine whether two signatures are
created with identical secret key. As we mentioned before Monero beside hiding origion and
destination of transactions, to hide the value of transactions uses Ring CT protocol which
provides some extra properties on top of a ring signature and consequently MLSAG signature.

3.2.2 Ring Confidential Transaction

This subsection aims to summarize description of a transaction in the Ring CT protocol of
Monero. First of all, the receiver generates a new one-time public key for MLSAG (each key
is used just once). Inputs and outputs of a transaction are given as a Pedersen commitments
which is explained in sec. 2.1.1. As the Pedersern commitment has additive homomorphic
property, it allows third parties to verify that transaction is done correctly. For instance, let
Com(sk1 , m1 ) be the input of a transaction, and Com(sk2 , m2 ), Com(sk3 , m3 ) are the outputs of
the transaction; therefore anyone can verify that Com(sk2 , m2 ) · Com(sk3 , m3 ) = Com(sk1 , m1 )
if m1 = m2 + m3 and sk1 = sk2 + sk3 . The sender of transaction opens the committed values
only to the recipients of the transaction. Such that, only the receiver can verify the correctness of
received amount. All above arithmetic are done in modulo p, the sender also gives some range
proofs proving that commitments are in range{0, 1, · · · , k} where k  p.
At the end, the sender selects a randomly chosen subset of unspent public keys of various
users along with her own public key and creates a MLSAG signature of the transaction with
those keys. In practice the Ring CT protocol is a bit more complicated thanm our high level
explanation, but in general the intuition behind the protocol is described here.

3.2.3 Privacy of Ring CT.

As we already mentioned, Ring CT protocol aims to provide an anonymous payments by hiding
source, destination and value of each transaction. In the rest, we informally argue how the
protocol archives its goals.

Hiding the Receiver. By considering the fact that public keys of an individual user are
independent of other users, so it is computationally difficult to link various transactions to the
same individual account.

Hiding the Sender. Due to nature of Ring signature, that hides an individual signer in a group
of users, an attacker would not be able to say which of the public keys was used to create the

32
signature; as a result the sender is hidden among the number of members in the group and we
can not distinguish which one of them is the sender (e.g. 1 out of 16)

Hiding the Amount. As Ring CT uses Pedersen commitment, and this commitment scheme
is perfectly hiding, so the amount of transactions are private.

Double Spending. Regard to the double spending attack, in order to do this attack, a malicious
sender would need to sign two messages with the same secret key, that due to linkability of
MLSAG, it would be detected. Overflow attacks are avoided by Range proofs. e.g. if input of
a particular transaction is m1 = 1 and it outputs m2 = 2 and m3 = −1, then it still holds that
m2 + m3 = m1 . But we know that amount of coins cannot be negative, and it does not make
sense; on the other hand as arithmetic in Pedersen commitment is done modulo p which is a
large prime, then −1 can be considered as p − 1 that is a huge value. As a result, such an attack
would allow to illegally make new currency with huge value. Recall that, range proofs show that
each input and output are bounded by some value k, which mitigates this attack.

3.3 Zerocoin
As briefly mentioned before, Zerocash is a refined version of Zerocoin that provides more
security and flexibility. Here we present a short overview on Zerocoin which can help to have
better understanding of Zerocash in the rest of thesis.
Zerocoin is a concrete decentralized e-cash scheme that was proposed by Miers et al. in
2013 [MGGR13]. They have shown that their system is secure assuming the hardness of the
Strong RSA10 and Discrete Logarithm assumptions, and the existence of a zero-knowledge proof
system. Roughly speaking, Zerocoin extends Bitcoin by creating two new transaction types:
mint and spend. A mint transaction allows a user to exchange a quantity of bitcoins for the right
to mint a new zerocoin. Each coin of Zerocoin consists of a commitment value cm to a random
serial number sn. At a later point, a (potentially different) user may issue a spend transaction
containing a destination identity, the serial number sn, and a non-interactive zero-knowledge
proof for the N P statement "I know secret cm and r such that (i) cm can be opened to sn with
commitment randomness r, and (ii) cm was previously minted at some point in the past". Since
the proof is zero-knowledge, so it does not link the spend transaction to any particular mint
transaction in the list of all minted transactions. Due to soundness property of the proof, if the
proof verifies correctly and the serial number has not been spent previously (has not appeared in
the list of revealed serial numbers), the protocol semantics transfer a corresponding amount of
bitcoins to the destination address.
Precisely speaking about committed values, Zerocoin uses Pedersen commitments over
a prime field Fp , i.e., cm := g sn hr , for random generators g, h of a subgroup of F∗p . About
the corresponding zero-knowledge proofs, they are constructed by first accumulating (via the
Strong-RSA accumulator of [CL02]) the set of commitments of all minted zerocoins, and then
proving knowledge of Q the corresponding commitment randomness and membership in this set
(to give a proof that i (Ci − cmt ) = 0, where cmt denotes the target commitment and C is the
10
The assumptions states that given a modulus N of unknown factorization, and a ciphertext C, it is infeasible to
find any pair (M, e) such that C ≡ M e mod N .

33
set of committed values). In practice, the size of proofs in Zerocoin exceeds 45 kB at the 128-bit
security level, and require about 0.5 seconds to verify the proof [BCG+ 14a].
It is worth to mention that in Zerocoin, computing the witness for the accumulator requires
access to the entire set of commitments so far (though the witness can be incrementally updated
for each insertion). This technique supports an unlimited number of coins, but later we will
discuss that Zerocash supports a limited number of coins (precisely 264 coins).

3.3.1 Construction
Formally speaking, Zerocoin consists of four algorithms Πzerocoin = (Setup, Mint, Spend, Vf)
that can be expressed as below,

Setup, pp ← Setup(1n ): Given a security parameter n as an input, algorithm Setup outputs the
public parameters pp that are required for the system (including public parameter for the
deployed proof system).

Mint, (cm, skcm ) ← Mint(pp): Given public parameters pp as inputs, algorithm Mint returns
(cm, skcm ), where cm is the Pedersen commitment of coin and skcm is the secret informa-
tion of coin.

Spend, (π, sn) ← Spend(pp, cm, skcm , C): Given public parameters pp, a commitment cm, the
corresponding secret information cmsk and the set of commitments C, the algorithm Spend
checks if cm 6∈ C outputs ⊥. Otherwise, returns (π, sn) where π is a zero-knowledge
proof to attest that prover knows secret information of the spend coin, and the coin is not
spend before (serial number sn is not published before).

Verify, 0/1 ← Vf(pp, π, sn, C): Given inputs such as a proof π, a serial number sn, and a set
of coins C, the algorithm Vf verifies the validity of proof π, it returns 1 if proof verifies
successfully and returns 0 if the proof verification fails.

It is worth to mention that, since Zerocoin uses non-interactive zero-knowledge proofs, they
need a trusted third party to generate public parameters honestly. Actually later we will observe
that Zerocash also needs a similar trusted setup phase.

3.3.2 Security
The security of Zerocoin [MGGR13] depends on two theorems which we will briefly mention
below.

Theorem 1. Using the property computationally zero-knowledge in the random oracle model
of the zero-knowledge signature of knowledge they guarantee anonymity of Zerocoin scheme
Π = (Setup, Mint, Spend, Vf).
Intuitively, in order to provide anonymity for users in Zerocoin, the signature proof π should
at least be computationally zero-knowledge and the commitment cm has to be perfectly hiding.
These two requirements give the opportunity to spend a coin anonymously because the adversary
can only guess which coin is being spent.

34
 Block 2000 Block 2001 Block … Block 3001
Proof of work: Proof of work: Proof of work:
0000009857vvv 0000009718e3 0000002018dec
Previous block: Previous block: Previous block:
000000432qrza1 0000009857vvv … 0000001238e6
? → ? ?€ ? → ? ?€ ? → ? ?€
? → ? ?€ ? → ? ?€ ? → ? ?€
? → ? ?€ ? → ? ?€ ? → ? ?€
… … …

Figure 4. A graphical representation of ledger in privacy-preserving coins (e.g. Zcash)

Theorem 2. Using the property of soundness in the random oracle model of the signature
proof π, the hardness of Strong RSA problem and the hardness of Discrete Logarithm problem
in G, they guarantee Balance property of Zerocoin scheme Π = (Setup, Mint, Spend, Vf).
Intuitively, In order to provide Balance property for users in Zerocoin, there is need to have
the perfect binding coin commitment, the sound and unforgeable zero-knowledge signature of
knowledge and the collision resistant accumulator. The advantage of adversary to win Balance
game is negligible otherwise the adversary would be able to find a collision for commitment
scheme which would lead to solving of the Discrete Logarithm problem or find a collision
resistant for accumulator which would lead to solving the Strong RSA problem.

3.4 Zerocash
Now we move on to Zerocash [BCG+ 14a] which is a construction based on Zerocoin and Sander
and Ta-Shma’s scheme [ST99], by some feature extensions. In a short comparison with current
Bitocoin network, Zerocash is more scalable and can handle larger number of transactions per
seconds; as each block is generated in ≈ 2.5 minutes (instead of ≈ 10 minutes in the Bitcoin)
and block capacity is 2.5MB (compared to 1MB for Bitcoin). More importantly, Zerocash allows
complete anonymous transactions by hiding source, destination and value of each transaction.
But, Zerocoin does not hide the value of a transaction and other meta data. Zerocoin uses coins
of fixed denomination and does not allow users to do payments of exact values and users need
to use a support coin such as Bitcoin, but these issues are solved in Zerocash. As Zerocash
completely hides the source, the destination and the amount of transactions, so its ledger has a
structure as in Fig. 4 that in comparison with ledger of Bitcoin in Fig. 3, it reveals minimum
information about the transactions.

3.4.1 Construction
This section aims to present a step-by-step review of the construction of Zerocash. The design
of Zerocash, was later developed to a full-fledged cryptocurrency which is known as Zcash
these days. As we briefly mentioned in Sec. 2.6, Zerocash is a construction of DAP scheme
with a particular instantiation [BCG+ 14a]. In the rest, with recalling that a DAP scheme
ΠDAP consists of a tuple of polynomial time algorithms ΠDAP = (Setup, CreateAddress, Mint,
Pour, VerifyTransaction, Receive), we discuss how the algorithms are constructed in Zerocash.
We already have introduced all the primitives including collision-resistant hash functions,

35
commitments schemes, (one-time strongly-unforgeable) signature schemes, (key-private) public-
key encryption schemes, and zk-SNARKs that are deployed in the construction of the scheme.
Later we will talk about precise instantiation of these primitives in the construction of Zerocash.

Algorithms of the DAP Scheme in Zerocash. The DAP scheme ΠZcash consists of the
algorithms (Setup, CreateAddress, Mint, Pour, VerifyTransaction, Receive) defined as follows.
Setup Algorithm. The Setup algorithm generates public parameter needed in other algorithms
(including CRS of the zk-SNARK) which is executed only once by a trusted third party or
distributed authority. It returns public parameter pp which is shared with all nodes. Public
parameter pp contains encryption public parameter ppEnc , signature public parameter ppSig and
a tuple (pkPour , vkPour ), as the public parameter of the zk-SNARK, which will be used in the
following algorithms. Roughly speaking, the algorithm generates public parameters ppEnc and
ppSig for key generation of the encryption and the signature schemes, respectively; and the keys
(pkPour , vkPour ) which will be used in Pour algorithm to generate and verify the proofs. The
algorithm Setup is described in Alg. 1.
Algorithm 1: Setup
Input: security parameter (n)
Result: public parameters pp
1 Construct arithmetic circuit CPour for Pour transaction at security n.
2 Compute (pkPour , vkPour ) := KGenNIZK (1n , CPour ).
3 Compute ppEnc := KGenEnc (1n ).
4 Compute ppSig := KGenSig (1n ).
5 Set pp := (pkPour , vkPour , ppEnc , ppSig ).
6 Output pp.

CreateAddress Algorithm. Given the public parameters pp, the algorithm generates a tuple
of addresses (addrpk , addrsk ). To do so, it parses pp := (pkPour , vkPour , ppEnc , ppSig ) and then
using parameters ppEnc and algorithms KGenEnc , it generates a pair of public and secret keys
(pkEnc , skEnc ). Next, it samples a PRF with a seed ask and uses it to generate apk . Finally this
algorithm returns addrpk which consists of apk and pkEnc and addrsk which consists of ask and
skEnc . The algorithm CreateAddress is shown in Alg. 2.
Algorithm 2: CreateAddress
Input: public parameters pp
Result: address key pair (addrpk , addrsk )
1 Compute (pkEnc , skEnc ) := KGenEnc (ppEnc ).
2 Randomly sample a PRFaddr with a randomly selected seed ask .
3 Compute apk = PRFaddr ask (0).
4 Set addrpk := (apk , pkEnc ).
5 Set addrsk := (ask , skEnc ).
6 Output (addrpk , addrsk ).

Mint Algorithm. This algorithm is used to create a new coin with a value V. It produces a coin
c and a mint transaction TranMint to record the coin c in the ledger. More precisely, the Mint

36
algorithm gets public parameters, the desired coin value (which is bounded by Vmax initialized
in the protocol) and address public key addrpk for the user that wants to mind a coin. In order to
generate the serial number of the new coin, user picks a ρ randomly as a seed and runs a pseudo
random function on her secret address ask . On the other hand, to get commitment of the new
coin user needs to pick to randomnesses r and s and first produce k as k := Comr (apk ||ρ) and
finally produce coin commitment as cm := Coms (V||k). The produced new coin c includes
public address key of user, coin value V, the secrets ρ, r, s and the coin commitment cm which
will be placed in the commitments’ merkle tree. The other product of this algorithm is mint
transaction TranMint which consists of (cm, V, ∗), where cm is the coin commitment, V is a value
of the new coin and ∗ is r and s. The procedure of algorithm is described in Alg. 3.

Algorithm 3: Mint
Input: public parameters pp, coin value v ∈ [0, . . . , Vmax ], receiver’s addrpk
Result: coin c and mint transaction TranMint
1 Parse addrpk as (apk , pkEnc ).
2 Randomly sample a PRFsn seed ρ.
3 Randomly sample two Com trapdoors r, s.
4 Compute k := Comr (apk k ρ).
5 Compute cm := Coms (V k k).
6 Set c := (addrpk , V, ρ, r, s, cm).
7 Set TranMint := (cm, V, ∗), where ∗ := (k, s).
8 Output c and TranMint

Pour Algorithm. This is the most important algorithm in the DAP scheme and consequently
Zerocash, which is used to spend old coins and produce new coins and also pay the transaction
fee. Technically speaking it takes two old coins cold old
1 and c2 and produces two new coins c1
new
new new new
and c2 for the public address keys addrpk,1 and addrpk,2 , respectively and it can be generalized
to the case which takes n old coins as an input and outputs m new coins. It also outputs some
public value which can be spent as the transaction fee. This algorithm allows to merge coins,
subdivide coins into smaller denominations and also do public payments. To check the validity
of spent coins, the algorithm takes the root of the Merkle tree over all the coin commitments
verifies the authentication paths Path1 and Path2 which should go to two spent coins. The
algorithm also takes values V1new V2new as values of two new anonymous coins cnew 1 and cnew
2 with
new new
the corresponding address public keys addrpk,1 and addrpk,2 . The other input of Pour algorithm
is the value Vpub that shows the amount which is publicly spent, for instance for transaction
fees. The summation of the new coins’ value plus the Vpub must be exactly equal to the the
summation of the old coins’ value. The last input of Pour algorithm is an arbitrary string info
which is bound into the output pour transaction TranPour . The output of algorithm consists two
new coins cnew1 and cnew
2 and a pour transaction TranPour . The transaction TranPour contains the
root rt, two old coins’ serial numbers snold old
1 and sn2 , two commitments’ of new coins cm1
new
and
new
cm2 , the public value Vpub , a arbitrary string info and ∗, where ∗ is some extra information
related to the implementation.
Intuitively, this algorithm aims to spend old coins and create new coins and produce a pour
transaction TranPour which will be published in the ledger. This algorithm using zk-SNARK
generates a proof for a special statement which is important to provide anonymity and in order

37
to avoid the man-in-the-middle attack of the proof it uses a one time strong secure signature.
The procedure of algorithm Mint is described in Alg. 4.

Algorithm 4: Pour
Input: public parameters pp, the Merkle root rt, old coins cold old
1 and c2 , old address
secret keys addrold old old
sk,1 and addrsk,2 , path Path1 from commitment cm(c2 ) to the
root rt and path Path2 from commitment cm(cold new
1 ) to the root rt, new values V1
new new new
and V2 , new addresses public keys addrpk,1 and addrpk,2 , public value Vpub ,
transaction string info
Result: new coins cnew
1 , c2
new
and pour transaction TranPour
1 foreach i ∈ {0, 1} do
old
2 Parse cold old old old
i as (addrpk,i , Vi , ρi ,i , si , cmi );
old old
old
3 Parse cold old old old
i as (addrpk,i , Vi , ρi ,i , si , cmi );
old old

4 Parse addrold old old

sk,i as (ask,i , skEnc,i );
sn
5 Compute snoldi := PRFask ,i (ρi );
old

6 Parse addrnew new new

pk,i as (apk,i , pkEnc,i );
7 Randomly sample a PRFsn seed ρnew i ;
8 Randomly sample two Com trapdoors rinew , snew i ;
9 Compute kinew := Comrnew i
(a new
pk,i k ρ new
i );
10 Compute cmnew i := Com new
si (V new
i k kinew );
11 Set cnew
i := (addrnew new new new
pk,i , Vi , ρi ,i , snew new
i , cmi );
12 Set Ci := Enc(pknew new new new
Enc , (Vi , ρi ,i , snew
i ))

13 Generate (pkSig , skSig ) := KGenSig (ppSig ).

14 Compute hSig := CRH(pkSig ).
15 Compute h1 := PRFpk aold
(hSig ) and h2 := PRFpk
aold
(hSig ).
sk,1 sk,2

16 Set ~x := (rt, snold old new new

1 , sn2 , cm1 , cm2 , Vpub , hSig , (h1 , h2 )).
old old
17 Set ~a := (Path1 , Path2 , cold old new new
1 , c2 , addrsk,1 , addrsk,2 , c1 , c2 ).
18 Compute πPour := P(pkPour , ~x, ~a).
19 Set m := (~x, πPour , info, (C1 , C2 )).
20 Compute σ := Sign(skSig , m).
21 Set TranPour := (rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , info, ∗), where
∗ := pkSig , (h1 , h2 ), πPour , (C1 , C2 ), σ).
22 Output cnew
1 , c2
new
and TranPour

VerifyTransaction Algorithm. To check if a transaction is valid and well-formed, nodes of

the network need to execute the algorithm VerifyTransaction. For instance, to check a mint
transaction, it takes TranMint which contains (cm, V, ∗) where ∗ is randomnesses k and s and
sets cm0 := Coms (V||k). Then it returns b = 1 if cm0 = cm otherwise returns b = 0.
To check the validity of pour transaction, this algorithm needs to check validity of proof and
validity of signature. It takes TranPour which contains rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , info, ∗
where ∗ is pkSig , (h1 , h2 ), πPour , (C1 , C2 ), σ and checks some steps. First checks if the old
serial numbers already appeared in the spent serial number list or snold 1 = snold
2 , if so then
returns b = 0 otherwise returns 1. Next checks if this rt root appears on the ledger, if

38
yes returns b = 1, otherwise outputs b = 0. In the next step computes hSig which was
used in the signing process in the Pour algorithm. After that sets the statement as x :=
rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , hSig , (h1 , h2 ) and message as m := x, πPour , info, (C1 , C2 ).
Finally first runs signature’s verifier and sets b as b := Vf Sig (pkSig , m, σ). Then running proof
verifier
V on the proof computes b0 as b0 := VerifyTransaction(crsv , x, πPour ). At the end returns
b b’. If the result is 1 means that both proof and signature are valid otherwise means at least
one of them is not valid.
Intuitively, this algorithm has two parts, one is checking validity of mint transaction TranMint
produced by Mint algorithm and the second part checks if the TranPour generated by Pour
algorithm (which means checking both proof and signature) is valid or not. The procedure of
this algorithm is described in Alg. 5.

Algorithm 5: VerifyTransaction
Input: public parameters pp, a (mint or pour) transaction Tran, the current ledger L
Result: bit b, equal 1 iff the transaction is valid
1 if given a mint transaction Tran = TranMint then
2 Parse TranMint as (cm, V, ∗), and ∗ as (k, s);
3 Set cm0 := Coms (V k k);
sn
4 Compute snold old
i := PRFask ,i (ρi );
5 Output b := 1 if cm = cm0 , else output b := 0
6 if given a pour transaction Tran = TranPour then
7 Parse TranPour as (rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , info, ∗), where
∗ := pkSig , (h1 , h2 ), πPour , (C1 , C2 ), σ);
8 If snold old old old
1 , sn2 appears on L or (sn1 = sn2 ), output b := 0;
9 If the Merkle root rt does not appear on L, output b := 0;
10 Compute hSig := CRH(pkSig );
11 Set ~x := (rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , hSig , (h1 , h2 ));
12 Set m := (~x, πPour , info, (C1 , C2 ));
13 Compute b := Vf Sig (pkSig , m, σ);
14 Compute b0 := Vf(vkPour , ~x, πPour ), and output b ∧ b0

Receive Algorithm. This is the algorithm that when a node with address key pair (addrpk , addrsk )
wishes to receive payments sent to the addrpk , needs to execute to scan the ledger of Zerocash.
The algorithms returns the corresponding coins that their serial number have not published on
the SNList. In summary, this algorithm scans the ledger and returns all the unspent coins for a
special address key. The procedure of the algorithm is described in Alg. 6.
A key point about the DAP scheme in Zerocash is that it uses Succinct Non-interactive
Arguments of Knowledge (zk-SNARKs) [BCG+ 14a, Lip12, BCI+ 13, ABLZ17a] under some
cryptographic assumptions. For all the ledger based digital currency such as Bitcoin one can
use their proposed DAP scheme. Currently Zerocash uses the most efficient zk-SNARK that is
proposed by Groth in [Gro16].

39
 Algorithm 6: Receive
Input: public parameters pp, recipient’s (addrpk , addrsk ), the current ledger L
Result: set of received coins
1 Parse addrpk as (apk , pkEnc ).
2 Parse addrsk as (ask , skEnc ).
3 foreach Pour transaction TranPour on the ledger do
4 Parse TranPour as (rt, snold old new new
1 , sn2 , cm1 , cm2 , Vpub , info, ∗), where
∗ := pkSig , (h1 , h2 ), πPour , (C1 , C2 ), σ);
5 foreach i ∈ {1, 2} do
6 Compute (Vi , ρi , ri , si ) := DecEnc (skEnc , Ci );
7 if DecEnc ’s output is not ⊥ then
8 verify that, cmnew i equals Comsi (Vi k Comri (apk k ρi ));
9 verify that, sni := PRFsn ask (ρi ) does not appear on L;

10 if If both checks succeed then

11 output ci := (addrpk , Vi , ρi , ri , si , Comnew
i )

3.4.2 Instantiation
As we already mentioned, the coin Zerocash is an instantiation of the described DAP scheme
for particular security parameter. As one can see in the algorithms mentioned above, there are
collision resistant hash functions CRH, pseudo random functions PRF and commitment schemes
Com that Zerocash instantiate all of them with hash function SHA-256 which takes 512 bits
as an input and outputs 256 bits. Taking precisely 512-bit inputs in hash function is useful in
construction of the Merkle tree.

Pseudo Random Function Instantiation. The pseudo random functions are instantiated as
PRFaddr sn pk
x (z) := H(x||00||z), PRFx (z) := H(x||01||z) and PRFx (z) := H(x||10||z).

Commitment Schemes Instantiation. Zerocash instantiates the commitment schemes as fol-

lows: first instantiate commitment for producing k as k := Comr (apk ||ρ) = H(r||[H(apk ||ρ)]128 ).
Above, [·]128 denotes that we are truncating the 256-bit string to 128 bits (say, by dropping least
significant bits, as in their implementation) Then, using k they instantiate coin commitment as
cm := Coms (V||k) = H(k||0192 ||v).

NP Statement Instantiation. Zerocash instantiate the NP statement Pour algorithm such that
it checks the following holds, for each i ∈ {1, 2}:

• Pathi is an authentication path for leaf cmold

i with respect to root rt, in a CRH-based
Merkle tree;

• aold old
pk,i = H(ask,i ||0
256
);

• snold old old

i = H(ask,i ||01||[ρi ]254 );

40
 • cmold old old old
i = H(H(ri ||[H(apk,i ||ρi )]128 )||0
192
||Viold );

• cmnew
i = H(H(rinew |[[H(anew new
pk,i ||ρi )]128 )||0
192
||Vinew ) and

• hi = H(aold
sk,i ||10||bi ||[hSig ]253 ) where b1 := 0 and b2 := 1.

Beside the checking which are mentioned above Pour algorithm needs to check V1new + V2new +
Vpub = V1old + V2old , with V1old , V2old ≥ 0 and V1old + V2old < 264. Zerocash in order to build circuit
for Pour algorithm fixed a Merkle-tree depth dtree with 64 which this depth supports up to 264
that is enough for Zerocash currency.

Signature Scheme Instantiation. Zerocash instantiate signature scheme with ECDSA signa-
ture scheme [Kob98].

Encryption Function Instantiation. For instantiating encryption function they use the key-
private Elliptic-Curve Integrated Encryption Scheme (ECIES) [Cer00].

3.4.3 Security
As we already talked about the security requirements of a DAP scheme in Sec. 2.6.3, since
Zerocash is an instantiation of a DAP scheme, it should guarantee the required security. Security
proofs for Zerocash are explained with more details in the full version of the paper and we refer
reader to the paper [BCG+ 14a].

An issue with definition of Completeness. While we have been studying the structure and
security proofs of Zerocash, we noticed that the definition of completeness has some issues
and it does not cover all requirements of users in real life. Precisely speaking, we observed a
flaw on the construction of zerocash which allows a malicious spender to make the spent coins
unspendable to the recipient, while the network will accept the transactions and the Receive
algorithm will not detect the issue in the recipient side. Then we got aware that the attack is
correct, but 2 years ago Zooko Wilcox had reported the flaw and the issue is solved in current
version of Zcash protocol and is described with more details in recent update of the protocol
specification, but it still exists in the full version of paper.
In summary, the flaw stems from the construction of new coins in Pour algorithm. More
accurately, in constructing the new coins, the sender picks the serial number randomnesses ρ1 ,
ρ2 and sends them securely to the recipients; and later when recipients want to spend the new
coins, they will use the randomnesses along with their secret keys to generate the serial numbers
of new coins. It is easy to show that generating the randomnesses of new serial numbers by
spender, allows a malicious spender to act in a way that some of legitimate coins in recipients
side would be unspendable.

3.4.4 Efficiency
Setup algorithm in their construction includes constructing CPour and CRS generation for CPour .
They instantiate PRFs and Commitment schemes with SHA256 (except a Hash function in
signing). They constructed an arithmetic circuit CSHA256 for verifying SHA256’s function from

41
 Table 1. Number of gates needed in for checks in CPour
Gate count for circuit CPour
Ensure cmold
1 is in Merkle tree 1, 802, 304
(1 layer out of 64) 28, 161
Ensure cmold
2 is in Merkle tree 1, 802, 304
(1 layer out of 64) 28, 161
Check computation of snold 1 , sn2
old
2 × 27, 904
Check computation of aold old
pk,1 , apk,2 2 × 27, 904
Check computation of cmold old new
1 , cm2 , cm1 , cm2
new
4 × 83, 712
Check computation of (h1 , h2 ) 2 × 27, 904
Ensure that V1new + V2new + Vpub = V1old + V2old 1
Ensure that V1old + V2old < 264 65
Miscellaneous 2, 384
Total 4, 109, 330

Table 2. Performance of crs generator

Setup (crs generation) 5 min 11 sec, crsp : 896 MB, crsV : 750 B
Prover 1 min 59 sec, 288 B
verify < 6 ms

scratch (∼ 28.000 gates). Then they construct a large arithmetic circuit CPour that can verify all
checks in the Pour transaction (excepts the one-time signature) with 4, 100, 000 gates.
Running Setup (CRS generation) takes 5 minutes 11 second but it only needs to be run
once and the size of keys needed for proof generation is 896 MB and the size of keys for proof
verification is 750 B. Prover takes 1 min 59 sec, to generate a proof π with size 288 B and
verifier takes less than 6 ms to verify the proof. Reported experiments are done on a desktop
machine with an Intel Core i7-4770 @3.40GHz and 16GB of RAM. Tab. 1 summarizes the
number of gates needed in individual checks in circuit CPour . One can see that totally the circuit
has around 4.100.000 gates and the big part is required to check the validity of spent coins in a
Merkele tree that each coin requires around 1.800.000 gates. Based on implementation reports
in [BCG+ 14b], performance of CRS generation for zk-SNARK and other algorithms of Zcash
are summarized in Tab. 2 and Tab. 3 11 .

Table 3. Perfornace of all algorithms

Setup (crs generation) 5 min 12 sec, 896 MB params
Create Address 326 ms/add , 650 B
Mint a coin 23 η s, 72 B transaction
Pour (2-to-2) 1 min 59 sec, 1 KB transaction
Verify Transaction < 9 ms transaction
Receive < 2 ms transaction

11
We reported all implementation results based on the experiments reported in full version of Zerocahs paper
available in [BCG+ 14b]. It is worth to mention that initial version of Zerocash, was using initial version of
Pinocchio zk-SNARKs proposed by Ben-Sasson et al. [BCG+ 14a], but recently they optimized the system and
decreased the number of gates in CPour and also started to use Groth’s zk-SNARK [Gro16].

42
4 An Efficient Simulation Extractable zk-SNARK
Up to this section we considered Bitcoin and some privacy preserving coins including Zcash
that uses zk-SNARKs to generate proof in pour transactions. Due to very efficient verification
and succinct proofs of zk-SNARKs, recently they have appeared in various privacy-preserving
applications including privacy-preserving smart contract systems such as Hawk [KMS+ 16] and
Gyges [JKS16]. As we discussed in the introduction, majority of known zk-SNARKs [PHGR13,
BCTV13, Gro16] are designed to guarantee completeness, zero-knowledge and (non-black-box)
knowledge soundness that are defined in Sec. 2.7.1.
Currently the most efficient pairing-based zk-SNARK was proposed by Groth in Eurocrypt
2016 [Gro16]. Groth’s zk-SNARK is constructed for Quadratic Arithmetic Programs (QAPs)
and works over bilinear groups. While using zk-SNARKs in practical systems, their knowledge
soundness property is not enough to guarantee non-malleability of proofs. For instance, in
verification of some zk-SNARKs (e.g. Groth’s zk-SNARK [Gro16]) the verifier checks a pairing
equation as A • B = · · · , where A and B are proof elements from G1 and G2 with prime
orders. One can see that such verification equation will be satisfied also for new proof elements
1
such as A0 = Ar and B 0 = B r , for arbitrary r ∈ Zp . Due to this fact, zk-SNARKs that only
guarantee knowledge-soundness cannot be deployed in many of practical applications straightfor-
wardly [BCG+ 14a, KMS+ 16, JKS16, Bag19]. For instance, privacy-preserving crypocurrencies
such as Zerocash that uses zk-SNARKs [BCTV13, Gro16] as a subroutine, takes extra steps to
prevent malleability attacks in the SNARK proofs for pour transactions [BCG+ 14a]. Similarly,
privacy-preserving smart contract systems [KMS+ 16, JKS16] show that knowledge-soundness
of zk-SNARKs is not enough for their systems. Technically speaking, their system requires
zk-SNARKs that satisfies Universal Composability [Can01] which is stronger security guar-
antee than knowledge-soundness achieved in majority of zk-SNARKs. Simulation-knowledge
soundness which also is known as simulation extractability (defined in Def. 12), is an amplified
version of knowledge-soundness that guarantees non-malleability of proofs.
As mentioned before, Groth’s zk-SNARK [Gro16] is the most efficient pairing-based zk-
SNARK in the CRS model, but it does not guarantee non-malleability of proofs. In Crypto 2017
Groth and Maller [GM17] have proposed the first SE zk-SNARK that is constructed for Square
Arithmetic Programs (SAPs) and guarantees non-malleability of proofs. They also proved that
a SE zk-SNARK requires at least two verification equations. Their scheme is constructed in
the bilinear groups for Square Arithmetic Programs (SAPs) and achieves the lower bound in
the number of verification equations that results smaller number of pairings. To verify a proof,
the verifier needs to check two equations that contain with 5 pairings [GM17]. To guarantee
non-malleability in proofs, their scheme removes one of the bilinear group generators from the
CRS, which can create new challenges in some practical cases (e.g. in CRS generation by multi-
party computation protocols [BCG+ 15, ABL+ 19] , or in achieving subversion security [BFS16,
ABLZ17b, Fuc18]). Above all, Groth and Maller’s zk-SNARK is constructed for arithmetic
circuits with squaring gates that requires larger number of gates, as each multiplication gate
requires two squaring gates (a×b = ((a+b)2 −(a−b)2 )/4). Implementations have confirmed that
for many practical circuits Groth’s zk-SNARK [Gro16] (described in Sec. 2) has considerably
better efficiency than Groth and Maller’s zk-SNARK [GM17]. Based on the currently available
implementations in Libsnark library12 , for a Rank-1 Constraint System (R1CS) 13 instance,
12
Available on https://github.com/scipr-lab/libsnark/tree/master/libsnark/zk_proof_systems
13
The R1CS is the following natural NP-complete problem: given a vector v ∈ Fk and three matrices A, B, C ∈

43
efficiency metrics of both schemes are compared in Tab. 4. For two mentioned zk-SNARK,
we executed already written codes in Libsnark library on a Laptop with 2.50 GHz Intel Core
i5-7200U CPU, with 16GB RAM, in single-threaded mode.

Table 4. Empirical performance of zk-SNARKs proposed by Groth and Maller [GM17],

Groth [Gro16] and this thesis for arithmetic circuit satisfiability with an R1CS instance with
106 constraints and 106 variables, where 10 are input variables. SE: Simulation Extractable, KS:
Knowledge Soundness.
SNARK CRS size, time Proof size, P time Verification, V time Security
[GM17] 376 MB, 103 s 2G1 + 1G2 , 120 s 5 pairings, 2.3 ms SE
[Gro16] 196 MB, 75 s 2G1 + 1G2 , 83 s 3 pairings, 1.4 ms KS
New scheme 205 MB, 80.5 s 3G1 + 2G2 + 1BS, 90 s 4 pairings, 2.0 ms SE
By considering efficiency comparisons in Tab. 4, we observe that Groth’s zk-SNARK
has better efficiency but only achieves knowledge-soundness, and Groth and Maller’s zk-
SNARK [GM17] ensures simulation extractability but with less efficiency. So an interesting
research question can be raised whether we can achieve simulation extractability in Groth’s
scheme efficiently such that the new scheme will 1) work for QAPs 2) have both generators
of bilinear groups in the CRS 3) have a comparable or even better efficiency than Groth and
Maller’s zk-SNARK.
A variation of Groth’s zk-SNARK. In this thesis we address the questions discussed above
and propose a variation of Groth’s zk-SNARK that can achieve simulation extractability with
minimal efficiency loss in practical cases.
To this end, we use the known OR technique and define a new language L0 based on the
language L in Groth’s zk-SNARK that is inspired by the works of De Santis et al. [DDO+ 01]
and Kosba et al. [KZM+ 15].
Defining a new language based on original language results some changes in algorithms of
the original scheme. Evaluations show that in practical cases, new changes have minimal affects
on the efficiency of original scheme which currently is the state-of-the-art. Strictly speaking, the
verification of new scheme has two equations as the optimal case, and only adds 1 pairing to the
verification of Groth’s scheme. As a result, for smaller number of public inputs, verification of
new scheme is dominated with 4 pairings which is less than 5 pairings in Groth and Maller’s
SE zk-SNARK [GM17]. Empirical analysis shows that, for the considered instance in Tab. 4,
verification of new scheme takes 2.0 milliseconds. In the proposed variation, the proof size will
be extended by one element from G1 , one element from G2 plus a 256-bit string, that totally
will be 3 elements from G1 , 2 elements from G2 and one 256-bit string, which for 128-bit
security still it is less than 256 bytes. The prover should give a proof for a new circuit that
has around 50 × 103 gates more than before, where in practical scenarios the overload is very
small. I.e. Zerocash uses zk-SNARKs to give a proof for a circuit with approximately 2 × 106
multiplication gates14 . In comparison with P running times in Tab. 4, prover of new scheme
requires 90 sec to generate a proof; particularly with smaller CRS in comparison with Groth
and Maller’s [GM17] scheme (with 205 MB, instead of 376 MB). Efficiency of the proposed
variation is summarized in Tab. 4.
Fm×n , can one augment v to zFn such that Az ◦ Bz = Cz? (We use "◦" to denote the entry-wise product.)
14
Their initial circuit had ≈ 4 × 106 gates, but recently they optimized the system and reduced the number of
gates to ≈ 2 × 106 , but still it is very larger than ≈ 50 × 103 .

44
Discussion and Related Works. Among different NIZK arguments, zk-SNARKs are the most
practically-interesting ones; because of their succinct proofs and very efficient verifications.
But as majority of them guarantee knowledge-soundness by default, that is vulnerable to the
man-in-the-middle attacks, so they cannot be deployed directly in practical systems. Actually,
in constructing large cryptographic systems, this issue can cause misuse from non-expert
users. To address this, recently constructing efficient SE zk-SNARKs, that by default can
guarantee non-malleability of proofs, has gotten more attention [GM17, BG18b, KLO19, Lip19].
In [BG18b], Bowe and Ariel also proposed a variation of Groth’s scheme that achieves simulation
extractability but in the Random Oracle (RO) model. In their variation, the proof consists of 3
elements from G1 and 2 elements from G2 , and verification is dominated by 5 pairings. A good
point about their case is that they keep the language as original one, and add some computation
to the proof generation and verification with relying on a random oracle that returns group
elements 15 . Implementing such random oracle might cause some challenges in practice. But as
Groth’s zk-SNARK is constructed and proven in the CRS model, so we are interested to achieve
simulation extractability in the same model using more practical cryptographic primitives.

4.1 A Variation of Groth’s zk-SNARK

As briefly discussed in the introduction, Groth’s zk-SNARK [Gro16] guarantees knowledge-
soundness which is weaker than simulation extractability. Technically speaking, knowledge-
sound proofs are not secure against man-in-the-middle attacks. In this section, we present a
variation of Groth’s zk-SNARK which can achieve (non-black-box) simulation extractabilitythat
can guarantee non-malleability of the proofs.

4.1.1 New Construction

In construction of new variation, we define a new language L0 , using an OR technique [DDO+ 01,
KZM+ 15], which combines original language L in Groth’s zk-SNARK with a commitment
scheme which commits to a secret randomness as a key for a pseudorandom function. Let
(KGen, Sign, Vf) be a one-time signature scheme and (Com, ComVerify) be a perfectly binding
commitment scheme.
Given the language L with the corresponding NP relation RL , we define a new language L0
such that ((x, µ, pkSign , ρ), (w, s, r)) ∈ RL0 iff:


(x, w) ∈ RL ∨ (µ = fs (pkSign ) ∧ ρ = Com(s, r)) ,

where {fs : {0, 1}∗ → {0, 1}n }s∈{0,1}n is a pseudo-random function family. The intuition for a
pseudo-random function fs (·) is that without the knowledge of the key s, fs (·) behaves like a
true random function. However, given s, one can compute fs (·) easily. In new language L0 , for
a statement-witness pair to be valid, either a witness for RL is provided (by honest prover) or an
opening to ρ together with the value of µ = fs (pkSign ) is provided (by simulator), where s is the
open value of ρ (in CRS). One may note that in order for a statement to pass the verification
without a valid witness, the prover must generate fs (pkSign ) without the knowledge of s (thus
breaking the pseudo-random function fs ).
15
Intuitively, some part of their changes play the role of a one-time secure signature scheme, but add two pairings
to the verification of original scheme.

45
 By considering new language L0 , zk-SNARK of Groth for the relation R constructed
from PPT algorithms (KGen, P, V, Sim) can be lifted to a simulation-extractable zk-SNARK
Ψ0 with PPT algorithms (KGen0 , P0 , V0 , Sim0 ) as described in Fig. 5. To simplify the descrip-
tion, we assume Com takes exactly n random bits as randomness and that the witness for
original language L is exactly n bits; it is straight forward to adapt the proof when they are
of different lengths [KZM+ 15]. Note that in the simulation-extractable zk-SNARK Ψ0 , the
algorithms of original scheme will be executed for a new arithmetic circuit which encodes
new language L0 and has slightly larger number of gates. Namely, CRS generation algorithm
of Groth’s zk-SNARK will be executed with a new QAP instance that has larger parameters;
(crs||tr) ← KGen(RL0 , ξ). Similarly prover of new variation will execute prover of Groth’s
zk-SNARK with a new arithmetic circuit that has larger number of gates; namely π ← P(RL0 , ξ,
crs, (x, z0 , pkSign , ρ), (w, z1 , z2 )), where z1 and z2 play the role of witnesses s and r for prover.

CRS generator KGen0 (RL , ξ): Sample (crs||tr) ← KGen(RL0 , ξ); s, r ←u {0, 1}n ; ρ :=
Com(s, r); and output (crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, r))); where tr0 is new simulation
trapdoor and ξ is the auxiliary information returned by relation generator BGgen(1n ),
and is given as an input to the honest parties.
Prover P0 (RL , ξ, crs0 , x, w): Parse crs0 := (crs, ρ); abort if (x, w) ∈ / RL ; generate
n n
(pkSign , skSign ) ← KGen(1 ); sample z0 , z1 , z2 ←u {0, 1} ; generate π ← P(RL0 , ξ,
crs, (x, z0 , pkSign , ρ), (w, z1 , z2 )) using the prover of Groth’s scheme; sign σ ←
Sign(skSign , (x, z0 , π)); and return π 0 := (z0 , π, pkSign , σ).
Verifier V0 (RL , ξ, crs0 , x, π 0 ): Parse crs0 := (crs, ρ) and π 0 := (z0 , π, pkSign , σ); abort
if Vf(pkSign , (x, z0 , π), σ) = 0; call the verifier of Groth’s scheme V(RL0 , ξ, crs,
(x, z0 , pkSign , ρ), π) and abort if it outputs 0.
Simulator Sim0 (RL , ξ, crs0 , tr0 , x): Parse crs0 := (crs, ρ) and tr0 := (tr, (s, r)); gener-
ate (pkSign , skSign ) ← KGen(1n ); set µ = fs (pkSign ); generate π ← Sim(RL0 ,
ξ, crs, (x, µ, pkSign , ρ), (tr||(s, r))); sign σ ← Sign(skSign , (x, µ, π)); and output π 0 :=
(µ, π, pkSign , σ).

Figure 5. A variation of Groth’s zk-SNARK.

4.1.2 Security Proofs

In the rest we present security proofs of the proposed scheme.

Theorem 1 (Completeness). The variation of Groth’s zk-SNARK described in Sec. 4.1.1, guar-
antees completeness.

Proof. In new scheme internal computations of P and V are the same as original one, except few
extra efficient computations. Precisely, P needs to do the computation for a new instance that has
slightly larger size (e.g. n = nold + nnew , where nnew is the number of multiplication gates added
to the old circuit) and sign the proof and statement whit a one-time secure signature scheme.
So following the completeness of original scheme, and the fact that the deployed signature
scheme is complete, which means Vf(pkSign , m, Sign(m, skSign )) = 1, one can conclude that the
modified construction satisfies completeness.

46
Theorem 2 (Zero-Knowledge). The variation of Groth’s zk-SNARK described in Sec. 4.1.1,
guarantees computational zero-knowledge.

Proof. We write a series of hybrid experiments which start from an experiment with the simulator
and ends with an experiment that uses the real prover. We show that all experiments consecutively
are indistinguishable. Changes between successive experiments are shown with highlights.
Recall that Groth’s zk-SNARK guarantees perfect zero-knowledge and the simulator of the
modified scheme is expressed in Fig. 5. Now consider the following experiments,
G1 (simulator):
• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s, r ←u {0, 1}n ; ρ := Com(s, r); and output
(crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, r))); where tr0 is simulation trapdoor.

• Define function O(x, w): Abort if (x, w) 6∈ RL ; (pkSign , skSign ) ← KGen(1n ); set µ =
fs (pkSign ); generate π ← Sim(RL0 , ξ, crs, (x, µ, pkSign , ρ), tr0 ); sign σ ← Sign(skSign , (x, µ,
π)); return π 0 := (µ, π, pkSign , σ).

• b ← AO(x,w) (crs0 )

G2 (separate secret key of pseudo random function):

• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s0 , s, r ←u {0, 1}n ; ρ := Com(s0 , r); and out-
put (crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, s0 , r))); where tr0 is simulation trapdoor.

• Define function O(x, w): Abort if (x, w) 6∈ RL ; generate (pkSign , skSign ) ← KGen(1n );
set µ = fs (pkSign ); generate π ← Sim(RL0 , ξ, crs, (x, µ, pkSign , ρ), (tr||(s, r))); sign σ ←
Sign(skSign , (x, µ, π)); return π 0 := (µ, π, pkSign , σ).

• b ← AO(x,w) (crs0 )

Lemma 1. If the underlying commitment scheme is computationally hiding, then for two
experiments G2 and G1 we have Pr[G2 ] ≈ Pr[G1 ].
Proof. Computationally hiding property of a commitment scheme implies that Com(m1 , r) is
computationally indistinguishable from Com(m2 , r). So this property straightforwardly results
the lemma.
G3 (replace pseudo random function):

• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s0 , /s , r ←u {0, 1}n ; ρ := Com(s0 , r); and
output (crs0 ||tr0 ) := ((crs, ρ)||(tr, (/s , s0 , r))); where tr0 is simulation trapdoor.

• Define function O(x, w): Abort if (x, w) 6∈ RL ; (pkSign , skSign ) ← KGen(1n ); set
µ ←u {0, 1}n ; generate π ← Sim(RL0 , ξ, crs, (x, µ, pkSign , ρ), (tr||(s0 , r))); sign σ ←
Sign(skSign , (x, µ, π)); return π 0 := (µ, π, pkSign , σ).

• b ← AO(x,w) (crs0 )

Lemma 2. If the pseudo random function fs (·) is secure and the underlying one-time signature
scheme is unforgeable,we have Pr[G3 ] ≈ Pr[G2 ].

47
Proof. By considering that the signature scheme is secure, we note that the generated pkSign is
unique with overwhelming probability, otherwise it would break the one-time signature scheme.
Additionally, we can replace the pseudo random function fs (·) with a true random function that
will result G4 . By considering unique values of pkSign and indistinguishability of output of fs (·)
and truly random function, one can conclude the claim.
G4 (prover):
• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s0 , r ←u {0, 1}n ; ρ := Com(s0 , r); and output
(crs0 ||tr0 ) := ((crs, ρ)||(tr, (s0 , r))); where tr0 is simulation trapdoor.

• Define function O(x, w): Abort if (x, w) 6∈ RL ; (pkSign , skSign ) ← KGen(1n ); set µ ←u
{0, 1}n (µ plays the role of z0 in Fig. 5); sample z1 , z2 ←u {0, 1}n ; generate
π ← P(RL0 , ξ, crs, (x, µ, pkSign , ρ), (w, z1 , z2 )); sign σ ← Sign(skSign , (x, µ, π)); return
π 0 := (µ, π, pkSign , σ).

• b ← AO(x,w) (crs0 )
Lemma 3. If Groth’s zk-SNARK guarantees zero-knowledge, then we have Pr[G4 ] ≈ Pr[G3 ].
Proof. The last experiment exactly models the real prover of construction in Fig. 5, and as
already Groth’s scheme guarantees zero-knowledge, so one can conclude that the real proof
(generated by prover) in experiment G4 is indistinguishable from the simulated proof (generated
by simulator) in G3 . Intuitively this is because all new elements added to the new construction
are chosen randomly and independently.
This results that the construction proposed in Fig. 5, guarantees computationally zero-
knowledge.
Theorem 3 ((Non-Black-Box) Simulation Extractability). The variation of Groth’s zk-SNARK,
described in Sec. 4.1.1, guarantees (non-black-box) simulation extractability.
Proof. Similarly, we write a sequence of hybrid experiments and finally show that the success
probability in the last game is negligible. Recall that Groth’s scheme is proven to achieve
knowledge-soundness. For any NUPPT A and extractor ExtA , consider the following game
which models the definition of simulation-extractability,
G1 (main experiment):
• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s, r ←u {0, 1}n ; ρ := Com(s, r); and output
(crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, r))); where tr0 is simulation trapdoor.

• Define function O(x):

(pkSign , skSign ) ← KGen(1n ); set µ = fs (pkSign ); generate π ← P(RL0 , ξ, crs, (x, µ, pkSign , ρ),
(w, (s, r))); sign σ ← Sign(skSign , (x, µ, π)); return π 0 := (µ, π, pkSign , σ).

• (x, π 0 ) ← AO(x) (crs0 ).

• Parse π 0 := (µ, π, pkSign , σ); w ← ExtA (crs0 , x, π, ξ).

• Return 1 iff ((x, π 0 ) 6∈ Q) ∧ (V0 (RL , ξ, crs0 , x, π 0 ) = 1) ∧ ((x, w) 6∈ RL ); where Q shows

the set of statement-proof pairs generated by O(x).

48
G2 (relaxing the return checking):

• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s, r ←u {0, 1}n ; ρ := Com(s, r); and output
(crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, r))); where tr0 is simulation trapdoor.

• Define function O(x): (pkSign , skSign ) ← KGen(1n ); set µ = fs (pkSign ); generate π ←

P(RL0 , ξ, crs, (x, µ, pkSign , ρ), (w, (s, r))); sign σ ← Sign(skSign , (x, µ, π)); return π 0 :=
(µ, π, pkSign , σ).

• (x, π 0 ) ← AO(x) (crs0 ).

• Parse π 0 := (µ, π, pkSign , σ); w ← ExtA (crs0 , x, π, ξ).

• Return 1 iff ((x, π 0 ) 6∈ Q)∧ (V0 (RL , ξ, crs0 , x, π 0 ) = 1)∧(pkSign 6∈ PK) ∧ (µ = fs (pkSign ));
where Q is the set of statement-proof pairs and PK is the set of signature verification keys,
both generated by O(x).

Lemma 4. If the underlying one-time signature scheme is strongly unforgeable, and Groth’s
scheme guarantees knowledge-soundness, then Pr[G2 ] ≤ Pr[G1 ] + negl(n).
Proof. We note that if (x, π 0 ) 6∈ Q and "pkSign from (x, π 0 ), has been generated by O(·)", then the
(x, µ, π) is a valid message/signature pairs. Therefore by unforgeability of the signature scheme,
we know that (x, π) 6∈ Q and "pkSign has been generated by O(·)" happens with negligible
probability, which allows us to focus on pkSign 6∈ pk.
Now, due to knowledge-soundness (there is an extractor ExtA that can extract unique witness
from successful A) of the original scheme, the extracted w is unique for all valid witnesses.
Further, if some witness is valid for L0 and (x, w) 6∈ RL , so we conclude it must be the case
that there exists some s0 , such that ρ is valid commitment of s0 and µ = fs0 (pkSign ), which by
perfectly binding property of the commitment scheme, it implies µ = fs (pkSign ).
G3 (simulator):

• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s, r ←u {0, 1}n ; ρ := Com(s, r); and output
(crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, r))); where tr0 is simulation trapdoor.

• Define function O(x): (pkSign , skSign ) ← KGen(1n ); set µ = fs (pkSign ); generate

π ← Sim(RL0 , ξ, crs, (x, µ, pkSign , ρ), (tr||(s, r))); sign σ ← Sign(skSign , (x, µ, π)); re-
turn π 0 := (µ, π, pkSign , σ).

• (x, π 0 ) ← AO(x) (crs0 ).

• Parse π 0 := (µ, π, pkSign , σ); w ← ExtA (crs0 , x, π, ξ).

• Return 1 iff ((x, π 0 ) 6∈ Q)∧ (V0 (RL , ξ, crs0 , x, π 0 ) = 1)∧(pkSign 6∈ pk)∧(µ = fs (pkSign ));
where Q is the set of statment-proof pairs and pk is the set of signature verification keys,
both generated by O(x).

Lemma 5. If Groth’s zk-SNARK guarantees zero-knowledge, then for two experiments G3 and
G2 , we have Pr[G3 ] ≤ Pr[G2 ] + negl(n).

49
Proof. As the original scheme ensures (perfect) zero-knowledge, so it implies no polynomial
time adversary can distinguish a proof generated by the simulator from a proof that is gen-
erated by the prover. So, as we are running in polynomial time, thus two experiments are
indistinguishable.
G4 (separating secret key of pseudo random function):

• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s0 , s, r ←u {0, 1}n ; ρ := Com(s0 , r); and out-
put (crs0 ||tr0 ) := ((crs, ρ)||(tr, (s, s0 , r))); where tr0 is simulation trapdoor.

• Define function O(x): (pkSign , skSign ) ← KGen(1n ); set µ = fs (pkSign ); generate π ←

Sim(RL0 , ξ, crs, (x, µ, pkSign , ρ), (tr||(s, r))); sign σ ← Sign(skSign , (x, µ, π)); return π 0 :=
(µ, π, pkSign , σ).

• (x, π 0 ) ← AO(x) (crs0 ).

• Parse π 0 := (µ, π, pkSign , σ); w ← ExtA (crs0 , x, π, ξ).

• Return 1 iff ((x, π 0 ) 6∈ Q)∧ (V0 (RL , ξ, crs0 , x, π 0 ) = 1)∧(pkSign 6∈ pk)∧(µ = fs (pkSign ));
where Q is the set of statment-proof pairs and pk is the set of signature verification keys,
both generated by O(x).

Lemma 6. If the commitment scheme used in the CRS generation is computationally hiding,
then Pr[G4 ] ≤ Pr[G3 ] + negl(n).
Proof. Computationally hiding of a commitment scheme implies that Com(m1 , r) and Com(m2 , r)
are computationally indistinguishable, as in this lemma.
G5 (replace pseudo random function fs (·) with true random function F (·)):

• Setup: Sample (crs||tr) ← KGen(RL0 , ξ); s0 , s/ , r ←u {0, 1}n ; ρ := Com(s0 , r); and
output (crs0 ||tr0 ) := ((crs, ρ)||(tr, (s/ , s0 , r))); where tr0 is simulation trapdoor.

• Define function O(x): (pkSign , skSign ) ← KGen(1n ); set µ = F (pkSign ); generate π ←

Sim(RL0 , ξ, crs, (x, µ, pkSign , ρ), (tr||(s, r))); sign σ ← Sign(skSign , (x, µ, π)); return π 0 :=
(µ, π, pkSign , σ).

• (x, π 0 ) ← AO(x) (crs0 ).

• Parse π 0 := (µ, π, pkSign , σ); w ← ExtA (crs0 , x, π, ξ).

• Return 1 iff ((x, π 0 ) 6∈ Q)∧ (V0 (RL , ξ, crs0 , x, π 0 ) = 1)∧(pkSign 6∈ pk)∧ (µ = F (pkSign ));
where Q is the set of statment-proof pairs and pk is the set of signature verification keys,
both generated by O(x).

Lemma 7. If the underlying truly random function F (·) is secure, then Pr[G4 ] ≤ Pr[G5 ].
Proof. By assuming function F (·) is secure, we can conclude no polynomial time adversary
can distinguish an output of the true random function F (·) from an output of the pseudo random
function fs (·). Indeed, experiment G5 can be converted to an adversary for the game of a true
random function.

50
 For experiment G5 , we have Pr[G5 ] ≤ 2−n .
Proof. From verification we know pkSign 6∈ pk, therefore F (pkSign ) has not been queried already.
Thus, we will see F (pkSign ) as a newly generated random string independent from µ, which
implies adversary only can guess.
This completes proof of the main theorem.

4.2 Instantiation and Efficiency Evaluation

As we observed in Sec. 4.1.1, defining the new language L0 led to some changes in the algorithms
of original scheme. In this section, we discuss how efficient can be such changes (described in
Fig. 5). We first discuss how the used primitives can be instantiated and then evaluate efficiency
of the whole protocol.
Recall that in result of new changes, one needed a pseudo random function, a commitment
scheme and a one-time secure signature scheme. In similar practical cases, both pseudo random
function and commitment scheme are instantiated using an efficient SHA-256 circuit that has
around ≈ 25 × 103 multiplication gates for one block (512-bit input) [BCG+ 14a, KMS+ 16]16 .
We instantiate the signature scheme with Boneh and Boyen’s signature [BB08] where its setup
phase, signing and verification for message m can be summarized as follows,
• Setup: Given system parameters for a prime-order bilinear group (p, G1 , G2 , GT , ê,
[1]1 , [1]2 ), randomly selects sk ←u Z∗p , and computes sk · [1]1 and returns (pk, sk) :=
([sk]1 , sk).

• Signing: Given system parameters, a secret key sk, and a message m, computes [σ]2 =
[1/(m + sk)]2 and returns [σ]2 as the signature.

• Verification: Given a public key pk, a message m, and a signature σ, verifies if [m + sk]1 •
[1/(m + sk)]2 = [1]T ,
where • denotes the pairing operation. In our case, we use the same bilinear group as in the
main scheme and m would be the hash17 (e.g. with SHA-256) of concatenations of the proof
elements with the statement, i.e. m := H(x||z0 ||π). As it can be seen, the scheme generates
a single-element signature from G2 , its public key is an element from G1 , and above all its
verification only requires one pairing. Note that [1]T can be preprocessed and shared in the CRS.
So by considering the above instantiation, new proof π 0 = (µ, π, pkSign , σ) will be as
π 0 = (µ, π, [sk]1 , [1/(m + sk)]2 ) where from original scheme π = ([a]1 , [b]2 , [c]1 ), and µ
is an output of the pseudo random function fs (·), which is instantiated with SHA-256 hash
function [KMS+ 16]. As a result, the proof in new scheme will be 3 elements from G1 , 2
elements from G2 and one 256-bit string. Consequently, new changes add only one pairing to
the verification of original scheme. To the best of our knowledge, this is the first simulation-
extractable zk-SNARK in the CRS model with verification dominated by 4 pairings.
Next, we empirically analyse efficiency of the proposed scheme from different perspec-
tives. Tab. 5 summarizes asymptotic and empirical performance of new scheme and two
16
It has 25.538 gates in the xjsnark library, https://github.com/akosba/xjsnark.
17
As shown in [BB08], by taking hash of input message the signature scheme can be used to sign arbitrary
messages in {0, 1}∗ . To do so, a collision resistant hash function H : {0, 1}∗ → {0, . . . , 2b } such that 2b < p is
sufficient [BB08].

51
Table 5. An efficiency comparison of new scheme with Groth’s [Gro16] and Groth and
Maller’s [GM17] zk-SNARKs for arithmetic circuit satisfiability with m0 elements instance, m
wires, n multiplication gates. In [GM17], n multiplication gates translate to 2n squaring gates.
Implementations (Implem.) are done on a Laptop with 2.50 GHz Intel Core i5-7200U CPU,
with 16GB RAM, in single-threaded mode, for an R1CS instance with n = 106 constraints
and m = 106 variables, of which m0 = 10 are input variables. G1 and G2 : group elements, E:
exponentiations, P : pairings. In the new scheme, the statement contains (x, µ, pkSign , ρ) which
has 3 new elements (µ, pkSign , ρ), so m00 = m0 + 3. All asymptotic analysis of new scheme
are done based on our particular instantiation of commitment and pseudo random function.
So, as new changes add ≈ 50 × 103 multiplication gates to n and m, so n0 = n + 50.000 and
m0 = m + 50.000.

SNARK CRS size & gen. time Proof size Comp. & time of P V Sec.
[GM17] m + 4n + 5 G1 2 G1 m + 4n − m0 E1 m0 E1
& 2n + 3 G2 1 G2 2n E2 5P SE
Implem. 376 MB, 103 sec 127 bytes 120 sec 2.3 ms
[Gro16] m + 2n − m0 G1 2 G1 m + 3n − m0 + 3 E1 m0 E1
& n + 3 G2 1 G2 n + 1 E2 3P KS
Implem. 196 MB, 75 sec 127 bytes 83 sec 1.4 ms
Sec. 4 m + 2n0 − m00 + 5 G1
0
3G1 + 2G2 m + 3n0 − m00 + 4 E1
0
m00 + 1 E1
& n0 + 3 G2 1 bit string n0 + 2 E2 4P SE
Implem. 205 MB, 80.5 sec 254 bytes 90.1 sec 2.0 ms

zk-SNARKs proposed by Groth’s [Gro16] and Groth and Maller’s [GM17]. Implementations
of Groth’s [Gro16] and Groth and Maller’s [GM17] zk-SNARKs are available in libsnark
library [BCTV13] 18 , so similarly implementation of new scheme is done in the same library. In
Tab. 5, all implementation results are reported for the same R1CS instance.

18
Available on https://github.com/scipr-lab/libsnark

52
5 Conclusion
Beside very nice features that blockchain technology and its by-products, such as digital
currencies, provide, guaranteeing strong privacy and security of end-users always has been one
of main priorities for society and researchers of the area.
In the first part of the thesis, after a short summary of some cryptocurrencies such as Bitcoin,
Monero and Zerocoin, we reviewed Zerocash [BCG+ 14a] with details which is one of the most
well-known cryptocurrencies that is proposed to guarantee users’ privacy. Zerocash does not
reveal any information about user identities, source or destination addresses, and the account
of transferred or spent coins. To have a comprehensive review on Zerocash, we first had
an overview of the building blocks of the coin, including PRFs, commitment schemes, hash
functions, one-time signature schemes, public-key encryption schemes, and zk-SNARKs. Then
we discussed step-by-step the construction of the coin along with the main intuitions behind
each step. We observe that the main tool behind indistinguishability properties of the coin is a
zk-SNARK that allows a user (a prover) to give very short (succinct) proofs in pour transactions
and more importantly these proofs can be verified by a low-power verifier very efficiently (in
less than a second).
In the second part of the thesis, due to the importance of zk-SNARKs in various privacy-
preserving applications, we focused on construction of an efficient simulation-extractable zk-
SNARK. More precisely, we presented a new variation of Groth’s 2016 zk-SNARK [Gro16] that
currently is the most efficient pairing-based scheme. The main difference between the proposed
variation and the original one is that unlike the original version, new variation guarantees non-
malleability of generated proofs. In the new variation, we used an efficient OR construction to
define a new language L0 from the language L in the original scheme, that led to some changes in
the algorithms of original scheme. Analysis and implementation results showed that in practical
scenarios, new changes have minimal effect on the efficiency of original scheme which currently
is the most efficient pairing-based zk-SNARK in the CRS model [Gro16]. Precisely speaking,
evaluations showed that for arithmetic circuits with larger than ≈ 50 × 103 multiplication
gates, the proposed SE zk-SNARK outperforms Groth and Maller’s simulation-extractable
zk-SNARK [GM17]. We emphasize that in current real-life systems that use zk-SNARKs, their
underlying arithmetic circuits have much larger number of gates than 50 × 103 . For instance,
in Zerocash cryptocurrency [BCG+ 14a] their current circuit for pour transactions has 2 × 106
multiplication gates; or similarly in Hawk smart contract system [KMS+ 16], their circuit for
finalize operation in an auction with 50 bidders has around 4 × 106 multiplication gates. In
comparison with Groth and Maller’s SE zk-SNARK [GM17], however proof of new scheme is
extended slightly, but still its total size is less than 256 bytes for 128-bit security; and importantly
its verification is dominated by smaller number of pairings that allows very efficient verification.

53
References
[AB19] Shahla Atapoor and Karim Baghery. Simulation extractability in Groth’s zk-
SNARK. Cryptology ePrint Archive, Report 2019/641, 2019. http://eprint.
iacr.org/2019/641.
[ABL+ 19] Behzad Abdolmaleki, Karim Baghery, Helger Lipmaa, Janno Siim, and Michal
Zajac. UC-secure CRS generation for SNARKs. In Johannes Buchmann, Ab-
derrahmane Nitaj, and Tajje eddine Rachidi, editors, AFRICACRYPT 19, volume
11627 of LNCS, pages 99–117. Springer, Heidelberg, July 2019.
[ABLZ17a] Behzad Abdolmaleki, Karim Baghery, Helger Lipmaa, and Michal Zajac. A
subversion-resistant SNARK. In Advances in Cryptology - ASIACRYPT 2017 -
23rd International Conference on the Theory and Applications of Cryptology and
Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part
III, pages 3–33, 2017.
[ABLZ17b] Behzad Abdolmaleki, Karim Baghery, Helger Lipmaa, and Michal Zajac. A
subversion-resistant SNARK. In Tsuyoshi Takagi and Thomas Peyrin, editors, ASI-
ACRYPT 2017, Part III, volume 10626 of LNCS, pages 3–33. Springer, Heidelberg,
December 2017.
[Bag19] Karim Baghery. On the efficiency of privacy-preserving smart contract systems.
In Johannes Buchmann, Abderrahmane Nitaj, and Tajje eddine Rachidi, editors,
AFRICACRYPT 19, volume 11627 of LNCS, pages 118–136. Springer, Heidelberg,
July 2019.
[BB08] Dan Boneh and Xavier Boyen. Short signatures without random oracles and the
SDH assumption in bilinear groups. J. Cryptology, 21(2):149–177, 2008.
[BBDP01] Mihir Bellare, Alexandra Boldyreva, Anand Desai, and David Pointcheval. Key-
privacy in public-key encryption. In Advances in Cryptology - ASIACRYPT 2001,
7th International Conference on the Theory and Application of Cryptology and
Information Security, Gold Coast, Australia, December 9-13, 2001, Proceedings,
pages 566–582, 2001.
[BCG+ 14a] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers,
Eran Tromer, and Madars Virza. Zerocash: Decentralized anonymous payments
from bitcoin. In 2014 IEEE Symposium on Security and Privacy, pages 459–474.
IEEE Computer Society Press, May 2014.
[BCG+ 14b] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers,
Eran Tromer, and Madars Virza. Zerocash: Decentralized anonymous payments
from Bitcoin. Cryptology ePrint Archive, Report 2014/349, 2014. http://eprint.
iacr.org/2014/349.
[BCG+ 15] Eli Ben-Sasson, Alessandro Chiesa, Matthew Green, Eran Tromer, and Madars
Virza. Secure sampling of public parameters for succinct zero knowledge proofs. In
2015 IEEE Symposium on Security and Privacy, pages 287–304. IEEE Computer
Society Press, May 2015.

54
[BCI+ 13] Nir Bitansky, Alessandro Chiesa, Yuval Ishai, Rafail Ostrovsky, and Omer Paneth.
Erratum: Succinct non-interactive arguments via linear interactive proofs. In
Theory of Cryptography - 10th Theory of Cryptography Conference, TCC 2013,
Tokyo, Japan, March 3-6, 2013. Proceedings, 2013.

[BCTV13] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct
non-interactive arguments for a von neumann architecture. Cryptology ePrint
Archive, Report 2013/879, 2013. http://eprint.iacr.org/2013/879.

[BFS16] Mihir Bellare, Georg Fuchsbauer, and Alessandra Scafuro. NIZKs with an un-
trusted CRS: Security in the face of parameter subversion. In Jung Hee Cheon
and Tsuyoshi Takagi, editors, ASIACRYPT 2016, Part II, volume 10032 of LNCS,
pages 777–804. Springer, Heidelberg, December 2016.

[BG18a] J Benet and N Greco. Filecoin: A decentralized storage network. Protoc. Labs,
2018.

[BG18b] Sean Bowe and Ariel Gabizon. Making groth’s zk-snark simulation extractable in
the random oracle model. IACR Cryptology ePrint Archive, 2018:187, 2018.

[BGM+ 18] Christian Badertscher, Juan A. Garay, Ueli Maurer, Daniel Tschudi, and Vassilis
Zikas. But why does it work? A rational protocol design treatment of bitcoin.
In Advances in Cryptology - EUROCRYPT 2018 - 37th Annual International
Conference on the Theory and Applications of Cryptographic Techniques, Tel Aviv,
Israel, April 29 - May 3, 2018 Proceedings, Part II, pages 34–65, 2018.

[BMTZ17] Christian Badertscher, Ueli Maurer, Daniel Tschudi, and Vassilis Zikas. Bitcoin
as a transaction ledger: A composable treatment. In Advances in Cryptology -
CRYPTO 2017 - 37th Annual International Cryptology Conference, Santa Barbara,
CA, USA, August 20-24, 2017, Proceedings, Part I, pages 324–356, 2017.

[Can01] Ran Canetti. Universally composable security: A new paradigm for cryptographic
protocols. In 42nd FOCS, pages 136–145. IEEE Computer Society Press, October
2001.

[CL02] Jan Camenisch and Anna Lysyanskaya. Dynamic accumulators and application
to efficient revocation of anonymous credentials. In Advances in Cryptology -
CRYPTO 2002, 22nd Annual International Cryptology Conference, Santa Barbara,
California, USA, August 18-22, 2002, Proceedings, pages 61–76, 2002.

[CMP+ 19] Jean-Paul Calderone, Ramakrishnan Muthukrishnan, Paige Peterson, Liz

Steininger, and Chris Wood. P4:private periodic payment protocol. pages 1–23,
2019.

[DDO+ 01] Alfredo De Santis, Giovanni Di Crescenzo, Rafail Ostrovsky, Giuseppe Persiano,
and Amit Sahai. Robust non-interactive zero knowledge. In Joe Kilian, editor,
CRYPTO 2001, volume 2139 of LNCS, pages 566–598. Springer, Heidelberg,
August 2001.

55
[DFKP13] George Danezis, Cédric Fournet, Markulf Kohlweiss, and Bryan Parno. Pinoc-
chio coin: building zerocoin from a succinct pairing-based proof system. In
PETShop’13, Proceedings of the 2013 ACM Workshop on Language Support for
Privacy-Enhancing Technologies, Co-located with CCS 2013, November 4, 2013,
Berlin, Germany, pages 27–30, 2013.

[FKP15] Michael Fleder, Michael S. Kester, and Sudeep Pillai. Bitcoin transaction graph
analysis. CoRR, abs/1502.01657, 2015.

[FMMO18] Prastudy Fauzi, Sarah Meiklejohn, Rebekah Mercer, and Claudio Orlandi.
Quisquis: A new design for anonymous cryptocurrencies. IACR Cryptology
ePrint Archive, 2018:990, 2018.

[FS07] Eiichiro Fujisaki and Koutarou Suzuki. Traceable ring signature. In Tatsuaki
Okamoto and Xiaoyun Wang, editors, PKC 2007, volume 4450 of LNCS, pages
181–200. Springer, Heidelberg, April 2007.

[Fuc18] Georg Fuchsbauer. Subversion-zero-knowledge SNARKs. In Michel Abdalla and

Ricardo Dahab, editors, PKC 2018, Part I, volume 10769 of LNCS, pages 315–347.
Springer, Heidelberg, March 2018.

[GKL15] Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone
protocol: Analysis and applications. In Advances in Cryptology - EUROCRYPT
2015 - 34th Annual International Conference on the Theory and Applications of
Cryptographic Techniques, Sofia, Bulgaria, April 26-30, 2015, Proceedings, Part
II, pages 281–310, 2015.

[GKL17] Juan A. Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone
protocol with chains of variable difficulty. In Advances in Cryptology - CRYPTO
2017 - 37th Annual International Cryptology Conference, Santa Barbara, CA, USA,
August 20-24, 2017, Proceedings, Part I, pages 291–323, 2017.

[GM17] Jens Groth and Mary Maller. Snarky signatures: Minimal signatures of knowledge
from simulation-extractable SNARKs. In Jonathan Katz and Hovav Shacham,
editors, CRYPTO 2017, Part II, volume 10402 of LNCS, pages 581–612. Springer,
Heidelberg, August 2017.

[GMR89] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The knowledge complexity
of interactive proof systems. SIAM J. Comput., 18(1):186–208, 1989.

[Gro10] Jens Groth. Short pairing-based non-interactive zero-knowledge arguments. In

Masayuki Abe, editor, ASIACRYPT 2010, volume 6477 of LNCS, pages 321–340.
Springer, Heidelberg, December 2010.

[Gro16] Jens Groth. On the size of pairing-based non-interactive arguments. In Marc

Fischlin and Jean-Sébastien Coron, editors, EUROCRYPT 2016, Part II, volume
9666 of LNCS, pages 305–326. Springer, Heidelberg, May 2016.

56
[JKS16] Ari Juels, Ahmed E. Kosba, and Elaine Shi. The ring of Gyges: Investigating
the future of criminal smart contracts. In Edgar R. Weippl, Stefan Katzenbeisser,
Christopher Kruegel, Andrew C. Myers, and Shai Halevi, editors, ACM CCS 2016,
pages 283–295. ACM Press, October 2016.

[KCA+ 18] Aggelos Kiayias, Michele Ciampi, Behzad Abdolmaleki, Karim Baghery, Janno
Siim, Luisa Siniscalchi, Ivan Visconti, Michal Zajac, and Peter Gazi. State of the
art of cryptographic ledgers. 2018.

[KFTS17] Amrit Kumar, Clément Fischer, Shruti Tople, and Prateek Saxena. A traceability
analysis of monero’s blockchain. In Computer Security - ESORICS 2017 - 22nd
European Symposium on Research in Computer Security, Oslo, Norway, September
11-15, 2017, Proceedings, Part II, pages 153–173, 2017.

[KLO19] Jihye Kim, Jiwon Lee, and Hyunok Oh. Qap-based simulation-extractable SNARK
with a single verification. IACR Cryptology ePrint Archive, 2019:586, 2019.

[KMS+ 16] Ahmed E. Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos Papa-
manthou. Hawk: The blockchain model of cryptography and privacy-preserving
smart contracts. In 2016 IEEE Symposium on Security and Privacy, pages 839–858.
IEEE Computer Society Press, May 2016.

[Kob98] Neal Koblitz. An elliptic curve implementation of the finite field digital signature
algorithm. In Advances in Cryptology - CRYPTO ’98, 18th Annual International
Cryptology Conference, Santa Barbara, California, USA, August 23-27, 1998,
Proceedings, pages 327–337, 1998.

[KZM+ 15] Ahmed E. Kosba, Zhichao Zhao, Andrew Miller, Yi Qian, T.-H. Hubert Chan,
Charalampos Papamanthou, Rafael Pass, Abhi Shelat, and Elaine Shi. C∅C∅: A
Framework for Building Composable Zero-Knowledge Proofs. Technical Report
2015/1093, November 10, 2015. http://eprint.iacr.org/2015/1093, last
accessed version from 9 Apr 2017.

[Lip12] Helger Lipmaa. Progression-free sets and sublinear pairing-based non-interactive

zero-knowledge arguments. In Ronald Cramer, editor, TCC 2012, volume 7194 of
LNCS, pages 169–189. Springer, Heidelberg, March 2012.

[Lip19] Helger Lipmaa. Simulation-extractable SNARKs revisited. Cryptology ePrint

Archive, Report 2019/612, 2019. http://eprint.iacr.org/2019/612.

[Mer] Ralph Charles Merkle. Secrecy, authentication and public key systems. PhD thesis,
Stanford University.

[MGGR13] Ian Miers, Christina Garman, Matthew Green, and Aviel D. Rubin. Zerocoin:
Anonymous distributed e-cash from bitcoin. In 2013 IEEE Symposium on Security
and Privacy, SP 2013, Berkeley, CA, USA, May 19-22, 2013, pages 397–411, 2013.

[MS18] Izaak Meckler and Evan Shapiro. Coda: Decentralized cryptocurrency at scale.
2018.

57
[MSH+ 18] Malte Möser, Kyle Soska, Ethan Heilman, Kevin Lee, Henry Heffan, Shashvat
Srivastava, Kyle Hogan, Jason Hennessey, Andrew Miller, Arvind Narayanan, and
Nicolas Christin. An empirical analysis of traceability in the monero blockchain.
PoPETs, 2018(3):143–163, 2018.

[Nak08] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.

[Noe15] Shen Noether. Ring signature confidential transactions for monero. IACR Cryptol-
ogy ePrint Archive, 2015:1098, 2015.

[Ped91] Torben P. Pedersen. Non-interactive and information-theoretic secure verifiable

secret sharing. In Advances in Cryptology - CRYPTO ’91, 11th Annual Interna-
tional Cryptology Conference, Santa Barbara, California, USA, August 11-15,
1991, Proceedings, pages 129–140, 1991.

[PHGR13] Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. Pinocchio: Nearly
practical verifiable computation. In 2013 IEEE Symposium on Security and Privacy,
pages 238–252. IEEE Computer Society Press, May 2013.

[PSS17] Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in
asynchronous networks. In Advances in Cryptology - EUROCRYPT 2017 - 36th
Annual International Conference on the Theory and Applications of Cryptographic
Techniques, Paris, France, April 30 - May 4, 2017, Proceedings, Part II, pages
643–673, 2017.

[RH11] Fergal Reid and Martin Harrigan. An analysis of anonymity in the bitcoin system.
In PASSAT/SocialCom 2011, Privacy, Security, Risk and Trust (PASSAT), 2011
IEEE Third International Conference on and 2011 IEEE Third International
Conference on Social Computing (SocialCom), Boston, MA, USA, 9-11 Oct., 2011,
pages 1318–1326, 2011.

[RS13] Dorit Ron and Adi Shamir. Quantitative analysis of the full bitcoin transaction
graph. In Financial Cryptography and Data Security - 17th International Confer-
ence, FC 2013, Okinawa, Japan, April 1-5, 2013, Revised Selected Papers, pages
6–24, 2013.

[RST01] Ronald L. Rivest, Adi Shamir, and Yael Tauman. How to leak a secret. In Advances
in Cryptology - ASIACRYPT 2001, 7th International Conference on the Theory
and Application of Cryptology and Information Security, Gold Coast, Australia,
December 9-13, 2001, Proceedings, pages 552–565, 2001.

[ST99] Tomas Sander and Amnon Ta-Shma. Auditable, anonymous electronic cash
extended abstract. In Advances in Cryptology - CRYPTO ’99, 19th Annual Inter-
national Cryptology Conference, Santa Barbara, California, USA, August 15-19,
1999, Proceedings, pages 555–572, 1999.

58
 II. Licence
Non-exclusive licence to reproduce thesis and make thesis public
I, Shahla Atapoor,

1. herewith grant the University of Tartu a free permit (non-exclusive licence) to

reproduce, for the purpose of preservation, including for adding to the DSpace digital
archives until the expiry of the term of copyright,

On Privacy Preserving Blockchains and zk-SNARKs,

supervised by Helger Lipmaa, Janno Siim and Karim Baghery.

2. I grant the University of Tartu a permit to make the work specified in p. 1 available to the
public via the web environment of the University of Tartu, including via the DSpace digital
archives, under the Creative Commons licence CC BY NC ND 3.0, which allows, by
giving appropriate credit to the author, to reproduce, distribute the work and communicate
it to the public, and prohibits the creation of derivative works and any commercial use of
the work until the expiry of the term of copyright.

3. I am aware of the fact that the author retains the rights specified in p. 1 and 2.

4. I certify that granting the non-exclusive licence does not infringe other persons’ intellectual
property rights or rights arising from the personal data protection legislation.

Shahla Atapoor
14.08.2019

59

View publication stats