# Is ZK enabling Ethereum to eat Solana’s lunch?

Source: https://voynichsadventure.substack.com/p/is-zk-enabling-ethereum-to-eat-solanas
Kiwi News: https://news.kiwistand.com/stories/Is-ZK-enabling-Ethereum-to-eat-Solanas-lunch?index=0x66741f8295d9fa68fac5728623cd6b51cc7919ea1fa0c917dc83922b4f0985209315c04a
Submitted by auditless.eth on 2024-06-20 UTC, 3 upvotes, 0 comments

## Summary

Technically, zero-knowledge proofs and co-processors significantly expand Ethereum's design space toward what Solana offers, but the article argues that Ethereum's social consensus challenges keep key features like shared liquidity and pre-confirmations a long way off. It says ZK compute's slowdown factor has fallen from 5-6 to 3-4, and that proof creation time dropped 400x between 2017 and 2022, to 170 milliseconds. It cites RISC Zero's Bonsai, used by Eclipse and Citrea, and Axiom as leading ZK co-processor examples. It also notes that Ethereum supports only the BN-254 elliptic curve cost-effectively, and that roll-ups with their own tokens and brands may be reluctant to share state.

## Article

Setting the scene

In the last years, we have seen how Solana has continued to expand at the cost of (primarily) Ethereum. Driven by marvel engineering, Solana has brought scalability, instant settlement and low transaction fees to 1.5m MAU. Sure, RAM requirements increased 4x since 2020 making it impossible for non-professional actors to run nodes, yet the results have been highly beneficial for users. 65k TPS now, 600k TPS once Firedancer hits - a true world computer. Ethereum on the other hand still battles with expensive L2 transactions during high-throughput seasons, slow finality, centralisation risks (through L2 sequencers) and fragmented liquidity. Framing it like this makes it sound like Ethereum has lost its way.

We all know how we got here. By focusing on maximal decentralisation, Ethereum limited the network’s maximal computation to the computational throughput of the slowest node. This made it impossible for complex apps to be built due to the limited computation per block, the lack of persistent file storage and restricted memory on smart contracts. Something, you cannot change without increasing the computational baseline requirements. After all, computation needs to happen somewhere, either on the Execution or the DA layer. To solve its restrictions, Ethereum has drastically shifted away from a monolithic all-in-one solution towards a modular future as a pure settlement layer for ZKPs. Computation is outsourced to (centralized) actors and ZKPs are used to prove the correct computation. Outsourced, verifiable computation expands Ethereum’s throughput and design possibilities. But could it be the case that ZKPs are enabling Ethereum to eat Solana’s lunch?

The tech state of ZKP

ZK proving systems have made enormous progress in the last couple of years. The slowdown magnitude of ZK computation versus traditional computation has decreased from a factor of 5-6 to a slowdown magnitude of 3-4. This means that ZK compute is currently 1,000 to 10,000 computationally more expensive than traditional compute. As we have moved towards a slowdown magnitude 4-5, it has become economically feasible to create ZK roll-ups. With specialized HW (like this SNARK proving ASIC), we are able to further reduce the cost of computation down to a slowdown magnitude of <3. This means In USD terms that the average market clearing price per proof is expected to fall by 50%. Even today, a tx on Scroll (with a validity proof) is 50% cheaper than on Optimism (without a fraud proof). From a speed perspective, ZKPs have also made significant progress between 2017 - 2022: Proof creation time has decreased by 400x (to 170 milliseconds), proof size has fallen by 13x (to ~1.5MB), while proof verification time has decreased by 30x (to <1 second). With quantum computing, all of this is further expected to fall.

ZKPs are expanding Ethereum’s design space

As costs of ZK systems continue to fall, computational proof use cases have expanded significantly. We have seen an increasing number of new applications & protocols, whose ZKPs settle on Ethereum. The main use cases are Scale (i.e.: Roll-ups), Privacy (i.e.: privacy protocols) and Oracles (i.e.: historical data access, off-chain compute).

There are two ways to offload compute from Ethereum - Roll-ups and Co-processors. While Roll-ups maintain a fully partitioned state different from the base chain, Co-processors do not maintain any state themselves. Co-processors act like a Web3 version of AWS Lambda, where users send a computing task before receiving the result with a proof of computation. While Roll-ups use ZKPs to compress and verify transaction data, thus increasing throughput of the overall system, Co-processors only use the verifiability property of ZKP, basically giving applications the ability to do complex one-off tasks in a verifiable way. While Co-Processors can also be implemented using Trusted Execution Environments (TEEs), the two leading examples, RISC Zero and Axiom, rely on ZKs.

Axiom uses co-processors in the domain of off-chain historical state, enabling smart contracts to query its off-chain processors on-chain to do a combination of (historic) data reads and verified compute over that data. This increases the functionality of dApps, allowing for Objective Slashing Conditions or ML-based Dynamic DeFi.

RISC Zero is a “more” general co-processor allowing on-chain compute to be moved off-chain. Their flagship product Bonsai allows anyone to access permissionless off-chain verifiable compute and is currently being used by Eclipse (Solana VM settling on Ethereum), and Citrea (EVM-compatible Bitcoin ZK Rollup) and explored by Optimism (to enable validity proofs instead of fraud proofs).

Taking a step back, it becomes clear that Co-processors/ZK expand the design space of Ethereum’s on-chain applications, which were previously constrained by limited computation and a lack of storage. Thereby, Co-processors and ZKPs also increase the overall design space of Ethereum and its functionality. Recent examples include Ethereum L2s LayerN, which uses Co-processors to achieve 100k TPS, and =nil;, relying on zkSharding to achieve up to 60k TPS.

Suddenly, things that have only been possible on high-throughput chains like Solana, SEI, Aptos and Sui, have the possibility to be built in the Ethereum design space. This is possible as compute is increasingly out-sourced, yet proven on top of Ethereum. This means, as Ethereum is becoming a settlement layer (for proofs), its design and function possibilities are significantly increasing.

Going forward, as design constraints slowly but surely disappear, why would developers choose to build on fast-throughput chains rather than on Ethereum? Especially now as the Ethereum community is (finally) conceptualizing (decently) concrete plans to achieve shared liquidity and pre-confirmations? Well, there are still many obstacles that prohibit Ethereum to offer a design space as wide as Solana’s.

Ethereum’s unfulfilled potential?

Ideas are cheap, execution is everything. While Ethereum always had revolutionary ideas, execution has always taken its time. Which specific ZK challenges does Ethereum need to solve to offer a design space as wide as Solana’s?

Verification challenges: Ethereum was not originally designed with ZKPs or validity proofs in mind, making it a slow and expensive verification layer. As new proving systems emerge, integrating them into Ethereum is highly challenging and costly. Concretely, only the BN-254 elliptic curve is supported cost-effectively. Even minor changes, like migrating to a more secure curve like BLS12-381, are complex tasks in Ethereum. To counter this, we have seen many startups that are aiming to become an external (Hylé) or internal verification layer (Aligned Layer). It does not stop here - In order to achieve shared liquidity, Ethereum would be required to run real-time proving/verification, posing additional tech challenges.

Proving challenges: The past years have led to an emergence of various new proving systems, each with their own intricacies. Protocols and applications aim to optimize for their requirements, leading to a variety of proving systems out there, with only the minority being upgradeable. In order to compose various ZKPs from different parties, we have seen the emergence of Universal ZK Proof Aggregation services like Nebra.

Even when solving technical ZK challenges, which would allow for synchronous composability and shared liquidity, social alignment challenges across various roll-ups remain. Considering that every roll-up has its own brand, culture, tech, incentives, and their own token, why would they give all of this up just to achieve universal synchronous composability (a shared state and shared liquidity)? And even if this really happens, how long would it really take? As devs, why wait another couple of years if Solana offers synchronous composability immediately?

So are ZKs enabling Ethereum to rival Solana’s design space? From a technical perspective yes, ZKs and Co-processors significantly expand the design space of Ethereum. However, Ethereum’s key challenges - especially on the social consensus side - continue to exist. Concludingly, even though from a technical perspective Ethereum is slowly creating a design space that encompasses Solana’s design space, key innovation (shared liquidity and pre-confirmations) are still a long way out due to Ethereum’s social consensus challenges.