Byzantine Fault Tolerance Consensus Strikes Back (continued) - - PowerPoint PPT Presentation

▶
byzantine fault tolerance
SMART_READER_LITE
LIVE PREVIEW

Byzantine Fault Tolerance Consensus Strikes Back (continued) - - PowerPoint PPT Presentation

Jan 21, 2023 497 likes •1.7k views

Byzantine Fault Tolerance Consensus Strikes Back (continued) Announcements Lab 2 Due in approximately 5 hours. Lab 2 Due in approximately 5 hours. If you haven't started yet then ... I don't really know how to help. Lab 2 Due in

slide-1
SLIDE 1

Byzantine Fault Tolerance

Consensus Strikes Back (continued)

slide-2
SLIDE 2

Announcements

slide-3
SLIDE 3

Lab 2

  • Due in approximately 5 hours.
slide-4
SLIDE 4

Lab 2

  • Due in approximately 5 hours.
  • If you haven't started yet then ... I don't really know how to help.
slide-5
SLIDE 5

Lab 2

  • Due in approximately 5 hours.
  • If you haven't started yet then ... I don't really know how to help.
  • Note, even with late days you must submit by 23:59 on Saturday.
slide-6
SLIDE 6

Lab 2

  • Due in approximately 5 hours.
  • If you haven't started yet then ... I don't really know how to help.
  • Note, even with late days you must submit by 23:59 on Saturday.
  • Unless you have received an extension (over e-mail) from me.
slide-7
SLIDE 7

Remaining Classes

  • Changed one reading for next week.
slide-8
SLIDE 8

Remaining Classes

  • Changed one reading for next week.
  • Substantially reduced the number of pages.
slide-9
SLIDE 9

Remaining Classes

  • Changed one reading for next week.
  • Substantially reduced the number of pages.
  • Week after is Thanksgiving -- no class. 🦄 🦄
slide-10
SLIDE 10

Remaining Classes

  • Changed one reading for next week.
  • Substantially reduced the number of pages.
  • Week after is Thanksgiving -- no class. 🦄 🦄
  • No class on November 28th.
slide-11
SLIDE 11

Remaining Classes

  • No readings for class on December 5.
slide-12
SLIDE 12

Remaining Classes

  • No readings for class on December 5.
  • Use the time for final projects.
slide-13
SLIDE 13

Remaining Classes

  • No readings for class on December 5.
  • Use the time for final projects.
  • Spend December 12 on final project presentations.
slide-14
SLIDE 14

Remaining Classes

  • No readings for class on December 5.
  • Use the time for final projects.
  • Spend December 12 on final project presentations.
  • Essentially going to do posters, though maybe without the printing.
slide-15
SLIDE 15

Remaining Classes

  • No readings for class on December 5.
  • Use the time for final projects.
  • Spend December 12 on final project presentations.
  • Essentially going to do posters, though maybe without the printing.
  • Final project write-ups are due on Dec 12. Cannot accept them late.
slide-16
SLIDE 16

Remaining Classes

  • No readings for class on December 5.
  • Use the time for final projects.
  • Spend December 12 on final project presentations.
  • Essentially going to do posters, though maybe without the printing.
  • Final project write-ups are due on Dec 12. Cannot accept them late.
  • Between 5-12 pages single column.
slide-17
SLIDE 17

Previously...

slide-18
SLIDE 18

Byzantine Fault Tolerance

  • Failed nodes can exhibit arbitrary behavior.
slide-19
SLIDE 19

Byzantine Fault Tolerance

  • Failed nodes can exhibit arbitrary behavior.
  • Send different messages to different nodes, not send messages, etc.
slide-20
SLIDE 20

Byzantine Fault Tolerance

  • Failed nodes can exhibit arbitrary behavior.
  • Send different messages to different nodes, not send messages, etc.
  • Want to get consensus despite failures. Specifically ensuring:
slide-21
SLIDE 21

Byzantine Fault Tolerance

  • Failed nodes can exhibit arbitrary behavior.
  • Send different messages to different nodes, not send messages, etc.
  • Want to get consensus despite failures. Specifically ensuring:
  • Agreement: All correct nodes agree on a value.
slide-22
SLIDE 22

Byzantine Fault Tolerance

  • Failed nodes can exhibit arbitrary behavior.
  • Send different messages to different nodes, not send messages, etc.
  • Want to get consensus despite failures. Specifically ensuring:
  • Agreement: All correct nodes agree on a value.
  • Validity: Messages sent by a correct node are accepted.
slide-23
SLIDE 23

1 2 3 4

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c1, 4 0->1: c1, 4 0->1: c1, 4 0->1: c1, 4

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c1, 4 0->1: c1, 4 0->1: c1, 4 0->1: c1, 4

1 2 3 4 2

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c0, 4 ??? ??? ???

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

slide-24
SLIDE 24

Digests/Hashes

h Arbitrary length input Fixed length output

slide-25
SLIDE 25

Digests/Hashes

h Arbitrary length input Fixed length output

  • Deterministic: h(x) should always be the same value.
slide-26
SLIDE 26

Digests/Hashes

h Arbitrary length input Fixed length output

  • Deterministic: h(x) should always be the same value.
  • Not invertable -- given h(x) cannot find x.
slide-27
SLIDE 27

Digests/Hashes

h Arbitrary length input Fixed length output

  • Deterministic: h(x) should always be the same value.
  • Not invertable -- given h(x) cannot find x.
  • Output of h(x) is equivalent to a random function.
slide-28
SLIDE 28

Digests/Hashes

h Arbitrary length input Fixed length output

  • Deterministic: h(x) should always be the same value.
  • Not invertable -- given h(x) cannot find x.
  • Output of h(x) is equivalent to a random function.
  • Infeasible to find collisions.
slide-29
SLIDE 29

Digital Signature

  • Need an entire family of these functions, not just one.
  • Parametrize with one or more "keys".
  • f(private, message) = signature
  • g(public, message, signature) = ✔ iff f(private, message) = signature

f Input Signature g Input ✔ 𝙔

  • r

Signature g(m, s) = ✔ if and only if f(m) = s.

slide-30
SLIDE 30

1 2 3 4

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c1, 4 0->1: c1, 4 0->1: c1, 4 0->1: c1, 4

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c1, 4 0->1: c1, 4 0->1: c1, 4 0->1: c1, 4

1 2 3 4 2

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c0, 4 ??? ??? ???

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

0->1: c0, 4 0->1: c0, 4 0->1: c0, 4 0->1: c0, 4

1 2 3 4

AppendEntries(..., [], leaderCommit = 4), Sig(pr1, success), Sig(pr2, success), Sig(pr3, success) Pr0 Pr1 Pr2 Pr3 Pr4

1 2 3 4

AppendEntries(..., [], leaderCommit = 4), Sig(pr1, success), Sig(pr2, success), Sig(pr3, success) Pr0 Pr1 Pr2 Pr3 Pr4

slide-31
SLIDE 31

Practical Byzantine Fault Tolerance

slide-32
SLIDE 32

Requirements

  • Safety: Provide linearizability.
slide-33
SLIDE 33

Requirements

  • Safety: Provide linearizability.
  • Despite byzantine clients or participants. Safety preserved always.
slide-34
SLIDE 34

Requirements

  • Safety: Provide linearizability.
  • Despite byzantine clients or participants. Safety preserved always.
  • Liveness: Ensure progress.
slide-35
SLIDE 35

Requirements

  • Safety: Provide linearizability.
  • Despite byzantine clients or participants. Safety preserved always.
  • Liveness: Ensure progress.
  • Requires fewer than floor(n-1/3) failures, and partial synchrony.
slide-36
SLIDE 36

Requirements

  • Safety: Provide linearizability.
  • Despite byzantine clients or participants. Safety preserved always.
  • Liveness: Ensure progress.
  • Requires fewer than floor(n-1/3) failures, and partial synchrony.
  • Specifically require that message delay is bounded.
slide-37
SLIDE 37

Client Request

c 1 2 3 req, sigc(req)

slide-38
SLIDE 38

Initial Client Request

  • Why does the client need to sign its request?
slide-39
SLIDE 39

Pre-Prepare

c 1 2 3 pre-prepare(v, n, d) sig0(pre-prepare(v, n, d)) <req , sigc(req)> req, sigc(req) v = view n = slot d = D(<req, sigc(req)>)

slide-40
SLIDE 40

Pre-Prepare

  • Why does the leader leave the client message out from its signature?
  • Why do we need to include sigc(req) in this case?
slide-41
SLIDE 41

Prepare

c 1 2 3 req, sigc(req) prepare(v, n, d, 1) sig1(prepare(v, n, d, 1)) v = view n = slot d = D(<req, sigc(req)>)

slide-42
SLIDE 42

Prepare

  • Predicate: prepared(m, v, n, i)
slide-43
SLIDE 43

Prepare

  • Predicate: prepared(m, v, n, i)
  • Node i received a pre-prepare for message m in view v with slot n.
slide-44
SLIDE 44

Prepare

  • Predicate: prepared(m, v, n, i)
  • Node i received a pre-prepare for message m in view v with slot n.
  • Node i received 2f prepares from different backups.
slide-45
SLIDE 45

Prepare

  • Predicate: prepared(m, v, n, i)
  • Node i received a pre-prepare for message m in view v with slot n.
  • Node i received 2f prepares from different backups.
  • If prepared(m, v, n, i) and prepared(m', v, n, j) then
slide-46
SLIDE 46

Prepare

  • Predicate: prepared(m, v, n, i)
  • Node i received a pre-prepare for message m in view v with slot n.
  • Node i received 2f prepares from different backups.
  • If prepared(m, v, n, i) and prepared(m', v, n, j) then
  • D(m) = D(m')
slide-47
SLIDE 47

Prepare

  • Predicate: prepared(m, v, n, i)
  • Node i received a pre-prepare for message m in view v with slot n.
  • Node i received 2f prepares from different backups.
  • If prepared(m, v, n, i) and prepared(m', v, n, j) then
  • D(m) = D(m')
  • Why?
slide-48
SLIDE 48

Prepare

c 1 2 3 req, sigc(req)

Wait for prepared to become true

f = maximum number of faulty nodes

slide-49
SLIDE 49

Prepare

  • Why wait for 2f prepare messages?
slide-50
SLIDE 50

Prepare

  • Why wait for 2f prepare messages?
  • Why does every node broadcast the prepare message?
slide-51
SLIDE 51

Prepare

  • Why wait for 2f prepare messages?
  • Why does every node broadcast the prepare message?
  • Why not just send to leader, client, etc.
slide-52
SLIDE 52

Commit

c 1 2 3 req, sigc(req) commit(v, n, d, i) sig1(commit(v, n, d, i)) f = maximum number of faulty nodes

slide-53
SLIDE 53

Commit

  • Predicate: committed(m, v, n)
slide-54
SLIDE 54

Commit

  • Predicate: committed(m, v, n)
  • prepared(m, v, n, i) is true for f+1 non-faulty nodes.
slide-55
SLIDE 55

Commit

  • Predicate: committed(m, v, n)
  • prepared(m, v, n, i) is true for f+1 non-faulty nodes.
  • If committed is true then message m has been committed in slot n.
slide-56
SLIDE 56

Commit

  • Predicate: committed-local(m, v, n, i)
slide-57
SLIDE 57

Commit

  • Predicate: committed-local(m, v, n, i)
  • prepared(m, v, n, i) is true.
slide-58
SLIDE 58

Commit

  • Predicate: committed-local(m, v, n, i)
  • prepared(m, v, n, i) is true.
  • Node i accepts 2f + 1 commit messages.
slide-59
SLIDE 59

Commit

  • Predicate: committed-local(m, v, n, i)
  • prepared(m, v, n, i) is true.
  • Node i accepts 2f + 1 commit messages.
  • Claim: committed-local(m, v, n, i) => committed(m, v, n)
slide-60
SLIDE 60

Commit

  • Predicate: committed-local(m, v, n, i)
  • prepared(m, v, n, i) is true.
  • Node i accepts 2f + 1 commit messages.
  • Claim: committed-local(m, v, n, i) => committed(m, v, n)
  • For any non-faulty node i. Why?
slide-61
SLIDE 61

Commit

c 1 2 3 req, sigc(req)

Wait for committed

slide-62
SLIDE 62

Response

c 1 2 3 req, sigc(req) resp(r, v, 1) sig1(resp)

slide-63
SLIDE 63

Response

slide-64
SLIDE 64

Response

  • Client waits for f+1 identical responses before accepting the response.
slide-65
SLIDE 65

Response

  • Client waits for f+1 identical responses before accepting the response.
  • Why wait for f+1?
slide-66
SLIDE 66

Haven't really used those signatures yet?

slide-67
SLIDE 67

Violating Liveness

c 1 2 3 req, sigc(req)

slide-68
SLIDE 68

Violating Liveness

c 1 2 3 req, sigc(req) resp(r, v, 0) sig1(resp)

slide-69
SLIDE 69

Fixing Liveness Problems

c 1 2 3 req, sigc(req)

slide-70
SLIDE 70

Fixing Liveness Problems

c 1 2 3 req, sigc(req)

slide-71
SLIDE 71

Fixing Liveness Problems

c 1 2 3 req, sigc(req) req, sigc(req)

slide-72
SLIDE 72

Fixing Liveness Problems

c 1 2 3 req, sigc(req) req, sigc(req)

slide-73
SLIDE 73

Fixing Liveness Problems

c 1 2 3 req, sigc(req) req, sigc(req)

View Change

slide-74
SLIDE 74

What is Important for View Change

slide-75
SLIDE 75

What is Important for View Change

  • Committed log entries remain committed.
slide-76
SLIDE 76

What is Important for View Change

  • Committed log entries remain committed.
  • Eventually arrive at a non-faulty leader.
slide-77
SLIDE 77

Arriving at a Non-Faulty Leader

1 2 3 4 View 1

slide-78
SLIDE 78

Arriving at a Non-Faulty Leader

1 2 3 4 View 1 2

slide-79
SLIDE 79

Arriving at a Non-Faulty Leader

1 2 3 4 View 1 2 3 For view V, leader is V mod (# of peers) At most f view changes before arriving at a correct leader.

slide-80
SLIDE 80

View Change

c 1 2 3 view-change(v+1, prepared, 1) sig1(view-change(v+1, prepared, i))

slide-81
SLIDE 81

View Change

c 1 2 3 view-change(v+1, prepared, 1) sig1(view-change(v+1, prepared, 1)) prepared = [(pre-prepare(n, v, d), sig(pre-prepare(n, v, d), prepare(v, n, d, i0), sigi0(prepare(v, n, d, i0)), prepare(v, n, d, i1), sigi1(prepare(v, n, d, i1)), prepare(v, n, d, i2), sigi2(prepare(v, n, d, i2)), ...), (pre-prepare(n', v', d'), ...), ...]

slide-82
SLIDE 82

What is Included in Prepared

prepared = [(pre-prepare(n, v, d), sig(pre-prepare(n, v, d), prepare(v, n, d, i0), sigi0(prepare(v, n, d, i0)), prepare(v, n, d, i1), sigi1(prepare(v, n, d, i1)), prepare(v, n, d, i2), sigi2(prepare(v, n, d, i2)), ...), (pre-prepare(n', v', d'), ...), ...]

slide-83
SLIDE 83

What is Included in Prepared

prepared = [(pre-prepare(n, v, d), sig(pre-prepare(n, v, d), prepare(v, n, d, i0), sigi0(prepare(v, n, d, i0)), prepare(v, n, d, i1), sigi1(prepare(v, n, d, i1)), prepare(v, n, d, i2), sigi2(prepare(v, n, d, i2)), ...), (pre-prepare(n', v', d'), ...), ...] At slot n, prepared message with digest d, in view v.

slide-84
SLIDE 84

What is Included in Prepared

prepared = [(pre-prepare(n, v, d), sig(pre-prepare(n, v, d), prepare(v, n, d, i0), sigi0(prepare(v, n, d, i0)), prepare(v, n, d, i1), sigi1(prepare(v, n, d, i1)), prepare(v, n, d, i2), sigi2(prepare(v, n, d, i2)), ...), (pre-prepare(n', v', d'), ...), ...] At slot n, prepared message with digest d, in view v. Here is evidence that I received the pre-prepare message.

slide-85
SLIDE 85

What is Included in Prepared

prepared = [(pre-prepare(n, v, d), sig(pre-prepare(n, v, d), prepare(v, n, d, i0), sigi0(prepare(v, n, d, i0)), prepare(v, n, d, i1), sigi1(prepare(v, n, d, i1)), prepare(v, n, d, i2), sigi2(prepare(v, n, d, i2)), ...), (pre-prepare(n', v', d'), ...), ...] At slot n, prepared message with digest d, in view v. Here is evidence that I received the pre-prepare message. Received a prepare from i0

slide-86
SLIDE 86

What is Included in Prepared

prepared = [(pre-prepare(n, v, d), sig(pre-prepare(n, v, d), prepare(v, n, d, i0), sigi0(prepare(v, n, d, i0)), prepare(v, n, d, i1), sigi1(prepare(v, n, d, i1)), prepare(v, n, d, i2), sigi2(prepare(v, n, d, i2)), ...), (pre-prepare(n', v', d'), ...), ...] At slot n, prepared message with digest d, in view v. Here is evidence that I received the pre-prepare message. Received a prepare from i0 Proof that I did the right thing in preparing this slot.

slide-87
SLIDE 87

View Change

c 1 2 3

Send view-change requests on timeout. Why?

slide-88
SLIDE 88

View Change

c 1 2 3

Leader of new view waits for 2f valid view changes. Why 2f?

slide-89
SLIDE 89

View Change

  • Once leader for view v+1 has received 2f valid view-changes it is leader.
  • Needs to produce a single consolidated log.
  • Must include all committed log entries.
slide-90
SLIDE 90

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d'') (1, 0, d''')

slide-91
SLIDE 91

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d'') (1, 0, d''')

Is this possible?

slide-92
SLIDE 92

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d)

slide-93
SLIDE 93

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) Is it possible that d != d'?

slide-94
SLIDE 94

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) (1, 1, e) (1, 2, f) (1, 5, g)

slide-95
SLIDE 95

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) (1, 1, e) (1, 2, f) (1, 5, g)

slide-96
SLIDE 96

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) (1, 1, e) (1, 2, f) (1, 5, g)

slide-97
SLIDE 97

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) (1, 1, e) (1, 2, f) (1, 5, g)

slide-98
SLIDE 98

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) (1, 1, e) (1, 2, f) (1, 5, g) Merged Log (3, 0, d') (3, 1, e) (3, 2, f) (3, 3, noop) (3, 4, noop) (3, 5, g)

slide-99
SLIDE 99

View Change

Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 (1, 0, d) (2, 0, d') Tuple form: (v, n, d) (2, 0, d') (1, 0, d) (1, 0, d) (1, 1, e) (1, 2, f) (1, 5, g) Merged Log (3, 0, d') (3, 1, e) (3, 2, f) (3, 3, noop) (3, 4, noop) (3, 5, g)

Claim: This ensures committed entries remain committed. Why?

slide-100
SLIDE 100

View Change

c 1 2 3 new-view(v+1, [prepared1, prepared2, prepared3], merged, 1) sig1(new-view(v+1, [prepared1, prepared2, prepared3], merged, 1))

slide-101
SLIDE 101

Zyzzyva

slide-102
SLIDE 102

Observation

  • PBFT require n2 messages when deciding on a value.
slide-103
SLIDE 103

Observation

  • PBFT require n2 messages when deciding on a value.
  • Every node sends prepare messages to every other node.
slide-104
SLIDE 104

Observation

  • PBFT require n2 messages when deciding on a value.
  • Every node sends prepare messages to every other node.
  • Every node sends commit messages to every other node.
slide-105
SLIDE 105

Observation

  • PBFT require n2 messages when deciding on a value.
  • Every node sends prepare messages to every other node.
  • Every node sends commit messages to every other node.
  • Can we do better?
slide-106
SLIDE 106

Observation

  • PBFT require n2 messages when deciding on a value.
  • Every node sends prepare messages to every other node.
  • Every node sends commit messages to every other node.
  • Can we do better?
  • Have all nodes send prepare/commit messages to one node, that counts.
slide-107
SLIDE 107

Observation

  • PBFT require n2 messages when deciding on a value.
  • Every node sends prepare messages to every other node.
  • Every node sends commit messages to every other node.
  • Can we do better?
  • Have all nodes send prepare/commit messages to one node, that counts.
  • What node to pick: pick the client -- anyways involved in the process.
slide-108
SLIDE 108

Observation 2

  • So far we have assumed that one cannot undo state machine operations.
slide-109
SLIDE 109

Observation 2

  • So far we have assumed that one cannot undo state machine operations.
  • Here we assume there is some way to undo an applied operation.
slide-110
SLIDE 110

Observation 2

  • So far we have assumed that one cannot undo state machine operations.
  • Here we assume there is some way to undo an applied operation.
  • Enable speculatively executing operations before committed.
slide-111
SLIDE 111

Mechanism

c 1 2 3 pre-prepare(v, n, d) sig0(pre-prepare(v, n, d)) <req , sigc(req)> req, sigc(req) v = view n = slot d = D(<req, sigc(req)>) r = computed response spec-response(v, n, d, r, i) sigi(spec-response(v, n, d, r, i))

slide-112
SLIDE 112

Mechanism

c 1 2 3 req, sigc(req) v = view n = slot d = D(<req, sigc(req)>) r = computed response commit-certificate(v, n, d, [sig0(spec-response(v, n, d, r, i)), ...]), sigc(commit-certificate)

slide-113
SLIDE 113

Problem

slide-114
SLIDE 114

Problem

  • The only nodes which know what is committed are
slide-115
SLIDE 115

Problem

  • The only nodes which know what is committed are
  • Ones which receive a commit certificate.
slide-116
SLIDE 116

Problem

  • The only nodes which know what is committed are
  • Ones which receive a commit certificate.
  • Clients.
slide-117
SLIDE 117

Problem

  • The only nodes which know what is committed are
  • Ones which receive a commit certificate.
  • Clients.
  • Clients are not involved in view changes.
slide-118
SLIDE 118

Problem

  • The only nodes which know what is committed are
  • Ones which receive a commit certificate.
  • Clients.
  • Clients are not involved in view changes.
  • Challenge: how to preserve committed log entries?
slide-119
SLIDE 119

Problem

  • The only nodes which know what is committed are
  • Ones which receive a commit certificate.
  • Clients.
  • Clients are not involved in view changes.
  • Challenge: how to preserve committed log entries?
  • Abraham, Gueta and Malkhi show it doesn't.