I think this is a fundamental tradeoff in fault tolerant consensus protocols. (Thread!) 
Consensus protocols that only create finalized blocks have low latency and parametrizations in the purple area below (though their overheads for any different node counts may vary).
E.g. Tendermint, HoneyBadger BFT, Dfinity, pbft
E.g. Tendermint, HoneyBadger BFT, Dfinity, pbft
Traditionally, blockchain protocols have no finality, but can have an arbitrarily high number of consensus-forming nodes with the same incredibly low protocol overhead.
E.g. Nakamoto Consensus, PPC, NXT, Snow White, Ouroboros and many other PoS protocols
E.g. Nakamoto Consensus, PPC, NXT, Snow White, Ouroboros and many other PoS protocols
Casper the Friendly Ghost's parametrization, on the other hand, can explore the tradeoff space in all the directions!
It can't avoid making the tradeoff (no one can), but perhaps in the middle of the tradeoff triangle we can find a parametrization with a reasonably low latency to finality, reasonably large number of validators, and reasonably low overhead.
Notably, in the case of maximally low overhead for any number of validators, the latency to finality is finite (though unbounded), unlike in Nakamoto consensus or most proof-of-stake protocols, which have no finality (or, if you like, infinite latency to finality :P).
The overhead that we're talking about here is bandwidth overhead, on a per block (or per decision or per second) basis.
To talk about Casper the Finality Gadget, we should be clear about whether the overhead's basis is per underlying PoW block (in which case its parametrizations can explore the tradeoff fully), or per decision (in which case it's like pbft and is stuck to one side of the triangle)
I would love to hear about whether @Swirlds can explore the whole triangle. What's the lowest possible number of messages required for a decision? Can it do something like this?
