 Good afternoon everyone. Let me start by thanking the organizers for including our paper on this program. It's really a pleasure to present in front of such a variety of individuals who approach blockchain with such different background backgrounds. And so we're really grateful to have this opportunity. This paper is joint work with my colleagues at Carnegie Mellon, Zara Ebrahimi and Brian Rutledge. Zara is a great graduate student of ours. We'll be on the market in the coming years. We hope you'll keep your eye out for her. Yeah, you know, it's also great to follow both ETI and Martin's talks, because I think we're all starting to think about similar related issues, which is what are kind of useful and important design features of blockchains to get economic incentives on a blockchain correct. And so that's what we're really trying to do in this paper. In this crowd, I don't think I need to, to dive too much into this, but we all understand blockchain as a technology that lets us obtain a decentralized or maintain a decentralized distributed ledger. And by ledger, we just mean an ordered list of transactions, right? So on a blockchain, transactions are batched together into a block, and then they're ordered by sequencing them or adding blocks to chaining blocks to previous blocks. It's a distributed ledger in the sense that we all maintain our own, or miners maintain our own copy of the ledger. And it's decentralized in the sense that no centralized authority controls which version of the ledger is correct, so to speak. Okay? Now, for this ledger to be useful, of course, we all need to somehow agree on which is the right version of the ledger. And we all ideally hope that transactions are immutable. So we know they are final as well. And blockchains obtain this by a consensus protocol, which mixes a sequence of design decisions to deliver that, right? So we can think about the process of determining which transactions are valid on the blockchain. We can think about the process by which users get to add blocks to the blockchain. And we can think about the decision of where we should add new blocks to the blockchain. And when we merge this consensus protocol, what we're trying to do is we're trying to develop a framework that lets us understand the economic incentives that arise from these design decisions in a consensus protocol. So our goal is to develop a new framework to study strategic agents' incentives to follow, so to speak, the protocol. And so let me be clear. We're going to think very carefully about a blockchain database as a graph. Okay? So each block here is obviously representing a block. I want you to think of the graph as growing to your right. Okay? So new blocks are being added to the right of the slide. Of course, every block is chained to a previous block. So all of the links point in the opposite direction to the left. Okay? And the key decision we're really trying to study in this model and think kind of beyond the literature on protocol so far is Miner's decision of where to add new data. So when a miner takes a pool of transactions, forms it into a block and appends it to the blockchain, we're going to think very seriously about their incentives of whether they should add a block to which of the existing blocks in the graph. Okay? Now, we know existing research based on, in fact, one of the work by people in the room, I see Catherine, Christoph, and Matthew. So we're grateful and we're trying to build on some of their research, which shows us that if any one miner has a lot of power or the value of Bitcoin say, if this is a Bitcoin blockchain they've spent already is quite large, they may have incentives to deviate from proof of work's proposed decision, which is they should add their blocks to the longest chain in the blockchain graph. They may want to deviate from that. In other words, under some conditions, mining the longest chain may not be an equilibrium. And people have used this to argue, therefore, and we saw in Martin's talk previously, that this implies strong conditions on when blockchains will work, when they will be final, when we will achieve consistency. And our question leading from that then is, well, are those restrictions on the technology or are those failures of a proposed equilibrium strategy follow the longest chain? And so when longest chain fails to be an equilibrium, we want to know what is an equilibrium? Are there equilibria that eliminate double spend incentives to still obtain consistency and finality? And so that's what we're trying to do. And to do that, we found we need, and I'll present to you a richer model of miners' actions, payoffs and strategies to try to study this question. And what I'm going to argue to you today is that, you know, our framework reveals kind of two key incentive problems that any consensus protocol has to resolve. Okay, and so I want you to picture my graph. I've grayed out what is a proposed consensus chain, which says everyone should end blocks here, should add their new blocks here at the end of the longest chain. Okay. And here what I'm going to say is there are two big incentive problems. So the first is some minor M may have some positive values, some transactions, if you will, think they have received a bunch of bitcoins in a block that is not currently on the consensus chain, this top four. And if the longest chain is the current consensus, this minor may want to take actions to try to switch the consensus protocol to the top four. This is not a double spend. We're calling this a coordination problem. Minor M may want to act in a way that convinces the other miners to switch to the top four, to accrue this value plus YM that is currently off the consensus chain. So one problem any protocol has to resolve is persuading miners to continue with the protocol, instead of trying to induce a switch that lets them get value that's not on the chain right now. And the other is the more classic double spend problem. So an agent may want to deviate if they have a negative transaction, we can imagine they have spent 10 bitcoins, it's currently on the consensus chain. And a double spend is simply an action where you try to switch the consensus to eliminate that negative transaction from the consensus chain. And so we're going to show you how you can resolve these different incentives. We're going to call that a new consensus protocol if you will. And we're going to show you that our equilibrium will be valid for arbitrary distributions of mining power. So we're going to relax these constraints that say if mining power is concentrated or if the value of spent bitcoins is sufficiently large, then you can't obtain a safe quote unquote blockchain. We're going to relax that. And we're going to have to make kind of, we're going to walk away from some canonical assumptions on blockchains on some margins and show you where you can get improvement in the consensus protocol. More broadly, what I want you to pay attention to, and I'll try to illustrate throughout the talk, is we don't think this just applies to proof of work or to Bitcoin. We're trying to build a framework that lets you think very generally about blockchains. So I'll try to show you how we can embed Ethereum where the data on our blockchain are not just transactions of spent bitcoins. They could be software embedded in the blockchain or the output of software that's been run on the blockchain. And we also think it's straightforward to extend our theory to think about other protocols like proof of state. And I'll show you that. Our goal is to develop one framework that lets you study the combination of decisions that go into a consensus protocol and determine equilibrium outcomes. So time is short, so I just want to dive in. We're thinking of a dynamic extensive form game where all of the players are quote unquote strategic or rational, if you will. So we're going to focus on the game among minors. We'll think of there being M of them. We're going to think very seriously about the blockchain ledger represented as a graph, really a tree. And again, the strategic choice we're thinking about in this framework is agents' decisions of where to add a new block of transactions. And again, most of my talk, I'll interpret this as Bitcoin. It's easiest in your mind to think of a transaction as Alice sends Bob one Bitcoin. But we can generalize this to other types of public blockchains. So again, we need a state to talk about a dynamic game. So our state is going to be the tree of data that the blockchain database represents. And again, the tree is growing to the right and every link is pointing back to the left, if you will. And just in terms of notation, I'm going to think of this graph of edges and nodes as GT. Each node here, I'll call a block. Those are the blocks you see in my graph. And I'll think of B as the set of blocks in our graph. Now, if I take any block in my graph, if this is my current graph, if I take a particular block B, then I can think of the chain of blocks from the Genesis block to B. This is the chain of the blocks to B in my graph. And again, any chain now denotes a ledger. So if I pick any block in our graph and I follow that block all the way back to the Genesis block, I get one version of our ledger. And of course, because I could choose any block at any given date, there are lots of versions of our ledger minors could choose. And so what minors are doing in this model at each period is their action. I'm going to call that A. That's minor M's action at date T is to just choose a given block in this graph. What they're effectively doing is choosing a ledger that they want to update. So they're going to have some new transactions that aren't in the graph today, and they are going to choose a block where they would like to add this new block to. If you will, you could think of minor M say choosing this block that I'm highlighting in green, and they're going to try to add this new block of data to this block right here. And then this is our representation of the proof of work lotteries. What we're going to assume is that if minor M were to choose this block that I've erode in green, then minor M's block is added with probability P M. So P M denotes minor M's mining power. We're treating that as exogenous in this model. And so if I have M minors and they all choose a given block, the tree will update by adding minor M's block with probability P M. So there are M possibilities depending on that. Is this structure clear? Every period the minors wake up they see the graph of existing blocks. They can add a new block potentially to any existing block in the graph and they get to choose a location which is just an element of the existing graph. That's their action in each period. So now I need to tell you what's in a block to try to work towards telling you what their payoffs are. Their payoff will depend on the data embedded in each block. So again in each period T minors will receive a new block of transactions and a block is just going to be a list. Again I want you to think about this as Bitcoin for today. It's just a list of credits and debits for each agent. So if I'm minor M, I get a list of credits for Alice, Bob, Charlie, Donna, etc. And those are the capital Y's in this vector here. So YMB is a net credit for agent M minor M that we are potentially adding to our account. And then we're going to add to that the mining reward, which I'm going to call little YMB, which for today we're just going to treat as a constant. So if minor M's block is selected Y, little YMB is just Y bar and it's zero otherwise for minor M. So we have these credits and these mining rewards. And here's where we could start thinking about this as much more richly than just Bitcoin. I could think of these capital Y's as the utility of minor gets from having some software embedded in a block. So if you want, this could be a reduced form representation for Ethereum where what YMB represents is how much I value having software encoded in this block. And then the little Y is my mining reward. So as long as we assume utilities quasi linear between how much I value software and mining rewards our whole theory will go through. Okay. So we wake up and we see this list of transactions we're going to try to append it somewhere given that we need to talk about how they value data. Okay. And so this is the last step before I can define payoffs. Again, here's a graph. If I focus on say minor one, we can imagine the graph has two net credits for minor one, Y1 prime on the top fork and Y1 on the central fork. And the question is do those deliver equal utility for minor one. So what I need to define formally is I need somehow a utility for minor one given the actions. This is a G given the actions of all the other minors today. So I have a graph. If all the other minors are taking an action I need a stage utility minor one gets. And so the way we're going to think about this is to say well if minor one has credits on a chain that others are mining that should be worth more to minor one then credits he has on chains other minors are not mining. So in particular if all of the other minors are choosing the screen circle block to mine. So if minors two through M are trying to add their block to the end of the longest chain then minor one should get more value from the transaction Y1 than from the transaction Y1 prime. You might think Y1 prime is worthless to him because it's today because it's off the consensus chain. And so that's what our payoffs are going to represent. We're going to build in a preference for consensus. Each minor will get more value from credits that exist on chains other minors are mining. But instead of doing it in this crude way we're going to do it in a slightly smoother way. So I again I just want you to take away from this talk what we assume is that the date to utility a minor gets is the value of all coins on the quote-unquote consensus chain. So what is the minor getting? This minor is first looking at every possible block in the graph and he's adding up all of his net credits from every block and then he's waiting them according to where all of the other minors are mining. So I get as minor M I get minor I's weight from this block if that block lies in the chain minor I is mining. So again it's just coins I care about the balances of coins I have in the graph and I care more about balances where other minors are mining. The last thing we add and this is actually important is an element to take care of negative transactions. So if I said my co-author who's on the call today if I send Brian 10 bitcoins I have a negative transaction that shows up permanently in the blockchain if that ends up on the consensus chain that's lying out there and the assumption is somewhere else say in the real world Brian has sent me something worth the value of 10 bitcoins say a Ferrari and so what happens here in my stage payoff is I will get that imagine YMB is minus 10 I will get this positive value lambda is an indicator function there's one date in time when the goods are delivered where I get a flow utility from a negative transaction and exactly how much flow utility I get might be adjusted that's delta it's a scalar reflecting the cost of delay so if I send Brian 10 bitcoins today and it takes a year for him to send me a Ferrari I might get a different amount of value than if it takes one day to get a Ferrari so that's just a scale. So let me dive in because I'm running short on time to what are equilibria here if you notice in this model so far and for the computer scientists in the room this might be troubling to see in our system. Right so all transactions are observed in real time every period and most one block is added. So when we study equilibrium we want to use an equilibrium concept that's robust to latency. What if our graph had a fork and then what do we choose to do even if along the equilibrium path people wouldn't have incentives to generate a fork. So we're thinking of latency as disciplining our equilibrium concept here and so we're going to study public perfect equilibrium. Even those not arrived at along the equilibrium path we want to make sure our strategy is an ash equilibrium on those sub games so that's going to be our equilibrium concept and I just want to show you the two key problems with longest chain but because I'm short on time I'm going to go through this quickly here's a graph we know what the longest chain is it's this one here if minor one has a large value off the equilibrium path he may try to add accruing this y1 on the consensus path he may try to do that mine quickly enough to switch the consensus two periods later to accrue y1 and indeed those incentives arise in this model so we're using these conditions that come out of existing research to discipline kind of our framework and make sure we nest those types of incentives similarly if I look at a double spend incentive in this case the consensus chain is this longest chain on top minor four has a spend transaction they might like to take an action that would eliminate that from the chain by mining rapidly along the bottom I should just put in the extra blocks when would they want to do that they would want to do that either if their spend minus y4 is really really large or if their mining power p4 is quite large okay the folk wisdom is that p4 can be small but the economic incentive say it can still be profitable even if I have low mining power if the value of my spent bitcoins is quite large so that's existing work under the conditions where longest chain would not be an equilibrium we can use our framework a richer framework now to ask well what is an equilibrium and so we're going to build an equilibrium with two key features and if you take away anything from this I want you to remember our equilibrium says one history dependence is important so the equilibrium strategy we build is non-marcovian that means there are different histories that give rise to the same state that would induce different actions by our players and then there's a waiting matrix that depends on miners mining power so we encode this history dependence with what we're going to call a checkpoint others if you read some white papers in the world about consensus protocols you'll see the words checkpoints show up for us it's just a summary statistic of the history of the graph at every date and we're going to use these checkpoints to determine the settlement lag meaning if I send my co-author Brian 10 bitcoins he should not send me the Ferrari until my transaction shows up behind the checkpoint so there's a history dependence state when settlement should happen I'm going to argue to you checkpoints are critical for resolving double spends and second we have these approval weights which are a coordinating device and so what's the approval weight we're going to add a miners block weight PM if minor M has some positive coin balance along the chain and we won't otherwise and so we're going to build checkpoints and approval weights iteratively I think an example is more illustrative to show their role I'm claiming here I can build an equilibrium let me just try to show that to you briefly before I wrap up here's that same graph we've been looking at in this case imagine the only net credits are those that I'm showing you so in the first two blocks here only minor two has a net credit in these blocks only minor three has a net credit and then here minor one has one if I look at the chain on the top fork minors one and two have net credit so I add their approval weight P one and two when I look on the central chain two and three have credits so I add up their approval weights when I look at the bottom I have minor one I get minor ones approval weight so if I assume one two and three are ordered in this way then the highest approval weighted chain is this top fork P one plus P two now we know I just told you minor three may have incentives to deviate to try to switch the equilibrium consensus in the future minor three says I'd love to switch the consensus down to this longest chain but anything minor three does by himself any blocks minor three adds does not change the approval weight of that central chain so what the approval weights are doing is they're saying minor three already wanted to go there his actions today can't update consensus in the future so even if minor three successful no one's behavior will change and people will keep mining this top fork and in that way the approval weights resolve these incentives to try to switch consensus to put values you don't have on the consensus chain on the consensus chain so that's our first resolution of the problem how do we resolve double spending this is where checkpoints play an important role so the assumption here is that I have a block and I have a graph and so minor four let's assume as we said before has a negative transaction that negative transactions on the blockchain that may be the consensus chain today before the spend settles minor four has zero incentives to deviate if I send Brian 10 bitcoins and he hasn't sent me the Ferrari unwinding that transaction before I get the Ferrari has no value for me so before it settled I have no reason to deviate to try to eliminate data from the from the consensus chain but you can imagine a new block gets added and the checkpoint updates we describe in the paper how that works so here's my new checkpoint and now Brian sends me the Ferrari and now I have very strong incentives to try to deviate because I have the Ferrari I'd love to get the bitcoins back so where could I go well I could try to mine this lower block along this ledger my negative transaction if I minor four does not appear so if I try to mine this lower block I get to eliminate that spend but if the assumption is people only mine blocks following the checkpoint then I could never switch consensus anymore so because we have this history dependence now that I mine this block no one will follow it's behind the new checkpoint I can't change it and so what we're arguing here is that these checkpoints this history dependence in the mining strategies creates a link between online meaning on the blockchain incentives and offline meaning trading in real goods incentives and so that's the main result in the paper I'll describe it this way we make a technical assumption on the distribution of transactions why and under that assumption we prove there exists an equilibrium in the game among minors that has no coordination problems and no double spending for any distribution of mining power P what is this technical assumption we're going to assume that if I fix a history length N then in any history where checkpoint has not updated for N periods there's no transaction data all the wise are zero now I can do this for any finite N so I can let N go off to infinity in that sense this conditions quite as weak as I want it to be and what are the kind of implications of this kind of the strategy is very complicated but we show when the checkpoint fails and you get forks we allow for temporary lack of consensus that gets resolved in finite time we have argued the settlement lag built in here exchanging goods for bitcoins is essential for eliminating double spends this gives us a very different conclusion about what currency blockchains may be useful for perhaps they're useful for large value transactions where we're willing to tolerate large settlement lags that's different from existing literature which says they may be small value transactions that eliminate the usefulness of double spends given longest chain but more broadly we think there's a nice link here between the latency and optimal settlement lag and I'll conclude on this point which is if you propose a strategy where miners actions are history dependent if there's real latency in the underlying technology people will observe different histories and they might start deviating and that could generate a lack of consensus just because of the technology what we're arguing is that the history dependence has to be lagged far enough back in the history where users can agree so if I tolerate there's a maximum latency in our network of an hour then you want to make sure the checkpoint is conditioned to be at least an hour or more you wouldn't want the checkpoint sooner where you'd send people off on their ways so in additional work we're doing now and in the future we're really thinking about how do we link latency and the potential lack of consensus to our history dependent strategies which resolve double spends in coordination and so I spoke really quickly to try to get this in in 25 minutes let me stop there and try to take a few times for questions thanks everyone