Projects in this category follow a common pattern:
There is an implicit step hidden into the procedure above: consensus algorithms are usually aimed at implementing some sort of SMR system (e.g. a replicated DB). Even if the goal of a project in this category is to study & implement a consensus algorithm, students may need to actually use it in order to test it. To do so they will have to create a simple SMR system, like, e.g. a replicated Key-Value store supporting at least two operations: put and get.
Paper abstract:
We present a new algorithm for state machine replication that is built around a leader-driven consensus primitive. This algorithm requires only two additional communication steps between replicas and clients if the consensus leader is correct and the system is synchronous, being thus the first latency-optimal transformation from Byzantine consensus to BFT state machine replication. We also discuss how to make simple modifications to leader-driven consensus algorithms in order to make them compatible with our transformation.
http://www.di.fc.ul.pt/~bessani/publications/edcc12-modsmart.pdf
Overviews and surveys are available in order to perform a quick evaluation and comparison among the protocols above:
https://arxiv.org/pdf/1707.01873.pdf
https://infoscience.epfl.ch/record/121590/files/TR-700-2009.pdf
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8014672
https://www.cs.unc.edu/~reiter/papers/1998/DC.pdf
Finally, the following readings may of interest for who is interest in understanding the many impossibility results affecting the distributed consensus:
https://www.the-paper-trail.org/post/2008-08-13-a-brief-tour-of-flp-impossibility/
https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf