-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Conversation
Fast-forward upstream.
EIPS/eip-1234.md
Outdated
category: Core | ||
status: Draft | ||
created: 2018-07-19 | ||
replaces: 1227 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1227 doesn't appear to be a valid EIP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it is #1235? Or do you want me to remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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? |
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. |
That's a shame to constantly delay difficulty bomb. |
@SmeargleUsedFly No need to be mean. Keep the convo technical. |
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? |
@5chdn @kaibakker Yes I would like to know the number 2 ETH, is there any secret place where you discuss about future of ethereum?? |
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. |
EIPS/eip-1234.md
Outdated
category: Core | ||
status: Draft | ||
created: 2018-07-19 | ||
replaces: 1227 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
This is out of scope for this proposal I guess.
The place is not secret and can be extracted from the
I was aiming for a 40% reduction as in #649 and then rounded to full 10^18 Wei numbers.
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 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. |
@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)? |
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 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)."" |
@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 |
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. |
There seeems to be this misconception that eip-2 introduced the difficulty bomb. > 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. <ethereum/EIPs#1234> > Due to the "difficulty bomb" (also known as the "ice age"), introduced in EIP ethereum#2, an artificial exponential increase in difficulty until chain freeze, <https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1227.md> When looking into the homestead fork (specified in eip-2), it seems that the difficulty change has nothing to do with the difficulty bomb. The difficulty bomb has always been there. Why was the difficulty bomb introduced in the first place? <https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/> > starting from block 200,000 (very roughly 17 days from now), the difficulty will undergo an exponential increase which will only become noticeable in about a year. https://ethereum.org/en/glossary/#ice-age
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.