Separate get scalar function

[kigawas]

Separate get scalar logic for getExtendedPublicKey

[paulmillr]

Could you clarify your use case?

[kigawas]

One call of point.toRawBytes can be reduced for fromPrivateKey

[paulmillr]

@kigawas what do you mean?

[paulmillr]

How much of a performance gain are we talking about? A comparison before/after would be useful. If it's negligible then we're optimizing the wrong part.

[kigawas]

@paulmillr Around 2% performance improvement, and it reduces memory footprints as well (since we can save a call to toAffineMemo.

I ran with (npm run build:clean || true) && npm run build && npm run bench:install && node benchmark/curves.js:

Before (main branch)

$ (npm run build:clean || true) && npm run build && npm run bench:install && node benchmark/curves.js

> @noble/[email protected] build:clean
> rm {.,esm,abstract,esm/abstract}/*.{js,d.ts,d.ts.map,js.map} 2> /dev/null


> @noble/[email protected] build
> tsc && tsc -p tsconfig.cjs.json


> @noble/[email protected] bench:install
> cd benchmark; npm install; npm install .. --install-links

...

ed25519
init 18ms
getPublicKey x 10,207 ops/sec @ 97μs/op ± 1.13% (82μs..1ms)
sign x 5,104 ops/sec @ 195μs/op
verify x 1,142 ops/sec @ 875μs/op

ed448
init 40ms
getPublicKey x 4,494 ops/sec @ 222μs/op
sign x 2,128 ops/sec @ 469μs/op
verify x 465 ops/sec @ 2ms/op
...

After

$ (npm run build:clean || true) && npm run build && npm run bench:install && node benchmark/curves.js

> @noble/[email protected] build:clean
> rm {.,esm,abstract,esm/abstract}/*.{js,d.ts,d.ts.map,js.map} 2> /dev/null


> @noble/[email protected] build
> tsc && tsc -p tsconfig.cjs.json


> @noble/[email protected] bench:install
> cd benchmark; npm install; npm install .. --install-links

...

ed25519
init 18ms
getPublicKey x 10,599 ops/sec @ 94μs/op ± 1.66% (78μs..3ms)
sign x 5,189 ops/sec @ 192μs/op
verify x 1,096 ops/sec @ 911μs/op ± 3.45% (773μs..6ms)

ed448
init 39ms
getPublicKey x 4,616 ops/sec @ 216μs/op
sign x 2,167 ops/sec @ 461μs/op
verify x 459 ops/sec @ 2ms/op

...

After (another try)

ed25519
init 18ms
getPublicKey x 10,360 ops/sec @ 96μs/op ± 1.07% (81μs..1ms)
sign x 5,203 ops/sec @ 192μs/op
verify x 1,147 ops/sec @ 871μs/op

ed448
init 39ms
getPublicKey x 4,557 ops/sec @ 219μs/op
sign x 2,162 ops/sec @ 462μs/op
verify x 442 ops/sec @ 2ms/op ± 1.85% (2ms..9ms)

[paulmillr]

Is it necessary to expose it?

[kigawas]

That's a good question, I'd expose it for two reasons:

1. In rust (ed25519-dalek) and go (standard library), user can get the exposed Scalar
2. Currently we are already exposing scalar through getExtendedPublicKey, with some extra calls

[paulmillr]

I've decided to not expose it for now, because the lib needs to have feature parity with 4kb noble-ed25519. fromPrivateKey is still in though.

[kigawas]

I see. You can easily update it here when you're ready

https://github.com/paulmillr/noble-ed25519/blob/main/index.ts#L245

[paulmillr]

Not really.

ed25519 does not support synchronous hashing out-of-box because it requires no deps. Curves, on the other hand, use noble-hashes.

Because of that, ed25519 provides two implementations: async (using built-in crypto.subtle) and sync (which requires connecting to hashing library first).

So utils will need TWO functions, not one. And it's already a mess with 2 getExtPubkey, 2 getPubkey, 2 sign, 2 verify, etc.

[kigawas]

I think we may need a better abstraction for the sync and async crypto just like @noble/ciphers/webcrypto

[paulmillr]

yeah