2.2 KiB
eip | title | author | discussions-to | type | category | status | created |
---|---|---|---|---|---|---|---|
3238 | Difficulty Bomb Delay to Q2/2022 | Afri Schoedon (@q9f) | https://github.com/ethereum/EIPs/issues/3239 | Standards Track | Core | Stagnant | 2021-01-25 |
Simple Summary
Delays the difficulty bomb so 30 second blocks won't happen until around Q2/2022.
Abstract
Starting with FORK_BLOCK_NUMBER
the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting eleven million blocks later than the actual block number.
Motivation
Even after the Ethereum 2.0 mainnet launch, Ethash proof-of-work mining on the legacy chain should be feasible. It should allow miners sealing new blocks every 13~15 seconds on average for another ten months and allow both Ethereum 1.x and Ethereum 2.0 developers to conclude the merge.
Specification
Relax Difficulty with Fake Block Number
For the purposes of calc_difficulty
, simply replace the use of block.number
, as used in the exponential ice age component, with the formula:
fake_block_number = max(0, block.number - 11_000_000) if block.number >= FORK_BLOCK_NUMBER else block.number
Rationale
This will delay the ice age by another ~26 million seconds (approximately ~9.89 months), so the chain would be back at ~30 second block times in Q2/2022. Hopefully, by then the Eth1-to-Eth2 merge will be concluded and the ice age fulfilled its task.
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. It's suggested to consider this EIP either with or shortly after the Berlin hard-fork but not later than July 2021.
Alternatively, in order to maintain stability of the system, a it can be considered to activate this EIP along with EIP-1559 fee market changes in a bundle. With the delay of the ice age, there is a desire to no further increase inflation and rather incentivize users to participate in proof-of-stake consensus instead.
Security Considerations
There are no known security issues with this proposal.
Copyright
Copyright and related rights waived via CC0.