Skeptical about #ProgPoW? I am too!

Note, everything here is representative of my employer because I only employ myself presently, but besides that I don’t have any horse in this race because I don’t personally do any mining and have no connections to hardware manufacturers. Although, I am looking for a new graphics card soon, so I guess an abundance of cheap, used graphics cards is a mild incentive for me to oppose it.

Like many in the community, I’ve been listening in to the debate behind Programmatic Proof-of-Work (ProgPoW) with interest in how it will resolve. As a smart contract developer and member of the security community, I don’t necessarily have the hardware expertise to understand many of the arguments being made in favor of the approach, but I have an intense interest in ensuring that the Ethereum network remains a stable and secure for the applications it hosts (including my own). So let’s dive into it a little!

What The Heck is ProgPoW?

First, a little about the algorithm at a high level. The idea is simple: programmatically reconfigure the Proof-of-Work algorithm at a regular interval (every 50 blocks) in such a way as to make the development of an ASIC (application-specific integrated circuit) that has significant enough performance to justify it’s cost impractical. The reconfiguration happens in such a way that the algorithm ends up utilizing nearly all the hardware available in the GPU, to ensure you get minimal gain by trying to optimize out specific hardware modules. This doesn’t mean such devices are impossible to produce, only that they are impractical enough that they are much less cost-effective for the performance they offer over our miner of choice: the GPU.

Ethereum has preferred the GPU mining community since the beginning of the project since the project released it’s main network. The theory is that GPUs are way easier to purchase than ASIC devices, so acquiring them is easy and therefore wider community participation is practical. This ultimately encourages newcomers to interact with the protocol; for example, my first interaction with Ethereum was mining (and figuring out how much I did not want to do that!).

The Ethash algorithm was designed to be “ASIC resistant” in the same way that ProgPoW is, but after a few years of the algorithm being available open source ASIC miners are finally starting to come out. This is a crisis! We are ASIC resistant no more!

Why be ASIC Resistant?

So at the outset, being “ASIC resistant” sounds like a good thing: prevent manufacturers and other special interests from controlling the security of the chain. The theory is, if they had control over the chain they could do “bad things” to control the chain and limit the overall community from doing what they want. And as we of course all know: centralized entities are bad!

That theory is not wrong. The entrenchment of interests in the mining community is a source of economic risk and a huge political distraction in some cases, and may lead to an overall instability in the chain’s future. That’s certainly a bad thing. Therefore ASIC resistance represents the last bastion of hope against the involvement of powerful centralized entities, allowing small, independent “mom and pop” mining operations (collections of tens to hundreds of GPUs) to secure the chain through their collective “co-opetition”. Miners are valuable members of the ecosystem, and as a community we should support efforts that maintain fair competition and diversity in the provision of mining devices available for purchase in order to keep our chain free of such special interests.

Falling Hashrates (

But what is the long-term trend? Alexey Akhunov has an interesting article summarizing his thoughts and opinions on the wider trend of “ASIC resistance”. He brings up some very valid points on the overall market trends in the mining ecosystem. 2017–2018 mining markets were hot, and bringing more value into the ecosystem in the future will only reinforce the existing asymmetries that exist between the independent miner and the entrenched interests of hardware manufacturers and larger mining operations.

This sounds dire, but a big part of the Ethereum experiment with moving to Proof of Stake is trying to design a fundamentally different approach to securing the chain where these economies of scale are themselves made impractical. If the overall goal is to make a consensus mechanism that is as egalitarian as possible, then Proof of Stake is our Hail Mary pass. This is a complicated topic though, and many doubt that that PoS even works at the large scale. I say it mostly remains to be seen how the experiment plays out.

But, that’s definitely beyond the scope of this post!

We’re Stuck With PoW, Can We Make It Better?

At least until the first cross-client testnet for Ethereum 2.0 “Proof of Stake edition” appears, and we can start validating PoS at the scale and value that Ethereum currently operates at, Proof of Work is the best mechanism we know of to secure a high-value chain. We should seek to make that security as strong as possible, and as resistant as possible to the sort of entrenched interests and political power that ASICs bring. Is ProgPoW good for this?

I believe ProgPoW is technically sound in theory, and an excellent candidate for an “ASIC resistant” hashing algorithm.

A preliminary analysis shows that a potential ASIC developed for ProgPoW would be at most 1.5x as efficient relative to a GPU, which would be an improvement over the 4x possible efficiency gains that would be provided by a similar ASIC with the current algorithm. This brings things much more within the realm of reason, as the cost of owning and operating an ASIC hinges directly on their efficiency. This sort of efficiency loss should prevent an economically viable ASIC for ProgPoW for at least 1–1.5 years, which should be long enough for ETH 2.0 to reach viability (or at the very least, allow Hybrid PoW/PoS mechanisms to be implemented). You can read more about some of the benchmarks here.

It isn’t quite possible to gather more data about the algorithm and how it works in practice without experimenting further in a fork of the core client software, so we should conduct more of these experiments to understand what the pros and cons are of the algorithm, and show that it is strictly better for the security of the network than what we currently have (by enough of a margin).

In terms of “strictly better for security”, here are some of my questions:

  1. What is the current ASIC hashrate estimate? (yes, this is a hard but absolutely critical metric to gather)
  2. Is there any ASIC on the market that can be easily adapted to the new algorithm? How do we know this for sure?
  3. How do we validate the estimates for expected ASIC efficiency over GPUs when one is finally developed? (Hopefully 1–1.5 years from now)
  4. Has a hardware design expert given a detailed analysis of the steps required to create a competitive ASIC miner?
  5. How stable will the algorithm be with relevant metrics? (e.g. Block Time, Uncle Counts, Difficulty Adjustment) How does the 50 block algorithm re-adjustment affect these critical metrics?

Another interesting side-note is that some of these questions could potentially be compared/contrasted with Bitcoin Interest, a Bitcoin fork that has already implemented a different version of the ProgPoW algorithm. I’d love to see what we can learn by observing other chains.

Who Wants It Anyways?

According to recent Twitter polls, everyone wants ProgPoW and we should implement it immediately. While I’m an extreme skeptic of the quality of signal in Twitter/Reddit polls and even coin votes, one vote shines above the rest (in my opinion): the miners themselves.

Miner voting statistics (as of 3/20/19)

While this chart is a little misleading (for example, 77.2% voter turnout means that 23.8% failed to vote, or “don’t care”). 100% of the miners that secured our network in the past 24 hours (at least the ones that published blocks) signaled that we should move forward with ProgPoW. This is the right signal to watch, because this party of miners are exactly the ones impacted by the proposal. It is a little interesting that this metric is 100% of all miners that voted. Perhaps those miners that own ASICs abstained from voting? Can we assume that an ASIC miner would vote no for this proposal? Unsure.

A good number of the mining community have already done testing with the new algorithm. There are some side-effects to this upgrade, namely that the hashrate of ProgPoW will change drastically, so the difficulty will need to adjust over a period of 3ish hours or so until it stabilizes. That will need to be explored and tested on the Ropsten PoW test network first so we have a full picture of the short-term effects of the switch when introduced to the production network. This is one aspect of the costs of upgrading our core consensus algorithm.

Isn’t This All A Huge Distraction?

Probably the best criticism of ProgPoW is that it’s all a distraction from the very significant effort being spent on the Eth 1.x and Eth 2.0 roadmaps. I think it’s hard to argue against this. It doesn’t mean it’s not worth it. But is it more worth it than the rest of the roadmap? How much more? Those are bigger question every stakeholder will have to answer for themselves.

It will certainly involve a fair amount of resources developing, testing, organizing the fork, and responding to any failure conditions. Taking on such a task should not be taken lightly.

Okay, So What’s Next?

So, while not a “Silver Bullet” for all our problems, in my opinion it does seem to offer enough of a benefit to advocate moving forward with it.

Cool. Now what?

Well, one thing to understand is that only the mining software has been tested well so far. This is good enough to show the algorithm works and starting to benchmark and tune it to prevent favoring any one GPU type/manufacturer over another too heavily. However, there also needs to be cross-client testing of the update, so a fork date needs to be scheduled for Ropsten, which is the only test network that uses PoW mining and thus the only way to truly show the upgrade works. If that proves successful, it can be followed with a potential mainnnet fork block proposal and time to prepare exchanges, miners, and other community members of the large change to the consensus algorithm. I would definitely advocate for this to be a separate fork.

Here’s my checklist for what to do next:

  1. PRs with adequate testing for the Parity (started here), Geth (started here), Trinity (not started) and Pantheon (developers have started) clients
  2. Test all Client PRs together on the ProgPoW testnet chain
  3. Merge PRs for Parity/Geth clients and propose fork block for Ropsten
  4. Mine Ropsten with enough hashpower to validate the change (maybe incentivize the testnet mining?)
  5. Data analysis report of Ropsten upgrade and cross-client tests
  6. Decide on timeframe of mainnet upgrade and propose fork block
  7. Prepare for the fork!

Unfortunately, this will not be easy. Or cheap.

As ProgPoW is not currently planned in the Eth 1.x roadmap, this would have to be added in addition to all the other significant work that is planned for the medium-term. Client developers and ProgPoW developers could use your support (in both Ether and your time) to do the work required to highly vet this upgrade as it is extremely critical to the security of the protocol that it goes correctly on the first shot.

There have been estimates of the costs involved. A showing from the mining community that they are willing to help pay for a portion of the upgrade costs is the ultimate signal in my opinion that the short-term pain is worth the long-term gains! There is a Gitcoin Grants to form a working group fund to continue this work here. I would encourage those who advocate for ProgPoW to solicit donations to help pay for further due diligence and testing.

Help pay your volunteers!


I still have some larger macro-level questions about the effects of this proposal that I listed above, but I am now convinced that enough technical due diligence was done to move forward with wider testing and preparation for a hard fork. Thank you to several community members working on ProgPoW for sharing recent research/analysis with me so that I could learn more about what’s been done and what is left to do.

If you have other concerns, or disagree with my opinions that I’ve presented here, let’s talk about it on the EthMagicians forum.