Challenges in Public Economic Consensus

Transcript

[Music] Hi everyone. It's a real honor to be here and a real honor to have that introduction from Vitalic. Thanks V. Um so this first talk actually is going to be um on there we go. Um on the problem space rather than the solution space the uh so I'm not going to talk about Casper directly. I'm just going to talk about you know what is this problem that I'm trying to solve uh with blockchains and with these consensus protocols and then in and after lunch I'm going to give a

talk on Casper. So um firstly let's start off with a little bit of background. So what's a consensus protocol? just I'm going not gonna be too formal just like pragmatically uh consensus protocol is something that computers use to agree on the state of some application and basically the important thing is that consistent protocols are useful for making really reliable systems out of unreliable or even untrusted components. Uh and so some nodes go offline and some nodes behave badly clients can still access the application. Uh here's like a nice the here's the only drawing in my talk. Uh and this kind of shows you this this idea that like there's like some nodes

who keep the some state that is a result of like applying some changes which are kept in like some log and then there are clients who kind of are able to interface with this state. Uh and if one of these nodes were to go offline or behave badly uh the clients wouldn't be disrupted. So usually uh in traditional extensive protocols we have like a network administrator and we try to guarantee that uh the application is available in consistent so long as not so many nodes go offline um or as long as the network isn't partitioned. So let's go through these little this concepts. Consistency means that traditionally means that every node has the same like an identical copy of the state and

availability means that clients are actually able to interface with it and cause changes to it. And then there's this famous result, one of the most important results in consensus literature is called the cap theorem, which is that uh if there's a partition, then a consensus protocol has to choose between being available or being consistent. And you can kind of imagine why that is because if there's a partition uh a client and a client is able to affect changes. Then different clients could affect changes on either side of the partition and we would lose consistency because the application state would be different on either side of the partition. or we could not allow them to make changes and remain and have the same uh application state on either side of the partition. Uh and then the other concept that brought up was like this idea of

faults. We usually like breakdown faults into kind of crash faults and Byzantine faults. Crash faults are when nodes go offline and they may come back or they may not ever. So crash fail basically means that they don't come back online. Crash recover faults eventually they they'll they'll reync. Uh, and Byzantine faults are kind of just a node that isn't offline, but it behaves badly. Generally, we we Byzantine faults are kind of defined to be behave in an arbitrary way, which can mean basically which you can think of as like they're running the wrong code, i.e. the one that the network administrator didn't tell them to run. uh or that they somehow can be observed to behave wrong behaving correctly due to like you know perhaps uh not because of the code they're

running but because of other other other things. Um so basically usually when we talk about like the security of consensus protocols in traditional consensus literature we think about you know how can we keep this protocol guarantee given some number of faulty nodes and we basically say that it's secure up to some given number of faults um and like consistency or availability are some examples of uh properties that we want access protocol to have. And I'm also going to mention censorship resistance um because that's you know especially relevant in our in our context. And one more thing before we go on to public consensus is this idea of uh eventual consistency which is kind of a weakening of the idea of consistency where instead

of requiring that every node has exactly the same copy of the state you require that eventually with very high probability they do have exactly the uh the same the same state. So Bitcoin is eventually consistent in that you don't really have a strong guarantee that everyone has the same copy of the state. now but you have a really strong guarantee that they have the same state you know four five six blocks ago. So public consensus is basically consensus protocol without network administrators where basically anyone can go and become one of those nodes who is part of the consensus process and who uh can handle client requests and cause changes to the consensus state and basically because there's no network administrator membership has to be

governed by something actually inside the consensus itself. uh basically we call it a mechanism kind of hearkening to like game theory. It's like basically like a game whose rules define whether or not is able to participate in affecting the state of the consensus. So there's like a really big problem to this kind of mechanism which is basically that uh an adversary could could try to game this mechanism to overwhelm the network and to have all or very large majority of the nodes in the network. Uh and that's like the first challenge to public consensus. Um, basically how do you prevent without being without there being a network administrator an adversary from bringing a whole lot of nodes online? And this is um kind of the real

the real important innovation of Bitcoin is that it figured out that you can have an economic mechanism in the consensus which made it uh expensive for civil to bring on a lot of nodes and to behave badly. So basically um economic assistance protocols try to make it prohibitively expensive for civil to conduct their their attack. Uh and currently economic consensus is the only known solution to public consensus problems. It's the only way that we know to defend against civil attacks without having a concept of trusted network administrators.

So it's in bold because it's important. So just to take bitcoins as an example, um what we what Bitcoin does is it makes it computationally expensive to produce changes to the network. And so uh for civil to propose a change, they have to incur this expense. And for civil to take a a majority of the network, they have to incur a majority of the expense. And so this is like the simple way that Bitcoin uses economics in order to make civil attacks difficult and inconvenient. And incidentally, this is why blockchains are trusted because it's expensive and inconvenient to abuse the trust that the blockchain has provided.

So economic consensus uh basically has like it has to have certain properties and we're going to so I'm going to start to give you an idea of how we reason about these things. Um so nodes have expenses and revenues. Nodes can't operate at a loss forever. Nodes can change their software for profit. uh an adversary can can has has to be defined not just as like a number of nodes but someone who has a a certain attack budget. Uh and nodes nodes can have the profit their profitability affected by an attacker.

Um so we kind of need to use economic analysis um rather than fault tolerance analysis to analyze public consensus protocols. It's bold because it's important. I'll say this again and again. Um so because nodes have expenses and they can't operate a loss forever um it's not sufficient to just say whether a node is correct or not because an even a correct node can't stay around forever if it's operating at a loss. So the the idea of using fault tolerance analysis where an adversary controls some of the nodes and all the rest of the nodes are correct doesn't work because you need to pay attention to whether or not those other nodes are operating at a loss or not because if they're operating a loss then that pool of nodes will shrink.

So we need to use economic analysis rather than fault tolerance analysis to to analyze these networks. So we kind of to do economic analysis the kind of nice tractable way to do it is to use kind of game theory uh and economics as like you know the school of thought that involves like rational action which which is to say that uh nodes will change the behavior just to increase their profitability. Now the the true state of the reality is that nodes that behave in a way that is more rational will end up having higher returns and nodes behave in a way that's less rational end up having bigger losses and so over time the profitable the rational nodes will dominate. But we can reason about it by thinking about

nodes changing their strategies to increase their profitability. Um and basically so they'll they'll they'll respond to all the incentives they have including the ones defined in the protocol and the ones uh due to an adversaries the expenditure of an adversar's budget. Um so it's not and it's also not sufficient to regard rational nos as Byzantine because we can say a lot more than just that they're behaving badly. We can say in a very particular they're behaving badly in a very particular way. So in the worst case in the worst case case economic economic analysis all or maybe almost all knows are rational uh and coordination costs are zero which is

to say that um you know an adversary doesn't have to deal with a complicated process to contact nodes and to bribe them. Um they can uh they can and and nodes don't need to incur cost in order to act together to increase their profitability. they could all just upgrade upgrade to the software and access the coalition. So in the in the worst case economic analysis, attackers can easily bribe nodes and and nodes will form profit maximizing coalitions. So it's bold because it's important. This is this this is the the context that we have to reason in when we're reasoning about uh consensus protocols in a public setting. um at least if we want to do a worst case

analysis, which I'm going to argue is what we should do because if we make something that's better in the worst case, it's going to be better in the the better case. Um and some here are some additional kind of worst case assumptions that we also make sometimes. They're maybe a little less important. Um marginal return is equal to marginal cost on a global basis. Um and nodes have access to basically like derivative markets so that you can't assume that oh they won't attack the network because it'll make the price of the node go down. U that's kind of like a rosy assumption right they could they could they could have just have they could just hedge their exposure to that to those price fluctuations. Um so basically uh those two things together mean that uh in those two things being

that nodes of form coalitions and attackers can bribe nodes mean that in order to have security we needed to make it unprofitable for majority coalitions to undermine protocol guarantees because then uh because they're unprofitable when they undermine the guarantee. an attacker would have to spend a large budget in order to cause them to do that without you know incurring a loss for an extended period of time. So we need to make it unprofitable for majority coalitions to revert transactions to prevent consensus from occurring or to censor transactions. It's bold because it's important.

So the fundamental challenge then then in public consensus is again to protect protocol guarantees against supermajority coalitions even in the context of bribe attacks which means we need to make sure that if if a majority coalition gets together and tries to undermine the protocol then they will do so at their own expense and they will need to therefore an adversary would need to allocate and spend a large budget. So in Bitcoin um like most public consensus protocols out there today uh it's rational for majority any majority coalition to censor transactions. They get an immediate raise. So no an adversary who actually doesn't need to spend any money to convince them to do this in in a rational model because they

they just get a raise in protocol. Um you know after the difficulty readjusts if twothirds of the Bitcoin miners censor one/ird they get a 50% increase in their block rewards. um you know a 50% increase in returns for a minor is a is a huge deal. Um you know there's like selfish mining strategy. to give another example of uh how like a bitcoin node can be Byzantine uh at and at their at their at their profit right it's rational no miners will engage in selfish mining at least if they have sufficient uh mining power for it to be effective um and and another thing um because marginal cost is equal to marginal return in um kind of this worst

case analysis uh you could bribe some miners in in order to increase the marginal cost of all other miners and the only the miners that you're bribing will be able to stay online because the other ones will be operating at a loss unless they're also being being bribed by someone else. Um but so these are like examples of u this kind of analysis this worst case analysis applied to to Bitcoin. Uh traditional proof of stake has very sim very similar problems. Um but in addition they have this nothing at stake problem where uh is uh an irrational node will move their keys will move their coins to a new address and then sell their keys of that held their coins at their old address to an adversary who's willing to pay a small

amount of money because that old address doesn't hold any coins anymore and so it means nothing to them. And so if all or most know are rational you could an adversary could like and they could all coordinate with at low cost. they could all at the same time move their coins to new addresses and then sell all of their old keys to an attacker for like no money and then the attacker would control basically the blockchain. Um and so this is kind of combination of the long range attack and the nothing at stake attack which um going to talk about more in my Casper talk. And then also we have this property that uh majority coalition has an incentive to uh censor a minority because they just get a raise right away in terms of block rewards and transaction fees. And we have a same property for double spends

um where like you know majority can get together and conduct double spends and actually they just gain from that. Um so rather than making defending against majority coalitions these consensus protocols uh have the property that it is rational for a majority coalition to undermine their their properties. So basically these protocols are not secure under pure economic analysis with these kind of worst case assumptions. And my whole philosophy with Casper as you'll see later is to try to have as best of an out outlook under this kind of uh rational rational model or under this under economic analysis. So there kind of two main

criticisms that people levy on me when I tell them this. Um it's not realistic. Uh this is basically people who who have some consensus protocol they like in the cryptocurrency space and they think that you know under their assumptions and under the realistic assumptions their thing is secure because you know it's not going to be the case that all of these my all the stakers in proof stake like in like you know pure coin or something will move their coins to a new address in order to sell all their old coins to an attacker. Uh and there's like coordination costs. There's all sorts of reasons why this might not be realistic, but um and but and and then the other the other the other criticisms that are often here is um it's just impossible to be secure in this context. Uh and that's and that's

something that I hear especially from people who have a lot of familiarity with traditional consensus research uh because they have like fault tolerance results that say oh more than this number of nodes behave badly then we lose our guarantees. Uh whereas here we're assuming that actually most nodes will behave badly if they just have an incentive to um you've given me these these criticisms before. You know who you are. So in response to the it's not realistic criticism. Um basically there's a couple of things. One of them is this teaches us about kind of you know edge cases of like you know the economic assumptions that we could be making. Uh and that and that is really informative. Um so even if it's

not realistic it it teaches us about the protocols that we're analyzing. Um and I think it kind of is realistic in the long run for basically a a couple reasons. One of them is uh you know there there might be a wellunded adversary who tries to attack one of these systems. I mean uh the it's kind of a fundamental problem to an extent that because we're relying on economics someone with enough money can come in and uh have a large effect on the system. And so if we if we can be secure against highly resource attackers then uh if there will be highly resourced attackers then this model becomes more realistic. Um, and the other thing is that like coordination costs are kind of falling over time both because people

kind of get established in industry and figure out who each other are and have conversations and because we're actually working on technology that reduces coordination costs. So I think you know you know even though it might not be realistic today where like Bitcoin miners wouldn't dream of colluding to attack Bitcoin um because you know they think Bitcoin is a good thing. is something that they want. Uh in the long run, uh I would say that it's it's this kind of situation where everyone is just governed by their ability to make profit is is becomes um becomes kind of more more reasonable. Um and basically I also think that if we make our analys our protocols better under worst case analysis, they'll be better in general.

And so that's another reason why, you know, even though it might not be realistic, this is how we should do analysis. Um and then basically it's impossible to be secure in this context. They say uh partly um partly they say this because they have results in Byzantine fault tolerance literature and um but but a Byzantine fault is very different from an economic fault, right? Um a Byzantine node is just like a node that will do anything. An economic node will only do anything at a price. And it's important to say what that price is. um rational nodes kind of only behave incorrectly if it's in their incentive to. They'll behave badly if it's bad well if it's in their incentive to um and

basically you know it's impossible to be secure in this context. I agree if the adversary has an unbounded budget but for any particular budget you can say whether or not um we are secure in that context. So this analysis lets you think about, you know, an adversary that has like $100,000 or $10 million or billion dollars and and and we can't just say that, oh, because all of the nodes will just behave badly if they're incentivized to um that they that that we won't be secure because they're Byzantine. It kind of really depends on what their incentives are.

Uh so you know and another reason is that I like another response I have to this criticism is that you know you don't know this right you just think this this is like an intuition you have but this is all very new and we haven't had much time to explore this space it might be that you're just wrong and that we can we can be secure in this in this So public consensus protocols face very different challenges than traditional consensus protocols or than non-public protocols. Uh they're they're kind of hard to reason about because we can't just assume that a certain portion of nodes behave badly. We have to use economics and game theory and this kind of reasoning about um the environment in which nodes operate as an as an economic

agent um or as an economic entity with with expenses and revenues. And there's no way at all to re to weasle economic analysis into Byzantine analysis or into around it by saying oh we do Byzantine fall tolerance analysis then we say and then we prove that it's incentive compatible you know there they're separate things and there's there's no way to put the economic analysis thing into the Byzantine analysis box. Um this and when you when you when you kind of when you start to doubt that just remember notes of expenses, notes of revenues. A correct node doesn't have an infinite budget. If it's operating at a loss, it'll go offline. Uh and and therefore you can't just rely on this

business So my my basically takeaways for you if you are designing or reasoning about these sensor protocols is think about it in the worst case. assume that there's a super majority of validators who will maximize their profit working in concert um and assume that uh an adversary can affect their incentives rather than assuming that the adversary just controls some fixed proportion of their nodes. So that's the end of my talk. Hope you enjoyed it.