LibSubmarine - Temporarily hide transactions on Ethereum (Devcon4)

so yeah it's a fun I'm here representing Lib submarine I spend most of my time thinking about security tokens so he's financial securities had we actually represent them on the blockchain but I've been fortunate enough over the last few months to work with some incredible people and implementing Lib submarine which comes off of the work that has been done that I see three out of Cornell so Lib submarine there was a previous talk earlier today describing how the mechanism is actually used to prevent front running on decentralized exchanges my talk today is gonna talk about how do we actually implement those what does it look like from the smart contracts perspective and how does it look like from the DOT perspective to work with Lib submarine so let's jump into it quick overview I'm not going to go into detail about this Lib submarine is the right solution to prevent reordering attacks and also to increase the level of privacy in a commit reveal scheme and really eliminate the signal that the commit is gonna provide so on the on the left side of the screen here you can see kind of what a regular commit reveal scheme will be which is you have the commits that hashes the data but you still have see the participation as well as the value that's being committed then during the reveal stage you reveal what the data can contains and maybe this is like a voting mechanism right on the right side of the screen you actually see what it would look like from a submarine perspective which is the entire commit period is completely hidden its mask you don't see who's participating you don't see the value that's being committed and of course you don't see the data that's being committed but again everything is revealed at the end of the day so how do you actually implement it here on the left side of the screen we have a very simple auction contract that's implemented as an ER C 721 token receiver hook we took out a lot of kind of the basic storage and like function setup functions are required for the auction and only left this bid function which is the one that people would monitor to get an idea of what the active bids are on this auction so what someone that's monitoring the chain would see is that when someone commits a new bid to the to the so the mempool they could see it and then make sure they place a transaction right after that kind of beats the bit and make sure that they're on top of the auction so what you want to do is be able to mask the value and and really the participation inside of this bidding and create what is called a sealed bid auction so this can be done the only function that you end up needing to change is this bid function so you actually implement it as an event receiver hook based off of this lib Submarine contract that you inherit from so you can see at the top you inherit the the the new contract and then you implement this function called on lips on submarine reveal with these data parameters so the submarine ID is what kind of identifies the bed and then you have the embedded data which is that data that was previously hashed in a commit reveal scheme in this scheme you have it through this function and as well as the value then the logic of your function actually kind of remains the same you still have the same logical checks the same storage changes and the new logic for calculating who is the winner so this and would actually happen on the reveal stage of your commit reveal so you make sure that you're not liable to someone that's watching all the commits unable to to make beds accordingly so from the user perspective if you're just modifying a traditional commit reveal scheme it actually doesn't look very much different from a user perspective it still needs to do to sign transaction from the user and then you have this third transaction which is the unlock transaction which is generated as kind of a raw sign transaction and can be relayed by anyone that's communicating with the chain so from a client perspective then what you have to do is you have to also have your commit that gets generated on the off chain and then also you have to generate a miracle patrícia proof of that commit off chain and we've added some Python scripts inside of our repository that actually does this for you and then on chain we have implemented all the smart contracts that actually executes this Submarine commit and then also verify that the commit is done through doing on chain miracle material proof verification so all in all if you compare kind of the gas consumption of just a regular transaction with the gas consumption of a submarine sentence or live submarine you have approximately 200 K gas additional per per commit reveal kind of process but on the flip side you get front running protection and you also get protection against signaling schemes so we have one decks that's looking to integrate with us already to help them prevent their their front running problems and we encourage anyone that's looking on implementing these kinds of techniques to reach out to us these are our Twitter hashtags our twitter handles so reach out to us we'll be happy to answer question how to integrate and you can also check out live submarine org this is just open source code that we're working on for fun no fees no token no nothing take a look implement it and see you online