EthCC7 was recently held in Brussels, and the organizers invited Ethereum founder Vitalik to give a keynote speech.
It is worth noting that 2024 marks the 10th anniversary of Ethereum IC0. After Vitalik’s speech, the three former core founders of Ethereum, Vitalik Buterin, Joseph Lubin and Gavin Wood, took a group photo together again to commemorate the event.
This article is the keynote speech given by Ethereum founder Vitalik at EthCC7 recently.
the speech topic
Strengthening L1: Optimizing Ethereum to be a highly reliable, trustworthy, and permissionless Layer 2 base layer
Ethereum Vision Spectrum
I think there is a spectrum of different possible roles that the Ethereum base layer might play in the ecosystem over the next five to ten years. You can think of it as a spectrum from left to right.
On the left side of the spectrum, it basically tries to be a very minimalistic base layer that basically just acts as a proof validator for all L2s. Maybe also provides the ability to transfer ETH between different L2s. But other than that, that's basically it.
On the right side of the spectrum, there is essentially a refocus on dApps running primarily on L1, with L2 only used for some very specific and high-performance transactions.
There are some interesting options in the middle of the spectrum. I put Ethereum as the base layer of L2 on the second left. On the far left, I put an extreme version, which is that we completely abandon the execution client part of the entire Ethereum, keep only the consensus part, and then add some zero-knowledge proof validators, basically turning the entire execution layer into a Rollup.
I mean the very extreme options are on the left, and on the right it can be a base layer but also try to provide more functionality to L2. One idea in this direction is to further reduce Ethereum's swap time, which is currently 12 seconds, maybe down to 2-4 seconds. The purpose of this is to actually make basic rollups feasible as the main way L2 operates. So right now, if you want L2 to have a top-notch user experience, you need to have your own pre-confirmation, which means either a centralized sorter or your own decentralized sorter. If their consensus speed increases, then L2 will no longer need to do this. If you really want to enhance the scalability of L1, then the need for L2 will also decrease.
So, it's a spectrum. I'm focusing on the second-left version right now, but the things I suggest here also apply to other visions, and the suggestions here don't actually hinder other visions. That's something I think is important.
Ethereum’s robustness advantage
One of Ethereum’s big advantages is that it has a large and relatively decentralized staking ecosystem.
On the left side of the above picture is the computing power chart of all Bitcoin mining pools, and on the right side is the chart of Ethereum stakers.
The distribution of Bitcoin computing power is not very good at present. Two mining pools together account for more than 50% of the computing power, and four mining pools together account for more than 75%.
And Ethereum is actually in a better position than the chart shows, because the second largest gray portion is actually unidentified, which means it could be a combination of many people, and there could even be a lot of independent stakers in it. And the blue portion, Lido, is actually a weird, loosely coordinated structure of 37 different validators. So, Ethereum actually has a relatively decentralized staking ecosystem that's doing pretty well.
There's a lot of improvements we can make on that, but I think there's still value in recognizing that this is one of our unique advantages that we can really build on.
Ethereum’s robustness advantages also include:
· Have a multi-client ecosystem: There are Geth execution clients and non-Geth execution clients, and the proportion of non-Geth execution clients even exceeds that of Geth execution clients. A similar situation also occurs in the consensus client system;
International community: people in many different countries, including projects, L2, teams, etc.
A multi-center knowledge ecosystem: There is the Ethereum Foundation, client teams, and even teams like Paradigm’s Reth have been increasing their leadership in open source recently;
A culture that values these attributes
So, the Ethereum ecosystem as a base layer already has these very strong advantages. I think this is something that is very valuable and should not be given up easily. I would even go so far as to say that there are clear steps that can be taken to further advance these advantages and even to remedy our weaknesses.
Where does Ethereum L1 fail to meet high standards and how can it be improved?
Here’s a poll I did on Farcaster about half a year ago: If you’re not Solo staking, what’s stopping you from Solo staking?
I can repeat this question in this venue, who is doing Solo staking? If not doing Solo staking, who thinks the 32 ETH threshold is the biggest obstacle, who thinks it is too difficult to run a node, who thinks the biggest obstacle is not being able to put your ETH into DeFi protocols at the same time? Who thinks the biggest obstacle is the worry that you have to put your private key on a running node, which is more vulnerable to theft?
As you can see, the top two barriers that are agreed upon are: the minimum requirement of 32 ETH and the difficulty of node operation. It is always important to recognize this.
A lot of times when we start to dig into how to maximize how people can double spend their collateral in DeFi protocols, we find that a large number of people are not even using DeFi protocols at all. So let's focus on the main problems and what we can do to try to solve them.
Starting from running a validator node, or in other words, starting from a threshold of 32 ETH. In fact, these two questions are related because they are both functions of the number of validators in Ethereum Proof of Stake.
Today we have about 1 million validator entities, each with 32 ETH on deposit, so if the minimum requirement changes to 4 ETH, then we would have 8 million or maybe more than 8 million, maybe 9 million or 10 million validators. If we want to get down to 100,000 validators, then the minimum requirement might have to go up to around 300 ETH.
So, it's a tradeoff. Ethereum has historically tried to be in the middle of that tradeoff. But if we can find any way to improve it, then we have extra stat points that we can choose to spend on reducing the minimum requirements, or on making it easier to run a node.
In fact, I now think that aggregating signatures isn’t even the main difficulty in running a node. In the beginning, we’ll probably focus more on reducing the minimum requirements, but eventually it will be about both.
So, there are two techniques that can improve both aspects.
One technique is to allow staking or allow finality without requiring every validator to sign. Basically, you need some kind of random sampling, random sampling of enough nodes to achieve significant economic security.
Now, I think we have more than enough economic security. The cost of conducting a 51% attack, in terms of the amount of ETH slashed, is one-third of 32 million ETH, which is about 11 million ETH. Who would spend 11 million ETH to destroy the Ethereum blockchain? Not even the US government.
These sampling techniques are similar to if you have a house, if the front door is protected by four layers of steel plates, but the windows are just a piece of shoddy glass that someone can easily break with a baseball bat. I think Ethereum is like this to some extent, if you want to do a 51% attack, you have to lose 11 million ETH. But in reality, there are many other ways to attack the protocol, and we really should strengthen these defenses more. So instead, if you have a subset of validators doing finality, then the protocol is still secure enough and you can really increase the level of decentralization.
The second technique is better signature aggregation. Instead of supporting 30,000 signatures per slot, you can do some advanced stuff like Starks, and eventually we might be able to support more than that. That's the first part.
The second part is to make running a node easier.
The first step is historical expiration. In fact, EIP-4444 has made a lot of progress in this regard.
The second step is stateless clients. Verkle has been around for a long time, and another possible option is to do a binary hash tree like Poseidon, Stark-friendly hash functions. Once you have this, you no longer need a hard disk to verify Ethereum blocks. Later you can also add a Type 1 ZKVM that can Stark-verify the entire Ethereum block, so that you can verify arbitrarily large Ethereum blocks by downloading data, or even data availability sampling data, and then you only need to verify a proof.
If you do that, it will be much easier to run a node. If you have stateless clients, one very annoying thing currently is that if you want to change your hardware or software setup, usually you either need to start from scratch and lose a day, or you need to do something very risky and put your keys in two places so that they get slahed, if we have stateless clients, you no longer need to do that.
You can simply start a new standalone client, close the old one, move the keys over, and start the new one. You will only lose one epoch.
Once you have ZKVM, the hardware requirements are basically reduced to almost zero.
So, the 32 ETH threshold and the difficulty of running nodes, both of these problems can be solved technically. I think there are a lot of other benefits to doing this, which will really improve our ability to increase people's individual staking, and will give us a better individual staking ecosystem and avoid the risk of staking centralization.
There are other challenges with proof of stake, such as risks associated with liquid staking, risks associated with MEV. These are also important issues that need to be considered. Our researchers are considering these.
Recovering from a 51% attack
I really started thinking about it seriously and critically. It’s amazing how many people don’t think about this topic at all and just treat it as a black box.
What would happen if there was a 51% attack?
Ethereum may suffer a 51% attack, Bitcoin may suffer a 51% attack, and a government may suffer a 51% attack, such as by bribing 51% of the politicians.
One problem is that you don’t want to rely solely on prevention, you want to have a recovery plan as well.
A common misconception is that people think 51% attacks are about reversing finality. People focus on this because this is something that Satoshi emphasized in the white paper. You can double spend, after I bought my private jet, I 51% attack, get my bitcoin back, and I can keep my private jet and fly around.
More realistic attacks might involve depositing money on exchanges and doing things like breaking DeFi protocols.
However, reversals aren’t actually the worst thing that could happen. The biggest risk we should be worried about is actually censorship. 51% of the nodes stop accepting blocks from the other 49% or any nodes that try to include a certain type of transaction.
Why is this the biggest risk? Because the finality reversal has Slash, there is immediate on-chain verifiable evidence that at least one-third of the nodes did something very, very wrong and they were punished.
In a censorship attack, this is not programmatically attributable, there is no immediate programmatic evidence to say who did something bad. Now, if you are an online node, if you want to see that a transaction was not included within 100 blocks, but we haven't even written software to do this kind of check,
Another challenge with censorship is that if someone wants to attack, they can do so by starting out by delaying transactions and blocks they don’t like by 30 seconds, then delaying them by a minute, then by two minutes, and you don’t even have consensus on when to respond.
So, I say, actually censorship is the greater risk.
There is an argument in blockchain culture that if an attack happens, the community will unite and they will obviously do a minority soft fork and cut off the attacker.
That might be true today, but it relies on a lot of assumptions about coordination, ideology, all kinds of other things, and it's not clear how true that will be in 10 years. So what a lot of other blockchain communities are starting to do is they're saying, well, we have things like censorship, we have these inherently more unattributable bugs. So, we have to rely on social consensus. So let's just rely on social consensus and be proud to admit that we're going to use it to solve our problems.
In fact, I advocate going in the opposite direction. We know that fully coordinating an automated response and automatic forking of a censorship-prone majority attacker is mathematically impossible. But we can get as close as we can.
You can create a fork that, based on some assumptions about network conditions, actually brings at least a majority of nodes online. The point I'm trying to make here is that what we actually want is to try to make the response to a 51% attack as automated as possible.
If you are a validator then your node should be running software that automatically forks the anti-censorship majority chain if it detects that transactions are being censored or certain validators are being censored, and all honest nodes will automatically coordinate on the same minority soft fork due to the code they run.
Of course, there is again the mathematical impossibility of the result, and at least anyone who was offline at the time would not be able to tell who was right and who was wrong.
There are a lot of limits, but the closer you get to that goal, the less work social consensus needs to do.
If you imagine what a 51% attack would actually look like, it wouldn't be like this, all of a sudden at some point in time, Lido, Coinbase, and Kraken would publish a blog post at 5:46 that basically says, hey guys, we're under review now.
What will actually happen is that you'll see a social media war at the same time, you'll see all kinds of other attacks at the same time. If in fact a 51% attack does happen, by the way, I mean, we shouldn't assume that Lido, Coinbase, and Kraken are going to be in power in 10 years. The Ethereum ecosystem is going to become more and more mainstream, and it needs to be very resilient to that. We want the social layer to be as lightly burdened as possible, which means we need the technical layer to at least present a clear winning candidate, and if they want to fork off a chain that's being censored, they should rally around a minority soft fork.
I am advocating that we do more research and have a very specific recommendation.
Proposal: Raise the Quorum threshold to 75% or 80%
I think the Quorum threshold can be raised from today’s two-thirds to around 75% or 80%.
The basic argument is that if a malicious chain, such as a censored chain, attacks, recovery becomes very, very difficult. However, on the other hand, if you increase the percentage of Quorum, what is the risk? If the Quorum is 80%, then instead of 34% of the nodes being offline stopping finality, 21% of the nodes being offline stopping finality.
This is risky. Let's see what this looks like in practice? From what I've seen, I think we've only had one incident where finality was down for about an hour due to over a third of the nodes being offline. And then, have there been any incidents where 20% to 33% of the nodes were offline? I think at most once, at least zero. Because in practice, very few validators are offline, I actually think that the risk of doing this is pretty low. The benefit is basically that the threshold that an attacker needs to reach is much higher, and in the case of a client vulnerability, the range of scenarios where the chain goes into safe mode is much higher, so people can really collaborate to figure out what went wrong.
If the threshold for Quorum goes from 67% to 80%, then assuming the percentage a client needs to achieve goes from 67% to 80%, then the value of a minority of clients or the value that a minority of clients can provide really starts to increase.
Other censorship concerns
The other censorship concerns, either the inclusion list, or some kind of alternative to the inclusion list. So, the whole multiple parallel proposer thing, if it works, could be even a replacement for the inclusion list. You need, either account abstraction, you need some kind of in-protocol account abstraction.
The reason you need it is because right now, smart contract wallets don't really benefit from the inclusion list. Smart contract wallets don't really benefit from any kind of censorship resistance guarantees at the protocol level.
If there is an in-protocol account abstraction, then they benefit. So there are a lot of things, actually a lot of these things have value in both the L2-centric vision and the L1-centric vision.
I think, of the different ideas that I talked about, about half are probably specifically for Ethereum focused on L2, but the other half are basically, for L2 as a user of the base layer of Ethereum and L1, or, like, direct-to-user applications as a user.
Use light clients everywhere
In a lot of ways, it's a little sad how we interact with the space, we're decentralized, we're trustless, who in this room runs a light client on their computer that verifies consensus? Very few. Who uses Ethereum by trusting Infura's browser wallet? In five years, I'd like to see the number of hands raised reversed. I'd like to see wallets that don't trust Infura for anything. We need to integrate light clients.
Infura can continue to provide data. I mean, if you don't have to trust Infura, that's actually good for Infura because it makes it easier for them to build and deploy infrastructure, but we have tools that remove the trust requirement.
What we can do is, we can have a system where the end user runs something like the Helios light client. It should actually run directly in the browser, verifying the Ethereum consensus directly. If he wants to verify something on-chain, like interact with the chain, then you just verify the Merkle proof directly.
If you do this, you actually gain a level of trustlessness in your interactions with Ethereum. That’s for L1. We also need an equivalent for L2.
On the L1 chain, there are block headers, there is state, there is a synchronization committee, and there is consensus. If you verify the consensus, if you know what the block header is, you can walk through the Merkle branch and see what the state is. So how do we provide light client security guarantees for L2s. The state root of L2 is there, and if it is a basic Rollup, there is a smart contract, and that smart contract stores the block header of L2. Or, if you have pre-confirmation, then you have a smart contract that stores who the pre-confirmer is, so you determine who the pre-confirmer is, and then listen to a two-thirds subset of their signatures.
So once you have the Ethereum headers, there's a fairly simple chain of trust, hashes, Merkle branches, and signatures that you can verify, and you can get light client validation. The same is true for any L2.
I’ve brought this up to people in the past, and a lot of times the response is, gosh, that’s interesting, but what’s the point? A lot of L2s are multisig. Why don’t we trust the multisig to verify the multisig?
Fortunately, as of last year, this is actually no longer true. Optimism and Arbitrum are in Rollup Phase 1, which means they actually have proof systems running on-chain, there is a security committee that can cover them in case of vulnerabilities, but the security committee needs to pass a very high voting threshold, like 75% of 8 people, Arbitrum will increase the size to 15. So, in the case of Optimism and Arbitrum, they are not just multisig, they have actual proof systems, and these proof systems actually work, at least have a majority power in deciding which chain is correct or wrong.
The EVM even goes a step further, I believe it doesn't even have a security committee, so it's completely trustless. We're really starting to move forward on that, and I know a lot of other L2s are moving forward on that as well. So L2 is more than just multisig, so the concept of light clients for L2 is actually starting to make sense.
Today we can already verify Merkle branches, we just need to write code, and tomorrow we will also be able to verify ZKVM, so you can fully verify Ethereum and L2 in your browser wallet.
Who wants to be a trustless Ethereum user in a browser wallet? Great. Who would rather be a trustless Ethereum user on their phone? From a Raspberry Pi? From a smartwatch? From the space station? We'll get to that, too. So what we need is the equivalent of an RPC configuration that contains not only which servers you're talking to, but also the actual light client verification instructions. That's something we can work towards.
Quantum-resistant strategies
The timeline for quantum computing is decreasing. Metaculous believes quantum computers will arrive in the early 2030s, while some believe it will be sooner.
So we need a quantum-resistant strategy. We do have a quantum-resistant strategy. There are four parts of Ethereum that are vulnerable to quantum computing, and each of them has a natural replacement.
The quantum-resistant alternative to Verkle Tree is Starked Poseidon Hash, or if we want to be more conservative, we can use Blake consensus signatures. We currently use BLS aggregate signatures, which can be replaced with Stark aggregate signatures. Blob uses KZG, and can use separate encoding Merkle tree Stark proofs. User accounts currently use ECDSA SECP256K1, which can be replaced with hash-based signatures and account abstraction and aggregation, smart contract wallet ERC 4337, etc.
Once we have that, users can set their own signature algorithm, and basically use hash-based signatures. I think we really need to start thinking about actually building hash-based signatures so that user wallets can easily upgrade to hash-based signatures.
Protocol simplification
If you want a strong base layer, the protocol needs to be simple. It shouldn't have 73 random hooks and some backward compatibility that exists because of some random stupid idea that some random guy named Vitalik came up with in 2014.
So there's value in trying to really simplify and start to really eliminate technical debt. Logs are currently based on bloom filters, they don't work very well, they're not fast enough, so there needs to be improvements to Log that add stronger immutability, and we've already done that in terms of statelessness, basically limiting the amount of state access per block.
Ethereum is currently an incredible combination of RLP, SSZ, and API. Ideally we should only use SSZ, but at least get rid of RLP, state, and binary Merkle trees. Once you have a binary Merkle tree, all of Ethereum is on the binary Merkle tree.
Fast finality, Single Slot Finality (SSF), cleaning up unused precompilers, such as the ModX precompiler, which often causes consensus errors, it would be great if we could remove it and replace it with performant solidity code.
Summarize
As a strong base layer, Ethereum has very unique advantages, including some advantages that Bitcoin does not have, such as decentralized consensus and significant research on 51% attack recovery.
I think there is a need to really build on those strengths. And also recognize and fix our weaknesses and make sure we're meeting very high standards. These ideas are completely compatible with the aggressive L1 roadmap.
One of the things I'm most pleased about with Ethereum and especially the core development process is that our ability to work in parallel has greatly improved. That's a strong point, we can actually work on a lot of things in parallel. So caring about these topics doesn't actually impact the ability to improve the L1 and L2 ecosystem. For example, improving the L1 EVM to make it easier to do cryptography. It's currently too expensive to verify a Poseidon hash in the EVM. 384-bit cryptography is also too expensive.
So there are some ideas on top of EOF, like SIMD opcodes, EVM max, etc. There is an opportunity to attach this high performance coprocessor to the EVM. This is better for Layer 2 because they can verify proofs more cheaply, and it is also better for Layer 1 applications because privacy protocols such as zk SNARKs are cheaper.
Who has used Privacy Protocol? Who wants to use Privacy Protocol and pay 40% instead of 80%? A lot more people. The second group can use it on Layer 2, while Layer 1 can get significant cost savings.
Ethereum's "Big Three" reunited
2024 is the 10th anniversary of Ethereum IC0. The 2024 EthCC invited the three former core founders of Ethereum, Vitalik Buterin, Joseph Lubin and Gavin Wood, to attend.
After Vitalik's speech, they were invited to take a group photo:
The Big Three shake hands again
Welcome to BlockBeats the BlockBeats official community:
Telegram subscription group: https://t.me/theblockbeats
Telegram group: https://t.me/BlockBeats_App
Official Twitter account: https://twitter.com/BlockBeatsAsia
