Change difficulty adjustment to target mean block time including uncles
The EIP-100 proposal, authored by Vitalik Buterin, suggests a change in the difficulty adjustment formula used in the Ethereum blockchain. Currently, the formula takes into account the timestamp of the parent block and the difficulty of the parent block, among other factors, to determine the difficulty of the new block. However, this formula does not account for the presence of uncle blocks, which are blocks that are not included in the main blockchain but are still valid and can be used to calculate rewards.
The proposed change in the formula aims to target a constant average rate of blocks produced, including uncle blocks, to ensure a predictable issuance rate that cannot be manipulated by increasing the uncle rate. The new formula takes into account the timestamp of the parent block, the number of uncle blocks included, and a new adjustment factor that ensures the block time remains roughly the same.
The rationale behind this change is to prevent miners from manipulating the uncle rate to increase their rewards, which can lead to an unpredictable issuance rate and potentially harm the stability of the network. By targeting a constant average rate of blocks produced, the EIP-100 proposal aims to ensure a more stable and predictable issuance rate.
Overall, the EIP-100 proposal is an important step towards improving the stability and predictability of the Ethereum blockchain, and it highlights the ongoing efforts to address potential flaws and vulnerabilities in the network.
Video
Original
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 >= BYZANTIUM_FORK_BLKNUM, we change the first line to the following:
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. A formula that accounts for the exact number of included uncles:
adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)
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. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that 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).
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%).
References
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all