ZIP: 2004
Title: Remove the dependency of consensus on note encryption
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
Status: Draft
Category: Consensus
Created: 2024-10-22
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/917>
Pull-Request: <https://github.com/zcash/zips/pull/918>

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. 4

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

ZIP 213 6 added the ability for coinbase outputs to be shielded. An unfortunate side effect of this was to make consensus dependent on the details of note encryption. This has unnecessarily complicated the specification and implementation of consensus rules.

This proposal disentangles note encryption from consensus, by instead requiring coinbase outputs for v6 and later transaction versions to be unencrypted. The disentanglement will be complete once earlier transaction versions are no longer allowed on the network, which is likely to happen in some later upgrade.

Motivation

In the original design of Zcash, the consensus protocol was carefully isolated from the details of note encryption. This property, which was preserved through the Overwinter, Sapling, and Blossom upgrades, reduces the complexity and attack surface of the consensus protocol. It also potentially allows changes to note encryption to be made outside network upgrades.

A dependency on note encryption crept into the consensus protocol as a result of the changes to support shielded coinbase outputs in ZIP 213 6, deployed in the Heartwood network upgrade. These changes added the requirement that it must be possible to decrypt Sapling and Orchard outputs in coinbase transactions using a sequence of 32 zero bytes as the outgoing viewing key.

The complexity impact of this change was overlooked. This became apparent during the design of ZIP 212 5 for the Heartwood network upgrade. In fact for a time there were separate and slightly diverging implementations of note decryption for the consensus checks in zcashd, and in librustzcash. This could have led to a chain fork between zcashd and zebrad before the implementations were reconciled.

This ZIP restores the originally intended design property.

Requirements

The consensus rule change specified in this ZIP must, from transaction version 6 onward, make the implementation and specification of shielded coinbase outputs independent of note encryption.

Specification

Changes to the Zcash Protocol Specification

In § 5.4.3 'Symmetric Encryption', rename \(Sym\) to \(NoteSym\) and add the following text:

Let \(\mathsf{NullSym.}\mathbf{K} := \mathbb{B}^{[256]}\!\) , \(\mathsf{NullSym.}\mathbf{P} := \mathbb{B^Y}^{\mathbb{N}}\!\) , and \(\mathsf{NullSym.}\mathbf{C} := \mathbb{B^Y}^{\mathbb{N}}\!\) .

Let \(\mathsf{NullSym.Encrypt_K}(\mathsf{P}) := \mathsf{P} \,||\, [0x00]^{16}\!\) .

Define \(\mathsf{NullSym.Decrypt_K}(\mathsf{C})\) as follows:

  • If the last 16 bytes of \(\mathsf{C}\) are not \([0x00]^{16}\!\) , return \(\bot\!\) . Otherwise discard those 16 bytes and return the remaining prefix of \(\mathsf{C}\!\) .

Note: These definitions intentionally ignore the key; \(\mathsf{NullSym}\) is not a secure authenticated encryption scheme. It MUST be used only for notes in shielded coinbase outputs, which are intended to be visible as cleartext.

In § 4.20 'In-band secret distribution (Sapling and Orchard)', change:

let \(\mathsf{Sym}\) be the encryption scheme instantiated in § 5.4.3 'Symmetric Encryption'.

to

let \(\mathsf{NoteSym}\) and \(\mathsf{NullSym}\) be as instantiated in § 5.4.3 'Symmetric Encryption'.

[Pre-NU7] let \(\mathsf{Sym}\) be \(\mathsf{NoteSym}\!\) .

[NU7 onward] if the note to be decrypted is in an output of a version 6 or later coinbase transaction, let \(\mathsf{Sym}\) be \(\mathsf{NullSym}\!\) , otherwise let it be \(\mathsf{NoteSym}\!\) .

These changes apply identically to Mainnet and Testnet.

TODO: specify the handling of the ephemeralKey field.

Deployment

This ZIP is proposed to be deployed with the next transaction version change, which is assumed to be v6. 7

Reference implementation

TBD.

Acknowledgements

The author would like to thank Jack Grigg and Kris Nuttycombe for discussions leading to the submission of this ZIP.

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 or later
3 Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet
4 ZIP 200: Network Upgrade Mechanism
5 ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext
6 ZIP 213: Shielded Coinbase
7 ZIP 230: Version 6 Transaction Format