Conflict between new technologies
Throughout history, there have always been similar technologies coming to market around the same time that seek similar results but approach the problem in differing ways. When this market phenomenon occurs, adopters should attempt to evaluate each technology objectively.
Since both the STARK camp and SNARK camp are incredibly passionate about their respective technologies, we thought it would be interesting to do an objective comparison of these two technologies.
STARKs vs. SNARKs
Just a quick refresher, zero-knowledge proof technologies enables one party to prove to another party that they know something without the prover having to convey the information itself in order to prove their knowledge. They are both a privacy enhancing technology, as they reduce the amount of information that needs to be provided between users, and a scaling technology, since they can allow proofs to be verified at a faster rate because they don’t contain the full amount of information for non-private systems.
Two of the most compelling zero-knowledge technologies in the market today are zk-STARKs and zk-SNARKs. Both are acronyms for the method by which the two parties prove their knowledge: zk-STARK stands for zero-knowledge scalable transparent argument of knowledge, and zk-SNARK stands for zero-knowledge succinct non-interactive argument of knowledge.This post will delve into the core differences between these two different zero-knowledge technologies, both from a cultural and technical perspective. Furthermore, both of these zero-knowledge technologies are non-interactive by nature, meaning the code can be deployed and act autonomously.
Below, we have a couple tables depicting some of the high-level differences between the two technologies. We will also delve into the differences in paragraph format.
SNARKs
In January 2012, a professor at UC Berkeley named Alessandro Chiesa co-authored a paper that coined the term zk-SNARK for the zero-knowledge proofs they constructed for the first time. Zk-SNARKs at their base depend upon elliptic curves for their security. Elliptic curves in cryptography operate under the base assumption that finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point is infeasible.
While there has been significant debate on whether there is a backdoor into elliptic curve random number generators, the algorithm as a whole generally remains secure. Although there are several popular vulnerabilities in side-channel attacks, they are easily mitigated through several techniques. Quantum attacks do loom over cryptography based on elliptic curves, but the quantum computing required to break their security model is yet to be widely available.
In addition to being based on elliptic curves, zk-SNARKs also require a trusted set up. A trusted setup refers to the initial creation event of the keys that are used to create the proofs required for private transactions and the verification of those proofs. Initially, when those keys are created, there is a hidden parameter linked between the verification key and the keys sending private transactions. If the secrets used to create these keys in the trusted set up event are not destroyed, the secrets could be utilized to forge transactions by false verifications, giving the holder the ability to perform actions such as creating new tokens out of thin air and using them for transactions. Because of the privacy features of zk-SNARKs, there would be no way to verify the tokens created out of thin air were actually created out of thin air. That being said, the trusted set up is only needed initially
Consequently, users of the SNARK based network must rely on the fact that the trusted set up was performed correctly, meaning that the secrets associated with the trusted set up key were destroyed and are not being held by the individuals who oversaw the ceremony. The reliance on a trusted set-up has been one of the largest areas of concern for critics of SNARKs. That being said, developers only need to utilize the trusted set up initially, not continuously.
Another significant area of criticism for SNARKs is that they are not quantum resistant. Once quantum computing is largely available, the privacy technology behind SNARKs would be broken. Of course, supporters of SNARKs correctly point to the fact that we will have far more problems on our hands, such as the breaking of RSA and most wallet infrastructure, when quantum computers are utilized.
That being said, there are many reasons why SNARKs have actually been adopted at a far faster rate than STARKs, despite having the issues associated with the trusted set-up. SNARKs were discovered years ahead of STARKs, which gave the technology a significant head start in terms of adoption. Zcash, one of the older digital asset projects, popularized the usage of SNARKs within the blockchain development community. Because of Zcash and other adopters of SNARKs, SNARKs has the most developer libraries, published code, projects, and developers actively working on the technology. In addition to Zcash, emergent DEX Loopring also utilizes SNARKs. If a developer wanted to begin utilizing zero-knowledge technologies, they would have far more support in utilizing SNARKs than STARKs.
Additionally, SNARKs are estimated to require only 24% of that gas that STARKs would require, meaning that transacting with SNARKs would be far cheaper for the end-user. Finally, the proof size for SNARKs is much smaller than STARKs, meaning it would take less on-chain storage.
STARKs
While SNARKs has some distinct advantages over STARKs in regards to documentation and developer support, STARKs does offer some unique benefits. But first, let’s dive into a little about what STARKs are from the technical perspective.
Eli Ben-Sasson, Iddo Bentov, Yinon Horeshy and Michael Riabzev wrote the first papers describing STARKs in 2018. Unlike SNARKs, the base technology for STARKs relies on hash functions. Right off the bat, relying on hash functions offers some benefits, such as being quantum resistant. Furthermore, no trusted set-up is required to begin utilizing STARKs in a network.
That being said, STARKs have far larger proof sizes than SNARKs, which means that verifying STARKs takes more time than SNARKs and also leads to STARKs requiring more gas.
Additionally, developers will have a much harder time utilizing STARKs because of the lacking developer documentation and community. While there are some projects creating STARK based scaling solutions, such as STARKWARE, the SNARKs community is still far larger.
While both developer communities support both SNARKs and STARKs, the Ethereum Foundation in particular displays vocal support for STARKware, which utilizes Starks. In fact, the Ethereum Foundation gave STARKware a $12 million grant, clearly exemplifying their devotion to the emergent technology.
Furthermore, while the documentation for STARKs pales in comparison to SNARKs, the technical community recently developed a greater set of resources for those looking to implement the cutting edge technology.
Thanks to Anish Mohammad for the insight and expertise.
