ZK Rollups on Ethereum and ZK Compression on Solana Head-to-Head
Choosing the Right Blockchain for Your Needs
Table of Contents:
1. INTRODUCTION
2. Zero-Knowledge Proofs (ZKPs)
3. zk-Rollups (Zero-knowledge rollups) on Ethereum
4. On Solana, Everything is an Account
5. zk Compression on Solana
6. TL;DR Key Differences of zk-Rollup and zk Compression
7. Use Cases of ZK Compression on Solana
8. My Humble Opinion
OVERVIEW
In this article, I’ll explore zk-Rollups on Ethereum and zk Compression on Solana and their key differences, use cases, etc. — two innovations leveraging zero-knowledge proofs (ZKPs) to enhance blockchain scalability. These solutions address the blockchain trilemma by increasing transaction throughput and improving data management, all while upholding the core principles of blockchain technology. I’m working hard on this project, I hope to achieve my goal of having a balanced comparison of both chains.
INTRODUCTION
Today, the crypto ecosystem is continuously evolving to tackle three primary issues (i) scalability, (ii) security, and (iii) decentralization. This is known as the “blockchain trilemma”, a term coined by one of my deeply respected persons in Crypto Vitalik Buterin, which posits that achieving all three of these attributes simultaneously is incredibly challenging.
Moreover, Blockchains like Ethereum and Solana operate on a vast, decentralized network of computers. Each transaction on the network must be validated and recorded on the blockchain, ensuring transparency and security.
However, this process creates a bottleneck (i) Limited transaction throughput — every node in the network must process every transaction, limiting the number of transactions the network can handle per second (TPS). (ii) High transaction fees — as network congestion increases, users compete for limited block space, driving up transaction fees.
Now, let’s start with a brief overview of how ZKPs address some of these challenges.
Zero-Knowledge Proofs (ZKPs)
There are various implementations of ZKPs, with each having its own trade-offs of proof size, prover time, verification time, and more. To learn more, I highly recommend Vitalik’s Blog post. The core purpose of all ZKPs is to provide a “proof of knowledge”.
What is it?
ZKPs are at the forefront of the blockchain space, primarily due to their pivotal role in “rollups.” These scaling solutions often utilize ZK-SNARKs, a specific type of ZKP known for its succinctness. Succinct proofs offer fixed size and fast verification, making them ideal for on-chain use where efficiency is paramount.
Basically, ZKPs are a cryptographic method that allows one party (the prover) to prove to another party (the verifier) that they know a specific piece of information or that a statement is true, without revealing that information itself.
In the diagram:
- Prover. Someone who knows a secret and wants to prove they know it without revealing the secret itself.
- Verifier. Someone who wants to confirm the prover knows the secret, but doesn’t need to know the secret itself.
- UI (Make a Proof). A tool that helps the prover create a special proof to show they know the secret.
- Server (Check Proof). A system that checks the proof the prover made to see if it’s valid. It can confirm the prover knows the secret without actually learning the secret.
ZKPs play a crucial role in addressing Blockchain Trilemma:
- Scalability. By enabling off-chain computation and verification, ZKPs increase throughput and transaction speed, addressing the scalability issue.
- Security. ZKPs provide a strong cryptographic guarantee that computations are done correctly, maintaining security while scaling.
- Decentralization. ZKPs enable trustless verification, meaning that anyone can verify the correctness of proof without needing to trust the party that generated it.
Okay, we already have an idea of how ZKP works now let’s try to unpack the nuance implementation of ZKP between Ethereum and Solana.
ZK-Rollups (Zero-knowledge rollups) on Ethereum
ZK-rollups bundle (or “roll up”) transactions into batches that are executed off-chain. Off-chain computation reduces the amount of data that has to be posted to the blockchain. ZK-rollup operators submit a summary of the changes required to represent all the transactions in a batch rather than sending each transaction individually. They also produce validity proofs to prove the correctness of their changes.
The ZK-rollup’s state is maintained by a “smart contract” deployed on the Ethereum network. To update this state, ZK-rollup nodes must submit a validity proof for verification. As mentioned, the validity proof is a cryptographic assurance that the state change proposed by the rollup is really the result of executing the given batch of transactions. This means that ZK-rollups only need to provide “validity proofs” to finalize transactions on Ethereum instead of posting all transaction data on-chain like optimistic rollups.
Furthermore, the Ethereum EIP-4844 upgrade, also known as Proto-Danksharding, introduced a significant change to how Layer 2 (L2) rollups interact with the Ethereum network — (i) Blobs are designed to provide a cheaper and more efficient way for L2 rollups to store transaction data on the Ethereum mainnet (ii) Each Ethereum block can now accommodate up to 6 blobs, with each blob holding 128KB of data (iii) Blobs are temporarily stored in the beacon node (part of the Ethereum consensus layer) for roughly two weeks before being pruned to manage storage requirements.
How zk-Rollups Work on Ethereum (Post EIP-4844)?
- Off-chain Execution. Transactions are processed on a separate network (the zk-Rollup).
- State Updates & Proof Generation. The zk-Rollup’s state is updated, and a zero-knowledge proof (ZKP) is created to prove the validity of these changes.
- On-chain Verification & Data Availability:
(i) ZKP Verification. The ZKP is submitted to a smart contract on Ethereum’s mainnet for verification.
(ii) Transaction Data Availability. Transaction data (or a commitment to it) is made available either:
- On-chain. Directly on Ethereum (via “blobs” introduced in EIP-4844, reducing costs compared to pre-EIP-4844 methods).
- Off-chain. With additional mechanisms to ensure data remains accessible and verifiable.
Advantages of zk-Rollups on Ethereum:
zk-Rollups on Ethereum offer a multitude of advantages, including (i) enhanced scalability through off-chain execution and (ii) batched proof verification, (iii) reduced gas fees due to lower computational load, (iv) increased security by inheriting Ethereum’s security model via ZKPs, (v) efficient compatibility with Ethereum smart contracts and infrastructure, and (vi) improved data availability through EIP-4844’s “blobs”.
Real-World Application Examples of zk Rollups on Ethereum
- Loopring is a zkRollup-based decentralized exchange (DEX) protocol that offers fast and low-cost trading with enhanced privacy. By utilizing zkRollups, Loopring can process thousands of transactions per second while maintaining the security of Ethereum.
- zkSync (Payments & Transfers) is a layer 2 scaling solution for Ethereum, utilizing zkRollups to enable fast and low-cost payments. It supports microtransactions and cross-border payments, making it an ideal solution for everyday financial transactions.
- Immutable X is a layer 2 scaling solution for NFTs, built using zkRollups. It offers a marketplace where users can create, buy, and sell NFTs with zero gas fees and instant trade confirmation.
- Aztec is a zkRollup-based protocol that enhances privacy and scalability for DeFi applications. It enables complex financial operations such as lending, borrowing, and trading with reduced gas costs and added privacy.
Some Limitations of zk-Rollups:
- Proof Generation Overhead. Creating ZKPs can be computationally intensive, leading to some latency (ie. block time is approximately 12–14 seconds on Ethereum relative to Solana’s 400 milliseconds).
- Technical barriers for users. The zk-rollup technology is quite complex, requiring specialized knowledge and expertise for development and implementation.
- Data availability concerns. zk-rollups rely on off-chain data storage, so if the data corresponding to these rollups is lost or becomes unavailable, it can impact the integrity of the network.
On Solana, Everything is an Account
All data is stored in what are referred to as “accounts”. The way data is organized on Solana resembles a key-value store, where each entry in the database is called an “account”.
Each account is identifiable by its unique address, represented as 32 bytes in the format of an Ed25519 PublicKey. You can think of the address as the unique identifier for the account.
Moreover, on Solana, storing data on the blockchain requires a “deposit”, similar to paying rent. This is because validators need to store account data on their nodes, and if there were no cost associated with creating accounts, you could overwhelm the network with endless accounts, leading to “state bloat”. This excessive data storage can strain the network’s infrastructure, slow down transaction processing, and potentially disrupt its operation.
This deposit, called “rent” a.k.a “bond”, is proportional to the amount of data you want to store. However, you get the deposit back when you’re done with the data (like getting your security deposit back when you move out of an apartment).
Think of it like this:
- Creating one NFT. You pay a small amount of rent to store the NFT’s data on the blockchain.
- Creating many NFTs (5,000 NFTs = 5,000 accounts). You need to pay more rent because you’re storing more data.
The more NFTs you create, the more “rent” you’ll need to pay. This is because each NFT or account requires storage space on the blockchain, and validators need powerful hardware to keep up with the increasing data demands. To cover the costs of this hardware, validators require developers and users to pay for this “rent.”
ZK Compression on Solana Changes this Dynamic
By compressing (or “shrinking”) the data associated with NFTs, it significantly reduces the amount of storage space required. This means validators don’t need as much expensive hardware, and they can lower the “rent” they charge to developers and users. It’s a win-win situation — developers and users pay less, and validators can still maintain a profitable and efficient network.
What is it?
This is a recent announcement and Development on Solana Collaborated with LighProtocol and Heliuslabs (not Helium) Helius.
ZK Compression is a new primitive built on Solana that enables you to build applications at scale.
Developers and users can opt to compress their on-chain state, reducing state costs by orders of magnitude while preserving the security, performance, and composability of the Solana L1 (Layer 1).
ZK and Compression Highlights:
- Compression: Only the state roots (small fingerprints of all compressed accounts) are stored in on-chain accounts. The underlying data is stored on the cheaper Solana ledger.
- ZK: The protocol uses small zero-knowledge proofs (validity proofs) to ensure the integrity of the compressed state. This is all done under the hood. You can fetch validity proofs from RPC providers that support ZK Compression.
On-Chain Accounts with ZK Compression:
(i) State Roots.
On-chain accounts primarily store state roots, which are concise cryptographic hashes summarizing the underlying compressed account data. These state roots are generated and verified within the Solana Virtual Machine (SVM) runtime, acting as unique “fingerprints” representing the entire account state.
Hence, when you perform a transaction on Solana, you specify which accounts you want to read or write.
(ii) Storage Location & State Maintenance.
State roots are stored directly on the Solana blockchain, specifically in validator node fast access memory (eg. RAM). This ensures quick access to essential information like token balances, program data, and program instructions.
On Solana, the current state of all accounts, including token balances and program data, is actively maintained by validators in their fast access memory for fast transaction processing. This state is analogous to the account data stored in Ethereum’s Merkle Patricia Trie. Due to the limited and high-performance nature of on-chain storage, it is more expensive than off-chain storage options.
(iii) Merkle Trees & Off-Chain Storage.
Due to RAM limitations, expensive costs, and the need for efficient transaction processing enabled by the SVM, the full historical transaction data is not stored directly on-chain. Instead, Solana leverages a separate storage mechanism for retaining the complete history of state transitions.
This historical state data is similar in function to the data stored in Ethereum’s archival nodes, providing a complete record of past account states and transactions. However, there’s a key difference in data retention: on Solana, this data is typically pruned after approximately three days, while on Ethereum, may retain data for two weeks or longer.
In summary:
ZK Compression optimizes on-chain account storage on Solana by storing only state roots (hashes representing compressed account data) on-chain. This significantly reduces storage costs while maintaining data integrity through the use of sparse Merkle trees and zero-knowledge proofs (ZKPs).
The compressed account data itself is stored off-chain in the Solana ledger, enabling efficient retrieval and verification when needed.
Important Note: Most validators don’t store the entire Solana ledger, but most RPC (Remote Procedure Call) providers, like Heliuslabs, do. These RPC providers maintain indexed copies of the ledger and the compressed state to facilitate client interaction.
Role of an RPC Provider (e.g., Helius):
- Indexing and Parsing. The RPC node indexes the compressed state and parse transactions, making it easier for clients to read and construct transactions that interact with the compressed data.
- ZK Compression RPC API. Helius’ Photon indexer leverages a ZK Compression RPC API to provide clients with read access to the compressed state.
- Database Backends. Photon supports both Postgres and SQLite databases, defaulting to an in-memory SQLite configuration. Users can specify alternative database backends and run migrations if needed.
TL;DR Key Differences of zk-Rollup and zk Compression
- Ethereum zk-rollups. Transactions are handled “off-chain” (on a separate L2) and only the proof is sent to the main Ethereum blockchain. Utilize ZKPs to prove the validity of bundled transactions executed off-chain. It’s like building a faster, cheaper system on top of the existing Ethereum blockchain.
- Solana zk Compression. Data compression occurs directly on the Solana Layer 1 (L1) blockchain. Utilize ZKPs to validate the consistency of off-chain state data with the on-chain Merkle root. By compressing data, Solana aims to reduce storage costs significantly, enhancing scalability and maximizing composability. Ultimately, “storing data is Cheaper” and it’s like upgrading the existing Solana blockchain to be more efficient and scalable.
Use Cases of ZK Compression on Solana
The beauty of ZK compression is that it complements Solana’s existing Layer 1 strengths. By optimizing storage and throughput on the base layer itself. It eliminates the need for complex Layer 2 solutions for many use cases. Developers can focus on building innovative applications directly on Solana, benefiting from its high throughput, low fees, and composability.
Here are some plausible use cases of zk compression:
(i) Micropayments and High-Frequency Transactions.
Applications like Drip, designed for micropayments and social tokens, could benefit from ZK compression. It would drastically reduce on-chain storage requirements for the massive number of small transactions, making them more cost-effective and sustainable on the Solana network.
(ii) Large-Scale User Bases.
Protocols like Helium (decentralized wireless networks) and Hivemapper (map-building network) aim to serve millions of users and devices. ZK compression can be crucial in managing the immense data generated by these networks without resorting to complex Layer 2 solutions.
(iii) Gaming and NFTs.
Solana’s growing gaming like Star Atlas and NFT ecosystems like Tensor and Magic Eden often involve high volumes of transactions and state updates. ZK compression could optimize storage costs for game assets, in-game items, and NFT metadata, enhancing the overall user experience.
(iv) DeFi Applications.
Decentralized finance protocols on Solana like Marinade, Kamino, and especially those involving lending, borrowing, and yield farming, can leverage ZK compression to efficiently manage transaction histories and user data. This would contribute to lower fees and faster transaction times.
For Developers to get started
Development with ZK Compression on Solana consists of two main parts:
(i) Client development (SDK). You can use SDKs in Rust and Typescript to interact with ZK Compression:
- @lightprotocol/stateless.js (TS). SDK to interact with compression programs via the ZK Compression RPC API
- @lightprotocol/compressed-token (TS). SDK to interact with the compressed token program.
- light-sdk. Rust client
(ii) On-chain program development. You can write custom programs using ZK compression in Anchor or native Rust.
First, you’ll need to ensure your machine has Rust, the Solana CLI, and Anchor installed. If you haven’t installed them, refer to this setup guide.👈
- light-system-program. The system program. It enforces the compressed account layout with ownership and sum checks and verifies the validity of your input state. Invoke it to create/write to compressed accounts and PDAs.
- light-compressed-token. A compressed token implementation built on top of ZK Compression. It enforces a SPL-compatible token layout and allows for arbitrary compression/decompression between this and the SPL standard.
- account-compression. Implements state and address trees. Used by the Light System program.
For a detailed approach head over to lightprotocol Documentation here.
My Humble Opinion
The crypto world is trying hard to solve some big problems — (i) enhancing transaction speed and (ii) efficiency, (iii) maintaining robust security, and (iv) ensuring decentralization. Ethereum and Solana, two prominent blockchain platforms, are exploring innovative solutions to address these issues.
Imagine these platforms as massive, decentralized networks of computers. Every single transaction needs to be checked and recorded by multiple participants, much like a busy highway where every vehicle needs to be inspected at multiple toll booths. This process ensures transparency and security but can lead to congestion and scalability problems.
Enter ZKPs, a powerful cryptographic tool that allows information to be verified without revealing the actual data. ZKPs (specifically ZK-SNARKs) are the backbone of two promising solutions: zk-Rollups on Ethereum and zk Compression on Solana (currently live on Testnet). Solana co-founder Anatoly Yakovenko is particularly enthusiastic about zk Compression, calling it a potential game-changer that could “reshape the fabric of society.”
While both technologies leverage ZKPs, their implementation differs. Zk-Rollups prioritize off-chain scaling, while zk Compression focuses on improving on-chain storage efficiency. The choice between them depends on the specific needs and priorities of each blockchain ecosystem.
Some folks in the Ethereum community argue that ZK Compression functions like a validity roll-up, an L2 feature, rather than a true L1 innovation. However, as Anatoly puts it “ ZK Compression shares some L2-like features, it’s unique in that it doesn’t require a separate security council, chain ID switching, governance token, or external sequencer”.
In the end, there’s “no one-size-fits-all” answer. Both zk-Rollups and zk Compression have the potential to revolutionize the crypto landscape. They could pave the way for faster, cheaper, and more scalable decentralized applications, making blockchain technology a great part of our daily lives.
References:
[1]https://www.zkcompression.com/
[2] https://ethereum.org/en/developers/docs/scaling/zk-rollups/
[3] https://x.com/aeyakovenko/status/1796569211273445619
[4] https://solana.com/docs/core/accounts
[6] https://github.com/Lightprotocol/light-protocol/blob/main/cli/README.md
[7] https://github.com/helius-labs/photon
[8] https://www.zkcompression.com/introduction/intro-to-development#on-chain-program-development
[9] https://solana.com/news/archivers---solana-s-solution-to-petabytes-of-blockchain-data-storage
[10] https://ethereum.org/en/developers/docs/nodes-and-clients/archive-nodes/
[11] https://www.youtube.com/watch?v=bkOHUYEkRuQ
[12] https://pixelplex.io/blog/overview-of-zk-rollups/
Other sources consulted are duly Hyperlinked.
Feel free to reach out to me on Twitter @Oxmarkdams with any suggestions or opinions (I value genuine feedback or critique). If you find this even slightly insightful, please share it — I’ve invested countless of refining this article, and your support means everything in helping it educate a wider audience. Props to Swen Schäferjohann at lightprotocol and Mert Mumtaz at Heliuslabs for giving their inputs indirectly. Thank you.
