Ethereum (ETH) co-founder Vitalik Buterin has pushed for a simpler, more practical way to report performance in zero-knowledge proof (ZK) and fully homomorphic encryption (FHE) systems. He is arguing that developers should stop leaning on raw “operations per second” claims and instead report an “efficiency ratio, ” the time a computation takes under cryptography divided by the time it takes to run in the clear.
In a post on X, Buterin laid out the idea plainly: give the overhead as a ratio, “time to compute in cryptography vs time to compute raw,” so that engineers and product teams immediately understand how much performance they would be sacrificing to gain cryptographic guarantees. That single number, he suggested, answers a very practical question: how much slower will my application be if I make it cryptographic instead of trust-dependent?
Buterin also explained why this metric is useful from a developer’s point of view. Most teams already know how long a task takes when run normally, he noted, so multiplying by an overhead factor gives an immediate estimate of cryptographic cost without having to translate what “N ops per second” means for their specific workload and hardware. That makes the ratio a handy shortcut for planning and tradeoff analysis.
He didn’t pretend the idea was perfect. Buterin acknowledged key complications: the operations needed for execution and for proving can be heterogeneous, and differences in SIMD parallelization, memory-access patterns, and other hardware-specific factors mean the ratio won’t be totally hardware-independent. Even so, he called the overhead factor “a good number despite these imperfections,” arguing that it is still more informative and developer-friendly than the current headline figures.
Efficiency, Not Throughput
The suggestion has already sparked commentary across crypto media and research circles, with some welcoming a standardized, application-focused metric that could help product teams weigh privacy and performance more clearly, while others point to the practical difficulty of comparing ratios produced on different stacks, accelerators, and proof models.
The conversation lands at a moment when both ZK and FHE technologies are increasingly being pitched for real-world deployments, places where latency, developer ergonomics, and cost matter as much as theoretical throughput numbers. Buterin’s ask is intentionally modest: not a new benchmark suite, but a different way of reporting results that speaks directly to the tradeoffs teams care about.
If researchers and product teams begin to adopt the efficiency-ratio framing, it could make it easier for engineers and decision-makers to tell whether a privacy-preserving approach is a viable fit for a given application, or an impressive demo that won’t scale in production. For a field wrestling with both hype and genuine technical progress, that kind of clarity could matter a lot.
