Correct validator rewards

[burdges]

A draft RFC for paritytech/polkadot-sdk#1811

Rendered

At a high level the points:

Relay chain block production matters, and should be paid reasonably, and better than any one parachain, but afaik 10% or 15% or 20% matters little.

This protocol requires only one new message type, but incurs some internal overhead in data collection, especially for the availability parts.

Approval checker rewards must be computed by an off-chain median protocol, because althoug hte machine elves gadget could run on-chain, doing so creates something biased and gives wrong results.

Approval checker statement must be paid strictly better than backing statements. I propose backers being paid only 80% of what approval checkers get paid, which winds up being 87% after other details.

Backers should never be paid unless the approval checkers get paid. Also neither should be paid unless the inclusion block gets finalized. This means there is not much point in computing the backers rewards on-chain, just add them in the new off-chain system for approval checkers rewards.

Availability re-distribution should also be paid by an off-chain protocol, but it's nastier than the approval checker one. We could postpone this in an initial implementation, or do the data collection and messaging, but omit the tit-for-tat strategy. Yet long-term validators do incur some bandwidth costs from availability redistribution so this avoids a nasty tragedy of the commons.

Availability distribution cannot really be paid fairly, so backers reduced rewards must cover this bandwidth cost.

In both those, we're seemingly paying more for compute than bandwidth, dispite bandwidth being more expensive than compute. This is not really avoidable, so really we're merging bandwdith and compute rewards, but providing some extra bandwidth rewards in one niche case.

Non-laziness hashes ideas are split off into https://github.com/burdges/Polkadot-RFCs/blob/nonlaziness/text/0000-nonlaziness.md

[burdges]

Implementation stages:

1. Approvals:
   a. Extract used approvals from machine elves gadget
   b. Send the message
   c. On-chain median computation
   d. Fix rewards, including replacing existing backing rewards
2. Availability:
   a. Extract sent and recieved chunks information, add to used approvals record
   b. Add to used approvals message
   c. Off-chain rewards & stiffed computation
   d. Tit-for-tat record storage
   e. Tit-for-tat punishments
   f. On-chain rewards computation

Alone, approvals rewards suffices to incentivise validator hardware upgrades. Availability rewards just disincentivise nodes from shirking availability duties. We'll want availability rewards eventually, and they help paritytech/polkadot-sdk#5334 (comment), but if we delay doing it, then maybe 2a and 2b would be worth doing early, just to save ourselves on upgrade work later.