Decouple crypto functions #7
Description
I very much like the design of the system except one thing.
check_preimage() : Compares the hash associated with the key-path with the hash of the value on top of the parameter stack; increments the check counter if it fails. Pops one parameter off of the parameter stack if it succeeds. This function understands the Multihash format and is able to generate and verify preimages using any hash function it supports.
check_signature() : Verifies the digital signature and message on the parameter stack using the public key associated with the key-path; increments the check counter if it fails. Pops two parameters off of the parameter stack if it succeeds. This function understands the Multikey and Multisig formats and is able to verify any digital signature they support.
emphasis mine
If I understand correctly this means that the hashing or signature scheme must be part of the lib. This has implication I don't like.
Who controls the lib? How fast can new schemes be added? Will this lead to forks? The entire network of nodes must update just to support my niche crypto scheme? What happens when nodes use different versions?
Since WASM is already used for VLADs creation could be not add an extra parameter for the hash of the WASM module to load that in turn will compute the hash, sign or verify?
I imagine we would end up with ubiquitous and audited modules for each hashing and signature schemes but allow niche ones too.
Finding and loading the modules the first time would take time but then the main code base would have to be updated much less often or not at all.
WDYT?