Speed up keypair generation in Nodejs with an optional dependency on `sodium-native`

[ChrisAntaki]

trafficstars

Problem

Generating keypairs using tweetnacl is slow, which I noticed mostly when mining vanity addresses (ex: CHRIS2...)

Solution

Add sodium-native as an optional dependency for Nodejs. If sodium-native is available, generate keypairs with it. Otherwise just fallback to tweetnacl. Stellar does this here: https://stellar.github.io/js-stellar-base/index.html

The above solution helps with Nodejs. For browsers, there might be a WebASM solution, but I haven't looked yet

Dependencies

sodium-native as an optional dependency

Urgency

Not super urgent, it would just help make the SDK more efficient in Nodejs

[barnjamin]

@fabrice102 ^

[fabrice102]

It looks like it would only work on node.js but not on browser looking at https://github.com/sodium-friends/sodium-universal. In that case, using another SDK is a workaround. Do you have any use cases where tweetnacl performance is an issue?

As an aside, regarding vanity addresses, it is much faster to generate them as 1-out-of-2 multisig where the first public key is a real public key and the second public key is generated completely randomly. This will be order of magnitudes faster than generating a pure address (essentially it is one SHA-512/256 hash as opposed to one ed25519 exponentiation). But still a native library would make it even faster (and actually multithreading would make it even better, which JS does not really support to my knowledge).

[ChrisAntaki]

Nodejs' cluster module helps with multithreading https://nodejs.org/api/cluster.html

[ChrisAntaki]

Do you have any use cases where tweetnacl performance is an issue?

I noticed the JavaScript SDK was much slower than the Python SDK when mining vanity addresses

[ChrisAntaki]

I'm seeing 66x speedups from using sodium-native instead of tweetnacl to generate keypairs

[jasonpaulos]

This SDK is more concerned with security and correctness than performance at that level, so this issue likely doesn't have high priority for the development team.

That being said, if someone wants to make a PR that swaps tweetnacl for a more efficient library and all tests pass, I'd certainly be interested in reviewing and hopefully approving it. We just need to be very confidant when switching crypto libraries that security is not negatively impacted.