Alternative Consensus

Transcription

1 1 Alternative Consensus DEEP DIVE Alexandra Tran, Dev Ojha, Jeremiah Andrews, Steven Elleman, Ashvin Nihalani

2 2 TODAY S AGENDA GETTING STARTED 1 INTRO TO CONSENSUS AND BFT 2 NAKAMOTO CONSENSUS 3 BFT ALGORITHMS 4 TENDERMINT 5 CASPER 6 FEDERATED CONSENSUS

3 3 1 Introduction

4 4 What is a distributed system? Centralized system: State stored on a single computer Distributed system: State divided over multiple computers Properties of distributed systems: concurrent components message sharing no global clock potential asynchronicity, i.e., message delays and processing delays can be arbitrarily long potential failure of individual components SLIDE CREDIT: ALEXANDRA TRAN

5 5 Distributed Consensus Goal of distributed systems: all components agree on the system s state - they reach a consensus. AUTHOR: ALEXANDRA TRAN

6 6 Correctness of Distributed Systems Leslie Lamport s seemingly simplistic but seminal result in Proving the Correctness of Multiprocess Programs (1977) states that to prove that a program is correct, i.e., achieves its intended goal, one must prove that it has safety and liveness properties. Safety property: guarantee that something will not happen Example: if the program is started with the correct input, then it cannot stop if it does not produce the correct output. Liveness property: guarantee that something must happen Example: a program will terminate if its input is correct Correctness of distributed systems, a.k.a. feasibility of distributed consensus, can thus be described in terms of safety and liveness. Safety in distributed systems: guarantee that different honest components will never decide on different values (agreement) Liveness in distributed systems: guarantee that each honest component will eventually decide on a value (termination) AUTHOR: ALEXANDRA TRAN

7 7 Failure in Distributed Systems Fault tolerance: the ability of a system to operate in the event of failure of one or some of its components Question: can a distributed system retain its ability to reach consensus AND be fault tolerant? Let s first describe potential failures: Network failures vs. node failures One type of network failure is a network partition - loss of connectivity. AUTHOR: ALEXANDRA TRAN

8 Network Partition Partition: at least 2 components of system continue to run, buth can t communicate. Slide by Chris Colohan

9 9 CAP Theorem Consistency: guarantee that reading from different nodes will return the same value. (agreement) Availability: guarantee that reading from any node will return some value. (termination) Partition Tolerance: guarantee that the system will still operate in the face of a network partition, across which some messages between nodes cannot be delivered (fault tolerance) Introduced by Eric Brewer in 2000, the CAP Theorem states that an asynchronous distributed system can at most provide two of the three guarantees at once AUTHOR: ALEXANDRA TRAN

10 10 CAP Theorem Given a partitioned network, the shared state diverges and there will be a tradeoff between consistency and availability. Network partition X AUTHOR: ALEXANDRA TRAN A B C D Y

11 11 CAP Theorem Given a partitioned network, the shared state diverges and there will be a tradeoff between consistency and availability. Network partition X AUTHOR: ALEXANDRA TRAN A B C D?

12 12 Failure in Distributed Systems There also exist individual node failures. One type of node failure are fail-stop nodes. crash, power outage, hardware failure, out of memory AUTHOR: ALEXANDRA TRAN

13 13 FLP Impossibility Impossibility of Distributed Consensus with One Faulty Process by Fischer, Lynch, and Paterson (1985): Both termination and agreement cannot be satisfied immediately in an asynchronous distributed system, if it is to be resilient to at least one fail-stop node. See paper for proof. fault tolerance liveness AUTHOR: ALEXANDRA TRAN safety

14 14 Failure in Distributed Systems Another important type of node failure is a Byzantine failure: a Byzantine node can send conflicting information to different parts of the system, e.g.: Bit flip in memory or on disk corrupts data Older version of code on one node sends (now) invalid messages Node starts running malicious version of software SLIDE CREDIT: CHRIS COLOHAN AND ALEXANDRA TRAN

15 15 Byzantine Fault Tolerance Byzantine fault tolerance is a characteristic of distributed systems that can reach consensus in the face of Byzantine faults A class of failures illustrated by The Byzantine Generals Problem (1982 Lamport, Shostak, and Pease): Multiple divisions of the Byzantine army surround an enemy city; must decide upon common plan: attack or retreat Generals of each division can only communicate individually via messenger There may be traitorous generals who send different votes to different generals What degree of Byzantine failure can be tolerated? n := number of generals. Trivial if n = 1 or n = 2 AUTHOR: ALEXANDRA TRAN

16 16 Byzantine Fault Tolerance n = 3 with 1 traitor: Both scenarios look the same to Lieutenant 1. You cannot tell which general is traitorous and thus, which command to follow. AUTHOR: ALEXANDRA TRAN

17 17 Byzantine Fault Tolerance Theorem: No solution with fewer than 3m + 1 generals can cope with m traitors - i.e., consensus is impossible to achieve if ⅓ or more of the generals are traitors Proof: Assume that a solution exists for >=⅓ traitorous generals use that solution to solve the case of 1 traitor among 3 generals contradiction the assumption is false AUTHOR: ALEXANDRA TRAN

18 18 Impossibility overview Fault Tolerance Safety Tradeoff Assumes asynchronicity? each node will return the same value 2 of 3 yes FLP Impossibility tolerates >= 1 fail-stop node each non-faulty each non-faulty node will return a node will return value the same value 2 of 3 yes Byzantine Generals Problem each non-faulty each non-faulty node will return a node will return value the same value >= ⅔ non-faulty nodes for liveness and safety no CAP Theorem Liveness tolerates network each node will partitions return a value tolerates Byzantine faulty nodes AUTHOR: ALEXANDRA TRAN

19 19 2 Nakamoto Consensus

20 20 Nakamoto Consensus: Proof of Work finding a block : the first announced valid block containing a solution to the mining puzzle, which is linked to a previous chain. Longest chain considered correct. Simultaneously found solutions and malicious mining lead to forks network partitions. The result is different parts of the network containing different values. Thus, favors liveness (availability) over safety (consistency) AUTHOR: ALEXANDRA TRAN

21 Nakamoto Consensus: Naive Proof of Stake finding a block : per chain, the consensus algorithm pseudo-randomly selects a stakeholder in proportion to its stake and assigns it the right to create a single block pointing to the chain. Longest chain considered correct. Again, deviant actors will lead to forks that result in inconsistent network components Thus, favors liveness (availability) over safety (consistency) AUTHOR: ALEXANDRA TRAN 21

22 22 NOTHING AT STAKE PROBLEM AUTHOR: SUNNY AGGARWAL

23 23 NOTHING AT STAKE PROBLEM 0.7h Let h be total hash power mining. Hash power must be split among forks. 0.3h AUTHOR: SUNNY AGGARWAL

24 24 NOTHING AT STAKE PROBLEM 0.7h 0.3h AUTHOR: SUNNY AGGARWAL h

25 25 NOTHING AT STAKE PROBLEM s1 s1 AUTHOR: SUNNY AGGARWAL

26 26 NOTHING AT STAKE PROBLEM s1 s1 AUTHOR: SUNNY AGGARWAL s1 s1 s2 s2 s2 s2

27 27 NOTHING AT STAKE PROBLEM Naive Proof of Stake Proof of Work AUTHOR: SUNNY AGGARWAL

28 28 Introducing Slashing Early PoS chains resorted to hybrid PoW/PoS or developer checkpoints So far, we ve only considered using rewards. What if we introduce penalties? Make a rule that you are only allowed to vote on one fork If you are caught voting on another fork, you get punished on this fork You end up getting punished on both forks AUTHOR: SUNNY AGGARWAL A B A B

29 29 Introducing Slashing AUTHOR: SUNNY AGGARWAL

30 30 Security Deposits Might take some time for proof of malicious double signing to be detected. In that time, the double signer might have moved his money to a different account. No money left in that account to slash. Can t slash the account that the money was sent to Might be some innocent person s account Introducing security deposits Coins used for staking must be locked up in a security deposit (bonding) Can t unbond immediately, funds need to be in holding period Has effect where only excess capital can be used for staking, not all coins Security deposits cannot be forever. People want their money back at some point. AUTHOR: SUNNY AGGARWAL

31 31 Long Range Attacks Let s imagine the unbonding period is three blocks AUTHOR: SUNNY AGGARWAL

32 32 Long Range Attacks Begin unbonding AUTHOR: SUNNY AGGARWAL

33 33 Long Range Attacks Begin unbonding AUTHOR: SUNNY AGGARWAL

34 34 Long Range Attacks Finish unbonding AUTHOR: SUNNY AGGARWAL

35 35 Long Range Attacks Move money AUTHOR: SUNNY AGGARWAL

36 36 Long Range Attacks AUTHOR: SUNNY AGGARWAL

37 37 Long Range Attacks How did you get enough stake here to do this? AUTHOR: SUNNY AGGARWAL #JustBribeEm

38 38 WEAK SUBJECTIVITY Solution: make unbonding period long + weak subjectivity. See How I Loved to Learn Weak Subjectivity. AUTHOR: ALEXANDRA TRAN

39 39 Nakamoto-Based Proof of Stake Peercoin (2012): First known implementation of hybrid proof of stake/proof of work currency. Uses coin age consumed by a transaction as proof of stake as well as centrally broadcasted checkpoints NXT (2014): Uses an account s effective balance, not coin age, as part of its block creation algorithm Slasher (2014): Vitalik s punitive PoS algorithm using security deposits and weak subjectivity to combat nothing at stake and long range attacks Bitshares (circa 2015): Delegated proof of stake Tezos (2014): Mix of Slasher, chain-of-activity, and proof-of-burn Ouroboros (2017): a provably secure proof-of-stake blockchain protocol ; chain-based and synchronous settings AUTHOR: ALEXANDRA TRAN

40 NAKAMOTO PoS CONSENSUS Environmentally Harmful Expensive Slow and Synchronous Relatively Centralized? No Finality AUTHOR: SUNNY AGGARWAL 4 0

41 41 BFT Consensus Algorithms Lot of work done in distributed consensus algorithms in 80s and 90s Paxos, PBFT, etc Maintained safety in asynchronous network, and liveness in partial synchrony Require 2/3 of voting power to agree on a block and then the block is finalized Were based on permissioned system and needed fixed validator set. Couldn t do in open setting. Until Tendermint came along PoS allows for dynamic validator sets that change with changes in stake AUTHOR: SUNNY AGGARWAL

42 42 BFT-Based Proof of Stake Tendermint: mostly asynchronous, BFT consensus protocol with voting power denominated in validator stake; two-stage voting process; favors safety (consistency). Used in heterogeneous blockchain network Cosmos. Casper: Ethereum s to-be-released Nakamoto/BFT hybrid proof of stake algorithm; favors liveness (availability); the friendly GHOST. AUTHOR: ALEXANDRA TRAN

43 43 3 BFT Algorithms

44 Practical Byzantine Fault Tolerance Quick Overview One third of the nodes can have byzantine faults Computationally efficient. Provides Liveness, and Safety given that less than one third of the nodes are faulty. This requires synchronicity. AUTHOR: Dev Ojha 44

45 Understanding the algorithm Design Elements AUTHOR: Dev Ojha 45

46 Understanding the algorithm Design Elements AUTHOR: Dev Ojha 46

47 Practical Byzantine Fault Tolerance A first look We know at the end that each node must communicate with the client. A first idea at modeling a PBFT system could reasonably be: Client talks to Primary node Primary node talks to every replica Every node computes the validity independently Every node communicates with the client 47

48 48 Practical Byzantine Fault Tolerance Issues with previous outline The primary node can t be trusted to communicate with every other node in the network If malicious it could try to exclude certain nodes from ever getting their state updated, to try to cause network disruption. (It only must communicate to 2f nodes) Outline: 1. Client talks to Primary node 2. Primary node talks to every replica 3. Every node computes the validity independently 4. Every node communicates the result to the client

49 49 Practical Byzantine Fault Tolerance Issues with outline The issue here is concurrency. All requests must be processed in the correct order across all replicas. Outline: 1. Client talks to Primary node 2. Primary node communicates with every other node 3. Every node alerts every other node. (Nodes also check that messages are all the same) 4. Every node computes the validity independently 5. Every node communicates the result to the client

50 50 Practical Byzantine Fault Tolerance Issues with outline The byzantine generals problem isn t solved for the ordering of requests. Different start indexes can be given from the primary node to the different nodes, or the nodes can tell each other different things. Outline: 1. Client talks to Primary node 2. Primary node communicates with every other node, with a provided order 3. Every node alerts every other node. Also provides the order they were given to be used for this request. 4. Every node computes the validity independently, once the node reaches the majority request index. 5. Every node communicates the result to the client

51 51 Practical Byzantine Fault Tolerance Solution 1. (Request) Client talks to Primary node 2. (Pre-Prepare) Primary node communicates with every other node, with a provided order. 3. (Prepare) Every node alerts every other node with the info they were given. This includes providing the order they were given to be used for this request. 4. (Commit) Once a node has gotten 2f prepares matching their own provided order, they alert every other node to their planned action and sequence number. 5. (Reply) Once a node has gotten 2f commits matching their own provided order, they process the request and respond to the client.

52 52 Practical Byzantine Fault Tolerance Solution

53 53 Paxos Key Points There are many different variants Does not provide Byzantine Fault Tolerance (Except Byzantine Paxos) Ensures Safety Ensures Liveness If f faults need to be handled, 2f + 1 nodes are required.

54 54 QUESTIONS?

55 55 4 Tendermin t

56 56 Tendermint BFT consensus mechanism, for arbitrary state machine replication

57 57 Tendermint BFT consensus mechanism, for arbitrary state machine replication Liveness without partition

58 58 Tendermint BFT consensus mechanism, for arbitrary state machine replication Liveness without partition Safety without ⅓ byzantine

59 59 Tendermint BFT consensus mechanism, for arbitrary state machine replication Liveness without partition Safety without ⅓ byzantine Consistent / Safe in the event of partition

60 60 Tendermint BFT consensus mechanism, for arbitrary state machine replication Liveness without partition Safety without ⅓ byzantine Consistent / Safe in the event of partition 1000s of TX/Second throughput

61 61 Tendermint BFT consensus mechanism, for arbitrary state machine replication Liveness without partition Safety without ⅓ byzantine Consistent / Safe in the event of partition 1000s of TX/Second throughput 1-2 second latency, with finality

62 62 In the event of a partition (or just high latency) Do we wait for the network to reconnect? Or do we keep going, and fix inconsistencies later? source

63 63 Bitcoin chooses Availability

64 64 Bitcoin chooses Availability Network partitions create temporary forks, some transactions will be invalidated

65 65 Bitcoin chooses Availability Network partitions create temporary forks, some transactions will be invalidated Latency creates divergences too orphan blocks

66 66 Bitcoin chooses Availability Network partitions create temporary forks, some transactions will be invalidated Latency creates divergences too orphan blocks Faster block times would make this problem much worse Larger blocks could too

67 67 Bitcoin chooses Availability Network partitions create temporary forks, some transactions will be invalidated Latency creates divergences too orphan blocks Faster block times would make this problem much worse Larger blocks could too By choosing consistency, tendermint can have very fast block times

68 68 source: tendermint documentation

69 69 source: cosmos whitepaper

70 70 Issues Nothing at stake

71 71 Issues Nothing at stake Solved by slashing validators who double sign

72 72 Issues Nothing at stake Solved by slashing validators who double sign Weak subjectivity / long range attack

73 73 Issues Nothing at stake Solved by slashing validators who double sign Weak subjectivity / long range attack Month long bonding period

74 74 Issues Nothing at stake Solved by slashing validators who double sign Weak subjectivity / long range attack Month long bonding period Limited decentralization (100 validators)

75 75 Issues Nothing at stake Solved by slashing validators who double sign Weak subjectivity / long range attack Month long bonding period Limited decentralization (100 validators) Expected to grow over time 13% per year in Cosmos

76 76 Issues Nothing at stake Solved by slashing validators who double sign Weak subjectivity / long range attack Month long bonding period Limited decentralization (100 validators) Expected to grow over time 13% per year in Cosmos Better than 10 mining pools source: blockchain.info

77 77 QUESTIONS?

78 78 Cosmos Network of Tendermint based blockchains

79 79 Cosmos Network of Tendermint based blockchains Interoperable with existing blockchains

80 80 Cosmos Network of Tendermint based blockchains Interoperable with existing blockchains Decentralized exchange

81 81 Cosmos Network of Tendermint based blockchains Interoperable with existing blockchains Decentralized exchange Sharding via zones sidechains which can have same or different validator sets

82 82

83 83 Ethermint Ethereum Virtual Machine

84 84 Ethermint Ethereum Virtual Machine With Tendermint consensus layer

85 85 Ethermint Ethereum Virtual Machine With Tendermint consensus layer Full support for ethereum smart contracts

86 86 Ethermint Ethereum Virtual Machine With Tendermint consensus layer Full support for ethereum smart contracts Launching with Hard Spoon of ethereum

87 87 QUESTIONS?

88 88 5 Casper

89 89 Motivation for Casper

90 90 Motivation for Casper

91 91 Motivation for Casper

92 92 Maintaining the Defender s Advantage

93 93 Maintaining the Defender s Advantage

94 94 Maintaining the Defender s Advantage

95 95 Maintaining the Defender s Advantage

96 96 One Sentence Philosophy

97 97 One Sentence Philosophy

98 98 QUESTIONS?

99 99 Casper as Three Algorithms

100 100 Casper as Three Algorithms

101 101 Casper as Three Algorithms

102 102 Casper as Three Algorithms

103 103 Casper as Three Algorithms

104 104 Casper as Three Algorithms

105 105 Proof of Stake Algorithm

106 106 Proof of Stake Algorithm

107 107 Proof of Stake Algorithm

108 108 Proof of Stake Algorithm

109 109 Proof of Stake Algorithm

110 110 Proof of Stake Algorithm

111 111 Economic Finality Algorithm

112 112 Economic Finality Algorithm

113 113 Economic Finality Algorithm

114 114 Economic Finality Algorithm

115 115 Light Client Algorithm

116 116 Light Client Algorithm

117 117 Light Client Algorithm

118 118 Light Client Algorithm

119 119 QUESTIONS?

120 120 Proof of Stake Process - Consensus by Bet

121 121 Proof of Stake Process - Consensus by Bet

122 122 Proof of Stake Process - Consensus by Bet

123 123 Proof of Stake Process - Consensus by Bet

124 124 Proof of Stake Process - Consensus by Bet

125 125 Proof of Stake Process - Consensus by Bet

126 126 Proof of Stake Process - Consensus by Bet

127 127 Proof of Stake Process - Consensus by Bet

128 128 QUESTIONS?

129 129 Dunkle Mechanism

130 130 Dunkle Mechanism

131 131 Dunkle Mechanism

132 132 Fork Choice as Value-at-Loss

133 133 Fork Choice as Value-at-Loss

134 134 Fork Choice as Value-at-Loss

135 135 Fork Choice as Value-at-Loss

136 136 QUESTIONS?

137 137 Slashing Conditions

138 138 Slashing Conditions

139 139 Slashing Conditions

140 140 Slashing Conditions

141 141 Accountable Safety and Plausible Liveness ⅓

142 142 Accountable Safety and Plausible Liveness ⅓

143 143 Accountable Safety and Plausible Liveness ⅓

144 144 Accountable Safety and Plausible Liveness ⅓

145 145 Example: Accountable Safety, No Plausible Liveness ⅔

146 146 Example: Accountable Safety, No Plausible Liveness ⅔

147 147 Example: Accountable Safety, No Plausible Liveness ⅔

148 148 Example: Accountable Safety, No Plausible Liveness ⅔ ⅔ ⅓ ⅓

149 149 Example: Accountable Safety, No Plausible Liveness ⅔

150 150 Example: Accountable Safety, No Plausible Liveness ⅔

151 151 Example: Accountable Safety, No Plausible Liveness ⅔ ⅙

152 152 Example 2: Plausible Liveness, No Accountable Safety ⅔

153 153 Example 2: Plausible Liveness, No Accountable Safety ⅔

154 154 Example 2: Plausible Liveness, No Accountable Safety ⅔

155 155 Example 2: Plausible Liveness, No Accountable Safety ⅔

156 156 Example 2: Plausible Liveness, No Accountable Safety ⅔

157 157 QUESTIONS?

158 158 Weak Subjectivity

159 159 Weak Subjectivity

160 160 Weak Subjectivity

161 161 Weak Subjectivity

162 162 Weak Subjectivity

163 163 Weak Subjectivity

164 164 Weak Subjectivity

165 165 Weak Subjectivity

166 166 QUESTIONS?

167 167 PoS Attacks

168 168 PoS Attacks

169 169 PoS Attacks ⅓

170 170 PoS Attacks ⅓

171 171 PoS Attacks ⅓

172 172 QUESTIONS?

173 173 Casper Wrap Up

174 174 Casper Wrap Up

175 175 Casper Wrap Up

176 176 Casper Wrap Up

177 177 Casper Wrap Up

178 178 QUESTIONS?

179 179 6 Federated Consensu s

180 180 COMPARISON OF CONSENSUS FEDERATED CONSENSUS SOURCE: STELLAR WHITEPAPER

181 181 BASIC FBA FEDERATED CONSENSUS The key difference between a Byzantine agreement system and a federated Byzantine agreement system (FBAS) is that in FBA each node chooses its own quorum slices. SOURCE: eb3e949

182 182 QUORUM SLICES FEDERATED CONSENSUS SOURCE: eb3e949

183 183 EXAMPLES FEDERATED CONSENSUS SOURCE: STELLAR WHITEPAPER

184 184 DEFINITIONS FEDERATED CONSENSUS Definition (safety): A set of nodes in an FBAS enjoy safety if no two of them ever externalize different values for the same slot. Definition (liveness): A node in an FBAS enjoys liveness if it can externalize new values without the participation of any failed (including ill-behaved) nodes SOURCE: STELLAR WHITEPAPER

185 185 SAFETY FEDERATED CONSENSUS SOURCE: STELLAR WHITEPAPER

186 186 SAFETY FEDERATED CONSENSUS SOURCE: STELLAR WHITEPAPER

187 187 LIVENESS FEDERATED CONSENSUS Liveness is only guaranteed for a node v if it has a quorum slice that is composed of all good nodes

188 188 LIVENESS FEDERATED CONSENSUS Liveness is not a binary option for the network. A quorum slice can have failed without the entire network failing

189 189 VOTING FEDERATED CONSENSUS SOURCE: on-worldwide-consensus-359e9eb3e

190 190 PROBLEMS FEDERATED CONSENSUS No longer One CPU = One Vote

191 191 PROBLEMS FEDERATED CONSENSUS SOURCE: STELLAR WHITEPAPER

192 192 PROBLEMS FEDERATED CONSENSUS Security is pushed to the user s end

193 193 CURRENT IMPLEMENTATION FEDERATED CONSENSUS

194 194 DIFFERENCES FEDERATED CONSENSUS Provides a validator set for you. Requires 100 SOURCE: STELLAR WHITEPAPER No validator set provided No minimum requirement

195 195 QUESTIONS?

196 196 Thank you! Today s reading document can be found here: tinyurl.com/alternativeconsensus Attendance form for Fundamentals DeCal students: tinyurl.com/alt-consensus Leave Feedback for the Lecture (Required for DeCal): tinyurl.com/altcon-feedback Want to discuss other opportunities Talk to Alex or Ashvin innovation@blockchain.berkeley.edu