Broader ecosystem adoption of shielded addresses through the implementation of faster zk-SNARKs has been a highlight of the Sapling network upgrade. However, there are supplemental enhancements introduced for Sapling shielded addresses which further optimize efficiency and usability. The implementation of shielded HD wallets is one key feature.
HD Wallets for Bitcoin and Transparent Addresses
Before launch, the Zcash engineering team decided to keep a Bitcoin-like address functional in the protocol in order to allow for easier adoption by third-party services. These transparent addresses have been not only useful to avoid the resource requirements of legacy shielded addresses; they also support many advanced features already developed for Bitcoin.
Since the launch of Zcash, a number of services have implemented transparent addresses within their HD wallets, a feature initially proposed for Bitcoin in 2012. These HD wallets derive private keys and addresses from a seed, often a sufficiently randomized set of words. This means users can backup and fully restore an entire wallet with just a set of words.
Without this feature, users are required to do regular backups of the wallet as new addresses are created within it to protect against the loss of funds. Zcashd users should be familiar from the wallet backup documentation provided for legacy shielded addresses and transparent addresses.
HD Wallets for Sapling Addresses
Engineers at Zcash Company have developed an HD wallet specification for shielded addresses. ZIP 32 details how this is implemented.
The diagram above illustrates the basic implementation of Sapling’s shielded HD wallet. Access to the seed will allow that party to derive the entire tree of keys in the wallet. The seed first establishes a pair of master keys; this pair consists of a master spend key and a master view key. Access to the master spend key is equivalent to knowing the seed. For an introduction to view key concepts, read the post Selective Disclosure & Shielded Viewing Keys.
Accounts and Address Management
Next, the master keys establish distinct accounts with their own private key pairs (spend and view). Access to account keys restricts spending or viewing capabilities to only that account. The account’s view key derives the shielded address used for receiving payments. The Sapling protocol also allows deriving multiple addresses under the control of a single spend and view key pair. We’ll write more about this feature down the road.
As explained in the post Payment Contexts & Reusing Shielded Addresses, the properties of shielded addresses allow users to safely reuse them without risking transaction linkability. As a result, most individual users will not need more than one or two account keys. Businesses, on the other hand, might have distinct budgets with distinct managers and using these accounts can delineate authority over budgets while maintaining an executive authority over the master keys.
We’re looking forward to the Zcash ecosystem taking advantage of the new features introduced in Sapling in the coming months. If you have questions about supporting Zcash in your service, reach out to the ecosystem team or ask in the community.
