zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 215: editorial and formatting changes; regenerate HTML. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-06-05 15:54:52 +01:00
parent e38d52c46f
commit 1fafff988a
4 changed files with 116 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
README.rst
View File

@ -82,6 +82,7 @@ Index of ZIPs
<tr> <td>212</td> <td class="left"><a href="zip-0212.rst">Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td> <td>Proposed</td>
<tr> <td>213</td> <td class="left"><a href="zip-0213.rst">Shielded Coinbase</a></td> <td>Implemented (zcashd)</td>
<tr> <td>214</td> <td class="left"><a href="zip-0214.rst">Consensus rules for a Zcash Development Fund</a></td> <td>Proposed</td>
<tr> <td>215</td> <td class="left"><a href="zip-0215.rst">Explicitly define Ed25519 validation rules</a></td> <td>Proposed</td>
<tr> <td>221</td> <td class="left"><a href="zip-0221.rst">FlyClient - Consensus-Layer Changes</a></td> <td>Implemented (zcashd)</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243.rst">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>250</td> <td class="left"><a href="zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Implemented (zcashd)</td>

1
index.html
View File

@ -55,6 +55,7 @@
<tr> <td>212</td> <td class="left"><a href="zip-0212">Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</a></td> <td>Proposed</td>
<tr> <td>213</td> <td class="left"><a href="zip-0213">Shielded Coinbase</a></td> <td>Implemented (zcashd)</td>
<tr> <td>214</td> <td class="left"><a href="zip-0214">Consensus rules for a Zcash Development Fund</a></td> <td>Proposed</td>
<tr> <td>215</td> <td class="left"><a href="zip-0215">Explicitly define Ed25519 validation rules</a></td> <td>Proposed</td>
<tr> <td>221</td> <td class="left"><a href="zip-0221">FlyClient - Consensus-Layer Changes</a></td> <td>Implemented (zcashd)</td>
<tr> <td>243</td> <td class="left"><a href="zip-0243">Transaction Signature Verification for Sapling</a></td> <td>Final</td>
<tr> <td>250</td> <td class="left"><a href="zip-0250">Deployment of the Heartwood Network Upgrade</a></td> <td>Implemented (zcashd)</td>

97
zip-0215.html Normal file
View File

@ -0,0 +1,97 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 215: Explicitly define Ed25519 validation rules</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: 215
Title: Explicitly define Ed25519 validation rules
Owners: Henry de Valence &lt;hdevalence@zfnd.org&gt;
Status: Proposed
Category: Consensus
Created: 2020-04-27
License: BSD-2-Clause</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key word "MUST" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature verification from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 verification criteria and changing them to be compatible with batch verification.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The lack of clear verification criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validation criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validation criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validation criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
<p>In addition, the validation criteria used by Zcash preclude the use of batch verification of Ed25519 signatures. While signature verification is not the primary bottleneck for Zcash, it would be nice to be able to batch-verify signatures, as is the case for RedJubJub.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>After activation of this ZIP, the
<span class="math">\(\mathsf{JoinSplitSig}\)</span>
validation rules in §5.4.5 of the protocol specification <a id="id4" class="footnote_reference" href="#protocol">3</a> are changed to the following:</p>
<ul>
<li>
<span class="math">\(\underline{A}\)</span>
and
<span class="math">\(\underline{R}\)</span>
MUST be encodings of a point on the Edwards form of Curve25519;</li>
<li>
<span class="math">\(\underline{S}\)</span>
MUST represent an integer less than
<span class="math">\(\ell\)</span>
;</li>
<li>The group equation
<span class="math">\([8][s]B = [8]R + [8][k]A\)</span>
MUST be satisfied, where
<span class="math">\(k\)</span>
is defined as in RFC 8032 §5.1.7. <a id="id5" class="footnote_reference" href="#rfc8032">2</a></li>
</ul>
<p>The language about <cite>ExcludedPointEncodings</cite> in §5.4.5 of the Zcash specification no longer applies.</p>
<p>It is <em>not</em> required that
<span class="math">\(\underline{A}\)</span>
and
<span class="math">\(\underline{R}\)</span>
are canonical encodings; in other words, the integer encoding the
<span class="math">\(y\)</span>
-coordinate of the points may be unreduced modulo
<span class="math">\(2^{255}-19\)</span>
.</p>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This change simplifies the Ed25519 validation logic and reduces future maintenance burden. Because multiplication by the cofactor admits more solutions to the verification equation, not fewer, it is compatible with all existing Ed25519 signatures on the chain.</p>
<p>It also allows the use of batch verification, which requires multiplication by the cofactor in the verification equation.</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This change has no effect on honestly-generated signatures. Unlike the current validation rules, it makes it possible for a user to generate weak signing keys or to generate signing keys with nonzero torsion component and submit them to the blockchain. However, doing so provides them with no advantage, only compromise to their own security. Moreover, these cases are not a failure mode of any deployed implementation.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is intended to be deployed with the Canopy Network Upgrade, which is scheduled to activate on Mainnet at block height 1046400.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="rfc8032" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc8032.html">Edwards-Curve Digital Signature Algorithm (EdDSA)</a></td>
</tr>
</tbody>
</table>
<table id="protocol" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.5 or later [Overwinter+Sapling+Blossom+Heartwood]</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

32
zip-0215.rst
View File

@ -12,15 +12,15 @@
Terminology
===========
The key word "MUST" in this document is to be interpreted as
described in `RFC2119`_.
The key word "MUST" in this document is to be interpreted as described in
RFC 2119. [#RFC2119]_
Abstract
========
Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519
does not clearly define criteria for signature validity, and implementations conformant
to `RFC8032`_ need not agree on whether signatures are valid. This is
to RFC 8032 [#RFC8032]_ need not agree on whether signatures are valid. This is
unacceptable for a consensus-critical application like Zcash. Currently, Zcash
inherits criteria for signature verification from an obsolete version of
`libsodium`. Instead, this ZIP settles the situation by explicitly defining the
@ -53,19 +53,21 @@ signatures, as is the case for RedJubJub.
Specification
=============
After activation of this ZIP, the `JoinSplitSig` validation rules in §5.4.5 of the
protocol specification [#protocol]_ are changed to the following:
After activation of this ZIP, the :math:`\mathsf{JoinSplitSig}` validation rules
in §5.4.5 of the protocol specification [#protocol]_ are changed to the following:
- :math:`\underline{A}` and :math:`\underline{R}` MUST be encodings of a point on the Edwards form of Curve25519;
- :math:`underline{S}` MUST represent an integer less than :math:`\ell`;
- The group equation `[8][s]B = [8]R + [8][k]A` MUST be satisfied, where `k` is defined as in RFC 8032 §5.1.7.
- :math:`\underline{A}` and :math:`\underline{R}` MUST be encodings of a point
on the Edwards form of Curve25519;
- :math:`\underline{S}` MUST represent an integer less than :math:`\ell`;
- The group equation :math:`[8][s]B = [8]R + [8][k]A` MUST be satisfied, where
:math:`k` is defined as in RFC 8032 §5.1.7. [#RFC8032]_
The language about `ExcludedPointEncodings` in §5.4.5 of the Zcash
specification is deleted.
specification no longer applies.
It is *not* required that `A` and `R` are canonical encodings; in other words,
the integer encoding the `y`-coordinate of the points may be unreduced modulo
`2^255-19`.
It is *not* required that :math:`\underline{A}` and :math:`\underline{R}`
are canonical encodings; in other words, the integer encoding the
:math:`y`-coordinate of the points may be unreduced modulo :math:`2^{255}-19`.
Rationale
=========
@ -89,14 +91,14 @@ compromise to their own security. Moreover, these cases are not a failure mode
of any deployed implementation.
Deployment
=========
==========
This is intended to be deployed with the Canopy Network Upgrade, which is
scheduled to activate on mainnet at block height 1046400.
scheduled to activate on Mainnet at block height 1046400.
References
==========
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#RFC8032] `Edwards-Curve Digital Signature Algorithm (EdDSA) <https://www.rfc-editor.org/rfc/rfc8032.html>`_
.. [#protocol] `Zcash Protocol Specification, Version {...} or later [Overwinter+Sapling+Blossom] <protocol/protocol.pdf>`_
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.5 or later [Overwinter+Sapling+Blossom+Heartwood] <protocol/protocol.pdf>`_