Skip to content

Slow precompiles for alt_bn128 curve #5492

Open
@r0wdy1

Description

@r0wdy1

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

  1. Create a private network using official docs
  2. Deploy a contract to the network using tronbox
  3. 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.

  1. Place FullNode.jar into bin folder
  2. ./scripts/run.sh
  3. ./scripts/deploy.sh
  4. set contract address from deploy output to TRANSFER_VERIFIER_ADDRESS in .env
  5. ./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

Metadata

Metadata

Type

No type

Projects

Status

In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions