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, and after Vitalik’s speech, the three core founders of Ethereum, Vitalik Buterin, Joseph Lubin, and Gavin Wood, reunited for a photo to commemorate the occasion. This article is a translation of Vitalik’s keynote speech at EthCC7 by Jinse Finance 0xxz.
Speech Topic: Strengthening L1: Optimizing Ethereum to Become a Highly Reliable, Trustworthy, and Permissionless Layer 2 Base Layer.
I believe that there is a possible spectrum of different roles that the Ethereum base layer could play in the ecosystem in 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 essentially tries to be a very minimalistic base layer, essentially only serving as the proof validator for all L2s. It may also provide the ability to transfer ETH between different L2s. But other than that, that’s pretty much it.
On the right side of the spectrum, it basically refocuses on dApps running primarily on L1, with L2 being used only for very specific and high-performance transactions.
There are some interesting options in the middle of the spectrum. I place Ethereum as the base layer for L2 on the second left. On the far left, I placed an extreme version where we completely abandon the entire execution client part of Ethereum and only keep the consensus part, while adding some zero-knowledge proof validators, essentially turning the entire execution layer into a Rollup.
By extreme, I mean very extreme options on the left, and on the right, it can be a base layer but also try to provide more functionality for L2s. One idea in this direction is to further reduce Ethereum’s swap time, which is currently 12 seconds, to maybe 2-4 seconds. The purpose of this is to make the basic rollups a viable way for L2 to operate. So now, if you want top-level user experience for L2, you need to have your own pre-confirmation, which means either a centralized sequencer or your own decentralized sequencer. If their consensus speed increases, then L2 will no longer need to do this. If you really want to enhance the scalability of L1, the demand for L2 will also decrease.
So, this is a spectrum. Currently, I am mainly focused on the version on the second left, but the things I suggest here are also applicable to other visions, and the suggestions here do not actually hinder other visions. This is something I think is important.
One of Ethereum’s major advantages is its robust staking ecosystem, which is large and relatively decentralized. The distribution of Bitcoin’s mining power is currently not very good, with two mining pools accounting for over 50% of the power and four mining pools accounting for over 75%. The situation with Ethereum is actually better than what the chart shows because the second largest portion of the gray area is actually unidentified, which means it may be a combination of many people or even many independent stakers. The blue part, Lido, is actually a strange and loosely coordinated structure consisting of 37 different validators. So Ethereum actually has a relatively decentralized staking ecosystem and performs quite well. We can make many improvements in this regard, but I think it is still valuable to recognize this. This is one of the unique advantages that we can really build on.
Ethereum’s robustness advantage also includes:
– Having a multi-client ecosystem: there are both Geth and non-Geth execution clients, with non-Geth execution clients even outnumbering Geth execution clients. A similar situation also occurs in the consensus client system.
– An international community: people from many different countries, including projects, L2s, teams, etc.
– A multi-centered knowledge ecosystem: there is the Ethereum Foundation, client teams, and even increasing leadership in open source, such as the Reth team from Paradigm.
– A culture that values these attributes.
So, the Ethereum ecosystem as a base layer already has these very strong advantages. I think this is a valuable thing that should not be easily abandoned. I would even say that there are clear steps that can be taken to further advance these advantages and even address our weaknesses.
Where Ethereum L1 Falls Short of High Standards and How to Improve?
This is a survey I conducted about half a year ago on Farcaster: What prevents you from solo staking if you have not done solo staking?
I can repeat this question here. Who here is doing solo staking? If you are not doing solo staking, who thinks the 32 ETH requirement is the biggest barrier, who thinks running a node is too difficult is the biggest barrier, who thinks the biggest barrier is not being able to simultaneously use your ETH in DeFi protocols, and who thinks the biggest barrier is the concern of having to put your private keys on a running node that can be more easily stolen?
You can see that the top two agreed-upon barriers are the 32 ETH requirement and the difficulty of running a node. It is always important to recognize this.
Many times when we start delving into how to maximize the ability for people to reuse their collateral in DeFi protocols, we find that there are a lot of people who are not even using DeFi protocols at all. So let’s focus on the main issues and see what we can do to try to address these problems.
Starting from running a validating node or, in other words, starting from the 32 ETH threshold. In fact, these two issues are related because they are both a function of the number of validators in Ethereum’s Proof of Stake (PoS).
Today we have about 1 million validator entities, each with a 32 ETH deposit, so if the minimum requirement is changed to 4 ETH, then we would have about 8 million or possibly over 8 million, maybe 9 million or 10 million validators. If we want to reduce it to 100,000 validators, then the minimum requirement may have to increase to around 300 ETH.
So, this is a trade-off. Ethereum has historically tried to be in the middle of this trade-off. But if we can find any improvements, then we will have additional data points to choose from to reduce the minimum requirement or make running a node easier.
Actually, I don’t think aggregated signatures are even the main difficulty of running a node. Initially, we may focus more on reducing the minimum requirement, but eventually, both will be involved.
So, there are two techniques that can improve these two aspects.
One technique is to allow staking or finality without requiring every validator to sign, essentially you need some kind of random sampling, sampling enough nodes to achieve significant economic security without needing every validator to sign.
Now, I think we have far more than enough economic security. The cost of performing a 51% attack, calculated in terms of ETH slashed, is one-third of 32 million ETH, which is about 11 million ETH. Who would spend 11 million ETH to attack the Ethereum blockchain? Even the US government wouldn’t.
These sampling techniques are similar to, if you have a house and the front door has four layers of steel plate protection, but the windows are just made of cheap glass that can easily be broken with a baseball bat. I think Ethereum is somewhat like that to some extent, if you want to perform a 51% attack, you have to lose 11 million ETH. But in reality, there are many other ways to attack the protocol and we should really be strengthening those protections. 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. You can do some advanced things like Starks, where instead of each slot supporting 30,000 signatures, eventually, we may be able to support more signatures. That’s the first part.
The second part is making running a node easier.
The first step is historical expiry, which has made a lot of progress, actually EIP-4444.
The second step is statelessness. Verkle has been around for a long time, and another possible option is to do a binary hash tree like Poseidon, a Stark-friendly hash function. Once you have this, you no longer need a hard drive to verify Ethereum blocks. After that, you can add a Type 1 ZKVM that can Stark verify the entire Ethereum block, so you can verify arbitrarily large Ethereum blocks by downloading data, even data availability sampling data, and then you only need to verify one proof.
If this is done, running a node will become much easier. If there is a stateless client, currently one very annoying thing is that if you want to change hardware or software settings, usually you either have to start from scratch and lose a day or do some very dangerous things like putting the keys in two places, which can be slashed. If we have a stateless client, you no longer need to do this.
You can simply start a new independent client, shut down the old one, move the keys over, and start the new one. You only lose one epoch.
Once we have ZKVM, the hardware requirements basically drop to almost zero.
So, the 32 ETH threshold and the difficulty of running a node, both of these issues can be addressed technically. I think there are many other benefits to doing this, it will really improve our ability to stake individually, it will give us a better individual staking ecosystem, and it will mitigate centralization risks in staking.
Proof of Stake has other challenges as well, such as liquidity staking-related risks and MEV-related risks. These are also important issues that need to be further considered. Our researchers are looking into these.
Recovering from a 51% Attack
I have really started to think about this seriously and rigorously. Surprisingly, many people don’t even think about this topic and just treat it as a black box.
What would happen if a 51% attack actually occurred?
Ethereum could experience a 51% attack, Bitcoin could experience a 51% attack, and even a government could experience a 51% attack, like buying off 51% of politicians.
One question is, you don’t want to rely solely on prevention, you also want a recovery plan.
A common misconception is that people think a 51% attack is about reversing finality. People focus on this because it’s something that Satoshi emphasized in the whitepaper. You can double-spend, buy a private jet, perform a 51% attack, get back your Bitcoin, and still keep your private jet and fly around.
The actual more realistic attacks may involve depositing on exchanges and things like breaking DeFi protocols.
But, reversibility is not actually the worst thing. The biggest risk we should be concerned about is censorship. 51% of nodes stopping to accept blocks or any attempts by the 49% of nodes to include certain types of transactions.
Why is this the biggest risk? Because finality reversal has Slash, there is immediate on-chain verifiable evidence, at least one-third of the nodes have done something very, very wrong and they are punished.
While in censorship attacks, it is not procedurally attributable, there is no immediate procedural evidence to say who did something wrong. Now, if you are an online node and you want to see that a certain transaction has not been included in 100 blocks, but we don’t even have software written to do that check,
Another challenge of censorship attacks is that if someone wants to attack, they can do it by delaying transactions and blocks they don’t like for 30 seconds, then delay for a minute, then delay for two minutes, and you don’t even have consensus on when to respond.
So, I say actually censorship is the bigger risk.
There is an argument in blockchain culture that if an attack occurs, the community will unite and they will do a minority soft fork and cut off the attacker.
This may be true today, but it relies on a lot of assumptions about coordination, ideology, various other things, and it’s not clear how true this will be in 10 years. So, many other blockchain communities are starting to do things where they say, we have things like censorship, we have these essentially more unattributable errors. Therefore, we have to rely on social consensus. Therefore, let’s just rely on social consensus and proudly admit that we will use it to solve our problems.
Actually, I advocate going in the opposite direction. We know that it is mathematically impossible to fully coordinate an automatic response and an automatic minority fork for an ongoing censorship attack. But we can try to get as close to that as possible.
You can create a system where if you have 51% of online nodes that are doing something very, very wrong, you can have the remaining 49% of nodes automatically fork off and form a new consensus. This is a very powerful tool because it allows you to recover from censorship attacks, and it also allows you to recover from things like bugs in the consensus code.
So, in conclusion, we should not only focus on prevention but also have a recovery plan. We should be prepared for the possibility of attacks and have mechanisms in place to respond and recover.A fork based on certain assumptions about network conditions actually brings at least most of the online nodes. The argument I want to convey here is that what we actually want is to automate the response to a 51% attack as much as possible.
If you are a validator, your node should run software that automatically counter-scrutinizes most chains if it detects transactions being censored or certain validators being censored. All honest nodes will automatically coordinate on the same minority soft fork due to the code they run.
Of course, there are mathematical impossibility results again, at least no one who was offline at the time will be able to tell who is right and who is wrong.
There are many limitations, but the closer we get to this goal, the less work social consensus needs to do.
If you imagine how a 51% attack would actually occur. It wouldn’t happen like this, suddenly at some point in time, Lido, Coinbase, and Kraken would publish blog posts at 5:46 am saying, basically, “Hey guys, we’re censoring now.”
The actual scenario would probably involve a social media war and various other attacks happening simultaneously. If a 51% attack actually occurred, by the way, and I mean, we shouldn’t assume that Lido, Coinbase, and Kraken will be in power for the next 10 years. The Ethereum ecosystem will become more and more mainstream, and it needs to be resilient to that. We want the burden of the social layer to be as light as possible, which means we need the technical layer to at least propose an obvious winning candidate, and if they want to fork out of a censoring chain, they should coordinate on a minority soft fork.
I advocate for more research and a very specific proposal.
Proposal: Raise the Quorum threshold to 75% or 80%.
I believe that the Quorum threshold could be raised from the current two-thirds to around 75% or 80%.
The basic argument is that if a malicious chain like a censoring chain is attacking, recovery would become very, very difficult. However, on the other hand, what is the risk of increasing the Quorum threshold? If the Quorum is 80%, then finality could be stopped not by 34% of nodes being offline, but by 21% of nodes being offline.
There is risk. Let’s see how it would play out in practice. From what I know, there was only one instance where finality was stopped for about an hour due to more than one-third of nodes being offline. Then, were there any instances involving 20% to 33% of nodes being offline? I think at most once, and at least zero times. Because in practice, validators are rarely offline, I actually think the risk of doing this is quite low. The benefit is basically that the threshold an attacker needs to reach is significantly higher, and the range of scenarios where the chain goes into security mode in the event of a client bug is significantly increased, so people can really work together to find out what’s wrong.
If the Quorum threshold is raised from 67% to 80%, then the proportion a client needs to reach would be increased from 67% to 80%, and the value or the value that a minority client can provide would truly start to increase.
Other censorship concerns involve inclusion lists or some alternative to inclusion lists. So, the whole thing with multiple parallel proposers, if it works, could even become an alternative to inclusion lists. You need either account abstraction, you need some kind of account abstraction within the protocol.
You need it because right now, smart contract wallets don’t really benefit from inclusion lists. Any guarantee of censorship resistance at the protocol layer does not really benefit smart contract wallets.
If there is account abstraction within the protocol, then they would benefit. So, there are many things, a lot of these things are valuable both in the L2-centric vision and the L1-centric vision.
I think in the various ideas I’m talking about, about half of them are specifically targeted towards Ethereum’s focus on L2, but the other half is basically applicable both to L2 as the Ethereum base layer and to applications that are directly user-facing.
Widespread use of light clients.
In many ways, the way we interact with the space is a bit sad. We’re decentralized, we’re trustless, who in this room is running a light client that validates consensus on their computer? Few. Who is using Ethereum through a browser wallet that trusts Infura? I hope to see the number of hands raised change in the next five years. I hope to see wallets that don’t trust anything about Infura. We need to integrate light clients.
Infura can continue to provide data. I mean, if you don’t need 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 to remove the trust requirement.
What we can do is have a system where end users run something like a Helios light client. It should actually run directly in the browser and validate Ethereum consensus directly. If they want to interact with something on-chain, like interacting with the chain, then you would just validate Merkle proofs directly.
By doing this, you actually achieve a certain level of trustlessness in interacting with Ethereum. This is for L1. Additionally, we need the equivalent for L2 solutions.
On L1, there are block headers, state, sync committees, consensus. If you validate the consensus, if you know what the block headers are, you can walk the Merkle branch and see what the state is. So, how do we provide light client security guarantees for L2s? The L2’s state root is there, if it’s a basic Rollup, there’s a smart contract that stores the L2’s block headers. Or, if you have precommits, then you have a smart contract that stores who precommitted, so you know who precommitted and then you listen for a two-thirds subset of them signing.
So, once you have Ethereum block headers, there’s a fairly simple trust chain, a hash, a Merkle branch, and a signature that you can validate, and you can get light client validation. The same goes for any L2.
In the past, when I brought up this idea to people, a lot of times the reaction is, “Oh, that’s interesting, but what’s the point?” A lot of L2s are just multisig. Why don’t we trust the multisig to validate the multisig?
Luckily, that’s actually no longer true as of last year. Optimism and Arbitrum are in the first phase of Rollup, which means they actually have proof systems running on-chain, and there’s a security committee that can cover them in case of bugs, but the security committee requires a very high voting threshold, like 75% of 8 people in the case of Arbitrum, which will scale up to 15 people. So, in the case of Optimism and Arbitrum, they’re not just multisig, they have actual proof systems, and these proof systems actually have power in determining which chain is right or wrong, at least in terms of the majority.
The EVM goes even further, I believe it doesn’t even have a security committee, so it’s fully trustless. We’re really starting to make progress in this regard, and I know many other L2s are also pushing forward. So, L2 is not just multisig, so the concept of light clients for L2s actually starts to make sense.
Today, we can already validate Merkle branches with just a bit of code. Tomorrow, we can also validate zkVM, so you can fully validate Ethereum and L2 in a 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? On a Raspberry Pi? On a smartwatch? On a space station? We’ll solve that problem too. So, what we need is an equivalent of an RPC configuration that includes not just which servers you’re talking to, but also the actual light client validation instructions. That’s the goal we can work towards.
Quantum Resistance Strategy
The time for quantum computing is decreasing. Metaculous believes that quantum computers will arrive in the early 2030s, while others believe it will be even sooner.
So, we need a quantum resistance strategy. And we do have a quantum resistance strategy. There are four parts of Ethereum that are vulnerable to quantum computing, and each part has a natural alternative.
The quantum-resistant alternative to the Verkle Tree is Starked Poseidon Hash, or if we want to be more conservative, we can use Blake Consensus Signature. Currently, we use BLS aggregate signatures, which can be replaced with Stark aggregate signatures. The Blob uses KZG, which can be replaced with a separable encoding Merkle tree and Stark proofs. User accounts currently use ECDSA SECP256K1, which can be replaced with hash-based signatures and account abstraction and aggregation, such as ERC 4337 for smart contract wallets.
Once we have these, users can set their own signature algorithm and basically use hash-based signatures. I think we really need to start thinking about building actual hash-based signatures so that user wallets can easily upgrade to hash-based signatures.
Protocol Simplification
If you want a robust base layer, the protocol needs to be simple. It shouldn’t have 73 random hooks and backward compatibility due to some random stupid idea proposed by someone named Vitalik in 2014.
So, it’s valuable to try to truly simplify, to really eliminate technical debt. Currently, logs are based on Bloom filters, they don’t work well and they’re not fast enough, so there needs to be improvements in logs to increase immutability. We’re already doing this in statelessness, essentially limiting the amount of state access per block.
Ethereum is currently an incredible collection of things, with RLP, SSZ, APIs, ideally we should just use SSZ, but at the very least we should get rid of RLP, state and binary Merkle trees, once there’s a binary Merkle tree, then all of Ethereum is on a binary Merkle tree.
Fast finality, Single Slot Finality (SSF), cleaning up unused precompiles like the ModX precompile that often leads to consensus errors, if we can remove it and replace it with high-performance Solidity code, that would be great.
Summary
Ethereum as a robust base layer has very unique advantages, including some that Bitcoin lacks, such as decentralized consensus and significant research on recovering from a 51% attack.
I believe it is necessary to truly strengthen these advantages. At the same time, we need to recognize and address our shortcomings to ensure that we meet very high standards. These ideas are fully compatible with a positive L1 roadmap.
One of the things I’m most satisfied with about Ethereum, especially the core development process, is that our ability to work in parallel has greatly improved. It’s a strength, and we can actually work on many things in parallel. So, caring about these topics doesn’t actually hinder our ability to improve the L1 and L2 ecosystems. For example, improving the L1 EVM to make it easier to do cryptography. Currently, validating Poseidon hashes in the EVM is too expensive. 384-bit cryptography is also too expensive.
So, there are ideas on top of EOF, such as SIMD opcodes, EVM max, etc. There’s an opportunity to attach this high-performance coprocessor to the EVM. This is better for Layer 2s because they can validate proofs more cheaply, and it’s also better for Layer 1 applications because privacy protocols like zk-SNARKs become cheaper.
Who has used privacy protocols? Who would prefer to pay 40 fees instead of 80 fees for using a privacy protocol? More people. The second group can use it on Layer 2, and Layer 1 can achieve significant cost savings.
2024年 is the 10th anniversary of Ethereum ICO, and the EthCC in 2024 invited all three founders of Ethereum, Vitalik Buterin, Joseph Lubin, and Gavin Wood, to attend.
After Vitalik’s speech, they were invited to take a group photo:
Three giants reunited.
Tags:
DeFi
Gavin Wood
Joseph Lubin
Vitalik
Vitalik Buterin
Ethereum
Source link:
https://www.jinse.cn/blockchain/3691362.html
Note: The above translation is a professional translation of the news article.