Ethereum Governance, me and ProgPoW

Since the very moment I got in touch with the proof-of-concept of ProgPoW (late Aug 2018) I immediately fell in love with it: in a world of crypto-mining where the vast majority of hashing functions is made on top of constant patterns and cycles (which made possible the blooming of various ASIC miners), ProgPoW appeared to me as a brilliant, and at the same time simple, way to take full advantage of GPUs (which are commodity general purpose ASICs) for the mining service of Ethereum.

I won’t spend many words about what ProgPoW is : you can read here if you want to learn more.

This time I’d like to focus on what I’ve witnessed during the long (and not completed yet) decision-making process which may (or may not) lead to the adoption of ProgPoW on main Ethereum network.

My initial involvement

I voluntarily joined the ethminer’s development team in early 2018. I found the project almost abandoned with tons of unresolved issues in the Github repository and very few sporadic commits addressed only to solve critical usage problems (i.e. miner would not start). To my knowledge ethminer project was (and is actually) coordinated by Pawel Bylica who is one of the Core Developers specifically in charge to maintain Aleth client.

At that time the undisputed king of mining softwares for Ethereum was Claymore’s (a closed source with dev-fee solution) which significantly outperformed ethminer. I immediately thought it was strange Ethereum’s stack was not directly maintaining an efficient miner for its own network. Instead they were delegating to a closed source solution, provided by an anonymous third party, the duty to provide an efficient tool for the security of the whole network. A highly remunerative delegation though : a screening of the eth accounts used by Claymore software to collect the fee revealed incomes in the range of roughly 120 eth per day (if not more). Simple math 120 * 130$ * 365 = 5.694 Millions USD per year (at bear market price).

In addition to that the quality of code expressed by ethminer was well under the standards generally endorsed in any ethereum-releated project I got in touch with. I questioned Pawel about the causes of this poor maintenance of the project and I got as response a laconic “You know … developers come and go”.

I was surprised by that: with all evidence there was no incentive for quality developers to focus on the project nor for the coordinator to mantain a quality vision of the whole stack and lead developers in their steps.

I then decided to roll-up my sleeves and began a long refactor phase during the whole 2018 being supported by a handful of valuable colleagues. I also spent myself giving all support I could to end users and sorting out hundreds of issues. At the moment I began to work on ProgPoW the github unresolved issues for ethminer were reduced from almost 300 to less than 20. My incentive ? I was (and still am) a user of ethminer and wanted to make it better for my needs in first instance and for others too.

Meet ProgPoW

In late Aug 2018 Pawel announced on gitter’s ethminer developer channel there was the opportunity to implement a new algorithm named ProgPoW on top of ethminer on behalf of EIP-1057. As a consequence of the technicalities embedded in ProgPoW (which require to know the exact number of the block the miner is working on) an additional project to create a new stratum standard was needed: this latter lead to EIP-1571 from my original work here.

In October 2018, lead by Pawel, our very small team (only three from ethminer’s development team decided to join the initiative) we filed for a Grant Application to the Ethereum Foundation to expedite our development while the voices calling for ProgPoW implementation were swelling.

From that moment on despite a total lack of responses by the EF I continued to work on ProgPoW implementation into ethminer.

January 2019: tentative green light for ProgPoW by Core Devs

In the call by All Core Devs on January 4th, 2019, which I attended to, it was given ProgPoW a “tentative green light” in the terms of, quote, “let’s go ahead if no major technical flaws emerge”.

This to me sounded like an encouragment to continue development and research on ProgPoW implementation (otherwise how you can possibly find technical flaws?). At that moment a testnet (Gangnam) supported by two major clients (go-ethereum and parity) was running and we were testing with a couple of miners (original implementation from IfDefElse team and mine which was the only to support both ethash and progpow) mining algo and epoch transitions.

A lot of volunteers were joining giving support for what they could: testing various GPUs and providing feed-back on performances and issues on the miners.

Yet I had no answer from the EF about the status of the grant despite the fact several solicitation emails were sent. Mind my words : I was not begging for an acceptance. I was simply asking for a clear statement whether or not the grant would have been paid or not. In either cases I had the right to be put in a situation where I could adivisedly decide what to do with my time and resources.

The Linzhi affaire

I believe a day or two after the afore mentioned call a tweet by Alexey Akhunov collects the invitation by an unknown (till then) ASIC manufacturer to be open and collaborative with the ASIC world. That was the beginning of the stall we’re experiencing right now.

Linzhi (which I personally never heard of before) began a very extensive campaign against ProgPoW (which from their perspective makes sense as ProgPoW would brick all their ongoing investiments for ASICs on the ethereum network) pulling various levers: the conspirancy theory, the anoniminity of the IfDefElse team, the involvment in ProgPoW by Nvidia and or AMD etc. while, at the same time, making statements about the possibility of an ASIC capable to implement ProgPoW with very high efficiency.
Obviously none of their statements was endorsed by any proof-of-concept, sketch design or whatever.

Two facts must be underlined : none of the major ASIC manufacturers (Bitmain, Innosilicon) has officially made any statement about ProgPoW implementation on ethereum and if really Linzhi had the opportunity to build an ASIC implementing ProgPoW more efficiently than a GPU then they had any advantage in keeping their mouth shut.

Nevertheless this was enough to push the Core Devs team into panic to the point that, in subsequent calls, they decided they “have not the technical skills needed to make a decision about the change of the algo”.

The CatHerders team and the Audit

Despite the consensus over the ProgPoW matter had already been established in early January, discussion continues among the core devs with very peculiar positions: the most noticeable is the one from Alexey Akhunov who states his silence or his abstention over the ProgPoW matter does not imply an acceptance. Which translates to me “I don’t say no but please note I’m not in favor”. If such positions are considered valuable a consensus would never be reached.

To try solve the empasse Core Devs have decided to establish a new team named the CatHerders (a selected group of project managers) which, as first task, has to try determine the pros and cons of ProgPoW implementation and try to address many (if not all) of the concerns raised by Linzhi and by some (harsh) adversaries of the proposal.

To achieve this goals it’s been decided to issue an audit over ProgPoW as algo and as implementation to determine if there are (or not) any technical flaws in the algo, if the algo does favor one GPU manufacturer or another (AMD/Nvidia), and eventually which could be the potential gain of a future ASIC capable to run ProgPoW.

Obviously enough the last question can’t have any answer unless someone tries to sketch the design of such a machine: work which can be carried out only by an ASIC manufacturer.

The funding

In early February 2019, after many solicitations, I got a call from the EF basically stating “We have not decided, nor we can decide right now, whether or not to fund your project. If we do this would be an endorsment of the ProgPoW solution which has not been fully accepted by the Core Devs.” I then asked if I had to consider expired the grant option but they replied “No, cause if things change we will recall you and ask to continue development”.

Meanwhile CatHerders and Core Devs are trying to raise funds to pay the auditors which will have to carry out analysis on behalf of incomplete and underperforming implementations. In fact I withdrawn all my public open-sourced code about ProgPoW implementation cause I dont’ want to make life for closed source developers easier and eventually I may decide to play the same rules embedding a dev-fee.

The Paradox

Ethereum’s governance is showing themselves very weak in deciding (with a yes or a no) on such an important matter. But above all if ProgPoW will get accepted Ethereum won’t provide an “official” open-source miner for their PoW chain.

Andrea Lanfranchi
ethminer ProgPoW developer