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.
2 Likes
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.
4 Likes
It would be absolutely, positively, foolhardy to implement ProgPoW without an audit.
Needless risk.
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”.
6 Likes
Summary of the entire problem with EIPs right here.
2 Likes
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.
2 Likes
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.
3 Likes
And that pre-audit decision was never made or not articulated clearly - precisely what I was afraid of!
Cross post from https://gitter.im/ethereum/governance
“I care about rational arguments.”
“Phil Daian’s essay is rather convincing. It would have been more useful before January.”
This seems sort of comical. Sorry to single you out @gcolvin, but here you’re basically admitting to not caring about rational arguments and excusing yourself for making the decision without considering them.
Much rational. Such logic.
As for @mhswende’s arguments (My stance on Progpow):
Community. As far as I’ve seen, most signals point to ‘the community’ wanting to go ahead with progpow.
This is the signaling argument you don’t like, right? Also our discussion over the last week points to more contention than I most ProgPow proponents expected. Most of us didn’t even realize that the ProgPow decision had “been made” back in January.
Known “evils”. If we switch to progpow, we will keep the ‘same’ ecosystem of miners around.
Who cares? The GPU miners will have their issuance reduced in the coming year anyways as PoS starts to provide finality for the PoW chain.
In my view, a hardfork which updates ethash-hashimoto to ethash-progpow will be the simplest fork we have ever done.
If this was really the case, then why is there so much fuss about getting an audit done? Either it’ll be trivial, and we should do it, or it won’t be trivial, and we should definitely do it.
Ethereum has historically been aimed to be ASIC-resistant… to me, this means that the ‘conservative’ route forward is to keep this model. And conversely, if we are to change this model, then the burden of proof for why we should change this model is on the progpow opponents.
Yea, we should allow ASICs temporarily because:
-
We’re well on our way to PoS securing the PoW chain, so the ROI on this change is negative for the community (due to coordination cost), and only positive for GPU miners. The ASICs will lose their relevancy over the next 1-2 years.
-
ASICs do not represent an existential risk at this time, and I don’t understand the fear that ProgPow proponents have of ASIC manufacturers trying to impede PoS. Like, let’s say we start to see more miner centralization, and then they attack the PoS transition by not going along with the fork… who in their right mind would want be on the centralized miner chain instead of the PoS chain, or at least the PoW chain secured by PoS in the meantime?
audits are necessary for every EIP, not just politically contentious ones.
This is a change in the core algorithm (never been done on Ethereum). It seems like a full order of magnitude more risky than the typical EIP change.
2 Likes
That’s the big point of contention I don’t think people understand. In terms of raw technical risk, it is actually fairly small. Most of the implementations have been completed in under a week, and the engineers are fairly confident in them at this point. There is huge execution risk, in that a small mistake could have a major impact. Execution risk is purely short term. If we do a good job, test it, and get it right, that risk does not carry over longer term.
At this point I agree an audit would be a good part of an overall security strategy for this EIP, and a good part of reducing the potential for high impact to the network. The audit proposal, as written today, is extremely broad as far as security audits typically go, including evaluating such claims as “providing better decentralization”. I wouldn’t modify the proposal at this point, but I would say that the majority of the claims to be evaluated have largely been debated and discussed in the community at large and most have been resolved, at least to my knowledge. These claims have very little to do with the software codebase, which is a software security firm’s primary expertise. I expect the debate to continue afterwards, but at least we can all get happy with the code being as well-crafted as possible.
A majority of EIPs affect the core consensus algorithm through EVM execution, which is notoriously difficult to get correct, hence the massive test suite that we have. Many EIPs are way more difficult than this change. We are absolutely underfunding security review across the board for EIPs.
1 Like
So you are barking at me here too.
If you had understood the discussion on ethereum/governance after your selective quoting you would gotten that I learned that I was mistaken about the date of the paper, that I had seen the same arguments in other places, that those arguments weighted some factors differently than I did, and that there were other arguments that I and others considered that Phil did not. In the end, after over 7 months of discussion on public forums I chose to support ProgPow.
Now you come along four months later questioning my rationality and intelligence.
Please, stop trolling me or get out of here. (@jpitts)
1 Like
Alrighty sir, I will stop trolling you and move on to rational arguments.
This is what you said above:
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.
I empathize with the fatigue, I’m feeling it too and I’ve only been doing this for a week.
There are three main reasons why I believe an audit is important:
- Safety - As is the first time we’re updating the hashing algorithm, I think we should take extra precautions to make sure it doesn’t do anything unexpected. I believe this is a fair request. The reason Constantinople was delayed was because an audit caught a bug. Why skip it for this?
As I said above, in response to @mhswende claiming the upgrade would be trivial:
If this was really the case, then why is there so much fuss about getting an audit done? Either it’ll be trivial, and we should do it, or it won’t be trivial, and we should definitely do it.
-
Consensus - From what I can tell, of the people who oppose ProgPow, none of them would be more fine proceeding without an audit. On the other hand, there are many people who support ProgPow that would prefer to have an audit done first. This means the anti-audit camp is a strict subset of the pro-ProgPow camp, and therefore the pro-audit group is by definition the largest group.
-
Legitimacy - When the “decision” was originally made, it mentioned an audit would take place, and that if any risks were discovered, they would be fixed. If you believe in the legitimacy of that decision, in order to be consistent with all of it, not just the part where we move forward with ProgPow, then you should support an audit. I said as much to @Arachnid on twitter yesterday.
https://twitter.com/ameensol/status/1111777587695501312
Also here are some screenshots of the notes from the core devs calls.
All of you mention wanting to do an audit. And now your (@gcolvin) position is:
an audit will good to have, but I can’t see demanding one.
I don’t think this is a coherent position to have.
I’ll repeat what I said in the OP:
I want to add that I still don’t support ProgPow even if the audit comes back clean, but I would much more willing to accept it if it didn’t feel reckless.
It seems that the fatigue over this issue is causing us to abandon the interest in the audit, but I don’t see any external pressure motivating the urgency of this decision.
I maintain that we should not include ProgPow until an audit has been conducted.
3 Likes
The main thing currently preventing an audit is a lack of funding for it. The more ProgPoW is looked into at a technical level the more people there are who are comfortable moving forward without an audit because they feel the scrutiny has been sufficient.
For those wanting an audit the simplest way to get one is to contribute to funding it.
2 Likes
Can you point me to the available reviews by IC designers? I dont think a lot of the core devs sepcialize in this area, and we additionally want to see the the forecast or estimates into the likelihood of ProgPoW specialized hardware developing, that were supposed to be included as part of it.
Additionally, the horse trade for the decision making was that implementation would occur but under the premise that an independent audit would be performed in support of a final go/no go status. This was to be coordinated by the Ethereum Cat Herders, and they have thus far done a good job organizing, but the funding problem has created delays.
I don’t believe we, who were offered the audit in return for support for a decision, should be solely responsible for the funding that audit. I’ve contributed to the Gitcoin raise, however believe my money would have been more useful elsewhere such as ETH 2.0 clients, or FFG development, both of which provide mitigations for the risks associated with ASIC centralization anyway.
As this proposal disproportionately benefits one interest group (GPU miners) and there has been virtually no demonstration of the pressing need for ProgPoW, I believe funding should come from the proponents or the Ethereum Foundation. As it was core devs who proposed the conditional terms of the decision to include such an audit.
This is a change to the underlying PoW algorithm, and tech that many of the proponents lack expertise in, versus many other EIPs which had the luxury of many competent eyes from a large developer base on them (and still eleventh hour bugs were found). Ethereum does not have a similar electrical engineering/IC designer base. An independent audit seems like a prudent course of action to, at the very least, provide the appearance of appropriate due diligence on both the security, and the merit of the change. One of the driving rationales for the change is the commitment to ASIC resistance. One of the objectives of the audit is to demonstrate just that. Whether ProgPoW does in fact fulfill that objective or not. If it is identified in the course of the audit that it does not fulfill that objective, I believe the need for ProgPoW just be reassessed entirely.
2 Likes
I don’t think there was any IC designers, but many people on the implementation team have sufficient hardware design expertise, especially an understanding of GPU internals, where I believe the concern on the mining algorithm side is met.
The client implementations (again separate from the mining algorithm) were implemented and looked over between the client teams, core devs, implementors, etc. I believe an audit is warranted for the client code, as one small bug could cause a large disruption to the network, however I also feel as though there has been sufficient review where this may be considered largely unnecessary. But what’s $50k amongst friends? (Better than all those people missing something small I suppose).
The audit also proposes reviewing the technical credentials of the mining algorithm (the part outside of consensus that generates data for consensus to work). This would be handy, but risk is lower because this can be iterated on out-of-band and released to miners piecewise as they upgrade their rigs. They will not do this all at once therefore a risk of total network disruption is small. The audit may be beneficial to ensure code quality and obvious errors are caught, but that’s probably had a fair amount of review at this point and honestly running on a testnet is better. Run it for at least a month on Ropsten with significant enough mining occuring and that is good enough to understand how it works in practice.
Lastly, the audit will evaluate the claims that the algorithm has in terms of utilizing the whole GPU (minus FP functions and some other non-standard things), it’s suitability to the task, any inherent inefficiencies with particular devices, etc. This work has largely been done (ProgPoW Benchmarked, by a Ethereum Miner!). More benchmarking and the like couldn’t hurt, but data collection from the Ropsten testnet with the final draft software configurations is probably the best measure of fitness here. Perhaps those who already have done significant data collection can provide their findings to the auditors and reduce the scope of work there.
1 Like
EIP-1 should be modified to add a required section where the proposer of the EIP is asked to remark on the possible negative side-effects of his/her proposal. This won’t directly solve much, because of course, this type of analysis is nearly impossible, but it would give the Core Devs a way to easily reject EIPs. The problem with the way things currently work is that the Core Devs are put in a position of having to articulate concerns that the proposer of the EIP has neglected to address. What we want is any easy way for Core Devs to reject a proposal. Requiring a well-thought out defense of the idea in EIP-1 might provide a hook for them to do that.
For example, we could add a section to the section called “What Belongs in an EIP.” We could change the words “Each EIP should have the following parts” to “Each EIP MUST have the following parts” and include “Thorough and convincing exploration of negative impacts of this EIP on the EcoSystem.”
Things to be considered in this section might include ‘effect of the EIP on state size,’ ‘effect of this EIP on network propogation,’ ‘analysis of code complexity (effect on workload of core devs),’ ‘necessity of an audit or arguments in support of why it’s not required.’
We want to force people to do the security/cost analysis of their EIP themselves before they make a proposal, but mostly we need to provide an easy way for Core Devs for reject a proposal. “It’s not complete.”
Unrelated: EIPs should enter ‘Rejected’ state after XXX months/weeks of inactivity or failing to become “Final”.
1 Like
In general, just an assessment of the risks of implementing a proposal, how impactful to the network, etc. Audits are a part of a risk mitigation strategy where their cost may or may not be justified, and which can be mitigated through other activities (testing, peer review, demos, testnet operation). There should be an understanding of the strategy to validate the change before moving forward. Too often it’s an afterthought.
1 Like
I apologize in advance for what I am going to write, as I respect you and your opinions very much.
I might not be as well informed as you are, but seems the move to POS will be done in stages. Even if POS will finalize the chain, we still need mining until full POS.
POS + sharding, which even Vitalik seems to consider there might be a lot of undiscovered issues with, might experience a lot of delays, so that goal of reaching full POS, which personally I wait for a long time now, might be a few years away from us.
If you think everything will go smooth, I will post how ASIC manufacturers and their customers think this should be done from gitter ProgPoW, as it seems I didn’t get an answer from Sonia and also most people maybe didn’t notice it.
So, from their point of view, a decentralized network needs to negotiate with them the transition to POS, to be done “peacefully”.
I am guessing, and extrapolating it using my logic, same ideas/attitude will apply to any future block reward reduction, and/or any other change that will affect their sales and their customers investment and ROI.
While such radical ideas as Sonia’s can remain marginal when ASICs represent a low % of the network, and maybe even divided in the hands of many, the balance of power will change very fast when a few big entities will control most of the mining in ETH. And those entities will try to decide/interfere not only by mining, but rather they will use any mean necessary, as I feel they started to use now reg ProgPoW, to split the community over it.
Wasn’t one of the goals of Ethereum and Ethash to prevent such threats and centralization from the beginning?
As far as I can tell, most people supporting ProgPoW, including myself, have nothing against an audit. I actually feel this step is needed and it will help everybody who has doubts, who cannot spend all his day researching it, who cannot test or understand what this is about, to trust the result of the audit.
But, I do have a problem with how everything has evolved until now, how we had 3 or 4 different grants, (I think two of them for WhiteBlock, which is not even in charge of the audit anymore), how everybody is confused (while actually being on gitter, on twitter, on discord, on github, on reddit, on whatever X is necessary to track the progress of it).
And the last thing that happened, with Eric and Ewan suggesting to trade ProgPoW to miners, against a new issuance reduction for funding Ethereum developement, when the foundation has become even less transparent than before, I am starting to feel that small miners like myself, who mined for POS, who mined on loss during 80 USD, and barely can keep the rigs on now, who spent time testing ProgPoW, who was against the chain split proposed by some trying to push for ProgPoW, who helps run nodes so people can connect to it for free (I do), are not welcomed and nobody cares about us.
I also start to ask myself, big guys like you involved in Ethereum, called stakeholders lately, really any decision taken should satisfy each one of you? Plus the rest of the internet? Even ones that are not related to you at all? Miners really need to take each man out there and explain: why ASICs are bad, why we are on the verge of giving up mining ether, which will lead to centralization probably, why this is a even a threat to you, why the security of a chain is coming from the power consumption to attack it mainly, and not from hashrate.
I am sorry, I feel all those are quite basic knowledge, hell, some of it are even found in ethereum white/yellow paper.
And following the same logic, of satisfying everybody, who is taking our opinion into consideration?
We did twitter polls (cannot even remember how many!), and it was YES, even after GPUShack tried to manipulate it, we did coin voting, and it was YES, even after some big stake holders decided to vote with other people’s funds, we did hash voting, and it’s a YES.
I also see the trend lately to consider mining and miners as being super highly dooper profitable.
Please plug in a rig, or hell, at least please have a look over whattomine.com or any other source like https://www.coingecko.com/en/coins/ethereum/mining_calculator, and let’s discuss how “profitable” it is.
So in the and, again, with all the respect I have for you, and using you to understand why this is needed for other people with no stake in mining or security of ETH chain, why do we have to convince you, considering the just mentioned signals? You have a stake in mining? You have some other concern, leaving out the governance issue which seems to apply to this, but not other EIPs?
Who will take OUR opinion into consideration? Who will satisfy us?
So yes, we find our-self in a dead-end it seems. Same dead-end that might make POS transition harder, under current conditions, and much harder, under Linhzi’s conditions.
1 Like