- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.
Here is my reasoning:
Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.
Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.
Network latency isn't an issue if you apply some simple ruling to delegate selection.
You are correct that it is impossible for all nodes to know the current set of delegates if they are selected below a certain interval, in real time, due to CAP theorem.
However, if you base the set selection on an offset of time in the past, say 60 seconds, you can be sure that the majority of the network has information on transactions up to 60 seconds ago. Thus you select the delegates from a set between say T-60 and T-120 (if you want a set duration of 1 minute).
This approach allows you to have per second delegate set generation, as it provides a "sliding window" over time.