Ethereum Foundation: A Quick Look at Eth1.x Research

Author | Griffin Ichiba

Compilation | Jhonny & Tessa

The new direction of Eth1.x research has begun. The focus is to transfer the current Ethereum chain to the "stateless client" paradigm. The ultimate goal is to smoothly transition into an Executive Environment in Eth 2.0.

• A brief history of crypto exchanges: a glimpse into the evolution of the most powerful organization in the blockchain industry
• Crypto Industry Watch | There is no guide to bear markets, success is not limited to the present
• Miners must read: 8 tips to help you achieve long-term mining profitability

The next conference call will focus on collecting and organizing research topics and planning a more structured and relevant roadmap. This conference call is open for anyone to attend and is scheduled for 16:00 PM on December 17. If you want to join, please send a message directly to Piper Merriam or James Hancock on the ethresear.ch forum .

This article is a review of all our efforts. It might be helpful for those who have recently joined the Ethereum community and have missed the Eth1.x discussions, or want to go back a bit. In the spirit of "–sync-mode = fast", we will cover most of the historical research topics in this article, and leave in-depth explanations of stateless clients and current research in subsequent articles.

First of all, our core developers realized that the final stage of the Ethereum roadmap, "Serenity", would not be as early as expected, so it was ready to continue. The birth of a complete "Eth2.0" may take several years. We need to make improvements to the current Eth1.0 chain to ensure that before a complete protocol upgrade is implemented, there will not be a larger problem that prevents Ethereum from working . Therefore, "Eth1.x"-research on the smaller, progressive upgrades of the current "Eth (1.0)"-emerged with the goal of extending the life of the current Ethereum chain by at least 3 -5 years until the arrival of a more significant Serenity (Eth2.0) upgrade.

What's wrong with the current Ethereum blockchain?

The problem is complicated. It does not look like a security hole or a major design flaw, because Eth1.0 does not have a problem that needs to be solved urgently, which allows us to invest special resources to solve it. Similarly, if no changes are made to the current chain at all, it is unlikely that major events will cause the Ethereum network to stop functioning or "fire".

However, what may bring catastrophic conditions to the current Ethereum network is that with the natural growth of the chain state, the result is a slight decline in network performance and damage to network health . If Eth1.x is not carried out, Ethereum will face risks in the long run. As it becomes more and more difficult to run full nodes, this network may become more and more centralized; as the network delay increases, its speed may become slower and slower; with the emergence of "state inflation", Block verification may become more difficult. Eventually, as transaction throughput reaches its upper limit and client improvements become increasingly difficult to achieve, both end users and core developers will be frustrated .

Our goal is to prevent Ethereum from encountering a thousand swordsmanship situation. Even if this situation takes years to come, it is too late to start taking immediate measures at that time, so as early as during Devcon4 in Prague The discussion about Eth1.x has already begun (🦄> 💀).

Broadly speaking, the problem we face is a very fundamental and obvious display: the Ethereum blockchain is getting bigger and bigger , but there are some subtle differences when we discuss " the size of the blockchain " (the size of the blockchain), we are really discussing the size of some different sub-components, and more importantly, how the size of these components will affect the performance of the entire network. These sub-components include:

01. Storage requirements of the chain

"If anyone mentions the" blockchain storage cost "", just talk to them about Amazon Black Friday's web page: 8TB of storage costs $ 125. Blockchain faces some real problems, but the cost of storage is not one of them. "——Emin Gün Sirer ( @ el33th4xor )

Before a full node becomes a "first class citizen" of Ethereum, it must synchronize the entire history of the Ethereum blockchain. The longer the history is, the more data is stored. Currently, for a "standard" Parity or Geth full node, its storage requirement is about 219GB, and it grows by 10-15GB per month.

From an absolute storage cost perspective, this is not too bad . Running completely on consumer hardware has always been Ethereum's vision (except for archive nodes, because archive nodes require approximately 3.5TB of storage). Consumer hardware below 500GB is within a reasonable threshold, so running an Full nodes will not be out of reach in the next few years.

But a stronger argument comes from the marginal cost of starting a new full node: an increase in storage requirements and synchronization time will lead to a decrease in full nodes, which will further lead to an increase in synchronization time and a reduction in the number of nodes .

As a result, over time, developers will increasingly rely on services such as Infura, and "real" blockchains will become more and more trapped in the cloud, leaving ordinary enthusiasts, researchers and Amateur developers can't reach it.

02. Block size and transaction throughput

Another aspect of growth is the increase in the size of a single block and its relationship to the overall network transaction throughput . Unlike Bitcoin, Ethereum does not explicitly limit the size of each block by memory, but enforces the block size through a gas limit. Ethereum's Gas Limit effectively limits the amount of transactions that can be included in a block . This gas limit is determined by the miners collectively, that is, the gas limit is dynamically increased or decreased by voting. Recently, the miners collectively agreed to increase the block gas limit of Ethereum to about 10 million gas units, increasing each block by about 25% from the size since January 18, which theoretically improves the system's Transaction throughput.

There is a trade-off between block gas limits and the ability of miners to reach consensus on new blocks. In theory, a higher Gas limit will increase the unblock rate of the block (unblocks cannot be quickly propagated to other miners, so unblocks are valid blocks that cannot be accepted by most miners). We need to collect more data on what is the "safe" block size upper limit, but it is generally believed that the increase in throughput brought by increasing the gas limit will not be enough to achieve the development of Ethereum in the next 5 years. In addition, larger blocks will exacerbate the issue of chain storage requirements.

03. State size and network performance

Ethereum is a state machine that moves forward as the number of blocks increases . At any given moment, the complete "state" of Ethereum includes the collective storage of all smart contracts deployed and running in the EVM, as well as the current status of all accounts and balances. When transactions are added to a block, they change the state of Ethereum by changing the account balance, deploying new smart contract code, or having the smart contract execute some of its own code.

The current state of Ethereum is about 10GB . Theoretically, the state will grow proportionally as the total transaction volume on the network increases. Therefore, if we expect Ethereum to continue to gain mainstream adoption, this number is likely to grow significantly in the coming years.

Larger states affect two main performance points for all clients:

• The speed at which the client can read the state will be limited, so transaction processing will be slower . Processing a transaction requires reading the relevant part of the state stored in the client database. The larger the status, the longer it takes to find a transaction. More importantly, in clients that use a trie structure to represent state (such as Parity, Geth, and Trinity), this slowdown situation is exacerbated by the lookup of the underlying database (where the trie structure is implemented).
• Since a new state needs to be constructed by changing the state, a larger state will mean that the verification of the block will be slower . As with the above inference route, when verifying a new block, the client must recalculate the state changes; this involves building a new state trie structure and calculating a new root hash. From a computational point of view, constructing a new state trie structure requires more calculations than simply looking up, so the increase in state has a greater impact on this operation than processing a single transaction.

State-driven performance degradation is the most worrying. Ethereum is a peer-to-peer network, which means that small changes may have a ripple effect on the health of the network . In addition, storing and changing state is one of the things that makes the client developer team more headache. Writing and maintaining clients is hard enough, and state growth adds to the burden. As the state grows, the diversity and performance of customers will decline, which is bad for everyone.

What are the potential solutions?

Starting from the launch conference in Devcon4 Prague and continuing until 2019, many core developers, contributors and magicians gathered to discuss how to extend the life of the Eth1.0 chain. Here are the most important proposals and related content discussed:

01. Moderate optimization and mitigation

• More radical cuts . One way to manage your storage needs is to actively delete parts you no longer need, such as transaction receipts, logs, and older historical blocks . It is possible to reach a consensus on the period for which the historical data is to be stored at all nodes (for example, 3-9 months), and then delete it after the expiration, which can effectively reduce the total storage required for running nodes. Péter Szilágyi has provided a comprehensive overview of the long-term viability of the Eth1.0 chain with regard to chain deletion . In summary, there are some trade-offs in this method, and one of the unresolved requirements is that historical data needs to be available (somewhere), and replacing all the history records stored in the chain means that nodes must retain the deleted part Proofs .
• Blocks are announced in advance & status caching . This has to do with mitigating the effects of network latency. Publish the block in advance. The idea is that before the block is verified, the miner publishes the block in advance. This will give the listening client a chance to guess which part of the state will be affected and cache these for the next state. Be forewarned. Similarly, the client can save some state in memory so that it does not have to start from scratch if the synchronization state fails. These optimizations are currently achievable, and turbo-geth has used some variants of such optimizations to improve performance.

02. Making changes with large hard forks

• Opcode repricing & ETH lock . Usually, this means simply adjusting the cost of the opcode to prevent further growth of the state. In a broad sense, this means increasing the cost of operations that lead to a state increase, and / or increasing the rewards for operations that lead to a state reduction. But the way to refund is a bit tricky, because the refund must come from the gas included in the transaction, which means that those transactions that only clear memory or destroy the contract cannot actually get a refund proportionally. In order for the transaction to generate more revenue than expenditure on Gas, it is possible to require the contract to lock a certain amount of ETH sufficient to pay those refunds when it is deployed.
• State rent and 'recovery' . Even more striking than the above-mentioned way of repricing opcodes is the state rent approach by requiring the contract to pay a recurring fee proportionally to the size of the state it occupies . The contract will be deleted or terminated before this fee is paid. For smart contract and Dapp developers, this approach will be a major change, and this will require more than one hard fork to implement. This approach is by far the most widely discussed and most controversial proposal in the Eth1.x space. Therefore, research on the state lease of the Eth1.0 chain has been suspended.

Holy Grail: Stateless Clients✨

If the size of the state poses a major problem to the health of the network, the ultimate solution is to completely eliminate the need for the state. In short, stateless clients use block witnesses to prove the validity of a particular state change relative to the previous state . That is, the client will only calculate the state changes of the new block, and then prove that these state changes are consistent with the previous state, without calculating the complete state of each new block.

Miners and some full nodes will still need to save a complete copy of the state in order to generate block witnesses from it. Although for clients, propagating block witnesses across the entire network presents some new challenges, the potential benefits of this approach are huge.

The concept of stateless clients was first introduced by Vitalik while exploring sharding (sharding), but has since been explored in the discussion surrounding Eth1.x. At first this approach was considered too complicated, but recently, as Trinity's bean sync approach demonstrated the feasibility of semi-statelessness for light clients, the concept of stateless clients has gained a lot of support.

It's important that moving to a stateless or semi-stateless paradigm does less damage to existing Eth1.0 networks than methods such as state rent, because this approach does not cause major changes to existing clients . Stateful nodes and stateless light clients can coexist at the same time, and semi-stateless (semi-stateless) Ethereum will provide more opportunities for experimenting with different client implementations. At the same time, the shards in Eth2.0 will almost certainly be stateless, so when the time is ripe, this will open a new path for Eth1.0's final transition to Serenity.

We will explore stateless clients in more depth in another article. If you have read here, you are now up to date with the current state of Eth1.x research and can follow and join in related new developments! Join us at ethresear.ch, or stay tuned for updates from the foundation on Eth1.x.

[The copyright of the article belongs to the original author, and its content and opinions do not represent the position of Unitimes, nor does it constitute any investment opinions or suggestions. Posting articles is only for disseminating more valuable information. For cooperation or authorized contact, please send an email to [email protected] or add WeChat unitimes2018]

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