Discussion: Native BN254 Precompiles via Rust FFI #846

Activity

1. anishnarang9 commented on Mar 27, 2026

   

   anishnarang9

   on Mar 27, 2026

   Author

   More actions

   Draft TIP PR opened: #847
2. Federico2014 commented on Mar 28, 2026

   

   Federico2014

   on Mar 28, 2026

   Contributor

   More actions

   @anishnarang9 Thank you very much for your contribution. We have already developed optimizations for the BN254 precompiled contract—see: tronprotocol/java-tron#6374. You can refer to it for comparison.
3. waynercheung commented on Apr 5, 2026

   

   waynercheung

   on Apr 5, 2026

   More actions

   @anishnarang9
   Thank you for the proposal!
   As @Federico2014 mentioned, we’ve been working on BN254 precompile optimization via the besu-gnark approach in #6374. Before we evaluate whether this TIP should move forward independently, could you help clarify a few points:
   1. What native library / backend does your proposal rely on? The current implementation in #6374 uses gnark via Besu’s JNI bridge - does your approach differ here?
   2. Do you have benchmark numbers comparing your approach against both the current Java implementation and the besu-gnark version?
   3. Does this TIP propose any changes to the resources cost model? If so, it would require a network-wide governance vote.

   If your approach offers meaningful advantages (e.g., better multi-platform support, lower latency, simpler dependency chain), we’d love to discuss it further. Otherwise, we may consider folding any improvements into #6374 rather than maintaining a separate implementation path.
4. anishnarang9 commented on Apr 6, 2026

   

   anishnarang9

   on Apr 6, 2026

   Author

   More actions

   @waynercheung Thanks.

   1. This draft uses a Rust ark-bn254 / arkworks backend via JNI, so it differs from the gnark/Besu path in #6374, but it is
      still a native backend behind a JVM bridge.

   2. I have benchmark evidence against the current Java implementation, but I do not yet have a clean apples-to-apples benchmark against java-tron-gnark / besu-gnark. So I cannot honestly claim this approach is better than #6374. Based on the numbers already shared there, gnark appears stronger overall, especially for multiplication and pairing.

   3. This draft is not intended to change the resource cost model. It keeps conservative pricing and only proposes governance-
      gated activation of the native path.

   My honest view is: the Rust/arkworks approach should work, and the current results do show that native acceleration is
   necessary versus the existing Java path. But I do not have enough evidence to argue that it is better than the gnark path
   already under development, so I do not think maintaining a separate implementation track is justified on performance grounds
   alone.
5. anishnarang9

   closed this as completedon Apr 6, 2026