This post summarizes an as-of-yet unwritten EIP for a compromise on ProgPoW. It has been created solely by myself, Ben DiFrancesco, without the input or suggestion of any other persons or entities. The intent of this post is to share the idea, collect said input, and gauge community interest. Should such interest materialize, a formal EIP would be created.
A Note On Compromises
By definition, a compromise entails an agreement where neither side is fully satisfied with the result. That means— if you have a strong opinion on ProgPoW— you won’t be happy with this proposal. That doesn’t mean it’s not a workable path forward for the community, so please don’t dismiss it outright.
As succintly and fairly as possible, I aim to present the motivations of each group below.
- Ethereum should strive for ASIC resistance because it’s part of the social contract as defined in the Yellow Paper.
- Specialized hardware is inherently centralizing. It places the network at risk of being 51% attacked by secret ASIC’s, and/or disrupted intentionally while attempting to transition to PoS in ETH 2.0 by miners with mis-aligned incentives.
All consensus breaking upgrades are inherently risky, none more so than a change to the PoW mining algorithm. Thusly, the burden of justification lies with those proposing a change, and the threshold of such justification is very high. Based on the current state of the network, and on the unsettled state of the research related to ASICs and security, the Pro-ProgPoW arguments fall well short of the necessary threshold.
This proposal aims to balance the security concerns of the PPP group with the risk aversion of the PSQ group. The security concerns of the PPP group are (to date) theoretical, but if we wait until attacks are observed to take action, it may be too late to avoid serious harm to the network. Conversely, if the PPP group’s concerns never actually materialize, then we risk serious harm to the network by implementing an unwarranted change.
The proposal does not aim to resolve the PPP group’s belief that ASIC resistance is an immutable part of Ethereum’s social contract (labeled #1 in the PPP Motivation section). Ultimately, this contention is a value judgement, one that each individual must evaluate for themselves.
- ProgPoW should be fully implemented and tested across all major clients.
- ProgPoW should not be included as part of any planned or future upgrade hardfork.
- All clients should include a command line switch which enables ProgPoW at a block height specified by the node’s operator.
- A ProgPoW enabled hardfork of the Ropsten testnet should be created and maintained using this switch. (Up for debate: should this fork be a new, parallel testnet, or should it simply replace Ropsten).
- A strong Schelling point should be encouraged in the Ethereum community: if clear evidence of an ASIC-lead attack on the network is ever demonstrated, Ethereum stakeholders will coordinate to activate an emergency ProgPoW hardfork, at an agreed upon block height, using the switch.
Both the PPP group and the PSQ group share a desire for Ethereum to remain secure and decentralized, and to successfully transition to Ethereum 2.0. By fully implementing, testing, and maintaining compatibility with ProgPoW— and standing ready to activate it in the case of an emergency— we can coalesce on a solution that focuses on these common goals.
The existence of a fully implemented, tested, and easily enabled ProgPoW would serve as a sword of Damocles hanging over the heads of any would-be malicious miners. If they’re altruistic, it does them no harm. If they’re inclined to attack or to thwart Ethereum 2.0, it changes the incentive structure of any such attempt. Put simply, it acts as a deterrent