secp256k1: Optimize precomp values to use affine. #2690
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davecgh
force-pushed
the
secp256k1_optimize_precomps_and_base_mult
branch
3 times, most recently
from
af58a2d
to
d886f32
Compare
|
Rebased to the latest master. No changes. |
jrick
reviewed
Aug 4, 2021
matheusd
approved these changes
Aug 5, 2021
rstaudt2
approved these changes
Aug 10, 2021
JoeGruffins
approved these changes
Aug 11, 2021
This separates the code that loads the pre-computed byte points used to accelerate scalar base multiplication from the elliptic adaptor code which further makes the internals of the package independent of the crypto/elliptic and crypto/ecdsa stdlib interfaces. It also takes this opportunity to improve the related code a bit by making it less dependent on magic numbers and defining a proper type for the data table. Finally, it retains and improves the logic which only loads the data on first use by making use of a closure to house and access the loaded data so it is no longer possible to accidentally access the uninitialized pointer.
This removes the code that deals with only initializing the adaptor instance on first use since the adaptor code no longer houses the pre-computed byte points which motivated that behavior.
This optimizes the pre-computed byte points used to accelerate scalar base multiplication to store the data in affine coordinates instead of Jacobian coordinates which reduces the memory usage requirement to 66% of what it current requires and also has the important benefit of further speeding up the computation. This is the case because projecting affine coordinates into Jacobian space is essentially free and the point doubling and addition routines have optimizations which allow them to avoid additional operations when the Z coordinate is 1, which is the case for an initial affine projection. Further, since the compressed table is stored in the string table of the binary, it also reduces the size the of final binary by ~385KiB. The following benchmark shows a before and after comparison of scalar base multiplication as well as how that translates to signature verification: name old time/op new time/op delta ------------------------------------------------------------------------- ScalarBaseMult 34.5µs ± 1% 24.7µs ± 1% -28.43% (p=0.008 n=5+5) ScalarBaseMultLarge 48.2µs ± 1% 38.0µs ± 1% -21.08% (p=0.008 n=5+5) SigVerify 181µs ± 5% 163µs ± 2% -9.86% (p=0.008 n=5+5) While 18 µs less per signature verification might not seem like much on the surface, consider that every transaction requires at least one signature operation, so there are a ton of them when doing no checkpoint syncs. For a concrete number, verifying 100 million signatures would take 30 minutes less time.
davecgh
force-pushed
the
secp256k1_optimize_precomps_and_base_mult
branch
from
d886f32
to
fdfae1a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This optimizes the pre-computed byte points used to accelerate scalar base multiplication to store the data in affine coordinates instead of Jacobian coordinates which reduces the memory usage requirement to 66% of what it current requires and also has the important benefit of further speeding up the computation.
This is the case because projecting affine coordinates into Jacobian space is essentially free and the point doubling and addition routines have optimizations which allow them to avoid additional operations when the Z coordinate is 1, which is the case for an initial affine projection.
Further, since the compressed table is stored in the string table of the binary, it also reduces the size the of final binary by ~385KiB.
There are also a couple of preparatory commits to ease the review process that separates the code that loads the pre-computed byte points from the elliptic adaptor code which further makes the internals of the package independent of the crypto/elliptic and crypto/ecdsa stdlib interfaces.
The following benchmark shows a before and after comparison of scalar base multiplication as well as how that translates to signature verification:
While 18 µs less per signature verification might not seem like much on the surface, consider that every transaction requires at least one signature operation, so there are a ton of them when doing no checkpoint syncs. For a concrete number, verifying 100 million signatures would take 30 minutes less time.