Add Dispatchable Interface for Staking's `reward_by_ids` and `report_offence`

[joepetrowski]

The Staking pallet provides a function for other modules within the runtime to reward era points to validators. Some remote service may want to grant validator era points for its service providers, for example a system chain's collators or a bridge's relayers.

Staking should have a dispatchable call with privileged origin (i.e. origins that the system deems worthy of validation points) to increase an account's era points.

Likewise, Staking should also provide an interface into reporting offences.

(cc @georgepisaltu and @gpestana )

[bkchr]

This assumes that validators of the relay chain are also running collators on a system chain? Is this economically thought through? Isn't this some form of restaking?

[bkchr]

My argument about restaking makes no sense as collators are not providing security. But still not sure about rewarding collators on the relay chain. This would change the reward distribution.

[joepetrowski]

Economically we are already paying bounties from the Treasury for system collators, which more accurately cover operating costs but are dependent on governance to approve the allocations. Tying the activity to era points reduces risk for collators. But I see your point about restaking, something Jonas can evaluate.

Nonetheless, I think with validators on the Relay Chain and staking on a parachain, we will need this API for the RC to send points/offences to the staking chain?

[jonasW3F]

I don't think this qualifies as restaking, because the stake from the RC validators are not used as collateral at any other place / the parachains. I.e., there is no “economic security” drawn from the same stake twice or more. As long as this is the case, I don’t see any implication for security.

I see the point that it creates some overhead to constantly manage collator funding from treasury bounties and that collators might be worried to get their funding (are they really in practice?).

There are, however, a few problems that come to mind with this specific idea of tying collator rewards into the era rewards distribution of RC validators:

1. Right now, era points are only awarded for active validators. For this new system to work, as we cannot expect all collators having an (active) validator, we’d need to break this convention and award era points outside the active set of validators. This seems a bit messy to me?
2. To be competitive a validator would want to run a collator (given the incentives are sufficient). But, especially after scaling up the number of validators, I don’t think there is a need for that many collators. You could argue that there will be some equilibrium number of collators based on the incentives posed. But afaik it’s not trivial to enter the collator sets of system parachains. Also, I am not aware of much benefit of putting harsh competition between collators.
3. My main concern is that this would economically tax the stakers disproportionally, instead of all token holders. Since system chains are useful for everyone, I believe everyone should pay their share. That means, funds should still come from treasury.

Having said that, I think the idea of paying collators automatically (and also proportionally to the work they do) is interesting. We could repurpose the mechanism of gathering era points and integrate it with treasury spending.

Simply put, governance could decide on a fixed budget of DOTs that are used for the incentivation of collators per era. Then, each collator may withdraw DOTs directly from treasury based on their share of collator_era_points relative to the sum of collator_era_points.

This would leave the current incentivation of RC validators untouched, but still allows for automated payment of collators. Further, it makes it easier to incentivize robust hardware / infrastructure.

The mechanism might also come in handy for several other applications (e.g., bridge relayers, LP incentives, etc.). Once we get more certainty about the treasury inflow, the treasury can directly fund all these buckets first and leave the rest to be distributed through the common approach of funding proposals.

[gpestana]

I agree with many of points that Jonas raised and highlight the fact that collators would need to be validators too in order to be able to request rewards from the inflation with the current implementation. I'm also wary of how would we reasonably gate the issuance (to whom, how many?) of the era points to collators and the reward dilution for validators era that would come from that.

If we want the collators to have be paid directly from inflation, I think we should think of a similar strategy to what is being proposed to mint partial inflation into treasury , where a % of the era inflation is assigned to collators and then build a flow that would allow collators to be paid from the collator era points "pot".

[kianenigma]

Nonetheless, I think with validators on the Relay Chain and staking on a parachain, we will need this API for the RC to send points/offences to the staking chain?

Not really, the reward logic would be local to the staking chain as well. The staking chain will report the validators of an era to the relay chain, and then handle all reward related logic locally.

---

What is the immediate use-case for which we need this? If it is a matter of paying collators, I think it is easier to

1. have the relay chain governance send funds to any system chain that it wants to pay.
2. A lean pallet/SC on the system chain would receive the funds and distribute them to the collators.

This is one option. If the reward distribution logic is very similar to what staking does (eg. payout_stakers extrinsic's logic), then it is possibly to do exactly what you said, and in fact break this assumption that @jonasW3F mentioned:

Right now, era points are only awarded for active validators. For this new system to work, as we cannot expect all collators having an (active) validator, we’d need to break this convention and award era points outside the active set of validators. This seems a bit messy to me?

We can abstract the reward payout into a separate pallet that only provides interfaces for:

1. recording rewards for anyone (validator or not validator) via points.
2. payout_stakers to collect.

Staking would use this. Collators would also use this. And they don't need to be validator on the relay chain. They will receive their funds on the relay chain as DOT, as a part of inflation. They are subject to the same 72 day expiry period.

---

I am less sure about your ask about reporting offence though. In order for offence to make sense, we need to go back to the assumption that the relay chain validators are the same entities as collators.

[joepetrowski]

where a % of the era inflation is assigned to collators and then build a flow that would allow collators to be paid from the collator era points "pot".

That was actually my original idea and we decided against it (the thread is here and was summarized in RFC-7). It doesn't scale well nor provide incentives in the way we want.

Not really, the reward logic would be local to the staking chain as well. The staking chain will report the validators of an era to the relay chain, and then handle all reward related logic locally.

Can you clarify? I interpret this as a contradiction - as in, the reward logic is local to the staking chain but the reward logic is local to the relay chain.

---

I also think this discussion is too focused on rewards and not enough on offences. The system could have foreign (even bridged) chains where Polkadot dictates the validator set and that they must have some stake on Polkadot (even if not currently elected as a Polkadot validator in the active era). There may be offences (like equivocation) on the foreign chain that could be reported to Polkadot, and Polkadot could either slash them and/or remove them as validators from the foreign chain.

Likewise with rewards, I did not suggest that all collators should be rewarded using points. I think RFC-7 still stands and is the result of many discussions about system collator economics. However, there could be some system chains where tying some activity (not even strictly collation) to inflationary rewards exist. Recall that these functions would obviously have privileged origins, and it would be up to the Fellowship to configure system runtimes to call into these functions and up to governance to accept the changes.

So to clarify, I am not suggesting that era points and offences replace the current means of subsidizing collation, merely that this API exist as it will be useful in some cases.

[gpestana]

One option I see to implement this is to refactor out both the 1) era point tracking from staking and 2) offences from staking into a new pallet (pallet-inflation perhaps?) that exposes an interface (for staking) and extrinsics/xcm for system parachains to use. The logic to request, allocate, keep track of system-wide era points and reward DOT based on era points would be lifted from staking and implemented by this new pallet, as well as the logic of queuing and applying slashes.

This way, staking and priviledged system parachains could request for accounts to accrue era points and to queue/apply slashes.

If we pursue this or other direction, it would be great to keep in mind a potential future use in the staking parachain world too, so that we move towards that goal.

[joepetrowski]

Yeah, whatever we do should be with a staking parachain in mind. No reason to introduce some debt here with an API that we'll need to break to use in a parachain.

Separate pallet for points tracking is fine, although calling it pallet-inflation doesn't make sense to me.

[Ank4n]

where a % of the era inflation is assigned to collators and then build a flow that would allow collators to be paid from the collator era points "pot".

That was actually my original idea and we decided against it (the thread is here and was summarized in RFC-7). It doesn't scale well nor provide incentives in the way we want.

Can you explain this more on why we decided against it?

---

The way I imagine this (very similar to Kian's suggestion), there is a pallet-rewards that is provided a budget of DOTs for an era, tracks era points for each validator and rewards them based on total era points and the budget. This budget today would be minted and provided by staking pallet to pallet-rewards for validator rewards on RC. For system chain collator rewards, this budget can be via configuration provided either by treasury and then sent to System Chain or RC minting the budgeted dots every era (or a set of eras) and teleporting to SC. This way minting happens only in one place and pallet-rewards can be reused in every system chain.

The future staking parachain would also receives budget for validator rewards for each era (by RC today but may be some day by AH) and distributes reward locally in the staking chain in the keyless account derived from stakers AH address. The reward for foreign staked dots (locked and staked from AH) can be claimed back to AH by just a XCM transfer instruction.

[joepetrowski]

Can you explain this more on why we decided against it?

Basically what Rob wrote in the post:

Materially, it doesn’t seem to me that there is much difference in computing this on the front-end of inflation or on the back-end of the treasury. Couldn’t we also consider alternative models where the treasury votes to send DOT to system parachains, to be distributed as rewards to the collators of those parachains?

The reason I bring this up is that, as you point out, parachain collators don’t provide any service except for liveness & censorship resistance. As such, I believe that the amount of rewards for system parachain collators should be relatively low - 20% of inflation seems quite high to me. Furthermore, since opportunity costs are less of a factor without a need for slashing, it seems to me that the rewards per system chain should be based on the real costs operational nodes for system chains undertake. This will vary heavily from one chain to the next - something like Statemint is extremely lightweight compared to e.g. a storage chain and I think we’d want to give the treasury the ability to budget accordingly.