Defuse Difficulty Bomb and Reset Block Reward

[SmeargleUsedFly]

Pull request with up-to-date proposal: #1235

This thread is for discussion.

Original proposal

eip: title: Defuse Difficulty Bomb and Reset Block Reward author: SmeargleUsedFly (@SmeargleUsedFly) discussions-to: https://github.com//issues/1227 status: WIP type: Standards Track category: Core created: 2018-07-18 requires: #649

Simple Summary

This EIP proposes to permanently disable the "difficulty bomb" and reset the block reward to pre-Byzantium levels.

Abstract

Starting with FORK_BLKNUM the client will calculate the difficulty without the additional exponential component. Furthermore, block rewards will be adjusted to a base of 5 ETH, uncle and nephew rewards will be adjusted accordingly.

Motivation

Nick Johnson, the de facto lead EIP editor, has stated unambiguously that the Ethereum user community's opinion on changes to the protocol may only be announced by running/not running node client software. This is also reflected in EIP #1, which includes no mention of community input over the EIP process. However, due to the "difficulty bomb" (also known as the "ice age"), introduced in EIP #2, an artificial exponential increase in difficulty until chain freeze, users may find it much more challenging to exercise one of those choices than the other—namely, remaining on the unforked chain after a controversial hard-fork.

This situation has in fact already been observed: during the Byzantium hard-fork users were given the "choice" of following the upgraded side of the chain or remaining on the original chain, the latter already experiencing block times greater than 30 seconds. In reality one will find that organizing a disperse and decentralized set of individuals to keep the original, soon-to-be-dead chain alive under such conditions impossible. This is exacerbated when a controversial change, such as EIP #649, is merged in so close to the hard-fork date, as users cannot be organized to take an educated stance for or against the change on such short notice.

Ultimately, the difficulty bomb serves but a single purpose: make it more difficult to keep the original chain alive after a hard-fork. This is unacceptable if the only way the community can make their voice heard is running/not running client software, and not through the EIP process, since they effectively have no choice and therefore no power. This EIP proposes to completely eliminate the difficulty bomb, returning some measure of power over Ethereum's governance process to the users, to the community.

Given the controversy surrounding the directly relevant EIP #649, the issuance should also be reset to pre-Byzantium levels. It may be reduced again at a later time via a new hard-fork, only this time users would actually have a meaningful choice in accepting the change or not.

Specification

Remove Exponential Component of Difficulty Adjustment

For the purposes of calc_difficulty, simply remove the exponential difficulty adjustment component, epsilon, i.e. the int(2**((block.number // 100000) - 2)) if block.number >= FORK_BLKNUM.

Reset Block, Uncle, and Nephew rewards

To ensure a constant Ether issuance, adjust the block reward to new_block_reward, where

new_block_reward = 5_000_000_000_000_000_000 if block.number >= FORK_BLKNUM else block.reward

(5E18 wei, or 5,000,000,000,000,000,000 wei, or 5 ETH).

Analogue, if an uncle is included in a block for block.number >= FORK_BLKNUM such that block.number - uncle.number = k, the uncle reward is

new_uncle_reward = (8 - k) * new_block_reward / 8

This is the existing pre-Byzantium formula for uncle rewards, simply adjusted with new_block_reward.

The nephew reward for block.number >= FORK_BLKNUM is

new_nephew_reward = new_block_reward / 32

This is the existing pre-Byzantium formula for nephew rewards, simply adjusted with new_block_reward.

Rationale

This will permanently, without further changes, disable the "ice age." It will also reset the block reward to pre-Byzantium levels. Both of these changes are specified similarly to EIP #649, so they should require only minimal changes from client developers.

Backwards Compatibility

This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. However, it may be controversial in nature among different sections of the userbase—the very problem this EIP is made to address. Therefore, it should not be included in a scheduled hardfork at a certain block number. It is suggested to implement this EIP in an isolated hard-fork before the second of the two Metropolis hard-forks.

Test Cases

Forthcoming.

Implementation

Forthcoming.

Copyright

Copyright and related rights waived via CC0.

[thunder02dragon]

Interesting! Would love to come back to ETH again if needed..Left supporting this network for months. However it will draw the whole GPU network here resulting in more higher difficulty. Still I support it as the hash will be within community not BITMAIN or someone similar's control.

[ghost]

+1 for this EIP

[PeterFarfan]

I think this would actually make it worse since the companies making the ASICS would also enjoy the increase in block rewards, infact they'll benefit a lot more then the community due to economies of scale. (Example: with $1000 BITMAIN could build 3 asic miners. With $1000 the community can only afford 1 asic miner) Right now the only solution to give power back to the community is the move to Proof of Stake or change the code to be Asic resistance.

[1ultimat3]

Is there any study/article discussing if reducing block rewards is affecting decentralization aspects? E.g. when mining becomes not profitable in most western countries, who and with what incentives would want to participate in securing and keeping the chain alive ?

[realcodywburns]

Tying the 2 separate issues, blockreward & bomb removal , together made a mess of the last EIP. Armchair economists made the thread woefully off topic. It was likely because no group would agreed to both on their own.

The bomb was a poor design decision in the first place, and randomly patching it to extend the delay is unsustainable. The intent of the bomb was to give leverage during the pos switch which never occurred. The community and developers have made it abundantly clear that this is the roadmap and miners are a short term third party that will be fired. If this social understanding is accepted, there is no reason to have needlessly inelegant code. Defuse the bomb.

my comments on #649 are still valid. all logic is in place to support defusing the bomb and adjusting the block rewards in parity and trivially implemented in geth. ref: ecip1041

[MicahZoltu]

Consider splitting this issnto two EIPs so the two issues can be discussed separately and/or implemented separately. The difficulty increase serves a different purpose from the reward decrease, and putting a change to both into a single EIP is likely to add confusion and struggle to the discussion.

[SmeargleUsedFly]

@MicahZoltu The original proposal wasn't clear on this point, but I added a line to say that the block reward reset is optional, and the lesser concern, in this proposal. Though #649 would like a word with you...

[MicahZoltu]

Saying that something is optional but leaving it in the EIP doesn't really help address the confusion in discussion issue. People will discuss both intermixed and the EIP needs to pass all or nothing. To avoid this, just author two separate PRs, then people can freely discuss them in isolation.

[SmeargleUsedFly]

@MicahZoltu I'm on the fence about that. I don't care enough about resetting issuance to champion a separate EIP for it. On the other hand, it is something that is directly relevant to the underlying motivation of the proposed change of defusing the difficulty bomb. I listed it as "optional" because I think the case can be made to not reset issuance ("let's not play around with the issuance any more than we already have, which is already too much"), and it can be removed entirely from this proposal if desired by the community, users, miners, and core devs.

[MicahZoltu]

Your EIP, so ultimately your call. I would advocate against this EIP getting included in a fork as written though, but I would probably be in support of an EIP that only removed the difficulty bomb. As it is, I don't have the energy to get stuck in a quagmire of an EIP discission that includes a rider.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.