Plonk + BN254
At the beginning of the project, we considered the Groth16 zero-knowledge proof protocol. Groth 16 is the most concise zk-SNARKs, it features fast verification speed and low cost, and is widely used in blockchain projects, such as Zcash Sapling, Loopring, etc. But Groth16 has a very big shortcoming, that is, it requires a trusted setup. The result is called CRS (Common Reference String), which contains PK (proving key) and VK (verification key) for generating and verifying certificates.
The setup of Groth16 is divided into two stages. The first stage can be reused, which means that under a certain circuit scale, different applications can reuse the results of the first stage. However, the result of the second stage is related to the specific application. Every time the circuit is upgraded, the second stage of setup needs to be redone. At present, the industry's common practice in making a trusted setup is generally to use MPC (Multi-Party Ceremony), which takes a relatively long time period.
So, in order to overcome this difficulty, we adopt the more "universal" zero-knowledge proof protocol -- Plonk. The Plonk protocol also requires a trusted setup, and the result of the setup is called SRS (Structured Reference String). Unlike Groth16's CRS, SRS is only used upon verification. Plonk's setup has nothing to do with the specific circuit, only with the scale of the circuit, that is to say, only one setup is required, and the result of setup can be used for circuits that are under a certain scale. As long as our circuit is upgraded below a certain scale, we don't need to do the setup anew. In addition, SRS is also generated through MPC and is upgradeable, which means that developers can add their contributions to generate new SRS based on the original SRS.
After selecting the Plonk protocol, we tied the corresponding pairing-friendly elliptic curve. The two most commonly used curves are BLS12-381 and BN254. BLS12-381 has higher security, delivering 128-bit security, while BN254 only delivers 100-bit security. Given that pairing needs to be calculated when verifying proofs of smart contracts in Ethereum, we use the BN254 curve. After the Byzantium hard forking of Ethereum, EIP-196 and EIP-197 took effect to add precompiled contracts for addition, scalar multiplication, and optimal ate pairing check on alt_bn128-based curves (also known as BN254 curve), greatly reducing the gas consumed by verifying the zero-knowledge proof of BN254. So far, Ethereum also supports pre-compiled contracts for the BLS12-381 curve. After EIP-2537 takes effect or the ETH2.0 upgrade is completed, we can consider replacing it with the BLS12-381 curve.
Copy link