Perspectives | Stateless Clients: New Trends in Ethereum 1.x

Author: Piper Merriam

Translation: A Jian

Source: Ethereum enthusiasts

The Ethereum network, like all commons, also has many maintenance problems: the continuous expansion of state data, increasingly long synchronization time, and the popularity of the full node is getting smaller and smaller. If left unattended, these issues will pose a serious threat to the future of Ethereum 1.x.

• One article to understand why 2019 is the year of DeFi and 2020 is the year of DeFi
• China Europe Business School Gong Yue: DAO and Alliance Chain, a dispute that began with Hayek and Keynes
• Vitalik's latest thinking: what kind of subversive effect the second party payment will bring

These issues were taken seriously by core developers and community developers at the time of Devcon4, and research on the current direction of the Ethereum protocol upgrade was dubbed "Ethereum 1.x". But recently, research on 1.x has stalled, as more and more people are shifting their interest to Ethereum 2.0-which is understandable, Eth2.0 is more fascinating after all.

However, Ethereum 2.0 (Serenity) will take another 2 to 3 years to fully realize, of which Phase 0 and Phase 1 will be realized in 1 to 2 years, and Phase 2 may not arrive until 2022.

At the same time, problems such as the expansion of state data, longer synchronization time, and decreased network health are all urgent. In addition, to date, there is no clear plan to migrate the current Ethereum chain into an execution environment for Eth2.0.

After meeting with some client developers in Osaka this year, I and others discussed these issues in depth, and we all agree that the research and upgrade of 1.x are meaningful.

Together, we have determined a new direction and plan, hoping to ensure the survival and health of the Ethereum 1.0 chain while moving towards tranquility.

We prepare:

• Fundamentally improve the user experience of running the Ethereum client software

• Further increase the client diversity of the Ethereum network

• Consolidate the foundation to smoothly transition into an execution environment of 2.0

This is a complex task and undoubtedly requires the cooperation of many teams. But after an ice-breaking video conference this week, we opened the new chapter of Ethereum 1.x research with solitude.

cause

The story also begins in 2018, the first release of the Trinity client. Trinity is an Ethereum client written in Python. Because Python is an interpreted language, it's impossible to outperform peers like Go or Rust in performance; but it has some great features.

After the first trial version was released, we spent a lot of effort on achieving fast synchronization of blockchain data, but only got a frustrating conclusion: the performance of this client seems to never be able to let people go With it, no one wants to spend weeks waiting for their nodes to complete synchronously.

After "quick sync" didn't work, we started looking for new things to do. Over the next 9 months, we continue to iterate based on the idea of ​​"Can we completely avoid this problem?" If we can avoid this problem, we can quickly get the client online, and the activities of synchronous completion and online work took several hours or even days to complete in the past.

One day in September 2019, we made a prototype, and we called it "beam sync".

Beam sync is nothing else, it just wants to improve the user experience of the client. We want our clients to be up and running as fast as possible-even if the hardware is ideal, the "fast sync" will be completed in less than 4 hours.

Beam sync is inspired by the concept of "stateless client": using a part of data called "block witness", beam sync does not download the complete state like "quick sync" during synchronization, it only passes in The data needed to complete the state transition. Gradually, as the synchronization process touches more and more states, the client can rebuild the complete blockchain state and switch to full synchronization mode.

Because only the data needed to execute the block is extracted and executed immediately, the nodes synchronized using the main beam can be started and run almost instantaneously (although it is far from optimal, but informal tests have proven that: download It only takes about 5 minutes to run after all block headers).

Because the concept behind beam sync is fully validated, the Trinity team has moved from quiet research to working out a working beta experiment. We plan to release a beta version in the second quarter of 2020.

From Beam Sync to stateless clients

Alexey Akhunov spent a lot of time trying to solve the state explosion. Recently, he concluded that stateless clients are the most viable solution to abandon more controversial directions such as state rents.

Beam sync essentially starts from a stateless mode, and gradually transitions to the rich state mode as the blocks are gradually downloaded to the local database. With Beam sync online, we can quickly outline a clear path to achieve a network that is good at providing the raw materials required by stateless clients.

And stateless clients are theoretically compatible with the current client model, which means that Alexey's research achievements can come in handy, it will only bring some incremental improvements to the network without the need for large-scale , Controversial protocol layer improvements.

From 1.x to 2.0

A stateless 1.x network is also very important for Ethereum 2.0: validators will be shuffled into shards that they do not understand, so they must be able to rebuild the latest state of a shard very quickly-none Stateful execution environments appear to be the most feasible cross-shard verification scheme.

Because of this, being able to run reliably on stateless clients may become a prerequisite for the Ethereum 1.x network to migrate to a certain shard in 2.0.

Therefore, dedicated to the stateless execution of Ethereum 1.x, we are also doing the necessary preparations for the smooth migration of 1.x.

In other words: the statelessness of today, the tranquility of the future.

Formalize 1.x research

On Devcon's last day, I was in a discussion about how to get the 1.x research started again. Everyone present knew that there were problems and expressed interest in solving them. This is the last thing that pleases me.

If Trinity and other client teams can improve the client's networking components and support beam sync, we can fully enable the Ethereum network to implement a stateless mode. The stateless client of Ethereum 1.x, in turn, will also prepare for the protocol to migrate to an execution environment on Ethereum 2.0 when the grapes mature.

Inspired by the 9 (and more) teams developing the Ethereum 2.0 client, we hope to achieve in-depth cooperation between different teams and form a clear and high-end Eth1.x vision, which can be cut into specific results Vision.

We will form regular video conferences, and next spring we will organize an Ethereum 1.x research summit.

Right now, the best way to join this movement is to participate in discussions on the Ethereum 1.x section of the etherum research forum. If you are interested in joining the 1.x research revival, please introduce yourself and ask us to pull you into the telegram group and join us in our next video conference (temporarily planned to be a bi-weekly meeting from the publication of this article).

Ethereum 1.x is long!

(Finish)

We will continue to update Blocking; if you have any questions or suggestions, please contact us!