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
you