search

neo-project / neo-vm

NEO Virtual Machine
MIT License
195 stars 146 forks source link

EC point multiplication/add #78

Closed igormcoelho closed 3 years ago

igormcoelho commented 5 years ago

We propose an operation for Elliptic curve point scalar multiplication and (possibly) addition. The idea is to allow onchain implementation of zero knowledge and other cryptography techniques, allowing users to switch prefered curves. This is related to MODPOW issue, and also could be interop, if community prefers. The intented syntax is to receive curve parameters on a input array on stack, followed by point (array of two items) and scalar (another bytearray).output will be a point (array of two elements).

vncoelho commented 5 years ago

More important than Zero Knowledge are the Cryptography Techniques, which ensures the possibility of Quantum-Safety in terms of users preferences.

erikzhang commented 5 years ago

Is this really a viable direction? It is indeed achievable to assemble some cryptographic operations with addition, multiplication and MODPOW in smart contracts, but what is the cost? I don't think anyone will actually use this method. Perhaps a more feasible approach is to provide cryptographic functions directly in the instruction set or interop services.

vncoelho commented 5 years ago

If we directly provide cryptographic functions we will always be responsible for the final safety. I believe that, in a true decentralized account system, the user will be able to create its account a cryptographic function chosen according to their needs (using systems such as https://neoresearch.io/smacco/). By allowing this, the responsibility for quantum safety moves from the Blockchain to a superior layer.

jsolman commented 5 years ago

Sounds like a bit of a headache for wallets to deal with signing.

vncoelho commented 5 years ago

@erikzhang, we current think this is the best option to keep that flow of allowing flexibility for signatures. With this PR we plan to include, for example, Schnorr signatures in terms of Verification Scripts. We believe this is the best way to decentralize these Cryptographic mechanisms in a way that appeals to all users.

igormcoelho commented 5 years ago

@erikzhang

Is this really a viable direction?

Yes, I think so. A similar strategy has been also pursued by Ethereum group since 2017, in order to allow applications to develop and support zero knowledge. But as far as I know, they were only providing operations for an specific curve... I'm not still quite sure on the costs of supporting any curve, but my initial plan was for having a public smart contract with curve parameters on storage (so they don't get re-submitted), and support only Jacobian efficient computation.

It is indeed achievable to assemble some cryptographic operations with addition, multiplication and MODPOW in smart contracts, but what is the cost?

You mean, the computational cost? Again quoting eth for the MODPOW, they had a gas price proportional the operation, so as soon as we have decided over this, we can experiment with computational costs and see what price fits best. It can be expensive, as long as it's feasible for current and similar verification scripts.

I don't think anyone will actually use this method. Perhaps a more feasible approach is to provide cryptographic functions directly in the instruction set or interop services.

I believe that providing direct hardcoded support is the spirit of BItcoin, because it's not a Turing complete network (not intended to be), but flexible chains such as Neo will find many (so many!) useful applications for this. One example, as quoted by Vitor, is Schnorr signatures, which is important to compress multisig, and other applications is zero knowledge... RSA (for MODPOW only) can support online decryption, which has some applications too. But if this is viable, nothing would disallow users from having Bitcoin security secp256k1 on Neo, for example, or to use more bits (512 perhaps?) if desired. From user perspective and wallets, they will only use operations that are safe and tested, and these can be proposed as future NEPs, for example, different curves and computing methods such as Schnorr, without the need to change core features of Neo. Regarding interop services, I agree that this may be a better solution (less opcodes the better).

But let's think more about it, I'm still not 100% confident on deeper implementation aspects of crypto security, directly on a smart contract, compared to a native (C# for example) implementation of these techniques. I need to study exacty how different curves such as 25519 are implemented, in a compatible manner. Let's discuss more.

igormcoelho commented 5 years ago

We can propose this as a Native contract: https://github.com/neo-project/neo/issues/303

erikzhang commented 4 years ago

I think this kind of features should not be implemented in VM layer.