# Incomplete rewards

# Validator rewards in Polkadot/Kusama

Idealy almost all rewards in Kusama/Polkadot would come from work done securing parachains, including work supporting XCMP. We should continue some rewards for relay chain block production and finality of course, but their levels shall be greatly reduced.

We have several plausible archetectures for rewards along two axes, rewarding only tranche zero vs all tranches, and rewarding deterministically vs probabaistically.

1. *Reward all tranches for all candidates*
We'd rerun the approvals loop on-chain after approvals happened off-chain, which avoids requiring good randomness. We worry this looks heavy, so we'd likely do this as a system parachain, which adds complexity.

2. *Reward all tranches but only for random candidates*
We'd likely never do this since its our most complex option, do to both sampling code and running the full approvals loop, but it provides a mechanism for the relay chain to non-zero tranches.

3. *Reward only tranche zero and only probabalistically*
We randomly sample tranche zero assignments and reward those apporoval checkers.

We risk validators avoiding delay assignments by running modified code *if* we only reward tranche zero assignments. In the near term though, we need rewards that push validators into running sufficent hardware. We could therefore proceed with only a tranche zero solution provided that rewarding only tranche zero turns out much simpler than doing a system parachain.

We risk validators biasing randomness by running modified code *if* we deploy a probabalistic solution without adopting stronger randomness. We'll only use strong-ish epoch randomnesses here, but maybe worthwhile if approvals represent most rewards. We could leave approvals rewards lower than desired short term of course.

# Validator rewards: Notes on rewarding all tranches for all candidates

an incomplete probabalistic model and a thurough system parachain.

### System parachains

We want relay chains to do little as possible besides tyheir core task of coordinating parachains. It follows that all heavy functionality like accounts and elections should ideally be moved off the relay chain onto parachains.

All parachains receive soundness assurances from polkadot, but we also have important "system parachains" that benefit from some liveness assurances, including defense against censorship and capture.

There is no

We do however need liveness assurances beyond

System parachains perform essential task

relay chain itself should only manage

We need system parachain perform handle opertions essential

In polkadot, we perform some essential system
System parachains

consit of wanna-be validators who ..

### Approvals

We reward approval checks using a special approval rewards system parachain, which internally works in partial blocks that concatenate into parachain blocks. It'll ultimately distribute significantly more validator rewards than any other source.

After a relay chain block $R$ gets finalized, the approval rewards system parachain creates an partial block consisting of all approval asignments and validity votes that approved finalizing $R$. We require that a partial block for $R$ prove that $R$ is approved. We could exclude any unnecessary approval asignments, but we must not exclude any necessary approval asignments, including a no-shows.

All validators have accounts on the approval rewards system parachain that contain a counter of the number of partial blocks they approve. We increment these counters when processing partial blocks.

Internally, we structure partial blocks using Merkle trees whose leaves are parachain candidates together with their votes. We maintain a Merkle mountian range of past partial blocks in the approval rewards system parachain.

We have a correction transaction that prove a past partial block omitted some necessary approval asignment. It should update all rewards appropriately and update this Merkle mountian range, so that repeated corrections work.

We'd prefer but do not require that correction transactions maintain approved state. If approved state reverts and fails indefinitely then presumably the relay chain would detect the ploblem too, halt all parachains, and governance would intervene.

After two epochs, we sweet all rewards from two epochs ago into more permenent counters and/or messaged to the relay chain.

### Availability

We

### Backing

be rewarded by placing the approval assignment and validity vote together onto a parachain itself, and running

We should reward backing, availability, and approval checking. Among

We reward backers when a candidate becomes available.

We should reward backers only when the candidate becomes available. We'll initially reward for availability bitfield voters but doing so should creates a small tragedy of the commons in which they distribute nothing. We should instead reward them for delivering the pieces, which appears possible via a tit-for-tat game using VRFs.

Idea: Approval checkers could select from whom they fetch pieces randomly and claim from whom they obtained pieces in their approval vote, called a "provider bitfield". We trust and blindly sum provider bitfield for rewards computations with zero validation, but punish stiffer using a tit-for-tat game, and punish biasers by rewarding more if their random actions agree more with their VRF.

...

Approval checkers compose, and attach to their approval vote, a "provider bitfield" that identifies whose pieces they used in reconstruction, so a provider bitfield must have exactly f+1 bits set since reconstruction works with exactly f+1 pieces. In fact, they could aggregate the provider bitfields across many approval votes if one likes.

If you "sum" the provider bitfields from all approval checkers across an entire epoch then you obtain an aggregate votes saying which validators more readily provided their pieces for approval checkers. This is a far nicer reward metric for availability providers than availability bitfields.

As we fixed one problem, we now encounter two problems that validators could either (a) obtain their pieces preferentially from their friends, so semi-honestly bias reconstruction, or else (b) obtain their pieces from anyone but then claim they obtained their pieces from their friends, so dishonestly stiff the real provider.

We punish stiffing (b) with tit-for-tat, without even being dishonest and stiffing back. Yet, semi-honest bias (a) requires subtlety, slightly reduce rewards if provider bitfields differ from verifiable expectations.

...

At the beginning of the epoch, you seed ChaChaRng with a VRF output based on the epoch randomness and then use the block number and core for the chacha nonce. This gives you an Rng that tells you the order in which you fetch pieces from different validators, assuming they vote that they have the piece.

We implement the stiffing tit-for-tat (b) with three "count fields": You have a black mark count field from the previous epoch based upon which you occasionally skip nodes that pop up in your fetch priority. If you skip one then you remove one black mark against him. You track you own cumulative provider count field, as well as a providee count field of what contributions you expect others to credit you for.

After the the epoch, you all post your provider count field accumulated over the epoch, and then you figure out who credited you less than you think you deserved. You increase their black mark count fields entry for each skip, meaning you'll return the skip eventually. You also attach your VRF to your provider count field.

You are paid according to primarily how many times nodes named you a provider and secondarily how well your naming of people as providers stuck to your VRF's predictions.

In this, you give up earnings to punish people by returning the skips in your black mark count field, but much less than they loose by not being your provider. We do not track availability bitfields so some nodes loose money whenever nodes skip availability voting, but only tiny amounts.