Our current goal at Zcash Company is to increase the adoption and use of shielded addresses. This work is aimed at empowering everyone with economic freedom and opportunity through an open, permissionless and private payment system.
Zcash Company is building a reference light client wallet featuring a Sapling shielded address that can receive and send transactions. The objective of this project is to prove that shielded transactions can work on mobile devices and to build reusable solutions for functionality required to support shielded addresses.
Shielded transactions
Unlike other cryptocurrencies, Zcash has two types of addresses, transparent and shielded. This results in four basic types of transactions: transparent, shielding, deshielding and shielded. Shielded transactions, transactions from one shielded address to another, provide the most financial privacy by encrypting identifying data on the blockchain — such as the sender, recipient and transaction amount. These are our favorite transactions!
The Sapling network upgrade — released Oct. 28 — greatly improved the performance of creating these shielded transactions. Prior to this upgrade, shielded addresses were too computationally intensive to run on a mobile device, and could only be accessed via a full node client. Now that it is possible for mobile devices to support shielded addresses, we want to encourage the community to support them.
Reference wallet
Our reference wallet has a minimal number of features, and for a reason: It is not designed to be an end user application, but rather a resource. The reference wallet’s goal is to deliver a light client example that focuses on Sapling shielded interactions, leverages a zcashd full node as a server in a privacy-preserving way, and consumes the native rust implementation of Zcash wallet components. The reference wallet secondarily also serves as a design example of a single-currency application that only uses shielded addresses and leverages Zcash-specific features not commonly supported by multi-currency wallets.
Given the technical challenges associated with implementing shielded addresses, the most obvious but non-privacy preserving way for a light client to interact with a server is to give the server its viewing key. Then, the server can see which transactions belong to a particular shielded address and pass those relevant transactions along. However, we don’t find this to be a satisfying solution because it does not meet our privacy goals:
- The server should not learn which transactions belong to a given wallet.
- The server should not learn which transactions are being spent by a given wallet.
We are working on an initial solution that preserves the privacy of the light clients. For instance, we pre-process blockchain information so that a wallet can feasibly scan through it itself to look for incoming transactions, but more efficiently than if it had to download the raw blocks and try decrypting them in a naive way.
We have already started work on the reference wallet, and we plan to share our progress and all resulting design and code in a series of forthcoming blog posts.
Coming up
A series of blog posts will feature specific areas of the reference wallet work:
- Design: user experience priorities, user interface design, and styling choices
- Protocol: technical challenges, interacting components, and privacy goals
- Implementation: target devices, build methodology, and security measures
Come back to the Zcash blog or follow us on Twitter for further updates!
