forked from DecentralizedClimateFoundation/DCIPs
86 lines
3.2 KiB
Markdown
86 lines
3.2 KiB
Markdown
|
---
|
|||
|
eip: 698
|
|||
|
title: OPCODE 0x46 BLOCKREWARD
|
|||
|
author: Cody Burns <dontPanic@codywburns.com>
|
|||
|
discussions-to: https://github.com/ethereum/EIPs/issues/698
|
|||
|
status: Stagnant
|
|||
|
type: Standards Track
|
|||
|
category: Core
|
|||
|
created: 2017-08-28
|
|||
|
---
|
|||
|
|
|||
|
## Simple Summary
|
|||
|
|
|||
|
This EIP adds an additional opcode to the EVM which will return a finalized blocks reward value.
|
|||
|
|
|||
|
## Abstract
|
|||
|
|
|||
|
In the EVM, the 0x40 opcodes are reserved for `Block Information`. Currently reserved opcodes are:
|
|||
|
* `0X40 BLOCKHASH`
|
|||
|
* `0X41 COINBASE`
|
|||
|
* `0X42 TIMESTAMP`
|
|||
|
* `0X43 NUMBER`
|
|||
|
* `0X44 DIFFICULTY`
|
|||
|
* `0X45 GASLIMIT`
|
|||
|
|
|||
|
This EIP would add an additional opcode, `0x46 BLOCKREWARD`, which would return the block reward for any finalized block. The finalized block reward would include the base reward, uncle payments, and gas.
|
|||
|
|
|||
|
## Motivation
|
|||
|
|
|||
|
|
|||
|
Per EIP-649 ( #669 ) periodic block reward reductions/variance are now planned in the roadmap, however, this EIP is consensus system agnostic and is most useful in decentralized pool operations and for any contract that benefits from knowing a block reward payout(i.e. Merge mined tokens)
|
|||
|
|
|||
|
## Specification
|
|||
|
|
|||
|
After block `n` all clients should process opcode `0x46` as follows:
|
|||
|
|
|||
|
* Value: `0x46`
|
|||
|
* Mnemonic: `BLOCKREWARD`
|
|||
|
* δ:` 0` nothing removed from stack
|
|||
|
* α:`1` block reward added to stack
|
|||
|
* Description: `Get the block's reward emission`
|
|||
|
* GasCost: `G<sub>base</sub>`
|
|||
|
|
|||
|
Where:`µ'<sub>s</sub>[0] ≡ I<sub>HR</sub>`
|
|||
|
|
|||
|
|
|||
|
## Rationale
|
|||
|
|
|||
|
### Contract Mining Pools
|
|||
|
|
|||
|
For distributed consensus systems(staking pools and mining pools) ad hoc groups combine resources in order to reduce variance in payouts. Broadly, pool operations function by allowing a collective of miners / stakers to verify their contribution to solving PoW or staking share by periodically submitting solutions which are is representative of the miners probability of finding a true block.
|
|||
|
|
|||
|
In all these schemes `B` stands for a block reward minus pool fee and `p` is a probability of finding a block in a share attempt ( `p=1/D`, where `D` is current block difficulty).
|
|||
|
|
|||
|
Some common methods of mining pool payout are pay-per-share, `R = B * p`, proportional [`R = B * (n/N)` where `n` is amount of a miners shares, and `N` is amount of all shares in this round.], and pay-per-last-N-shares [`R = B * (n/N)` where miner's reward is calculated on a basis of `N` last shares, instead of all shares for the last round]. All of these methods are predicated on knowing the block reward paid for a given block. In order to provide a trust minimized solution, `0x46` can be used to call a blocks reward for computing payouts.
|
|||
|
|
|||
|
### Merge mined tokens
|
|||
|
|
|||
|
Contracts could create tokens which could be variably ‘minted’ as a function of block reward by calling `0x46`
|
|||
|
|
|||
|
## Backwards Compatibility
|
|||
|
|
|||
|
|
|||
|
### Currently deployed contracts
|
|||
|
|
|||
|
No impact
|
|||
|
|
|||
|
### Current clients
|
|||
|
|
|||
|
This EIP would be incompatible with currently deployed clients that are not able to handle `0x46` and would process all transactions and block containing the opcode as invalid.
|
|||
|
|
|||
|
Implementation should occur as part of a coordinated hardfork.
|
|||
|
|
|||
|
## Implementation
|
|||
|
|
|||
|
|
|||
|
## Further reading
|
|||
|
|
|||
|
[Mining Pools](https://en.wikipedia.org/wiki/Mining_pool)
|
|||
|
|
|||
|
The Yellow Paper Appendix H. Virtual Machine Specification section H.2
|
|||
|
|
|||
|
## Copyright
|
|||
|
|
|||
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|