EIP-1015: Configurable On Chain Issuance

Author	Alex Van de Sande
Discussions-To	https://ethereum-magicians.org/t/eip-dynamic-block-rewards-with-governance-contract/204
Status	Stagnant
Type	Standards Track
Category	Core
Created	2018-04-20

Simple Summary

This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would not be a generic governance solution, which is a much broader and harder topic, would not affect technical upgrade decisions or other hard forks, but seen as a forum to attempt to prevent contentious hard forks that can be solved with the issuance.

Summary

Thesis: many controversial issues boil down to resources

These are current EIPs that are being developed or debated. They might seem unrelated but they have something in common, that they can be resolved by proper channel of funds.

Casper and PoS

Moving to PoS has been on the roadmap since day 0 for ethereum, along with a reduction in issuance to a cost equivalent to the Validator’s cost of security (considered to be more eficient than PoW). But the exact issuance necessary for PoS has yet to be determined and is currently being researched. Casper validation will be an on chain contract and therefore it will need to be funded. It’s unlikely that a definitive final answer on how much issuance is needed for validation will be reached in the next years as new research will uncover new arguments, so it would make sense to allow some flexibility on this matter

Issuance Cap at 120 Million

EIP-960, Vitalik’s not so jokey april’s fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by we don’t know enough to know what that ether can be used for and Vitalik’s counterpoint is that reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0. Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider not issuing as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision.

Asics and advantages of PoW

EIP-960 proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than resisting economies of scale is futile and there might be specific security advantages to specialized hardware. One of the main arguments for PoW mining, even when it doesn’t provide security, it is useful as a fair distribution mechanism, that PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls.

Recovery Forks

After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: a general protocol improvement to allow reviving self destructed contracts (which was considered dangerous), a general process to recover funds and a specific recovery of the multisig library. The latter two are finding a lot of resistance from the community, but it’s unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it’s an issue that is likely to occur again in the future. If they get reimbursed, there are many other special cases of ether provably burnt or stuck that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it’s likely they’ll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers.

Other Public Goods

There are many other types of public goods that could be funded by issuance. By Public Good, I’m using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, incentivize full clients and networking, fair distribution of tokens etc.

Proposed Solution

Issuance Contract

This EIP proposes a future hard fork where block reward is not issued to miners/validators etherbase, but instead to a single contract, that then will activate the default function (with a fixed amount of gas) and then it will forward the ether to other contracts which will finally distribute to their final destinations.

Limits on the contract

It can only deal with issuance

It’s not meant to be a general governance contract. The contract should NOT be used to to decide software updates, to freeze funds, change contracts balances or anything on the consensus layer other than the strict definition of where block rewards go. It should be seen as a platform to settle disputes to avoid the implementation of contentious hard forks, not as a mean to remove the power of users and developers to execute them.

It cannot only decrease issuance, and once decreased it cannot be increased again

In order to reduce future abuse and uncertainty, once issuance is reduced, it cannot be increased. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the decision assembly is aggressively to reduce issuance to zero, it would take a known number of years.

Results are locked for six months

Whenever a new decision on either reducing the issuance or changing the target is made, the effects will have a six month delay to it. Once a decision is made it is final, it will take place six months after that, but if it’s shortly reversed, then that change will be short lived. The rationale behind is that it allows time to anyone disagreeing with the decision to:

• Sell their coins so that if a bad actor takes over they will have a reduced reward
• Attempt to revert the decision as soon as possible, to reduce the duration that the change will take place
• Organize to create counter measures against the decision
• Implement a hard fork changing the decision contract or to remove the issuance contract altogether, as a last resort measure

Interface

It would have the following interface:

function targetContract() returns (address)

There’s a single target contract that should ether issued to. At each new block, that contract would have the default function called so it would forward to the intended addresses.

function decisionAssembly() returns (address)

A contract that would represent the internal governance of decisions. More on this later.

function reduceIssuance(uint)

Can only be called by decision assembly. The contract is allowed to reduce or maintain the issuance per block. Change is not executed immediately, effects only happen six months later, but once a decision is committed it is irrevocable.

function changeTargetContract(address)

Can only be called by decision assembly. It changes the contract that will receive the funds in the future. Only one contract can be appointed, but if the community desires to split issuance or even burn a part of it (in a non-irrevocable manner) it can be done in that contract. Change is not executed immediately, effects only happen six months later, but once a decision is committed it is certain, even if it’s later reverted: if a new target contract is changed after a few hours, then it still means that in six month’s time, it would issue for that contract for a few hours.

function executeDecision(uint)

Can be called by anyone: it executes a change to issuance amount or target that had been scheduled six months prior.

Decision Assembly

A contract that has the power to decide the changes to issuance, the core of the governance of these decisions. The exact format of this governance is open to debate, but what follows is a suggestion:

The decision would be made by multiple signalling contracts, each one implemented by separate groups and representing one aspect of the community or one sort of measurement. Each signaling process would have a int bound in which they could vote and they would have their own internal process to decide that. As new governance methods are tested and debated, new signalling contracts should be added and removed. Suggested signalling contracts:

• Futarchy and prediction markets based on multiple measures
• Votes weighted by ether balance (optionally with multipliers if the voters where committed to locking votes)
• Token votes, weighted by their own relative ether exchange rate
• Votes by individual humans if a good sybil resistance, coercion mechanism is developed
• Block-signalling, as a way to measure validators/miners choices
• Some sort of signalling representing developers, exchanges or other stakeholders
• Any other proposed manner

Since adding and removing signalling contracts, as well as changing their total weight would be controlled by the contract itself, it would be crucial that the first signalling contracts were a diverse set of interests, and that they were open to adding more signals as new governance is experimented as well as removing signals that stop representing the community.

Questions to be debated

A lot of things are suggested in this EIP, so I would like to propose these questions to be debated:

1. Do we want to have dynamically changing block rewards, instead of having them be hard coded in the protocol?
2. If the answer above is yes, then what would be the best governance process to decide it, and what sorts of limits would we want that governance contract to have?
3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the process to add and remove them?

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Alex Van de Sande, "EIP-1015: Configurable On Chain Issuance," Ethereum Improvement Proposals, no. 1015, April 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1015.