Add access to incentive related consensus parameters

[jannotti]

@pbennett says:
Things I need for Reti:
❌ The 'fee' required when going online to make the account IncetiveEligible.
❌ The maximum algo amount for incentives
❌ The minimum amount for incentives would be nice as well (but not 'needed')## Status

[jannotti]

The easiest way to do this is a bunch of new global fields, and that is what I think we should do. But, it is worth considering that some callers may want these values for previous rounds which could be different. For example, in the round 1000, the actual values that determine whether the proposer can receive block rewards are the min and max values from round 680. (1000-320). So a more full-featured mechanism might be something like:

block BlkConsensusVersion
and
consensus_params_get MinPayoutBalance

The first would allow callers to determine the consensus version in effect at a given block, and the second would return the value for that consensus version.

I don't think that anyone intends to use these values in such a careful way that this is relevant right now. For example, I believe Reti wants to do something like "Don't let a voting pool exceed 90% of the max payout balance". If there came a time that the max payout balance changed drastically, that would be an issue - but the exact round that it goes into effect would not materially affect the difficulty of addressing that issue.

Further, determining the round for which the caller wants the BlkConsensusVersion is non-trivial. It is, in fact, determined by looking at the consensus version from block n-2, then using two more consensus parameters (SeedRefreshInterval and SeedLookback) from that consensus version. So doing things the precise way would be pretty complex.

[pbennett]

I think a generic global is fine (and preferred for me as well).

don't think that anyone intends to use these values in such a careful way that this is relevant right now. For example, I believe Reti wants to do something like "Don't let a voting pool exceed 90% of the max payout balance".

Exactly. The maximum for incentives is just to provide a soft (and somewhat fuzzy given the 320 round lag) ceiling to keep pools in compliance. Users aren't 'booted' out in any way it would just prevent 'more' stake other than from rewards from being added. There WILL be an option for validators to return stake to stakers (and ONLY to the staker) if they need to 'sunset' the validator. This 'could' be used for reduce stake to get back in compliance though - which might be a nice touch and one I could add to the node daemon.

Actually, this makes me wonder if some of these new consensus/incentive parameters shouldn't be part of the /ledger/supply endpoint (or possibly a new one) ?

[pbennett]

The 'fee sink' address is another one I'd like to see as an opcode.