Blockchain-based Consensus
Juan Garay
Ya h o o L a b s
[email protected]
Based on joint work with Aggelos Kiayias and Nikos Leonardos
(University of Athens) [Eurocrypt’15]
Talk Outline
Distributed Consensus: Brief Recap
Blockchain Protocols
Blockchain-based Consensus
Other POW-based Protocols
Summary and Open Problems
Distributed Consensus (Byz. Agreement) [PSL80, LSP82]
n parties
t corrupted
v2
v1
v3
...
vn
Adversary
Consensus Protocol
vi ∈ V = {0,1}
v
v
v
v
...
3
Blockchain-based Consensus
Distributed Consensus (Byz. Agreement) [PSL80, LSP82] (2)
Distributed Consensus: n parties start with an initial value vi
•
•
•
Agreement: All honest parties output the same value
Validity: If all honest parties start with the same input (say, v), then
they output this value
Termination: Parties eventually terminate
Single-sender/source version (“Byzantine Generals,” Broadcast)
•
Validity: If sender is honest, then all honest parties output his value
|V| > 2: Strong Consensus [Nei94]
•
Strong Validity: Output value is initial value of some honest party
Fundamental problems in fault-tolerant distributed computing and
cryptographic protocols (secure multi-party computation ─ MPC)
4
Blockchain-based Consensus
Models (Setup + Assumptions)
Channels: Authenticated point-to-point
Network communication: Synchronous; rushing adversary
Adversary’s computational power:
• Unbounded (“unconditional,” information-theoretic)
• Polynomial time (in security parameter; cryptographic, “authenticated”)
5
Blockchain-based Consensus
Complexity Measures
Rounds: r = t+1 [LSP82, FL82]
Resiliency:
• Unconditional setting: n > 3t [LSP82]
6
Blockchain-based Consensus
Impossibility with n = 3t [PSL80, LSP82]
7
Blockchain-based Consensus
Complexity Measures
Rounds: r = t+1 [LSP82, FL82]
Resiliency:
• Unconditional setting: n > 3t [LSP82]
8
Blockchain-based Consensus
Complexity Measures
Rounds: r = t+1 [LSP82, FL82]
Resiliency:
• Unconditional setting: n > 3t [LSP82]
• Cryptographic setting:
− Broadcast: n > t [LSP82, DS82]
− Agreement: n > 2t [Fit03]
9
Blockchain-based Consensus
Complexity Measures
Rounds: r = t+1 [LSP82, FL82]
Resiliency:
• Unconditional setting: n > 3t [LSP82]
• Cryptographic setting:
− Broadcast: n > t [LSP82, DS82]
− Agreement: n > 2t [Fit03]
Message/Bit complexity: m = Ω(n2) [DR85]
10
Blockchain-based Consensus
Unconditional Consensus Protocols
Setup: Point-to-point authenticated channels
[LSP82]: n > 3t, r = t+1, exp(n)
11
Blockchain-based Consensus
LSP’s Protocol (“EIG” [BDDS87])
t+1
12
Blockchain-based Consensus
Unconditional Consensus Protocols (2)
Setup: Point-to-point authenticated channels
[LSP82]: n > 3t, r = t+1, exp(n)
13
Blockchain-based Consensus
Unconditional Consensus Protocols
Setup: Point-to-point authenticated channels
[LSP82]: n > 3t, r = t+1, exp(n)
[GM93]: n > 3t, r = t+1, poly(n)
• [AD15]: r = min(t+1, f+2) (optimal early stopping [DRS90])
14
Blockchain-based Consensus
Unconditional Consensus Protocols
Setup: Point-to-point authenticated channels
[LSP82]: n > 3t, r = t+1, exp(n)
[GM93]: n > 3t, r = t+1, poly(n)
• [AD15]: r = min(t+1, f+2) (optimal early stopping [DRS90])
If r = O(t), much simpler protocols
15
Blockchain-based Consensus
Authenticated Consensus Protocols
Setup: Public-key infrastructure (PKI)
Assumption: Digital signatures secure against adaptive chosenmessage attacks [GMR88]
[DS82]: n > t, r = t+1, poly(n)
16
Blockchain-based Consensus
Authenticated Consensus Protocols (2)
[DS82] protocol (informal):
• Source signs its input value and sends to all parties
• r = 1,…,t+1:
If any value vi ∈ V = {0,1} has been newly added to a set of accepted
values, sign it and send value and signatures to everybody
o If a value/signatures message is received by any party containing
valid signatures by at least r distinct players including the sender, then
accept the value and update signatures
If only one accepted value, then the party outputs that value; otherwise
a default value
o
•
17
Blockchain-based Consensus
Randomized Consensus Protocols
[BO83, Rab83]: Introduction of randomization to distributed
algorithms (2015 Dijkstra Prize)
Expected constant no. of rounds; probabilistic, non-simultaneous
termination [DRS90]
Consensus reduces to access to “common coin” [Rab83]
[FM88]: Common coin from “scratch”
• [KK06]: Common coin in the cryptographic setting
18
Blockchain-based Consensus
Open, Peer-to-Peer Networks
Above models assume authenticated point-to-point channels
between parties
Such setup may not exist in many interesting scenarios
No prior relations among parties; come and go as they please
No PKI or authenticated channels, so standard MPC techniques
can’t be used
Can anything “interesting” be achieved?
• [Okun05]: “Anonymous model without port awareness”
• [BCLPR05]: Secure computation without authentication
• “The proof-of-work chain is a solution to the Byzantine Generals problem”
[Nak08b]
19
Blockchain-based Consensus
Blokchain Protocols
Blockchain Protocols
Bitcoin white paper [Nak08a]
Based on Proofs of Work (POWs) [DN92, …]
“The proof-of-work chain is a solution to the Byzantine Generals
problem” [Nak08b]
21
Blockchain-based Consensus
Proofs of Work (POWs)
Aka “moderately hard functions,” “cryptographic puzzles,” “time-lock
puzzles” [DN92, RSW96, Back97, JB99, BN00, AJK05, GMPY06, BGJPVW15]
Q(·,·): Polynomial-time predicate
Q(x,·)
witness
space
Challenge
determines
work level d
22
Blockchain-based Consensus
Search for witness
takes time exp(d)
Verification is easy!
(a complexity lower bound Challenge is unpredictable!
needs to be assumed)
Blockchain Protocols (2)
n parties, hash functions G(), H()
Players have/maintain a state C of the form:
G(
si-1
xi-1
)
ctr
H(·)< T
…,xi-1,xi,… : inputs, ctr = 0,1,2,…
23
Blockchain-based Consensus
G(
si
xi
)
ctr
Blockchain Protocols (3)
SHA-256(·)
Performing “work”
ctr := 0; while Hash(ctr; Hash(si,xi)) > T do ctr++
T: block’s “target” (difficulty level)
(T = 0000000000000000171A8B000000000000000000000000000000000000000000)
If while loop terminates "broadcast“ (si,xi,ctr)
(new “block”: state, input [set of transactions], counter)
24
Blockchain-based Consensus
Our Model: q-bounded Setting
Synchronous operation: time is divided in rounds
n parties, t are controlled by the adversary
Assume a “random oracle” (RO) ─ SHA-256
• In each round, each player is allowed q queries to RO. Sends
messages through a diffusion mechanism (“broadcast”)
Adversary may:
1. Spoof messages
2. Generate arbitrary number of messages
No authentication infrastructure; n and t are not known
25
Blockchain-based Consensus
The Bitcoin Backbone Protocol (1)
Parameterized by V(), I(), R(), and hash functions G(), H()
Players have/maintain a state C of the form:
G(
si-1
xi-1
)
ctr
H(·)< T
G(
si
xi
The contents of C satisfy the predicate V(x1,…,xi) = true
26
Blockchain-based Consensus
)
ctr
The Bitcoin Backbone (2)
Parameterized by V(), I(), R(), and hash functions G(), H()
Within a round, parties receive inputs from the environment and
the network and process them:
xi+1 ꞉꞊ I(…all local info…)
Then they use their q queries to H() to obtain a new block by
trying ctr = 0,1,2,…
G(
27
Blockchain-based Consensus
si+1
xi+1
)
ctr
The Bitcoin Backbone (3)
Parameterized by V(), I(), R(), and hash functions G(), H()
If a party solves a POW, it extends C :
G(
si-1
xi-1
)
ctr
G(
si
xi
)
ctr
G(
si+1
xi+1
The new C is propagated to all parties via (the unreliable/
anonymous) broadcast
28
Blockchain-based Consensus
)
ctr
The Bitcoin Backbone (4)
Parameterized by V(), I(), R(), and hash functions G(), H()
A party will compare any incoming chains and the local chain wrt
their length/difficulty:
si-1
G(
G(
xi-1
s’i-1
yi-1
)
)
ctr
ctr
G(
G(
si
xi
s’i
yi
)
ctr
)
ctr
G(
Blockchain-based Consensus
xi+1
)
ctr
Better chain ─ adopt!
Finally, when requested, a player will return R(x1,…,xi)
29
si+1
The Bitcoin Backbone (5)
Size does matter: longest chain wins
• If (si ≠ si’) then parties compare their respective sizes in terms of
difficulty/number of blocks
Parties’ basic rule: If my chain is not smaller, I keep it; else I
switch to the new one
30
Blockchain-based Consensus
Backbone Protocol Properties
31
Common Prefix
Chain Quality
(informal)
(informal)
If two parties "prune"
prune" a
sufficient number of blocks
from their chains,
chains, they will
obtain the same prefix
Any (large enough) chunk of
an honest party’s
arty’s chain will
contain some blocks from
honest parties
Blockchain-based Consensus
Backbone Protocol Properties
32
Common Prefix
Chain Quality
(informal)
(informal)
If two parties "prune"
prune" a
sufficient number of blocks
from their chains,
chains, they will
obtain the same prefix
Any (large enough) chunk of
an honest player’s chain will
contain some blocks from
honest players
Blockchain-based Consensus
Common Prefix: Will Parties Converge?
33
Blockchain-based Consensus
Notation
α: Expected POW solutions by honest parties in a round
β: Adversary’s expected POW solutions in a round
f=α+β
(Total expected POWs/round)
We will require f << 1
γ = α − α2: Prob. that exactly one honest party solves a POW in a
round ( “uniquely successful round” )
34
Blockchain-based Consensus
Common Prefix Property (1)
Theorem (Common prefix). No matter the adversary’s strategy, the
chains of two honest parties will not “fork” in the last k blocks with prob.
1 – e-Ω(k)
Provided γ > λβ for some λ ε [1,∞) and λ2 − fλ − 1 ≥ 0
Relation between “good” and “bad”
hashing power
35
Blockchain-based Consensus
Common Prefix Property (2)
Common-prefix theorem: (proof idea)
• Uniform round: Round where all honest parties invoke a POW with a
chain of the same length
• Uniquely successful round: Round when exactly one honest party is
successful
uniform uniquely successful round
p1
p2
p1,p2,p3,p4
p3
p4
36
Blockchain-based Consensus
convergence block
Common Prefix Property (3)
Common-prefix theorem: (proof idea, cont’d)
• Uniform uniquely successful rounds (u.u.s) allow parties to reach a
"convergence block"
• To maintain a "fork,” adv. must produce a POW for each convergence
block
• The rate of u.u.s. rounds is (1 − β)γ
Thus, in order for the adversary to maintain a fork for
a certain length
β > (1 − β)γ
which is equivalent to λ2 − fλ − 1 < 0, contradicting
assumption (λ2 − fλ − 1 ≥ 0) …
(QED)
37
Blockchain-based Consensus
Common Prefix Property (4)
Now, if f → 0 we can let λ → 1
(adversarial tolerance up to 50%)
(fast information propagation)
As f → 1 we have λ → 0
W/ ≠ tie-breaking rule: f → 1 we have λ → (1 + √5)/2 (Golden Ratio)
Adversarial bound (y-axis) wrt
network synchronization f (x-axis)
so that common prefix is ensured
in Bitcoin (blue) vs. Bitcoin with
lexicographic tie-breaking (red)
38
Blockchain-based Consensus
Backbone Protocol Properties
39
Common Prefix
Chain Quality
(informal)
(informal)
If two parties ""prune
prune"" a
sufficient number of blocks
from their chains,
chains, they will
obtain the same prefix
Any (large enough) chunk of
an honest player’s chain will
contain some blocks from
honest players
Blockchain-based Consensus
Chain Quality Property (1)
Will honest blocks be adopted by the honest parties?
Theorem (Chain quality). Any sequence of l blocks in an honest party’s
chain will contain a 1− 1/λ proportion of honest blocks with probability
1 − e−Ω(l )
Provided γ > λβ, λ ε [1,∞), λ2 − fλ − 1 ≥ 0
40
Blockchain-based Consensus
Chain Quality Property (2)
The theorem is tight
• There is an adversarial strategy that restricts the honest parties to a
ratio of exactly 1− 1/λ
• The strategy is a type of selfish mining [ES14]
o Malicious parties mine blocks in private attempting to “hit” honest
parties’ blocks when they become available
41
Blockchain-based Consensus
Chain Quality Property (3)
Ideal chain quality: A set of parties with hashing power α may
control up to αL blocks in a blockchain of length L
Our chain quality bound is much more pessimistic: as β → 1/2
the adversary can control almost all the blocks
Selfish mining implies that this is tight
• Bitcoin‘s rewarding mechanism is not incentive-compatible
42
Blockchain-based Consensus
Talk Outline
Distributed Consensus: Brief Recap
Blockchain Protocols
Blockchain-based Consensus
Other POW-based Protocols
Summary and Open Problems
Blokchain-based Consensus
Blockchain-based Consensus
Application of Backbone Protocol
•
App’s specify V(·), I(·), R(·)
Distributed Consensus (aka BA) [PSL80, LSP82]: n parties start
with an initial value vi
•
•
•
45
Agreement: All honest parties output the same value
Validity: If all honest parties start with the same input (say, v), then
they output this value
Termination: Parties eventually terminate
Blockchain-based Consensus
Blockchain-based Consensus (2)
BA in a non-standard setting
Related to “anonymous model without port awareness” [Okun05]
• Impossibility of deterministic solutions
• Randomized (inefficient) protocol; corrupt parties send one
msg/round
New ingredient: Use of POWs
46
Blockchain-based Consensus
Nakamoto’s Consensus Protocol [Nak08b]
The n parties start building a blockchain inserting their input
If a party receives a longer blockchain, it switches to that one and
switches its input
When the blockchain is long enough the party outputs the (unique)
value that it contains
Issue: If adv. finds a solution first, then honest parties will extend
adv.’s solution and switch to adv.’s input → protocol doesn’t
guarantee Validity with overwhelming prob.
47
Blockchain-based Consensus
Nakamoto’s Consensus Protocol [Nak08b] (2)
48
Blockchain-based Consensus
Our First Blockchain-based Consensus Protocol
The n parties start building a blockchain inserting their inputs
If a party receives a longer blockchain switches to that one but
keeps the same input
Once the blockchain is long enough (2k) the parties prune the last k
blocks and output the majority value in the prefix
We get:
• Agreement from the Common Prefix property
• Validity as long as adv. controls < ⅓ of the parties (need λ ≥ 2(1+δ))
(Chain Quality property)
• Properties satisfied with prob. 1 − e−Ω(k )
49
Blockchain-based Consensus
Our First Blockchain-based Consensus Protocol (2)
Strong Validity: The output value is one of the honest parties’
inputs
Relevant when |V| > 2
γ ≥ |V|(1+δ)β ensures that the no. of blocks controlled by adv. is
< 1 ⁄ |V|
• Consistent with known bound for standard (cryptographic) setting: n > |V|t
[FG03]
50
Blockchain-based Consensus
Summary of Results (1)
51
Blockchain-based Consensus
Our Second Blockchain-based Consensus Protocol
Robust transaction ledgers: n unauthenticated parties accept
transactions and build a ledger so that the following properties are
satisfied:
(i) Persistence: If a transaction is "deep" enough in the ledger for one
honest party, then it will be reported by all honest parties at the same
location
(ii) Liveness: If a transaction is attempted to get installed for a “large
enough” no. of rounds, eventually it will be installed
Common Prefix → Persistence, Chain Quality → Liveness
(see paper)
52
The Bitcoin Backbone Protocol: Analysis and Applications
Summary of Results (2)
53
The Bitcoin Backbone Protocol: Analysis and Applications
Does Robust Transaction Ledger → Consensus?
Not really: Liveness is weaker than Validity. It only guarantees that
transaction will be included in the output
Reason: Chain Quality is too low; honest parties’ inputs stored in
transactions may get “drowned” due to selfish mining
Our approach: Use POWs at the transaction layer as well
54
The Bitcoin Backbone Protocol: Analysis and Applications
Our Second Blockchain-based Consensus Protocol (2)
The n parties generate a ledger but now generate transactions
based on POWs that contain their inputs ─ input itself must satisfy
POW predicate
(Hash(ctr, Hash(nonce, v)) < T) ˄ ctr ≤ q
Once the blockchain is long enough the parties prune the last k
blocks and output the majority of the values drawn from the set of
transactions in the ledger
Protocol tolerates (1/2)-bounded adversaries
• Second/transaction POW improves Chain Quality
55
The Bitcoin Backbone Protocol: Analysis and Applications
Our Second Blockchain-based Consensus Protocol (3)
Beware! Given that POWs are now used for two different tasks
How do we prevent the adversary from shifting its
hashing power from one to the other?
56
The Bitcoin Backbone Protocol: Analysis and Applications
2-for-1 POWs: Composition of POW-based Protocols (1)
h ← G(x,s)
if H(h,ctr) < T then…
h’ ← G(x’,s’)
if H(h’,ctr’) < T’ then…
Given ((x,s), ctr)
Verify H(G(h,s), ctr) < T
Given ((x’,s’), ctr’)
Verify H(G(h’,s’), ctr’) < T’
57
The Bitcoin Backbone Protocol: Analysis and Applications
Not
secure
2-for-1 POWs: Composition of POW-based Protocols (2)
h ← G(x,s)
if H(h,ctr) < T then…
h ← G(x,s)
h’ ← G(x’,s’)
w ← H(h,h’,ctr)
h’ ← G(x’,s’)
if H(h’,ctr’) < T’ then…
Given ((x,s), ctr)
Verify H(G(h,s), ctr) < T
Given ((x’,s’), ctr’)
Verify H(G(h’,s’), ctr’) < T’
58
The Bitcoin Backbone Protocol: Analysis and Applications
if w < T then…
if [w]R < T’ then…
Not
secure
Given ((s,x),(*,*) ctr)
Verify
[H(G(s,x),G(*,*), ctr)] < T
2-for-1 POWs: Composition of POW-based Protocols (3)
h ← G(x,s)
if H(h,ctr) < T then…
h ← G(x,s)
h’ ← G(x’,s’)
w ← H(h,h’,ctr)
h’ ← G(x’,s’)
if H(h’,ctr’) < T’ then…
Given ((x,s), ctr)
Verify H(G(h,s), ctr) < T
Given ((x’,s’), ctr’)
Verify H(G(h’,s’), ctr’) < T’
59
The Bitcoin Backbone Protocol: Analysis and Applications
if w < T then…
if [w]R < T’ then…
Not
secure
Given ((*,*),(s’,x’) ctr’)
Verify
[H(G(*,*),G(s’,x’), ctr’)]R < T’
Summary of Results (3)
60
The Bitcoin Backbone Protocol: Analysis and Applications
Blockchain-based Consensus Protocols: Remarks
Tolerating (1/2)-bounded adversaries is optimal (e.g., [Fit03])
Unpredictability of first (“genesis”) block
61
The Bitcoin Backbone Protocol: Analysis and Applications
Talk Outline
Distributed Consensus: Brief Recap
Blockchain Protocols
Blockchain-based Consensus
Other POW-based Protocols
Summary and Open Problems
Other POW-based Protocols
Other POW-based Protocols
Identity assignment tool [AJK05]
• Combat “sybil” (fake-identity) attacks [D02]
• Establish PKI: no. identities proportional to parties’ computing power;
run standard authenticated agreement protocol [DS82]
POW-based secure multi-party computation (MPC)
64
Blockchain-based Consensus
Secure Multi-party Computation [Y82, GMW87]
n parties
t corrupted
x2
x1
x3
...
xn
MPC Protocol
y
y
y
y
...
y = f(x1,x2,…,xn)
correctness and
privacy
65
Blockchain-based Consensus
Other POW-based Protocols
Identity assignment tool [AJK05]
• Combat “sybil” (fake-identity) attacks [D02]
• Establish PKI: no. identities proportional to parties’ computing power;
run standard authenticated agreement protocol [DS82]
POW-based secure multi-party computation (MPC)
66
Blockchain-based Consensus
Other POW-based Protocols
Identity assignment tool [AJK05]
• Combat “sybil” (fake-identity) attacks [D02]
• Establish PKI: no. identities proportional to parties’ computing power;
run standard authenticated agreement protocol [DS82]
POW-based secure multi-party computation (MPC)
• Use POWs to solve Interactive Set Consistency [KMS14]
o Pseudonymous PKI → Broadcast [DS82] + MPC [GMW87]
o Puzzles are unpredictable
67
Blockchain-based Consensus
Other POW-based Protocols
Identity assignment tool [AJK05]
• Combat “sybil” (fake-identity) attacks [D02]
• Establish PKI: no. identities proportional to parties’ computing power;
run standard authenticated agreement protocol [DS82]
POW-based secure multi-party computation (MPC)
• Use POWs to solve Interactive Set Consistency [KMS14]
o Pseudonymous PKI → Broadcast [DS82] + MPC [GMW87]
o Assumes unpredictable puzzles
• POW-based MPC without trusted setup [AD15]
68
o Consistent PKI (as opposed to [AJK05])
o No precomputation attacks!
o Assumes max no. of messages in a single round
Blockchain-based Consensus
Summary and Open Questions
Studied consensus in a new, non-standard setting: blockchains
•
Bitcoin Backbone: “Common Prefix” and “Chain Quality” as foundations for
consensus and robust transaction ledger protocols
Deviations of concern
•
•
Network synchronization vis-à-vis POW rate: fast information propagation is
essential
Adv.’s contributions to blockchain can be strictly larger than β: transaction
liveness becomes fragile as β → 1/2
Analysis assumes fixed (yet unknown) no. of participants
•
Variable difficulty: “Target T” may be calibrated according to the no. of
active players
Consensus, MPC with no trusted setup and no unpredictability
assumption
•
69
POWs + ??
The Bitcoin Backbone Protocol: Analysis and Applications
References
J. Garay, A. Kiayias and N. Leonardos, “The Bitcoin Backbone Protocol:
Analysis and Applications.” Eurocrypt 2015. Full version: Cryptology
ePrint Archive Report 2014/765
http://eprint.iacr.org/2014/765
70
Blockchain-based Consensus
Thanks!
Thanks!