Ethereum Core Dev Call #54: Waiting for ProgPoW


Ethereum Core Developers regrouped for their 54th public bi-weekly this Friday. If you haven’t tuned into an Ethereum Developer call before, we suggest giving it a go. The calls are a great way to see how decisions are coordinated and made at the core developer level. At the very least, check out the first 5 minutes for some groovy Web3 tunes.

While today’s call discussed roadmaps, Ethereum talks at the Stanford Blockchain Conference, and research updates, the discussion around how to best move forward with ProgPow — a proposed change to the Ethereum hashing algorithm which would narrow the performance gap between generalized and specialized hardware — once again took center stage. For a refresh on the ProgPow debate, see our recent take on the concerns. 


Despite Core Dev consensus, ‘Proposition ProgPow’ faces community concerns

Read More


In short, the discussion around ProgPoW centered on how to best move forward with deciding to implement or not. The indecisiveness continues to persist, as many developers feel inadequately qualified to make an informed decision either way, amidst a backdrop of high noise to low signaling data. Some developers feel more strongly that the decision needs to be made by them, given the purpose of why they meet in the first place – to make core development decisions! Quite the dilemma.

We’ve summarized some of the highlights from today’s call below, a full audio log of the call can be found here.

The path ahead: hire another opinion

The decision comes down to four options: 1) decide not to decide 2) decide one way or the other 3) enable a default ProgPow and push the decision to users, or 4) audit/bring in experts and then make a decision.

Martin Holst Swende, Security Lead of the Ethereum Foundation said he felt that even if core devs gave the green light for ProgPoW, people could still decide to use or not if made as a default option. “Leaving it to some expert group feels like deferring the decision further.” Swende said he’s concerned that they’ve been trying to decide for several months, and they shouldn’t just go to another group to help make the decision for them. He discussed the ability to default the preference to enable ProgPoW onto users, which would allow the devs to forgo making a final decision.

This does, however, come with a catch, as Swende suggested, “a drawback [of pushing decision onto users] is there’s less hash per second with ProgPoW, so the difficulty is expected to go down on the ProgPoW hash… even if there is double the amount of hashpow on progpow work, only then will they reach the same difficulties as non ProgPoW hashing algorithms. This could risk a chain split he added, suggesting “it may be prudent to make [ProgPow] its own hard fork.” Not exactly an optimal situation. 

Some developers proposed the benefits of an audit, suggesting that a neutral third party that specializes in hardware audits could better assess claims and provide data for or against ProgPow, helping to break through the noise on both sides of the debate. 

“[From my perspective] a lot of people against ProgPoW are conspiracy theorists, I believe the audit will help squash fears,” said Hudson Jameson, chairing the discussion.

Others are concerned that an audit can still be contentious, and that it just delays the inevitable decision of whether to implement. Still, a majority of participants felt that the audit would give more confidence in making a decision, provided there are no glaring red flags that surface during the exercise. The group agreed to prioritize the focus and course of action post-audit, in order to stem further indecisiveness when the report comes back with more information. 

Why have developers been so indecisive?

The problem is not enough core developers feel qualified to make a decision either way, leaving some merit to fears that the audit may not come back with the decisive information that some are hoping for.

One participant added color to this point, suggesting, “I don’t know what to do here, expertise [in ASIC/ProgPoW debate] isn’t adequate relative to others… it’s hard to know who to listen to and whose information is right. It’s a decision I’m not excited to make for the network.”

It’s not just lack of expertise that’s causing the hesitation, as the same developer suggested that the public forum of their calls may be prohibitive for contentious decisions like ProgPoW, saying the calls are “not entirely a safe place to try out new ideas or opinions…[it] might not be a popular opinion, but if we are going to have some meeting [on the ProgPoW decision] down the road it should happen behind closed doors and then we discuss what happened during the meeting in public.”

Others were quick to dismiss, suggesting “contentious jury trials happen in public, we need to make the final decision here in public.”

Ironically missing from the conversation are the community participants that stand to benefit the most from the switch to ProgPoW: miners. To that end, the developers have decided to implement miner signaling as a way to garner feedback from ETH miners, mirroring a similar mechanism used in Bitcoin to poll miners on the intent to support upcoming changes to the protocol. The decision to implement signaling for ETH miners was initially shot down on the call as pointless and “gameable,” however was walked back fairly easily as a net positive to have more signals. 

Delaying the inevitable?

While the discussion on ProgPoW concluded by settling on moving forward with the audit, assuming it receives funding, the timeline for completion remains clouded. Some suggested the audit could take months, with the earliest soft guess pointing to April. To streamline the process, the developers plan to continue to test and implement ProgPoW in parallel to the audit. Should the report come back with no red flags, the decision should then become easier to make.

Still, not every participant was excited for the unknown, with Swende pointing out, “we’ve been trying to make a decision for several months, we can’t just push it to another group to make it for us.” Another developer added, “It gets resolved by making a fucking decision, we can just MAKE IT, it’s our job.” 

Needless to say, we didn’t leave the call confident in seeing a decision on ProgPoW anytime soon.

The post Ethereum Core Dev Call #54: Waiting for ProgPoW appeared first on The Block.

Ethereum Core Dev Call #54: Waiting for ProgPoW written by Ryan Todd @ February 1, 2019 Ryan Todd

Comments are closed.