 I'm Phil Diane and I'm a PhD student at Cornell Tech and IC3 and I'm going to be talking about smart contract security incentives beyond the launch. So let's just get right into it. What is security? Recently I was lucky enough to attend this fascinating talk at the usenic security summit which is a gathering of professionals and academics by James Mickens from Harvard University. So I know the title is long, but if you Google James Mickens you can find this talk. And I'm actually going to steal all his philosophical insights from my talk. So sort of classically when we define security as a community we've looked at historically this Cartesian product between people, programs and computational resources. This was originally motivated by wanting to make statements like Piotr, who is on the other side of the Iron Curtain and it's bad, cannot use the log and demon to access the US government ARPANET. And this definition sort of naturally has been adopted by the blockchain space and extends to this space saying things like Piotr, who's the Dow hacker, cannot use re-entrancy to access my tokens or can't use overflow to access my tokens or self-destruct. So in the last two years we've gotten a lot right with regards to this notion of security. So two years ago it was sort of the eve of the Dow hack and it still wasn't even clear whether we would be able to build secure smart contracts at all. Since then we've seen sort of this blossoming of projects, many of whom are talking here including hydro projects, Securify, Mythril, new languages like Viper, the K-framework, say hi to the runtime verification booth and Manticore and many more and we've also seen a wide, wide variety of publications about smart contract security, smart contract formal verification and more. So unlike two years ago we have a range of tools, a robust audit community and a robust culture, a deep toolkit of formal methods, much better testing practices and higher standards. Now that's not to say we're perfect but we've been substantially successful at optimizing for this notion of Cartesian product security. So let's keep calm and give ourselves a pat on the back. All right, great. And that concludes the talk. Thank you guys very much. I'm just kidding because that would be ignoring the dumpster fire in the corner and that is the way ICO incentives are set up to create a security culture in this space. So up until now most community attention and audit attention has focused on tokens, ICOs and other form of launch once walk away contracts. So these are contracts that you stand up, they start running and then they're not upgradeable so you kind of take your hands off and let them run themselves. So this is great for some sort of business purposes but unfortunately it creates this sort of vicious cycle of incentives. So you launch your token, it goes to the moon, you pat yourself on the back if you're Dan Larimer maybe restart that whole process a few times. And what does that give you? So what it gives you is a lack of in-house security experience at many of these projects because you sort of don't need to engage in continual development and continual security processes. It gives a big desire for rubber stamp audits to sort of approve something for a strict production deadline, sign off on it and defer that risk sort of onto someone else and it gives zero incentive to set up the kind of security lifecycle processes we have in this space. So I'm going to go back to James Mickens who argued that for the broader security community as a whole we need a more holistic view of security and that really the high level goal of computer security when you break it down is to ensure that the systems we're building will do the right thing even in the presence of malicious inputs. Now you might say what is the right thing? Is the right thing that what these Cartesian things we've been talking about before and actually these are too simple in a world where technology sort of pervades and impacts every aspect of our lives. It's no longer sufficient to just ask can someone access a resource, can someone steal my tokens. We have to ask as a security community what guarantees do we want these systems to provide their users and we have to reason about broader and more nebulous moral questions. So for example should a particular action be possible from a moral perspective and if so how do we get socially beneficial outcomes out of our systems. So in a nutshell basically the role of security is to separate the good from the inscrutable. So a good system, it's a system that does what users expect. It leads to socially good outcomes and it fails in known and predictable ways that the user is aware of before they engage with the system. An inscrutable system are systems that often violate the expectations of their users. They lead to socially negative or socially morally bad outcomes and they fail in unpredictable and surprising and often catastrophic ways. So as a security community how do we separate these two kinds of systems? Well we sort of lean on this rich culture and this rich tradition and this rich history of extensive modeling, formal modeling and proofs, field data, philosophical reflections and reviews on the type of modeling and the type of data we're using and whether that's actually getting us the type of security we really want and experience from all of you guys, people in the industry, people who are actually building things and are on the ground every day talking to users and putting these systems into production. So you might say, Phil, I saw you use the poo emoji instead of inscrutable and I actually blame Twitter for everything in this talk so I ran two polls about this talk. If you hate the talk what you should probably do is follow me on Twitter after and vote in the next poll and maybe you'll like the next one more. And if you did vote in the poll then it's all your fault I guess. So this is the main thesis of my talk and this is sort of what we're going to be focusing on for the rest of the talk and that is the idea that we simply don't understand how to build principled, secure, smart contract systems at all yet. So it's a little bit of a dooming loom talk but it's not completely hopeless. We are sort of moving in the right direction and there is quite a chance that we will be able to eventually understand how to build these systems but right now we do not. So I'm going to say that again we simply don't understand how to build principled and secure smart contract systems yet. And I'm going to prove this in three lemmas. So the first one I'm going to show that many dexes are inscrutable. We do not understand how to build a secure dex for our users right now as a community from sort of a theoretically optimal and an academic standpoint as well as from a practical standpoint. I'm going to talk about why on-chain voting is also inscrutable. So we don't understand how to build a good on-chain voting system. This implies that building anything more complex especially when you're using one of these two pieces somewhere in your system is also going to lead to something that's inscrutable. And so these three lemmas together are going to prove that we just don't know how to build even the simplest mechanisms. And then I'm going to talk about why this is sort of threatening to Ethereum as a whole and the security of Ethereum as a whole as well as what we can do about it. So let me tell you a story. There's this fascinating book called Flash Boys which is sort of about this this band of traders on Wall Street who figured out that by sort of cutting down the latency people were using by a little bit and getting access to sort of very quick market inefficiencies that were momentary in a continuous market you could actually profit systematically and extract mechanical rent out of the market itself regardless of sort of how the market was moving or what users actually wanted to trade. So it's a fascinating book. And I'm going to tell you the story of Flash Boys 2.0 which is a very similar story to that but on the Ethereum network. So who are the Flash Boys 2.0? Well it's Yuen Xili and Xiuan Zhao who were primarily responsible for the initial work of coding and operating the trading bot that I'm going to be talking about as well as myself Lawrence Breidenbach, Ido Bentov, Ari Jules, Tyler Kel and Raphael Pass and these are all affiliated with Cornell or Cornell Tech. So Lawrence and Tyler are actually here at this conference I highly suggest you find them and talk to them about this work and they're also giving a talk tomorrow on one potential mitigating solution to this kind of problem. So this story starts on August 13th, 2017 when we published this blog post about the cost of decentralization in Xerox and EtherDelta. This was over a year ago and what we said in that blog post is that decentralized exchange leaves users vulnerable to minor front running. That means if a user comes and puts in an order on a decentralized exchange a minor can see that and can with guaranteed profit essentially insert their own transactions on either side of that order to sandwich that order. This is something that's frowned on in regular markets if you're doing activity like this either the market design will try to design to make sure you can't do that or you'll get banned from whatever broker you're trading through or whatever. But in on-chain systems this is very prevalent and not only that but it actually gets worse. So many of the systems we've built now have slow cancellation which means that because an order is sitting on the blockchain and you have to bring your cancellation to the blockchain by the time you go to cancel your order if the price has changed essentially that's a juicy order for miners to come take quickly before you're able to cancel it and you're just gonna waste the gas price of your cancellation. There's also an issue of high gas cost for competing transactions. So multiple transactions trying to take a juicy order that's on the blockchain essentially engage in this bidding war on gas to see who can get mined first by the miners and who can get that transaction. So Xerox followed this up later with a nice article about front running, griefing and the perils of virtual settlement on the blockchain where they sort of describe this process of minor front running and how miners insert their own transactions when assembling these blocks. Now you might say Phil you're in your ivory tower over there talking about this but we're building real systems. That's not actually the case so we practice what we preach. So we actually ran the numbers on this in the 24 hours on August 11th, 2017. And on that day you could have made approximately $4,500 or approximately $1.6 million front running Ether Delta alone. So remember this was before sort of the rise of many DEXs that came out shortly after this work as well as before many of the users started using these DEXs with better UIs so it's likely these numbers are actually much worse today. We also ran an arbitrage bot and observed our own success rate of actually taking these opportunities at 58.3% which applied approximately $2,500 a day in profit or 8.32 ETH a day in 2017. And of course the reactions we got looked something like this. Spoiler alert we didn't. And so quick warning the next few slides contain preliminary data. I'm a big believer of sort of doing science in the open and showing you guys what we have as soon as we have a form that we can show it to you in. So take this data with a grain of salt and sort of watch out on my Twitter for when I sort of tweet that this is finalized and you can really have confidence in this data. And we're also gonna be releasing it and open sourcing everything I talk about today for peer review within the next month or so. So quantifying the front running problem. So between around blocks 3.87 million and around blocks 6.6 million which was I think a week or two ago, we saw around 2,500,000 of these programmatic arbitrage bot transactions which is about 30% of all blocks on the network in that time containing such a transaction. We also saw 21 trillion total way bid in the network for the gas to pay for these transactions which paid for 989 billion gas or sorry bid 989 billion gas the transaction could potentially use less than it bid. And that's equivalent to about 120,000 full blocks of gas. So you can see this is already happening actively on the system today. Now let's sort of zoom in a little bit and look at the graphical data of what this market looks like. So that purple line over there is the date we published the post. You can see before that it was maybe us trading around and experimenting a little in one bot. And shortly after that a sort of this rapid professionalized economy rose up taking these arbitrage opportunities often competitively. So the way you should read this graph is the top line of the top graph is the way bid including failures. And what that means is we include transactions that didn't necessarily successfully arbitrage things and we're using a pretty loose heuristic which might accidentally identify transactions that are trading programmatically through DEXs for other reasons. So we're looking through that data manually and just validating it take this with a grain of salt right now but approximately this is what the shape of the market looks like. And the way you should read this is essentially we chunked up time into 10,000 block intervals and just looked at how much gas and way was being used in each of those 10,000 block intervals. So it's not actually a moving average sorry for that misleading label but if you see for example the bottom line 15 billion gas that means in those 10,000 blocks 15 billion total gas was sort of bid which means 1.5 million gas per block was demanded by these arbitrageers. The lower two lines show the successful arbitrage rates and these are transactions which actually managed to execute trades on a DEX programmatically through other smart contracts. And the bottom red line is the gas used and the top is the gas bid. So again the gas bid is the price you offer to pay and the gas used is the price you pay. So you can see this market has sort of been steadily increasing slowly in gas but decreasing in the amount of gas it's burning for two reasons. Number one the general gas market has cooled off a little bit since that sort of spike right after our blog post and another one users are actually making smaller and smaller trades on these DEXs as they hit the mainstream which means the average size of the opportunity is decreasing over time. So we went and actually measured this market in much more detail because we wanted to know how are these bots that are doing this actually competing? What does it take to be competitive in this market? So we deployed eight nodes with 256 peers each deeply paired with the Ethereum network. Geo distributed this across three different server providers in South and North America, Europe and Asia. We collected 215 million observations over a period of about a month and a half and what an observation is is essentially every time a peer sent us an arbitrage transaction we record the precise time we saw it synchronized to the microsecond as well as which peer related and things like that. And the goal was to eventually sort of geolocate these bots ask where in the world are the latency advantages strongest as well as understand their operation and the dynamics between them and collect precise timing data on these auctions. So what did we see when we did that? This is what a typical competition between two bots trying to take a profitable opportunity looks like. The graph is showing the bids over time. So on the right is time passing. You can see the auction ends about two and a half seconds after it starts. And the Y axis is sort of the gas price these bots are bidding for these opportunities. So you can see two things. Number one, the bids are happening very fast, many bids in two minutes. And also the green dot is the bot that eventually won and the red dot is the one that got mined and paid the fees but didn't get the opportunity. So how does this game work? Well at some point in time some random orange line will drop on this graph and that orange line is when the block template was formed by the pool mining the block. And when the pool that eventually is gonna mine the successful block forms that template and includes those transactions, the two transactions that at that point in time have paid the highest price will be included. So in that case it's those two, in this case it would be those two and the guy on the right would win and the guy on the left would lose. So this actually induces a latency war because whoever sort of had the last word in this back and forth is the most likely to win the market. And it actually gets even weirder than that. So here's an example of an auction in which the winner and the loser happened right at the start of the auction. And the bots kept bidding afterwards even though the winner and loser were already locked in. So why did this happen? This happened because sort of in the network there's this difference between when this orange line drops that sort of locks in the auction results and when this red line drops that actually finds the solution to the block on an ASIC and distributes it to the rest of the network. So by making the distance between these orange and red lines smaller the pool could have taken a later bid and potentially profited a lot more from this auction than it did. But instead the pool was a little bit inefficient. It took about seven seconds without refreshing its block and it lost out on a few fees as a result. So I'm gonna claim that the transparency in this mechanism is a lie because when you read the Ether Delta smart contract or the zero X smart contract it doesn't imply this game at all. But the real game people are playing on these networks from a game theoretic perspective is continuous time. It's imperfect information because you don't know when that orange line is gonna drop. It's all pay because even losing bots pay gas for attempted execution. It's probabilistic both in execution and duration and it's rate limited because you can only send out transactions so fast on the Ethereum network. So this gives these bots a wide range of sort of angles to optimize on to be more profitable at taking these opportunities. So our conclusion in the blog was to recommend a centralized order book and say essentially there's a fundamental trade-off between who can front run you. Either you have an exchange operator who can front run you if they do the routing and matching for your orders or you have some sort of peer-to-peer network or blockchain involved in your routing and your orders at which point someone in an advantageous position on that network could potentially have information asymmetry advantages that lead to mechanical rent. And we prove that this is sort of fundamental no matter what kind of global peer-to-peer marketplace you build. So just centralize it, maybe it will fix it. We don't know. All right, so the real competition here again is on latency, connectivity, et cetera just like traditional HFT, just like flash boys, et cetera. And the transparency is a lie because what we have on chain is actually not all the data. So of all the data I just showed you in the auctions only one or two of those transactions even makes it to the chain or even makes it to ether scan because most of them just get replaced so quickly that no one in the network sees them. So sort of under this surface mechanism that we're building that looks simple we have this iceberg of sort of bot strategies and interacting bots and weird liquidity pools backroom channels of influence and potential black swan events if these things behave poorly. So there's actually a lot of complexity that still remains out of line. It's not enough to just say, oh, we're making the trades more transparent and therefore we've, this is bringing our users more security. That is absolutely not necessarily the case. So now you might be saying to me, Phil, isn't that just an efficient market? Isn't that just how the world works? So let's talk about user experience in this brave new world of DEXs. So here's a user who says, would you have the heart to return 24 East to my address? I am a stay-at-home parent and day trade to keep my family above water. In your heart, you know this isn't right. Here's another one. I have faith in you, man, fate in you, man. Please send my money back. So these are users who went to cancel their order and were immediately front run by these bots who sort of detected a fat finger and essentially took all their money. And here's another one. Please, please, please, this was an accident. I did not mean to make this transaction. Please can we reverse this? Please be kind and karma will be kind for you too. I'm a single parent trying to make ends meet at a job I hate. Please have some mercy and Benjamin Huffman goes on to write again. It's all I have, please have some mercy. Or there's Alfie here who says, please, please, please return at least one ETH. I give you the rest willingly if God ever asked you. I really needed to continue my education. I might need to sell my car to pay. And last but not least, you have Rajesh Kumar here who says, sir, this was an error order. This is all of my village rupee I trade for them. If I do not receive back ETH, I will be in the inscrutability, sir, please. So you can see that this is something that's really impacting real users today, these issues that we pointed out in 2017 and that most of the projects in this space just went on to ignore and launch anyway. And there are hundreds of these comments on the ETH or scan comments of all these trading bots that we've sort of found. So I encourage you to go look for yourself after the talk. And of course, we have a few comments like this. LOL making people pay for their fat fingers. How do you do this? Tell me your secret sauce. So the conclusion is we don't understand existing DEX designs or sort of how these will behave in the eventual game theoretic equilibrium of these systems. And while we're sitting here in decadence at these conferences going to parties and enjoying popping the champagne, real users are losing money on the systems we've built and it's having real world impact on them. And unfortunately, a lot of the reaction in the space, a lot of the time kind of looks like this. So instead, let's learn from history. We can look at a wide variety of work on this kind of high frequency trading and market design. This is a recent paper I highly recommend by Buddhist, Cremden and Shim, which sort of says that these opportunities and mechanical rents are fundamental inside continuous markets. And it's not just healthy competition because it creates an arms race that induces mechanically a prisoner's dilemma and charges of liquidity tax on the system that's paid by all of its users. And this actually gets worse with the blockchain. So let's imagine we're a minor for a second. We have these transactions on DEX as we're getting fees F1, F2, F3. If we insert our own transactions here, suddenly we have fee F1, F2, F3, plus the profit from the first transaction plus the profit from the second transaction. Or maybe we can switch the order of transactions one and two and then we get P3 and P4 instead and that's actually more. So figuring out the optimal ordering and insertions here is actually an optimization problem that's provably undecidable with Turing complete transactions and NP hard without, which makes it a substantial vector for minor competition. Not only that, but in the long-term iterated game equilibrium, miners can out-compete non-mining arbitrage bots for these ordering opportunities and are incentivized to sort of minimize those orange and red differences we were talking about earlier in absurd levels to milliseconds or lower. If they don't do this, they just won't be competitive with miners who are and they'll be driven out of the system. So what you get is huge opportunities that lead to reorgs, orphaning, selfish mining, fee estimator errors. We've seen this already with systems like POWH3D and you get mining that's dominated by a small set of high-frequency trading firms using proprietary relay and optimization networks just like we have on Wall Street. But not only that, these guys will also be powerful players in governance. So you can't have a system that's full of intractable mechanisms that we don't understand that's still secure. All right, I'm gonna talk about another simple mechanism here, on-chain voting. So this is the one used in the Ethereum example documentation. And we have two posts about this as well on Hacking Distributed and also my personal website talking about how on-chain voting is open to trustless, frictionless bribery. It does not satisfy the classic properties and security literature of coercion resistance, receipt freedom, all these things people have been studying for over 30 years now for real elections. We also released a vote-buying mechanism for carbon vote that you can use to publicly buy people's votes on that platform. And we described a new construction called the Dark Dow which is sort of this trustless hidden cartel that operates in trusted hardware where I can buy your vote. You don't have to give me control of your funds or anything like that. I'm only buying your vote for a specific vote and you can tell how I'm gonna buy it. And nobody in the system can tell whose votes are bought, whose votes are sold, or how much money is even bought or sold at any given time. So this can undermine the legitimacy of the process even without having any money in it because cryptographically there's simply no way to know how far this attack has advanced. So I encourage you to check the details of that scheme in our post. The conclusion is that we don't actually understand voting. Dark Dows can also be used in other mechanisms in our space. So any sort of Nash equilibrium incentive model you set up you can modify using a Dark Dow by paying users to behave in a conditional way. And this motivates the bribing attacker model. It motivates cooperative game theory and it motivates using much stronger models than we've been using for security in the blockchain space. And actually you can use a Dark Dow even to attack consensus itself because proof of stake and proof of work are just a form of voting. So I can pay you to censor someone or do a 51% attack or whatnot. So the conclusion is that on-chain voting is inscrutable. So what about more complex mechanisms? This is a picture from a documentation a little bit old, a little bit outdated, but from a real project in the space. And this is a more up-to-date sort of version of that same picture. So as you can see, we're building incredibly complex interacting mechanisms with a multitude of components. And we're looking at it and saying, well, it works because it works, right? But if you zoom into something like this, you see that but one small piece of this sort of like mess of interactions is an admin multi-sig that's eventually gonna be replaced with something like on-chain voting. So again, here because this on-chain voting feeds back into every single aspect of the security of these systems and we simply don't even know how to build on-chain voting that's secure and incentive compatible, how can we possibly build something like this that's incentive compatible? We simply don't understand how to do that yet. So the conclusion is that any more complex mechanisms or any form of sort of substantial complexity is inscrutable. And a corollary there is that we should stop hyping these things up and stop selling them to regular users because we don't understand what they are, we don't understand how to build them. We understand that they work because they work so far but they're not necessarily more transparent and they're not necessarily better. So when you're selling this to normal people and saying there's no risk here, you're doing them a great to service. All right, so why did we get here? I'm gonna kick it back to James Mickens who has this sort of scathing critique of the technology industry in that talk that I suggest that you all watch. And we got here because often technologies assume that technology is value neutral. So that means that you deploy a technology and that automatically leads to good outcomes for everyone. So new kinds of technology should just be developed and deployed as quickly as possible without taking any time to reflect on a general idea of how the technology works or how it will develop or what the social impact of deploying these technologies in a widespread fashion will be. And this belief sort of comes with the idea that history is uninteresting because the past has nothing to teach us because we're reinventing everything anyway. So we might as well not look back at old academic work from 30 years ago or any of that because they don't understand us today. And this is a very, very flawed culture that cryptocurrency is inheriting while existing in decadence. So we're throwing our hands up and saying these mechanisms are more transparent so what we've built is sort of enough. But as we said before, even that is actually a lie. And we can't afford to become detached as a community from these security outcomes in this fashion because if we do, what's gonna happen is that we're poised to just reinvent the same systems that we're telling people we're going to escape and we're poised to reinforce the same power corridors that exist in the world today. At which point sort of all of this that we've done here has just been a way to fund some like Burning Man style parties. And so we're really just not learning enough from our mistakes in this process. But we have a chance to turn it around. So here's the happy part of the talk. Let's break out of technological determinism and let's be more skeptical. Let's learn from history, let's do our homework and let's listen to people who criticize our systems in principled and smart ways. And let's start today. So announcing an early preview of frontrun.me which is a little dashboard that we've built where you can view a small subset of the data we've talked about today. So you can see sort of a view of the day's auctions and see how these arbitrage are competing against each other. Sort of have some insight into their dynamics. You can drill down into individual auctions and sort of see data about them including the price they've bid, the bidder, what the gas limit is, how much gas they actually paid, et cetera. And you can also go to a sort of a strategy breakdown which graphs things like the bot's latency against themselves and against other players in the market as well as what strategies they're using in this auction in terms of raises and things like that. So this is super preliminary data. There are some known bugs in the software but I just wanna release it for you guys to sort of get an idea of the story we're gonna tell here. So what are we gonna do next? We're gonna integrate much more data into frontrun.me. So of that hundreds of gigabytes of data that we've talked about maybe only 1% is currently integrated into that dashboard. So we really only have the tip of the iceberg. We're also gonna do things like geolocation studies and more. We also have robust game theory that's currently sort of being formalized and finalized behind how these markets actually work and what users can actually expect from these systems validated by the data that we're experimentally collecting here on frontrun.me. And we're gonna do the same for blockchain voting over the next year. So we're gonna create attacks on existing protocols that we're actually going to implement and deploy. And we're also gonna build schemes that have rigorous and provable security and sort of outline the contours of when these schemes are appropriate to be deployed and when not. So let me say that as a community we have a chance here to set a positive example and get out of the poop emoji and into this world of sunshine and rainbows that we're all promising everyone will exist someday. All right, that's pretty much all I have. Thank you guys so much for coming and listening. If you're interested to know more you can visit my website at pdian.com. Follow me on Twitter at Phil Dian. There's also projectchicago.io. So Project Chicago aims to study resource markets in Ethereum and things like fee markets, et cetera. And actually this is a part of Project Chicago because you can't really understand fee markets at all without understanding these additional ordering fees that are introduced by smart contract systems like Ethereum and these arbitrage auctions that we've sort of talked about today. I'm also part of this cryptocurrency research initiative called IC3 at initc3.org. So a bunch of us are here, come say hi. And a company for formal verification called Runtime Verification. They are in my opinion the best at this Cartesian product security we talked about on the first few slides. And thank you to the Ethereum Community and Foundation for always supporting our independent research. Thank you to the NSF for supporting me and our whole lab through grants. And thank you to all our industry partners for amazing conversations, support, insight from events and more. And of course all this work has at least five or six co-authors on it. It wouldn't be possible without them and my sincere thanks go out to them. Unfortunately I don't think I have time to take questions but you can find me on Twitter or after the talk in the hallway and I'm happy to do that. Thanks guys.