Vitalik Buterin's Speech at Hong Kong Web3 Festival: We Need Protocols That Can Reach the Limits of Cryptographic Technology
TechFlow Selected TechFlow Selected
Vitalik Buterin's Speech at Hong Kong Web3 Festival: We Need Protocols That Can Reach the Limits of Cryptographic Technology
We really need to start studying what the upper limit is and how we can truly reach it.
Navigating Web3 tides with focused insightsAuthor: Vitalik Buterin
Compiled by: DeThings
During the 2024 Hong Kong Web3 Festival, Ethereum co-founder Vitalik Buterin delivered a keynote speech titled "Reaching the Limits of Protocol Design" at the "Web3 Scholars Summit 2024," hosted by DRK Lab.
Below is DeThings' Chinese live transcript, edited for clarity:
Over the past decade, the types of technologies we use to build protocols have changed significantly. When Bitcoin was created in 2009, it actually used very simple cryptographic techniques—the only cryptography in the Bitcoin protocol being hashes, elliptic curve ECDSA signatures, and proof-of-work (PoW). Proof-of-work is just another way of using hashes. If you look at the types of technologies used to build protocols in the 2020s, you start seeing a much more sophisticated set of tools—many of which have only become practical in the last ten years.
These things technically existed long before—they’ve been around for decades. For example, we’ve had the PCP theorem for decades. We’ve had fully homomorphic encryption since Craig Gentry’s breakthrough in 2009. Garbled circuits, a form of two-party computation, have also existed for decades. But there's a difference between these technologies existing in theory and being practically usable.
I think blockchain itself deserves a lot of credit for bringing substantial resources that pushed these technologies into stages where they can be used in real-world applications.
If you were building blockchains in the 2010s, you assumed hashes and signatures were all you had. But protocols designed in the 2020s treat all these advanced tools as fundamental components from day one.
ZK-SNARKs were the first major development here. ZK-SNARKs are a technology that allows you to prove you performed a computation and obtained some output, in such a way that verification is much faster than re-running the computation yourself—and you can do so without revealing the original input data.
The ZK-SNARKs of 2010 and even those used in Zcash when it launched in December 2016 are vastly different from today’s ZK-SNARKs, right?
So many of these newer cryptographic techniques have gone from obscure theoretical curiosities to niche interests, then mainstream adoption, and now nearly default assumptions. These tools have undergone massive improvements over the past decade.
"ZK-SNARKs are incredibly useful for both privacy and scalability. What do blockchains give us? They offer openness, permissionless access, and global verifiability. But all this comes at the cost of two major trade-offs: one is privacy, and the other is scalability. ZK-SNARKs restore both privacy and scalability.
In 2016, we saw the Zcash protocol. After that, we began seeing increasing use of these tools within the Ethereum ecosystem. Today, almost everything starts incorporating zkSNARKs, multi-party computation (MPC), and fully homomorphic encryption (FHE). People know less about MPC and FHE compared to zkSNARKs, but there are certain tasks that simply cannot be done with ZK-SNARKs alone—like private computations on users’ sensitive data.
Voting is a major use case—you can achieve a certain level of privacy with zk-SNARKs, but if you want the strongest guarantees, you must use MPC and FHE. Many encrypted AI applications also end up relying on MPC and FHE—both primitives whose efficiency has dramatically improved over the past decade. BLS (Boneh-Lynn-Shacham) aggregation is another powerful technique: it allows you to collect signatures from potentially tens of thousands of participants and verify them collectively almost as quickly as verifying a single signature.
This capability is extremely powerful. BLS aggregation is actually a core component of Ethereum’s modern proof-of-stake consensus. If you look at proof-of-stake systems built before BLS aggregation, most algorithms could only support a few hundred validators. On Ethereum today, there are around 30,000 validators, each submitting a signature every 12 seconds. This is only possible because this new cryptographic primitive has only recently been optimized enough over the past 5–10 years. These new technologies make many things possible."
They are rapidly becoming even more powerful. Today’s protocols heavily rely on all these technologies. We’ve gone through a major shift—from specialized cryptography, where creating new protocols required deep cryptographic expertise, to general-purpose cryptography, where you no longer need to be a cryptographer to build applications using the tools I’ve discussed in the past few minutes.
You can simply write a piece of code, compile it in Circom, and Circom generates a verifier and prover—you instantly have a zk-SNARK application. The challenge now is this: we’ve come a long way in the past decade. What remains? What gaps still exist between today’s technologies and their theoretical ideals? I believe this is precisely where researchers and academics can make a significant impact.
I see two main challenges today: efficiency and security. There’s also a third, broader issue—extensibility.
For example, we haven’t yet mastered indistinguishability obfuscation. A practical algorithm for that would be revolutionary. But realistically, improving the efficiency and security of what we already have is more urgent."
Let’s talk about efficiency. Take Ethereum as a concrete example. On Ethereum, the slot time is 12 seconds—the average time between blocks. Normal block verification time—that is, how long it takes any Ethereum node to validate a block—is about 400 milliseconds.
Right now, verifying a standard Ethereum block with a zk-SNARK takes about 20 minutes. That’s improving fast—two years ago, it took five hours. Now 20 minutes is the average, though worst-case scenarios still exist. For instance, if an entire Ethereum block were filled with Zcash-style computations, proving it would take longer than 20 minutes.
Still, we’ve made great progress. What’s the goal? Real-time proving. The goal is that when a block is created, its proof is generated before the next block arrives. With real-time proving, what do we gain? Essentially, every Ethereum user could easily become a full validator of the Ethereum protocol. Yet today, very few people run Ethereum nodes. An archive node requires 2TB of storage—it’s doable, but inefficient. What if every Ethereum wallet—even browser wallets, mobile wallets, or lightweight wallets on other chains—could fully verify Ethereum’s consensus rules?
Some people don’t trust Infura. Some don’t even trust Ethereum’s PoS validators—they want direct rule validation, directly ensuring the correctness of Ethereum blocks. How can we achieve this with ZK-SNARKs? To make this truly work, zk-SNARK proofs need to be real-time—ideally, provable within 5 seconds of a block being created.
Can we get there? MPC and FHE face similar issues. As I mentioned earlier, voting is a classic use case for MPC and FHE—and it’s already being used. About three weeks ago, Vietnam held an Ethereum event where they actually used MPC—a type of cryptographically secure voting system—for voting on projects and hackathons.
The current problem with MPC is that some of its security properties depend on a central server. Can we decentralize that trust assumption? Yes—but it requires MPC and FHE. The issue now is that guaranteeing efficiency for these protocols is expensive. You can’t have each vote costing $5 worth of computation if you want ordinary people to use these systems by default. It must be fast—and capable of handling large-scale voting in real time.
So how do we reach our ZK-SNARK goals? I see three major paths to improve efficiency. One is parallelization and aggregation. Imagine validating an Ethereum block requires up to 10 million computational steps. You split each step and generate individual proofs. Then you aggregate them: take the first two proofs and create a proof of their correctness; then the next two; then the next two. Then prove the proofs of the first two pairs, and so on—building a tree. After about 20 levels, you get one final proof representing the entire block’s correctness.
This is technically feasible today. Such a method could theoretically prove a block’s correctness within 5 seconds. Where’s the catch? It requires massive parallel computation—10 million separate proofs. Can we optimize this? Can we improve parallelization and aggregation? Yes—there are many theoretical ideas on how. But they need to become practical. This is a multidisciplinary challenge involving algorithmic improvements, low-level optimizations, hardware design, and efficiency gains. ASICs matter too. We’ve all seen how crucial ASICs are for mining—remember 2013, when ASICs first arrived and Bitcoin’s hash rate exploded?
ASICs are incredibly powerful—given the same hardware cost and electricity, ASICs can hash about 100 times faster than GPUs. So can we bring similar benefits to SNARK proving? I believe yes. More and more companies are now building ASICs specifically for generating zk-SNARK proofs. These could be tailored for zkEVMs, but ideally should be highly general-purpose—capable of proving any kind of computation. Can this bring us from 20 minutes down to 5 seconds?
Finally, better zk-SNARK algorithms themselves. We have Groth16, lookup tables, 64-bit SNARKs, STARKs, 32-bit STARKs—various approaches. Can we further improve SNARK efficiency? Can we design more SNARK-friendly hash functions and signature schemes? There are many promising directions—I strongly encourage more work in this area.
On security, bugs are the biggest under-discussed issue—and critically important. We have all these amazing cryptographic tools, but if people suspect bugs in the circuit, they won’t trust them. Whether it’s zk-SNARKs or zkEVMs, these systems often involve around 7,000 lines of code—even in optimized cases. On average, there are 15 to 50 bugs per thousand lines of code. In Ethereum, we work hard to keep it under 15 per thousand—but still above zero. If a system holding billions of dollars has even one bug, all that money could be lost regardless of how advanced the cryptography is.
So what can we do to reduce bugs in these systems? Currently, the basic approach is a security council—basically gathering a group of experts in Ethereum, and if a supermajority (say, over 75%) agrees a vulnerability exists, they can override what the proof system says. It’s quite centralized, but it’s the best we have for now. Soon, we’ll likely move toward multi-proof systems. Here’s a diagram from Starknet, one of Ethereum’s rollups. The idea is, if you have multiple proof systems, you can use redundancy to lower the risk that any one has a bug. If three systems exist, and one fails, hopefully the other two won’t fail in exactly the same way.
Finally, I think an exciting future direction is leveraging AI tools—possibly using new techniques for formal verification. Imagine mathematically proving that a zkEVM implementation has no bugs. Can you formally prove that the zkEVM correctly validates EVM code exactly as Ethereum does? Can you prove it produces a single unique output for any given input? If we can truly prove such things, perhaps we’ll eventually live in a world of bug-free zkEVMs.
That sounds crazy, right? Because until now, no one’s ever built such a complex program without bugs. But in 2019, no one thought AI could generate beautiful images either. Look how far we've come. We now understand AI’s potential. So the question is: can we apply similar tools to real-world tasks—like automatically generating mathematical proofs for complex programs spanning thousands of lines of code? I think this is a fascinating open challenge worth pursuing.
Regarding the efficiency of aggregate signatures: Ethereum currently has 30,000 validators, and running a node is demanding. I run an Ethereum node on my laptop—it works, but it’s not a cheap machine, and I had to upgrade the hard drive myself. Ethereum’s ideal is to support as many validators as possible. We want proof-of-stake to be as decentralized as possible, enabling anyone to participate in validation at any scale. We want running an Ethereum node to be as easy and accessible as possible. We want the underlying theory and protocols to be maximally simple.
What’s the theoretical limit? Fundamentally, you need 1 bit of data per participant per epoch—just to broadcast who participated in signing and who didn’t. Beyond that, there are no hard limits: computation can be aggregated, recursive proof trees can be built, various forms of signature aggregation can be used, STARKs, lattice-based cryptography, 32-bit STARKs—many different techniques are available.
So how far can we optimize signature aggregation? This leads to peer-to-peer network security—an area people often overlook. I want to emphasize this: in crypto, people tend to build fancy layers on top of P2P networks and assume the underlying network just works.
But there are hidden risks. In Bitcoin, P2P worked relatively simply in the 2010s—every node saw everything. Sure, attacks like eclipse attacks, denial-of-service, and others were possible. But when the network is simple and its sole job is ensuring everyone receives all data, the problems are manageable.
The issue is, as Ethereum scales, the P2P network becomes increasingly complex. Today’s Ethereum P2P network already has 64 shards, right? To enable signature aggregation and handle 30,000 signatures per epoch as we do now, we’ve divided the P2P network into 64 subnetworks—each node belongs to only one or a few.
Data availability sampling—the technique Ethereum uses to expand data space for scalability and keep rollup fees low—also depends on this more complex P2P architecture. In this setup, each node downloads only 1/8 of the total data. So the question arises: is such a network really secure? Can we guarantee its security? Can we maximize confidence in its reliability? How can we protect and enhance the security of the P2P networks that Ethereum depends on?
Ultimately, I believe we now need to focus on protocols that can reach the limits of cryptographic capabilities. Our cryptography is far stronger than it was ten years ago—but it can still go further. At this stage, we really need to start exploring the upper bounds: what are they, and how do we reach them?
There are two equally critical frontiers. One is pushing efficiency further—we want real-time proving for everything. We want a world where, in decentralized protocols, every message passed on a blog post comes with a default zk-SNARK proving that the message and everything it relies on follows the protocol rules.
The second frontier is enhancing security—reducing the chance of failure so that the underlying technologies powering these protocols become robust and trustworthy enough for widespread reliance. Right now, despite vulnerabilities, people don’t trust the cryptography—they continue to trust humans.
But as we’ve seen repeatedly, multisignature setups can be hacked. There are many examples—so-called Layer 2 projects where coins were controlled by a multisig, and somehow five out of nine signers got compromised simultaneously, leading to massive losses. If we want to move beyond this, we need to trust what technology can actually deliver—and enforce rules cryptographically, rather than relying on small groups of people to uphold them.
But to do that, the code must be trustworthy. Can we make the code trustworthy? Can we make the network trustworthy? Can we make the economics of these products and protocols trustworthy? I believe these are the core challenges. I hope we can continue working together to push forward. Thank you.
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
@DethingsNews
