mirror of https://github.com/zcash/zips.git
314 lines
16 KiB
ReStructuredText
314 lines
16 KiB
ReStructuredText
::
|
|
|
|
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: Proposed
|
|
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. [#RFC2119]_
|
|
|
|
The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash
|
|
Protocol Specification [#protocol-networks]_.
|
|
|
|
|
|
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 [#zerocash-differences]_), 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 [#zcash-paramgen]_), 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, [#bctv14-vuln]_ 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
|
|
[#protocol-orchard]_.
|
|
|
|
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 :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 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: [#protocol-pallasandvesta]_
|
|
- :math:`\mathsf{GroupHash}`: [#protocol-concretegrouphashpallasandvesta]_
|
|
- Supporting evidence: [#pasta-evidence]_
|
|
|
|
Proving system
|
|
--------------
|
|
|
|
Orchard uses the Halo 2 proving system with the UltraPLONK arithmetization (UPA), 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.
|
|
|
|
- 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: [#protocol-actions]_
|
|
- Circuit statement: [#protocol-actionstatement]_
|
|
- 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: [#protocol-concretesinsemillahash]_
|
|
- Sinsemilla commitments: [#protocol-concretesinsemillacommit]_
|
|
- 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: [#protocol-addressesandkeys]_
|
|
- Key components specification: [#protocol-orchardkeycomponents]_
|
|
- Encodings and HRPs: [#protocol-orchardpaymentaddrencoding]_ [#protocol-orchardinviewingkeyencoding]_ [#protocol-orchardfullviewingkeyencoding]_
|
|
[#protocol-orchardspendingkeyencoding]_
|
|
- 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: [#protocol-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: [#protocol-poseidonhash]_
|
|
- 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: [#protocol-concretereddsa]_
|
|
|
|
|
|
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
|
|
:math:`\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 :math:`\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. [#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
|
|
==========
|
|
|
|
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
|
.. [#zerocash-differences] `Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper <https://zips.z.cash/protocol/protocol.pdf#differences>`_
|
|
.. [#zcash-paramgen] `Parameter Generation <https://z.cash/technology/paramgen/>`_
|
|
.. [#bctv14-vuln] `Zcash Counterfeiting Vulnerability Successfully Remediated <https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/>`_
|
|
.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal] <protocol/nu5.pdf>`_
|
|
.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 3.11: Mainnet and Testnet <protocol/nu5.pdf#networks>`_
|
|
.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.1: Payment Addresses and Keys <protocol/nu5.pdf#addressesandkeys>`_
|
|
.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.2: Notes <protocol/nu5.pdf#notes>`_
|
|
.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions <protocol/nu5.pdf#actions>`_
|
|
.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.17.4: Action Statement (Orchard) <protocol/nu5.pdf#actionstatement>`_
|
|
.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.2.3: Orchard Key Components <protocol/nu5.pdf#orchardkeycomponents>`_
|
|
.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function <protocol/nu5.pdf#concretesinsemillahash>`_
|
|
.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.10: PoseidonHash Function <protocol/nu5.pdf#poseidonhash>`_
|
|
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas <protocol/nu5.pdf#concretereddsa>`_
|
|
.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments <protocol/nu5.pdf#concretesinsemillacommit>`_
|
|
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta <protocol/nu5.pdf#pallasandvesta>`_
|
|
.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta <protocol/nu5.pdf#concretegrouphashpallasandvesta>`_
|
|
.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.1: Orchard Payment Address <protocol/nu5.pdf#orchardpaymentaddrencoding>`_
|
|
.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys <protocol/nu5.pdf#orchardinviewingkeyencoding>`_
|
|
.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.3: Orchard Full Viewing Keys <protocol/nu5.pdf#orchardfullviewingkeyencoding>`_
|
|
.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.4: Orchard Spending Keys <protocol/nu5.pdf#orchardspendingkeyencoding>`_
|
|
.. [#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>`_
|