ZIP: 224
Title: Orchard Shielded Protocol
Owners: Daira-Emma Hopwood <daira-emma@electriccoin.co>
        Jack Grigg <jack@electriccoin.co>
        Sean Bowe <sean@electriccoin.co>
        Kris Nuttycombe <kris@electriccoin.co>
Original-Authors: Ying Tong Lai
Status: Final
Category: Consensus
Created: 2021-02-27
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/435>

Terminology

The key words "MUST" and "SHOULD" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification 5.

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

Zcash currently has two active shielded protocols and associated shielded pools:

Both of these shielded protocols suffer from two issues:

We are thus motivated to deploy a new shielded protocol designed around a curve cycle, using a proving system that is both amenable to recursion and does not require an SRS.

Specification

The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification 4.

Given that the Orchard protocol 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 \(\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 33 (but the protocol specification takes precedence in the case of any discrepancy).

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

  • Curve specifications: 15
  • \(\mathsf{GroupHash}\) : 16
  • Supporting evidence: 34

Proving system

Orchard uses the Halo 2 proving system 23 with the PLONKish arithmetization 22, instead of Groth16 and R1CS.

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

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: 8
  • Circuit statement: 9
  • Design rationale: 25

Commitments

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

  • Sinsemilla hash function: 11
  • Sinsemilla commitments: 14
  • Design rationale: 26

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: 27

Keys and addresses

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

  • The proof authorizing key is removed, and \(\mathsf{nk}\) is now a field element.
  • \(\mathsf{ivk}\) is computed as a Sinsemilla commitment instead of a BLAKE2s output. There is an additional \(\mathsf{rivk}\) component of the full viewing key that acts as the randomizer for this commitment.
  • \(\mathsf{ovk}\) is derived from \(\mathsf{fvk}\) , instead of being a component of the spending key.
  • All diversifiers now result in valid payment addresses.

There is no Bech32 encoding defined for an individual Orchard shielded payment address, incoming viewing key, or full viewing key. Instead we define unified payment addresses and viewing keys in 32. Orchard spending keys are encoded using Bech32m as specified in 20.

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: 6
  • Key components specification: 10
  • Encodings: 17 18 19 20
  • HD key derivation specification: 29
  • Design rationale: 24

Notes

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

  • Orchard notes: 7

Nullifiers

Nullifiers for Orchard notes are computed as:

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

where \(F\) is instantiated with Poseidon, and \(\mathcal{G}\) is a fixed independent base.

  • Poseidon: 12
  • Design rationale and considered alternatives: 28

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: 13

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 the \(\mathsf{valueBalanceOrchard}\) transaction field. This has the following considerations:

Test Vectors

Reference Implementation

Deployment

This ZIP is proposed to activate with Network Upgrade 5.

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 Parameter Generation
3 Zcash Counterfeiting Vulnerability Successfully Remediated
4 Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]
5 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.12: Mainnet and Testnet
6 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.1: Payment Addresses and Keys
7 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.2: Notes
8 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 3.7: Action Transfers and their Descriptions
9 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.17.4: Action Statement (Orchard)
10 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.2.3: Orchard Key Components
11 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.9: Sinsemilla Hash Function
12 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.1.10: PoseidonHash Function
13 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas
14 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.8.4: Sinsemilla commitments
15 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta
16 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.8: Group Hash into Pallas and Vesta
17 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.2: Orchard Raw Payment Addresses
18 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.3: Orchard Raw Incoming Viewing Keys
19 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.4: Orchard Raw Full Viewing Keys
20 Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.4.5: Orchard Spending Keys
21 Zcash Protocol Specification, Version 2021.2.16. Section 8: Differences from the Zerocash paper
22 The halo2 Book: 1.2 PLONKish Arithmetization
23 The halo2 Book: 3.1. Proving system
24 The Orchard Book: 3.1. Keys and addresses
25 The Orchard Book: 3.2. Actions
26 The Orchard Book: 3.3. Commitments
27 The Orchard Book: 3.4. Commitment tree
28 The Orchard Book: 3.5. Nullifiers
29 ZIP 32: Shielded Hierarchical Deterministic Wallets
30 ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext
31 ZIP 315: Best Practices for Wallet Handling of Multiple Pools
32 ZIP 316: Unified Addresses and Unified Viewing Keys
33 draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves
34 Pallas/Vesta supporting evidence