In this post, we discuss our new zero-knowledge proving system, Marlin, by Chiesa, Hu, Maller, Mishra, Vesely, and Ward. This year has been the year of the universal SNARK, with Sonic, Libra, and Plonk all bidding for attention. Marlin is yet another competitor, one which we recommend using when you require fast verification time without the use of batching.
Why Universal SNARKs?
A universal SNARK is a proving system in which a single trusted setup suffices to prove anything that we know how to prove. That means that the same setup could be used across all applications and that parameters could be stored in a general-purpose library. Additionally, these universal SNARKs typically have relatively easy to coordinate setup procedures, which makes it easier to convince users that the procedure has been carried out correctly and securely.
Some SNARKs avoid setup procedures altogether. Such works include Spartan, Halo, and Hyrax. However, the cost of avoiding a trusted setup can generally be seen in the proof sizes and verification time.
Marlin or Sonic?
In this authors’ humble opinion, Sonic is fabulous. The proofs are small, the provers are fast, and the verification is fast provided one is verifying many proofs at the same time. For applications that use batched verifications, Sonic currently remains the state-of-the-art. Cryptocurrency transactions are a classic example of this – nodes can verify all the transactions in a new block simultaneously (provided the miner aggregates the transactions). However, this setting in which Sonic excels, i.e. the setting in which the verifier is not just given a single proof but many, many proofs of the same thing, is not always a given. For an example where Sonic’s batched proofs would not suffice, consider a randomness beacon. Here verification of the beacons outputs is only done once in a while. Therefore it would be a setting where batching is totally inappropriate.
Settings in which batching is not possible is where Marlin comes into its own. In such a setting, our proving times are an entire order of magnitude better than Sonic. Also, our verifier requires fewer pairings (only two) and fewer exponentiations. Thus we take universal proving systems with constant sized proofs from being theoretically possible to being practical and useful.
Compared to Libra, Marlin has smaller proof sizes and faster verification time, but we do require large Fast Fourier Transforms whereas Libra does not. This means we have less flexibility in the curves that we implement Marlin over (there needs to be a large power of 2 dividing the order of the field) and our prover time also suffers a logarithmic overhead.
Compared to Plonk, our prover work and proof length (about 1 kbyte) are similar, and therefore we believe both systems are respectable choices for similar applications. Some differences are as follows:
- We have provided an implementation for Marlin. Currently, Plonk has not been implemented.
- Marlin uses an R1CS constraint system, whereas Plonk(er) requires a special purpose constraint system.
- Plonk introduces an elegant permutation argument that could be used in more specific applications such as mixnets.
A Note to Cryptographers
Check out our algebraic holographic proving system (AHP). It separates the underlying algebra in the proving system from any heavy cryptographic tools like polynomial commitment schemes, making the exposition simpler and mistakes easier to spot.
Could Marlin be Implemented using Quantum Secure Tools?
It is an exciting research direction to try to use transparent-setup PCs in a similar compilation. We provide a method of transforming any polynomial commitment scheme to an AHP. Our compiler would output a SNARK given a proof that a scheme such as that by Vlasov and Panarin fits into our definitions. This additionally makes it easy to build Marlin using primitives which do not require a trusted setup.