The Ethereum network, like many common-pool resources, has some maintenance problems: Burgeoning state bloat, ever-increasing sync times, declining popularity of running full nodes. If left un-addressed, these issues pose an existential threat to the future of the Eth1.x network.

This fact began to gain some serious attention from core and community devs around Devcon IV, and research into upgrades to the current Ethereum protocol were codenamed ‘Ethereum 1.x’. But recently, 1.x research has stalled as more and more people shift their focus to Ethereum 2.0 — and that’s understandable. Eth2.0 is sexy.

Unfortunately, Ethereum 2.0 (Serenity) won’t be fully rolled out for another 2–3 years, with Phase 0 and Phase 1 due within 1–2 years and Phase 2 due sometime in 2022.

Meanwhile, the problems of state bloat, sync times, and overall network health are immediate. Furthermore, the reality is that until now there has been no clear plan for migrating the current chain into an Eth2.0 execution environment

After a gathering of client developers this year in Osaka, I and others discussed these problems at length, and we all agreed that a revitalized plan for 1.x research and upgrades are needed.

Together, we’ve set into motion a new direction and plan for keeping the 1.0 chain alive and healthy while we move closer to Serenity.

We’re going to:

Fundamentally improve the UX of running an Ethereum client

Improve client diversity on the Ethereum network

Lay the groundwork for moving smoothly from 1.x into a 2.0 execution environment

It’s ambitious, complex, and will depend on a lot of cross-team collaboration, but after a kickoff call this week, a new chapter of ETH1.x research has begun.

Origins

The story begins back in early 2018, with the first release of the Trinity Ethereum client. Trinity is written in Python. As an interpreted language, Python will never win in a head-to-head race with the likes of Go or Rust; it has some great properties, but raw speed is not one of them.

After the first alpha release, we chipped away at our implementation of fast sync only to come to the depressing conclusion that we were never going to be performant enough for it to be a viable option. Nobody is going to wait multiple weeks for their node to sync.

With ‘fast sync’ off the table we had to try something new. Over the next 9 months we iterated on an idea that promised to side-step the problem entirely. If the idea worked we would be able to bring the client online in moments, something that previously took hours or days.

Sometime in September of 2019 we had a working prototype of what we now call beam sync.

Beam sync is more about client UX than anything else. We want clients to be up and running as fast as possible — and at about 4 hours even with ideal hardware, ‘fast sync’ isn’t nearly fast enough.

Beam sync is inspired by the concept of ‘stateless clients’: using a block witness, beam sync pulls only the data it needs to execute changes to the state, instead of downloading the whole state as ‘fast sync’ does. Over time, as more and more of the state is touched by the beam-syncing node, it can build up a complete state and switch over to full sync.

By pulling just the data needed to execute each block, and starting execution immediately, a beam-syncing node can be up and running almost immediately (it’s far from optimized, but informal tests suggest ~5 mins after all headers are downloaded).

With the concept behind beam sync fully validated, the Trinity team has shifted gears from quiet research and experimentation to getting a working beta release out the door. We’re aiming for Q2 of 2020.

From Beam Sync to Stateless Clients

Alexey Akhunov has spent a lot of time trying to tackle the state bloat problem — recently it seems he’s settled on stateless clients as the most viable solution, tabling more controversial directions such as state rent.

A beam-syncing node is essentially operating in a stateless paradigm, moving gradually toward statefulness as it back-fills its local database. With the advent of Beam sync, we suddenly have a clear path towards a network that is good at doing exactly the thing needed for stateless clients.

And stateless nodes are in principle compatible with the existing client model, which means the stage is set nicely for Alexey’s research, bringing small incremental changes to the network instead of massive, contentious protocol changes.

From 1.x to 2.0

A stateless 1.x network is also important in the context of Eth 2.0: Validators will be shuffled around between different shards, and they will need to be able to tune into a shard’s latest state very quickly — a stateless execution environment looking to be the most promising solution for cross-shard validation.

Because of this, it’s likely that a prerequisite for the Eth 1.x network migrating into an Eth 2.0 shard will be the ability for it to operate reliably on stateless clients.

So by focusing on stateless execution for ETH1.X, we will be working directly on the necessary changes for a smooth transition to Eth2.0.

In other words: Statelessness now -> Serenity later.

Formalizing 1.x Research

On the last day of Devcon I found myself in a discussion focused on how we can get 1.x research moving again. Everyone acknowledged there was a problem as well as an expressed interest in solving it. This is where the last pieces fell into place for me.

If Trinity and other client teams work to improve networking primitives and support beam sync, the very same efforts will move the Ethereum network toward a stateless paradigm. ETH1.x stateless clients, in turn, will prepare the protocol to transition to a 2.0 execution environment when the time comes.

Taking a cue from the 9+ teams working on ETH2.0 clients, we want to foster a high degree of collaboration between disparate teams and a clear, high-level vision for ETH 1.x that can be broken down into tangible deliverables.

We’ll be coordinating regular calls, and this spring will be organizing an Ethereum 1.x research summit.

For now, the best place to join the discussion is the new Eth1.x-research topic on the Ethresearch forums. If you’re interested in joining the revitalized 1.x research effort, come introduce yourself, ask for an invite to the telegram group, and join our next call (tentatively scheduled for ~2 weeks from the publication of this post).

May Ethereum 1.x live long and prosper!