Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add opcode 0x46 blockreward #700

Merged
merged 4 commits into from
Mar 8, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions EIPS/eip-698.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
---
eip: 698
title: OPCODE 0x46 BLOCKREWARD
author: Cody Burns <[email protected]>
discussions-to: https:/ethereum/EIPs/issues/698
status: Draft
type: Standards Track
category: Core
created: 2017-28-08
---

## 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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this list relevant to the current EIP?

* `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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is possible to get the "final" block reward for the current block since total gas usage cannot be known in advance.


## 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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EIP-649 is now Final. You may want to update the text to reflect this.


## 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the total reward cannot be known for the current block, it may be more useful to:

It may be possible to implement this change similar to how #210 is done, that would make it clear that all this detail can only be retrieved for past blocks.

* 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](https://creativecommons.org/publicdomain/zero/1.0/).