Byzantine Fault Tolerance Consensus Strikes Back Announcements Lab - - PowerPoint PPT Presentation

▶
byzantine fault tolerance
SMART_READER_LITE
LIVE PREVIEW

Byzantine Fault Tolerance Consensus Strikes Back Announcements Lab - - PowerPoint PPT Presentation

Jul 08, 2023 445 likes •1.87k views

Byzantine Fault Tolerance Consensus Strikes Back Announcements Lab 2 Lab 2 Hopefully everyone has started by now, maybe even finished large portions. Lab 2 Hopefully everyone has started by now, maybe even finished large portions.

slide-1
SLIDE 1

Byzantine Fault Tolerance

Consensus Strikes Back

slide-2
SLIDE 2

Announcements

slide-3
SLIDE 3

Lab 2

slide-4
SLIDE 4

Lab 2

  • Hopefully everyone has started by now, maybe even finished large portions.
slide-5
SLIDE 5

Lab 2

  • Hopefully everyone has started by now, maybe even finished large portions.
  • If not ... you should worry.
slide-6
SLIDE 6

Lab 2

  • Hopefully everyone has started by now, maybe even finished large portions.
  • If not ... you should worry.
  • Please don't change the protobufs.
slide-7
SLIDE 7

Lab 2

  • Hopefully everyone has started by now, maybe even finished large portions.
  • If not ... you should worry.
  • Please don't change the protobufs.
  • My testing strategy is going to be to write a few clients and check linearizability.
slide-8
SLIDE 8

Lab 2

  • Hopefully everyone has started by now, maybe even finished large portions.
  • If not ... you should worry.
  • Please don't change the protobufs.
  • My testing strategy is going to be to write a few clients and check linearizability.
  • Changing the interface doesn't let me do that.
slide-9
SLIDE 9

Lab 2

  • Hopefully everyone has started by now, maybe even finished large portions.
  • If not ... you should worry.
  • Please don't change the protobufs.
  • My testing strategy is going to be to write a few clients and check linearizability.
  • Changing the interface doesn't let me do that.
  • Feel free to change whatever is not the interface.
slide-10
SLIDE 10

BFT

slide-11
SLIDE 11

A Note on Terminology

  • Byzantine Empire?
slide-12
SLIDE 12

A Note on Terminology

  • Byzantine Empire?
  • Continuation of the Roman Empire, ~400-1450 AD
slide-13
SLIDE 13

A Note on Terminology

  • Byzantine Empire?
  • Continuation of the Roman Empire, ~400-1450 AD
  • Commonly used as example of bad bureaucracy, in fighting...
slide-14
SLIDE 14

A Note on Terminology

  • Byzantine Empire?
  • Continuation of the Roman Empire, ~400-1450 AD
  • Commonly used as example of bad bureaucracy, in fighting...
  • Historical records don't entirely agree with this.
slide-15
SLIDE 15

What is the Problem?

1 2 3 4

slide-16
SLIDE 16

What is the Problem?

1 2 3 4

slide-17
SLIDE 17

Concrete Problems

1 2 3 4

AppendEntries(..., [(index=4)])

slide-18
SLIDE 18

Concrete Problems

1 2 3 4

AppendEntries(..., [(index=4)]) Success

slide-19
SLIDE 19

Concrete Problems

1 2 3 4

AppendEntries(..., [(index=4)]) Success AppendEntries(..., [], leaderCommit=4)

slide-20
SLIDE 20

Concrete Problems

1 2

slide-21
SLIDE 21

Concrete Problems

1 2

RequestVote( term=2)

slide-22
SLIDE 22

Concrete Problems

1 2

RequestVote( term=2) RequestVote( term=2)

slide-23
SLIDE 23

Concrete Problems

1 2

RequestVote( term=2) RequestVote( term=2) VoteGranted( term=2)

slide-24
SLIDE 24

Concrete Problems

1 2

RequestVote( term=2) RequestVote( term=2) VoteGranted( term=2) VoteGranted( term=2)

slide-25
SLIDE 25

Concrete Problems

slide-26
SLIDE 26

Failure Models

  • Until now we have considered fail-stop processes.
slide-27
SLIDE 27

Failure Models

  • Until now we have considered fail-stop processes.
  • When failed: stop sending messages and take no steps.
slide-28
SLIDE 28

Failure Models

  • Until now we have considered fail-stop processes.
  • When failed: stop sending messages and take no steps.
  • Byzantine faults: when failed do "arbitrary things."
slide-29
SLIDE 29

Failure Models

  • Until now we have considered fail-stop processes.
  • When failed: stop sending messages and take no steps.
  • Byzantine faults: when failed do "arbitrary things."
  • These arbitrary things could even be coordinated with other failed nodes.
slide-30
SLIDE 30

However assuming we know participants a priori.

slide-31
SLIDE 31
slide-32
SLIDE 32

On the internet nobody knows what maps to a user, nor to a machine, ...

slide-33
SLIDE 33

Not Considering this Problem

  • Live in a centralized environment.
slide-34
SLIDE 34

Not Considering this Problem

  • Live in a centralized environment.
  • All servers/nodes are launched by some centralized entity.
slide-35
SLIDE 35

Not Considering this Problem

  • Live in a centralized environment.
  • All servers/nodes are launched by some centralized entity.
  • For example Kubernetes or a human with physical access.
slide-36
SLIDE 36

Not Considering this Problem

  • Live in a centralized environment.
  • All servers/nodes are launched by some centralized entity.
  • For example Kubernetes or a human with physical access.
  • Several ways to solve the decentralized problem.
slide-37
SLIDE 37

Not Considering this Problem

  • Live in a centralized environment.
  • All servers/nodes are launched by some centralized entity.
  • For example Kubernetes or a human with physical access.
  • Several ways to solve the decentralized problem.
  • But largely separable from the discussion at hand.
slide-38
SLIDE 38

Is This Still Useful?

slide-39
SLIDE 39

Is This Still Useful?

  • Yes...
slide-40
SLIDE 40

Is This Still Useful?

  • Yes...
  • Used by Boeing in the 777 to ensure safety.
slide-41
SLIDE 41

Is This Still Useful?

  • Yes...
  • Used by Boeing in the 777 to ensure safety.
  • Used in SpaceX Falcon -- "... to meet requirements for approaching the ISS"
slide-42
SLIDE 42

Is This Still Useful?

  • Yes...
  • Used by Boeing in the 777 to ensure safety.
  • Used in SpaceX Falcon -- "... to meet requirements for approaching the ISS"
  • Generally useful, but cost prohibitive.
slide-43
SLIDE 43

Failure Models

  • Until now we have considered fail-stop processes.
slide-44
SLIDE 44

Failure Models

  • Until now we have considered fail-stop processes.
  • When failed: stop sending messages and take no steps.
slide-45
SLIDE 45

Failure Models

  • Until now we have considered fail-stop processes.
  • When failed: stop sending messages and take no steps.
  • Byzantine faults: when failed do "arbitrary things."
slide-46
SLIDE 46

Failure Models

  • Until now we have considered fail-stop processes.
  • When failed: stop sending messages and take no steps.
  • Byzantine faults: when failed do "arbitrary things."
  • These arbitrary things could even be coordinated with other failed nodes.
slide-47
SLIDE 47

What Can we Do?

slide-48
SLIDE 48

What Do We Care about Addressing

1 2 3 4

State State State State State

slide-49
SLIDE 49

What Do We Care about Addressing

1 2 3 4

State State State State State

Can't really peer into the state of a remote node, cannot do much.

slide-50
SLIDE 50

What Do We Care about Addressing

1 2 3 4 Failed nodes can only interfere by sending messages.

slide-51
SLIDE 51

What Do We Care about Addressing

1 2 3 4 Make sure messages sent by all nodes are "correct" before acting.

slide-52
SLIDE 52

Why challenging?

slide-53
SLIDE 53

Why challenging? Don't know failed nodes a-priori.

slide-54
SLIDE 54

When are Messages Correct?

slide-55
SLIDE 55

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
slide-56
SLIDE 56

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
  • Same might not necessarily mean "correct".
slide-57
SLIDE 57

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
  • Same might not necessarily mean "correct".
  • But always accept any message from a correct participant.
slide-58
SLIDE 58

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
  • Same might not necessarily mean "correct".
  • But always accept any message from a correct participant.
  • Every message is "consistent" with the protocol.
slide-59
SLIDE 59

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
  • Same might not necessarily mean "correct".
  • But always accept any message from a correct participant.
  • Every message is "consistent" with the protocol.
  • Attach some kind of proof that you were supposed to send this message.
slide-60
SLIDE 60

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
  • Every message is "consistent" with the protocol.
slide-61
SLIDE 61

Agreeing on Correct Messages

slide-62
SLIDE 62

Problem we Want to Solve

1 2 3 4

AppendEntries(..., [(index=4)])

slide-63
SLIDE 63

Problem we Want to Solve

1 2 3 4

Success

slide-64
SLIDE 64

Problem we Want to Solve

1 2 3 4

AppendEntries(..., [], leaderCommit = 4)

slide-65
SLIDE 65

Problem we Want to Solve

1 2 3 4

AppendEntries(..., [(index=4)])

slide-66
SLIDE 66

Problem we Want to Solve

1 2 3 4

AppendEntries(..., [], leaderCommit = 4)

slide-67
SLIDE 67

Problem we Want to Solve

  • Cannot observe messages between individuals.
slide-68
SLIDE 68

Problem we Want to Solve

  • Cannot observe messages between individuals.
  • Hard to judge whether behavior is correct.
slide-69
SLIDE 69

Problem we Want to Solve

  • Cannot observe messages between individuals.
  • Hard to judge whether behavior is correct.
  • New idea: send messages to everyone.
slide-70
SLIDE 70

Problem we Want to Solve

  • Cannot observe messages between individuals.
  • Hard to judge whether behavior is correct.
  • New idea: send messages to everyone.
  • Everyone knows where the state machine should be.
slide-71
SLIDE 71

Sending to Everyone

1 2 3 4

0->1: AppendEntries(..., [(index=4)])

slide-72
SLIDE 72

Sending to Everyone

1 2 3 4

Success Success

slide-73
SLIDE 73

Sending to Everyone is Insufficient

1 2 3 4

0->1: AppendEntries(..., [(c0, index=4)]) 0->1: AppendEntries(..., [(c1, index=4)])

slide-74
SLIDE 74

Sending to Everyone is Insufficient

1 2 3 4

Success Success

slide-75
SLIDE 75

Sending to Everyone is Insufficient

1 2 3 4

Success Success

Slot 4 is c0

slide-76
SLIDE 76

Sending to Everyone is Insufficient

1 2 3 4

Success Success

1 thinks slot 4 is c1 Slot 4 is c0

slide-77
SLIDE 77

Sending to Everyone is Insufficient

1 2 3 4

Success Success

1 thinks slot 4 is c1 Slot 4 is c0 1 thinks slot 4 is c0

slide-78
SLIDE 78

Sending to Everyone is Not Sufficient

  • Faulty node can send differing messages to "everyone".
slide-79
SLIDE 79

Sending to Everyone is Not Sufficient

  • Faulty node can send differing messages to "everyone".
  • Run some protocol to detect this problem.
slide-80
SLIDE 80

Sending to Everyone

1 2 3 4

0->1: AppendEntries(..., [(c0, index=4)]) 0->1: AppendEntries(..., [(c1, index=4)])

1 2 3 4

0->1: c0, 4

1 2 3 4

0->1: c1, 4

1 2 3 4

0->1: c0, 4

1 2 3 4

0->1: c1, 4

slide-81
SLIDE 81

Sending to Everyone

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

1 2 3 4

0->1: c0, 4

1 2 3 4

0->1: c1, 4

slide-82
SLIDE 82

Sending to Everyone

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

slide-83
SLIDE 83

Sending to Everyone

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

Choose majority, breaking ties deterministically.

slide-84
SLIDE 84

Sending to Everyone

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-85
SLIDE 85

Sending to Everyone

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

Choose majority, breaking ties deterministically.

slide-86
SLIDE 86

Not Possible for 1 failure with 3 participants

1 1 2 2

0->1: x=2 0->1: x=1 0->1: x=1 0->1: x=1

slide-87
SLIDE 87

Not Possible for 1 failure with 3 participants

1 1 2 2

0->1: x=2 0->1: x=1 0->1: x=2 0->1: x=1

slide-88
SLIDE 88

Not Possible for 1 failure with 3 participants

1 1 2 2

0->1: x=2 0->1: x=1 0->1: x=2 0->1: x=1

Cannot distinguish between these two cases. Cannot meet the two requirements state at the beginning.

slide-89
SLIDE 89

Limitations

  • More generally cannot solve for m failures with < 3m+1 participants.
slide-90
SLIDE 90

Limitations

  • More generally cannot solve for m failures with < 3m+1 participants.
  • Proof by reduction to the case with 3.
slide-91
SLIDE 91

Sending to Everyone

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

  • However, note that doing this once is not sufficient for more than 1 faults.

5 6

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

1 2 3 4

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

1 2 3 4

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

5 6 5 6 5 6 5 6 5 6 5 6

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

slide-92
SLIDE 92

Sending to Everyone

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 ??? ??? ???

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

  • However, note that doing this once is not sufficient for more than 1 faults.
  • For example, can force any decision in this case.

5 6

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

1 2 3 4

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

1 2 3 4

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

5 6 5 6 5 6 5 6 5 6 5 6

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

2

slide-93
SLIDE 93

Solution: Recursively call again.

slide-94
SLIDE 94

When are Messages Correct?

  • Every correct node receives the same messages (and acts correctly).
  • Every message is "consistent" with the protocol.
slide-95
SLIDE 95

Proving Consistency with the Protocol

slide-96
SLIDE 96

What Does this Even Mean?

1 2 3 4

AppendEntries(..., [(index=4)])

slide-97
SLIDE 97

What Does this Even Mean?

1 2 3 4

Success

slide-98
SLIDE 98

What Does this Even Mean?

1 2 3 4

AppendEntries(..., [], leaderCommit = 4), Proof that a majority have accepted entires until 4.

slide-99
SLIDE 99

Problem

  • How to generate proofs?
slide-100
SLIDE 100

Problem

  • How to generate proofs?
  • Many possibilities, but just going to include messages here.
slide-101
SLIDE 101

Problem

  • How to generate proofs?
  • Many possibilities, but just going to include messages here.
  • How to prevent failed nodes from misrepresenting messages?
slide-102
SLIDE 102

Misrepresenting Messages

1 2 3 4

AppendEntries(..., [], leaderCommit = 4), Success from 0, 1, 2, 3

slide-103
SLIDE 103

Misrepresenting Messages

1 2 3 4

AppendEntries(..., [], leaderCommit = 4), Success from 0, 1, 2, 3

slide-104
SLIDE 104

Warning: Cryptography

slide-105
SLIDE 105

Digests/Hashes

h Arbitrary length input Fixed length output

slide-106
SLIDE 106

Digests/Hashes

h Arbitrary length input Fixed length output

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

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-108
SLIDE 108

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-109
SLIDE 109

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-110
SLIDE 110

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

Signature

slide-111
SLIDE 111

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

slide-112
SLIDE 112

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

O w e y

  • u

1 s c

  • p

s

  • f

i c e c r e a m . f ( O w e y

  • u

1 s c

  • p

s

  • f

i c e c r e a m . )

slide-113
SLIDE 113

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

O w e y

  • u

1 s c

  • p

s

  • f

i c e c r e a m . f ( O w e y

  • u

1 s c

  • p

s

  • f

i c e c r e a m . ) Owe you 10 scoops of ice cream.f(Owe you 10 scoops of ice cream.)

slide-114
SLIDE 114

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

Owe you 10 scoops of ice cream.f(Owe you 10 scoops of ice cream.)

slide-115
SLIDE 115

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

Owe you 10 scoops of ice cream.f(Owe you 10 scoops of ice cream.) O w e y

  • u

s c

  • p

s

  • f

i c e c r e a m .

slide-116
SLIDE 116

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

Owe you 10 scoops of ice cream.f(Owe you 10 scoops of ice cream.) O w e y

  • u

s c

  • p

s

  • f

i c e c r e a m . Owe you 10 scoops of ice cream. f(Owe you 10 scoops of ice cream.)

slide-117
SLIDE 117

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

Owe you 10 scoops of ice cream.f(Owe you 10 scoops of ice cream.) O w e y

  • u

s c

  • p

s

  • f

i c e c r e a m . Owe you 10 scoops of ice cream. f(Owe you 10 scoops of ice cream.) You owe Grizzly 10 scoops.

slide-118
SLIDE 118

Digital Signature

f Input Signature g Input ✔ 𝙔

  • r

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

Owe you 10 scoops of ice cream.f(Owe you 10 scoops of ice cream.) O w e y

  • u

s c

  • p

s

  • f

i c e c r e a m . Owe you 10 scoops of ice cream. f(Owe you 10 scoops of ice cream.)

Provides a non-repudiation mechanism.

You owe Grizzly 10 scoops.

slide-119
SLIDE 119

Digital Signature

  • Need an entire family of these functions, not just one.
  • Why?

f Input Signature g Input ✔ 𝙔

  • r

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

slide-120
SLIDE 120

Digital Signature

  • Need an entire family of these functions, not just one.
  • Why?
  • Parametrize with one or more "keys".

f Input Signature g Input ✔ 𝙔

  • r

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

slide-121
SLIDE 121

Digital Signature

  • Need an entire family of these functions, not just one.
  • Why?
  • Parametrize with one or more "keys".
  • f(key, message) = signature

f Input Signature g Input ✔ 𝙔

  • r

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

slide-122
SLIDE 122

Digital Signature

  • Need an entire family of these functions, not just one.
  • Why?
  • Parametrize with one or more "keys".
  • f(key, message) = signature
  • g(key', message, signature) = ✔ if and only if f(key, message) = signature

f Input Signature g Input ✔ 𝙔

  • r

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

slide-123
SLIDE 123

Digital Signature

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

f Input Signature g Input ✔ 𝙔

  • r

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

slide-124
SLIDE 124

Proving Message Receipt

1 2 3 4

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

slide-125
SLIDE 125

Proving Message Receipt

1 2 3 4

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

slide-126
SLIDE 126

Proving Message Receipt

  • Looks simple in principle, but tricky to get right in practice.
  • PBFT takes this basic idea and packages it into an optimized version.
slide-127
SLIDE 127

PBFT

c 1 2 3 req, sigc(req)

slide-128
SLIDE 128

PBFT

c 1 2 3 pre-prep(v, n, d) sig0(pre-prep(v, n, d)) <req , sigc(req)> req, sigc(req)

slide-129
SLIDE 129

PBFT

c 1 2 3 pre-prep(v, n, d) sig0(pre-prep(v, n, d)) <req , sigc(req)> req, sigc(req)

slide-130
SLIDE 130

PBFT

c 1 2 3 req, sigc(req) prep(v, n, d, i) sig1(prep(v, n, d, i))

slide-131
SLIDE 131

PBFT

c 1 2 3 req, sigc(req)

Wait for 2m prepare messages

slide-132
SLIDE 132

PBFT

c 1 2 3 req, sigc(req) commit(v, n, d, i) sig1(commit(v, n, d, i))

slide-133
SLIDE 133

PBFT

c 1 2 3 req, sigc(req)

Wait for 2m commit messages

slide-134
SLIDE 134

PBFT

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

slide-135
SLIDE 135

Haven't used those signatures yet?

slide-136
SLIDE 136

Where are the Signatures Used?

  • View change: prove that you are not trying to cheat when consolidating logs.
slide-137
SLIDE 137

Where are the Signatures Used?

  • View change: prove that you are not trying to cheat when consolidating logs.
  • Another important bit: in each view leader is decided by view-number.
slide-138
SLIDE 138

Where are the Signatures Used?

  • View change: prove that you are not trying to cheat when consolidating logs.
  • Another important bit: in each view leader is decided by view-number.
  • Not by voting as in Raft.
slide-139
SLIDE 139

Where are the Signatures Used?

  • View change: prove that you are not trying to cheat when consolidating logs.
  • Another important bit: in each view leader is decided by view-number.
  • Not by voting as in Raft.
  • Why is this important?
slide-140
SLIDE 140

Where are the Signatures Used?

  • View change: prove that you are not trying to cheat when consolidating logs.
  • Another important bit: in each view leader is decided by view-number.
  • Not by voting as in Raft.
  • Why is this important?
  • Not discussing details today, might return to this next week.
slide-141
SLIDE 141

Quiz