Cloud Computing (CS293s) Winter 2018 Amr El Abbadi

1. OmniLedger
A Secure, Scale-Out, Decentralized Ledger
via Sharding
Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, Bryan Ford
Ecole Polytechnique Federale de Lausanne, Switzerland
Trinity college, USA
Presented by Sydney Ma
02/21/2018

2. Outline
1. Motivation
2. Omniledger
 SimpleLedger -> OmniLedger
3. Evaluation

3.  High failure probability
 e.g. 100 validator per shard yields 2.76% failure probability per shard
 For 16 shards, the failure probability is 97% over only 6 epochs
 Shard selection may not be bias-resistant
 Miners can selectively discard PoWs to bias results
 Does not ensure transaction atomicity across shards
 Funds could be locked forever
 Large storage
 Validators constantly switch shards resulting each validator to store the global state
 Transaction confirmation delay
 Any transaction takes around10 mins until being confirmed
Drawbacks of Elastico

4. Terms
 Validators
 Entity that validates transactions
 Shard
 Composite of validators that cooperate with each other
 Epoch
 Fixed time between reconfiguration events
 Identity blockchain
 Distributed ledger that stores validators’ identities

5. Assumptions
System
Network
fault-tolerance Validators are evenly distributed across shards
 Each validator i has a key pair (pki ,ski)
 The network graph of honest validators is well connected
 The communication channels between honest validators are synchronous
 Byzantine fault tolerance model (n=4f)
 The adversary is computationally bounded

6. SimpleLedger
 A strawman distributed ledger system that we use to outline OmniLedger
 1. Register new validators in Identity blockchain
 2. Assign validators to shards
 3. Start processing transactions within a shard

7. SimpleLedger
 1. Register new validators in Identity blockchain
new
validator
Identity + proof
Validator
LEADER
Validator
Validator
Shard
Validator
Identity blockchain

8. SimpleLedger
 1. Register new validators in Identity blockchain
new
validator
Identity + proof Validator
LEADER
Validator
Validator
Validator
Send identity to shard
Identity blockchain Shard

9. SimpleLedger
 1. Register new validators in Identity blockchain
new
validator
Validator
LEADER
Validator
Validator
Validator
Identity blockchain Shard

10. SimpleLedger
 1. Register new validators in Identity blockchain
new
validator
Validator
LEADER
Validator
Validator
Validator
ID
approved
Identity blockchain Shard

11. SimpleLedger
 1. Register new validators in Identity blockchain
new
validator
Validator
LEADER
Validator
Validator
Validator
Identity blockchain
ID
approved
Append to identity
blockchain
Shard

12. SimpleLedger
 2. Assign validators to shards (Randomness Beacon)
Validator1
Validator2
Validator3
Shard1 Shard2 Shard 3
Trusted Random Beacon

13. SimpleLedger
 2. Assign validators to shards (Randomness Beacon)
Validator1
Validator2
Validator3
Shard1 Shard2 Shard 3
Trusted Random Beacon

14. SimpleLedger
 2. Assign validators to shards (Randomness Beacon)
Validator1Validator2 Validator3
Shard1 Shard2 Shard 3
Trusted Random Beacon

15. SimpleLedger
 3. Start processing transactions within a shard
Validator
Validator
Validator

16. Drawbacks
 Security Restrictions
 1. Randomness beacon is a trusted third party
 2. The system stops processing transactions during the global reconfiguration at
the beginning of each epoch until enough validators have bootstrapped their
internal states
 3. There is no support for cross-shard transactions

17. Drawbacks continued…
 Performance Restrictions
 1. Its performance deteriorates when nodes start failing (due to ByzCoin’s failure
handling mechanism)
 2. Validators face high storage and bootstrapping overheads
 3. Cannot provide concurrently real-time transaction latencies and high
transaction throughput

18. Hail, Omniledger

19. What is OmniLedger
 “The first scale-out distributed ledger that can
preserve long-term security under permissionless
operation.”
 Permissionless blockchain: Anybody can create an address
and begin interacting with the network.

20. Design Goals of OmniLedger
 1. Full decentralization: No trusted third parties or single points of failure.
 2. Shard robustness: Shards process TXs correctly and continuously.
 3. Secure transactions: TXs commit atomically or abort eventually.
 4. Scale-out performance: Throughput increases linearly in the number of
participating validators.
 5. Low storage overhead: Validators do not need to store the full
transaction history.
 6. Low latency: Transactions are confirmed quickly
Security goals
Performance goals

21. How to securely divide validators into
shards
Solution: RandHound
 A scalable secure multi-party computation protocol
 providing unbiased decentralized randomness in a
Byzantine setting

22. Validator1
Validator2
Validator4Validator3
How to securely divide validators into
shards

23. Validator1
Validator2
Validator4Validator3
Ticket = 10
Ticket =
92
Ticket =
77
Ticket =
23
How to securely divide validators into
shards

24. Validator1
Validator2
Validator4Validator3
Ticket =
77
Ticket =
92
How to securely divide validators into
shards

25. Validator1
(leader)
Validator2
Validator4Validator3
Ticket = 10
Ticket =
10
Ticket =
10
Ticket =
10
How to securely divide validators into
shards

26. Validator1
(leader)
Validator2
Validator4Validator3
Shard 1
Shard 2
How to securely divide validators into
shards

27. Validator1
(leader)
Validator2
Validator4
Validator3
Shard 1
Shard 2
How to securely divide validators into
shards

28. How to ensure security and reliability
of transactions within a shard
Solution: Omnicon
 A consensus protocol that combines
 A tree communication pattern based on groups
 blockDAG

29. blockDAG
 Block-based directed acyclic graph
 Every block can have multiple parents


30. How to handle cross-shard transactions
Solution: Atomix
 A two-phase client-driven “lock/unlock” protocol ensuring clients can
 either fully commit a transaction across all shards
 Or abort eventually

31. Atomix
Client
Input Shard
1
Input Shard
2
Output Shard
3
T
x

32. Atomix (success)
Client
Input Shard
1
Input Shard
2
Output Shard
3
Accept

33. Atomix (success)
Client
Input Shard
1
Input Shard
2
Output Shard
3
Commit

34. Atomix (failure)
Client
Input Shard
1
Input Shard
2
Output Shard
3
Reject

35. Atomix (failure)
Client
Input Shard
1
Input Shard
2
Output Shard
3

36. Refinement - Trade-offs between security and
Latency
 Solution: Trust-but-Verify Validation
 Terms:
 Optimistic validators : follow usual procedures but form much smaller groups (as
smaller as one validator per group)
 Core validators: Verify all provisional commitments, detecting any inconsistencies
and their culprits

37. Trust-but-Verify Validation
Optimistic
Validators
Core Validators

38. Optimistic
Validators
Core Validators
Client
tx
Trust-but-Verify Validation

39. Trust-but-Verify Validation
Optimistic
Validators
Core Validators
Client
tx
Optimistically
validated
blocks

40. Optimistic
Validators
Core Validators
Client
tx
Optimistically
validated
blocks
Finalized
block
Trust-but-Verify Validation

41. Optimistic
Validators
Core Validators
Client
tx
Optimistically
validated
blocks
Shard ledger
Finalized
block
Trust-but-Verify Validation

42. Evaluation
 Experiments setup
 60 physical machines
 Intel E5-2420 v2 CPU, 24 GB of RAM
 A 10 Gbps network link
 restrict the bandwidth of all connections between nodes to 20 Mbps
 Impose a latency of 100 ms on all communication links
 The dataset consists of the first 10,000 blocks of the Bitcoin blockchain

45. Thanks to
 https://blog.acolyer.org/2018/02/09/omniledger-a-secure-
scale-out-decentralized-ledger-via-sharding/
 http://blockchain-workshop.net/talks/jovanovic.pdf