zips/zip-0224.rst

::

  ZIP: 224
  Title: Orchard Shielded Protocol
  Owners: Daira Hopwood <daira@electriccoin.co>
          Jack Grigg <jack@electriccoin.co>
          Sean Bowe <sean@electriccoin.co>
          Kris Nuttycombe <kris@electriccoin.co>
          Ying Tong Lai <yingtong@electriccoin.co>
  Status: Draft
  Category: Consensus
  Discussions-To: <https://github.com/zcash/zips/issues/435>


Abstract
========

This document proposes the Orchard shielded protocol, which defines a new shielded pool
with spending keys and payment addresses that are amenable to future scalability
improvements.


Motivation
==========

TBD


Specification
=============

The Orchard protocol is specified as an update to the Zcash Protocol Specification
[#orchard-spec]_. Given that it largely follows the design of the Sapling protocol, we
provide here a list of differences, with references to their normative specifications
and associated design rationale.

Curves
------

The Orchard protocol uses the Pallas / Vesta curve cycle, in place of BLS12-381 and its
embedded curve Jubjub:

- Pallas is used as the "application curve", on which the Orchard protocol itself is
  implemented (c/f Jubjub).
- Vesta is used as the "circuit curve"; its scalar field (being the base field of Pallas)
  is the "word" type over which the circuit is implemented (c/f BLS12-381).

We use the "simplified SWU" algorithm to define an infallible :math:`\mathsf{GroupHash}`,
instead of the fallible BLAKE2s-based mechanism used for Sapling. It is intended to follow
(version 10 of) the IETF hash-to-curve Internet Draft [#ietf-hash-to-curve]_ (but the
protocol specification takes precedence in the case of any discrepancy).

The presence of the curve cycle is an explicit design choice. This ZIP only uses half of
the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be
leveraged by future ZIPs.

- Curve specifications: [#spec-pasta]_
- :math:`\mathsf{GroupHash}`: [#spec-pasta-grouphash]_
- Supporting evidence: [#pasta-evidence]_

Proving system
--------------

Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), instead
of Groth16 and R1CS.

This ZIP does not make use of Halo 2's support for recursive proofs, but this is expected
to be leveraged by future ZIPs.

- Halo 2 protocol description: TODO
- UltraPLONK Arithmetization: [#concepts-upa]_
- Halo 2 explanation and design rationale: [#design-halo2]_

Circuit
-------

Orchard uses a single circuit for both spends and outputs, similar to Sprout. An "action"
contains both a single (possibly dummy) note being spent, and a single (possibly dummy)
note being created.

An Orchard transaction contains a "bundle" of actions, and a single Halo 2 proof that
covers all of the actions in the bundle.

- Action description: [#spec-actions]_
- Circuit statement: [#spec-action-statement]_
- Design rationale: [#design-actions]_

Commitments
-----------

The Orchard protocol has equivalent commitment schemes to Sapling. For non-homomorphic
commitments, Orchard uses the UPA-efficient Sinsemilla in place of Bowe--Hopwood Pedersen
hashes.

- Sinsemilla hash function: [#spec-sinsemilla-hash]_
- Sinsemilla commitments: [#spec-sinsemilla-comm]_
- Design rationale: [#design-commitments]_

Commitment tree
---------------

Orchard uses an identical commitment tree structure to Sapling, except that we instantiate
it with Sinsemilla instead of a Bowe-Hopwood Pedersen hash.

- Design rationale and considered alternatives: [#design-tree]_

Keys and addresses
------------------

Orchard keys and payment addresses are structurally similar to Sapling, with the following
changes:

- The proof authorizing key is removed, and :math:`\mathsf{nk}` is now a field element.
- :math:`\mathsf{ivk}` is computed as a Sinsemilla commitment instead of a BLAKE2s output.
- :math:`\mathsf{ovk}` is derived from :math:`\mathsf{fvk}`, instead of being a component
  of the spending key.
- All diversifiers now result in valid payment addresses.

Keys and addresses are encoded using Bech32. Orchard addresses used with the Zcash mainnet
have the prefix "zo" (compared to "zc" for Sprout and "zs" for Sapling).

Orchard keys may be derived in a hierarchical deterministic (HD) manner. We do not adapt
the Sapling HD mechanism from ZIP 32  to Orchard; instead, we define a hardened-only
derivation mechanism (similar to Sprout).

- Key components diagram: [#spec-addrs-keys]_
- Key components specification: [#spec-keys]_
- Encodings and HRPs: [#spec-encoding-addr]_ [#spec-encoding-ivk]_ [#spec-encoding-fvk]_
  [#spec-encoding-sk]_
- HD key derivation specification: [#zip-0032]_
- Design rationale: [#design-keys]_

Notes
-----

Orchard notes have the structure :math:`(addr, v, \rho, \psi, \mathsf{rcm}).` :math:`\rho`
is set to the nullifier of the spent note in the same action, which ensures it is unique.
:math:`\psi` and :math:`\mathsf{rcm}` are derived from a random seed (as with Sapling
after ZIP 212 [#zip-0212]_).

- Orchard notes: [#spec-notes]_

Nullifiers
----------

Nullifiers for Orchard notes are computed as:

:math:`\mathsf{nf} = [F_{\mathsf{nk}}(\rho) + \psi \pmod{p}] \mathcal{G} + \mathsf{cm}`

where :math:`F` is instantiated with Poseidon, and :math:`\mathcal{G}` is a fixed
independent base.

- Poseidon: TODO
- Design rationale and considered alternatives: [#design-nullifiers]_

Signatures
----------

Orchard uses RedPallas (RedDSA instantiated with the Pallas curve) as its signature scheme
in place of Sapling's RedJubjub (RedDSA instantiated with the Jubjub curve).

- RedPallas: [#spec-redpallas]_


Additional Rationale
====================

The primary motivator for proposing a new shielded protocol and pool is the need to
migrate spend authority to a recursion-friendly curve. Spend authority in the Sapling
shielded pool is rooted in the Jubjub curve, but there is no known way to construct an
efficient curve cycle (or path to one) from either Jubjub or BLS12-381.

Despite having recursion-friendliness as a design goal, we do not propose a recursive
protocol in this ZIP. Deploying an entire scaling solution in a single upgrade would be a
risky endeavour with a lot of moving parts. By focusing just on the components that enable
a recursive protocol (namely the curve cycle and the proving system), we can start the
migration of value to a scalable protocol before actually deploying the scalable protocol
itself.

The remainder of the changes we make relative to Sapling are motivated by simplifying the
Sapling protocol (and fixing deficiencies), and using protocol primitives that are more
efficient in the UltraPLONK arithmetization.


Security and Privacy Considerations
===================================

This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports
spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an
Orchard-specific :math:`\mathsf{valueBalance}` transaction field. This has the following
considerations:

- The Orchard pool forms a separate anonymity set from the Sprout and Sapling pools. The
  new pool will start with zero notes (as Sapling did at its deployment), but transactions
  within Orchard will increase the size of the anonymity set more rapidly than Sapling,
  due to the arity-hiding nature of Orchard actions.
- The "transparent turnstile" created by the :math:`\mathsf{valueBalance}` field, combined
  with the consensus checks that each pool's balance cannot be negative, together enforce
  that any potential counterfeiting bugs in the Orchard protocol or implementation are
  contained within the Orchard pool, and similarly any potential counterfeiting bugs in
  existing shielded pools cannot cause inflation of the Orchard pool.
- Spending funds residing in the Orchard pool to a non-Orchard address will reveal the
  value of the transaction. This is a necessary side-effect of the transparent turnstile,
  but can be mitigated by migrating the majority of shielded activity to the Orchard pool
  and making these transactions a minority. Wallets should convey within their transaction
  creation UX that amounts are revealed in these situations.

  - Wallets should take steps to migrate their userbases to store funds uniformly within
    the Orchard pool. Best practices for wallet handling of multiple pools will be covered
    in a subsequent ZIP. [#zip-0315]_


Test Vectors
============

- https://github.com/zcash-hackworks/zcash-test-vectors/pull/14


Reference Implementation
========================

- https://github.com/zcash/halo2
- https://github.com/zcash/orchard


Deployment
==========

This ZIP is proposed to activate with Network Upgrade 5.


References
==========

.. [#orchard-spec] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal] <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf>`_
.. [#spec-addrs-keys] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.1: Payment Addresses and Keys <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#addressesandkeys>`_
.. [#spec-notes] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.2: Notes <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#notes>`_
.. [#spec-actions] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#actions>`_
.. [#spec-action-statement] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. 4.17.4: Action Statement (Orchard) <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#actionstatement>`_
.. [#spec-keys] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 4.2.3: Orchard Key Components <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#orchardkeycomponents>`_
.. [#spec-sinsemilla-hash] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretesinsemillahash>`_
.. [#spec-redpallas] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretereddsa>`_
.. [#spec-sinsemilla-comm] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretesinsemillacommit>`_
.. [#spec-pasta] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#pallasandvesta>`_
.. [#spec-pasta-grouphash] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#concretegrouphashpallasandvesta>`_
.. [#spec-encoding-addr] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.5: Orchard Payment Address <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#orchardpaymentaddrencoding>`_
.. [#spec-encoding-ivk] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.8: Orchard Incoming Viewing Keys <https://raw.githubusercontent.com/daira/zips/orchard-circuit/protocol/orchard.pdf#orchardinviewingkeyencoding>`_
.. [#spec-encoding-fvk] TODO
.. [#spec-encoding-sk] TODO
.. [#concepts-upa] `The halo2 Book: 1.2 UltraPLONK Arithmetization <https://zcash.github.io/halo2/concepts/arithmetization.html>`_
.. [#design-halo2] `The halo2 Book: 3.1. Proving system <https://zcash.github.io/halo2/design/proving-system.html>`_
.. [#design-keys] `The Orchard Book: 3.1. Keys and addresses <https://zcash.github.io/orchard/design/keys.html>`_
.. [#design-actions] `The Orchard Book: 3.2. Actions <https://zcash.github.io/orchard/design/actions.html>`_
.. [#design-commitments] `The Orchard Book: 3.3. Commitments <https://zcash.github.io/orchard/design/commitments.html>`_
.. [#design-tree] `The Orchard Book: 3.4. Commitment tree <https://zcash.github.io/orchard/design/commitment-tree.html>`_
.. [#design-nullifiers] `The Orchard Book: 3.5. Nullifiers <https://zcash.github.io/orchard/design/nullifiers.html>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools <zip-0315.rst>`_
.. [#ietf-hash-to-curve] `draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves <https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html>`_
.. [#pasta-evidence] `Pallas/Vesta supporting evidence <https://github.com/zcash/pasta>`_