forked from zcash/zips
-
Notifications
You must be signed in to change notification settings - Fork 0
/
zip-0227.html
988 lines (988 loc) · 78.9 KB
/
zip-0227.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
<!DOCTYPE html>
<html>
<head>
<title>ZIP 227: Issuance of Zcash Shielded Assets</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 227
Title: Issuance of Zcash Shielded Assets
Owners: Pablo Kogan <pablo@qed-it.com>
Vivek Arte <vivek@qed-it.com>
Daira-Emma Hopwood <daira-emma@electriccoin.co>
Jack Grigg <str4d@electriccoin.co>
Credits: Daniel Benarroch
Aurelien Nicolas
Deirdre Connolly
Teor
Status: Draft
Category: Consensus
Created: 2022-05-01
License: MIT
Discussions-To: <<a href="https://github.com/zcash/zips/issues/618">https://github.com/zcash/zips/issues/618</a>>
Pull-Request: <<a href="https://github.com/zcash/zips/pull/680">https://github.com/zcash/zips/pull/680</a>></pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 <a id="footnote-reference-1" class="footnote_reference" href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200 <a id="footnote-reference-2" class="footnote_reference" href="#zip-0200">7</a>.</p>
<p>The terms "Orchard" and "Action" in this document are to be interpreted as described in ZIP 224 <a id="footnote-reference-3" class="footnote_reference" href="#zip-0224">8</a>.</p>
<p>We define the following additional terms:</p>
<ul>
<li>Asset: A type of note that can be transferred on the Zcash blockchain. Each Asset is identified by an Asset Identifier <a href="#specification-asset-identifier">Specification: Asset Identifier</a>.
<ul>
<li>ZEC is the default (and currently the only defined) Asset for the Zcash mainnet.</li>
<li>TAZ is the default (and currently the only defined) Asset for the Zcash testnet.</li>
<li>We use the term "Custom Asset" to refer to any Asset other than ZEC and TAZ.</li>
</ul>
</li>
<li>Native Asset: a Custom Asset with issuance defined on the Zcash blockchain.</li>
<li>Wrapped Asset: a Custom Asset with native issuance defined outside the Zcash blockchain.</li>
<li>Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset Identifier.</li>
<li>Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.</li>
</ul>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP (ZIP 227) proposes the Zcash Shielded Assets (ZSA) protocol, in conjunction with ZIP 226 <a id="footnote-reference-4" class="footnote_reference" href="#zip-0226">9</a>. This protocol is an extension of the Orchard protocol that enables the creation, transfer and burn of Custom Assets on the Zcash chain. The creation of such Assets is defined in this ZIP (ZIP 227), while the transfer and burn of such Assets is defined in ZIP 226 <a id="footnote-reference-5" class="footnote_reference" href="#zip-0226">9</a>. This ZIP must only be implemented in conjunction with ZIP 226 <a id="footnote-reference-6" class="footnote_reference" href="#zip-0226">9</a>. The proposed issuance mechanism is only valid for the Orchard-ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP introduces the issuance mechanism for Custom Assets on the Zcash chain. While originally part of a single ZSA ZIP, the issuance mechanism turned out to be substantial enough to stand on its own and justify the creation of this supporting ZIP for ZIP 226 <a id="footnote-reference-7" class="footnote_reference" href="#zip-0226">9</a>.</p>
<p>This ZIP only enables <em>transparent</em> issuance. As a first step, transparency will allow for proper testing of the applications that will be most used in the Zcash ecosystem, and will enable the supply of Assets to be tracked.</p>
<p>The issuance mechanism described in this ZIP is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import Wrapped Assets. This enables what we hope will be a useful set of applications.</p>
</section>
<section id="use-cases"><h2><span class="section-heading">Use Cases</span><span class="section-anchor"> <a rel="bookmark" href="#use-cases"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The design presented in this ZIP enables issuance of shielded Assets in various modes:</p>
<ul>
<li>The issuer may or may not know the receivers of the issued Asset in advance.</li>
<li>The Asset can be of non-fungible type, where each Asset type can be made part of a single “series”.</li>
<li>The supply of the Asset can be limited in advance or not.</li>
<li>The Asset can be a wrapped version of an Asset issued by another chain (as long as there is a bridge that supports transfer of that Asset between chains).</li>
</ul>
<p>See the <a href="#concrete-applications">Concrete Applications</a> section for more details.</p>
</section>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>Any user of the Zcash blockchain can issue Custom Assets on chain.</li>
<li>The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash blockchain.</li>
<li>Issuing or changing the attributes of a specific Asset should require cryptographic authorization.</li>
<li>The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset Identifier.</li>
<li>An issuer should be able to issue different Assets in the same transaction. In other words, in a single "issuance bundle", the issuer should be able publish many "issuance actions", potentially creating multiple Custom Assets.</li>
<li>Every "issuance action" should contain a
<span class="math">\(\mathsf{finalize}\)</span>
boolean that defines whether the specific Custom Asset can have further tokens issued or not.</li>
</ul>
</section>
<section id="specification-issuance-keys-and-issuance-authorization-signature-scheme"><h2><span class="section-heading">Specification: Issuance Keys and Issuance Authorization Signature Scheme</span><span class="section-anchor"> <a rel="bookmark" href="#specification-issuance-keys-and-issuance-authorization-signature-scheme"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The Orchard-ZSA Protocol adds the following keys to the key components <a id="footnote-reference-8" class="footnote_reference" href="#protocol-addressesandkeys">18</a> <a id="footnote-reference-9" class="footnote_reference" href="#protocol-orchardkeycomponents">19</a>:</p>
<ol type="1">
<li>The issuance authorizing key, denoted as
<span class="math">\(\mathsf{isk}\!\)</span>
, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer.</li>
<li>The issuance validating key, denoted as
<span class="math">\(\mathsf{ik}\!\)</span>
, is the key that is used to validate issuance transactions. This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer.</li>
</ol>
<p>The relations between these keys are shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="450" src="zip-0227-key-components-zsa.png" alt="" />
<figcaption>Diagram of Issuance Key Components for the Orchard-ZSA Protocol</figcaption>
</figure>
<section id="issuance-authorization-signature-scheme"><h3><span class="section-heading">Issuance Authorization Signature Scheme</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-authorization-signature-scheme"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>We instantiate the issuance authorization signature scheme
<span class="math">\(\mathsf{IssueAuthSig}\)</span>
as a BIP-340 Schnorr signature over the secp256k1 curve. The signing and validation algorithms, signature encoding, and public key encoding MUST follow BIP 340 <a id="footnote-reference-10" class="footnote_reference" href="#bip-0340">16</a>.</p>
<p>Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results; for example, for a given verification key
<span class="math">\(pk\)</span>
and
<span class="math">\(\mathit{lift\_x}(\mathit{int}(pk))\)</span>
MAY be precomputed.</p>
<p>We define the constants as per the secp256k1 standard parameters, as described in BIP 340.</p>
<p>The associated types of the
<span class="math">\(\mathsf{IssueAuthSig}\)</span>
signature scheme are as follows:</p>
<ul>
<li>
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Message} = \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}\)</span>
</li>
<li>
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Signature} = \mathbb{B}^{\mathbb{Y}^{[64]}} \cup \{\bot\}\)</span>
</li>
<li>
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Public} = \mathbb{B}^{\mathbb{Y}^{[32]}} \cup \{\bot\}\)</span>
</li>
<li>
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Private} = \mathbb{B}^{\mathbb{Y}^{[32]}}\)</span>
</li>
</ul>
<p>where
<span class="math">\(\mathbb{B}^{\mathbb{Y}^{[k]}}\)</span>
denotes the set of sequences of
<span class="math">\(k\)</span>
bytes, and
<span class="math">\(\mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}\)</span>
denotes the type of byte sequences of arbitrary length, as defined in the Zcash protocol specification <a id="footnote-reference-11" class="footnote_reference" href="#protocol-notation">17</a>.</p>
<p>The issuance authorizing key generation algorithm and the issuance validating key derivation algorithm are defined in the <a href="#issuance-key-derivation">Issuance Key Derivation</a> section, while the corresponding signing and validation algorithms are defined in the <a href="#issuance-authorization-signing-and-validation">Issuance Authorization Signing and Validation</a> section.</p>
</section>
<section id="issuance-key-derivation"><h3><span class="section-heading">Issuance Key Derivation</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-key-derivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="issuance-authorizing-key-generation-for-hierarchical-deterministic-wallets"><h4><span class="section-heading">Issuance authorizing key generation for hierarchical deterministic wallets</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-authorizing-key-generation-for-hierarchical-deterministic-wallets"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The issuance authorizing key is generated using the Orchard master key derivation procedure defined in ZIP 32 <a id="footnote-reference-12" class="footnote_reference" href="#zip-0032-orchard-master">3</a>. We reuse the functions defined there in what follows in this section.</p>
<p>Let
<span class="math">\(S\)</span>
be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes. We define the master extended issuance key
<span class="math">\(m_{\mathsf{Issuance}} := \mathsf{MasterKeyGen}(\texttt{"ZIP32ZSAIssue_V1"}, S)\!\)</span>
.</p>
<p>As in ZIP 32 for Orchard <a id="footnote-reference-13" class="footnote_reference" href="#zip-0032-orchard-child-key-derivation">4</a>, we only use hardened child key derivation for the issuance authorizing key. We reuse the
<span class="math">\(\mathsf{CDKsk}\)</span>
function for Orchard child key derivation from ZIP 32.</p>
<p>We use the notation of ZIP 32 <a id="footnote-reference-14" class="footnote_reference" href="#zip-0032-orchard-key-path">6</a> for shielded HD paths, and define the issuance authorizing key path as
<span class="math">\(m_{\mathsf{Issuance}} / \mathit{purpose}' / \mathit{coin\_type}' / \mathit{account}'\!\)</span>
. We fix the path levels as follows:</p>
<ul>
<li>
<span class="math">\(\mathit{purpose}\)</span>
: a constant set to
<span class="math">\(227\)</span>
(i.e.
<span class="math">\(\mathtt{0xe3}\!\)</span>
).
<span class="math">\(\mathit{purpose}'\)</span>
is thus
<span class="math">\(227'\)</span>
(or
<span class="math">\(\mathtt{0x800000e3}\!\)</span>
) following the BIP 43 recommendation.</li>
<li>
<span class="math">\(\mathit{coin\_type}\)</span>
: Defined as in ZIP 32 <a id="footnote-reference-15" class="footnote_reference" href="#zip-0032-key-path-levels">5</a>.</li>
<li>
<span class="math">\(\mathit{account}\)</span>
: fixed to index
<span class="math">\(0\!\)</span>
.</li>
</ul>
<p>From the generated
<span class="math">\((\mathsf{sk}, \mathsf{c})\!\)</span>
, we set the issuance authorizing key to be
<span class="math">\(\mathsf{isk} := \mathsf{sk}\!\)</span>
.</p>
</section>
<section id="derivation-of-issuance-validating-key"><h4><span class="section-heading">Derivation of issuance validating key</span><span class="section-anchor"> <a rel="bookmark" href="#derivation-of-issuance-validating-key"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Define
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{DerivePublic}\; : \; (\mathsf{isk}\; : \; \mathsf{IssueAuthSig}.\!\mathsf{Private}) \to \mathsf{IssueAuthSig}.\!\mathsf{Public}\)</span>
as:</p>
<ul>
<li>
<span class="math">\(\mathsf{ik} := \textit{PubKey}(\mathsf{isk})\)</span>
</li>
<li>Return
<span class="math">\(\bot\)</span>
if the
<span class="math">\(\textit{PubKey}\)</span>
algorithm invocation fails, otherwise return
<span class="math">\(\mathsf{ik}\!\)</span>
.</li>
</ul>
<p>where the
<span class="math">\(\textit{PubKey}\)</span>
algorithm is defined in BIP 340 <a id="footnote-reference-16" class="footnote_reference" href="#bip-0340">16</a>. Note that the byte representation of
<span class="math">\(\mathsf{ik}\)</span>
is in big-endian order as defined in BIP 340.</p>
<p>It is possible for the
<span class="math">\(\textit{PubKey}\)</span>
algorithm to fail with very low probability, which means that
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{DerivePublic}\)</span>
could return
<span class="math">\(\bot\)</span>
with very low probability. If this happens, discard the keys and repeat with a different
<span class="math">\(\mathsf{isk}\!\)</span>
.</p>
<p>This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 <a id="footnote-reference-17" class="footnote_reference" href="#zip-0032">2</a>. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.</p>
</section>
</section>
<section id="issuance-authorization-signing-and-validation"><h3><span class="section-heading">Issuance Authorization Signing and Validation</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-authorization-signing-and-validation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Define
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Sign}\; : \; (\mathsf{isk}\; : \; \mathsf{IssueAuthSig}.\!\mathsf{Private}) \times (M\; : \; \mathsf{IssueAuthSig}.\!\mathsf{Message}) \to \mathsf{IssueAuthSig}.\!\mathsf{Signature}\)</span>
as:</p>
<ul>
<li>Let the auxiliary data
<span class="math">\(a = [\mathtt{0x00}]^{32}\!\)</span>
.</li>
<li>Let
<span class="math">\(\text{σ} = \mathsf{Sign}(\mathsf{isk}, M)\!\)</span>
.</li>
<li>Return
<span class="math">\(\bot\)</span>
if the
<span class="math">\(\mathsf{Sign}\)</span>
algorithm fails in the previous step, otherwise return
<span class="math">\(\text{σ}\!\)</span>
.</li>
</ul>
<p>where the
<span class="math">\(\mathsf{Sign}\)</span>
algorithm is defined in BIP 340 and
<span class="math">\(a\)</span>
denotes the auxiliary data used in BIP 340 <a id="footnote-reference-18" class="footnote_reference" href="#bip-0340">16</a>. Note that
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Sign}\)</span>
could return
<span class="math">\(\bot\)</span>
with very low probability.</p>
<p>Define
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Validate}\; : \; (\mathsf{ik}\; : \; \mathsf{IssueAuthSig}.\!\mathsf{Public}) \times (M\; : \; \mathsf{IssueAuthSig}.\!\mathsf{Message}) \times (\text{σ}\; : \; \mathsf{IssueAuthSig}.\!\mathsf{Signature}) \to \mathbb{B}\)</span>
as:</p>
<ul>
<li>Return
<span class="math">\(0\)</span>
if
<span class="math">\(\text{σ} = \bot\!\)</span>
.</li>
<li>Return
<span class="math">\(1\)</span>
if
<span class="math">\(\mathsf{Verify}(\mathsf{ik}, M, \text{σ})\)</span>
succeeds, otherwise
<span class="math">\(0\!\)</span>
.</li>
</ul>
<p>where the
<span class="math">\(\mathsf{Verify}\)</span>
algorithm is defined in BIP 340 <a id="footnote-reference-19" class="footnote_reference" href="#bip-0340">16</a>.</p>
</section>
</section>
<section id="specification-asset-identifier"><h2><span class="section-heading">Specification: Asset Identifier</span><span class="section-anchor"> <a rel="bookmark" href="#specification-asset-identifier"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>For every new Asset, there must be a new and unique Asset Identifier, denoted
<span class="math">\(\mathsf{AssetId}\!\)</span>
. We define this to be a globally unique pair
<span class="math">\(\mathsf{AssetId} := (\mathsf{ik}, \mathsf{asset\_desc})\!\)</span>
, where
<span class="math">\(\mathsf{ik}\)</span>
is the issuance key and
<span class="math">\(\mathsf{asset\_desc}\)</span>
is a byte string.</p>
<p>A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest,
<span class="math">\(\mathsf{AssetDigest}\!\)</span>
, which is simply is a
<span class="math">\(\textsf{BLAKE2b-512}\)</span>
hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each shielded protocol using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.</p>
<p>Let</p>
<ul>
<li>
<span class="math">\(\mathsf{asset\_desc}\)</span>
be the asset description, which includes any information pertaining to the issuance, and is a byte sequence of up to 512 bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.</li>
<li>
<span class="math">\(\mathsf{ik}\)</span>
be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.</li>
</ul>
<p>Define
<span class="math">\(\mathsf{AssetDigest_{AssetId}} := \textsf{BLAKE2b-512}(\texttt{"ZSA-Asset-Digest"},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))\!\)</span>
, where</p>
<ul>
<li>
<span class="math">\(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}((\mathsf{ik}, \mathsf{asset\_desc})) := \mathtt{0x00} || \mathsf{ik} || \mathsf{asset\_desc}\!\!\)</span>
.</li>
<li>Note that the initial
<span class="math">\(\mathtt{0x00}\)</span>
byte is a version byte.</li>
</ul>
<p>Define
<span class="math">\(\mathsf{AssetBase_{AssetId}} := \mathsf{ZSAValueBase}(\mathsf{AssetDigest_{AssetId}})\)</span>
</p>
<p>In the case of the Orchard-ZSA protocol, we define
<span class="math">\(\mathsf{ZSAValueBase}(\mathsf{AssetDigest_{AssetId}}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{AssetDigest_{AssetId}})\)</span>
where
<span class="math">\(\mathsf{GroupHash}^\mathbb{P}\)</span>
is defined as in <a id="footnote-reference-20" class="footnote_reference" href="#protocol-concretegrouphashpallasandvesta">20</a>.</p>
<p>The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:</p>
<figure class="align-center" align="center">
<img width="600" src="zip-0227-asset-identifier-relation.png" alt="" />
<figcaption>Diagram relating the Asset Identifier, Asset Digest, and Asset Base in the ZSA Protocol</figcaption>
</figure>
<p><strong>Note:</strong> To keep notations light and concise, we may omit
<span class="math">\(\mathsf{AssetId}\)</span>
(resp.
<span class="math">\(\mathsf{Protocol}\!\)</span>
) in the subscript (resp. superscript) when the Asset Identifier (resp. Protocol) is clear from the context.</p>
<p>Wallets MUST NOT display just the
<span class="math">\(\mathsf{asset\_desc}\)</span>
string to their users as the name of the Asset. Some possible alternatives include:</p>
<ul>
<li>Wallets could allow clients to provide an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers via a petname system. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.</li>
<li>The Asset Digest could be used as a more compact bytestring to uniquely determine an Asset, and wallets could support clients scanning QR codes to load Asset information into their wallets.</li>
</ul>
</section>
<section id="specification-global-issuance-state"><h2><span class="section-heading">Specification: Global Issuance State</span><span class="section-anchor"> <a rel="bookmark" href="#specification-global-issuance-state"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Issuance requires the following additions to the global state defined at block boundaries:</p>
<ul>
<li>
<span class="math">\(\mathsf{previously\_finalized}\!\)</span>
, a set of
<span class="math">\(\mathsf{AssetId}\)</span>
that have been finalized (i.e.: the
<span class="math">\(\mathsf{finalize}\)</span>
flag has been set to
<span class="math">\(1\)</span>
in some issuance transaction preceding the block boundary).</li>
</ul>
</section>
<section id="specification-issuance-action-issuance-bundle-and-issuance-protocol"><h2><span class="section-heading">Specification: Issuance Action, Issuance Bundle and Issuance Protocol</span><span class="section-anchor"> <a rel="bookmark" href="#specification-issuance-action-issuance-bundle-and-issuance-protocol"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="issuance-action-description"><h3><span class="section-heading">Issuance Action Description</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-action-description"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An issuance action, <code>IssueAction</code>, is the instance of issuing a specific Custom Asset, and contains the following fields:</p>
<ul>
<li><code>assetDescSize</code>: the size of the Asset description, a number between
<span class="math">\(0\)</span>
and
<span class="math">\(512\!\)</span>
, stored in two bytes.</li>
<li><code>asset_desc</code>: the Asset description, a byte string of up to 512 bytes as defined in the <a href="#specification-asset-identifier">Specification: Asset Identifier</a> section.</li>
<li><code>vNotes</code>: an array of <code>Note</code> containing the unencrypted output notes of the recipients of the Asset.</li>
<li><code>flagsIssuance</code>: a byte that stores the
<span class="math">\(\mathsf{finalize}\)</span>
boolean that defines whether the issuance of that specific Custom Asset is finalized or not.</li>
</ul>
<p>An asset's
<span class="math">\(\mathsf{AssetDigest}\)</span>
is added to the
<span class="math">\(\mathsf{previously\_finalized}\)</span>
set after a block that contains any issuance transaction for that asset with
<span class="math">\(\mathsf{finalize} = 1\!\)</span>
. It then cannot be removed from this set. For Assets with
<span class="math">\(\mathsf{AssetDigest} \in \mathsf{previously\_finalized}\!\)</span>
, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with
<span class="math">\(\mathsf{AssetDigest} \not\in \mathsf{previously\_finalized}\!\)</span>
, new issuance actions can be issued in future transactions. These must use the same Asset description,
<span class="math">\(\mathsf{asset\_desc}\!\)</span>
, and can either maintain
<span class="math">\(\mathsf{finalize} = 0\)</span>
or change it to
<span class="math">\(\mathsf{finalize} = 1\!\)</span>
, denoting that this Custom Asset cannot be issued after the containing block.</p>
<table>
<thead>
<tr>
<th>Bytes</th>
<th>Name</th>
<th>Data Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>2</code></td>
<td><code>assetDescSize</code></td>
<td><code>byte</code></td>
<td>The length of the <code>asset_desc</code> string in bytes.</td>
</tr>
<tr>
<td><code>assetDescSize</code></td>
<td><code>asset_desc</code></td>
<td><code>byte[assetDescSize]</code></td>
<td>A byte sequence of length <code>assetDescSize</code> bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.</td>
</tr>
<tr>
<td><code>varies</code></td>
<td><code>nNotes</code></td>
<td><code>compactSize</code></td>
<td>The number of notes in the issuance action.</td>
</tr>
<tr>
<td><code>noteSize * nNotes</code></td>
<td><code>vNotes</code></td>
<td><code>Note[nNotes]</code></td>
<td>A sequence of note descriptions within the issuance action, where <code>noteSize</code> is the size, in bytes, of a Note.</td>
</tr>
<tr>
<td><code>1</code></td>
<td><code>flagsIssuance</code></td>
<td><code>byte</code></td>
<td>
<dl>
<dt>An 8-bit value representing a set of flags. Ordered from LSB to MSB:</dt>
<dd>
<ul>
<li>
<span class="math">\(\mathsf{finalize}\)</span>
</li>
<li>The remaining bits are set to
<span class="math">\(0\!\)</span>
.</li>
</ul>
</dd>
</dl>
</td>
</tr>
</tbody>
</table>
<p>We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the note commitment tree as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers.</p>
</section>
<section id="issuance-bundle"><h3><span class="section-heading">Issuance Bundle</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-bundle"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An issuance bundle, <code>IssueBundle</code>, is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields:</p>
<ul>
<li>
<span class="math">\(\mathsf{ik}\)</span>
: the issuance validating key, that allows the validators to verify that the
<span class="math">\(\mathsf{AssetId}\)</span>
is properly associated with the issuer.</li>
<li><code>vIssueActions</code>: an array of issuance actions, of type <code>IssueAction</code>.</li>
<li>
<span class="math">\(\mathsf{issueAuthSig}\)</span>
: the signature of the transaction SIGHASH, signed by the issuance authorizing key,
<span class="math">\(\mathsf{isk}\!\)</span>
, that validates the issuance.</li>
</ul>
<p>The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format <a id="footnote-reference-21" class="footnote_reference" href="#protocol-txnencoding">22</a>.</p>
<table>
<thead>
<tr>
<th>Bytes</th>
<th>Name</th>
<th>Data Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>varies</code></td>
<td><code>nIssueActions</code></td>
<td><code>compactSize</code></td>
<td>The number of issuance actions in the bundle.</td>
</tr>
<tr>
<td><code>IssueActionSize * nIssueActions</code></td>
<td><code>vIssueActions</code></td>
<td><code>IssueAction[nIssueActions]</code></td>
<td>A sequence of issuance action descriptions, where IssueActionSize is the size, in bytes, of an IssueAction description.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>ik</code></td>
<td><code>byte[32]</code></td>
<td>The issuance validating key of the issuer, used to validate the signature.</td>
</tr>
<tr>
<td><code>64</code></td>
<td><code>issueAuthSig</code></td>
<td><code>byte[64]</code></td>
<td>The signature of the transaction SIGHASH, signed by the issuer, validated as in <a href="#issuance-authorization-signature-scheme">Issuance Authorization Signature Scheme</a>.</td>
</tr>
</tbody>
</table>
</section>
<section id="issuance-protocol"><h3><span class="section-heading">Issuance Protocol</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-protocol"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The issuer program performs the following operations:</p>
<p>For all actions <code>IssueAction</code>:</p>
<ul>
<li>encode
<span class="math">\(\mathsf{asset\_desc}\)</span>
as a UTF-8 byte string of size up to 512.</li>
<li>compute
<span class="math">\(\mathsf{AssetDigest}\)</span>
from the issuance validating key
<span class="math">\(\mathsf{ik}\)</span>
and
<span class="math">\(\mathsf{asset\_desc}\)</span>
as decribed in the <a href="#specification-asset-identifier">Specification: Asset Identifier</a> section.</li>
<li>compute
<span class="math">\(\mathsf{AssetBase}\)</span>
from
<span class="math">\(\mathsf{AssetDigest}\)</span>
as decribed in the <a href="#specification-asset-identifier">Specification: Asset Identifier</a> section.</li>
<li>set the
<span class="math">\(\mathsf{finalize}\)</span>
boolean as desired (if more issuance actions are to be created for this
<span class="math">\(\mathsf{AssetBase}\!\)</span>
, set
<span class="math">\(\mathsf{finalize} = 0\!\)</span>
, otherwise set
<span class="math">\(\mathsf{finalize} = 1\!\)</span>
).</li>
<li>for each recipient
<span class="math">\(i\)</span>
:
<ul>
<li>generate a ZSA output note that includes the Asset Base. For an Orchard-ZSA note this is
<span class="math">\(\mathsf{note}_i = (\mathsf{d}_i, \mathsf{pk}_{\mathsf{d}_i}, \mathsf{v}_i, \text{ρ}_i, \mathsf{rseed}_i, \mathsf{AssetBase}, \mathsf{rcm}_i)\!\)</span>
.</li>
</ul>
</li>
<li>encode the <code>IssueAction</code> into the vector <code>vIssueActions</code> of the bundle.</li>
</ul>
<p>For the <code>IssueBundle</code>:</p>
<ul>
<li>encode the <code>vIssueActions</code> vector.</li>
<li>encode the
<span class="math">\(\mathsf{ik}\)</span>
as 32 byte-string.</li>
<li>sign the SIGHASH transaction hash with the issuance authorizing key,
<span class="math">\(\mathsf{isk}\!\)</span>
, using the
<span class="math">\(\mathsf{IssueAuthSig}\)</span>
signature scheme. The signature is then added to the issuance bundle.</li>
</ul>
<p><strong>Note:</strong> that the commitment is not included in the <code>IssuanceAction</code> itself. As explained below, it is computed later by the validators and added to the note commitment tree.</p>
</section>
</section>
<section id="specification-consensus-rule-changes"><h2><span class="section-heading">Specification: Consensus Rule Changes</span><span class="section-anchor"> <a rel="bookmark" href="#specification-consensus-rule-changes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>For the <code>IssueBundle</code>:</p>
<ul>
<li>Validate the issuance authorization signature,
<span class="math">\(\mathsf{issueAuthSig}\!\)</span>
, on the SIGHASH transaction hash,
<span class="math">\(\mathsf{SigHash}\!\)</span>
, by invoking
<span class="math">\(\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{ik}, \mathsf{SigHash}, \mathsf{issueAuthSig})\!\)</span>
.</li>
</ul>
<p>For each <code>IssueAction</code> in <code>IssueBundle</code>:</p>
<ul>
<li>check that
<span class="math">\(0 < \mathtt{assetDescSize} \leq 512\!\)</span>
.</li>
<li>check that
<span class="math">\(\mathsf{asset\_desc}\)</span>
is a string of length
<span class="math">\(\mathtt{assetDescSize}\)</span>
bytes.</li>
<li>retrieve
<span class="math">\(\mathsf{AssetBase}\)</span>
from the first note in the sequence and check that
<span class="math">\(\mathsf{AssetBase}\)</span>
is derived from the issuance validating key
<span class="math">\(\mathsf{ik}\)</span>
and
<span class="math">\(\mathsf{asset\_desc}\)</span>
as described in the <a href="#specification-asset-identifier">Specification: Asset Identifier</a> section.</li>
<li>check that the
<span class="math">\(\mathsf{AssetDigest}\)</span>
does not exist in the
<span class="math">\(\mathsf{previously\_finalized}\)</span>
set in the global state.</li>
<li>check that every note in the <code>IssueAction</code> contains the same
<span class="math">\(\mathsf{AssetBase}\)</span>
and is properly constructed as
<span class="math">\(\mathsf{note} = (\mathsf{g_d}, \mathsf{pk_d}, \mathsf{v}, \text{ρ}, \mathsf{rseed}, \mathsf{AssetBase})\!\)</span>
.</li>
</ul>
<p>If all of the above checks pass, do the following:</p>
<ul>
<li>For each note, compute the note commitment as
<span class="math">\(\mathsf{cm} = \mathsf{NoteCommit^{OrchardZSA}_{rcm}}(\mathsf{repr}_{\mathbb{P}}(\mathsf{g_d}), \mathsf{repr}_{\mathbb{P}}(\mathsf{pk_d}), \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase})\)</span>
as defined in the Note Structure and Commitment section of ZIP 226 <a id="footnote-reference-22" class="footnote_reference" href="#zip-0226-notestructure">10</a> and</li>
<li>Add
<span class="math">\(\mathsf{cm}\)</span>
to the Merkle tree of note commitments.</li>
<li>If
<span class="math">\(\mathsf{finalize} = 1\!\)</span>
, add
<span class="math">\(\mathsf{AssetDigest}\)</span>
to the
<span class="math">\(\mathsf{previously\_finalized}\)</span>
set immediately after the block in which this transaction occurs.</li>
<li>(Replay Protection) If issue bundle is present, the fees MUST be greater than zero.</li>
</ul>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following is a list of rationale for different decisions made in the proposal:</p>
<ul>
<li>The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This is in order to keep the issuance details and the Asset Identifiers consistent across multiple shielded pools.</li>
<li>The design decision is not to have a chosen name to describe the Custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.</li>
<li>The
<span class="math">\(\mathsf{asset\_desc}\)</span>
is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are:
<ul>
<li>links for storage such as for NFTs.</li>
<li>metadata for Assets, encoded in any format.</li>
<li>bridging information for Wrapped Assets (chain of origin, issuer name, etc)</li>
<li>information to be committed by the issuer, though not enforceable by the protocol.</li>
</ul>
</li>
<li>We require a check whether the
<span class="math">\(\mathsf{finalize}\)</span>
flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the
<span class="math">\(\mathsf{previously\_finalized}`\)</span>
set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.</li>
<li>We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.</li>
</ul>
<section id="concrete-applications"><h3><span class="section-heading">Concrete Applications</span><span class="section-anchor"> <a rel="bookmark" href="#concrete-applications"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p><strong>Asset Features</strong></p>
<ul>
<li>By using the
<span class="math">\(\mathsf{finalize}\)</span>
boolean and the burning mechanism defined in <a id="footnote-reference-23" class="footnote_reference" href="#zip-0226">9</a>, issuers can control the supply production of any Asset associated to their issuer keys. For example,
<ul>
<li>by setting
<span class="math">\(\mathsf{finalize} = 1\)</span>
from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.</li>
</ul>
</li>
<li>Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by
<ul>
<li>issuing a last set of tokens of that specific
<span class="math">\(\mathsf{AssetId}\!\)</span>
, for which
<span class="math">\(\mathsf{finalize} = 1\!\)</span>
, or by</li>
<li>issuing a transaction with a single note in the issuance action pertaining to that
<span class="math">\(\mathsf{AssetId}\!\)</span>
, where the note will contain a
<span class="math">\(\mathsf{value} = 0\!\)</span>
. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).</li>
<li>Note in the above cases, that the setting of the
<span class="math">\(\mathsf{finalize}\)</span>
flag will take effect at the block boundary, that is, after all the transactions in the block.</li>
</ul>
</li>
<li>The issuance and burn mechanisms can be used in conjunction to determine the supply of Assets on the Zcash ecosystem. This allows for the bridging of Assets defined on other chains.</li>
<li>Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each
<span class="math">\(\mathsf{AssetId}\)</span>
corresponds to
<span class="math">\(\mathsf{value} = 1\)</span>
at the fundamental unit level. Issuers and users should make sure that
<span class="math">\(\mathsf{finalize} = 1\)</span>
for each of the actions in this scenario.</li>
</ul>
</section>
</section>
<section id="txid-digest-issuance"><h2><span class="section-heading">TxId Digest - Issuance</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest-issuance"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This section details the construction of the subtree of hashes in the transaction digest that corresponds to issuance transaction data. Details of the overall changes to the transaction digest due to the Orchard-ZSA protocol can be found in ZIP 226 <a id="footnote-reference-24" class="footnote_reference" href="#zip-0226-txiddigest">11</a>. As in ZIP 244 <a id="footnote-reference-25" class="footnote_reference" href="#zip-0244">12</a>, the digests are all personalized BLAKE2b-256 hashes, and in cases where no elements are available for hashing, a personalized hash of the empty byte array is used.</p>
<p>A new issuance transaction digest algorithm is defined that constructs the subtree of the transaction digest tree of hashes for the issuance portion of a transaction. Each branch of the subtree will correspond to a specific subset of issuance transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:</p>
<pre>issuance_digest
├── issue_actions_digest
│ ├── issue_notes_digest
│ ├── assetDescription
│ └── flagsIssuance
└── issuanceValidatingKey</pre>
<p>In the specification below, nodes of the tree are presented in depth-first order.</p>
<section id="t-5-issuance-digest"><h3><span class="section-heading">T.5: issuance_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-5-issuance-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>T.5a: issue_actions_digest (32-byte hash output)
T.5b: issuanceValidatingKey (32 bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdSAIssueHash"</pre>
<p>In case the transaction has no issuance components, ''issue_actions_digest'' is:</p>
<pre>BLAKE2b-256("ZTxIdSAIssueHash", [])</pre>
<section id="t-5a-issue-actions-digest"><h4><span class="section-heading">T.5a: issue_actions_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-issue-actions-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A BLAKE2b-256 hash of Issue Action information for all Issuance Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.5a.i : notes_digest (32-byte hash output)
T.5a.ii : assetDescription (field encoding bytes)
T.5a.iii: flagsIssuance (1 byte)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdIssuActHash"</pre>
<section id="t-5a-i-issue-notes-digest"><h5><span class="section-heading">T.5a.i: issue_notes_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-i-issue-notes-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of Note information for all Notes belonging to the Issuance Action. For each Note, the following elements are included in the hash:</p>
<pre>T.5a.i.1: recipient (field encoding bytes)
T.5a.i.2: value (field encoding bytes)
T.5a.i.3: assetBase (field encoding bytes)
T.5a.i.4: rho (field encoding bytes)
T.5a.i.5: rseed (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxIdIAcNoteHash"</pre>
<section id="t-5a-i-1-recipient"><h6><span class="section-heading">T.5a.i.1: recipient</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-i-1-recipient"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification <a id="footnote-reference-26" class="footnote_reference" href="#protocol-orchardpaymentaddrencoding">21</a>.</p>
</section>
<section id="t-5a-i-2-value"><h6><span class="section-heading">T.5a.i.2: value</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-i-2-value"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Note value encoded as little-endian 8-byte representation of 64-bit unsigned integer (e.g. u64 in Rust) raw value.</p>
</section>
<section id="t-5a-i-3-assetbase"><h6><span class="section-heading">T.5a.i.3: assetBase</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-i-3-assetbase"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Asset Base encoded as the 32-byte representation of a point on the Pallas curve.</p>
</section>
<section id="t-5a-i-4-rho"><h6><span class="section-heading">T.5a.i.4: rho</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-i-4-rho"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>Nullifier encoded as 32-byte representation of a point on the Pallas curve.</p>
</section>
<section id="t-5a-i-5-rseed"><h6><span class="section-heading">T.5a.i.5: rseed</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-i-5-rseed"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h6>
<p>The ZIP 212 32-byte seed randomness for a note.</p>
</section>
</section>
<section id="t-5a-ii-assetdescription"><h5><span class="section-heading">T.5a.ii: assetDescription</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-ii-assetdescription"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>The Asset description byte string.</p>
</section>
<section id="t-5a-iii-flagsissuance"><h5><span class="section-heading">T.5a.iii: flagsIssuance</span><span class="section-anchor"> <a rel="bookmark" href="#t-5a-iii-flagsissuance"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>An 8-bit value representing a set of flags. Ordered from LSB to MSB:</p>
<ul>
<li>
<span class="math">\(\mathsf{finalize}\)</span>
</li>
<li>The remaining bits are set to <cite>0!</cite>.</li>
</ul>
</section>
</section>
<section id="t-5b-issuancevalidatingkey"><h4><span class="section-heading">T.5b: issuanceValidatingKey</span><span class="section-anchor"> <a rel="bookmark" href="#t-5b-issuancevalidatingkey"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A byte encoding of issuance validating key for the bundle as defined in the <a href="#issuance-key-derivation">Issuance Key Derivation</a> section.</p>
</section>
</section>
</section>
<section id="signature-digest"><h2><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The per-input transaction digest algorithm to generate the signature digest in ZIP 244 <a id="footnote-reference-27" class="footnote_reference" href="#zip-0244-sigdigest">13</a> is modified so that a signature digest is produced for each transparent input, each Sapling input, each Orchard action, and additionally for each Issuance Action. For Issuance Actions, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.</p>
<p>The overall structure of the hash is as follows. We highlight the changes for the Orchard-ZSA protocol via the <code>[ADDED FOR ZSA]</code> text label, and we omit the descriptions of the sections that do not change for the Orchard-ZSA protocol:</p>
<pre>signature_digest
├── header_digest
├── transparent_sig_digest
├── sapling_digest
├── orchard_digest
└── issuance_digest [ADDED FOR ZSA]</pre>
<section id="signature-digest-1"><h3><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest-1"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>S.1: header_digest (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
S.3: sapling_digest (32-byte hash output)
S.4: orchard_digest (32-byte hash output)
S.5: issuance_digest (32-byte hash output) [ADDED FOR ZSA]</pre>
<p>The personalization field remains the same as in ZIP 244 <a id="footnote-reference-28" class="footnote_reference" href="#zip-0244">12</a>.</p>
<section id="s-5-issuance-digest"><h4><span class="section-heading">S.5: issuance_digest</span><span class="section-anchor"> <a rel="bookmark" href="#s-5-issuance-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Identical to that specified for the transaction identifier.</p>
</section>
</section>
</section>
<section id="authorizing-data-commitment"><h2><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The transaction digest algorithm defined in ZIP 244 <a id="footnote-reference-29" class="footnote_reference" href="#zip-0244-authcommitment">14</a> which commits to the authorizing data of a transaction is modified by the Orchard-ZSA protocol to have the following structure. We highlight the changes for the Orchard-ZSA protocol via the <code>[ADDED FOR ZSA]</code> text label, and we omit the descriptions of the sections that do not change for the Orchard-ZSA protocol:</p>
<pre>auth_digest
├── transparent_scripts_digest
├── sapling_auth_digest
├── orchard_auth_digest
└── issuance_auth_digest [ADDED FOR ZSA]</pre>
<p>The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.</p>
<section id="auth-digest"><h3><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest (32-byte hash output)
A.3: orchard_auth_digest (32-byte hash output)
A.4: issuance_auth_digest (32-byte hash output) [ADDED FOR ZSA]</pre>
<p>The personalization field of this hash remains the same as in ZIP 244.</p>
<section id="a-4-issuance-auth-digest"><h4><span class="section-heading">A.4: issuance_auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#a-4-issuance-auth-digest"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>In the case that Issuance Actions are present, this is a BLAKE2b-256 hash of the field encoding of the <code>issueAuthSig</code> field of the transaction:</p>
<pre>A.4a: issueAuthSig (field encoding bytes)</pre>
<p>The personalization field of this hash is set to:</p>
<pre>"ZTxAuthZSAOrHash"</pre>
<p>In the case that the transaction has no Orchard Actions, <code>issuance_auth_digest</code> is</p>
<pre>BLAKE2b-256("ZTxAuthZSAOrHash", [])</pre>
</section>
</section>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="displaying-asset-identifier-information-to-users"><h3><span class="section-heading">Displaying Asset Identifier information to users</span><span class="section-anchor"> <a rel="bookmark" href="#displaying-asset-identifier-information-to-users"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the <a href="#specification-asset-identifier">Specification: Asset Identifier</a> section.</p>
</section>
<section id="issuance-key-compromise"><h3><span class="section-heading">Issuance Key Compromise</span><span class="section-anchor"> <a rel="bookmark" href="#issuance-key-compromise"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended:</p>
<ul>
<li>If an issuance validating key is compromised, the
<span class="math">\(\mathsf{finalize}\)</span>
boolean for all the Assets issued with that key should be set to
<span class="math">\(1\)</span>
and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new
<span class="math">\(\mathsf{AssetId}\!\)</span>
.</li>
</ul>
</section>
<section id="bridging-assets"><h3><span class="section-heading">Bridging Assets</span><span class="section-anchor"> <a rel="bookmark" href="#bridging-assets"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226 <a id="footnote-reference-30" class="footnote_reference" href="#zip-0226">9</a>. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.</p>
</section>
</section>
<section id="other-considerations"><h2><span class="section-heading">Other Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#other-considerations"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<section id="implementing-zcash-nodes"><h3><span class="section-heading">Implementing Zcash Nodes</span><span class="section-anchor"> <a rel="bookmark" href="#implementing-zcash-nodes"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping
<span class="math">\(\mathsf{issuanceSupplyInfoMap}\)</span>
from
<span class="math">\(\mathsf{AssetId}\)</span>
to
<span class="math">\((\mathsf{totalSupply}, \mathsf{finalize})\)</span>
in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.</p>
</section>
<section id="fee-structures"><h3><span class="section-heading">Fee Structures</span><span class="section-anchor"> <a rel="bookmark" href="#fee-structures"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317 <a id="footnote-reference-31" class="footnote_reference" href="#zip-0317b">15</a>.</p>
</section>
</section>
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>LINK TBD</li>
</ul>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>LINK TBD</li>
<li>LINK TBD</li>
</ul>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This ZIP is proposed to activate with Network Upgrade 6.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="bcp14" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/info/bcp14">Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="zip-0032.html">ZIP 32: Shielded Hierarchical Deterministic Wallets</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032-orchard-master" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="zip-0032.html#orchard-master-key-generation">ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032-orchard-child-key-derivation" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="zip-0032.html#orchard-child-key-derivation">ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard child key derivation</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032-key-path-levels" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="zip-0032.html#key-path-levels">ZIP 32: Shielded Hierarchical Deterministic Wallets - Key path levels</a></td>
</tr>
</tbody>
</table>
<table id="zip-0032-orchard-key-path" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0032.html#orchard-key-path">ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard key path</a></td>
</tr>
</tbody>
</table>
<table id="zip-0200" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="zip-0200.html">ZIP 200: Network Upgrade Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="zip-0224" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="zip-0224.html">ZIP 224: Orchard</a></td>
</tr>
</tbody>
</table>
<table id="zip-0226" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="zip-0226.html">ZIP 226: Transfer and Burn of Zcash Shielded Assets</a></td>
</tr>
</tbody>
</table>
<table id="zip-0226-notestructure" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="zip-0226.html#note-structure-commitment">ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment</a></td>
</tr>
</tbody>
</table>
<table id="zip-0226-txiddigest" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="zip-0226.html#txid-digest">ZIP 226: Transfer and Burn of Zcash Shielded Assets - TxId Digest</a></td>
</tr>
</tbody>
</table>
<table id="zip-0244" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="zip-0244.html">ZIP 244: Transaction Identifier Non-Malleability</a></td>
</tr>
</tbody>
</table>
<table id="zip-0244-sigdigest" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="zip-0244.html#signature-digest">ZIP 244: Transaction Identifier Non-Malleability: Signature Digest</a></td>
</tr>
</tbody>
</table>
<table id="zip-0244-authcommitment" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="zip-0244.html#authorizing-data-commitment">ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment</a></td>
</tr>
</tbody>
</table>
<table id="zip-0317b" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="https://github.com/zcash/zips/pull/667">ZIP 317: Proportional Transfer Fee Mechanism</a></td>
</tr>
</tbody>
</table>
<table id="bip-0340" class="footnote">
<tbody>
<tr>
<th>16</th>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki">BIP 340: Schnorr Signatures for secp256k1</a></td>
</tr>
</tbody>
</table>
<table id="protocol-notation" class="footnote">
<tbody>
<tr>
<th>17</th>
<td><a href="protocol/protocol.pdf#notation">Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation</a></td>
</tr>
</tbody>
</table>
<table id="protocol-addressesandkeys" class="footnote">
<tbody>
<tr>
<th>18</th>
<td><a href="protocol/protocol.pdf#addressesandkeys">Zcash Protocol Specification, Version 2023.4.0. Section 3.1: Payment Addresses and Keys</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardkeycomponents" class="footnote">
<tbody>
<tr>
<th>19</th>
<td><a href="protocol/protocol.pdf#orchardkeycomponents">Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretegrouphashpallasandvesta" class="footnote">
<tbody>
<tr>
<th>20</th>
<td><a href="protocol/protocol.pdf#concretegrouphashpallasandvesta">Zcash Protocol Specification, Version 2023.4.0. Section 5.4.9.8: Group Hash into Pallas and Vesta</a></td>
</tr>
</tbody>
</table>
<table id="protocol-orchardpaymentaddrencoding" class="footnote">
<tbody>
<tr>
<th>21</th>
<td><a href="protocol/protocol.pdf#orchardpaymentaddrencoding">Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses</a></td>
</tr>
</tbody>
</table>
<table id="protocol-txnencoding" class="footnote">
<tbody>
<tr>
<th>22</th>
<td><a href="protocol/protocol.pdf#txnencoding">Zcash Protocol Specification, Version 2023.4.0. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>