Hashing functions in 4.x

[luu-alex]

Currently in 1.x we are using ethereumjs for hashing functions like sha3 and keccak256
For 4.x suggestions are open as we have alot of flexibility and options in terms of what library would be suitable for us.

[spacesailor24]

I think the decision is between these two:

• https://github.com/ethereum/js-ethereum-cryptography
• https://github.com/paulmillr/noble-secp256k1

It was said by @mpetrunic:

Alternative is https://github.com/paulmillr/noble-secp256k1 and his audited libraries as they are using bigint so it would not pull in bn.js dep. There is also discussions to use his libs inside ethereum/js-ethereum-cryptography

My preference is to utilize official Ethereum packages whenever available, but not pulling in bn.js is compelling. @jdevcs provided this comparison link, and js-ethereum-cryptography has 15 dependencies while noble-secp256k1 has 0, but the former is used significantly more by other packages

[FSM1]

Browser support for BigInt is still a bit patchy, so if you're intending on these hashing functions being called in a browser, then maybe the bn.js dependency is worthwhile for now.

[spacesailor24]

@FSM1 What do you mean by patchy? CanIUse reports it being supported by all major browsers using latest versions

[nazarhussain]

I had been using BigInt over 3 years in a blockchain platform, not that much famous but well developed. Never faced any issue on any browser or platform.

[nazarhussain]

For the nature of our library, to us wider aspects to consider are range of browsers and platforms compatibility and trust of the community. But with that we can't compromise the goal to reduce the library size.

For the library noble-secp256k1 I am not sure if its full-fulling our requirements, as it's majorly focused only on secp256k1

After reviewing the code of js-ethereum-cryptography library, I found that its just the wrapper on couple of other packages, famous of those are keccak and scrypt-js. It does not have any cryptographic implementation of itself.

So my suggestion would be to proceed with js-ethereum-cryptography and later if we found some need, we can look into directly using the underlying libraries like keccak and scrypt-js.

We can also do a standalone performance comparison between cryptographic libraries to see which one performs well. But that can be done as an independent goal.

[mpetrunic]

Thing to note, there is "noble" implementation of other crypthographic functions, like hashing: https://github.com/paulmillr/noble-hashes

[alcuadrado]

Something to add here: while ethereum-cryptography does pull a lot of packages, it was designed in a way that makes your bundle only includes the things you actually use. We'll keep this design in 2.x (see below).

[alcuadrado]

Hey @spacesailor24, I can give more context here.

We are going to release a 2.x version of ethereum-cryptography soon, based mostly on noble-* packages. It won't add a ton over those packages, but just group them and give them more exposition. noble-hashes was created for this purpose.

We will keep maintaining 1.x as it targets legacy runtimes/browsers, while 2.x won't. No plan to introduce any change on that branch though, but just keep it in maintenance mode.

Regarding audits, noble-secp256k1 has already been audited, but the new packages haven't. We are planning to get them audited by the end of the year.

[jdevcs]

@alcuadrado Thanks for this info.
Could you tell us what the plan for min node and browsers support target for ethereum-cryptography 2.x ? and is there any time line defined for its release? Will the API remain same or might have breaking changes?
( I want to see how easy it will be to migrate to 2.x )

[alcuadrado]

Sure!

The API will change as it won't use any node-specific API. For example, Uint8Array will be used instead of Buffer. Apart form that we'll try to keep it similar and simple.

A PR updating ethereum-cryptography will be available soon. Most probably in ~1 week. This is being built by the author of the noble packages.

The minimum node version will be 12, as it has native BigInts. And every browser that has them will be supported too. The browser support is not super well defined right now though. It's something we should definitely improve.

We are still considering if we should make an initial release of v2 before or after it gets audited. If you have an opinion on this, please let us know.

[spacesailor24]

Just wanted to echo @jdevcs, thank you very much for all the info @alcuadrado! This is all extremely useful for making a decision on how to move forward

Our rewrite is making use of BigInts as well, so it sounds like we'll be supporting the same minimum node/browser versions

My opinion is to implement v1 since it's already audited so we can move forward with the rewrite, then follow up with upgrading to v2 once it's been audited. @jdevcs I don't think our use of ethereum-cryptography is so heavy that it would be a monumental task to upgrade to v2, even if the API completely changes

[spacesailor24]

Consensus around this is to use the js-ethereum-cryptography package using v1 and upgrading to v2 when it's been audited - marking the discussion as resolved