This section classifies every component of a Zcash FlyClient in the classes of Definition 1.3. It opens with one table that places each hypothesis of Theorem 5.32 and each obligation of Remark 5.33 in its class, with the cited fact that places it there. The subsections that follow elaborate the rows: the specified commitment and the absence of a specified consumer, the differences between the paper’s commitment and the deployed one, the conditions that the ZIPs impose on any sample check of a Zcash verifier, and the open problems.
The classes of Definition 1.3 apply to components, not to properties. A property proved in this volume of a specified object is recorded as “the object is specified, and the property is proved here”, never as specified. Table 4 classifies every hypothesis of Theorem 5.32 and every obligation O1 to O6 of Remark 5.33, together with two components of the deployed commitment, the chain commitment (row (1)) and its composition across upgrade epochs (row (4)); O1 and O2 share row (3). Each row gives its class and the cited fact that places it there or, for an assumption on the client’s environment, the source that records it. Hypothesis 1 of the theorem fixes the parameters , and , whose values an instantiation chooses; rows (7) and (9) classify what those values rest on. The rows read as follows.
Chain commitment: specified. It is the epoch-scoped, metadata-bearing, branch-separated epoch tree (Definition 6.2, Construction 6.10), to whose chain-history root every header after the Heartwood activation block commits under Definition 6.22, enforced by consensus (ZIPs 221 and 244; ZIP 258, Draft, whose rules are in force from NU6.3 by Definition 1.2).
Collision resistance of the hash functions: the functions are specified, namely personalised BLAKE2b-256 for tree nodes, the chain-history root, the authorising-data root and the block commitment hash (ZIPs 221 and 244; protocol specification, §“BLAKE2 Hash Functions”), and SHA-256d for block hashes, hence for leaves (protocol specification, §“Block Header Encoding and Consensus”). Their collision resistance is a standard assumption (Crypto Guide, §“Security notions: preimage, second-preimage, and collision resistance”).
O1, binding within one upgrade epoch: the commitment is specified (Definition 6.22), and the property is proved here of the specified object (Proposition 6.13); no normative text fixes the property. O2, fork structure for ZIP 221 trees: open, since it is conditional on a sufficient sample check for those trees, which no specification or result supplies (Proposition 7.4); Lemmas 5.4 and 5.5 are stated for the paper’s construction only. Hypothesis 6 of Theorem 5.32, leaf–internal separation, enters only through Lemma 5.4 and shares the class of O2: it is stated for the paper’s construction, and for ZIP 221 trees no specification or result supplies its counterpart.
The verifier’s anchor, the genesis block in the paper: open (Corollary 6.25).
O3, weight binding: the node vector is specified (Definition 6.3), and the binding of the field- interval of a leaf to the root and its position within one upgrade epoch is proved here of the specified object (Lemma 3.21(1) with Proposition 6.13). The link from a sampled header to its leaf’s weight is conditional on the same sufficient sample check, and so open. Sampling by the chain’s total work is open, field of a root summing one upgrade epoch (Definition 6.3; Proposition 7.8).
Assumption 4.8, the transition checks of O3 (Construction 5.8) and Assumption 5.11 under the Zcash retarget rule, in both of its regimes: open (protocol specification, §“Difficulty adjustment”; ZIP 218, Draft).
Assumption 5.20: open for Zcash; no analysis relates the work of individual blocks to the invalid segments of a Zcash fork.
The random-oracle hypothesis on the sampling hash: open. No ZIP or specification section fixes a sampling hash for Zcash, so the hypothesis has no object; the model is that of the Crypto Guide, §“The random oracle model”.
O6, size: the bound of Corollary 5.34 is designed but unspecified; a Zcash proof format is open.
At least one honest prover: an assumption on the client’s connectivity, not a component, so no class applies. ZIP 221, “Security and Privacy Considerations”, summarises the analysis of the paper, not the setting of ZIP 221 itself, as follows: “The security analysis assumes adversary mining power is bounded by a known fraction of combined mining power of honest nodes, and cannot drop or tamper with messages between client and full nodes. It also assumes the client is connected to at least one full node and knows the genesis block.” The bound on mining power is row (7); the absence of dropping or tampering and the connection to at least one full node are this row; knowledge of the genesis block is row (5).
Open problems (§7.5) derives rows (4), (5), (7), (11) and (12), and the total work of row (6), from cited rules; O2 of row (3), with the header-to-weight link of row (6), and rows (8) and (10) are open for the reasons stated above.
| Hypothesis or obligation | Class | Placed by | |
|---|---|---|---|
| (1) | chain commitment | specified | Definition 6.22; ZIPs 221, 244, 258 |
| (2) | collision resistance of and SHA-256d | functions specified; resistance assumed | ZIPs 221, 244; Crypto Guide |
| (3) | O1: binding within one upgrade epoch | commitment specified; property proved here | Proposition 6.13 |
| O2: fork structure for ZIP 221 trees; hypothesis 6 (leaf–internal separation) | open problem | Proposition 7.4; sufficiency not claimed | |
| (4) | composition across upgrade epochs | open problem | Theorem 6.24; ZIP 221 silent |
| (5) | anchor of the verifier | open problem | Corollary 6.25 |
| (6) | O3: weight binding | node vector specified; interval binding proved here; header-to-weight link and total work open | Lemma 3.21(1); Proposition 7.8 |
| (7) | , transition checks, transition rewriting | open problem | retarget rule of the specification; ZIP 218 |
| (8) | discretisation | open problem | no analysis for Zcash |
| (9) | O4: catch probability, sample count | designed but unspecified | Theorem 5.21; Proposition 5.22 |
| (10) | random oracle for sampling | open problem | no sampling hash specified |
| (11) | O5: grinding | transform designed but unspecified; transcript and open | Construction 5.27; Assumption 5.28 |
| (12) | O6: size | designed but unspecified; format open | Corollary 5.34 |
| (13) | at least one honest prover | environment; no class | ZIP 221, “Security and Privacy Considerations” |
The verifier as a whole is designed but unspecified. The protocol of “The FlyClient protocol” (§5) exists with the paper’s theorem in the paper’s model; no ZIP specifies a Zcash instantiation; and the paper’s model does not cover Zcash’s retarget rule. The paper proves security only for its model of retargeting once per retarget epoch (Definition 4.5), places rules that retarget from a moving average outside it, and credits them with heuristic guarantees only (ePrint 2019/226, Section 3.1, pages 7–8); it names Ethereum there and does not name Zcash. ZIP 221, “Security and Privacy Considerations”, names Zcash among the chains “with rapidly adjusting difficulty” that the paper leaves open.
Row (1) of Remark 7.1 is the following. ZIP 221 (Final) specifies the tree, with FlyClient as its stated motivation (ZIP 221, “Motivation”). ZIP 221, “FlyClient Requirements and Recommendations”, designates seven fields for reasoning about the difficulty adjustment over a range of blocks: , , , , , and (Remark 6.4). The pool roots and transaction counts are its “Non-FlyClient Commitments”. No ZIP or specification section specifies a consumer of the tree, a proof object or a verifier. The specified class depends on no implementation: Definition 1.2 places the fields of ZIP 258 (Draft) in force from NU6.3.
The consensus rule of Definition 6.22 is an equality between the commitment field of a header and a value that the validator recomputes from the chain it holds: in the Heartwood and Canopy upgrade epochs, and the block commitment hash from NU5 (protocol specification, §“Block Header Encoding and Consensus”; ZIP 221, “Block header semantics and consensus rules”; ZIP 244, “Block Header Changes”). No ZIP or specification section defines an inclusion proof for the tree, a proof object or a verification algorithm. The operation that the paper’s verifier performs, Construction 5.2, is therefore unspecified for Zcash.
Against Construction 5.1 and Definition 5.6, the deployed commitment differs in five respects.
ZIP 221, “Tree Node specification”, states: “Other than the metadata commitments, the MMR tree’s construction is standard.” Items (1), (3), (4) and (5) record the respects in which the deployed construction also differs from the paper’s.
The verifier is designed but unspecified (Remark 7.1). The conditions below are obligations that ZIPs 221 and 244 impose on any sample check for ZIP 221 trees; they are not a construction of this volume, and no Zcash verifier is specified here. A sample check for ZIP 221 trees is a deterministic algorithm that takes the header of a head, an index and a prover’s message, and accepts or rejects; its purpose is to establish, for the head’s epoch tree, the conclusions of Proposition 5.3 and Lemma 5.7. A condition is necessary when some message that meets every other condition and violates it also violates such a conclusion, so that a check that does not reject that message fails the conclusion.
Let the head , , commit to with leaves, let encode , and let a sample be leaf of , , the block at height , with received header . Each of the following conditions, the height clause of (ii) and the parsing clause of (iv) excepted, is necessary for a sample check for ZIP 221 trees. Sufficiency is not claimed. The height clause of (ii) is required for the leaf’s stated heights to match its position (Lemma 6.6); parsing under the field vector is the hypothesis under which Proposition 6.13 and Lemma 3.20(2) apply; the necessity of neither is claimed.
Field of the leaf equals , the SHA-256d hash of the full received header, Equihash solution included (Lemma 6.7).
Fields and of the leaf equal the field of , fields and its field ; field equals the work of that ; and fields and equal , the height that the position fixes, the header carrying no height (Definition 2.3).
The header satisfies proof of work in the sense of Definition 2.3: a valid Equihash solution, and the difficulty filter at the target it declares.
The sampled leaf of (i) and (ii) and the path siblings are received as full node serialisations, parsed under the field vector of Definition 6.5 for the upgrade epoch beginning at . Starting from that leaf, every parent is recomputed: field as (Construction 6.10), the other fields by the parent rule of Definition 6.3. The recomputed root node yields , which is compared with the head’s commitment field under Definition 6.22: directly in the Heartwood and Canopy upgrade epochs, and from NU5 through Proposition 6.19 with the head’s .
The sides and the length of the path are those that and fix under , the length being (Lemma 3.7).
For : the root node output by (Construction 3.16), run on the path with the parent rule in place of , is the claimed root node of , and the value
is accepted against the commitment field of under Definition 6.22: equals that field in the Heartwood and Canopy upgrade epochs, and from NU5 is accepted by Proposition 6.19 with the of the sampled block.
For each condition, a message that meets the other five and violates it also violates the conclusion named.
An honest header paired with a leaf of inflated field , in a tree that the adversary builds over such leaves under a head that it mines, so that every path verifies. The header-determined fields are not those of the header, contrary to Proposition 5.3(ii), and the interval that Lemma 3.21(1) binds belongs to a forged weight.
A tree built over fabricated headers without valid solutions. Every other condition is met by construction, and unmined headers pass, contrary to Lemma 5.7(1).
If a node is taken in any other form, the fields that do not enter the recomputation are unbound. With the siblings supplied as field- digests and the path checked on field alone, the siblings’ field , which fixes the interval of Lemma 3.21, and the leaf’s pool fields (, and, where the vector carries them, to ), which its header does not determine, are chosen freely; two passing samples at then carry distinct leaf tuples, contrary to Proposition 5.3(i). If the recomputation starts from a node other than the leaf matched in (i) and (ii), the matched header is bound to nothing. Proposition 6.13 binds full serialisations only.
The single-block tuple of a leaf placed at a position where the shape has an internal node: a tree with fewer than leaves then passes, and a tuple committed at another depth is accepted as leaf . Theorem 3.17, which assumes the shape fixed by and the bagging order, does not apply.
Honest blocks, mined on the honest chain after the fork point, appended as leaves of the fork’s tree. They pass (i) to (v), while their own commitments bind the honest prefix, not the fork’s first leaves, contrary to Proposition 5.3(iii). This is the case that Lemma 5.4 excludes by the prefix check.
No condition is shown sufficient. □
The conditions are the ZIP 221 counterparts of the checks of Construction 5.2: (i) and (ii) of check (a), (iii) of check (d), (iv) and (v) of check (b), and (vi) of check (c). Three further statements bound their reach. For the sample is the block . For it is an activation block, which commits to the completed tree of the previous upgrade epoch (Theorem 6.24); for it carries the sentinel of Definition 6.12 (Corollary 6.25). In both cases its prefix check belongs to epoch composition, which is open. The consensus condition of Definition 2.3 depends on preceding headers and is not decided by one sample; it is the object of the transition checks of row (7), which are open. And condition (iv) makes Proposition 6.13 apply, but the fork structure of row (3) additionally needs a sufficient check, which is open.
The size is evaluated at the scale of one upgrade epoch, since is the leaf count of one epoch tree and never the length of the chain. The message of Proposition 7.4 for one sample consists of the -byte header (§2.1), the sampled leaf’s own serialisation of at most bytes (Definition 6.5), at most siblings of at most bytes each (Lemma 3.7), and the bytes of the sampled block’s . For a path has at most siblings, and a sample at most
of which the header is per cent. For , with peaks, a path has at most siblings, and a sample at most
of which the header is per cent. The leaf’s fields fixed by its header and its position, to and to , could be omitted by a proof format, which is open. The figures are computed by script.
The following open items, each a row of Remark 7.1 except the serving interface, are derived below from cited rules: epoch composition, the anchor below the Heartwood activation height, total work, the proof format, the serving interface, the Fiat–Shamir transcript, and the security analysis under Zcash’s retarget rule with its NU7 regime. Composition with compact-block scanning follows. Availability of prover data is not a protocol question.
Epoch trees are hashed under distinct branch IDs, and each complete root is committed only by the next activation header (Theorem 6.24). No specified rule chains them, and ZIP 221, “Specification”, is silent. Composition is needed for prefix proofs and for difficulty checks: the averaging window and the median-time span of the first blocks of an upgrade epoch reach into the previous upgrade epoch (protocol specification, §“Difficulty adjustment”), so a transition check at an upgrade boundary needs two epoch trees. Proposition 5.38 needs an inclusion path of the accepted head against the later head’s root, and so applies within one epoch tree. Across epoch trees it does not apply: no tree of a later upgrade epoch contains a leaf of an earlier one (Definition 6.2), and only the activation header commits to the completed earlier tree. No design exists: the item is open.
The anchor below the Heartwood activation height is open, by Corollary 6.25.
Let .
For every node of , field is the sum modulo of the work of the blocks at heights to , all in ; field of no node of depends on .
Hence no inclusion path against the root to which commits opens . Sampling by the chain’s cumulative work (Definition 5.19) and the acceptance rule need field of the root of every completed epoch tree , an activation height, each committed only by (Theorem 6.24), together with the work of the blocks below , which no tree commits (Corollary 6.25).
No ZIP addresses the item; it is open.
(a) The block hash covers the whole header, and included (Definition 2.3); induction down the chain, a divergence yielding a collision of SHA-256d. (b) Field of a leaf is its block’s work and that of an internal node the sum of its children’s (Definition 6.3); the leaves of are (Definition 6.2); the height range of is that of Lemma 6.6. (c) A path opens only fields of nodes of , and by (b) the only work-valued field, field , sums work over leaves of ; the pool-root fields depend on earlier blocks, but through treestates, from which work is not computed. The work of each block is at least , since , so exceeds the work of the leaves of whenever . The remaining work is committed only as stated, by Theorem 6.24 and Corollary 6.25. ZIP 221, “Tree Node specification”, assumes that cumulative chain work stays below , which makes each modular sum exact (Lemma 3.21(2)). □
Part (b) does not contradict the statement of (a) that every header commits to the total work: that commitment is through the linkage of every header, which a sampling verifier does not receive.
The proof format is open; no ZIP or specification section defines one. From NU5 any format carries, for every header whose commitment it opens, the -byte needed to reopen the block commitment hash (Proposition 6.19).
The serving interface is open: no ZIP or specification section defines a message for requesting or serving tree nodes, inclusion paths or assembled proofs. Availability of prover data is not a protocol question. Every node, and hence every inclusion path, of is a function of the chain up to its last leaf , not of the blocks of the upgrade epoch alone, since the pool-root fields (, , , , and ) are roots of final treestates, which depend on every note commitment since the activation of the pool (Definition 6.3; Construction 6.10; ZIP 221, “Tree Node specification”; ZIP 258, “Changes to ZIP 221”). Any party that holds that chain computes them; what is unspecified is the message.
The transcript is open. Construction 5.27 derives the sampling randomness from a hash of the head (ePrint 2019/226, Section 6.2). For Zcash no ZIP or specification section fixes the header bytes, the hash, the domain separation or the map from output to weight points across upgrade epochs, so Proposition 5.29 has no Zcash instance.
The security analysis is open. Zcash retargets after every block from an averaging window with median-time spans, damping and asymmetric clamps, which is not Definition 4.5. The blocks of the upgrade epochs from Heartwood through NU6.3 are governed by a -block window at a -second target spacing (protocol specification, §“Difficulty adjustment”); NU7 as specified uses blocks at seconds (ZIP 218, Draft, “Averaging window”; Consensus Guide, §“Difficulty in motion”). Neither regime is covered by Theorem 5.32, and the paper contains no derivation of from either (Remark 4.13). The published analysis of a Zcash instantiation (Perazzo and Capecchi, arXiv 2604.26736, Section IV-A, Definition IV.1) assumes its adversarial work budget rather than deriving it from the retarget rule, so it does not close the gap; it is recorded here because the open classification must account for it. ZIP 221, “Security and Privacy Considerations”, records that the paper leaves such chains with only heuristic guarantees, that “The use of these fields has not been analysed in the academic security literature”, and that “A more in-depth security analysis of FlyClient should be performed before designing a FlyClient-based light client ecosystem for Zcash”. No ZIP addresses the gap.
ZIP 218 (Draft) changes the target spacing from to seconds, the averaging window from to blocks and the expected stale rate (ZIP 218, “Block target spacing”, “Averaging window”, “Stale block rate”). These bear on the that an instantiation could assume, not on Theorem 5.21, which is stated in and . Transition checks must use the height-dependent spacing and window, span two regimes across one more upgrade boundary (Corollary 6.26), and meet first adjustments that ZIP 218, “Effect on difficulty adjustment”, expects to be limited by (Consensus Guide, §“NU7: 25-second blocks and bounded shielded work”).
Composition with compact-block scanning is open. A FlyClient replaces trust in the header chain, not in the channel through which a wallet detects its transactions (ZIP 307, Draft).