 So like we said, we're going to talk about why all your smart contracts are vulnerable to bribery and what to do about it And this is joint work with a number of excellent co-authors like all good research. Remember no research is ever in Ireland So let's start by talking about why we're all here and actually one of the interesting reasons We're all here is because of a Polish economist from the 1970s named John Harsiani Who laid the the groundwork for this field of study? We call mechanism design What is mechanism design? It's a field of economics and game theory that takes an engineering based approach to trying to get users to behave a certain way using economic incentives Assuming the players in this game will act rationally and in their own self-interest so the field started in the 60s and 70s and Consists of several basic components one of them is a mechanism Which is a game that has rules a game environment and that players send messages to That game has an outcome and that outcome has what's called a social choice function or social utility function That says how good that outcome is for all the players in the game and therefore for society at large So what you want to do is implement some mechanism that implements some social choice function You find desirable and the hope is that because people act rationally they'll sort of converge on the social choice function You've chosen so what's an example of this well before dev con I actually found myself pretty hungry and I wanted some toast But I actually couldn't decide whether I wanted regular toast or toast with an image of Jesus on it Like you may have seen being popular on various auction sites Obviously, I went with the Jesus toast because who wouldn't and so I headed over to eBay and found some auctions on this sort of toast And you can see here this one has a few days left in the auction and it's currently bidding at 1 cent So I was like this is great I put in my bid for 2 cents and I'm gonna win this Jesus toast and sort of fill my hunger But then sort of at the last second someone comes in and puts a bid for over $9,000 because they really wanted that piece of toast and I'm sort of left hungry and not knowing what's going on So this sort of highlights a general problem with auctions, which is that in auctions? You need to play strategically you need to consider how other people are going to act when you choose how you're going to act yourself And the games you sort of play with them like people play on eBay become very complex So one of the early things the field of mechanism design has looked at traditionally is can we improve things like auctions? And in terms of the social choice function what our high-level goals are for that function for the seller Their goal is to maximize their profit from selling the item of course and for the buyers They don't want to overpay over what they think the item is worth or the minimum. They could be paying They don't want to have to think about complex strategies like when should I place my bid? Do I have to wait until the last second what are other people going to do in this auction? And how can I get this item more cheaply and the buyers also want to win the item if they value it more than any other buyer in the system? We also assume the existence of some auctioneer who's this sort of trustworthy third party that runs the mechanism Which is sort of a classic assumption in mechanism design that you have this third party that everyone who trusts That's actually running this game that we talked about So can we improve the eBay auction one of the proposals from sort of mechanism designers? Classically was what's called a VCG auction or Vickrey Clarks Grove's auction And the way this works is that all the buyers send a bid in a sealed envelope to the auctioneer And at the end of the auction the auctioneer opens it and the winner of the item is the highest bidder But he pays the second highest price for the item This model is used very commonly in things like ad sales And you can actually mathematically prove that given a bunch of private valuations on the buyer The best strategy for any buyer in this game is to bid what the item is really worth for them If they over bid in many cases, they will lose money over bidding their real valuation and similarly if they under bid They'll lose money. So that's great, right? That's what's called a dominant strategy truthful mechanism in the classic field of mechanism design Meaning that a buyer's dominance or best strategy is always to tell the truth and Traditionally, we've wanted to build mechanisms that are DST because they minimize cognitive load and overhead for sort of the players in your system and just make things simpler to think about and reason about and Cryptocurrency has sort of continued this broad tradition of mechanism design again by some party or principle using incentives to drive outcomes So this is an example from the Bitcoin white paper of Satoshi Nakamoto who talks about how the incentives in Bitcoin may help nodes to behave honestly in the system And smart contracts have similar overlaps and continuations of this field of study that's been going on since the 70s For example, there's this idea that you can take any mechanism that we've been studying for decades and just make it a Smart contract get rid of your trust at third party get rid of your auctioneer put it on chain And then we don't have to choose who to trust to play that role. We can just sort of converge on this code instead Otherwise if you want to build something that no one's ever built before you can use these same techniques that people have been using for decades To sort of analyze your mechanism and give users the properties they want Unfortunately, there's some challenges in doing this that make smart contracts very different from traditional mechanisms So again in traditional mechanisms, you have this trust at third party Whereas in blockchains you're replacing it with the blockchain which has its own sort of set of gotchas Including things like how the peer-to-peer network works or how miners choose transactions or sensor transactions Also in traditional mechanisms, you often assume a permission set of players a known fixed set of players when you analyze your games For example eBay knows all of the accounts that are eligible to participate in a given Auction and they have permission control over this set. So does Google when they're auctioning off ads And because of that you can do things like leveraging identity And there is some trust involved there unlike in smart contracts and cryptographic systems Where all you might see is someone's private key and signatures and you might not be able to leverage the shared trust so smart contract mechanism design poses new challenges and Chief among these challenges and what we're going to talk about today is the ease of coordinating bribery So last year I wrote a blog post called the dark down Which if you haven't read I highly encourage you to check out and it described a sort of nightmare scenario where people can Build bribery systems for smart contracts that operate completely in the dark So no one can tell exactly what players are being bribed to do how many players are being bribed Or or if the attack is even succeeding at all Not only that but users are guaranteed that the person that's bribing them is not going to get control of their money So the entire thing is sort of a trustless bribing infrastructure Right and the dark down is actually a mechanism for bribing other mechanisms essentially And what I'm going to do today is introduce this new term for you guys that we call anti mechanisms Which are all mechanisms that are intended to disrupt other mechanisms? So the dark down is a particular type of anti mechanism It's called the dark down because it's dark or invisible no one can tell exactly what's going on inside it But you could also have a public bribery contract or other form of anti mechanism And what anti mechanisms look like is basically this so on the left you have what what it looks like when users are playing a Regular mechanism they're sending messages to this mechanism and the mechanism is coming up with some outputs of the game You can see this mechanism as a smart contract on Ethereum Private keys there on the left sending transactions to the mechanism and some outputs occurring in the state of the system An anti mechanism happens when you have another mechanism that users can play through instead Potentially one that can interact with the original mechanism so you can see that there shown on the right M prime here is an anti mechanism and two users in this case are playing M through M prime So why does that matter it matters because the existence of these anti mechanisms Erode a mechanisms ability to faithfully implement its social choice function So in terms of optimizing for those goals that we talked about earlier that mechanism design loves to optimize for Those goals are highly harmed by the existence of these anti mechanisms Not only that but we can actually quantify the security of a given mechanism as the smallest budget Anti-mechanism that disrupts the properties we designed the original mechanism for So I would encourage you guys to stop thinking about anti mechanisms or sorry Stop thinking only about mechanisms when you design your smart contracts and your protocols and start thinking about what? Anti-mechanisms could be possible in your system and what the sort of lowest cost of disruption is as a result So for the VCG auction the second price auction we mentioned earlier Here's a very simple anti-mechanism M prime All M prime does is it collects bids from its users and it forwards only the top bid to the original mechanism M So why is playing through M prime always better than playing through M? Well, if the highest bidder plays through M Doesn't matter the outcome is the exact same as before so no one's worse off on the other hand if the highest bidder happens to play through M prime Then either the second bidder plays through M prime in which case their bid is never forwarded and the highest bidder ends up paying less Or the second bidder plays through M and you get sort of the same outcome again So what we say is that M prime composed with M or playing M through M prime in this case dominates in this case weekly dominates Playing M directly it's always better for players to play through M prime and it disrupts what we talked about earlier Which is the dominant strategy truthful nature of VCG auctions because the auction is no longer receiving the true valuations from the buyers So in this case VCG in terms of a dominant strategy truthfulness has zero security against bribery And bribery is a huge deal in all these systems were building a huge deal in smart contracts So if you're building an oracle you can bribe people to provide certain responses You can bribe them to go offline You can bribe them to choose which point in a continuous time series of data They sample and send into the blockchain if you're running a vote or a governance system You can buy people's votes you can pay them to not vote you can otherwise influence governance if you're building an identity system You can build anti mechanisms that lease people's identities or partition out certain capabilities of the identities as separate from others and For all mechanisms you can bribe players to take certain strategies and even to collude with each other or not participate So the conclusion is basically this At least for now So what are we going to do about it? Well first let's talk about the core problem here Which is that this dark down or these private smart contracts that we're talking about remove a user's free will in the system They do that by restraining the actions a user can take in this cryptographic system and basically shackling them to a certain set of Strategies or shackling them to a certain collusive set And we want to get back to sort of a state where users have free will where we know that if they're signing a message They could have signed any other message in the system as well And they're not artificially shackled by some other piece of technology or some anti mechanism So here we define free will as the ability for a user to use their information in this case They're keys in Ethereum without any external restrictions and in this case. We're specifically talking about remote parties People who are trying to bribe or otherwise influence users over a network because that's most of what we're trying to secure against So this problem actually goes beyond cryptocurrencies. This is not only a cryptocurrency problem These two papers have pointed out similar problems in traditional cryptographic systems So one thing you can do is you can use SGX or MPC to take a deniable communication protocol Where the property is that I can't generate a transcript of the protocol And you can actually generate a transcript that's provable, right? So I lose all my deniability I can't tell you that no, I didn't say this because now the MPC or SGX process is gonna stamp for me that Yes, I actually did say this or you can use it to do things like bribe people to act Certainly on Facebook or buy their votes in like sort of Traditional voting systems and things like that which is what that paper on the left deals with So how do we get back to free will well our core task is ensuring that a user has unlimited knowledge or access to their private information such as their keys and that that those private information Or that private information can't be stored in a secured environment. That's somehow shackling the user And our second task is that we want to use this to make a signature scheme That's usable in things like smart contracts. So we know that when a user signs the message they actually control their key So we more generally define free will as the ability of a user to learn their own secrets And we achieve free will by requiring that whenever a user sends a message that involves secret data for example a private key Someone can eavesdrop on that message and because a user won't let anyone else eavesdrop on their message That would for example compromise their funds That means that essentially the user is able to eavesdrop on their own data So what we're gonna be doing is sort of Designing a scheme we call complete knowledge And users are gonna provide these complete knowledge proofs to the system to prove that they actually know their own secrets And that some human knows this secret and it's not somehow shared across multiple parties or otherwise constrained So I'm gonna flash a bunch of cryptography at you these slides are gonna be on my Twitter if you want to read this in more depth But the only important thing on this slide is sort of these last two bullet points Which is that we consider two computation environments One being sort of an untrusted computation environment and another one being an eavesdrop environment And we want to make sure that a user has to send their private data through this environment that they can also eavesdrop on and Therefore can learn their own private data And the way we generate these proofs is we require some proof scheme that matches these two cryptographic definitions The two important properties here are number three and four the first one is unforge ability That means I can't prove to you that I know some secret data That I actually don't know right and the second one is secret eavesdropping Which says that I have the ability to eavesdrop on my own data and nobody else in the network can tell whether or not I actually did this eavesdropping or not If they could tell whether I actually did the eavesdropping or not They could simply require me not to do the eavesdropping when they bribe me So it's very critical that the data is able to be eavesdropped on but sort of in the dark and in secret and The basic solutions we use for this are actually quite surprising So there's two possible schemes here One of which is based on Bitcoin asics and another one of which is based on SGX or trusted hardware So the Bitcoin a solution is to basically do a proof of work on your secret key as well as some challenge And then generate a snark that some asic has done this proof on a secret key that the snark keeps secret That corresponds to a public key that the snark makes public So when the snark is submitted to the network, you know that at some point someone put that secret key into an asic to generate the pow The SGX solution similarly forces you to send the secret key as input or the secret data as input raw unencrypted input into an SGX chip So on the left this allows users to eavesdrop on their own data because asics are not secured You don't know what firmware someone else is running on their own asic and whether it lets them eavesdrop on their data or not on The right SGX achieves this because SGX enclaves Have to be communicated with through an unsecured OS and nobody sort of in the broader network can tell if the OS that Was communicating with the enclave did or did not eavesdrop on its secrets So I'm not going to go through these but check them out later if you're interested in sort of the formal cryptographic definitions of both of those schemes What we're actually implementing is a little bit different So the problem with the schemes that I just mentioned is they're a little bit heavy-handed and inefficient Generating the snark actually takes quite some time So there's this cute little trick you can do for the proof-of-work version where you restrict the non-space of the asic and Require someone to try multiple times to sort of generate a proof such that if they try more than once They can recover their own key And with high probability then they'll be able to sort of eavesdrop on themselves So Basically the math here works. So let's talk about the proof-of-work version The proof-of-work version fails in one of several cases So the proof-of-work version will fail if you can use a CPU to generate the proof of work Then SGX can just directly make this proof even though the secret data is never known to the user It also fails if the asic fails to find a proof then a user that actually knows their own secret data won't be able to prove that to the network Fortunately Bitcoin asics are much much much faster than CPUs So a hundred thousand times faster than state-of-the-art CPUs at this sort of work And you can see that Given even if they're only a hundred times faster the probability that an asic will find a solution before a CPU is basically one Right, so there's sort of a broad range of parameters here for which it's highly likely that an asic will be able to find this proof-of-work But a CPU will not and therefore no sort of SGX process or multi-party computation can also solve this proof-of-work So these are the the marginal CDFs of sort of the times to solve blue You see the probability that an asic has solved the puzzle and red the probability that a CPU has solved the puzzle And you can see the asic slope is just much steeper So you can sort of parameterize your system to make sure that an asic can always give you this proof But a CPU can never give you this proof and therefore no constrained or shackled computing environment can ever give you this proof So what we're going to be doing is releasing this sort of system on Ethereum using this kind of an architecture So all you're going to need to do in your voting contract or anti bribery mechanism is call this single function on our registry When CK which will tell you the last time that a complete knowledge proof was generated on some key the last time some user proved to the system that they actually are able to learn their key right and Users can choose like several back ends to do this if they prefer to do it through SGX They can do it through SGX if they prefer to do it through a Bitcoin asic. They can do that And interestingly enough this also gives us an opportunity to recycle old Bitcoin asics because even old asics that are no Longer profitable for mining on the network are still much much faster than state-of-the-art CPUs and can still be used kind of to generate these proofs So I recommend to you that if you're designing a system where bribery is a big deal You should use this technique to make sure users actually know their data and they're not being bribed by some sort of Shackling mechanism some anti mechanism like we described earlier Not that CK is enough by itself though So you need to actually follow this more complex recipe you need to also provide the classical notion of coercion resistance Which basically says that a user can secretly change their mind whenever they want So if a user can secretly change their mind whenever they want There's no point in bribing the user because you don't know if they're just going to go and change their mind later You can't tell if they did that or not, right? And because you're using CK you know that there's no sort of shackles on the user that prevent them from changing their mind in this way And for stake-based systems we want to require this on the stake key So we know that whoever signed the message actually has skin in the game and actually has funds at risk Sort of using the generation of this message So the high-level takeaway here I guess is that if you don't use this system your protocol is vulnerable to bribery period no exceptions So please don't DM me on Twitter and ask me like are we vulnerable to bribery and collusion if you haven't sort of studied this kind of Infrastructure and read this background material because you a hundred percent are And if you're interested in learning more about the technical details or you want to sort of use this in your anti bribery systems Please feel free to reach out to me and I'm happy to chat more It's a very complex sort of topic. I only had 20 minutes to describe it I know I sort of flew through it But hopefully you got some takeaways that we can sort of make sure users own their own data in these systems And that's very important to making sure that they're not being bribed All right, if you'd like to contact me or learn anything further Here's my information as well as funding and a big thanks to all our IC3 partners and the ethereum community for their support in this research Thank you