With most of the crypto community focused on the US election and rising prices, Denis gives us a reprieve with a deep-dive on a topic we’re always keen to learn more about: zero-knowledge proofs. - Chris
The adoption of zero-knowledge (ZK) rollups – once hailed as the next big thing in blockchain scalability – has been surprisingly slow. Despite their technological promise and recent major leaps in privacy and scalability, implementation into everyday blockchain use has been slow. Below, we discuss reasons behind the slower uptake of ZK rollups compared to optimistic rollups, and ponder how the technology will integrate into DeFi and blockchains in the future.
Zero-knowledge proofs allow someone to prove a claim without revealing the underlying information. While ZK involves some of the most advanced math in crypto, we can grasp the basics through analogies and high-school concepts.
Imagine a cave with two paths – path A and path B – that eventually meet at a locked door inside. The door can only be unlocked with a secret code. You claim to know this code.
The process:
This process is repeated multiple times. If you consistently exit through the correct path, the verifier gains confidence that you know the code. Importantly, the verifier never learns the code itself – hence, ‘zero-knowledge’.
The way the cave is built in this example (a door with a secret code and how it can influence the outcome) is very similar to how ZK systems are built.
ZK proofs can further be explained in simple terms, relying on mathematics, particularly using polynomials. These algebraic expressions – formed by the sum of any number of terms of the form cxk – are key to how ZK systems work. You may remember these from high school math:
x + 1
x2
X3+3x2+2x+1
345x335+221x334+115x333+...+65x+44
The important thing to remember as we try to understand ZKs is that polynomials can contain an unbounded number of terms. We can then understand that a single equation involving a number of polynomials can represent an infinite number of equations (read: relationships) between numbers. For example, consider the equation that includes polynomials A, B, C, and variable x: A(x) + B(x) = C(x). If this equation is true, then it’s also true that:
A(0) + B(0) = C(0)
A(1) + B(1) = C(1)
A(2) + B(2) = C(2)
A(3) + B(3) = C(3)
…
If some equation involving some polynomials solves for a randomly selected x, then it almost certainly holds true for the polynomials as a whole. So, when we look back to the cave example above, the person (verifier) can exit through the randomly required path multiple times, which is the same as an equation involving polynomials solving for a randomly required x multiple times. This in a succinct way proves that the prover holds the full amount of information, whether it’s a secret code as in the cave example, or relating to all transactions in an L2 block. For more of a detailed explanation, see this Vitalik’s article or Starknet founder Eli Ben-Sasson’s video.
These proofs are computationally expensive to create, but fast to verify. Here, it’s important to know that even though ZK is about zero leaked information, it is its speed property, and not privacy, that underpins rollups. Mathematicians and cryptographers are working on further reducing verification times.
ZK rollups aggregate transactions offchain into batches, generating proofs (zk-SNARK or zk-STARK) that are used to validate batches of transactions. The aggregated proof, along with a minimal amount of data required to reconstruct the state, is submitted to the main chain (e.g., Ethereum). This proof is used to confirm that the offchain transactions were processed correctly. The main chain only needs to verify this small proof rather than re-executing every transaction, which significantly reduces the computational load and enhances scalability.
ZK proofs ensure that rollup operators cannot cheat or commit fraud without being detected. The proof guarantees that the state transitions and computations are correct according to the protocol. As long as the proof is valid, the results are accepted as correct, maintaining the integrity and security of the rollup.
Because ZK proofs are succinct and don’t require full transaction data to be stored or processed onchain, ZK rollups can handle a higher throughput of transactions compared to processing them directly on the main chain. This scalability is achieved without compromising the security guarantees provided by the main chain.
ZK technology cannot be used to verify any computational problem directly. Rather, the problem has to be converted into the right ‘form’. Normal program logic has to be represented by a group of polynomials.
You can imagine how complicated this is, and rewriting EVM (or any virtual machine) to be able to operate via these polynomials is as complex as it sounds. That’s why creating a fully-EVM compatible zkEVM is hard, and why there’s such a wide range of zkEVM implementations happening (from fully Ethereum-equivalent to high-level-language equivalent ones). This affects applicability of industry infrastructure and the extent to which smart contract code of existing projects has to be changed to run on the chain.
So, now that we understand the basics of ZK technology, it’s time to address the conundrum of ZK rollups’ lackluster takeup.
We’ve seen some successful implementations: namely, ZKsync, Scroll, Starknet. It marks a success in itself that these function at this point, with no significant hacks so far (only a couple of halts). However, optimistic rollups are still dominating ZKs, the latter holding approximately 10% of the market only by TVL and user activity. L2beat.com’s proprietary statistic, scaling factor for ZK rollups, is 2.3 times over the last 90 days. This means that only two times more transactions are settled by Ethereum thanks to these rollups. This figure is 9 times for optimistic rollups, which means optimistic rollups are being more widely used as the preferred Ethereum scaling solution.
So what is really holding ZK rollups back? We see three possible explanations:
The tech behind ZKs simply hasn't garnered as much trust as optimistic rollups. It seems tech-savvy whales are yet to move their capital to ZK rollups. Most likely, they’re waiting for ZK rollups to be battle tested and have all their bugs fixed. For example, since verifiers (that are not yet open-sourced) form such a major part of the stack, the industry can’t check and verify them.
This illustrates how making the zkEVM (or any zkVM) provable is not a straightforward task. Veridise, a security audit firm specializing in ZK audits, claims that ZK security is simply more challenging. The firm's ZK audits revealed a twice-increased chance of bugs compared to the rest of their audits. This is understandable given the complexity and rapid development of ZK technology.
Plus, the smart contracts for Type 4s (Starknet & zkSync) are not just forks of existing Solidity contracts, so they have to be written from scratch, and investors have less trust in them. Battle-tested contracts are so sought after that Starknet, initially a Type-4 ZK rollup, is adding an EVM implementation Kakarot to become a Type-3 rollup (which will support existing Solidity contracts). Full EVM and Solidity support seems to be crucial for developer adoption.
Optimistic L2s were launched three to four years ahead of their ZK competitors. And once users moved to these solutions they stayed, without seeing significant incentives to move to new ZK chains. Fees on optimistic rollups have stayed at the same level as ZKs, even though the promised fee reduction by ZKs is 10 times that of optimistic rollups. ZK rollups still lack the mass adoption needed to bring millions of users and billions of transactions to truly demonstrate their scaling advantage.
Also to be noted is that relative market capitalization of these chains is surprisingly low (zkSync, Taiko and Scroll are ranked 126, 342 and 344 on CoinMarketCap), largely explained by bad tokenomics. Low float with high FDV means tokens still have to undergo years of unlocks, deterring investors from buying them. Token launch timing hasn’t been great either; altcoins are now performing notoriously worse than in previous cycles, so ZK rollups have been launched to less welcoming markets than optimistic rollups one cycle ago. Indeed, since our piece on ZK rollups a year and a half ago, zkSync and Starknet have launched their tokens. Smaller market caps mean smaller treasuries to provide incentives to developers and users, so there is less liquidity and activity.
ZK technology has the potential to scale blockchains by increasing transaction throughput by several orders of magnitude, potentially up to thousands of transactions per second, depending on implementation.
The Ethereum Foundation plans to make changes to Ethereum to support ZK rollups to further improve efficiency. In the long run, ZK will actually become a major part of the L1 itself. Ethereum node clients are expected to begin experimenting with ZKs to verify Ethereum block execution on L1. We anticipate a gradual shift from clients validating Ethereum L1 blocks through direct re-execution, to most clients relying on ZK proofs for verification.
So far, ZK implementations have not introduced enough differentiation. The fees are almost the same, which doesn’t do enough to lure users away from optimistic rollups. A new technology cannot be just marginally better to convince users to switch: it must be orders of magnitude better. In the long term, once there are 100 times or 1,000 times transactions onchain, ZK tech will truly shine.
But the overarching question is whether this will occur through the current collective of ZK rollups, or whether ZK tech will be implemented into existing L2s or the base layer. The latter outcome looks increasingly likely. With growing concerns about Ethereum’s positioning and the problem of L2 interoperability, ZK integrations look set to be the key enhancement to improving the execution of the L1. Or, as the key standard that all Ethereum L2s should agree to, as explored in Justin Drake’s ‘Beam Chain’ proposal to introduce ZK execution to the base layer, or Martin Koeppelman’s proposal for 128 Ethereum-approved ZK rollups that all share the same standards.
ZKs will eventually live up to the hype, but it doesn’t look like the first movers will benefit.
That’s it! Feedback appreciated. Just hit reply. Brr! It’s cold in Tennessee. Enjoyed work and play in Asia and seeing readers at Devcon.
Dose of DeFi is written by Chris Powers, with help from Denis Suslov and Financial Content Lab. *I spend most of my time contributing to Powerhouse, an ecosystem actor for MakerDAO/Sky. Some of my compensation comes from MKR, so I’m financially incentivized for its success. All content is for informational purposes and is not intended as investment advice.
Continue reading:
The adoption of zero-knowledge (ZK) rollups – once hailed as the next big thing in blockchain scalability – has been surprisingly slow. Despite their technological promise and recent major leaps in privacy and scalability, implementation into everyday blockchain use has been slow. Below, we discuss reasons behind the slower uptake of ZK rollups compared to optimistic rollups, and ponder how the technology will integrate into DeFi and blockchains in the future.
The cave analogy: Understanding ZK basics
Zero-knowledge proofs allow someone to prove a claim without revealing the underlying information. While ZK involves some of the most advanced math in crypto, we can grasp the basics through analogies and high-school concepts.
The setup
Imagine a cave with two paths – path A and path B – that eventually meet at a locked door inside. The door can only be unlocked with a secret code. You claim to know this code.
Prover (you): Knows the secret code to unlock the door.
Verifier: Wants to confirm that you know the code without learning it themselves.
The process:
You and the verifier stand outside the cave. You enter the cave, choosing either path A or B. The verifier stands outside and doesn’t see which path you take.
Challenge: Once you’re inside, the verifier shouts which path they want you to come out from.
Response: If you take path A and the verifier asks you to come out from path A, you simply exit from path A. If you take path A and the verifier asks you to come out from path B, you must use the secret code to unlock the door, walk through it, and then exit from path B.
This process is repeated multiple times. If you consistently exit through the correct path, the verifier gains confidence that you know the code. Importantly, the verifier never learns the code itself – hence, ‘zero-knowledge’.
The way the cave is built in this example (a door with a secret code and how it can influence the outcome) is very similar to how ZK systems are built.
Back to school: How do ZKs actually work?
ZK proofs can further be explained in simple terms, relying on mathematics, particularly using polynomials. These algebraic expressions – formed by the sum of any number of terms of the form cxk – are key to how ZK systems work. You may remember these from high school math:
x + 1
x2
X3+3x2+2x+1
345x335+221x334+115x333+...+65x+44
The important thing to remember as we try to understand ZKs is that polynomials can contain an unbounded number of terms. We can then understand that a single equation involving a number of polynomials can represent an infinite number of equations (read: relationships) between numbers. For example, consider the equation that includes polynomials A, B, C, and variable x: A(x) + B(x) = C(x). If this equation is true, then it’s also true that:
A(0) + B(0) = C(0)
A(1) + B(1) = C(1)
A(2) + B(2) = C(2)
A(3) + B(3) = C(3)
…
If some equation involving some polynomials solves for a randomly selected x, then it almost certainly holds true for the polynomials as a whole. So, when we look back to the cave example above, the person (verifier) can exit through the randomly required path multiple times, which is the same as an equation involving polynomials solving for a randomly required x multiple times. This in a succinct way proves that the prover holds the full amount of information, whether it’s a secret code as in the cave example, or relating to all transactions in an L2 block. For more of a detailed explanation, see this Vitalik’s article or Starknet founder Eli Ben-Sasson’s video.
These proofs are computationally expensive to create, but fast to verify. Here, it’s important to know that even though ZK is about zero leaked information, it is its speed property, and not privacy, that underpins rollups. Mathematicians and cryptographers are working on further reducing verification times.
ZK proofs
ZK rollups aggregate transactions offchain into batches, generating proofs (zk-SNARK or zk-STARK) that are used to validate batches of transactions. The aggregated proof, along with a minimal amount of data required to reconstruct the state, is submitted to the main chain (e.g., Ethereum). This proof is used to confirm that the offchain transactions were processed correctly. The main chain only needs to verify this small proof rather than re-executing every transaction, which significantly reduces the computational load and enhances scalability.
ZK proofs ensure that rollup operators cannot cheat or commit fraud without being detected. The proof guarantees that the state transitions and computations are correct according to the protocol. As long as the proof is valid, the results are accepted as correct, maintaining the integrity and security of the rollup.
Because ZK proofs are succinct and don’t require full transaction data to be stored or processed onchain, ZK rollups can handle a higher throughput of transactions compared to processing them directly on the main chain. This scalability is achieved without compromising the security guarantees provided by the main chain.
Types of zkEVMs
ZK technology cannot be used to verify any computational problem directly. Rather, the problem has to be converted into the right ‘form’. Normal program logic has to be represented by a group of polynomials.
You can imagine how complicated this is, and rewriting EVM (or any virtual machine) to be able to operate via these polynomials is as complex as it sounds. That’s why creating a fully-EVM compatible zkEVM is hard, and why there’s such a wide range of zkEVM implementations happening (from fully Ethereum-equivalent to high-level-language equivalent ones). This affects applicability of industry infrastructure and the extent to which smart contract code of existing projects has to be changed to run on the chain.
Why are ZKs underperforming optimistic rollups?
So, now that we understand the basics of ZK technology, it’s time to address the conundrum of ZK rollups’ lackluster takeup.
We’ve seen some successful implementations: namely, ZKsync, Scroll, Starknet. It marks a success in itself that these function at this point, with no significant hacks so far (only a couple of halts). However, optimistic rollups are still dominating ZKs, the latter holding approximately 10% of the market only by TVL and user activity. L2beat.com’s proprietary statistic, scaling factor for ZK rollups, is 2.3 times over the last 90 days. This means that only two times more transactions are settled by Ethereum thanks to these rollups. This figure is 9 times for optimistic rollups, which means optimistic rollups are being more widely used as the preferred Ethereum scaling solution.
So what is really holding ZK rollups back? We see three possible explanations:
1. Untested tech
The tech behind ZKs simply hasn't garnered as much trust as optimistic rollups. It seems tech-savvy whales are yet to move their capital to ZK rollups. Most likely, they’re waiting for ZK rollups to be battle tested and have all their bugs fixed. For example, since verifiers (that are not yet open-sourced) form such a major part of the stack, the industry can’t check and verify them.
This illustrates how making the zkEVM (or any zkVM) provable is not a straightforward task. Veridise, a security audit firm specializing in ZK audits, claims that ZK security is simply more challenging. The firm's ZK audits revealed a twice-increased chance of bugs compared to the rest of their audits. This is understandable given the complexity and rapid development of ZK technology.
Plus, the smart contracts for Type 4s (Starknet & zkSync) are not just forks of existing Solidity contracts, so they have to be written from scratch, and investors have less trust in them. Battle-tested contracts are so sought after that Starknet, initially a Type-4 ZK rollup, is adding an EVM implementation Kakarot to become a Type-3 rollup (which will support existing Solidity contracts). Full EVM and Solidity support seems to be crucial for developer adoption.
2. User stickiness
Optimistic L2s were launched three to four years ahead of their ZK competitors. And once users moved to these solutions they stayed, without seeing significant incentives to move to new ZK chains. Fees on optimistic rollups have stayed at the same level as ZKs, even though the promised fee reduction by ZKs is 10 times that of optimistic rollups. ZK rollups still lack the mass adoption needed to bring millions of users and billions of transactions to truly demonstrate their scaling advantage.
3. Tokenomics and economics
Also to be noted is that relative market capitalization of these chains is surprisingly low (zkSync, Taiko and Scroll are ranked 126, 342 and 344 on CoinMarketCap), largely explained by bad tokenomics. Low float with high FDV means tokens still have to undergo years of unlocks, deterring investors from buying them. Token launch timing hasn’t been great either; altcoins are now performing notoriously worse than in previous cycles, so ZK rollups have been launched to less welcoming markets than optimistic rollups one cycle ago. Indeed, since our piece on ZK rollups a year and a half ago, zkSync and Starknet have launched their tokens. Smaller market caps mean smaller treasuries to provide incentives to developers and users, so there is less liquidity and activity.
The future of ZK technology: Still bright
ZK technology has the potential to scale blockchains by increasing transaction throughput by several orders of magnitude, potentially up to thousands of transactions per second, depending on implementation.
The Ethereum Foundation plans to make changes to Ethereum to support ZK rollups to further improve efficiency. In the long run, ZK will actually become a major part of the L1 itself. Ethereum node clients are expected to begin experimenting with ZKs to verify Ethereum block execution on L1. We anticipate a gradual shift from clients validating Ethereum L1 blocks through direct re-execution, to most clients relying on ZK proofs for verification.
So far, ZK implementations have not introduced enough differentiation. The fees are almost the same, which doesn’t do enough to lure users away from optimistic rollups. A new technology cannot be just marginally better to convince users to switch: it must be orders of magnitude better. In the long term, once there are 100 times or 1,000 times transactions onchain, ZK tech will truly shine.
But the overarching question is whether this will occur through the current collective of ZK rollups, or whether ZK tech will be implemented into existing L2s or the base layer. The latter outcome looks increasingly likely. With growing concerns about Ethereum’s positioning and the problem of L2 interoperability, ZK integrations look set to be the key enhancement to improving the execution of the L1. Or, as the key standard that all Ethereum L2s should agree to, as explored in Justin Drake’s ‘Beam Chain’ proposal to introduce ZK execution to the base layer, or Martin Koeppelman’s proposal for 128 Ethereum-approved ZK rollups that all share the same standards.
ZKs will eventually live up to the hype, but it doesn’t look like the first movers will benefit.
Odds & Ends
Safe launches new L2, Safenet for cross-chain execution Link
Flashbots and Beaverbuild launch BuilderNet Link
Sky Ecosystem Risk & Analytics Dashboard Link
Decentralised.co launches SnetientMarketCap as dashboard for AI agents Link
Implications of Tornado Cash’s victory in court Link
Hyperliquid airdrop praised for wide distribution and strong performance Link
DeFi TVL hits an all-time high over $200bn Link
Ethena continues USDe growth with new partnership Link
Thoughts & Prognostications
What I would love to see in a wallet [Vitalik]
Ethereum’s North Star [Jon Charbonneau/DBA]
The return of the basis trade [Charlie/Parsec]
Understanding staking yields on Ethereum and Solana [Tanay Ved & Matías Andrade/CoinMetrics]
Memes tokens and consent [Dan Finlay/Metamask]
The Opinionated Application: The App-Infra Thesis, an ode to customisation [Rain&Coffee/Maven11]
The 5 levels of secure hardware [Georgios Konstantopoulos/Paradigm]
That’s it! Feedback appreciated. Just hit reply. Brr! It’s cold in Tennessee. Enjoyed work and play in Asia and seeing readers at Devcon.
Dose of DeFi is written by Chris Powers, with help from Denis Suslov and Financial Content Lab. *I spend most of my time contributing to Powerhouse, an ecosystem actor for MakerDAO/Sky. Some of my compensation comes from MKR, so I’m financially incentivized for its success. All content is for informational purposes and is not intended as investment advice.
Continue reading:
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
