I was kind of surprised that a hardware audit was also required. As long as the client implementation is secure won’t the network be secure? Miners are used to making miner software, they will iterate and are also invested in the security of their own software.
So why simply not disclose ?
Any reason like :
- They don’t have time
- They don’t understand what to do
- They consider themselves not competent
- They asked for more money
- Whatever …
I’m not speculating but I’m fed up with governance’s lack of clarity
4 Likes
The intent of the “hardware audit” was more to assess the claims by the creators of the algorithm that ProgPoW makes more complete use of GPU hardware than Ethash does. There are a lot of technical claims made, which sound reasonable, but I think opponents wanted an independent assessment of them. We arguably don’t need to pay auditors to do this, anyone with the requisite experience can do this sort of assessment. The problem is finding someone with the requisite experience. Most people in our community don’t have the deep hardware design experience to do this, so we have to rely on the claims of overall chip usage by the designers.
Absolutely, from a software perspective this audit will show that the implementation of the algorithm is secure enough for a public deployment. Mining software can be iterated on, and the overall mining software ecosystem will be heterogeneous enough to protect against catastrophic failure. However, assessing the claims made by the algorithm designers I think is more what people wanted to know about, and this audit will only partially provide that without hardware experts.
Sorry for potentially over reading this. I feel you on lack of transparency. I don’t know where the information disconnect is so hard to know where the the lack of transparency lies.
Thanks for clarifying. Kind of funny to me that progpow is possibly
- the most scrutinized mining algorithm in the space. I certainly don’t know of another that will receive audits
- The furthest EIP, as far as progress, on the list considered for Istanbul
And also the most likely to be kicked from Istanbul
I know there are commitments that have been made, and respect Hudson’s efforts in keeping them. It still makes me chuckle a little bit.
edit: added a diagram
2 Likes
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