CIP 25 - ed25519 precompile - Discussions about celo-proposals

[prestwich]

After some discussion, we decided on:

1. Adapt the precompile to accept arbitrary-length messages.
   • func Verify(msg []byte, pubkey [32]byte, signature [64]byte) uint32
2. Modify the serialized precompile input format to include 1 variable-length argument (the message)
   • serialized format to be defined as pubkey || signature || message where || is concatenation
3. Modify gas costs to account for the internal sha-512

This should preserve full compatibility with other PureEdDSA and HashEdDSA implementations

[mkaczanowski]

FYI: I've just published the initial PR

[prestwich]

If I recall correctly, ed25519 specifies sha2-512 (64-byte messages) while the proposal specifies 32-byte messages. For full compatibility with the ed25519 spec

1. Should message size be 64 (and support a 32-byte operating mode)?
2. Should CIP-20 add support for sha2-512?

[prestwich]

Went and reviewed RFC 8032. It looks like this is the prehash function PH(M) (see section 4). We do not need to support PureEdDSA, and for HashEdDSA the prehash can be parameterized by any collision-resistant hash function. I guess the question then is whether common cryptographic protocols we want to verify use 64-byte hashes. What does Cosmos use?

[prestwich]

ah hmm. I guess that I had been thinking of this as a Raw verify function func VerifyRaw(msgHash []byte, pubkey [32]byte, signature [64]byte) uint32 where msgHash is almost always 32 or 64 bytes. Edit: Apparently this concept doesn't precisely apply to EdDSA because it always uses sha512 internally

Currently as specced it's Verify(msg [32]byte, pubkey [32]byte, signature [64]byte) uint32. This results in the 32 byte message being hashed with Sha512 again in the eddsa library I believe. This would create compatibility issues with almost any use case (including cosmos-sdk, I believe) so it seems like we'll want to switch to the raw variant 🤔