ambcrypto.com
Programmatic Proof-of-Work [ProgPow] has so far been one of the most talked about upgrades in the Ethereum community. The protocol that aims at making GPU mining more efficient against ASIC mining also raised questions pertaining to the governance of the ecosystem. This was one of the topics of discussions during the Eth1x/ Istanbul Planning, where Danno Ferrin, a blockchain developer, presented on ‘ProgPow: Flipping the Switch’.
Danno Ferrin spoke about the outcome of ProgPow implementation, assuming the transition happened after the audit was released and it gets scheduled for a Mainnet block. Ferrin stated that one of the results of the implementation would lead to a “dramatic” fall in Ethereum’s hash rate, adding that this would “not be the end of the world” as the work done would remain the same but it would be measured differently.
This was followed by the developer explaining the reason the hash rate would fall. He said,
“The biggest reason is that the work done in ProgPow is about twice ‘hard’ as Ethash and part of that comes from the amount of memory access that goes on […] since this is a memory-hard algorithm, that is the primary motivator for how long it takes to calculate the hash […]”
Ferrin stated that the second reason was the different ProgPow periods have a different hash rates. He stated that the program run to calculate the Proof-of-Work would change based on the block number particular block number, adding that every ten blocks the “different randomly generated program is generated” with some being quicker and others being slower.
[…] and probably the biggest reason is the ratio between Ethash hash rate and ProgPow hashrate on a given graphics card is not uniform, it changes based on the vendor, it changes based on the card type […] and those are the things the miners get all excited about, to increase their margin, to increase their profitability […]”
Ferrin explained that the drop in the hash rate would have an impact on the block time and the difficulty bomb. Further, the developer listed the ways this could be handled, first: not addressing the issue. The second was to apply a one-time difficulty adjustment and the third was to apply a pre-algorithm “difficulty multiplier”.