mirror of https://github.com/status-im/EIPs.git
64 lines
4.7 KiB
Markdown
64 lines
4.7 KiB
Markdown
---
|
|
eip: 1276
|
|
title: Eliminate Difficulty Bomb and Adjust Block Reward on Constantinople Shift
|
|
author: EOS Classic (@eosclassicteam)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-1276-eliminate-difficulty-bomb-and-adjust-block-reward-on-constantinople-shift/908
|
|
type: Standards Track
|
|
category: Core
|
|
status: Draft
|
|
created: 2018-07-31
|
|
---
|
|
|
|
## 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](https://github.com/ethereum/EIPs/issues/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.
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|