enhancing bitcoin security and performance with … · talk outline o bitcoin and its limitations o...

ENHANCING BITCOIN SECURITY AND PERFORMANCE WITH STRONG CONSISTENCY VIA COLLECTIVE SIGNING

Swiss Federal Institute of Technology Lausanne

25th USENIX Security Symposium – Austin, TX, August 10th, 2016

Lefteris Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser and Bryan FordEPFL

@LefKok

1

Cryptocurrency Ecosystem

729 Companies

2

Distributed Ledger (Blockchain)

o Cheaper transaction managemento M2M payments (IoT)

3

Distributed Ledger (Blockchain)

o Real-time verification is not safe (need 1 hour of delay)o Throughput is low (7 tx/sec)

4

Talk Outlineo Bitcoin and its limitationso Strawman design: PBFTCoino Opening the consensus group o From MACs to Collective Signingo Decoupling transaction verification from leader election o Performance Evaluationo Future work and conclusions

5

6

Transaction Verification in Bitcoin

AàB

Transaction Conflicts

AàB

7

AàC

Transaction Conflicts8

AàB

AàC

Resolving Conflicts9

AàB

AàC

Proof-of-Work

TX TX TX

Hash(Previous Block)

BLOCK

nonce

H(Block, nonce=0) =abc3426fe31233H(Block, nonce=1) =fe541200abc229

.

.

.

.

H(Block, nonce=2) =0bc3429831233

H(Block, nonce=29) =0000fed98312

10

TX TX TX

The Blockchain11

Problem Statement

1. In Bitcoin there is no verifiable commitment of the system that a block will persist

o Clients rely on probabilities to gain confidence.o Probability of successful fork-attack decreases exponentially

12


13

Strawman Design: PBFTCoino 3f+1 fixed “trustees” running PBFT* to withstand f

failureso Non-probabilistic strong consistency

o Low latency

o No forks/inconsistencieso No double-spending

14

L

blockchain

L

block

trustees

leader

*Practical Byzantine Fault Tolerance [Castro/Liskov]

Strawman Design: PBFTCoino Problem: Needs a static consensus groupo Problem: Scalability

o O(n2) communication complexityo O(n) verification complexityo Absence of third-party verifiable proofs (due to MACs)

15

ClientPrimary

Replica 2Replica 3Replica 4

Request Pre-Prepare Prepare Commit Reply


16

Opening the Consensus Group 17

L

blockchain

share window of size w

L

block

share

miner

leader

o PoW against Sybil attackso One share per block

o % of shares ∝ hash-power

o Window mechanismo Protect from inactive miners


18

From MACs to Signing19

o Substitute MACs with public-key cryptographyo ECDSA provides more efficiencyo Third-party verifiableo PoW Blockchain as PKIo Enables sparser communication patterns (ring or star

topologies)

From MACs to Collective Signing20

o Can we do better than O(n) communication complexity?o Multicast protocols transmit information in O(log n)o Use trees!!

o Can we do better than O(n) complexity to verify?o Schnorr multisignatures could be verified in O(1)o Use aggregation!!

o Schnorr multisignatures + communication trees = Collective Signing [Syta et all, IEEE S&P ’16]

21

CoSio Efficient collective signature, verifiable as a

simple signatureo 80 bytes instead of 9KB for 144* co-signers

(Ed25519)

21

* Number of ~10-minute blocks in 1-day time window

Discussiono CoSi is not a BFT protocolo PBFT can be implemented over two subsequent CoSi rounds

o Prepare roundo Commit round

22

L

blockchain

share window of size w

L

block

share

miner

leader

Problem Statement1. In Bitcoin ByzCoin there is no a verifiable commitment

of the system that a block will persist2. Throughput is limited by forkso Increasing block size increases fork probabilityo Liveness exacerbation

23

Talk Outlineo Bitcoin and its limitationso Strawman design: PBFTCoin

o Opening the consensus group

o From MACs to Collective Signing

o Decoupling transaction verification from leader election

o Performance Evaluationo Future work and conclusions

24

Bitcoin-NG [Eyal et all, NSDI ’16]

o Makes the observation that block mining implement two distinct functionalitieso Transaction verificationo Leader election

o But, Bitcoin-NG inherits many of Bitcoin’s problemso Double-spendingo Leader is checked after his epoch ends

25

Decoupling Transaction Verification from Leader Election

o Key blocks: o PoW & share valueo Leader election

o Microblocks: o Validating client transactionso Issued by the leader

26

1 2

1 2 3 4 5

Keyblock

Microblock

Collective Signature


27

Performance Evaluation28

o Experiments run on DeterLab network testbedo Up to 1,008* miners multiplexed atop 36 machineso Impose 200 ms roundtrip latencies between all serverso Impose 35 Mbps bandwidth per miner

* 1008 = # of ~10-minute key-blocks in 1-week time window

Performance Evaluation29

o Key questions to evaluate:o What size consensus groups can ByzCoin scale to?o What transaction throughput can it handle?

Consensus Latency 30

Throughput31


32

Limitationso Attacker with >= 1/3 of the shares

o Can trivially censor transactions / DoS the systemo Can double-spend if he splits the network

o Can currently only scale-up not scale-outo Leader can exclude miners from the consensus

33

Future Work

o Alternatives to PoWo Sharding to enable scaling-outo Incremental deployment to existing cryptocurrencieso Fail more gracefully under 33% attacks

34

Conclusiono Use Collective Signing to scale BFT protocols o Use PoW to create hybrid permissionless BFTo Combine the above with Bitcoin-NG to create

ByzCoino Demonstrate experimentally its practicalityo ByzCoin increases the security and performance of

cryptocurrencies.

35

Thank you

[email protected]

people.epfl.ch/eleftherios.kokoriskogias

@LefKok

36

enhancing bitcoin security and performance with … · talk outline o bitcoin and its limitations o...

Documents