What is Sapling? Ƶero-2.0.1
Sapling is a network upgrade that introduces significant efficiency improvements for shielded transactions that will pave the way for broad mobile, exchange and vendor adoption of Zero shielded addresses. Sapling activated successfully on Zero’s Main Net - Block Height 492850.
- Performance for shielded addresses — Payments involving the new Sapling z-addresses can be constructed in as little as a few seconds and with only 40 megabytes of memory.
- Decoupled spend authority — Allows the hardware that constructs the zero-knowledge proof to be independent from the hardware that signs for the transaction.
- Improved keys — Full viewing keys allow owners of shielded addresses the ability to view incoming and outgoing transaction details without exposing their private spending key.
What’s New in Sapling?
Sapling represents over two years of protocol design and engineering with cryptographic breakthroughs that improve the performance and functionality of shielded (encrypted) transactions. Currently, most Zero transaction use transparent addresses that function in the same way as Bitcoin. This is largely due to the computational cost of proving that shielded transactions are valid. With Sapling, we move one (giant) step closer toward the ubiquity of shielded addresses.
Performance for Shielded Transactions
Prior to Sapling, if you had created a new z-address it would of looked something like this:
This is called a Sprout z-address because it was introduced in our original “Sprout” release of Zero. These addresses start with “zc”.
A z-address generated after Sapling activation will look something like this:
This new, shorter address starts with “zs” and is called a Sapling z-address. The legacy Sprout z-addresses will continue to function after Sapling activates, but will later be deprecated in favour of this new address.
Payments involving the new Sapling z-addresses can be constructed in as little as a few seconds and with only 40 megabytes of memory. Exchanges, mobile wallet providers, vendors and other 3rd parties will now be able to support shielded addresses.
The increased use of shielded addresses will improve the effective privacy for the entire network.
Decoupled Spend Authority
All shielded transactions require the creation of a zero-knowledge proof. Today, the hardware that constructs the proof must also be in possession of the spending key that authorises the transaction. Sapling changes this by allowing the hardware that constructs the proof to be independent from the hardware that signs for the transaction.
Enterprises can perform an inexpensive signature step in a trusted environment while allowing another computer, not trusted with the spending key, to construct the proof. Additionally, hardware wallets can support shielded addresses by allowing the connected computer to construct the proof without exposing the spending key to that machine.
Shielded addresses currently support an incoming viewing key. The holder of an incoming viewing key for a shielded address is able to see the value of all incoming transactions and the memo field. They cannot see the sending address and cannot spend the funds.
Sapling extends the capability of the viewing key to include visibility into outgoing transactions for a shielded address. Visibility includes the transaction value, memo field and target address.
Viewing keys allow owners of shielded addresses the ability to view transaction details without exposing their private spending key. Additionally, these can be shared with trusted third parties for compliance, auditing or for other reasons. Currently, only incoming transactions are view-able.
Efficient wallets with many z-addresses
Sapling z-addresses come with a feature which allows trillions of addresses to receive payments simultaneously with no additional performance cost on the receiving end. All of these addresses are unlinkable with each other.
Currently, exchanges and merchants must pay a computational penalty to receive on large numbers of z-addresses. The new Sapling z-addresses allow these businesses to create large numbers of distinct and unlinkable z-addresses for their clients.
How do I upgrade?
Update your Zero client to
2.0.1 or above.
Nodes which haven’t updated will exit with an error message requesting an update prior to the upgrade. The only way you will miss the upgrade is if you are running your own full node and manually configured your client to continue running the legacy software.
Users upgrading from earlier
1.x releases will need to download the additional Sapling parameters which are just under 800MB in size.