The first post-Devcon4 Ethereum 1.x meeting featured updates from the initiative’s four working groups.
Ethereum 1.x, a proposed set of upgrades to the mainnet to occur alongside research and development for Ethereum 2.0 (aka Serenity), emerged during a series of core developer meetings at Devcon4 in Prague. 1.x, at its most basic, “will introduce major, breaking changes to the mainnet,” which focus on scalability, sustainability, and improved developer experience.
The first 1.x sync meeting occurred Friday, November 30, and adhered to the Chatham House Rule, meaning it was not recorded or livestreamed, nor were speakers identified in the notes published yesterday. The call included updates from the four main 1.x working groups: simulation, state rent, eWASM, and chain pruning.
The simulation working group is tasked with developing three setups: a simulation framework that, when a dataset is entered, produces an output to estimate properties of proposed changes (such as uncle rate reduction and gas limit increases); an emulation framework that alters environment conditions to test properties of launched changes; and a testnet that launches these changes together on the same network. This simulation platform, as it were, is intended to provide information to community members about project progress.
During the meeting, the simulation group reported some advancements, but it has not finalized any of its parameters for simulation. Group members specifically mentioned Whiteblock, an emulation framework they have worked on but are still determining the specifications for. Further, they are in the process of collecting datasets for simulation.
The state rent working group deals with the implementation of a rent system for the storage of EDCC (aka smart contract) data on Ethereum. A rent mechanism would, theoretically, help manage the ever-increasing Ethereum state, which includes the data from every EDCC deployed on the network. With the emergence of Dapps left and right, however, that state has grown dramatically, making it difficult and time-consuming for nodes to sync.
In the meeting, the idea of a stateless contract was broached as an alternative solution to the storage issue. Under this mechanism, portions of the EDCC data would be moved off chain, though a core developer noted there would need to be a subprotocol dedicated to the delivery of off-chain contract data.
The eWASM working group is developing a roadmap for implementing the new virtual machine, as the current architecture provided by the Ethereum Virtual Machine is considered to be inflexible. During the sync call, there was discussion regarding the introduction of eWASM through precompiles, which are EDCC operations with limited (but well-known) functionalities that have fixed gas costs. Because of their limited nature, precompiles have a minimal impact on consensus.
The final group, chain pruning, seeks to place a cap on Ethereum’s data storage growth. Part of the proposal includes the deletion of historical blocks, logs, and indexes. The group members noted during the sync that if Ethereum were to grow at its current rate, 91 GB would be added per year to storage. Although individuals were ambivalent about the implications of this growth rate and how to curb it, one speaker mentioned that the majority of Ethereum users do not necessarily care about historical data, so deletion of such information could be feasibly accomplished (though, as another participant indicated, there would need to be agreement on a data retention policy).
It’s important to note that the 1.x initiative, despite the advancements made thus far, remains a work in progress. There is no guaranteed roadmap for the upgrades.
Source: Read Full Article