Evaluate prioritization of confirm_req by voting weight

[zhyatt]

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:

• Simply find sqrt of directly connected peers and grab that number of peers with the most weight?
• Set a floor below which peers won't be used and stick with random sqrt from that subset?
• Setup tiered system with groups of heavy/medium/light weight nodes, and select evenly from these? Select more heavy, less medium, fewest light?

Need to consider the additional resource consumption impacts of heavy weight nodes if not doing a random selection.

[zhyatt]

related to #2113

[Srayman]

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.

[SergiySW]

Now confirm_req is sent to all known representatives with weigth >= 0.1% of online stake (found by rep crawler)

[Srayman]

@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)?

[SergiySW]

From ancient versions.
Confirmation height processor is not adding any new elections. Not sure what do you mean. frontiers confirmation may be?

[Srayman]

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.

[zhyatt]

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.

[zhyatt]

@guilhermelawless Should this be considered as part of research into better active election alignment efforts?

[guilhermelawless]

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.

[zhyatt]

Thanks for clarifying @guilhermelawless. Closing out now as already in place.