“`html
ETH 1.x: a rapid synchronization
The new trajectory of ETH 1.x investigation has officially commenced, concentrating on directing the existing Ethereum chain towards the ‘stateless client’ model, with the ultimate aim being a seamless transition into an Eth 2.0 Execution Environment.
The forthcoming call will center on gathering and structuring research subjects and devising a more organized timeline. The meeting is accessible for anyone interested in attending, and is set for December 17th at 16:00 UTC — if you wish to participate, please DM Piper Merriam or James Hancock on the ethresear.ch forum.
This article serves as a summary of all that has led us to this point, and may act as a resource for anyone who may have recently entered the Ethereum community, missed the Ethereum 1.x dialogues as they occurred, or needs a slight memory jog.
In the spirit of –sync-mode=fast, we will touch on the majority of historical research topics and reserve the detailed examination of stateless clients and ongoing studies for a future post.
Our narrative begins with a realization among core developers that the final stage of the Ethereum roadmap, “Serenity”, would not be available as early as initially anticipated. With potentially several years until a complete “Ethereum 2.0” deployment, the existing chain required modifications to ensure that larger issues would not incapacitate Ethereum before a thorough protocol upgrade could be executed. Thus, “Ethereum 1.x” — research into minor, incremental enhancements to current Ethereum (1.0) — was initiated with the objective of extending the chain’s lifespan for at least another 3-5 years until a more substantial upgrade to Serenity (Eth 2.0) takes place.
What’s the issue?
It’s complex. Unlike a security flaw or major design issue, there isn’t a singular urgent concern that we can pinpoint with Ethereum 1.0 and direct focused resources to rectify. Similarly, if things are completely left unattended, there probably won’t be one dramatic incident that causes the network to malfunction and ignite 🔥.
Instead, the ETHpocalypse scenario emerged from minor, subtle declines in performance and diminishing network vitality due to natural chain growth. Without 1.x initiatives, over time Ethereum risks becoming more centralized as it grows more difficult to operate full nodes, slower as network latency increases, and block verification becomes tougher due to state bloating, ultimately resulting in frustration for both end users and core developers as transaction throughput hits a maximum and client enhancements become more challenging to implement. The aim was to circumvent a death by a thousand cuts scenario that would evolve over years and be recognized too late by starting to plan immediately, commencing at Devcon4 in Prague (🦄 > 💀).
Generally speaking, the challenges at hand are all facets of one fundamental and unremarkable reality: The blockchain keeps expanding, but there’s some subtlety here, and when discussing “the size of the blockchain”, we are primarily talking about the dimensions of a few different sub-components, and more crucially about how their size impacts the network’s performance.
Let’s delve into them one at a time!
Chain storage
“If anyone so much as whispers a word about “storage costs of blockchain,” just direct them to the Amazon Black Friday webpage. 8TB for $125. There are significant issues blockchains confront. Storage expenses are not one of them.
–Emin Gün Sirer (@el33th4xor)
Before a complete node can gain status as a first-class participant in Ethereum, it must synchronize the entire history of the blockchain. The longer that history is, the more data there is to accommodate. Currently, storage necessities are roughly 219 GB for a ‘standard’ full node in both parity and geth, increasing by 10-15 GB each month.
This isn’t too problematic, from an absolute cost-of-storage viewpoint. It has always been Ethereum’s aspiration to operate entirely on consumer hardware, and excluding archive nodes (which necessitate ~3.5 TB), under 500GB is well within a reasonable range, thus operating a full node won’t be infeasible for a few more years. The stronger point of contention relates to the marginal expense of initiating new full nodes: Escalating storage necessities and synchronization durations lead to fewer full nodes, which in turn results in even longer synchronization periods, thus diminishing the number of nodes even further.
Over time, developers will increasingly depend on services like Infura, and the ‘true’ blockchain will be increasingly entrenched in the cloud, out of reach for average hobbyists, researchers, and casual developers.
Block size and transaction throughput
Another facet of growth pertains to the size of individual blocks and their connection to overall transaction throughput. Unlike Bitcoin, Ethereum does not explicitly restrict the size of a block by memory but enforces the block size through a gas limit. The gas limit in Ethereum effectively caps the number of transactions that can be incorporated into a block, and is collectively determined by miners, with voting to adjust the gas limit dynamically. Recently, miners collectively consented to elevate the block gas limit to around 10 million gas units, making each block approximately 25% larger than it had been since Jan ’18’ — and, by extension, enhancing theoretical transaction throughput.
There exists a trade-off between the block gas limit and the ability of miners to achieve consensus on new blocks. Increased gas limits theoretically will enhance the frequency of block uncles (valid blocks that do not propagate to other miners rapidly enough to be accepted by a majority). More data is required to ascertain what a ‘safe’ upper bound is for block sizes, but it’s generally acknowledged that throughput advantages to be gained from augmenting the gas limit will not suffice for Ethereum’s expansion over the next five years. Furthermore, larger block sizes accelerate the requirement for chain storage.
“`problem.
State Size and Network Efficiency
Ethereum operates as a state machine progressing one step at a time with each block. At any particular moment, the entire ‘state’ of Ethereum consists of the combined memories of all smart contracts that are deployed and functioning in the EVM, alongside the current conditions of all accounts and balances. When transactions are incorporated into a block, they modify the state by altering account balances, deploying new smart contract codes, or by triggering a smart contract to execute portions of its code.
The overall size of the state presently is approximately 50GB. It follows logically that the state expands in proportion to the total transaction volume on the network, so if we anticipate Ethereum to maintain its growth in mainstream acceptance, that figure could escalate significantly in the years ahead.
A more extensive state impacts all clients along two principal performance dimensions:
- Slower transaction processing stemming from limitations of clients accessing state. Executing a transaction necessitates querying the relevant section of the state stored in the client’s database. The more extensive the state, the longer it takes to locate the transaction. Notably, in clients that employ a trie structure to depict state (parity, geth, trinity), this deceleration is compounded by the underlying database query (wherein the trie is realized).
- Slower block verification due to the reconstruction of new state from alterations. Following similar reasoning to the previous point, when a new block is verified, the state changes must be recalculated by the client; this involves formulating a new state trie and calculating a new root hash. Creating a new state trie is more computationally demanding than a straightforward lookup, thus, this operation experiences greater impact from state expansion than processing an individual transaction.
State-driven performance decline is particularly concerning. Ethereum functions as a peer-to-peer network, implying that minor adjustments can yield cascading impacts on network wellness. Moreover, managing state storage and modifications is among the more complex tasks for client development teams. Crafting and sustaining clients is already sufficiently challenging, and state expansion adds to that strain. As the state enlarges, the variety and performance of clients will suffer, which is detrimental to all.
What are the prospective solutions?
Beginning with the initial gathering in Prague and continuing through 2019, various core developers, contributors, and wizards have convened both online and in person to deliberate on optimal strategies for prolonging the lifespan of the 1.0 chain. Below are the key proposals discussed and what they involve:
Moderate optimizations and mitigations
-
More assertive pruning. One method to handle storage requirements is to actively remove segments of the chain that are no longer necessary, such as transaction receipts, logs, and earlier historical blocks. A mutually agreed period (3-9 months) of historical data would be retained by full nodes and subsequently eliminated after it becomes outdated, effectively limiting the total storage required for node operation. Péter Szilágyi provided a thorough overview of the impacts of chain pruning for long-term sustainability. TL;DR — there are compromises, and one unresolved necessity is that historical data must be accessible (somewhere), and instead of complete chain history, nodes must maintain proofs for removed chain segments.
-
Block pre-announcement and state caching. These address the minimization of the impacts caused by network latency. In block pre-announcement, the concept is that a miner announces a new block prior to its validation, which allows listening clients the opportunity to predict which portions of state will be impacted and proactively prepare those caches for the upcoming state. Similarly, clients could retain partial states in memory to avoid starting from scratch should syncing the state fail. These enhancements are presently obtainable, and variations on this theme are already utilized by turbo-geth to boost performance.
Significant, hard-forking modifications
-
Opcode re-pricing and ETH lockups . Generally, this entails merely adjusting the costs of opcodes to further deter state growth. Broadly, this includes elevating the costs of operations that expand state and/or enhancing the rewards for operations that contract state. Refunds, however, pose a bit of a challenge, as they must derive from gas included with the transaction — this indicates that transactions which only clear memory or destroy contracts cannot genuinely receive proportional refunds. To enable transactions to earn more in gas than they utilize, it may be feasible to necessitate contracts to lock up a portion of ETH upon deployment, sufficient to cover those refunds.
-
State rent and ‘eviction’. More drastic than the aforementioned opcode price adjustments, state rent pertains to directly minimizing the size of state by mandating that contracts pay a recurring charge relative to their share of the state size. The contract would be eliminated or suspended until the fee is settled. This would represent a substantial, transformative modification to smart contracts and dapp developers and would necessitate more than one hard fork for implementation. To this date, it remains the most extensively debated proposal within the 1.x category, as well as the most contentious. Consequently, research regarding state rent on the 1.0 chain has been put on hold.
The new path: ✨Stateless Clients✨
If the size of the state is the principal issue affecting network health, the ideal solution would be to eliminate the dependence on state altogether. In essence, a stateless client utilizes a block witness, which verifies the legitimacy of a specific state change in relation to the preceding state. Rather than calculating a complete state with every new block, clients merely calculate the alterations to state for a new block, and then confirm that those modifications are consistent with the prior block. Miners and some full nodes will stillneed to maintain a complete copy of the state for witnesses to be produced from, and the necessity for block witnesses to be circulated throughout the network presents new challenges for clients. However, the potential advantages of this modification are extensive.
Note: This is still in its preliminary research phases and should not be considered an established element of the Ethereum roadmap or in any manner ‘validated’ as a concept. Stateless clients face several significant technical obstacles that need addressing, all of which will be clarified in future updates as research progresses.
The stateless client concept initially emerged in the Ethereum ecosystem through a post by Vitalik regarding sharding, but was also later addressed during discussions on Eth 1.x; it was deemed too intricate to execute at that time. Nevertheless, recently, support for the stateless client concept has increased as Trinity’s beam sync showcases the practicality of semi-statelessness for light clients.
Crucially, transitioning towards a stateless or semi-stateless model is less disruptive to the current network than approaches like state rent, as it does not fundamentally cause breaking changes for existing clients. Stateful nodes and stateless light clients can coexist without conflict, and the advent of semi-stateless Ethereum provides greater room for experimentation with various client implementations. As an added bonus, shards on Eth 2.0 are likely to be stateless, creating a new pathway toward a future migration to Serenity when it is prepared for mainstream adoption.
We will reserve a more profound exploration of stateless clients for a subsequent post. If you have reached this point, you are now informed about the present state of Ethereum 1.x research and should be able to keep up and participate in new developments as they arise! Join us at ethresear.ch, or stay tuned here for the next installment of ‘the 1.x files’ 🙂
