How often is too often to alter consensus?

A group of ethereum’s veteran open-source developers discussed the subject in a bi-weekly meeting Friday, wherein they aired the possibility that system-wide upgrades, also called hard forks, to the software could be enacted as often as every three months.

Wanting to “check the temperature,” the developer asking the question explained that certain upcoming ethereum improvement proposals (EIPs) such as state rents would require multiple upgrades sequentially spaced out for full effect.

Three months, however, in the eyes of Joseph Delong, senior software engineer at venture capital studio Consensys, is “too quick for a turnaround.”

Team lead at the Ethereum Foundation Péter Szilágyi agreed, explaining:

“As a [software] client developer if you’re only job is to implement hard forks and do them then three months is fine but usually clients require a lot of maintenance. So, if you start doing three month hard forks it will essentially take all the time away from general maintenance and performance improvements.”

Ethereum Foundation security lead Martin Hoste Swende, while agreeing that a hard fork every three months “would be a bad thing,” noted that particular cases with simple changes unanimously agree upon could have shorter run times.

“The idea would not be to schedule a hard fork every three months but see if feature X is finished and there exist test cases and it is implemented in all clients. If so, then we can hard fork pretty soon,” argued Swende during the call.

But encouraging developers to take their plans “one step” at a time, Fredrik Harryson CTO of Parity Technologies noted that even a timeline of six months for a planned ethereum hard fork has never been achieved.

“There’s a couple things we probably need to automate in order to do [shorter hard forks] really well. A lot of the time that goes into the hard fork is not just making the code. It’s everything that goes around,” said Harryson.

In addition to this, Ethereum Foundation advisor Greg Colvin noted that most teams building ethereum software clients do not presently have “the right person” to handle essential jobs for hard fork implementation such as “setting up testnets, running test cases, doing testing” among other responsibilities.

To this, Harryson responded the matter was about not having enough finances to onboard such team members. “For us, it’s money. We don’t have enough money behind it,” quipped Harryson.

Multi-step upgrades

But it’s not only a matter of whether or not there should be more frequent hard forks.

Developers during today’s call also discussed whether there was a need for ambitious, longer-term changes to the present ethereum blockchain in light of an impending move to ethereum 2.0 – a new ethereum network which once fully activated users would migrate over to from the current mainnet.

Suggesting that developers like Alexey Akhunov and ethereum founder Vitalik Buterin have cautioned against “changes that aren’t for the survival of the [present ethereum] chain,” Harryson asked:

“How much do we sway outside of this because [EIP 615] leads into a long chain of improvements that go into several years before we’re seeing massive benefits from it.”

EIP 615 is one of five proposals considered for inclusion in the next ethereum hard fork called Istanbul. It aims to introduce improvements to the very heart of the ethereum codebase known as the Ethereum Virtual Machine (EVM) which is responsible for executing all self-deploying lines of code – also called smart contracts – on the platform.

The EVM is also a key technology that other enterprise blockchain initiatives such as Hyperledger have been reported in the past to build interoperability with.

“The design of the EVM makes low-gas-cost, high-performance execution difficult. We propose to move forward with proposals to resolve these problems by tightening the security guarantees and pushing the performance limits of the EVM,” writes the authors of EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic and Christina Reitwiessner.

However, as noted by Swende during today’s call, EIP 615 as proposed would require at least two hard forks to fully execute and “a positive speed effect” to actual code computations in the EVM would not be noticeable until the latter hard fork is executed.

“That’s my main concern about this EIP, it’s a lot of work but I don’t think it will lead to a much better EVM. It might be better for the external tools like if you’re doing a reverse analysis of the security properties of a smart contract,” said Swende.

Such tooling Zelenka suggested is essential to ensure continued “forward compatibility” with forthcoming EVM upgrades like eWASM and a smooth onboarding experience for smart contract developers in light of “an undetermined ethereum 2.0 release date.”

“There are other options for smart contract developers out there. We need to keep ethereum 1.x alive and that means continuing to move,” argued Zelenka on today’s call.

Agreeing to continue debate and discussion on the EIP in further weeks, Swende concluded that at present he remains skeptical about “implementing such large changes into the old engine which basically takes a couple of hard forks before it finally settles.”

But agreeing with uncertain sentiment around the future of ethereum 2.0, Harryson, who raised the initial question about ambitious, multi-hard fork upgrades said:

“We shouldn’t adjust our roadmap or thinking based on what ethereum 2.0 may or may not be.”

Fork image via Shutterstock