FastBFT is a scalable Byzantine fault tolerant consensus protocol that uses hardware-assisted secret sharing to achieve high performance. It uses a trusted execution environment to implement a lightweight secret sharing scheme and assign unique sequence numbers to requests. Replicas are organized in a tree topology to distribute communication and computation costs, allowing the protocol to reach consensus in a constant number of message rounds regardless of the number of replicas. The protocol takes an optimistic approach where a subset of replicas participate in agreement while others passively update their state.

1. FastBFT: Scalable Byzantine Consensus
via Hardware-assisted Secret Sharing
Yongrae Jo
System Software Laboratory
Department of CSE
POSTECH
2017. 7. 26
Jian Liu, et al.
Not published
Aalto University, NEC Laboratories Europe

2. 2
Contents
● BFT problem
●
Why fast? How fast?
●
Message pattern
● Cryptography Primitives
●
Protocol & Algorithms
●
Proof
● Evaluation

3. 3
https://medium.com/@DebrajG/how­the­byzantine­general­sacked­the­castle­a­look­into­blockchain­370fe637502c

4. 4
https://medium.com/@DebrajG/how­the­byzantine­general­sacked­the­castle­a­look­into­blockchain­370fe637502c
They need to reach verifiable
consensus!

5. 5
BFT Problem & Why is it important today?
● BFT Problem is about building dependable and high
performance Byzantine fault tolerant system that can
tolerate Byzantine faults to some extent
● There is a long history to the journey for improving BFT
algorithm from the very first time when the paper, “The
Byzantine Generals Problem” was published in 1982 to the
most recent works (..PBFT, Zyzzyva, Min BFT, Fast BFT)
● Recent blockchain technologies surge research about high
performance BFT algorithm

6. 6
Why “Fast BFT” called fast?
● Lightweight Secret Sharing Scheme
● Trusted Execution Environment for BFT Application
● Message Aggregation
● Tree Topology
● Novel Failure Detection
● Optimistic Approach

7. 7
How fast ?

8. 8
Compared to Bitcoin...
100,000 vs 7

9. 9
● Protecting a secret by spliting it into
many pieces which can be used to
retrive original secret later
● After spliting secret into several
pieces, original secret should be
destroyed.
● Splited secrets are calld shadows
● (k, n) secret sharing scheme
– A secret is splited into n pieces
– At least k pieces is needed to retrive
a secret
Secret sharing scheme

10. 10
https://www.youtube.com/watch?v=­wI5­uzSBdE

11. 11
● XOR secret sharing scheme is special case where k = n
● which means, if you are gonna retrive original secret, you need
to gather all the shadows(i.e. shares)
● Principles
– Define a (binary)secret, with length L
– Generate n-1 random binary numbers(shadows) with length L
– Generate last random binary numbers which equals to a value that all
shadows and secret are XORed
– And distribute all shadows randomly into participants
– To retrive a secret, gathers all shadows and apply XOR op to them
● XOR based secret sharing scheme is lightweight version
XOR secret sharing scheme

12. 12
● Each replica’s local TEE maintains a unique, monotonic and
sequential counter; each message is required to be bound
to a unique counter value
● Since monotonicity of the counter is ensured by TEEs, replicas
cannot assign the same counter value to different messages
● At pre-prepare phase of PBFT, the primary assigns unique
sequence number to client‘s request and broadcasts it for reaching
consensus on total order of request.
→ Not needed anymore
●
With TEE, it is guarenteed that only two phase is needed to
proceed the protocol
● And all cryptographic processes are calculated in TEE
Trusted Execution Environment for BFT

13. 13
Trusted Execution Environment for BFT
Hybrid on Steroids: SGX­based High Performance BFT, eurosys2017

14. 14
● Message aggregation techniques reduces
communication cost
● Rather than broadcast messages to all replica, each
replica unicast a single message to the primary
Message Aggregation

15. 15
● O(n) message communication can still be bottleneck to
primary
● Primary organizes replicas into a balanced tree rooted at itself
to distribute both communication and computation costs
● O(n2) → O(n) → O(1)
Message Aggregation with Tree Toplogy
Only takes constant time: O(b),
(b: branch factor)

16. 16
● Crash faults are detected by timeout
● Byzantine faults are detected by verifying shares
● Think of below picture as a path from the root to the leaf
in tree structure for adoption in Fast BFT
(Non-primary)Failure Detection Mechanism
BChain: Byzantine Replication with High Throughput and Embedded Reconfiguration, opodis 2014

17. 17
Bchain: Novel Non-Primary Failure
Detection Mechanism
BChain: Byzantine Replication with High Throughput and Embedded Reconfiguration, opodis 2014

18. 18
● Spliting 2f + 1 correct replicas into two group:
– 1) f + 1 active replicas
– 2) f passive replicas
● Active replicas engage in both agreement and execution
● Passive replicas only update its state and become active
only in case the agreement protocol fails
● Similar concept to optimistic replication which ensures
eventual consistency
● Optimistic approach reduces replication cost and
number of communication message
Optimistic Approach

19. 19
3 phase protocol 2 phase protocol
● From PBFT to MinBFT
● Using TEE
● Reaching consensus through 2 phase protocol
Message Pattern – PBFT, MinBFT
PBFT normal operation

20. 20
● From MinBFT to FastBFT
– Secret sharing, message aggregation, tree topology, optimistic approach
Message Pattern – Fast BFT

21. 21
● Public/Private Encryption/Decryption
● Authenticated Encryption/Decryption
– AES­GCM with 128 bits key
● ECDSA(Elliptic Curve Digital Signature Algorithm)
● CMAC(Cipher based MAC)
● And more for Intel SGX…
– Elliptic Curve Integrated Encryption Scheme (ECIES)
– Diffie–Hellman key exchange
– MD5
Cryptography Primitives

22. 22
Notations
4 parts: Hash, Authenticated enc/dec(Symmetric
key), Public key enc/dec(Asymmetric key),
Digital signature

23. 23
TEE based counter
● TEE based counter is used to assign unique sequence
number(counter value) to the client’s request
● For each counter value, TEE generate the signature with
(counter value, view number, secret shares)
● With the signature signed by TEE, the primary can’t
fabricate the sequence number
● Other replicas trust the counter through so called
“Remote Attestation” process, not the primary itself

24. 24
TEE based counter offered by Fast BFT
Generate digital
signature(ECDSA)
Request digital signature
signed by primary for the
next counter value
1. Verify signature
2. Autheticated Decryption
3. Check if valid counter

25. 25
TEE based counter offered by Fast BFT

26. 26
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
preprocessing(next slide)
Phase1: Preprocessing - Secret distribution

27. 27
Operations
For each counter c,
1. Generate secret
2. Bind secret to counter
value and view number using
SHA256
3. Split secrets
Preprocessing function
4.Each replica has a
hash of aggregated
secrets from its
descendants
5.Authenticated
encryption so that only
authroized replica can
decrypt the cipher text
Secret assigned
to replica iSymmetric key
Hash of
aggregated
secrets

28. 28
Operations
For each counter c,
1. Generate secret
2. Bind secret to counter
value and view number using
SHA256
3. Split secrets
Preprocessing function
4.Each replica has a
hash of aggregated
secrets from its
descendants
5.Authenticated
encryption so that only
authroized replica can
decrypt the cipher text
6.Generate digital
signature(ECDSA)
7.Return cryptographic
information bound to c

29. 29
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
Phase 2: Client’s request
1. function name
2. parameters

30. 30
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
Phase 3: Prepare – Multicast <PREPARE>
Start aggregation
process

31. 31
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
Phase4: Commit(1/2)– Message Aggregation
Message Aggregation
send a secret to parent
When non­primary & non­leaf replica receives secret
When primary receives all secrets(next slide)
1/2 2/2

32. 32
When primary receives secret at Commit phase(1/2)
received secret at Commit phase
Multicast COMMIT messages to all active replica
Execute operation
Onward to the
next counter
value
Primary verifies each secret from its children
and aggregates secrets,

33. 33
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
Phase 4: Commit(2/2) – Multicast <COMMIT>
When a replica receives COMMIT message
(next slide)

34. 34
When replica receives COMMIT message at Commit phase(2/2)
Execute operation & Verify the result
Start aggregation process

35. 35
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
Phase 5: Reply(1/2) – Message Aggregation
secret
Message Aggregation
When non­primary & non­leaf replica receives secret
When the primary receives all secrets(next slide)

36. 36
non­primary faulty detection
When primary receives secret at Reply phase(1/2)
Primary verify each secret from its children
and aggregates secrets,
Multicast REPLY messages to client and passive replica

37. 37
C
Sp
S1
S2
S3
(passive)
Preprocessing Request Prepare Commit Reply
Phase 5: Reply(2/2) - Multicast <COMMIT>
When passive replica receives REPLY message(next slide)

38. 38
When passive replica receives REPLY message at REPLY phase(2/2)

39. 39
Let’s get clear on message aggregation
● When <PREPARE> or <COMMIT> message comes at each replica(leaf,
non­leaf),
● Non­leaf replica starts a timer until it gets secret from its children
● Leaf replica sends its secret to parent
● If Non­leaf replica gets secrets from children, exit the timer and aggregates
the secrets and send them to parents
● This process is going on till the primary get the all secrets
● When the primary aggregates all the secrets from children, it gets ready to
move to the next stage
● Of course, verifying the secret is done using hash of the secret when receving
each secret from children

40. 40
Still confusing?
Let’s see again with tree topology
In optimistic approach,
­ f + 1 : number of active replica &
primary, participating agreement &
execution
­ f: number of passive replica, not
participating agreement & execution

41. 41
Phase1: Preprocessing
- Prelude for Message aggregation
1. Generate sc
2.
Split sc
into sc
1
,
sc
2
,
...
sc
7
3. hc
= H(<sc
, (c, v)>)
sc
1
,
hc
2
, hc
3
sc
2
,
hc
4
, hc
5
sc
3
,
hc
6
, hc
7
sc
4
sc
5
sc
6
sc
7
sc
1
= sc
2
s⊕ c
3
hc
2
= H(sc
2
)
hc
7
= H(sc
7
)
hc
1
= H(sc
1
)
sc
2
= sc
4
s⊕ c
5
sc
3
= sc
6
s⊕ c
7

42. 42
Phase 2: Client’s Request
1. function name
2. parameters

43. 43
Phase 3: Multicast <PREPARE>

44. 44
Phase 4(1/2): Message Aggregation
sc
2
sc
3
sc
4
sc
5
sc
6
sc
7
Node 2, 3 verify
children’s secrets
using hc
i

45. 45
Phase 4(2/2): Multicast <COMMIT>

46. 46
Phase 5(1/2): Message Aggregation
sc
2
sc
3
sc
4
sc
5
sc
6
sc
7
Node 2, 3 verify
children’s secrets
using each hc
2
, hc
3

47. 47
Phase 5(2/2): Multicast <REPLY>

48. 48
View Change Protocol
● When exsisting primary is suspected to be faulty, correct
replica broadcast <REQ­VIEW­CHANGE> message which
includes the new view number v ’
● When correct replica receives f + 1 <REQ­VIEW­CHANGE>
message, broadcast <VIEW­CHANGE> message
● When the new primary(v ’) receives f + 1 <VIEW­CHANGE>
message
– Choose set of active replica
– TEE.be_primary(), TEE.request_counter()
– Broadcast <NEW­VIEW> message

49. 49
Algorithms for View Change Protocol
enough storage?

50. 50
Algorithms for View Change Protocol
TEE

51. 51
Being primary(TEE)

52. 52
Checkpointing & Logging
●
View Change process is quite complex due to logging and
checkpointing
● Messages: <PREPARE>, <COMMIT>, <REPLY> are all
logged → Not sufficient space!
– Think 100,000 transactions per second
● Checkpointing solves it through garbage collection which
discards all messages after latest checkpoint
●
When the primary changes, all operations after the latest
checkpoint are executed

53. 53
Evaluation - Implementation & Test
Environment
● Golang based implementation
● Intel SGX for TEE
● A private network consisting of five 8 vCore Intel Xeon E3­
1240 equipped with 32 GB RAM and Intel SGX
● All BFT replicas were running in separate processes.
● The clients: 8 vCore Intel Xeon E3­1230 equipped with 16 GB
RAM
● Communication between various machines was bridged using
a 1 Gbps switch

54. 54
Evaluation

55. 55
Evaluation – Combinations of Design Choices

56. 56
Evaluation - For 1 KB payload, Peak throughput

57. 57
Evaluation – For 1 KB payload, Latency

58. 58
Evaluation – For 1 MB payload, Peak throughput

59. 59
Evaluation – For 1 MB payload, Latency

60. 60
Conclusion
● FastBFT is 6 times faster than Zyzzyva which reduces replicas’
overheads to near their theoretical minima
● FastBFT achieves near­optimal efficiency for BFT protocols
● FastBFT exhibits considerably slower decline in the achieved
throughput as the network size grows when compared to other
BFT protocols
● FastBFT an ideal consensus layer candidate for next­ generation
blockchain systems

61. 61
Thanks

62. 62
비잔틴 폴트 잡아내는 법(non-primary)
●
preprocessing 단계에서, 각 리플리카에 대해, 그 자식의 자식
들의 시크릿 값을 XOR 연산한 해쉬 값을 갖게 하고,
●
이후 메시지 합산(aggregation) 과정을 시작 할 때, 각 리플리
카는 자식들의 시크릿 값의 해쉬 값과 preprocessing 단계에
서 받은 해쉬 값을 비교해서, 다르면 비잔틴 폴트로 간주
●
즉, 시크릿 값(or 카운터 값, 뷰 번호) 조작하다 걸리면 비잔
틴 폴트로 간주되어서 active replica 그룹에서 쫓겨남

63. 63
크래쉬 폴트 잡아내는 법(non-primary)
●
Non­leaf 위치의 replica가 <PREPARE> 또는 <COMMIT> 메시지
수신시, 자식 노드로부터 시크릿 값을 받을 때까지 타이머
를 실행함
●
일정 시간 동안 시크릿 값을 받지 못하면 자식 노드에 크
래쉬 폴트가 났다고 간주하고 <SUSPECT> 메시지를 부모와
프라이머리에게 보냄
●
고소(?) 한 노드는 리프 노드로 이동하고, 고소 당한 노드는
Passive replica로 이동

64. 64
XOR 연산의 대수적 성질
●
결합 법칙 성립
●
교환 법칙 성립
●
역 연산이 존재
●
즉, 이진 시크릿 값에 임의의 이진 수들을 XOR 연산
한 값에서 원래의 시크릿 값을 복원할 수 있음

65. 65
정확성 증명 - Safty
●
Safty: Correct replica들은 똑같은 결과를 내놓는다는 것을 보증하
는 속성

66. 66
정확성 증명 - Liveness
●
Liveness: 클라이언트는 결국에는 응답을 받는다는 것을 보증하
는 속성

67. 67
정확성 증명 - Lemma 1

68. 68
정확성 증명 – Lemma 2

69. 69
정확성 증명 – Lemma 3

70. 70
정확성 증명 – Lemma 4