[Ethereum] Ethash vs Equihash in terms of memory hardness

asic-resistantethashhash-algorithmmining

Ethereum's Ethash was designed to be memory hard with the intention of making the mining process ASIC-resistant. Zcash's Equihash algorithm also promises the same. How do these two PoW systems compare to each other?

Note: I'm not looking for a detailed explanation or differences in implementations etc. I just want to know how these algorithms effect miners and end-users. For example, in some video, I remember Vitalik saying that Ethash is 200 times more memory hard that Scrypt (used by Litecoin). I'm looking for similar comparisons between Ethash and Equihash.

Best Answer

Ethash vs Equihash memory hardness isn't a constant - it changes with time - but I'll try to provide a (very basic and generalised) method that you could use to work out what it is at any point in time.

Ethereum uses a generated DAG file which increases in size every 30,000 blocks (called an epoch). As of writing the current Ethereum epoch is #151 and the DAG size is 2.18 GB. You can find the current Ethash DAG details here: https://investoon.com/tools/dag_size

Equihash's memory hardness is dependent on the parameters used in its algorithm (based on Blake2b hashing) called n and k. According to the protocol paper (https://github.com/zcash/zips/blob/master/protocol/protocol.pdf), on the production Zcash network n=200 and k=9. That translates to ~500Mb memory requirement based on the algorithm implementations as defined by the authors of this article: https://www.cryptolux.org/index.php/Equihash. (Personally, I've found that the actual memory requirements when mining zCash tend to be a bit higher with a peak usage in the 800Mb-1.2Gb range.)

So to give a simple answer to your question - one could say that Ethash is at least 2-4 times more memory hard than Equihash (with that number set to grow as the Ethereum DAG epochs increase).

However there are more important nuances that you would need to factor in when assessing the two algorithms - especially for mining profitability - most of which are outlined here: http://www.openwall.com/articles/Zcash-Equihash-Analysis

Related Solutions

[Ethereum] Why did Ethereum design Ethash instead of using an existing memory-hard hash function

Though it's only a partial answer, this might shed some light: http://github.com/ethereum/wiki/wiki/Ethash-Design-Rationale . I seem to recall reading a blog post by vbuterin, but I can't locate it at the moment.

The main points can be found in that link, and are as follows:

IO saturation: The algorithm should consume nearly the entire available memory access bandwidth (this is a strategy toward achieving ASIC resistance, the argument being that commodity RAM, especially in GPUs, is much closer to the theoretical optimum than commodity computing capacity)

GPU friendliness: We try to make it as easy as possible to mine with GPUs. Targeting CPUs is almost certainly impossible, as potential specialization gains are too great, and there do exist criticisms of CPU-friendly algorithms that they are vulnerable to botnets, so we target GPUs as a compromise.

Light client verifiability: a light client should be able to verify a round of mining in under 0.01 seconds on a desktop in C, and under 0.1 seconds in Python or Javascript, with at most 1 MB of memory (but exponentially increasing)

Light client slowdown: the process of running the algorithm with a light client should be much slower than the process with a full client, to the point that the light client algorithm is not an economically viable route toward making a mining implementation, including via specialized hardware.

Light client fast startup: a light client should be able to become fully operational and able to verify blocks within 40 seconds in Javascript.

[Ethereum] Verifying ethash output Ethereum block hash

I've found an answer here at the Ethash wiki.

def calc_dataset_item(cache, i):
    n = len(cache)
    r = HASH_BYTES // WORD_BYTES
    # initialize the mix
    mix = copy.copy(cache[i % n])
    mix[0] ^= i
    mix = sha3_512(mix)
    # fnv it with a lot of random cache nodes based on i
    for j in range(DATASET_PARENTS):
        cache_index = fnv(i ^ j, mix[j % r])
        mix = map(fnv, mix, cache[cache_index % n])
    return sha3_512(mix)

def hashimoto_light(full_size, cache, header, nonce):
    return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))

Instead of generating the full dataset with calc_dataset_item, just the required dataset items for the single hash cycle are generated dynamically

Best Answer

Related Solutions

[Ethereum] Why did Ethereum design Ethash instead of using an existing memory-hard hash function

[Ethereum] Verifying ethash output Ethereum block hash

Related Topic