forked from DecentralizedClimateFoundation/DCIPs
51 lines
4.0 KiB
Markdown
51 lines
4.0 KiB
Markdown
|
---
|
||
|
|
eip: 3368
|
||
|
|
title: Increase block rewards to 3 ETH, with 2 Year Decay to 1 ETH Scheduled
|
||
|
|
author: Michael D. Carter (@BitsBeTrippin)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/eip-3368-block-reward-increase-w-decay-for-next-two-years/5550
|
||
|
|
status: Stagnant
|
||
|
|
type: Standards Track
|
||
|
|
category: Core
|
||
|
|
created: 2021-03-12
|
||
|
|
---
|
||
|
|
|
||
|
|
## Simple Summary
|
||
|
|
Changes the block reward paid to proof-of-work (POW) miners to 3 ETH from existing 2 ETH and starts a decay schedule for next two years to 1 ETH Block Reward.
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
Set the block reward to 3 ETH and then decrease it slightly every block for 4,724,000 blocks (approximately 2 years) until it reaches 1 ETH.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
A sudden drop in PoW mining rewards could result in a sudden precipitous decrease in mining profitability that may drive miners to auction off their hashrate to the highest bidder while they figure out what to do with their now "worthless" hardware. If enough hashrate is auctioned off in this way at the same time, an attacker will be able to rent a large amount of hashing power for a short period of time at relatively low cost vs. reward and potentially attack the network. By setting the block reward to X (where X is enough to offset the sudden profitability decrease) and then decreasing it over time to Y (where Y is a number below the sudden profitability decrease), we both avoid introducing long term inflation while at the same time spreading out the rate that individual miners cross into a transitional range. This approach offers a higher level of confidence and published schedule of yield, while allowing mining participants time to gracefully repurpose/sell their hardware. This greatly increases ethereums PoW security by keeping incentives aligned to ethereum and not being force projected to short term brokerage for the highest bidder. Additionally the decay promotes a known schedule of a deflationary curve, aligning to the overall Minimal Viable Issuance directive aligned to a 2 year transition schedule for Proof of Stake, consensus replacement of Proof of Work. Security is paramount in cryptocurrency blockchains and the risk to a 51% non-resistant chain is real. The scope of Ethereum's current hashrate has expanded to hundreds of thousands of new participants and over 2.5x original ATH hashrate/difficulty. While the largest by hashrate crypto is bitcoin, ethereum is not far behind the total network size in security aspects. This proposal is focused to keep that superiority in security one of the key aspects.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
Adjust block, uncle, and nephew rewards
|
||
|
|
### Constants
|
||
|
|
* `TRANSITION_START_BLOCK_NUMBER: TBD`
|
||
|
|
* `TRANSITION_DURATION: 4_724_000` (about two years)
|
||
|
|
* `TRANSITION_END_BLOCK_NUMBER: FORK_BLOCK_NUMBER + TRANSITION_DURATION`
|
||
|
|
* `STARTING_REWARD: 3_000_000_000_000_000_000`
|
||
|
|
* `ENDING_REWARD: 1_000_000_000_000_000_000`
|
||
|
|
* `REWARD_DELTA: STARTING_REWARD - ENDING_REWARD`
|
||
|
|
### Block Reward
|
||
|
|
```py
|
||
|
|
if block.number >= TRANSITION_END_BLOCK_NUMBER:
|
||
|
|
block_reward = ENDING_REWARD
|
||
|
|
elif block.number = TRANSITION_START_BLOCK_NUMBER:
|
||
|
|
block_reward = STARTING_REWARD
|
||
|
|
elif block.number > TRANSITION_START_BLOCK_NUMBER:
|
||
|
|
block_reward = STARTING_REWARD - REWARD_DELTA * TRANSITION_DURATION / (block.number - TRANSITION_START_BLOCK_NUMBER)
|
||
|
|
```
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
2 years was chosen because it gives miners sufficient time to find alternative uses for their hardware and/or get their hardware back out onto the open market (e.g., in the form of gaming GPUs) without flooding the market suddenly. This proposal should ONLY be considered as a last resort as something we have in our pocket should the "network need to attract hashing power quickly and then bleed it off over time" rather than "something that is scheduled to be included in X hard fork" ; Recommendation to have in a fast track state, but NOT deployed to mainnet unless needed.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
There are no known backward compatibility issues with the introduction of this EIP.
|
||
|
|
|
||
|
|
## Security Considerations
|
||
|
|
There are no known security issues with the introduction of this EIP.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
Copyright and related rights waived via CC0.
|