Progress for ASIC resistant RandomX, to possibly be implemented by Monero.
https://ostif.org/four-audits-of-randomx-for-monero-and-arweave-have-been-completed-results/
Asic resistant, yet server farm friendly. What’s the bet Monero’s hashrate ends up more centralized than ever.
Monero PoW team asked me to do an audit, but I declined. Note that almost all the audit feedback is from security firms looking for buffer overflows and dumb shit like that, as if someone will try to hack the miner itself. Not much audit brainpower was devoted to the main point of the PoW, ASIC resistance, but I’ll repeat this part which I agree with:
ASIC/FPGA Resistance 1 – DISPUTED – Low Reliance on Branch Prediction Unit
The branch prediction unit of a CPU is a complex and large component that takes up a lot of physical space on a CPU. RandomX does not rely on branch prediction logic, so an ASIC could greatly simplify a potential ASIC by simplifying the branch prediction unit. After talking with the RandomX team, this is disputed because any logic that can be predicted by a branch predictor can be implemented in an ASIC, possibly more efficiently.
That is an unsolvable catch-22. If RandomX encourages branch prediction, ASIC’s will be better at it than CPU’s. If RandomX doesn’t encourage branch prediction, a large part of CPU’s goes unused and wasted.
IMHO it is extremely difficult for RandomX to succeed in being ASIC resistant. I do expect to see ASIC’s sometime after launch, and if that happens, we could see Monero give up and finally be ASIC friendly with Keccak. RandomX is a very lengthy spec and complicated to implement, so it might take some time to see ASIC’s, although ASIC designers could have started a while ago…
3 Likes
It seems that a RandomX ASIC can take many shortcuts that a real CPU cannot. The branch predictor will be much simplified and optimized for the distribution of values encountered in random programs. For instance, testing a register which holds a somewhat random value against zero can just assume the test will fail all the time.
Notethat it’s ok for the ASIC to produce faulty results as long as the probability of doing so is small enough. The performance and efficiency benefits will outweigh the occasionally faulty executions. This option is of particular benefit to integer and floating point arithmetic. A normal ALU needs to handle a carry all the way to the most significant 63rd bit when adding. An ASIC will just judge any carry beyond bit 16 or 24 to be too unlikely and not bother implementing further carries.
The option to avoid dealing with any unlikely cases will benefit many aspects of a CPU implementation. I find it hard to believe that the efficiency advantage of an ASIC will be limited to a factor of 2.