SCP is a computationally scalable Byzantine consensus protocol that uses committees to achieve scalability. It partitions users into multiple committees, with each committee running a traditional BFT consensus protocol in parallel. This allows throughput to scale with increased computational power. SCP combines proof-of-work for identity generation and committee assignment with message passing-based BFT within committees. Evaluation shows SCP scales computationally with increased cores and has lower bandwidth consumption than Bitcoin.

1. SCP: A Computationally-Scalable
Byzantine Consensus Protocol For
Blockchains
Loi Luu, Viswesh Narayanan, Kunal Baweja, Chaodong Zheng, Seth
Gilbert, Prateek Saxena
School of Computing, National University of Singapore
IACR Cryptology ePrint Archive 2015
Yongrae Jo (20172938)

2. Traditional BFT is Not scalable
: Heavy message passing based consensus
→ Network bandwidth quickly exhausted
→ Communication efficient protocol

3. Breakthroughs in BFT
Oral Message Algorithm
(1982)
O(N^f)
Fast distributed agreement
(1985)
O(N^3) or O(Nf^2)
PBFT
(1999)
O(N^2)
Randomized BA
(2013)
O(N polylog(N))
Exponential
Polynomial
(cubic)
Quadratic
Sub-linear

4. My previous seminar(Algorand)

5. My previous seminar(Algorand)
Computation
based consensus
Message passing
based consensus

6. Computation based consensus
●
Reaching consensus via (heavy) computation rather
than communication(e.g. PoW)
●
Computationally scalable
– As the computation power increases in the network,
throughput increases as well
– Bitcoin is not computationally scalable
●
More computing power doesn’t increase its
throughput
●
SCP is an attempt to find computationally scalable
consensus algorithm while keeping the advantages of
message passing based consensus

7. Finding the sweet spot
Sweet
Spot
More
Computation
More
Message passing
CPU power
Slow
Scalable
Secure
Network bandwidth
Fast
Not scalable
Not secure(in open network)

8. SCP in a Nutshell
PoW
Subset Committee Protocol
(or Scalable Consensus Protocol)
●
Generating identities
●
Forming committees
●
Shared public randomness
●
Prevent sybil attack
BFT
●
Reaching consensus on a value in
normal committee or a block in final
committee
●
Parallel consensus via committee
C1
C2
C3
(Final committee)
●
Each committee
runs traditional BFT.
●
Integrated into single ordered
blockchain in final committee
Run
BFT
C4
Stellar
Consensus
Protocol?

9. Subset Committee Problem (1)
●
Problem Definition: Subset Consensus
– Agreement over a subset of transactions
– Description
●
Assumption
– Let there be n identity-less processors, f(< n/3) of
which are controlled by a byzantine adversary
– Each processor has integer input(x), output(y) and
constraint function(mapped to 0 or 1)
●
Then, the following condition holds.(next slide)

10. Subset Committee Problem (2)
P1
P2
P3
P4
x1
x2
x3
x4
y1
y2
y3
y4
Subset
Consensus
Protocol
0 or 1
0 or 1
0 or 1
0 or 1
X
Constraint
Func.
y1
= y2
= y3
= y4
(with prob. p)

11. SCP Protocol
Protocol proceeds in epoch.
In each epoch, following steps executed
Step1. Committee Formation
Step2. Committee Overlay Joins
Step3. Intra-committee consensus
Step4. Final Consensus Broadcast
Step5. Generating Shared Randomness

12. Committee Formation (1)
●
Establish processor’s (virtual) identity via local
computation
– Generating (IP addr / Public Key / Private Key)
– Broadcast (IP addr, Public Key)
●
Establish committee
– Committee that the processor participates in a epoch
– Allocate the identity to random committee via PoW
Step 1

13. Committee Formation (2)
0 0 0 0 0 0 1 1 0 10 0 0
000000...1111
s-bits# of leading
zeros
Public
Key
IP
Addr.
Shared random
seed
Committee
Identity
PoW Solution Broadcast
(IP, PK, nonce,
s-bits)
2s
= # of
committee
SHA256
Step 1

14. Committee Overlay Join (1)
●
Once identities and their committees are established,
committee members need a way to establish point-to-
point connections with their committee peers
●
Directory committee
– The first c identities created in the network
– All subsequent identities created will contact the
directory members to announce their committee
membership
– Keeps track of the committee membership
– When their list for a committee reaches size c, they
multicast it to all members of that committee
Step 2

15. Committee Overlay Join (2)
Established first c identities
1
Broadcast channel
Established Point to Point Channel
2
When new identity is generated,
it firstly contacts directory committee
3
Contact
When c/2 + 1 messages are received, It accepts
the member lists of the committee which it
belongs to
4
Receive member
list
Step 2
First c identities
forms directory
committee

16. Intra-committee Consensus (1)
●
Runs traditional BFT to agree on a value
●
After reaching consensus on a value, send that value
to final committee
– O(c2)
●
Partitioned transactions(values) into independent set
for parallelism
●
(There was no description on how to partition
transactions into independent committee and end-to-
end message flow on client’s request)
→ Let’s assume :)
Step 3

17. Intra-committee Consensus (2)
C1
C2
C3
Run
BFT
C4
Run
BFT
Run
BFT
Run
BFT
Step 3
Each committee runs BFT
protocol
→ O(c2
)

18. Final Consensus Broadcast (1)
●
Merge the results of committees
– Set union of all inputs
– Create a cryptographic digest (a digital signature) of the
final agreed result
●
Run the same intra-committee algorithm(BFT) to get
verifiable result by at least c/2 + 1
Step 4

19. Final Consensus Broadcast (2)
C1
C2
C3
Run
BFT
C4
(final committee)
Run
BFT
Run
BFT
Step 4
Each committee member
runs BFT protocol (sames
previous intra-committee
consensus)

20. Final Consensus Broadcast (3)
C1
C2
C3
C4
(final committee)
v1
v2
v3
Step 4
All normal committee members
multicast agreed value to
members in final committee
→ O(nc)

21. Final Consensus Broadcast (4)
C1
C2
C3
C4
(final committee)
Run
BFT
Step 4
Final committee runs BFT to check
that its members get the same
values from normal committee

22. Final Consensus Broadcast (5)
C1
C2
C3
C4
(final committee)
Agreed
result
Agreed
result
Agreed
result
Step 4

23. Generating Shared Randomness (1)
●
Final committee generates a set of random strings for PoW
in the next epoch
●
Two rounds of communication
– First round
●
Each member of the final committee chooses a random string
u consisting of r random bits and broadcasts a hash H(u) to
everyone. This serves as a commitment to the random string.
– Second round
●
Each member of the final committee broadcasts a message
containing the random string u itself to everyone
●
Users XORs the set of valid random strings received
Step 5

24. Generating Shared Randomness (2)
C1
C2
C3
C4
(final committee)
H(u1
),
...
H(uc
)
H(u): Hash of random string u
First Round
Send broadcast commitment first
H(u1
),
...
H(uc
)
H(u1
),
...
H(uc
)
Step 5

25. Generating Shared Randomness (3)
C1
C2
C3
C4
(final committee)
u1
...uc
H(u): Hash of random string u
Second Round
Broadcast random string u
u1
...uc
u1
... uc
Step 5

26. Generating Shared Randomness (4)
C1
C2
C3
C4
(final committee)
Each user XORs over u1
...uc
to get
shared random string for random
seed for PoW in the next epoch
u1
…⊕ ⊕uc
u1
…⊕ ⊕uc
u1
…⊕ ⊕uc
u1
…⊕ ⊕ uc
Step 5

27. In a given epoch, for each committee, we refer to the frst c identities
that broadcast a valid proof-of-work for this committee as the
members of this committee. (If more than one proof-of-work is
broadcasted during the same round, they are ordered
lexicographically, and the smallest one is picked.)
Security Analysis
Defnition 1 (Committee)
We say that an epoch has good randomness if: (1) every user has a
publically random string of r bits, verifably generated in the previous
epoch, with at least r−c/2 bits of entropy, and (2) no user has access
to such a verifable random string more than two communication
rounds prior to the beginning of the epoch
Defnition 2 (Good randomness)

28. Security Analysis
In every epoch with good randomness, for every integer n’ among the
frst n’ identities created, at most n’/2 are controlled by the adversary,
with probability at least 1 − e(−27n’ /160)
Lemma 3 (Good Majority)
In every epoch with good randomness, for each committee, at least
c/2 + 1 committee members will be honest with probability at least
1−e(−27c/160)
. Moreover, the probability of generating c/2 + 1 malicious
identities by the end of the epoch is also exponentially small.
Lemma 4 (Committees Good)

29. Security Analysis
In every epoch with good randomness, if the directory size is d, then for
each committee, with probability at least 1 − e−27c/160
, all honest
committee members will correctly adopt the (same) member list for
the committee.
Lemma 5 (Consistent Committees)
In every epoch with good randomness, the honest members agree on
a unique value with at least c/2+1 signatures, with probability at least
1− e (−27c/116)
Lemma 6 (Consensus)

30. Security Analysis
In every epoch with good randomness, the fnal committee its honest
members will broadcast a combined value (from values from other
committees) which has at least c/2 + 1 signatures, with probability
at least 1 − 2s
· (e−27c/160
). → Termination of protocol(Liveness)
Lemma 7 (Final Committee)
In every epoch with good randomness, with probability at least
1 − e (−27c/160)
: at the end of the epoch every user computes a random
string of r bits that: (a) contains at least r −c/2 bits of entropy, and (b)
can be verifed as validly generated in that epoch. Moreover, no user
knows any of the random strings until at least two rounds prior to the
end of the epoch. That is, if epoch e has good randomness, then
epoch e+1 also has good randomness.
Lemma 8 (Good Randomness)

31. SCP Blockchain Implementation
●
Two layers of Blockchain
– Two types of Block
●
Consensus block (proposed by final committee)
●
Data block (proposed by normal committee)
Separating
consensus data
and transaction
data
Lazy broadcast
Used in
consensus
protocol
Immediate broadcast

32. Evaluation
(Configuration)
●
Local network
●
SCP by modifying existing Bitcoin
client code
●
Authenticated BFT protocol for
intra-committee consensus
●
Committee size(c) = 50
●
10 / 20 / 40 / 80 CPU cores
●
(not known computer hardware
spec and # of computer)
Bitcoin SCP
●
Amazon EC2 platform
●
Nakamoto consensus
●
Deploy instances in different
geographical regions
●
20 / 40 / 80 CPU cores
●
(not known # of instances and
types of instances)

33. Evaluation
(Computational Scalability)
SCP is more computationally scalable
Epoch time: 1 minute
Block rate remains almost
constant regardless of
computation power in the
network
BitcoinBitcoin SCP
(more computing power --> more identity,
more committee --> more parallel)

34. Evaluation
(Bandwidth consumption)

35. Conclusion
●
SCP is committee based consensus, which partitions
users into several committees to achieve scalability
and parallelization
●
By combining computation based consensus(PoW) and
message passing based consensus(BFT), SCP finds
sweet spot between the two.

36. Thanks