New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defuse Difficulty Bomb and Reset Block Reward #1227

Open
SmeargleUsedFly opened this Issue Jul 18, 2018 · 10 comments

Comments

Projects
None yet
7 participants
@SmeargleUsedFly
Contributor

SmeargleUsedFly commented Jul 18, 2018

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/ethereum/EIPs/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

This comment has been minimized.

Show comment
Hide comment
@thunder02dragon

thunder02dragon Jul 18, 2018

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.

thunder02dragon commented Jul 18, 2018

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.

@eosclassicteam

This comment has been minimized.

Show comment
Hide comment
@eosclassicteam

eosclassicteam Jul 18, 2018

Contributor

+1 for this EIP

Contributor

eosclassicteam commented Jul 18, 2018

+1 for this EIP

@Hodl2Zero

This comment has been minimized.

Show comment
Hide comment
@Hodl2Zero

Hodl2Zero Jul 18, 2018

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.

Hodl2Zero commented Jul 18, 2018

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.

@mateuszk87

This comment has been minimized.

Show comment
Hide comment
@mateuszk87

mateuszk87 Jul 19, 2018

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 ?

mateuszk87 commented Jul 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@realcodywburns

realcodywburns Jul 19, 2018

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

realcodywburns commented Jul 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Jul 19, 2018

Contributor

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.

Contributor

MicahZoltu commented Jul 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@SmeargleUsedFly

SmeargleUsedFly Jul 19, 2018

Contributor

@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...

Contributor

SmeargleUsedFly commented Jul 19, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Jul 19, 2018

Contributor

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.

Contributor

MicahZoltu commented Jul 19, 2018

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

This comment has been minimized.

Show comment
Hide comment
@SmeargleUsedFly

SmeargleUsedFly Jul 19, 2018

Contributor

@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.

Contributor

SmeargleUsedFly commented Jul 19, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Jul 20, 2018

Contributor

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.

Contributor

MicahZoltu commented Jul 20, 2018

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.

5chdn added a commit to 5chdn/EIPs that referenced this issue Jul 20, 2018

Arachnid added a commit that referenced this issue Jul 20, 2018

EIP-1234: Constantinople Difficulty Bomb Delay and Block Reward Adjus…
…tment (#1234)

* difficulty bomb: duplicate eip 649

* eip-1234: update spec to match with constantinople requirements

* eip-1234: update header

* Remove reference to #1227

@ethereum ethereum deleted a comment from trustfarm-dev Aug 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment