Adopting ZIP-215 verbatim would make Solana's System Program ID a signable key
Serguey Asael Shinder2 min readPR #616 rewrites the core of SIMD-0376 - 351 lines added, 57 removed in proposals/0376-verify-strict.md - and the change is a narrowing rather than a reconsideration.
The earlier text replaced Solana's current verify_strict semantics, inherited from Agave's use of ed25519-dalek, with ZIP-215, Zcash's Zebra EdDSA variant: drop the $R$ and $A$ torsion checks, multiply the verification equation by the cofactor, make verification insensitive to torsion elements. The amended text specifies instead the ***cofactored* verification scheme from "Taming the many EdDSAs" (eprint 2020/1244) - that is, ZIP-215's cofactored equation combined with explicit rejection of non-canonical encodings and of small-order $A$ and $R$**. The practical effect is described precisely: verification becomes insensitive to the torsion components of otherwise valid points, but not to points that are entirely torsion.
The reason for the divergence is stated outright, and it is the part worth carrying away. The proposal deliberately does not adopt ZIP-215 verbatim, because ZIP-215 accepts small-order $A$ - which on Solana would make Pubkey::default(), the all-zero encoding and also the System Program ID, a signable public key.
The stated benefits are unchanged: batch verification of transaction signatures, better validator efficiency, and consensus behaviour standardised across implementations.
What it means
This is what it looks like when a chain stops inheriting its consensus rules from a library and writes them down. verify_strict was never a specification; it was whatever ed25519-dalek happened to implement, promoted to consensus by being the code everyone ran. Replacing it with a cited equation plus named rejection criteria means a second implementation can be written from the document rather than by reading Agave - which is the precondition for having more than one validator client at all.
The Pubkey::default() finding is the better argument for doing the work, though. An adjacent chain's well-reviewed, widely-implemented standard turned out to interact with one of Solana's own conventions to produce a signable System Program ID - a fact that lives in neither specification and only appears when you hold both at once. Nothing in ZIP-215 is wrong; nothing in using the all-zero pubkey as a program identifier is wrong either. The defect is in the seam, which is exactly where imported specifications fail.
Worth noting the honesty of the residual caveat: insensitive to torsion components, not to wholly torsion points. That distinction is the kind of thing that gets rounded off in a summary and then implemented wrongly, and SIMD-0376 now spells it out rather than leaving it to the reader.