provide blake2_512 in runtime or provide from_ss58check_with_version for runtime

[atenjin]

In our situation, we submit a chain address(Substrate type) to runtime, and verify whether this address is valid.
But in Substrate, to verify the chain address should parse from ss58 and check the ss58version.
ss58 decode could be implemented in runtime, but check ss58version need blake2_512 hash.
and in sp-io, substrate provide:

[runtime_interface]
pub trait Hashing {
	/// Conduct a 256-bit Keccak hash.
	fn keccak_256(data: &[u8]) -> [u8; 32] {
		sp_core::hashing::keccak_256(data)
	}

	/// Conduct a 256-bit Sha2 hash.
	fn sha2_256(data: &[u8]) -> [u8; 32] {
		sp_core::hashing::sha2_256(data)
	}

	/// Conduct a 128-bit Blake2 hash.
	fn blake2_128(data: &[u8]) -> [u8; 16] {
		sp_core::hashing::blake2_128(data)
	}

	/// Conduct a 256-bit Blake2 hash.
	fn blake2_256(data: &[u8]) -> [u8; 32] {
		sp_core::hashing::blake2_256(data)
	}
//...
}

but not provide blake2_512.
If I provide blake2_512 or from_ss58check_with_version from my local runtime_interface, currently parachain could not support custom runtime_interface definition.

So substrate could provide balke2_512 in runtime for generic requirements?
or could provide AccountId32::from_ss58check_with_version for the situation which some one need to verify Substrate Address in runtime?

[bkchr]

Thank you for your request.

I assume that you don't need to call this method 1000 times per block. Thus, I think it is enough for you to just use the blake2 crate directly from wasm.

We provide common used hash functions for the wasm runtime to run them in native speed, because they are run very often per block. As said above, in your case this is probably not the case.

Furthermore, we probably would also need to support blake2_1024 etc. and where should we stop this?

[atenjin]

Thank you for your request.

I assume that you don't need to call this method 1000 times per block. Thus, I think it is enough for you to just use the blake2 crate directly from wasm.

We provide common used hash functions for the wasm runtime to run them in native speed, because they are run very often per block. As said above, in your case this is probably not the case.

Furthermore, we probably would also need to support blake2_1024 etc. and where should we stop this?

happy to hear that.
and yes, there is no end, so we help parachain could support custom runtime-inferface(though it may not possible for current architecture), but it's real necessary, for some team may build a chain with zk-snark or some complex cryptography or some thing else, substrate could not and should not to provide all runtime-interface for those possibility

(and on the other hand, for example I'm planning to implement Cid(belong to ipfs) in substrate, without custom interface, I could just implement the structure for cid, could not implement all hash function, if I use custom interface, I just could use in my local chain, can't be a paranchain in future. All in all, allow developers to use there custom interface in parachain is necessary :p)

[bkchr]

How should Parachains support custom interfaces? That will never work. It could be voted in Council or similar to add support for extended interfaces, but yeah, that is something for the future.

As I said, please use the WASM implementation of blake2 for now. AFAIK we will bring some sort of support for more complex crypto, but we are still working on ways to make this easily integratable.