This section fixes the object a light client verifies, the Zcash block header, and the baseline procedure that verifies a chain of headers in full. It states the trust model of the light-client protocol specified for Zcash and the problem the volume solves, with each term of its solution defined in one clause and constructed in a later section.
A light client is a client that is not a full participant in the network of Zcash peers. It can send and receive payments, but does not store or validate a copy of the block chain (ZIP 221, “Terminology”).
The verifier of the FlyClient paper is a light client given the additional inputs fixed in Definition 4.16 (“Security and succinctness of chain proofs”, §4.4).
Byte strings and integers are related by the maps of the Ironwood Guide, §“Fields, groups, and encodings”, Definition “Integer and byte encodings”: the map sends an integer in to its -byte little-endian encoding, and the map sends a -byte string to the integer it encodes in little-endian order.
The CompactSize encoding of an integer is the byte string
of length , , or bytes respectively. Only this encoding, the shortest, is valid for : a byte string that decodes to under one of the other three prefixes MUST be rejected (ZIP 204, “CompactSize”).
ZIP 204 has status Draft; the minimal-encoding rule binds block headers independently, through the protocol specification, §“Block Header Encoding and Consensus”, which requires the header field to be encoded with the minimum number of bytes. That rule prevents a miner from testing several encodings of one Equihash solution against the difficulty filter.
The upgrade epochs delimited by the network upgrades of Definition 1.1 are fixed in “Upgrade epochs and epoch trees” (§6.2).
A Zcash block consists of a block header and a sequence of transactions. A block header is the concatenation, in the following order, of the fields
| Bytes | Field | Content |
|---|---|---|
| signed 32-bit integer; the consensus rules require | ||
| the block hash of the previous block | ||
| the root of the transaction Merkle tree over the identifiers of the block’s transactions, stated in “The authorising-data root” (§6.5) | ||
| commitment field | named as below | |
| unsigned 32-bit integer, the block timestamp | ||
| unsigned 32-bit integer, an encoding of the target threshold | ||
| arbitrary bytes | ||
| an Equihash solution |
with integers encoded little-endian. The commitment field is named before Sapling, in Sapling and Blossom, in Heartwood and Canopy, and from NU5; its value in each upgrade epoch is fixed in “The header consensus rules” (§6.7). The block hash of is the -byte string
taken over the whole header serialisation, and included, in internal byte order, the order in which the hash function outputs its bytes. Let be the conversion of protocol specification, §“nBits conversion”. The header satisfies proof of work when is a valid Equihash solution for and
(protocol specification, §“Difficulty filter”). The consensus rules further require, for a block at height , that , the value the difficulty-adjustment rule of protocol specification, §“Difficulty adjustment” assigns to that height.
The definition follows protocol specification, §“Block Header Encoding and Consensus” for the field table and its consensus rules, and ZIP 221, “Block header semantics and consensus rules” and ZIP 244 for the renaming of the commitment field. The hash is registered in the Crypto Guide, §“The transparent layer’s hashes”. The Equihash condition is cited, not reconstructed: Consensus Guide, §“Equihash and the memoryless model”. The work of a block whose header carries is
and the total work of a chain is the sum of the work of its blocks; a node considers the valid chain of greatest total work to be best, breaking ties between leaf blocks in favour of the block received first (Consensus Guide, §“The block tree and the most-work rule”, and its subsection §“Work, and the best chain”; protocol specification, §“The Block Chain” and §“Definition of Work”).
The fixed-width fields of Definition 2.3 occupy bytes. Since , the field occupies bytes, and with the -byte solution a Zcash block header is bytes, of which the solution is , about per cent.
A claimed chain of length is a sequence of block headers in which is the header of the genesis block; header is the header at height . Given one or more claimed chains, a simplified-payment-verification (SPV) client downloads every header of every claimed chain and checks, for each chain :
linkage: for , the field of equals ;
proof of work: for , header satisfies proof of work in the sense of Definition 2.3, and its field equals , computed from .
It rejects every chain that fails a check and accepts, among the rest, the chain of greatest total work , under the best-chain rule of the Consensus Guide, §“Work, and the best chain”.
The definition is that of ePrint 2019/226, Section 1, p. 2, instantiated with the header checks of protocol specification, §“Block Header Encoding and Consensus”. For a claimed chain of blocks the client receives headers, bytes, so its communication is . A block is at most bytes (same section), so the saving over downloading full blocks is at most a constant factor, not an asymptotic one.
An SPV client checks neither the validity of transactions nor any consensus rule beyond those of the header, and therefore relies on the following assumption.
“The chain with the most PoW solutions follows the rules of the network and will eventually be accepted by the majority of miners.” (ePrint 2019/226, Section 1, p. 2, Assumption 1.)
ZIP 307 (Draft) specifies a light-client protocol in which a light client obtains, from a Zcash node and a proxy, compact blocks: per-block messages that may carry the block header. The trust model is stated in ZIP 307, “Security Model”: the node and proxy combination is assumed to be “honest but curious” and “is trusted to provide a correct view of the current best chain state and to faithfully transmit queries and responses”.
ZIP 307, “Block header validation” describes, as a proposed enhancement that the ZIP records as only partially implemented (only check (Z2) is made), checks of the SPV kind on each compact block that carries a header. With the fields named as in Definition 2.3, the checks are:
the field is at least the minimum block version;
the field equals the block hash of the previous compact block;
the Equihash solution is valid;
the target is non-zero and at most the proof-of-work limit (protocol specification, §“Constants”);
when the last compact blocks all carry headers, the field is correct under the difficulty-adjustment rule;
the block hash, read as a little-endian integer, is at most .
In that proposal, a compact block that fails a check MUST be discarded. The same section of ZIP 307 further describes a check that the commitment field equals the root of the Sapling note commitment tree recomputed from the compact block; from Heartwood that check no longer applies, since the field changes meaning (Definition 2.3; ZIP 221, “Block header semantics and consensus rules”). Checks (Z1) to (Z6), where made on every header, cost communication linear in the chain length , as in Definition 2.4.
Of the trust that ZIP 307 places in the node and proxy, a FlyClient verifier would replace only the trust in which header chain carries the most work, under Assumption 4.8 (“The -adversary”). It would replace the linear header checks by the logarithmic sampling of “The FlyClient protocol” (§5); it does not replace faithful transmission of queries and of compact-block contents. Such a verifier is designed but unspecified in the sense of Definition 1.3; its status is fixed in “A Zcash verifier” (§7.4).
The problem is the following. Under the SPV assumption (Assumption 2.5), strengthened quantitatively as Assumption 4.8 in “The -adversary” (§4.3), a light client is to accept the head of the chain of greatest total work after communication sublinear in the chain length . The inputs and the chain to be selected are those of Definition 2.4; the assumption is strengthened to Assumption 4.8, the selection holds except with a failure probability fixed in “The FlyClient protocol” (§5), and the communication falls from to sublinear.
A client that does not check every proof of work “can be tricked into accepting an invalid chain by a malicious prover who can precompute a sufficiently-long chain using its limited computational power” (ePrint 2019/226, Section 1, p. 3); the adversary is fixed in “The FlyClient security model” (§4).
The solution uses four objects. A Merkle mountain range is a binary hash tree over a sequence that admits appending a leaf without changing its peaks or any node beneath them (“Merkle mountain ranges”, §3). A header chain commitment is a root, carried in every header after the genesis header, of such a range over all blocks strictly before that header (“Header chain commitments and per-sample checks”, §5.1). A work-weighted sample is a block drawn at a random point of cumulative work and checked against the commitment of the head (“The sampling distribution”, §5.4). A suffix of the chain is downloaded and checked in full, its extent fixed in the same subsection. FlyClient is the protocol that verifies a proof-of-work chain by drawing logarithmically many such samples and checking each against the commitment of the head (ePrint 2019/226, Section 1). The commitment of the paper covers the chain from the genesis block, whereas the commitment of ZIP 221 covers one upgrade epoch: the blocks from the activation height of the preceding network upgrade up to the committing block, exclusive (ZIP 221, “Specification”; “Upgrade epochs and epoch trees”, §6.2).