OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding Philipp Jovanovic (@daeinar) Distributed and Decentralized Systems Lab (DEDIS) École polytechnique fédérale de Lausanne (EPFL) IEEE International Verification and Security Workshop 2018-07-04, Platja D’Aro
Acknowledgements Eleftherios Kokoris Kogias Nicolas Gailly Linus Gasser Ewa Syta Bryan Ford (EPFL, CH) (EPFL, CH) (EPFL, CH) (Trinity College, USA) (EPFL, CH) 2
Talk Outline • Motivation • OmniLedger • Evaluation • Conclusion 3
Talk Outline • Motivation • OmniLedger • Evaluation • Conclusion 4
The Core of Bitcoin: Nakamoto Consensus Drawbacks Miner of the The Bitcoin p2p network latest block • Transaction confirmation delay ‣ Bitcoin: Any tx takes >10 mins until confirmed • Low throughput “Permanently” committed ‣ Bitcoin: ~4 tx/sec transactions • Weak consistency ‣ Bitcoin: You are not really certain your tx is committed until you wait >1 hour 10 mins } • Proof-of-work mining } 1 MB blocks ‣ Wastes huge amount of energy The Bitcoin blockchain 5
… But Scaling Blockchains is Not Easy Miner of The Bitcoin p2p network latest block “Permanently” committed transactions Still Cannot just add 10 mins more hardware for } better performance! } Still 1 MB blocks The Bitcoin blockchain 6
What we Want: Scale-Out Performance Ideal system Bitcoin Throughput [tx/sec] n 2n 3n 4n 5n 6n Number of Validators Scale-out : Throughput increases linearly with the available resources. 7
Towards Scale-Out Performance via Sharding • Concept: Blockchain 1 ‣ Validators are grouped into distinct subsets ‣ Each subset processes different transactions Transactions ‣ Achieves parallelization and therefore scale-out • But: Blockchain 2 ‣ How to assign validators to shards? ‣ How to send transactions across shards? Transactions � 8
Distributed Ledger Landscape Decentralization E. Kokoris Kogias et al., Enhancing L. Luu et al., A Secure Sharding Elastico Bitcoin Security and Performance with ByzCoin Protocol for Open Blockchains , Strong Consistency via Collective Signing , CCS 2016 USENIX Security 2016 OmniLedger RSCoin Scale-Out Security G. Danezis and S. Meiklejohn, Centrally Banked Cryptocurrencies , NDSS 2016 9
Talk Outline • Motivation • OmniLedger • Evaluation • Conclusion 10
OmniLedger – Design Goals Security Goals 1. Full Decentralization 2. Shard Robustness 3. Secure Transactions No trusted third parties or Shards process txs Txs commit atomically or single points of failure correctly and continuously abort eventually Performance Goals 4. Scale-out 5. Low Storage 6. Low Latency Throughput increases linearly in Validators do not need to store Tx are confirmed quickly the number of active validators the entire shard tx history Assumptions: <= 25% mildly adaptive Byzantine adversary, (partially) synchronous network, UTXO model 11
Strawman: SimpleLedger Overview Shard coordinator conf e • Evolves in epochs e • Trusted source releases shard configuration conf e Validators • Validators: ‣ Bootstrap from the shard ledger according to conf e ‣ Process transactions in parallel using per-shard consensus Shard ledgers Shard 1 Shard 2 Shard 3 (ByzCoin group) (ByzCoin group) (ByzCoin group) 12
Strawman: SimpleLedger Security Drawbacks Shard coordinator • Shard coordinator: trusted third party conf e • No tx processing during validator re-assignment Validators • No cross-shard tx support Performance Drawbacks • ByzCoin failure mode • High storage and bootstrapping cost • Throughput vs. latency trade-off Shard ledgers Shard 1 Shard 2 Shard 3 (ByzCoin group) (ByzCoin group) (ByzCoin group) 13
Roadmap SimpleLedger Randomized sharding Security Secure system reconfigurations Atomic cross-shard transactions Failure-resistant Byzantine consensus Performance Blockchain pruning High-throughput low-latency transaction validation OmniLedger 14
Roadmap SimpleLedger Randomized sharding Security Secure system reconfigurations Atomic cross-shard transactions Failure-resistant Byzantine consensus Performance Blockchain pruning High-throughput low-latency transaction validation OmniLedger 15
Roadmap SimpleLedger Randomized sharding Security Secure system reconfigurations Atomic cross-shard transactions Failure-resistant Byzantine consensus Performance Blockchain pruning High-throughput low-latency transaction validation OmniLedger 16
Shard Validator Assignment • How to assign validators to shards? ‣ Deterministically: Adversary can use predictable assignments to his advantage ‣ Randomly: Adversary cannot control or predict assignment • How to ensure long-term shard security against an adaptive adversary? ‣ Make shards large enough ‣ Periodically re-assign validators to shards 17
Shard Validator Assignment • Challenge: Unbiasable, unpredictable and scalable shard validator assignment • Solution: Combine VRF-based lottery and unbiasable randomness protocol for sharding 1. Temp. leader election 2. Randomness generation 3. Shard assignment via VRFs (biasable) via RandHound* (unbiasable) (using rnd e ) Verifiable Temp. randomness rnd e leader PVSS PVSS Validators group 1 group 2 Validators (sharded) *Scalable Bias-resistant Distributed Randomness, E. Syta et al., IEEE S&P’17 18
Roadmap SimpleLedger Randomized sharding Security Secure system reconfigurations Atomic cross-shard transactions Failure-resistant Byzantine consensus Performance Blockchain pruning High-throughput low-latency transaction validation OmniLedger 19
Two-Phase Commits Coordinator Server Query to commit { Voting phase Vote yes / no Commit / rollback { Completion phase Acknowledgement Problem: Does not work in a Byzantine setting as malicious nodes can always abort. 20
Atomix: Secure Cross-Shard Transactions • Challenge: Cross-shard transactions commit atomically or abort eventually • Solution: Atomix, a secure cross-shard transaction protocol (utilizing secure BFT shards) (1) Initialize (2a) Lock (3a) Commit Client Client cross-shard ACK 1 ACK 2 transaction tx commit tx 1 2 3 1 2 3 inputs outputs Shards Shards 1 3 2 (2b) Lock (3b) Rollback Client Client Client tx tx ACK 1 ERR 2 reclaim tx inputs 1 2 3 1 2 3 1 2 3 Shards Shards Shards 21
Roadmap SimpleLedger Randomized sharding Security Secure system reconfigurations Atomic cross-shard transactions Failure-resistant Byzantine consensus Performance Blockchain pruning High-throughput low-latency transaction validation OmniLedger 22
Trust-but-Verify Transaction Validation • Challenge: Latency vs. throughput trade-off • Solution: Two-level “trust-but-verify” validation to get low latency and high throughput small ( e.g. , 500KB) optimistically validated blocks large ( e.g. , 16MB), re-validated blocks tx tx clients shard ledger tx core validators optimistic validators 23
Talk Outline • Motivation • OmniLedger • Evaluation • Conclusion 24
Implementation & Experimental Setup Implementation DeterLab Setup • Go versions of OmniLedger and its • 48 physical machines subprotocols (ByzCoinX, Atomix, etc.) ‣ Intel Xeon E5-2420 v2 (6 cores @ 2.2 GHz) • Based on DEDIS code ‣ 24 GB RAM ‣ Kyber crypto library ‣ 10 Gbps network link ‣ Onet network library • Realistic network configurations ‣ Cothority framework ‣ 20 Mbps bandwidth • https://github.com/dedis ‣ 200 ms round-trip latency 25
Evaluation: Scale-Out 100'000 OmniLedger Bitcoin 10'000 5'850 Throughput [tx/sec] 3'240 1'000 1'674 869 439 100 10 4 4 4 4 4 1 70 / 1 140 / 2 280 / 4 560 / 8 1120 / 16 Number of Validators / Number of Shards For a 12.5%-adversary 26
Evaluation: Maximum Throughput Results for 1800 validators 27
Evaluation: Latency Transaction confirmation latency in seconds for regular and mutli-level validation #shards, adversary 4, 1% 25, 5% 70, 12.5% 600, 25% OmniLedger 1 MB blocks 1.38 5.99 8.04 14.52 regular OmniLedger 500 KB blocks 1.38 1.38 1.38 4.48 confirmation OmniLedger 16 MB blocks 1.38 55.89 41.89 62.96 consistency Bitcoin 1 MB blocks 600 600 600 600 confirmation Bitcoin 3600 3600 3600 3600 consistency latency increase since optimistically validated blocks are batched into larger blocks for final validation to get better throughput � 28
Talk Outline • Motivation • OmniLedger • Experimental Results • Conclusion 29
Conclusion Epoch randomness rnd e (RandHound) Validators OmniLedger – Secure scale-out distributed ledger framework • ‣ Sharding via unbiasable randomness for linearly-scaling throughput ‣ Atomix: Client-managed cross-shard transactions ‣ ByzCoinX: Robust intra-shard BFT consensus ‣ Trust-but-verify validation for low latency Shard and high throughput ledgers ‣ For PoW, PoS, permissioned, etc. Shard 1 Shard 3 Shard 2 (ByzCoinX group) (ByzCoinX group) (ByzCoinX group) Paper: ia.cr/2017/406 (published at IEEE S&P’18) • tx 2,in Code: https://github.com/dedis • tx 1,in tx 3,out Client (Atomix coordinator) Thanks! philipp.jovanovic@epfl.ch – @daeinar 30
Recommend
More recommend
