Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Change difficulty adjustment to target mean block time including uncles #100
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))) ...
adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)
adj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99)
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
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.
Version (1b) was chosen.
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.
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.
PR has been merged and EIP is active in the main repository with status Final