Approvals usage collection #3
Conversation
While getting approvals usages from candidates entries it checks if the candidate was included in a block that is currently finalized, avoiding collecting approvals usages from candidates that was from non-finalized blocks
| let is_new_session = match state.last_session_index { | ||
| Some(last_session) if finalized_tip.session() > last_session => true, | ||
| Some(_) => false, | ||
| None => true, | ||
| }; |
There was a problem hiding this comment.
Is possible while finalizing to finalize more than one session?
| } | ||
|
|
||
| #[derive(Clone, Debug)] | ||
| struct ApprovalsTally((SessionIndex, Vec<ApprovalTallyLine>)); |
- Implement approvals tally message signing - Implement medians calculation - Implement medians message signing - Implement receiving medians signed message
receive signed approvals tallies
| .any(|b_hash| finalized_hashes.contains(b_hash)); | ||
|
|
||
| if on_finalized_block { | ||
| for idx in candidate.approvals.iter_ones() { |
There was a problem hiding this comment.
This is a bit trickier than that, we can't count just the approvals because in that case, validators can game this by triggering all their tranches and approving stuff, although that wasn't used. So we need to count the approvals that were used for approving the candidate.
See for understanding how https://github.com/paritytech/polkadot-sdk/blob/c1a31e3505c0c4e01b9d2daad5f4d19b220345ec/polkadot/node/core/approval-voting/src/approval_checking.rs#L415.
There was a problem hiding this comment.
Appears this was not clear enough in the RFC. I've explained the notions of "useful" approval check more clearly before, but maybe lost in conversion to RFC format.
A validator v thinks an approval vote x on candidate c by validator u is "useful" if the ELVES approval gadget on v counted x during the run where it approved the candidate c. We only count "useful" approval checks here
The "useful" approval votes should be computed by returning some Vec<AuthId> from the ELVES approvals gadget, or maybe rerunning the gadet in some "accumulate" mode that computes this Vec, if we're afraid that computing the Vec each time the loop runs causes too many allocations.
We consider this notion of "useful" approval check in the availability part too, becuase if the approval cehck is not useful then we do not worry about those chunks being paid.
There was a problem hiding this comment.
Actually it was somewhat clear, the paragraph above spelled everything out, but I've edited the RFC to be much clearer.
5 participants
Description