A notable voice is joining the ranks of ethereum developers who are seeking to block powerful ASIC miners from earning an outsized share of the platform’s valuable ether cryptocurrency.
In an developer meeting Friday, Martin Holst Swende, security lead at the Ethereum Foundation, said he supports swift action to remove ASIC mining hardware from the ethereum platform. Joining the non-profit in 2016, Swende now works to ensure code changes do not disrupt or harm operations on the world’s second-largest blockchain.
With the remarks, Swende is aligning with other leading technologists who work on the platform’s core code and who think developers should introduce code to block the chips. First introduced on ethereum back in April, dissenting developers argue the chips may reduce the number of participants able to profitably maintain the network’s ledger.
In the meeting, Swende remarked that a software change, dubbed ProgPoW, should be implemented “in parallel” with a larger, upcoming upgrade, “if the technical underpinnings are there.”
As detailed by CoinDesk, the software change would render current ethereum ASICs unusable, and potentially prevent the development of such hardware going forward.
“I think it’s a very good change and am for including it as soon as possible.”
Swende also noted after the meeting in email to CoinDesk that unlike other proposals for software upgrades on ethereum that affect the heart of smart contract deployment on the platform called the ethereum virtual machine (EVM), ProgPow would “not touch the EVM or state transition at all.”
As such, Swende noted that testing for the proposal could be implemented on “a totally separate testbed” in parallel to the normal testing process currently at a bottleneck due to preparation for ethereum’s upcoming hard fork or system-wide upgrade.
The upgrade also known as Constantinople has been in the works for months, with developers convening and reconvening on the priority issues of ethereum needing to be addressed.
As of today’s meeting, the upgrade is due to activate on ethereum testnet Ropsten on October 9, estimated to be block 4.2 million.
Speaking on a forum prior to today’s meeting, Swende proposed the software change to be implemented in a “separate hard fork which is decoupled from Constantinople.”
“If we eventually decide to set both [upgrades] to the same [block] number, then fine, but that’s not a necessity,” the developer wrote.
Developers also said that a cost optimization upgrade geared towards reducing the cost of privacy on ethereum authored by Antonio Salazar Cardozo could be implemented in a subsequent hard fork along with the ProgPoW software shift.
Still, speaking in the meeting, core developers Pawel Bylica and Alexey Akhunov said the proposal needs further work to explain “why exactly,” as Akhunov puts, it can achieve its claims.
In response, representatives from ProgPow in attendance on today’s call cited “misinformation about hardware and how ProgPow actually works.”
Responding to the confusion, ProgPow co-creator “Def” emphasized that a “deep dive” could be done to better corroborate the aims of the proposal.
In essence, however, Def highlighted that:
“The algorithm’s goal is not not exactly to be ASIC-resistant.”
This is because, in one sense, all general processing units if utilized for the express purpose of mining can be thought of as an ASIC machine being effectively operated to mine ether, the main form of currency on the ethereum blockchain.
As a result, Def posits that the design of ProgPow is not to be ASIC resistant but rather “to be friendly or very much tied to a single type of ASIC, which is a GPU,” and these having the advantages of being lower cost for miners in the ethereum community to acquire.
Def’s counterpart, Kristy-Leigh Minehan who was also present on the call acknowledged that “as creators of the algorithm,” misinformation being spread was their duty to prevent and moving forward would ensure “we’re educating the entirety of the community and the development team on how [ProgPow] works.”
Minehan also emphasized on the other hand that the importance of continued developer support progressing ProgPow implementation was crucial, noting that it wasn’t worth “wasting the man hours or the money” from their side for “a project that would most likely be ignored.”