status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-05 11:34:35 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 969

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing draft EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Noel Maersk 2018-04-16 17:55:48 +03:00 committed by EIP Automerge Bot
parent 668f1f591d
commit 822eec10fb
1 changed files with 113 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

152
EIPS/eip-969.md
View File

@ -26,22 +26,22 @@ may *"break"* these miners if they are in-fact built as traditional ASICs.
## Motivation ## Motivation
ASIC based miners will have lower operational costs than GPU based miners which ASIC-based miners will have lower operational costs than GPU-based miners, which
will result in GPU based mining quickly becoming unprofitable. Given that 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, 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. this will cause a trend towards centralization of mining power.
Risks include market dominance by a single manufacturer that may utilize production Risks include market dominance by a single manufacturer that may utilize production
stock to mine themselves, introduce backdoors in their hardware, or otherwise stock to mine themselves, introduce backdoors in their hardware, or facilitate a 51%
facilitate a 51% attack that would be infeasible. attack that would otherwise be infeasible.
This trend towards centralization has a negative effect on network security, 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. putting significant control of the network in the hands of only a few entities.
Ethash remains ASIC resistant, however ASIC manufacturer technology is advancing Ethash remains ASIC-resistant, however ASIC manufacturer technology is advancing
and ethash may require further changes in order to remain resistant to unforeseen 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 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 ASIC technology will face a barrier while more long-term mechanisms to ensure
continued ASIC resistance can be explored. continued ASIC resistance can be explored.
## Specification ## Specification
@ -57,50 +57,52 @@ the exception of the implementation of `fnv`.
The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 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 separate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing
`FNV_PRIME_A=0x10001a7` ``` c
`FNV_PRIME_B=0x10001ab` FNV_PRIME_A=0x10001a7
`FNV_PRIME_C=0x10001cf` FNV_PRIME_B=0x10001ab
`FNV_PRIME_D=0x10001e3` FNV_PRIME_C=0x10001cf
`FNV_PRIME_E=0x10001f9` FNV_PRIME_D=0x10001e3
FNV_PRIME_E=0x10001f9
```
`fnvA` replaces `fnv` in the DAG item selection step;
`fnvA` replaces `fnv` in the DAG item selection step `fnvB` replaces `fnv` in the DAG item mix step;
`fnvB` replaces `fnv` in the DAG item mix step `fnvC(fnvD(fnvE` replaces `fnv(fnv(fnv(` in the compress mix step.
`fnvC(fnvD(fnvE` replaces `fnv(fnv(fnv(` in the compress mix step
`fnv` as utilized in DAG-item creation should remain unchanged. `fnv` as utilized in DAG-item creation should remain unchanged.
## Agent Changes (Optional Variant) ## Agent Changes (Optional Variant)
The JSON-RPC `eth_GetWork` call may optionally return the proposed blocks algorithm. 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 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 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 field so a miner does not require special configuration when mining on a chain
that chooses not to implement the ASIC_Mitigation hardfork. that chooses not to implement the `ASIC_Mitigation` hardfork.
Due to compatibility concerns with implementations that already add additional Due to compatibility concerns with implementations that already add additional
parameters to GetWork, it is desired to add BlockNumber as an explicit 4th parameter 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 as suggested in https://github.com/ethereum/go-ethereum/issues/2333. Algorithm
should then be returned as either `"ethash"` or `"ethashV2"` according to the should then be returned as either `"ethash"` or `"ethashV2"` according to the
`block.number >= ASIC_MITIGATION_FORK_BLKNUM` criteria. `block.number >= ASIC_MITIGATION_FORK_BLKNUM` criteria.
## Rationale ## Rationale
This EIP is aimed at breaking existing ASIC based miners via small changes to the This EIP is aimed at breaking existing ASIC-based miners via small changes to the
existing ethash algorithm. We hope to accomplish the following: existing ethash algorithm. We hope to accomplish the following:
1. Break existing ASIC based miners. 1. Break existing ASIC-based miners.
2. Demonstrate a willingness to fork in the event of future ASIC miner production. 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 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 knowledge of existing ASIC miner design. The known released miner is available for
purchase [here](https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7) with delivery slated for mid-summer. purchase [here](https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7),
with delivery slated for mid-summer 2018.
Our approach should balance the inherent security risks involved with changing 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 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 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 changes to the algorithm, accepting the risk that the change may not break dedicated
hardware miners that utilize partially or fully configurable logic. hardware miners that utilize partially- or fully-configurable logic.
Furthermore, we do not wish to introduce significant algorithm changes that Furthermore, we do not wish to introduce significant algorithm changes that
may alter the power utilization or performance profile of existing GPU hardware. may alter the power utilization or performance profile of existing GPU hardware.
@ -124,13 +126,15 @@ experts.
The choice of FNV constants is made based on the formal specification at 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 https://tools.ietf.org/html/draft-eastlake-fnv-14#section-2.1
@goobur provided the following python code to output primes matching this criteria @goobur provided the following python code to output primes matching this criteria:
`candidates = [2**24 + 2**8 + _ for _ in xrange(256)]`</br> ``` python
`candidates = [_ for _ in candidates if is_prime(_)]`</br> candidates = [2**24 + 2**8 + _ for _ in xrange(256)]
`["0x%x" % _ for _ in candidates if _ % (2**40 - 2**24 - 1) > (2**24 + 2**8 + 2**7)]`</br> 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. The minimal prime constraint was relaxed, as has already been the case in `ethashV1`.
Typical ASIC synthesis tools would optimize multiplication of a constant Typical ASIC synthesis tools would optimize multiplication of a constant
in the FNV algorithm, while reducing the area needed for the multiplier according in the FNV algorithm, while reducing the area needed for the multiplier according
@ -139,48 +143,76 @@ 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 hamming weight, however care should be taken not to choose constants with too
large of a weight. large of a weight.
The current FNV prime, 0x1000193 has a hamming weight of 6. 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.
``` c
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
``` ```
uint32_t candidate = 0;
uint32_t dups = 0; An analysis can be done regarding the dispersion of these constants as compared to
uint32_t fnv_candidate = 0x10001a7; `0x01000193`, using the following snippet.
uint8_t *counts = malloc(0xFFFFFFFF);
memset(counts, '\0', 0xFFFFFFFF); ``` c
for ( candidate = 0; candidate <= 0xFFFFFFFF; candidate++) { // http://eips.ethereum.org/EIPS/eip-969
uint32_t result = (uint_32)(candidate * fnv_candidate);
uint8_t oldCount = counts[result]; #include <stdlib.h>
counts[result] = counts[result]+1; #include <stdio.h>
if (oldCount != 0) { #include <string.h>
dups++;
int main() {
u_int32_t candidate = 0;
u_int32_t dups = 0;
u_int32_t fnv_candidate = 0x10001a7; // MODIFY!
u_int8_t *counts = malloc(0xFFFFFFFF);
memset(counts, '\0', 0xFFFFFFFF);
for (candidate = 0; candidate < 0xFFFFFFFF; candidate++) {
u_int32_t result = (u_int32_t)(candidate * fnv_candidate);
u_int8_t oldCount = counts[result];
counts[result] = counts[result]+1;
if (oldCount != 0) {
dups++;
}
//// progress display: remove comment to speed down
//if ((candidate & 0xFFFFF) == 0xFFFFF) printf("0x%08x\n", candidate);
} }
printf("\nFNV candidate 0x%08x : %i dups\n", fnv_candidate, dups);
return 0;
} }
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 can be empirically confirmed that no more than 1 duplicate occurs 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 It is worth noting that FNV is not a cryptographic hash, and it is not used as
that said, a more invasive hash algorithm change could consider other options. One suggestion has been such in ethash. That said, a more invasive hash algorithm change could be considered.
[MurmorHash3](https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp).
[Other suggestions have been made](https://twitter.com/el33th4xor/status/981292363627810818). [Argon2](https://github.com/P-H-C/phc-winner-argon2), [Equihash](https://blog.z.cash/why-equihash/) of Zcash fame, and [Balloon Hashing](https://crypto.stanford.edu/balloon/). One suggestion has been [MurmurHash3](https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp).
Another possible candidate is [Cuckoo Cycle](https://github.com/tromp/cuckoo), although there are some concerns regarding unaddressed optimization vulnerabilities. One review is found [here](https://da-data.blogspot.com/2014/03/a-public-review-of-cuckoo-cycle.html) [Other suggestions have been made](https://twitter.com/el33th4xor/status/981292363627810818):
[Argon2](https://github.com/P-H-C/phc-winner-argon2),
[Equihash](https://blog.z.cash/why-equihash/) of Zcash fame, and
[Balloon Hashing](https://crypto.stanford.edu/balloon/).
Another possible candidate is [Cuckoo Cycle](https://github.com/tromp/cuckoo),
although there are some concerns regarding unaddressed optimization
vulnerabilities. One review can be found
[here](https://da-data.blogspot.com/2014/03/a-public-review-of-cuckoo-cycle.html).
This may be considered once the exact mechanism of the released ASICs is known and This may be considered once the exact mechanism of the released ASICs is known and
their effectiveness against its optimisations can be fully evaluated. their effectiveness against its optimisations can be fully evaluated.
## Backwards Compatibility ## Backwards Compatibility
This change implements a backwards incompatible change to proof of work based This change implements a backwards incompatible change to proof of work based