Improve EcRecover precompile performance #9053

siladu · 2025-08-11T03:32:50Z

In draft awaiting testing.

Use LibSecp256k1JNI by default and fallback to SECP256K1 signature algorithm which uses LibSecp256k1 native lib as well as Java fallback. In reality, the backend lib (bitcoin-core-secp256k1) is the same so should always use LibSecp256k1JNI if available.
ECRECPrecompiledContractTest and ECRecoverBenchmark only switches between LibSecp256k1JNI and Java (LibSecp256k1 is effectively ignored for this precompile in reality).
R1 chains will use SECP256R1 SignatureAlgorithm (native/java) as before.
~~- Add --Xecrecover-precompile-native-enabled to disable LibSecp256k1JNI.~~

If --Xsecp-native-enabled=true (default) and LibSecp256k1JNI is available then use that.
If --Xsecp-native-enabled=false or native lib not available, then use Java.

Removed `--Xecrecover-precompile-native-enabled` in second iteration following review. Expand for out-of-date details

Flag combinations showing interaction between LibSecp256k1JNI used for precompile-only versus SECP256K1 used for precompile fallback as well as other key operations apart from EcRecover. The default for both flags is `true`:

default:

--Xecrecover-precompile-native-enabled=true --Xsecp-native-enabled=true
2025-08-11 13:16:34.899+10:00 | main | INFO  | Besu | Using the native implementation of the signature algorithm
2025-08-11 13:16:35.039+10:00 | main | INFO  | Besu | Using the native implementation of ecrecover precompile

JNI lib used for ecrecover, but Java used for other secp operations:

--Xecrecover-precompile-native-enabled=true --Xsecp-native-enabled=false
2025-08-11 13:16:48.220+10:00 | main | INFO  | Besu | Using the Java implementation of the signature algorithm
2025-08-11 13:16:48.373+10:00 | main | INFO  | Besu | Using the native implementation of ecrecover precompile

Disable JNI lib, fallback to SECP256K1 for ecrecover:

--Xecrecover-precompile-native-enabled=false --Xsecp-native-enabled=true
2025-08-11 13:16:15.395+10:00 | main | INFO  | Besu | Using the native implementation of the signature algorithm
2025-08-11 13:16:15.544+10:00 | main | INFO  | Besu | Using the native secp256k1 signature algorithm implementation of ecrecover

Disable both, use Java for ecrecover:

--Xecrecover-precompile-native-enabled=false --Xsecp-native-enabled=false
2025-08-11 13:16:03.316+10:00 | main | INFO  | Besu | Using the Java implementation of the signature algorithm
2025-08-11 13:16:03.560+10:00 | main | INFO  | Besu | Using the Java secp256k1 implementation of ecrecover

Testing

Currently running on gas-benchmarks suite and perf-devnet-1 via https://github.com/hyperledger/besu/tree/performance and improvement is clear:

Ongoing: ~~full~~ snap sync of perf-devnet-1
Looking into fuzzing.

…k1JNI Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

- Use LibSecp256k1JNI by default and fallback to SECP256K1 signature algorithm which uses LibSecp256k1 native lib (as well as Java fallback). - Add --Xecrecover-precompile-native-enabled to disable LibSecp256k1JNI. - ECRecoverBenchmark switches between LibSecp256k1JNI and Java. Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

ethereum/evmtool/src/main/java/org/hyperledger/besu/evmtool/benchmarks/ECRecoverBenchmark.java

garyschulte

Few comments - nothing major. It would be good to mark the prior native path with deprecation IMO. There isn't a need to keep that code path around once the single-entrypoint-ecrecover is proven.

ethereum/evmtool/src/main/java/org/hyperledger/besu/evmtool/benchmarks/ECRecoverBenchmark.java

garyschulte · 2025-08-11T21:44:59Z

app/src/main/java/org/hyperledger/besu/cli/BesuCommand.java

+      logger.info("Using the native implementation of ecrecover precompile");
+    } else {
+      ECRECPrecompiledContract.disableNative();
+      if (SignatureAlgorithmFactory.getInstance().isNative()) {


This is a little confusing because disableNative should force isNative to be false AFAICT? is this if statement necessary in that case?

Yeh there's two layers of disabling because SECP256K1 is used in both ecrecover and in transactions.
I agree it's a little odd, but with the benefit of supporting a fallback native option if the new one isn't supported. Maybe doesn't make sense if it's the same native lib backend?

The alternative is to never attempt to use LibSecp256K1 if we wish to disable LibSecp256K1JNI...but I think I'd have to disable that only in the precompile and leave it enabled for the other use cases.

Note, there already exists --Xsecp-native-enabled.
A simpler approach would be to only disable the JNI wrapper if this is set to false, so for K1 ecrecover it's only ever new JNI lib or Java (and remove the new option).

maybe a comment here could clarify for future-us why we are double-disabling.

Removed double layer disabling and now driving LibSecp256K1JNI enable/disable via SignatureAlgorithm.isNative

ethereum/evmtool/src/main/java/org/hyperledger/besu/evmtool/benchmarks/P256VerifyBenchmark.java

garyschulte · 2025-08-11T21:53:36Z

evm/src/main/java/org/hyperledger/besu/evm/precompile/ECRECPrecompiledContract.java

+    return useNative;
+  }
+
+  /** Disable native. Note SECP256K1 must additionally be disabled to fully disable native */


If we are on an r1 chain, does the same apply?

Might need to chat to you about this.

Is the current expectation for an "r1 chain" that you would use R1 for the precompile as well? Doesn't seem obvious either way to me. If you're transactions are R1, maybe you still want access to a K1 precompile to support various contracts?

IOW, the spec for this precompile is K1, would we want a different precompile for R1?

Can discuss more in the context of the upcoming R1 variant of this PR, but for now I guess it might be safer to only enable the K1JNI lib if the signature algorithm is set to K1?

yeah, ecrecover on a secp256r1 chain will need to use an r1-friendly ecrecover

Agree for ecrecover outside the scope of the precompile.
but for the precompile, that would break any public network-based contracts that use k1 precompile though?

Feels like we might need a separate R1 ecrecover precompile?

Perhaps we can subclass and configure or compose ecrecover precompile for both r1 and k1. I am keen to avoid any complexity with precompile registry per-hardfork specs. For example, ideally "london-is-london" and we don't have to define a separate protocol schedule with different precompile config for an r1 chain.

It might even be worth pushing the optimized signature recovery into SignatureAlgorithm in the same way it was done previously for the native implementation. In essence we leave ECRECPrecompiledContract as-is and choose the native implementation (or not) in SignatureAlgorithm

@daniellehrner - can you shed light on the original requirements for ecrecover for r1 chains?

Have isolated these changes to K1 so this PR does not impact R1 chains.

I have not pushed the impl to SignatureAlgorithm as suggested. I attempted it, but you still end up with the same amount of complexity in ECRECPrecompiledContract due to different interface requirements between the precompile and SignatureAlgorithm.

We can revisit when writing the upcoming R1 EcRecover PR, however for it to be worth the complexity, I think we need to redesign the SigAlg ecrecover interface across the board (not just for the precompile).

evm/src/main/java/org/hyperledger/besu/evm/precompile/ECRECPrecompiledContract.java

- remove TODOs - Handle exception Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Remove --Xecrecover-precompile-native-enabled Can now only disable for testing purposes Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

…improvements Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

macfarla · 2025-08-26T01:35:06Z

evm/src/main/java/org/hyperledger/besu/evm/precompile/ECRECPrecompiledContract.java

      final Bytes input, @NotNull final MessageFrame messageFrame) {
    final int size = input.size();
-    final Bytes d = size >= 128 ? input : Bytes.wrap(input, MutableBytes.create(128 - size));
-    final Bytes32 h = Bytes32.wrap(d, 0);


this second wrap to Bytes32 was just not needed?

It's moved both inside computeK1Native and computeDefault, also renamed from h -> messageHash

I could have calculated outside and passed it in but thought the unary method signature of computeX(safeInput) was clearer than computeX(safeInput, messageHash)

ok that makes sense

macfarla · 2025-08-26T01:47:26Z

evm/src/main/java/org/hyperledger/besu/evm/precompile/ECRECPrecompiledContract.java

+
+      // SECP256K1#PublicKey#recoverFromSignature throws an Illegal argument exception
+      // when it is unable to recover the key. There is not a straightforward way to
+      // check the arguments ahead of time to determine if the fail will happen and


Suggested change

// check the arguments ahead of time to determine if the fail will happen and

// check the arguments ahead of time to determine whether the fail will happen.

macfarla

think this looks ok to me if it has synced perf-devnet-1

…improvements Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

siladu · 2025-08-29T00:31:52Z

Testing update: SNAP synced perf-devnet-1 and FULL sync hoodi.

- Use LibSecp256k1JNI by default and fallback to SECP256K1 signature algorithm which uses LibSecp256k1 native lib as well as Java fallback. In reality, the backend lib (bitcoin-core-secp256k1) is the same so should always use LibSecp256k1JNI if either available. - ECRECPrecompiledContractTest and ECRecoverBenchmark only switches between LibSecp256k1JNI and Java (LibSecp256k1 is effectively ignored for this precompile in reality). - R1 chains will use SECP256R1 SignatureAlgorithm (native/java) as before. - If --Xsecp-native-enabled=true (default) and LibSecp256k1JNI is available then use that. - If --Xsecp-native-enabled=false or native lib not available, then use Java. --------- Signed-off-by: Simon Dudley <simon.dudley@consensys.net> Co-authored-by: garyschulte <garyschulte@gmail.com>

- Use LibSecp256k1JNI by default and fallback to SECP256K1 signature algorithm which uses LibSecp256k1 native lib as well as Java fallback. In reality, the backend lib (bitcoin-core-secp256k1) is the same so should always use LibSecp256k1JNI if either available. - ECRECPrecompiledContractTest and ECRecoverBenchmark only switches between LibSecp256k1JNI and Java (LibSecp256k1 is effectively ignored for this precompile in reality). - R1 chains will use SECP256R1 SignatureAlgorithm (native/java) as before. - If --Xsecp-native-enabled=true (default) and LibSecp256k1JNI is available then use that. - If --Xsecp-native-enabled=false or native lib not available, then use Java. --------- Signed-off-by: Simon Dudley <simon.dudley@consensys.net> Co-authored-by: garyschulte <garyschulte@gmail.com> Signed-off-by: jflo <justin+github@florentine.us>

- Use LibSecp256k1JNI by default and fallback to SECP256K1 signature algorithm which uses LibSecp256k1 native lib as well as Java fallback. In reality, the backend lib (bitcoin-core-secp256k1) is the same so should always use LibSecp256k1JNI if either available. - ECRECPrecompiledContractTest and ECRecoverBenchmark only switches between LibSecp256k1JNI and Java (LibSecp256k1 is effectively ignored for this precompile in reality). - R1 chains will use SECP256R1 SignatureAlgorithm (native/java) as before. - If --Xsecp-native-enabled=true (default) and LibSecp256k1JNI is available then use that. - If --Xsecp-native-enabled=false or native lib not available, then use Java. --------- Signed-off-by: Simon Dudley <simon.dudley@consensys.net> Co-authored-by: garyschulte <garyschulte@gmail.com> Signed-off-by: georgereuben <reubengeorge101@gmail.com>

siladu added 2 commits August 11, 2025 12:33

Refactor ECRECPrecompiledContract to prepare for wiring in LibSecp256…

ccf7477

…k1JNI Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

siladu added the performance label Aug 11, 2025

jflo reviewed Aug 11, 2025

View reviewed changes

ethereum/evmtool/src/main/java/org/hyperledger/besu/evmtool/benchmarks/ECRecoverBenchmark.java Outdated Show resolved Hide resolved

garyschulte reviewed Aug 11, 2025

View reviewed changes

siladu and others added 6 commits August 12, 2025 11:05

Review comments:

1de01cb

- remove TODOs - Handle exception Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Only use LibSecp256k1JNI when chain is using K1 curve

f7818d5

Remove --Xecrecover-precompile-native-enabled Can now only disable for testing purposes Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Couple LibSecp256k1JNI enablement with SignatureAlgorithm

3098127

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Merge remote-tracking branch 'upstream/main' into ecrecoverk1-native-…

cf9d9bb

…improvements Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Merge remote-tracking branch 'upstream/main' into ecrecoverk1-native-…

885f86f

…improvements Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

Merge branch 'main' into ecrecoverk1-native-improvements

08d3176

macfarla reviewed Aug 26, 2025

View reviewed changes

macfarla approved these changes Aug 26, 2025

View reviewed changes

Merge remote-tracking branch 'upstream/main' into ecrecoverk1-native-…

03f698d

…improvements Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

siladu force-pushed the ecrecoverk1-native-improvements branch from c4c01ee to 03f698d Compare August 28, 2025 05:45

siladu added 2 commits August 29, 2025 10:29

Merge remote-tracking branch 'upstream/main' into ecrecoverk1-native-…

b742293

…improvements Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

changelog

a73b057

Signed-off-by: Simon Dudley <simon.dudley@consensys.net>

siladu marked this pull request as ready for review August 29, 2025 00:31

siladu merged commit c80e23f into hyperledger:main Aug 29, 2025
46 checks passed

siladu deleted the ecrecoverk1-native-improvements branch August 29, 2025 01:12

	// check the arguments ahead of time to determine if the fail will happen and
	// check the arguments ahead of time to determine whether the fail will happen.

Improve EcRecover precompile performance #9053

Improve EcRecover precompile performance #9053

Uh oh!

Conversation

siladu commented Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing

Uh oh!

Uh oh!

garyschulte left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

siladu Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

siladu Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

macfarla left a comment

Choose a reason for hiding this comment

Uh oh!

siladu commented Aug 29, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

siladu commented Aug 11, 2025 •

edited

Loading

siladu Aug 12, 2025 •

edited

Loading

siladu Aug 12, 2025 •

edited

Loading