safety and liveness

Safety and liveness are the two fundamental guarantees any consensus protocol is measured against, and almost every design choice in this field is a trade-off between them. Safety means 'nothing bad ever happens': honest nodes never finalize two conflicting histories, so once something is settled it stays settled. Liveness means 'something good eventually happens': the chain keeps making progress, accepting and finalizing new transactions rather than grinding to a halt. A useful intuition is that safety is about never being wrong, and liveness is about never being stuck.

The two are in genuine tension because real networks are unreliable. A classic impossibility result (FLP) shows no deterministic protocol can guarantee both safety and liveness in a fully asynchronous network where messages can be arbitrarily delayed. Practical systems therefore assume partial synchrony and then choose which property to sacrifice during a severe network partition — the same dilemma the CAP theorem describes for databases. You can have a chain that always stays consistent but may freeze, or one that always keeps moving but may temporarily fork.

Different blockchains pick opposite sides. Tendermint and PBFT-style chains are safety-favoring: under a bad partition they halt rather than risk finalizing conflicting blocks. Bitcoin and Ethereum's fork-choice layer are liveness-favoring: they keep producing blocks through disruptions, accepting transient forks that the fork-choice rule later resolves. Ethereum is a nuanced hybrid — its LMD-GHOST layer prioritizes liveness while Casper FFG provides safety on checkpoints, and the inactivity leak is precisely the mechanism that trades a little safety (allowing partitioned forks to finalize separately) to recover liveness after a large outage.