Azeroth: Auditable Zero-knowledge Transactions in Smart Contracts
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Azeroth: Auditable Zero-knowledge Transactions in
Smart Contracts
Abstract—With the rapid growth of the blockchain market, proofs [19] to ensure transactions in a valid set of UTXOs.
privacy and security issues for digital assets are becoming more Zether [8] based on the account model encrypts accounts
important. In the most widely used public blockchains such as with homomorphic encryption and provides zero-knowledge
Bitcoin and Ethereum, all activities on user accounts are publicly
disclosed, which violates privacy regulations such as EU GDPR. proofs [10] to ensure valid modification of encrypted accounts.
Encryption of accounts and transactions may protect privacy, Zether builds up partial privacy for unlinkability between
but it also raises issues of validity and transparency: encrypted sender and receiver addresses, similar to Monero [31].
information alone cannot verify the validity of a transaction and
As asset transactions on the blockchain increase, the demand
makes it difficult to meet anti-money laundering regulations, i.e.
auditability. for adequate auditing capabilities is also increasing. Moreover,
In this paper, we propose Azeroth, an auditable zero- if transaction privacy is protected without proper regulation,
knowledge transfer framework. Azeroth connects a zero- financial transactions can be abused by criminals and terrorists.
knowledge proof to an encrypted transaction, enabling it to Without the management of illegal money flows, it would
check its validation while protecting its privacy. Azeroth also
be also difficult to establish a monetary system required
allows authorized auditors to audit transactions. Azeroth is
designed as a smart contract for flexible deployment on existing to maintain a sound financial system and enforce policies
blockchains. We implement the Azeroth smart contract, execute it accordingly. Recently, Bittrex1 delisted dark coins such as
on various platforms including an Ethereum testnet blockchain, Monero [31], Dash [15], and Zerocash [6]. In fact, many
and measure the time to show the practicality of our proposal. global cryptocurrency exchanges are also strengthening their
The end-to-end latency of an privacy-preserving transfer takes
distance from the dark coins as recommended by Financial
about 4.4s. In particular, the client’s transaction generation time
with a proof only takes about 0.9s. The security of Azeroth is Action Task Force (FATF) [16]. Thus, we need to find a
proven under the cryptographic assumptions. middle ground of contradiction between privacy preservation
and fraudulent practices. This paper focuses on a privacy-
I. I NTRODUCTION preserving transfer that provides auditability for auditors while
With the widespread adoption of blockchains, various de- protecting transaction information from non-auditors.
centralized applications (DApps) and digital assets used in Auditable private transfer can be designed by using encryp-
DApps are becoming popular. Unlike traditional banking sys- tion and the ZKP. A sender encrypts a transaction so that
tems, however, the blockchain creates privacy concerns about only its receiver and the auditor can decrypt it. At the same
digital assets since all transaction information is shared across time, the sender should prove that the ciphertext satisfies all
the network for strong data integrity. Various studies have the requirements for the validity of the transaction. In partic-
been attempted to protect transaction privacy by utilizing ular, we utilize zk-SNARK (Zero-Knowledge Succinct Non-
cryptographic techniques such as mixers [3], [25], [26], ring interactive ARgument of Knowledge) [19], [20], [29] to prove
signatures [31], homomorphic encryption [8], zero-knowledge arbitrary functionalities for messages, including encryption.
proofs [6], [8], [21], [30], etc. Although the encryption check incurs non-negligible overhead
In the blockchain community, the zero-knowledge proof for the prover, it is essential for the validity and auditability
(ZKP) system is a widely used solution to resolve the conflict of the transaction. Indeed, without a proof for encryption as in
between privacy and verifiability. The ZKP is a proof system Zerocash [6], even if a ciphertext passes all other transaction
that can prove the validity of the statement without reveal- checks, there always exists a possibility that an incorrectly
ing the witness value; users can prove arbitrary statements generated ciphertext, either accidentally or intentionally, will
of encrypted data, enabling public validation while protect- be accepted, resulting in the loss of the validity and auditability
ing data privacy. For instance, the well-known anonymous of the transaction.
blockchain ledger Zerocash [6], which operates on the UTXO There are two main privacy considerations in a transfer
model, secures transactions, while leveraging zero-knowledge transaction: confidentiality (concealing a balance and a transfer
amount) and anonymity (concealing a sender and a recipi-
ent). Confidentiality can be provided by utilizing encryption,
while anonymity can be provided by utilizing an accumu-
lator. Specifically, we employ dual accounts that constitute
Network and Distributed System Security (NDSS) Symposium 2023 an encrypted account in addition to a plain account, similar
28 February - 4 March 2023, San Diego, CA, USA
ISBN 1-891562-83-5 1 https://global.bittrex.com/
https://dx.doi.org/10.14722/ndss.2023.23xxx
www.ndss-symposium.orgto Blockmaze [21]. A user may execute deposit/withdrawal While Azeroth additionally supports encryption verifia-
transactions between its own plain/encrypted accounts. At the bility and auditability, it shows better performance results
same time, the user may send some encrypted value from its than the other existing schemes through implementation
accounts to the accumulator (implemented as an Merkle tree). optimization. To show the practicality of our scheme, we
The owner of the encrypted value may receive it from the implement the client side on various devices including
accumulator to the user’s accounts. Android/iOS mobile phones. For the details, refer to
We construct a single transaction to execute all these section VI.
functions of deposit/withdrawal/send/receive simultaneously. Organizations. The paper is comprised of the following
Information about the transaction can be inferred only from contents: First, we provide the related works concerning our
the plain account state transition; if the plain account state proposed scheme in section II. In section III, we describe
keeps the same, it cannot learn even the function type as well preliminaries on our proposed system. In section IV, we
as the value amount. We also add auditability by utilizing give an explanation of data structures utilized in Azeroth.
two recipients encryption so that an authorizer as well as the Afterward, we elucidate the overview and construction, al-
receiver can decrypt the transaction. The auditor’s ability can gorithms, construction, and security definitions in section V.
be distributed through a threshold scheme. In order to have this Section VI shows the implementation and the experimental
strong anonymity with auditablity, the most challenging part results. Finally, we make a conclusion in section VII.
is how to adopt and implement zk-SNARKs for this complex
relation proof. II. R ELATED W ORK
The blockchain has been proposed for integrity rather than
In this paper, we propose Azeroth, an auditable zero-
privacy. To provide privacy in blockchain, various schemes
knowledge transaction framework based on zk-SNARK. The
have been proposed along several lines of work.
Azeroth framework provides privacy, verifiability, and au-
A mixing service(or tumbler) such as CoinJoin [25],
ditability for personal digital assets while maintaining the
Möbius [26], and Tornado Cash [3] offers a service for
efficiency of transactions. Azeroth preserves the original func-
mixing identifiable cryptocurrency transfer with others, so as
tionality of the account-based blockchain as well as providing
to obscure the trail back to the transfer’s original source. Thus,
the additional zero-knowledge feature to meet the standard
the mixer supports personal privacy protection for transactions
privacy requirements. Azeroth is devised using encryption for
on the blockchain. However, since the mixers take heed of
two-recipients (i.e., the recipient and the auditor) so that the
anonymity, it exists the possibility of a malevolent problem.
auditor can audit all transactions. Still, the auditor’s capability
Zerocash [6] provides a well-known privacy-preserving
is limited to auditing and cannot manipulate any transactions.
transfer on UTXO-model blockchains. In Zerocash, a sender
Azeroth enhances the privacy of the transaction by performing
makes new commitments that hide the information of the
multiple functions such as deposit, withdrawal, and transfer in
transaction (i.e., value, receiver) which is open only to the
one transaction. For the real-world use, we adopt a SNARK-
receiver. The sender then proves the correctness of the com-
friendly hash algorithm to instantiate encryption to have an
mitments using the zero-knowledge proof. As an extension to
efficient proving time and execute experiments on various
a smart contract, Zeth [30] sorts the privacy problem out by
platforms.
implementing Zerocash into a smart contract. Zeth creates the
The contributions of this paper are summarized as follows. anonymous coin within the smart contract in the form of un-
• Framework: We design a privacy-preserving framework derlying the UTXO model. Thus, operations and mechanisms
Azeroth on an account-based blockchain model, while in Zeth are almost the same as Zerocash. ZEXE [7], extending
including encryption verifiability, and auditability. More- Zerocash with scripting capabilities, supports function privacy
over, since Azeroth constructed as a smart contract that nobody knows which computation is executed in off-line.
does not require any modifications to the base-ledger, Hawk [24] is a privacy-preserving framework for building
it advocates flexible deployment, which means that any arbitrary smart contracts. However, there exists a manager,
blockchain models supporting smart-contract can utilize entrusted with the private data, that generates a zk-SNARK
our framework. proof to show that the process is executed correctly.
• Security: We revise and extend the security properties of Blockmaze [21] proposes a dual balance model for account-
private transactions: ledger indistinguishability, transac- model blockchains, consisting of a public balance and private
tion unlinkability, transaction non-malleability, balance, balance. For hiding the internal confidential information, they
and auditability, and prove that Azeroth satisfies all employ zk-SNARK when constructing the privacy-preserving
required properties under the security of underlying cryp- transactions. Thus, it performs within the transformation be-
tographic primitives. tween the public balance and the private balance to disconnect
• Implementation: We implemented and tested Azeroth on the linkage of users. Blockmaze is implemented by revising
the existing account-based blockchain models, such as the blockchain core algorithm, restricting its deployment to
Ethereum [9]. According to our experiment, it takes 4.38s other existing blockchains.
to generate a transaction in a client and process it in Quisquis [17] is a new anonymity system without a trusted
a smart contract completely on the Ethereum testnet. setup. However, it has the possibility of a front-running attack
2by updating the public keys in an anonymity set before key. Given the values u and o, a commitment cm to a value
the transaction is broadcasted. Moreover, this system is a u can be disclosed; one can check if cm ← COM(u; o).
standalone cryptocurrency not supporting deployment on any
smart contract platform. Pseudorandom function. A pseudorandom function
Zether [8] accomplishes the privacy protection in the PRFk (x) : {0, 1}∗ → {0, 1}poly(λ) is a function of a random
account-based model using ZKPs (Bulletproofs [10]) and the seed key k and an input x that is indistinguishable from a
ElGamal encryption scheme. While Zether is stateful, it does uniform random function.
not hide the identities of parties involved in the transaction. Zero-Knowledge Succinct Non-interactive Arguments of
Moreover, since the sender should generate a zero-knowledge Knowledge. As described in [19], [20], given a relation R, a
proof for the large user set for anonymity, it has limitation to zk-SNARK is composed of a set of algorithms Πsnark = (Setup,
support a high level of anonymity. Diamond [14] proposes Prove, VerProof, SimProve) that works as follows.
“many out of many proofs” to enhance proving time for
a subset of a fixed list of commitments. Nevertheless, the • Setup(λ, R) → crs := (ek, vk), td : The algorithm takes a
anonymity corresponding to all system users is not supported. security parameter λ and a relation R as input and returns
Among the privacy-preserving payment systems, some a common reference string crs containing an evaluating
approaches allow auditability. Solidus [11] is a privacy- key ek and a verification key vk, and a simulation trapdoor
preserving protocol for asset transfer in which banks play a td.
role as an arbitrator of mediation. Solidus utilizes ORAM to • Prove(ek, x, w) → π : The algorithm takes an evaluating
support update accounts without revealing the values, but it key ek, a statement x, and a witness w such that (x, w) ∈
cannot provide a dedicated audit function. Specifically, it can R as inputs, and returns a proof π.
only offer auditing by revealing whole keys to an auditor, and • VerProof(vk, x, π) → true/false : The algorithm takes
opening transactions. a verification key vk, a statement x, and a proof π as
zkLedger [27] and FabZK [23] enable anonymous payments inputs, and returns true if the proof is correct, or false
via the use of homomorphic commitments and NIZK while otherwise.
supporting auditability. However, since these systems are de- • SimProve(ek, td, x) → πsim : The SimProve algorithm
signed based on organizational units, there is the problem takes a evaluating key ek, a simulation trapdoor td, and a
of performance degradation as the number of organizations statement x as inputs, and returns a proof πsim such that
increases. Thus, they are practical only when there are a small VerProof(vk, x, πsim ) → true.
number of organizations due to the performance issue.
PGC [12] aims for a middle ground between privacy and Its properties are completeness, knowledge soundness, zero-
auditability and then proposes auditable decentralized confi- knowledge, and succinctness as described below.
dential payment using an additively homomorphic public-key C OMPLETENESS. The honest verifier always accepts the proof
encryption. However, the anonymity set size should be small for any pair (x, w) satisfying the relation R. Strictly, for ∀ λ ∈
in the approach. The work [4] proposes a privacy-preserving N, ∀ Rλ , and ∀ (x, w) ∈ Rλ , it holds as follow.
auditable token management system using NIZK. However,
the work is designed for enterprise networks on a permissioned (ek, vk, td) ← Setup(R);
Pr true ← VerProof(vk, x, π) =1
π ← Prove(ek, x, w)
blockchain. Moreover, whenever transferring a token, a user
should contact the privileged party called by Certifier that
checks if the transaction is valid. K NOWLEDGE SOUNDNESS. Knowledge soundness says that
if the honest prover outputs a proof π, the prover must
III. P RELIMINARIES know a witness and such knowledge can be extracted with
In this section, we describe notations for standard crypto- a knowledge extractor E in polynomial time. To be more
graphic primitives. Let λ be the security parameter. specific, if there exists a knowledge
extractor E for any PPT
adversary A such that Pr GameKS RG,A,E = true = negl(λ), a
Collision-resistant hash. A hash function CRH : argument system Πsnark has knowledge soundness.
∗ poly(λ)
{0, 1} → {0, 1} is a collision-resistant hash KS
function if it is difficult to find two different inputs of GameRG,A,E → res
λ
which their output is equivalent. That is, for all PPT (R, auxR ) ← RG(1 ); (crs := (ek, vk), td) ← Setup(R);
adversaries
A, there exists a negligible function negl, (x, π) ← A(R, auxR , crs); w ← E(transcriptA );
Pr (x0 , x1 ) ← A(1λ , CRH) : x0 ̸= x1 ∧ CRH(x0 ) = CRH(x1 ) Return res ← (VerProof(vk, x, π) ∧ (x, π) ∈
/ R)
≤ negl(λ).
Commitment. A commitment scheme COM provides the Z ERO KNOWLEDGE. Simply, a zero-knowledge means that
computational binding property and the statistical hiding prop- a proof π for (x, w) ∈ R on Πsnark only has information
erty. It also provides the ability to reveal the committed about the truth of the statement x. Formally, if there exists
value later. We denote a commitment cm for a value u as a simulator such that the following conditions hold for any
cm ← COM(u; o) where o denotes the commitment opening adversary A, we say that Πsnark is zero-knowledge.
3IV. DATA S TRUCTURES
λ
(R, auxR ) ← RG(1 ); (crs := (ek, vk), td) ← Π.Setup(R) This section describes the data structures used in our pro-
Pr
: π ← Prove(ek, x, w); true ← A(crs, auxR , π) posed scheme Azeroth, referring to the notion.
≈
Ledger. All users are allowed to access the ledger denoted as
(R, auxR ) ← RG(1λ ); (crs := (ek, vk), td) ← Setup(R)
L, which contains the information of all blocks. Additionally, L
Pr
: πsim ← SimProve(ek, td, x); true ← A(crs, auxR , πsim ) is sequentially expanded out by appending new transactions to
the previous one (i.e., for any T′ < T, LT always incorporates
S UCCINCTNESS. An arguments system Π is succinctness if LT′ ).
it has a small proof size and fast verification time.
Account. There are two types of accounts in Azeroth: an
|π| ≤ Poly(λ)(λ + log|w|) externally owned account denoted as EOA, and an encrypted
TimeVerProof ≤ Poly(λ)(λ + log|w| + |x|) account denoted as ENA. The former is the same one as in
other account-based blockchains (e.g., Ethereum) and the latter
Symmetric-key encryption. We use a symmetric-key encryp- is an account that includes a ciphertext indicating an amount
tion scheme SE is a set of algorithms SE = (Gen, Enc, Dec) in the account. EOA is maintained by blockchain network and
which operates as follows. interacts with the smart contract, while ENA registration and
updates are managed by a smart contract, and users cannot see
• Gen(1λ ) → k : The Gen algorithm takes a security
the value in ENA without its secret key.
parameter 1λ and returns a key k.
• Enck (msg) → sct : The Enc algorithm takes a key k and Auditor key. An auditor generates a pair of private/public keys
a plaintext msg as inputs and returns a ciphertext sct. (ask, apk) used in the public key system; apk is used when
• Deck (sct) → msg : The Dec algorithm takes a key k and a user generates an encrypted transaction, while ask is used
a ciphertext sct as inputs. It returns a plaintext msg. when an auditor needs to audit the ciphertext.
The encryption scheme SE satisfies ciphertext indistin- User key. Each user generates a pair of private/public keys
guishability under chosen-plaintext attack IND-CPA security (usk = (kENA , skown , skenc ), upk = (addr, pkown , pkenc )).
and key indistinguishability under chosen-plaintext attack IK-
• kENA : It indicates a secret key for encrypted account of
CPA security.
ENA in a symmetric-key encryption system.
Public-key encryption. We use a public-key encryption • (skown , pkown ) : pkown is computed by hashing skown . The
scheme PE = (Gen, Enc, Dec) which operates as follows. key pair is used to prove the ownership of an account
• Gen(1λ ) → (sk, pk) : The Gen algorithm takes a security in a transaction. Note that skown is additionally used to
parameter 1λ and returns a key pair (sk, pk). generate a nullifier, which prevents double-spending.
• Encpk (msg) → pct : The Enc algorithm takes a public • (skenc , pkenc ) : These keys are used in a public-key en-
key pk and a message msg as inputs and returns a cryption system; skenc is used to decrypt ciphertexts taken
ciphertext pct. from transactions while pkenc is to encrypt transactions.
• Decsk (pct) → msg : The Dec algorithm takes a private • addr : It is a user address and computed by hashing pkown
key sk and a ciphertext pct as inputs. It returns a plaintext and pkenc .
msg.
Commitment and Note. To build a privacy-preserving trans-
The encryption scheme PE satisfies ciphertext indistin-
action, a commitment is utilized to hide the sensitive infor-
guishability under chosen-plaintext attack IND-CPA security
mation (i.e., amount, address). Our commitment is noted as
and key indistinguishability under chosen-plaintext attack IK-
follows.
CPA security.
cm = COM(v, addr; o)
Remark. To prove that encryption is performed correctly
To commit, it takes v, addr as inputs and runs with an opening
within a zk-SNARK circuit, we need random values used
o. v is the digital asset value to be transferred and addr is the
in encryption as a witness. We denote the values as aux.
address of a recipient. Once cm is published on a blockchain,
Depending on the context in our protocol, we denote the
the recipient given the opening key o and the value v from the
encryption such that it also outputs aux as a SNARK witness
encrypted transaction uses them to make another transfer. We
as follows.
denote the data required to spend a commitment as a note:
(pct, aux) ← PE.Encpk (msg)
note = (cm, o, v)
Remark. Supporting the audit function allows the trusted
auditor to decrypt the message for the encrypted message. Note that each user stores his own notes in his wallet privately
Thus, we need an encryption with two recipients. We denote for his convenience.
its encryption with a user public key pk and an auditor public
Membership based on Merkle Tree. We use a Merkle hash
key apk as follows.
tree to prove the membership of commitments in Azeroth and
(pct, aux) ← PE.Encpk,apk (msg) denote the Merkle tree and its root as MT and rt, respectively.
4MT holds all commitments in L, and it appends commitments zkTransfer, all values in ENA and MT are processed in
to nodes and updates rt when new commitments are given. Ad- the form of ciphertexts and whether remittance is between
ditionally, an authentication co-path from a commitment cm to own accounts or between non-own accounts is hidden, so
rt is denoted as Pathcm . For any given time T, MTT includes the linking information between the sender and receiver is
a list of all commitments and rt of these commitments. There protected.
are three algorithms related with MT. Figure 1 illustrates the zkTransfer. The left box “IN”
• true/false ← MembershipMT (rt, cm, Pathcm ) : This al- represents input values and the right box “OUT” denotes
pub pub
gorithm verifies if cm is included in MT rooted by rt; output values. In zkTransfer, vin and vout are publicly visible
if rt is the same as a computed hash value from the values. vENA is obtained by decrypting its encrypted account
commitment cm along the authentication path Pathcm , value sct. The updated vnewENA
is encrypted and stored as sct∗
priv
it returns true. in ENA. The amount (vin ) included in a commitment can
• Pathcm ← ComputePathMT (cm) : This algorithm returns be used as input if a user has its opening key; the opening
the authentication co-path from a commitment cm appear- key is delivered in a ciphertext pct so that only the destined
ing in MT. user can correctly decrypt it. To prevent double spending, for
• rtnew ← TreeUpdateMT (cm) : This algorithms appends each spent commitment a nullifier is generated by hashing the
a new commitment cm, performs hash computation for commitment and the private key skown and appended; it is still
each tree layer, and returns a new tree root rtnew . unlinkable between the commitment and the nullifier without
the private key skown . Finally, for the transaction validity,
Value Type. A transaction includes several input/output asset zkTransfer proves that all of the above procedures are correctly
values which are publicly visible or privately secured. In our performed by generating a zk-SNARK proof.
description, pub and priv represent a publicly visible value and
Auditability is achieved by utilizing public-key encryption
an encrypted (or committed) value respectively. “in” indicates
with two recipients; all pct ciphertexts can be decrypted by an
the value to be deposited to one’s account and “out” represents
auditor as well as a receiver so that the auditor can monitor
the value to be withdrawn from one’s account. We summarize
all the transactions. We note that ENA exploits symmetric-
the types of digital asset values as follows.
key encryption only for the performance gain although ENA
• vENA : The digital asset value available in the encrypted can also utilize the public-key encryption. Notice that without
account ENA. decrypting ENA, the auditor can still learn the value change
pub pub
• vin and vout : The digital asset value to be publicly in ENA by computing the remaining values from vin pub pub
, vout ,
transferred from the sender’s EOA and the digital asset priv
vin priv
, and vout .
value to the receiver’s public account EOA, respectively.
priv priv
• vin and vout : The digital asset value received anony-
mously from an existing commitment and the value sent B. Algorithms
anonymously to a new commitment in MT, respectively.
Azeroth consists of three components: Client,
V. Azeroth Smart Contract, and Relation. Client generates a transaction
A. Overview which includes a ciphertext and a proof. Smart Contract
denotes a smart contract running on a blockchain. Relation
We construct Azeroth by integrating deposit/withdrawal
represents a zk-SNARK circuit for generating a zkTransfer
transactions and public/private transfer transactions into a
proof. The our system is a tuple of algorithms defined as
single transaction zkTransfer. Since zkTransfer executes multi-
follows.
functions in the same structure, it improves the function
anonymity. One may try to guess which function is executed [Azeroth Client]
by observing the input/output values in zkTransfer. zkTransfer,
• SetupClient : A trusted party runs this algorithm only
however, reveals the input/output values only in EOA; the
once to set up the whole system. It also returns public
values withdrawn/deposited from/to ENA and the values trans-
parameter pp.
ferred from/to MT are hidden. A membership proof of MT
• KeyGenAuditClient : This algorithm generates an auditor
hides the recipient address. As a result, the information that
key pair (ask, apk). It also outputs the key pair and a
an observer can extract from the transaction is that someone’s
transaction TxKGA .
EOA value either increases or decreases; he cannot know
• KeyGenUserClient : This algorithm generates a user key
whether the amount difference is deposited/withdrawn to/from
pair (usk, upk). It also returns a transaction TxKGU to
its own ENA, or is transferred from/to a new commitment in
register the user’s public key.
MT. It is even more complicated because those values can be
• zkTransferClient : A user executes this algorithm for trans-
mixed in a range where the sum of the input values is equal
fer. The internal procedures are described as follows:
to the sum of the output values.
i) Consuming note = (cm, o, v): It proves the knowledge of
zkTransfer implements a private transfer with only two the committed value v using the opening key o and the
transactions; a sender executes zkTransfer transferred to MT membership of a commitment cm in MT and derives a
and a receiver executes zkTransfer transferred from MT. In nullifier nf from PRF to nullify the used commitment.
5Fig. 1: Overview of zkTransfer
priv
ii) Generating cmnew : By executing COM(vout , addrrecv ; onew ), valid, the cmnew is appended to MT, MT is updated, a
a new commitment and its opening key are obtained. Then it new Merkle tree root rtnew is added to Listrt and the
priv
encrypts (onew , vout , addrrecv ) via PE.Enc and outputs pct. nullifier nf is appended to Listnf . The encrypted account
iii) Processing currency: The sender’s ENA balance is updated
priv
based on vin (from note), vout priv pub
, vin , and voutpub
or ∆v ENA =
is updated. And then the public amounts are processed;
pub pub
priv pub priv
vin + vin - vout - vout . pub vin is acquired from EOAsend , and vout is delivered to
recv
EOA . If the transaction is invalid, it is reverted and
With prepared witnesses and statements, the algorithm
aborted.
generates a zk-SNARK proof and finally outputs a
zkTransfer transaction TxZKT . [Azeroth Relation] The statement and witness of Relation
• RetreiveNoteClient : This algorithm is a sub-algorithm RZKT are as follows:
computing a note used in zkTransferClient . It allows a user x = (apk, rt, nf, upksend , cmnew , sctold , sctnew , vin
⃗ pub pub
, vout , pctnew )
to find cm transferred to the user along with its opening
⃗ = (usksend , cmold , oold , vin
w priv
, upkrecv , onew , vout
priv
, auxnew , Path)
key and its committed value. Then, a user decrypts the
ciphertext using skenc each transaction pct ∈ L to where a sender public key upksend is (addrsend , pksend send
own , pkenc )
(o, v, addr∗ ) and stores (cm, o, v) as note in the user’s and a receiver’s public key upkrecv recv recv recv
is (addr , pkown , pkenc ).
wallet if addr∗ matches its address addr.
• Audit: An auditor with a valid ask runs this algorithm to We say that a witness w ⃗ is valid for a statement ⃗x, if and only
audit a transaction by decrypting the ciphertext pct in the if the following holds:
priv
transaction. • If vin > 0, then cmold must exist in MT with given rt
[Azeroth Smart Contract] and Path.
• pksend send
own = CRH(skown ).
• SetupSC : This algorithm deploys a smart contract and
• The user address addrsend and addrrecv are well-formed.
stores the verification key vk from zk-SNARK where vk
• cmold and cmnew are valid.
is used to verify a zk-SNARK proof in the smart contract.
• nf is derived from cmold and sksend own .
• RegisterAuditorSC : This algorithm stores an auditor pub-
• pctnew is an encryption of cmnew via auxnew .
lic key apk in Azeroth’s smart contract.
• sctnew is an encryption of updated ENA balance.
• RegisterUserSC : This algorithm registers a new encrypted priv pub
• All amounts (e.g., vin , vin , ...) are not negative.
account for address addr. If the address already exists in
Listaddr , the transaction is reverted. Otherwise, it registers Given the building blocks of a public-key encryption PE,
a new ENA and initializes it with zero amount. a symmetric-key encryption SE, and a zk-SNARK Πsnark , we
• zkTransferSC : This algorithm checks the validity of the construct Azeroth as in Figure 2.
transaction, and processes the transaction. A transaction
is valid iff: Merkle root rtold exists in root list Listrt , C. Security
a nullifier nf does not exists in the nullifier list Listnf , Following the similar model defined in [6], [21], we de-
addrsend exists, cmnew does not exists in Listcm , and fine the security properties of Azeroth including ledger in-
a proof π is valid in zk-SNARK. If the transaction is distinguishability, transaction unlinkability, transaction non-
6Azeroth Client Azeroth Smart contract
λ
◦ SetupClient (1 , RZKT ) : ◦ SetupSC (vk) :
(ek, vk) ← Πsnark .Setup(RZKT ) Store a zk-SNARK verification key vk
G←G
$ Initialize a Merkle Tree
Return pp = (ek, vk, G)
◦ RegisterAuditorSC (apk) :
◦ KeyGenAuditClient (pp): APK ← apk
$
(ask, apk) ← PE.Gen(pp) ◦ RegisterUserSC (addr) :
TxKGA = (apk) Assert addr ̸∈ Listaddr
Return (apk, ask), TxKGA ENA[addr] ← 0
◦ KeyGenUserClient (pp): pub pub
◦ zkTransferSC (π, rtold , nf, addrsend , cmnew , sctnew , pctnew , vin , vout , EOArecv ):
$
(skenc , pkenc ) ← PE.Gen(pp) Assert rtold ∈ Listrt
$ Assert nf ̸∈ Listnf
kENA ← SE.Gen(pp)
$ Assert addrsend ∈ Listaddr
skown ← F; pkown ← CRH(skown )
Assert cmnew ̸∈ Listcm
addr ← CRH(pkown ||pkenc )
usk = (kENA , skown , skenc ) send
( )
APK, rtold , nf, upk , cmnew ,
upk = (addr, pkown , pkenc ) ⃗x= send pub pub
TxKGU = (addr) ENA[addr ], sctnew , vin , vout , pctnew
Return (sk, pk), TxKGU
Assert Πsnark .VerProof(vk, π, ⃗x) = true
ENA[addrsend ] ← sctnew
◦ RetreiveNoteClient (L, sk, pk):
rtnew ← TreeUpdateMT (cmnew )
Parse usk as (kENA , skown , skenc ) Listrt .append(rtnew )
Parse upk as (addr, pkown , pkenc ) Listnf .append(nf)
For each TxZKT on L: pub
if vin pub
> 0 then TransferFrom(EOAsend , this, vin )
Parse TxZKT as (cm, pct, . . . ) end if
(o, v, addr∗ ) ← PE.Decskenc (pct) pub pub
if vout > 0 then TransferFrom(this, EOArecv , vout )
if addr = addr∗ then end if
Return note = (cm, o, v)
end if
Azeroth Relation
priv pub pub
◦ zkTransferClient (note, apk, usksend , upksend , upkrecv , vout , vin , vout , EOArecv ): ◦ Relation R(⃗
x; w)
⃗ :
send send send send
Parse usk as (kENA , skown , skenc )
Parse upksend as (addrsend , pksend send send
( )
own , pkenc ) apk, rt, nf, upk , cmnew ,
Parse upkrecv as (addrrecv , pkrecv send ⃗
x=
own , pkenc ) pub pub
priv sctold , sctnew , vin , vout , pctnew
Parse note as (cmold , oold , vin ) if note ̸= ⊥;
priv $ priv
, addrsend ; oold )
( send priv recv
)
otherwise vin ← 0; oold ← F; cmold ← COM(vin usk , cmold , oold , vin , upk ,
sctold ← ENA[addrsend ] w
⃗ = priv
ENA onew , vout , auxnew , Path
vold ← SE.Decksend (sctold ) ; nf ← PRFsksend (cmold )
ENA own
rt ← Listrt .Top Parse sksend as (ksend send send
ENA , skown , skenc )
priv
Path ← ComputePathMT (cmold ) if vin > 0 Parse upksend as (addrsend , pksend send
priv own , pkenc )
cmnew ← COM(vout , addrrecv ; onew ) Parse upkrecv as (addrrecv , pkrecv send
own , pkenc )
priv
pctnew , auxnew ← PE.Encpkrecv (o ||vout
enc ,apk new
||addrrecv ) priv
if vin > 0 then
ENA ENA priv priv pub pub Assert true = MembershipMT (rt, cmold , Path)
vnew ← vold + vin − vout + vin − vout
sctnew ← SE.Encksend (vnew ENA
) end if
ENA Assert pksend send
own = CRH(skown )
send
Assert addrsend = CRH(pkown ||pkenc )
( )
apk, rt, nf, upk , cmnew ,
⃗
x= pub pub Assert cmold = COM(vin priv
, addrsend ; oold )
sctold , sctnew , vin , vout , pctnew
Assert nf = PRFsksend (cmold )
own
( send priv recv
) priv recv
usk , cmold , oold , vin , upk , Assert pctnew , auxnew = PE.Encpkrecv enc ,apk (onew ||vout ||addr )
w
⃗ = Assert addrrecv = CRH(pkrecv recv
priv own ||pkenc )
onew , vout , auxnew , Path priv recv
Assert cmnew = COM(vout , addr ; onew )
ENA
π ← Πsnark .Prove(ek, ⃗
x, w)
⃗ if sctold = 0 then vold ←0
ENA
pub
TxZKT = (π, rt, nf, addrsend , cmnew , sctnew , vin pub
, vout , pctnew , EOArecv ) else vold ← SE.Decksend (sctold )
ENA
Return TxZKT end if
ENA
Assert vnew ← SE.Decksend (sctnew )
◦ Audit(ask,pct): ENA ENA priv
ENA
priv pub pub
Assert vnew = vold + vin − vout + vin − vout
msg ← PE.Decask (pct) priv priv pub pub
Return msg Assert vout ≥ 0; vin ≥ 0; vin ≥ 0; vout ≥0
ENA ENA
Assert vnew ≥ 0; vold ≥0
Fig. 2: Azeroth scheme ΠAzeroth
malleability, and balance, and define auditability as a new information and even adaptively engender honest parties to
property. execute Azeroth functions. Namely, even if there are two
ledgers L0 and L1 , designed by the adversary using queries
Ledger Indistinguishability. Informally, we say that the
to the oracle, A cannot tell the difference between the two
ledger is indistinguishable if it does not disclose new in-
ledgers. We design an experiment L-IND as shown in fig. 3.
formation, even when an adversary A can see the public
7L-IND TR-NM
Azeroth.GA (λ) : Azeroth.GA (λ) :
pp ← Setup(λ) pp ← Setup(λ)
Azeroth Azeroth Azeroth
O0
(L0 , L1 ) ← A ,O1
(pp) L ← AO (pp, ask)
$ ′ O Azeroth
b ← {0, 1} Tx ← A (L)
$
Q ← {KeyGenUser, zkTransfer} b ← VerifyTx(Tx′ , L′ ) ∧ Tx ∈
/ L′
ans ← QueryLb (Q) return b ∧ (∃Tx ∈ L : Tx ̸= Tx′ ∧ Tx.nf = Tx′ .nf)
Azeroth Azeroth
b′ ← AO0 ,O1
(L0 , L1 , ans)
′
return b = b Fig. 5: The transaction non-malleability experiment (TR-NM)
Fig. 3: The ledger indistinguishability experiment (L-IND) Transaction Non-malleability. Intuitively, a transaction is
non-malleable if no new transaction is constructed differ-
ently from the previous transactions without knowing pri-
We say that Azeroth scheme is ledger indistinguishable if vate data (witness) such as secret keys. Even when an
L-IND
|AdvAzeroth,A − 1/2| ≤ negl(λ) for every A and adequate auditor tries to attack or an auditor’s secret key is ex-
security parameter λ. posed, this property should hold. We show an experiment
TR-NM
Azeroth.GA in fig. 5. Let AdvTR−NM
Azeroth,A (λ) be the advan-
tage of A winning the game TR-NM. The Azeroth satisfies
TR-UN
Azeroth.GA (λ) : the transaction non-malleability if for any PPT adversary A,
pp ← Setup(λ) we have that |AdvTR−NM
Azeroth,A (λ)| ≤ negl(λ).
Azeroth
L ← AO (pp)
n o
send recv
(pk , pk , aux), (pksend , pkrecv , aux) BAL
Azeroth.GA (λ) :
Azeroth
← AO (L) pp ← Setup(λ)
Azeroth
$
b ← {0, 1} L ← AO (pp)
Azeroth
Tx ← zkTransfer(pk send recv
, pk , aux) (Listcm , ENA, EOA) ← AO (L)
ENA pub priv pub priv
if b = 0 (v , vout , vout , vin , vin )
Tx′ ← zkTransfer(pksend , pkrecv , aux) ← Compute(L, Listcm , ENA, EOA)
else if b = 1 if vENA + vout
pub priv
+ vout pub
> vin priv
+ vin then return 1
Tx′ ← zkTransfer(pksend , pkrecv , aux) else return 0
b′ ← A(Tx, Tx′ , L)
return b = b′ Fig. 6: The balance experiment (BAL)
Fig. 4: The transaction unlinkability experiment (TR-UN) Balance. We say that Azeroth is balanced if and only if no
attacker can spend more than what she has or receives. Let
AdvBALAzeroth,A (λ) be the advantage of A winning the game
Transaction Unlinkability. Transaction unlinkability is de- BAL as described in fig. 6. For a negligible function negl(λ),
fined as an indistinguishability problem in which a PPT ad- the Azeroth is balanced if for any PPT adversary A, we have
versary A cannot distinguish the receiver’s information. Note that |AdvBALAzeroth,A (λ)| ≤ negl(λ).
that a transaction caller (sender) is always identifiable in an ex-
Auditability. If the auditor can always monitor the confi-
isting account-based blockchain model. Still, if the receiver’s
dential data of any user, we informally say that the scheme
information is unlinkable, it is guaranteed that the linkability
has auditability. More precisely, we define that Azeroth
information between the sender and the receiver is hidden. Be-
is auditable if there is no transaction in which the de-
cause the recipient information is hidden, the sender can create
crypted plaintext is different from commitment openings. Let
a transaction with himself as the recipient privately as well.
AdvAUDAzeroth,A (λ) be the advantage of A winning the game
We say that a transaction is unlinkable if it does not disclose
AUD as described in fig. 7. For a negligible function negl(λ),
the correlation between its sender and receiver. We describe an
the Azeroth is auditable if for any PPT adversary A, we have
experiment TR-UN as shown in fig. 4 where aux denotes the
TR-UN that |AdvAUDAzeroth,A (λ)| ≤ negl(λ).
remaining input of zkTransfer. Formally, let AdvAzeroth,A (λ)
TR-UN
be the advantage of A winning the game Azeroth.GA . Theorem 5.1: Let ΠAzeroth = (Setup, KeyGenAudit, Key-
Azeroth satisfies the transaction unlinkability if for any PPT GenUser, zkTransfer) be a Azeroth scheme in Figure 2.
adversary A, we have that |AdvTR -UN
Azeroth,A (λ)−1/2| ≤ negl(λ). ΠAzeroth satisfies ledger indistinguishability, transaction un-
8AUD a transaction, the mutual cooperation of auditors exceeding a
Azeroth.GA (λ) :
certain quorum is unconditionally required.
pp ← Setup(λ)
Azeroth
L ← AO (pp) VI. I MPLEMENTATION AND E XPERIMENT
O Azeroth
(Tx, aux) ← A (L) A. Implementation
Parse Tx = (cm, pct) Our Azeroth implementation coded in Python, C++, and
b ← VerifyTx(Tx, L)∧ Solidity languages consists of two parts; the client and the
VerifyCommit(cm, aux) ∧ aux ̸= Auditask (pct) smart contract. The client interacts with blockchain network
return b using Web3.py2 . To generate a zk-SNARK proof in Azeroth,
we use libsnark3 with Groth16 [19] and BN254 curve.
Fig. 7: The auditability experiment (AUD) PRF, COM, and CRH: We instantiate pseudorandom function
PRFk (x) where k is the seed and x is the input, using a
collision resistant hash function as follows.
linkability, transaction non-malleability, balance, and au-
PRFk (x) := CRH(k||x)
ditability.
Proof. The proofs for the above theorem are described in A commitment is also realized using a hash function CRH as
appendix A.1 A.2. follows.
D. Extension to threshold auditing COM(v, addr; o) := CRH(v||addr||o)
In a blockchain, the presence of a privileged entity(e.g., an A collision resistant hash function CRH is implemented
auditor) who can infringe on the privacy of all participants using zk-SNARK friendly hash algorithms such as MiMC7 [2]
is able to induce another baleful problem. One solution to and Poseidon [18] as well as a standard hash function
mitigate this problem is to use a threshold scheme. In a SHA256 [28].
threshold public-key encryption [13], the message is encrypted
Symmetric-key encryption: The symmetric-key encryption
using a public key, and the private key is shared among the
needs to be efficient in the proof generation for encryption.
participants. Several participants more than some threshold
Therefore, we implement an efficient stream cipher based
number t must cooperate in the decryption procedure to
on PRF using zk-SNARK friendly hash algorithms such as
decrypt an encrypted message.
MiMC7 and Poseidon as follows.
Our audit function can be extended to a threshold public-
key encryption using a standard secret sharing scheme. Briefly, SE.Enck (msg) → (r, sct)
let the secret key k be shared secret key among P1 , . . . , Pn $
r ← F; sct ← msg + PRFk (r)
using a polynomial f of degree t where t is a threshold,
meaning that the encryption tolerates the passive corruption of Return (r, sct)
t parties. In key generation phase, a trusted manager chooses
t + 1 random coefficients a0 , a1 , a2 , . . . , at+1 s.t. a0 = k and SE.Deck (r, sct) → msg
computes f (x) = a0 + a1 x + a2 x2 + · · · + at+1 xt+1 mod q msg ← sct − PRFk (r)
where q is a field prime number. The dealer sends a split
Return msg
secret key (skj = f (j)) to each Pj for all j. In the encryption
phase, all processes are the same as the standard ElGamal We also employ the CTR mode in case the message size is
encryption with pk = g k . Thus, the ciphertext consists of longer than the range of PRF.
(c0 , c1 ) = (Gr , pk r · m) for the message m. For threshold
Public-key encryption: We implement public-key encryption
decryption, an auditor sends a decryption request to other
with two recipients of a receiver and an auditor by extending
auditors. Upon receiving a decryption request on (c0 , c1 ), an
ElGamal encryption system such that the randomness can be
auditor Ai computes a decryption share csk 0
i
and sends it back
re-used. (Refer to the general treatment of randomness re-
to the requestor (or other auditors in case of group auditing).
use in multi-recipient encryption in [5].) For the performance
Upon receiving shares from a set of t + 1 parties, the auditors
gain, we also utilize the standard hybrid encryption; a random
can compute the message m.
key is encrypted by the public key encryption and the key is
The role of the trusted manager can be also distributed [32]
used to encrypt the message using a symmetric-key encryption
so that the participants jointly choose shares corresponding to
scheme. Given two key pairs (pk1 , sk1 ) and (pk2 , sk2 ) for
a (t, n)-secret sharing of a random value for a system without
ElGamal encryption, and the symmetric-key encryption SE,
the trusted manager. Each participant Pi arbitrary selects a
the resulting implementation of the public key encryption is
polynomial fi (x) of degree t over Zq and sends fi (j) to every
as follows.
participantPnPj . Next, Pj obtains its share aj = f (j) where
f (j) = k=1 fk (j). Note that the values (a1 , . . . , an ) make 2 https://github.com/ethereum/web3.py
up a (t, n)-threshold secret sharing. Thus, in order to audit 3 https://github.com/scipr-lab/libsnark
9is about 20x and 40x slower than MiMC7 and Poseidon in
PE.Encpk1 ,pk2 (msg) → pct, aux zk-SNARK. The verification time is almost independent of
$
k ← F; r ← F
$ the hash type. However, when each hash function is executed
c0 ← Gr ; c1 ← k · pk1r ; c2 ← k · pk2r ; c3 ← SE.Enck (msg)
natively, SHA256 shows the best performance as shown in
Figure 8 (d), which is similar to the gas consumption trend
pct ← (c0 , c1 , c2 , c3 ); aux ← (k, r)
shown in Figure 8 (e).
Return pct, aux
Figure 9 shows the key size. The proving key (ek) size is
proportional to the tree depth, whereas the verification key
PE.Decski (pct) → msg size remains 1KB.6 Poseidon has the smallest sizes of ek and
(c0 , c1 , c2 , c3 ) ← pct
constraints. Specifically, in depth 32, the ek sizes in Poseidon,
k ← ci /csk
0 ; msg ← SE.Deck (c3 )
i
MiMC7, and SHA256 are 3,341KB, 4,339KB, and 255,000KB
Return msg respectively. The circuit size of SHA256 is enormous due to
B. Experiment numerous bit operations, and Poseidon has 30% smaller size
than MiMC7’s. Figure 9 (c) shows that MiMC7 and Poseidon
In our experiment, the term cfgHash,Depth denotes a configu-
hashes consume relatively more gas than SHA256 since not
ration of Merkle hash tree depth and hash type in Azeroth.
only is SHA256 natively supported in Ethereum [9], but also
For instance, cfgMiMC7,32 means that we run Azeroth with
it shows better native performance as shown in Figure 8 (e).
MiMC7 [2] and its Merkle tree depth is 32. Table I(a) illus-
trates our system environments. For the overall performance The number of constraints. We measure the number of
evaluation, we execute all experiments on the machine Server constraints for each algorithm component as shown in Table II.
described in Table I(a) as a default machine. And the default The membership proof algorithm performs the hash execution
blockchain is the Ethereum testnet. The used proof system is as many as the tree depth. SE.Dec conducts the one hash
Gro16 [19]. computation and PE.Enc executes the group operation (i.e.,
exponentiation) three times internally. Note that in the table,
Overall performance. We show that the performance and the the number of constraints for CRH is obtained when a single
gas consumption in Azeroth with cfgMiMC7,32 as shown in input block is provided to the hash and the number of
Table I (b).4 The execution time 4.04s of Setup is composed of constraints is proportional to the number of input blocks.
the zk-SNARK key generation time 2.2s and the deployment
time 1.84s of the Azeroth’s smart contract to the blockchain. Performance analysis of smart contract.
Setup consumes a considerable amount of gas due to the We analyze the execution time and the gas consumption
initialization of Merkle Tree. In zkTransfer, the executed time in smart contract zkTransferSC . Table III shows the gas con-
is 4.38s including both the Client part and the Smart Contract sumption for each function in smart contract zkTransferSC .
part. The gas is mainly consumed to verify the SNARK proof In the smart contract, the most time-consuming functions are
and update the Merkle hash tree. Varying the hash function, the proof verification Πsnark .Verify and the Merkle hash tree
the further analysis of zkTransfer is described in the following update TreeUpdate. The gas consumption for TreeUpdate
experiments. depends on hash tree depth and hash type while Πsnark .Verify
remains constant.
zk-SNARK performance. We evaluate the performance of
Figure 10 represents the execution time of Πsnark .Verify
zk-SNARK used to execute zkTransfer on various systems
and TreeUpdate. The verification time is 11.9ms, and the
Server, System1 , · · · , System4 as described in Table I (b).
execution time of TreeUpdate is 12.8ms, 17.4ms, and 7.3ms
Table I (c) shows the setup time, the proving time, and the
on MiMC7, Poseidon, and SHA256 respectively.
verification time respectively on each system with cfgMiMC7,32 .
Although System3 has the lowest performance, still its proving Deployment to various blockchains. We execute Azeroth
time of 4.56s is practically acceptable. with cfgMiMC7,8 on various blockchains such as Ethereum [9],
Hyperledger Besu [22], and Klaytn [1] which support a smart
Hash type and tree depth. We evaluate Azeroth performance
contract. The gas consumption result is shown in table IV.
depending on hash tree depths and hash types as shown in
Figure 8 and Figure 9. Comparison with the other existing schemes. We com-
Figure 8 illustrates the execution time of zk-SNARK for pare the proposed scheme Azeroth with the other privacy-
MiMC7 [2], Poseidon [18]5 , and SHA256 [28] where the preserving transfer schemes such as Zeth [30], Block-
hash tree depth is 32. The SNARK key generation times maze [21], Zether [8], and PGC [12] in Table V. Our proposal
are 2.311s, 2.182s, and 53.393s respectively. The proving shows better performance than the existing schemes, even
times for MiMC7 and Poseidon are 0.901s and 0.582s respec- if Azeroth provides an additional function of auditability.
tively, while it takes 20.69 seconds with SHA256; SHA256 Zeth and Blockmaze are implemented with cfgMiMC7,32 and
4 The result includes the execution time until the task of receiving the receipt
cfgSHA256,8 respectively and the same configuration is applied
of the transaction.
to the proposed scheme for a fair comparison. The experiment
5 We utilize a well-optimized Poseidon smart contract from circomlib(https:
//github.com/iden3/circomlib/tree/feature/extend-poseidon). 6 We omit the graph of vk, since it is constant.
10TABLE I: Benchmark of Azeroth
(a) System specification
Machine OS CPU RAM
Server Ubuntu 20.04 Intel(R) Xeon Gold 6264R@3.10GHz 256GB
System1 macOS 11.2 M1@3.2GHz 8GB
System2 macOS 11.6 Intel(R) i7-8850H CPU @ 2.60GHz 32GB
System3 android 11 Exynos9820 8GB
System4 iOS 15.1 A12 Bionic 4GB
(b) Execution time and gas consumption of Azeroth with cfgMiMC7,32
Azeroth
Setup RegisterAuditor RegisterUser zkTransfer Audit
Time (s) 4.04 0.02 0.017 4.38 0.03
Gas 5,790,800 63,179 45,543 1,555,957 N/A
(c) Execution time of zk-SNARK in zkTransfer
Server System1 System2 System3 System4
Πsnark .Setup (s) 2.311 4.19 4.13 8.529 5.529
Πsnark .Prove (s) 0.901 2.581 2.77 4.557 3.15
Πsnark .Verify (s) 0.017 0.041 0.079 0.062 0.054
·10−2 ·10−4 ·104
60 40 2 4
30 3 3
40 1.9
20 2 2
20 1.8
10 1 1
0 0 1.7 0 0
MiMC7 Poseidon SHA256 MiMC7 Poseidon SHA256 MiMC7 Poseidon SHA256 MiMC7 Poseidon SHA256 MiMC7 Poseidon SHA256
(a) Πsnark .Setup (b) Πsnark .Prove (c) Πsnark .Verify (d) Native (e) Gas consumption
Fig. 8: Performance with 32 hash tree depth. (a)-(c): The execution time of zk-SNARK’s algorithms where the y axis is time(s).
(d): The native execution time of each hash algorithm written in C++ where the y axis is time(s). (e): The gas consumption
where the y axis denotes the gas consumption.
·105 ·106 ·106
4 2.5
MiMC7 MiMC7
4
Poseidon 3 Poseidon
2
SHA256 SHA256
2
1.5
2
1
1
0 0
8 16 32 64 8 16 32 64 8 16 32
(a) The proving key size(KB) (b) The number of constraints (c) Gas consumption
Fig. 9: Key size, constraints in circuits and gas consumption by varying hash tree depth and hash type
TABLE II: The number of constraints for each algorithm TABLE III: Gas cost for each function
component F Πsnark .Verify MiMC7 SHA256 Poseidon Etc
gas 402,922 23,405 1,506 32,252 42,143
Membership32 CRH(1) SE.Dec PE.Enc GroupOp
MiMC7 11,713 364 364 7,211 2,035
Poseidon 7,745 213 240 6,758 2,035
SHA256 1,465,473 25,725 45,794 83,294 2,035
is conducted on Server. Note that the proof generation time in
the table excludes the circuit loading time for a fair compari-
son, and the loading time is significantly long in Blockmaze.
11TABLE IV: Gas consumption on various blockchains with VII. C ONCLUSION
cfgMiMC7,32
In this paper, we propose an auditable privacy-preserving
Ethereum Besu Klaytn
digital asset transferring system called Azeroth which hides
Setup 3,778,604 4,382,410 4,845,674
the receiver, and the amount value to be transferred while
RegisterAuditor 63,179 66,115 68,891
the transferring correctness is guaranteed by a zero-knowledge
RegisterUser 45,543 55,215 56,967
proof. In addition, the proposed Azeroth supports an auditing
zkTransfer 854,110 1,773,406 951,220 functionality in which an authorized auditor can trace trans-
actions to comply an anti-money laundry law. Its security is
proven formally and it is implemented in various platforms
On the other hand, PGC [12] and Zether [8] use standard ElGa- including an Ethereum testnet blockchain. The experimental
mal encryption and NIZK to provide confidentiality instead of results show that the proposed Azeroth is efficient enough to
utilizing Merkle Tree. The performance results in these works be practically deployed.
exclude anonymity, which means that the anonymity set size
is 2. Note that the performance degrades as the anonymity set R EFERENCES
size increases in PGC and Zether, since the number of Elliptic [1] Klaytn position paper v2.1.0. https://www.klaytn.com/Klaytn
curve operations in the smart contract increases proportionally PositionPaper V2.1.0.pdf.
to the anonymity set size. [2] Martin R. Albrecht, Lorenzo Grassi, Christian Rechberger, Arnab Roy,
and Tyge Tiessen. Mimc: Efficient encryption and cryptographic hashing
In comparison with Zeth7 , we utilize ganache-cli8 as our with minimal multiplicative complexity. In ASIACRYPT, pages 191–219,
test network. Due to the circuit optimization of Azeroth, the 2016.
resulting circuit size is 4x smaller and the size of pp is [3] Roman Storm Alexey Pertsev, Roman Semenov. Tornado cash privacy
solution.
22x smaller than Zeth. In zkTransfer, Azeroth reduces the [4] Elli Androulaki, Jan Camenisch, Angelo De Caro, Maria Dubovitskaya,
execution time by 90% compared with Zeth’s Mix function. Kaoutar Elkhiyaoui, and Björn Tackmann. Privacy-preserving auditable
token payments in a permissioned blockchain system. page 255–267.
While BlockMaze9 has four transactions of Mint, Redeem, Association for Computing Machinery, 2020.
Send, Deposit, Azeroth provides the equivalent functionality [5] Mihir Bellare, Alexandra Boldyreva, Kaoru Kurosawa, and Jessica
using a single transaction zkTransfer. Note that it takes 20s Staddon. Multirecipient encryption schemes: How to save on bandwidth
and computation without sacrificing security. IEEE Trans. Inf. Theory,
to load the proving key in Blockmaze while it is only 1s in 53(11):3927–3943, 2007.
Azeroth. Hence Azeroth provides much better performance [6] Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green,
than Blockmaze in practice. Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized
anonymous payments from bitcoin. In 2014 IEEE Symposium on
Zether [8] and PGC [12] are stateful10 schemes using Security and Privacy, pages 459–474, 2014.
ElGamal encryption and NIZK. Due to the large difference [7] Sean Bowe, Alessandro Chiesa, Matthew Green, Ian Miers, Pratyush
Mishra, and Howard Wu. Zexe: Enabling decentralized private compu-
in structure, the comparison experiment compares the gas tation. pages 947–964, 2020.
cost and transaction size generated per transfer. Zether and [8] Benedikt Bünz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh.
PGC require 4.6 times and 5.3 times more gas than Azeroth Zether: Towards privacy in a smart contract world. In Joseph Bonneau
and Nadia Heninger, editors, Financial Cryptography and Data Security
respectively due to the Elliptic curve operations in the smart - 24th International Conference, pages 423–443, 2020.
contract. In terms of transaction size, Azeroth generates a [9] V. Buterin. Ethereum white paper: a next generation smart contract-
smaller transaction than Zether and PGC although Azeroth decentralized application platform. 2013.
provides higher anonymity than them. [10] Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter
Wuille, and Greg Maxwell. Bulletproofs: Short proofs for confidential
transactions and more. Cryptology ePrint Archive, Report 2017/1066,
2017. https://ia.cr/2017/1066.
7 https://github.com/clearmatics/zeth [11] Ethan Cecchetti, Fan Zhang, Yan Ji, Ahmed Kosba, Ari Juels, and Elaine
8 https://github.com/trufflesuite/ganache Shi. Solidus: Confidential distributed ledger transactions via pvorm.
9 https://github.com/Agzs/BlockMaze CCS ’17, page 701–717. Association for Computing Machinery, 2017.
10 The meaning is that the account is renewed immediately through one [12] Yu Chen, Xuecheng Ma, Cong Tang, and Man Ho Au. Pgc: Decentral-
transaction. ized confidential payment system with auditability. In Computer Security
– ESORICS 2020, pages 591–610, 2020.
[13] Yvo G Desmedt. Threshold cryptography. European Transactions on
Telecommunications, 5(4):449–458, 1994.
·10−2 [14] Benjamin E. Diamond. Many-out-of-many proofs and applications to
anonymous zether. In 2021 IEEE Symposium on Security and Privacy
Πsnark .Verify (SP), pages 1800–1817, 2021.
execution time[s]
3
TreeUpdate [15] E. Duffield and D. Diaz. “dash: A privacycentric cryptocurrency. https:
//github.com/dashpay/dash/wiki/Whitepaper, 2015.
2
[16] FATF. ”virtual assets and virtual asset service providers”. 2021.
[17] Prastudy Fauzi, Sarah Meiklejohn, Rebekah Mercer, and Claudio Or-
landi. Quisquis: A New Design for Anonymous Cryptocurrencies, pages
649–678. 11 2019.
1
[18] Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab
MiMC7 Poseidon SHA256 Roy, and Markus Schofnegger. Poseidon: A new hash function for
Zero-Knowledge proof systems. In 30th USENIX Security Symposium
Fig. 10: The execution time of functions in zkTransferSC (USENIX Security 21). USENIX Association, August 2021.
12You can also read
