-
Notifications
You must be signed in to change notification settings - Fork 783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate prioritization of confirm_req by voting weight #2128
Comments
related to #2113 |
Do principal rep nodes respond to confirm_req with just their own weight or do their responses also include votes they’ve seen from other nodes? During normal voting don’t they rebroadcast votes? So if they don’t include other nodes votes could that be changed so they do include them as a response to confirm_req? That could add a 4th option to send confirm_req to sqrt of all principal rep peers if the response includes votes from other reps. The problem I see with any limits using sqrt of peers is if they only respond with their own weight then eventually the big reps would need to be sent a confirm_req in order to reach quorum, so might as well save the time and do it from the beginning. |
Now confirm_req is sent to all known representatives with weigth >= 0.1% of online stake (found by rep crawler) |
@SergiySW now as in v19 RC5 or was there an update to implement this? If that’s the case currently, why would active confirmations added by confirmation height processor take 120+ seconds to confirm, shouldn’t it be relatively fast to get responses from those peers and confirm the block(s)? |
From ancient versions. |
Yes, maybe getting confused by the different height confirmations. Thinking about the one that adds up to 1000 blocks to active confirmations once spam has ended and there are a large number of blocks not cemented. Those blocks take a long time to confirm. Increasing the size like is being done here I think should help. #2126 But if they still take 120+ seconds to confirm it will take a while to recover from spam still. |
Although we are looking at improvements to confirm_req behavior in V20, this prioritizing behavior is being pushed to research for a future release likely beyond that. |
@guilhermelawless Should this be considered as part of research into better active election alignment efforts? |
The current approach is: from a list of PRs sorted in descending order by weight, select the first N (currently about 30) that we don't have votes for, and send a request to these. This process is done every 500ms, but alternating such that the process is repeated for the same block only every 2 seconds. This means it's already prioritized by voting weight. |
Thanks for clarifying @guilhermelawless. Closing out now as already in place. |
Provide details on the current prioritization, if any, for confirm_req - sqrt of random peers?
Evaluate options for improving confirm_req prioritization to help speed up confirmation times:
Need to consider the additional resource consumption impacts of heavy weight nodes if not doing a random selection.
The text was updated successfully, but these errors were encountered: