Open Tommo-L opened 4 years ago
I vote for option 2.
Supporting Chinese national cryptography standards is helpful for dapps development in China.
https://github.com/neo-project/neo/pull/1419 already has secp256k1 without BC
To be fair, I don't think it's a good idea for a public chain. IMO it makes sense to make crypto pluggable and changeable for various private networks, but to stick with one set of crypto primitives for public network.
Suppose you've added Chinese crypto, now how about GOST? How about various other standards or just some nice algorithms like ed25519? You may very soon easily end up with a full-blown openssl inside this way, and I don't think that's what we want.
IMO it makes sense to make crypto pluggable and changeable for various private networks, but to stick with one set of crypto primitives for public network.
Agree.
For me, another reason that we hope to add SM2, is for legality reason.
YMMV with SM2, but my experience with GOST algorithms tells me that usually they're used in some regulated environments and usually using them implies some kind of certification that in turn may require strictly not having non-locally-standardized algorithms. So it's not that you're required to have GOST, but you're required to have just it and nothing else, which is impossible for public blockchain.
So it's not that you're required to have GOST, but you're required to have just it and nothing else, which is impossible for public blockchain.
This is a real possibility. We are not trying to solve all the problems, but we are trying to solve some projects' requirements and possible legality issues, just like os which supports different languages in different countries.
At the moment we'll not add, just do some research work. Only when some projects have the requirements, we will consider adding.
Each country or region may have different technical standards.Indeed, it is a bit bloated to be compatible and use all the standards in NEO's mainnet.But NEO is not just a public chain, it is also a protocol.Users can do what they want to do according to this protocol, not only the main network, but also their own private network.We should help with such needs.So I think we should abstract the existing encryption method and put the specific implementation into the plug-in or independent class library. Of course, the main network needs to specify the corresponding encryption standard, which can be stored in the configuration file.This will be a long term job
This isn't an urgent issue, we can just discuss it, maybe we can do it in the future.
Q1: Do we need to support this cryptography standards?
In my opinion, we should support it as some dapps may need, and also consider for legality.
Q2: If we want to support, how do we implement it?
Reference