Rhythmic blockbeats 2022-04-05 09:17:32 阅读数:430
Original title ：《The roads not taken》
Original author ：Vitalik Buterin
The source of the original ：Vitalik Buterin Official website
Original translation ：Kxp, Rhythm BlockBeats
Ethereum Agreement development community in Ethereum Many decisions were made in the early stages of , It has had a significant impact on the development track of the project . In some cases ,Ethereum The developer made a rational decision , It's solved Bitcoin Some problems encountered . In other cases , We are also creating something new , Use many options to fill the gaps in the past . Sometimes , We need to make a trade-off between complexity and simplicity , Because they are applicable to different situations .
In this article, I will introduce some bifurcation functions , Many of them have been seriously discussed in the core developer community ; But the remaining features that have not been discussed should also be on the agenda at this time . meanwhile , We also look forward to seeing a different Ethereum, And learn something new .
Ethereum Will soon be merged into Gasper Although the proof of interest system is complex , But it's powerful , It has the following characteristics ：
Powerful single block confirmation —— Once the transaction is included in the block , Usually in seconds , The block will be solidified . Unless a large number of nodes have low integrity , Or there are extreme network delays , Otherwise it cannot be reversed .
Economic certainty —— Once the block is finalized , The attacker did not lose millions ETH Under the circumstances , It is also irreversible .
Highly predictable returns —— The verifier in each cycle （6.4 minute ） Can get reliable rewards , Reduced incentives for capital pools .
Support a large number of verifiers —— Unlike most other chains with these properties ,Ethereum The beacon chain supports hundreds of thousands of verifiers （ for example ,Tendermint Provide more than Ethereum Faster certainty , But it only supports hundreds of verifiers ）.
But making a system with these characteristics is quite difficult , It takes years of research , Through countless failures , And spend a lot of energy , And the end result will be very complex .
If our researchers don't need to think too much about consensus , And have enough energy , Then maybe rollup stay 2016 It has been invented since . This makes us reflect ： Should our certificate of rights and interests really have such a high standard , Because even a simple weakened version of the proof of interest will be much better than our current work proof .
Many people have a misunderstanding , I think the proof of interest itself is quite complex , But in fact, there are many equity proof algorithms that are almost the same as Nakamoto PoW It's as simple as .NXT Proof of interest in 2013 In , Is a natural candidate ; Although it has problems , But these problems are easy to fix , And we could have started from 2017 year , There is even a well functioning certificate of interest from the beginning .Gasper The reason why it is more complex than these algorithms , Just because it tries to accomplish a lot more than they do . however , If we were cautious at the beginning , We could have focused on achieving some more likely goals first .
in my opinion , Using proof of interest from the beginning is not the right approach ;PoW Help expand the initial distribution , improve Ethereum Accessibility of , And promote the development of amateur community . But in 2017 year , even to the extent that 2020 year , Using simpler proof of interest can better protect the environment （ And the anti pollution caused by environmental damage Crypto thought ）, It also allows researchers to better focus on expansion problems . In the end, we still need to spend a lot of resources to make a better proof of interest , From the current situation, this will be an inevitable result .
since 2014 Began to study Ethereum Since slicing , We've been working on the problem of de complexity . Previous complex shards had built-in execution and cross shard trading functions , And then we simplified the agreement , Shift more responsibility to users （ for example , In cross slice trading , The user must pay separately on two slices Gas fee ）. then , We turned to rollup A road map centered around , From an agreement point of view , Fragmentation is just a collection of data . Last , adopt danksharding, We can combine the piecemeal charging market into one . thus , Although the final design looks like a non segmented chain , But the data availability sampling behind it can make slice verification a reality .
But what if we choose the opposite path ？ actually Ethereum Researchers have spent a lot of time exploring a more complex fragmentation system ： Pieces will become chains , In the bifurcation selection rule, the sub chain depends on the main chain , Cross fragment messages are routed by the protocol , The verifier will rotate between slices , Even applications automatically load balance between shards .
The problem with this approach is ： This kind of slicing is basically just some ideas and mathematical models , and Danksharding Is a complete and implementable specification . therefore , Whereas Ethereum The constraints of , in my opinion , The simplification and disambiguation of segmentation is absolutely right . For all that , We should still devote more energy to research , Because it can help us identify promising research directions . Generally speaking , Even very complex ideas have a simple version , And it can still bring us a lot of help , At the same time, it is likely that in the next few years or so Ethereum The development direction of the agreement （ Even Layer2 agreement ）.
In addition to the security audit function ,EVM What are the specifications 2014 It can be launched before the middle of the year . however , In the next few months , We have been actively exploring new functions useful for decentralized application blockchain , As follows ：
1. We wanted to add a POST opcode , But then I decided to give up .POST The opcode makes asynchronous calls , The call will not be executed until the transaction is completed .
2. We also wanted to add a ALARM opcode , But then I gave up .ALARM The function of is similar to POST, It's just that it can perform asynchronous calls in a future block , So that the contract can plan the operation in advance .
3. We added a log , It can make the contract output independent of state , But it can be DApp Interface and wallet read records . however , We also considered letting ETH Transfer Issue Log , But I gave up , Because we think 「 Anyway, people will soon switch to smart contract wallet 」.
4. We considered expanding SSTORE To support byte arrays , But later, I chose to give up because I was worried about its high complexity and insufficient security .
5. We added a precompiled contract , They can be compared with EVM Lower Gas fee , Perform specific tasks in a native way Crypto operation .
6. In the months after the release , We repeatedly considered the problem of state rent , However, due to its complexity, we do not include it . Now , People are actively exploring better state expiration schemes , Although stateless verification and proponents / Builder separation is much more important than it .
Today to see , We basically made the right decision , We really don't need to add POST opcode , It's hard to guarantee ALARM Security of opcodes （ If everyone is 1 To 99999 One is set in each block ALARM, Then in the first place 100000 Execute a lot of code in a block , What's going to happen ？ Will that block take hours to process this code ？ Will some scheduled operations be pushed to the later block ？ If that happens , that ALARM What security guarantees can be retained ？） Byte array SSTORE Security is also difficult to achieve , And it will expand the witness scale in the worst case .
The problem of status renting is more challenging ： If we really achieve a certain state from the first day , Then we will have any smart contract ecosystem that can evolve around the normative assumption of continuous state .Ethereum It will become more difficult to build , Although 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 shortcut .
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 time for exchanges and many other users , And reduce the occurrence of and software errors . People will be more dependent on LOG, At the same time, smart contract wallet will also be used on a larger scale .
2. We don't have to LOG opcode , And turn it into a ERC： There will be a configuration submitLog The standard contract of the function , It can be used Ethereum Deposit contract technology is used to calculate the value of all logs in the block Merkle root . Whether it's EIP-2929 Or the storage on the block （ amount to TSTORE, But it will be emptied after ） Will reduce its cost .
We have seriously considered the first way , But in the end, it didn't adopt , The main reason is its lack of simplicity ： Use LOG It will be more convenient to generate logs directly from opcodes . We also made wrong estimates , I think most users will quickly migrate to smart contract wallet , And use the operation code to record the transfer .
We haven't thought about the second method before , But in retrospect , It's actually very good . Its main drawback is , It lacks a way to scan logs quickly Bloom Filter mechanism . But it turns out ,Bloom The filter mechanism is too slow , Yes DApp Unfriendly , So now more and more people are using TheGraph To query .
in general , Using either method will make the situation better . take LOG Staying outside the agreement makes things easier , But if it's within the agreement , It automatically records all ETH The transfer function is also very practical .
today , I will approve of canceling EVM Medium LOG opcode .
EVM You can choose two distinct paths ：
1. Give Way EVM Become a higher-level language , There are built-in variables 、if sentence 、 Circulation and other structures .
2. Give Way EVM Become some existing virtual machines （LLVM、WASM etc. ） Copy of .
We never thought about the first path , And its advantage is , It can simplify the compiler , And allow more developers to directly EVM Code in . meanwhile , It can also make ZK-EVM It's simpler . however , The weakness of this path is , 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 a specific way . in other words , We missed an opportunity to have the best of both worlds ： In maintaining EVM While the basic structure remains unchanged , Making some changes to it can bring us a lot of benefits , Including disabling dynamic jump 、 Add some operation codes designed to support subroutines （ See also ：EIP-2315）、 Only in 32 Access memory on the lexical boundary of bytes , wait .
The second path is mixed , People who support it think it can make programs from existing languages （C、Rust etc. ） Compile to EVM in , Opponents argue that , Whereas Ethereum Special constraints , It doesn't actually offer any benefits ：
1. 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 .
2. We need to realize many functions of virtual machine , It is strictly required that the two functions cannot handle the same code in different ways , But it will also make it difficult to conduct security audit and verification on code that is not written by us .
3. If the virtual machine specification changes ,Ethereum Will have to be updated with it all the time , Otherwise, it will be difficult to synchronize .
therefore , Although some details have been improved, it may produce better results , But unlike the current situation ,EVM There may have never been a feasible path before .
We can take this picture from Etherscan The chart shows that at present ETH Supply of ：
About half of today's ETH It's public Ethereum Sold in sales , Anyone can turn to a standardized Bitcoin The address to send BTC, And the first ETH The supply distribution is calculated by an open source script , The script scans Bitcoin The transaction on the blockchain obtains the address . The rest ETH They are basically obtained by mining , It's marked with 「 other 」 Of 1200 ten thousand ETH, yes 「 Pre mining 」 Part of —— That is to say Ethereum Foundation peace treaty 100 individual Ethereum The portion of the agreement allocated among early contributors .
Two criticisms have been made of the process ：
1. Pre mining , as well as Ethereum The fact that the foundation received sales funds , Not credible neutrality . Some recipient addresses are manually selected in a closed loop , And we must believe Ethereum The fund will not put the funds received from sales back into the sales link through loans to provide more for itself ETH.
2. Pre mining over rewards early contributors , This allows subsequent contributors to receive fewer rewards .75% Pre mining is used to reward contributors for their work before startup , And after starting ,Ethereum The foundation has only 300 ten thousand ETH. In the next six months , Due to financial needs , The number dropped again to about 100 ten thousand ETH.
In a way , These problems are interrelated ： In order to minimize centralization , Reduced the scale of pre mining , And this will make it run out faster .
Zcash Took a different approach ： A set of hard coded receiving addresses in the protocol will receive a constant 20% Block rewards , And this list every 4 It will be renegotiated once a year （ So far, an adjustment has been made ）. Although this approach is more sustainable , But there will also be more criticism for centralization （Zcash The community seems to be better than Ethereum The community is more willing to accept the leadership of technical experts ）.
We can use today in some defi Popular in the project 「DAO from day 1」 As an alternative route , The draft proposal is as follows ：
1. We agree to 2 During the year , Take out each block 2 individual ETH The reward is put into the Development Fund .
2. Any in Ethereum Buy... In sales ETH People can vote for their favorite Development Fund , To carry on ETH Distribute （ for example ：「 Every block 1ETH to Ethereum The foundation ,0.4ETH to Consensys Research team ,0.2ETH to Vlad Zamfir wait 」）
3. The recipient who gets the vote will receive a share of the development fund equal to the median of everyone's vote , And will be calculated proportionally , So as to ensure that the total number is equal to each block 2 individual ETH（ The median is set to prevent self trading ： It's no use voting for yourself , Unless you ask at least half of the other buyers to vote for you ）.
This sale can be completed by the operation of legal entities , The entity undertakes to pay the amount received during the sale Bitcoin According to and ETH The development fund shall be distributed in the same proportion （ Or destroyed , If we want to Bitcoin If the player is happy ）. This may lead to Ethereum Foundations and other groups get a lot of money without undermining credible neutrality , Accelerate the process of ecosystem decentralization . Of course , The disadvantage of this approach is , Coin voting is really bad , But to be pragmatic ,2014 The year is still an early and idealized stage , The most serious disadvantage of coin voting will not begin to appear long after the end of sales .
This might be a better idea , And set a better precedent . Although from a practical point of view , Even if the development fund is completely credible and neutral , Those today are right Ethereum A person who is dissatisfied with the miners , It is likely to turn to DAO Bifurcation .
in general , Sometimes I think Ethereum The biggest challenge is to maintain a balance between the two visions —— One pays attention to security and simplicity , Pure and simple blockchain , And a high-performance platform for building advanced applications . The above examples are only one aspect of this problem ： We are reducing the number of functions to be more similar Bitcoin, Or create more features for developers ？ We should worry that making development funds more credible and neutral will make them more like Bitcoin, Or should we first care about how to ensure that developers get enough rewards , So that Ethereum Get better ？
In my opinion , We can achieve these two visions at the same time —— A foundation layer with gradually reduced specifications , And one with Layer2 Agreement centered , Powerful developer friendly advanced application ecosystem . even so , It still takes a long time to reach such an ideal state . So , We can only consider how to formulate the road map step by step , In order to achieve certain results .
Although we can't change many things now , But it's not all , And we can still start to improve functionality and simplicity . however , In this process, we sometimes encounter some difficulties ： In order to improve the segmentation Layer2 extensibility , We need to add some complexity first to achieve fragmentation . But even so , A reduction in complexity is also possible ,Ethereum History has proved this ：
1.EIP-150 Make the call stack depth limit no longer applicable , This reduces the security concerns of contract developers .
2.EIP-161 Give Way 「 Empty account 」 It is no longer distinguished from accounts with zero fields .
3.EIP-3529 Partial refund mechanism deleted , bring Gas Token It's no longer feasible .
With Verkle After the idea that the tree is still brewing , We can even further reduce complexity . But how to better balance these two visions in the future , It's something we should start thinking about .
版权声明：本文为[Rhythmic blockbeats]所创，转载请带上原文链接，感谢。 https://netfreeman.com/2022/04/202204050855382940.html