Which Scaling Solution is Better?
ZK Rollups on Ethereum vs ZK Compression on Solana
This article is explores the scaling solutions touching on popular blockchains, Ethereum and Solana, to understand their key differences, use cases and approaches. Both the blockchains have used zero-knowledge proofs (ZKPs) to enhance blockchain scalability. These solutions address and improves the current state of blockchain trilemma. Check out one of my earlier article of the following video to understand blockchain trilemma.
Table of contents
Intro to zk Rollups on Ethereum
Intro to zk Compression on Solana?
Comparison: key differences
Use cases: currently used and potential for both
Conclusion: my perspective on the approaches of the technology used by both blockchains.
Ethereum is one of the most popular and utilized blockchain in the crypto ecosystem. However, with number of people using the network, it has reached certain limitations wrt capacity. This is the reason the gas fee is way higher on Ethereum blockchain compared to networks like Solana, Sui and others. The community addresses this issue by increasing the speed (faster finality) and transaction throughput (high number of transactions per second).
Two different approaches can be followed to provide solutions for these scalability challenges:
On-Chain Scaling
Sharding was chosen as a solution to scale Ethereum operations for longer time. Implementing sharding is basically splitting the database of the Ethereum network into discrete pieces (shards) which are to be verified by subsets of validators of the network.
Off-Chain Scaling
On the other hand, there was rapid development on the second approach which is layer 2 rollups like optimistic rollups, zero-knowledge rollups or state channels. For beginners, layer 2 is a term used for solutions designed to scale the process of transactions of layer 1 networks.
There are other solutions which involves the creation of new chains in forms that derive security layer from Ethereum network. Solutions like sidechains, validiums, or plasma chains.
Rollups
Rollups perform transactions off-chain (outside layer 1) and the data is posted on layer 1 where consensus is reached. In this, there are two types:
Optimistic rollups: In this approach, the process of transactions are moved off-chain by maintaining computation and state storage off-chain. This process happens outside Ethereum network but posts transaction data to mainnet as “calldata” or in blobs.
Zero-knowledge rollups: This approach is similar to optimistic rollups where it bundles transactions and processes off-chain (computation and state-storage) but it posts minimal summary data to mainnet.
The difference is that with optimistic rollups approach they submit transaction data on-chain and assuming off-chain transactions are valid until anyone challenges the results of a rollup transaction by computing a fraud proof. Whereas with zk rollups, must submit a validity proof for verification to finalize transactions on Ethereum.
Now that we understand the concept of it, let’s dive into the how ZK-Rollups work and its utility cases on Ethereum network.
ZK rollups on Ethereum
Zero-knowledge rollups are scaling solutions on Ethereum blockchain. zk rollups increases throughput of Ethereum blockchain by moving computation and state-storage off-chain.
These rollups are maintained by a smart contract deployed on the Ethereum network. You do not experience any delay in moving funds from ZK-rollups to Ethereum because exit transactions gets executed once the contract gets verified (validity proof).
ZK-rollups use compression techniques to reduce transaction data. Instead of representing accounts via address, it is presented as index thereby reducing the data. This reduces the need for data storage on the mainnet thereby reducing costs/fees for users and increases the transaction throughput.
How do ZK rollups work?
Before getting on to it, let’s understand the basic architecture of ZK-rollups. The architecture primarily has two components:
On-chain contracts: ZK-rollup protocol is controlled by smart contracts on Ethereum network. This contract includes storing the block produced by rollup, tracking the deposits, and monitoring the state updates. On the other hand, the verifier contract verifies zero-knowledge proofs that gets submitted as validity proof. Therefore. zk-rollups acts as layer 2 on top of base layer, Ethereum.
Off-chain virtual machine (VM): As discussed, transaction execution and state storage happens off-chain i.e., on a separate virtual machine. Think of this machine as an execution environment for transaction on the ZK-rollup and its servers as layer 2. Ultimately, the validity proofs verified on the mainnet guarantees the accuracy of state transitions in the off-chain VM.
Summarizing these points, ZK-rollups are hybrid scaling solutions which carries some part of process off-chain and derives security of it from the Ethereum network.
How the transactions work?
When users submit/sign transactions on ZK-rollup protocol, these transactions are sent to L2 operators for processing in the next batch. There are two different cases on how the this works:
Centralized Sequencer Model
In this model, once ZK-rollup contract is deployed and smart contract on L1 handles the state and verification of transaction in the ZK-rollup, the transactions are collected by a centralized entity. This entity is responsible for collecting transactions, creating batches and submitting them to the L1 rollup contract.
Post this, the sequencer submits batches of transactions to the L1 rollup contract, which are then verified and finalized on-chain.
Proof-of-Stake Validator Set Model
The process is very similar, but the collection of transactions is tasked by a set of validators who have deposited stake in the rollup contract. Once the validator from the set is chosen (based on stake or random selection) to create the next batch of transactions.
The selected validator submits batches of transaction to the L1 rollup contract for verification nd finality.
The difference is Proof-of-Stake Validator Set model is decentralized and it create a mechanism for validators to act with honesty because their stakes can be slashed if they acted otherwise.
Therefore the process involves:
Batching Transactions - Where multiple transactions are basketed into a single batch.
Sequencer collecting user transactions - A centralized entity or a sequencer is chosen from a set to prove and verify the bundled transactions.
L2 Virtual Machines (VMs) - Sequencer/centralized entity verifies these transactions off-chain and submits proof of validity to the Ethereum network. These proofs can be in the form of a ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) or ZK-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge).
Updating the L2 State: The layer 2 gets updated with the verified transaction data.
Sending New State Root and ZKP/Fraud Proof to Ethereum - Transactions once verified, are submitted to Ethereum mainnet with validity proofs which are then challenged if needed.
The difference between ZK-SNARK and ZK-STARK is the underlying construction, setup requirements, scalability, transparency and resilience against quantum computing.
ZK-SNARKs requires a trusted setup but offer smaller proofs and efficient verification. They are widely used in application which prioritizes efficiency. This form requires management over security against quantum computers which sometimes can be compromised.
On the other hand, ZK-STARK does need a require a trusted setup, however provides scalability benefits and are potentially better version of ZK-SNARKs with regards to security against future quantum computing threats. These are typically used in applications where there is a need for high security is need in proving and verifying larger computation efficiency. despite the trade-off of larger proof sizes.
This process streamlines and allows ZK rollups to handle high volume transactions with better efficiency, speed and cost on Ethereum network.
Check out the below video for more easier explanation -
Let’s look at upsides and downsides of ZK Rollups.
First let’s start with benefits:
Validity proofs ensure accuracy of off-chain verification and prevents operators from executing inaccurate state transitions.
Batching transactions and verifying them once validity proofs are verified on L1 enabling faster transaction finality.
Rollups relies on trustless cryptographic mechanisms for security unlike optimistic rollups which rely on the honesty of actors.
As the transaction on-chain data is compressed by processing and storing data off-chain, it comes with low fees and high throughput, providing cost-effective solution.
Downsides:
In few instances, the cost associated with computing and verifying validity proofs can increase fees (large proofs) for users using rollups.
Building EVM-compatible ZK rollups is difficult due to the complexity of zero-knowledge technology.
An issue with the opportunity for centralized control as producing validity proofs require specialized hardware. This can lead to influence of the transactions order.
The above challenges also leads to lack of participants due to hardware requirements which can increase the risk of malicious operators. This opens problems like censoring users and freezing network.
Systems like ZK-SNARKS require trusted setup. If not managed properly it could lead to compromise on security.
Use Cases of ZK Rollups
ZK rollups can be leveraged by DeFi protocols to reduce transaction fees and improve processing time.
Minting and trading NFTs with ZK rollups can be achieved at lower cost compared to normal state. This will open doors for adoption at scale.
Some of the projects like Starknet, Polygon zkEVM, zkSync and Aztec are levergaing ZK rollups to improve scalability state, reduce costs and building privacy-focused zk rollups on Ethereum.
ZK Compression on Solana - Account Compression!!
In the month of June 2024, bunch of Solana-based developers of Light Protocol and Helius Labs introduced a new layer 1 scaling solution called ZK Compression. Compression in simple terms is
ZK Compression is a new primitive built on Solana network which allows developers to building application at scale. This is a huge technology upgrade which allows developers and users to opt to compress their on-chain state, reducing costs drastically while maintaining security, performance and composability of Solana base layer (L1).
The core feature of this technology and its impact on Solana L1 is:
State Cost Reduction: As the technology securely stores state on cheaper ledger space instead of the expensive “account” space, it allows apps to scale to million users at a cheaper cost.
L1 Security and Performance: The performance and security remains as it is. Solana is one of the high performance blockchain with a capacity of 65,000 + throughput per second maintaining the consensus of the blockchain.
Composable: Even with ZK Compression, Solana programs can mix and match between compressed and regular on-chain data, allowing interaction with multiple programs, accounts and compressed accounts.
Why does Solana need ZK Compression? How do it work?
To get into why Solana needs ZK Compression, let’s get a brief understanding about Merkle tree.
Merkle Tree
Merkle tree, also known as a hash tree, is a binary tree structure where each leaf node contains the has of a data block, and each non-leaf node contains the hash of its child nodes’ hashes. This structure allows for efficient and secure verification of large data sets.
In blockchain, it is useful to store transactions in blocks efficiently, enabling lightweight clients to verify transactions without downloading the entire blockchain and facilitates quick comparisons of large datasets. Merkle trees are crucial in ZK Compression techniques, allowing complex states to be represented by a single root hash while maintaining verifiability of individual elements.
Solana boasts with high throughput facing unique challenges in the ecosystem - managing state bloat. State bloat occurs when the blockchain’s data size increases beyond capacity. This happens when there are too many transactions or unnecessary information added to the blockchain, making it larger and harder to manage. This sometimes can slowdown the system and increases the cost for storing and processing data.
Solana addresses this issue by introducing ZK Compression. At its core, Solana uses system of Accounts which holds both executable program code and program state. This core design is a fundamental data structure on the blockchain.
Executable Program Code is the actual code that can be executed on Solana blockchain. These programs are typical smart contracts that perform specific tasks.
Program State is the data associated with that account. The data includes variables, data structures, and other information that program needs to operate or needs to be recorded.
On the other hand, there are two types of storage on Solana which can be termed as Active accounts and Inactive Accounts.
Active accounts does require a rent in SOL, proportional to the data stored, which would be fully refunded upon account closure.
Inactive accounts are stored in Solana’s ledger (on-chain storage), which is cheaper and not directly accessible by programs. The ledger is cheaper because validators do not need data from this space to validate new transactions, allowing them to prune it. (Similar to Ethereum’s Blob layer).
To give you better understanding, if you want to create 10,000 NFTs, you need to create these accounts where each NFT is one account. Creating these accounts was not cheap, if you do it 10,000 time the cost adds up. More accounts lead to more rent to store data.
ZK Compression on Solana works by storing multiple accounts as leaves of a Merkle tree. Instead of storing all data on-chain, only Merkle root has is stored on Solana’s ledger account space. This root serves as a cryptographic commitment to all the compressed accounts’ states. The raw data is then stored on the ledger, which is significantly cheaper and does not require active maintenance by validators.
The compression comes into play as it bundles multiple accounts to be represented by a single on-chain Merkle root. This design reduces the expenses of on-chain storage.
Each compressed account has functions as a leaf in the state tree, thereby representing segments of the compressed account data.
So with the same example that was used with NFTs, with compression it lets to compress 10,000 accounts into 1 account and store the data in a cheaper place on Solana’s ledger. The cost would be 10,000x lesser. This number is huge!!
But this comes with a problem. The problem is, when a transaction involves a compressed account, Solana’s L1 cannot directly access or verify the account details. To address this issue, the system employs ZKPs.
For transactions involving compressed accounts, users or applications must provide:
The relevant account details
A ZK Proof that verifies these details are consistent with the corresponding Merkle leaf
The ZK Proof allows Solana’s L1 to confirm the validity of the account data without needing to store or process the entire dataset. The L1 checks if the ZKP is valid and then performs the necessary computations on the provided accounts.
When account states are modified, the Light Protocol (developed in collaboration with Helius Labs) conducts several crucial steps:
Verifies the validity proof
Removes the old account leaf from the Merkle tree
Updates the leaf with the new state
Generates a new Merkle root representing the updated state
This process ensures that any changes to compressed accounts are accurately reflected in the overall state root, maintaining the integrity of the entire system.
To facilitate this process, Solana employs an open-source indexer called Photon. This indexer reads the ledger storage and provides indexing and validity proofs to RPC (Remote Procedure Call) providers. When users interact with Solana applications, either they or the application connect to Photon to obtain necessary proofs.
The beauty is it maintains Solana’s high performance while significantly reducing the storage burden.
Unlike other Layer 2 solutions on blockchains like Ethereum, Solana’s ZK Compression doesn’t require off-chain execution or asset bridging.
This preserves the liquidity of Solana state and doesn’t require separate sequencers like Ethereum.
Check out few open questions asked about this upgrade:
For better context, the role of RPC provider is:
Indexing and Parsing: The RPC node organizes and interprets the compressed state and transaction data. This approach facilitates easier interaction for clients, enabling them to read and construct transactions that interact seamlessly with the compressed data.
ZK Compression RPC API: Helius uses a ZK Compression RPC API through its Photon indexer. This API provides access to read the compressed state.
Database Flexibility: Photon, supported by Helius, offers versatile database backed such as Postgres and SQLite. By default, it utilizes an efficient in-memory SQLite configuration. Users also have the flexibility to specify alternative database backends and perform migrations as necessary, ensuring robust adaptability and scalability.
To Summarize, ZK Compression optimizes on-chain account storage on Solana network by storing state roots (basically hashes representing compressed accounts) on-chain.
The compressed account data itself is stored off-chain in the Solana ledger, enabling efficient retrieval and verification when needed.
Key Differences
Let me breakdown on the key differences on each of its process.
Operation:
zk-Rollups (Ethereum): Operate as a Layer 2 solution, processing transactions off-chain.
ZK Compression (Solana): Implemented directly on Layer 1, compressing data on the main blockchain.
Transaction Processing:
zk-Rollups: Execute transactions off-chain, then submit proofs to Ethereum.
ZK Compression: Process transactions on-chain, using compression for efficient state storage.
Data Storage:
zk-Rollups: Store transaction data off-chain, with only proofs submitted to Ethereum.
ZK Compression: Store compressed data on-chain in Solana's cheaper ledger space.
Scalability Approach:
zk-Rollups: Scale by moving computation off-chain.
ZK Compression: Scale by optimizing on-chain storage and processing.
Network Architecture:
zk-Rollups: Require separate Layer 2 infrastructure.
ZK Compression: Integrated into Solana's existing Layer 1 architecture.
Composability:
zk-Rollups: May face challenges with cross-layer composability.
ZK Compression: Maintains full Layer 1 composability.
Implementation Complexity:
zk-Rollups: More complex, requiring bridging between L1 and L2.
ZK Compression: Relatively simpler, built into Solana's core protocol.
Primary Focus:
zk-Rollups: Primarily address transaction throughput and gas fees.
ZK Compression: Primarily addresses state bloat and storage costs.
Use Cases
Decentralized Social Platforms: This solves the problem of immense amount of data generated on these platforms. ZK Compression can compress user-generated content on-chain, reducing costs while maintaining data availability and integrity.
Microtransactions and NFTs: ZK Compressions could make microtransaction more cheaper and effective which could bring new possibilities for NFTs and SocialFi sectors. Drip comes into the picture in the Solana ecosystem that could potentially use ZK Compressions for tipping creators or paying for some kind of services.
DePIN: Projects like Helium and Hivemapper could utilize this technology to enable millions of physical devices to interact with blockchain effectively and efficiently. The reduction of the cost is insane and it opens many doors in this space.
Supply Chain: Tracking goods across a supply chain involves storing large amounts of data regarding the provenance, condition and location of goods. ZK Compression has the possibility to play around and enable blockchain implementation in this space.
Healthcare Data Management: As healthcare systems require secure, efficient and compliant ways to store and access patient records, ZK Compression can enable the storage of encrypted, compressed medical records directly on the blockchain, ensuring privacy and storage costs while allowing authorized access to comprehensive patient histories.
Securing Data Recording Sectors: Gaming, Document management systems like academia records, digital IDs, Real Estate records, and other similar use cases can leverage ZK Compressions on Solana for securing property records (tamper-proof), transaction histories and ownership details across various sectors.
Conclusion - My Thoughts
The crypto landscape has continuously been evolving with new upgrades and emerging with innovative projects. These upgrades may seem very new or not exciting when looked at the current state of adoption vs the potential adoption. However, these upgrades addresses key challenges like transaction speed, efficiency and security of the state for it to scale.
The core concept of ZKP technique is to enable the verification of any statement without disclosing the details. The implementation of this concept is different between Ethereum and Solana. While ZK Rollups focuses on off-chain scaling to reduce cost and increase throughput, ZK Compression targets to improve on-chain storage efficiency.
Although there was debate by Ethereum folks calling ZK Compression as layer 2, check out Anatoly’s comments:
My raw thought is ZK Compression is a different ball game that Solana community is playing compared to ZK Rollups that Ethereum state wants to achieve. Both the blockchains are striving to provide the most efficient, scalable and cheaper blockchain for app developers and users.
ZK Compression wins in my opinion with its unique design and simplistic approach in scaling compared to ZK Rollups. I’m excited on the apps and features that would be built around this technology once it’s live on mainnet.
Developers
Tech folks if you have read this article, please find the document for detailed information on this technology.
References
Other sources are hyperlinked throughout the article
If you have reading this, you have reached/read to the end. Please feel free to share your feedback/opinions on X @abhijith_psr, would love to chat! If you found this article even a bit insightful, please share it, your support means, awareness for this ecosystem.