Merge branch 'orchard-wip'

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-03-26 19:27:21 +00:00
commit 17a6a72974
5 changed files with 1495 additions and 1287 deletions

View File

@ -18,10 +18,10 @@ NOCRUFT?=|perl -pe 's|[{\<\(]\/[^ ]* ?||g;s|^.* has been referenced but does not
.PHONY: all all-specs release
all: .Makefile.uptodate
$(MAKE) nu5 canopy heartwood blossom sapling sprout
$(MAKE) nu5 canopy heartwood blossom sapling
all-specs: .Makefile.uptodate
$(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf sprout.pdf
$(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf
release:
ifeq ($(shell git tag --points-at HEAD |wc -l),0)
@ -41,9 +41,6 @@ endif
$(MAKE) clean
touch .Makefile.uptodate
sprout.pdf: protocol.tex zcash.bib incremental_merkle.png key_components.png
$(MAKE) sprout
sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) sapling
@ -59,18 +56,6 @@ canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling
nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png
$(MAKE) nu5
.PHONY: auxsprout
auxsprout:
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
mkdir -p aux
rm -f aux/sprout.* aux/protocol.*
$(LATEXMK) -jobname=sprout -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT)
.PHONY: sprout
sprout:
$(MAKE) auxsprout
mv -f aux/sprout.pdf .
.PHONY: auxsapling
auxsapling:
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
@ -132,18 +117,6 @@ nu5:
$(MAKE) auxnu5
mv -f aux/nu5.pdf .
.PHONY: nolatexmk-sprout
nolatexmk-sprout:
printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
# If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time.
rm -f sprout.aux sprout.bbl sprout.blg sprout.brf sprout.bcf
$(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; }
biber sprout
$(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; }
$(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; }
sh mymakeindex.sh -o sprout.ind sprout.idx
$(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; }
.PHONY: nolatexmk-sapling
nolatexmk-sapling:
printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver
@ -207,4 +180,4 @@ nolatexmk-nu5:
.PHONY: clean
clean:
rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf sprout.pdf
rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf

File diff suppressed because it is too large Load Diff

View File

@ -501,6 +501,15 @@ Received March~20, 2012.}
Last updated December~16, 2020.}
}
@misc{Poseidon-1.1,
presort={Poseidon-1.1},
author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger},
title={Poseidon reference implementation, Version 1.1},
date={2021-03-07},
url={https://extgit.iaik.tugraz.at/krypto/hadeshash/-/commit/7ecf9a7d4f37e777ea27e4c4d379443151270563},
urldate={2021-03-23}
}
@misc{BDPA2007,
presort={BDPA2007},
author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}},
@ -600,6 +609,16 @@ Last revised November~11, 2020.},
Lecture Notes in Computer Science; Springer, 2020.}
}
@misc{GRS2020,
presort={GRS2020},
author={Lorenzo Grassi and Christian Rechberger and Markus Schofnegger},
title={Proving Resistance Against Infinitely Long Subspace Trails: {H}ow to Choose the Linear Layer},
url={https://eprint.iacr.org/2020/500},
urldate={2021-03-23},
howpublished={Cryptology ePrint Archive: Report 2020/500.
Last revised January~27, 2021.}
}
@misc{AGRRT2017,
presort={AGRRT2017},
author={Martin Albrecht and Lorenzo Grassi and Christian Rechberger and
@ -1422,6 +1441,16 @@ Last revised February~5, 2018.}
addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.}
}
@misc{Hopwood2020,
presort={Hopwood2020},
author={Daira Hopwood},
title={GitHub repository `\hairspace zcash/pasta'\hairspace:
{G}enerator and supporting evidence for security of the {P}allas/{V}esta pair of elliptic curves suitable for {H}alo},
url={https://github.com/zcash/pasta},
urldate={2021-03-23},
addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.}
}
@misc{Bowe2018,
presort={Bowe2018},
author={Sean Bowe},
@ -1462,6 +1491,16 @@ Last revised February~5, 2018.}
doi={10.1109/IEEESTD.2004.94612}
}
@misc{ISO2015,
author={ISO/IEC},
title={International {S}tandard {ISO/IEC} 18004:2015(E): {I}nformation {T}echnology --
{A}utomatic identification and data capture techniques -- {QR} {C}ode bar code symbology specification.},
howpublished={Third edition},
date={2015-02-01},
url={https://raw.githubusercontent.com/yansikeim/QR-Code/master/ISO%20IEC%2018004%202015%20Standard.pdf},
urldate={2021-03-22}
}
@misc{Zcash-libsnark,
presort={Zcash-libsnark},
title={libsnark: {C}++ library for {zkSNARK} proofs (Zcash fork)},
@ -1830,3 +1869,11 @@ Proceedings of the 19th Annual International Cryptology Conference
url={https://zcash.github.io/orchard/},
urldate={2021-03-02}
}
@misc{Zcash-halo2,
presort={Zcash-halo2},
author={Daira Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and Ying Tong Lai and Steven Smith},
title={The halo2 Book},
url={https://zcash.github.io/halo2/},
urldate={2021-03-23}
}

View File

@ -3,6 +3,7 @@
<head>
<title>ZIP 225: Version 5 Transaction Format</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>
@ -20,10 +21,11 @@ License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://github.com/zcash/zips/issues/440</a>&gt;</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The character § is used when referring to sections of the Zcash Protocol Specification <a id="id2" class="footnote_reference" href="#protocol-nu5">2</a>.</p>
</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="id2" class="footnote_reference" href="#protocol-orchard">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <a id="id3" class="footnote_reference" href="#zip-0244">7</a>.</p>
<p>This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol <a id="id3" class="footnote_reference" href="#protocol-nu5">2</a>. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.</p>
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <a id="id4" class="footnote_reference" href="#zip-0244">7</a>.</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" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The new Orchard shielded pool requires serialized data elements that are distinct from any previous Zcash transaction. In addition, with the activation of ZIP 244, the serialized transaction format will no longer be consensus-critical. It makes sense at this point to define a format that can readily accommodate future extension in a systematic fashion, where elements required for support for a given pool are kept separate.</p>
@ -124,7 +126,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<td>Number of Sapling Spend descriptions in <code>vSpendsSapling</code>.</td>
</tr>
<tr>
<td><code>128 * nSpendsSapling</code></td>
<td><code>96 * nSpendsSapling</code></td>
<td><code>vSpendsSapling</code></td>
<td><code>SpendDescriptionV5[nSpendsSapling]</code></td>
<td>A sequence of Sapling Spend descriptions, encoded per protocol §7.3 Spend Description Encoding and Consensus.</td>
@ -201,8 +203,8 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<dt>An 8-bit value representing a set of flags. Ordered from LSB to MSB:</dt>
<dd>
<ul>
<li><code>spendsEnabledOrchard</code></li>
<li><code>outputsEnabledOrchard</code></li>
<li><code>enableSpendsOrchard</code></li>
<li><code>enableOutputsOrchard</code></li>
<li>The remaining bits are set to <code>0</code>.</li>
</ul>
</dd>
@ -248,12 +250,16 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</tbody>
</table>
<ul>
<li>The <code>valueBalanceSapling</code>, <code>anchorSapling</code>, and <code>bindingSigSapling</code> fields are present if and only if <code>nSpendsSapling + nOutputsSapling &gt; 0</code>. If <code>valueBalanceSapling</code> is not present, then <code>valueBalanceSapling</code> is defined to be 0.</li>
<li>The <code>valueBalanceOrchard</code>, <code>anchorOrchard</code>, and <code>bindingSigOrchard</code> fields are present if and only if <code>nActionsOrchard &gt; 0</code>. If <code>valueBalanceOrchard</code> is not present, then <code>valueBalanceOrchard</code> is defined to be 0.</li>
<li>The fields <code>valueBalanceSapling</code>, <code>anchorSapling</code>, and <code>bindingSigSapling</code> are present if and only if <code>nSpendsSapling + nOutputsSapling &gt; 0</code>. If <code>valueBalanceSapling</code> is not present, then
<span class="math">\(\mathsf{v^{balanceSapling}}\)</span>
is defined to be 0.</li>
<li>The fields <code>flagsOrchard</code>, <code>valueBalanceOrchard</code>, <code>anchorOrchard</code>, <code>sizeProofsOrchard</code>, <code>proofsOrchard</code>, and <code>bindingSigOrchard</code> are present if and only if <code>nActionsOrchard &gt; 0</code>. If <code>valueBalanceOrchard</code> is not present, then
<span class="math">\(\mathsf{v^{balanceOrchard}}\)</span>
is defined to be 0.</li>
<li>The elements of <code>vSpendProofsSapling</code> and <code>vSpendAuthSigsSapling</code> have a 1:1 correspondence to the elements of <code>vSpendsSapling</code> and MUST be ordered such that the proof or signature at a given index corresponds to the <code>SpendDescriptionV5</code> at the same index.</li>
<li>The elements of <code>vOutputProofsSapling</code> have a 1:1 correspondence to the elements of <code>vOutputsSapling</code> and MUST be ordered such that the proof at a given index corresponds to the <code>OutputDescriptionV5</code> at the same index.</li>
<li>The proofs aggregated in <code>proofsOrchard</code>, and the elements of <code>vSpendAuthSigsOrchard</code>, each have a 1:1 correspondence to the elements of <code>vActionsOrchard</code> and MUST be ordered such that the proof or signature at a given index corresponds to the <code>OrchardAction</code> at the same index.</li>
<li>For coinbase transactions, the <code>spendsEnabledOrchard</code> bit MUST be set to <code>0</code>.</li>
<li>For coinbase transactions, the <code>enableSpendsOrchard</code> bit MUST be set to <code>0</code>.</li>
</ul>
<p>The encodings of <code>tx_in</code>, and <code>tx_out</code> are as in a version 4 transaction (i.e. unchanged from Canopy). The encodings of <code>SpendDescriptionV5</code>, <code>OutputDescriptionV5</code> and <code>OrchardAction</code> are described below. The encoding of Sapling Spends and Outputs has changed relative to prior versions in order to better separate data that describe the effects of the transaction from the proofs of and commitments to those effects, and for symmetry with this separation in the Orchard-related parts of the transaction format.</p>
</section>
@ -288,7 +294,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in §7.3 Spend Description Encoding and Consensus of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#protocol-spenddesc">3</a>.</p>
<p>The encodings of each of these elements are defined in §7.3 Spend Description Encoding and Consensus of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-spenddesc">3</a>.</p>
</section>
<section id="sapling-output-description-outputdescriptionv5"><h3><span class="section-heading">Sapling Output Description (<code>OutputDescriptionV5</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-output-description-outputdescriptionv5"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
@ -328,12 +334,12 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<tr>
<td><code>80</code></td>
<td><code>outCiphertext</code></td>
<td><code>byte[580]</code></td>
<td><code>byte[80]</code></td>
<td>The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key.</td>
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in §7.4 Output Description Encoding and Consensus of the Zcash Protocol Specification <a id="id5" class="footnote_reference" href="#protocol-outputdesc">4</a>.</p>
<p>The encodings of each of these elements are defined in §7.4 Output Description Encoding and Consensus of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-outputdesc">4</a>.</p>
</section>
<section id="orchard-action-description-orchardaction"><h3><span class="section-heading">Orchard Action Description (<code>OrchardAction</code>)</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-action-description-orchardaction"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<table>
@ -385,22 +391,22 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/440">https://g
<tr>
<td><code>80</code></td>
<td><code>outCiphertext</code></td>
<td><code>byte[580]</code></td>
<td><code>byte[80]</code></td>
<td>The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key.</td>
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in §7.5 Action Description Encoding and Consensus of the Zcash Protocol Specification <a id="id6" class="footnote_reference" href="#protocol-actiondesc">5</a>.</p>
<p>The encodings of each of these elements are defined in §7.5 Action Description Encoding and Consensus of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#protocol-actiondesc">5</a>.</p>
</section>
<section id="modifications-to-zip-244"><h3><span class="section-heading">Modifications to ZIP 244</span><span class="section-anchor"> <a rel="bookmark" href="#modifications-to-zip-244"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="txid-digest"><h4><span class="section-heading">TxId Digest</span><span class="section-anchor"> <a rel="bookmark" href="#txid-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The tree of hashes defined by ZIP 244 <a id="id7" class="footnote_reference" href="#zip-0244">7</a> is re-structured to include a new branch for Orchard hashes. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<p>The tree of hashes defined by ZIP 244 <a id="id8" class="footnote_reference" href="#zip-0244">7</a> is re-structured to include a new branch for Orchard hashes. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>txid_digest
├── header_digest
├── transparent_digest
├── sapling_digest
└── orchard_digest</pre>
<section id="id8"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id8"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="id9"><h5><span class="section-heading">txid_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id9"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>The top hash of the <code>txid_digest</code> tree is modified from the ZIP 244 structure to be a BLAKE2b-256 hash of the following values</p>
<pre>T.1: header_digest (32-byte hash output)
T.2: transparent_digest (32-byte hash output)
@ -419,7 +425,7 @@ T.4e: valueBalanceOrchard (64-bit signed little-endian)</pre>
<pre>"ZTxIdOrchardHash"</pre>
</section>
<section id="t-4b-orchard-actions-compact-digest"><h5><span class="section-heading">T.4b: orchard_actions_compact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4b-orchard-actions-compact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id9" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 <a id="id10" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4b.i : nullifier (field encoding bytes)
T.4b.ii : cmx (field encoding bytes)
T.4b.iii: ephemeralKey (field encoding bytes)
@ -434,7 +440,7 @@ T.4b.iv : encCiphertext[..52] (First 52 bytes of field encoding)</pre>
<pre>"ZTxIdOrcOutMHash"</pre>
</section>
<section id="t-4d-orchard-actions-noncompact-digest"><h5><span class="section-heading">T.4d: orchard_actions_noncompact_digest</span><span class="section-anchor"> <a rel="bookmark" href="#t-4d-orchard-actions-noncompact-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id10" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<p>A BLAKE2b-256 hash of the remaining subset of Orchard Action information <strong>not</strong> intended for inclusion in an updated version of the the ZIP 307 <a id="id11" class="footnote_reference" href="#zip-0307">8</a> <code>CompactBlock</code> format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:</p>
<pre>T.4d.i : cv (field encoding bytes)
T.4d.ii : rk (field encoding bytes)
T.4d.iii: encCiphertext[564..] (post-memo suffix of field encoding)
@ -444,14 +450,14 @@ T.4d.iv : outCiphertext (field encoding bytes)</pre>
</section>
</section>
<section id="signature-digest"><h4><span class="section-heading">Signature Digest</span><span class="section-anchor"> <a rel="bookmark" href="#signature-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The signature digest creation algorithm defined by ZIP 244 <a id="id11" class="footnote_reference" href="#zip-0244">7</a> is modified to include a new branch for Orchard hashes. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<p>The signature digest creation algorithm defined by ZIP 244 <a id="id12" class="footnote_reference" href="#zip-0244">7</a> is modified to include a new branch for Orchard hashes. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>header_digest</code>, <code>transparent_digest</code>, <code>sprout_digest</code>, and <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>signature_digest
├── header_digest
├── transparent_digest
├── sprout_digest
├── sapling_digest
└── orchard_digest</pre>
<section id="id12"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id12"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<section id="id13"><h5><span class="section-heading">signature_digest</span><span class="section-anchor"> <a rel="bookmark" href="#id13"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>A BLAKE2b-256 hash of the following values</p>
<pre>S.1: header_digest (32-byte hash output)
S.2: transparent_digest (32-byte hash output)
@ -464,14 +470,14 @@ S.4: orchard_digest (32-byte hash output)</pre>
</section>
</section>
<section id="authorizing-data-commitment"><h4><span class="section-heading">Authorizing Data Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#authorizing-data-commitment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The tree of hashes defined by ZIP 244 <a id="id13" class="footnote_reference" href="#zip-0244">7</a> for authorizing data commitments is re-structured to include a new branch for Orchard Actions. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>transparent_digest</code>, and <code>sprout_digest</code> <code>sapling_digest</code> are as in ZIP 244:</p>
<p>The tree of hashes defined by ZIP 244 <a id="id14" class="footnote_reference" href="#zip-0244">7</a> for authorizing data commitments is re-structured to include a new branch for Orchard Actions. The <code>orchard_digest</code> branch is the only new addition to the tree; <code>transparent_digest</code>, and <code>sprout_digest</code> <code>sapling_digest</code> are as in ZIP 244:</p>
<pre>auth_digest
├── transparent_scripts_digest
├── sprout_auth_digest
├── sapling_auth_digest
└── orchard_auth_digest</pre>
<section id="auth-digest"><h5><span class="section-heading">auth_digest</span><span class="section-anchor"> <a rel="bookmark" href="#auth-digest"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h5>
<p>The tree of hashes defined by ZIP 244 <a id="id14" class="footnote_reference" href="#zip-0244">7</a> for authorizing data commitments is re-structured to include a new branch for Orchard authorizing data. The <code>orchard_auth_digest</code> branch is the only new addition to the tree; <code>transparent_auth_digest</code>, <code>sprout_auth_digest</code>, and <code>sapling_auth_digest</code> are as in ZIP 244:</p>
<p>The tree of hashes defined by ZIP 244 <a id="id15" class="footnote_reference" href="#zip-0244">7</a> for authorizing data commitments is re-structured to include a new branch for Orchard authorizing data. The <code>orchard_auth_digest</code> branch is the only new addition to the tree; <code>transparent_auth_digest</code>, <code>sprout_auth_digest</code>, and <code>sapling_auth_digest</code> are as in ZIP 244:</p>
<pre>A.1: transparent_scripts_digest (32-byte hash output)
A.2: sprout_auth_digest (32-byte hash output)
A.3: sapling_auth_digest (32-byte hash output)
@ -497,9 +503,9 @@ A.4c: bindingSigOrchard (field encoding bytes)</pre>
<p>Removing these fields reduces the complexity of the NU5 upgrade in the following ways:</p>
<ul>
<li>V5 parsing and serialization code does not need to take these fields into account.</li>
<li>ZIP 244 <a id="id15" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
<li>ZIP 244 <a id="id16" class="footnote_reference" href="#zip-0244">7</a> transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.</li>
</ul>
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="id16" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
<p>Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 <a id="id17" class="footnote_reference" href="#zip-0222">6</a> extension or by other means not yet determined.</p>
<p>The original definitions for the transaction fields that have been removed are:</p>
<table>
<tbody>
@ -548,11 +554,11 @@ A.4c: bindingSigOrchard (field encoding bytes)</pre>
</tr>
</tbody>
</table>
<table id="protocol-orchard" class="footnote">
<table id="protocol-nu5" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.17 or later</a></td>
<td><a href="protocol/nu5.pdf">Zcash Protocol Specification, Version 2021.1.20 or later</a></td>
</tr>
</tbody>
</table>
@ -560,7 +566,7 @@ A.4c: bindingSigOrchard (field encoding bytes)</pre>
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/nu5.pdf#spenddesc">Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.4: Spend Descriptions</a></td>
<td><a href="protocol/nu5.pdf#spenddesc">Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.4: Spend Descriptions</a></td>
</tr>
</tbody>
</table>
@ -568,7 +574,7 @@ A.4c: bindingSigOrchard (field encoding bytes)</pre>
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/nu5.pdf#outputdesc">Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.5: Output Descriptions</a></td>
<td><a href="protocol/nu5.pdf#outputdesc">Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.5: Output Descriptions</a></td>
</tr>
</tbody>
</table>
@ -576,7 +582,7 @@ A.4c: bindingSigOrchard (field encoding bytes)</pre>
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/nu5.pdf#actiondesc">Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.6: Action Descriptions</a></td>
<td><a href="protocol/nu5.pdf#actiondesc">Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.6: Action Descriptions</a></td>
</tr>
</tbody>
</table>

View File

@ -20,12 +20,15 @@ Terminology
The key words "MUST" and "MAY" in this document are to be interpreted as described in
RFC 2119. [#RFC2119]_
The character § is used when referring to sections of the Zcash Protocol Specification
[#protocol-nu5]_.
Abstract
========
This proposal defines an update to the Zcash peer-to-peer transaction format to include
support for data elements required to support the Orchard protocol [#protocol-orchard]_.
support for data elements required to support the Orchard protocol [#protocol-nu5]_.
The new transaction format defines well-bounded regions of the serialized form to serve
each of the existing pools of funds, and adds and describes a new region containing
Orchard-specific elements.
@ -106,7 +109,7 @@ Transaction Format
+-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+
|``varies`` |``nSpendsSapling`` |``compactSize`` |Number of Sapling Spend descriptions in ``vSpendsSapling``. |
+-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+
|``128 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV5[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per |
|``96 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV5[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per |
| | | |protocol §7.3 Spend Description Encoding and Consensus. |
+-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+
|``varies`` |``nOutputsSapling`` |``compactSize`` |Number of Sapling Output Decriptions in ``vOutputsSapling``. |
@ -136,8 +139,8 @@ Transaction Format
| | | |§7.5 Action Description Encoding and Consensus. |
+-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+
|``1`` |``flagsOrchard`` |``byte`` |An 8-bit value representing a set of flags. Ordered from LSB to MSB: |
| | | | * ``spendsEnabledOrchard`` |
| | | | * ``outputsEnabledOrchard`` |
| | | | * ``enableSpendsOrchard`` |
| | | | * ``enableOutputsOrchard`` |
| | | | * The remaining bits are set to ``0``. |
+-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+
|``8`` |``valueBalanceOrchard`` |``int64`` |The net value of Orchard spends minus outputs. |
@ -154,13 +157,15 @@ Transaction Format
|``64`` |``bindingSigOrchard`` |``byte[64]`` |An Orchard binding signature on the SIGHASH transaction hash. |
+-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+
* The ``valueBalanceSapling``, ``anchorSapling``, and ``bindingSigSapling`` fields are
* The fields ``valueBalanceSapling``, ``anchorSapling``, and ``bindingSigSapling`` are
present if and only if ``nSpendsSapling + nOutputsSapling > 0``. If
``valueBalanceSapling`` is not present, then ``valueBalanceSapling`` is defined to be 0.
``valueBalanceSapling`` is not present, then :math:`\mathsf{v^{balanceSapling}}`` is
defined to be 0.
* The ``valueBalanceOrchard``, ``anchorOrchard``, and ``bindingSigOrchard`` fields are
present if and only if ``nActionsOrchard > 0``. If ``valueBalanceOrchard`` is not
present, then ``valueBalanceOrchard`` is defined to be 0.
* The fields ``flagsOrchard``, ``valueBalanceOrchard``, ``anchorOrchard``,
``sizeProofsOrchard``, ``proofsOrchard``, and ``bindingSigOrchard`` are present
if and only if ``nActionsOrchard > 0``. If ``valueBalanceOrchard`` is not present, then
:math:`\mathsf{v^{balanceOrchard}}` is defined to be 0.
* The elements of ``vSpendProofsSapling`` and ``vSpendAuthSigsSapling`` have a 1:1
correspondence to the elements of ``vSpendsSapling`` and MUST be ordered such that the
@ -176,7 +181,7 @@ Transaction Format
``vActionsOrchard`` and MUST be ordered such that the proof or signature at a given
index corresponds to the ``OrchardAction`` at the same index.
* For coinbase transactions, the ``spendsEnabledOrchard`` bit MUST be set to ``0``.
* For coinbase transactions, the ``enableSpendsOrchard`` bit MUST be set to ``0``.
The encodings of ``tx_in``, and ``tx_out`` are as in a version 4 transaction (i.e.
unchanged from Canopy). The encodings of ``SpendDescriptionV5``, ``OutputDescriptionV5``
@ -216,7 +221,7 @@ Sapling Output Description (``OutputDescriptionV5``)
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. |
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|``80`` |``outCiphertext`` |``byte[580]`` |The encrypted contents of the byte string created by |
|``80`` |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by |
| | | |concatenation of the transmission key with the ephemeral |
| | | |secret key. |
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
@ -244,7 +249,7 @@ Orchard Action Description (``OrchardAction``)
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. |
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
|``80`` |``outCiphertext`` |``byte[580]`` |The encrypted contents of the byte string created by |
|``80`` |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by |
| | | |concatenation of the transmission key with the ephemeral |
| | | |secret key. |
+-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+
@ -476,10 +481,10 @@ References
==========
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.17 or later <protocol/nu5.pdf>`_
.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.4: Spend Descriptions <protocol/nu5.pdf#spenddesc>`_
.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.5: Output Descriptions <protocol/nu5.pdf#outputdesc>`_
.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.6: Action Descriptions <protocol/nu5.pdf#actiondesc>`_
.. [#protocol-nu5] `Zcash Protocol Specification, Version 2021.1.20 or later <protocol/nu5.pdf>`_
.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.4: Spend Descriptions <protocol/nu5.pdf#spenddesc>`_
.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.5: Output Descriptions <protocol/nu5.pdf#outputdesc>`_
.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.6: Action Descriptions <protocol/nu5.pdf#actiondesc>`_
.. [#zip-0222] `ZIP 222: Transparent Zcash Extensions <zip-0222.rst>`_
.. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.rst>`_
.. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection <zip-0307.rst>`_