Privacy has always been considered a very valuable feature by the cryptocurrency community. It is a precursor to fungibility, which is necessary for a widely used form of money. Most crypto asset owners do not want their holdings and transaction histories to be completely public. Among the various cryptographic methods aimed at ensuring the confidentiality of blockchains, two examples of evidence worthy of attention are zk-SNARK and zk-STARK.
zk-SNARK stands for short, non-interactive, zero-knowledge argument of knowledge, and zk-STARK stands for short, transparent, zero-knowledge argument for knowledge. Zk-SNARK proofs are already used in Zcash, JP Morgan Chase's blockchain-based payment system, and as a way to securely authenticate clients to servers. But while zk-SNARK has made significant strides in its establishment and adaptation, zk-STARK is now touted as a new and improved version of the protocol that addresses many of zk-SNARK's previous shortcomings.
The Parable of Ali Baba and the Cave
In 1990, cryptographer Jean-Jacques Quisquater (along with other collaborators) published a paper entitled “How to Explain Zero Knowledge Protocols to Your Children.” The article presents the concept of ZK evidence with the parable of Ali Baba's cave. Since its publication, it has been revised several times, and several versions currently exist. However, the basic information is essentially the same.
Let's imagine a circular cave with one entrance and a magical doorway separating two side paths. To get through the magical doorway, you need to whisper the right secret words. So, consider that Alice (yellow) wants to prove to Bob (blue) that she knows the secret words, and at the same time wants to keep them secret. To do this, Bob agrees to wait outside while she enters the cave and goes to the end of one of two possible paths. In this example, she decides to take path 1.
After a while, Bob walks past the entrance and shouts which way he wants Alice to appear (path 2 in this case).
If Alice really knows the secret, she will definitely end up on Bob's chosen path.
The entire process can be repeated several times to confirm that Alice did not accidentally choose the right path.
The parable of Ali Baba and the Cave illustrates the concept of zero-knowledge proofs, which are part of the zk-SNARK and zk-STARK protocols. ZK proofs can be used to prove possession of certain knowledge without revealing any information about it.
zk-SNARKs
Zcash is the first widely available zk-SNARKs application. While other privacy projects like Monero use ring signatures and other techniques, effectively creating a smokescreen around who sent something, zk-SNARKS fundamentally changes the way data is exchanged. Zcash's privacy is based on the fact that transactions on the network can remain encrypted but still be verified using zero-knowledge proofs. Thus, those applying the consensus rules do not need to have all the data underlying each transaction. It is worth noting that the privacy feature in Zcash is not enabled by default, but is subject to manual configuration and is optional.
Zero-knowledge proofs allow one person to prove to another that a statement is true without revealing any information beyond the validity of the statement. The parties involved are usually referred to as a verifier and verifier, and the statement they are keeping secret is called a witness. The main purpose of these evidences is to reveal as little information as possible between the two parties. In other words, one can use zero-knowledge evidence to prove that they have certain knowledge without revealing any other information.
The acronym SNARK “compressed” means that this evidence is smaller in size and can be quickly verified. “Non-interactive” means that there is little to no interaction between prover and verifier. Older versions of zero-knowledge protocols typically require the verifier and verifier to communicate with each other and are therefore considered "interactive" zk-proofs. But in “non-interactive” designs, the verifier and verifier must exchange only one piece of evidence.
Currently, zk-SNARK proofs depend on an initial trust setting between the verifier and the verifier, meaning that a set of public parameters is required to create zero-knowledge proofs for private transactions. These parameters almost correspond to the rules of the game, they are encoded in the protocol and are one of the necessary factors confirming that the transaction was valid. However, this creates a potential problem in centralization since the parameters are often formulated by a very small group.
While the initial public setup is fundamental to modern zk-SNARK implementations, researchers are working to find other alternatives as a way to reduce the level of trust required in this process. The initial setup phase is important to prevent counterfeit spending because if someone had access to the randomness that generates the parameters, they could create false evidence that would appear valid to the verifier. In Zcash, the initial setup phase is known as the Parameter Generation Ceremony.
Let's move on to “ARuments” as a fragment of an acronym. zk-SNARKs are considered computationally sound, meaning that rogue verifiers have a very low chance of successfully fooling the system. This property is known as strength and assumes that the verifier has limited processing power. In theory, a verifier with enough computing power could create fake evidence, which is one of the reasons why quantum computers are seen by many as a threat to zk-SNARK and blockchain systems.
The last part of this acronym is “Knowledge,” meaning that the examiner cannot construct evidence without having knowledge (or a witness) to back up their claim.
Zero-knowledge proofs are quickly verified and typically take up much less data than a standard Bitcoin transaction. This paves the way for zk-SNARK technology to be used as a privacy and scalability solution.
zk-STARKs
zk-STARK was created as an alternative version of zk-SNARK and is considered a faster and cheaper implementation of the technology. But more importantly, zk-STARK does not require an initial trust setting (hence "T" transparent).
Technically speaking, Zk-STARK does not require initial trusted setup as it relies on simpler symmetric cryptography thanks to its collision-resistant hash functions. This approach also removes the number-theoretic assumptions of zk-SNARK, which are computationally expensive and theoretically susceptible to attacks by quantum computers.
One of the main reasons why Zk-STARK offers cheaper and faster implementation is that the number of communication cycles between verifiers and verifiers remains constant relative to any increase in computation. In contrast, in zk-SNARKs, the more computation required, the more parties have to send messages back and forth. Therefore, the total data size in zk-SNARK is much larger than in zk-STARK.
It is clear that both zk-SNARKS and zk-STARKs are appealing to growing concerns about privacy. In the world of cryptocurrencies, these protocols have great potential and can become the innovation needed for mass adoption.
