Wallet Guide The Zcash wallet layer: keys, transactions, and light-client synchronisation 3 Addresses and viewing keys (ZIP 316)5 The light-client service

4 Compact blocks (ZIP 307)

This section states the compact block as an abstract message format: the records of a block and of a transaction, the compact outputs, spends and Actions and the fields they omit, the compact variant of trial decryption with the soundness of accepting a plaintext that no tag authenticates, and the placement of notes in the note commitment trees from per-block tree sizes. The service that delivers compact blocks is the subject of “The light-client service” (§5).

4.1 The compact block and the compact transaction

A compact block carries only the data of a block that a wallet needs to detect payments to its addresses, to detect spends of its notes and to maintain the witnesses of its notes (ZIP 307, “Compact Stream Format”); for the transparent pool it carries, on request, the data needed to detect spends of the wallet’s transparent coins.

Remark 4.1 (Normative status of the compact format).

ZIP 307, “Compact Stream Format”, “Output Compression” and “Spend Compression”, specifies the compact format for the Sapling pool only: a compact block of height, block hash and transactions, and a compact transaction of index, transaction identifier, spends and outputs. It names neither the Orchard pool nor the Ironwood pool, nor per-block tree sizes, nor transparent data. ZIP 318 and ZIP 326 address light wallets and specify no compact format. The remainder of the format below (the parent hash of a block, the tree sizes, the compact Actions of both Orchard-protocol pools, the transparent part and pool selection) is designed but unspecified (Definition 1.1). The volume states the format as an abstract message format, not as a serialisation, and states no field number, field width or encoded size. The status of each ZIP cited is that of Table 1.

Definition 4.2 (Compact block).

A compact block of height $h$ is a tuple

\mathit{CB}=(h,\,\mathsf{hash},\,\mathsf{prevHash},\,\mathsf{hdr},\,\mathsf{% vtx},\,S)

where

1.

$h\in\mathbb{N}$ is the block height;
2.

$\mathsf{hash}$ and $\mathsf{prevHash}$ are the $32$ -byte hashes of the block and of its parent block (protocol specification, §“Block Header Encoding and Consensus”);
3.

$\mathsf{hdr}$ is either the encoded block header or empty; the abstract format does not guarantee that it is present;
4.

$\mathsf{vtx}=(\mathit{ctx}_{0},\dots,\mathit{ctx}_{m-1})$ is the sequence of compact transactions (Definition 4.3) of the block, in block order;
5.

$S=(S^{\mathsf{Sapling}},S^{\mathsf{Orchard}},S^{\mathsf{Ironwood}})$ gives, for each shielded pool $\mathsf{pool}$ , the number $S^{\mathsf{pool}}$ of leaves of that pool’s note commitment tree after every transaction of the block has been appended, written $S^{\mathsf{pool}}_{\mathsf{end}}(h)$ .

Each $S^{\mathsf{pool}}$ is an integer in $[0,2^{32}]$ , where $2^{32}$ is the leaf capacity of a tree of depth $\mathsf{MerkleDepth}^{\mathsf{Sapling}}=\mathsf{MerkleDepth}^{\mathsf{Orchard}% }=32$ (Ironwood Guide, §“The Merkle hash and the tree”, Definition “Note commitment tree”; protocol specification, §“Constants”). The width of any serialisation of $S^{\mathsf{pool}}$ lies outside the abstract format.

Definition 4.3 (Compact transaction).

A compact transaction is a tuple

\mathit{ctx}=(i,\,\mathsf{txid},\,\mathit{SSp},\,\mathit{SOut},\,A^{\mathsf{% Orchard}},\,A^{\mathsf{Ironwood}},\,T)

where

1.

$i\in\mathbb{N}$ is the index of the transaction in its block;
2.

$\mathsf{txid}$ is the $32$ -byte transaction identifier in protocol byte order, the form in which it is computed, not the byte-reversed form used for display (Ironwood Guide, §“Transaction digests and signatures”, Definition “Transaction identifier”; protocol specification, §“Transaction Identifiers”);
3.

$\mathit{SSp}$ and $\mathit{SOut}$ are the sequences of compact Sapling spends and compact Sapling outputs, and $A^{\mathsf{Orchard}}$ and $A^{\mathsf{Ironwood}}$ the sequences of compact Actions of the Orchard pool and of the Ironwood pool (Definition 4.5), each in the order of the transaction’s descriptions, on which note positions depend (§4.4);
4.

$T$ is an optional transparent part $(O_{\mathsf{in}},O_{\mathsf{out}})$ : $O_{\mathsf{in}}$ is the sequence of outpoints $(\mathsf{txid}^{\prime},n)$ spent by the transaction’s transparent inputs, in input order, and $O_{\mathsf{out}}$ the sequence of pairs $(\mathsf{value},\mathsf{script})$ of its transparent outputs, in output order, with $\mathsf{value}$ in zatoshi.

The coinbase transaction of a block is its first transaction and the one whose single transparent input has a null previous outpoint (protocol specification, §“Coinbase Transactions”); it spends no outpoint, its $O_{\mathsf{in}}$ is empty, and it is recognised by $i=0$ . No fee field is part of the abstract format.

Definition 4.4 (Pool selection).

Let $\mathcal{P}\subseteq\{\mathsf{transparent},\mathsf{Sapling},\mathsf{Orchard},% \mathsf{Ironwood}\}$ . The compact block restricted to $\mathcal{P}$ is obtained from a compact block by keeping, in each compact transaction, only the components of the pools in $\mathcal{P}$ ( $\mathit{SSp}$ and $\mathit{SOut}$ for Sapling, the sequence $A^{\mathsf{pool}}$ for an Orchard-protocol pool, and $T$ only when $\mathsf{transparent}\in\mathcal{P}$ ), and by omitting every compact transaction left with no component. The tuple $S$ is kept whole, and a compact block is returned for every block of a requested range, possibly with empty $\mathsf{vtx}$ . The default is $\mathcal{P}=\{\mathsf{Sapling},\mathsf{Orchard},\mathsf{Ironwood}\}$ . The range query of “The query interface” (§5.2) takes $\mathcal{P}$ as an argument. Pool selection is designed but unspecified (Definition 1.1); ZIP 307 includes by default only the transactions that have Sapling spends or outputs (ZIP 307, “Block header validation”).

For every shielded pool in $\mathcal{P}$ the restriction keeps every commitment of that pool in its order, since an omitted compact transaction has no component of the pool. The per-pool counts and offsets of Definition 4.11 are therefore the same on a restricted block as on the unrestricted one.

4.2 Compact outputs, spends, and Actions

Definition 4.5 (Compact spend, output, and Action).

Let $C_{\mathsf{enc}}$ be the note ciphertext of a Sapling output or of an Action: $580$ bytes, the encryption of the $564$ -byte note plaintext followed by the $16$ -byte tag. Its split at the offsets $52$ and $564$ is that of the Ironwood Guide, §“Transaction digests and signatures”, Definition “Transaction identifier”.

(a)

A compact Sapling spend is the $32$ -byte nullifier $\mathsf{nf}$ of a Spend description.
(b)

A compact Sapling output is the triple $(\mathsf{cmu},\mathsf{ephemeralKey},C_{\mathsf{enc}}[0{:}52])$ , a payload of $32+32+52=116$ bytes.
(c)

A compact Action, of the Orchard pool and of the Ironwood pool alike, is the tuple $(\mathsf{nf},\mathsf{cmx},\mathsf{ephemeralKey},C_{\mathsf{enc}}[0{:}52])$ , a payload of $32+32+32+52=148$ bytes.

Parts (a) and (b) are specified (ZIP 307, “Output Compression” and “Spend Compression”); part (c) is designed but unspecified (Definition 1.1). The fields are those of the protocol specification, §“Spend Description Encoding and Consensus”, §“Output Description Encoding and Consensus” and §“Action Description Encoding and Consensus”. Only payload sizes are stated; the size of any serialisation lies outside the abstract format.

The nullifier $\mathsf{nf}$ of a compact Action has two roles. It detects a spend of the note that the Action consumes, and it is the element $\rho$ of the note that the Action creates (Ironwood Guide, §“Nullifier chaining”, Construction “Chaining rule”), an input of $\mathsf{esk}$ , $\psi$ and $\mathsf{rcm}$ and hence of the commitment that acceptance recomputes (Definition 4.9). A compact Action without $\mathsf{nf}$ therefore cannot be accepted.

A compact block omits the memo $C_{\mathsf{enc}}[52{:}564]$ , the tag $C_{\mathsf{enc}}[564{:}580]$ , the outgoing ciphertext $C_{\mathsf{out}}$ , value commitments, randomised validating keys, anchors, proofs and signatures (ZIP 307, “Output Compression”, “Spend Compression” and “Transaction privacy”). Recovery of a memo or of an outgoing plaintext requires the full transaction, fetched by its identifier (“Leakage of transaction queries”, §8.4).

Proposition 4.6 (Sufficiency of the compact fields).

Let $\mathit{CB}$ be a compact block of height $h$ , and let a wallet hold incoming viewing keys and the nullifiers of its notes.

(i)

Receipt detection, that is compact decryption and acceptance of an output (§4.3), is a function of the key, of $h$ , and of the record $(\mathsf{cmu},\mathsf{ephemeralKey},C_{\mathsf{enc}}[0{:}52])$ of a Sapling output or $(\mathsf{nf},\mathsf{cmx},\mathsf{ephemeralKey},C_{\mathsf{enc}}[0{:}52])$ of an Action.
(ii)

Spend detection is a function of the fields $\mathsf{nf}$ of $\mathit{SSp}$ , $A^{\mathsf{Orchard}}$ and $A^{\mathsf{Ironwood}}$ .
(iii)

Note placement is a function of the order of the commitments in $\mathsf{vtx}$ and of $S$ (§4.4).

No field omitted by the compact block enters (i) to (iii).

Proof.

(i) Trial decryption and acceptance read the ephemeral key, the ciphertext prefix that encrypts the lead byte, diversifier, value and note seed, the commitment, the height through the admissible lead bytes, and, for an Action, $\mathsf{nf}$ as $\rho$ (Ironwood Guide, §“Trial decryption and note acceptance”, Constructions “Trial decryption” and “Acceptance of an Ironwood-pool output”; ZIP 307, “Scanning for relevant transactions” for Sapling); the memo and the tag enter only the full decryption. (ii) A spend of a note is detected by membership of its nullifier among the published ones (ZIP 307, “Detecting spends”). (iii) The chain appends each pool’s commitments in block, transaction and description order to the least unused leaf (Ironwood Guide, §“The Merkle hash and the tree”, Definition “Note commitment tree”; protocol specification, §“Note Commitment Trees”), so positions follow from that order and a tree size. □

The omitted fields serve the verification of the chain, which the client delegates to the server; that delegation and its assumption are stated in “Architecture and authority” (§5.1).

4.3 Compact trial decryption

Trial decryption and acceptance of full outputs are those of the Ironwood Guide, §“Trial decryption and note acceptance” (Constructions “Trial decryption” and “Acceptance of an Ironwood-pool output”), cited and not re-derived. This subsection states the compact variant.

Definition 4.7 (Compact note plaintext).

The compact note plaintext is the tuple $\mathsf{np}_{\mathsf{c}}=(\mathsf{leadByte},d,v,\mathsf{rseed})$ , encoded as

\mathsf{leadByte}\,\|\,\mathsf{LEBS2OSP}_{88}(d)\,\|\,\mathsf{I2LEOSP}_{64}(v)% \,\|\,\mathsf{rseed},

of $1+11+8+32=52$ bytes: the note plaintext of the Ironwood Guide, §“The note plaintext”, Definition “Note plaintext”, without its memo (protocol specification, §“Note Plaintexts and Memo Fields” and §“Encodings of Note Plaintexts and Memo Fields”). The AEAD encryption is a stream-cipher encryption followed by a tag, so $C_{\mathsf{enc}}[0{:}52]$ is the encryption of exactly these $52$ bytes, which are the contents and the opening of the note commitment (ZIP 307, “Output Compression”).

Construction 4.8 (Compact decryption of an output).

Input: an incoming viewing key $\mathsf{ivk}$ of the pool’s protocol and a compact output or compact Action with fields $\mathsf{ephemeralKey}$ and $c=C_{\mathsf{enc}}[0{:}52]$ .

1.

Compute $\mathsf{epk}:=\mathsf{abst}(\mathsf{ephemeralKey})$ on the pool’s curve, $\mathsf{abst}_{\mathbb{J}}$ on Jubjub for Sapling and $\mathsf{abst}_{\mathbb{P}}$ on Pallas for either Orchard-protocol pool; return $\bot$ if $\mathsf{epk}=\bot$ .
2.

Compute $K:=\mathsf{KDF}(\mathsf{KA.Agree}(\mathsf{ivk},\mathsf{epk}),\mathsf{% ephemeralKey})$ with the key agreement and key derivation of the pool’s protocol.
3.

Compute $\mathsf{np}_{\mathsf{c}}:=c\oplus\mathrm{KS}_{1}(K,0^{96},52)$ , where $\mathrm{KS}_{1}(K,0^{96},52)$ is the first $52$ bytes of the ChaCha20 keystream under key $K$ and the all-zero nonce $0^{96}$ of the protocol specification, §“Symmetric Encryption”, starting at block counter $1$ , the counter from which ChaCha20-Poly1305 encrypts (block $0$ yields the Poly1305 key; Crypto Guide, §“The ChaCha20-Poly1305 AEAD”, Construction “ChaCha20-Poly1305”; RFC 8439, §2.8); equivalently, bytes $64$ to $115$ of the keystream from counter $0$ .
4.

Return $\mathsf{np}_{\mathsf{c}}$ parsed as a compact note plaintext (Definition 4.7).

The tag is never checked. The result is a candidate, not an accepted note (ZIP 307, “Scanning for relevant transactions”).

Definition 4.9 (Acceptance of a compact candidate).

Let $\mathsf{np}_{\mathsf{c}}=(\mathsf{leadByte},d,v,\mathsf{rseed})$ be the candidate returned by Construction 4.8 under $\mathsf{ivk}$ for an output of pool $\mathsf{pool}$ in a compact block of height $h$ . Let $H_{\mathsf{C}}$ be the Canopy activation height and $\mathsf{ZIP212GracePeriod}=32{,}256$ blocks (protocol specification, §“Constants”). The set of admissible lead bytes is

\mathsf{allowedLeadBytes}^{\mathsf{pool}}(h):=\begin{cases}\{\mathtt{0x01}\}&% \text{if }h<H_{\mathsf{C}},\\ \{\mathtt{0x01},\mathtt{0x02}\}&\text{if }H_{\mathsf{C}}\leq h<H_{\mathsf{C}}+% \mathsf{ZIP212GracePeriod},\\ \{\mathtt{0x02}\}&\text{otherwise, if }\mathsf{pool}\neq\mathsf{Ironwood},\\ \{\mathtt{0x03}\}&\text{otherwise}\end{cases}

(protocol specification, §“Note Plaintexts and Memo Fields”), so that an Orchard-pool note has lead byte $\mathtt{0x02}$ and an Ironwood-pool note $\mathtt{0x03}$ . The wallet accepts $\mathsf{np}_{\mathsf{c}}$ if and only if every check passes:

(i)

$\mathsf{leadByte}\in\mathsf{allowedLeadBytes}^{\mathsf{pool}}(h)$ ; for Sapling, moreover, $\mathsf{rcm}<r_{\mathbb{J}}$ and $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)\neq\bot$ , with $\mathsf{rcm}:=\mathsf{rseed}$ read as an integer for lead byte $\mathtt{0x01}$ ;
(ii)

with $\mathsf{pk_{d}}:=[\mathsf{ivk}]\,\mathsf{g_{d}}$ , and with $\rho:=\mathsf{nf}$ of the same Action for either Orchard-protocol pool, the note commitment recomputed from $(\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi,\mathsf{rcm})$ , where $\psi$ and $\mathsf{rcm}$ are derived from $\mathsf{rseed}$ as the pool and the lead byte prescribe ( $\rho$ and $\psi$ absent for Sapling), is not $\bot$ and extracts to the record’s $\mathsf{cmu}$ (Sapling) or $\mathsf{cmx}$ (either Orchard-protocol pool);
(iii)

for every lead byte other than $\mathtt{0x01}$ , the field $\mathsf{ephemeralKey}$ equals the encoding of $[\mathsf{esk}]\,\mathsf{g_{d}}$ , with $\mathsf{esk}$ re-derived from $\mathsf{rseed}$ , and from $\rho$ for either Orchard-protocol pool.

The accepted note is $n=((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ without memo, with $\rho$ and $\psi$ absent for a Sapling note. The derivations of $\psi$ , $\mathsf{rcm}$ and $\mathsf{esk}$ are cited and not restated: for Sapling and the Orchard pool to the protocol specification, §“Decryption using an Incoming Viewing Key (Sapling and Orchard)” (ZIP 212, “Changes to the process of sending Sapling or Orchard notes”); for the Ironwood pool to the Ironwood Guide, §“Trial decryption and note acceptance”, Construction “Acceptance of an Ironwood-pool output”, whose checks (i), (ii) with (iv), and (iii) are checks (i), (ii) and (iii) here (ZIP 2005, “Changes to the Protocol Specification”). The method of comparison is not part of the rule.

Check (iii) is a step of the specification’s decryption procedure and of ZIP 307, not an addition (ZIP 212, “Changes to the process of receiving Sapling or Orchard notes”). For an Ironwood-pool note it is made directly after the computation of $\mathsf{g_{d}}$ , in the order of ZIP 2005. Without it a sender could agree the key with one address of a recipient while naming the diversifier of another, and link the two addresses by observing acceptance (Ironwood Guide, §“Trial decryption and note acceptance”, Remark “Role of check (iii)”; ZIP 212, “Motivation”). A Sapling note with lead byte $\mathtt{0x01}$ , created under the rules before ZIP 212, skips check (iii), since its $\mathsf{esk}$ is not derivable from $\mathsf{rseed}$ .

For a note $n$ the commitment input is the pair of committed values and trapdoor from which check (ii) computes its commitment: $((\mathsf{g_{d}},\mathsf{pk_{d}},v),\mathsf{rcm})$ for Sapling and $((\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi),\mathsf{rcm})$ for either Orchard-protocol pool. An address of $\mathsf{ivk}$ is a pair $(d,[\mathsf{ivk}]\,\mathsf{DiversifyHash}(d))$ with $\mathsf{DiversifyHash}(d)\neq\bot$ .

Proposition 4.10 (Soundness of compact acceptance).

Let $\mathit{cm}^{*}$ be the commitment, $\mathsf{cmu}$ or $\mathsf{cmx}$ , that a compact output or compact Action carries.

(a)

Every note $n$ accepted by Definition 4.9 is an opening of $\mathit{cm}^{*}$ . For every efficient sender, which chooses $\mathsf{ephemeralKey}$ , $C_{\mathsf{enc}}$ and the keys under which they are formed, the probability that the wallet accepts $n$ while the sender outputs a note $n^{\prime}$ whose commitment input differs from that of $n$ and whose commitment extracts to $\mathit{cm}^{*}$ is negligible, under the binding of the pool’s note commitment scheme. The tag of the AEAD gives no integrity against the sender, who holds $K$ , so its omission loses none.
(b)

For an output honestly formed for a note $n^{\prime}$ whose address is not an address of $\mathsf{ivk}$ , the probability that $\mathsf{ivk}$ accepts a candidate is negligible under the same assumption.

Whether $\mathit{cm}^{*}$ is the commitment of an output of the best chain is not a property of decryption; it is settled under the assumption of “Architecture and authority” (§5.1).

Proof.

(a) Check (ii) recomputes the commitment of $n$ deterministically from its commitment input and compares it with $\mathit{cm}^{*}$ , whatever the ciphertext and whichever key decrypted it, so $n$ opens $\mathit{cm}^{*}$ . Consider the algorithm that generates the wallet’s key, runs the sender and the compact decryption and acceptance, and outputs the commitment inputs of $n$ and $n^{\prime}$ . When the event of (a) occurs it outputs two distinct commitment inputs whose commitments extract to the same $\mathit{cm}^{*}\neq\bot$ . For either Orchard-protocol pool this is excluded, except with negligible probability, by the argument of the Ironwood Guide, §“Trial decryption and note acceptance”, Proposition “Consistency of accepted notes”, part (c), under Proposition “Hiding and binding of note commitments” (§“Note commitments”). That proof uses neither the integrity of ChaCha20-Poly1305 nor key commitment, so it applies unchanged to a candidate decrypted from the $52$ -byte prefix; and binding holds for every $\mathsf{rcm}$ , hence also for the trapdoor derivation of the Orchard pool. For Sapling the named assumption is the computational binding of $\mathsf{NoteCommit}^{\mathsf{Sapling}}$ , the security requirement of the protocol specification, §“Windowed Pedersen commitments”, together with the injectivity of $\mathsf{Extract}_{\mathbb{J}^{(r)}}$ on $\mathbb{J}^{(r)}$ (protocol specification, §“Coordinate Extractor for Jubjub”).

(b) Let $n$ be accepted. By check (ii) its address is $(d,[\mathsf{ivk}]\,\mathsf{g_{d}})$ with $\mathsf{g_{d}}=\mathsf{DiversifyHash}(d)\neq\bot$ , an address of $\mathsf{ivk}$ . Suppose the commitment inputs of $n$ and $n^{\prime}$ were equal. Then the diversified base $\mathsf{DiversifyHash}(d^{\prime})$ of the address $(d^{\prime},\mathsf{pk_{d}}^{\prime})$ of $n^{\prime}$ equals $\mathsf{g_{d}}$ , and $\mathsf{pk_{d}}^{\prime}=[\mathsf{ivk}]\,\mathsf{g_{d}}=[\mathsf{ivk}]\,% \mathsf{DiversifyHash}(d^{\prime})$ , so $(d^{\prime},\mathsf{pk_{d}}^{\prime})$ is an address of $\mathsf{ivk}$ , contrary to the hypothesis. The commitment inputs therefore differ, and the honest sender outputs $n^{\prime}$ , whose commitment extracts to $\mathit{cm}^{*}$ ; the honest sender is an efficient sender of (a), which bounds the probability. □

4.4 Note positions and tree sizes

For each shielded pool, every note commitment of a block, not only those of the wallet’s notes, is appended to the wallet’s copy of that pool’s note commitment tree in block order, transaction order and description order: $\mathsf{cmx}$ of each Action of the pool and $\mathsf{cmu}$ of each Sapling output (ZIP 307, “Creating and updating note witnesses”; Ironwood Guide, §“The Merkle hash and the tree”, Definition “Note commitment tree”; protocol specification, §“Note Commitment Trees”). The leaf of each accepted note is marked for witness retention. The part of the tree a wallet must retain is fixed in “Commitment-tree synchronisation” (§7).

Definition 4.11 (Note position).

Let $\mathsf{pool}$ be a shielded pool, $b$ a block height with compact block $\mathit{CB}$ , and $n_{\mathsf{pool}}(b)$ the number of commitments of $\mathsf{pool}$ in $\mathit{CB}$ . The start size of $b$ is

S^{\mathsf{pool}}_{\mathsf{start}}(b):=\begin{cases}S^{\mathsf{pool}}_{\mathsf% {end}}(b-1)&\text{if the wallet knows it},\\ 0&\text{otherwise, if }b\text{ lies below the activation of }\mathsf{pool},\\ S^{\mathsf{pool}}_{\mathsf{end}}(b)-n_{\mathsf{pool}}(b)&\text{otherwise},\end% {cases}

the wallet knowing $S^{\mathsf{pool}}_{\mathsf{end}}(b-1)$ when it holds the compact block of height $b-1$ or a tree state of $\mathsf{pool}$ at the end of $b-1$ ; in the third case the value is taken from $\mathit{CB}$ alone, and the block is rejected if it is negative. For the $j$ -th output $o$ of $\mathsf{pool}$ , counted from $j=0$ , of a compact transaction $\mathit{ctx}$ of $b$ ,

\mathsf{position}(o):=S^{\mathsf{pool}}_{\mathsf{start}}(b)+\mathsf{off}(% \mathit{ctx})+j,

where $\mathsf{off}(\mathit{ctx})$ is the number of commitments of $\mathsf{pool}$ in the compact transactions of $b$ before $\mathit{ctx}$ . Positions are per pool. A block scanned out of order thus places its notes from its own compact block. Note positions are designed but unspecified (Definition 1.1).

For a pool outside the pool set $\mathcal{P}$ of the query that returned $b$ , the count $n_{\mathsf{pool}}(b)$ is not served, and neither position nor check is defined.

The position of a note is the leaf index of its commitment (Ironwood Guide, §“The Merkle hash and the tree”, Definition “Note commitment tree”, item 1). Every spend needs it for the authentication path. A Sapling nullifier depends on it, through $\rho=\mathsf{MixingPedersenHash}(\mathsf{cm},\mathsf{pos})$ (protocol specification, §“Computing $\rho$ values and Nullifiers”), while the nullifier of an Orchard-protocol note does not.

Lemma 4.12 (Consistency of tree sizes).

Let the wallet reject a block $b$ unless, for each shielded pool of the pool set $\mathcal{P}$ of the query that returned $b$ ,

S^{\mathsf{pool}}_{\mathsf{end}}(b)\geq n_{\mathsf{pool}}(b)\quad\text{and}% \quad S^{\mathsf{pool}}_{\mathsf{start}}(b)+n_{\mathsf{pool}}(b)=S^{\mathsf{% pool}}_{\mathsf{end}}(b).

(a)

If every reported size is the true size, no block is rejected, and every position of Definition 4.11 is the leaf index of the commitment in the pool’s tree.
(b)

A reported $S^{\mathsf{pool}}_{\mathsf{end}}(b)$ that is inconsistent with the block’s own commitment count, or with the known end size of $b-1$ , is rejected.
(c)

A block with $n_{\mathsf{pool}}(b)>0$ and reported size $0$ is rejected. A size read as zero therefore yields a position only where $0$ is consistent with the block, and the check needs no means of telling an absent size from zero.
(d)

A size that is false but consistent with both conditions is not detected; its exclusion is clause (a) of the server assumption of “Architecture and authority” (§5.1).

Proof.

(a) The chain appends the commitments of a pool in block, transaction and description order, each to the least unused index (Ironwood Guide, §“The Merkle hash and the tree”, Definition “Note commitment tree”). The true start size of $b$ is thus the true end size of $b-1$ , which equals $S^{\mathsf{pool}}_{\mathsf{end}}(b)-n_{\mathsf{pool}}(b)\geq 0$ , so both conditions hold in every case of the start size; and the $j$ -th commitment of $\mathit{ctx}$ lands at index $S^{\mathsf{pool}}_{\mathsf{start}}(b)+\mathsf{off}(\mathit{ctx})+j$ . (b) A size $S^{\mathsf{pool}}_{\mathsf{end}}(b)<n_{\mathsf{pool}}(b)$ fails the first condition. With a known start size, a size that differs from $S^{\mathsf{pool}}_{\mathsf{start}}(b)+n_{\mathsf{pool}}(b)$ fails the second. (c) A size $0$ with $n_{\mathsf{pool}}(b)>0$ fails the first condition. (d) Let the wallet not know the end size of $b-1$ , and let $b$ lie at or above the activation of $\mathsf{pool}$ , so that its start size is that of the third case of Definition 4.11. Adding one integer $\delta\neq 0$ to $S^{\mathsf{pool}}_{\mathsf{end}}(b)$ and to the end sizes of all later scanned blocks, such that every shifted size stays in $[0,2^{32}]$ and at least the count of its block, preserves both conditions for $b$ , whose start size is computed from its own end size, and for every later block, whose start and end sizes shift by $\delta$ together. □

Comparison of the running position with $S^{\mathsf{pool}}_{\mathsf{end}}(b)$ identifies the last commitment of $\mathsf{pool}$ in $b$ , at position $S^{\mathsf{pool}}_{\mathsf{end}}(b)-1$ . The tree after that commitment, or for $n_{\mathsf{pool}}(b)=0$ the tree at the end of $b-1$ , is the tree state at the end of $b$ . Its root is the anchor that a later spend against height $b$ uses (Ironwood Guide, §“Anchors”; protocol specification, §“Transactions and Treestates”), and the wallet records it as a candidate anchor.