pls donate eth to help keep this running! 0xA91E63C9d57Df30970b4900A4965a389936680bC

ASIC Resistant Hard Fork Discussion Overview

I am speaking on behalf of myself, Hudson Jameson, and not on behalf of the Ethereum Foundation or any other entity. However, I am a lawyer/doctor and this post is both medical and legal advice. Just kidding, it isn't.

Hey all!

I've been closely following the debate that has been happening across social media and chat channels the past 2 weeks regarding the possibility of designing and implementing a new ASIC resistant proof-of-work algorithm. The debate is over whether or not we should hard fork the Ethereum network in order to prevent ASIC miners from operating. I am in the unique position of organizing and running the bi-weekly core developer meetings and have been active in the ecosystem for a while. I want to make sure both sides feel like they are heard. This post is meant to provide context and offer next steps for both sides of the argument.

Facts

About 2 weeks an EIP was created by Piper Merriam called "EIP 958: Modify block mining to be ASIC resistant.". Piper opened the EIP intending for it to be a starting point for both technical and non-technical discussion about ASIC resistant algorithm changes. His role in the EIP is to act as a neutral facilitator and not as an expert. The EIP is now closed at the request of the author. Discussion has continued in other forums such as Reddit.

About a week ago, AirSquirrels created "EIP 969: Early ASIC Mitigation Hardfork.". This EIP is focused on technical discussion around an ASIC resistant hard fork. It has been merged in the EIP respository in Draft status in accordance with EIP 1. This does not indicate that the EIP is agreed upon or accepted, but that it meets the minimum technical requirements based on the EIP X template to be merged as a file into the repository.

veox has been working on cleaning up EIP 969 from a grammatical and technical standpoint. The status of that EIP PR can be found here.

PAR 1: It is a security risk that ASICs are allowed to exist on the Ethereum network. With one entity having a majority of the hashing power, 51% attacks are a real possibility.

PAR 2: The Ethereum White Paper declared that Ethereum was built to be "ASIC resistant", at least from the perspective of being resistant to economic incentives to produce ASICs. If this wasn't a false narrative it needs to be upheld.

PAR 3: Bitmain being allowed to mine using ASICs on the network would cause increased centralization in Ethereum.

PAR 4: Bitmain may have a better ASIC that they have not revealed that they are using to mine the network currently. This amplifies the other risks and eliminates some of the uncertainties around how much of an improvement Ethash ASICs are compared to GPU mining if true.

PAR 5: Bitmain has been proven to be hostile to cryptocurrency groups. This can be shown by their hostility to Bitcoin when they got involved in Bitcoin Cash. Their business practices are not altruistic in any way.

PAR 6: After Monero forked to prevent ASICs their hash power dropped 70%+ which proves that ASICs were secretly mining on their network. The same could be happening to Ethereum today which is why we need to act quickly.

PAR 7: ASICs would eliminate hobbyist miners and make it difficult for the Average Jane to mine Ethereum.

Pro Doing Nothing (PDN)

There are 2 great resources that provide more detail to these bullet points.

PDN 1: The efficiency gains accomplished by the ASIC is relatively limited. At the time this comment was made on the code devs call, Batch 1 of the Bitmain ASIC's sold for $800 for 180MH/s which is a 2.5x factor improvement over GPUs. Batch 2 now sells for $1,800, but the argument can still technically be made, albeit with a different improvement level. (35:38)

PDN 2: We are unsure what protocol changes would make a difference. Even if we switch to a PoW algorithm that is entirely different and not I/O bound at all, such as SHA3, it may only buy us 6-12 months. (37:37)

PDN 3: The development effort to change the PoW algorithm and getting everyone to upgrade would be chaotic and risky. Developing, testing, planning, and enacting a hard fork and related code is not a simple process. (38:47)

PDN 4: Focusing on changing the PoW algorithm would detract from more important things, such as Casper, sharding, and other protocol level work. (38:47)

PDN 5: The Ethereum network is switching to proof-of-stake (Casper) soon™ so changing the PoW algorithm detracts from the research and development. Changing the PoW algorithm would serves as a band-aid while Casper is both an eventuality and a permanent solution.

PDN 6: The worst case scenario is that Bitmain controls a large portion of the Ethereum network for some time. If they try to use it for malicious purposes, Casper development can be sped up, launched in a week (albeit with potentially more bugs and skipping formal verification/academic review), and mining rewards would go down by 90%. If geth and Parity start making it a higher priority to implement Casper it would provide us with some insurance in the case of a 51% attack.(39:05)

PDN 7: It is impossible to prevent anti-competitive economies of scale from forming around mining. Large corporations and entities will achieve economies of scale in any mining model, including general purpose hardware / GPU-dominated mining (see Phil's blog I previously referenced).

PDN 8: Anti-ASIC forks reduce the cost to attack a cryptocurrency substantially and are a good thing for the security of a cryptocurrency system (see Phil's blog I previously referenced).

How long until Casper is launched?

This seems to be a sticking point in many of the arguments. Here is the latest: Researchers are in the process of finalizing the code for the 2nd stage of the testnet with the goal of completing and freezing the full specification of the Casper PoS algorithm. geth and Parity could start implementing parts of the Casper today. Casper is currently being formally verified by Runtime Verification which should take another 4-5 months to complete. Multiple academic groups are also looking at Casper. A formal EIP on Casper is being worked on and will be released for review in the next 2 weeks. The plan is to have Runtime Verification formally verify Casper, relaunch a custom Casper testnet with specs from the EIP, relaunch the contract on an Ethereum testnet, and finally launch Casper on the mainnet. There is no official timeline and there is unlikely to be one, in my opinion, until we get much closer to Casper being formally verified. (40:23)

So what now?

Well I for one am going to make myself a whiskey. Not because this was stressful, but because I enjoy whiskey. I actually find this pretty fun.

Anyways, if you are in the PAR group I suggest you act on your convictions and help with some of the EIPs being produced. If you are in the PDN group you can provide counter-arguments to the PAR group in forums/chat rooms. Currently the rough consensus of Ethereum core developers is that of the PDN group. However, my experience is that they are open to whatever the community wants as long as community consensus, or something close to it, can be demonstrated. There are many ways to determine this, including voting and discussions and EIPs. I encourage everyone to participate in this process.

You said a thing wrong!

If you feel like I left off an argument or made a mistake in this post let me know in the comments. I'll track edits at the bottom of this post.