ZIP: 2003
Title: Disallow version 4 transactions
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
Status: Draft
Category: Consensus
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/825>
Pull-Request: <https://github.com/zcash/zips/pull/927>

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 terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification. 3

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

Abstract

This proposal disallows v4 transactions. The v5 transaction format introduced in the NU5 network upgrade 7 does not support Sprout, and so this will have the effect of disabling 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 possibility of re-enabling v4 transactions, or of adding another facility to retrieve these funds if the Zcash community considers it worthwhile. However, since it is possible the ability to spend Sprout funds will never be re-enabled, holders of these funds should move them out of the Sprout pool without delay.

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 the complexity and attack surface of the Zcash protocol and of full node implementations. For instance, verification of transactions involving Sprout JoinSplit descriptions also has to be taken into account for potential denial-of-service attacks. 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, planned to be in advance of NU7, will also remove the only maintained software that still provides wallet functionality for Sprout, which would in any case make it impractical to move funds out of the Sprout pool. It is therefore necessary in any case to give holders of Sprout funds sufficient warning that they may be unable to retrieve them after zcashd deprecation.

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, change the applicability of the following rule:

  • [N​U​5 onward] The transaction version number MUST be 4 or 5. If the transaction version number is 4 then the version group ID MUST be 0x892F2085. If the transaction version number is 5 then the version group ID MUST be 0x26A7270A.

to be “[N​U​5 and NU6, pre-NU7]”, and ensure that the corresponding rule that applies from NU7 onward does not allow version 4.

These changes apply identically to Mainnet and Testnet.

Interaction with the proposed Network Sustainability Mechanism

For clarity, the Sprout chain value pool balance as of activation of this ZIP remains issued. If the Network Sustainability Mechanism ZIPs that affect issuance (8 and 9) are activated, then the Sprout chain value pool balance is, therefore, not considered part of the “Money Reserve” as a consequence of activating this ZIP.

Deployment

This ZIP is proposed to be deployed with NU7.

Reference implementation

TBD

Acknowledgements

The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP, 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

1 Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
2 Zcash Protocol Specification, Version 2024.5.1 [NU6] or later
3 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet
4 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1.2: Transaction Consensus Rules
5 ZIP 200: Network Upgrade Mechanism
6 ZIP 209: Prohibit Negative Shielded Chain Value Pool Balances
7 ZIP 225: Version 5 Transaction Format
8 Draft ZIP 233: Network Sustainability Mechanism: Burning
9 Draft ZIP 234: Network Sustainability Mechanism: Issuance Smoothing
10 Cultivating Sapling: Faster zk-SNARKs. Sean Bowe, September 13, 2017.