Dear ICON Community,
We express our deepest gratitude for the unwavering support extended to us in implementing the BLS12-381 curve addition on the ICON network. This remarkable achievement has significantly enhanced the ICON network’s capabilities by opening native support for zkSNARKS for application developers, thereby enabling the implementation of complex privacy projects.
While the integration of the BLS12-381 curve offers a viable solution for privacy-oriented endeavors, we would like to initiate a discussion within the ICON community regarding the potential inclusion of the BN254 curve. Prior to submitting a CPS proposal, we believe it is crucial to share our reasons for considering this addition.
Given that we have already implemented support for the BLS12-381 curve, we believe it would be prudent to offer the option of utilizing the BN254 curve as well. The BN254 curve boasts a vast community base and robust tooling support, making it an attractive choice for numerous projects. It is important to acknowledge that although the eventual migration towards the BLS12-381 curve may be inevitable, it will require considerable time to achieve full adoption in terms of available tooling and library support.
One important factor to consider is the comprehensive tooling support and existing community surrounding the BN254 curve. 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 a curve known as [baby jubjub](https://github.com/iden3/circomlib/blob/master/circuits/babyjub.circom), which possesses a unique property: its base field aligns with the scalar field of the BN254 curve. This alignment enables the native snark computation to be leveraged for an efficient implementation of the baby jubjub curve. 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.
It is important to note that the JubJub curve is designed to work with the BLS12-381 curve, with its base field size identical to the scalar field size of BLS12-381. But the ecosystem has not caught up to its use so far.
Additionally, many existing projects and their publicly available client libraries are tailored to operate with the BN254 curve. Incorporating the BN254 curve into the ICON network would facilitate the integration of zkSNARK-based solutions with minimal friction. By aligning with widely used standards and libraries, the adoption of such solutions within the ICON ecosystem becomes considerably easier.
While it is technically possible to rewrite the circom libraries to employ the Jubjub curve instead of the baby Jubjub curve, the reality is that client library support for this transition is currently lacking. Although large-scale projects with substantial funding might be able to develop their own libraries and choose to utilize the BLS12-381 curve, the absence of readily available libraries poses significant challenges for dApp development teams seeking to leverage existing resources.
By considering the inclusion of the BN254 curve, we aim to foster compatibility, ease of adoption, and integration with established tools and libraries. This approach will empower the ICON community, particularly dApp developers, to harness the advantages of zkSNARK-based solutions without impeding their progress or requiring substantial redevelopment efforts.
One notable example is the Railgun project, which offers a privacy layer for Ethereum and other EVM chains. Railgun has already developed client libraries that could be readily reused. Without the inclusion of the BN254 curve, developers would face the daunting task of implementing these libraries from scratch, introducing a heightened risk of potential bugs and complexities.
Moreover, it is essential to recognize that many large-scale projects still rely on the BN254 curve. While it is anticipated that these projects will gradually 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.
The following examples illustrate the importance and practical relevance of incorporating the BN254 curve into our ecosystem:
- Polygon zkEVM: The alt_bn128 curve is employed within the Polygon zkEVM implementation. (Reference: Polygon zkEVM Contracts)
- Railgun: Railgun utilizes the same pre-compile and specifies it as 8 in the second argument to staticcall in the contract/Snark.sol file. (Reference: Railgun Contract Snark.sol)
- zkSync: The BN254 or altBN128 curve is used for the final commitment verifier in zksync/VerifierTemplate.sol. (Reference: zkSync VerifierTemplate.sol)
- Loopring: The bn128 curve is employed in protocols/Verifier.sol within the Loopring project. (Reference: Loopring Verifier.sol)
- Scroll zkEVM: The bn254 curve is utilized in the PLONK verifier within the scroll-zkevm repository. (Reference: Scroll-zkevm Verifier.rs)
Furthermore, it is worth noting that the BN254 curve offers an attractive balance between performance and security. While it provides approximately 100 bits of security compared to the 120 bits of the BLS12-381 curve, most Zero Knowledge solutions prioritize a trade-off between performance and security. For instance, in a multi-layer proof system, the first-level proof can be generated using a different proof system, while verification of that proof can still be accomplished using the BN254 curve. Groth16 on BN254 represents the most cost-effective proof to verify, and its existing support through audited libraries makes it a favorable choice for teams opting for BN254 in final proof verification.
To illustrate this distinction, we have developed a minimal Sudoku application available at https://v23-zkp-examples-sudoku.vercel.app/. The application allows users to switch between SHA256 Hash and Pedersen Hash. The SHA256 circuit, which is not elliptic curve-based, exhibits approximately 30,000 additional constraints compared to the Pedersen-based circuit. Utilizing an algebraic hash, such as Pedersen, proves highly efficient within SNARK, enabling significant constraint reduction when implementing an on-chain Merkle tree. In fact, the difference is so substantial that generating a proof of membership within a 20-level Merkle tree takes 10 seconds using an algebraic hash, whereas it takes over 2 minutes when employing SHA256, which is not elliptic curve-based.
Based on these findings, we strongly believe it is crucial to engage in a discussion with the ICON community regarding the benefits of adding the BN254 curve to the ICON network. By doing so, we can ensure the network remains well-equipped with the BN254 curve until other infrastructures and libraries are ready to transition to the BLS12-381 curve.
By the way, we have leveraged the code from the EthereumJ client’s BN128 codebase, which can be found at EthereumJ BN128 Codebase. Please note that while the EthereumJ client is now deprecated, the bn128 code remains stable and sufficient for our purposes. You can find our crude integration at Venture23-zkp BN128 Integration.
The Sudoku app featured in our previous discussion utilizes this implementation. It randomly selects a board from the contract and reloads the page until a board is obtained with only the second-to-last element (bottom right) set to 0. Subsequently, it replaces this element with 8 for testing purposes. We encourage you to explore both the SHA256 and Pedersen circuits within the app. Please be aware that the initial verification may take additional time as the assets load, but subsequent verifications will demonstrate fair proof times.
We strongly believe that the inclusion of the BN254 curve will significantly facilitate the development of Zero Knowledge-based applications for ICON Network dApp developers. By incorporating the BN254 curve, developers within the ICON ecosystem can prioritize the design and implementation of privacy-preserving applications without the burden of adding client library support.
We highly value your opinions and insights on this matter, and we encourage you to share your thoughts with the community. Through an open and collaborative dialogue, we aim to ensure that any decisions made align with the best interests of the ICON ecosystem.
Once again, we extend our sincere appreciation for your continuous support and look forward to the forthcoming discussions.
Warm regards,
Venture23 ZKP team