ZLiTE: Lightweight Clients for Shielded Zcash Transactions Using Trusted Execution

Abstract

Cryptocurrencies record transactions between parties in a blockchain maintained by a peer-to-peer network. In most cryptocurrencies, transactions explicitly identify the previous transaction providing the funds they are spending, revealing the amount and sender/recipient pseudonyms. This is a considerable privacy issue. Zerocash resolves this by using zero-knowledge proofs to hide both the source, destination and amount of the transacted funds. To receive payments in Zerocash, however, the recipient must scan the blockchain, testing if each transaction is destined for them. This is not practical for mobile and other bandwidth constrained devices. In this paper, we build ZLiTE, a system that can support the so called “light clients”, which can receive transactions aided by a server equipped with a Trusted Execution Environment. Even with the use of a TEE, this is not a trivial problem. First, we must ensure that server processing the blockchain does not leak sensitive information via side channels. Second, we need to design a bandwidth efficient mechanism for the client to keep an up-to-date version of the witness needed in order to spend the funds they previously received.

K. Wüst and S. Matetic—Equally contributing authors.

A Commitment Tree Updates

As described in Sect. 4.3, the commitment tree update $U_{ct}$ for the interval between time $t_1$ and $t_2$ consists of the right child of the path from $\mathsf {cm}_i$ to the root at time $t_2$, where $\mathsf {cm}_i$ is the rightmost non-empty leaf at time $t_1$.

Fig. 4.

At a time $t_1$ the note commitments Merkle tree is fully updated up to the latest block. A specific client holds a transaction with a note commitment c and knows the witness (i.e. the Merkle path) for it (d, N8, N5, and N3 nodes). After some time the blockchain is updated and new transactions added, thus, the Merkle Tree is updated accordingly ($t_2$). In order for the client to update the witness of her commitment c, she only needs the updated information from nodes (N11, N5, N3).

In Fig. 4, we show an example for the commitment tree update. In this example, the leaf f is the rightmost non-empty leaf at $t_1$, i.e. it corresponds to $\mathsf {cm}_i$, which means that the commitment tree update consists of the values of the nodes N11, N5, N3 at time $t_2$. In the example, the update is applied to the witness 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 $t_1$ and $t_2$, the values of N5 and N3 do, however, and thus the values are contained in the commitment tree update and updated from there.

We now show that given a witness at time $t_1$ for a commitment $\mathsf {cm}_j$ (where $j<i$, i.e. $\mathsf {cm}_j$ was added to the tree before $\mathsf {cm}_i$) and the commitment tree update $U_{ct}$, a client can compute the witness for $\mathsf {cm}_j$ at time $t_2$.

Let $A_{ji}$ be the lowest common ancestor node of $\mathsf {cm}_j$ and $\mathsf {cm}_i$ in the commitment tree, i.e. $\mathsf {cm}_j$ is in the left subtree of $A_{ji}$ and $\mathsf {cm}_i$ is in the right subtree. Any node in the left subtree of $A_{ji}$ remains unchanged between $t_1$ and $t_2$, i.e. any node from that subtree which is part of the witness for $\mathsf {cm}_j$ also remains unchanged. Since none of these nodes changes through the update process, updating the witness with $U_{ct}$ results in the correct values.

Similarly, any node of the witness for $\mathsf {cm}_j$ that is a left child of a node on the path from $A_{ji}$ to the root remains unchanged in the Merkle tree at time $t_2$, since all leafs in any left subtree are already fixed at time $t_1$ and thus all node values are already final. Since our update process does not change any left children in the tree, it also leaves these values unchanged and thus results in the correct values.

Finally, any node of the witness for $\mathsf {cm}_j$ that is a left child of a node on the path from $A_{ji}$ to the root may change in the Merkle tree at time $t_2$. Since $A_{ji}$ is an ancestor of $\mathsf {cm}_i$, any such node is included in $U_{ct}$, i.e. these nodes on the witness are updated in our update process. These values are therefore changed to the correct values from the note commitment tree at time $t_2$.

It follows that the witness at time $t_2$ for $\mathsf {cm}_j$ can be constructed correctly given the witness at time $t_1$ and the commitment tree update $U_{ct}$.