An influx of research and development is beginning to form around ethereum 1x, a proposed upgrade that aims to more quickly improve the usability of the world's third-largest blockchain.

While the exact code changes that will comprise the upgrade have yet to be settled, active discussions suggest a myriad of different proposals could be activated by June 2019, should a final proposal ultimately be formulated, proposed and approved by users of the ethereum network.

Still the plan, first reported by CoinDesk last week, is in its early stages of development.

Indeed, there's even been a suggestion by Afri Schoedon, release manager for the Parity ethereum client, to release the upgrade on its own, separate blockchain network. Nevertheless, there are many voices contending ethereum 1x ought to be activated on the existing blockchain – and soon.

Originally thought to be an addition to an upgrade called ethereum 2.0 – ethereum creator Vitalik Buterin has referred to it recently by an older name “Serenity” – the roadmap for this upgrade changed in June to include new design specifications that are projected to delay activation.

As explained to CoinDesk by Schoedon, developers are now more certain ethereum 2.0 will not go into production before the year 2020. According to Schoedon, developers “started panicking and saying, ‘Hey we really need to find intermediate solutions’” – creating the impetus for new ideas able to be implemented in the near-term.

And though ideas for ethereum 1x may “sound too radical or controversial” for now, Schoedon said that the goal is to discuss any and all ideas inclusively with community stakeholders such that “none of the upgrades will be controversial in the end.”

With plans for ethereum 1x originally discussed during in-person meetings at an ethereum developer conference, Devcon4, earlier this month, certain members of the community were disgruntled at the lack of public involvement. Still, the controversy has been set aside for now with the creation of public forums to openly discuss ethereum 1x.

In addition, meetings to coordinate efforts on this proposed upgrade are expected to proceed under Chatham House Rules, meaning public disclosure of the content of discussions must exclude speaker attribution.

With the intent of encouraging open discussion among developers, the first of these meetings will occur tomorrow at 14:00 UTC.

“We need to to be very sensible about how we do this,” Schoedon told CoinDesk, adding:

According to meeting minutes from earlier discussions at DevCon4 published by Dan Heyman, the program director of ethereum blockchain development group PegaSys, there are currently four different working groups tasked with advancing ethereum 1x.

One of these groups, led by ethereum core developer Alexey Akhunov, is leading the effort to introduce storage rent to the ethereum platform. Storage rent is a mechanism discussed by developers in detail back in March. Its purpose is to curb the growth of the ethereum “state” – otherwise understood to be all of the active applications and accounts operating on the blockchain network.

Given the fast acceleration of decentralized applications (dapps) built on ethereum through smart contracts – self-deploying lines of code – the amount of data being stored on the blockchain to support these contracts is also increasing.

This presents an issue for new users wanting to participate in the network by deploying software called nodes that download and maintain a full copy of the active blockchain state.

The larger the state, as Akhunov told CoinDesk, the longer it takes for new computers joining the ethereum network to download such copies and maintain them.

Adding to this, Schoedon estimated the size of ethereum blockchain data to be currently sitting at around 125 gigabytes, with the active running state of the network being roughly 10 gigabytes.

“It's growing at a pace that we're probably looking at 200 or 300 gigabytes of chain data by end of next year and a massive state,” said Schoedon.

As such, the proposal to charge a fee to users who are storing smart contract data on the blockchain is aimed at mitigating the speed at which the ethereum blockchain is currently growing and thereby ensure accessibility of the network for all users at least in the short-term.

However, this is not the only proposal currently being discussed among developers. An alternative proposal suggests moving certain portions of smart contract data off-chain. This would effectively push the responsibility of data storage to dapp developers.

The mechanism – called “stateless contracts” – to facilitate off-chain smart contract data would be simpler to implement than storage rents, Akhunov concedes.

Still, there are concerns with this proposal as it relates to how dapp developers share and update off-chain data.

“I have a problem with stateless contracts at the moment. People think they are actually easier to implement and they are easier to implement in terms of protocol upgrade,” said Akhunov. “But they will be much harder for the dapp developers to support.”

In addition to storage rent, another 1x-focused group is exploring proposals to archive old information stored on the blockchain in a bid to relieve the pressures of a growing state.

But outside of ethereum’s data storage mechanisms, a third team of developers – called “the simulation group” – aims to “analyze the issues that happen through the blockchain when block size grows or when the latency increases,” Akhunov said.

This is particularly relevant due to code optimizations that have increased the speed of block propagation on ethereum presently. As a result of new blocks being relayed throughout the network more quickly, ethereum miners are also expected to be able to add in a greater number of transactions per block and collect a larger amount of transaction fees.

Akhunov said that studies suggesting exactly how much more the maximum amount of transaction fees collected by miners – called the “gas limit” – are few and far between.

“There are only a few studies that have been done to analyze how blocks propagate through the network and what would happen if you raise the gas limit,” said Akhunov.

Some of the development efforts going into ethereum 1x are focussed on running simulations to test higher gas limits, given that it's a key area of research around the wider progress toward relieving scaling pressures faced by the network today.

As such, ethereum 1x – outside of addressing issues to do with blockchain state size – is also expected to feature improvements to transaction throughput on ethereum. Indeed, the two issues go hand-in-hand in the context of supporting more network activity.

According to Akhunov, ethereum 1x is an “ensemble” of different proposals that are only effective when deployed together.

He told CoinDesk:

The dovetailing nature of the groups also covers the fourth working team, which is looking into decreasing the cost of smart contract deployment. The idea is that such efforts could lead to ways to balance out a potential increase to smart contract storage costs with proposals like the rent one.

By putting forward an early implementation of eWASM – a new virtual machine that processes smart contract code – ethereum developers aim to leverage the new technology and create so-called “precompiles” more easily.

Precompiles are commonly deployed smart contract operations that are optimized to run natively on ethereum for a fixed fee, or gas cost. And as Akhunov explains, there are currently only a handful created on the ethereum network.

But the demand is high for more to be added to streamline smart contract development.

With a “limited number of people in the core development team,” Akhunov admits that “if we try to start implementing all the precompiles people are asking for, we’re never going to be able to do anything else.”

One of the biggest hurdles when it comes to developing precompiles is deciding what a fair gas cost for a particular smart operation should be.

Normally, developers create formulas to gauge the energy and time precompiles take to execute. But through leveraging the eWASM engine, this process of pricing is done automatically.

As Akhunov highlighted:

Predicting the construction process of precompiles to get much “easier” for ethereum core developers through the technology, Akhunov also added that once fully-tested, “the plan is to open eWASM for all smart contract developers.”

Indeed, the longer-term goal is to do away with the need to create precompiles all together. Among other benefits to smart contract developers, the eWASM engine as previously reported is expected to run all smart contract operations at native network speeds and efficiency.

Still, until that future is realized, etheruem 1x is envisioned to sustain the ethereum network with what Parity developer Afri Schoedon calls “out of the box” solutions.

And while all these solutions are projected to be activated on “a very accelerated timeline,” Schoedon highlights that, on his part, no concrete action will be taken until a "broad consensus in the community" is reached.

Correction:  A previous version of this article referred to stateless contracts as stateless clients.  

Image via CoinDesk archives