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

Change difficulty adjustment to target mean block time including uncles #100

Closed
vbuterin opened this Issue Apr 29, 2016 · 9 comments

Comments

Projects
None yet
10 participants
@vbuterin
Collaborator

vbuterin commented Apr 29, 2016

Specification

Currently, the formula to compute the difficulty of a block includes the following logic:

adj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99)
child_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF)))
...

If block.number >= METROPOLIS_FORK_BLKNUM, we change the first line to the following:

adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)

Specification (1b)

adj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99)

Rationale

This new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. The formula can be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with k uncles is equivalent to a sequence of k+1 blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect.

Changing the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%).

(1b) accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash) and not the entire block.

Update 2017.06.29

Version (1b) was chosen.

@wanderer

This comment has been minimized.

Show comment
Hide comment
@wanderer

wanderer May 13, 2016

Member

lgtm

Member

wanderer commented May 13, 2016

lgtm

@SergioDemianLerner

This comment has been minimized.

Show comment
Hide comment
@SergioDemianLerner

SergioDemianLerner May 18, 2016

lgtm.
If the uncle rate decreases, the avg block rate will slightly increase, forcing an increase in the uncle rate.
If the uncle rate increases, the avg block rate will slightly decrease, forcing an decrease in the uncle rate.
Nice negative feedback loop.
If block reward depended on the current block rate, so that reward/sec were always constant, block rate could be freely chosen by the network and the difficulty adjustment formula could allow decreasing block rate down to 5 secs if network conditions tolerated it. All dynamic.

SergioDemianLerner commented May 18, 2016

lgtm.
If the uncle rate decreases, the avg block rate will slightly increase, forcing an increase in the uncle rate.
If the uncle rate increases, the avg block rate will slightly decrease, forcing an decrease in the uncle rate.
Nice negative feedback loop.
If block reward depended on the current block rate, so that reward/sec were always constant, block rate could be freely chosen by the network and the difficulty adjustment formula could allow decreasing block rate down to 5 secs if network conditions tolerated it. All dynamic.

@gumb0

This comment has been minimized.

Show comment
Hide comment
@gumb0

gumb0 Mar 22, 2017

Member

Uncle number is not the part of the header, so now to validate the header we need not only the parent header, but parent body, too. Wouldn't this cause troubles for the light clients?

Update. This was the concern only for 1a specification, but now 1b seems to be the consensus and it doesn't require the parent body.

Member

gumb0 commented Mar 22, 2017

Uncle number is not the part of the header, so now to validate the header we need not only the parent header, but parent body, too. Wouldn't this cause troubles for the light clients?

Update. This was the concern only for 1a specification, but now 1b seems to be the consensus and it doesn't require the parent body.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Aug 2, 2017

Member

The activation should be BYZANTIUM_FORK_BLKNUM now.

Member

pirapira commented Aug 2, 2017

The activation should be BYZANTIUM_FORK_BLKNUM now.

@marcogiglio

This comment has been minimized.

Show comment
Hide comment
@marcogiglio

marcogiglio Aug 3, 2017

The proposed change has a negative conseguence on the effective gas throughtput of the network per second. Since uncle rates increas 0.77% per each additional 1M unit of gas consumed, after applying this change, increasing the block gas limit would result in a less than linear increase in effective throughput per second, due to the increased uncles which are now taken in consideration for blocktime calculation. The effect becomes evident already at around 20M block gas limit, where the available throughtput is around 80% of what would be with today difficulty algorithm, at least in theory.

Assuming linearity of the uncle rate probability, the effective throughput per second converges then to a value equivalent to a 50M gas block limit, which becomes kinda of hardcoded since voting the gas beyond that actually decreases the throughtput because of the increasing uncle rate.

marcogiglio commented Aug 3, 2017

The proposed change has a negative conseguence on the effective gas throughtput of the network per second. Since uncle rates increas 0.77% per each additional 1M unit of gas consumed, after applying this change, increasing the block gas limit would result in a less than linear increase in effective throughput per second, due to the increased uncles which are now taken in consideration for blocktime calculation. The effect becomes evident already at around 20M block gas limit, where the available throughtput is around 80% of what would be with today difficulty algorithm, at least in theory.

Assuming linearity of the uncle rate probability, the effective throughput per second converges then to a value equivalent to a 50M gas block limit, which becomes kinda of hardcoded since voting the gas beyond that actually decreases the throughtput because of the increasing uncle rate.

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Oct 11, 2017

Member

@vbuterin This needs to be a PR.

Member

Souptacular commented Oct 11, 2017

@vbuterin This needs to be a PR.

@jamesray1

This comment has been minimized.

Show comment
Hide comment
@jamesray1

jamesray1 Oct 20, 2017

Contributor

When you make a PR maybe just include the chosen option 1b.

Contributor

jamesray1 commented Oct 20, 2017

When you make a PR maybe just include the chosen option 1b.

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Oct 20, 2017

Member

This has a PR #692

Member

cdetrio commented Oct 20, 2017

This has a PR #692

@pipermerriam pipermerriam referenced this issue Oct 20, 2017

Merged

Byzantium Fork Rules #123

9 of 9 tasks complete

@pirapira pirapira referenced this issue Oct 23, 2017

Open

Apply Byzantium changes #459

0 of 10 tasks complete
@nicksavers

This comment has been minimized.

Show comment
Hide comment
@nicksavers

nicksavers Jan 7, 2018

Collaborator

PR has been merged and EIP is active in the main repository with status Final
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md
@vbuterin The document still references this issue for discussion, but I imagine it can be closed.

Collaborator

nicksavers commented Jan 7, 2018

PR has been merged and EIP is active in the main repository with status Final
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-100.md
@vbuterin The document still references this issue for discussion, but I imagine it can be closed.

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