Add support for keccak hashing and secp256k1 signature verification

[ysavchenko]

We're working on expanding Certus One Wormhole bridge architecture (currently supporting token transfer between Solana and Ethereum) to support other blockchains (you can find original repository here: https://github.com/certusone/wormhole)

One of the key parts of this architecture are VAAs (verifiable action approvals) which are sent by guardians who confirm cross-chain actions. And these VAAs contain signatures (in secp256k1 format) from guardians approving the action. These signatures have to be verified in the smart contract and this cannot be achieved with CosmWasm now. So what we ask is to add such signature verification (and sha-3 hashing) to be available from the smart contract environment.

Regarding interface it would be ideal if it is compatible with Ethereum ecrecover function, which accepts 32-byte message, v, r, s signature field and returns recovered address as first 20 bytes of sha3-hashed pubkey.

Overall we believe that such functionality in CosmWasm will be useful for many future projects on Cosmos. With high Ethereum fees many DeFi services will look for compatible blockchains they can integrate with their existing smart contracts and support for the same cryptography features in CosmWasm will be very important.

[webmaster128]

Welcoem to CosmWasm!

Yeah we talked about adding crypto APIs before but nothing has been implemented so far.

Did you try using Rust crates to compile this functionality as part of your Wasm contract? This might increate the contract size and gas consumption significantly but should work to unblock your project right now.

Regarding potential APIs:

• Ethereum is not using SHA-3, so I assume you want KECCAK-256
• ecrecover returning an address is too Ethereum specific for a general purpose crypto API. The algorithm should return a pubkey. This can then be derived to an address on demand.
• Cosmos uses compressed secp256k1 pubkeys, Ethereum uses uncompressed pubkeys. Which version would we choose in such an API?

[ysavchenko]

Did you try using Rust crates to compile this functionality as part of your Wasm contract? This might increate the contract size and gas consumption significantly but should work to unblock your project right now.

Thanks for an idea, will try to do this workaround until this issue is addressed

Ethereum is not using SHA-3, so I assume you want KECCAK-256

Right, I meant Keccak

ecrecover returning an address is too Ethereum specific for a general purpose crypto API. The algorithm should return a pubkey. This can then be derived to an address on demand.

Agreed, this would work and it will be more general purpose.

Cosmos uses compressed secp256k1 pubkeys, Ethereum uses uncompressed pubkeys. Which version would we choose in such an API?

I think it will be better to support uncompressed keys because they can be easily converted to compressed version and not the other way round (afaik)

[webmaster128]

Thanks for an idea, will try to do this workaround until this issue is addressed

I recently implemented BLS12-318 signature verification in pure Rust/Wasm. The contract is about 500 KB large and a verification costs about 5 million Cosmos SDK gas. Not production ready for sure, but with that approach prototypes can be built that will prove the point.

I think it will be better to support uncompressed keys because they can be easily converted to compressed version and not the other way round (afaik)

👍 will double check. I'm not too familiar with the math. But both conversions are possible without extra information.

[webmaster128]

We're now implementing this in #751. Our current thinking is that hashing remains in the contract as it varies a lot from application to application and is small/fast enough to be done in Wasm. The VM would then provide a secp256k1_verify and a secp256k1_recover_pubkey. Let's more the discussion over there and the follow-up tickets.