6 min read
The date is set. On 27 February 2019, Ethereum’s postponed upgrade, still called Constantinople, will finally—fingers crossed—occur. But part of that upgrade will then immediately be undone by a second Constantinople.
Confused? Yeah, thought so. Read on.
Ethereum’s core developers, who help maintain and ever improve the network, met online this afternoon and decided to have two Constantinople’s. That decision came in the wake of a possible security vulnerability that was discovered earlier this week, and which delayed the scheduled Constantinople upgrade. The problem was that the bug was discovered after around half of the node operators on the network (according to estimates) had upgraded to the vulnerable client. If the fork occurred as planned, that would create all sorts of problems.
So how to solve it? The developers agreed that if a new upgrade was adopted, without the buggy clients being fixed, security vulnerabilities would persist in the network. The affected code would have to be removed from every testnet and every private net that had upgraded already to Constantinople—a substantial undertaking.
Ethereum developer Péter Szilágyi was the first to suggest a fork/refork solution.“We define two hard forks—one is Constantinople as it is currently, and the second is a Constantinople fix up” Szilágyi said. “On mainnet, these two forks would trigger on the same block.” This would mean fewer potential problems and lower costs. Developers say that would reduce the cost of alerting the community to an impending hard fork, which is the main expense in achieving a hard fork.
Testnets, meanwhile, would use a different block number, as a means to transition onto the mainet.
While some devs were keen to take their time in rolling out Constantinople redux, Vitalik Buterin, the platform’s inspirational co-founder, promoted more "aggressive" action, suggesting that the new fork should happen asap, in as little as two weeks. But the community ultimately decided to err on the side of caution, as time is needed to alert those affected.
Earlier, in an interview, the Ethereum Foundation’s Hudson Jameson urged patience in general. He explained that Ethereum, unlike Bitcoin, is able to execute smart contracts and thus has many more use cases, creating more complexity on the blockchain. “It’s challenging to create a mostly Turing-complete, programmable blockchain, and there’s going to be a lot of things that—even with 100,000 eyes on them—will be overlooked,” he said. “So it’s less about us focusing on one certain thing, and more about us just putting general best practices in place for people around the ecosystem, and spreading knowledge and education about the things to look out for.”
Developers, meanwhile, with the help of so-called cat herders, are starting to tire from rounding up stray nodes, miners and others, and alerting them to the delay. They were further stressed by Ethereum’s so-called “Difficulty Bomb,” which has already kicked in, and was intended to make upgrading the blockchain a priority. The devs are acutely aware of the problems miners face; without a viable update, some say, the network would be unusable within a matter of months. .
Also discussed at today’s meeting was the future of ProgPOW. Two weeks ago, developers had tentatively agreed to implement the controversial ASIC-blocking code in a future hard fork. But community sentiment appeared to have changed, developers said. They also cautioned that the decision had been rushed, and there were bugs in the code. The future of ProgPOW is thus uncertain.
ChainSecurity, which audits smart contract security and which had initially identified the Constantinople bug, addressed the core developers and briefly outlined some possible ways to avert the 11th hour discovery of a security bug, should it happen again. One interesting idea floated was creating a kind of centralized kill switch. Needless to say, a centralized anything will create plenty of debate in the community, but during the meeting, the idea was merely a suggestion.
Despite the ingenious plans to rescue Constantinople, concerns remain about future upgrades, which are linked to the to-be-removed part of the code relating to the introduction of cheaper gas costs (the way the network charges for transactions). Its long-term fate is still to be decided. Developers on Gitter and the Ethereum Magicians Forum said that some of the proposals for the upcoming Ethereum 1x, will be affected, in particular a plan to introduce storage rent, known as “State Rent.” The measure aims to reduce the pressure on the blockchain by requiring every account to pay for storage.
There are also wider philosophical questions raised about the meaning of “immutability” and Ethereum core developers’ responsibility to those who develop smart contracts.
“Some smart contract developers may have been operating under the assumption that something (namely, the gas cost of particular operations) is “invariant” when I don’t think we ever intended that to be the case,” said the Ethereum Foundation Lane Rettig, in response to Decrypt's request for clarification.
The problem, he said, wasn't so much any fault with Ethereum but the way some smart contracts had been programmed. Nevertheless, it impacts on further rollouts, such as state rent.
Smart contract developers are likely to be concerned that their code will no longer be immutable, as was originally promised at Ethereum’s inception. And this is at odds with the freedom needed by core developers to continue to improve the protocol, reduce complexity and enable the platform to scale.
But with the discovery of the “potential vulnerability,” what is underlined is the extreme difficulty of introducing changes, which could have second-order effects.
“It raises some very interesting, very difficult, very deep philosophical questions about Ethereum,” said Rettig. “About the social contract between Ethereum and its developers/users—what exactly is immutable/inviolable/invariant, what is intended to be, what is not.”
Rettig is part of the team responsible for introducing ewasm, which is intended (at some point) to replace Ethereum's current operating system, the EVM. There are indications that fast-tracking this could provide solutions to the current dilemma, although this is something that is yet to be debated, he stressed.
So while the waiting is over and a course of action has been set, the wider implications that led to Constantinople’s delay are only just emerging. Discussions on this topic are likely to dominate the coming months and even years, developers say. Lucky them.
Decrypt-a-cookie
This website or its third-party tools use cookies. Cookie policy By clicking the accept button, you agree to the use of cookies.