Finally after 18 mos, my PR to gnark got merged: BLS12-381 G2 signature verification circuit implementation. My original PR was github.com/Consensys/gnark/p… Then @ikubjas developed more codes based on it and it became github.com/Consensys/gnark/p…, merged four days ago. Glad to contribute.

🌟 Exciting news! Linea is participating in the House of ZK’s Ethproofs Summit on June 10th! Join us for insightful talks from @DeclanFox14, Head of Linea, and @alexand_belling, Principal of Cryptography Research. Don’t miss out on this opportunity to dive deep into the world of zero-knowledge proofs, limitless provers, and more! Sign up here: lu.ma/hozkethproofs

We benchmarked Plonky3’s FRI PCS vs Vortex (@LineaBuild’s polynomial commitment scheme). 🚀 Vortex commitment is 3.7× faster under identical parameters. 📊 Benchmark instructions: hackmd.io/@YaoGalteland/SJ1W… 📚 Theory intro to Vortex: hackmd.io/@YaoGalteland/BJtz…

Another step towards @LineaBuild switching to small fields—Vortex, our polynomial commitment scheme, uses a hash function based on SWIFFT (+Ring-SIS). Optimized AVX512 code github.com/Consensys/gnark-c… lets us hit Blake-level throughput (1750Mb/s)! 🚀

gnark has also been extensively audited. Go see audit reports github.com/consensys/gnark?t… (with @LeastAuthority, @OpenZeppelin, @zksecurityXYZ, @ConsensysAudits). NB! gnark is provided as is and we do not make any guarantees on the safety and reliability.

- inlined G2 membership check in pairing check during Miller loop line computation (@YoussefElHousn3) - a lot of typo fixes (different contributors) And a lot small optimizations. Full list github.com/Consensys/gnark/r…

- small field implementations (BabyBear and KoalaBear) - improved KZG MPC setup primitives - shplonk and fflonk primitives - more examples (Sudoku, recursive proving, input hashing for efficient recursion) - non-native multivariate evaluation (thanks @ikubjas)

- updated ICICLE GPU prover backend for Groth16 over BN254 (thanks @jeremyfelder). Hopefully soon also PLONK and other curves! - emulated and native pairing check optimizations (now almost 2x faster!). Thanks @YoussefElHousn3 - faster ARM proving using assembly. Thanks @zkgbo!

We have released gnark version v0.12.0. See the highlights below: - fixed security advisory github.com/Consensys/gnark/s… which caused OOM during keys deserialization for crafted inputs. Thanks @Pat_Ventuzelo for reporting. - optimized logderivative argument (thanks @mmkostrzewa)

If you're at Devcon, then come see my talk about optimising SNARK recursion in @gnark_team on Wednesday at 12. app.devcon.org/schedule/E8KY…

Dedicated circuit fuzzer for @gnark_team 👇👇👇

See the full list of public gnark audits at github.com/consensys/gnark?t… Follow us here and on Github for more announcements!

We have similar commitment construction for PLONK backend also. But for PLONK we already randomized individual commitments and malleability is prevented through PLONK verification equations.

To confirm - these issues were only theoretically relevant for the Groth16 proving backend in non-standard usage. PLONK was and is safe!

In our fix, when commitment is used, we add a dummy constraint during the circuit compilation time which is then randomized by the prover at proving time. This approach allows us to keep the existing G16 verification equations with minimal prover overhead.

However, in practical circuits the search space explodes quickly to sizes which makes the brute-force approach infeasible. As an example - even doing one non-native multiplication in circuit would already mitigate the attack.

When the search space for the committed witness elements is small, this leads to allowing an attacker to enumerate all values to see which lead to expected commitment value.

The second issue about the ZK-ness of the commitment arises as we didn't blind the commitment as the blinding would have prevented directly checking the G16 verification equations.

To really fix the issue for the proof system, we instead use less efficient batching method which prevents the malleability of the individual commitments.

Instead, if in circuit we need multiple commitments, we batch all commitment calls to a single backend commitment through the multicommit package. gnark's standard gadgets all rely on the multicommit feature.