Photo: Moralis, all right reserved.
The infamous blockchain scalability issue might be permanently solved by zero-knowledge proofs (ZKPs), which are described in great length in my recent publication. They can offload the main layer-1 network and increase transaction throughput. Using ZKP encryption, some businesses are already developing scalability solutions. You may be familiar with zkSync, Loopring, or Starknet; their teams recently revealed their milestones, sparking a heated discussion regarding scalability.
Photo: David Becker, all right reserved.
Zero-knowledge rollups (ZK-rollups) bundle many layer-2 transactions that were executed off-chain and submit them as one transaction onto Ethereum, while generating a cryptographic proof. Unlike Optimistic rollups which assume transactions are valid until proven otherwise, ZK-rollups use those validity proofs to instantly prove if transactions are valid or not. The status of all transfers on layer-2 is maintained by the ZK-rollup smart contract, and this state can only be altered with a validity proof. This implies that instead of entire transaction data, ZK-rollups merely require the validity evidence. Because less data is supplied in a ZK-rollup, verifying a block is faster and less expensive. With a ZK-rollup, there are no delays when moving funds from layer-2 to layer-1 because a validity proof accepted by the ZK-rollup contract has already verified the funds.
The cryptographic proof submitted on layer-1 can be in the form of SNARK (Succinct Non-interactive Argument of Knowledge) or STARK (Scalable Transparent Argument of Knowledge). ZK-SNARKs are so-called because they possess the following qualities:
- Succinct: the proof can be easily confirmed and is far smaller than the data it represents.
- Non-interactive: there is no back-and-forth communication between the prover and verifier because only one set of data is sent between them.
- Argument: A SNARK is a “computationally sound” statement that satisfies rigorous requirements, making it difficult to cheat (i.e., generate false proofs).
- Knowledge: SNARK-based proofs cannot be created with access to the underlying information.
The T* *present in the STARK name stands for transparent. It replaces the non-interactive property.
STARKs, unlike SNARKs, do not require trusted setup.
The meaning of S* *is changed from succinct to scalable, signifying that STARKs can be even more scalable than SNARKs.
Photo: Altoros, all right reserved.
Photo: Cytonn Photography, all right reserved.
ZK-SNARKs uses Elliptic curve cryptography (ECC) which is a kind of encryption technology that generates secure cryptographic keys using elliptic curve properties.
Photo: Avinetworks, all right reserved.
The initial generation event that creates the credentials needed for private transactions and the keys required to verify those credentials is called trusted setup. When such a key is initially created, a secret parameter is assigned between the verification key and the key that carries the private transaction.
Suppose the secrets used to construct these keys during the trusted setup event are not compromised. In that case, they might be used to manufacture trades via fake verifications, allowing the holder to do things like produce new tokens out of thin air and use them in transactions. But, of course, there would be no method of verifying that the tokens made out of thin air were indeed brought into existence due to the privacy characteristics of ZK-SNARKs. Having said that, developers should only use the trusted setup once at the beginning. As a result, users of SNARK-based networks must trust that the trusted setup has been performed correctly, which means that the secret associated with the trusted setup key has been destroyed and is no longer in the possession of the people who attended the ceremony. The reliance on settings has been one of the main reasons for disagreement among SNARK critics.
Photo: fcats-blockchain-incubator, all right reserved.
Throughput is increased via ZK-SNARKs by reducing processing on Ethereum’s base layer. The transaction data that a ZK-SNARK verifies is typically greater than the actual SNARK proof. Consequently, the underlying blockchain is less congested, then, faster transactions and lower gas costs are made possible.
SNARK proofs are simple to verify on the main chain due to their moderate size. On Ethereum, this translates to decreased gas costs for off-chain transaction verification, lowering rollup costs for users.
The cutting-edge cryptographic security procedures employed in ZK-SNARKs are the primary reason why ZK rollups are regarded as being more secure than other scaling projects. Computationally sound, ZK-SNARK evidence makes it challenging to mislead verifiers and engage in malevolent behaviour.
To set up the ZK-SNARK protocol, public parameters must be created, they enable private communication between provers and verifiers. A malicious actor may produce erroneous validity proofs if they were aware of the public parameters. Some projects attempt to solve this problem by using multi-party computation (MPC), which involves different individuals, to generate the public parameters. Nevertheless, this strategy necessitates that users have faith in all parties’ honesty. Given that blockchains are meant to remove the need for authority trust, this is a big challenge.
At its core, ZK-SNARKs rely on elliptic curves for security to provide validity proofs. However, elliptic curves are utilized in cryptography upon the presumption that it is impossible to calculate the discrete logarithm of a random elliptic curve element with regard to a publicly known base point. Although Elliptic Curve Cryptography (ECC) is very secure, advances in quantum computing could undermine its security architecture.
Unlike SNARKs, STARKs’ core mechanism is based on hash functions. Using hash functions provides various advantages right away, such as being quantum resistant, or being less vulnerable to attack. Furthermore, there is no need for a trustworthy setup to start using STARKs in a network.
STARKs are safer thanks to this nuance, which takes away the danger of initial collaboration. Since researchers believe quantum computers could pose a threat to SNARK security in the future, it might become significant. Although STARKs are produced more rapidly, they require a lot more space and require more time to check. Yet, for large transaction batches, the amortized computation cost is still lower. Therefore, they allow us to scale more effectively.
Photo: *Ethworks; image courtesy of Alex Gluchowski, *all right reserved.
ZK-STARKs rely on open randomness and do not need a trusted setup to work. As a result, trust assumptions on the part of users are reduced, and STARK-based protocol security is increased.
When compared to SNARKs, STARKs can be computed and verified faster. However, even as the complexity of the underlying computation increases exponentially, ZK-STARKs maintain low proving and verifying times.
By providing secure and verifiable off-chain computation, STARKs, like SNARKs, can scale blockchains.
Instead of the elliptic curve encryption techniques used in ZK-SNARKs, collision-resistant hashes are employed in ZK-STARKs. This is thought to be more secure than the elliptic curves used in SNARKs since it is immune to quantum computing assaults.
While STARKs offer speedier proofs than SNARK-based proofs, the disadvantage is that these proofs are bulkier. Therefore, verifying STARK proofs on Ethereum is longer and more expensive due to the greater gas costs associated with computing larger proofs.
Since SNARKs were the first use of zero-knowledge technology in blockchains, they have a larger market share than STARKs. The developer environment and tooling for SNARK-based ZK proofs are larger, and ZK-SNARKs are used in the majority of ZK rollups. On the other hand, ZK-STARKs have less acceptance even though they have well-known backers like the Ethereum Foundation. Thus, developers may encounter less assistance and tooling while creating ZK projects using STARKs.
Photo: Hackernoon, all right reserved.
⁃ Know The Difference Between ZK-SNARKs vs ZK-STARKs* -**** ***March 23, 2022 - by smita.verma - (https://www.blockchain-council.org/blockchain/ZK-SNARKs-vs-ZK-STARKs/)
⁃ ***SNARKs vs STARKs - Understanding the Difference - ***November 20, 2021 - by Gaurav (Coincodecap) - (https://coincodecap.com/snarks-vs-starks-difference)
⁃ ***STARKs vs SNARKs vs Recursive SNARKs - ***May 27, 2022 - by Alchemy - (https://www.alchemy.com/overviews/snarks-vs-starks)
⁃ ***What Are ZK-SNARKs? - ***Zcash - (https://z.cash/technology/zksnarks/)
⁃ Zero-knowledge Proof: STARKs vs SNARKs?* -**** ***May 18, 2021 - by Mattison Asher, Coogan Brennan - (https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)
⁃ ***What is ZK-STARK? - ***by Starkware - (https://starkware.co/stark/)