mirror of https://github.com/zcash/zips.git
[ZIP 215] Fix Ed25519 validation rules to allow batch verification (#355)
* First draft of Ed25519 validation rules. * Add ZIP number. * Clarify language. * Remove Original-Authors when Owners has same value Co-authored-by: Daira Hopwood <daira@jacaranda.org> * Status: Active -> Proposed Co-authored-by: Daira Hopwood <daira@jacaranda.org> * Tidy words Co-authored-by: Daira Hopwood <daira@jacaranda.org> * Clarify libsodium divergence Co-authored-by: Daira Hopwood <daira@jacaranda.org> * Link to rfc8032 * Include references section * Redo * Math syntax Co-authored-by: Daira Hopwood <daira@jacaranda.org> * Update math syntax to match spec for byte-arrays Co-authored-by: Daira Hopwood <daira@jacaranda.org> * Define only the RFC words that are used * Link to spec * Fleshout title * Deployment section * Update zip-0215.rst * Add linebreak Co-authored-by: Deirdre Connolly <deirdre@zfnd.org> Co-authored-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
3d8b0363c7
commit
e38d52c46f
|
@ -0,0 +1,102 @@
|
|||
::
|
||||
|
||||
ZIP: 215
|
||||
Title: Explicitly define Ed25519 validation rules
|
||||
Owners: Henry de Valence <hdevalence@zfnd.org>
|
||||
Status: Proposed
|
||||
Category: Consensus
|
||||
Created: 2020-04-27
|
||||
License: BSD-2-Clause
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The key word "MUST" in this document is to be interpreted as
|
||||
described in `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
|
||||
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
|
||||
Ed25519 verification criteria and changing them to be compatible with batch
|
||||
verification.
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
The lack of clear verification criteria for Ed25519 signatures poses a
|
||||
maintenance burden. The initial implementation of Zcash consensus in `zcashd`
|
||||
inherited validation criteria from a then-current version of `libsodium` (1.0.15).
|
||||
Due to `a bug in libsodium <https://github.com/zcash/zcash/issues/2872#issuecomment-576911471>`_,
|
||||
this was different from the intended criteria documented in the Zcash protocol
|
||||
specification [#protocol]_ (before the specification was changed to match
|
||||
`libsodium` 1.0.15 in specification version 2020.1.2). Also, `libsodium` never
|
||||
guaranteed stable validation criteria, and changed behavior in a later point
|
||||
release. This forced `zcashd` 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, `ed25519-zebra` to
|
||||
provide Zcash-flavored Ed25519, attempting to match `libsodium` 1.0.15 exactly. And
|
||||
the initial attempt to implement `ed25519-zebra` was also incompatible, because
|
||||
it precisely matched the wrong compile-time configuration of `libsodium`.
|
||||
|
||||
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.
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
After activation of this ZIP, the `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.
|
||||
|
||||
The language about `ExcludedPointEncodings` in §5.4.5 of the Zcash
|
||||
specification is deleted.
|
||||
|
||||
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`.
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
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.
|
||||
|
||||
It also allows the use of batch verification, which requires multiplication
|
||||
by the cofactor in the verification equation.
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
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.
|
||||
|
||||
Deployment
|
||||
=========
|
||||
|
||||
This is intended to be deployed with the Canopy Network Upgrade, which is
|
||||
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>`_
|
Loading…
Reference in New Issue