Reenabling ASIC resistance and the decentralized consensus.

Posted on 2019-04-12 by opauaiyvjp
Status: Disabled

This proposal was trashed.


Stoffu recently proposed running AEON on SHA3/Keccak/K12, which apparently did not achieve community consensus. Since the AEON community seemed to be looking for a new hash algorithm for a while now, this appears to be a decent time to propose a fast and assymetric algorithm.

How much?

To implement a fork to a new assymetric hash algorithm, the core hashing structure has to be changed. This of course is a lot of development work, which additionally has the be tested and made available for the public in a testnet, resulting in a few days, maybe a week, of work.


While stoffu proposed the usage of K12, AEON appeared to be searching for an algorithm providing resistance against ASICs and the centralisation that comes with them. Therefore an algorithm similar to rainforest or ethash would be ideal for the AEON cryptocurrency. Problem with those is that rainforest is slow and repeats the same process plenty of times, while being computationally difficult and ethash being IO-Bound and assymetric but relying on slow and ASIC-favoring algorithms. Those two algorithms have been merged and optimized in here, to allow a low maximum gain for a potential ASIC implementations aswell as fulfilling a few other design requirements listed in here. While this would assymetry substantially increase the impact of the average miner and lowering the investment needed to participate, it would drastically increase the accessibility of AEON for potential miners. The reduced requirements for a light evaluation make it possible to synchronize even faster and more efficient with the network.


The milestones can be split into two major parts, as seen below.

Light Evaluation: Enable light evaluation globally, forcing miners to run it aswell. (~1 Day)

Full Evaluation: Enable full evaluation allowing miners and verifiers to run differently optimized code. (~1 Day)

Enable fork: This step is necessary to ensure that the previous AEON blockchain works with the future one, instead of discarding it. (~0.5 Days)

Testnet: Publish a testnet, allowing miners submit their hashrate and experiences. (~1.5 Days)

Tweak settings: (Optional) If the algorithm is too slow or does not provide enough resistance against certain attacks, the parameters can be tweaked. (~3 Days)

Repeat: Repeat the 4/5 block until consensus is reached.

Totalling in four days of work @ 10 hours per day. With an average of 75 AEON per hour this results in 3000 AEON funding needed, assuming that the tweaking and testing after everything is in the testnet is done by the community.


Outcomes and milestones can be seen above.

Why you?

I have studied this code for two weeks now and am very confident in understanding most parts about it.

You need to be logged in to comment.

BigSlim 2019-04-12 01:09
Merging EThash is probably one of the heaviest things you can do for Aeon in regards to speed, sync time, and lightweightness of the blockchain. That would be a step backwards along with allowing hundreds of Mh from gpu farms to overrun a small cap coin. Please explain how moving forward with K12 did not achieve community consensus? There were 2 weeks of solid discussion between all avenues of the community and even Smooth himself agreed that there was an overwhelming support for the change going forward. " in general we want to stabilize this portion of the protocol so there is not a need for mining-economics-driven forks" Yes, every project wants people to support it via mining, and with k12 you still will be able to even with CPU power. There are no known asics for k12 *right now* but there will be fpga bitstreams available and entry-level fpga miners will be around $200 usd and more advanced fpga are available for $3200-4500. All things aside mining wise, giving a week to fork a coin would be a disaster, especially if there is a minimal community effort to help move that process along.
opauaiyvjp [op] 2019-04-12 11:31
I already explained above why even having an investment needed of 4000USD still is an investment, a barrier reducing availability. Without everyone being able to mine with atleast somewhat decent returns, you will never achieve a decentralized consensus. Think about it. Who will be able to mine AEON? Will it be the average joe who likes the idea of self-governance and independence from banks and big cooperations - or will it be the few rich guys next door to him? Nobody has 4000USD just to throw them out of the window. But everyone has a few watts to spare while idling. I put in the amount of time I expect I would need, I would have no issues with shifting it or stretching it. It simply is a good idea to move those forks to as early as possible (if they're safe), to allow change to happen. Something I didnt see in aeon for a while now. About your comments on Ethash. No. Exactly the opposite. With cryptonight, commodity hardware achieves about 100H/s to 200H/s, with the aeon variant twice that. With ethash, you have asymetry, as mentioned above, which forces a miner to run a 4 gigabyte scratchpad, while allowing a validator to run a 64 megabyte scratchpad. While a miner achieves a few megahash per second using their CPU, and functions that are explicitly designed for CPUs, so no GPU farms, a validator will achieve the same speeds, maybe higher speeds, than aeon currently does. A set of parameters resulting in 11MH/s for miners and 1.2kH/s was found. Lastly, yes, I agree that it looks like you achieved consensus. You five people. But there are more people in the community and you can expect that 90% of the people who disagree with something, will not open their mouth and just silently walk away. Additionally, most of whats written in stoffus post is not reasonable. "a semi-standardized design endorsed by the same team who designed SHA-3. It feels safer than tweaking the Keccak parameters by ourselves." thats true. The github package containing the source of keccak variations contains K12, a keccak variation. The official website of the team behind keccak also lists the variations. Is it publicly endorsed? I doubt it. Especially considering that the number of rounds has been bumped up from 18 to 24 in the SHA-3 competition, reducing the rounds later on to something even lower to the initial values does not seem idea. In some early proposals for a stream cypher, the authors reduced it to a total of 12 rounds. (In other words, the authors already thought about it and considered it insecure) - "a bit faster than SHA-3 with the round number reduced to 12 which is still believed to be secure enough" already covered above. - "potentially useful for hashing all other things in the protocol, especially transactions which are often large, because K12's main strength is its ability to quickly process large chunks of data in parallel" you could use anything to achieve that. Even a CRC256 would be enough. And that thing has 10 bytes per CPU cycle (keccak uses 20 cycles per byte). But yes, it can be used to process transactions faster, but only because keccak is not ideal. Blake2s would do much better and be less controversial about its security. - "If we implement this in the future, we get another benefit that the PoW hash and the block hash become identical (as in Bitcoin), thus saving the current doubled computation of hashes for each block (one for the block ID and the other for PoW)." There is good reason there are two hashes. Entropy. If your difficulty is as high as it is with bitcoin, or even higher if you take K12, and implement those changes, you will quickly see that the leading 24 bytes are all zero, while the last 8 bytes change. 8 bytes, that is 64 bit, or 18 quintillion. 18 quintillion as the total number of possible block IDs, even lower if the network grows, is far from a good choice. Assuming that we have a total number of 1 billion blocks, there is a chance of 1% that we have a hash collision. Thats unacceptable.
comment is locked for editing/deleting
shigutso 2019-04-12 01:41
community consensus = smooth and stoffu agreed with each other that ASIC resistance is not worth it and other people followed the idea. They didn't agree with the community, they agreed with themselves, and they have the final word because one makes the PR and the other approves it. Nothing wrong with that, that's how some stuff works, but community consensus... I would say the community got almost equally split. Other people against the idea already jumped ship, but some (like me) that don't agree are still around to see how it goes.
comment is locked for editing/deleting
shigutso 2019-04-12 00:47
Interesting. I'm in favor of ASIC resistance, but I think this needs better explanation. Why this and not RandomX? Will you be able to maintain AEON's core code (i.e. merging Monero's updates), as stoffu will abandon ship if SHA-3 is not accepted by the community?
opauaiyvjp [op] 2019-04-12 10:33
RandomX is built around GPUs and ASICs by using the natural resistance argon2 and AES provide. Additionally RandomX uses the same IO-Boundness as ethash, but ethash uses faster functions to have it stronger bound to the IO, which drastically increased its resistance against potential ASICs. (This section can be skipped) This is because we assume that a GPU/CPU provider (depending on when GPUs finally die) will always try shipping you the best possible hardware, which implies that the ASIC manufacturer has the same memory to work with, but can design different chips. Therefore by having an algorithm be strongly bound to memory read operations, which is a strong contrast to cryptonight, you have a strong resistance against potential ASICs. This is exploited in SquashPoW by first writing a completely new hash algorithm (Squash-Hash, as fast as Blake2, ~10x faster than SHA-3) to replace SHA-3 with, and afterwords having more minor changes such as picking CRC32 in favor of FNV, to build it so that an ARM CPU is an ASIC for this algorithm. By then changing the memory read operations from something outside of the hash function to some operation inside the hash function, additional speed gains can be achieved, which can then be traded in for more being more bound to the IO (which further increases the ASIC resistance). Which is why I mentioned that tweaking might take a while. You have to carefully set a point where your desired resistance against a potential ASIC and the speeds you require both meet. A possible solution proposed on their github was 100kH/s on a low-end CPU (mining) and 20H/s when validating (both single-threaded) with a potential gain of x1.01 for an ASIC. But only if the entire calculation of the algorithm could be reduced to literally nothing, which is not the case, the calculation is very expensive for an ASIC. This implies that special implementations would not just be unlikely, but also unfeasible, allowing you to mine with your commodity hardware, at home. SECTION 2 >Will you be able to maintain AEON's core code (i.e. merging Monero's updates), as stoffu will abandon ship if SHA-3 is not accepted by the community? I guess so, while it would technically be more easy to just merge the commits done for aeon back on top of monero, instead of doing it the other way around.
comment is locked for editing/deleting