Subject: Tentative notes for today Alternatives to ``grading'' turns: Presentation--volunteer for April 2? Something else? HW4, due by midterm (Wednesday, March 6, 11 a.m.): Exercises 5.1-5.15, except 5, 6, and 10 (Watch for the errata!) Due (to me) by 5 p.m., Friday, March 1: Your estimate of the 2 hardest Modifications for 284: *Omit* those 2 hardest ------------------------ Chapter 5: Fault-tolerant consensus Main rule: Must go along with unanimity among nonfaulty processors (This is validity; obviously require termination and agreement, too.) Faults considered: Crash, Byzantine Main network considered: Complete, reliable ------------------------ Limitations on fault-tolerant consensus: 1. Asynchronous settings: Entirely impossible, even with just one crash. 2. Synchronous settings: Need f+1 rounds, even if all f faults are crashes. For Byzantine faults, need also n > 3f. ------------------------ Summary of protocols: f+1 rounds do suffice, even if the f faults are Byzantine Simple protocol for f crashes Mindless protocol with tricky analysis for f Byzantine faults Less wasteful protocol if some big-O slack (rounds, faults) ------------------------ Simple protocol for f crashes: Share news (candidate values) for f+1 rounds, and then settle on smallest seen My proof: Some round is crash-free; all subsequent perceptions same Limitation: Need f+1 rounds, even if all f faults are crashes. (Insufficient) warmup: f-round version of above protocol can fail Idea for the real proof of the limitation: Consider fault-free execution on all 0's. Chain all the way to all 1's, without changing the verdict. At each step, change just one 0 input to 1. How? Introduce a harmless (?!) crash at the very start for the input owner. Then harmlessly change the input. Then harmlessly (?!) remove the same crash. ------------------------ Crash a processor at the very start *without verdict change*? Trivial to do at very *end*. So how move a crash earlier and earlier? Do it delivery by delivery (and thus round by round). Easy: Deliveries in last round, assuming at least 2 live recipients. How about second-to-last round? Bright idea: Recursively ``anesthetize'' (and revive) live recipients. (Really just the original idea, recursively.) Revivals? Add deliveries back, in similar way. ------------------------ Sufficient lemma: Consider a synchronous consensus protocol that is somewhat tolerant of crash failures. (Detail: n has to exceed the tolerable number of crash failures by at least 2.) Consider any execution that involves only some *smaller* number of crashes. If f is the number of ``unused'' tolerable crashes (i.e., the difference), then you can ``advance'' or ``postpone'' a crash within the last f rounds, without affecting the consensus outcome. Our corollary: If n >= f+2, then no f-round consensus protocol can tolerate f crash failures. (Even if only 2 values.) Proof of lemma: Induction on f. Of course it is enough to advance or postpone by one round at a time. (And within each round, can remove or restore one delivery at a time.) Base case: f=1. Each delivery you remove (or restore) doesn't matter (for some unaffected never-crasher, hence for the whole system). (Uses fact that there are at least 2 uncrashed destinations.) Induction case: Again sequentially remove (or restore) deliveries. To remove (or restore) one changes nothing if the recipient is dead; otherwise, apply the induction hypothesis to the recipient, twice: First crash it (temporarily using at most f-1 unused crashes), then remove (or restore) the delivery at issue, and finally resurrect it (again temporarily using unused crashes).