Add cryptographic verification functions for contracts to call

[atenjin]

hey, many contract developers feedback to us that they need to verify signature in contracts for many defi situations.

Now, pallet-contracts just contains 4 type hash function in host_function, but has no verify&sign crypto methods. Though for one chain, it can use ChainExtenstion to add those function, but in my mind, I think the verify&sign methods are generic feature for contract platform, not need those chains integrate by themself.

Integrating in pallet-contracts is better then using ChainExtension, because for contract developers, in contract, verify&sign is not related with chain, and for second, if those method need to support by ChainExtension, different chain may choose different function id, so it will cause more complicated things for contract developers to modify they contract to run in different chain, however those verify&sign function is not related to the business of the chain.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[atenjin]

I think this feature is useful. Many developers need this.

[RoyTimes]

We need to verify a cryptographic signature on smart contract as a core requirement for one of our product. Because the contract pallet does not support cryptographic verification, we'd forced to use EVM and deal with all the issues with account types. We would LOVE to see cryptographic signature support on wasm contracts.

[athei]

Yes it makes total sense to have those. I suggest using the schemes which are already provided by the client to the runtime to implement those.

[xgreenx]

I agree that we need support verification. But I think that signing must be forbidden. Because if someone tries to sign something in the contract, it means that the private key will be compromised.

About verification funciton. The question is which API do we expect?
Which size of the message? Is it 32 bytes(so the developer must hash it before using of verifying function) or it can have a dynamic size?
The signature can be 64 bytes(Sr25519 and Ed25519) or 65 bytes(ECDSA). Based on the type of verification.
The public key can be 32 bytes(Sr25519 and Ed25519). The question is about the ECDSA key. The size for the ECDSA key will be 32 bytes(the developer must hash the original compressed ecdsa public key by blake2_256) or it must be an original compressed ecdsa public key with 33 bytes?

[athei]

But I think that signing must be forbidden. Because if someone tries to sign something in the contract, it means that the private key will be compromised.

You are right. Signing does not make sense in a public contract.

About verification funciton. The question is which API do we expect?

I think this is exactly the reason why this issue wasn't tackled. There are so many ways of doing this and I am reluctant to ossify one way in the contracts API. Additionally, you have other possibilities than doing in-contract crypto on substrate. You could store the account id of some multi sig or proxy account and use those mechanisms. That said, having some flexible verification API would still be something we want.

[athei]

Fixed by #9686