Vitalik's long article review: Those "roads not taken" by Ethereum

The Ethereum protocol development community made a lot of decisions in Ethereum's early days that had a big impact on the trajectory of the project. In some cases, Ethereum developers made a conscious decision to improve on areas where we thought Bitcoin got it wrong. In other places, we were creating something completely new, and we just had to come up with something to fill the gap - but there were a lot of things to choose from. And still other places, we made a trade-off between something more complex and something simpler. Sometimes, we chose something simpler, but sometimes, we chose something more complex.

This post will look at some of the forks in the road that I remember. Many of these features have been seriously discussed within core development circles; others have barely been considered, but perhaps should have been. But even so, it’s worth looking at what a different Ethereum might have looked like, and what we can learn from them.

Should we use a simpler version of PoS?

The Gasper PoS that Ethereum is about to incorporate is a complex system, but also a very powerful one. Some of its features include:

• Very strong single-block confirmation - once a transaction is included in a block, the block is usually solidified to the point of being irreversible within a few seconds unless a large fraction of nodes are dishonest or there is extreme network latency.

• Economic finality — Once a block is finalized, it cannot be reversed without the attacker having to be penalized and lose millions of ETH.

• Very predictable rewards — validators reliably receive rewards every epoch (6.4 minutes), reducing incentives for pools.

• Support for very high validator counts — Unlike most other blockchains with the above features, the Ethereum Beacon Chain supports hundreds of thousands of validators (for example, Tendermint offers faster finality than Ethereum, but it only supports a few hundred validators).

But making a system with these properties is difficult. It takes years of research, years of failed experiments, and generally a lot of effort. The end result is very complex.

If our researchers didn’t have to worry so much about consensus and had more brain cycles to spare, then maybe, just maybe, rollups could have been invented in 2016. This brings us to the question: should we really have such high standards? Would our PoS, even simpler and weaker versions of it, be a big improvement over the PoW status quo?

Many people think that PoS is inherently complex, but there are actually PoS algorithms that are almost as simple as Satoshi PoW. NXT PoS has been around since 2013 and would have been a natural candidate; it has problems, but those problems were easily patched and we could have had a well-functioning PoS from 2017 or even from the beginning. The reason Gasper is more complex than these algorithms is simply because it tries to accomplish more than they do. But if we start out more modestly, we can focus on achieving a more limited set of goals first.

In my opinion, PoS was a mistake from the beginning. PoW was useful for scaling the initial distribution and making Ethereum accessible, as well as encouraging a community of enthusiasts. But switching to a simpler PoS in 2017 or even 2020 would probably result in much less environmental damage (and the anti-crypto mentality that environmental damage leads to), and more research talent would be free to think about scaling. Will we end up having to spend a lot of resources to make a better PoS? Yes. But it looks like we will eventually.

Decomplexification of Sharding

Ethereum sharding has been getting less complex since we started working on these ideas in 2014. First we had complex sharding with built-in execution and cross-shard transactions. Then we simplified the protocol by shifting more responsibility to the user (e.g. in a cross-shard transaction the user had to pay gas for both shards separately). Then we switched to a Rollup-centric roadmap where shards are just chunks of data from the protocol’s perspective. Finally, with danksharding, the shard fee market merged into one, resulting in a design that looks just like a non-sharded chain, but with some data availability sampling magic happening behind the scenes for shard verification.

But what if we go the other way? There are actually Ethereum researchers who have explored a more complex sharding system in depth: shards will spawn chains, there will be child chains that depend on the fork selection rules of the parent chain, cross-shard messages will be routed by the protocol, validators will rotate between shards, and even applications will automatically load balance between shards!

The problem with this approach is: these forms of sharding are largely just ideas and mathematical models, while Danksharding is a complete and almost implementable specification. Therefore, given the context and constraints of Ethereum, simplification and less ambition in sharding is definitely the right move in my opinion. That said, more ambitious research also has a very important role: it identifies promising research directions, and even very complex ideas usually have "fairly simple" versions of those ideas that still offer a lot of benefits, and there is a high probability that it will significantly influence Ethereum protocol development (even Layer-2 protocols) in the coming years.

More or less functionality in the EVM?

In fact, aside from the security audit, the specification for the EVM was basically ready to go by mid-2014. However, in the following months, we continued to actively explore new features that we thought might be important for decentralized applications. Some of them were not added, and some were added.

• We considered adding a "POST" opcode but decided against it. The POST opcode will make an asynchronous call that will be executed after the rest of the transaction has completed.

• We considered adding an ALARM opcode but decided against it. ALARM functions similarly to POST except that it performs an asynchronous call in some future block.

• We added logging functionality to allow contracts to output records that do not involve state but can be interpreted by dapp interfaces and wallets. It is worth noting that we also considered allowing ETH transfers to emit logs, but ultimately decided not to do so - the reason being that "people will soon move to smart contract wallets."

• We considered extending SSTORE to support byte arrays, but decided against it due to concerns about complexity and security .

• We added precompiles , which are contracts that perform specialized cryptographic operations using native implementations with much lower gas costs than in the EVM.

• In the months after launch, state rent was considered again and again, but never included. It was too complicated. Today, better state expiry schemes are being actively explored, although stateless verification and proposer/builder separation mean it's a much lower priority right now.

Most of the decisions not to add more features have proven to be very good ones today. There is no obvious reason to add a "POST" opcode. The "ALARM" opcode is actually very difficult to implement safely: what happens if everyone in blocks 1...99999 sets an "ALARM" to execute a large amount of code at block 100000? Will the block take hours to process? Will some scheduled actions be postponed to a later block? But if this happens, then what guarantee is there that the "ALARM" can be preserved? "SSTORE" is difficult to do safely for byte arrays, and will greatly expand the worst-case witness size.

The state rent problem is more challenging: if we had actually implemented some kind of state rent from day one, we wouldn’t have allowed the smart contract ecosystem to evolve around the canonical assumption of persistent state. Ethereum would have been harder to build on, but it would have been more scalable and sustainable. At the same time, our state rent plan back then was indeed much worse than what we have now. Sometimes good ideas take years to come to fruition, and there’s no better way to fix it.

Alternative path to "LOG"

LOG can be done in two different ways in different ways:

1. We can make ETH transfers automatically issue a "LOG" . This will save a lot of effort and software bugs for exchanges and many other users, and accelerate everyone's reliance on logs, which ironically helps the adoption of smart contract wallets.

2. We can completely avoid the "LOG" opcode and make it an ERC : there will be a standard contract with a function submitLog, and use the technology in the Ethereum deposit contract to calculate the Merkle root of all logs in the block. EIP-2929 or block-wide storage (equivalent to "TSTORE" but cleared after the block) will make this cheap.

We strongly considered (1), but rejected it. The main reason was simplicity: logging can more easily come from the "LOG" opcode.

We also (very wrongly!) expected that most users would quickly migrate to smart contract wallets, which might already record transfers explicitly using opcodes.

(2) was not considered, but in retrospect, it was always an option. The main disadvantage of (2) is the lack of a Bloom filter mechanism for fast log scanning. But it turns out that the Bloom filter mechanism is too slow for dapps and user-friendly, so now more and more people use TheGraph for queries.

Overall, either of these two approaches is likely to be better than the status quo. Keeping the "LOG" outside the protocol makes things simpler, but it would be more useful if it automatically recorded all ETH transfers inside the protocol.

Today, I would probably be in favor of eventually removing the "LOG" opcode from the EVM.

What if the EVM is completely different?

There are two very different natural paths that the EVM can take:

1. Make EVM a high-level language with built-in variables, if statements, loops and other structures.

2. Make EVM a copy of some existing VM (LLVM, WASM, etc.).

The first path was never really considered. The appeal of this path is that it would make the compiler simpler and allow more developers to code directly in the EVM. It would also make the ZK-EVM structure simpler. The weakness of this path is that it would make the EVM code more structurally complex: it would not be a simple list of consecutive opcodes, but a more complex data structure that must be stored somehow. That is, an opportunity to have the best of both worlds was missed: some EVM changes would have given us a lot of benefits while keeping the basic EVM structure roughly intact: ban dynamic jumps and add some opcodes designed to support subroutines (see also: EIP-2315), only allow memory access on 32-byte word boundaries, and so on.

The second path has been suggested and rejected many times. The usual argument is that it allows programs to be compiled into the EVM from existing languages ​​(C, Rust, etc.). The argument against it has always been that it would not actually provide any benefit given Ethereum's unique limitations:

• Existing compilers from high-level languages ​​tend not to care about total code size, whereas blockchain code must be heavily optimized to reduce every byte of code size.

• We need multiple implementations of the VM, with a hard requirement that two implementations never handle the same code differently. It is much harder to perform security audits and validation on code we did not write.

• If the virtual machine specification changes, Ethereum will either always have to update with it or become increasingly out of sync.

So there was probably never a viable path for the EVM to be radically different from what we have today, although there are a lot of smaller details (jumps, 64-bit vs 256-bit, etc) that might have led to better results if done differently.

Should ETH supply be distributed differently?

This chart from Etherscan roughly represents the current ETH supply:

About half of all ETH in existence today was sold in public Ethereum sales, where anyone can send BTC to a standardized Bitcoin address, and the initial ETH supply allocation is calculated by an open source script that scans the Bitcoin blockchain for transactions to that address. Most of the rest has been mined. The black portion - 12 million ETH marked "Other" - is premine, allocated to the Ethereum Foundation and about 100 early contributors to the Ethereum protocol.

There are two main criticisms of this process:

• The fact that the premine and the Ethereum Foundation received funds from the sale is not credibly neutral. Some of the recipient addresses were hand-picked through a closed process, and one must trust that the Ethereum Foundation would not borrow money to recycle the funds received in order to reinvest them into the sale to give themselves more ETH (we didn't, and no one seriously claims that we did, but even the requirement of full trust would offend some people).

• The premine over-rewarded early contributors and left too little for later contributors. 75% of the premine was used to reward contributors for their work before launch, and after launch, the Ethereum Foundation was left with only 3 million ETH. Within 6 months, the need to sell for economic survival was reduced to about 1 million ETH.

To some extent, these issues are related: the desire to minimize the perception of centralization leads to smaller premines, and smaller premines are exhausted more quickly.

This is not the only way things could be done. Zcash has a different approach: a fixed 20% of block rewards going to a set of recipients hardcoded in the protocol, and renegotiating that set of recipients every 4 years (this has only happened once so far). This would have been more sustainable, but it would have been more heavily criticized for being centralized (and the Zcash community seems to be more openly accepting of more technical leadership than the Ethereum community).

One possible alternative path is similar to the “DAO from day one” route popular among some DeFi projects today. Here is a possible vulnerable proposal:

• We agree that for 2 years, 2 ETH from each block reward will go into the developer fund.

• Anyone who buys ETH in the Ethereum sale can specify their preferred allocation vote for the developer fund (e.g., “1 ETH per block goes to the Ethereum Foundation, 0.4 ETH goes to the Consensys research team, 0.2 ETH goes to Vlad Zamfir…”)

• The recipient of the vote gets a share of the development fund equal to the median of everyone's votes , calculated proportionally, with a total of 2 ETH per block (the median is to prevent self-dealing: if you vote for yourself, you will get a share unless you get at least half of the other purchasers who mentioned you)

The sale could be conducted by a legal entity that promised to distribute the Bitcoin received during the sale in the same proportion as the ETH development fund (or burn it, if we really wanted to make Bitcoin holders happy). This could result in a lot of money going to the Ethereum Foundation, and a lot of money going to non-Ethereum foundations (thus building a more decentralized ecosystem) , all without undermining credible neutrality. The main drawback is of course that token voting really sucks, but realistically we could have realized that 2014 was still an early and idealistic time, and the worst drawbacks of token voting would only come into play long after the sale was over.

Would this be a better idea and set a better precedent? Probably! Although in reality even if the dev fund was completely credibly neutral, it’s likely that the people who are yelling about Ethereum’s premine today are just starting to raise even bigger voices against the DAO fork.

What can we learn from all this?

Overall , I sometimes feel like Ethereum's biggest challenge comes from the balance between two visions - a pure and simple blockchain that values ​​security and simplicity, and a performant and functional platform for building advanced applications. Many of the examples above are just one aspect of this: are we less functional but more like Bitcoin, or more functional but more developer-friendly? Are we very worried about making the development fund credibly neutral and more like Bitcoin, or are we first and foremost worried about making sure developers are rewarded enough to make Ethereum good?

My personal dream is to try to achieve both visions simultaneously - a base layer whose specifications are smaller every year than the previous year, and a strong developer-friendly ecosystem of advanced applications centered around the Layer 2 protocol. That said, it will take a long time to get to such an ideal world, and being more aware that it will take time and that we need to think about the roadmap step by step may help us a lot.

Today, there are many things we cannot change, but there are many things we can still change, and there is still a path to get sufficient improvements in 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 Layer2 scalability on top. That said, reducing complexity is possible, and Ethereum's history has proven this:

• EIP-150 makes the call stack depth limit irrelevant, reducing security concerns for contract developers.

• EIP-161 no longer has the concept of an “empty account” as something separate from an account whose fields are zero.

• EIP-3529 removes the partial refund mechanism, making gas tokens no longer viable.

Ideas in the works, such as Verkle trees, could reduce complexity even further, but how best to balance these two visions in the future is something we should start thinking about more actively.