This section fixes the subject of the volume, its status, its sources and its notation before any construction: the scope; the named network upgrades and ZIP statuses on which later rules depend; the three classes in which the deployment boundary places each component of a Zcash FlyClient; the primary paper and the policy for its printed defects; the normative sources; and one table of conventions closing with a symbol index.
This volume of The Zcash Arboretum states three objects and the relation between them. The first is the FlyClient protocol of Bünz, Kiffer, Luu and Zamani (ePrint 2019/226). The second is the chain-history commitment of ZIP 221 (Final), to which every block header after the Heartwood activation block (Definition 1.1) commits: directly, as the header field , in blocks validated under the Heartwood or Canopy rules, and, from NU5, as the first input of the hash of ZIP 244 (Final). The header fields are named in “The header consensus rules” (§6.7), and their values are defined in “The epoch tree and its root commitment” (§6.4) and “The block commitment hash” (§6.6). The third is the boundary between the protocol and the commitment: each component of a Zcash FlyClient is classified as specified, designed but unspecified, or an open problem (Definition 1.3). 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.
The volume assumes the following, each cited by italic volume name and section title. From the Math Guide: probability, densities and asymptotics (§“Probability, asymptotics, and computation”, with §“Beyond finite spaces: countable additivity, limits, and densities” and §“Asymptotic notation”). From the Crypto Guide: hash functions and their security notions (§“Hash functions and the random oracle model”, with §“Security notions: preimage, second-preimage, and collision resistance” and §“The random oracle model”); the provable-security model (§“The provable-security model”, with §“Adversaries and the security parameter”, §“Security as a game” and §“Reductions”); interactive arguments (§“Interactive protocols, proofs, and arguments”); the Fiat–Shamir transform (§“The Fiat–Shamir transform: from interactive to non-interactive”); and the binding and inclusion soundness of Merkle trees (§“Merkle trees and commitments to sets”, with its subsections §“Binary Merkle trees”, §“Authentication paths and membership proofs”, §“Soundness: forging a path implies a collision”, §“Layer and domain separation”, §“Append-only and incrementally updatable trees” and §“Vector commitments”). From the Consensus Guide: work and the most-work rule (§“The block tree and the most-work rule” and §“Work, and the best chain”), memoryless clocks (§“Memoryless clocks and the attribution sequence”), the retarget rule under NU7 (§“Difficulty in motion”) and Equihash (§“Equihash and the memoryless model”). From the Ironwood Guide, only for the objects it constructs: block chain, height, network upgrades, ZIPs and the status Draft (§“Scope and status”); the Orchard pool and the Ironwood pool (§“The Orchard protocol and its two pools”); the encoding (§“Fields, groups, and encodings”); pool roots, final treestates and anchors (§“The note commitment tree” and §“Anchors”); branch IDs and the valid transaction formats, version 5 and version 6 under NU7 (§“The transaction format”; ZIP 2003 (Draft); ZIP 259 (Draft)); and transaction identifiers, the personalised hash and the branch-ID encoding (§“Transaction digests and signatures”). The light-client model is cited directly to ZIP 307 (Draft), “Security Model” and “Block header validation”.
A network upgrade, its activation height and the fixed order in which network upgrades activate are those of the Ironwood Guide, §“Scope and status”, Definition “Network upgrade” (ZIP 200 (Final), “Terminology” and “Activation mechanism”). This volume names the following network upgrades, in activation order, each with its deployment ZIP and the status of that ZIP:
| Upgrade | ZIP | Status | Upgrade | ZIP | Status |
|---|---|---|---|---|---|
| Sapling | 205 | Final | NU6 | 253 | Final |
| Blossom | 206 | Final | NU6.1 | 255 | Final |
| Heartwood | 250 | Final | NU6.2 | 257 | Final |
| Canopy | 251 | Final | NU6.3 | 258 | Draft |
| NU5 | 252 | Final | NU7 | 259 | Draft |
An upgrade is named only where its name fixes which header rule or tree-node rule applies. The Heartwood activation block is the block whose height is the activation height of Heartwood. No activation height, date or branch ID value is given here; the branch IDs of the upgrades from Heartwood on, whose upgrade epochs bear an epoch tree (“Upgrade epochs and epoch trees”, §6.2), are tabulated in Table 3.
A ZIP and its status Draft, the status of every ZIP on submission, are those of the Ironwood Guide, §“Scope and status”, Definition “ZIP”. Two further statuses occur in this volume (ZIP 0 (Active), “ZIP Status Field”):
Final, the status of a Consensus or Standards ZIP that is both implemented and activated on the Zcash network;
Active, the status, typically of a Process or Informational ZIP, reached once rough consensus on it has been reached; ZIP 0 itself has this status.
The status is a property of the document and does not decide whether its rules are in force. The rules of ZIP 258 (Draft) and ZIP 229 (Draft) apply from NU6.3 activation: ZIP 258, “NU6.3 deployment”, lists ZIP 229 among the primary sources of the NU6.3 consensus changes, and ZIP 258, “Changes to ZIP 221”, amends the history-tree node of ZIP 221. Every ZIP is cited with its status at its first citation in the volume.
The volume describes the protocol as specified for NU7, whose deployment ZIP, ZIP 259, has status Draft (ZIP 259, preamble). NU6.3 is active.
A component of a Zcash FlyClient is a data structure, rule, check or proof format of the protocol, or a hypothesis of its security theorem. A component is
specified when normative text of the protocol specification or of a ZIP fixes it, whatever the status of that ZIP (Definition 1.2);
designed but unspecified when a published design with an analysis exists but no ZIP or section of the protocol specification fixes it for Zcash;
an open problem when no design exists.
A property proved in this volume of a specified object is classified by its object: the object is specified, and the property is proved here.
The class specified is that of the Ironwood Guide, §“Scope and status”, Definition “Epistemic classes”; that volume applies designed but unspecified to a property that a deployed construction is designed to satisfy but that no specification, ZIP or proof establishes, whereas this volume applies it to a component that exists only as a published design; the two uses share the condition that no normative text fixes the object, and the sense of the Ironwood Guide is not used here.
The primary source is B. Bünz, L. Kiffer, L. Luu and M. Zamani, “FlyClient: Super-Light Clients for Cryptocurrencies”, IACR ePrint 2019/226, in its sixth revision, the last revision on the ePrint page and the revision of record; the paper also appeared at the IEEE Symposium on Security and Privacy. Every statement taken from the paper is cited by the section, definition, theorem, lemma, algorithm or printed page of that revision. A section of the paper is written “Section 5.3”, without the section sign, which this volume reserves for sections of the protocol specification and of the Arboretum.
Where a statement of this volume rests on a printed statement of the paper that is defective, the volume states the corrected form at that point and names the departure. Only defects that touch a stated result are mentioned, and there is no separate register of them. Claims of the paper that this volume does not prove are stated as the paper’s, with their gaps: for example Assumption 5.11 (“Transition rewriting”) and Remark 4.11 (“Lemma 1 of the paper”).
The normative sources are the following. The protocol specification, in the sections §“The Block Chain”, §“Integers, Bit Sequences, and Endianness”, §“Constants”, §“BLAKE2 Hash Functions”, §“Transaction Encoding and Consensus”, §“Block Header Encoding and Consensus”, §“Difficulty filter”, §“Difficulty adjustment”, §“nBits conversion” and §“Definition of Work”. ZIP 0 (Active), which defines the ZIP process and its statuses; ZIP 200 (Final); ZIP 204 (Draft); ZIPs 205, 206, 250, 251, 252, 253, 255 and 257 (Final), the deployment ZIPs of the upgrades named in Definition 1.1 before NU6.3; ZIP 218 (Draft); ZIP 221 (Final); ZIP 229 (Draft); ZIP 244 (Final); ZIP 258 (Draft); ZIP 259 (Draft); ZIP 307 (Draft); and ZIP 2003 (Draft). A ZIP is cited by its number and the title of a section, the title following the number in the same sentence; the protocol specification is cited as protocol specification, §“Title”.
The conventions of the volume and the symbols of later sections are fixed in Table 1. The paper overloads several symbols: denotes both the honest participation and the chain length; the persistence depth, the samples per interval and ; both the security parameter and a statistical exponent; both the weight fraction checked in full and the backbone parameter for which bounds the adversary’s mining power; both the fork threshold and the number of blocks of the checked suffix; and both the weight bound and a ratio of mining power. The table assigns one meaning to each symbol, and the index that closes it records where each is defined.
| Conventions | |
|---|---|
| Logarithms | The logarithm is natural and is to base (Math Guide, §“Symbols and how to say them”). For real , , , as in : a real-base logarithm, distinct from the discrete logarithm , whose base is a group element. |
| Floor, ceiling | The floor and ceiling of a real (Math Guide, §“Symbols and how to say them”; §“The division algorithm”). |
| Asymptotics | The symbols and and negligible functions are as in the Math Guide, §“Asymptotic notation” and §“Polynomial, exponential, and negligible functions”; and . With several parameters, or grows while , , and are fixed; the budget is either fixed or, as in the paper, , and each bound states which. |
| Three parameters | the security parameter (Math Guide, §“The security parameter”); the statistical exponent of a failure target ; the output length in bits of the paper’s hash . The paper writes for all three. |
| Node fields | Fields of a node of the difficulty Merkle mountain range are sans-serif and accessed with a dot, as , . |
| Personalised hash | The hash and the encoding are those of the Ironwood Guide, §“Transaction digests and signatures”; the hash is always written with its personalisation and input in full. |
| Two epochs | The retarget epoch (“Retargeting and the difficulty-raising attack”) and the upgrade epoch (“Upgrade epochs and epoch trees”) are distinct objects; “epoch” is not used alone where it is ambiguous. |
| Unused symbols | The Crypto Guide’s (completeness error) and (language) do not occur. |
| Symbol index (pointers to the defining subsection; nothing is defined here) | |
| Header-only verification | the length of a claimed chain; a block height in the sense of the Ironwood Guide, §“Scope and status”; the total work of a chain ; a block header; every chain-length quantity before “Merkle mountain ranges” is written or “the chain length”, never . |
| Merkle mountain ranges (section preamble) | the hash and its output length . |
| The recursive definition | the leaf count of a Merkle mountain range, hence of the range a head commits to, never a block height; a leaf index and the value of leaf ; the range over values and its root; the altitude of a node. |
| Peaks and bagging | the peaks, ; and the two bagging orders. |
| Aggregating ranges | the serialisation of a node tuple; the cumulative weight before a leaf. |
| The variable-difficulty backbone model | a difficulty level (larger is harder); a target (smaller is harder); , restated, never written ; the queries per player per round; a round; and the honest and adversarial players of round ; the participation parameters; the adversary’s power bound; the persistence depth. |
| Retargeting and the difficulty-raising attack | the retarget-epoch length; the rounds a retarget epoch takes; the dampening factor; the expected blocks per round. |
| The -adversary | and the parameters of the adversary; the power ratio of the paper’s evaluation. |
| The difficulty Merkle mountain range | and the level exponent and the retarget-epoch count of the feasibility bounds; the dotted node fields. |
| The sampling distribution | the weight fraction checked in full; the catch parameter, , its only meaning; a fork point; a point of ; a density on ; the constant of the indifference density; the FlyClient density and its distribution function; the single-draw catch probability; the sample count; the samples per dyadic interval; a uniform variable on . |
| The non-interactive protocol | the head-recomputation budget. |
| Header chain commitments and per-sample checks | the block at height ; heights are written , never . |
| Upgrade epochs and epoch trees | an activation height; that of Heartwood, distinct from the hash ; the greatest activation height below ; the epoch tree committed by , distinct from a target , with leaves. |
| The epoch tree and its root commitment | the branch ID of an epoch tree . |
| The header consensus rules | the activation height of NU5. |
| The committed range | the activation height of NU7. |