jakiro
ETHCC7 was held in Brussels recently, and the organizer invited Ethereum founder Vitalik to give a keynote speech.
It is worth noting that in 2024, it was the 10th anniversary of the Tapo IC0. After the Vitalik speech was over, the former Ethereum three core founders Vitalik Buterin, Joseph Lubin, and Gavin Wood again took a photo of the same frame.
This article is a keynote speech on ETHCC7, the founder of Ethereum Vitalik, and compiled 0xxz from the Bitchain Vision.
Theme
Strengthen L1:Optimize Ethereum to make it highly reliable, trustworthy, and no need to license .er 2 basic layer
Ethereum vision spectrum
In my opinion, there is a possible spectrum system that may play the role that may play in the ecosystem in the ecosystem in the ecosystem of Ethereum in the next five to ten years.You can see it as a spectrum from left to right.
On the left side of the spectrum, it basically tries to become a very simple foundation layer, basically just as the proof verification of all L2.Perhaps the ability to transfer ETH between different L2.But in addition, there are basically so many.
On the right side of the spectrum, it is basically focused on DAPPS that is mainly running on L1, and L2 is used only for some very specific and high -performance transactions.
There are some interesting options in the middle of the spectrum.I put Ethereum as the basic layer of L2 on the left.On the far left, I put an extreme version. The extreme version is that we completely abandon the executive client of the entire Ethereum. Only the consensus part is retained, and some zero -knowledge certification verifications are added.
I mean very extreme options on the left, and it can be a basic layer on the right, but you can also try to provide more functions for L2.An idea in this direction is to further reduce the SWAP time of Ethereum. It is currently 12 seconds and may fall to 2-4 seconds.The purpose of doing so actually makes the basic Rollups as the main way to operate L2 feasible.So now, if you want L2 to have a top user experience, you need to have your own pre -confirmation, which means that it is either a centralized sorter or your own decentralized sorter.If their consensus speed is accelerated, L2 will no longer need to do so.If you really want to enhance the scalability of L1, the demand for L2 will decrease.
So this is a spectrum.At present, I mainly pay attention to the version of the second left, but what I suggest here is also applicable to other visions, and the suggestions here will not actually hinder other vision.This is what I think is very important.
Ethereum’s robust advantage
A big advantage of Ethereum is that there is a huge and relatively decentralized pledge ecosystemEssence
On the left side of the figure above are all bitcoin mining pool computing power charts, and on the right is the Ethereum pledker chart.
Bitcoin computing power distribution is currently not very good. The two mining pools add up to more than 50%of the computing power, and the four mining pools are more than 75%.
The situation of Ethereum is actually better than the chart, because the second part of the gray part is actually not recognized, which means that it may be a combination of many people, and there may even be many independent pledges in it.The blue part of the Lido is actually a strange, loose coordinated structure, consisting of 37 different verificationers.Therefore, Ethereum actually has a relatively decentralized pledge ecosystem, which performs quite well.
We can make a lot of improvements in this area, but I think that this is still valuable.This is one of the unique advantages we can really build on it.
The robust advantages of Ethereum also include:
Have a multi -client ecosystem:There are Geth executing clients, as well as non -Geth execution clients, and non -Geth execution clients share even more than Geth execution clients.Similar situations also occur in the consensus client system;
Internationalized community:People in many different countries, including projects, L2, team, etc.;
Multi -center knowledge ecosystem:There are Ethereum Foundation, there are client teams, and even the RETH team like Paradigm has recently increased leadership in open source;
Culture that values these attributes
Therefore, the Ethereum ecosystem has these very powerful advantages as the basic layer.I think this is a very valuable thing and should not give up easily.I can even say that there are clear steps to further advance these advantages and even make up for our weaknesses.
Where does the Ethereum L1 not reach high standards, how to improve?
This is a public opinion survey I did about Farcaster about half a year ago: If you did not perform solo pledge, what stopped you from pledged SOLO?
I can repeat this problem at this venue. Who is pledged SOLO?Without SOLO pledge, who do you think the threshold for 32 ETH is the biggest obstacle. Who thinks that running a node is too difficult is the biggest obstacle. Who thinks that the biggest obstacle cannot be put in your ETH in the DEFI protocol at the same time?Who thinks the biggest obstacle is to worry that the private key must be placed on the node in the operation and is more likely to be stolen?
You can see, unanimously agreedThe first two major obstacles are: the minimum requirements of 32 ETH and the difficulty of node operationEssenceIt is always important to recognize this.
Many times when we start to discuss how to maximize the use of their mortgages in the DEFI protocol, we will find that a large number of people do not even use the DEFI protocol at all.So let’s focus on the main problems, what we can do to try to solve these problems.
From running a verification node, or in other words,Start with the threshold of 32 ETHEssenceIn fact, these two problems are related, because they are functions of the number of verificationrs in the PROOF of Stake.
Today we have about 1 million authenticants entities, and each entity has 32 ETH deposits, so if the minimum requirement is changed to 4 ETH, then we will have 8 million or may be more than 8 million, which may be 9 million, which may be 9 million, which may be 9 million, which may be 9 million, which may be 9 million, which may be 9 million.Or 10 million verifications.If we want to reduce to 100,000 verifications, the minimum requirements may rise to about 300 ETH.
Therefore, this is a balance.Ethereum history is trying to be in the middle of weighing.However, if we can find any ways to improve, then we will have additional statistics, we can choose to reduce the minimum requirements, or make it easier for running nodes.
In fact, now I think that aggregation signature is not even the main difficulty of running nodes.At the beginning, we may pay more attention to the minimum requirements, but in the end both will involve.
Therefore, there are two technologies that can improve these two aspects.
One technically allows pledge or final certainty without signed by each verification.Basically, you need some random sampling and random sampling nodes to achieve significant economic security.
Now, I think we have enough economic security.The cost of a 51%attack at a time, calculated based on the number of ETHs of Slash, is one -third of 32 million ETH, about 11 million ETH.Who would spend 11 million ETH destroying the Ethereum blockchain.Even the US government, no one wants.
These sampling techniques are similar to that if you have a house, if there are four -layer steel plate protection in the front door, but the window is just a inferior glass, others can use a baseball stick to easily break.I think Ethereum is like this to some extent. If you want to attack 51%, you must lose 11 million ETH.But in fact, there are many other methods of attack protocols, we really should really strengthen these protection.So on the contrary, if you have an authenticator of a subset, the protocol is still safe enough, and you can truly improve the level of decentralization.
The second technology is a better signature aggregation.You can do some high -end things such as Starks, not each slot supports 30,000 signatures. In the end, we may be able to support more signatures.This is the first part.
The second part is to make the running node easier.
The first step is the history of history. In fact, EIP-4444 has made many progress in this regard.
The second step is the stateless client.Verkle has been in it for a long time. Another possible choice is to make a binary hash tree similar to Poseidon, Stark’s friendly hash function.Once you have this, in order to verify the Ethereum block, you no longer need a hard disk.After that, you can also add a Type 1 ZKVM, which can be stark to verify the entire Ethereum block, so that you can download the data and even data available sampling data to verify the Ethereum block of any of the Italian, and then you only need to verify a certificate.
If you do this, running nodes will become easier.If there is a state client, a very annoying thing is that if you want to change the hardware or software settings, you usually need to start from scratch and lose a day, or you need to do some very dangerous things, put the key on two in two, two in two, and put the key on two two.In this place, this will be slad. If we have a state client, you no longer need to do so.
You can simply start a new independent client, close the old one, move the key over, and start new.You only lose one epoch.
Once there is ZKVM, the demand for hardware has basically dropped to almost zero.
so,The threshold of 32 ETH and the difficulty of node operation can be solved technically.I think there are many other benefits to doing so. This will really improve our ability to improve people’s separate pledges. It will give us a better pledge ecosystem and avoid pledge risk.
There are other challenges of equity proof, such as risks related to migrant pledge, MEV -related risks.These are also important issues that need to be considered.Our researchers are considering these.
Recovery from 51%attack
I really started thinking seriously and rigorously.Surprisingly, many people don’t think about this topic at all, just treat it as a black box.
What will happen if you really encounter a 51%attack?
Ethereum may encounter 51%attack, Bitcoin may suffer 51%attack, and a government may also encounter 51%attack, such as buying 51%of politicians.
One problem is that you don’t want to rely on prevention just, and you also want to have a recovery plan.
A common misunderstanding is that people think that 51%attack is about reversing the final certainty.People pay attention to this because this is what Nakamoto emphasizes in the white paper.You can make a double expense. After I bought a private jet, I made 51%attack, took my Bitcoin, and could retain my private plane and fly everywhere.
In fact, more realistic attacks may involve things like deposits on the exchange and such as destroying the DEFI protocol.
But reversing is not the worst thing.The greatest risk we should worry about is actually censorship.51%of nodes stop receiving blocks from 49%of other nodes or any attempt to include some types of transactions.
Why is this the biggest risk?Because the final definition reversal is SLASH, there is evidence that can be verified on the chain immediately, at least one -third of nodes do some very, very wrong things, and they are punished.
In the censorship attack, this is not attributable to the program. There is no immediately procedural evidence to say who has done bad things.Now, if you are an online node, if you want to see that a transaction is not included in 100 blocks, but we do not even write software for this kind of inspection,
Another challenge for censors is that if anyone wants to attack, they can do this. They start from delayed transactions and blocks that they don’t like for 30 seconds, then delay for one minute, and then delay for two minutes. You don’t even have consensus when to respond.
Therefore, I said that it is actually a greater risk.
There is a argument in the blockchain culture that if the attack occurs, the community will be united, and they will obviously make a few soft forks and reduce the attackers.
This may be true today, but this depends on many assumptions about coordination, ideology, and various other things, and it is not clear how real such things will be.Therefore, many other blockchain communities began to do. They said that we have things like reviewing, and there are more incompetent errors in nature.Therefore, we must rely on social consensus.Therefore, let us only rely on social consensus and proudly acknowledge that we will use it to solve our problems.
In fact, I advocate advancing in the opposite direction.We know that most attackers who are being reviewed with automatic response and automatic splitrs are mathematics.But we can try to get closer to this.
You can create a fork, based on some assumptions about network conditions, in fact bring at least most of the online nodes.The argument I want to convey here is that what we actually want is to try to make the response to 51%as much as possible.
If you are a verification person, then your node should run the software,If it detects that the transaction is reviewed or some verifications are reviewed, it will automatically conduct counter -examination of most chains. All honest nodes will automatically coordinate on the same few soft forks because they run the code.
Of course, there is a mathematical impossible result again. At least anyone who is offline at that time will not be able to distinguish who is right and who is wrong.
There are many restrictions, butThe closer to this goal, the less the social consensus needs to do.
If you imagine the actual situation of 51%attack.It will not be like below. Suddenly at a certain point in time, Lido, Coinbase, and Kraken will publish blog posts at 5:46. Basically, hey guys are now reviewing.
The actual situation that will happen may be that you will see a social media war at the same time, and you will see various other attacks at the same time.If 51%of the attack does happen, by the way, I mean, we should not assume that lido, coinbase, and Kraken will be in power within 10 years.The Ethereum ecosystem will become more and more mainstream, and it needs to have a strong ability to adapt to this.We hope that the burden of society is as light as possible, which means that we need the technical layer and put forward at least one obvious winning candidate. If they want to split out from a chain that is being reviewed, they should gather on a few soft split bits on a few soft splits forks.superior.
I advocate more research and make a very specific suggestion.
Proposal: increase the Quorum threshold to 75 % or 80 %
In my opinion, the threshold for the threshold that is commonly used in a distributed system to ensure data redundancy and ultimate consistency in a distributed system can be increased from two -thirds of today to 75 % or 80 % today.about.
The basic argument is that if the malicious chain, such as the censorship chain to attack, recovery will become very very difficult.However, on the other hand, if you increase the proportion of Quorum, what is the risk?If the Quorum is 80 %, it can stop the final certainty without a 34 % node offline, but the 21 % node is offline to stop the final certainty.
This is risky.Let’s see what will happen in practice?Judging from what I know, I think we only stopped for about one hour due to more than one -third of the nodes of more than one -third of nodes.Then, is there any incident involving 20 % to 33 % of nodes offline?I think it is up to once, at least zero.Because in practice, there are few verifications offline, I actually think that the risk of doing this is quite low.Basically, the income is that the threshold that attackers need to reach are greatly improved, and when the client has vulnerabilities, the scope of the chain entering the security mode has greatly increased, so people can really cooperate to find out the problem.
If the threshold of the Quorum increases from 67 % to 80 %, then assuming the proportion of a client that needs to be achieved from 67 % to 80 %, the value of a few clients or the value that a few clients can be provided by a small number of clients really begin to increase.
Other censorship concerns
Other censorship concerns, either include a list, or an alternative to the list.Therefore, if the entire polyphonic proposal, if it is valid, it may even become a alternative to the list.You need it, or the account is abstract, you need an account abstraction in a certain protocol.
The reason you need it is that now, the smart contract wallet does not really benefit from the list.The examination resistance guarantee of any kind of protocol layer, the smart contract wallet has not really benefited.
If the account in the agreement is abstract, they will benefit.Therefore, there are many things. In fact, many these things are valuable in the vision of the center of L2 and the vision of the center of L1.
I think that in the different ideas I talked about, about half may be dedicated to Ethereum to focus on L2, but the other half is basically suitable for L2 as users and L1 as the basic layer of Ethereum, or like directly facing usersApplication as a user.
Use light clients everywhere
In many ways, the way we interact with space is a bit sad. We are decentralized. We do not need to trust. Who in this room runs a light client that verifies consensus on his computer?rare.Who uses Ethereum by trusting Infura’s browser wallet?Within five years, I hope to see the number of hand raising my hand in turn.I hope to see wallets that do not trust Infura.We need to integrate light clients.
Infura can continue to provide data.I mean, if you don’t need to trust Infura, it is actually good for Infura, because it makes them easier to build and deploy infrastructure, but we have tools to remove trust requirements.
What we can do is that we can have a system that runs like the Helios light client.It should actually run directly in the browser and directly verify the Ethereum consensus.If he wants to verify things on the chain, like interacting with the chain, then you only need to directly verify the Merkel proof.
If you do this, you actually get a certain degree of trust in the interaction with Ethereum.This is for L1.In addition, we need L2 equivalent schemes.
On the L1 chain, there are block heads, state, synchronous committees, and consensus.If you verify the consensus, if you know what the block head is, you can walk through the Merkel branch and see what the status is.So how do we provide light client security guarantee for L2S.The state of L2 is there, if it is the basic rollup, there will be a smart contract, and the smart contract stores the block header of L2.Or, if you have a pre -confirmation, then you have a smart contract storage pre -confirmor, so you are sure who the pre -confirmor is, and then monitor the two -thirds of their signatures.
Therefore, once you have the Ethereum block head, there is a very simple chain of trust, hash, Merkel branch and signature, you can verify, and you can get light client verification.The same is true of any L2.
I have mentioned this problem to people in the past. Many times people’s reactions are, God, this is very interesting, but what does it mean?Many L2 are multiple signatures.Why do we do not trust multiple signatures to verify multiple signatures?
Fortunately, as of last year, this was no longer a fact.Optimism and Arbitrum are in the first stage of Rollup, which means that they actually have a proof system that runs on the chain. There is a security committee that can cover them when there is vulnerabilities, but the Security Committee needs to pass a very high voting threshold valueFor example, 75%of 8 people, the size of Arbitrum will increase to 15.Therefore, in the case of Optimism and Arbitrum, they are not just multiple signatures, they have a practical proof system, and these proof systems are actually functional, at least in determining which chain is correct or wrong.
EVM is even one step further. I believe it is not even a security committee, so it does not need to trust.We really started to advance in this area, and I know that many other L2s are also advancing.Therefore, L2 is not just a multi -signature, so the concept of L2’s light client is actually meaningful.
Today we can verify the branch of Merkel and only need to write code.Tomorrow, we can also verify ZKVM, so you can fully verify Ethereum and L2 in the browser wallet.
Who wants to be a Utano user in the browser wallet?marvelous.Who is more willing to become a Utano users who do not need to trust on their mobile phones?What about the Raspberry Pi?What about smart watches?What about the space station?We will also solve this problem.Therefore, what we need is an equivalent of an RPC configuration, which not only contains which servers you are talking with, but also the actual light client verification instruction.This is the goal we can work hard.
Anti -quantum strategy
The time for quantum calculation is decreasing.Metaculous believes that quantum computers will come in the early 2030s, and some people think that time is earlier.
So we need an anti -quantum strategy.We do have an anti -quantum strategy.There are four parts of quantum computing in Ethereum, and each part has natural alternatives.
Verkle Tree’s quantum resistance replacement is Starked Poseidon Hash, or if we want to be more conservative, we can use Blake consensus signature. We currently use BLS aggregation signatures to replace the Stark aggregation signature.BLOB uses KZG to prove it with separate encoding Merkel tree Stark.User account currently uses ECDSA SECP256K1, which can be replaced with hash -based signatures and account abstraction and aggregation, smart contract wallet ERC 4337, etc.
Once these are, users can set their signature algorithms, which can basically use hash -based signatures.I think we really need to start considering the actual construction -based signature, so that user wallets can easily be upgraded to hash -based signatures.
Simplified protocol
If you want a strong basic layer, the agreement needs to be simple.It should not have 73 random hooks and some random people named Vitalik’s random stupidity proposed by random people in 2014.
So it is valuable to try to really simplify and start to truly eliminate technical debt.The log is currently based on the Bloom filter. They are not too working or fast enough, so LOG improvements need to be made to increase stronger non -tampering. We have already done so in terms of no state.Visits.
Ethereum is currently an incredible collection, with RLP, SSZ, and API. Ideally, we should only use SSZ, but at least to remove RLP, state and binary Merkel tree, once the binary Merkel tree is availableThen all Ethereum is on the binary Merkel tree.
Fast final determination, Single Slot Finality (SSF), cleaning up unused pre -edited translations, such as MODX pre -editing translations, often leads to consensus errors. If we can delete it and replace it with high -performance Solidity code, it is good.
Summarize
Ethereum, as a strong foundation, has a very unique advantage, including the advantages of some Bitcoin, such as consensus decentralization, such as a significant study of 51%attack recovery.
I think it is necessary to truly strengthen these advantages.At the same time, understand and correct our shortcomings to ensure that we reach very high standards.These ideas are completely compatible with the positive L1 route.
One of the most satisfactory things I am the most satisfactory about Ethereum, especially the core development process, is that our parallel working ability has greatly improved.This is a strong point, and we can actually work in parallel.Therefore, care about these topics does not actually affect the ability to improve the L1 and L2 ecosystems.For example, improve L1 EVM, making it easier to perform cryptography.Currently verifying the Poseidon hash is too expensive in EVM.384 -bit cryptography is too expensive.
So there are some ideas on EOF, such as SIMD operating code, EVM MAX, etc.Have the opportunity to attach this high -performance collaborator to EVM.This is better for Layer 2, because they can verify proves cheaper, and it is better for Layer 1 applications, because privacy protocols such as ZK SNARKS are cheaper.
Who has used a privacy agreement?Who wants to use a privacy agreement to pay 40, not 80?More people.The second group can be used on Layer 2, and Layer 1 can get significant cost savings.
Ethereum “Three Giants” reunited again
In 2024, the 10th anniversary of the Ethereum IC0, EthCC invited the former Ethereum core founder Vitalik Buterin, Joseph Lubin and Gavin Wood all the time.
After the vitalik speech, they were invited to take a photo in the same frame:
Three giants shake hands again
