Ethereum is currently underway for its next upgrade, Istanbul, which is scheduled for the next coming months. The Testnet dates of the upgrade were recently announced by the developers, with the first Testnet scheduled for October 2nd on Ropsten and the last in December on Kovan. While Istanbul Gorli Testnet is set to occur on October 30 and Rinkeby for November.
Amid this, the community has been engulfed in the debate of whether to implement ProgPoW or not in the next hard fork, Berlin, which is scheduled for early 2020. The implementation of this protocol was one of the topics of discussions in the 71st Ethereum Core Devs meeting, with the team discussing the recent audit reports and the concerns surrounding ProgPoW.
ProgPoW aka Programmatic Proof-of-Work, a protocol proposed by IfDefElse, would be a GPU-extension of the current Ethash, the PoW algorithm of Ethereum. The protocol essentially aims to reduce the control of ASIC mining on the network by making graphic card mining more competitive.
This protocol was initially set to be implemented in the Istanbul hard fork but was pushed forth for the next one due to the delay in the audit. The software part of the audit was assigned to Least Authority, while the hardware part of the audit was assigned to Bob Roa, a semiconductor technologist. The final audit report for both software and hardware was released earlier this year.
One of the suggestions made in the software audit was “Scrutinize the custom Keccak Function”. This was brought up during the meeting by Danno Ferrin, Blockchain Protocol Engineer at Pegasys. Ferrin stated that he had raised concerns pertaining to this on a social media platform, which was addressed by IfDefElse on Gitter.
On this, he said,
“[…] it doesn’t really have any security impact. That satisfies my concern. That’s what I was thinking because it’s deep in the weeds thing. It’s not going to be subjected to an extension attack when you’re immediately going after another round with all the details on it […]”
This was soon followed by Trent Van Epps, Developer Advocate at Whiteblock, asking whether the developers were considering on integrating the protocols in the clients but not activating it until ASICs posed a threat, considering this suggestion was made some community members.
On one hand, Hudson Jameson stated that it was “too early for the alternatives”. On the other, Martin Holst Swende explained why keeping it in the back pocket was a bad idea. He stated that if the network becomes dominated by ASICs in the future and “something bad happens,” then the switch to ProgPoW wouldn’t be possible in merely an hour or a day, adding that it would at least take two weeks for the entire process to roll out.
Swende also stated that once the decision to active ProgPoW was made, then the existing minders could “do whatever they want” as their investment would go in vain either way. He continued to say,
[…] while that happens during the week the actual value of Ether is going to plummet during those attacks and then we will eventually, if we ever manage to actually do the switch to ProgPow, we might discover that there is no mining farm that is able and ready to pick up and switch over to actually mine Ether on full scale […]
Succeding this, Trent spoke about another concern surrounding ProgPoW, the likeliness of causing a chain split. As an argument to this, Ferrin stated that during the miner vote for ProgPoW, there was not a single miner that voted against its implementation. He also pointed out that, in reality, there was a user rebellion in favor of ProgPoW earlier this year. He said,
“If there was a single miner that took the time for a negative vote then I would put more weight to that argument, to be honest.”
Bob Summerwill, Executive Director of Ethereum Classic Cooperative, also weighed in on the concern, stating,
“I think the controversy is not on the mining side but on the user side. I think if there was a chain split, it would be an ETC style one. A user rebellion and then mining building up support that’s how I think that would play out.