Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 1 when, and only when, it appears in all capitals.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 5

The character § is used when referring to sections of the Zcash Protocol Specification. 2

The terms "Mainnet" and "Testnet" are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. 3

Abstract

This proposal disallows all v4 transactions from NU7 onward. It therefore affects every workflow that creates v4 transactions, not only workflows involving Sprout. Neither the v5 transaction format 7 introduced in the NU5 network upgrade, nor the v6 format 8 introduced in NU6.3, supports Sprout. Because Sprout transfers can only be represented in v4 transactions, this proposal also disables the ability to spend Sprout funds.

It is not proposed in this ZIP to unissue, burn, or otherwise make Sprout funds permanently unavailable. This leaves open the theoretical possibility of re-enabling v4 transactions, or of adding another facility to retrieve these funds if the Zcash community considers it worthwhile. However, the ability to spend Sprout funds may never be re-enabled.

Motivation

Zcash is an extremely complex protocol. Some of that complexity comes from functionality that is now obsolete.

The Sprout shielded protocol was the first large-scale deployment of general-purpose zero-knowledge proofs, but suffered from long proving times and high memory requirements that limited its practicality. Its successors, the Sapling and Orchard shielded protocols, made substantial optimizations 10 and added new functionality such as viewing keys and diversified addresses. As a result, Sprout is essentially unused at this point.

In the Sapling network upgrade, the proving system and the pairing-friendly curves used for Sprout were changed to be the same as for the Sapling shielded protocol, i.e. Groth16 and BLS12-381. So that part of the attack surface is shared between Sprout and Sapling. The magnitude of potential balance violation due to any weakness in Sprout’s cryptography is also limited by the “turnstile” mechanism defined in ZIP 209 6.

Nevertheless, the parts of Sprout that are not shared with Sapling, such as the JoinSplit circuit and the handling of Sprout nullifiers and note commitments, still impose a substantial burden on live transaction-acceptance paths before NU7. For instance, verification of transactions involving Sprout JoinSplit descriptions has to be taken into account for denial-of-service attacks against mempool and new- block processing. Because of Sprout’s lack of use, there is little incentive for node implementations to optimize its verification, which may lead to such attacks imposing greater cost than they otherwise would.

The deprecation of zcashd, just prior to the NU6.3 upgrade, also removed the only maintained software that still provided wallet functionality for Sprout. Although the consensus rules still permit moving Sprout funds before NU7, this was and is another reason to give holders sufficient warning of difficulty in retrieving them.

Privacy Implications

Moving value out of the Sprout pool changes its publicly visible chain value pool balance through the vpub_old and vpub_new fields 6. The amount moved by a transaction is therefore visible. A short or poorly coordinated exit period could also make transaction timing and distinctive amounts easier to correlate with particular holders.

Disallowing v4 transactions does not itself disclose additional information about notes left in Sprout, but it prevents those notes from being spent unless a future consensus change restores a mechanism for doing so.

Requirements

It must become possible to remove the complexity and attack surface of Sprout from Zcash specifications and node implementations.

Specification

In § 7.1.2 ‘Transaction Consensus Rules’ 4 (as of NU6.3), change:

> * [NU6.3 onward] The transaction version number MUST be 4 or 5 or 6.

to

> * [NU6.3 only, pre-NU7] The transaction version number MUST be 4 or 5 or 6. > * [NU7 onward] The transaction version number MUST be 5 or 6.

These changes apply identically to Mainnet and Testnet.

Deployment

This ZIP is proposed to be deployed with NU7.

Reference implementation

• Zebra: 11
• Zakura: 12

Acknowledgements

The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP; Conrado Gouvêa for pointing out the need to update it to take into account changes in NU6.3 and NU7; and everyone else whose work made it feasible to deprecate Sprout. Particular credit goes to the four people who were put under a unique kind of stress during Sapling’s development: Ariel Gabizon, Sean Bowe, Nathan Wilcox, and Zooko Wilcox.

References