search

neo-project / neo

NEO Smart Economy
MIT License
3.47k stars 1.03k forks source link

Expand supported cryptography primitives to include industry standards #972

Closed canesin closed 4 years ago

canesin commented 5 years ago

Hi,

This can be tagged for NEO3 but might still beneficial to NEO2 projects building like SeraphID, Bridge and Nash.

The request is to add all supported Bitcoin (secp256k1) and Ethereum (keccak256) primitives for encryption, signing and hashing algorithms. In addition to those if possible also add X509v3 RSA primitives to allow to interact with digital identity cards like from Estonia or Finland from smart contracts.

igormcoelho commented 5 years ago

@canesin I fully agree, could you support this Issue here on vm? https://github.com/neo-project/neo-vm/issues/176

I believe the best way to do it is to put crypto primitives as neo-vm extensions... this way, we enforce neo-vm as a crypto computing machine (for blockchain and verifiable computing), and since it's low level implementation, it's outside the scope of blockchain interops, so it's better as computing extensions. VM extensions can grow in the future, without harming blockchain states or protocol.

We could draft a NEP for it, what do you think?

lllwvlvwlll commented 5 years ago

This could also be helpful for Moonlight. @birmas

lock9 commented 5 years ago

@igormcoelho how these extensions would work? What would happen if someone does not have the extension? Are extensions mandatory for all nodes? So why is it called an extension? Why not add it directly to the NEO VM or use it as an Interop service?

igormcoelho commented 5 years ago

The proposed idea for extensions is to extend VM operations in time, without creating new opcodes. Since EXTENSION code is incremental (differently from Interops, which are free on every neo-based blockchain platform), we can control it over time, without needing to version the whole thing. As long as we reject scripts that try to use unexisting extensions in the present, this won't cause problems to be future, when new extensions are added (this is a simple numeric comparison, but requires tx opcodes to be parsed on node).