contracts: Sr25519 (Schnorrkel) signature verification

[goastler]

Questions

• Is this a bug concerning building of ink! smart contracts?
  • no
• Is this a bug that appears when interacting with smart contracts via the Polkadot JS browser UI?
  • no

FAQ

• Are you using the nightly Rust channel to compile your smart contract?
• no
• Are you using an up-to-date cargo-contract? Check via cargo contract --version.
• yes
• Are you using an up-to-date ink! version in your smart contract?
• yes

Describe the bug
I cannot verify a sr25519 (schnorrkel) signature.

Expected behavior
Ability to verify a sr25519 (schnorrkel) signature in a manner similar to the ecdsa_recover() function.

Screenshots

Additional context
Our business logic dictates that we need to sign a payload on our frontend using the polkadot JS extension. Unfortunately, the keyring used by the extension stores the keys in sr25519 format and provide no functionality to load keys in a different format.

We need to verify these sr25519 signatures in ink. However, only ecdsa verification is currently provided via the ecdsa_recover() function. As we cannot access ecdsa on the polkadot JS extension, ecdsa_recover() is a no-go.

I've managed to add the schnorrkel crate to our ink contract and successfully verify sr25519 signatures from the frontend. Anyone wanting to do the same can see our ink contract code here and js code here (one thing to note is that the polkadot js extension wraps the payload to sign in a <Bytes> tag - this was a big "gotcha!" for us).

My question is: is sr25519 going to be implemented in ink? Or is importing the schnorrkel crate the only option? Schnorrkel adds ~30KB to the contract size, which is an unfortunate but necessary hit for us at the moment.

[goastler]

@forgetso

[goastler]

corresponding polkadot js extension issue: polkadot-js/extension#1237

[shunsukew]

It is possible to do Sr25519/Ed25519 signature verification in ink! by using chain extensions (pallet-contracts extension).
And it worked as expected in my local environment AstarNetwork/astar-frame#141, although still work in progress.

However, I also would like to know about potential ink! native multi signature schemes verification support, and current plans.

[athei]

As a cryptographic primitive which is native to substrate we should include such a function into the core API of pallet-contracts.

[burdges]

Ink should use the substrate host calls for sr25519, no?

[athei]

Yes. The PR that closes this issue did exactly this. It exposes this host functions to contracts.