Ethereum Developers Converse on Whether or Not More Hard Forks Could Bring Benefits to ETH
One important question is currently pairing over the ETH core developers’ head: how often is too often when it comes to a change of consensus?
As reported by Coindesk, this was one of the main aspects of the network that was discussed in one of the bi-weekly ETH core developers’ meetings last week. An unnamed developer started the debate: what if ETH were to upgrade its consensus model every three months?
At the moment, it takes way more than time than that for a hard fork and it is a hard occurrence for a token to have more than one per year. However, as it is with everything in the blockchain sector, this could change soon.
The main idea is that some new upgrades and Ethereum improvement protocols (EIPs) could require many upgrades. Therefore, spacing them out could be a good time, in his opinion.
A senior software engineer called Joseph Delong, which was participating in the meeting, affirmed that this kind of turnaround is just too quick, though, so the idea is not suitable.
Péter Szilágyu, the team leader of the Ethereum Foundation agreed with Delong in this case. According to him, it would be fine to do it every three months if you only had to implement these changes but the truth is that they require a huge amount of time spent on maintenance.
If you keep piling one hard fork on top of each other, you will not have enough time for maintenance, which can become a serious issue down the road. Because of this, the performance of the network could be severely affected if the devs decided to implement such a tight schedule.
Martin Hoste Swende, the security lead at the Ethereum Foundation, has agreed that period hard forks every three months would be a very bad idea for the network. However, he agreed that if you change unanimously changes to do, you could implement them quickly instead of bundling them into big upgrades.
According to him, the ideal would not be to schedule a fork every three months but to see how many features are finished, if it can be implemented and then to decide whether a hard fork can be made soon.
It is a subtle difference, but an important one. This way, the devs would not need to rush in order to release updates on the schedule. This would, in his perspective, encourage them to plan one step ahead instead.
Fredrik Harryson, the CTO of Parity Technologies, remained cautious, though. According to him, ETH has not been historically able to make a hard fork in even six months alone, so three is not really something that should be considered.
He defended the idea that plenty had to be automated in order to have this level of productivity as most of the hard forks are not just creating the code but everything that is linked to the implementation and testing.
Greg Colvin, an advisor of the ETH foundation, also noted that most teams which are in charge of creating clients do not have the “right person” to make hard forks, as this generally requires a very specific set of skills which includes running test cases, testnets, etc.
Harryson’s answer was pretty straightforward: the main issue is that the client developers simply lack the money to hire these people.
The Future of The Ethereum Network
After not a long time, it was quite clear that upgrades every three months were simply not feasible at all. The debate got even more heated when some people started asking whether there was even any necessity for most of these changes.
Vitalik Buterin, the co-creator of Ethereum, has warned the team before against making any non-vital changes to the code. Ethereum will move to Ethereum 2.0 soon, which will have a completely new blockchain network. This would mean abandoning the current one, so what is the point in making so many small changes?
According to what Buterin said before, any change that is not for the survival of the network should not be done. However, he was not present and is not the sole voice in the ETH dev community, so obviously, some people disagree with him.
EIP 615 was one of the major discussion points. This EIP was created to improve the codebase of the Ethereum Virtual Machine (EVM), in which all smart contracts are used and deployed. The EVM is possibly one of the most important aspects of Ethereum, so many people want to upgrade it. Others do not see the upgrade as something that is quite so vital now.
The authors of the EIP 615 are Brooklyn Zelenka, Christina Reitwiessner and Pawel Bylic. They believe that the EVM should be cheaper and have a better performance, which is the whole reason for the upgrade.
However, another part of the community deems that the benefits will not be enough for a code that will be so hard to implement (because it has to be compatible with several other projects, etc).
The EIP 615 could need at least two hard forks and the positive effects would only be seen after the second one. Since Ethereum 2.0 is already being planned and it overhauls everything, a main point of argument starts: whether to make this effort or not.
Some voices in the community are very interested in the upgrade since they believe that they should not adjust their road map based on what Ethereum 2.0 is or may not be. Ethereum 1.x needs to be alive for the 2.0 to exist. Others, however, are concerned that this may waste time. This discussion will probably be very strong in 2019.