Beyond Consensus — Part 3
In part two we posed the question of whether ASIC resistance is a myth. The answer is simple: no. It’s easy to fall into the trap of thinking about ASIC resistance as a boolean property: either you have it or you don’t. However this is a false dichotomy. We should be very conscious of the specific term ASIC resistant. We’re not saying ASIC proof. There is a spectrum of ASIC resistance. So the right question to ask ourselves is not “are we ASIC resistant?” but rather “how ASIC resistant do we want to be?” It’s possible to be somewhat resistant, extremely resistant, or not at all resistant, and every shade in between. And as always there are tradeoffs. For example if you’re willing to take the hit of hard forking every several months, then it’s pretty easy to be extremely ASIC resistant, by constantly changing the hashing algorithm. Indeed this leverages the most fundamental difference between general purpose processing units and ASICs, that they run software which can be easily changed. By designing hardware for a very specific task, ASIC manufacturers gain performance but lose flexibility.
Of course there are less extreme ways to be ASIC resistant. A common approach is to use a memory-hard hash function. The idea is that the bottleneck should be memory performance rather than compute performance, since it’s easy to speed up compute tasks by encoding them in ASICs, but hard to speed up memory intensive tasks. It can still be done, but it’s costlier and the delta in performance is smaller. If ASIC manufacturers could build significantly faster memory at reasonable costs relative to what’s already on the market, then they wouldn’t waste their time with cryptocurrencies. There are still some tricks they can play, for example stripping away unnecessary logic blocks such as floating point units to save power draw, or using smaller but more numerous RAM chips and wider buses for increased bandwidth.
Speaking of bandwidth, it’s important to understand that memory hardness isn’t one-size-fits-all. There are different flavors. Take ethash for example. It was designed to be bottlenecked by memory bandwidth due to performing bunches of random reads, therefore GPUs typically perform better than CPUs since they’re designed to churn through vast amounts of data in streaming fashion. Whereas CryptoNight on the other hand is bottlenecked by memory latency due to performing successive dependent reads and writes in a small scratch pad. Hence it performs very well on CPUs since they have larger and faster caches by design. CryptoNight also has a neat choice of logic as part of its inner loop: an AES round of encryption. This operation is built into the instruction set of many CPUs, whereas GPUs must use a pure software implementation that piles on many more clock cycles to achieve the same result. Some will argue that favoring CPU miners yields more participation and decentralization, while others say it’s an invitation for botnet mining and botnet attacks.
Where does all of this leave us in terms of the plan for Marconi? Long story short, our goals are extensive decentralization and strong ASIC resistance. We’re still testing and evaluating different options, but one thing is already clear. We’re going to be very transparent with and supportive of the mining community. We have a soft spot for miners because many of us were once miners ourselves. So stay tuned.
