SIMD-0376

TL;DR

This proposal replaces the `verify_strict` semantics used in Solana, derived from Agave's usage of `ed25519-dalek`'s `verify_strict`, with [ZIP-215](https://zips.z.cash/zip-0215), Zebra's EdDSA variant. In practice, this removes the $R$ and $A$ torsion checks, multiplies the verification equation by the cofactor, and makes verification insensitive to torsion elements. This change enables batch verification of transaction signatures, improves validator efficiency, and standardizes consensus behaviour across implementations.

Summary

This proposal replaces the `verify_strict` semantics used in Solana, derived from Agave's usage of `ed25519-dalek`'s `verify_strict`, with [ZIP-215](https://zips.z.cash/zip-0215), Zebra's EdDSA variant. In practice, this removes the $R$ and $A$ torsion checks, multiplies the verification equation by the cofactor, and makes verification insensitive to torsion elements. This change enables batch verification of transaction signatures, improves validator efficiency, and standardizes consensus behaviour across implementations.

Motivation

Two main factors motivate this proposed change. 1. Today, Solana validators must perfectly replicate the behaviour of `verify_strict`, a function implemented in the `ed25519-dalek` library. This forces validators written in other languages, or ones that do not wish to use this library for better diversity, to re-implement the exact semantics. While this will always be the case, due to transaction verification being part of consensus, this proposal suggests using a better proven verification equation, which is better described, rather than the implicit behaviour found in the `ed25519-dalek` library. 2. `verify_strict` rejects small-order `R`, which makes batch verification impossible. Batched verification can reduce costs by ~40% for large signatures batches, which is significant at Solana's scale, where validators process hundreds of thousands of signatures every block.

Key Changes

• Strict Verification: Ed25519 verification that explicitly rejects both public
• Cofactored Verification: A scheme where the entire verification equation
• Batch Verification: Verifying many signatures together via random linear
• Reject the signature if $S \notin \{0, ..., L - 1\}$.
• Compute the hash $\text{SHA512}(R \|\| A \|\| M)$ and reduce it
• Given that $B$ is the Ed25519 basepoint, accept the signature if:

Impact

- Dapp developers: No required changes, signatures already generated remain valid. - Validators: Lower CPU usage, faster verification pipelines. - Core Contributors: A more clear, standardized implementation for new validator clients and other software potentially performing signature verification.

Backwards Compatibility

- All signatures valid under `verify_strict` remain valid under ZIP-215 verification. - A small class of signatures previously rejected may now be accepted. This upgrade will require one feature gate. Once this feature gate is active, ZIP-215 will be the equation used for all EdDSA signature verifications, instead of `verify_strict`. Here is a proof that any signature that `verify_strict` accepts would be accepted by the new verification equation as well: ### Lemma: Consider the `verify_strict` equation (E) to be: ```math S \cdot B - h \cdot A = R ``` where $B$ is the base point, $A$ is the public key point, $R$ is the ephemeral point, $S$ is the signature scalar and $h = \text{SHA512}(R \|\| A \|\| M) \bmod L$. Assume `verify_strict` accepts a signature, where 1. The above equation (E) holds in the Edwards25519 group. 2. $S$ is canonical and $`S \in \{0, ..., L - 1\}`$. 3. $A$ is canonical and *not* a small-order point. 4. $R$ is canonical and *not* a small-order point. Then the new verification equation (C): ```math 8(S \cdot B) - 8R - 8(h \cdot A) = \mathcal{O} ``` also holds; therefore a new verifier that enforces (2), and the equation (C), will accept the signature. ### Proof: Start from (E): ```math S \cdot B - h \cdot A = R ``` This can be rewritten as: ```math S \cdot B - R - h \cdot A = \mathcal{O} ``` Apply scalar multiplication by the cofactor (8). Since scalar multiplication is linear and the group law applies: ```math [8](S \cdot B - R - h \cdot A) = [8]\mathcal{O} ``` If you distribute $[8]$ across the sum: ```math 8(S \cdot B) - 8R - 8(h \cdot A) = \mathcal{O} ``` which is exactly the equation (C). Therefore, assuming that $S$ is properly checked, the new verification equation should never reject a signature accepted by `verify_strict`.

Security Considerations

There are two important qualities an EdDSA scheme can have. - Strongly Binding Signatures (SBS): A signature scheme is *strongly binding* if each valid signature corresponds to exactly one valid message, i.e there is no "malleability" in the verification equation. - Strong Unforgeability under Chosen Message Attack (SUF-CMA): A signature scheme is SUF-CMA secure if an attacker cannot create *any* new valid signature, even on a message that has been signed before. In other words, they can't "malleate" an existing signature into another distinct, valid one. The only quality that Solana worries about is SUF-CMA (as opposed to EUF-CMA), which ZIP-215 achieves by rejecting $S$ scalars which do not fit into $l$.