Question: I've read Lamport's [paper](http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf) on Paxos. I've also heard that it isn't used much in practice, for reasons of performance. What algorithms are commonly used for consensus in distributed systems?

Answer: 
Paxos is *optimal* in terms of performance of consensus protocols, at least in terms of the number of network delays (which is often the dominating factor). It's clearly not possible to reliably achieve consensus while tolerating up to *f* failures without a single round-trip communication to at least *(f-1)* other nodes in between a client request and the corresponding confirmation, and Paxos achieves this lower bound. This gives a hard bound on the latency of each request to a consensus-based protocol regardless of implementation. In particular, Raft, Zab, Viewstamped Replication and all other variants on consensus protocols all have the same performance constraint.

One thing that can be improved from standard Paxos (also Raft, Zab, ...) is that there is a distinguished leader which ends up doing more than its fair share of the work and may therefore end up being a bit of a bottleneck. There is a protocol known as Egalitarian Paxos which spreads the load out across multiple leaders, although it's mindbendingly complicated IMO, is only applicable to certain domains, and still must obey the lower bound on the number of round-trips within each request. See the paper *"There Is More Consensus in Egalitarian Parliaments"* by Moraru et al for more details.

When you hear that Paxos is rarely used due to its poor performance, it is frequently meant that *consensus* itself is rarely used due to poor performance, and this is a fair criticism: it is possible to achieve much higher performance if you can avoid the need for consensus-based coordination between nodes as much as possible, because this allows for horizontal scalability.

Snarkily, it's also possible to achieve better performance by *claiming* to be using a proper consensus protocol but actually doing something that fails in some cases. [Aphyr's blog](http://aphyr.com/tags/jepsen) is littered with examples of these failures not being as rare as you might like, where database implementations have either introduced bugs into good consensus-like protocols by way of "optimisation", or else developed custom consensus-like protocols that fail to be fully correct in some subtle fashion. This stuff is hard.
There are two general blockchain consensus systems: 

1. Those that produce unambiguous 100% finality given a defined set of
validators
2. Those which do not provide 100% finality but instead
rely on high probability of finality.

The first generation blockchain consensus algorithms (Proof of Work, Proof of Stake, and BitShares’ Delegated Proof of Stake) only offer high probability of finality that grows with time. In theory someone could pay enough money to mine an alternative “longer” Bitcoin blockchain that goes all the way back to genesis.

More recent consensus algorithms, whether `HashGraph, Casper, Tendermint, or DPOS BFT` all adopt long-established principles of `Paxos` and related consensus algorithms. Under these models it is possible to reach unambiguous finality under all network conditions so long as more than ⅔ of participants are honest.

Objective and unambiguous 100% finality is a critical property for all blockchains that wish to support inter-blockchain communication. Absent 100% finality, a reversion on one chain could have irreconcilable ripple effects across all interconnected chains.

The abstract protocol for these more `recent protocols` involves:

1. Propose block
2. All participants acknowledge block (pre-commitment)
3. All participants acknowledge when ⅔+ have sent them pre-commitments
(commitment)
4. A block is final once a node has received ⅔+ commitments
5. Unanimous agreement on finality is guaranteed unless ⅓+
are bad and evidence of bad behavior is available to all

It is the technical differences in the protocols that give rise to real-world impact on user experience. This includes things such as latency until finality, degrees of finality, bandwidth, and proof generation / validation overhead.

Look for more details on delegated proof of stake by eos [here](https://eos.io/news/dpos-bft-pipelined-byzantine-fault-tolerance/)