Making Byzantine Fault Tolerant Systems Tolerate Byzantine - - PowerPoint PPT Presentation

▶
making byzantine fault tolerant systems tolerate
SMART_READER_LITE
LIVE PREVIEW

Making Byzantine Fault Tolerant Systems Tolerate Byzantine - - PowerPoint PPT Presentation

Jan 27, 2024 15 likes •660 views

Making Byzantine Fault Tolerant Systems Tolerate Byzantine Failures Allen Clement, Mirco Marchetti, Edmund Wong Lorenzo Alvisi, Mike Dahlin BFT Systems PBFT [OSDI 98] Attested Append Only Memory [SOSP 07] HQ [OSDI 06] Beyond 1/3 Faulty in

slide-1
SLIDE 1

Making Byzantine Fault Tolerant Systems Tolerate Byzantine Failures

Allen Clement, Mirco Marchetti, Edmund Wong Lorenzo Alvisi, Mike Dahlin

slide-2
SLIDE 2

BFT Systems

PBFT [OSDI 98] HQ [OSDI 06] Zyzzyva [SOSP 07] HT BFT [DSN 04] QU [SOSP 05] BFT Under Attack [NSDI 08] Commit Barrier Scheduling [SOSP 07] Low Overhead BFT [SOSP 07] Attested Append Only Memory [SOSP 07] Beyond 1/3 Faulty in BFT [SOSP 07] BASE [OSDI 02] SafeStore [USENIX 07] Separating Agreement from Execution [SOSP 03] SUNDR [OSDI 04] ...

slide-3
SLIDE 3

Best Case Faulty Client Client Flood Faulty Primary Faulty Replica

PBFT 62k crash 1K 250 Q/U 24k crash NA 19k HQ 15k NA 4.5k NA crash Zyzzyva 65k crash crash

  • ps/sec

System Throughput

slide-4
SLIDE 4

Best Case Faulty Client Client Flood Faulty Primary Faulty Replica

PBFT 62k crash 1K 250 Q/U 24k crash NA 19k HQ 15k NA 4.5k NA crash Zyzzyva 65k crash crash

  • ps/sec

System Throughput

slide-5
SLIDE 5

Best Case Faulty Client Client Flood Faulty Primary Faulty Replica

PBFT 62k crash 1K 250 Q/U 24k crash NA 19k HQ 15k NA 4.5k NA crash Zyzzyva 65k crash crash Aardvark 39k 39k 7 .8k 37k 11k

  • ps/sec

System Throughput

slide-6
SLIDE 6

Outline

Robust BFT: The case for a new goal Aardvark: Designing for RBFT Evaluation: RBFT in action

slide-7
SLIDE 7

Paved with good intentions

No BFT protocol should rely on synchrony for safety FLP: No consensus protocol can be both safe and live in an asynchronous system! All one can guarantee is eventual progress “Handle normal and worst case separately as a rule, because the requirements for the two are quite different: the normal case must be fast; the worst case must make some progress”

  • - Butler Lampson, “Hints for Computer System Design”
slide-8
SLIDE 8

Maximize performance when the network is synchronous all clients and servers behave correctly While remaining safe if at most servers fails eventually live

Recasting the problem

f

slide-9
SLIDE 9

Misguided Dangerous Futile

Recasting the problem

slide-10
SLIDE 10

Recasting the problem

Misguided

it encourages systems that fail to deliver BFT

Dangerous Futile

slide-11
SLIDE 11

Recasting the problem

Misguided

it encourages systems that fail to deliver BFT

Dangerous

it encourages fragile optimizations

Futile

slide-12
SLIDE 12

Recasting the problem

Misguided

it encourages systems that fail to deliver BFT

Dangerous

it encourages fragile optimizations

Futile

it yields diminishing return on common case

slide-13
SLIDE 13

Synchronous

A New Goal

No Failures Failures No Failures Asynchronous

slide-14
SLIDE 14

Failures Synchronous

A New Goal

No Failures Failures

?

Synchronous

No Failures Asynchronous

slide-15
SLIDE 15

A New Goal

Synchronous No Failures Failures Asynchronous Failures

slide-16
SLIDE 16

Robust BFT

Maximize performance when the network is synchronous at most servers fail While remaining safe if at most servers fail eventually live

f f

slide-17
SLIDE 17

Outline

Robust BFT: The case for a new goal Aardvark: Designing for RBFT Evaluation: RBFT in action

slide-18
SLIDE 18

Protocol Structure

“Good” messages “Bad” messages Computation steps

Step 1 Step 2 Step 3

slide-19
SLIDE 19

Fragile Optimizations

slide-20
SLIDE 20

Revisiting conventional wisdom

Signatures are expensive - use MACs View changes are to be avoided Hardware multicast is a boon

slide-21
SLIDE 21

Revisiting conventional wisdom

Signatures are expensive - use MACs

Faulty clients can use MACs to generate ambiguity Aardvark requires clients to sign requests

View changes are to be avoided Hardware multicast is a boon

slide-22
SLIDE 22

Revisiting conventional wisdom

Signatures are expensive - use MACs

Faulty clients can use MACs to generate ambiguity Aardvark requires clients to sign requests

View changes are to be avoided

Aardvark uses regular view changes to maintain high throughput despite faulty primaries

Hardware multicast is a boon

slide-23
SLIDE 23

Revisiting conventional wisdom

Signatures are expensive - use MACs

Faulty clients can use MACs to generate ambiguity Aardvark requires clients to sign requests

View changes are to be avoided

Aardvark uses regular view changes to maintain high throughput despite faulty primaries

Hardware multicast is a boon

Aardvark uses separate work queues for clients and individual replicas

slide-24
SLIDE 24

Big MAC Attack

c

slide-25
SLIDE 25

Big MAC Attack

c

slide-26
SLIDE 26

Big MAC Attack

c

slide-27
SLIDE 27

Big MAC Attack

c c c

slide-28
SLIDE 28

Big MAC Attack

c c c

slide-29
SLIDE 29

Big MAC Attack

slide-30
SLIDE 30

c

Big MAC Attack

slide-31
SLIDE 31

c

Big MAC Attack

slide-32
SLIDE 32

c

Big MAC Attack

slide-33
SLIDE 33

c c c

Big MAC Attack

slide-34
SLIDE 34

c c c

Big MAC Attack

slide-35
SLIDE 35

c c c c c c

Big MAC Attack

c

Faulty Client

c c

Faulty Primary

c

slide-36
SLIDE 36

c

] [

Hybrid MAC/Signatures

slide-37
SLIDE 37

c

] [

Hybrid MAC/Signatures

request submission

slide-38
SLIDE 38

c

] [

Hybrid MAC/Signatures

request submission

The MAC is good. How is the signature?

slide-39
SLIDE 39

c

Hybrid MAC/Signatures

request submission

slide-40
SLIDE 40

c

Hybrid MAC/Signatures

request submission

Signature is good too!

slide-41
SLIDE 41

c

Hybrid MAC/Signatures

request submission

slide-42
SLIDE 42

c c c

Hybrid MAC/Signatures

request submission primary

  • rders

request

slide-43
SLIDE 43

c c c

Hybrid MAC/Signatures

request submission primary

  • rders

request

slide-44
SLIDE 44

c c c

Hybrid MAC/Signatures

request submission primary

  • rders

request

slide-45
SLIDE 45

Signed Request Filtering

Client Blacklisted? Verify MAC Verify Signature Blacklist Client Process Request

slide-46
SLIDE 46

Big MAC Attack

request submission primary

  • rders

request replicas agree on the next request replicas respond to the client

PBFT

slide-47
SLIDE 47

Big MAC Attack

request submission primary

  • rders

request replicas agree on the next request replicas respond to the client primary

  • rders

request execute the request

Zyzzyva

slide-48
SLIDE 48

Big MAC Attack

Q/U

request submission replicas agree on the next request replicas respond to the client “primary” orders request view change execute the request

slide-49
SLIDE 49

Big MAC Attack

request submission “primary” orders request replicas respond to the client replicas agree on the next request view change execute the request

HQ

slide-50
SLIDE 50

Slow Primary

slide-51
SLIDE 51

Slow Primary

slide-52
SLIDE 52

Slow Primary

slide-53
SLIDE 53

Adaptive View Changes

Time Required Throughput Observed Throughput Throughput

slide-54
SLIDE 54

Adaptive View Changes

Time Required Throughput Observed Throughput Throughput

slide-55
SLIDE 55

Adaptive View Changes

Time Required Throughput Observed Throughput Throughput

slide-56
SLIDE 56

Adaptive View Changes

Time Required Throughput Observed Throughput Throughput

slide-57
SLIDE 57

Implementation details

Sign client requests Adaptive view change Separate network channels Fair scheduling clients -v- replicas replicas -v- replicas Exploit multicore architectures

slide-58
SLIDE 58

Outline

Robust BFT: The case for a new goal Aardvark: Designing for RBFT Evaluation: RBFT can work

slide-59
SLIDE 59

Throughput -v- Latency

Aardvark

HQ Q/U PBFT Zyzzyva

Latency (ms) Throughput (Kops/sec)

10 20 30 40 50 60 70 80 1 2 3 4 5 6 7

slide-60
SLIDE 60

Aardvark, Incrementally

MAC Client Request Sign Client Request Adaptive View Change

PBFT

62k 30k

  • Aardvark

58k 39k 39k

slide-61
SLIDE 61

Performance with failures

Byzantine failures are arbitrary Good faith effort

slide-62
SLIDE 62

Big MAC Attack

Peak Faulty Client PBFT

62k

Q/U

24k

HQ

7 .6k

  • Zyzzyva

65k

Aardvark

39k 39k

slide-63
SLIDE 63

Slow Primary

Peak 1ms delay 10ms delay 100ms delay PBFT 62k 5k 5k 1k Zyzzyva 65k 28k 5k crash Aardvark 39k 38k 37k 38k

slide-64
SLIDE 64

Summary

RBFT: a new goal for BFT systems Aardvark: rejecting conventional wisdom Evaluation: it works!