Early ASIC Mitigation Hardfork #969
Conversation
READ THISThis pull request is for a technical focused discussion of the proposed changes in this EIP. Comments which stray from this guideline or which do not contribute to the discussion may be deleted. |
|
@AirSquirrels can you explain the addition of the new header field Also, can you verify that your intention is for this to be a new RLP field and not just an extra computed field that the JSON-RPC returns. update I'm apparently a poor reader. I see your explanation now under the Agent Changes section. It might be nice to mark the Node Changes and Agent Changes sections as variants or optional additional changes. There is a core change which is the new ethashV2 algorithm, and then potentially some additional options.
|
|
@pipermerriam This was a forward compatibility consideration, although active fork rules could handle future changes in EthashVersion for future block numbers as well. I don't believe it would need to be an RLP field, it could be moved to only a GetWork flag. My reasoning is not all chains based off ETH would necessarily want to disable ASICs, and requiring individual miner developers to be individually configured for EthashV2 vs. Ethash as opposed to a node dictation of version seemed prudent. I see your point - simplicity could be had by only relying on the block number. Might I suggest ethereum/go-ethereum#2333 be implemented in that case? The seed hash pre-calculation hack to determine epoch is an annoying quirk of miner development. |
| ## Abstract | ||
|
|
||
| There are companies who currently have dedicated hardware based ethereum miners in | ||
| production, and probabalistically actively mining. This EIP aims to "Poison |
There was a problem hiding this comment.
Should read: "and probably actively mining"
I also recommend rewording to say, "and may be actively mining with that hardware". EIPs are not the place for speculation, and the only "facts" we have are that there is one company actively selling pre-orders for an EthHash ASIC.
| ## Abstract | ||
|
|
||
| There are companies who currently have dedicated hardware based ethereum miners in | ||
| production, and probabalistically actively mining. This EIP aims to "Poison |
There was a problem hiding this comment.
"Poison" should be lower case.
| There are companies who currently have dedicated hardware based ethereum miners in | ||
| production, and probabalistically actively mining. This EIP aims to "Poison | ||
| the well" by modifying the block mining algorithm in a manner that | ||
| probabalistically *"breaks"* these miners if they are in-fact built on ASICs. |
There was a problem hiding this comment.
Recommend rewording this to:
modifying the proof of work algorithm in a manner that may break existing ASICs.
Once again, EIPs are not the place for speculation, and until we know exactly how ASICs are functioning we cannot assert with any confidence whether or not a particular change will break anything. For all we know, the ASICs being sold are just second hand GPUs mounted together in a box.
There was a problem hiding this comment.
not at 800$ buddy.. we know for certain they are not GPUs mounted together in a box!
|
|
||
| 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, this will cause a |
There was a problem hiding this comment.
Production of GPUs also has a high barrier to entry. The provided argument does not effectively explain why ASICs are bad and GPUs are good. Recommend refining this to provide a more clear argument for why ASICs will lead to centralization.
There was a problem hiding this comment.
" more clear argument for why ASICs will lead to centralization" in every instance that an ASIC has been produced, it has led to a greater degree of centralization. no need to create an argument on something that is common sense these days... this is not pre-bitcoin ASIC days
There was a problem hiding this comment.
Data showing that the introduction of ASICs into a crypto-currency has increased centralization is a reasonable argument. However, that needs to be shown with data not "just common sense" and that needs to be explicitly stated. What is here now is simply incorrect.
There was a problem hiding this comment.
what kind of data?
"“Jihan does have a lot of control for now, and much of that is simply due to mining centralization. As Bitmain is so vertically integrated, from selling ASICs, to operating mining farms, to running mining pools, he can prevent network upgrade and attempt to hijack the Bitcoin brand with things like Bitcoin Cash," Mow said."
https://cointelegraph.com/news/bitmains-mining-monopoly-compromises-bitcoins-decentralized-nature
There was a problem hiding this comment.
Data showing a statistically significant correlation and causation between introduction of ASICs into a crypto-currency and an increase in centralization. I have seen a lot of correlation claims, but none backed up by data that gives a reasonable argument for causation other than "it feels right". When it comes to reality, there are often things that feel correct but turn out not to be.
Keep in mind that miners do not have a meaningful vote in which direction a hard fork goes. Economic participants make the decisions as to which fork survives and thrives, it only takes a single miner (until PoS, when it takes 0 miners) in alignment with economic participants to keep a fork alive.
|
|
||
| Furthermore, Ethereum was initially designed as an ASIC resistant algorithm and | ||
| the community has voiced strong support for making a definitive stand on our position | ||
| regarding dedicated mining hardware development to discourage future R&D investments. |
There was a problem hiding this comment.
Ethereum's PoW algorithm was designed to be ASIC resistant and it is ASIC resistant. It has not failed in achieving its stated goals in any way. Recommend removing that line as it isn't relevant to whether we alter the algorithm now.
|
|
||
| Furthermore, Ethereum was initially designed as an ASIC resistant algorithm and | ||
| the community has voiced strong support for making a definitive stand on our position | ||
| regarding dedicated mining hardware development to discourage future R&D investments. |
There was a problem hiding this comment.
It is incorrect to interpret brigading on GitHub issues as "strong support". Ethereum currently doesn't have a mechanism for determining actual support of an issue outside of the forking process. Recommend removing the claims of "strong support" as they are not verifiable and may not actually be correct.
There was a problem hiding this comment.
Agree, proposing "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."
| 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 to continue to probalistically propagate | ||
| on the network, as well as the risk of providing too much advanced warning to |
There was a problem hiding this comment.
For us to need to rush this the following need to be true for a single entity:
- It has the capital necessary to take over 50% of mining.
- It is capable of manufacturing an ASIC itself (without leaking design).
- It has the manufacturing infrastructure available to manufacture enough ASICs to take over 50% of Ethereum hashing power (a little less technically since as it takes over margins will go down forcing some people out).
- They have the manufacturing infrastructure from (3) at such scale that they can rapidly build and deploy this.
- They are willing to invest all of that capital into Ethereum mining with the knowledge that Ethereum is eventually moving to PoS and their hardware will eventually become worthless.
I find it unlikely that any single entity meets all of these requirements, thus I do not see the need to rush this.
There was a problem hiding this comment.
where did these requirements come from???
There was a problem hiding this comment.
Considering the change is fairly trivial and bitmain has been proven time and time again as a bad actor i see no reason to delay
There was a problem hiding this comment.
Forking is a complicated process and should not be taken lightly. It requires a massive amount of coordination. On top of that, changing the PoW algorithm requires implementation in multiple clients, which means multiple languages, along with testing, and cross-client testing. Along with all of this it needs to be audited by experts to ensure that it cannot be trivially gamed (this is easier for a small tweak than an entirely new algorithm).
30 days from EIP to fork is an extremely tight deadline and will require re-allocating many resources away from other tasks in order to take care of everything. Normally, time between EIP and fork is on the order of quarters to years.
There was a problem hiding this comment.
@cryptomined They come from reality. 😄 It is not free in either capital or time to take over Ethereum mining. With the current hash rate taking over is not something anyone is likely to do overnight.
There was a problem hiding this comment.
For the sake of argument, a cost analysis suggests bitmain could likely cross threshold to execute a 51% attack with about $300-400 MIllion in hardware. Analysts data suggests they do have that kind of capital available, and also arguably the manufacturing capability if all resources had been devoted to such an effort. I also find such an attack extremely, but they are one of very few entities that could. In these types of scenarios we have to consider every option where’s the risk of inaction, however small the chance, greatly outweighs the cost of action.
I don’t believe a 51% attack is necessary to significantly damage Ethereum either. A single player visibly gaining a large stake can serve to drive down mining interest through discouraging actors as well as profitability below the level where most can afford to proceed based on power costs, leading to heavy geographic centralization. This may be inevitable on a long enough time scale, but the concern is POS isn’t ready to take the reigns yet.
Finally, there is an argument to be made that rapidly executing this fork allows us to gather definitive data on the current concentration of dedicated hardware on the network and better assess this risk. Delaying too long (assuming the change would happen at all) opens a new lower cost scenario risk. There could be enough time for such an entity to replace their ASIC hashpower with programmable or commodity hardware hashpower long enough to convince the world they don’t exist. I’m not much for conspiracy theories but we have to consider all possibilities.
I also must make my personal stance clear. I am against hardforking for the directly evident current risks, but there are unknown risks. Thus I believe if we should hardfork the cost needs to be lower than the worst case of the unknown risks. This pull request meets that criteria.
There was a problem hiding this comment.
oh it's just common sense then? i thought we needed data... well they have probably taken over 30%+ already.. maybe more. waiting too long will allow them to take over more than 50%.. is that worth the risk?
There was a problem hiding this comment.
@cryptomined if we are attempting to keep the discussion technical, Bitmain would have to have pre-produced 250,000+ E3 miners to take account for even 20% of the current difficulty, at costs of at least $100,000,000. If those gradually came online since December at even pacethey wouldn’t have even paid for their miners yet. The R&D alone certainly cost $10M + before mass production would even begin. I don’t think they have that level of production capacity while maintaining shipments of all their other miners. Infact, all their other miner shipments combined for that period barely reach that number.
…motivation of this pull request
| 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. |
There was a problem hiding this comment.
I think the argument trying to be made here is along the lines of:
ASIC miner production is likely to be done by the people doing the mining, unlike GPU production which is done primarily by resellers who do not use the GPUs (in mass quantities) themselves.
I would like to see some data to back this up if it is true. If ASICs are produced and sold to the general public then ASICs are not a problem as it doesn't lead to centralization. If ASICs are produced and then used (without being sold publicly) then ASICs can lead to centralization if they are a big enough improvement over GPUs (which are sold publicly).
There was a problem hiding this comment.
Many risk arguments exist around single supplier scenarios as well. Backdoors are possible, leading to future 51% attack risks.
The data is a difficult ask, given that Bitmain mines in secret there is no way to know for certain. The only probable data is that the miner exists. The closest to data we could get would be from the results of the hardfork. I might suggest watching Monero’s hashrate this weekend as a possible canary in the coal mine.
| @@ -0,0 +1,182 @@ | |||
| --- | |||
| eip: <to be assigned> | |||
| title: Poisoning the Well | |||
There was a problem hiding this comment.
This isn't a descriptive title. Suggest "Modifications to ethash to invalidate dedicated hardware implementations".
There was a problem hiding this comment.
Perhaps "Modifications to ethash to invalidate existing dedicated hardware implementations"
| @@ -0,0 +1,182 @@ | |||
| --- | |||
| eip: <to be assigned> | |||
There was a problem hiding this comment.
Please rename this file to eip-969.md and assign it number 969 here.
| eip: <to be assigned> | ||
| title: Poisoning the Well | ||
| author: David Stanfill <david@airsquirrels.com> | ||
| discussions-to: <email address> |
There was a problem hiding this comment.
This should be a URL to somewhere people can discuss the EIP in general (this PR will only serve as a discussion venue so long as it's open, and we're moving towards merging PRs as soon as practical).
I suggest opening a discussion thread on the Ethereum Magicicans forum, or an issue in the EIPs repository, and linking to it from here.
| discussions-to: <email address> | ||
| status: Draft | ||
| type: Standards Track | ||
| category Core |
There was a problem hiding this comment.
You're missing a colon here.
|
|
||
| ## Simple Summary | ||
|
|
||
| This EIP attempts to break ASIC miners specialized for the current ethash |
There was a problem hiding this comment.
How? Suggest "This EIP modifies ethash in order to break ..."
|
|
||
| ## Agent Changes (Optional Variant, stand alone or combined with Node Changes) | ||
|
|
||
| GetWork may optionally return the proposed blocks `EthashVersion` field. While a |
There was a problem hiding this comment.
I would suggest making it an "algorithm" field, instead, with an algorithm name and version. If a new field is to be added, it makes sense to make it as versatile as possible.
There was a problem hiding this comment.
It can be an Algorithm field in the block, however GetWork returns unnamed values and parity already defines a 4th (block number). I would propose adding block number regardless, and defining algorithm as an optional 5th value of getwork. Would you like version as a 6th? Or algorithm as “ethash2”?
There was a problem hiding this comment.
Since different versions of the same algorithm can't be compatible, I don't think there's any point in having separate name and version fields - just a name field should be enough.
There was a problem hiding this comment.
I think FNV Prime change's are main change on this proposal.
It is simple, if FPGA based miners will easily catch-up.
I think more different ways of MIX algorithm change's make more time, Registance to ASIC vendors.
|
|
||
| `fnv` as utilized in DAG-item creation should remain unchanged. | ||
|
|
||
| ## Node Changes (Optional Variant) |
There was a problem hiding this comment.
What's the rationale behind adding this?
There was a problem hiding this comment.
In short, it is 6th isolated usage of FNV but there isn’t another ideal FNV constant other than the already selected constant.
There was a problem hiding this comment.
I'm asking about the "Node Changes (Optional Variant)".
There was a problem hiding this comment.
I believe I’m going to drop that from the EIP completely. I originally had thoughts that we needed to preserve the Algorithm in the RLP on the block chain as well as a computed Block header field for GetWork. @pipermerriam pointed out that the block.number check in VerifySeal and Mine is sufficient.
…escriptive about the intention and risk. Removed unneeded Concensus/Block field changes.
EIPS/eip-969.md
Outdated
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| This change implements a backwards incompatable change to proof of work based |
There was a problem hiding this comment.
incompatable -> incompatible
There was a problem hiding this comment.
This is what I get for using vi without spell checker. Grammar fixes incoming.
EIPS/eip-969.md
Outdated
| @@ -0,0 +1,167 @@ | |||
| --- | |||
| eip: 969 | |||
| title: Modifications to ethash to invalidate dedicated hardware implementations | |||
There was a problem hiding this comment.
I suggest "Modifications to ethash to invalidate existing dedicated hardware implementations"
EIPS/eip-969.md
Outdated
| the exception of the implementation of `fnv`. | ||
|
|
||
| The new algorithm replaces the 5 current uses of `fnv` inside `hashimoto` with 5 | ||
| seperate instances defined as `fnvA`, `fnvB`, `fnvC`, `fnvD`, and `fnvE`, utilizing |
There was a problem hiding this comment.
Could you also give more information, e.g. as per #958 (comment)?
There was a problem hiding this comment.
Can you clarify the more information from #958? A lot of 958 discussion is now deleted.
There was a problem hiding this comment.
I didn't delete any useful discussion on #958, just "Me too" type comments. @jamesray1 is linking to a particular comment there.
EIPS/eip-969.md
Outdated
|
|
||
| ## Agent Changes (Optional Variant) | ||
|
|
||
| GetWork may optionally return the proposed blocks algorithm. While a |
There was a problem hiding this comment.
Sorry, can you introduce GetWork more clearly?
EIPS/eip-969.md
Outdated
|
|
||
| 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 https://github.com/ethereum/go-ethereum/issues/2333. Algorithm |
There was a problem hiding this comment.
as suggested in... The algorithm...
EIPS/eip-969.md
Outdated
| 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 probabalistically without detailed |
There was a problem hiding this comment.
probabalistically -> probabilistically
EIPS/eip-969.md
Outdated
| 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 |
There was a problem hiding this comment.
algorithm, while accepting
|
|
||
| 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) |
There was a problem hiding this comment.
Other suggestions have also been:
Ari points out that there are off-the-shelf solutions such as Argon2, Equihash of Zcash fame, and Balloon Hashing.
https://twitter.com/el33th4xor/status/981292363627810818
There was a problem hiding this comment.
has been [MurmorHash3](https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp).
…analysis and FNV selection, grammar fixes
|
I think the next step is to seek commentary from experts in this subject matter on ASIC-resistant, memory-hard hash functions and ASIC resistant PoW algorithms, specifically on how likely it is that this proposed change will render the Bitmain E3 miner ineffective. https://twitter.com/JamesCRay01/status/981553711871770626 |
|
Please advise when you're happy to merge this; we're trying to move to a model where we merge drafts quickly and direct discussion on them to a permanent location. |
|
Yes I'm happy to merge this as a draft. |
|
I’m happy to have this merged as well |
|
Big thanks to @MicahZoltu @jamesray1 and @Arachnid for your review and help moving this through the process. |
|
Yes, thanks Micah and Nick, and a big thank you to you too Piper for facilitating this, and to Dan for writing this! |
|
Should we lock the discussion on this now? |
|
|
||
| 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 |
There was a problem hiding this comment.
Looking at http://eips.ethereum.org/EIPS/eip-969 it seems that the URL is not automatically rendered as a clickable URL. So may you please change this to purchase [here](https://shop.bitmain.com/product/detail?pid=00020180403174908564M8dMJKtz06B7).
There was a problem hiding this comment.
I don't think this needs to be a clickable URL, and I think it's actually better if it isn't.
There was a problem hiding this comment.
Haha, for this Bitmain shop link one, fair enough.
|
|
||
| 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 |
There was a problem hiding this comment.
[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/).
There was a problem hiding this comment.
This PR has already been merged, so I'm not sure if I should create a new PR for the edits?
There was a problem hiding this comment.
Yes, you need to create a new PR. It'll be automatically merged by the bot as soon as you submit it and the build passes.
|
I actually think that using https://github.com/tromp/cuckoo is very much worth considering / further analysis instead of this, as the implementation is only 42 lines, and the readme makes striking claims. |
|
I had given a suggestion the otherday of using Equihash algorithm. I have
since reconsidered and I think you guys are on the best track....to make a
small change in the existing Ethash algorithm.
The reason for my change of
heart is I am worried Bitmain already has ASICs designed for EVERY
published GPU algorithm. They are simply waiting for the price of coins
mined with those algorithms to go high enough for them to mass produce,
mine, sell coins, then sell miners once their production is ramped.
You guys are going in the best direction. Do not trust any published
algorithm.
Finally, I am not sure if this is possible and if it is might be very controversial. For the long term solution you should consider developing a hybrid algorithm and not releasing the code. This should buy Ethereum enough time to roll into full POS without wasting more time on this again.
|
|
Cuckoo is likely not ASIC-resistant. Weaknesses pointed out 4 years ago have never been addressed: |
|
@jamesray1 I also wanted to mention that while Cuckoo has had striking claims, there is a known optimization to the the initial interesting routes pruning step. I believe that's similar to the analysis @rufus210 posted. I'm looking for the link I read in my notes. |
|
I would say it would be better to change the fnv not just for mix aggregation, but also for random selection (ie. in |
|
@vbuterin what's the catch for this sort of tweaks? Is there any evidence to support you guys' (implied) assumption that it is all about som combinational circuit somewhere to be neutralized by some random tweaks to the algorithm? I have argued against such a naive perception in my comments above and I'm absolutely sure that blind algorithm changes won't help a bit. Alternatively, I have more comprehensive analysis and counter measures for the attack to present, if there is a commitment to resist, from the news I'm not convinced it is the case tho. |
|
@AliAshrafD we have been discussing explicitly disabling existing hard ASICs in these changes, not more in-depth changes to prevent future chip design or mitigate theoretical programmable logic. Can you provide your evidence for being “absolutely sure” it won’t help? Information I have does strongly suggest the current batch is not based on programmable or configurable chips. We are not trying to work on guesses or assumptions here. |
|
@vbuterin I had also included the random selection FNV, infact I had reserved the strongest constant for that purpose as it is the most sensitive area. Did you have rationale other than changing another factor for increasing number of accesses? My view was that increasing accesses would affect both GPU and ASIC logic similarly, given that it would only increase memory bandwidth. I had offlined the suggestion that we could switch the Keccak hash to the final SHA3 as well. If the full Keccak/SHA3 pipeline is in hardware changing the message delineation byte (the sole change from Keccak to SHA3) would render hardware SHA3 disabled even on an otherwise programmable chip. On the other hand if only the individual Keccak Round is accelerated this would be easily changed in software. |
|
@AirSquirrels I am strongly convinced that E3 is programmable because: So, I have to declare E3 not to be an ASIC attack, it is definitely a shared memory attack in architectural specifications of the hashing board, simply because it is the only vulnerability for Ethash that opens doors for specialized hardwares (not necessarily circuits printed on chips) attacking the network. Finally and most importantly, it doesn't matter you find my analysis persuasive enough or not! A hard fork is a hard fork, isn't it? People should upgrade and it is a 'hard' process to go through, no matter how deep is the fork and what it actually is about. As a programmer I never do a trade off between the risk of side effects and the risk of missing the purpose. My priority is always the purpose because I have full control over my code and can do it in a reliable, clean way and for the god sake, we have testnet and a thousand eyes watching and reviewing every single line of our code. Forgetting about side effects, what other factor may discourage us to take care of the shared memory attack vulnerability? I have a very interesting idea with minimum potential for side effects. we can include this EIP's tweaks as well (i,e, I will preserve Ethash mostly) doing this we can mitigate both attack scenarios. |
Where do they claim that? The product page even says:
How?
What is a "shared memory attack"? |
|
@AliAshrafD I certainly appreciate all your information and discussion, however I do continue to find a lot of speculation and not evidence based points in your response.
|
|
@Arachnid , @AirSquirrels Bitmain is a sophisticated player, and it is a high stake game. Right? As of my efficiency argument: @AirSquirrels's perception eventually leads to a general purpose ASIC-like 'thing' that fetches memory to its registers and does some operations (probably using a mega opcode instruction set like _doHashimoto) supported by specialized circuits for the algorithm ... Regarding my analysis of this attack to be of a shared memory class, I have already described the big picture for a possible schema based on a critical argument: I admit that I have to describe more. The problem is with my time zone and me being kinda exhausted right now, will be back on this tomorrow, my apologies. |
|
@AliAshrafD Again I appreciate all your insight. I believe Bitmain designed and initially produced the E3 at a time when they were far less worried that ETH would intentionally fork or change the algorithm. That suggestion has only come about loudly recently. I don't have much time to respond to all your speculation, however you made a statement regarding a "State of the art 4GB DRAM bank" achieving 200 MH/s. Most modern graphics cards can saturate their memory buses, but not with ETHash due to random access pattern and linear dependency chaining. In reality you only need a handful of pipelines to achieve 200 MH/s if you have the memory bandwidth. 200 MH/s requires an absolute bare minimum of 1.56 Terabytes/s of DRAM access no matter how you slice it, a bit more in reality due to pre-charge, access time, etc. The worlds best possible imaginary controller can not change that. Certainly you can build many cheap instruction or macro-op based GPU cores (why bother? fixed pipeline ASIC cores are cheaper to design and build and faster/lower power to run. If you use instruction processing ops, your competitor will beat you in power efficiency). You would still need a very modern chip to wire into your DRAM. For 1.6 Terabytes a second with GDDR6 @ 18Gbps you need 728 pins, or ~ 23-24 chips without ECC. GDDR6 is not shipping yet in volume, so double those numbers for GDDR5 - 1456 pins. The memory controller to interface to 48 chips like that is the bulk of the complexity of a modern GPU, not the shader engines. You should then need to interface all your cheap chips to that memory controller with a similar high-bandwidth low-latency interconnect. Modern SERDES at PCIe 4.0 levels is 16 Gbps and would require 66 transceiver lanes of this from each of your "cheap" GPUs to the memory controller to achieve the needed 133 GB/s (1.6TB/s divided by your 12 GPUs). You now have 1456 pins of GDDR5 memory just for the data lines, plus 264 pins for your LVDS TX/RX pairs for the SERDES to EACH of your 12 GPUs. I count 3168 pins of SERDES + 1456 pins of Memory Controller to memory interface. I haven't even included memory address lines or power pins. A package of that size essentially doesn't exist. There is also no evidence Bitmain has GDDR5 IP (Their Sophon could certainly benefit from it, yet it is all DDR4 based). Everything you are describing is feasible in a theoretical world, but is far from the most power, price, or effort efficient way to accomplish Bitmain's performance numbers. It fails the Occam's razor test. Compare 18 relatively simple ASIC chips, each with 32 x16 DDR3 1Gb chips hanging off of them. Quad-Channel DDR3, 4GB per core, with 512 data lines and a perfectly reasonable number of pins. Assign a cheap part at 1600 MT/s per pin (or run the numbers for 2133MT/s if you'd like) = 100 GB/s for each of the 18 cores, achieving up to 12.5 MH theoretical per core. 225 MH. Allow for random access in-efficiencies and you get 180MH as advertised, with 576 DDR3 chips as rumored multiple times. Easily $0.50/chip of old proven tech at volume on contract, and with a relatively simple control chip. This is significantly cheaper and easier than your proposed shared memory custom GPU machine. |
|
@AirSquirrels Appreciate your patience and dedication of your time. I'n not much of a system architect and have no privilege to judge your analysis properly. Just some insights: As of your critics regarding my hypothetical shared memory architecture: As of your hypothetical ASIC alternative: 2- 576 RAM banks+ ASICs+controller+ ... doesn't look a cost effective solution to me. 3- I doubt that tASIC chips on that volume are accessible too. 4- I don't believe a multi billion dollars company commits such a huge mistake against an almost centralized community (in terms of 'spiritual' governance) such as Ethereum to build an ASIC vulnerable to little tweaks in the algo through easily manageable hard forks. A community that has been united once for an incident as small as the DAO hack. They have risk analysis task forces obviously and your alternative puts a lot of investments (in ASIC design phase) in danger. And one more thing: |
|
Hey ethereans, would be possible to make the paramenters of ethash change each epoch? And maybe not just this, but change the "hashing circuit" each epoch, making ASIC need to become "generic", so not more ASIC. |
|
First of all thank you all talented guys for the great ethereum project. Since I am not a programmer nor system architect I can not really critisize any tech details above, but I have something on my mind to share. English is not my first language please forgive me. A. Ethash algo is memory intensive but technically $/H(price per hash) or J/H(electric power per hash) improvement is possible and very likely to have happened already. Suppose both points are correct. Then, Any Asic/FPGA or other type of devices shall land between Point A and Point B. Manufacturer of such deive has follwowing options. Scenario 1. mass production and keep mining for max profit. Scenario 1 is close to monero before Apr6th V7 fork while Scenario 2 is comparatable to a new GPU vendor, say Intel, selling their GPU, or just nVidia selling 11xx serious and thus harmless. Again real world situation is in somewhere in between , a Scenario 1.* . It is obvious that A1 is the worst case for ETH and B2 is nothing to be worried about and hard fork is entirelly unnecessary. Now lets have a closer look. Suppose bitmain is unable to get A too faraway from B, and ethash algo did its job, being asic resistant, perfectly. Their product is barely better than a RX570, lets say. We can find out that mass production is profitable because they can always acheive profit level of AMD and nVidia at least by resell it. Their mineing machines always sell well. And they do mass produce them. Bitmain is the largest crypto IC buyer of TSMC(even globally, matter of fact) and larger than nVidia or AMD. Bitmain is known to runs their own farm, and they "test" run their product at least. In the monero case they run it for mothes without any intention to retail untill Apr 6th v7 fork is announced. It also makes economic sense to be as close to Scenario 1 as possible and resort to resell only when the mashines are becoming obsolete. I don't know how people feel like it but in my mind it takes me 1 minute to realise that eth is facing this |--- A ---B---| matrix. Bitmain will keep making their machines untill retail price GPU is not at all profitable for mining. They will mine eth with $0.04 power price till everyone else has powered off. It is their business to make crypto-chip and mine. It is all fit and profitable that they shall do this. GPU miners are, at this very moment, swithing to Cryptonight V7 or other algos. Bitmain will not stop entill GPU eth mining is totally dead and that is the best case, A1.5 . Even ethash algo is asic resistant or 100% asic-proof, eth is still becoming asic-ed wthiout a hard fork. |
Pull request based on the conversation in #958