Innovations in Zero-Knowledge Proofs
Thematic Analysis #9
This is the ninth article in our Thematic Analysis series. In this series, we talk about broader trends and emerging concepts in the crypto space, looking towards the future and analysing how Web3 is evolving in real-time. Let’s dive in!
Theme: Innovations in Zero-Knowledge Proofs
Glossary 🔖
Given the technical nature of this piece, it’ll be helpful to level-set on terminology and concepts to make sure your reaction while reading this article isn’t like the one on the face of our favourite Julia Roberts lookalike:
Zero-Knowledge Proofs (ZKPs)
ZKPs let someone prove that they know, have, or are something without giving up any information about what they know, have, or are. At their core, ZKPs have strong cryptographic guarantees, with the use of cryptographic techniques like digital signatures and hashing providing assurances that the underlying data has not been accessed, modified, or disclosed in an unauthorised manner. These guarantees are achieved via mathematical algorithms that make it practically impossible for attackers to break the encryption or tamper with the data.
zk-SNARKs and zk-STARKs
These are two types of zero-knowledge proofs; zk-SNARKs rely on trusted setups and are faster and less computationally intensive than zk-STARKs, but are also less secure.
zkEVM
To start with, the Ethereum Virtual Machine, or EVM, is a virtual computer that executes smart contracts on the Ethereum blockchain. A zkEVM is a privacy-focused version of the EVM that that uses zero-knowledge technology to prove the correctness and verifiability of transactions submitted to Ethereum. zkEVMs use zero-knowledge proofs to validate transactions without revealing any sensitive information, allowing for private and secure transactions on Ethereum.
The biggest benefit of zkEVMs is that they are ‘EVM-equivalent’ – i.e., existing apps on Ethereum can be migrated with little to no rework, significantly reducing development effort and making it much easier to deploy apps on Ethereum.
Introduction 👋
Picture this. You’re standing outside a club, waiting to get in, and the bouncer stops you at the door, ready to check your ID. You hand it over to him, and he sees, along with the fact that you’re (hopefully) above 21, your name, address, visa status and national insurance number – none of which he needs to know to let you into the club.
What if, instead, he could scan a QR code on your phone that would prove the one fact needed to enter the club: that you’re over 21. The bouncer would know no other information about you, preserving your privacy. That is what zero-knowledge proofs enable.
The first instance of ZKPs and blockchains coming together was in Zcash, where zero-knowledge proofs enable the network of computers running the Zcash protocol to verify that every transaction is valid (i.e., I actually have the 10 Zcash I am sending to you) while maintaining the privacy of the transaction data. However, Zcash did not scale especially well – the zkSNARKs it used at the time (and until very recently) were computationally intensive and made transactions slower and more resource-intensive. The computational power needed to generate zkSNARKs meant ordinary users could not participate in proof generation, and thus in the Zcash network. The team also prioritised privacy over scalability, aiming to perfect privacy-enhancing features even at the expense of some speed and scalability.
However, the tide is turning. ZKPs have been gaining more and more attention over the last few years as the technology to create them has advanced enough to reach production scale. For starters, the race is on and heating up to be the preeminent Layer 2 blockchain on Ethereum leveraging zero-knowledge proofs, with zkSync and Polygon already having launched their zkEVM products and Scroll and Consensys not too far behind.
The ecosystem is also recognising the fundamental benefit of zero-knowledge technology for a host of other applications: preserving total privacy and confidentiality while simultaneously verifying the truthfulness of a statement with a high degree of certainty. There are many potential applications for ZKPs – digital identity (as in the example above), ratings and risk assessments for financial instruments, private KYC/KYB, proof of ownership or activity, digital voting, etc. Given the widely commercial aspects of these applications in maintaining the privacy of individuals and businesses at scale, ZKPs are also likely to gain much interest from an institutional perspective. There are a number of projects in the ZK ecosystem building solutions aimed at, one, scaling and improving zero-knowledge technology itself, and two, utilising the vast improvement in ZKPs to encourage their use in scaling and growing blockchains at the base layer.
In this article, we’ll first explore what ZKPs are, how they work, and some practical applications. We’ll then go into some challenges with zero-knowledge technology and what is being worked on to scale ZKPs, such as hardware acceleration. Then, we’ll look at applications of zero-knowledge proofs across the blockchain space, touching upon zkEVMs and diving into three projects with ZKPs at their core: Aleo, Espresso Systems, and Lagrange. Other honourable mentions include Railgun, Herodotus, Capsule and Panther Protocol.
How ZKPs Work 🧩
There are two key actors in the creation of a zero-knowledge proof: a prover and a verifier. The prover convinces the verifier that they know a certain piece of information without revealing that information.
Imagine a scenario to understand how ZKPs work: Alice wants to prove to Bob that she knows the password to a locked box, without actually revealing the password to him. The protocol would proceed as follows:
Alice puts the locked box in a room and leaves.
Bob goes into the room, opens the box, and retrieves a piece of paper with a random string of characters written on it. He then locks the box again and leave the room.
Alice comes back into the room and Bob asks her to prove that she knows the string of characters on the paper. Alice then performs some computations on the string of characters in such a way that Bob can be convinced that she knows the string without actually revealing the string itself.
Bob is then satisfied that Alice knows the password, even though he never learns the password himself.
Alice is the prover and Bob is the verifier. The protocol ensures that Bob can be convinced of Alice's knowledge without revealing the information to him. Alice creates a ‘proof’ and hands it to Bob to verify its accuracy.
Initial versions of ZK proofs were interactive, i.e., to prove something, you must play a game with the verifier. Think of them as a lie detector test, where one party asks questions and the other answers until the truth has been established. Now, more and more ZK proofs are non-interactive and generate a piece of data that acts as a proof and can be directly submitted for verification without needing back-and-forth communication, increasing speed and scalability.
A core feature (and benefit) of ZKPs is configurable privacy – they allow you to selectively hide some or all inputs. To further improve the integrity and scalability of ZKPs, third-party providers can also generate ‘proofs of computational integrity’ that guarantee the output received.
Applications 📱
Some examples of how ZKPs can be integrated into everyday tools are:
Identity Authentication: Instead of divulging all details about your identity to anyone who needs to verify who you are, you can simply provide a zero-knowledge proof confirming that you are who you say you are. An institutional and retail use case is cloud computing, where institutions and individuals can use cloud computing without sharing any private, sensitive data – for example, they can prove their identity to the cloud service provider without revealing their credentials, or verify computations done on private data stored in the cloud without exposing private data.
Access Control: ZKPs can be used to prove that a person has access to a certain resource without revealing any information about the resource or the access credentials.
Copyright Protection: They can prove that a person owns a piece of content without revealing the content itself.
Credit Scores: Individuals and institutions can prove that they have a good credit score without revealing their actual credit score or any other personal financial information.
Investment Portfolios: ZKPs can verify the accuracy of risk assessment data without revealing any sensitive information about the investments. This is important in scenarios where multiple parties need to collaborate on risk assessments without exposing their investments to each other.
Voting: ZKPs can be used to prevent voter fraud by ensuring that only eligible voters can vote and that each vote is counted accurately and has not been tampered with.
One of the main blockchain-specific applications of zero-knowledge proofs (apart from the Zcash example above) is ZK rollups. A Layer 2 rollup (Optimism, Arbitrum, zkSync, etc.) is a blockchain built on top of another blockchain (Ethereum) in order to scale the underlying blockchain. Layer 2s increase transaction throughput and lower transaction costs by processing transactions off-chain and aggregating them into a single transaction that is submitted to the underlying blockchain in a compressed format. ZK rollups use zero-knowledge proofs to verify the validity of all the transactions processed off-chain. When a ZK rollup is published onto an L1, it includes a proof that all the activity on the L2 was legitimate along with a complete list of all the changes to account balances on the L2 since the last rollup. Zero-knowledge technology is well-suited to scale blockchains since, by reducing the amount of data held in a transaction, it reduces the computing and storage resources needed to validate transactions. This increases speed markedly and helps in decentralising the network.
Another use case is privacy-enabled stablecoins. A stablecoin can be created where the issuer is able to verify the compliance status of all holders and maintain a complete audit trail while preserving the privacy of holders from both the issuer and the rest of the world.
Later in the article, we’ll go through some other innovative ways in which ZKPs are being used to improve and scale blockchain technologies.
Challenges with ZKPs ❌
One of the main challenges with ZKPs is that they are slow and expensive since a large number of expensive math operations are required to generate a proof. Proving a computation requires first translating it from a classical program to a ZK-friendly format. More complex operations result in longer proof generation times, and some operations may not be ZK-friendly, again leading to long proof generation times.
Moreover, as mentioned above, an interactive ZK proof requires a trusted setup, where a group of trusted parties generate a set of parameters that are used to generate and verify proofs. In a trusted setup, each member of the group generates a portion of the parameter and obfuscates it. The portions are then combined to create the final key. This ensures that no single member of the group can individually determine the final key. It can be difficult to set up and coordinate this process and it may also introduce security risks. Trusted setups also need multiple rounds of verification between the prover and verifier, which reduces the speed and efficiency of proof generation.
Another challenge with wide-scale implementation of ZKPs is integrating them with existing systems, especially since most systems have not been designed with ZKPs in mind.
Scaling ZKPs: Hardware Acceleration 🏎️
Hardware acceleration refers to the use of specialised hardware to perform certain operations required for generating and verifying ZKPs. The mathematical operations needed to generate ZKPs, such as elliptic curve operations, can be sped up by using dedicated hardware modules like field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or graphics processing units (GPUs).
FPGAs are the most promising of the three. They are like small electronic chips that can be programmed to perform different tasks. They are designed to be very flexible, i.e., they can be programmed to do many different things. For example, you could program an FPGA to process audio signals, or to control the movements of a robot. One of the biggest advantages of FPGAs is that they can be reprogrammed or updated with new functionality as needed. This makes them very useful for applications where you need to be able to change what the device does, without having to completely redesign it from scratch. This property makes them useful for ZKP generation. FPGAs are preferable for hardware acceleration compared to ASICs due to this property, and because their supply chain is healthier and it is easier to buy them on the market. They are also cheaper and more efficient than GPUs.
Another benefit of hardware acceleration is how they can improve the security of ZKPs by reducing the risk of side-channel attacks, where attackers use information that leaks from a device, like its power consumption or electromagnetic radiation, to steal sensitive information like cryptographic keys.
All in all, hardware acceleration using FPGAs (and ASICs and GPUs) has led to marked improvements in the scalability of ZKPs.
Innovations in Zero-Knowledge Proofs 💡
There are a number of tools and crypto infrastructure services incorporating ZKPs at the very core of their products. Today, we’ll dive into Aleo, a decentralised platform that uses its blockchain to verify and store proofs; Espresso Systems, a crypto infrastructure company creating privacy-enhancing products like CAPE protocol; and Lagrange, a protocol that uses ZKPs to enable cross-chain interoperability.
Aleo
Aleo is a blockchain that uses a Bitcoin-like architecture, including a ledger and a UTXO (unspent transaction output) model in which:
Inputs specify which address an asset comes from;
Outputs specify the address to which an asset is being sent;
The value represents the amount of the asset being sent.
To understand Aleo and the cryptography that is at the heart of its design, let’s first take a step back in time.
Long ago, in the olden times (of only a few years ago), it used to take around 3 hours to generate a zkSNARK proof. This severely limited the use cases it was applicable to and put it more in the category of ‘interesting from an academic perspective, less so from a practical one’.
And then, a breakthrough: Howard Wu, the founder of Aleo, published a new, more scalable form of cryptography called DIZK which distributes ZKP generation across machines to speed up computations. Its main innovation was in the ability to generate and verify proofs without a trusted setup. Furthermore, DIZK also introduced a distributed element to the generation of ZKPs, increasing the decentralisation and resiliency of the system. However, DIZK still had some problems: it was computationally intensive and required a lot of communication between the distributed nodes in the system, which put a ceiling on how decentralised and scalable the system could be.
So, what did Howard do? He helped create ZEXE, which takes DIZK a step further. ZEXE runs applications off-chain and just verifies the proofs on-chain. Transactions can be of many different sizes and re-executing them on-chain takes a lot of time and effort. In the ZEXE system, rather than re-executing transactions, verifiers simply check the output and the proof, which is much less computationally intensive. Another noteworthy innovation of ZEXE is that it enables function privacy as well as data privacy, meaning that no detail about the transaction, including that it even happened, is made public. Function privacy protects the privacy of the inputs and outputs of a computation, making a transaction completely private. This type of configurable privacy brings life to a whole host of institutional use cases that have a range of stringent, ever-changing privacy requirements.
His next step was to apply the ZEXE system practically in creating Aleo, which has a couple of core components: zkCloud, which is an off-chain computing environment where programs are executed privately, securely, and cheaply; and the Aleo blockchain, which stores the state of programs built on Aleo (i.e., the current balances of all accounts, status of all transactions, and any smart contracts running on the network).
Individuals interact with each other on zkCloud via ‘shielded’ transactions. These transactions are completely private – they completely hide the details of the interaction (i.e., the participants, amounts, smart contracts interacted with) by using a series of recursive ZKPs. Recursive ZKPs are used to prove to someone that you know a bunch of secrets without revealing what exactly those secrets are. They are created by first creating a ‘tree’ of small proofs, with each proof representing one secret. Pairs of small proofs are combined together to create ‘parent’ proofs, with the process being repeated until you have one big proof that simultaneously covers all secrets while keeping them hidden. In the case of Aleo, recursive ZKPs hide the smart contracts interacted with, participant identities, and transaction amounts.
The shielded transactions link zkCloud to the Aleo blockchain, creating records on-chain to update the state of the programs on Aleo, while nodes verify the proofs attached to the transactions. What this means is that the nodes do not get to see the exact details of a transaction, and only verify that it is legitimate. Moreso, transaction throughput can increase significantly since nodes are only verifying proofs rather than running programs, which takes more time and computing power.
However, running a private application is still expensive, and the learning curve for developers to build applications reliant on heavy cryptography is very high. To (somewhat) combat this, Aleo has its own programming language, Leo, which is built to look and feel like JavaScript. Leo takes code written by a developer and produces a proof that the computation was run correctly. While this may make building on Aleo easier, the need to learn a new language may somewhat slow developers onboarding onto Aleo. Aleo’s design also helps to commoditise proof generation since applications can outsource proof generation to third-party proving services using specialised hardware like FPGAs, allowing proofs to be generated in parallel and thus increasing throughput even more.
When a block is added to the Aleo blockchain, provers, verifiers, and validators are rewarded with ‘Aleo credits’. Provers receive rewards for generating proofs, validators stake Aleo credits to propose blocks made up of these proofs, and verifiers check whether the proofs within the blocks are correct.
While introducing Aleo credits helps decentralise and incentivise proof creation, the question to ask is whether a(nother) native currency like Aleo credits is necessary or if the same result could have been achieved with using an existing asset like ETH. Another question to ask is if Aleo would have been better off in terms of adoption as a Layer 2 built on top of Ethereum; this would absolve it from having to bootstrap its own network and onboard developers from scratch.
Aleo is a great experiment in showing how blockchains can maintain complete privacy while still adhering to fundamental properties like decentralisation, trustlessness, and provable verifiability.
Espresso Systems
Espresso Systems, a team of researchers from Stanford’s applied cryptography research group, builds scaling and privacy systems for Web3. One of its primary products is CAPE, or the Configurable Asset Privacy Protocol, which enables digital assets to have customised (configurable) privacy. Users can create new, privacy-enabled assets on CAPE or give existing ERC-20 assets privacy features.
Users lock existing ERC-20 tokens within wrappers (which invariably introduces the risk of ensuring that the assets locked in the wrappers are safe and not able to be accessed by rogue actors) and mint them 1:1 within the CAPE system. These assets can be unwrapped back into ERC-20 tokens.
In CAPE, users own asset records which specify the asset type, amount, and owner’s address, of which the system publishes hidden representations called ‘commitments’. The asset type defines the privacy properties of the asset that are structured like ‘policies’ – asset viewing and asset freezing policies. The asset viewing policies are configurable:
Enabling address viewing allows authorised users to follow transactions from the asset creator without seeing the value of the transaction (revealing the address commitment).
If amount viewing is enabled, authorised users can see the value of the transaction but not the recipient (revealing the amount commitment).
If both are enabled, authorised users can see both the value and recipient of the transaction (revealing both commitments).
Each transaction itself is a zero-knowledge proof, within which the transaction details, including amount and asset type, are encrypted. Authorised holders, each of whom hold a ‘viewing key’, are the only ones who can decrypt them. Verifiers only have to verify the ZKP and do not get access to any of the transaction details, apart from the CAPE fee amount attached to each transaction.
CAPE transactions are created via the CAPE wallet and submitted to a relayer rather than directly to CAPE’s smart contract on the Ethereum blockchain. The CAPE smart contract on Ethereum maintains the state of the CAPE system, tying CAPE to Ethereum by utilising its consensus mechanism and security. The relayer forwards the transaction data to the CAPE smart contract on Ethereum to be validated and pays the gas fee to do so. This ensures that the Ethereum transaction fee cannot be linked to the original user on the blockchain, preserving privacy. As of today, the relayer performs no validation and simply forwards the transaction data to Ethereum as soon as it is received.
An obvious point of danger / centralisation is in the relayer itself – is there only one relayer that is controlled by Espresso Systems and is there a way to prove that it is doing its job correctly? Also, if the relayer pays the gas fee every time, is this reflected in the CAPE fee paid by the user, and if so, is this an approximation of what the ETH gas fee would be and who covers the difference between the two fees paid if there is one? Is there a way to decentralise the relayer and reduce a potential single point of failure?
CAPE’s flexibility, configurable privacy, and ease of integration with the rest of the Ethereum ecosystem make it an appealing product for projects across Ethereum. To that end, zkSync has begun to collaborate with CAPE and is planning on using it to introduce private transactions on zkSync Era, its zkEVM blockchain.
Lagrange
Cross-chain interoperability (i.e., sending assets from one blockchain to another) is one of the most pernicious problems in Web3 due to the wide array of risks (security, operational, complexity, etc.) it introduces. Lagrange Labs develops state proofs that attest to the state of a chain at a specific point in time. State proofs allow a user to verify the integrity and accuracy of a specific piece of information or transaction without having to download and validate the entire blockchain. This simplifies transactions and makes them more secure. For example, a user who does not have a verified identity on Arbitrum can present proof of their verified identity credential on another blockchain (e.g., Solana) and start conducting activities on Arbitrum immediately. It also eliminates the need for trust between Arbitrum, Solana, and the user, and the need for the user to constantly re-authenticate themselves across chains – they can do it once and reuse the credential as needed. It also collapses the entire transaction to one continuous transaction for which only one fee must be paid.
Consider a situation where a user wants to use their ID on Solana to deposit to a permissioned vault on Dopex on Arbitrum. In a non-Lagrange world, they would have to first submit a transaction to a pre-specified smart contract on Solana. The transaction emits an ‘event’ that an intermediary messaging protocol (e.g., LayerZero) listens for, and upon receiving it, collects a fee from the user and submits a transaction to Arbitrum that contains a timestamped proof of the user’s ID on Solana. The user then submits a second transaction on Arbitrum to deposit assets into Dopex. All in all, the user needs to pay for a Solana transaction, two Arbitrum transactions, and a fee to the messaging protocol. In a Lagrange world, on the other hand, the user can attach a Lagrange state proof to a single transaction on Arbitrum and pay only one set of fees. Lagrange also offers a lot of scale and flexibility to dApp developers since multiple state proofs can be combined into one big proof. This proof, for example, can verify a user’s collateral across chains, increasing capital efficiency and reducing transaction fees since there is only one transaction with a fixed cost to which the aggregated proof is attached.
Closing Thoughts ⌛
A fundamental feature of blockchains is their pseudonymity. While this feature has attracted many privacy-focused individuals to the blockchain ecosystem, we have seen numerous times, especially with the rise of whale watcher tools (e.g., Loch, a crypto portfolio tracker and whale watcher tool co-founded by Genesis Block’s very own @yoshi_eth2), how these transactions are not really private at all. On the other hand, due to KYC/AML and compliance requirements, institutions need to verify user identities and today, they have to do what the bouncer does at the beginning of this article: take all information from the user, which compromises their privacy. ZKPs have the potential to solve both sides of this problem – regulators can get proof that users are who they say they are (and verify a bunch of other facts about users), while users can maintain complete privacy. Moreover, the configurable privacy introduced by projects like CAPE (and Railgun) gives institutions and developers a lot of flexibility in designing their systems and products.
In conclusion, ZKPs have the potential to transform how blockchains work and make them fit for purpose for a range of (primarily institutional) applications that they were previously unsuited to, and unleash a wave of compliant, privacy-focused innovation across the space.
Bibliography 📖
https://a16zcrypto.com/content/article/decentralized-speed-advances-in-zero-knowledge-proofs
https://messari.io/report/railgun-privacy-infrastructure-for-defi
https://docs.espressosys.com/cape/
Disclaimer
This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the article authors and do not represent those of people, institutions or organizations that those authors may or may not be associated with in professional or personal capacity, unless explicitly stated. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
👇🏽 please hit the ♥️ button below if you enjoyed this post.
