This section fixes the subject of the volume, its status and its vocabulary before any construction: the sources and their status, and the notation (§1.1); the three epistemic classes, the status of a result proved here and the carrier of a construction (§1.2); the Assets, the OrchardZSA protocol and the premise on the pool that carries its notes (§1.3); and the requirements that a protocol for shielded assets must meet, each paired with the result of this volume that discharges it (§1.4).
This volume of The Zcash Arboretum describes the OrchardZSA protocol, defined in §1.3, as a delta on the Orchard protocol that the Ironwood Guide constructs. Every construction of the volume modifies an object of that volume, or adds an object beside it, and the objects of the Orchard protocol are cited by the Ironwood Guide’s titles, never re-derived: §“Notes and note commitments”, with Definition “Note” and Definition “Note commitment”; §“The note seed: Ironwood derivations (lead byte )”; §“Actions, bundles, and dummy notes”, with Definition “Dummy notes”; §“Value commitments and the binding signature”, with §“Value commitments” (Definition “Net value commitment”), §“The balancing value” and §“The binding signature”; §“The Action statement and its proof”, with §“The Action statement” (Definition “Orchard Action statement”); §“Nullifiers”; §“Sinsemilla: hash, commitment, and short forms”; §“GroupHash, domain separation, and nothing-up-my-sleeve generators”; §“The Orchard protocol and its two pools”; §“The transaction format”; §“Value conservation”, with Theorem “Balance”; §“Fields, groups, and encodings”; and §“Requirements on a shielded payment”. The volume further assumes the Math Guide; the Crypto Guide for digital signatures (§“Digital signatures”), Pedersen commitments (§“Commitment schemes”, §“The Pedersen commitment”) and random oracles (§“Hash functions and the random oracle model”); and the Halo 2 Guide for the proof system. No other volume is cited. The volume 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.
Sources. Two ZIPs specify the protocol. ZIP 227, “Issuance of Zcash Shielded Assets”, specifies the issuance of Custom Assets; ZIP 226, “Transfer and Burn of Zcash Shielded Assets”, specifies their transfer and burn. Both have status Draft and category Consensus (ZIP 226 and ZIP 227, preambles). ZIP 226 is written relative to the protocol with ZIP 2005 applied (ZIP 226, Abstract), and calls ZIP 2005 “Orchard Quantum Recoverability”; the current title of ZIP 2005 is “Ironwood Quantum Recoverability”, and its status is Proposed (ZIP 2005, preamble). Every construction of the OrchardZSA protocol is therefore fixed, where it is fixed at all, by Draft text, and none belongs to the consensus rules of any network upgrade. The class of each construction (§1.2) is stated once, where the construction is made.
The status field of a ZIP takes one of the values that ZIP 0, “ZIP Status Field”, fixes; a ZIP with several revisions carries one status per revision. This volume uses five of them.
Proposed: typically the stage after Draft, set after consideration, feedback and rough consensus of the community. ZIP 2005 has it.
Active: typically used for Process or Informational ZIPs, set once rough consensus on a Proposed ZIP is reached. Revision of ZIP 317 has it.
Final: the status of a Consensus or Standards ZIP that is both implemented and activated on the Zcash network.
A ZIP text is live when its status, or the status of the revision concerned, is Draft, Proposed, Active or Final. Every published ZIP that this volume cites is either live or Withdrawn. The Ironwood Guide’s Definition “ZIP” names only the statuses Draft and Reserved; Reserved is not used here.
Status with respect to network upgrades. NU6.3 is the active network upgrade, deployed by ZIP 258, and NU7 is specified by ZIP 259 (Draft). The sources of the consensus changes of NU7 are the protocol specification, ZIPs 200, 218 and 2003, and ZIP 237, which ZIP 259 names but which is unpublished; none of these is ZIP 226 or ZIP 227; NU7 introduces no new transaction format, and version- and version- transactions remain valid (ZIP 259, Abstract and Specification, “NU7 consensus changes”). ZIP 258 does not mention Zcash Shielded Assets (ZIP 258, Specification). ZIP 226, “Deployment”, still names NU7 as the network upgrade that deploys the protocol, which ZIP 259 contradicts, and ZIP 227, “Deployment”, reads “TBD”. The assignment of the OrchardZSA protocol to a network upgrade is therefore an open problem in the sense of Definition 1.2, stated in §1.2.
Notation. The notation is that of the Ironwood Guide, whose table in §“Fields, groups, and encodings” maps it to the names of the protocol specification. Table 1 extends that map to the names that ZIP 226 and ZIP 227 use and that the table of the Ironwood Guide does not list. The names of the ZIPs appear in that table only. The table lists no symbol that this volume defines: every such symbol, among them the Asset Base, the Asset Identifier and Asset Digest, the OrchardZSA note and value commitments, the split flag, the pause flag, the issuance keys, the global issuance state and the burn set, is defined at its first use. The same convention applies to the generator of Construction 4.4, which ZIP 226 writes calligraphically.
| ZIP notation | This volume | Meaning |
|---|---|---|
| , also | the Pallas group | |
| the Pallas group without its identity | ||
| the Pallas base-field modulus | ||
| the order of the Pallas group | ||
| the bit length of the star encoding | ||
| -bit little-endian encoding | ||
| the star encoding of | ||
| the group hash into | ||
| , , | , , | fixed generators of the Orchard protocol |
Prose uses British spelling, as in finalisation and authorisation. Identifiers and titles taken from the ZIPs keep their own spelling, as in the flag and the title “Issuance Authorization Signature Scheme” of ZIP 227.
Each construction of this volume is in exactly one of three classes.
It is specified when normative text of the protocol specification or of a live ZIP (Definition 1.1), Draft included, fixes it.
It is designed but unspecified when no live normative text and no published proof fixes it, but a complete design of it exists, in withdrawn ZIP text, in text removed from a ZIP, in a document outside the ZIPs, or as an argument of a ZIP’s rationale without proof, and that design conflicts with no live text.
It is an open problem when the protocol needs it and either no text, live, withdrawn or removed, supplies a design of it; or every existing design conflicts with live text, in that a value or position that the design assigns is assigned otherwise by live text; or live texts contradict one another about it.
The Ironwood Guide’s Definition “Epistemic classes” uses the first two names for claims about the deployed protocol; here they are redefined for constructions, and the third is added.
Each construction is classified where it is made. Among the designed but unspecified constructions are the OrchardZSA circuit (§4.4), the derivation of the commitment trapdoor of an OrchardZSA note (§3.3) and the fee terms (§8.3). Among the open problems are the pool that carries OrchardZSA notes (Remark 1.7); the live carrier, whose withdrawn version is now the format of ZIP 229, which need not support Zcash Shielded Assets (ZIP 229, Non-requirements); the bit of the pause flag , whose position in withdrawn ZIP 230, bit of the flags byte, is that of in ZIP 229 (§8.1); and the value of the lead byte, whose removed value is the Ironwood lead byte (§3.3).
A theorem, proposition, lemma or corollary of this volume is proved here for the constructions as the ZIPs state them, and carries no class: the classes of Definition 1.2 apply to constructions and to the rationale arguments of the ZIPs. The hypotheses of a result are named in its statement. A hypothesis that concerns a designed but unspecified object, or an open problem (Definition 1.2(iii)), makes the result conditional on that object:
A result about notes created by issuance, such as the provenance of Asset Bases or supply integrity, holds for every deterministic derivation of the commitment trapdoor from the published fields of such a note. It depends on the designed but unspecified derivation of only in that some such derivation must be fixed for a validator to compute the commitment. Where a ZIP argues the same property in its rationale only, that argument remains designed but unspecified; a proof in this volume does not change its class.
Every construction states its class where it is made, and every result the premises on which it is conditional. “Classification of the components” (§10) tabulates both.
The carrier of a construction is the set of transaction fields that encode it, together with the digests that commit to it: the transaction identifier, the authorising-data digest and the signature digest, the three digests of the Ironwood Guide, §“Transaction digests and signatures”. A construction can be specified while its carrier is not.
An Asset is a type of note that can be transferred on the Zcash block chain. Each Asset is identified by an Asset Identifier (ZIP 227, Terminology). ZEC is the default, and currently the only defined, Asset on Mainnet, and TAZ the default, and currently the only defined, Asset on Testnet; each is the Native Asset of its network. A Custom Asset is an Asset other than ZEC and TAZ (ZIP 227, Terminology; ZIP 226, “Burn Mechanism”). The Asset Identifier of a Custom Asset is constructed in “Asset descriptions and Asset Identifiers” (§2.2); no ZIP constructs one for the Native Asset, whose Asset Base is fixed directly (Definition 2.15). In this volume issuance means the issuance of a Custom Asset, in the sense of ZIP 227. It is distinct from the creation of ZEC by the block subsidy in a coinbase transaction (Ironwood Guide, Definition “Coinbase transaction”), which the OrchardZSA protocol does not modify.
The OrchardZSA protocol is the extension of the Orchard protocol that ZIP 226 and ZIP 227 define jointly: ZIP 227 specifies the issuance of Custom Assets, and ZIP 226 their transfer and burn. ZIP 227 is to be implemented only together with ZIP 226, because the notes that issuance creates can be transferred only by the OrchardZSA transfer protocol (ZIP 227, Abstract, where “must” is lower-case and is not a key word of BCP 14). Relative to the Orchard protocol it makes the following changes, each constructed in the section named with it.
Each note gains one field, a point of the Pallas group that names its Asset (“Notes and note commitments”, §3).
The note commitment becomes a case split that leaves the commitments of ZEC notes unchanged (same section).
The net value commitment takes that point as its value base, in place of the fixed base (same section).
The binding validating key further subtracts the burnt amounts (“Burn and the binding signature”, §5).
An Action of a Custom Asset that consumes no note pads its consumed side with a copy of a note already committed, of the same Asset and counted at value , instead of a dummy note (“OrchardZSA Actions and Action Groups”, §4).
The Action statement changes accordingly (same section).
The sources of these changes are ZIP 227, Abstract, and ZIP 226, Abstract and Specification, with “Split Notes”, “Value Balance Verification” and “Backward Compatibility”.
ZIP 226 places OrchardZSA notes in the Orchard pool, which the Orchard and the OrchardZSA protocols then share, and adds their note commitments to the same note commitment tree (ZIP 226, “Privacy Implications”, “Backward Compatibility” and “Rationale for Note Commitment”). It also assumes ZIP 2005 applied (ZIP 226, Abstract). ZIP 2005 applies its recoverable note plaintext format, of lead byte , only to notes of the Ironwood pool (ZIP 258, “ZIP 2005 activation”), and note plaintexts of the Orchard pool take the lead byte only (protocol specification, §“Note Plaintexts and Memo Fields”). Since NU6.3 the Orchard pool is sealed (ZIP 258, “Consensus rules from NU6.3 activation”; Ironwood Guide, §“The Orchard protocol and its two pools”):
a coinbase transaction has no Orchard-pool Actions;
every Orchard-pool Action creates its note at the address of the note it consumes, cross-address transfers being disabled;
the balancing value of the Orchard pool is non-negative.
Read literally, these rules have consequences that no ZIP states. Rule (b) excludes, for a Custom Asset, every created note at an address other than that of the note which the same Action consumes or copies; it thus excludes a transfer of a Custom Asset to such an address, and every padding copy at an address other than that of its Action’s created note. Rule (c) is stated for ZEC only, and leaves unaddressed the entry of issued value into a pool that admits no inflow. ZIP 226 and ZIP 227 have not been revised for the pool rules of NU6.3 (ZIP 226 has only given up lead byte ), ZIP 258 does not mention them, and no ZIP places OrchardZSA notes in the Ironwood pool: ZIP 2005 treats the extension as undeployed (“if that were deployed”, Terminology) and requires it to take a new lead byte (“Usage with other proposals requiring note plaintext format changes”).
Class: which pool carries OrchardZSA notes is an open problem (Definition 1.2). Live texts contradict one another about it: ZIP 258 states that no new value may enter the Orchard pool, while ZIP 227 adds the commitments of issued notes to the note commitment tree (ZIP 227, “Addition to the Note Commitment Tree”) that ZIP 226 places in that pool, and no live text places the notes elsewhere. The later sections state each construction as ZIP 226 and ZIP 227 state it, and recall this remark where a consequence falls: at Split Inputs, at reference notes and at the order of the note commitment tree.
A protocol for shielded assets meets the following requirements. Each refines one of the Ironwood Guide’s Definition “Requirements R1 to R5”, or is new (ZIP 227, Requirements; ZIP 226, “Privacy Implications”, “Rationale for Value Commitment” and “Backward Compatibility”).
Per-Asset conservation. Requirement R4 holds Asset by Asset: in every valid bundle, for each Asset, the value consumed equals the value created plus the value that leaves the pool, burnt value counted as leaving.
No counterfeiting across Assets. No transaction creates value of one Asset from value of another Asset, or from nothing; value of a Custom Asset enters only by issuance.
Supply integrity. The amount of a Custom Asset in circulation equals the amount issued minus the amount burnt, can be tracked publicly, and stops growing once its issuer finalises the Asset.
Issuance authority. Only the holder of an issuer’s key issues or finalises that issuer’s Assets.
Hiding of the Asset type. A shielded transfer reveals which Assets it moves no more than burn and issuance publish. This refines the hiding parts of R1 and R4.
Two design requirements are recorded with Z2. First, the identification of an Asset should be unique among all shielded pools, and different issuer keys should not produce the same Asset Identifier (ZIP 227, Requirements, where “should” is lower-case). Second, the identity of an Asset maps to a point of the Pallas group that serves as a private value base inside the Action proof (ZIP 226, Overview, “Rationale for Value Commitment” and “Value Commitment Correctness”).
Table 2 names, for each requirement, the result of this volume that discharges it. The checks that serve each requirement are mapped in Table 6 of “Verification of an OrchardZSA transaction” (§7.4), where all of them are defined.
| Requirement | Result |
|---|---|
| Z1, Z2 | Theorem 9.5, “No counterfeiting across Assets” |
| Z3 | Theorem 9.7, “Supply integrity”; |
| Proposition 7.8, “Finalised supply never grows” | |
| Z4 | Theorem 9.8, “Issuance authority” |
| Z5 | Theorem 9.11, “Privacy of the Asset type” |