EIP-1234: Constantinople Difficulty Bomb Delay and Block Reward Adjus…

…tment (#1234)

* difficulty bomb: duplicate eip 649

* eip-1234: update spec to match with constantinople requirements

* eip-1234: update header

* Remove reference to #1227

EIPS/eip-1234.md

@@ -0,0 +1,61 @@
+---
+eip: 1234
+title: Constantinople Difficulty Bomb Delay and Block Reward Adjustment
+author: Afri Schoedon (@5chdn)
+discussions-to: https://github.com/ethereum/EIPs/pull/1234
+type: Standards Track
+category: Core
+status: Draft
+created: 2018-07-19
+---
+
+## Simple Summary
+The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately one and a half year 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 based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 2 ETH, uncle and nephew rewards will be adjusted accordingly.
+
+## Motivation
+The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.
+
+## Specification
+#### Relax Difficulty with Fake Block Number
+For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula:
+
+    fake_block_number = max(0, block.number - 6_000_000) if block.number >= CNSTNTNPL_FORK_BLKNUM else block.number
+
+#### 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 delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times in summer 2020. An alternate proposal was to add special rules to the difficulty calculation to effectively _pause_ the difficulty between different blocks. This would lead to similar results.
+
+This was previously discussed at All Core Devs Meeting [#42](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2042.md) without stating any details. This draft can be used to discuss further changes to the difficulty bomb and issuance in subsequent meetings. This EIP-1234 opposes directly the intent of [EIP-1227](https://github.com/ethereum/EIPs/issues/1227) 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 in it's logic does not differ from [EIP-649](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-649.md) and can be used as temporary reference.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).