contracts: add sr25519_verify

[pgherveou]

fix #13703

[pgherveou]

bot bench $ pallet dev pallet_contracts

[command-bot]

@pgherveou https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2614559 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/bench/bench.sh" pallet dev pallet_contracts. Check out https://gitlab.parity.io/parity/mirrors/substrate/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 17-f5846515-5654-48b7-8ccb-dba7ae90bd09 to cancel this command or bot cancel to cancel all commands in this pull request.

[pgherveou]

@athei quick questions, before I take a second pass at this:

• should we implement a generic verify function as demonstrated here

/// Ext defines a generic 
fn sig_verify(&self, payload: SigVerifierPayload) -> bool;

// each variant define the message, signature, and public key with the appropriate types
pub enum SigVerifierPayload {
    Sr25519 { ...  },
    Ed25519 { ... },
    Ecdsa { ... },
}

vs

what I started the other day

fn sr25519_verify(&self, signature: &[u8; 64], message: &[u8], pub_key: &[u8; 32]) -> bool;

and in this option here I am not sure if we want the message to be a fixed sized hash or just plain &[u8] as defined here

[command-bot]

@pgherveou Command "$PIPELINE_SCRIPTS_DIR/commands/bench/bench.sh" pallet dev pallet_contracts has finished. Result: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2614559 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2614559/artifacts/download.

[athei]

should we implement a generic verify function as demonstrated here
https://github.com/AstarNetwork/astar-frame/pull/141/files#diff-16c73d79bacd21e8243b65478b218afa791cb812008c4f8055a549d03cd4862a

I would say we opt for individual host functions. We don't have precedence for multiplexed functions. Reason is that it makes benchmarking harder when we multiplex: The weight will depend on the argument which decides which algorithm to depley. Hence this PR should a function for sr25519 and one for ed25519.

Not too sure what are the exact use cases here, but do we want the message payload to be hashed so it's constant size or
should it just be an arbitrary payload

The message will be an arbitrary payload as demonstrated in this PR. Reason is that this is what the functions in sp_io::crypto expect. Weight needs to be linear over its length.

[agryaznov]

only nitpicks

[pgherveou]

bot merge

[paritytech-processbot]

Waiting for commit status.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/april-updates-for-substrate-and-polkadot-devs/2764/1