This section fixes the subject of the volume, its status and its vocabulary before any construction: the scope; in plain language, the structure of a shielded payment and the division of its verification; the Orchard protocol and its two value pools; and the requirements that a shielded payment must meet.
This volume of The Zcash Arboretum constructs the Orchard protocol for a shielded payment in the Ironwood pool, both terms being defined in §1.3: how the payment is constructed, delivered and verified; why a valid payment cannot create value, consume a note twice, or consume a note without the authority of its owner; and what it hides. The sealed Orchard pool enters only where a rule shared with the Ironwood pool, or a rule that distinguishes the two pools, is needed to state the Ironwood-pool payment correctly. The volume assumes the Math Guide and the Crypto Guide, and cites the Halo 2 Guide for the proof system. It is non-normative: the Zcash Protocol Specification, cited as the protocol specification with the title of a section, and the Zcash Improvement Proposals are authoritative.
A block chain is a sequence of blocks that starts at the genesis block, the header of each block referring to the preceding block; the height of a block is its number of predecessors, so that the genesis block has height (ZIP 200, Terminology; protocol specification, §“The Block Chain”). Each block contains an ordered sequence of one or more transactions, the units in which the chain records transfers of value (protocol specification, §“Transactions and Treestates”). The consensus rules are the validation rules that determine which block chains, and hence which blocks and transactions, are valid (ZIP 200, Terminology, “Consensus rule set”).
A Zcash Improvement Proposal (ZIP) is a design document that describes a feature of Zcash, or a change to it, with a concise technical specification and a rationale. Each ZIP carries a status. Two statuses are named in this volume: Draft, the status that every ZIP receives on submission, and Reserved, the status of a ZIP number that the ZIP editors have reserved while no ZIP text has been published (ZIP 0, Abstract and “ZIP Status Field”). A deployed rule is cited to a section of the protocol specification by its title, or to a ZIP and its section.
A network upgrade is an intentional change of the consensus rules that takes effect at a block height fixed for it, its activation height: blocks below that height are validated under the preceding rules, and blocks at or above it under the new rules. Network upgrades are named and activate in a fixed order (ZIP 200, Terminology and “Activation mechanism”). This volume names two: NU6.3, whose deployment ZIP is ZIP 258, and NU7, the upgrade that follows NU6.3, whose deployment ZIP is ZIP 259 (ZIP 258, Abstract; ZIP 259, Abstract and Rationale, “Rationale for no new transaction format”).
The volume describes the protocol as specified for NU7, whose deployment ZIP has status Draft (ZIP 259, preamble). It names a network upgrade only where the name fixes which rule applies, gives no activation parameter, such as an activation height or a date, and describes no upgrade by what it adds or changes.
Where the status of a claim about the deployed protocol needs stating, the volume places it in one of exactly two classes. The claim is specified when normative text of the protocol specification or of a ZIP fixes it. It is designed but unspecified when the deployed construction is designed to satisfy it but neither the protocol specification, nor a ZIP, nor a published proof establishes it for the deployed instance. An example of each class is given where its object is introduced: knowledge soundness of the Action proof in §1.2, and the cross-address restriction in §1.3.
This subsection names, in plain language, the objects of a shielded payment and the checks that verify it. Each term receives one defining clause here and its construction in the section named.
A shielded payment transfers value held in notes. A note records, among other fields, an amount of value and the address of its recipient, a public value derived from the recipient’s keys (§3.3); no note is published in the clear (§4.1). For each note that a payment creates, the chain records a commitment to the note in the sense of the Crypto Guide, §“Hiding and binding”, its note commitment, in the extracted form constructed in §4.2. For each note that a payment consumes, the chain records a tag, the note’s nullifier, which marks the note as consumed (§6.1).
In this volume a value pool is a separately accounted collection of notes with its own record of note commitments, the note commitment tree (§5.1); its own record of nullifiers, the nullifier set (§6.2); and its own chain value pool balance, the total value that the chain accounts as held in the pool (§11.4).
A shielded payment is carried by Actions. An Action consumes one note of a pool and creates one note of the same pool. A side of an Action that the payment does not use carries a dummy note, a note of value zero that pads the Action (§4.4; protocol specification, §“Action Transfers and their Descriptions” and §“Dummy Notes (Orchard)”).
The Actions of one transaction in one pool, together with data common to them, form the transaction’s bundle for that pool; a transaction carries at most one bundle per pool (§4.4; ZIP 229, Abstract and “Transaction Format”). The balancing value of a bundle is the net value, public, that the bundle moves out of its pool into the rest of the transaction; it is negative when value enters the pool (§8.2).
A created note reaches its recipient through the chain: the Action that creates it also carries a note ciphertext, an encryption of the note to the recipient’s address, from which the recipient recovers the note (§10).
A verifier, a party that checks transactions against the consensus rules, accepts a bundle, without learning its notes, on one proof per bundle, two kinds of signature and two checks against the state of the chain (protocol specification, §“Action Transfers and their Descriptions” and §“Action Descriptions”).
One zero-knowledge proof per bundle, the Action proof (Crypto Guide, §“SNARKs: succinct non-interactive arguments of knowledge”; Halo 2 Guide, §“The Halo 2 proof system”): an argument that the prover knows, for each Action, private data that together with the Action’s public data satisfy one fixed relation, in the sense of the Crypto Guide, §“Languages, relations, and witnesses”, namely the Action statement, defined in “The Action statement” (§9.2). The proof system has no notion of value or ownership; the relation supplies both.
Per Action, a spend-authorisation signature (Crypto Guide, §“Syntax and security goal”), made with a signing key obtained from the spend authorising key, the signing secret associated with the consumed note’s address (§3.1), by which the holder of that key authorises the consumption (§7).
Per bundle, one binding signature, by which balance is checked: the total value of the notes that the bundle consumes, minus that of the notes it creates, equals its balancing value (§8.3).
Two checks against the state of the chain. The proof refers to one earlier state of the pool’s note commitment tree, through a digest of that state, the bundle’s anchor (§5.2), and the verifier checks that the anchor is one that the chain recorded for an earlier block. The verifier also checks that every nullifier that the bundle publishes is new to the pool (§6.2).
Both kinds of signature sign one digest of the transaction, constructed in “Transaction digests and signatures” (§11.3). The two checks of (4) lie outside the proof because they concern the history of the whole chain, which a proof over the data of one Action cannot attest.
Knowledge soundness of the Action proof as deployed (Crypto Guide, §“SNARKs: succinct non-interactive arguments of knowledge”), the property under which an accepted proof establishes the knowledge claimed in (1), is designed but unspecified: the volume takes it as Assumption 9.11 (§9.3), not as a result.
The Orchard protocol is the cryptographic design shared by two value pools: its primitive instances, among them the Pallas and Vesta curves and the Sinsemilla hash (§2); its keys and addresses; its notes, note commitments and nullifiers; its note encryption; and the one relation that every Action proves, the Action statement, defined in “The Action statement” (§9.2), with the circuit designed to encode it (§9.3). ZIP 229 fixes this vocabulary (ZIP 229, Terminology), and the volume adopts it.
The Orchard pool and the Ironwood pool are the two value pools of the Orchard protocol. Each has its own note commitment tree, and hence its own anchors, its own nullifier set and its own chain value pool balance (ZIP 229, Terminology, and Rationale, “Separate state”).
The Ironwood pool admits net inflow, value moved into it by a negative balancing value (§11.4). The Orchard pool is sealed, in two respects (ZIP 258, “Consensus rules from NU6.3 activation”); each rule is stated where its object is constructed. First, no transaction increases the value held in the Orchard pool (§11.4). Second, every Orchard-pool Action creates its note at the address of the note it consumes (ZIP 229, Rationale, “enableCrossAddress polarity”), a rule made exact in “Bundle flags” (§9.1) and with the Action statement, defined in “The Action statement” (§9.2). ZIP 229, Abstract, states the effect of the second rule: outputs to the Orchard pool go to an address for which the creator of the transaction can authorise spends, which discourages transfers between users within the Orchard pool. Consensus does not prevent such transfers: any party able to authorise spends for an address can create an Orchard-pool note to that address, since the consumed side of the Action can be a dummy note at that address (ZIP 326, “Rationale for key-generation restrictions”; the witness of such an Action is exhibited in §9.2).
The restriction of an Action’s created note to the address of its consumed note, in force for every Orchard-pool Action and for every Ironwood-pool Action whose bundle does not enable cross-address transfers (§9.1), is specified: the protocol specification, §“Action Descriptions”, fixes the meaning of the flag that controls it, although ZIP 2006, which that section cites for it, has status Reserved (ZIP 2006, preamble).
Notes of the two pools have the same form and the same note commitment. They differ only in the note plaintext format, the encoding in which note encryption carries a note: an Ironwood-pool note uses the format whose first byte, the lead byte that names the format, is , under which the note’s commitment trapdoor, the randomness of its note commitment, is derived by hashing a random seed, which the plaintext carries, together with every field that the commitment binds (the format and the lead-byte rule in §4.3, the plaintext in §10.1; ZIP 258, “ZIP 2005 activation”). Actions of both pools prove the same relation, the Action statement, defined in “The Action statement” (§9.2), with one circuit and one verifying key, the public parameter against which a proof is checked (§9.3; protocol specification, §“Action Descriptions”; ZIP 258, “Consensus rules from NU6.3 activation”). The pools are distinguished by their note commitment trees, nullifier sets and chain value pool balances, and by the component of the transaction that carries their bundles (§11.2), not by separate circuits (ZIP 229, Abstract, and Rationale, “Reuse of the Orchard protocol with minimal changes”).
Orchard-pool notes are spendable, in version- and version- transactions (§11.2), subject to the rules that seal the Orchard pool (ZIP 258, “Consensus rules from NU6.3 activation”; ZIP 259, Abstract).
The name “Orchard” alone qualifies the shared cryptography of the Orchard protocol; a statement that depends on the pool names the pool, the Orchard pool or the Ironwood pool.
A transparent payment is one whose consumed and created amounts and addresses are public. The goal of a shielded payment is to achieve the effects of a transparent payment, namely transfer of value, exclusion of double-spending, the consumption of one note twice, and conservation of value, while hiding the contents of its notes, and the links between the notes it consumes and the notes it creates, from an observer: any party that reads the chain but holds no key of the notes concerned. Requirements R1 to R5 below make this precise. Each of R1 to R4 has a soundness part, a property of every valid payment, and a hiding part, a bound on what the observer learns; R5 has a soundness part only.
Hidden representation of value. Soundness: the chain’s record of a created note binds that note, so that its owner can later prove possession of it and no party can present the record as the record of a different note. Hiding: the record reveals neither the recipient’s address nor the value, and does not distinguish a real note from a dummy note.
Membership without identification. Soundness: every consumed note of non-zero value was previously committed in the same pool, at the state of the pool’s record of commitments to which the payment refers. Hiding: the payment does not identify which committed note it consumes. A note of value zero, such as a dummy note, transfers no value, and R2 does not require it to have been committed.
No second consumption. Soundness: no note of a pool is consumed twice. Hiding: this holds without a public list of consumed notes; the data published when a note is consumed do not identify which committed note it is.
Conservation. Soundness: in every valid bundle the total value of the consumed notes equals the total value of the created notes plus the balancing value, so that no payment creates value. Hiding: no note’s value is disclosed; of the amounts, only the balancing value is public.
Spend authority, a soundness part only. Only the holder of a note’s spending authority, the spend authorising key associated with its address (§3.1), can consume the note; and no other party can alter what an authorised payment transfers, namely the notes it consumes and creates and the value it moves into or out of the pool, without invalidating it. Requirement R5 requires nothing of data that do not change what is transferred; which data the signatures fix is stated in “Transaction digests and signatures” (§11.3).