EIP 2387/EIP 2384 and the Delay of Ethereum’s Difficulty Bomb
On January 1st, 2020 the Ethereum blockchain adopted EIP 2387, a hard fork, containing a single Ethereum Improvement Plan — EIP 2384 — in order to delay the “Ice Age” difficulty bomb for approximately 611 days.
Like Bitcoin, Ethereum is a blockchain network based on a Proof-of-Work block validation system. Today that burns around $238.50 in electricity for each and every Ethereum block — a number that has been trending upward over time.
Unlike Bitcoin, where block difficulty is targeted at about 10 minutes, Ethereum hopes for each block to be validated at an average rate of 15 seconds.
Why? Because Ethereum isn’t just a store-of-value. The Ethereum network also contains smart contracts that execute native code on the blockchain. A vibrant ecosystem of banking functions, asset management, trading exchanges, and more have sprung from this, requiring Ethereum to quickly respond to external events and triggers.
Based on the overall hash-power (currently over 144 trillion hashes per second) of the network, the difficulty increases or decreases to keep that average between 10 and 20 seconds — and it works very well.
But lurking in that difficulty adjustment algorithm lies a piece of semi-dormant code meant to cripple the Ethereum network on purpose by spiking the difficulty well above the network’s ability to solve in a reasonable time.
It’s not a bug.
It’s a bomb.
Why would someone do this? Why intentionally sabotage Ethereum’s ability to make blocks solvable at some point in the future?
We can explain the motivation, but let’s make sure we’re clear on the environment that the bomb lives in.
Ethereum contains a block-solving adjustment algorithm that, since the Homestead release in March of 2016, targets an average 15 second block time until a gradual (but eventually exponential) artificial increase requires more and more hash-power until the difficulty causes significant block-solving delays.
This is the “difficulty bomb” — the Ethereum Ice Age.
It looks a little something like this:
block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) +
int(2**((block.number // 100000) - 2))See that last bit in bold?
Ethereum’s yellow paper explains it clearly: a forced increase of difficulty every 100,000 blocks, with a difficulty rate that increases exponentially, and implemented to “encourage” the transition from Proof-of-Work to Proof-of-Stake.
Gavin Wood’s detailed explanation in the yellow paper records the history of changes from EIP 2, EIP 100, EIP 649, and EIP 1234 with the overall story being easy to follow: Proof-of-Stake is coming, but it’s delayed (again and again), so we have to push off the difficulty bomb or the Ethereum network will grind to a halt.
Proof-of-Stake will shift the Ethereum network from distributed miners using their hash-power to “stakers” who put up their Ether to have a random chance of being selected to validate a node. While Ethereum will lose the Bitcoin-style “absolute proof that the selection method of the validator was fair because it’s first to find a valid solution”, it also loses the baggage of wasting the electricity of a small city to keep itself running.
So, while the plans to accommodate Proof-of-Stake go all the way back to Buterin and Schoeder’s work from EIP 2, because the new PoS system isn’t ready yet the difficulty bomb has to be delayed once again because it was creeping up again (from the last delay).
EIP 2387 Code Name: Muir Glacier is just another delay in allowing the difficulty bomb to do its job, and required a hard fork to lengthen the fuse to another 611 days or so.
