I’ve stated (too) often that we accepted progPoW in early January and I have never understood how an audit became an obstacle. A hardware audit seems particularly pointless, as if someone knew how to beat progPoW in hardware they’d do better to keep their mouth shut and make some money. I wish we had called this progEthHash–it might have just sailed on through.
8 Likes
Option 3. Release ProgPoW in Istanbul without an audit.
3 Likes
Absolutely. The problems with this proposal are almost entirely social. The audit will help validate the technical implementation, which I think is important given the criticality of this functionality to our overall security, but the audit simply cannot address all the issues that opponents have because they’re mostly social and have to do with trust. I don’t know how to solve that, other than simply educating others on what it’s all about and keeping things fact-based. In the end though, it’s a social decision, and the only tool we have that we know works for this scenario is hard forking. That’s one of the reasons I believe it should be in a separate fork from Istanbul, to make it very clear accepting the update is approving of it.
We could potentially soft fork it… If enough miners adopt it, it’ll be the longest chain. Something of that nature would be interesting.
2 Likes
Ethash, the algorithm ProgPow is aiming to replace, received an audit from Least Authoruty in 2015: ethereum-analyses/PoW.md at master · LeastAuthority/ethereum-analyses · GitHub
My advocacy for ProgPow has always been conditioned on the audit. If ProgPow is going to get into Istanbul without an audit then someone else will need to step up as champion on the calls.
3 Likes
The technical audit as a requirement makes sense.
I also know people think/want the audit to answer a larger set of questions it’s simply not adequate to answer, as they are more philosophical in nature (should we support the current miners by doing this?) or just hard to quantify (when does Ethash ASIC hashrate take over the network?)
Not really clear why Ethash audit was completed successfully by Least Authority single-handed, but ProgPoW audit requires "hardware partner who specialized in ASICs ".
1 Like
Hi from Gitcoin. We are paying out 13k DAI in CLR matching for this grant ( buidlbox ) this week. this is in additoin to the 15805 DAI raised on the grant already.
4 Likes
Did Constantinople get an audit? Will the next hard fork? Is everything getting a long, expensive audit now, or just ProgPoW (despite there being overwhelming support)?
1 Like
We don’t have a process for what deserves an audit. There are definitely examples of past EIPs that should have had an audit, due to deeper complexity that could cause adverse behaviors if not implemented correctly. I think ProgPoW meets the cut for that, because while it is a very simple change, if it is not done correctly it could reek havoc and stall the chain or affect the security of it in some way. So I support the audit.
Regardless, it does seem like some opponents promoted the audit as a method to block implementation into the next fork, hoping for a death through bureaucracy. This is unfortunate because it does have wider support. The audit was reduced in scope to only technical correctness for this reason.
1 Like
I think the request for the audit of ProgPow has set the standard that anything that replaces or significantly modifies the base consensus layer needs an audit (base consensus, not including EVM execution and state syncing, i.e. “payload”). So we should plan now for a beacon chain audit and a beacon chain finality gadget audit and just put those in our mental project plans.
2 Likes
Yup, that definitely seems consistent.
Is there a tag we could put on changes that are significant enough to require an audit to be considered? Currently we have “Core”, but it seems to me that some of these are more hard"core" then others.
- Progpow
- Beacon Chain
- Finality Gadget
If there is consistency then it would be helpful to put language to this as well.
2 Likes
Beacon chain is fun because there exists no EIP for that. I’m not even sure how we would standardize something like that, it’s basically a new thing. Do we need a new EIP process? That rabbithole is looking pretty deep…
Anyways, I had a suggestion to add tags on EIPs requesting particular specialized review by subsets of the community. I think the event plan was to align these tags with FEM rings that maintain channels of communication and discuss the relevant proposals on something like a monthly basis. Not sure that makes sense to me any more, but might get the juices flowing on how we make something like this happen.
@souptacular and Ethereum core devs ,
ePIC Blockchain would like to help with the ProgPOW hardware audit.
We are former engineers with GPU and mobile SoC semiconductor firms with over 120 years of combined experience designing and manufacturing GPU, mobile SoC and various ASIC’s.
Our team consists of key architect and designers who have worked on 8 generations of GPU’s, the shader core for an upcoming game console, as well as, several crypto ASICS. Our supply chain team has put into production 100’s of millions of ASIC’s and GPU’s for ATI/AMD and Qualcomm. Our foundry experience and contacts range across TSMC, GF, Samsung and others through 7nm to 65nm nodes.
We would be pleased to work with the Ethereum community in the ProgPOW audit with the neutrality that is needed. Who better to conduct the audit than a team that builds both GPU and ASIC’s and has the full ASIC supply chain and foundry expertise?
Be sure to check out our website at www.epicblockchain.io. Also if any of you are in Toronto for the @ScalingETH Dev Workshop next week and want to meet to discuss ASIC’s or what hotspots in Toronto are, drop me a PM.
Cheers, Henry
PS. I should also point out that ePIC makes ASIC’s and we do not mine.
3 Likes
Hi, I’ve engineered both GPU and ASIC miners, and I’ve also operated large-scale CPU and medium-sized GPU farms. Together with 7400 and Salt, we released an open-source ASIC miner for Cryptonight Classic that was 5x better H/J than Bitmain’s X1, while using only 28nm. Recently, the Monero PoW team invited me to review RandomX, and I’m also releasing new technical work on Cuckoo Cycle.
Our hardware team at altASIC has done an initial review of ProgPoW and posted our comments to their GitHub issue. We’re unwilling to go on record as to whether ProgPoW will meet its objectives of keeping ASIC’s to within 2x and thereby being considered more ASIC-resistant than Ethash. Such determination would require more implementation work than we are willing to commit, but we call attention to the published design by Sonia Chen at Linzhi, also referenced in the ProgPoW issue.
I’ve cross-posted our comments here from the ProgPoW issue, and hope they’re helpful to the Ethereum community:
Overall, ProgPoW looks to be a genuine, professional attempt by GPU-interested parties. That is to say, we found no obvious backdoors or any suggestion that ProgPoW is anything but an honest attempt at ASIC resistance.
The inner loop does try to cover the shader datapaths pretty well, but obviously GPU’s without a unified texture/L1 architecture will waste some texture area, and all geometry pipelines go unused. Also, ProgPoW is strictly integer math, while GPU’s predominantly focus on float performance, so that overlap is also less than 100%. However, we are not GPU insiders and cannot quantify the GPU die area that would go unused in ProgPoW.
We do point out that while GPU’s are not especially good at integer multiplication and are outright bad at bit operations, five of eleven random math operations in ProgPoW are bitops and two are multiplies. For Nvidia, bitops take 2 cycles each, the same as addition, and multiplies are so slow the official docs say only “multiple cycles.” In ASIC’s, bit operations especially can run considerably faster.
We suspect a VLIW architecture may help exploit this, by combining multiple instructions into a bundle that can be computed in fewer clock cycles than each instruction individually. If we group the 11 operations into three categories: bitops, adds, and muls (also rot), then our slow-seed compiler can generate instructions like bitop-muladd-bitop that frequently match branches of the abstract syntax tree and run in far less than the 8+ cycles this would take on a GPU. The timings and dependencies of instructions may be precalculated by the compiler, such that no on-chip sequencing logic is necessary. Also, the set of VLIW instructions may be generated from the distribution of the program space, and this distribution may also inform the number of compute instances for each instruction. There would be many bitop-bitop units for example, and fewer bitop-add-mul-add-bitop units, efficiently matching transistor count to the frequency of each op sequence.
These gains all together may or may not give a 2x speedup, and we can’t say without deeper analysis.
Overall we think ProgPoW is a good try, probably the best anti-ASIC attempt so far. It is relatively simple and straightforward, and professionally designed and documented, yet we remain uncertain of its chances for keeping the ASIC gap to 2x.
3 Likes
Actual ethash suffers from the same waste.
FP operations imply other kind of problems.
I quote @shemnon from the gitter channel
“Floating point precision is different between GPUs (and vendors and versions) and CPUs. Java has a strictfp keyword just to deal with that. EWASM has banned it from their specification for similar reasons. Integer math provides portable exactness.”
1 Like
I’m not suggesting that the PoW use floats, and of course I’m well aware of the issues. Actually RandomX does use floats in a CPU-oriented PoW, but they take care to avoid non-normal conditions like underflow and NaN, and they’ve verified implementation consistency with the IEEE standard across Intel, AMD, and ARM, exhaustively validating all possible outputs of their float operators.
My point is that GPU’s are primarily designed for floating point performance, not integers or bitops or flow control. In fact, the only operation that runs in a single cycle on an Nvidia card is a half-precision float muladd. Full precision float multiplies run in just 2 cycles even though their integer multiply counterpart is much slower. GPU’s can do this because you just don’t need exact answers in graphics shaders, only something that’s close enough to look good to a human eye. GPU’s do the best they can in a short time and leave some small errors in the LSB’s of the significand, which is obviously unsuitable for a PoW. PoW’s require exactness and integer arithmetic, and using GPU’s for PoW is like using a hammer to drive a screw. The main thing they do well, float muladds, goes unused.
That is changing recently with the greater emphasis on GPGPU computing, but the focus is really on scientific compute and deep learning, which are both primarily all float ops. There is not much incentive outside crypto for GPU manufacturers to improve integer performance.
Although I want to maintain a neutral stance on ProgPoW vs Ethash, in general I think ASIC resistance is a fool’s errand, and GPU mining is doomed. The ProgPoW team did what they could within the constraints provided, but you can’t turn a boat into a car. Not their fault if it doesn’t work. GPU’s are just suboptimal for PoW computations.
ProgPoW’s hope is that is they do get “close enough” to ASIC performance that the economics of scale in the GPU industry make smaller ASIC manufacturers unable to compete, but this is an Economy of Scale effect, not a technical difference between ASIC’s and GPU’s. ASIC’s by their very definition will always be faster than general compute units at the task for which the ASIC was designed. The question is whether a GPU’s integer performance is good enough relative to ASIC’s to allow the GPU industry’s economy of scale to make up the difference.
If GPU integer performance sucks very badly then ProgPoW may be worse than Ethash. If GPU’s perform pretty well at integers, then ProgPoW may be better. We’re not willing to speculate without a lot more work.
My personal view on PoW is that there is no such thing as ASIC resistance. Furthermore, GPU’s can jump coins and are easily rented and are therefore less secure than ASIC’s even before you consider hashrates. A PoW needs to be simple to understand and implement, and it needs to be well reviewed by serious cryptographers. IMO Ethereum should dump both ProgPoW and Ethash and use Keccak. But there’s too much GPU-interested politics in Ethereum for that…
This is a double-edged sword that almost everyone points out the bad side of. The good side is that because GPU miner’s hardware is less specialized (they can always sell the hardware at a loss or mine another coin), they will not dig as deep a position against an existential threat to their operations (for example, the upcoming move to PoS and the mining reward reduction when we employ the finality gadget). If PoW mining were the long-term goal of Ethereum, then it would absolutely make the most sense to adopt an ASIC friendly position, because that type of deep hardware investment aligns these actors long-term with the health and security of the current chain. But we are not trying to do this! As a community we are looking to make a move to a completely different consensus mechanism that eliminates the need for any sort of mining over time.
To respond to the specific criticism though, rental attacks hold true for any PoW algorithm, no matter what is considered the most profitable hardware for mining it (CPUs, GPUs, ASICs, etc.). In the general case, if you do not have a supermajority share of the hardware considered to be the most profitable for mining a particular PoW algorithm, you will be at risk to a rental attack. Ethereum currently attracts the largest share of GPUs used for mining. If it were to change it’s algorithm to something that attracts more specialized hardware, that currently mines another coin more profitably, the network would become much more insecure as a result. Therefore changing to another algorithm where the GPU is not the most profitable hardware for mining it would almost certainly lead to a loss of security over what we currently have. It also represents a centralization of power as these manufacturers are much better coordinated and have larger incentives to disrupt any unprofitable changes than to current mining algorithm. It simply should not be done.
I don’t think it’s controversial to say we should either make a change in an attempt to further ensure ETH is the most valuable coin for GPU miners to mine, or accept that we as a community no longer value ASIC resistance and we prefer to let specialized hardware own our network security from the near future onwards, for better or worse. The later option will happen by default as it does not require any change to the current technical design of Ethereum, but we should recognize it represents a change to the social contract laid out from the beginning in the Whitepaper. However, deciding to go all in on allowing ASICs may see an exodus of GPU miners as they divest themselves from involvement in our community, so we may see short term insecurity as a result. Failure to make an active decision one way or another represents a win for specialized hardware manufacturers, and invites them to make further investment into our ecosystem with the knowledge that they can win against the community on any dispute much easier than if we did make an active decision.
Whatever we decide, it should be understood that it may come at the detriment of our future plans for a transition to PoS.
3 Likes
@timolson Have you watched the DevConIV ProgPow talk by @ohgodagirl? I think it addresses most of the issues, apart from the deep dive into floats. I would ask that anyone who is serious about debating ProgPow watch it first. She is Miss If (of If/Def/Else) so her word is gospel when it comes to the authors intent.
First, let’s not conflate ASIC-resistance with ASIC-proof. No algorithm is ASIC-proof. What ASIC-resistance aims to do is to resist, not prevent. By making an algorithm that is very well suited to the GPGPUs it makes the economics of producing and maintaining unpalatable, short of a sustained tripling of Eth’s all time high. Making GPUs the best device on the market to do it and designing the algorithm so that an ASIC would look like a GPU missing some ports an chips is their method. Miss If admits it is a short term solution and that this resistance has a time limit. The goal is to make that time limit past the Proof of Stake transition.
And that one of the reasons I think ProgPow should be done. We need to move the cheese before ASICs dominate the mining aspect in the way they have controlled BTC and other cryptocurrencies. The need for a return on investment is a contradictory alignment of interests. By moving to a GPU favorable algorithm the miners who do remain will have devices that are still useful when mining on the original Ethereum mainnet becomes moot, because Serenity is fully activated. If all the miners were on ASICs their incentive would be to sabotage such a transition as their hardware would be useless. But with a GPGPU there is still utility in AI, other cryptos, or even gasp video games.
So there is a community commitment to “move the cheese” once Proof-of-Stake becomes viable. If we flinch now updating the Proof-of-Work algorithm because the chosen algorithm isn’t ASIC-proof then there is a reason to doubt if the community will ever be willing to pull the trigger to end the mainnet and let the difficulty bomb fully explode. Remember, we were supposed to already be on a Proof of Stake network by now, the plan has already changed.
6 Likes
FFS I try to post a highly-educated technical review and first get insulted that I don’t even know the basics of floats, and now you think I don’t know who Kristy is or understand that ASIC resistance is a continuum?
We specifically call out the 2x threshold which seems to be a common number used for “resistance” and also say it’s not clear that ProgPoW is an improvement over Ethash (but it’s an honest try.) Really, it could go either way. If you just care about delaying ASIC’s with forks then the PoW doesn’t matter much. Just keep forking to something new every 6 months. If you think ProgPoW will last 12 months then that is purely speculation.
I thought the community would want an expert opinion that didn’t come from the authors. If you’d like to ask for more detail on our assessment I’m happy to oblige, but I have no interest in devolving into a philosophical PoW conversation. I shouldn’t have said anything about my personal view on PoW.
To my knowledge, no one has mentioned or considered a VLIW architecture for ProgPoW before, and it’s a clever approach that will give a nontrivial performance increase, so you’re welcome. I could have sat on this design and made a lot of money selling a ProgPoW ASIC.
I find it strange that no one has yet commented on this VLIW proposal or its implications for ASIC resistance. Instead, you seem most interested in just quoting KLM to me and defending a philosophical position you were already entrenched in… Have you even bothered to add up the gate counts in Linzhi’s design? Hmm? What do you get for your die area calculations?
3 Likes