# Privacy Chains and ZKPS

Recently, privacy cryptocurrencies and blockchains have gained a lot of spotlight due to the U.S. Treasury's Tornado Cash sanction. This has opened up many discussions on what lies ahead for the roles of privacy within blockchain technology.

For some basic background information, Tornado Cash is related to privacy as its role as a currency mixer operating on the Ethereum blockchain, by anonymizing transactions through hiding their origin, destination, and counterparties. However, this privacy also provides leeway to conduct money laundering operations as crypto wallets couldn’t be traced to their origins.

The government regulation on this technology has raised questions on whether there will be further state-controlled sanctions on privacy in blockchains, and if the fundamental values of borderless, permissionless, uncensorable payment systems will remain intact.

While this regulation was on mixers, it’s important to note that privacy is not being implemented in just cryptocurrency designs but also in Layer 1 and Layer 2 protocols. In this article, we will explore why privacy is being valued, how they are being implemented in each types of protocols, and what some of the trade-offs are.

## Why privacy is valued

Let’s first think about why privacy is being valued in blockchains. The entire foundation of Web3 is based on decentralization, transparency, and open-source codes. In a blockchain, every transaction is made public so that anyone can verify whether a transaction is valid or not, which enables trust even in a trustless environment.

However, if you shift your perspective, this also means that your entire wallet transaction history and current balance is open to the public. While in the case of a centralized setting, banks and yourself are the only entities that have access to this confidential data, in crypto, at the expense of decentralization, this sort of transparency has led to targeted attacks of exploitation, otherwise known as MEVs and front running attacks.

Because everything is made open to the public, a bot could scan all of the unconfirmed transactions and create an opportunity to gain profit before a large trade occurs on the decentralized exchange. These bots would do so by offering a higher gas price than other transactions, incentivizing miners to execute their transactions first before other transactions.

Not limited to bots, miners can also perform these front running attacks by manually switching the order of transactions to their preference after knowing that some of the pending transactions include a large number of assets being traded. They have the flexibility to reorder, include, or even exclude transactions to gain profit, which harms other honest traders within the network. This is otherwise known as MEV (Miner Extractable Value).

These issues have become more serious, up to the extent where more than [$675M value](https://explore.flashbots.net/) was extracted by MEVs since 2020. With this in mind, privacy has been explored in Layer 1 and Layer 2 chains as a solution to withstand these front running attacks by hiding the details of the transactions.

## Why privacy is valued (Proposal)

*While in the case of a centralized setting, banks and yourself are the only entities that have access to confidential datas, the entire foundation of Web3 relies on decentralization, transparency, and open-source codes. In a blockchain, every transaction is made public so that anyone can verify whether a transaction is valid or not, which enables trust even in a trustless environment.*

*This sort of transparency has led to targeted attacks of exploitation, otherwise known as MEVs and front running attacks.*

*Because everything is made open to the public, a bot could scan all of the unconfirmed transactions and create an opportunity to gain profit before a large trade occurs on a decentralized exchange. These bots would do so by offering a higher gas price than other transactions, incentivizing miners to execute their transactions first before other transactions.*

*Not limited to bots, miners can also perform these front-running attacks. They have the flexibility to reorder, include, or even exclude transactions to gain profit, which harms other honest traders within the network. This is otherwise known as MEV (Miner Extractable Value).*

*These issues have become more pressing, up to the extent where more than $675M value was extracted by MEVs between 2020 and 2022. With this in mind, privacy has been explored in Layer 1 and Layer 2 chains as a solution to withstand these front running attacks by hiding the details of the transactions.*

## How is privacy being implemented?
They use forms of zero knowledge proofs, which can be divided into two categories at the moment: zk-SNARKs and zk-STARKs. Both are non-interactive zero knowledge proofs that enable much faster verification for networks as they are smaller in size compared to full-size transactions on Bitcoin or Ethereum. Due to this property, zk-SNARKs and zk-STARKs are widely used as solutions for scalability, as in the case of Mina, zkSync, and Starknet.

Meanwhile, using these proofs solely for the privacy of the chain is yet to be further explored as there are only a few chains that do so. In this article, we will be looking into how these proofs are being used to guarantee *privacy*. How these proofs are used for *scaling* are dealt with in other quests under the campaign, Scalability.

The main difference between zk-SNARKs and zk-STARKs is that in a zk-SNARK, you need a trusted setup with a set of public parameters beforehand, while in a zk-STARK, there is no need for a setup as they use publicly available randomness to generate those parameters. As such, for zk-SNARKs, the security of the proof relies on who gets access to the public parameters and depending on the assumption that at least one honest participant utilizes the system. While trusted setups increase security, there still exists a downfall that if malicious entities are able to gain access, they would be able to create false proofs to their benefit.

On the other hand, zk-STARKs has improved upon zk-SNARKs’ scalability and transparency and eliminate the dependency on trusted setups. Zk-STARKs are transparent in the sense that they use public random parameters that are based on collision-resistant cryptography. This means that there is less dependency on trusted setups and groups, further increasing security as there is a less probability of a malicious group gaining access to the parameters.

Overall, zk-STARKs have been more recently introduced in the field of zero knowledge proofs and are thus more advanced than zk-SNARKs. While zk-SNARKs are based on elliptic curve cryptography, zk-STARKs use collision-resistant cryptography, meaning that zk-SNARKs are susceptible to quantum computing attacks. Furthermore, proving and verification times for zk-STARKs increases quasilinearly while for zk-SNARKs they scale linearly. Thus zk-STARKs are faster when it comes to generating proofs. Yet one of the downsides to zk-STARKs is that they produce larger proof sizes, making it more expensive to verify on chains like Ethereum.

So what are some of the applications for each zk-SNARKs and zk-STARKs in Layer 1 and Layer 2 protocols?

## Privacy in Layer 1 protocols

The first naive way of solving the forementioned front running attacks is to make everything private. The advantages of this are that the attacks would be prevented as bots or miners wouldn’t be able to scan any of the transaction information. However, the major drawback of this decision would be composability, as the chain would not be able to interact with other smart contracts and access on-chain transparent information. With everything private, sidechains, rollups, and multi-chains are out of the picture, as retrieving data for validating proofs would become extremely difficult, and inevitably be detrimental to scalability as well.

As an alternative approach, Layer 1 chains are mainly adapting the mechanism called **privacy by default.** Privacy by default gives power to the users by enabling them to choose which information to reveal to the public. This guarantees decentralization without having to make all the transactions transparent by incentivizing users to disclose information only when necessary.

How does zero knowledge proofs come into this picture? Essentially, zero knowledge proofs are what enables such anonymity for transaction amounts and wallet addresses. In other words, zero knowledge proofs allow parties to verify each other’s information without exposing any of it.

For example, in the case of Aleo, they use ZEXE (Zero Knowledge EXEcution) with zk-SNARKs as the basis, in which the users’ transactions contain a proof of the state transitions that does not hold any information of the inputs that generated it. Thus, the proof does not show who was involved in the transaction, which assets were traded, and what the action was. In this case, even if all counterparties and an user’s transaction history, addresses, and accounts are made anonymous, an user could still verify to the network that he/she has enough assets to trade.

Another example of a Layer 1 blockchain that uses zk-SNARKs for privacy is Anoma, which allows users to safe-guard their financial information as they can process transactions without exposing any of the inputs needed to reconstruct the proofs. In addition to zk-SNARKs, Anoma has developed Ferveo for further privacy, which is a threshold decryption mechanism that can be used to prevent front-running attacks as all transactions become ordered and encrypted.

Such blockchains that have a privacy by default structure are more resistant to MEVs or front-running attacks as malicious groups have no way to figure out the information of a transaction unless an user chooses to reveal them. However, some concerns towards this approach that exist are composability and compatibility, as in a multi-chain setting, privacy chains will have to be compatible with various existing protocols if they want more user flow and capital influx so that they can stand as their own Layer 1 chain.

## Privacy in Layer 2 protocols

Besides the the utilization of zero knowledge proofs in privacy chains, zk-SNARKs and zk-STARKs are both widely used in Layer 2 solutions, especially in rollups. Particularly, in zk-rollups, validity proofs are used to verify that the state transitions proposed by the rollup are indeed the results of executing the batch of the transactions. These validity proofs prove the result of the changes without broadcasting any of the information that generated those changes, which is why validity proofs are in this sense also called zero-knowledge proofs.

Zero knowledge proofs are used in rollups with the main objective being scalability as it is much faster to validate a succinct validity proof without having to re-execute all of the transaction batches. On top of this, privacy comes in as another factor that guarantees the security of the network. One of the examples is Aztec, a privacy by default zk-rollup that uses zk-SNARK technology to enable end-to-end ecrypted transactions. Both the identities of the prover and the verifier, as well as the values of the transferred assets are hidden to the public.

Another example is zkSync, a scaling and privacy rollup for Ethereum that uses zk-SNARKs. While zkSync’s transactions are transparent at the moment, they are planning to make their transactions private in the future once their technology is advanced enough to scale efficiently without much cost and overhead.

Up to now we've only been looking at chains using zk-SNARKs. What about zk-STARKs? At the moment the only rollup that uses zk-STARK is StarkWare, in which the inputs that the off-chain prover uses are not exposed on the blockchain, ultimately protecting the user's privacy.

Currently, zk-rollups are more focused towards solving issues of scalability rather than for privacy, which is why there has not been a lot of development towards fully private zk-rollups. At the core, the transactions can be seen as "private," as validity proofs do not necessarily contain any specific information of the state transitions. However, whether the rollup itself is fully private or not is a different matter.

## Conclusion
Privacy chains are still at its early stage and need much more time and development in order to become fully scalable and accessbile across multiple chains. One of the interesting developments for privacy chains would be interchain private transfers as it would create an ecosystem that guarantees full privacy to its users while also being resistant to front running attacks, which are some of the main issues that other transparent chains are dealing with. Yet with the constant regulation and pushback on privacy solutions for users, it will be interesting to see how privacy will further be developed.