Choosing the right SNARK Backend

Building on our previous discussions from "[SNARKs 101](https://deeprnd.medium.com/snarks-101-40189a12eabc)", today we delve deeper into the backend systems of SNARKs, which play a pivotal role in the practical application of these technologies.

Conceptually, in the backend, the verifier challenges the prover. However, this interaction is cleverly abstracted away using cryptographic methods, resulting in a static proof where the verifier never directly interacts with the prover. Here, the prover claims to know a satisfying assignment to the circuit. This part of the SNARK system is what you typically encounter in literature, encompassing names like Groth16, Marlin, PlonK, and others, each referring to different backends of the probabilistic proof system.

In this piece, we'll examine various SNARK constructions and their appropriate setups, considering factors such as trusted setups versus transparent setups. As we continue our series, we will explore how choosing the right backend is not just a technical decision but a strategic one that can define the scalability and security of blockchain technologies and other applications relying on these powerful cryptographic tools.

Types of Setups

SNARKs operate under various setups, each with its own nuances and implications for security and transparency. Let's explore the three main types:

Trusted Setup Per Circuit

Here, each SNARK requires a unique setup, creating a situation where the setup's secrecy must be impeccably maintained. If the randomness used in this setup leaks, it could compromise the entire system. This model, although secure, poses challenges in scalability and trust.

An example of a project that utilized this setup is Zcash, a cryptocurrency leveraging zk-SNARK technology for secure transactions. Originally, Zcash implemented this type of setup in its "Sprout" transactions but later transitioned to a more universal setup in subsequent upgrades.

The advantages of this setup type are significant, particularly because it is tailor-made for each circuit. This customization allows for optimizations that enhance both performance and security for specific use cases. However,the primary concern is the security risk associated with the potential leakage of setup randomness, which could enable attackers to create false proofs.

Additionally, the need for a new setup for each circuit introduces considerable overhead, making this approach less practical for projects that require frequent updates (hm, hm this is any project).

Groth16 is a widely-used construction under this setup category. Groth16 is efficient, producing very short proofs and requiring minimal verification time, which makes it highly suitable for systems where performance and security are critical.

Trusted but Universal Setup

A slight improvement over the per-circuit approach, this setup is performed only once and can be used for multiple circuits. It reduces the burden of multiple setups but still carries the risk associated with a single point of failure in the initial setup phase.

An example of this approach in use is by Celo, which applies a SNARK setup to enable scalable operations in mobile blockchain environments. The one-time setup facilitates the efficient management of multiple proof verifications.

The primary advantage of this setup is its scalability. Once the initial setup is complete, adding additional circuits does not require new setups, thus simplifying and speeding up the process. It also significantly reduces both the cost and time, as it eliminates the need for multiple setups across various circuits. However, this setup is not without drawbacks. The initial setup still requires a significant degree of trust in those who conduct it, maintaining a central point of failure which could be a security risk. Additionally, because the setup is not customized for each specific circuit, it may not offer the same level of optimization as setups tailored to individual circuits. This could potentially affect the performance and efficiency of the SNARKs in certain applications.

Plonk is a notable construction that uses a universal trusted setup. Plonk offers the flexibility of applying the initial trusted setup across various circuits without the need for reconfiguration, simplifying the deployment of new SNARKs applications.

Transparent Setup

The gold standard in SNARK setups, a transparent setup requires no hidden randomness, making it immune to the pitfalls of the other two types. This renders it completely transparent and openly verifiable by anyone.

STARKWare is a prominent project in this space, utilizing STARKs—a technology akin to SNARKs but fundamentally based on transparent setups. Although STARKs are not SNARKs per se, the philosophy behind their setup significantly influences the SNARK community by demonstrating how transparency can be effectively implemented.

The major advantage of a transparent setup is the absence of trust requirements. Without the need for hidden randomness, there's no dependence on the integrity of the setup participants, thereby enhancing the overall security. These setups are viewed as more robust against both internal and external threats, largely because they eliminate the central point of failure that comes with secretive setup processes.

Exploring SNARK Constructions

In the world of SNARKs, several constructions stand out, each with unique strengths and trade-offs. Let's unpack some of the most prominent ones:

- Groth16: a system known for producing very small proofs—around 200 bytes, no matter how large the circuit is. It's fast too, with verification times of roughly 1.5 milliseconds. However, this impressive performance comes at the cost of requiring a trusted setup for each specific circuit, meaning a new ceremony is needed each time the circuit changes.

- Plonk from 2019 offers slightly larger proofs at 400 bytes and has a verification time of about 3 milliseconds. It main advantage is the universal trusted setup, meaning you do it once and can use it for many circuits.

- Bulletproofs take a different approach. The proof sizes grow with the circuit size, usually up to 1.5 kilobytes, and the verification takes longer, scaling with the circuit size. Despite this, Bulletproofs don't need any trusted setup, which is great for applications where avoiding any setup is key.

- STARK with proof sizes around 100 kilobytes and verification times that get longer as the circuit grows, but not as fast as Plonk or Groth16. Like Bulletproofs, STARKs don't require a trusted setup, making them secure against certain risks.

When you're choosing a SNARK, Groth16 is fast and small but not as flexible. Plonk and Marlin offer a middle ground, and Bulletproofs and STARKs provide security without the setup but at the cost of speed and size. The best choice depends on what's most important for your project: speed, size, or setup security.

Conclusion: The Future is Bright

In conclusion, as we navigate through the young and rapidly evolving field of SNARK constructions, it's crucial to make an informed choice that aligns with the specific needs of a project. Beyond comparing the differences in proof size, verification time, and setup requirements, it's vital to select a proven library—one that has not only been battle-tested in production environments but also vetted by independent audits. This ensures both reliability and security. Additionally, most SNARK constructions are implemented in C++ or Rust, which can limit options for projects developed in other programming languages, like Go. Thus, finding a compatible and secure solution may require careful consideration of the available cryptographic libraries and possibly adapting or interfacing with the existing codebase.

In the next article of our series, we'll take a closer look at how these technologies are being implemented in real-world scenarios, examining case studies and the challenges faced during deployment. Stay tuned for more exciting insights into the world of zero-knowledge proofs!

Comments

Popular posts from this blog

Rust Static Analysis and Blockchain Licensing

Length extension attack

CAP Theorem and blockchain