Discussion: Native BN254 Precompiles via Rust FFI

[anishnarang9]

This issue is the discussion thread for a draft TIP proposing a native Rust-backed implementation of the generic BN254 precompiles at 0x06, 0x07, and 0x08.

Scope of the draft:

• preserve the existing precompile addresses
• match EIP-196 / EIP-197 calldata semantics
• activate through deterministic committee governance
• keep conservative pricing in this TIP
• focus on the generic BN254 / Groth16 path, not TRONZ / TIP-137

Companion implementation and evidence repository:

• https://github.com/anishnarang9/pennblockchain26

I will link the draft TIP PR here once it is opened.

[anishnarang9]

Draft TIP PR opened: #847

[Federico2014]

@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.

[waynercheung]

@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.

[anishnarang9]

@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.