Reward validators for participating in parachains#2089
Conversation
rphmeier
added
A3-in_progress
|
We should reward backers only when the candidate becomes available like you mentioned elsewhere. We could pay backers slightly more the fuller the availability bitfield. Any reward for availability bitfield voters should stay quite small since it maybe only represent downloading about 3/num_validators of the candidate and storing it for a day. We'd just pay them for delivering the pieces ideally, which sounds like future work but here goes.. 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 now encounter a problem that validators could (a) obtain their pieces preferentially from their friends or (b) obtain their pieces from anyone but then claim they obtained their pieces from their friends. We might address (b) using tit-for-tat: If you think someone who downloaded your piece stiffed you in its provider bitfield then you demote them somewhat in the otherwise random order in which you fetch pieces. As a result, you continue behaving honestly yourself, not stiffing anyone, but you do punish the guy who stiffed you. In fact, you've punished them enough after only one time when you skipped fetching from them and your approval vote got counted, so maybe even punishing twice buys nothing. Also they'll never know if your order uses local randomness, which makes retaliation impossible. Isn't this second argument some easy Nash equilibrium result @jonasW3F or @SamuelHaefner ? Is there anything we should worry about like extortion? We might address (a) by paying validators more based upon the aggregate distribution of their provider bitfield. We'd implement and want uniformly distributed providers but honest behavior creates a Gaussian distribution by the central limit theorem. @AlistairStewart Is there a nice statistical test for "anywhere between uniform and Gaussian" which we can reward for the actual behavior without rewarding for deviations from the implementation? We could explore tit-for-tat for (a) too: If n is the number of times Y says X provided a piece then the payout to X could be sublinear in n like n^{1/2} or even linear with a declining term, like n + n^{1/2}. If Y named X a provider more than X named Y a provider then X bumps up the probability for selecting Y. I'd suggest including provider bitfields right away but delay doing the rewards calculations until we've sorted out the distribution test question, finish higher priority things, etc. We could still pay something for the original availability vote too, well this payment might be justified by the risk that governance could manually slash you if they ask you for a disputed piece and you do not provide. |
|
Thanks for the write-up Jeff. I'll put in a small reward for each bit of the bitfield. We'll need subsystems for watching the chain and doing that tit-for-tat calculation, but that's future work. |
github-actions
bot
added
A0-please_review
Sorry, I was off yesterday. Yes, this is exactly what I was referring to in our previous discussion (I think it was in elements?, can't find an issue for this). A local reputation, system where you basically be nice to someone providing you the piece in the hope that they'll be nice to you and provide their piece. Otherwise you punish them by avoiding requesting pieces from them in the future (tit-for-tat or some other trigger strategy). I try to understand this issue more and have some questions on that:
I guess more questions than answers...sorry :) |
The punisher cannot know this but the punisher always behave honestly, never stiffs the punishee, and never does anything detectable, so this should remain a Nash equilibrium I think.
Anyone stiffing a piece provider ala (a) knows they'll be punished if the piece provider is honest.
If there are n = 3f+1 validators then there are n unique pieces of each candidate. We need 2f+1 different validators to each obtain their unique pieces from the 3ish backers before approvals start, or else we trash the candidate. Approval checkers need any f+1 pieces before they can reconstruct the candidate. I suppose cartels could make their own nodes faster or save networking costs, but a cartel with f+1 validators breaks polkedot anyways. I discussed speed bonuses in https://github.com/w3f/research-security-issues/issues/50 because they avoided O(n^2) per piece payments, making it an optimization over this scheme. If we're doing bitfields based payments then provider bitfields remain O(n^2) but have 1/2 to 1/3 the fullness of availability bitfields. In between speed bonuses and the naive accounding, one could do logarithmic bitfield accumulation, meaning we "add" provider bitfields by producing a "carry" bitfield. I implemented this in-gossip aggregation of BLS signatures in https://github.com/w3f/bls/blob/master/src/bit.rs but it's maybe even more useful here. I think someone like @drskalman could extract out the logarithmic bitfield accumulation code into some generally usable utility crate for runtime code that handles bitfields on chain. |
|
@burdges By provider bitfields, do you mean the bitfields that the validators sent to the chain, where availability bitfields are the 'aggregated' versions of specific bits in those pertaining to a particular core? |
|
No. We've no provider bitfields before this discussion. ;) An approval checker would 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 you like. 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 nicer reward metric for availability providers than availability bitfields. We've zero validation of provider bitfields however, so validators could bias the bitfield towards their friends either by semi-honestly biasing our reconstruction (a) or dishonestly by stiffing (b). We can easily punish stiffing with tit-for-tat, without even being dishonest and stiffing back, but semi-honest bias requires a more subtle tit-for-tat. |
|
Thanks for elaborating @burdges . I don't think we'll do that in this PR, but it's something to have an eye on for Polkadot economics |
|
Yes, there is some work involved in adding the provider bitfields, especially with an aggregation optimization, and the tit-for-tat protocols, so not really MVP. They look quite efficient and avoid the tragedy of the commons that eventually comes from either not paying availability voters or else paying them only for voting yes (as proposed here). |
|
We could deal with (a) using the assignment VRF instead of looking at distributions or some tit-for-tat. 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 then do the (b) first tit-for-tat with three "count fields": You also 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 for less than you think you deserved. You add a black mark count fields for them. You also attach your VRF to your provider count field. You are paid according to how many times nodes named you a provider and how well your naming of people as providers stuck to your VRF's predictions. In this, you give up some earnings to punish people, but that's probably okay. We'll postpone doing this as future work I'm sure, but it looks quite clean to me. :) |
|
bot merge |
|
Missing process info; check that the PR belongs to a project column. Merge can be attempted if:
See https://github.com/paritytech/parity-processbot#faq |
5 participants
We want to give reward points according to the schedule here: https://w3f-research.readthedocs.io/en/latest/polkadot/Token%20Economics.html
That document doesn't yet account for bitfields, but I imagine we want to record every '1' bit set in candidates that actually get included. Likewise, I only rewarded validators backing candidates that became available later on.
TODO:
RewardValidatorsthat usespallet-stakingand real values under the hood