The best way to speed up the ethash hashing algorithm is to speed up the 128 byte DAG page fetches from memory. Since fetching the DAG pages from memory is much slower than the mixing computation, we’ll see almost no performance improvement from speeding up the mixing computation. The reads are random access (each 128 byte page is chosen pseudorandomly based on the mixing function), so putting a small chunk of the DAG in an L1 or L2 cache isn’t going to help much, since the next DAG fetch will very likely yield a cache miss. Hashing a single nonce requires 64 mixes, resulting in (128 Bytes x 64) = 8 KB of memory read. Otherwise, Current Nonce is considered invalid, and the algorithm is rerun with a different nonce (either by incrementing the current nonce, or picking a new one at random).Įvery mixing operation requires a 128 byte read from the DAG (See Figure 1, Step 2). If Mix Digest is less than or equal to Target Threshold, then the Current Nonce is considered successful, and will be broadcast to the ethereum network. Mix Digest is compared against the predefined 32 byte Target Threshold. Mix 64 is post processed, yielding a shorter, 32 byte Mix Digest. Steps 2 & 3 are repeated 64 times, finally yielding Mix 64. This is done using a ethereum-specific mixing function to generate the next mix, called Mix 1 here. The Mix is combined with the retrieved DAG page.
The Mix is used to compute which 128 byte page from the DAG to retrieve, represented by the Get DAG Page block. The Preprocessed Header (derived from the latest block) and the Current Nonce (the current guess), are combined using a SHA3-like algorithm to create our initial 128 byte mix, called Mix 0 here. The flow of the ethash hashing algorithm can be summarized as follows:
#ETHMINER HASH CALCULATOR HOW TO#
The specifics of how to generate the DAG aren’t so relevant for this article, but you can read more about DAG generation in this stack exchange answer. As of March 2017, the DAG was ~2GB, and the DAG will continue grow in size as the blockchain grows. This is called a DAG, and is regenerated every 30,000 blocks (or every ~5 days).
The Ethash algorithm relies on a pseudorandom dataset, initialized by the current blockchain length. How the Ethereum Ethash Hashing Algorithm Works Instead, miners must “guess-and-check” hashes as fast as possible, and hope they’re the first miner in the entire crypto-currency’s network to find a valid nonce. Due to the cryptographic nature of each currency’s hash function, there is no way to reverse-engineer or back-compute a nonce that satisfies the target threshold limit. In proof-of-work mining, miners are tasked with generating a short binary blob (called a nonce), which, when hashed, produces an output value less than a pre-specified target threshold. For a less technical introduction to blockchains, visit the blockgeeks blockchain guide here. For a more technical, programmer-oriented explanation of Ethereum’s mining algorithm, called ethash, please refer to the ethash page on the ethereum wiki. For this article, I’m assuming readers have a general understanding of standard computer technologies and crypto-currency blockchains, but don’t need to be programming or mining experts. Here, I’ll walk through where Ethereum mining’s memory hardness comes from, and what the next generation of custom ethereum mining hardware might look like. Plenty of articles and forums attribute this to ethash being memory hard (a.k.a. Today, Ethereum GPU mining is the norm, but the miners haven’t made the jump to running the ethereum mining/hashing algorithm, ethash, on specialized hardware solutions (e.g. We saw this with bitcoin: Mining migrated from CPUs, to GPUs, to FPGAs, and now to ASICs. This creates a substantial economic incentive to not only deploy more mining hardware, but to also develop faster, more efficient mining hardware. As crypto-currencies increase in value, so does the payout from mining them.
0 kommentar(er)
