cryptocurrency and blockchain research · 2018. 3. 15. · replacing nonce with attestation suppose...
Post on 11-Oct-2020
2 Views
Preview:
TRANSCRIPT
Cryptocurrency and Blockchain ResearchCHANATHIP NAMPREMPRE, PH.D.
1
Agenda
Recall bitcoin consensus protocol
Components of bitcoin consensus protocol
Variations on the same theme
Beware of snake oil
Solution: secure protocol design and analysis
Example from cryptography: modes of operation
Conclusion
2
Recall bitcoin blockchain: adding a block
Genesis block
The Times
03/Jan/2009
Chancellor
on brink of
second
bailout for
banks
nonceH(•)tx1
tx2
To add the next block, find “nonce” such that00…..0xxxxxx…xxxx = H( nonce ph tx1 tx2 … )
ph•••
txn(reward)
3
nonceH(•)tx1
tx2
ph
txn(reward)
Recall bitcoin blockchain: forking
Genesis block
The Times
… bailout for
banks
H(•)ph
••• H(•)
tx1
ph
H(•)
tx1’
ph
H(•)ph
H(•)ph
4
Bitcoin consensus protocol: GOAL
All honest participants agree on the order in which blocks are appended to the chain.
5
The Times
03/Jan/2009
Chancellor
… bailout for
banks
H(•)
tx
ph••• H(•)
tx
phH(•)
ph
tx
tx
tx
tx
Bitcoin consensus protocol
1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into blocks.
3. In each round, a winning node gets to add its block to the chain.
4. Other nodes accept the block only if all transactions in it are valid.
5. Nodes express their approval of the block by including its hash in the next block they create.
source: Bitcoin and Cryptocurrency Technology, Narayanan, et. al. 2016
“Leader” election
Transactions record money transfers.
6
Ledger is a blockchain.
TransactionBitcoin Bitcoin: money transfer
Alternatives:
• smart contracts
• medical records
• college degrees
• …
7
Transaction ID 73in:
H(•), index, signature, pkH(•), index, signature, pkH(•), index, signature, pk
out:index, value, H(pk)index, value, H(pk)index, value, H(pk)
Transaction ID 68in:
H(•), index, signature, pkH(•), index, signature, pkH(•), index, signature, pk
out:index, value, H(pk)index, value, H(pk)index, value, H(pk)
Transaction ID 42in:
H(•), index, signature, pkH(•), index, signature, pkH(•), index, signature, pk
out:index, value, H(pk)index, value, H(pk)
scriptSig
scriptPubSig
redeeming transactionreferenced transaction
referenced transaction 7
LedgerBitcoin Bitcoin: chain of blocks
ledger = blockchain
Alternatives:
• individual transactions
ledger = Directed Acyclic Graph
(GHOST, SPECTRE, Meshcash, Hashgraph, etc.)
• “batched” transactions
(IOTA)
8
The Times
03/Jan/2009
Chancellor
… bailout for
banks
H(•)
tx
ph••• H(•)
tx
phH(•)
ph
tx
tx
tx
tx
Leader electionBitcoin Bitcoin: proof-of-work
Alternatives:
• proof-of-stake
(Ouroboros, Algorand)
• proof-of-elapsed-time
(Sawtooth Lake)
• proof-of-luck
(Berkeley)
• …9
To add a block to the chain, find “nonce” such that
00…..0xxxxxx…xxxx = H( nonce ph tx1 tx2 … )
Leader election via Proof-of-Elasped-Time (PoET)
Observation:
Bitcoin proof-of-work, namely the nonce, is evidence that the winning node has taken about 10 minutes to find a nonce that works.
Alternative:
A node can just wait 10 minutes then can provide a proof that it has waited.
10
00…..0xxxxxx…xxxx = H( nonce ph tx1 tx2 … )
Intel SGX (Software Guard eXtensions)
Attestation:
Prove to a remote party what software was loaded on my machine
Applications:
• Bank allows money transfer only if customer has patched his device.
• Gamers can join network only if their game client is unmodified.
Source: Dan Boneh’s course notes.
11
Replacing nonce with attestationSuppose P is the program “wait 10 minutes”
12
P
Attestation server
Intel SGX
attestation
attestation
H(•)tx1
tx2
ph
txn(reward)
Participation in protocolBitcoin Bitcoin: permissionless with
dynamic join/leave
Alternatives:
• permissioned with static membership
• permissioned with semi-static membership (no join/leave during each “round”, but ok between “rounds”)
• …
13
Participation in leader election protocolBitcoin Bitcoin: all mining nodes
Alternatives:
• a fixed subset (e.g., Honey Badger)
• a dynamic subset [e.g.,
endorsers (Ouroboros)
committee members (Algorand)
validators (Tendermint)
trusted quorums (Stellar), …]
14
Participation in leader election protocolBitcoin Bitcoin: all mining nodes
Alternatives:
• a fixed subset (e.g., Honey Badger)
• a dynamic subset [e.g.,
endorsers (Ouroboros)
committee members (Algorand)
validators (Tendermint)
trusted quorums (Stellar), …]
15
Failure modesBitcoin Bitcoin: Byzantine
Alternatives:
• fail-stop (crash only)
• honest-but-curious
• honest-but-lazy
(in this model, Algorand can tolerate failure of majority of nodes!)
• …
16
ClocksBitcoin Bitcoin: loosely synchronized (NTP)
Alternatives:
• strongly synchronized
• same speed (Algorand)
• …
17
Message delivery modelBitcoin Bitcoin: unreliable
Alternatives:
• reliable with known delay
(msgs are delivered correctly and exactly once within a certain amount of time)
• reliable with unknown delay
18
dropped/modified/ injected
Timing modelBitcoin Bitcoin: asynchronous
(msgs can take arbitrarily long to arrive, and processor speeds can be vastly different)
(different from the ‘A’ in AJAX)
Alternatives:
• synchronous
(msg delays are bounded, and differences in processor speeds are bounded)
• eventually synchronous
• weakly synchronous
• strongly synchronous
• …19
fastslow
Timing model [Dwork and Lynch, 1988]
In a synchronous system, there is a known fixed upper bound A on the time required for a message to be sent from one processor to another and a known fixed upper bound B on the relative speeds of different processors.
In an asynchronous system, no fixed upper bounds A and B exist.
In an eventually synchronous system, the system is synchronous most of the time but may experience periods of asynchrony.
20
Consensus protocol example: AlgorandTransaction: any
Ledger: blockchain
Leader election: proof-of-stake
Participation: permissionless
Participation in leader election: committee
Failure modes: byzantine
Message delivery: reliable (gossip protocol)
Timing: strong synchrony (liveness)
weak synchrony (safety)
Clock: same speed
21
Recall Bitcoin consensus protocol
1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into blocks.
3. In each round, a winning node gets to add its block to the chain.
4. Other nodes accept the block only if all transactions in it are valid.
5. Nodes express their approval of the block by extending the chain from it.
22
a. Select committee members based on stakesb. Committee members vote on winner based on stakes
Algorand
a. Select committee members based on stakes• Cannot be done deterministically
• Cannot be done in multiple steps
• Must be done in secret
b. Committee members vote on winner based on stakes
23
committee members may be targeted!
sortition
Verifiable Random Function (VRF)
VRF = (F, VF) such that, for any public-secret key pair (pk,sk),
• (h,p) = F(sk,x)
On input x, the algorithm F returns a hash and a proof.
The hash h is “random” to anyone who does not know sk.
• b = VF(pk,x,h,p)
On input pk, x, h, and p, the algorithm VF returns a bit.
The proof p lets anyone with pk verify that h corresponds to x.
24
Implementing VRF with digital signatures
VRF = (F, VF) such that, for any public-secret key pair (pk,sk),
• (h,p) = F(sk,x)
On input x, the algorithm F returns a hash and a proof.
The hash h is “random” to anyone who does not know sk.
• b = VF(pk,x,h,p)
On input pk, x, h, and p, the algorithm VF returns a bit.
The proof p lets anyone with pk verify that h corresponds to x.
25
p Sign( sk, x ) ; h H( p )
Vf( pk, x, p ) ˄ h == H( p )
Algorand (much simplified)
a. Select committee members based on stakes• Cannot be done deterministically
• Cannot be done in multiple steps
• Must be done in secret
b. Committee members vote on winner based on stakes
26
(h,p) VRF(sk, seed||role)
• seed0 agreed through distributed random number generation
• seedr = hr
Algorand (much simplified)
a. Select committee members based on stakes• Cannot be done deterministically
• Cannot be done in multiple steps
• Must be done in secret
b. Committee members vote on winner based on stakes
27
(h,p,j) Sortition(sk, seed,role,w,W)
Algorand (much simplified)
a. Select committee members based on stakes• Cannot be done deterministically
• Cannot be done in multiple steps
• Must be done in secret
b. Committee members vote on winner based on stakes
Block with highest priority wins.
28
For i in {1,…,j},block priority max(block priority, H(h||i))
(h,p,j) Sortition(sk, seed,role,w,W)
Algorand claims
75-page paper with tons of proofs of
• safety
• liveness
• other properties
under various timing models, message delivery models, etc.
29
others?
30
Being able to model the system helps!
31
Summary of consensus resilience properties, some of which use statically configured nodes with a special role.
Symbols and notes: ‘✓’ means that the protocol is resilient against the fault and ‘−’ that it is not; ‘.’ states that no such special node exists in the protocol; ‘?’ denotes that the properties cannot be assessed due to lack of information; (✓) denotes the crash of other nodes, different from the special node; + MultiChain has non-final decisions; ⊕ PoET assumes trusted hardware available from only one vendor; ⊗ Ripple tolerates one of the five default Ripple-operated validators (special nodes) to be subverted.
Source: Blockchain consensus protocols in the wild. Christian Cachin and Marko Vukolic. IBM Zurich. 2017.
Results from distributed systems research• FLP: In an asynchronous model with reliable links, no deterministic
protocol can achieve consensus when at least one party can crash.
[ asynchronous parties, reliable links, f ≥ 1 in fail-stop model ]
• PBFT: In an eventually synchronous model with reliable links, parties running PBFT protocol can reach consensus as long as no more than one third of all parties can be malicious.
[ eventually synchronous parties, reliable links, f ≤ n/3 in byzantine model ]
[FLP]: Impossibility of Distributed Consensus with One Faulty Process, Fischer, Lynch, and Paterson, 1985.
[PBFT]: Practical Byzantine Fault Tolerance, Castro and Liskov, 1999.
32
Meanwhile…
We still see claims like this:
“Every transaction is replicated to every node. When a majority of nodes have replicated the transaction, the transaction is committed.” – Kadena based on ScaleableBFT
Model: asynchronous with byzantine failures
33
Snake oil?
Unsupported, hard to verify claims abound.
This situation has happened before!
Look at the history of modern cryptography.
34
Block ciphers and modes of operation
FIPS-80: DES and modes of operation
Various modes proposed: ECB, CBC, CTR, OFB, CFB
Assuming that the underlying block cipher is perfect, are these modes any good?
35
ECB encryption mode: definition
36
Source: Symmetric Cryptography Basics, Chanathip Namprempre, 2011.
ECB encryption mode: secure?
37
Source: Wikipedia
ECB insecurity
38
Modeling primitives and defining security definitions
Block cipher
• What is it: family of permutations
• What it means to be secure: PRP-CPA, PRP-CCA
Symmetric encryption scheme
• What is it: three algorithms satisfying a correctness condition
• What it means to be secure: IND-CPA, IND-CCA
39
Results?
• ECB is not IND-CPA.
• CBC with counter IV is not IND-CPA.
• CBC with random IV is IND-CPA but not IND-CCA.
• CTR with random IV is IND-CPA but not IND-CCA.
• CTR with counter IV is IND-CPA but not IND-CCA.
• CTR with counter IV is more secure than CTR with random IV.
• etc.
40
Theory catching up with practice
Modern cryptography
• Block ciphers were proposed and used.
• Then, models and proofs were developed.
41
Cryptocurrencies and distributed systems
• Bitcoin is proposed and used.
• Then, models and proofs are being developed!
What makes a good consensus protocol?
Efficient:
• throughput? latency? average case? worse case?
Secure:
• DOS? targeted attack?
• Prevent/eliminate forks?
• Liveness? Safety?
42
Safety and LivenessSafety: Nothing bad happens.
With overwhelming probability, all nodes agree on the same order of transactions.
If one honest node accepts transaction A (i.e., it appears on the chain), then with overwhelming probability any future transactions accepted by other honest nodes will be on the chain that already contains A.
Liveness: Something good eventually happens.
With overwhelming probability, new transactions get added to the chain.
During synchronous period, with overwhelming probability honest nodes eventually add a new transaction to the chain.
43
State of the art
Security models and proofs for “blockchain” systems are emerging.
But the models and security definitions are complicated and hard to work with.
Plenty of room for improvement! We can start with devising simpler, cleaner models and definitions.
44
45
top related