ZSA Guide Zcash Shielded Assets: asset identity, issuance, transfer, and burn 9 Security

10 Classification of the components

This section collects the classes that the preceding sections assign. It tabulates the class of every construction of the volume under Definition 1.2 and the unspecified objects on which every result is conditional under Definition 1.3 (§10.1), and it enumerates the open problems, each with the texts that leave it open and the obligation that closes it (§10.2). No class is derived here; each is the one stated where the construction or result is made.

10.1 Classes of the constructions and results

Remark 10.1 (Reading of the table).

Each row of the first part of Table 7 is a construction, or a named part of one, with the subsection that states it; the rows are grouped by their class under Definition 1.2. “Specified” means specified by Draft text: no ZIP of OrchardZSA is Final and no network upgrade includes one (item (1) of “Open problems”, §10.2). The second part lists every theorem, proposition, lemma and corollary of the volume. A result carries no class (Definition 1.3); its row states only the unspecified objects that its hypotheses concern, and the rows are grouped by those objects. The standing assumptions of “Accepted transactions and assumptions” (§9.1) on specified primitives, namely the group hash, discrete logarithms on Pallas, BLAKE2b, RedPallas, $\mathsf{IssueAuthSig}$ , note encryption, Poseidon as a PRF, PRF expansion and the joint hiding of the viewing keys, are not repeated per row.

The reading of condition A8 has a group of its own. ZIP 226 leaves conditions A8 and A9 unchanged by its delta, so A8 reads $v^{\mathsf{old}}$ and A9 reads $v^{\mathsf{new}}$ , and a Split Action that copies a note of non-zero value needs $\mathsf{enableSpends}=1$ ; this is specified by the delta. The confirmation of that reading in the circuit document outside the ZIPs is designed but unspecified (Remark 4.7).

Construction	Subsection
Specified (Draft text)
Issuance key pair, $\mathsf{IssueAuthSig}$ , issuer and signature encodings	§2.1
Asset description, Asset Identifier and its encoding	§2.2
Asset Digest, Asset Base and its byte encoding	§2.3
Rejection of an issuance whose derived Asset Base is the identity, by typing (Remark 2.12)	§2.3
Native Asset Base	§2.4
OrchardZSA note	§3.1
OrchardZSA note commitment	§3.2
Derivation of $\psi$	§3.3
Field set of the OrchardZSA note plaintext	§3.4
Per-Asset value commitment	§3.5
Split Inputs, Split Actions and the padding rule	§4.1
Split-nullifier formula, a sender rule that no condition of the statement enforces (Remark 4.8)	§4.2
Statement delta: conditions A1^′ to A5^′ and C1 to C3 against A1 to A9, with A8 and A9 unchanged and reading $v^{\mathsf{old}}$ and $v^{\mathsf{new}}$	§4.3
Structure of the Action Group	§4.5
Burn set, rules (B1) to (B3), structure of the OrchardZSA bundle	§5.1
Binding validating key; its signed message excepted	§5.2
Issue Note; the rule that validators compute its commitment	§6.1
Issuance Action and Issuance Bundle	§6.2
Derivation of issued $\rho$ values	§6.3
Reference note	§6.4
Rules (I1) to (I3); the signed message excepted	§6.5
Global issuance state and its chaining	§7.1
Transition rules (T1) to (T4) and (I4) to (I7); insertion order of note commitments	§7.2
Finalisation	§7.3
Checks of the verification procedure, each carrier tagged with its own class	§7.4
Specified by the delta; realisation designed but unspecified
Reading of A8 on $v^{\mathsf{old}}$ : specified; its confirmation in the circuit document outside the ZIPs designed but unspecified	§4.3
Designed but unspecified
OrchardZSA circuit, its verifying key and the proof length it determines	§4.4
Derivation of $\mathsf{rcm}$ , up to its lead byte	§3.3
Withdrawn transaction layouts, read as a composition of the constructions	§8.1
Withdrawn transaction-identifier and signature digests, and the signature message $\mathsf{SigHash}$ they define (the authorising-data digest excepted, Remark 8.1(ii))	§8.2, §6.5
ZSA fee terms	§8.3
Rationale arguments of the ZIPs for the properties proved in “Security”	§9
Open problem (item of “Open problems”)
(1) Network upgrade; activation block of the issuance state	§7.1
(2) Value of the lead byte	§3.3
(3) Live carrier: encodings, digests, signature message, and the bit and instance position of $\mathsf{enableZSA}$	§8.1, §8.2
(4) Carrying pool (Remark 1.7)	§1.3
(5) Composition of the delta with A10 and $\mathsf{disableCrossAddress}$	§4.3
(6) Empty Issuance Action for a new Asset	§7.2
(7) Issue Note whose commitment is $\bot$	§6.1
(8) Encoding of the note plaintext	§3.4

Table 7: Classification of the OrchardZSA components, first part: every construction with its class under Definition 1.2 and the subsection that states it. “Specified” means specified by Draft ZIP text.

Result	Number
Conditional on no unspecified object
Proposition “Uniqueness of Asset Identifiers”	2.7
Lemma “Distinctness of the OrchardZSA group-hash inputs”	2.8
Lemma “Non-identity of derived Asset Bases”	2.11
Proposition “Separation of Asset Bases”	2.13
Proposition “Hiding and binding of OrchardZSA note commitments”, stated for uniform $\mathsf{rcm}$	3.3
Lemma “Hiding and binding of per-Asset value commitments”	3.9
Proposition “Unsoundness of the dummy exemption under a witnessed base”	4.1
Proposition “Independence of split nullifiers”; part (ii) for senders that follow the sender rule	4.5
Lemma “Modular per-Asset balance is integer balance”	5.5
Proposition “Unlinkability of spends of Issue Notes”	6.4
Proposition “Uniqueness of issued rho values”	6.9
Lemma “Keys of the issuance state”	7.7
Proposition “Finalised supply never grows”	7.8
Proposition “The recorded balance”	7.9
Conditional on an open case
Lemma “First-issuance detection”: on item (6)	7.6
Proposition “Reference notes as universal Split Inputs”, part (a): on item (2), the lead byte	6.11
Conditional on the circuit, through Assumption 4.9
Proposition “Ownership of Split Inputs”	4.12
Proposition “Per-Asset balance and key knowledge”	5.6
Proposition “Reference notes as universal Split Inputs”, part (b), on zero-valued outputs, through Proposition 5.6	6.11
Conditional on the circuit, through Assumption 4.9, and, for leaves of Issue Notes, on a fixed derivation of $\mathsf{rcm}$
Lemma “Provenance of Asset Bases”	9.3
Lemma “One consumption per OrchardZSA note”	9.6
Theorem “Supply integrity”	9.7
Corollary “Asset Bases of accepted Actions”, through Lemma 9.3	9.4
Theorem “No counterfeiting across Assets”, through Lemma 9.3	9.5
Conditional on the signed message, through Assumption 6.13
Proposition “Replay protection of issuance”	6.16
Theorem “Issuance authority”	9.8
Conditional on the circuit, through Assumption 4.10, on the lead byte and on the plaintext encoding
Theorem “Privacy of the Asset type”	9.11

Table 7: Classification of the OrchardZSA components, second part: every result of the volume, grouped by the unspecified objects that its hypotheses concern (Definition 1.3). Standing assumptions on specified primitives are omitted.

The groups of the second part read as follows. A fixed derivation of $\mathsf{rcm}$ for Issue Notes is needed only so that the validator’s commitment is computable; any deterministic derivation from the published fields suffices (Definition 1.3), and the corollary and the theorem that use Lemma 9.3 carry that qualification only through it. Theorem 9.11 needs the lead byte for $\mathsf{rcm}$ to be uniform as a pseudorandom output, and the plaintext encoding to have a length independent of the Asset; both are open, items (2) and (8). No result is conditional on the carrier otherwise than through Assumption 6.13.

10.2 Open problems

Each item below is an open problem in the sense of Definition 1.2: no text supplies a design, every existing design conflicts with live text, or live texts contradict one another. Each item names the texts that leave it open and the obligation that closes it.

(1)

Network upgrade. ZIP 226, “Deployment”, names NU7; ZIP 227, “Deployment”, reads “TBD”. ZIP 259 (Draft), which specifies NU7, lists its consensus changes without either ZIP (“NU7 consensus changes”) and introduces no transaction format (“Rationale for no new transaction format”); ZIP 258, which specifies NU6.3, mentions neither. Consequently the first block of OrchardZSA, whose input issuance state is the empty map (Definition 7.1), is not assigned. Closed by a deployment ZIP that includes ZIPs 226 and 227.
(2)

Value of the lead byte of OrchardZSA notes and Issue Notes. ZIP 226, “Note Structure and Commitment”, fixes only the placeholder $\{\{\mathsf{ZSALEADBYTE}\}\}$ ; ZIP 2005, “Usage with other proposals requiring note plaintext format changes”, requires a new lead byte for plaintext changes; and the removed design’s $\mathtt{0x03}$ is the Ironwood lead byte in live text (protocol specification, §“Note Plaintexts and Memo Fields”; Remark 3.6). Consequently the commitment of an Issue Note is not computable from live text (Remark 6.2). Closed by an assignment of the value and an extension of $\mathsf{Derive\_rcm}$ to it.
(3)

Live carrier. ZIP 226, “OrchardZSA Transaction Structure”, and ZIP 227 defer the encodings to ZIP 230, and ZIP 226, “Sighash modifications relative to ZIP 244”, and ZIP 227, “Modifications relative to ZIP 244”, defer the signature message to ZIP 246; both are Withdrawn. Version $6$ is the format of ZIP 229, which carries no ZSA bundle, and ZIP 248 lists OrchardZSA and ZSA Issuance only as potential bundle types without an allocated type (Remarks 8.1 and 8.3). The flag $\mathsf{enableZSA}$ has no bit and no instance position in any current format: the withdrawn design places it at bit $2$ of $\mathsf{flagsOrchard}$ , which the consensus rules of ZIP 229 reserve and require to be $0$ , the format table of that ZIP naming the bit $\mathsf{enableCrossAddress}$ . Closed by a live format that encodes the OrchardZSA bundle, the Issuance Bundle and $\mathsf{enableZSA}$ , with a signature digest that meets Remark 8.2.
(4)

Carrying pool. ZIP 226, “Backward Compatibility”, places OrchardZSA notes in the Orchard pool, which ZIP 258, “Consensus rules from NU6.3 activation”, closes to new value and to cross-address transfers from NU6.3 (Remark 1.7). The rules of that pool then forbid transfers of Custom Assets between distinct addresses, leave issuance into it unaddressed, and leave undetermined the tree that Definition 7.4 extends. Closed by a reconciliation of ZIP 226 with ZIP 258 that names the pool and its rules.
(5)

Composition of the delta with condition A10. ZIP 226, “Circuit Statement”, states its delta against A1 to A9; the current statement adds condition A10 and the primary input $\mathsf{disableCrossAddress}$ (Ironwood Guide, Definition “Orchard Action statement”; Remark 4.7). Closed by a statement text that includes both, which depends on the resolution of item (4).
(6)

Empty Issuance Action for a new Asset. For an Issuance Action without Issue Notes on an Asset Base without a reference note, rule (I5) refers to a first Issue Note that does not exist, so its validity, finalising or not, is undetermined (ZIP 227, “Specification: Consensus Rule Changes”; Remark 7.5). Lemma 7.6 is conditional on this case. Closed by a rule that rejects such an action or fixes its effect on the issuance state.
(7)

Issue Note whose commitment is $\bot$ . The protocol specification, §“Sending Notes (Orchard)”, makes a sent note whose commitment is $\bot$ invalid and resamples $\mathsf{rseed}$ , which covers sent notes only; ZIP 227, “Issue Note”, states no rule (Remark “Commitment $\bot$ for an Issue Note” in §6.1). The event has negligible probability. Closed by a rule: resampling by the issuer or rejection by validators.
(8)

Encoding of the OrchardZSA note plaintext. The field set is specified (Definition 3.7); ZIP 226, “Note Structure and Commitment”, delegates the encoding to ZIP 230, which is Withdrawn. Theorem 9.11 is conditional on it. Closed by a live encoding whose length does not depend on the Asset.

Remark 10.2 (Items not open).

Four items are not open problems. The bound on the number of Actions that Lemma 5.5 needs, at most $62\,500<2^{16}$ Actions per transaction, follows from the block-size rule (protocol specification, §“Block Header Encoding and Consensus”) whatever the carrier. The ZSA fee terms (Remark 8.4), the derivation of $\mathsf{rcm}$ (Remark 3.6) and the OrchardZSA proof length (Remark 4.11) are designed but unspecified, as the first part of Table 7 records: each has a design that no live text contradicts. ZIP 227 and ZIP 317 disagree about the fee terms, which the protocol does not need (Remark 8.4).