EthCC 2: Lorenz Breidenbach

[Music] test test can hear me perfect so uh bones rule for everybody my name is Logan splat whaaah I'm here from ETH Zurich and I see three the initiative for crypto currencies and contracts and today I will tell you about lips submarine and a theorem library that allows you to temporarily hide transactions on aetherium and defeat front-running so this is based on research with my awesome collaborators Phil Diane florian trauma and re jewels as well as on development with my co developers Tyler Kell and Stefan Gosselin so shout out to them and let's let's dive right in so why would you want to temporarily hide transactions on a theory and why is this useful well basically whenever you have some sort of problem where you're worried about either somebody front-running you or in some other way benefiting from the knowledge that your transaction will be included in the blockchain in the future then this is useful so here's a few use cases for example for blind auctions you want to hide the bids that are being made for the auction for Texas you want to prevent front-running for voting you might want to hide who is participating in the vote until it's over for challenged protocols you have issues where cheaters can upon observing that somebody else wants to challenge them challenge themselves to lower the economic punishment that they would receive for having cheated and then for bug bounties for example you also deal with a sort of bug withholding attacks which are also related to front-running so this pops up in a lot of contexts and perhaps even your dad so let me let me give you a brief intro to what front-running is for those of you who don't know so here we have an example where we have a user that wishes to purchase some tokens from a dex contract that acts as an automated market maker think bank or or think you only swap to something along those lines and so the user will broadcast a buy transaction to the etherium network the transaction will bounce around the network sit in the men pool and then eventually get mind now what a front-runner can do is he can profit at the user's expense and the way he would do that is by sandwiching the users transaction between two of his own transactions so he would broadcast the buy transaction maybe pay a minor some some money or collude with a minor to get his buy transaction included in the blockchain before the users buy transaction is included and then he would immediately after the users buy transaction include a sell transaction now what happens here then is that if you look at what happens to the price on the decks once the front-runners buy transaction arrives the price on the decks so after at this point the price on the decks will go up now our users by transaction will arrive and will buy at a higher price than she would have otherwise and finally our front runner sells again so after all of this is done the price on the decks is exactly the same as if the front runner had not sent any transaction at all but our user ended up paying more than she would have otherwise and the difference between those two amounts that's what the front runner pocketed at the users expense and so this attack is not just theoretical a guy named Yvonne Bugatti wrote a nice blog post about how he implemented this for Bank I think he computed that at the time he could make tens of thousands of dollars per month running this just against banker and I think with the increased proliferation of various decentralized finance products the lucrative Ness of these attacks is only bound to increase there's also an interesting project by IC 3 as well which is called front run me which monitors the the gas markets on the etherium network in real time and which i think indicates that by now there's a lot of parties who are sophisticated enough to do these sorts of attacks or perform these sort of games and at the expense of unsophisticated users so let's let's look at went wrong here in the in the example for example of the ex contract the issue is that the user red broadcast some transaction to the contract and this is observable to everybody and it's not just the transaction that's observable but also the amount that's attached to it so both the data and the amount of money you are sending to the contract and this is leakage that you don't want so one thing that people sometimes do to to sort of try to mitigate these kinds of things is to use something called a commit reveal scheme so the way this would work is that the user would first send a commit transaction to the smart contract the commit transaction would sort of use a use only a hash of the actual data the user wants to submit to the contract so that would not be visible to the adversary and then at a later stage the user would vo and only then the smart contract would know what information the user wanted to pass to it and would take some application specific decisions based on it the problem here is that this send of funds this commit right is still visible so the adversary still sees how much money is being sent to the contract and still sees that a commit transaction occurred to that contract and this on its own in many cases is too much information so again into the scenario of sort of an auction right seeing how much money somebody's bidding basically tells you all you want to know and this is where submarine sends come in so the sort of key idea for submarine senses that we say we also do a commit reveal but for us the commit goes not from the user to the contract directly but from the user to what we call a submarine address and this address has some special properties so in particular it looks just like a fresh address so this commit transaction looks like the user sending some ether to a fresh never-before-seen address on the etherium network and so this commit transaction is hidden in a large anonymity set so something like 2% of all transactions on the etherion main net look like this and so now an adversary observing the network won't be able to tell what is a commit transaction and what isn't and a second stage the user then reveals to the smart contract and the contract can verify the reveal verify the commits unlock the funds stored in the submarine address and pull them out and again perform whatever application specific logic you wanted to do so this is this is nice right but now if you think about this more deeply you should probably come up with some questions so how exactly does this work so the first problem is that we somehow need to establish the order in which commits occur right so we need to know when a commit occurred inside of our smart contract so again to go back to the example of an auction contract the auction contract needs to ensure that bids only arrive during the bidding phase not afterwards and again in the traditional world sort of where you just send the commit transaction directly to the smart contract that's easy to do because the contract can just timestamp that and record that in storage but here the whole point is that nobody not even the contract saw this commit transaction only the user is aware of the fact transaction was a commit transaction and so we need some way to to let the contract know that it was a commit transaction and when it was included in the block we need to prove when it was included and so now we can exploit a property that the etherion block structure affords us which is that all transactions are basically stored in a sort of more complicated version of a Merkel treaty which is called a Merkel Patricia tree and what in particular we can do with that is we can give efficient small proofs that a certain transaction was included in a block that then anybody can verify if they know the block cash sounds simple unfortunately from an implementation perspective it's quite tricky to do because these Merkel patrícia proofs or trees that etherium uses just introduce a lot of implementation complexity if you've ever sort of tried to do any sort of etherium client development you're probably familiar with this problem but we said okay let's do it let's bite the bullet let's shave the Yaak and I can happily tell you that the yak is now naked and we we implemented a library that allows you to easily verify these proofs inside solidity inside smart contracts and you can also easily generate them off chain so you have an off chain generator that generates such a proof and then as part of the reveal you submit the proof to the contract and the contract can then just use the library to check that the proof is correct and that you need to commit it when you claim you commit it so this is the first challenge the second challenge is how do you construct the submarine address so if you remember we need kind of three properties for this address the first property is that we we want to make sure that any funds that you send here to this address can only be unlocked by the smart contract nobody else should have access to them second of all we want to make sure that the submarine address looks just like a regular fresh address so that we have this anonymity set property and finally we need to ensure that the user can compute this address offline without having to interact with a contract on chain because again any such interaction would be observable to our adversary and we used to do this using some pretty complicated ECDSA signature stuff but since roughly one week ago we have a new toy which is the create to up code and that greatly simplifies how we do this and so I wanted to give you a quick overview of how this works and I think this kind of trick is very useful in general and maybe you can also independently find it useful in your own contracts so what we do here is we or or what the what the create to up code gives us it computes the address of a contract that's deployed as a hash of the creator's address of the code of the contract that's being deployed and some user supplied salt and this is nice because we can basically send funds to an address where no contract exists yet knowing that only a specific contract can be instantiated at that address and this is exactly what we do here so the user to send this commit transaction computes the submarine address as the address that would be used by a create to created contract that is created by the receiver smart contract the user knows this then a very very simple smart contract that this smart contract will instantiate at the submarine address it's it's literally two instructions two bytes and all it does is it immediately self destructs and sends all funds back to this contract so this is the unlock step and as the salt we can just use a hash commitment to whatever data the user wants to supply to the smart contract in the reveal stage so so this is neat it's it's much simpler than what we had to do before and I'm very happy that we have a two byte smart contract that's useful so now you saw this this this kind of as you see is not super easy right there's quite a bit of complexity here but our goal was to sort of abstract all of that away and package it into this nice library that you can hopefully easily use in your own projects and so this is sort of a not quite complete but but almost complete sketch of what a simple blind auction contract would look like that user slip submarine so first of all you simply you know you inherit from the loop submarine simple contract to bring in all that functionality that that we just talked about and secondly you basically only need to implement handler function that will be that is sort of an abstract function and the base contract that you then implement and it will be called when a user performs a valid reveal so the base contract will take care of all of the logic of checking that the reveal is valid that the commit was valid how much money was sent in what block the commit was done what the what the index of the commit transaction that block was etc and it will simply supply all this information to your sort of handler function that can then do the application-specific logic so in this example I simply check that the commit was done while the commit period happened so kind of like the bidding period and the auction example that the reveal was done during some again limited reveal period then just for the fun of it we say you need to bid at least 0.1 ether for this auction we require that each bidder can only make it most one bid and finally we just do the the update of who has made the best fit so far and then what you don't see here but what you would probably see some extra function where then once everything is over the winner can withdraw there or whatever crypto Kitty that they bought and the losers can get back the money that they put into the contract because they are not getting the crypto Kitty so this brings us the question then how much gas does all of this cost right it all sounds nice but is it feasible is it is it useful in practice and so I'm very happy to report that since DEFCON we have substantially optimized the contract and have now brought it down to what I would argue is a fairly feasible gas overhead in practice so compared to sort of just writing your contract without using luke slip submarine and you pay an extra 90,000 gas and total for sort of the typical flow that a user would go through 21,000 gas or just this commit transaction which is just you know the regular send of eath to an address that looks like a fresh address and then 69,000 gas result from this reveal and unlock logic that I described to you yeah that's that's it check out our website at loop submarine org check out our code it's all open source no token no SEO [Music] I'm github wow that was a pretty enthusiastic response to that yeah and if you have any questions contact me after the talk ask now DM us file a Twitter issue whatever your preferred mode of communication is thanks everyone [Applause] okay so penny we have time for two questions if anybody wants to ask a question here so do I understand it correctly that it's so cheap in terms of gas that it's actually cheaper than traditional hash-based commit and reveal and it's it's obsolete today so this is better in every possible way I mean traditional sort of commit and reveal what I think still be a little bit cheaper right if you just look at the overhead you introduced over your whatever you're doing you basically have the sort of commit transaction which would be probably something on the order of say 40,000 or so right because you roughly pay twenty one thousand does the base price and then twenty one twenty thousand to store the commit hash and then the reveal you would basically just kind of maybe make one more storage update so that's another forty thousand so then you pay eighty thousand which is less so it's a little more expensive but not not much no just a quick question art weary centralizing it a bit here meaning that we are using a third party for each transaction no so so so so just to be clear so this is all entirely maybe this is a good diagram for it so this is all entirely trustless purely in smart contracts there is no third party no reason centralization because this submarine address right you can you can just through some sort of ethereal magic compute that address send funds to it and only the smart contract can access it so you don't trust any additional third parties sorry dynamic address right the addresses computer dynamically exactly all right thanks everyone [Applause]