Peach agorithm

A new mining algorithm from the creators of Mochimo meant to level the playing field among miners and prevent FPGA dominance.

Reason for change

The effect of the FPGA pool resonated throughout the network. GPU's became unprofitable and while some miners dropped off the network waiting for development, a lot of others simply left the community. The Peach algorithm is another step towards discouraging the use of non-GPU hardware, thereby keeping Mochimo a currency that can be mined effectively as long as you have a couple of graphics cards and some spare time.

Story

To combat FPGAs, Mochimo developers had to come up with a new algorithm. After months, they presented Stax-1. A beautiful memory intensive algorithm that could easily scale the memory capacity requirement to eradicate emerging FPGAs from the network as they appear. Though, it came with one caveat: Once implemented, this algorithm would permanently impose large memory requirements on any machine that intended to validate the Mochimo blockchain. But we finally had a solution to the FPGA crisis, which at this point was at an arguably critical level, and we were running out of time to keep the Mochimo network healthy. The Stax-1 algorithm was ready for prime time. However, the caveat was too much for our Programming Wizard, Ortis. So much so that he took the core of the Stax-1 algorithm and with it built the framework for a new algorithm that would remove the permanent memory requirement (or prerequisite) to validate, while making it necessary for miners to maintain that requirement to gain a mining advantage. This is the moment The Peach Algorithm was born...

In the original Super Mario Brother’s game, players were tasked with rescuing Princess Peach from the evil Bowser. To do so, they’d often find themselves jumping from tile-to-tile trying to reach the castle, only to be told “Our princess is in another castle”. The Peach algorithm was named after this process, as one of the core mechanics of the algorithm is the inclusion of an enormous sparse matrix, where the algorithm jumps from tile to tile, attempting to solve the block (and usually getting to the end of the process without finding a solve).

How it works

Shorter explanation:

The Peach algorithm is a proof-of-work mining algorithm for the Mochimo network that is designed to be GPU optimized. The Peach algorithm uses various FPGA-deterrent features such as pseudorandom deterministic floating-point operations, pseudorandom byte transformations, a 1 gibibyte sparse matrix, and the “Nighthash” function, which applies one of 8 dynamically chosen hashing algorithms to each tile. The Peach algorithm begins its function by hashing the starting tile using the contents of the block trailer. The resulting hash points the algorithm to the first tile in the matrix, where some work will be performed. Once the starting tile is known, the tile data (as well as the nonce and index data from the block trailer) is passed through the “Nighthash” function. It performs the “work” in our proof of work system and also points the system to the next tile. This sequence occurs several times. The hash of the final tile represents a potential block solve. If the final hash is equal to (or better than) the block difficulty, then you have solved the block (and, of course, saved the princess)! If however, you have not, then the cycle will continue until you or a peer have solved the block. The Peach algorithm rewards computers with high memory because they can store previous tiles in a cache, reducing the work of any cached tile. This becomes increasingly important as difficulty increases and the number of attempts needed to solve a block pushes into the many-billions.

Longer explanation:

The "tiles" in Peach algorithm each contain 1024 bytes of deterministic data, derived from the hash of the previous block. There are 1048576 possible Tiles per block. For anyone counting, that's exactly 1 Gibibyte (not a typo) of unique data per block. The algorithm requires you to insert a unique nonce (Haiku) into the "Candidate Block" and perform a SHA256 hash on the Candidate Block. This hash is used to determined the index of the starting Tile. Once you have this starting Tile, the nonce, index and tile data are passed through a random and complex set of operations, known as a "Nighthash". The result of the Nighthash will determine the next tile you must jump to on your journey to finding a solution. This jumping process is performed several times and results in a final tile location. A final SHA256 hash is then performed on the candidate block hash and the 1024 bytes of data in the final tile, giving us a "Final Hash" that is then tested against the difficulty requirement of the block. More often than not, the result will not meet the difficulty criteria and we will need to start the process all over again. If, however, it does meet the criteria, then we have found our princess... I mean, solution.

Yaayyyy !! (Alexa, play Mario Theme song!)

This is basically how The Peach Algorithm works.

But we can dive even deeper...

Peach leverages several different mechanisms that attempt to shift the mining advantage back to GPUs, the first and arguably the most important of which is the 1 Gibibyte of unique "Tile" data per block. To obtain this data it must be built from the hash of the previous block. Building this data from scratch every time we need it takes time, but by caching (or storing) the data in available RAM we are able to obtain the data for processing much faster, thus providing an advantage to hardware supporting a decent capacity of faster memory. This alone was enough to eradicate the FPGA dominance present on the network, but we didn't stop there.

Nighthash, the extended implementation designed to limit the potential processing advantage of FPGAs. Now again, in English. Nighthash was designed to combat the possibility of a future event where the processing speed of FPGAs may outweigh the advantage of using high speed memory. It is composed of 3 sections of processing that attempts to play on an FPGAs weaker points. These sections include: Deterministic Floating Point Operations, Byte Transformations, and a selection of 8 different hashing processes (32bit Blake2b, 64bit Blake2b, sha1, sha256, sha3, keccak, md2, and md5). By themselves, these sections don't offer anything special, but due to the nature of how their random operations are selected, the number of combinations of operations should make the algorithm inefficient to implement on most FPGAs. For the remaining FPGAs not overly affected by this play, Nighthash hangs on the advantage GPUs have in the area of Floating Point Operations per Second (or FLOPs for short).

FPGA resistance

One of the Peach algorithms main benefits is its FPGA-resistant design. While it is not technically impossible to implement the Peach algorithm in an FPGA, it is definitely impractical. Further, an FPGA implementation would not be expected to perform as well as a GPU when mining with Peach. There are a few main ways in which the Peach algorithm discourages FPGA implementations: The Peach algorithm rewards miners running higher amounts of memory (RAM), which most FPGAs do not have. Caching tile data can be recalled later so as to reduce the workload of solving. The Peach algorithm uses a complex arrangement of randomly chosen operations, making it ridiculously hard to code for an FPGA. Peach leverages the extensive floating-point operation capabilities of GPUs in a deterministic way. Attempting to do the same thing in an FPGA is programmatically prohibitive at best. These factors together make the implementation of the Peach algorithm infeasible on an FPGA; even if someone went to the trouble of making it work, GPU miners would still out perform them.