This is the third installment in our series about the progress and development of the Zcash reference wallet; we invite you to look back at previous articles about our goals and what we’re building as well as user experience, interface and styling. This article builds on those topics, with a discussion about the protocol.
Note: the reference wallet, along with the work described in this post, is ongoing and subject to updates.
A reference implementation is concrete and functioning code, proving that a concept can work. Recall that Sapling made shielded transactions computationally feasible for low-capacity devices, such as smartphones.
Zcash shielded transactions can work on mobile devices. Our reference wallet and light client library proves that. Light clients are important, because users with low-capacity devices can maintain security assurance about the Zcash network and verify transactions.
Interacting components
The Zcash reference wallet is a light client. Light clients help users access and interact with a blockchain in a secure and decentralized way without having to sync the full blockchain. Light clients are serviced by a full node server that handles those services.
For security reasons, the light client holds the spending key and generating transactions. This ensures that the owner is in charge of the funds in the wallet, and the server cannot spend the funds without permission. The server is responsible for keeping up with the blockchain data, verifying that transactions happened safely, and servicing many light clients by providing them relevant information.
Higher standards for privacy
The typical server can see the details of shielded transactions. This information includes the sender, receiver, and amount. They use that to forward transactions relevant to their clients. For Zcash, this can be done by giving a server the viewing keys to the light clients’ addresses they service.
We want to prevent servers from learning what and how a light client spends or receives funds, to protect the privacy of our users. So, we are working on an alternative solution.
The first version of the reference wallet will not meet these goals, since the server will know which transactions are being spent by a given light client. But until they are spent the server will not know which transactions are received by a particular light client.
Preserving inbound privacy
Our design pre-processes blocks on the blockchain so that a light client can then scan through all the information itself. This is tricky since the reference wallet only uses shielded addresses. Since every shielded transaction is encrypted, light clients need to try decrypting every one on the network. If they do not, they might not see that a transaction has sent successfully or miss detecting new incoming transactions.
This is bandwidth-intensive. To optimize the performance, we:
- pass along only sapling shielded transactions
- scan blocks only after sapling activation
- download the transaction memo field on demand
The memo field is ~70% of a Zcash block. Shielded transactions pad the memo field to reduce distinctive features that could be used to identify them, even if the memo field is not used. Zcash blocks can be trial decrypted the rest of the block to find out the sender, receiver, and amount without decrypting the memo field. To achieve a 70% improvement in bandwidth, we decided to have light clients only decrypt the non-memo parts of a shielded address at first. This makes memo fields second-class citizens, and light clients will reveal which transactions are of interest if they request a specific transaction’s memo.
This is our solution for now. We plan to validate this approach and exploring other approaches in order to improve the user experience and in particular to make sure that using the memo field is useful and secure.
For further information, check out the protocol specification, client side code, and server side code.
Warning: it’s a work in progress so the code is unstable. We do not recommend builds off of it.
What’s next?
We will continue to share our progress in these upcoming posts:
- Development: build methodology and target devices.
- Future work: what’s next for the reference wallet.
Subscribe to the Zcash blog for further updates and other company news.