I do appreciate the validity and originality of the observation that even if some SHA-256 engine makes some errors because the adders it uses are not quite always yielding the correct result, it might still be usable for Proof-of-Work applications such as bitcoin mining, if the error rate remains low enough; and that this conceivably could be beneficial, by allowing to cram more SHA-256 engines for the same silicon area or cost, and/or run the thing faster, and/or make it draw less power.
However, when I compare a solution using approximate adders to a comparable one not using these, based on the article's own numbers, I'm far from matching the draft article's abstract:
Our results show that approximation has the potential to increase mining
profits by $30\%$.
By the numbers in table 2, the delay⋅area product of the SHA-256 implementation using the KSA16 adder is only $1-82744/90769\approx8.8\%$ below that of the next best solution with an adder making no error, KSA32. When we compare against that baseline, which is the Right Thing to do, no usable solution proposed gains more from a delay⋅area standpoint (KSA8 is acknowledged to almost never gives a correct SHA-256 result).
Update: Also, when we take into account the fact that the whole circuit using KSA16 draws more power to run at higher speed than its counterpart using KSA32 (as acknowledged in table 2), its operational benefits taking into account power cost must be somewhat lower than estimated on the sole basis of delay⋅area.
And then, this potential saving has the drawback that some of the hashes are wrong, thus (in most PoW context including bitcoin), anything involving these is worthless.
It is said (above equation 4) [obvious correction mine]
The sensitivity derives from three CPA modulo 32-bit additions each iteration, so there will be $64\cdot3=192$ additions in a single round of SHA-256".
An apparent problem is that there are more than $192$ additions of two 32-bit operands in a single SHA-256. Looking at the "Algorithm 2" pseudocode, I count $48\cdot3$ at line 7; $64\cdot4$ at line 10; $64$ at line 11; $64$ at line 13; $64$ at line 15; $8$ at lines 17 to 20; for a total of $600$ additions of two 32-bit operands per SHA-256.
Performing all the 32-bit additions in SHA-256 by adder KSA16 (the only one giving savings per the above analysis) with stated error rate of $4.6\times10^{-5}$ (taken from table 1) thus makes $1-(1-4.6\times10^{-5})^{600}\approx2.7\%$ of the SHA-256 computations invalid; thus in a bitcoin context $5.4\%$ of the findings valueless. Thus the overall potential benefit would be down from about $8.8\%$ to about $6.1\%$ for SHA-256, or $3.4\%$ for bitcoin mining.
Update: on second thought, the authors are right counting towards the error rate only 3 adders out of 10 of those involved in the round loop, if they optimize only these few adders in the timing-critical path, which would make a lot of sense. This change of a limited portion of the adders will reap low size benefit, but still allow faster speed for the whole circuit. That qualitatively matches the numbers for delay and area in Tables 1 and 2, where we see that most of the benefit of using KSA16 compared to KSA32 is that it allows a faster clock cycle (at the expense of power drawn).
My conclusion is that the article investigates various designs of adders for ASICs performing SHA-256 in PoW systems like bitcoin; rightly observes that it is possible to significantly improve an existing design, by virtue of speeding it up in its timing-critical path, through replacement of some of its basic Ripple Carry Adders with more appropriate ones (larger but faster) still giving exact results; reports some marginal extra improvement (mostly due to further speedup) with another implementation using approximate adders; but do not give any strong argument beyond this anecdotal evidence towards the claim that approximate adders can give sizable overall benefit in hash-based PoW systems.
