Addressing Privacy through Zero-Knowledge Proofs
This report examines the relevance and application of privacy-preserving zero-knowledge proofs (ZKPs) in the context of smart contract networks, while highlighting the various limitations, tradeoffs, recent discoveries and continued research fields surrounding these proof systems. A ZKP allows an entity to prove any arbitrary statement about a set of data, without revealing any underlying information other than the proof itself and can offer privacy without sacrificing the auditability that is inherent to public smart contract networks. While ZKPs and privacy are often associated with monetary networks such as Monero and Zcash, there has been less attention paid to their usefulness for Web3 applications and enterprise adoption of public blockchain networks.
- Unlike most other privacy technologies, ZKPs offer privacy to public smart contract networks in a manner that does not sacrifice auditability.
- There are three main categories of ZKPs, namely: ZK-SNARKs, Bulletproofs, and ZK-STARKs with the majority of implementations so far having used SNARKs.
- ZKPs may increase the likelihood of enterprises using public crypto networks while also encouraging the growth and adoption of Web3 applications.
- ZKPs can broadly be measured according to performance, functionality, transparency, and security while there are typically tradeoffs between these properties.
Integrating robust privacy-enabling technologies is one of the hardest existing problems for permissionless crypto networks. Open blockchains provide a transparent and auditable transaction record in a way that is impossible on centralized alternatives. Indeed, this has been perhaps the greatest value proposition for such networks. At the same time, these properties are antithetical to user privacy, because any network observer can see the details of every transaction, while blockchain applications are of little use to enterprises or the public if at any stage they expose sensitive data. This tension remains fundamental to the growth and adoption of decentralized networks.
Although privacy is likely a prerequisite to the widespread adoption of blockchain technology, there are multiple routes for its effective implementation, each with a distinct set of benefits and tradeoffs. This report analyzes the rapidly growing class of privacy-enabling technologies, with a specific focus on ZKPs while examining the nuances of their implementation.
While the ZKP protocols that are discussed apply to all types of crypto networks, the report will be looking specifically at their integration in smart contract networks and the implications for the applications that make use of them. There has been a considerable amount of research on the application of ZKPs to monetary networks such as Monero and Zcash. Applying these protocols to smart contract networks and decentralized applications (dApps) however is arguably both more consequential and complex. Given that such networks enable Web3 applications and possibly, enterprise adoption, embedding robust privacy guarantees is extremely important as both Web2 applications and current enterprise technology stacks already offer strong privacy, due to their siloed architectures. At the same time, these networks, by enabling more expressive applications than distributed monetary networks, also involve more complex operations, namely the involvement of more on and off-chain data, smart contract logic and state changes. These differences make comparisons between implementations on purely monetary networks versus those on more expressive smart contract networks less insightful, especially in terms of parameters and performance metrics.
The Evolution towards Zero-Knowledge Proofs
At a fundamental level, privacy technologies used in the context of crypto networks, through cryptography, seek to obscure some set of information or data from all parties who do not require direct access to said data, as deemed by its owner. In its simplest form, this may involve encryption, the use of private and possibly permissioned chains whereby read access to certain data is limited, or the use of secure multi-party computation. However, these techniques have little use in the context of public networks where nodes have to verify the data.
Consider, for instance, the example of a credit scoring protocol that runs on top of a public crypto network. In this scenario, an individual known as Alice is attempting to secure a credit score via a protocol with which she can then use to secure loans and access other financial products. Simply encrypting or otherwise concealing Alice’s underlying financial data is not a viable option, since the nodes would be unable to verify the integrity of Alice’s data, while revealing it on-chain is equally unsuitable since it reveals Alice’s data indiscriminately. In the current environment, centralized credit reporting bodies such as TransUnion, Equifax and Experian issue credit scores to people like Alice. In the process, however, these companies collect vast swathes of consumer credit data from lending providers and banks, and store this information on centralized databases, in turn posing a major security and privacy risk. Through the use of ZKPs, however, it is possible to bypass these centralized providers entirely while preserving privacy and allowing a network’s nodes to publicly verify the integrity of the underlying data. Alice, with the help of a ZKP-based credit scoring protocol, would be able to generate an on-chain credit score built from proofs that are generated from her underlying credit history and financial data without revealing any of the underlying data.
One alternative privacy technique that does have some relevance in public networks involves storing hashes on-chain, although, as we will see, this is also inapplicable to our credit scoring example. Hashing is, however, particularly useful for notarization, where an entity wishes to ensure a digital file or document is not tampered with, either on a one-time basis or at certain intervals while storing the file off-chain where it remains private. In this case, the file is passed through a one-way hash function, such as SHA256, and the resulting output (digest) is stored on-chain. For one time and infrequent usage, hashes are far more efficient than more complex mechanisms such as ZKPs, with a SHA256 digest measuring just 32 bytes relative to the smallest ZKP at 130 bytes. Beyond this, hashing techniques can be used as part of commitment (commit-reveal) schemes to attest to the integrity of some information at a particular point in time, where the information is hashed and the resulting digest is stored on a public blockchain.1
In this scenario, one or both parties hash their information, publishing the digest on-chain. Then, when they are ready, both participants reveal the information to each other (not publishing this on-chain), while the original digest proves that the information they have just revealed is that of the original. Commitment schemes can also be used to attest to the validity of some off-chain state, where the state is hashed and the digest serves as proof of the state’s integrity as of the provided timestamp.
As much as they have their place in certain scenarios though, hashing techniques, including commitment schemes, cannot fully preserve privacy in the credit scoring example discussed earlier, nor in many other more sophisticated scenarios. If Alice used a hashing technique to prove anything about her underlying financial data other than that she has not tampered with it during a certain time period, she would have to reveal the underlying credit history, negating any privacy that she ever had.
Ultimately then, despite its utility in certain instances, hashing is unsuitable for a broader range of privacy-preserving applications. Specifically, all a hash proves is that some set of digital information was unchanged since the digest’s timestamp. Hashing does not allow a party to make any claims in a verifiable and private manner about this data. Furthermore, it still requires parties to exchange the data in another venue. Awareness of this limitation helps explain the impetus to develop more complex solutions, with a leading example being the emergence of ZKP technology.
Unlike simple hashing, ZKPs theoretically allow a party to prove various things about a set of data, making a range of different statements while keeping the data itself fully private and allowing for any node to verify said claim. This is in contrast with hashing-based commitment schemes, where actually proving anything about the data requires revealing the underlying data to the interested party, an outcome that is not always ideal. Examples of zero-knowledge proofs can include proving that a group of citizens on a registrar are all above a certain age, or that a financial firm has the solvency to make a set of defined payments over the next six months without revealing any balance sheet information. ZKP-based statements are applicable to a broad range of Web3 applications. dApps often require access to user data to execute business logic. In order to read this data however, it must be accessible on-chain in some form. Publishing sensitive user data on public networks is clearly not an option, however, with ZKPs it is possible for statements about private computation to be published on-chain that are sufficient to trigger a smart contract’s logic.
Specifically, ZKPs allow for one party, known as the prover, to prove to another party, known as the verifier, that it knows the value of something without disclosing any information beyond the proof itself. To classify as a ZKP, a protocol must have the following three properties:
- Completeness: The verifier affirms that the statement (made by the prover) is correct.
- Soundness: A dishonest prover cannot mislead a prover about a statement, within the context of some defined probability.
- Zero-Knowledge: Assuming the statement is true, the verifier learns nothing else about the statement other than its truth, lending the protocol its privacy-preserving feature.
To illustrate, consider a scenario where an individual (the prover) wants to buy health insurance from an insurance provider (the verifier). Rather than revealing any underlying data, such as their specific age or exact medical history, the individual could provide a series of statements (proofs) to the provider based on their digital health records. These records would be stored by the individual on their device, preserving the privacy of the underlying data while they could simultaneously prove that they fall within certain health parameters, such as being a male between the ages of 35-45 with no preexisting conditions. The proofs would be provided in such a way that the provider is certain that the individual is not making any false claims about the underlying data and, as such, can be confident they are offering the correct insurance all while preserving the individual’s privacy.
In the context of smart contracts, ZKPs allow for any variable in a program to remain private without sacrificing the system’s accountability. Shafi Goldwasser, Silvio Micali and Charles Rackoff first articulated the concept of a ZKP in 1985; however, the theory’s practical implementations in the context of blockchains only materialized in 2013 with the advent of the Zerocoin protocol.
Over the past year, in particular, there has been a proliferation of novel proofs, providing an ever greater range of design choices and tradeoffs. Within the ZKP family, three main categories are commonly recognized, namely ZK-SNARKs, Bulletproofs, and ZK-STARKs. Readers must be aware that there is still no consensus around this specific taxonomy and there have been other smaller categories postulated.
There is a broad range of existing and potential applications for ZKPs in the context of preserving privacy, including:
Table 1. ZKP General Applications: Financial Services
|Example: Credit Rating Protocols||Example: Income-Generating Securities||Example: Company Solvency|
|Thus far, the majority of use cases for ZKPs has been within the context of finance, whether it be for cryptocurrencies and the emerging decentralized finance sector or preexisting legacy providers.||ZKP technology could feasibly allow users and corporations to receive credit ratings through the issuance of proofs based on their financial history that attest to their ability to make repayments without revealing any specific financial data or using a trusted intermediary as is currently the case with traditional finance. Not only does this strengthen user and business privacy, which in itself is monetarily valuable but it also potentially introduces major cost and time savings.||Many projects are working on bridging the existing financial industry with the emergent blockchain-based financial ecosystem, looking to integrate asset classes such as securities onto public networks. In the case of income-generating assets such as bonds and dividend-yielding equities, it is necessary for asset issuers to make regular payments to asset holders. ZKPs allow for such payments to occur without revealing a recipient’s payment address or the amount received, offering a similar degree of privacy to that of legacy finance.||While traditional auditing typically preserves privacy, it is reliant on the good conduct of the auditor. ZKPs can enable full audits with even greater privacy, by not revealing balance sheet information to any third party, while also introducing major cost savings through automation and disintermediation. It is not unheard of for audit information to leak from auditing firms, and so any technique that minimizes human interaction with sensitive data is positive for business privacy and security. A ZKP allows any entity to prove that its assets are greater than its liabilities or prove any other conditional statement about its financial state, while all inputs (balance sheet specifics) are fully hidden.|
Table 2. ZKP General Applications: Healthcare
|General Application: Healthcare||Benefit: Better Patient Outcomes||Benefit: Health Insurance|
|Users can retain sovereignty over their health records and information, while selectively sharing statements and conclusions about their health to certain healthcare providers on-demand without unveiling the underlying medical data. Increasing the privacy that patients have over their health data potentially has wide ranging benefits.||ZKP technology can allow users to retain underlying health data while making selective statements about their health to professionals. This alternative design bypasses the need for patients to either provide their data to every practitioner they interact with or to wait for it to be forwarded by their current practitioner.|
As such, patients can access multiple professional opinions and diagnoses simultaneously at much greater speeds. Not only will this likely result in better outcomes through faster and more accurate diagnoses and treatments, but it may in turn increase competition between providers, reducing costs and improving services. Meanwhile, an increase in sharing should be to the benefit of providers who can theoretically serve a larger group of patients.
|Patients can apply for health insurance by providing minimally-sufficient statements about their health status without revealing underlying data. Simultaneously, patients who already have insurance can prove this to a hospital without exchanging any specific document details.|
Ultimately, ZKPs can be applied to any use case that requires high levels of privacy alongside verifiable claims on a public blockchain.
Before considering the specifics of each type of ZKP, it is essential to outline the parameters by which these setups should be measured so that we can understand the different properties and tradeoffs between different ZKP protocols. For the sake of clarity, it is necessary to make some generalizations across the three categories outlined as the nuances of each setup are too great to reflect with complete accuracy in a concise manner.
At a high level, a ZKP can be assessed across four broad categories, namely: performance, functionality, transparency and security while there are key parameters by which they are typically measured and compared within each of these categories.2
Categories & Parameters for Consideration
|Proof Size||The size in bytes of a proof. Larger proofs create a heavier network load and higher storage requirements.|
|Prover Time||The time required to construct a proof. Longer prover times generally involve higher up-front computation costs and introduce delays.|
|Verification Time||The time required for a node to verify a proof. Longer verification times generally involve higher computation costs and introduce delays.|
|Costs||The costs to verify a proof on-chain. Higher gas costs limit the application of ZKPs on networks such as Ethereum where there is a bounded gas limit.|
|Privacy Guarantees||The extent to which the protocol extends privacy to transaction participants (e.g. hiding addresses) and smart contract logic.|
|Universality||If a protocol is universal then it can be used across any number of applications without requiring a new setup|
|Trusted Setup||Some ZKPs require an initial input number as part of the first proof construction. A ZKP either has a ‘trusted setup’, meaning generating this number is not transparent and participants must trust the entities involved in the setup or there is no setup at all and is, therefore, transparent.|
|Strength of Cryptographic Assumptions||How long have the ZKP’s cryptographic primitives been in use and how much peer review has there been of them. Older cryptographic primitives are generally considered more battle-tested.|
|Quantum Security||Whether the protocol uses cryptographic primitives that are considered to be secure in the face of quantum computing. While there remains debate over how soon the threat of quantum decryption will become practically real, in general proofs currently considered quantum secure are preferred.|
A ZK-SNARK (SNARK) is an abbreviation for a zero-knowledge succinct non-interactive argument of knowledge. The zero-knowledge component of a SNARK is what gives the construction its privacy features, offering both confidentiality, by hiding inputs (e.g. transaction amounts), and anonymity by hiding the parties involved (e.g. hiding sender and receiver addresses). The SNARK has so far been the ZKP method most commonly employed by smart contract platforms for achieving privacy.
By and large, SNARKs have small proofs, moderate prover times and short verification times. Its short verification time is what lends a SNARK its succinct property which notably does not take into consideration the prover time, i.e. the time it takes to generate a proof.
Until recently, SNARK constructions all relied on what is known as a trusted setup, and so were not transparent while they were also inapplicable to smart contract use cases. Older SNARKs, such as that used in Zcash (Groth16) require a set of public parameters for the construction and verification of proofs. These parameters are generated in what is known as a multi-party computation (MPC) ceremony, where a group of parties each generates parameters from random numbers, known as toxic waste. Assuming that at least one actor behaves honestly, the setup is secure and immune from fraudulent proofs. Despite what is theoretically a low-security threat, ultimately users of SNARKs such as these have to place trust in the setup. Recently, trustless SNARKs have been published such as Hyrax and Spartan though.
Beyond this, with SNARKs such as Groth16, the resulting parameters can only be used for one application, i.e. a UTXO set in the case of Zcash. This rigidness makes such setups unsuitable for smart contract platforms, where it is necessary to support an unlimited number of applications. Recently, alternative SNARKs, namely Sonic, Marlin and PLONK, referred to by some as SNORKs, have emerged.3 These constructions provide universal and updateable reference strings. The universality of these protocols means that there is no requirement for a new setup every time that you require a change to a smart contract, something that is essential for any practical implementation. In addition, the ability for new parties to indefinitely contribute additional randomness to a reference string (updateable), increases the robustness of the setup, in turn improving the security for the applications making use of the protocol. Critically, though, there is a tradeoff between transparency and universality on the one hand, and proof size on the other, meaning that transparent and universal SNARKs have larger proof sizes than more limited constructions, introducing a point of reflection for engineers and developers.
The final aspect of SNARKs to consider is their general reliance on asymmetric cryptographic primitives. Asymmetric cryptography is generally considered susceptible to advances in quantum computing. For instance it has been shown over ten years ago that the discrete logarithm problem, commonly used in asymmetric-based ZKPs, can be efficiently broken by Shor’s quantum computer algorithm. Considering recent advances in quantum computing performance from companies such as Google, IBM, and Honeywell, privacy-conscious platforms and applications may be wise to steer away from such setups. Beyond this, it is important to consider the future costs of such choices, especially considering that applications, services, and infrastructure layers will likely be building on top of them. There have been some recent proposals to use lattice-based SNARKs that may offer quantum-security, however they are currently at an academic stage.
Among different ZKP designs, SNARK-based implementations have been by far the most commonly deployed in blockchain-based systems, some notable examples include:
- Aztec Protocol is a privacy-preserving protocol for transactions on Ethereum. Aztec currently uses ZKPs based on homomorphic encryption and range proofs and only offers privacy for transaction amounts. However, the project has developed a high-performance SNARK, called PLONK that is both universal and updateable and is relatively inexpensive in terms of gas costs while the team is also working towards privacy for transaction participants, transaction logic and smart contracts.4 Aztec’s design means that users can theoretically transact privately between any dApp with any asset that runs on top of Ethereum. Aside from its use of asymmetric primitives and the problems this engenders, Aztec’s current ZKPs and upcoming PLONK, rely on a trusted setup and are therefore not transparent. Beyond this, the Aztec team recently announced that it is also working on an additional design, called ZK-ZK Rollup that uses recursive SNARKs based on PLONK, that is intended to allow for scalable private transactions with both private amounts and participants at a capacity of 100 TPS.
- ZK-Sync is a second-layer protocol based on ZK-Rollups being developed by Matter Labs. The Matter Labs team is working on a new SNARK, called Redshift for integration in ZK-Sync that promises universality, transparency, and quantum-security. Redshift’s universal property allows it to efficiently extend privacy to smart contracts and therefore, dApps, all without the need for a trusted setup. Unlike nearly all other SNARK designs, Redshift only uses symmetric primitives, namely collision-resistant hash functions, making it quantum-secure although this comes at the cost of large proof sizes that measure several kilobytes.5 Although ZK-Sync’s second-layer design offers a highly scalable option to developers, once Redshift is implemented, it will only initially provide transaction privacy. It should also be noted, that since ZK-Sync is a second layer protocol it does not come with the same security guarantees as privacy-enabled layer one protocols.
- Tornado Cash has focused solely on transaction privacy, opting out of addressing the complexities in enabling private smart contracts. Through the use of SNARKs, Tornado Cash obfuscates the path of an Ether transaction between the sender and receiver, similar to how mixing protocols operate. Ether is deposited into a smart contract from which other addresses can then withdraw. This design ensures that the protocol is noncustodial and with the use of SNARKs, onlookers cannot trace the transactions between addresses, offering strong privacy guarantees to the participants. While the protocol only supports Ether as of now, its team intends to add support for ERC20 tokens.
- Qtum is designing a private computation and asset protocol, named Phantom that is in development and expected to go live this year. Phantom uses SNARKs and aims to support private smart contracts while being relatively cost-competitive with a confidential transaction resulting in a 1,014,000 gas cost. The protocol does, however, rely on a trusted setup and although not explicitly stated, almost certainly depends on asymmetric primitives. The QTUM team has also explored other protocols, namely Aztec and Zether as well as an implementation of confidential transactions through an adaption of the MimbleWimble protocol that also uses Bulletproofs. It is unclear, however, whether these considerations have been dismissed in favor of Phantom.
- Nomadic Labs, a Tezos-focused research and development company is working towards an implementation of SNARKs for the Tezos network. The implementation will be largely based on Zcash’s Sapling protocol which itself uses a Groth16 SNARK. Although Sapling is no longer the current specification for Zcash, it does introduce performance improvements over earlier Zcash specifications, specifically to verification times. Nomadic has framed the potential upgrade as especially relevant to security token offerings (STOs), for which they believe enhanced privacy is important.
- Nightfall is an enterprise-focused ZKP protocol being developed by the professional services company, EY for implementation on public, permissionless networks rather than private blockchains. Nightfall uses a SNARK with a trusted setup and allows for entities to privately transact with ERC20 and ERC721 tokens on Ethereum, with privacy extending both to transaction values and participants. Like other SNARKs, Nightfall relies on asymmetric primitives, however, its use of the knowledge of exponent (KoE) assumption, a less-tested primitive means that it has inferior security guarantees than setups that use more tested assumptions such as the discrete log problem over elliptic curve groups (DLP).6
Table 3. Comparison of SNARK implementation tradeoffs.7
|Project||Privacy Guarantees||Trusted Setup Reliance||Cryptographic Assumptions||Gas Costs||Privacy Transaction Scalability||State of Development|
|• Currently only values are hidden|
• Working towards privacy for participants and smart contract logic
|• Current ZKPs and upcoming PLONK rely on a trusted setup|
• Somewhat mitigated by largest MPC ceremony to-date (176 participants over 32 days)
|PLONK is quantum-insecure, however, by swapping Kate commitments for the FRI protocol it can become quantum-secure||300,000|
• PLONK proof sizes are 510 bytes
• Recursive SNARKS via ZK-ZK Rollup offer greater scalability
|• Current Aztec protocol is ready for use|
• PLONK is under development
|ZK-Sync||• Values remain private|
• No privacy for participants
• Smart contract privacy in development
|No trusted setup||Quantum-secure||Unspecified||Redshift has large proof sizes (several kilobytes)||• Active development|
• Under peer review
|• Participants remain private|
• Transaction values can plausibly be obscured
|Trusted setup||Quantum-insecure||301,233 – 1,088,354||Unspecified proof size||• Still experimental|
• Has passed a security audit
|Qtum||Values and participants remain private||Trusted setup||Quantum-insecure||1,014,000||Unspecified proof size||• Active development|
• Due in 2020
|Nomadic||Values and participants remain private||Trusted setup||Quantum-insecure||Unspecified||Small proof sizes (130 bytes if unchanged from original Sapling specifications)||Early development|
|Nightfall||• Values and participants remain private|
• Minting and burning functions are visible
|Trusted setup||• Quantum-insecure|
• KoE assumption is less robust than other asymmetric primitives
|2,700,000 for ERC20 transfer||Small proof sizes (256 bytes)||Active development, not production ready|
Bulletproofs are an alternative branch of ZKPs, that were originally designed to improve on confidential transactions that had been suggested for use in Bitcoin and other monetary crypto networks. However, with their own set of distinct tradeoffs and advantages, the technology has since found growing application in smart contract platforms. Unlike the majority of SNARK implementations, Bulletproofs are transparent and do not require a trusted setup. In addition, while Bulletproofs are also quantum insecure, their cryptographic assumption, namely the DLP, is an older and better-tested primitive than the KoE assumption that SNARKs rely on. Furthermore, while vulnerabilities in the KoE would not necessarily affect the robustness of the DLP, if the DLP were found to be insecure then the KoE would automatically be insecure. Although Bulletproofs have larger proof sizes than SNARKs, they are not generally prohibitively large.
Where Bulletproofs struggle to compete with SNARKs is their inferior privacy capabilities, in that they only provide confidentiality (obscuring transaction amounts), while unlike SNARKs, they do not offer anonymity (obscuring the addresses of the parties involved in a transaction). It is possible, however, as later examples will illustrate, to combine Bulletproofs with anonymity-preserving techniques for privacy that is comparative to SNARKs. The other major disadvantage of Bulletproof-based ZKPs are their longer verification times, relative to most SNARKs.
Although there are fewer Bulletproof implementations compared to SNARKs, there are still some promising applications, including:
- Zether or private Ether, uses a modified version of Bulletproofs to facilitate private payments on account-based smart contract networks. The protocol functions as a smart contract that obscures values and can interoperate privately with other contracts. This feature, according to its authors, allows Zether to support certain private applications, including auctions, payment channels, voting, and private staking. By using Bulletproofs, Zether is inherently transparent but does impose relatively high gas costs.8 Since Bulletproofs only extends privacy to transaction values, Zether offers an extension, through the use of ring signatures and range proofs, albeit with further costs, for users to collectively group transactions, theoretically providing anonymity by obscuring the sender and receiver.
- Anonymous Zether is a modified version of Zether, built by JPMorgan Chase for use on its Quorum network. Anonymous Zether is a very recent protocol (March 2020) that offers more extensive privacy guarantees than the original Zether proposal by improving the anonymity between participants, while also enhancing the protocol’s performance, by achieving logarithmic growth in proof size compared to linear growth in the case of Zether. There is however no standard comparison between Zether and Anonymous Zether since the performance of Anonymous Zether depends on the size of its anonymity set, i.e. the number of participants, while Zether’s published metrics only apply to its non-anonymous version. Notwithstanding this, for anonymity sets of two and four, Anonymous Zether consumes less gas, whereas, for sets of eight and above, it is more expensive than the original Zether protocol.9 Critically though, in the case of Quorum, where teams can set their gas limits and are not bound by the hardware limitations of a public network, gas consumption matters far less.
- Stellar has been applying Bulletproofs to its Slingshot project. Slingshot’s ZkVM (zero-knowledge virtual machine) uses a modified Bulletproofs protocol for private transaction values and smart contract parameters. In addition, it hides an asset type, meaning that multiple assets can coexist on the same network while appearing the same to onlookers. This modified implementation of Bulletproofs, according to the authors, is the fastest Bulletproofs protocol to-date, made possible by the use of the Ristretto technique. Based on the benchmarks that its authors use, this lends it major improvements in both proving and verification times relative to the original (2017) Bulletproofs protocol.10 Although it does not by default offer anonymity, the ZkVM does support an adaption of the trustless mixing protocol, CoinJoin that offers some degree of anonymity. To keep the logic of smart contracts private, the ZkVM uses Taproot, a novel commitment scheme developed for Bitcoin, that allows multiple conditions to be expressed in a single public key.
Table 4. Comparison of Bulletproof implementation tradeoffs. 11
|Project||Privacy Guarantees||Trusted Setup Reliance||Cryptographic Assumptions||Gas Costs||Private Transaction Scalability||State of Development|
|Zether||• Values remain private|
• Privacy for participants is possible with additional gas cost
|No trusted setup||Quantum-insecure||7,188,000||1.472 KB proof size||No direct implementations|
|Anonymous Zether||Values and participants remain private||No trusted setup||Quantum-insecure||• Huge variations depending on size of anonymity set|
• 2,405,339 – 48,764,759
|2.048-4.928 KB proof sizes||• Active development|
• Not production ready
|Slingshot||• Values remain private|
• Privacy for participants is available
• Smart contract parameters and logic remain private
|No trusted setup||Quantum-insecure||Unspecified||Unspecified||Active development|
The most recent category of ZKP to emerge are ZK-STARKS (STARKs). This ZKP is a zero-knowledge scalable and transparent argument of knowledge. Much like SNARKs, the zero-knowledge property lends it its privacy capability, in that it allows inputs and participants to remain private.
Unlike a SNARK, STARKs scalable characteristic refers to both its verification and prover times, while its transparent property refers to its lack of a trusted setup, much like Bulletproofs and in contrast to most SNARKs. Despite their very short verification and prover times, though, STARKs typically have very large proof sizes, which has been one of its main barriers to use thus far since these proofs have to be stored on public blockchains where storage capacity is typically quite scarce.12 Where STARKs differ from SNARKs and Bulletproofs alike though are its use of symmetric primitives, namely hash functions. Whereas Bulletproofs and most SNARK construction use asymmetric (public key) cryptography, STARKs make use of symmetric primitives, namely hash functions such as SHA256 or Keccak making them plausibly quantum-secure. Industry experts, for now, consider symmetric cryptography as secure in the face of quantum computers, albeit with some mild alterations.
STARKs promisingly combine privacy with scalability. STARK’s scale ‘asymmetrically,’ meaning that, as the size of the data set for which the STARK is providing proofs for grows, the proving time scales almost linearly while, most importantly, the verification time scales logarithmically (or exponentially smaller). In practical terms, this design enables enterprise solutions that balance data-privacy with public transparency and accountability. For instance, using STARKs, it is possible to process large sets of data off-chain along with the construction of their proofs while allowing nodes on a public network such as Ethereum to verify said proofs, attesting to their validity without any sensitive data becoming public. Proponents of this technology have hypothesized other use cases such as proofs of solvency that allow for businesses to demonstrate financial health without disclosing any specific balance-sheet information.
Performance of StarkWare’s ZK-STARK Implementation vs Other ZKPs13
Thus far, however, implementations have focused on the scalability rather than privacy property of STARKs and to date, there are no privacy-enabling implementations of STARKs on smart contract networks. Several possible reasons exist for this, such as their relative novelty compared to SNARKs and Bulletproofs, a lack of developer tooling and the current focus from Starkware, the dominant STARK development company, on their scalability rather than privacy property. However, the most pressing issue is their large proof size (communication complexity), which, despite also scaling logarithmically relative to the size of the data set, is typically two orders of magnitude (10²) larger than those of SNARKs and one order relative to Bulletproofs. As such, despite being quick to prove and verify, their especially large proof sizes make them prohibitively large in the case of public networks, where on-chain storage space is limited by the hardware capacity of the network’s nodes, in turn making them expensive (in terms of Gas cost in the case of Ethereum) to verify. STARKs’ authors theorize that proof aggregation could reduce proof size, and there are several known theoretical advancements that could lead to proofs as small as 1 KB. Yet, for now, STARKs’ proof size impedes their use. Ultimately, STARKs are more suited to privacy scenarios that require very large data sets to be proved and verified whereas for smaller computations, SNARKs and Bulletproofs are more applicable.
This limitation highlights a final tradeoff that projects should consider. In general, there is an inverse relationship between a ZKP’s proof size and the soundness of its underlying cryptography. At a high level, ZKPs that solely use symmetric primitives, and so are safe against quantum computing attacks, also have much larger proof sizes, while ZKPs that use asymmetric primitives have far smaller proof sizes but are quantum-insecure.
Table 5. Key Parameters of SNARKs, Bulletproofs and STARKs.14
|Proof Size||Small (130-600 bytes in most cases)||Medium (~1.3-2 KB)||Large (~20-45 KB)|
|Verification Time||Fast (Less than 20 MS)||Medium||Fast (Less than 20 MS)|
|Verification Costs (EVM)||~600,000 Gas||7,188,000 Gas|
|Transparency||Mixed (Generally nontransparent)||Transparent||Transparent|
|Asymmetric Primitives; Quantum Insecure||Asymmetric Primitives; Quantum Insecure||Symmetric Primitives; Quantum Secure|
Clearly then, there are many tradeoffs between different ZKPs that projects need to consider before implementation. While it is unlikely that any one construction will ever perform well across every parameter, there has been and likely will continue to be an overall improvement in the performance of these proofs. More importantly, the recent and significant increase in the number of different ZKPs, means that teams have a broad range of choices, and can selectively optimize for the exact needs of their application.
As this report shows, projects have an already wide and fast-increasing choice of ZKP systems to integrate into their applications and protocols. Smart contract networks and the services that use them, almost certainly require privacy embedded throughout the stack if they are to be adopted by enterprises and the general public. These networks execute and support programs and applications while also connecting sensitive off-chain data such as user credentials (passports, etc), with on-chain behavior and connect these interactions across the entire mesh of applications with which users interact. Beyond this, enterprises who may want to leverage public blockchains, bring with them internal databases containing highly sensitive and valuable information. If these networks hope to attract traffic away from existing centralized systems, they must offer at least comparable levels of privacy and ideally, far more.
ZKP systems offer a compelling balance of privacy and accountability. While there are certainly still impediments to ZKP adoption such as the theoretical state of many systems, an oftentimes lack of developer tooling (especially in the case of newer systems), the numerous tradeoffs such as quantum security vs proof size as well as the higher costs of ZKP systems compared to both non-private alternatives and lighter privacy solutions (i.e. hash-reveal schemes), these hindrances are most likely either transitory or acceptable limitations for the majority of potential use cases. The promise of enhanced privacy at the lower levels of contract design, provides motivation for projects to explore this exciting class of privacy enhancing protocols. This allows for blockchain and distributed ledgers to deliver embedded privacy guarantees within higher level solutions.
The fundamental privacy value of ZKP systems is their ability to allow for complete data privacy while supporting permissionless verification of said data and the claims that derive from it, solving the transparency-privacy dichotomy highlighted at the start of the report. As such, ZKPs open the possibility to enterprises and governmental organizations using public crypto networks as they can retain data privacy while benefiting from the increased trust and credibility that comes from permissionless verification of data integrity whether that be financial solvency, supply chain auditability or blockchain voting. At the same time, ZKPs should strengthen the promise of Web3 applications by concealing on-chain and off-chain user data that would otherwise be exposed while still allowing analytics providers to produce highly-detailed graphs of user activity, information, behavior and even personality types since the Web3 design is predicated on maximizing interconnectivity on what are otherwise pseudonymous networks.
2) It is important to also consider the difference between optional and mandatory privacy within ZKP implementations. Generally, however, this is far more relevant to pure monetary networks (such as Monero and Zcash) and implementations that only obscure transaction values on smart contract networks. Given that privacy typically increases computational costs, most-often born by the end-user, when privacy is optional projects risk that a majority of participants opt-out of private transactions, in turn undermining the privacy of others. Blockchain analytics providers have an ever-increasingly powerful set of tools to graph interactions between network participants and in general, can deanonymize participants in systems that have small privacy sets (e.g. few users opting for privacy). As such, implementations, where privacy is mandatory or at least the default and have larger privacy sets, offer stronger privacy guarantees.
4) Some industry participants refer to PLONK as a SNORK [Succinct Non-interactive Oecumenical (Universal) Arguments of Knowledge]. According to the team, the verifier gas cost for PLONK is 223,000 vs 203,000 on Groth16.
6) This is explicitly acknowledged by the protocol’s authors.
7) Sources for SNARK table values include:
Aztec. MPC ceremony participation. Kate commitments and quantum-security. Gas costs. PLONK proof sizes.
Tornado Cash. Gas costs.
Qtum. Gas costs.
Nomadic. Gas costs.
Nightfall. KoE assumptions. Gas costs. Proof sizes.
8) Zether transactions at the time of the paper’s release cost ~0.014 ETH, however the recent Istanbul upgrade on Ethereum should reduce these costs due to the cost reduction of the elliptic curve precompiles that Zether uses.
9) Size of Anonymity Set/Gas Used: 2/2,405,339, 4/5,152,200, 8/8,519,260, 16/13,670,599, 32/24,427,623, 64/48,764,759.
10) Readers should be aware that there is no standardized benchmark for comparison ZKPs. In this case, the author measured their protocol in the context of 64-bit range proofs. The authors present the comparative performance (proving and verification times only) of their implementation relative to other Bulletproof protocols here.
12) Although STARKs have very large proof sizes, they can be verified extremely quickly since the verifier can query the proof at intervals rather than reading it in its entirety, as explained here. This property is due to the use of interactive oracle proofs (IOPs), based on the PCP theorem.
13) Communication complexity refers to proof size. The source for the chart is https://eprint.iacr.org/2018/046.pdf.
14) This table used data from multiple reputable industry sources. It should be noted that much like the taxonomy of ZKPs, there is no consensus on how these parameters should be measured. While the table attempts to reflect the different approaches to benchmarking, the values should not be accepted without further investigation into individual ZKP constructions. Some notable caveats include:
- Proof size for more limited SNARKs that are neither transparent nor universal and updateable are smaller (130 bytes in the case of Groth16) than more capable SNARK constructions such as PLONK (510 bytes) and others that are typically closer to ~600 bytes while other constructions have proofs of several KB.
- Measurements and estimates of Verification Costs so far have all been conducted against Ethereum.
- The Verification Costs for Bulletproofs are based purely on Zether, the only strict Bulletproof protocol to be tested in an EVM environment. Readers should be aware that higher performance Bulletproof protocols do now exist but none have been tested on the EVM.