Stateless Clients: What's New in Ethereum 1.x
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, Author: Piper Merriam, translation: A Jian, reprinted by Odaily with authorization.
Like all commons, the Ethereum network also has many maintenance problems: the continuous expansion of state data, the longer and longer synchronization time, and the popularity of the full node is getting smaller and smaller. If left unchecked, these issues pose serious threats to the future of Ethereum 1.x.
These issues were first taken seriously by core developers and community developers at Devcon4, and the research on the current upgrade direction of the Ethereum protocol was dubbed "Ethereum 1.x". But recently, 1.x research has stagnated, because more and more people have shifted their interest to Ethereum 2.0-this is also understandable, Eth2.0 is more fascinating after all.
However, Ethereum 2.0 (Serenity Tranquility) will not be fully realized until 2 to 3 years later, 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 state data expansion, longer synchronization time, and decreased network health are all urgent. Additionally, there are as yet no clear plans to migrate the current Ethereum chain into an execution environment for Eth2.0.
After meeting with some client developers in Osaka this year, I discussed these issues in depth with others, and without exception, we all agreed that 1.x research and upgrades make sense.
Together, we have defined a new direction and plan, hoping to keep the Ethereum 1.0 chain alive and healthy while running towards serenity.
We prepare:
Lay a solid foundation for a smooth transition to become an execution environment for 2.0
cause
This is a complex undertaking that will undoubtedly require the cooperation of many teams. But after an ice-breaking videoconference this week, we have bravely opened a new chapter in Ethereum 1.x research.
secondary title
cause
The story begins with the first release of the Trinity client in early 2018. Trinity is an Ethereum client written in Python. Because Python is an interpreted language, it's impossible to compete on performance with peers like Go or Rust; but it has some nice features.
After the release of the first beta, we worked hard to achieve fast synchronization of blockchain data, only to come to a frustrating conclusion: the performance of this client seems to never be able to let people go Use it, no one wants to wait weeks for their nodes to sync.
After "quick sync" didn't work, we started looking for new things to do. Over the next 9 months, we iterated on the idea of "can we avoid this problem entirely?" If we can really avoid this problem, we can quickly get the client to work online, and the activity of synchronous completion and online work used to take several hours or even days to complete.
One day in September 2019, we made a prototype, which we called "beam sync".
Beam sync is inspired by the concept of "stateless client": using a part of data called "block witness (block witness)", beam sync will not download the complete state like "fast sync" when synchronizing, but only pass in The data needed to complete the state transition. Gradually, as the synchronization process touches more and more states, the client can reconstruct the complete blockchain state and switch to full sync mode.
Because only those data needed to execute the block are fetched and executed immediately, nodes using mainbeam synchronization can be up and running almost instantly (although far from optimal, but informal testing proves that: after downloading It only takes about 5 minutes to start running after all block headers).
Since the concept behind beam sync has been most fully proven, the Trinity team has moved from quietly researching to experimenting with a usable beta version. We plan to release the beta version in the second quarter of 2020.
secondary title
Alexey Akhunov spends a lot of time trying to solve the state explosion problem. More recently, he concluded that stateless clients are the most viable approach, moving away from more controversial directions like state rents. (Editor's Note: Please refer to the hyperlink at the end of the article)
And Beam sync essentially starts from a stateless mode, and gradually transitions to a rich state mode as the blocks are gradually downloaded to the local database. With Beam sync online, we will soon be able to outline a clear path to a network that is good at providing the ingredients needed for stateless clients.
Moreover, the stateless client is theoretically compatible with the current client model, which means that Alexey's research can come in handy, it will only bring some incremental improvements to the network, and does not require large-scale A controversial, protocol layer improvement.
secondary title
From 1.x to 2.0
Because of this, being able to run reliably on stateless clients may become a prerequisite for migrating the Ethereum 1.x network to a shard of 2.0.
Therefore, we are committed to the stateless execution scheme of Ethereum 1.x, and we are also making necessary preparations for the smooth migration of 1.x.
In other words: statelessness today, serenity tomorrow.
secondary title
Formalizing 1.x Research
On the last day of Devcon, I was in a discussion about how to get the 1.x research work started again. Everyone present knew there was a problem and expressed an interest in solving it. This is the last thing that makes me happy.
If Trinity and the rest of the client team can improve the networking elements of the client and support beam sync, we can make the Ethereum network completely stateless. The stateless clients of Ethereum 1.x, in turn, will prepare the protocol for migration to an execution environment on Ethereum 2.0 when the grapes are ripe.
Inspired by the 9 (and more) teams that developed the Ethereum 2.0 client, we hope to achieve in-depth cooperation among different teams and form a clear and lofty Eth1.x vision, which can be divided into specific results vision.
