RAFT 2f+1

It is designed to be easier to teach than Paxos, while providing the same guarantees. In particular, the different parts of the algorithm are more clearly separated and the paper also describes a mechanism for cluster membership change. It has recently seen adoption in etcd inspired by ZooKeeper.

Raft is strictly single Leader protocol. Too much traffic can choke the system. Some variants of Paxos algorithm exist that address this bottleneck.
There are a lot of assumptions considered to be acting, like non-occurrence of Byzantine failures, which sort of reduces the real life applicability.
Raft is a more specialized approach towards a subset of problems which arise in achieving consensus.
Cheap-paxos(a variant of Paxos), can work even when there is only one node functioning in the server cluster. To generalise, K+1 replicated servers can tolerate shutting down of/ fault in K servers.
Raft DOESN’T protect against bad actors (bizantine failure).

Pros

Super fast with a default block minting at 50ms
Does not mint empty blocks, giving us a big saving on storage space
Transaction finality, insures we don’t get forks that would slow us down

Cons

No protection from bad actors, in fact historical block information could be modified and then the block hashes recalculated to edit the past.
A workaround could be to implement a custom solution that would store the block hashes on a separate system.

If we take a look at Figure 2 in the Raft paper, we get an idea for all the state we need to model.