Merge pull request #918 from daira/draft-hopwood-remove-consensus-dep…

…endency-on-note-encryption

[ZIP 2004] Remove the dependency of consensus on note encryption

zips/zip-2004.rst

@@ -0,0 +1,148 @@
+::
+
+  ZIP: 2004
+  Title: Remove the dependency of consensus on note encryption
+  Owners: Daira-Emma Hopwood <[email protected]>
+  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
+[#BCP14]_ 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. [#zip-0200]_
+
+The terms "Testnet" and "Mainnet" are to be interpreted as described in section
+3.12 of the Zcash Protocol Specification. [#protocol-networks]_
+
+The character § is used when referring to sections of the Zcash Protocol Specification
+[#protocol]_.
+
+
+Abstract
+========
+
+ZIP 213 [#zip-0213]_ 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 [#zip-0213]_,
+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 [#zip-0212]_ 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 protocol specification
+-------------------------------------
+
+In § 5.4.3 'Symmetric Encryption', rename :math:`Sym` to :math:`NoteSym` and
+add the following text:
+
+  Let :math:`\mathsf{NullSym.}\mathbf{K} := \mathbb{B}^{[256]}`,
+      :math:`\mathsf{NullSym.}\mathbf{P} := \mathbb{B^Y}^{\mathbb{N}}`, and
+      :math:`\mathsf{NullSym.}\mathbf{C} := \mathbb{B^Y}^{\mathbb{N}}`.
+
+  Let :math:`\mathsf{NullSym.Encrypt_K}(\mathsf{P}) := \mathsf{P} || [0x00]^{16}`.
+
+  Define :math:`\mathsf{NullSym.Decrypt_K}(\mathsf{C})` as follows:
+
+  * If the last 16 bytes of :math:`\mathsf{C}` are not :math:`[0x00]^{16}`,
+    return :math:`\bot`. Otherwise discard those 16 bytes and return the
+    remaining prefix of :math:`\mathsf{C}`.
+
+  Note: These definitions intentionally ignore the key; :math:`\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 :math:`\mathsf{Sym}` be the encryption scheme instantiated in
+  § 5.4.3 'Symmetric Encryption'.
+
+to
+
+  let :math:`\mathsf{NoteSym}` and :math:`\mathsf{NullSym}` be as
+  instantiated in § 5.4.3 'Symmetric Encryption'.
+
+  [Pre-NU7] let :math:`\mathsf{Sym}` be :math:`\mathsf{NoteSym}`.
+
+  [NU7 onward] if the note to be decrypted is in an output of a version 6
+  or later coinbase transaction, let :math:`\mathsf{Sym}` be
+  :math:`\mathsf{NullSym}`, otherwise let it be :math:`\mathsf{NoteSym}`.
+
+
+Deployment
+==========
+
+This ZIP is proposed to be deployed with the next transaction version change,
+which is assumed to be v6.
+
+
+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
+==========
+
+.. [#BCP14] `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" <https://www.rfc-editor.org/info/bcp14>`_
+.. [#protocol] `Zcash Protocol Specification, Version 2024.5.1 or later <protocol/protocol.pdf>`_
+.. [#protocol-networks] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks>`_
+.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.rst>`_
+.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
+.. [#zip-0213] `ZIP 213: Shielded Coinbase <zip-0213.rst>`_