Cryptography

This page motivates the choices made regarding cryptography in Shielder. Some of these choices are not 100% final and are subject to change.

Proof System

We use the Ultraplonk proof system instantiated using a KZG commitment scheme. The concrete implementation will be a variant of Halo2 (see https://github.com/zcash/halo2 and https://github.com/privacy-scaling-explorations/halo2). Rationale:

• We need a reasonably small proof and fast verifier because these are submitted by regular users as part of transactions so gas-efficiency of the verifier plays an important role. This rules out the original Halo2 with IPA as a polynomial commitment (https://github.com/zcash/halo2) as the verifier's work is not polylogarithmic. Similarly hash-based proof systems are still quite expensive when it comes to verification and proof size, hence we decided against.

• The prover also needs to be efficient, because regular users are supposed to generate proofs in browsers (or even on mobile).

• A serious alternative to Ultraplonk is certainly Groth16, which is still state-of-the art and many projects are using it. We decided against mainly for these reasons:

  • We feel that there is lots of innovation and progress around plonk-based proof systems, while Groth16 seems to be just a fully optimized local-optimum.

  • Groth16 is less flexible than Plonk and certainly makes it harder to add custom adjustments that could be necessary for certain features.

  • The per-circuit trusted setup makes Groth16 a little problematic in practice, since every update to the system requires a new ceremony, whereas plonk-based systems have a universal setup.

Elliptic Curve

We need an elliptic curve which supports pairings to be able to use KZG commitments. For the time being we decided to use BN256, at least until support for the BLS12 family of curves is added to Halo2. The final choice will be one of BLS12-381 or BLS12-377 because of increased security level in comparison to BN* and the partial support for recursion in BLS12-377 that we might at some point find useful. It is worth noting that the choice of the Elliptic Curve is probably the only choice that is final and cannot be changed once the system is deployed. That's because the Curve determines the field that our arithmetization (circuits, plonkish tables) will be defined over. Once we have some state committed to chain that uses a particular field to express, it will be close to impossible to move it to another field. That's why the choice of the proof system can be always altered, whereas the curve is chosen once and for all.

Snark-Friendly Hash

We use the Poseidon Hash https://eprint.iacr.org/2019/458 or one of its more modern versions https://eprint.iacr.org/2023/323 in our initial implementation.

Snak-Friendly Encryption

See SNARK-friendly Symmetric Encryption and SNARK-friendly Asymmetric Encryption