This section defines the burn set and the OrchardZSA bundle that it completes (§5.1); constructs the binding validating key, which subtracts the burnt amounts Asset by Asset (§5.2); and proves that a verifying binding signature forces per-Asset balance whenever every witnessed Asset Base and every Asset Base of a burn pair is a group-hash output at a suitably distinct input (§5.3). The premise on the bases concerns a single bundle; it is discharged for valid chains in “Security” (§9). The constructions are taken from ZIP 226 and ZIP 227, both Draft. The Orchard binding signature that they extend is that of the Ironwood Guide, §“The binding signature”, and is cited, not restated.
Burn destroys a stated amount of a Custom Asset (Definition 1.5): it sends nothing to any address, lowers the amount of the Asset in circulation, and publishes the Asset Base and the amount, so that the destruction is publicly verifiable. A burn set is a finite set of pairs with and . The author of a transaction adds one pair for each Custom Asset that the transaction burns, being the amount burnt. The constant
bounds the amount of one Custom Asset burnt in one transaction, so that every burnt amount is representable in a signed -bit balance field. A burn set is valid when it satisfies the following rules.
For every pair, : the Native Asset Base (Definition 2.15), of ZEC and of TAZ alike, is never burnt.
For every pair, .
Every Asset Base occurs in at most one pair. The burnt amount of a point is therefore well defined: the of the pair with , or if there is none.
Rules (B1) to (B3) constrain the pairs only. Rule (B1) excludes the one point and no other, and no rule requires to be the Asset Base of an issued Asset. The state rule that a burn cannot exceed the amount of the Asset in circulation is ZIP 227’s; it is rule (T4) of Construction 7.3, in “State transition of a transaction” (§7.2) (ZIP 226, “Burn Mechanism”, “Additional Consensus Rules for the assetBurn set” and “Rationale for MAX_BURN_VALUE”; ZIP 227, “Specification: Consensus Rule Changes”). Class: specified; the carrier of the burn set is stated in “Transaction formats” (§8.1).
The OrchardZSA bundle of a transaction consists of at most one Action Group (Definition 4.13), one burn set satisfying (B1) to (B3), one balancing value and one binding signature. It extends the Ironwood Guide’s Definition “Bundle” by the burn set; its anchor, flags and proof are those of the Action Group. ZIP 226 places one burn set in the transaction, and ZIP 227 limits the transaction to at most one Action Group, so the two readings coincide (ZIP 226, “Burn Mechanism”; ZIP 227, “Specification: Consensus Rule Changes”). Class: the structure is specified; its encoding, one burn set per Action Group in withdrawn ZIP 230, belongs to the carrier and is classified in Remark 8.1.
ZIPs 226 and 227 leave the transparent protocol unchanged and single-asset. Transparent inputs and outputs, and the Ironwood Guide’s transparent transaction value pool (Definition “Transparent transaction value pool”), carry the Native Asset only; Custom Assets have no transparent value pool and cannot be unshielded by a transfer. ZIP 226 conditions this on future consensus changes, which no ZIP specifies (ZIP 226, “Burn Mechanism”, note; “Rationale for Value Balance Verification”: “All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer”). Structurally, the binding validating key of the next subsection (Definition 5.4) has, besides the Actions’ net value commitments, only the balancing value at and one burn term per pair; a non-zero net amount of a Custom Asset in a bundle can therefore be absorbed only by a burn pair of that Asset. The computational statement is Proposition 5.6. Class: specified.
Let an OrchardZSA bundle have Actions with net value commitments (Definition 3.8), trapdoors , balancing value and burn set . The binding signing key is unchanged:
(Ironwood Guide, Definition “Binding signing key”). The verifier computes, from public fields only, the binding validating key
where the subtracted points are the zero-trapdoor commitments
each signed integer entering as its residue modulo . Against the Ironwood Guide’s Definition “Binding validating key” two things are new: the bases of the Actions’ commitments vary, being the witnessed Asset Bases, and one burn term is subtracted per pair.
The balancing value keeps the meaning of the Ironwood Guide’s Definitions “Transparent transaction value pool” and “Balancing value”: the net flow of ZEC between the pool and the transparent transaction value pool, a signed integer in . It enters at only. Its meaning rests on the key of ZIP 226; its encoding, the field valueBalanceOrchard of withdrawn ZIP 230, belongs to the carrier.
The binding signature is that of the Ironwood Guide’s Construction “Binding signature”, the binding-signature instance of RedPallas on the base (Ironwood Guide, §“The RedPallas signature scheme”): the author signs with , and the verifier MUST validate the signature on under . Here is the signature digest of the transaction (Ironwood Guide, Definition “Signature digest”) as modified for OrchardZSA; the modifications and their class are stated in “Transaction digests and the signature message” (§8.2, Remark 8.3) (ZIP 226, “Value Balance Verification” and “Value Commitment”; protocol specification, §“Balance and Binding Signature (Orchard)”). Class: specified; the signed message is not.
For an honestly constructed bundle each equals , by condition A4′ of Definition 4.6. By the additive homomorphism (Crypto Guide, §“The Pedersen commitment”, Theorem “Additive homomorphism”), the trapdoor terms sum to , and the value terms group by Asset Base. When the net values of each Custom Asset sum to its burnt amount and those of ZEC to , every value term cancels, so , the pair is a key pair of the instance, and the honest signature is accepted, as in the paragraph after the Ironwood Guide’s Construction “Binding signature”. In the notation of ZIP 226, with the indices of the Actions of Custom Assets, a correctly constructed bundle satisfies
(ZIP 226, “Rationale for Value Balance Verification”). For a Split Action , so the value of the copied note never enters : the commitment cancels against the value of the notes of the same Asset consumed by real spends in other Actions (ZIP 226, “Split Notes”).
The key is computed from the Actions’ commitments, the balancing value and the burn set, and of these only the burn set names an Asset, by publishing each burnt Asset Base with its amount. The hiding of the Actions’ Asset Bases is Theorem 9.11, in “Security”.
Let . For let and be integers in and a point. Let satisfy (B2) and (B3), with burnt amounts , and let be an integer in . For a point put
rule (B1) giving for a valid burn set. If , then as an integer.
The hypotheses hold for every OrchardZSA bundle of a valid block. Every Action carries its own -byte nullifier (Ironwood Guide, Definition “Action description”; protocol specification, §“Action Description Encoding and Consensus”), and a block, hence a transaction, holds at most bytes (protocol specification, §“Block Header Encoding and Consensus”), so
whatever the carrier. The values are -bit by Definition 3.1, with by the notation of Definition 4.6; burnt amounts are bounded by (B2), and the balancing value by Definition 5.4. No carrier-specific bound on the number of Actions is needed. Status (Definition 1.3): proved here; conditional on no unspecified object.
The argument is that of the Ironwood Guide’s Lemma “Modular balance is integer balance”. Each difference has absolute value at most , and . For , rule (B2) gives , so
for , with ,
the upper end of the range in the protocol specification, §“Balance and Binding Signature (Orchard)”. Both bounds are below (Ironwood Guide, §“Fields, groups, and encodings”; protocol specification, §“Pallas and Vesta”). The hypothesis makes a multiple of , the order of the Pallas group, and the only such multiple of absolute value below is . □
The protocol specification’s argument in §“Balance and Binding Signature (Orchard)” bounds the number of Actions by through a separate consensus rule, which it notes is redundant given the MB transaction size limit; the lemma uses the block size itself.
Fix an OrchardZSA bundle as in Definition 5.4, and let be the set of points consisting of , the Asset Bases of the Actions and the Asset Bases of the burn pairs. An opening of is a triple of a point , an integer and a scalar with
For openings, is defined for as in Lemma 5.5, with in place of and in place of . The set meets the premise on the bases when every other than is given with an input of such that and differs from the inputs of and of . As in the Ironwood Guide, a binding signature under a point is a signature valid under in the binding-signature instance of RedPallas.
For the bundle fixed above:
Identity. If for every , and , then
hence for every implies .
Knowledge. Given openings of every and with ,
If meets the premise on the bases and some is non-zero modulo , this is a non-trivial relation among values of at distinct inputs.
Consequently, under the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas”, “GroupHash as a random oracle” and “The RedPallas hash as a random oracle”, an efficient party that outputs a bundle whose set meets the premise on the bases, openings of every net value commitment and a binding signature under the resulting on a message of its choice satisfies for every , and knows , except with negligible probability. The statement holds for every message and does not depend on the signed message.
Under Assumption 4.9 in addition, let an efficient adversary output OrchardZSA bundles of valid blocks, hence with at most Actions each, whose Action proofs and binding signatures verify and whose witnessed and burn-pair Asset Bases meet the premise on the bases. Then, except with negligible probability, as integers:
for every Asset Base , , which is when is not burnt;
;
no burn pair has an Asset Base that no Action witnesses;
the signer knows the trapdoor sum .
Here , , and are read from the extracted witnesses. Status (Definition 1.3): proved here for the specified ; conditional on Assumption 4.9, which concerns the designed but unspecified circuit, and not on Assumption 6.13. The premise on the bases is discharged for every accepted bundle of a valid chain only in “Security”, in Theorem 9.5: for witnessed bases by Corollary 9.4, for burn-pair bases by rule (T4) of Construction 7.3 and Lemma 7.7. ZIP 226 argues per-Asset balance in rationale only (“Rationale for Value Balance Verification”), and that argument stays designed but unspecified.
(i) Expand each and apply the additive homomorphism (Crypto Guide, §“The Pedersen commitment”, Theorem “Additive homomorphism”):
By (B3) each Asset Base of a burn pair occurs in exactly one subtracted term , and by (B1) none of them is , whose only subtracted term is . Subtracting these terms as in Definition 5.4 and grouping by base gives the identity. If every vanishes modulo , the right-hand side is .
(ii) With the openings in place of the honest values, the same grouping gives ; equating with gives the relation. Its coefficients are scalars modulo . Under the premise, the base is the value at its input, and each other at . The points of are pairwise distinct, so the chosen inputs are pairwise distinct, one per point; two distinct inputs with one value would themselves be a relation of the same kind. The inputs differ from that of , by the premise and since the inputs of and differ in the message. A non-zero makes the relation non-trivial.
Consequence. Let an efficient party output, with probability , a bundle meeting the premise, openings, a message and a binding signature on it under the resulting , with some non-zero modulo ; the event is efficiently decidable from the output. The value is extracted exactly as in the proof of the Ironwood Guide’s Proposition “Balance and key knowledge”: if , then ; otherwise special soundness with forking in the random-oracle model for the RedPallas hash yields with (Crypto Guide, §“Binding signatures as a proof of knowledge of a discrete logarithm”, Theorem “The binding signature is a proof of knowledge of ”). Key prefixing places in the critical query, so the openings and the bases of the first run satisfy the hypothesis of part (ii) for it. Part (ii) then outputs a non-trivial relation among values of at distinct inputs, which the Ironwood Guide’s Lemma “Relations among fixed generators” excludes except with negligible probability; so is negligible. In the model of that volume’s Assumption “GroupHash as a random oracle” the inputs may equally be read from the queries of : a point that equals the value at an input never queried occurs with probability at most for each point. For Asset Bases of Custom Assets, Lemma 2.8 places every input under z.cash:OrchardZSA apart from those of and . When every vanishes, the relation reduces to , and has prime order , so .
Bundles. The adversary outputs polynomially many bundles, and the union bound reduces the claim to one of them, as in the proof of the Ironwood Guide’s Theorem “Balance”. The algorithm that runs the adversary with the extractor of Assumption 4.9 outputs, for that bundle, the triples read from the witnesses; by A4′ of Definition 4.6 each is an opening of , except with the negligible probability that a witness fails the relation. The bundle’s binding signature verifies on under , so the algorithm is a party of the consequence, and every vanishes modulo and , which is (d). The hypotheses of Lemma 5.5 hold for the witnesses, the bundle being in a valid block, and the lemma lifts each congruence to an equality of integers, which is (a) and (b). A burn pair of base that no Action witnesses has , with by (B2), so ; this is (c). □
The premise on the bases cannot be dropped, for witnessed bases or for the bases of burn pairs. For witnessed bases this is Proposition 4.1. For burn pairs, let be the Asset Base of an issued Asset and . Split Actions of base contribute , so Actions of base whose net values sum to create units of from nothing. The pair satisfies (B2) and (B3), and (B1) unless , a relation that Lemma “Relations among fixed generators” of the Ironwood Guide excludes except with negligible probability. With balancing value and , Definitions 3.8 and 5.4 give
whose discrete logarithm the author knows, so the binding signature verifies. Likewise, with balancing value , ZEC Actions whose net values sum to and the pair give
an amount of zatoshi of ZEC appears from nothing, and (B1) does not exclude the pair, since in a group of odd order. Rule (B1) excludes only ; the premise on burn-pair bases is discharged by the issuance state, through rule (T4) of Construction 7.3 and Lemma 7.7, not by the burn rules (ZIP 226, “Rationale for Split Notes”, on inputs that are a multiple or linear combination of an existing Asset Base; ZIP 226, “Additional Consensus Rules for the assetBurn set”).
ZIP 226, “Rationale for Value Balance Verification”, states that the relation between and holds “if and only if”, per Custom Asset, the net values sum to the burnt amount ( if absent) and, for ZEC, to the balancing value, and that the commitments “add up homomorphically only with respect to the same value base point”. Neither is a literal statement about the Pallas group. The group is cyclic of prime order (protocol specification, §“Pallas and Vesta”), so any two non-identity bases satisfy for some ; commitments to distinct bases add homomorphically as group elements; and has non-zero solutions . The “if” direction is part (i) of Proposition 5.6. The “only if” direction holds computationally, for group-hash bases and an efficient signer, as part (ii) and its consequence prove, and then as integers by Lemma 5.5. The argument of the ZIP is rationale and keeps its class (Definition 1.3).