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
+Zcash currently has two active shielded protocols and associated shielded pools:
+-
+
- The Sprout shielded protocol (based on the Zerocash paper with improvements and security fixes 2), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent. +
- The Sapling shielded protocol, which consisted of numerous improvements to functionality and improved performance by orders of magnitude, and as of Feburary 2021 is the "active" shielded pool. +
Both of these shielded protocols suffer from two issues:
+-
+
- Neither Sprout nor Sapling are compatible with known efficient scalability techniques. Recursive zero-knowledge proofs (where a proof verifies an earlier instance of itself along with new state) that are suitable for deployment in a block chain like Zcash require a cycle of elliptic curves. The Sprout protocol does not use elliptic curves and thus is an inherently inefficient protocol to implement inside a circuit, while the Sapling protocol uses curves for which there is no known way to construct an efficient curve cycle (or path to one). +
- The Sprout and Sapling circuits are implemented using a proving system (Groth16) that requires a "trusted setup": the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds. The parameters are in practice generated using a multiparty computation (MPC), where as long as at least one participant was honest and not compromised, the hidden structure is unrecoverable. The MPCs themselves have improved over the years (Zcash had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later 3), but it remains the case that generating these parameters is a point of risk within the protocol. For example, the original proving system used for the Sprout circuit (BCTV14) had a bug that made the Sprout shielded protocol vulnerable to counterfeiting, 4 which needed to be resolved by changing the proving system and running a new MPC. +
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 2.
+The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification 5.
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:
@@ -37,14 +47,14 @@ Discussions-To: <https://gWe 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 27 (but the protocol specification takes precedence in the case of any discrepancy).
+ , 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 30 (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.
Proving system
@@ -52,31 +62,31 @@ Discussions-To: <https://g
This ZIP does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future ZIPs.
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.
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.
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.
Keys and addresses
@@ -98,11 +108,11 @@ Discussions-To: <https://g
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: 3 -
- Key components specification: 7 -
- Encodings and HRPs: 13 14 15 16 -
- HD key derivation specification: 24 -
- Design rationale: 19 +
- Key components diagram: 6 +
- Key components specification: 10 +
- Encodings and HRPs: 16 17 18 19 +
- HD key derivation specification: 27 +
- Design rationale: 22
Notes
@@ -113,9 +123,9 @@ Discussions-To: <https://g
\(\psi\)
and
\(\mathsf{rcm}\)
- are derived from a random seed (as with Sapling after ZIP 212 25).
+ are derived from a random seed (as with Sapling after ZIP 212 28).
Nullifiers
@@ -130,13 +140,13 @@ Discussions-To: <https://g
is a fixed independent base.
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).