Work done already: NONE ! If funds not enough no one will move a finger.
The audit goals are extremely broad, and probably led to a very high cost to obtain the audit. Nonetheless, there should be enough of the discussion captured in this forum and elsewhere to construct a majority of this report as it stands right now.
Also, I meant in term of the test suite available. Ethereum has a very large and comprehensive test suite, so it shouldn’t be difficult to verify the updates with the client code. The work that would remain would be in verifying the miner code.
There are several implementations of that.
MH Swende’s work into geth
Andreas Silva’s work into parity
Pawel Bylica’s work on ethash library (used both in ethminer and aleth)
There was also a fully functional miner supporting both ethash and progpow (with kernels for both CUDA and OpenCL/AMD) by me but I removed the work.
Fully in support of needing a (well-defined and scoped) audit before moving forward with ProgPoW
And included in that audit we should look into the ASIC-resistance claims of ProgPoW and see if they actually stand up to scrutiny. See recent detailed write-up by Linzhi:
I guess most of us would like to avoid to trade our ship’s diesel engine for that experimental new different technology diesel engine or maybe even warp drive w/o having a clear understanding of the risks associated with that.
This change might have a broad effect in multiple dimensions and various groups have various incentives to either oppose or favour it. That’s to some extend also the problem and should be carried to a different battlefield (“political discussion”). I see people criticising every aspect of the ProgPoW discussion(s) for various reasons and hidden agendas, even the scoping gets its fair share of critics but unfortunately only the minority appears to be contributing or even working on an objective solution, still everyone would like to have one.
If it is likely that ProgPoW happens for whatever reason that might be we should make sure to fully understand the risks, be prepared and treat them appropriately (this includes potentially agreeing on accepting risks if the community wishes to do so - given it permits others to reduce their own risk e.g. by withdrawing their stake from the system). Accepting risks w/o knowing them feels like a bold move - not sure if that would be seen as a trust building exercise. Not doing security due diligence is negligent as summarized by @tvanepps:
Funding: The problem with peer-to-peer relationships appears to be that responsibility (e.g. in preserving the future of the ethereum ecosystem) is distributed across so many people that in the end nobody feels responsible - most people waiting for the others to make a move. It is even kicking off “why should I/groupX fund this” discussion ignoring the fact that we are in this all together. I wonder if this will work out in the end.
Since we’re already discussing security here I’d like to remind people that @boris set up a security discussion slot at the Istanbul & ETH1x Roadmap Planning Meeting - April 17th & 18th in Berlin. Participate, criticise AND contribute/discuss potential solutions.
We have been making risky changes to the client for years now without third-party audits. progPoW has been in the open and under review by experts for almost 11 months now, and experts are still reviewing it. So an audit will good to have, but I can’t see demanding one.
ASIC resistance claims analysis is part of the audit proposal: https://github.com/ethereum-cat-herders/progpow-audit/blob/master/Least%20Authority%20-%20ProgPow%20Algorithm%20Audit%20Proposal%20(v2).pdf
I’d kindly like you to list all the risky changes, along with some evaluation (chance of exploitability / impact if exploited) that have been merged in the clients over the last 12 months (or more if you like). Chance of exploitation is a “?” in progpow, and impact if exploited is beyond imagination.
Copying this here for reference in the hopes that it makes the discussion a bit less fragmented. ProgPow discussed on the AllCoreDevs Gitter: https://gitter.im/ethereum/AllCoreDevs?at=5c9e6a374de4296efc201237
Ideally, let’s keep the discussion here, but I wanted to share the parallel one that happened.
Exactly. If an audit is needed for all “critical” EIPs across the board, we should explore how to ensure that happens, what “critical” means, and how to fund it on a regular basis.
Just take a look at the hard fork meta EIPs. Most of the changes affect the VM, and so have much higher risk than a change to the PoW algorithm.
Also, please define what “exploit” means.
Here’s a few:
- Algorithm totally breaks.
- Algorithm disrupts the network.
- Algorithm has a hole that allows certain miners to exploit for financial gain.
The Mitigation for all 3 of these is that we just fork back the old code, which is the same as any other EIP. This is hopefully caught beforehand by extensive testing. If it’s not, this is our mitigation.
Yes, it incurs huge overhead costs, but so did Constantinople, and with the intense amount of eyes on this particular proposal, I expect it to have less show-stopping bugs than most other proposals in recent history (otherwise those against would’ve found something by now). If you disagree, look through the proposal and find some bugs. If you don’t feel comfortable doing that, you contribute money to the audit and we get some professionals to do that for us.
Security isn’t magic. It’s hard work. It requires money. This EIP is no different than the others in having problems with funding or security review. If it’s a showstopper for this EIP, I propose all progress on Istanbul EIPs should be stopped until we figure out a way to make sure all get the level of attention and expert review that this one is getting.
Most of the issues surrounding ProgPoW have been entirely political in nature. Based on our (Whiteblock) preliminary evaluation of ProgPoW, I think that basic benchmarking would likely be fairly useless. Most of the code I reviewed in ProgPoW appeared to be harmless at face value, but one thing I saw that really concerned me (not sure if this has been changed since or not) is how it handles randomization. If anything, this should be thoroughly vetted and highly scrutinized. Frankly, I’m surprised no one has brought this up yet (to my knowledge). I’ve kept out of these discussions as much as possible because I don’t want to get involved in a political war, so I’ll just leave it at that.
It would be absolutely, positively, foolhardy to implement ProgPoW without an audit.
Let’s not do it.
Well, this is my biggest worry - that this change can dominate the next upgrade (or two, if it does not end up going to the first one, or three) for all the wrong reasons. Not because it is urgent, or something is broken, but because someone wanted it and someone else said “Yeah, OK, why not”.
Summary of the entire problem with EIPs right here.
Will you fund security reviews for all EIPs?
They all affect the operation of the network just as much as this one does. Why does this proposal need special treatment? We have the same mitigations in place (forking back to the original) available to us as we do for any other mistakes that get made!
I definitely think an audit is necessary, but I also think audits are necessary for every EIP, not just politically contentious ones.
I also believe ProgPoW should not be included in a fork until an indepdentent audit is completed.
The premise of my argument against ProgPoW is irrelevant here. If the community shows support for ProgPoW I will also support it, after a proper independent audit is completed.
This isnt a trivial change and certainly many changes in the past have not been as well. However, previous changes and many current EIPs are well within the realm of expertise of the core developers. ProgPoW is not. From listening to the Core Devs calls since #38 when ProgPoW was introduced for consideration, it is clear that there is a knowledge gap amongst core devs in fully understanding ProgPoW, I believes this makes them more susceptible to proponents with the requisite knowledge. An independent audit with a report in a level of detail most can understand will go a long way in determining the efficacy and benefite, as well as the shortcomings of the algo.
I firmly support @lrettig’s statement in Core Devs #54 (https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2054.md) in which he supported a pre-audit decision, but relying on the results of the audit for a final go / no go status.
And that pre-audit decision was never made or not articulated clearly - precisely what I was afraid of!