 Hi, everyone. This is the talk for the paper, a rational protocol treatment of 51% attacks. This is joint work with Chris John, Professor Zika Zanai, and you can see the full version on e-print. If you read cryptocurrency news, especially news on proof-of-work cryptocurrencies, you will see the somewhat worrying trend of so-called 51% attacks. In these attacks, the attacker has somehow obtained a majority of power in a system, and they're able to steal tens of thousands of dollars, even millions of dollars from crypto exchanges. A lot of the time, the attacker does what's called double-spending. To see what double-spending is, let's give an example in our fictional cryptocurrency called SAC Coin and how it can be exchanged for a fiat currency like the US dollar. On the left, we have a potential cryptocurrency thief who has some 100 SAC coins. He asked an exchange, hey, can I exchange my 100 SAC coins for your $5,000? The exchange agrees. Now, the potential thief puts on the blockchain a transaction that gives his 100 SAC coins to the exchange. Seeing this, the exchange gives $5,000 to the potential thief. Now, at this point, if the trade were honest, then this is supposed to be over. But in the case of double-spending, our thief is able to obtain a majority of power in SAC coin, hence the name 51% attack, and he's able to secretly create a longer chain, the one in red here, which excludes the transaction that gave the exchange the 100 SAC coins. Now, since the red chain is longer, it means that even honest parties will turn to this chain instead and revert the shorter gray chain below, and that's the one with the transaction. So our thief in the end ends up with both the $5,000 and his 100 SAC coins back to be double-spent later. But this kind of attack is really not supposed to happen because of a very common property of blockchain called consistency. So what's consistency? Informally, consistency says that if an honest party removes the most recent blocks in his chain, which is given by the parameter, the cutoff parameter, then the rest of the blocks, the ones in gray here, are supposed to be immutable, and that means that they can't be reverted or changed in any way. So why has consistency been broken? Well, it turns out that consistency requires two main assumptions. The first one will not get into, but it's that there must be a bound on the total hashing power in the system, and this is so that blocks are not made too quickly and that parties can't have two diverging views on the blockchain itself. But the second one is the one we'll focus on in this work, and it's that there's an honest majority of power in the system, and this is exactly what's broken by a 51% attacker. And when consistency is broken, we say that there is a fork in the system. So now we've discussed the problem of 51% attacks. I will quickly go over an overview of our contributions. So first, we model these 51% attacks in a rational framework called RPD. Then we'll discuss and solve a problem with the previous work in RPD, which is what we call unbounded incentives. And thirdly, we'll discuss what makes a coin susceptible to these 51% attacks, and finally how we might protect these coins from these attacks. So let's start with the first point. Now we know that sometimes honest majority is broken, but this doesn't really answer the question why some blockchains might be more vulnerable to these attacks than other blockchains. The rational treatment gives a rather intuitive answer to this question, and it's that attackers don't usually attack blockchains for fun, they usually care about profit. And some factors that they might consider are, for example, the amount that they might want to double spend, the cost of attack or the block rewards. And several previous works have analyzed this 51% attacks in the rational setting under various adversarial models, but mostly in more economics or probabilistic analysis perspectives. So how does our work add to these previous works? Well, compared to previous works, our work analyzes this 51% attacks under a framework called RPD, which has two main advantages. First, there is no restriction on the adversarial action and what this means is that if we prove the optimality of some strategy or that our protocol is secure in some sense in this model, then this means that this is against all possible adversarial actions. And secondly, this framework is compatible with UC, which means that this analysis will hold in presence of other protocols. In the RPD framework, we start with a protocol designer, D, who has some blockchain protocol pie. Ideally, he wants to implement a consistent ledger functionality F, which is just a UC functionality with consistency embedded in it. Unfortunately, because of the lack of honest majority, he can only implement an inconsistent ledger functionality weak F that allows the blockchain to fork. The goal when working with RPD then is to show that although we can only implement the weak ledger functionality, when up against the rational attackers, we can actually achieve the consistent ledger. That is, if we assume that the attacker acts according to some class of utility functions, then we don't need the help of the weaker ledger to simulate them. And if this is the case, then we say that the protocol has attack payoff security. Of course, this is with respect to the utility function class. Now, in your crib of 2018, BGMT said, although they weren't explicitly analyzing these 51% attacks, they show the following for the Bitcoin backbone protocol. They show an even stronger property holds called strong attack payoff security. That is, they show that in fact, attackers are incentivized to just follow the protocol honestly. But wait, something doesn't seem right. Didn't we just say that a bunch of cryptocurrencies got attacked? So what's happening? Well, to see why this result doesn't seem to match up with reality, let's first take a look at the utility function they used. Here, I'm using this quickly equal sign because actually I'm omitting the fact that this utility depends on the simulator and the environment. But the important thing is that the first term here is just the expected total reward for making blocks. And the second term here is just the expected total cost of mining. So in fact, their utility function doesn't include the profit from double spending at all. Well, it's rather simple. Let's just add an additional term here where f payoff is the profit for forking like the reward for double spending. So now we have changed the utility function. Can we now prove something different? Well, surprisingly and rather unfortunately, no. In fact, we can prove almost the same thing. We can show that the blockchain is still strongly attacked pay off secure even with an arbitrarily large, but still a poly size f payoff. And the proof is even similar to that of BGMTZ18. And it goes as follows. Let A1 be any polynomial time adversarial strategy which makes a polynomial number of hashing queries Q. We see that A1's utility is at most f payoff which is polynomial by assumption plus the mining rewards from the Q queries which is also polynomial. We want to show that the passive strategy A2 can achieve better utility than A1. So he simply does so by mining a bit longer. He mined some Q star queries which turns out to be just polynomial in Q. And since Q is polynomial, this means that A2 itself is a poly time strategy. Well, this kind of proof strategy is very cute and it works, but there is a problem. Realistically, the passive strategy A2 can't just mine forever. And he thus can't always grow his utility to be greater than that of A1. And this is an example of what's called St. Petersburg paradox, which informally says that infinite rewards are not realistic. Now we lead to discussing our second contribution. We saw that the utility function from BGMTZ18 allowed a passive adversary to grow his utility in an unbounded manner. We call this property of utility functions unbounded incentives. In fact, we can show that any protocol is strongly attack payoff secure when the attacker's utility function has unbounded incentives. And this is not a good thing because this means that we don't really know whether a protocol is necessarily good or bad or just that the utility has this property of unbounded incentives. To avoid the problem of unbounded incentives, we introduce a condition on blockchain utility functions called limited horizons. We first generalize the block reward parameter B reward as a non-increasing function in the round number R. Then informally we say that a utility function has limited horizons if there is a round R, such that after this round, passive mining is not expected to be profitable. And it's easy to see that utility functions with limited horizons do avoid the problem of unbounded incentives. So what incentivizes 51% attacks that break consistency? Very roughly, we show that for utility functions with limited horizons, we can show the following. We can break both attack payoff security and strong attack payoff security if the lower bound on the utility of a forking adversary is greater than the upper bound utility of an optimal front running passive adversary. And this is clearly true because this is really just the opposite of the definition of attack payoff security. So what's left is to show what these two terms in this inequality are. To upper bound the utility of a passive mining adversary, we first observe that when the adversary is passive, then the probability of forking is negligible. So we can ignore this last term here. Secondly, we observe that this term, which is the expected block rewards is a bit hard to compute. And this is because the time the block enters the ledger, which is represented by this random variable IBR, is a bit hard to predict. But we can simplify computation by upper bounding this term by replacing the time blocks enter the ledger with the time blocks are broadcast. And this can be done because B reward is a non-increasing function by limited horizons. On the other hand, to lower bound the utility of a forking adversary, we consider this rather simple attack. In this attack, the adversary works to create a chain, the red one on top here, which he keeps private to himself. The honest parties who are unaware of this red chain keeps mining on the gray chain below. Since the adversary has a majority of hashing power, his red chain will grow faster than the chain that's known to the honest parties, the gray one below. And at some point, releasing this chain will cause a fork by reverting the supposedly immutable green block here. And how long this takes depends on the growth speed of this lower gray chain here, which is known by a property called chain growth. Then we can obtain the utility of this adversary, which is his expected profit from mining blocks during this time, plus the profit for forking, which he receives with overwhelming probability. Now that we have learned about profitable attacks, perhaps a more interesting question is on the other side of the coin, which is how can we protect a blockchain from these attacks? Remember that in the RPD framework, we have no restriction on adversarial strategy and again, no assumption on honest majority, only that the attackers are rational. And the question we're going to answer is the following, how much time do you actually have to wait for a block to be immutable under these restrictions? To do so, we borrow from the model of BGKRZ-20, which describes a 51% attacker by his budget B. We say that a adversary has some budget B if he makes a total of B mining queries over the majority of hashing power in the system. For example, very informally, let's say a total hashing power in the system per round is 100 and in a single round, the adversary makes some 51 queries. Then in this round, he has spent a budget of one, which is one over the majority of 100. Now, we give an overview of how we achieve our goal of finding a big enough confirmation time for blocks to be immutable in the blockchain. And the proof idea is as follows. First, we start with a limited horizons utility function UA. Then using the limited horizons property, we can upper bound the utility of an adversary that spends a total budget of B over some T rounds. Then we find the biggest B and T such that this upper bound utility U is positive. This means that it's even profitable to spend any budget and go over the majority. And finally, we use this maximal B and T to amplify the cutoff parameter of the blockchain so that consistency is always achieved against such rational attackers. Remember that the cutoff parameter is the number of recent blocks that are not yet immutable in the blockchain. And for this last step, we use the recent result from BGKRZ20. And finally, we show here a graph that plots the price of renting hashing power, the column on the left against the estimated length of attack, which is the biggest T such that either U of BT is greater than zero and it's the column on the right. For reference, the numbers used in this graph are from parameters in Ethereum classic from February of 2021, which is the time of writing. And just so that our utility function has limited horizons, I'm using T equals to three days as the maximal time and interval where passive mining is deemed always profitable. And actually in February, the price of renting hashing power is around 0.00045, which gives the length of attack of around two to three days. And this is around the order of the length of a recent attack on Ethereum classic in August of 2020, which is about two days. In case you were wondering what this weird dip is, this is the point where the price of renting makes passive mining go from being profitable to being unprofitable. And this makes sense since if passive mining were unprofitable, then you can't use the profit of passive mining to finance an attack, which leads to a much shorter attack. So in summary, we first showed why realistic utility functions must avoid the problem of unbounded incentives. Then we showed that the class of utility functions with limited horizons do avoid this problem of unbounded incentives and can be used to analyze both the case where attack payoff security is broken and when it's achieved. So what's next? Of course, implementations and analyzing other more complex utility functions can be very interesting, but perhaps of more theoretic interest, we can also extend our results by following some recent works that analyze variable difficulty blockchains and adapt our results to this variable difficulty setting. So that's it for the talk and here are some references for the papers referred to in this talk. Thanks for watching.