- Research has revealed a bug in the Ethereum ProgPow mining algorithm that makes it more vulnerable to ASIC equipment than the current Ethash algorithm.
- The flaw in the ProgPow algorithm is due to the 64-bit seed size that allows ASICs to mine without memory access.
The discovery of a bug in the Ethereum ProgPow mining algorithm is another point against replacing the current Ethash mining algorithm. The flaw was discovered by Ethereum community member Kik and was published as a problem in the ProgPow proposal on GitHub two days ago.
Since the proposal was drafted, the implementation of the Programmatic Proof of Work (ProgPow) mining algorithm has been controversial. The algorithm, which is intended as an update of the Ethereum algorithm, is intended to close the efficiency gap for GPU miners compared to ASIC miners and was designed by the IfDefElse development group and published under EIP 1057. A few days ago, the Ethereum Core developers decided in a meeting to approve it and implement it through a hard fork with a tentative date for July.
Vitalik Buterin criticized the approval and said that the way it was approved undermines users’ trust in the governance model. Kik’s finding could put the implementation of ProgPow back on hold. The researcher found a flaw in the ProgPow hashing function, the 64-bit seed which allows ASICs to mine without memory access.
Vulnerability of the Ethereum ProgPow mining algorithm to ASIC equipment
According to the Kik publication, ASICs have an even easier time with ProgPoW by exploiting the security of the 64-bit seed. ASICs are capable of forcing one of the three steps that the hashing function must perform to find a header and nuance in a given block.
Mining expert and developer for the ProgPow algorithm, Kristy Leigh Minehan confirmed Kik’s discovery. Although she explained that it has yet to be proven in practice. Minehan added that the vulnerability lies in the difference between the Ethash algorithm with a 256-bit seed and ProgPow which, as mentioned, uses a 64-bit seed and compensates for the rest of the bits “by other means”:
(Kik) found you can simply do the memory hard part once for a single seed, and then find your header + nonce through incrementing the extraNonce field (or extraData, this isn’t clear). That means 2^13 more calls to keccak, given the current D.
Minehan also said that some conditions must be met in order to apply the vulnerability. A miner or a group of miners, Minehan said, will have a difficult time meeting them. However, Minehan revealed that if they manage to violate ProgPow with this method, it becomes more profitable while increasing the difficulty of mining. The developer said Kik’s discovery validates the need for “multiple eyes” in the audit process of a new algorithm, Minehan said:
How do we fix it? Simple! Seed gets updated to uint128; the keccak calls consume the extra two words accordingly. Fill-mix will take the 128-bit seed argument, then we rearrange the order of the fnv calls to match + other consumers of the seed.
Although it seems that the solution is simple and the vulnerability technically difficult to apply, it is not clear whether the implementation of the ProgPow algorithm will continue. This will certainly be another point that ProgPow opponents will use to counter the change.