Number of nodes and voting round time

Trying to get some concrete numbers on things used in the Avalanche consensus:

1 - Would we really store connections for potentially million nodes? Most linux systems by default have 1024 maximum file descriptors, what’s the memory cost to that many connections? Bitcoin/Ethereum only store around 100 connections.

2 - How long do individual voting rounds take, there must be some upper bound of the time to wait for all responses (in case of lost messages)? If we assume that latency is 200 ms for a cross-globe peer (and an upper bound of 400ms) and I think I read it can be up to 20 rounds in case of many byzantine actors, that means 8 seconds to get a confirmation which seems pretty slow. We can’t start a new round if others may still be in the process of a round otherwise we can be polling old data.

“Would we really store connections for potentially million nodes?”

No, every node will not be connected to every other node.

“How long do individual voting rounds take, there must be some upper bound of the time to wait for all responses (in case of lost messages)?”

If a message should result in a response from a peer (a query message, for example) then there is a timeout. That timeout is dynamic.

“that means 8 seconds to get a confirmation which seems pretty slow. We can’t start a new round if others may still be in the process of a round otherwise we can be polling old data.”

A few things to note here. One is that validators are sampled in proportion to their stake, and validators don’t want to lose their staking reward by being byzantine. Another is that we don’t actually need to get a response from every peer before concluding a voting round. For example, is the voting sample size is 20 and the quorum size is 15, and all of the validators respond affirmatively to the query, we can finish the voting round when only 15 validators have responded. This further reduces the ability of an adversary to stall consensus.

1 Like

One addition to Dan’s great answer:

You can have multiple polls concurrently running. It does change the probabilistic measurements… But it’s a useful trick that we currently employ.