Skip to content

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

Closed
@vbuterin

Description

@vbuterin

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.

Activity

wanderer

wanderer commented on May 13, 2016

@wanderer
Member

lgtm

SergioDemianLerner

SergioDemianLerner commented on May 18, 2016

@SergioDemianLerner
Contributor

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

gumb0 commented on Mar 22, 2017

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

25 remaining items

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @pirapira@wanderer@marcogiglio@cdetrio@SergioDemianLerner

        Issue actions

          Change difficulty adjustment to target mean block time including uncles · Issue #100 · ethereum/EIPs