Unlocking Ethereum's Performance: An Innovative Path Beyond EVM Bottlenecks
TechFlow Selected TechFlow Selected
Unlocking Ethereum's Performance: An Innovative Path Beyond EVM Bottlenecks
Can the EVM truly meet the challenges of high-performance applications?
Navigating Web3 tides with focused insightsAuthor: Siddharth Rao, IOSG Ventures
On Ethereum Virtual Machine (EVM) Performance
Every operation on the Ethereum mainnet incurs a certain amount of gas. If we were to place all the computational load required for basic applications directly on-chain, either the app would crash or users would go bankrupt.
This gave rise to Layer 2s: OPRU introduced sequencers to bundle batches of transactions and submit them to the main chain. This not only allows apps to inherit Ethereum's security but also provides users with a better experience—faster transaction submissions and lower fees. While operations become cheaper, they still rely on the native EVM as the execution layer. Similarly, ZK Rollups like Scroll and Polygon zkEVM use or plan to use EVM-based zk circuits, where zk proofs are generated for each individual transaction or batch processed on their provers. While this enables developers to build fully on-chain applications, can such systems efficiently and economically support high-performance applications?
What Are These High-Performance Applications?
Common examples include gaming, on-chain order books, Web3 social platforms, machine learning, and genomic modeling—all requiring heavy computation that remains expensive even on L2s. Another issue with EVM is its speed and efficiency in computation, which lags behind modern alternatives like SVM (Sealevel Virtual Machine).
While L3 EVMs may reduce computation costs, the structural limitations of EVM itself make it suboptimal for high-compute tasks, particularly due to its inability to handle parallel execution. Each time a new layer is added atop existing infrastructure, maintaining decentralization requires building new networks of nodes—requiring either the same number of providers scaling up, or an entirely new set of node operators (individuals or enterprises), or both.
Thus, whenever more advanced solutions emerge, existing infrastructure must be upgraded—or a new layer built on top. To solve this, we need a post-quantum secure, decentralized, trustless, high-performance computing infrastructure capable of efficiently executing quantum algorithms for decentralized applications.
Alternative L1s like Solana, Sui, and Aptos achieve parallel execution, yet due to market sentiment and liquidity shortages, they lack developer traction and do not pose a real threat to Ethereum. Trust deficits and Ethereum’s network-effect-driven moat remain monumental. So far, there has been no true "killer" for ETH/EVM. The key question here is: Why should all computation happen on-chain? Is there an equally trustless, decentralized execution system? This is what DCompute systems aim to achieve.
A DCompute infrastructure must be decentralized, post-quantum secure, and trustless—not necessarily blockchain or distributed ledger technology per se—but verifying computational results, correct state transitions, and final confirmation are critical. This is how EVM chains operate: while ensuring network security and immutability, decentralized, trustless, secure computation can be moved off-chain.
What we're largely overlooking here is data availability. This article does not ignore data availability—solutions like Celestia and EigenDA are already advancing in this direction.
1: Only Compute Outsourced
2. Outsource Both Computation and Data Availability
In Type 1, zk-rollups already do this, but they are either constrained by EVM or require developers to learn entirely new languages/instruction sets. The ideal solution should be efficient, cost-effective (in terms of resources), decentralized, private, and verifiable. ZK proofs can be built on AWS servers, but those aren’t decentralized. Solutions like Nillion and Nexus are attempting to solve general-purpose computation in a decentralized way. However, these solutions are unverifiable without ZK proofs.
Type 2 combines off-chain computation models with separate data availability layers, but computation still needs to be verified on-chain.
Let’s examine today’s partially trusted and potentially fully trustless decentralized computing models.
Alternative Computation Systems
Ethereum Off-Chain Computation Ecosystem Map
- Secure Enclave Computations / Trusted Execution Environments (TEE)
A TEE is like a special box inside a computer or smartphone. It has its own lock and key, accessible only to specific programs called trusted applications. When these trusted apps run inside the TEE, they are protected from interference by other programs—even the operating system itself.
It’s akin to a secret hideout accessible only to a few trusted friends. The most common example of secure enclaves exists in our devices—Apple’s T1 chip and Intel’s SGX—which run critical operations like FaceID within the device.
Since TEEs are isolated systems, their authentication process cannot be compromised—at least under the assumption that the hardware manufacturer is trustworthy. You might think of it as a secure door you trust because Intel or Apple built it. But there are enough sophisticated attackers (including hackers and adversarial computers) who could potentially breach this door. TEEs are not “post-quantum secure,” meaning sufficiently powerful quantum computers could break their security. As computing power grows rapidly, post-quantum security must be a core consideration when designing long-term computing and cryptographic systems.
- Secure Multi-Party Computation (SMPC)
SMPC is another well-known computational model among blockchain practitioners. In an SMPC network, the workflow generally consists of three parts:
-
Step 1: Convert input data into shares and distribute them across SMPC nodes.
-
Step 2: Perform actual computation, typically involving message exchanges between SMPC nodes. At the end of this step, each node holds a share of the output value.
-
Step 3: Send result shares to one or more result nodes, which run the LSS (Linear Secret Sharing) reconstruction algorithm to recover the final output.
Imagine an automobile production line: components (engine, doors, mirrors) are outsourced to OEMs (worker nodes), then assembled together on an assembly line (result node) to produce the final car.
Secret sharing is crucial for privacy-preserving decentralized computation. It prevents any single party from accessing the full “secret” (i.e., the input) and producing malicious outputs. SMPC may be one of the easiest and safest decentralized systems. While no fully decentralized implementation currently exists, logically, it’s feasible.
MPC providers like Sharemind offer MPC infrastructure, but these providers remain centralized. How can we ensure privacy? How can we guarantee the network (or Sharemind itself) isn’t acting maliciously? This is where zk proofs and zk-verifiable computation come into play.
- Nil Message Compute (NMC)
NMC is a new distributed computing approach developed by the Nillion team. It’s an evolution of MPC where nodes perform computations without exchanging messages during execution. They achieve this using a cryptographic primitive called One-Time Masking (OTM), which uses random numbers known as blinding factors to obscure secrets—similar to one-time pads. OTM aims to provide correctness efficiently, meaning NMC nodes don’t need to communicate at all during computation. This eliminates the scalability issues inherent in traditional SMPC.
- Zero-Knowledge Verifiable Computation
ZK verifiable computation generates zero-knowledge proofs for a given function and input set, proving that any system executing the computation did so correctly. Though still nascent, ZK verifiable computation is already a critical component of Ethereum’s scaling roadmap.
There are various implementations of ZK proofs (as summarized in the paper “Off-Chaining_Models,” shown below):
Now that we have a basic understanding of ZK proof implementations, what does it take to verify computation using ZK proofs?
-
First, choose a proof primitive—ideally one with low proof generation cost, modest memory requirements, and easy verification.
-
Second, select a zk circuit designed to generate proofs for the chosen primitive through computation.
-
Finally, execute the given function over provided inputs within a computational system/network and produce the output.
The Developer’s Dilemma – Proof Efficiency Trap
Another major challenge is the high barrier to circuit development. Getting developers to learn Solidity was hard enough; now asking them to learn Circom to build circuits or a specialized programming language like Cairo to develop zk-apps seems out of reach.
As the statistics above show, adapting the Web3 environment to better suit developers appears more sustainable than forcing developers into new Web3 development environments.
If ZK is indeed the future of Web3, and Web3 applications must be built using existing developer skills, then zk circuits must be designed to generate proofs for computations executed via algorithms written in JavaScript or Rust.
Such solutions do exist. Two teams come to mind: RiscZero and Lurk Labs. Both share a very similar vision—enabling developers to build zk-apps without enduring steep learning curves.
Lurk Labs is still in early stages but has been working on this project for a long time. They focus on generating Nova proofs through universal circuits. Nova proofs were proposed by Abhiram Kothapalli from Carnegie Mellon University, Srinath Setty from Microsoft Research, and Ioanna Tzialla from New York University. Compared to other SNARK systems, Nova proofs offer distinct advantages in Incrementally Verifiable Computation (IVC). IVC is a concept in computer science and cryptography aimed at verifying computations without re-executing them from scratch—particularly useful when dealing with long, complex computations requiring optimized proof structures.
Nova proofs aren't “plug-and-play” like other proof systems—Nova is just a folding technique. Developers still need a full proof system to generate proofs. That’s why Lurk Labs built Lurk Lang, a Lisp implementation. Since Lisp is a lower-level language, it makes generating proofs on universal circuits straightforward and easily translatable to JavaScript—potentially giving Lurk Labs access to 17.4 million JavaScript developers. Transpilation support extends to other general-purpose languages like Python as well.
In summary, Nova proofs appear to be a powerful foundational primitive. While their downside is that proof size increases linearly with computation size, they do offer room for further compression.
STARK proofs do not increase in size with larger computations, making them better suited for verifying massive computations. To further improve developer experience, RiscZero launched the Bonsai Network—a decentralized computing network where proofs generated by RiscZero are verified. Below is a simple diagram illustrating how the Bonsai Network works.
The beauty of the Bonsai Network design is that computation can be initialized, verified, and output entirely on-chain. All of this sounds utopian, but STARK proofs come with their own drawback—high verification costs.
Nova proofs seem ideal for repetitive computations (due to their economically efficient folding scheme) and small-scale computations, potentially making Lurk a strong candidate for ML inference verification.
Who Are the Winners?
Some zk-SNARK systems require a trusted setup phase to generate initial parameters. The trust assumption here is that this setup was conducted honestly, without malicious intent or tampering. If compromised, invalid proofs could be created.
STARK proofs assume the security of low-degree testing used to verify polynomial degree properties. They also assume hash functions behave like random oracles.
Correct implementation of both systems is also a security assumption.
SMPC networks rely on the following assumptions:
-
SMPC participants may include “honest-but-curious” actors who attempt to infer underlying information through communication with other nodes.
-
Security depends on the assumption that participants follow the protocol correctly and do not introduce errors or act maliciously.
-
Some SMPC protocols require a trusted setup phase to generate cryptographic parameters or initial values, assuming this setup is honest.
-
Similar to SMPC, the same security assumptions hold, but due to OTM (Off-The-Mesh Multi-party Computation), “honest-but-curious” participants do not exist.
OTM is a multi-party computation protocol designed to protect participant privacy by preventing disclosure of input data during computation. Thus, “honest-but-curious” participants cannot exploit inter-node communications to access sensitive information.
Is there a clear winner? We don’t know. Each method has its strengths. While NMC appears to be a clear upgrade over SMPC, the network hasn’t launched nor undergone real-world testing.
The benefit of ZK verifiable computation is its strong security and privacy guarantees, though it lacks built-in secret sharing. The asymmetry between proof generation and verification makes it ideal for verifiable outsourced computation. However, if a system relies solely on zk-verified computation, the computing node must be extremely powerful to handle large workloads. To enable load sharing and balancing while preserving privacy, secret sharing becomes essential. In such cases, systems like SMPC or NMC can be combined with zk generators like Lurk or RiscZero to create robust, distributed, verifiable, outsourced computing infrastructures.
Today’s MPC/SMPC networks are centralized—an increasingly important limitation. Currently, Sharemind is the largest MPC provider; adding a ZK verification layer on top could prove valuable. The economic model for decentralized MPC networks hasn’t been proven yet. In theory, NMC represents an upgrade to MPC systems, but we haven’t seen successful implementations yet.
In the race among ZK proof schemes, there may not be a single winner-takes-all outcome. Each proof method is optimized for specific types of computation, and no one-size-fits-all model exists. The variety of computational tasks—and the trade-offs developers make across different proof systems—suggests that both STARK-based and SNARK-based systems, along with their future optimizations, will coexist in the future of ZK.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
