Discussion on the native support for BN254 curve

[bbist]

After the successful completion of addition of BLS12-381 curve, we want to start a discussion on addition of BN254 curve. We've already submitted a CPS proposal, and started a community forum discussion. While the forum post is open for comment, it makes sense to start a discussion here to reach a bigger audience and more stakeholders so that meaningful development of Zero-Knowledge powered applications on ICON is not postponed.

Implementation
We have utilized the code from the BN128 codebase of the EthereumJ client and have achieved a basic integration. Note that this is just for PoC and is not the final form.

In the final form, we intend to incorporate comprehensive trusted tests for curve operations sourced from Google and Cloudflare to ensure the code's quality and reliability. These tests have helped maintain the security of curve operations on Ethereum and thus will help validate the correctness and performance of the curve operations, ensuring that the integration meets the desired standards.

Unless a bug is found on Ethereum's implementation, once released, our implementation would not require any changes. Given how long the code has been running on Ethereum, the chances of the bug is pretty unlikely.

Benefits of the BN254 Curve: Community Base, Tooling Support, and Circuit Compatibility
BN254 curve boasts a vast community base and robust tooling support, making it an attractive choice for numerous projects. The widely used circomlib library, for instance, retains all its circuits and Javascript client library compatible with the BN254 curve. Notably, this library capitalizes on the baby jubjub curve, which possesses a unique property: its base field aligns with the scalar field of the BN254. This alignment enables the native SNARK computation to be leveraged for an efficient implementation. Consequently, various crucial functionalities, such as the implementation of Pedersen hash/commitments, Poseidon hash/shared_key_encryption, EdDSA signature verification on a snark circuit, and other use cases, have been made possible.

Accelerating Privacy-Preserving Protocols and Applications in the ICON Network: Leveraging the BN254 Curve
The constructs discussed above serve as the foundation for major privacy-preserving protocols (like Semaphore) and applications (like Railgun). With BN254, bringing these into the ICON network would only require minimal changes to the frontend and smart contracts, as the circuits and utility libraries can be reused. Without the BN254 curve, however, developers would need to implement some of these circuits from scratch, which presents significant challenges. Writing circuits requires an in-depth understanding of mathematics and cryptography, making it an expensive, complex, and time-consuming task. Moreover, starting from scratch introduces a higher risk of potential bugs.

BN254 Curve Adoption: Security and Reliability in Practice
BLS12-381 indeed provides a better security of 120 bits over 100 bits for BN254. However, the BN254 curve is secure enough that many-large scale projects still rely on it. These include:

• Polygon zkEVM: The alt_bn128 curve is employed within the Polygon zkEVM implementation.
• zkSync: The BN254 or altBN128 curve is used for the final commitment verifier in zksync/VerifierTemplate.sol.
• Loopring: The bn128 curve is employed in protocols/Verifier.sol within the Loopring project.
• Scroll zkEVM: The bn254 curve is utilized in the PLONK verifier within the scroll-zkevm repository.

Conclusion
While it is anticipated that these projects will eventually transition to the BLS12-381 curve as tooling support improves, the current landscape suggests that this migration process will require a substantial amount of time. By incorporating the BN254 curve into the ICON network, we aim to facilitate a seamless development experience for dApp developers and enable them to build new applications or repurpose existing ones, while leveraging the available resources. It is worth noting that working with Zero Knowledge protocols can be challenging, even for experienced developers. Therefore, it is imperative that we prioritize simplifying the initial steps for developers to embark on their Zero Knowledge journey. Should individuals desire enhanced security, they can always opt to switch to utilizing the BLS12-381 curve.

[bbist]

Hi @sink772,

Did you have some time to review this, it'd be great to continue the discussion. We have some comments in our CPS proposal, where validators seems to want a participation from the goloop team.
https://cps.icon.community/proposals/bafybeicrrpvx7qiwswx7omhibunm67vaiowlhimb55vsfv7fonu7skfnry