From 62c31fda896596d2e94f6321e5b7eca4365dd513 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 2 Mar 2021 22:17:02 +0000 Subject: [PATCH] ZIP 224 editorial changes. Signed-off-by: Daira Hopwood --- README.rst | 2 +- index.html | 2 +- zip-0224.html | 163 ++++++++++++++++++++++++++++---------------------- zip-0224.rst | 67 +++++++++++---------- 4 files changed, 128 insertions(+), 106 deletions(-) diff --git a/README.rst b/README.rst index c90fd46c..2c792aec 100644 --- a/README.rst +++ b/README.rst @@ -98,7 +98,7 @@ Index of ZIPs 219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved 221 FlyClient - Consensus-Layer Changes Final 222 Transparent Zcash Extensions Draft - 224 Orchard Shielded Protocol Draft + 224 Orchard Shielded Protocol Proposed 225 Version 5 Transaction Format Proposed 243 Transaction Signature Validation for Sapling Final 244 Transaction Identifier Non-Malleability Proposed diff --git a/index.html b/index.html index 83cf404f..ff5ca94e 100644 --- a/index.html +++ b/index.html @@ -71,7 +71,7 @@ 219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved 221 FlyClient - Consensus-Layer Changes Final 222 Transparent Zcash Extensions Draft - 224 Orchard Shielded Protocol Draft + 224 Orchard Shielded Protocol Proposed 225 Version 5 Transaction Format Proposed 243 Transaction Signature Validation for Sapling Final 244 Transaction Identifier Non-Malleability Proposed diff --git a/zip-0224.html b/zip-0224.html index 469f019f..5c1e302d 100644 --- a/zip-0224.html +++ b/zip-0224.html @@ -14,11 +14,12 @@ Owners: Daira Hopwood <daira@electriccoin.co> Sean Bowe <sean@electriccoin.co> Kris Nuttycombe <kris@electriccoin.co> Ying Tong Lai <yingtong@electriccoin.co> -Status: Draft +Status: Proposed Category: Consensus 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.11 of the Zcash Protocol Specification 6.

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.

@@ -26,18 +27,18 @@ Discussions-To: <https://g

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 2), which as of February 2021 is a "closing" shielded pool into which no new ZEC can be sent.
    • +
  • 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.
    • +
  • 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 5.

+

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:

@@ -47,46 +48,46 @@ Discussions-To: <https://g

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 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.

+ , 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 32 (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: 14
    • +
  • Curve specifications: 16
  • \(\mathsf{GroupHash}\) - : 15
    • -
  • Supporting evidence: 31
    • + : 17 +
  • Supporting evidence: 33

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.

+

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: 20
    • -
  • Halo 2 explanation and design rationale: 21
    • +
  • UltraPLONK Arithmetization: 22
    • +
  • Halo 2 explanation and design rationale: 23

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: 23
    • +
  • Action description: 9
    • +
  • Circuit statement: 10
    • +
  • Design rationale: 25

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: 11
    • -
  • Sinsemilla commitments: 13
    • -
  • Design rationale: 24
    • +
  • Sinsemilla hash function: 12
    • +
  • Sinsemilla commitments: 15
    • +
  • 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: 25
    • +
  • Design rationale and considered alternatives: 27

Keys and addresses

@@ -105,14 +106,14 @@ Discussions-To: <https://g , 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).

    +

    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: 6
      • -
    • Key components specification: 10
      • -
    • Encodings and HRPs: 16 17 18 19
      • -
    • HD key derivation specification: 27
      • -
    • Design rationale: 22
      • +
    • Key components diagram: 7
      • +
    • Key components specification: 11
      • +
    • Encodings and HRPs: 18 19 20 21
      • +
    • HD key derivation specification: 29
      • +
    • Design rationale: 24

    Notes

    @@ -123,9 +124,9 @@ Discussions-To: <https://g \(\psi\) and \(\mathsf{rcm}\) - are derived from a random seed (as with Sapling after ZIP 212 28).

    + are derived from a random seed (as with Sapling after ZIP 212 30).

      -
    • Orchard notes: 7
      • +
    • Orchard notes: 8

    Nullifiers

    @@ -139,14 +140,14 @@ Discussions-To: <https://g \(\mathcal{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).

      -
    • RedPallas: 12
      • +
    • RedPallas: 14
    @@ -166,7 +167,7 @@ Discussions-To: <https://g 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.
    • @@ -218,130 +219,146 @@ Discussions-To: <https://g - +
    - +
    5Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal]
    - +
    - +
    6Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.1: Payment Addresses and KeysZcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 3.11: Mainnet and Testnet
    - +
    - +
    7Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.2: NotesZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.1: Payment Addresses and Keys
    - +
    - +
    8Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.7: Action Transfers and their DescriptionsZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.2: Notes
    - +
    - +
    9Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. 4.17.4: Action Statement (Orchard)Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions
    - +
    - +
    10Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 4.2.3: Orchard Key ComponentsZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.17.4: Action Statement (Orchard)
    - +
    - +
    11Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash FunctionZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.2.3: Orchard Key Components
    - +
    - +
    12Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallasZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function
    - +
    - +
    13Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitmentsZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.10: PoseidonHash Function
    - +
    - +
    14Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.6: Pallas and VestaZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas
    - +
    - +
    15Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and VestaZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments
    - +
    - +
    16Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.5: Orchard Payment AddressZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta
    - +
    - +
    17Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.8: Orchard Incoming Viewing KeysZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta
    - +
    - +
    18TODOZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.1: Orchard Payment Address
    - +
    - + + + +
    19TODOZcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys
    + + + + + + + +
    20Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.3: Orchard Full Viewing Keys
    + + + + +
    21Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.4: Orchard Spending Keys
    - + @@ -349,7 +366,7 @@ Discussions-To: <https://g
    2022 The halo2 Book: 1.2 UltraPLONK Arithmetization
    - + @@ -357,7 +374,7 @@ Discussions-To: <https://g
    2123 The halo2 Book: 3.1. Proving system
    - + @@ -365,7 +382,7 @@ Discussions-To: <https://g
    2224 The Orchard Book: 3.1. Keys and addresses
    - + @@ -373,7 +390,7 @@ Discussions-To: <https://g
    2325 The Orchard Book: 3.2. Actions
    - + @@ -381,7 +398,7 @@ Discussions-To: <https://g
    2426 The Orchard Book: 3.3. Commitments
    - + @@ -389,7 +406,7 @@ Discussions-To: <https://g
    2527 The Orchard Book: 3.4. Commitment tree
    - + @@ -397,7 +414,7 @@ Discussions-To: <https://g
    2628 The Orchard Book: 3.5. Nullifiers
    - + @@ -405,7 +422,7 @@ Discussions-To: <https://g
    2729 ZIP 32: Shielded Hierarchical Deterministic Wallets
    - + @@ -413,7 +430,7 @@ Discussions-To: <https://g
    2830 ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext
    - + @@ -421,7 +438,7 @@ Discussions-To: <https://g
    2931 ZIP 315: Best Practices for Wallet Handling of Multiple Pools
    - + @@ -429,7 +446,7 @@ Discussions-To: <https://g
    3032 draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves
    - + diff --git a/zip-0224.rst b/zip-0224.rst index 7c4f6259..0c740cb3 100644 --- a/zip-0224.rst +++ b/zip-0224.rst @@ -7,7 +7,7 @@ Sean Bowe Kris Nuttycombe Ying Tong Lai - Status: Draft + Status: Proposed Category: Consensus Discussions-To: @@ -17,6 +17,9 @@ 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 ======== @@ -69,7 +72,7 @@ Specification ============= The Orchard protocol MUST be implemented as specified in the Zcash Protocol Specification -[#orchard-spec]_. +[#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 @@ -95,8 +98,8 @@ The presence of the curve cycle is an explicit design choice. This proposal only of the cycle (Pallas being an embedded curve of Vesta); the full cycle is expected to be leveraged by future protocol updates. -- Curve specifications: [#spec-pasta]_ -- :math:`\mathsf{GroupHash}`: [#spec-pasta-grouphash]_ +- Curve specifications: [#protocol-pallasandvesta]_ +- :math:`\mathsf{GroupHash}`: [#protocol-concretegrouphashpallasandvesta]_ - Supporting evidence: [#pasta-evidence]_ Proving system @@ -122,8 +125,8 @@ 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]_ +- Action description: [#protocol-actions]_ +- Circuit statement: [#protocol-actionstatement]_ - Design rationale: [#design-actions]_ Commitments @@ -133,8 +136,8 @@ The Orchard protocol has equivalent commitment schemes to Sapling. For non-homom 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]_ +- Sinsemilla hash function: [#protocol-concretesinsemillahash]_ +- Sinsemilla commitments: [#protocol-concretesinsemillacommit]_ - Design rationale: [#design-commitments]_ Commitment tree @@ -157,17 +160,17 @@ changes: 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 +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]_ +- 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]_ @@ -179,7 +182,7 @@ is set to the nullifier of the spent note in the same action, which ensures it i :math:`\psi` and :math:`\mathsf{rcm}` are derived from a random seed (as with Sapling after ZIP 212 [#zip-0212]_). -- Orchard notes: [#spec-notes]_ +- Orchard notes: [#protocol-notes]_ Nullifiers ---------- @@ -191,7 +194,7 @@ Nullifiers for Orchard notes are computed as: where :math:`F` is instantiated with Poseidon, and :math:`\mathcal{G}` is a fixed independent base. -- Poseidon: TODO +- Poseidon: [#protocol-poseidonhash]_ - Design rationale and considered alternatives: [#design-nullifiers]_ Signatures @@ -200,7 +203,7 @@ 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]_ +- RedPallas: [#protocol-concretereddsa]_ Additional Rationale @@ -277,21 +280,23 @@ References .. [#zerocash-differences] `Zcash Protocol Specification, Version 2021.1.16. Section 8: Differences from the Zerocash paper `_ .. [#zcash-paramgen] `Parameter Generation `_ .. [#bctv14-vuln] `Zcash Counterfeiting Vulnerability Successfully Remediated `_ -.. [#orchard-spec] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal] `_ -.. [#spec-addrs-keys] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.1: Payment Addresses and Keys `_ -.. [#spec-notes] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.2: Notes `_ -.. [#spec-actions] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions `_ -.. [#spec-action-statement] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. 4.17.4: Action Statement (Orchard) `_ -.. [#spec-keys] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 4.2.3: Orchard Key Components `_ -.. [#spec-sinsemilla-hash] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function `_ -.. [#spec-redpallas] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas `_ -.. [#spec-sinsemilla-comm] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments `_ -.. [#spec-pasta] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta `_ -.. [#spec-pasta-grouphash] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta `_ -.. [#spec-encoding-addr] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.5: Orchard Payment Address `_ -.. [#spec-encoding-ivk] `Zcash Protocol Specification, Version 2021.1.16-gc8c7dd [Orchard proposal]. Section 5.6.8: Orchard Incoming Viewing Keys `_ -.. [#spec-encoding-fvk] TODO -.. [#spec-encoding-sk] TODO +.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal] `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 3.11: Mainnet and Testnet `_ +.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.1: Payment Addresses and Keys `_ +.. [#protocol-notes] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.2: Notes `_ +.. [#protocol-actions] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 3.7: Action Transfers and their Descriptions `_ +.. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.17.4: Action Statement (Orchard) `_ +.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.2.3: Orchard Key Components `_ +.. [#protocol-concretesinsemillahash] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.9: Sinsemilla Hash Function `_ +.. [#protocol-poseidonhash] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.1.10: PoseidonHash Function `_ +.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.6: RedDSA, RedJubjub, and RedPallas `_ +.. [#protocol-concretesinsemillacommit] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.7.4: Sinsemilla commitments `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta `_ +.. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.8: Group Hash into Pallas and Vesta `_ +.. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.1: Orchard Payment Address `_ +.. [#protocol-orchardinviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4.2: Orchard Incoming Viewing Keys `_ +.. [#protocol-orchardfullviewingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.3: Orchard Full Viewing Keys `_ +.. [#protocol-orchardspendingkeyencoding] `Zcash Protocol Specification, Version 2020.1.17 [Orchard proposal]. Section 5.6.4.4: Orchard Spending Keys `_ .. [#concepts-upa] `The halo2 Book: 1.2 UltraPLONK Arithmetization `_ .. [#design-halo2] `The halo2 Book: 3.1. Proving system `_ .. [#design-keys] `The Orchard Book: 3.1. Keys and addresses `_
    3133 Pallas/Vesta supporting evidence