You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ZIP: 224
Title: Orchard Shielded Protocol
Owners: Daira Hopwood <[email protected]>
Jack Grigg <[email protected]>
Sean Bowe <[email protected]>
Kris Nuttycombe <[email protected]>
Ying Tong Lai <[email protected]>
Status: Final
Category: Consensus
Created: 2021-02-27
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/435>
Terminology
The key word "MUST" in this document is to be interpreted as described in RFC 2119. [1]
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:
The Sprout shielded protocol (based on the Zerocash paper with improvements and security
fixes [21]), 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 [2]), 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, [3] 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
[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.
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.
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.
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).
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]).
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).
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:
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 \mathsf{valueBalanceOrchard} 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 user bases to store funds uniformly within
the Orchard pool. Best practices for wallet handling of multiple pools will be covered
in a subsequent ZIP. [31]