[Ethereum] How does Ethash work

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

Keccak is nice that it has arbitrary inputs and an infinite input space. This enables one to "make a hash" of a super large file where each input causes the internal state to scramble up some more. The hash should entirely change if a single bit of data in the source is different - unlike say a CRC32, or a checksum. It means your password could be a million chars long maybe. It's stored on disk as a hash, much smaller in size.

Regarding Keccak, it uses a "Sponge Construction" lord knows what that is read up on it here: https://keccak.team/keccak_specs_summary.html If I understand it's a permutation chosen from a set of seven Keccak permutations, denoted I assume by reference to their bit depths as b∈{25,50,100,200,400,800,1600}.

The state is organized as an array of 5×5 lanes, each of length w∈{1,2,4,8,16,32,64} and 25 cells deep. When implemented on a 64-bit processor, a lane of Keccak can be represented as a tidy 64-bit CPU word.

Finally, to even entertain the thought of similar input causing collisions, you have to imagine this data traversing from base 25, through base 50, up to 1600 and back. Smart money is on this being quite very resistant to collisions (it's design goal?).