Review of Vitalik's long article: Those Ethereum "paths that have not been traveled"
Original title: "
Original title: "The roads not taken》
Wu said blockchainWu said blockchain
The Ethereum development community made many decisions in the early days of Ethereum that had a huge impact on the trajectory of the project. In some cases, ethereum developers made conscious decisions to improve where we thought bitcoin was problematic. Elsewhere, we're creating something completely new and we just have to come up with something to fill in the gaps, but there's a lot to choose from. There are also places where we need to make a trade-off between something more complex and something simpler. Sometimes we choose something simpler, but sometimes we choose something more complicated.
secondary title
Should we go with a simpler PoS mechanism?
The Gasper PoS mechanism that Ethereum is about to incorporate is a complex system, but it is also a very powerful system. Some of its properties include:
Very strong single-block confirmation: Once a transaction is included in a block, usually within seconds, the block is finalized unless a large percentage of nodes are dishonest, or there is extreme network latency It cannot be reversed.
Economic finality: Once a block is finalized, it cannot be reversed unless the attacker can withstand the loss of millions of ETH and be fined.
Very predictable rewards: Validators are reliably rewarded every epoch (6.4 minutes).
Supports very high validator counts: Unlike most other chains with the above properties, the Ethereum Beacon Chain supports hundreds of thousands of validators (eg: Tendermint provides faster finality than Ethereum, but it only supports hundreds of validators)
But creating a system with these properties is difficult. It required years of research, years of failed experiments, and often a lot of effort, with a rather complex final output.
If we researchers didn't have to worry as much about consensus and had more free time to think, then maybe, just maybe, rollups could have been invented in 2016. This leads us to think: should we really demand such high standards for our PoS? Because even a simpler and weaker PoS would be a huge improvement over the PoW status quo.
Many people have a misconception that PoS itself is complex, but in fact there are many PoS algorithms that are almost as simple as the Satoshi PoW consensus. NXT's PoS has been around since 2013 and would have been a ready candidate; while it has some issues, those issues are easily patched and we could have a reasonably viable PoS from 2017, or even from the start. Gasper is more complex than these algorithms simply because it is trying to do so much more than them. But if we don't aim too high in the first place, we can start by focusing on achieving a more limited set of goals.
secondary title
Shard Decomplication
Ethereum sharding has been moving in a less and less complex direction since research began in 2014. First, we have complex shards with built-in execution and cross-shard transactions; then, we simplify the protocol by shifting more of the responsibility to the user, in which the user has to pay gas for both shards separately ; then we switch to a Rollup-centric roadmap where, from a protocol perspective, shards are just data shards. Finally, through danksharding, the shard fee market is merged into a whole, and the final design looks like a non-shard chain, but here, data availability sampling enables shard verification.
But what if we took the opposite path? There are actually some Ethereum researchers who have delved into a more complex sharding system: shards will act as chains, there will be fork selection rules, where child chains depend on parent chains, and cross-shard messages will be routed by the protocol , validators will rotate between shards, and even DApps will automatically get load balanced between shards.
The problem with this approach is that these forms of sharding are largely ideas and mathematical models, whereas Danksharding is a complete, almost implementable specification. So, given the circumstances and limitations of Ethereum, sharding simplification and disambiguation is definitely the right thing to do in my opinion. That said, more ambitious research also serves a very important role: it identifies promising research directions, and even very complex ideas often have"Reasonably simple"secondary title
Selection of features in the EVM
In fact, except for the security audit, the EVM specification can basically be launched in mid-2014. However, over the ensuing months at the time, we continued to actively explore new features that we believed might be truly important to decentralized blockchains. Some features are added to the EVM, some are not.
We considered adding a POST opcode, but decided not to. The POST opcode makes an asynchronous call and is executed after the transaction is complete.
We considered adding an ALARM opcode, but decided not to. ALARM functions like a POST, except that it performs an asynchronous call some block in the future, allowing contracts to schedule operations.
We added logs, which allow contracts to output records that do not touch state, but can be interpreted by DApp interfaces and wallets. It's worth noting that we also considered having ETH transfers emit a log, but decided not to, citing"People will soon be switching to smart contract wallets anyway"。
We considered extending SSTORE to support byte arrays, but decided against it due to complexity and security concerns.
We added precompiles, which are contracts that use native implementations to perform specialized cryptographic operations, much cheaper than executing them in the EVM.
We mulled over state rent in the months since going live, but it was never included. It's just too complicated. Better state expiration schemes are being actively explored today, although stateless validation and proposer/builder separation (PBS) mean it's a much lower priority now.
Today, most decisions not to add functionality turn out to be very good decisions. There's no obvious reason to add a POST opcode. ALARM opcodes are actually hard to implement safely: what happens if everyone in blocks 1...9999 sets an ALARM, and executes a lot of code at block 100,000? Will that block take hours to process? Will some scheduled operations be pushed to later blocks? But if that happens, what guarantee does ALARM retain? An SSTORE of byte arrays is difficult to do safely and would greatly expand the worst-case witness size.
secondary title
Alternatives to LOG
LOG can be done in two different ways.
We can make ETH transfer automatically send a LOG. This will save exchanges and many other users a lot of effort and software bug issues, and will accelerate everyone's reliance on LOG, which will help the adoption of smart contract wallets.
We can completely do without the LOG opcode, and turn it into an ERC: there will be a standard contract, which has a function submitLog, and uses the technique of the Ethereum deposit contract to calculate the Merkle root of all logs in the block. Either EIP-2929 or block-wide storage (equivalent to TSTORE, but cleared after the block) would make this cheaper.
We strongly considered the first option, but rejected it. The main reason is that logging only comes from the LOG opcode, which is easier. We also very wrongly expected that most users would quickly migrate to smart contract wallets, which could explicitly use opcodes to record transfers.
We didn't consider the second option, but in retrospect, it was actually an option. The main disadvantage of the second method is the lack of a Bloom filter mechanism (Bloom filter) for quickly scanning logs. But it turns out that the Bloom filter mechanism is too slow and not friendly to DApps, so now more and more people use TheGraph for queries.
Overall, any of these approaches has the potential to be superior to the status quo. Not in the LOG would make things simpler, but it would be more useful to automatically record all ETH transfers if in the LOG.
secondary title
What if the current EVM took a completely different path?
At the beginning, EVM had two very different paths to choose from:
Makes the EVM a higher-level language, with built-in constructs like variables, if statements, loops, and more.
Make the EVM a copy of some existing virtual machine (LLVM, WASM, etc.).
The first path was never really considered. The appeal of this path is that it can make the compiler simpler and allow more developers to code directly in the EVM. It can also make the structure of ZK-EVM simpler. The weakness of this approach is that it makes the EVM code more structurally complex: it is no longer a simple list of opcodes, but a more complex data structure that must be stored somehow. That is, we missed an opportunity to have the best of both worlds: some EVM changes could give us a lot of benefits, while keeping the basic EVM structure unchanged: disabling dynamic jumps, adding some opcodes designed to support subroutines (otherwise See: EIP-2315), memory accesses are only allowed on 32-byte word boundaries, etc.
The second path has been suggested and rejected many times. The argument in favor of it is usually that it will allow programs to be compiled from existing languages (C, Rust, etc.) into the EVM. The counterargument has always been that, given Ethereum's unique limitations, it doesn't actually provide any benefit:
Compilers for existing high-level languages often don't care about the total code size, while blockchain code must be heavily optimized to reduce every byte of code size.
We need multiple implementations of the virtual machine and strictly require that no two implementations handle the same code differently. It's harder to do security audits and verifications on code we didn't write.
If the VM specification changes, Ethereum will have to always update with it, or become increasingly out of sync.
secondary title
Should the ETH supply be distributed differently?
The current supply of ETH can be roughly represented by this graph of Etherscan:
Roughly half of all ETH is currently sold in Ethereum Public Sale, where anyone can send BTC to a Bitcoin address, and the initial ETH supply allocation is calculated through an open-source script. Most of the rest have basically been mined as well. The 12 million ETH in black marked "other" is actually the pre-mined portion, the amount distributed between the Ethereum Foundation and about 100 early contributors to the Ethereum protocol.
There are two main criticisms of this process:
Neither pre-mining nor the Ethereum Fund in charge of public offerings has credible neutrality. Some recipient addresses are manually selected through a closed process, the Ethereum Foundation must be trusted not to further leverage public sale proceeds through loans to obtain more ETH (we do not, and no one claims we have , but even the requirement to be trusted offended some people).
Premine rewards very early contributors too much, leaving too little for later contributors. 75% of the pre-mining is used to reward the work of contributors before going online, and after going online, the Ethereum Foundation only has 3 million ETH left. Over the course of 6 months, the need to sell to survive reduced the stock to around 1 million ETH.
In a way, these issues are related: the desire to minimize the perception of centralization has contributed to smaller premines, but smaller premines drain faster.
This is not the only solution. Zcash takes a different approach: a fixed 20% of the block reward is allocated to a hard-coded set of recipients in the protocol that is renegotiated every four years (so far, this has happened once ). This would be more sustainable, but it would be criticized more harshly for being too centralized (the Zcash community seems to embrace more technologist leadership more openly than the Ethereum community).
A possible alternative path is similar to the one popular in some DeFi projects today"DAO from day 1"route. Here's a possible straw man proposal:
We agree to allocate 2 ETH from each block reward to the development fund for 2 years.
Anyone who buys ETH in the Ethereum public sale can vote for their favorite development fund allocation (eg:"In each block reward, 1ETH is given to the Ethereum Foundation, 0.4ETH is given to the Consensys research team, and 0.2ETH is given to Vlad Zamfir..."）
Voted recipients get a development fund share equal to the median of each person's vote, prorated for a total equal to 2ETH per block (the median is to prevent self-trading: if you vote for yourself, you get nothing Less than, unless you get at least half of the other buyers to mention you).
The public sale could be run by a legal entity that promises to distribute the bitcoins received during the public sale in the same proportion as the ETH development fund (or burn them, if we really want to keep bitcoiners happy). This could lead to a lot of funding for the Ethereum Foundation, and a lot of funding for non-Ethereum Foundation groups (leading to more decentralization of the ecosystem), all without undermining credible neutrality one iota. The main downside, of course, is that token voting really sucks, but pragmatically we can realize that 2014 is still an early and idealized time, and that the worst downside of token voting comes long after the public sale ends. will start to work.
secondary title
What can we learn from all this?
In general, sometimes I feel that Ethereum's biggest challenge comes from balancing two visions: a blockchain that values security and simplicity, and a highly performant and functional platform for building advanced applications . Many of the examples above are just one facet: are we more like Bitcoin with fewer features, or are we more developer-friendly with more features? Are we worried about making dev funding more neutral, more like Bitcoin, or are we worried about making sure developers are rewarded enough to make Ethereum better in the first place?
My personal dream is to try to achieve both visions at the same time. A base layer whose specification is smaller each year than the previous year, and a robust developer-friendly ecosystem of advanced applications centered around the Layer 2 protocol. That is to say, it will take a long time to reach such an ideal world, and it may be of great help to us to realize more clearly that this will take time, and that we need to consider route planning step by step.
Today, there are many things we cannot change, but there are also many things we can still change, and there is still a solid path to improved functionality and simplicity. Sometimes the path is tortuous: we need to add some complexity first to enable sharding, which in turn enables a lot of layer 2 scalability on top of it. That said, reducing complexity is possible, and the history of Ethereum has demonstrated this.
EIP-150 makes the call stack depth limit irrelevant, reducing security concerns for contract developers.
EIP-161 separates the notion of a "null account" from an account with a field of zero.
EIP-3529 removes some of the refund mechanisms, making Gas tokens no longer viable.
Ideas in the pipeline, such as Verkle trees, reduce complexity even further. But how to better balance these two visions in the future is a question we should start to think about more actively.
