By Eric Marti Haynes, Josh Klopfenstein, Abhimanyu Nag
After seven years of rigorous research, development, and testing, Ethereum is on the cusp of transitioning to proof-of-stake. The long-awaited Merge of the existing Ethereum proof-of-work blockchain into the proof-of-stake beacon chain will do away with mining and set the stage for future innovations.
To ensure miners (who benefit from the PoW system) do not hinder the transition, and developers continue work on The Merge, the protocol enforces the “difficulty bomb.” The bomb will make mainnet mining unprofitable and allow the new PoS validators to assume responsibility of securing the network. While the difficulty bomb has been part of the protocol since the early days of Ethereum, it has been pushed back to accommodate additional proof-of-stake R&D. Otherwise, the network would grind to halt.
In a continued commitment to network uptime and performance, the Ethereum community and core developers have decided to delay the difficulty bomb once more with EIP-5133. This will provide breathing room to put the polishing touches on client implementations before the Merge, while also allowing for the Merge to be carried out under more stable network conditions.
Delaying the difficulty bomb is not as straightforward as it might sound. If not done carefully, it can lead to unexpected delays in block production, resulting in a degraded network and negative user experience. In this post, we examine past work on the difficulty bomb and the new methods we have used to predict its effects.
Requiring a PoW for each block is not sufficient to guarantee security in perpetuity. More miners and faster hardware will generate PoWs faster than few miners with poor hardware. PoWs that can be generated quickly result in empty blocks, which are useless to the network (the whole point of the blockchain is to process transactions). Conversely, if a lot of miners leave the network, block production may slow to a creep because there isn’t enough hash power to produce regular blocks. To combat this, Ethereum dynamically adjusts the mining difficulty $H_d$ every block ($H$ denotes a block header) to keep block times around 13.3s. The amount of computation the miners need to perform for the current block is proportional to $\frac{2^{256}}{H_d}$, so increasing and decreasing the difficulty proportionally adjusts the amount of computation required.
$$ H_d = P(H)_{d} + r + \epsilon
$$
$$ r = \left\lfloor \frac{P(H)_{d}}{2048} \right\rfloor \times \max\left(1 - \left\lfloor\frac{H_s - P(H)_s}{9}\right\rfloor, -99 \right) $$
$$ \epsilon = \left\lfloor 2^{ \left\lfloor (H_i - \kappa)\div{100000} \right\rfloor
where $P(H)$ is the header of the parent block, $H_s$ is the block timestamp, and $H_i$ is the block number (note that the above equations are slightly simplified, but the loss of precision won’t affect the final outcome. The complete version can be found on page 7 of the Ethereum Yellow Paper, which uses slightly different notation).
In the equation above, $r$ is designed to keep block times around 13.3s by increasing when block times are low and decreasing when block times are high.
The $\epsilon$ is the difficulty bomb, which doubles every 100,000 blocks. Initially, the bomb was set to start increasing at block 200,000, hence the “minus two” in the exponent. **To delay the bomb, $\kappa$ is subtracted from the block number. Every EIP that has delayed the bomb has increased $\kappa$.
| EIP | Hard Fork: Date | $\kappa$ |
|---|---|---|
| EIP-649 | Byzantium: October 16, 2017 | 300,000 |
| EIP-1234 | Constantinople: February 28, 2019 | 500,000 |
| EIP-2384 | Muir Glacier: January 2, 2020 | 9,000,000 |
| EIP-3554 | London: August 5, 2021 | 9,700,000 |
| EIP-4345 | Arrow Glacier: December 9, 2021 | 10,700,000 |
With the Merge approaching, it is preferable that the community and core developers have solid predictions of block times a few months in advance. Unfortunately, block times are a third-order effect that depends directly on the hash rate and indirectly on miner decisions and the difficulty, which depend on the previous block times. The diagram below depicts the circular dependency.
To break the dependency, we’ll need to make some assumptions. First, we’ll use existing work to predict when the bomb will occur. Then, we’ll turn to more nuanced statistical techniques to predict block times after the bomb occurs.
Previous work has shown that the bomb starts to have a noticeable impact on block times when the following ratio holds: