--- eip: 969 title: Modifications to ethash to invalidate existing dedicated hardware implementations author: David Stanfill discussions-to: https://gitter.im/ethereum/topics/topic/5ac4d974109bb043328911ce/eip-969-discussion status: Draft type: Standards Track category: Core created: 2018-04-03 --- ## Simple Summary This EIP modifies ethash in order to break ASIC miners specialized for the current ethash mining algorithm. ## Abstract There are companies who currently have dedicated hardware based ethereum miners in production, and may be actively mining. This EIP aims to "poison the well" by modifying the block mining algorithm in a low risk manner that may *"break"* these miners if they are in-fact built as traditional ASICs. ## Motivation ASIC based miners will have lower operational costs than GPU based miners which will result in GPU based mining quickly becoming unprofitable. Given that production of ASIC based miners has a high barrier to entry and few market players, this will cause a trend towards centralization of mining power. Risks include market dominance by a single manufacturer that may utilize production stock to mine themselves, introduce backdoors in their hardware, or otherwise facilitate a 51% attack that would be infeasible. This trend towards centralization has a negative effect on network security, putting significant control of the network in the hands of only a few entities. Ethash remains ASIC resistant, however ASIC manufacturer technology is advancing and ethash may require further changes in order to remain resistant to unforeseen design techniques. This EIP seeks explicitly to buy time during which newly developed ASIC technology will face a barrier while more long term mechanisms to ensure continued ASIC resistance can be explored. ## Specification If `block.number >= ASIC_MITIGATION_FORK_BLKNUM`, require that the ethash solution sealing the block has been mined using `ethashV2`. ## EthashV2 `ethashV2` will be identical in specification to the current `ethash`(v1) algorithm, with the exception of the implementation of `fnv`. The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 separate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing `FNV_PRIME_A=0x10001a7` `FNV_PRIME_B=0x10001ab` `FNV_PRIME_C=0x10001cf` `FNV_PRIME_D=0x10001e3` `FNV_PRIME_E=0x10001f9` `fnvA` replaces `fnv` in the DAG item selection step `fnvB` replaces `fnv` in the DAG item mix step `fnvC(fnvD(fnvE` replaces `fnv(fnv(fnv(` in the compress mix step `fnv` as utilized in DAG-item creation should remain unchanged. ## Agent Changes (Optional Variant) The JSON-RPC `eth_GetWork` call may optionally return the proposed blocks algorithm. While a miner or pool may infer the requirement for ethashV2 based on the computed epoch of the provided seedHash, it is beneficial to explicitly provide this field so a miner does not require special configuration when mining on a chain that chooses not to implement the ASIC_Mitigation hardfork. Due to compatibility concerns with implementations that already add additional parameters to GetWork, it is desired to add BlockNumber as an explicit 4th parameter as suggested in https://github.com/ethereum/go-ethereum/issues/2333. Algorithm should then be returned as either `"ethash"` or `"ethashV2"` according to the `block.number >= ASIC_MITIGATION_FORK_BLKNUM` criteria. ## Rationale This EIP is aimed at breaking existing ASIC based miners via small changes to the existing ethash algorithm. We hope to accomplish the following: 1. Break existing ASIC based miners. 2. Demonstrate a willingness to fork in the event of future ASIC miner production. Goal #1 is something that we can only do probabilistically without detailed knowledge of existing ASIC miner design. The known released miner is available for purchase at https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7 with delivery slated for mid-summer. Our approach should balance the inherent security risks involved with changing the mining algorithm with the risk that the change we make does not break existing ASIC miners. This EIP leans towards minimizing the security risks by making minimal changes to the algorithm accepting the risk that the change may not break dedicated hardware miners that utilize partially or fully configurable logic. Furthermore, we do not wish to introduce significant algorithm changes that may alter the power utilization or performance profile of existing GPU hardware. The change of FNV constant is a minimal change that can be quickly implemented across the various network node and miner implementations. It is proposed that `ASIC_MITIGATION_FORK_BLKNUM` be no more than 5550000 (epoch 185), giving around 30 days of notice to node and miner developers and a sufficient window for formal analysis of the changes by experts. We must weigh this window against the risk introduced by allowing ASICs that may exist to continue to propagate on the network, as well as the risk of providing too much advanced warning to ASIC developers. It is further understood that this change will not prevent redesign of existing dedicated hardware with new ASIC chips. The intention of this change is only to disable currently active or mid-production hardware and provide time for POS development as well as larger algorithim changes to be well analyzed by experts. The choice of FNV constants is made based on the formal specification at https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1 @goobur provided the following python code to output primes matching this criteria `candidates = [2**24 + 2**8 + _ for _ in xrange(256)]`
`candidates = [_ for _ in candidates if is_prime(_)]`
`["0x%x" % _ for _ in candidates if _ % (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7)]`
The minimal prime constraint was relaxed, as has already been the case in ethashV1. Typical ASIC synthesis tools would optimize multiplication of a constant in the FNV algorithm, while reducing the area needed for the multiplier according to the hamming weight of the constant. To reduce the chance of ASIC adaptation through minor mask changes, we propose choosing new constants with a larger hamming weight, however care should be taken not to choose constants with too large of a weight. The current FNV prime, 0x1000193 has a hamming weight of 6. `HammingWeight(0x10001a7) = 7;` `HammingWeight(0x10001ab) = 7;` `HammingWeight(0x10001cf) = 8;` `HammingWeight(0x10001e3) = 7;` `HammingWeight(0x10001ef) = 9; // Not chosen` `HammingWeight(0x10001f9) = 8;` `HammingWeight(0x10001fb) = 9; // Not chosen` An exhaustive analysis was done regarding the dispersion of these constants as compared to 0x01000193 using the following process. ``` uint32_t candidate = 0; uint32_t dups = 0; uint32_t fnv_candidate = 0x10001a7; uint8_t *counts = malloc(0xFFFFFFFF); memset(counts, '\0', 0xFFFFFFFF); for ( candidate = 0; candidate <= 0xFFFFFFFF; candidate++) { uint32_t result = (uint_32)(candidate * fnv_candidate); uint8_t oldCount = counts[result]; counts[result] = counts[result]+1; if (oldCount != 0) { dups++; } } printf("Candidate 0x%08x : %i dups", dups); ``` It can be empirically confirmed that no more than 1 duplicates occur in the 32 bit word space with these constants. It is worth noting that FNV is not a cryptographic hash, and it is not used as such in ethash. With that said, a more invasive hash algorithm change could consider other options. One suggestion has been MurmorHash3 (https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp) Other suggestions have been made for complete algorithm changes, including off-the-shelf solutions such as Argon2, Equihash of Zcash fame, and Balloon Hashing. (https://twitter.com/el33th4xor/status/981292363627810818). This may be considered once the exact mechanism of the released ASICs is known and their effectiveness against its optimisations can be fully evaluated. ## Backwards Compatibility This change implements a backwards incompatible change to proof of work based block mining. All existing miners will be required to update to clients which implement this new algorithm, and all nodes will require updates to accept solutions from the new proof of work algorithm. ## Test Cases TODO: will need to generate test cases for `ethereum/tests` repository corresponding to the consensus changes. ## Implementation TODO ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).