2.8 KiB
| eip | title | author | discussions-to | type | category | status | created |
|---|---|---|---|---|---|---|---|
| 1240 | Remove Difficulty Bomb | Micah Zoltu (@MicahZoltu) | https://ethereum-magicians.org/t/difficulty-bomb-removal/832 | Standards Track | Core | Draft | 2018-07-21 |
Simple Summary
The average block times are increasing due to the difficulty bomb (also known as the "ice age") slowly accelerating. This EIP proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks.
Abstract
Starting with FORK_BLOCK_NUMBER the client will calculate the difficulty without considering the current block number.
Motivation
The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around.
Specification
Remove Difficulty
For the purposes of calc_difficulty, if block.number >= FORK_BLOCK_NUMBER then change the epsilon component to 0 rather than having it be a function of block number.
Rationale
With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users.
Author Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults.
Backwards Compatibility
This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number.
Test Cases
Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.
Implementations
The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710
Copyright
Copyright and related rights waived via CC0.