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

EIP-1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment #1234

Merged
merged 7 commits into from Jul 20, 2018

Conversation

Projects
None yet
10 participants
@5chdn
Copy link
Contributor

5chdn commented Jul 19, 2018

eip: 1234
title: Constantinople Difficulty Bomb Delay and Block Reward Adjustment
author: Afri Schoedon (@5chdn)
discussions-to: https://github.com/ethereum/EIPs/pull/1234
type: Standards Track
category: Core
status: Draft
created: 2018-07-19

Abstract: Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.

Read the draft here: eip-1234.md

Orthogonal intention and not compatible with #1227.

5chdn added some commits Apr 24, 2018

Merge pull request #3 from ethereum/master
Fast-forward upstream.
category: Core
status: Draft
created: 2018-07-19
replaces: 1227

This comment has been minimized.

@Arachnid

Arachnid Jul 19, 2018

Collaborator

1227 doesn't appear to be a valid EIP.

This comment has been minimized.

@5chdn

5chdn Jul 20, 2018

Contributor

Now it is #1235? Or do you want me to remove this?

This comment has been minimized.

@Arachnid

Arachnid Jul 20, 2018

Collaborator

Oh, the build was failing because it wasn't merged yet. It should work now.

I don't think this replaces that one, though - they're both drafts, and you can only replace a Final EIP.

@ppratscher

This comment has been minimized.

Copy link

ppratscher commented Jul 19, 2018

What is the rationale behind another block reward reduction? Have you evaluated the possible impact on the resiliency of the network against 51% attacks especially in the light of the recently released Ethash ASICS?
I suggest to move this part into a separate EIP as the delay of the difficulty bomb and the block reward reduction are not related from a technical point of view and thus should be discussed separately.

@SmeargleUsedFly

This comment has been minimized.

Copy link
Contributor

SmeargleUsedFly commented Jul 19, 2018

This does not conflict with #1227, as that proposal suggests deployment strictly before the Constantinople hard-fork. I know reading isn't your strong suite, but please actually bother to read the proposal before down-voting it.

@Nogreedy

This comment has been minimized.

Copy link

Nogreedy commented Jul 19, 2018

That's a shame to constantly delay difficulty bomb.
I propose a block reward reduction to 0.9 ETH... it's more than 5,000 ETH daily... more than enough.

@Souptacular

This comment has been minimized.

Copy link
Member

Souptacular commented Jul 19, 2018

@SmeargleUsedFly No need to be mean. Keep the convo technical.

@kaibakker

This comment has been minimized.

Copy link

kaibakker commented Jul 20, 2018

I think this would be the right moment to talk about short-term scalability for Ethereum v1.0. As v2.0 gets delayed and completion is getting stronger. Would it make sense to make the blockinterval shorter (10 second for example)? There might be other changes that could help ethereum short term, I am not an expert.

What is the rational of changing the block reward to 2 ETH, how did you get to that number?

@ghost

This comment has been minimized.

Copy link

ghost commented Jul 20, 2018

@5chdn @kaibakker Yes I would like to know the number 2 ETH, is there any secret place where you discuss about future of ethereum??

@Hodl2Zero

This comment has been minimized.

Copy link

Hodl2Zero commented Jul 20, 2018

I support a reduction in inflation, but I think asics would make it difficult to implement changes to the block reward, they should be looked at first.

category: Core
status: Draft
created: 2018-07-19
replaces: 1227

This comment has been minimized.

@Arachnid

Arachnid Jul 20, 2018

Collaborator

Oh, the build was failing because it wasn't merged yet. It should work now.

I don't think this replaces that one, though - they're both drafts, and you can only replace a Final EIP.

@5chdn

This comment has been minimized.

Copy link
Contributor

5chdn commented Jul 20, 2018

I support a reduction in inflation, but I think asics would make it difficult to implement changes to the block reward, they should be looked at first.

This is out of scope for this proposal I guess.

Yes I would like to know the number 2 ETH, is there any secret place where you discuss about future of ethereum??

The place is not secret and can be extracted from the discussion-to header of the proposal. I used similiar parameters as we used in #649 - everything is up for discussion.

What is the rational of changing the block reward to 2 ETH, how did you get to that number?

I was aiming for a 40% reduction as in #649 and then rounded to full 10^18 Wei numbers.

I think this would be the right moment to talk about short-term scalability for Ethereum v1.0. As v2.0 gets delayed and completion is getting stronger. Would it make sense to make the blockinterval shorter (10 second for example)? There might be other changes that could help ethereum short term, I am not an expert.

Decreasing block times just makes things worse as we have to process and store more on-chain data. I'd suggest for now to maintain a stable block time and issuance.

I suggest to move this part into a separate EIP as the delay of the difficulty bomb and the block reward reduction are not related from a technical point of view and thus should be discussed separately.

I stated that elsewhere multiple times, but happy to repeat this: reducing the block times increases the issuance. reducing the block rewards reduces the issuance. having both in one proposal aims to maintain a stable issuance, this is the overall goal of this EIP.

@Arachnid Arachnid merged commit 2e9723e into ethereum:master Jul 20, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid commented Jul 21, 2018

@5chdn I didn't notice at the time, the discussion link you provided is this PR. Can you please submit a new PR with a discussion link that is a permanent place to discuss this EIP (such as an issue or an ethereum-magicians topic)?

@5chdn 5chdn deleted the 5chdn:a5-eip-1234 branch Jul 21, 2018

@5chdn 5chdn restored the 5chdn:a5-eip-1234 branch Jul 21, 2018

@5chdn

This comment has been minimized.

Copy link
Contributor

5chdn commented Jul 21, 2018

@5chdn 5chdn referenced this pull request Jul 22, 2018

Closed

ethash: implement EIP-1234 #9187

@Nogreedy

This comment has been minimized.

Copy link

Nogreedy commented Jul 26, 2018

Why we just don't stick to what V. Buterin said about block reward adjustment ? :

"Block 3000000, approx ETH supply 87962556, time '2017-01-16 00:38:33.067775' blocktime 14.86
Block 3500000, approx ETH supply 90612556, time '2017-04-11 18:09:34.273529' blocktime 15.27
Block 4000000, approx ETH supply 93262556, time '2017-08-15 18:20:24.642729' blocktime 30.01
Block 4500000, approx ETH supply 95912556, time '2018-11-03 05:55:48.912370' blocktime 136.71
Block 5000000, approx ETH supply 98562556, time '2025-10-02 11:47:30.658317' blocktime 835.81
Block 5500000, approx ETH supply 101212556, time '2128-03-20 09:14:16.483692' blocktime 17183.83
Block 6000000, approx ETH supply 103862556, time '5189-09-26 20:57:59.367004' blocktime 520901.19

Hence, in the foreseeable future, the supply will not go far above 100 million.

PoS is likely to lead to quite low issuance rates; I am not comfortable promising zero, but if it is not much less than the current PoW then there is little point in making the switch in any case. If the community wishes to, while PoW is in play, it's possible to agree that any delay to the ice age bomb should also respect this general ETH supply growth curve, so in a situation where at time X if current ethereum would have a 75s block time, the ice age patch would set the block time to 15s and the block reward to 1 ETH (and adjust uncle/nephew rewards proportionately).""
https://np.reddit.com/r/ethereum/comments/5izcf5/lets_talk_about_the_projected_coin_supply_over/dbc66rd/

@jmiehau

This comment has been minimized.

Copy link

jmiehau commented Aug 22, 2018

@5chdn "This will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times in summer 2020."

I think that instead of 1.4 years, we should postpone the difficulty bomb only 6 months. The difficulty bomb is the best mechanism that we have to apply new hard forks. And hard forks are needed to make changes to move forward to POS.

About the issuance rate, I would be in favor to decrease it more than 2 ETH. But I agree that 2 ETH is better than doing nothing, so thank you for champion this EIP in the next core dev.

It would be great if we could reach consensus in something repeatable each 6 months till we reach POS. (Like decreasing 33% the block reward each 6 months).

PD: The link to the md file is broken. It should be: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1234.md

@tjayrush

This comment has been minimized.

Copy link

tjayrush commented Aug 25, 2018

Is there some reason why whole numbers of ETH per block is always proposed for ETH adjustments? Is it simply a matter of cognitive overload? Why not a smoother function than a straight off-the-cliff 1/3 reduction per block? Why not lower the issuance by some fraction of an ETH every X number of blocks? If issuance was reduced 1 Szabo per block, over six months it would lower by one block. Choosing a whole number of ETH is almost designed to be controversial.

I think I know the answer: because then we would be behaving very much like central bankers, adjusting the money supply to battle inflation, but we're doing that anyway. It never made sense to me, so I thought I'd ask.

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