⏫ Ethereum Upgrades — Issue No. 26

🗞 News

The minutes of several "private" Ethereum developer meetings that took place at the Devcon4 conference in October have been published. Some are implying the closed door nature of these meetings is problematic. While it seems some developers who (probably) should have been there were left out, I think this angle is being overblown. Much more interesting is the technical tradeoffs that were apparently discussed. In addition to plans for the so-called "Ethereum 2.0" upgrade, proposals for an interim 1.x upgrade were also considered. Link.

The first of these proposals is to replace the Ethereum Virtual Machine (EVM) with an Ethereum specific variant of the WebAssembly VM. Dubbed ewasm, this project has been under development for some time. It aims to leverage the extensive work of the open source community behind WebAssembly. As a modern VM that now ships in all major browsers, it theoretically offers significant performance improvements compared to the current EVM. Certain design aspects of the EVM are a barrier to improved Ethereum node performance. Link.

The second proposal is more dramatic and considerably less defined. Today, a developer can deploy a smart contract to the network by paying a one time gas fee. Subsequent state altering calls to that contract also require fee payments. The proposal being considered would introduce some kind of "rent" system. Presumably, developers would need to pay a gas fee not just for smart contract deployment, but also on a regular basis to keep the smart contract active on the network. Contracts that didn't pay their rent would be evicted from the network state tree. The motivation here seems to be concern over the growing disk space and I/O requirements needed to run an archiving node. Many have brought this issue up in the past, but this proposal is the first indication that the core devs actually consider a serious concern. Until now, it's mostly been dismissed as a myth. Take, for example, this article published a couple of weeks ago. Link.

There's a lot to unpack from these meeting minutes and the proposals they detail. First, it's important to note that nothing official has been decided. The proposals are still nascent. As of now, the Ethereum devs have merely established working groups to explore them. With that caveat in mind, I see plans for an interim upgrade to the network as a pragmatic and welcomed move. This stems mostly from my skepticism about the Ethereum 2.0 timeline.

As I've said before, my engineering instinct tells me that two years is not nearly enough time for changes that require first solving fundamental research problems, then implementing those solutions on a live, permissionless, decentralized network. I'd love to be proven wrong here, but if I'm right-- and it turns out the Ethereum 2.0 upgrade takes three to five years instead of two-- then an interim upgrade that picks off some low hanging fruit seems prudent.

That doesn't mean I see the proposals being discussed for Ethereum 1.x as a slam dunk. In fact, I have major questions about both of them. WebAssembly, for one, is still under heavy development. It's not clear that now is the right moment to adopt it on Ethereum. I'm also curious about the details of a would-be rent system for smart contracts. While it might be necessary to curb the growing size of the archived state, it will also come with its own set of tradeoffs. If nothing else, it will impact the economic viability of smart contracts for many use cases.

Overall, though, I'm pleased to hear these issues are being discussed and worked on. If the hardware requirements to run a full node are indeed on a trajectory which outpaces the improvements to commodity hardware, then it's best to tackle the issue sooner rather than later. While it might be tempting to wait for Ethereum 2.0 to come along and solve all these problems simultaneously, such an approach puts too much pressure and risk on that upgrade. As always, stay tuned. Interesting times ahead!

📊 Statistics

1.2 MB. The average size of blocks on the Bitcoin network in recent days, with SegWit adoption hovering at 44%. According to this analysis, block size could realistically approach 2 MB as SegWit adoption nears 100%, but is unlikely to approach the theoretical maximum of 4 MB. Link.