Explaining the liveness guarantee

One very concrete example of this actually happened last week at the start of the Medalla testnet launch. At the beginning, only ~57% of validators were online, because many validators did not yet realize the network had started (there were also some client failures accounting for a few percent). But the network did not stall as a result; instead, it kept on proceeding, though without finality, and the blocks were finalized once the percentage online got back up to 2/3. For plenty of applications this approach is sufficient, and would actually have given those applications much better performance than if the chain just completely stalled.

The general principle is that you want to give users “as much consensus as possible”: if there’s >2/3 then we get regular consensus, but if there’s <2/3 then there’s no excuse to just stall and offer nothing, when clearly it’s still possible for the chain to keep growing albeit at a temporarily lower level of security for the new blocks. If an individual application is unhappy with that lower level of security, it’s free to ignore those blocks until they get finalized.

3 Likes