It remains to be seen how much of an advantage asics would have
When the attack has a fab, the advantage is measured in cm^2/hps and process nodes. This is the only hash attack I worry about. Against commodity hardware, process nodes give the advantage to the good guys, maybe, but cm^2/hps is going overwhelmingly to the bad guys.
For a first order estimate, take the surface area of a haswell compared to the portion dedicated to the aes-ni block. That is a freaking huge advantage.
No -
Take the surface area dedicated to L3, because that's what limits the amount of cryptonight you can do concurrently.
... and that's not a freaking huge advantage, because the chips are already ~50% cache.
An ASIC could make slightly better use of the L3 -- by interspacing the AES units and the cache more optimally, it could slightly reduce read latency. Perhaps a 30% reduction. By specializing the reads instead of going through a more general memory controller, it could get another some %. By optimizing the AES computation at the expense of space, a little more.
But even if you take the compute time to zero, the ASIC will be limited by the time needed to do 1 million fetches from a 2MB scratchpad. Store that in SRAM, and you're area-limited at perhaps 3ns per retrieval. Storing it in DRAM, you can fill your chip with AES units, but you're 128-bit random-read limited to the DRAM.
That's about 330 hashes/second/2MB of SRAM, so perhaps 1500 hashes/sec on a chip the size of a modern i7.
Of course, this is a very back of the envelope calculation, but the sky will not completely fall. The advantage, of course, will be power - you'll be able to pack those densely - but it won't be the 2-3 order of magnitude gap you see with sha256.
(You can do an analogous computation for a DRAM-based solution. The advantage is probably comparable, but I'll leave that as an exercise for the reader.)
