Of course I agree. You just described how network failing will break the consensus assumptions. What’s the problem?
20 second slot time is specifically selected as a “sanity” choice that is both long enough to ensure proper signal traversal in case of a fairly healthy overall (average) network and short enough to be 3rd-gen usable.
But that’s not the same thing as you were asking initially. You were saying: “two nodes cannot reach consensus if one of them did not get a block in time”. No, they can. And that’s not the same statement as you are saying now.
Now you are saying (if I understand it correctly): “If many nodes along the whole execution will fail to receive blocks - this will break the security proofs”. Yes. All proofs assume two things:
- More than 50% of nodes are honest
- More than 50% of slots are successfully filled with blocks
All security proofs, in my understanding, are based on these assumptions and only answer the question: “how we can run a secure network, given those two properties.”
The extreme case of this problem is when network gets bad enough (cut off, for example) so that majority of nodes, already selected for slots, are not reachable. This might happen in the case of a minority subnetwork being isolated due to some problems. For now, I cannot say, with enough certainty, what will happen with the subnetwork in this case, and I don’t want to lie.
If the subnetwork gets reattached before the end of the epoch - it just follows the fork-selection rule and switches to the main-network view (all local transactions in the time of the separation are lost). For example - the same thing will happen with the bitcoin, in such a case - subnetwork will just continue to mine “lighter” blocks, and when reattached - local chain will be replaced with the main view.
If epoch end happens during separation - it gets very much more complex and I don’t know enough details. Will be glad if someone can link some sources about it (or code).
P.S. Have you read “Ouroboros Praos”? I haven’t got to it yet, so I might miss some details, but it specifically called “semi-synchronous proof-of-stake protocol”. You might find some answers there.
I am not competent enough in a “time-server decentralisation” topic to have any credible opinion about this. I guess we can just use multiple independent global time providers. There are enough of those.
P.P.S. Next time please try to provide as much details with your question as possible from the beginning. The discussion looks like I’m trying to forcefully pull what you actually want to know out of you )