Vitalik's long article review: those Ethereum "unparalleled roads"

Wu Shuo blockchain 2022-04-05 01:47:46 阅读数:564

vitalik long article review ethereum

author :Vitalik, Founder of Ethereum

The original title :《The roads not taken

translate :Mary Ma, Wu said blockchain

The Ethereum development community made many decisions in the early stages of Ethereum , These decisions have had a huge impact on the development trajectory of the project . In some cases , Ethereum developers make conscious decisions , Make improvements where we think bitcoin has problems . Elsewhere , We're creating something new , We just have to come up with something to fill the gap , But there are many things to choose from . There are other places , We need to make a trade-off between something simpler and something more complex . occasionally , We will choose something simpler , But sometimes , We also choose more complex things .

This article will focus on these route intersections of Ethereum in my memory . Many of these functions have been seriously discussed in the core development circle ; Some have hardly been considered , But maybe you really should think about . But even so , We still need to see what a different Ethereum would look like , And what we can learn from it .

Should we adopt a simpler PoS Mechanism ?

Ethereum is about to merge Gasper PoS Mechanism is a complex system , But it's also a very powerful system . Some of its properties include :

  • Very powerful single block confirmation : Once the transaction is included in the block , Usually in seconds , The block will be finalized , Unless a large number of nodes are dishonest , Or extreme network delays , Otherwise it cannot be reversed .
  • Economic finality : Once a block is finally confirmed , It cannot be reversed , Unless the attacker can withstand the loss of millions ETH Be forfeited .
  • Very predictable rewards : The verifier is at each epoch(6.4 minute ) Can be reliably rewarded .
  • Support a very high number of validators : Unlike most other chains with these properties , The Ethereum beacon chain supports hundreds of thousands of validators ( for example :Tendermint Provides faster finality than Ethereum , But it only supports hundreds of validators )

But creating a system with these characteristics is difficult . It takes years of research , Years of failed experiments , It usually takes a lot of effort , The final output is quite complex .


If our researchers don't need to worry about so much consensus , Have more free thinking time , Then maybe , Just maybe ,rollups Can be in 2016 It was invented in . This led us to think : We should, really PoS Ask for such a high standard ? Because even a simpler and weaker PoS It's better than PoW The current situation of has been greatly improved .

Many people have a misunderstanding , Think PoS It's complicated in itself , But there are many PoS The algorithm is almost the same as Nakamoto PoW As simple as consensus .NXT Of PoS since 2013 It has existed since , It was also a ready-made candidate ; Although it has some problems , But these problems are easy to fix , We can 2017 year , Even from the beginning, there is a reasonable and feasible PoS.Gasper The reason why it is more complex than these algorithms , Just because it tries to accomplish much more than they do . however , If we don't aim too high in the beginning , We can focus on achieving a more limited set of goals .

in my opinion , From the beginning PoS It's a mistake ;PoW It is helpful to expand the initial circulation distribution and make Ethereum more accessible , And can encourage the fan community . But in 2017 year , even to the extent that 2020 year , Switch to simpler PoS, May cause less environmental damage ( And the anti cryptocurrency mentality caused by environmental damage ), And more researchers can think about expansion freely . Will we eventually have to spend a lot of resources to make a better PoS Well ? I think it will , But now it seems , in any case , We all end up doing this .

Deconvolution of fragmentation

Ethereum is divided into pieces from 2014 Since the beginning of research in , Has been moving in an increasingly uncomplicated direction . First , We have complex shards with built-in execution and cross shard transactions ; then , We simplify the protocol by shifting more responsibility to users , In cross slice trading , The user must pay for two pieces separately Gas cost ; next , Let's switch to Rollup A road map centered around , among , From an agreement point of view , Sharding is just data sharding . Last , adopt danksharding, The slice cost market is merged into a whole , The final design looks like a non segmented chain , But here, , Data availability sampling can realize slice verification .


But what if we go the opposite way ? In fact, there are some Ethereum researchers , They explored a more complex fragmentation system : The segments will act as chains , There will be bifurcation selection rules , Where the child chain depends on the parent chain , Cross slice messages will be routed by the protocol , The verifier will rotate between slices , even to the extent that DApp Load balancing will be achieved automatically between slices .

The problem with this approach is : These forms of fragmentation are largely just ideas and mathematical models , and Danksharding Is a complete 、 Specifications that can almost be implemented . therefore , Given the circumstances and limitations of Ethereum , in my opinion , The simplification and disambiguation of segmentation is absolutely right . in other words , More ambitious research also plays a very important role : It identifies promising research directions , Even very complex ideas often have " Reasonable simplicity " edition , These ideas still offer many benefits , And it is likely to greatly affect the development of Ethereum in the next few years ( Even a two-tier agreement ).

EVM Selection of functions in

In reality , In addition to security audits ,EVM The specification of is basically in 2014 It can be launched in the middle of the year . However , At that time, in the next few months , We continue to actively explore new functions that we believe may be really important to decentralized blockchain . Some functions are added EVM 了 , Some don't .

  • We considered adding one POST opcode , But decided not to do so .POST The opcode makes asynchronous calls , Will be executed after the transaction is completed .
  • We have considered adding a ALARM opcode , But decided not to do so .ALARM The function of is similar to POST, Just perform asynchronous calls in a future block , Allow contractual arrangements to operate .
  • We added a log (logs), It allows the contract to output records that do not touch the State , But it can be DApp Interface and wallet explanation . It is worth noting that , We also considered letting ETH Transfer Issue Log , But decided not to do so , The reason is that " Anyway, people will soon switch to smart contract wallet ".
  • We considered expanding SSTORE To support byte arrays , But I decided not to do so because I was worried about complexity and security .
  • We added precompiled (precompiles), This is a contract that uses a local implementation to perform dedicated encryption operations , Than in EVM Execution is much cheaper .
  • In the months after the launch , We've been thinking about state rent over and over again (state rent), But never included . It's too complicated . today , People are actively exploring better conditions (state expiry) programme , Although stateless verification and proponents / Builder separation (PBS) That means it's now a much lower priority .

Now let's see , Most decisions not to add functionality have proven to be very good decisions . There is no obvious reason to add POST opcode .ALARM Opcodes are actually very difficult to implement safely : If 1...9999 Everyone in the block has a ALARM, stay 100000 Blocks execute a lot of code , What's going to happen ? Will that block take hours to deal with ? Will some scheduled operations be pushed to the later block ? But if that happens , that ALARM What guarantees can be retained ? Byte array SSTORE It's hard to do... Safely , And it will greatly expand the witness size in the worst case .

The problem of state rent is more challenging : If we really achieve a certain state rent from the first day , Ethereum does not need to always develop around the normalization assumption of the persistent state . Ethereum will be more difficult to build , But it may be more scalable and sustainable . meanwhile , We were in a much worse state than we are now . occasionally , A good idea is that it will take years to achieve , There is no better way .

LOG Alternative to

LOG  Can be done in two different ways .

  1. We can get ETH The transfer automatically sends a LOG. This will save a lot of energy and software error problems for exchanges and many other users , And will accelerate everyone's understanding of LOG Dependence , This will help the adoption of smart contract wallet .
  2. We absolutely don't need LOG opcode , And turn it into a ERC: There will be a standard contract , It has a function submitLog, The technology of Ethereum deposit contract is used to calculate the of all logs in the block Merkle root . Whether it's EIP-2929 Or block wide storage ( amount to TSTORE, But after the block is cleared ) Will make this cheaper .

We strongly considered the first way , But rejected it . The main reason is , Logs only come from LOG opcode , It's easier . We are also very wrong to expect that most users will quickly migrate to smart contract wallets , This allows you to explicitly use the opcode to record transfers .

We didn't consider the second way , But looking back , This is actually a choice . The main disadvantage of the second method is the lack of a bloom filter mechanism to quickly scan logs (Bloom filter). But it turns out , The bloom filter mechanism is too slow , Yes DApp It's not friendly , So now more and more people use it TheGraph To query .

in general , Any of these methods may be better than the current situation . Not included LOG Will make things easier , But if you include LOG, Automatically record all ETH The transfer of will make it more useful .

today , I may agree to the final cancellation of EVM Of LOG opcode .

If at present EVM Chose a completely different path , What will happen ?

The original EVM There are two very different ways to choose :

  1. send EVM Become a higher-level language , With variable 、if sentence 、 Loop and other built-in structures .
  2. send EVM Become some existing virtual machines (LLVM、WASM etc. ) Copy of .

The first way has never really been considered . The attraction of this road is , It can make the compiler simpler , And allow more developers to directly EVM Code in . It can also make ZK-EVM It's simpler . The weakness of this road is that it will make EVM The code is more complex in structure : It's no longer a simple list of opcodes , But a more complex data structure , Must be stored in some way . in other words , We missed an opportunity to have the best of both worlds : some EVM Changes can bring us many benefits , Keep basic at the same time EVM The structure remains the same : Prohibit dynamic jump , Add some operation codes designed to support subroutines ( See also :EIP-2315), Only in 32 Byte word boundary, access memory, etc .

The second way has been suggested many times , I've been rejected many times . The argument supporting it is usually , It will allow programs to learn from existing languages (C、Rust etc. ) Compile to EVM in . The opposition has always been , Given Ethereum's unique limitations , It doesn't actually offer any benefits :

Existing high-level language compilers often don't care about the total code size , The blockchain code must be greatly optimized to reduce the code size of each byte .

We need to implement a variety of virtual machines , And it is strictly required that the two implementations cannot handle the same code in different ways . It will be more difficult to conduct security audit and verification on the code we haven't written .

If the virtual machine specification changes , Ethereum will have to be updated with it all the time , Or more and more out of sync .

therefore ,EVM There may never be a viable path that is completely different from what we have today , Although there are many smaller details ( Jump ,64 position vs 256 I'm waiting for you ), If they can do it in different ways , Will bring better results .

ETH Whether supplies should be distributed in different ways ?

current ETH The supply can be roughly Etherscan To represent :



At present, about half of ETH It was sold in Ethereum public offering , Anyone can put BTC Send to a bitcoin address , The original ETH Supply allocation is calculated through an open source script . Most of the rest have been basically produced through mining . The black part 1200 ten thousand ETH Marked as “other”, It's actually a pre excavated part , At the Ethereum foundation and about 100 Amount allocated between early contributors to the Ethereum agreement .

There are two main criticisms of this process :

  • Pre excavation and Ethereum fund in charge of public funds , There is no credible neutrality . Some payee addresses are manually selected through a closed process , The Ethereum foundation must be trusted , The funds raised by the public cannot be further utilized through loans , To get more ETH ( We don't have it , And no one claims that we have , But even the demand to be trusted offends some people ).
  • Pre excavation over rewards very early contributors , And left too little for later contributors .75% Pre excavation is used to reward the work of contributors before going online , And after going online , The Ethereum foundation has only 300 m ETH. stay 6 In months , The need to sell for survival reduces the stock to 100 ten thousand ETH about .

In a way , These questions are relevant : The desire to minimize the perception of centralization has led to smaller pre excavation , But smaller pre excavation will run out faster .

This is not the only solution .Zcash A different approach is adopted : Block reward 20% A fixed assignment to a hard coded set of recipients in a protocol , This group of recipients renegotiates every four years ( up to now , This has happened once ). This will be more sustainable , But it will be more severely criticized for being too centralized (Zcash The community seems to be more open to the leadership of more technical experts than the Ethereum community ).

A possible alternative path is similar to today in some DeFi Popular in the project "DAO from day 1" Route . Here is a possible Scarecrow proposal :

  • We agree to 2 During the year , Divide... From each block reward 2 ETH Into the development fund .
  • Any purchase from Ethereum public offering ETH People can vote for the development fund they like ( for example :" In each block reward 1ETH To the Ethereum Foundation ,0.4ETH to Consensys Research team ,0.2 individual ETH to Vlad Zamfir...")
  • The development fund share of the recipient who is voted for is equal to the median of everyone's vote , In proportion , The total is equal to... Per block 2ETH( The median is to prevent self trading : If you vote for yourself , You won't get anything , Unless you let at least half of the other buyers mention you ).

Public offering can be operated by a legal entity , Promise to follow ETH Develop the same proportion of the fund to distribute the bitcoin received in the public offering process ( Or burn , If we really want to make bitcoin players happy ). This may lead to a lot of money for the Ethereum Foundation , Non Ethereum foundation groups also get a lot of money ( Leading to more ecosystem decentralization ), None of this undermines credible neutrality at all . Of course , The main disadvantages are , Pass voting is really bad , But to be pragmatic , We can realize that ,2014 The year is still an early and idealized time , The most serious disadvantage of pass voting will not come into play until long after the public offering is completed .

Would this be a better idea , And set a better precedent ? Maybe ! Although from a practical point of view , Even if the development fund is completely credible and neutral , Those who yelled at the Ethereum miners today , It's likely to be against DAO The fork began to shout twice .

What can we learn from all this ?

in general , Sometimes I think Ethereum's biggest challenge comes from balancing the two visions : A blockchain that values security and simplicity , And a platform for building high performance and functionality for advanced applications . Many of the above examples are just one aspect : We have fewer functions and are more like bitcoin , It still has more functions and is more suitable for developers ? We are worried about making development funds more neutral , More like bitcoin , Or our first concern is to ensure that developers get enough rewards , Make Ethereum better ?

My personal dream is to try to realize these two visions at the same time . A foundation layer , Its specifications are smaller every year than the previous year , And a layer 2 protocol centric , Powerful developer friendly advanced application ecosystem . in other words , It takes a long time to reach such an ideal world , If we can recognize more clearly that this will take time , We need to think about route planning step by step , It may be of great help to us .

today , There are a lot of things we can't change , But there are many things we can still change , And there is still a solid path to improve functionality and simplicity . Sometimes the road is tortuous : We need to add some complexity first to achieve fragmentation , And sharding can realize a lot of two-tier scalability on it . in other words , Reducing complexity is possible , The history of Ethereum has proved this .

  • EIP-150 Make the call stack depth limit irrelevant , Reduced security concerns for contract developers .
  • EIP-161 send “ Empty account ” The concept of is separated from accounts with zero fields .
  • EIP-3529 Partial refund mechanism deleted , send Gas Tokens no longer work .

A brewing idea , Such as Verkle Trees , It can even further reduce complexity . But how to better balance these two visions in the future , It's something we should start thinking about more positively .

版权声明:本文为[Wu Shuo blockchain]所创,转载请带上原文链接,感谢。