Disclaimer: I am not an expert on algorithms or mining software development. I am a hobbyist gpu miner with a small farm consisting of 18 gpus. I have been for several years now, so I do have experience in the crypto space in general.
Decentralization is an important part of any blockchain, especially with privacy coins. Since mining started, there has been a gradual increase in an unknown hashrate on the ironfish network. With an algorithm change likely to happen, I thought I would make a list of the best candidates and compare the positives and negatives of each.
The first obvious candidate would be Progpow. This algorithm is highly asic resistant, and would lead to a very decentralized chain. Progpow utilizes almost all parts of a consumer gpu, meaning ASICs would not be efficient to develop. Popular chains such as Ravencoin and Neoxa use a modified version of Progpow, meaning there is already lots of support in mining software. The main downside to Progpow is power draw. This algorithm is very power hungry and runs extremely hot. This could dissuade smaller miners with less infrastructure, leading to more centralization.
The second algorithm that I think makes sense is Autolykos2. Being a memory intensive algorithm gives it natural asic resistance, and current FPGA bitstreams are barely more efficient than gpus. This algorithm also runs fairly efficiently, with slightly less power draw then Ethash, and much cooler memory. There is support in almost all mining software for Autolykos as well. There are some concerns with using an algorithm that already has a massive hashrate, as farms could switch over easily, however there are plenty of gpu miners out there that would hop back on. Personally, I feel like this is a good choice. ASICs are a long way off, if they ever happen, and gpu miners would be able to match or beat out FPGAs.
Part of the changes would include a DAG lookup, adding a memory intensive twist on Blake3. This would discourage ASIC development.
There are probably more choices, but these are the ones I thought would fit the most with what Ironfish is trying to accomplish. Feel free to leave any comments with suggestion or criticism.
I think using a slightly tweaked version of Autolykos would be the best option period. Lolminer dev advised there was an oddity in the base Autolykos version that could have issues with some GPUs. I’d say use Autolykos as a base. So many GPU miners are still set up with with infrastructure that’d support ethash. So I’d say ideally you’d want an algo that drew similar or less power (which Autolykos does).
Since I was quoted, I will add some details about what I meant by this.
Generally the Autolykos V2 algorithm is no bad basis construction as it relies on memory and serves the original network well. There are some oddities in the construction though that I would not do in case of a algorithm fork of this.
The memory access width is only 128 bit / 32 byte. This is less then the cache line size of many modern GPUs (64 / 128 byte) and therefore many card can not achieve their peak bandwidth. This gives some imbalance to the GPU vendors and GPU generations as they have different properties regarding how well they can handle under-full cache line sizes.
There are 33 memory accesses per hash in Autolykos V2. First runs a blake2b run, then first access where the address of access requires 64 bit integer arithmetic, then an other blake2b run and then the final 32 accesses requiring 32 bit arithmetic for the address calculation - and then a blake2b again for the final hash computation. I personally would op to remove the middle block including the 64 bit calc for the access as it creates a strange algorithm design. Also having so many calls to blake2b are quite more compute heavy then needed to create a safe algorithm. One could save one of these and / or replace blake2b by blake3 - in order to also incorporate something from the original ironfish mining design
The modulus in the 32 bit operation is - due to a bit strange calculation on the size of the epochs dataset - sometimes odd and sometimes even. This allows to do some specific optimizations for some epochs that do not work for others. I would prefer having it unified e.g. by always picking the largest prime smaller then the target dataset size - then the optimization pathes are the same for every epoch.
So, thats so far what came to my mind as autolykos oddities that I would avoid if it were my design.
In the end the team needs to decide first if they want to change the algorithm at all, then what devices to target with it and well - we do the 3rd step here somehow by discussing what solutions could make sense
Edit: that said: do all this suggestions not rather belong into the consensus category?
