Early ASIC Mitigation Hardfork

EIPS/eip-969.md

@@ -0,0 +1,202 @@
+---
+eip: 969 
+title: Modifications to ethash to invalidate existing dedicated hardware implementations 
+author: David Stanfill <david@airsquirrels.com> 
+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)]`</br>  
+`candidates = [_ for _ in candidates if is_prime(_)]`</br>
+`["0x%x" % _ for _ in candidates if _ % (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7)]`</br>  
+
+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/).