EIP1276 - Eliminate Difficulty Bomb and Adjust Block Reward on Constantinople Shift

# Simple Summary

The average block times are increasing due to the factor of difficulty logic well known as difficulty bomb. This EIP proposes to eliminate the difficulty bomb forever and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.

# Abstract

Starting with CNSTNTNPL_FORK_BLKNUM the client will calculate the difficulty without considering the current block number. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.

# Motivation

Block time has been played a most important role on blockchain ecosystem, and it is being adjusted by the logic of mining difficulty calculation that is already implemented on the node client as a part of proof-of-work consensus. Last year, average block time rapidly increased due to the wrong design of difficulty logic that is meant to be changed on the part of Casper upgrade, however, implementation of casper has been delayed therefore it was inevitable to delay the difficulty bomb in order to prevent the significant delay of processing transactions on ethereum network.

Despite of the successful hardfork to delay the activation of difficulty bomb, activation of the difficulty bomb is expected to happen again on the upcoming period before implementing casper protocol on ethereum network. Therefore, completely removing the difficulty bomb is the most proper way to response the block time increase instead of delaying it again.

Also decreasing the block mining reward along with difficulty bomb removal is expected to help the growth of the stable ethereum ecosystem, right now ethereum dominates 92% of the total hashrate share of ethash based chains, and this corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.

# Specification

# Remove Exponential Component of Difficulty Adjustment

For the purposes of calc_difficulty, simply remove the exponential difficulty adjustment component, epsilon, i.e. the int(2**((block.number // 100000) - 2)).

# Adjust Block, Uncle, and Nephew rewards

To ensure a constant Ether issuance, adjust the block reward to new_block_reward, where

new_block_reward = 2_000_000_000_000_000_000 if block.number >= CNSTNTNPL_FORK_BLKNUM else block.reward

(2E18 wei, or 2,000,000,000,000,000,000 wei, or 2 ETH).

Analogue, if an uncle is included in a block for block.number >= CNSTNTNPL_FORK_BLKNUM such that block.number - uncle.number = k, the uncle reward is

new_uncle_reward = (8 - k) * new_block_reward / 8

This is the existing pre-Constantinople formula for uncle rewards, simply adjusted with new_block_reward.

The nephew reward for block.number >= CNSTNTNPL_FORK_BLKNUM is

new_nephew_reward = new_block_reward / 32

This is the existing pre-Constantinople formula for nephew rewards, simply adjusted with new_block_reward.

# Rationale

This will completely remove the difficulty bomb on difficulty adjustment algorithm without delaying the difficulty bomb again, therefore it is possible to prevent network delay on the beginning of 2019.

This EIP-1276 opposes directly the intent of EIP-1234 which should be also considered in discussions.

# Backwards Compatibility

This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, Constantinople.

# Test Cases

Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.

# Implementation

The implementation shall be created once the specification is to be accepted by the developers or implemented by the clients.