ZLiTE: Lightweight Clients for Shielded ZcashTransactions using Trusted Execution

Karl Wust1?, Sinisa Matetic1?, Moritz Schneider1, Ian Miers2, KariKostiainen1, and Srdjan Capkun1

1 Deparment of Computer Science, ETH Zurich2 Cornell Tech

Abstract. Cryptocurrencies record transactions between parties in ablockchain maintained by a peer-to-peer network. In most cryptocurren-cies, transactions explicitly identify the previous transaction providingthe funds they are spending, revealing the amount and sender/recipientpseudonyms. This is a considerable privacy issue. Zerocash resolves thisby using zero-knowledge proofs to hide both the source, destination andamount of the transacted funds. To receive payments in Zerocash, how-ever, the recipient must scan the blockchain, testing if each transaction isdestined for them. This is not practical for mobile and other bandwidthconstrained devices. In this paper, we build ZLiTE, a system that cansupport the so called “light clients”, which can receive transactions aidedby a server equipped with a Trusted Execution Environment. Even withthe use of a TEE, this is not a trivial problem. First, we must ensurethat server processing the blockchain does not leak sensitive informationvia side channels. Second, we need to design a bandwidth efficient mech-anism for the client to keep an up-to-date version of the witness neededin order to spend the funds they previously received.

1 Introduction

Decentralized cryptocurrencies offer the potential to revolutionize payments. Byproviding transparent means to audit transactions, they reduce the need to relyon trusted incumbents and allow new innovation on financial applications. Butthis same transparency renders nearly all cryptocurrencies completely unsuitedfor wide-scale adoption: all transaction are broadcast publicly in a manner thatcan be readily linked to real world identities [26,4], raising issues with governmentsurveillance, harassment and stalking, and the viability of business competitionwhen competitors can see all cash flow.

A variety of protocols have been proposed, such as Solidus [2,9], Cryptonote[37], Zerocoin [27] and Zerocash [5], that, with varying effectiveness [29,22,21],alleviate these issues. For example, in Cryptonote the destination address isalways a newly generated one-time public key derived from the receiver’s publickey and some randomness from the sender. Zerocoin functions as an overlayon Bitcoin, where users mint a zerocoin and issue a transaction to transfer the

? The first two authors contributed equally to this work.

funds to its commitment. The coin can be further spent by using zero-knowledgeproofs. The most promising of these protocols, Zerocash, removes all information,such as sender/recipient identity, value, and linkability through the use of a zero-knowledge proof that there exists some past transaction which gave the user thefunds they are spending. Zerocash is deployed in the cryptocurrency Zcash.

Payment Notification. Unlike in traditional means of payment, like credit cardsand cash payments, in nearly all cryptocurrencies, including Bitcoin, Ethereum,and Zcash, it is possible to send money to a recipient’s address without directinteraction or communication with the recipient. The recipient is paid, but onlylearns this next time when she is online. This raises the problem of paymentnotification, that is, the recipient must find out they were paid. Some cryptocur-rencies, like Ethereum, use an account model where there is a single, well-definedlocation for payments. As a result, the recipient and, more significantly, anyoneelse, can see when and for how much someone is paid. Other cryptocurrencies, in-cluding Bitcoin and Zerocash, eschew this approach for improved privacy, storingpayments individually as unspent transaction outputs (UTXOs) in unpredictablelocations. In such systems, there must be some mechanism for users to discovera UTXO belongs to them. The simplest way to do this is to scan the blockchainand check each transaction.

Payment notification is a particular problem for privacy-preserving systemslike Zcash. Transactions in Zcash, consist of an opaque commitment, a cipher-text, a serial number to prevent double spending, and a zero-knowledge proofof the transaction’s correctness and the existence of funds to spend. In partic-ular, there is no metadata to identify the sender or recipient. The only way fora client to identify if a payment is directed to them is by trial decryption ofthe ciphertext associated with a transaction: each transaction contains a cipher-text under the recipient’s public key. To monitor for payments, clients must,therefore, conduct a trial decryption for every transaction on the blockchain.While this is completely feasible for well-resourced clients, running on platformslike standard desktop PCs, it is not desirable, nor often feasible, for resource-constrained clients like mobile devices where both power and bandwidth aremajor constraints. In this paper, we focus on such resource-constrained clients.

Light Client Model. Several cryptocurrencies address this problem with a model,exemplified by Bitcoin’s Simplified Payment Verification (SPV) scheme [30],where “light clients” entrust a server (full node) to respond to queries aboutpayments to a given address. The SPV protocol reveals to the server which(pseudonymous) addresses belong to a client and thus links multiple addressestogether and potentially to real world identities, reducing user privacy. Directlyapplying the same model to Zcash is not possible without revealing the client’sdecryption key to the server so that it can perform the trial decryption fortransactions, and thus completely breaking the privacy properties of Zcash.

Another challenge for resource-constrained clients is that simply notifyingusers that they received funds is not sufficient to use them for new paymentsin Zcash. To spend funds sent to them in a previous transaction tx in block n,users must prove that there exists a path (called witness) w from the root of a

Merkle tree (called note commitment tree) to tx. Moreover, this information isnot static and it needs to be updated as new transactions are added to the tree.

Our Contribution. In this paper, we introduce ZLiTE, a system that enablesefficient privacy-preserving light clients for Zcash. Our approach follows the com-mon “light client and server” model, thus minimizing the client bandwidth andcomputation requirements by offloading processing to the server. To tackle theprivacy problem of client queries, we leverage trusted execution, namely IntelSGX [19], on the server. This approach allows the server to perform the trialdecryption for transactions without learning the client’s key.

Although this approach is conceptually simple, realizing it securely requiresovercoming technical challenges. First, external reads and writes from the SGXenclave to the blocks stored on the server or to response buffers can leak whichtransactions belong to the client. Second, SGX enclaves are susceptible to side-channel attacks [7,8,28,15,34,39] that can leak their internal memory access pat-terns. Secret-dependent code and data accesses can enable a malicious server toinfer the used client’s key. Third, our system also needs to ensure that the residingplatform cannot mount a combination of eclipse attacks [18,38] on the blockchainand replay client messages to identify queried transactions. And fourth, we needto efficiently provide the client with up-to-date Merkle tree witnesses needed tospend funds from a given transaction without leaking any private information.

To address these challenges, ZLiTE combines, in a novel way, a number ofknown techniques from private information retrieval and side-channel resilienttrusted execution, making the processing of client queries oblivious towards apowerful adversary controlling the supporting server. We also design a new com-mitment tree update mechanism that allows the client to obtain efficiently fromthe server all the needed information to spend the received funds.

Parallel Work. Finally, we note that, in parallel work, a similar solution has beensuggested for privacy protection in Bitcoin [25]. While our overall approach issimilar, the technical challenges that we address are specific to Zcash, and thusdifferent. We review such parallel work in more detail in Section 7.

2 Background

Transactions in Cryptocurrencies. Many cryptocurrencies operate in the socalled Unspent Transaction Output (UTXO) model. In this model, a transac-tion consists of a set of outputs, each with a numerical amount of money andan address, and a set of inputs each of which references the output of a previoustransaction. For a transaction to be valid, the following conditions have to bemet: (1) referenced outputs must exist, (2) inputs must be signed by the keyspecified in the referenced output address, (3) the

∑(output amounts) must be

≤ to the∑

(input amounts), and (4) referenced outputs must not be spent by aprevious transaction.

In Bitcoin, this is accomplished by directly identifying the referenced out-puts, checking that they are not referenced by any other transactions, and thenchecking the sum inputs and outputs. If a transaction validates, then the out-puts it references are removed from the UTXO set and the outputs it generates

added. Transactions in Bitcoin and most cryptocurrencies are validated via apeer-to-peer network and assembled into blocks (e.g., every 10 minutes), thatare broadcast to the network.

In Zcash there are two types of transactions: transparent and shielded trans-actions. The transparent kind is directly derived from Bitcoin and will not beconsidered for the rest of this paper.

Shielded transactions also take some inputs and create new outputs, butthe similarities end there. Outputs, also called notes, are created by so calledjoinsplits and are a commitment to an amount and the address it belongs to. Ajoinsplit takes a transparent input and up to two notes as input and creates onetransparent output and up to two notes as output. However this information isencrypted and can only be inspected by the receiver. Additionally a Merkle treeis constructed over all notes on the blockchain forming the note commitmenttree. A zero-knowledge proof forms the second part of the transaction and showsthat conditions (1)-(3) hold with respect to that Merkle tree root. Because the“outputs” that a shielded transaction spends are not revealed, they cannot beremoved from the UTXO set. Instead, a unique serial number, sometimes calleda nullifier, is produced by the transaction that ensures the referenced outputscannot be used again. This prevents double spending.

To perform operations in Zcash, each user has two keys associated to hisshielded address. First, the spending key that is used during the creation of azero-knowledge proof allowing the users to prove ownership of the received funds.Second, the viewing key that is used to decrypt the shielded transaction in theblocks and verify if each transaction belongs to the user.

Full Nodes and Light Clients. To interact with a cryptocurrency, one must have aclient. In both Bitcoin and Zcash, the default client is a full node, which receivesand validates every block, and contains the full state of the blockchain. Full nodesdo not need to trust other entities, provided the system functions as assumed,e.g., for Proof-of-Work systems the majority of the network’s computationalpower is honest and messages disseminate without problems. While full nodesoffer the best security and privacy, they entail considerable resource usage. Thecomputation and network resources necessary to maintain a full node are a majorimpediment and in some cases, e.g. mobile devices, simply prohibitive.

In contrast, lightweight clients are nodes that have smaller resource footprint.They were originally proposed for Bitcoin [30] as the Simplified Payment Veri-fications (SPV) scheme. In this proposal, clients store only the header of eachblock instead of the entire blockchain. This is sufficient to check the Proof-of-Work on each block and verify the presence of transactions by checking theirinclusion in the Merkle tree whose root is contained in the block header: clientsmust merely request both a transaction and the witness to its inclusion in theMerkle tree from a full node.

The reduced resource usage of SPV clients comes at a major cost: privacy. Asthe light client must request individual transactions from a full node, it revealswhich transactions and addresses belong to the requesting client. In Bitcoin, thisallows multiple addresses to be linked together. In Zcash, this effect is far more

pronounced since the client completely loses privacy: without such queries, noshielded transaction can be linked together, i.e., an adversary learns nothing.

ORAM. Encryption provides data confidentiality but access patterns can leakinformation possibly leading to reconstruction of the content itself. ObliviousRAM (ORAM) [14] is a popular scheme that hides access patterns and achievesfully oblivious data accesses. Most ORAM algorithms use randomized encryptionand shuffling techniques to build a fully oblivious database. Intuitively ORAMhides the address, access patterns, whether the same data access is repeated andthe type of operation, i.e. read or write. Note that ORAM operations still leaktiming information related to the frequency of access operations themselves.

3 Our Approach

3.1 Requirements

The main goal of this paper is to design a solution that enables privacy-preservinglight clients assisted by full-node servers for Zcash. More precisely, we specifythe following requirements for our solution:

R1 Privacy. ZCash light clients should be able to privately retrieve all transac-tion related data without revealing sensitive information (e.g., viewing key,transaction count, blocks containing transactions) to the server.

R2 Integrity. The server that is assisting the light client should not be able tosteal funds or make a client falsely accept a payment.

R3 Completeness. The retrieval of transactions should guarantee that the lightclient receives all data necessary for spending the funds they received.

R4 Performance. The solution should have minimal bandwidth and processingrequirement for the client. The server’s processing should be in the sameorder of magnitude as the normal full node operation.

3.2 Main Idea

Our main idea is to leverage commonly-available Trusted Execution Environ-ments (TEEs) and apply them to full nodes (servers) to enable privacy-preservinglight clients for Zcash. In particular, we use Intel’s SGX [19] which provides iso-lated execution of security-critical application code, called enclaves, such thatenclave data confidentiality and execution integrity remains protected from un-trusted software such as other applications, the OS, hypervisor. In SGX, theCPU enforces that untrusted software cannot access enclave memory. For spacereasons we omit details regarding Intel SGX. We refer readers unfamiliar withthe technology to a more detailed SGX introduction [12,20].

Similar to SPV in Bitcoin, we assume deployments where the light Zcashclients may be assisted by any number of servers (full nodes) that support TEEs.Some of the servers could be run by well-known companies as commercial serviceswhere light clients may have to pay a small fee for the service. Other servers couldbe run by private individuals, like members of the cryptocurrency community,as a free service. As in SPV, the light clients are free to choose which servers touse, if any. In this regard, our solution retains the decentralized nature of Zcash.

3.3 Controversy and Challenges

The use of TEEs is often controversial. TEEs rely on a trusted authority todesign a secure processor and issue some form of certification for it. Attestationsfrom the TEE can be forged either via exploiting design flaws or by corruptingthe provider and falsely claiming that an attestation came from a genuine pieceof hardware. The hardware and software are frequently closed source and themanufacturers opaque. These kind of trust assumptions are frequently an anath-ema, especially for cryptocurrencies. Moreover, usage of TEEs often seems likelazy systems design choice, since, if one assumes fully trusted TEEs (e.g., noneof the enclaves can be compromised, no side-channel leakage, full resilience onphysical attacks etc.), solving many problems becomes relatively easy.

However, current TEEs including SGX enclaves have noteworthy limitationssuch as side-channel attacks that leak information and no resilience to physicalattacks. We argue that the real research challenge is to leverage TEEs suchthat one can enable improved performance and privacy, but at the same timeaddress the limitations of TEEs such as side-channel leakage. In the (unlikely)case that TEEs are fully broken (e.g., a new severe processor vulnerability isdiscovered), the system should fail gracefully. One example of graceful failure isthat the affected clients’ privacy may be reduced, but integrity of the system ispreserved, i.e., in a cryptocurrency, no money is lost or stolen.

3.4 Adversary Model

In this paper, we consider the standard SGX adversary model where the at-tacker controls the OS and all other system software in the supporting server.In practice, the adversary could be a malicious administrator in a company thatprovides the full node service, an external attacker that has compromised theOS on the full node server, or a malicious individual operating a free server.

The adversary is able to perform digital side-channel attacks [7,8,15]. We as-sume that he is able to perfectly observe the enclave’s control flow with instruction-level granularity and its data accesses with byte-level granularity (best knownattacks are cache-line granularity). We overestimate the attacker capabilities, asall current side-channel attacks suffer from significant noise and cannot extractperfect traces in pratcice. By assuming such an adversary, we design our solutionfor future attacks that may be able to mount more precise side-channels. Ad-ditionally, the adversary has full control over the communication and can thusread, modify, block or delay all messages sent by the enclave.

The adversary cannot break the hardware protections of SGX along withcryptographic primitives such as encryption schemes and signatures. More specif-ically, the adversary cannot access SGX’s processor-specific keys and the en-clave’s encrypted runtime memory protected by the CPU.

Finally, even if full compromise of SGX is outside our adversary model, weconsider this possibility in our system design and discuss how our solution han-dles such worst case scenario in Section 5.3.

3.5 Strawman Solutions

We propose to leverage TEEs to protect the privacy of Zcash light clients. If clientprivacy relies on TEEs, it becomes natural to ask if one needs a complicatedsolution like Zcash and if anonymous payments can be realized through a muchsimpler solution using TEEs. To answer this question, we consider the limitationsof a few strawman solutions.

Our first strawman solution is that clients send all transactions in an en-crypted format to a set of authorized TEEs that process them privately. Such asolution would protect user privacy, but in case the enclaves get broken, the ad-versary can perform unlimited double spending on all users. Additionally, sucha solution would not be decentralized.

Our second strawman solution is to use pseudonymous transactions that arepublished to a permissionless ledger, similar to Bitcoin, and mix them in one ormore TEEs for improved privacy. Such a solution would prevent double spending,ensuring security for all users, even in the event that TEEs are broken. However,such a solution does not provide the same strong privacy protection, namelyunlinkability, as Zcash, since the anonymity set for a transaction output onlyconsists of the inputs of the mixed transaction. An adversary controlling theOS on the mixing service can further reduce anonymity by blocking incomingtransactions or injecting his own.

Our third strawman solution is to use the Zcash system, due to its strong pri-vacy properties, but allow light clients to offload their complete wallets to TEEsthat perform new payments and notification of received payments for them. Themain drawback of this approach is that if the TEE would be compromised, itwould incur direct monetary loss for a high number of clients.

Our goal is to design a solution that enables light clients for Zcash, andthus benefits from its sophisticated privacy protections, but avoids the abovediscussed limitations of simple TEE-based solutions.

3.6 Solution Overview

In our solution, when a light clients wants to be notified about received funds ormake new payments, she connects to one of the TEE-enabled full node servers,performs remote attestation of the server’s SGX enclave, and establishes a securechannel to it.

To enable payment notification, the client sends its viewing keys for theaddresses that she owns to the enclave and indicates from which point on (e.g.,the latest known block to the client) she wishes to update the light client’s state.The enclave obtains the data and information from the locally stored blockchainand processes it in a side-channel oblivious manner based on the client requestand sends back the response to the client.

To enable new payments by the client, the server also prepares a witness foreach new transaction of the client, as well as the note commitment tree updateand sends them to the client. Given this information, the client can efficientlycreate new transactions, and the associated zero-knowledge proofs, using thereceived funds, without revealing his spending key to the enclave.

ZCash Full Nodes

ZFN1

ZFN3

ZFNm

ZFN2

ZCash Lightweight Clients

ZLC2

ZLC1

ZLCn

……

…

…

secure Enclave E

Originalfull

node

BC

SpendingKey1,1…i

ViewingKey1,1…i

SpendingKey2,1…j

ViewingKey2,1…j

SpendingKeyn,1…k

ViewingKeyn,1…k

Fig. 1. System model. Lightweight clients request transaction verification and pay-ment issuing service from enclaves hosted on full Zcash nodes.

4 ZLiTE System Design

4.1 System Model and Operation Overview

Figure 1 presents our system model. The main stakeholders in the system areZcash Lightweight Clients ZLC1...ZLCn and Zcash Full Nodes ZFN1...ZFNm.A lightweight client ZLCa connects to any full node ZFNb that supports ourservice by hosting an enclave E when she wants to acquire information regardingtransactions and addresses that belong to the client or to issue new transactionstowards another Zcash client. ZLCa can own one or more addresses in her walletthat are also characterized by the SpendingKeya,1...c and the V iewingKeya,1...c.

Full nodes maintain the local version of the blockchain (BC) as usual, ap-pending each new confirmed block to the longest chain they have. The blockchainis maintained outside the secure environment, either on the disk or memory ofthe platform where the node resides. SGX enclave memory is limited (128MB)and is only suitable for smaller storage related to the currently executed task.

A client that wants to retrieve transactions, performs remote attestationfor the ZLiTE enclave and then establishes a secure connection (TLS), throughwhich she sends her viewing key and the height h of the last known block Bh. Theenclave then scans the blockchain for transactions for this viewing key startingfrom Bh and obliviously moves them to a temporary response ORAM (rORAM)to hide which transactions are of the client’s interest. Additionally, the ORAMstructure is obliviously serialized in the response buffer sent to the client.

Oblivious Scanning. All processes that rely on secret data, i.e. the clients viewingkey, must be performed in an oblivious fashion to prohibit any leakage of sensitiveinformation (see Section 5). Finding the transactions that match the clientsviewing key clearly depends on the client’s secrets. To make block scanningoblivious to a side-channel observer (see the adversary model in Section 3.4),processing of each transaction should produce the same side-channel trace. Anaive way to solve this is to do a fake copy of each non-matching transaction(viewing key does not result in a valid decryption) to the response buffer aswell. However, in that case the response buffer is as big as the scanned blocks(no performance improvement). To improve the performance we use a responseORAM to hold all relevant transactions of the current client. The rORAM allowsus to perform one ORAM operation per transaction while still hiding if this

operation is a write (relevant transaction) or a read (irrelevant transaction). Thisis achieved by constant-time branchless code using the cmov instruction [32]. Inconclusion, the enclave performs the following operations for each transaction:

(1) check if the viewing key manages to decrypt the transaction

(2) calculate the Merkle tree

(3) perform an ORAM operation (write or read transaction into the rORAMdepending on the outcome of (1))

Together with the transactions stored in the rORAM, ZLiTE delivers thecorresponding Merkle paths, all block headers since Bh, and the note commit-ment tree update for the requested interval (see Section 4.3). Below we firstdescribe the details of the ZLiTE operation and the retrieval of transactionsand then describe how a lightweight client using our system can create newshielded transaction.

4.2 Transaction Retrieval

The operation of the synchronization protocol (see Figure 2) works as follows:

Initialization and continuous operation.

(a) On initialization the Full Node ZFNj connects to the P2P network (a-1)and downloads the full ZCash blockchain (a-2). This locally stored blockchainis continuously updated as new blocks are received from the network.

(b) When the lightweight client is installed, it contains a checkpoint blockheader (this can be from a recent date or the genesis block). The client thendownloads all newer block headers from the P2P network and verifies them (i.e.the client checks the PoW and that their hash chain leads to the checkpoint). Allbut a small number of the most recent block headers (to handle shallow forks)can be deleted afterwards. This state is later updated during the synchronizationprocess that the client performs with a ZLiTE node in order to check for re-ceived transactions or before sending transactions (see below). This is similar tothe operation of existing lightweight clients for other blockchains (e.g. Bitcoin).

Synchronization of Transactions. Clients synchronize with a ZLiTE en-clave as follows:

(1) The ZCash Lightweight Client ZLCi performs attestation with the secureEnclave Ej residing on the full node ZFNj .

(2) If the attestation was successful, the ZCash Lightweight Client ZLCi estab-lishes a secure communication channel to the Enclave Ej using TLS.

(3) The Lightweight Client ZLCi sends a request containing its viewing key andthe number of the latest known block.

(4) The Enclave Ej creates a temporary in-memory response ORAM (rORAM)to store the transactions that will be sent to the client. Ej then scans its locallystored copy of the blockchain (BC) starting at the block number specified by theclient and decrypts the transactions with the specified viewing key. The decryp-tion will either result in garbage or in a valid plaintext transaction. If the decryp-tion is successful, Ej moves the transaction and the corresponding Merkle paths

establish secure communication2

information request for transaction retrieval3

authentication, TLS connection

5

Zcash Lightweight Client ZLCi ZCash Full Node ZFNj ZCash Full Node ZFNm…

attestation1

req(ViewingKey,h)

4

createresponse

ORAM (rORAM)

return request information about transactionsres(trxs, block_headers,

note_commitment_tree update)

6

Enclave Ej Enclave Em

P2P communication

update blockchainunchanged full node

normal operation

cont

inuo

usBC2

1a

acquire latest block header from the P2P ZCash network b

BCscan BC from hdecrypt with ViewingKeyif successful

-›(move to ORAM) rORAM

verify PoW and longest chainverify trx and Merkle paths

apply note commitment updates

Fig. 2. Synchronization. The lightweight client establishes a secure connection toan enclave on a full node and sends a request that contains its viewing key and latestknown block to perform the retrieval of all of her transaction information.

(for the transaction and for the note commitments) to the response ORAM,and if it is not successful, Ej performs a read operation, thereby performing themove obliviously using the cmov technique mentioned in Section 4.1 to replaceconditional statements.

(5) After the scanning operation has finished, the rORAM is serialized by mov-ing the entries to a fixed-size (dependent on the request, i.e., number of requestedblocks for update) response array that is then sent to the client. In addition, theresponse contains all of the block headers and the note commitment tree updates(see Section 4.3 for details).

(6) The ZCash Lightweight Client ZLCi verifies that the received block headershave a valid proof of work, create a chain to its latest known header and thatthe chain is the heaviest chain advertised in the P2P network. For every receivedtransaction, it checks whether the recomputed Merkle root, given the receivedpath, matches the corresponding block header. The client then updates the wit-nesses for all transactions with the received note commitment tree update andfinally deletes old block headers that no longer need to be stored.

4.3 Transaction Creation

The lightweight client receives all information necessary to create shielded Zcashtransactions from our system. Namely, for every output he wants to spend,he requires the witness (at the time of creating the new transaction) of thecorresponding note commitment (i.e., its Merkle path in the note commitmenttree).

These witnesses could be retrieved from a ZLiTE node at the time of spend-ing. However, this would require the node to retrieve the witness in an obliviousfashion on request, which becomes computationally expensive as the commit-ment tree gets larger. Instead, when scanning the chain for a client, we addition-ally supply the witness of a note at the block height where it was created (seeSection 4.2). When synchronizing, the client then also receives commitment treeupdates, which allow him to update witnesses for any previous note commitment.In this case, there is no need for oblivious computation since the update onlydepends on the block height and not on the transaction relevant to the client.

Given a note commitment tree at time t1 and a note commitment tree attime t2, to compute the commitment tree update, the enclave starts with anempty list Uct to store the update. Let cmi be the latest note commitment inthe tree at time t1, i.e., it is the rightmost non-empty leaf. Then, in the tree attime t2, for every node on the path from cmi to the root of the tree, add theright child to Uct. A client in the possession of a witness at time t1 for somenote, can then apply the update by replacing any node on the witness with thecorresponding node from Uct, if these two nodes have the same location in theMerkle tree. We present a proof in Appendix A that this construction results ina correct witness for the note commitment tree at time t2.

5 Security Analysis

In this Section, we provide an informal security analysis of ZLiTE. We firstdiscuss protection against information leakage, then discuss the completeness ofresponses, and finally consider the worst-case scenario, i.e. a full break of SGX.

5.1 Protection Against Information Leakage

Since ORAM reads and writes are indistinguishable, an adversary observingmemory access patterns is not able to determine which transactions were written.For ORAM accesses, when accessing the stash, indexes or the position map, everylocation is accessed to hide memory access patterns.

To protect against side channels (e.g. [8,28,15,34]), conditional statementsthat depend on transactions (e.g. during the process of moving transactions tothe response ORAM) are replaced using the cmov instruction. Since this resultsin the same control flow independent of the transaction, protection against leak-age even against an adversary that can observe the control flow with instructionlevel granularity is guaranteed. The cmov instruction has been previously usedto protect against side channels by Raccoon [32], Zerotrace [33] and also Oblivi-ate [3] in the context of providing secure ORAM access using SGX. This priorresearch shows that cmov can effectively protect against digital side channels.

Finally, the response size only depends on the number of scanned blocks, i.e.it is independent of how many (or if any) transactions are in the response, andthus does not leak any information about a client’s viewing key or transactions.

5.2 Integrity and Completeness

The ZLiTE node delivers the requested information along with all block infor-mation needed for simple payment verification. The client herself then verifiesthe block headers using the Merkle paths for her transactions. Similar to SPVin Bitcoin lightweight clients [30], this ensures that the server cannot make aclient falsely accept payments for which the transactions are not included in thechain. As the client can also check the proof of work and gossips with the P2Pnetwork to receive block headers, she can ensure that she receives informationfrom the longest chain. Thus, the server does not have stronger capabilities toeclipse a lightweight client than against a full node.

In contrast to standard SPV (as e.g. in Bitcoin [30]), where the client cannotbe sure to have received all of her transactions, the usage of a TEE makes surethat the received response contains all of her transactions for the scanned intervalgiven the ZLiTE node’s view of the blockchain.

5.3 Impact of Full SGX Compromise

While our adversary model considers side-channel attacks, we do not consider afull compromise of SGX, i.e., forged attestations, arbitrary control flow change orenclave secrets reading. However, recent research has shown that secrets can beread even from the quoting enclave allowing an adversary to extract attestationkeys [10,36] which makes it necessary to discuss such a worst-case scenario.

While it is obvious that the privacy provided by ZLiTE can no longer hold,if the adversary can read all secrets, or a client connects to a server that uses aforged attestation to impersonate an SGX enclave, such a breach cannot lead toloss of funds. In addition to the loss of privacy, a client also loses completeness,since a node may omit payments. However, because the client’s spending key isnever sent to a ZLiTE node and the client performs Simple Payment Verificationfor all of his transactions, a node is not able to steal coins from the client ormake him falsely accept a payment.

5.4 Trust Assumptions Comparison

In terms of security properties like double-spending protection, Zcash relies onthe following two trust assumptions: First, there must be an honest majority ofmining power. Second, the dissemination of messages broadcast to the peer-to-peer network must be sufficiently good, i.e., no eclipse attacks. ZLiTE relies onthe same trust assumptions as Zcash for its security properties.

For privacy, Zcash relies on securely-generated public parameters and hard-ness of numeric cryptographic assumptions. ZLiTE requires the same assump-tions and additional trust in TEEs.

6 Performance Evaluation

6.1 Implementation Details

Our implementation of ZLiTE is based on the protocol specification of Zcash.It consists of a blockchain parser, an oblivious Path ORAM implementation [35]and it makes use of some bundled cryptographic libraries. We support the currentZcash protocol specification including the ’overwinter’ protocol update.

The Trusted Computing Base (TCB) of our implementation can be splitup into a network part that is responsible for the communication with a client(around 1.5k LoC) and the blockchain relevant part (around 3.7k LoC). Ad-ditionally we use well reviewed crypto libraries like mbedTLS (53k LoC) andsmall libraries that provide crypto primitives: sha256 , blake2b, ripemd160,ChaCha20Poly1305 and ed25519 totaling to around 2.2k LoC. All of the in-cluded crypto primitives come from well reviewed sources. We will not go intodetails on the TLS library mbedTLS [23] and refer the interested reader to [40,24]for implementation details and performance results.

6.2 Performance

ZLiTE measurements were done on an i7-8700k processor with an SSD. Notethat all the reported timing results are without the additional TLS latency. Allmeasurements are according to the blockchain activity as of August 2018.

Lower Bound. Any node that wants to check for new transactions needs to parsethe new blocks and test its viewing keys against all transaction in the blocks.This is part of the Zcash specification and implies a lower bound for any fullnode. Testing viewing keys is computationally intensive because it involves akey exchange based on an elliptic curve for each transaction and viewing key.Our implementation manages to parse blocks of an entire day and test a singleviewing key against the transactions within 1.24s compared to fully obliviousoperation of ZLiTE which takes around 5s. We have to retrieve the Merklepaths and perform at least one ORAM operation per shielded transaction whilenon oblivious solutions can skip this for all non-relevant transactions.

Average Transaction Size. We measured the average number of joinsplits ina shielded transaction and show a histogram in Figure 3a. Around 95% of allshielded transactions only contain one joinsplit, thus they have at most 2 shieldedinputs and 2 shielded outputs. Every joinsplit occupies around 2KB of data. Wealso have to store the commitment tree update (see Appendix A) which is around1KB in size. The average shielded transaction thus requires an ORAM operationfor around 3KB of data. These measurements allow us to chose optimal ORAMblock size for our response ORAM of 3KB.

Latency. We measured the time required to fetch various amounts of blocks andshow a comparison between different expected client data per hour in Table 1.Note that the time per block rises when a client requests a longer time periodbecause the response ORAM is chosen accordingly and a big ORAM databaseleads to slower accesses. Additionally, slower responses are observed when theclient expects a lot of activity and requests a lot of client data.

0 1 2 3 4 5 6

Number of joinsplits

0%

25%

50%

75%

100%99%

94.7%

3.1% 0.8% 0.4%

(a) Joinsplit distribution in all shieldedtransactions up until block 350000.

1h 4h 12h 24h

Requested timespan

0s

1s

2s

3s

4s

5s

5%

25%

49%

21%

7%

29%

43%

20%

9%38%31%22%

14%53%13%19%

merkle tree calculation

ORAM operations

parsing

PoW verification

(b) Enclave latency for various requestsizes (with 24576B of client data/hour).

Fig. 3. Performance measurements.

Table 1. Total time for various request and response sizes. (100 runs)

Client data per hour

Time Blocks 6144B 12288B 24576B

24h 576 4187ms ±504ms 4382ms ±510ms 4967ms ±617ms12h 288 1875ms ±315ms 2122ms ±364ms 2317ms ±397ms4h 96 541ms ±75ms 583ms ±92ms 631ms ±104ms1h 24 123ms ±21ms 129ms ±21ms 130ms ±21ms

Figure 3b shows the latency for a request with 24576B of client data per hourand various requested time spans. The latency is further divided in the four maincontributors to the total: parsing the block, proof of work verification, ORAMoperations and generating the merkle tree. Note that the ORAM operations startto take the lions share of the latency as soon as longer time spans are requested.

Bandwidth. The required bandwidth can be split into a static part (not depen-dent on the number of blocks requested) and a dynamic part. The dynamic partis composed of the blockheader (1487B) and the private data per block that isused to return transactions to the client. For reasonable usage we estimate alightweight client to have (at most) one transaction every hour occupying 12kB.This results in 1024B of private data per block and the total dynamic bandwidthaccumulates to 2511B per block. The static part only consists of the commitmenttree update and is therefore 29 ∗ 32B = 928B large. A client that requests oneday of blocks from our system gets a response of 1.38MB.

Increased Blockchain Activity. As of August 2018 shielded transactions are notvery common on the Zcash blockchain (only 1.5 shielded txs/block). With singlesteps measurements we estimated ZLiTE performance with increased futureactivity. For 100 shielded transactions per block, a daily request would take112s, while with an hourly one the latency would shrink to around 750ms.

7 Related Work

Privacy for Lightweight Clients. Nakamoto introduced SPV in [30] in order toenable light clients for Bitcoin. The straight forward application of SPV trivially

sacrifices client privacy, which is why BIP 37 [17] introduced Bloom filters [6]to somewhat hide the client’s addresses in requests. Gervais et al. showed thatthis only marginally improves privacy [13]. Recently, Bitcoin protocol changeswere proposed where full nodes publish a filter for all transactions in a blockand clients download the block if the filter matches one of his addresses [31].

Most closely related to our work, Matetic et al. recently used SGX to provideprivacy to Bitcoin lightweight clients in a system called Bite [25]. While the mainchallenge was to efficiently protect privacy in a system that already provideslight clients, we tackle the problem of enabling light clients in a system thatprovides privacy, but until now does not support operation of light clients. Onenotable difference between [25] and our work is that in Zcash spending previouslyreceived funds requires the witness to the transaction’s inclusion in the Merkletree of all transactions, and therefore client must obtain, in efficient manner, anup-to-date version of this witness to spend the funds.

Zcash Scalable Clients. Several proposals aim to lower the resource requirementsfor clients in Zcash. While protocol upgrades [1] have reduced the computationalresources required to generate a transaction, they have not substantially changedthe bandwidth or verification requirements.

Bolt [16] proposes privacy preserving payment channels in which clients con-duct most transactions off chain in a fully private manner. However, the currentversion requires clients to either monitor the blockchain for channel closure usinga full-node, or entrust a third party to do so. While this does not violate privacy,failures by the third party can result in monetary loss. No such risk of theft existswith ZLiTE even if TEE integrity is violated. Moreover, Bolt requires payersto have an existing relationship with the recipient or an intermediate paymenthub. While promising, Bolt is not a full solution for bandwidth limited clients.

In [11], Chiesa et al. explore the use of probabilistic micro-payments as a wayof increasing throughput. In this setting, a sequence of, e.g., 100 micro-paymentsfor one cent, is approximated by paying $1 with probability 1

100 . Thus only 1100

of transactions are actually issued. However, this is only suitable for small andfrequently repeated payments. Moreover, it is unclear if it will reduce the totalvolume of transactions or simple free up capacity for even more transactions.

8 Conclusion

Zcash provides strong privacy for its users. Shielded transactions, however, re-quire clients to download and process every block which is impractical for de-vices like smartphones, and consequently no mobile client that supports shieldedtransactions exists in the market. In this paper we have developed a new solutionthat enables light clients to create and receive shielded payments by leveraginga supporting server and a commonly available TEE. Usage of trusted execution,obviously, changes the original trust model of Zcash, but we argue that such asolution strikes a balance between the best possible privacy and the range ofscenarios where Zcash can be used in practice. Thanks to our solution, develop-ment of mobile clients that support shielded transactions becomes possible andmore users can benefit from the sophisticated privacy protections of Zcash.

References

1. Sapling (2018), https://z.cash/upgrade/sapling.html2. Abraham, I., Malkhi, D., Nayak, K., Ren, L., Spiegelman, A.: Solidus: An incentive-

compatible cryptocurrency based on permissionless byzantine consensus. CoRR,abs/1612.02916 (2016)

3. Ahmad, A., Kim, K., Sarfaraz, M.I., Lee, B.: OBLIVIATE: A Data Oblivious FileSystem for Intel SGX (2018)

4. Androulaki, E., Karame, G.O., Roeschlin, M., Scherer, T., Capkun, S.: Evaluatinguser privacy in bitcoin. In: International Conference on Financial Cryptographyand Data Security. pp. 34–51. Springer (2013)

5. Ben-Sasson, E., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., Virza,M.: Zerocash: Decentralized anonymous payments from bitcoin. In: IEEE Sympo-sium on Security and Privacy. pp. 459–474. IEEE Computer Society (2014)

6. Bloom, B.H.: Space/time trade-offs in hash coding with allowable errors. Commu-nications of the ACM 13(7), 422–426 (1970)

7. Brasser, F., Capkun, S., Dmitrienko, A., Frassetto, T., Kostiainen, K., Muller, U.,Sadeghi, A.: DR.SGX: hardening SGX enclaves against cache attacks with datalocation randomization, http://arxiv.org/abs/1709.09917

8. Brasser, F., Muller, U., Dmitrienko, A., Kostiainen, K., Capkun, S., Sadeghi, A.R.:Software Grand Exposure: SGX Cache Attacks Are Practical. In: 11th USENIXWorkshop on Offensive Technologies,WOOT 2017. USENIX (2017)

9. Cecchetti, E., Zhang, F., Ji, Y., Kosba, A.E., Juels, A., Shi, E.: Solidus: Con-fidential distributed ledger transactions via PVORM. In: Proceedings of the2017 ACM SIGSAC Conference on Computer and Communications Security,CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017. pp. 701–717(2017). https://doi.org/10.1145/3133956.3134010, http://doi.acm.org/10.1145/3133956.3134010

10. Chen, G., Chen, S., Xiao, Y., Zhang, Y., Lin, Z., Lai, T.H.: Sgxpectre attacks:Leaking enclave secrets via speculative execution. arXiv preprint arXiv:1802.09085(2018)

11. Chiesa, A., Green, M., Liu, J., Miao, P., Miers, I., Mishra, P.: Decentralized anony-mous micropayments. In: Advances in Cryptology - EUROCRYPT 2017 - 36th An-nual International Conference on the Theory and Applications of CryptographicTechniques, Paris, France, April 30 - May 4, 2017, Proceedings, Part II. pp. 609–642 (2017). https://doi.org/10.1007/978-3-319-56614-6 21, https://doi.org/10.1007/978-3-319-56614-6_21

12. Costan, V., Devadas, S.: Intel SGX explained. In: Cryptology ePrint Archive (2016)13. Gervais, A., Capkun, S., Karame, G.O., Gruber, D.: On the privacy provisions

of bloom filters in lightweight bitcoin clients. In: Proceedings of the 30th AnnualComputer Security Applications Conference. pp. 326–335. ACM (2014)

14. Goldreich, O., Ostrovsky, R.: Software protection and simulation on oblivious rams.Journal of the ACM (JACM) 43(3) (1996)

15. Gotzfried, J., Eckert, M., Schinzel, S., Muller, T.: Cache attacks on intel sgx.In: Proceedings of the 10th European Workshop on Systems Security. p. 2. ACM(2017)

16. Green, M., Miers, I.: Bolt: Anonymous payment channels for decentralized curren-cies. In: Proceedings of the 2017 ACM SIGSAC Conference on Computer andCommunications Security, CCS 2017, Dallas, TX, USA, October 30 - Novem-ber 03, 2017. pp. 473–489 (2017). https://doi.org/10.1145/3133956.3134093, http://doi.acm.org/10.1145/3133956.3134093

17. Hearn, M., Corallo, M.: Connection bloom filtering. Bitcoin Improvement Pro-posal 37 (2012), https://github.com/bitcoin/bips/blob/master/bip-0037.

mediawiki

18. Heilman, E., Kendler, A., Zohar, A., Goldberg, S.: Eclipse attacks on bitcoin’speer-to-peer network. In: USENIX Security Symposium. pp. 129–144 (2015)

19. Intel: Intel Software Guard Extensions, https://software.intel.com/en-us/sgx

20. Intel: Software Guard Extensions Tutorial Series (2016),available at: https://software.intel.com/en-us/articles/

introducing-the-intel-software-guard-extensions-tutorial-series

21. Kappos, G., Yousaf, H., Maller, M., Meiklejohn, S.: An empirical analysis ofanonymity in zcash. In: 27th USENIX Security Symposium, USENIX Security2018, Baltimore, MD, USA, August 15-17, 2018. pp. 463–477 (2018), https:

//www.usenix.org/conference/usenixsecurity18/presentation/kappos

22. Kumar, A., Fischer, C., Tople, S., Saxena, P.: A traceability analysis of monero’sblockchain. In: ESORICS (2). Lecture Notes in Computer Science, vol. 10493, pp.153–173. Springer (2017)

23. Limited, A.: mbedTLS (formerly known as PolarSSL) (2015), https://tls.mbed.org/

24. Matetic, S., Schneider, M., Miller, A., Juels, A., Capkun, S.: Delegatee: Brokereddelegation using trusted execution environments. In: 27th USENIX Security Sym-posium (USENIX Security 18). USENIX Association (2018)

25. Matetic, S., Wust, K., Schneider, M., Kostiainen, K., Karame, G., Capkun, S.:BITE: Bitcoin Lightweight Client Privacy using Trusted Execution. IACR Cryp-tology ePrint Archive 2018, XXXX (2018)

26. Meiklejohn, S., Pomarole, M., Jordan, G., Levchenko, K., McCoy, D., Voelker,G.M., Savage, S.: A fistful of bitcoins: characterizing payments among men with nonames. In: Proceedings of the 2013 conference on Internet measurement conference.pp. 127–140. ACM (2013)

27. Miers, I., Garman, C., Green, M., Rubin, A.D.: Zerocoin: Anonymous distributede-cash from bitcoin. In: Security and Privacy (SP), 2013 IEEE Symposium on. pp.397–411. IEEE (2013)

28. Moghimi, A., Irazoqui, G., Eisenbarth, T.: Cachezoom: How sgx amplifies thepower of cache attacks. In: International Conference on Cryptographic Hardwareand Embedded Systems. Springer (2017)

29. Moser, M., Soska, K., Heilman, E., Lee, K., Heffan, H., Srivastava, S., Hogan, K.,Hennessey, J., Miller, A., Narayanan, A., Christin, N.: An empirical analysis oftraceability in the monero blockchain. PoPETs 2018(3), 143–163 (2018)

30. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)

31. Osuntokun, O., Akselrod, A., Posen, J.: Client side block filtering. Bitcoin Improve-ment Proposal 157 (2017), https://github.com/bitcoin/bips/blob/master/

bip-0157.mediawiki

32. Rane, A., Lin, C., Tiwari, M.: Raccoon: Closing digital side-channels through ob-fuscated execution. In: USENIX Security Symposium (2015)

33. Sasy, S., Gorbunov, S., Fletcher, C.: Zerotrace: Oblivious memory primitives fromintel sgx. In: Symposium on Network and Distributed System Security (NDSS)(2017)

34. Schwarz, M., Weiser, S., Gruss, D., Maurice, C., Mangard, S.: Mal-ware Guard Extension: Using SGX to Conceal Cache Attacks (2017),http://arxiv.org/abs/1702.08719

35. Stefanov, E., Van Dijk, M., Shi, E., Fletcher, C., Ren, L., Yu, X., Devadas, S.:Path oram: an extremely simple oblivious ram protocol. In: Proceedings of the2013 ACM SIGSAC conference on Computer & communications security. pp. 299–310. ACM (2013)

36. Van Bulck, J., Minkin, M., Weisse, O., Genkin, D., Kasikci, B., Piessens, F., Silber-stein, M., Wenisch, T.F., Yarom, Y., Strackx, R.: Foreshadow: Extracting the keysto the intel sgx kingdom with transient out-of-order execution. In: Proceedings ofthe 27th USENIX Security Symposium. USENIX Association (2018)

37. Van Saberhagen, N.: Cryptonote v 2.0 (2013), https://cryptonote.org/

whitepaper.pdf38. Wust, K., Gervais, A.: Ethereum eclipse attacks. Tech. rep., ETH Zurich (2016)39. Xu, Y., Cui, W., Peinado, M.: Controlled-channel attacks: Deterministic side chan-

nels for untrusted operating systems. In: Security and Privacy (SP), 2015 IEEESymposium on. pp. 640–656. IEEE (2015)

40. Zhang, F., Cecchetti, E., Croman, K., Juels, A., Shi, E.: Town Crier: An Authen-ticated Data Feed for Smart Contracts. In: CCS (2016)

A Commitment Tree Updates

As described in Section 4.3, the commitment tree update Uct for the intervalbetween time t1 and t2 consists of the right child of the path from cmi to theroot at time t2, where cmi is the rightmost non-empty leaf at time t1.

x

x

ba c d g l mi kh jf ne

N1

⊕

t1

X

Clients transaction

x

t2

a filled leaf before t1

filled leaf between t1 and t2b

N11[t2]

Uct

Witness

Note commitment update

N2

N4 N5 N7N6

N3

N15N14N13N12N11N10N9N8

N5[t2] N3[t2]

Witness(c)[t1] Witness(c)[t2]

d N8[t1] N5[t1] N3[t1] d N8[t1] N5[t2] N3[t2]

=

Fig. 4. At a time t1 the note commitments Merkle tree is fully updated up to the latestblock. A specific client holds a transaction with a note commitment c and knows thewitness (i.e. the Merkle path) for it (d, N8, N5, and N3 nodes). After some time theblockchain is updated and new transactions added, thus, the Merkle Tree is updatedaccordingly (t2). In order for the client to update the witness of her commitment c, sheonly needs the updated information from nodes (N11, N5, N3).

In Figure 4, we show an example for the commitment tree update. In thisexample, the leaf f is the rightmost non-empty leaf at t1, i.e. it corresponds to

cmi, which means that the commitment tree update consists of the values ofthe nodes N11, N5, N3 at time t2. In the example, the update is applied to thewitness of the leaf c (consisting of the nodes d, N8, N5, and N3). In this case,the values of the leaf d and node N8 do not change between time t1 and t2,the values of N5 and N3 do, however, and thus the values are contained in thecommitment tree update and updated from there.

We now show that given a witness at time t1 for a commitment cmj (wherej < i, i.e. cmj was added to the tree before cmi) and the commitment treeupdate Uct, a client can compute the witness for cmj at time t2.

Let Aji be the lowest common ancestor node of cmj and cmi in the commit-ment tree, i.e. cmj is in the left subtree of Aji and cmi is in the right subtree.Any node in the left subtree of Aji remains unchanged between t1 and t2, i.e.any node from that subtree which is part of the witness for cmj also remainsunchanged. Since none of these nodes changes through the update process, up-dating the witness with Uct results in the correct values.

Similarly, any node of the witness for cmj that is a left child of a node on thepath from Aji to the root remains unchanged in the Merkle tree at time t2, sinceall leafs in any left subtree are already fixed at time t1 and thus all node valuesare already final. Since our update process does not change any left children inthe tree, it also leaves these values unchanged and thus results in the correctvalues.

Finally, any node of the witness for cmj that is a left child of a node on thepath from Aji to the root may change in the Merkle tree at time t2. Since Aji

is an ancestor of cmi, any such node is included in Uct, i.e. these nodes on thewitness are updated in our update process. These values are therefore changedto the correct values from the note commitment tree at time t2.

It follows that the witness at time t2 for cmj can be constructed correctlygiven the witness at time t1 and the commitment tree update Uct.