Skip to content
This repository has been archived by the owner on Aug 15, 2024. It is now read-only.

Plonk proofs are invalid if bellman is compiled with the wasm feature #38

Open
weijiekoh opened this issue May 16, 2021 · 6 comments
Open

Comments

@weijiekoh
Copy link

Thank you for writing this library! I'm experimenting with using it to produce Plonk proofs in WASM. However, I'm facing an issue.

If I compile using the wasm feature, the Plonk proofs produced are invalid. If I do so with multicore, however, the proofs are valid. This can be seen through this demonstration: https://github.com/weijiekoh/bellman_ce_bug

The underlying issue is that the opening_at_z_omega_proof differs. All other values of the proof match.

@shamatar
Copy link
Member

I'll try to look at it, but are you sure that only an opening at z * omega is different? If it's different then opening proof at z should also not match as they are computed by the same function largely

@weijiekoh
Copy link
Author

weijiekoh commented May 16, 2021

Thanks for taking a look! Only proof.opening_at_z_omega_proof is different. I've updated the demo to print out the whole proof, parameter by parameter. Check out the diff between valid.txt and invalid.txt:

$ diff valid.txt invalid.txt

82,84c82,84
< proof.opening_at_z_omega_proof: G1(x=Fq(0x05a9a24328df520291c63cdfe58ed0e27db283ce9af20d90df677f4d938600cb), y=Fq(0x2aa2b74c71a72e73c61fb265cf2c975f1746aba6c05458c70d89ed8d7f680b7c))
< true
< Proof is valid
---
> proof.opening_at_z_omega_proof: G1(x=Fq(0x0488c95ff1846acf563139c7d068945b7011031bb5a7877b15f5f870cec32376), y=Fq(0x208a64c364fc2224856e321e330b7368ad533fdbcd7bd9aaf55b5a0c1d457ed8))
> false
> Proof is invalid

@eigmax
Copy link

eigmax commented Aug 26, 2022

@weijiekoh, did you figure out the root cause? I have the same issue.

@weijiekoh
Copy link
Author

@weijiekoh, did you figure out the root cause? I have the same issue.

I haven't figured out the cause of the issue unfortunately...

@eigmax
Copy link

eigmax commented Aug 28, 2022

@shamatar openning_at_z_omega is the first difference. I guess the bug is raised here https://github.com/matter-labs/bellman/blob/beta/src/plonk/better_cs/prover/prove_steps.rs#L1296.

Log of:
multicore is
fifth_step_from_fourth_step open_at_z_omega Polynomial { coeffs: [Fr(0x02361fcce2ca9cf1cb4f43798945a44240f065f0d3a8e36a5a0ea87c24fef85b), Fr(0x068643ee72498c100e2152172972ea5c8fb537932be1ee6b149958387dd18913), Fr(0x1936c256f657e9609ff569ff69999bdb10458f585a5ed054cdab96d804692a8a), Fr(0x0000000000000000000000000000000000000000000000000000000000000000)], exp: 2, omega: Fr(0x30644e72e131a029048b6e193fd841045cea24f6fd736bec231204708f703636), omegainv: Fr(0x0000000000000000b3c4d79d41a91758cb49c3517c4604a520cff123608fc9cb), geninv: Fr(0x06e9c21069503b73ac9dc0d0edede80d4ee2d80a5a8834a709b290cbfdb6db6e), minv: Fr(0x244b3ad628e5381f4a3c3448e1210245de26ee365b4b146cf2e9782ef4000001), _marker: PhantomData }

and the wasm is :
fifth_step_from_fourth_step open_at_z_omega Polynomial { coeffs: [Fr(0x1c2e434d815427c845970ff0278872864bf237d0e014e0c5916d65fead0d2346), Fr(0x172d8c1bead9b6c9185adbb717e7bc8217ee58f01f5aa03c76365ebbeb96d577), Fr(0x0375b9b2678a93278faa06e6b397b7d80662320a42be944289c6cd0f7a4ca762), Fr(0x1936c256f657e9609ff569ff69999bdb10458f585a5ed054cdab96d804692a8a)], exp: 2, omega: Fr(0x30644e72e131a029048b6e193fd841045cea24f6fd736bec231204708f703636), omegainv: Fr(0x0000000000000000b3c4d79d41a91758cb49c3517c4604a520cff123608fc9cb), geninv: Fr(0x06e9c21069503b73ac9dc0d0edede80d4ee2d80a5a8834a709b290cbfdb6db6e), minv: Fr(0x244b3ad628e5381f4a3c3448e1210245de26ee365b4b146cf2e9782ef4000001), _marker: PhantomData }

@eigmax
Copy link

eigmax commented Sep 1, 2022

@weijiekoh this issue had been fixed at PR #45.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants