Byzantine Fault Tolerance

Thus far we have limited ourselves to the fail-stop failure model,
where a process stops sending (and receiving) messages after failures.
While this is useful in modeling cases where processes crash, but cannot
model other possible failures including ones caused by software bugs. In
this regard fail-stop is a very limited failure model.

The byzantine failures model lies at the other extreme, making no assumption
about how failed processes behave: a failed process can stop, can send arbitrary
messages, etc.

The papers this week look at the question of how to achieve consensus in the
Byzantine model.

# Lamport, Shostak, and Pease: The Byzantine General Problem
This paper describes the Byzantine consensus problem, and analyzes the problem
to provide bounds on the number of faulty processes. The paper also presents two
protocols one assuming no cryptographic tools are used, and a second that assumes
the use of signatures.

## Questions
a. How many processes need to participate in the $OM$ protocol (without cryptography)
  to support $f$ failures?
b. How many processes need to participate in the protocol with cryptography to support
  $f$ failures?

# Castro and Liskov: Practical Byzantine Fault Tolerance
The next paper provides a practical implementation of a Byzantine fault tolerant
consensus protocol, and specifically shows how to build a RSM that can survive
Byzantine faults.

## Question
c. How many processes need to participate in PBFT to support $f$ failures?
d. PBFT uses cryptography, compare the fault tolerance provided by Lamport's paper
  with what PBFT achieves.