2 024 During the Hong Kong Web3 Carnival, Ethereum co-founder Vitalik Buterin delivered a keynote speech "Reaching the Limits of Protocol Design" at the "Web3 Scholar Summit 2024" hosted by DRK Lab.
The following is the Chinese live record brought by DeThings, slightly abridged:
The kinds of technologies we use to build protocols have changed significantly over the past 10 years. When Bitcoin was born in 2009, it actually used very simple cryptography. The only types of cryptography you saw in the Bitcoin protocol were hash and elliptic curve ECDSA signatures, and proof of work (Pow). .
Proof of work is just another way of using hash. If you look at the types of technologies used to build protocols in the 2020s, you start to see a more complex collection of technologies that have really emerged only in the past 10 years.
These things have really been around for a long time, so technically we've had the PCP theorem for decades. We've had fully homomorphic encryption since Craig Gentry's discovery in 2009. For decades we've had garbled circuits, a two-sided form of computing. But there is a difference between the existence of these technologies in theory and the existence of these technologies in practice.
In fact, I think the blockchain field itself deserves a lot of credit for actually bringing in a lot of resources to bring these technologies to a stage where you can use them in regular applications.
When building blockchains in the 2020s, it was assumed that hashes and signatures were all you had. And the observation protocols being constructed in the 2020s considered all of these things as critical components from the beginning.
Major improvements to ZK-SNARKs
ZK-SNARKs are the first big thing here. ZK-SNARKs are a technique that can prove that you performed a calculation and got some output from the calculation. You can prove this in a way that the verification is much faster than running the calculation yourself. You can also verify proofs without revealing the original input information.
The difference between zK-SNARKs in 2010 (theoretical stage) and ZK-SNARKs in 2016 (first used in the Zcash protocol launched in December of that year) is really huge, right?
So a lot of these newer forms of encryption went from being almost unknown to niche interest to mainstream to now almost becoming the default. These things have changed and improved dramatically over the past decade.
Therefore, Z-SNARKs are very useful in terms of privacy and also very useful in terms of scalability. What does blockchain do? Blockchains bring you a lot of benefits, they bring you openness, they bring you permission-free access, they bring you global verifiability. But all of this comes at the expense of two big things.
Sacrifice privacy and scalability
One is privacy and the other is scalability. ZK-SNARK gives you privacy and scalability.
In 2016, we saw the Zcash protocol. After that, we started to see more and more things in the Ethereum ecosystem. Nowadays, almost everything starts using zkSNARKs, multi-party computation, and fully homomorphic encryption.
Today, people know less about these things than zkSNARKs, but there are certain types of things that can't be done with ZK-SNARKs. For example, privacy computing operates on people's private data.
Voting is actually a big use case, and you can get a certain level of privacy with zk-SNARKs. But if you want to get the really best properties, then you have to use MPC (Multi-Party Computation) and FHE (Fully Homomorphic Encryption). Many cryptographic AI applications also end up using MPC and FHE, both of which are primitives that have seen dramatic improvements in efficiency over the past decade.
BLS (Boneh-Lynn-Shacham, aggregate signature) is an interesting technology that basically allows you to take a large batch of signatures from a large number of different participants, potentially tens of thousands of participants, and then like verify a single signature Verify that combined signature just as quickly.
This function is very powerful. BLS aggregation is actually the core technology of Ethereum’s modern proof-of-stake consensus. If you look at the proof-of-stake consensus that was established before BLS convergence, a lot of times the algorithms tended to only support a few hundred validators. In Ethereum, there are currently approximately 30,000 validators, submitting signatures every 12 seconds. And the reason why this is possible is because this new form of encryption has only really been optimized over the last five to 10 years to the point where it's useful and these new technologies make a lot of things possible."
They are rapidly becoming more powerful. Today's protocols make heavy use of all of these technologies. We did go through a major shift from specialized cryptography, where in order to build new protocols you had to understand how cryptography worked, to general purpose cryptography, where you had to build specialized algorithms for specialized applications. Where before you had to build a special-purpose algorithm for a special-purpose application, now you don't even need to be a cryptographer to build one that uses what I've been talking about for the past five minutes. application.
You just write a piece of code, write a piece of code in Circom, and Circom compiles it into a verifier and a validator, and you have a zk-SNARK application. What are the challenges here? Essentially, the problem is that we've come a long way in the last 10 years. What's left? What is the gap between these technologies and the theoretical ideals we have today? I think this is a key area where researchers and academics can make a big difference.
I think the two major issues at the moment are basically: one is efficiency and the other is security. Now there's a third issue, which is extended functionality, so to speak.
For example, one technology we haven't really mastered yet is indiscriminate obfuscation. It would be even more amazing if we could have a workable algorithm. But actually, I think it’s more important to be more efficient and more secure with what we have today.”
Let's talk about efficiency. Let’s take a concrete example, and that’s the Ethereum blockchain. In Ethereum, slot time is 12 seconds. The average time between one block and the next is 12 seconds. The normal block verification time, that is, the time required for any Ethereum node to verify a block, is approximately 400 milliseconds.
Currently, the time required for zk-SNARK to verify a normal Ethereum block is approximately 20 minutes. This time is improving rapidly, it was 5 hours a year or two ago. Now 20 minutes is about average, right? There are still worst-case scenarios. For example, if you have an Ethereum block and the entire Ethereum block is doing zk-SNARK calculations, then its proof time will be more than 20 minutes.
Still, we are further along than we were two years ago. What is the goal now? The goal is instant proof, the goal is that when a block is built, you have proof of that block before the next block is built.
When we have instant proof, what do we have? Basically, every Ethereum user in the world can easily become a fully verified user of the Ethereum protocol, but very few people have an Ethereum node. Realistically, an archive node requires 2 TB, which you can do, but it's very inefficient. What if we could make every Ethereum wallet, including browser wallets, mobile wallets, and lightweight wallets with smart contracts on other chains, truly and fully verify the Ethereum consensus rules?
Some people actually don't trust Infura. They don’t even trust Ethereum’s proof-of-stake validators, but directly verify the rules and directly ensure the correctness of Ethereum blocks. How do we do this with ZK-SNARK? To truly do this, zK-SNARK proofs need to be instantaneous, but there needs to be a way for any Ethereum block to be proven, possibly within 5 seconds.
The question is, can we get there? Now, MPC and FHE have similar problems. As I mentioned before, a typical use case for MPC and FHE is voting, and it is actually already being used. About three weeks ago, an Ethereum event was held in Vietnam. At that event, they actually used MPC, which is one of these cryptographically secure voting systems, to conduct voting on projects and hackathons.
The current problem with MPC is that it relies on a central server for some of its security properties. Can we decentralize this assumption of trust? Yes, but this requires MPC and FHE. The problem now is that ensuring the efficiency of these protocols is very expensive, and there is FHE on ZK-SNARK. For these protocols to become the default protocols used by ordinary people, you can't make every vote proof cost $5 in computational power, right? It must be done quickly, even with large numbers of votes cast on the fly.
How to improve the efficiency of zk-SNARK?
So, how do we achieve the goal of ZK-SNARK? I think there are three broad categories of efficiency improvements. One of them is parallelization and aggregation. Imagine that it takes up to 10 million computational steps to verify an Ethereum block. You take each of these calculation steps and make a proof for each. Then perform proof aggregation.
Take the first two proofs and prove them. Take two more proofs and prove them. Take the next two proofs and prove these proofs. Taking the proofs of the first two proofs and proving these proofs, we get a tree. After about 20 steps up the tree, you get a big proof that represents the correctness of the entire block of the program.
This is possible with today's technical conditions. It can prove the correctness of a theoretical block in 5 seconds. where is the problem? Basically, this requires a lot of parallel computing, right? It needs to be proven 10 million times. So can we optimize it? Can we optimize parallelization? Can we optimize aggregate proofs? The answer is yes.
There are many theoretical ideas on how to do this. But it does need to turn into something real. This is a problem that combines algorithm improvements, low-level improvements, hardware design improvements, and efficiency improvements, so ASIC is also very important. We all see how important ASICs are for mining, right? Remember in 2013 when ASIC first came online, we saw how Bitcoin’s computing power grew rapidly.
ASICs are pretty powerful, right? With the same hardware and electricity costs, the hash value of an ASIC is basically 100 times that of a GPU. The question is, can we bring the same benefits to SNARK proofs? I think the answer should be yes. As a result, more and more companies are starting to actually build ASICs specifically designed to prove zK-SNARKs. It could be zkEVMs, but should actually be very generic. You should be able to make a SNARK ASIC to prove any kind of computation. By doing this, can we go from 20 minutes to 5 seconds?
In the end, it’s about being more efficient, right? Therefore, we need a better zK-SNARK algorithm. We have Groth16, we have lookup tables, we have 64-bit SNARKs, we have STARKs, we have 32-bit STARKs, all kinds of different ideas. Can we further improve the efficiency of the SNARK algorithm? Can we create more hash functions that are more SNARK-friendly and more signature algorithms that are more SNARK-friendly? There are a lot of ideas here, and I highly encourage everyone to work on them.
The main security issue is bugs, right? I think bugs are one of the biggest issues that people rarely talk about, but they're so important, right? Basically, we have all these amazing encryption technologies, but people aren't going to trust them if they're worried that there's some kind of flaw in the circuit, right? Both zK-SNARK and zkEVM have 7000 lines of code.
This is still very efficient. On average, there are 15 to 50 vulnerabilities per thousand lines of code. In Ethereum, we work hard to have less than 15 bugs per thousand lines of code, but more than zero, right? If you have these systems that hold billions of dollars in assets, if there's a breach in one of those systems, that money will be lost no matter how advanced the cryptography is.
The question is, what can we do to truly leverage existing cryptography and reduce errors in it? Today, the basic technology used here is a security committee, basically you just get a bunch of people together in Ethereum and if a majority of them, like over 75%, think there is a vulnerability, then they can overturn the proof system Everything said.
So it's a fairly centralized system, but it's the best system we have right now. We will have multiple proofs in the near future. Here is a picture of Starknet, one of the Rollups based on Ethereum. The idea is that if you have multiple proof systems, in theory, you can use redundancy to reduce the risk of a vulnerability in any one of them, and if you have three proof systems, if one of them has a bug, then hopefully the other two No two systems will go wrong in exactly the same place.
Finally, I think one of the interesting things to look into in the future is using artificial intelligence tools, potentially using new tools to do formal verification, right? So, it's like mathematically proving that something like ZKEVM is bug-free, right? Basically, can you really prove that, for example, the zkEVM implementation is verifying the exact same functionality in the EVM code as the Ethereum implementation? For example, can you prove that they have only one output for any possible input? If you can try to actually prove these things, then maybe we can actually achieve a bug-free zkEVM world sometime in the future.
This is crazy, right? Because no one has ever made such a complex loophole-free program before. But in 2019, no one thought it was possible for artificial intelligence to make truly beautiful pictures, right? So, today we just saw how far we've come. We saw the capabilities of artificial intelligence. The question now is, can we try to apply similar tools to real-world tasks, such as automatically generating mathematical proofs of complex statements whose programs span thousands of lines of code? I think this is an interesting open challenge that deserves attention.
Regarding the efficiency of aggregated signatures, today, Ethereum has 30,000 validators, and running a node is very demanding, right? I have an Ethereum node on my laptop and it works, but it's not a cheap laptop and I have to upgrade the hard drive myself. The ideal goal of Ethereum is to support as many as possible validator.
We want Proof of Stake to be as democratized as possible, allowing people to participate directly in verification at any scale. We want the requirements to run an Ethereum node to be very low and very easy to use. We want the theory and protocol to be as simple as possible. What are the theoretical limits here? All data per participant per session needs to be 1 bit because you have to broadcast who signed and who didn't.
This is the most basic limit. Beyond this limit, there are no other limits. There is no lower limit for calculations. You can do aggregate proofs and you can do recursive proof trees. You can do signatures, you can do various aggregate signatures. You can use STARKs, you can use grid-based cryptography, you can use 32-bit STARKs, you can use a variety of different technologies.
The question is, to what extent can we optimize signature aggregation? This is peer-to-peer security, and people don't think enough about peer-to-peer networks. This is a point I want to emphasize a lot, because I think in the crypto space, people tend to build fancy structures on top of peer-to-peer networks and then assume that peer-to-peer networks work.
There's a lot of risk hidden here, right? I think these risks will become more sophisticated, so in the 2010s every node can see everything. You can certainly do some attacks: there are eclipse attacks, there are denial-of-service attacks, there are all kinds of attacks.
But when you have a very simple network whose only job is to make sure everything is available to everyone, the problem is pretty simple. The problem is that as Ethereum scales, the peer-to-peer network becomes increasingly complex. Today’s Ethereum peer-to-peer network already has 64 shards, right?
To do signature aggregation, to process 30,000 signatures per period like now. We have a point-to-point network that is divided into 64 different subnetworks, and each node belongs to only one or a few of them. In data availability sampling, this is the technique used by Ethereum to provide data space for blocks to achieve scalability.
This also depends on a more complex peer-to-peer architecture. Here, what you see is a graph of peer nodes. In this setting, each node can only download 1/8 of all data. So the question is, is such a network really safe? Can you guarantee its safety? Can you increase your guarantee rate as much as possible? How can we protect and improve the security of the peer-to-peer networks that Ethereum relies on?
Basically, I think what we need to focus on at this point is we need protocols that push the limits of cryptography, which is already much stronger than it was ten years ago, but can still be much stronger, and at this point, I think we really need to start looking at what the ceiling is and how we can actually get to it.
There are two equally important areas here. One of them is to continue to improve efficiency, and we want to prove everything immediately. We hope to see a world where, in a decentralized protocol, every piece of information delivered in a blog will have a zk-SNARK attached by default to prove that the information and everything it relies on follows the protocol rules.
The second frontier is improving security. Fundamentally, it’s about reducing the chance of error. Let's have a world where the actual technology these protocols rely on can be very powerful, very trustworthy, and people can rely on it as much as possible.
However, as we have seen many times, Multisignature can also be hacked, and there are many examples of these so-called Layer 2 projects, where the coins in one or two projects are actually composed of a multi-signature controlled, but somehow, five out of nine signatures were hacked at the same time, resulting in a massive loss of funds. If we want to transcend this world, then we need to believe in what is truly capable of using technology and truly pass cryptography. to enforce the rules rather than trusting a small group of people to ensure they are followed.
But to do this, the code must be trustworthy. The question is, can we make the code trustworthy?
Can we make the Internet trustworthy? Can we make the economics of these products, these protocols, trustworthy? I think these are core challenges, and I hope we can continue to work together and improve, thank you.
