To be or not to be: that is the question
Every once in a while, the crypto community stumbles on this question – What is my reason for existence?
Ethereum had to contend with this question in its hay days in light of the DAO hack. This cleaved a mark in the “code is law” rule; it also set a precedent in the traditions of “hard forking”.
When a community diverges on core topics, they have a choice… every community member was heard… the choice was then clear. A divorce from the “parent” blockchain was imminent. What we learned from this hardfork was that there’s always a choice. Now ProgPow rekindled the cycle, and the community is left wondering if history will repeat itself.
ProgPoW is a variant of Proof-of-Work algorithm, an algorithm that is much desired by GPU miners as it promises to give them an advantage over ASIC miners. Why now? Why even bother with ProgPoW? The dual dilemma is causing the next great divide in the Ethereum community.
It takes a village to raise a child
Who makes up this community? Is it the miners, or developers, or stakeholders? When ProgPoW was introduced, the miners who were overtly for it. The reason being ProgPoW’s immediate advantage in providing an upper hand to GPU miners against ASIC miners. Even though ProgPoW doesn’t guarantee ASIC resistance, it does put them a few steps ahead of them. In the mining world, ASIC has always posed an elitist edge over small scale miners. The bigger picture here was not the participation of GPU miners but decentralization. However, this has also been a factor that has been debated on in the cryptocurrency community as whole – can decentralization truly be achieved?
Initially, ProgPoW was supposed to go live this year, along with the Istanbul hard fork. However, this was pushed to the beginning of next year as its audit was yet to be completed. The catch here was that Etheruem 2.0 will also be rolling out in early 2020, resulting in some people questioning its implementation as ETH 2.0 would be seeing the shift from Proof-of-Work to Proof-of-Stake, which in itself would solve mining centralization.
Clash of clans:
ProgPoW reactions were far and wide. At first, some people opposed it by labeling it as a bailout for GPU miners and strongly expressed that this should not be allowed. This resulted in the Ethereum Cat Herders stepping in and taking appropriate measures required to gauge community sentiment.
Earlier this year, Hudson Jameson, communications relation manager at EF posted on Reddit,
“I consider myself a liaison to the Ethereum Core Developers and facilitate the Ethereum Core Dev meetings that happen every other Tuesday. Some considered this [ProgPoW] as a bargaining chip for miners to accept the issuance reduction. To be clear, there were some core devs who were in favor of ProgPoW and had been for a long time.”
Ethereum Cat Herders conducted a miner vote and carbon vote. Miner vote showed a turnout of over 77.2 percent, with all the vote cast in favor of ProgPoW and none against. While carbon vote showed that over 93 percent of people for it and around 6.2 percent were against it.
Having gauged sentiment, Cat herders are now plagued by other ProgPoW concerns:
- Validation of the soundness of protocol:
Considering that not many people in the community have expertise on the modification introduced to Keecak hash function in ProgPoW, perturbed on relying on a small group of people has been brought up.
- IfDefElse:
Another issue that surfaced post the audit release was around the team that’s behind ProgPoW, IfDefElse. Some people, including Bob Summerwill, raised questions about the people in charge and OhGodAGirl [Kristy-Leigh Minehan], particularly her connection with Craig Wright and Bitcoin SV community.
ASIC miners – Boon or bane?
Proof-of-Work algorithm would act as an extension to Ethash, Ethereum’s current PoW algorithm. The need for ProgPoW was brought up in light of ASIC miners taking control over the network, a factor the majority of the PoW blockchains fear. This, however, is a foreign concept for the Bitcoin community, considering that the majority of the network is controlled by ASIC mining.
One of the notable cryptocurrencies that have been on the front lines when it comes to battling ASIC mining is Monero. The fungible coin has always taken precautions in order to not let the network be centralized because of few entities trying that have a majority of the hash rate by making alterations to the algorithm every six months. And one of the major steps taken in this line is the implementation of RandomX, which is set to go live in the coming month.
Ethereum shares the same philosophy as that of Monero. The overview of ProgPoW on GitHub stated,
“The design goal of ProgPoW is to have the algorithm’s requirements match what is available on commodity GPUs. If the algorithm were to be implemented on custom ASIC there should be little efficiency gains compared to a commodity GPU.”
The post went on to list five key elements of the new algorithm. A change to Keccak, the hash function used in Ethash, from Keccak_f1600 [64-bit words] to Keccak_f800 [32-bit words]. The algorithm also proposes to increase the mix state.
A blog post by IfDefElse reads,
“The compute core of GPU has a large number of registers that feed high throughput programmable math units. The inner loops of Ethash has just DAG load and then an FNV to merge the data into a small mix state. ProgPoW adds sequence of random math instructions and random cache reads that are merged into a much larger mix state.”
The other major elements are: adding reads from a small, low-latency cache that supports random addresses, and increase the DRAM read from 128 bytes to 256 bytes.
If ProgPoW is implemented then the random sequence would change every 50 blocks, which would equate to around 12.5 minutes. The GitHub post stated,
“When mining source code is generated for the random sequence and compiled on the host CPU. The GPU will execute the compiled code where what math to perform and what mix state to use are already resolved. While a custom ASIC to implement this algorithm is still possible, the efficiency gains available are minimal.”
Verify, before it’s shared
The audit of ProgPoW contributed to the delay of its implementation, with raising funds on time being another hiccup. To get the required funds, Ethereum Cat Herders had created a donation page on Gitcoin, later asking the community to contribute.
Once the fundraising round was completed, Cat Herders assigned the auditing task to Least Authority and Bob Roa, with the former tasked to conduct a software audit and the latter a hardware audit. The final deadline for both audits was marked for September.
The main goals of the audit included measuring:
- Effects ProgPoW would have on the security of Ethereum: the cost of a 51 percent attack and the attack surface
- Potential advantages and disadvantages that ProgPoW would have when compared to Ethash
- Other potential effects that would impact the ecosystem.
Curtain Call:
The final report of both the software and the hardware audit showed that ProgPoW code was accurate and that it met its design goals. However, audits, both software, and hardware raised some doubts and even made some suggestions.
Source: Bob Rao hardware audit
The software audit conducted by Least Authority stated,
“ProgPoW algorithm provides better overall features of a GPU and a custom security against recentralization which is largely based on more optimal utilization of the overall features of a GPU. By preventing ASICs from out-performing GPUs, this encourages distribution of advantages in hardware development and therefore is a likely better defense against a 51% attack.”
Along with this, the software audit had five suggestions for ProgPoW:
- Scrutinize the custom Keccak Function;
- Address the Light-evaluation method mining attack;
- Create additional documentation;
- Explore a formal model of ASIC resistance,
- Monitor hardware advances.
Out of these, two gained prominence in the community: Keccak Hash Function and Light-evaluation method. The report suggested that a “deeper look at the custom Keecak function could elicit previously unidentified security risks,” considering that the hash function used by ProgPoW did not use padding. Whereas on the Light-evaluation method mining attack, the team stated that even though it did not pose an immediate threat, it was something that could be possible few years down the line.
Regarding the first concern, the IfDefElse team had stated,
“We do not add any padding, but that in now way has any effect on the cryptographic properties of Keccak. Padding exists to make sure different variants don’t produce same results, but we do not even actually care about the result.”
On the response of Keccak hash without padding, Liz Steininger, CEO of Least Authority, told AMBCrypto that the team “agrees with their statement.” She added, “We don’t think there is anything wrong or to be concerned with but it couldn’t hurt to have another specialist look into it further.”
Liz also commented on the possibility of a Light-Evaluation method mining attack, stating,
“This applies to Ethash, too. This is a non-issue now. Bob [Rao] said he thinks that specific hardware advancement that could facilitate this attack is about is about is about 4-5 years away. Even so, our suggestion mitigation would prevent the issue.”
The hardware audit also went along the same lines as that of the software audit; however, it pointed out one critical issue. The hardware report read,
“The ProgPoW algorithm works well to mitigate conventional ASIC strategies […] However, there is a looming threat to memory hard algorithms in general as massive amounts of memory can be brought very close to compute logic due to advancements in Moore’s law and 3D/ 2.5D packaging.”
Source: AMBCrypto
“A person is a person, no matter how small”
Cutting through the noise of ProgPoW, be it Keccak hash or Eth 2.0, during the final curtain call, more than whether ProgPoW is implemented or not… more than if it’s needed or not, it is the process of giving space to hear out every voice. Miners, Developers, stakeholders – their right to be heard was upheld in the Ethereum community.
