Slow precompiles for alt_bn128 curve

Intro

Timeout restrictions on Tron have previously prevented the ability to deploy certain zkSNARK-based applications. This issue has been identified in the past and the root problem has not yet been addressed ( #4311).

In this prs, we directly address this issue and propose an implementation that solves it ( zkBob#1,zkBob/zksnark-java-sdk#1 ). By optimizing the bn128 precompiles, zk-based apps and zkSNARKs verification processes become usable on Tron.

It’s important to note that these changes will not only enable the zkBob application on Tron, but also a whole class of applications and protocols based on elliptic curve cryptography and pairings in particular. The possibilities brought by ZKP are not limited to privacy focused protocols, some other examples include zk based auth for AA wallets, light clients, zk based bridges, computational integrity enforcing contracts, and many others.

System information

java-tron version: java -jar FullNode.jar -v
OS & Version: Linux
Branch: master

Expected behaviour

The verifyProof method of a contract for checking pairing over alt_bn128 curve as a part of Groth16 proof system which includes 6 point addition, 5 point multiplication and pairing check itself gives an appropriate result given a valid input.

Actual behaviour

A contract fails to return the result due to timeout error because of an unoptimized implementation of the bn128 precompiles (Multiplication , Addition , Pairing)

Steps to reproduce the behaviour

Reproducing on private network

Create a private network using official docs
Deploy a contract to the network using tronbox
Call the contract using a tron box with any parameters, here’s an example from one of successful transaction on Polygon

let result = await contract.verifyProof(
        [
            "410187940904267791665857625594021464304867517571189176088693585418403627175", 
            "3582932279793408241095145848517164196468279227198151416866003392249976328215", 
            "21702782062704102408149255137659156834040101148294719406156063531394617768752",
            "458964024542843322412024634467191796783627388968596258037504", 
            "1105154793589499054101509063059520053678357711567632030398761789118900390304"
        ], [
            "17319632901362089667297833381115050472198619632678725143485052131880736564716", 
            "20217952180782984327874966839451172866880046964759060634104328470666346490787", 
            "14675072293281706791212610449476963932780136199834552157253791069835791205313", 
            "11523869594945451880407802780789187832894590986555492595351670286111658956891", 
            "3618836117018041122057960110621015024190242066995639123523823804179020820127", 
            "17452347979391447598200144953804022165728450595367847105208004839301667143347", 
            "10758418988168490454233654079316113438289985487422580576512164625214747833303", 
            "16113585132297177719187882899369575704186199591529360947329945124938113973184"
        ]
    ).call();

It can be checked on Polygonscan (https://polygonscan.com/address/0xa86c511832ead78d30ad49711874a9f3a1dfb840#readContract) , with the same arguments:
[410187940904267791665857625594021464304867517571189176088693585418403627175,3582932279793408241095145848517164196468279227198151416866003392249976328215,21702782062704102408149255137659156834040101148294719406156063531394617768752,458964024542843322412024634467191796783627388968596258037504,1105154793589499054101509063059520053678357711567632030398761789118900390304]
[17319632901362089667297833381115050472198619632678725143485052131880736564716,20217952180782984327874966839451172866880046964759060634104328470666346490787,14675072293281706791212610449476963932780136199834552157253791069835791205313,11523869594945451880407802780789187832894590986555492595351670286111658956891,3618836117018041122057960110621015024190242066995639123523823804179020820127,17452347979391447598200144953804022165728450595367847105208004839301667143347,10758418988168490454233654079316113438289985487422580576512164625214747833303,16113585132297177719187882899369575704186199591529360947329945124938113973184]

We have created a dedicated repo for this particular purpose: https://github.com/zkBob/tron-local . It contains both a script to deploy contract and to call the verifyProof method.

Place FullNode.jar into bin folder
./scripts/run.sh
./scripts/deploy.sh
set contract address from deploy output to TRANSFER_VERIFIER_ADDRESS in .env
./scripts/verify.sh returns class org.tron.core.vm.program.Program$OutOfTimeException : CPU timeout for 'SWAP1' operation executing

Reproducing on testnet
The same contract is also deployed on Shasta and returns the same error :
https://shasta.tronscan.org/#/contract/TPf7skGEB8h7VPSbd2S1CfxjWSJfPKHpQG/code

Backtrace

org.tron.core.vm.program.Program$OutOfTimeException : CPU timeout for 'SWAP1' operation executing

@yanghang8612

That's a great job! Looking forward to further progress.

@yanghang8612 @Federico2014

Thanks for your work, we are reviewing the code. Any progress will be synced here.

Very glad to see this work! I have two questions:

After optimizing the bn128 precompiles, how long will one this transaction cost normaolly?
According to Timeout in calls to comparatively low energy consuming contracts #4311, maybe one transaction costs 120ms before optimizing, thus if we increase the maximum time limitation of TVM to longer than 120ms, will this solve the problem here?

Based on some research, we can discuss whether increasing the duration of individual transactions to avoid operation execution timeouts can solve this issue.

@CarlChaoCarl

@yuekun0707 @CarlChaoCarl
You can see benchmarks here:
#5507
Copying it here
The average time of operations before (Intel(R) Core(TM) i7-10750H CPU, 32 GB RAM):

BN128Addition: 66387 ns
BN128Multiplication: 3553350 ns
BN128Pairing (10 pairs): 101565419 ns

The average time of operations after:

BN128Addition: 11576 ns
BN128Multiplication: 181301 ns
BN128Pairing (10 pairs): 3285601 ns

So the gain is 6x - 30x for different ops, whereas BN128Pairing gains even more when more pairs are checked

It's really hard for us to give any useful and reasonable opinion on possible timeout values, because

it is strongly dependent on the node technical specs
curve operations are used as building blocks for vastly different applications. It seems to me that any proposed value could still become restricting for some applications out there. This PR was not meant to enable just ZkBob protocol but a more broad class of applications based on ZkSnarks

So despite the fact that timeout increase seems to be an easier/faster solution for ZkBob I would say that it should have a lesser priority than optimizations and should be considered as last resort
But that of course is left for Tron team to decide.

@CarlChaoCarl

@yuekun0707 @CarlChaoCarl You can see benchmarks here: #5507 Copying it here The average time of operations before (Intel(R) Core(TM) i7-10750H CPU, 32 GB RAM):
BN128Addition: 66387 ns
BN128Multiplication: 3553350 ns
BN128Pairing (10 pairs): 101565419 ns
The average time of operations after:
BN128Addition: 11576 ns
BN128Multiplication: 181301 ns
BN128Pairing (10 pairs): 3285601 ns
So the gain is 6x - 30x for different ops, whereas BN128Pairing gains even more when more pairs are checked

It's really hard for us to give any useful and reasonable opinion on possible timeout values, because

it is strongly dependent on the node technical specs

curve operations are used as building blocks for vastly different applications. It seems to me that any proposed value could still become restricting for some applications out there. This PR was not meant to enable just ZkBob protocol but a more broad class of applications based on ZkSnarks

So despite the fact that timeout increase seems to be an easier/faster solution for ZkBob I would say that it should have a lesser priority than optimizations and should be considered as last resort But that of course is left for Tron team to decide.

@r0wdy1 thanks very much for your information, the statistical data shows great improvement!
Thus, after the optimization and the test, the limit of the maximum time limitation of TVM which is 80ms now is enough for these Zk transactions mostly? If yes, we realy don't need to increase it recently.

Thus, after the optimization and the test, the limit of the maximum time limitation of TVM which is 80ms now is enough for these Zk transactions mostly? If yes, we realy don't need to increase it recently.

Yes current timeout would be sufficient to execute multiple (15-20) pairings with a reasonable amount of pairs in a single transaction, whereas even a single one used to cause timeout but that off course depends on particular node specs.

@r0wdy1

Thus, after the optimization and the test, the limit of the maximum time limitation of TVM which is 80ms now is enough for these Zk transactions mostly? If yes, we realy don't need to increase it recently.

Yes current timeout would be sufficient to execute multiple (15-20) pairings with a reasonable amount of pairs in a single transaction, whereas even a single one used to cause timeout but that off course depends on particular node specs.

@r0wdy1 Great! Thanks for your replay, I have no more questions~

Can this technology be used to layer-2 scaling solution ZK Rollups?

Can this technology be used to layer-2 scaling solution ZK Rollups?

If the underlying algorithm used by ZK rollup adopts the above calculation formula, this optimization may be beneficial to ZK rollup.

@yumenguan

@yumenguan @tomatoishealthy
Some of the scaling solution utilize KZG commitments (like Ethereum Danksharding ) or Groth16/Halo2 which means that they depend on elliptic curve pairings
This issue is specifically dedicated to fix that

@yumenguan

@yumenguan @tomatoishealthy Some of the scaling solution utilize KZG commitments (like Ethereum Danksharding ) or Groth16/Halo2 which means that they depend on elliptic curve pairings This issue is specifically dedicated to fix that

Get it.

This is a complex issue that requires a deeper dive and more research to ensure we get it right. We will also be sharing progress updates in the upcoming developer meetings, so please keep an eye out for the meeting announcements.

While we work on this, the issue will remain open. We highly value community input, so if you have any insights, potential approaches, or further suggestions, please don’t hesitate to comment. All ideas are welcome.

Regarding the progress of this issue, please refer to: #6374

@r0wdy1

@r0wdy1 @lxcmyf Since this has been discussed in #6374 , would it make sense to close this one and continue the conversation there?

Navigation Menu

Repository navigation

Slow precompiles for alt_bn128 curve #5492

Intro

System information

Expected behaviour

Actual behaviour

Steps to reproduce the behaviour

Backtrace

52 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Slow precompiles for alt_bn128 curve #5492

Description

Intro

System information

Expected behaviour

Actual behaviour

Steps to reproduce the behaviour

Backtrace

Activity

tomatoishealthy commented on Sep 14, 2023

yanghang8612 commented on Sep 14, 2023

kuny0707 commented on Oct 17, 2023

CarlChaoCarl commented on Oct 17, 2023

r0wdy1 commented on Oct 17, 2023

kuny0707 commented on Oct 18, 2023

r0wdy1 commented on Oct 18, 2023

kuny0707 commented on Oct 18, 2023

52 remaining items

abn2357 commented on Jun 16, 2024

tomatoishealthy commented on Jun 18, 2024

r0wdy1 commented on Jun 18, 2024

tomatoishealthy commented on Jul 4, 2024

lxcmyf commented on Jul 29, 2025

lxcmyf commented on Sep 29, 2025

waynercheung commented on May 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions