I wanted to talk a little bit today
about what it's like as a DAP developer
to think about Charlotte block chains in
particular asynchronous communication
between smart contracts so you know from
the introduction you know that I'm one
of the co-creators of cryptic ad so I
was also the original author of ER C 721
I contributed quite a bit on the
upcoming Chi's Wizards game and will
actually have a little bit more
information about that in the middle of
this presentation and then I'm the chief
architect of the upcoming flow
blockchain in computer science we like
to have these toy versions of abstract
problems because it makes it easier for
us to think through them I'm sure
everyone in this room is familiar with
the Byzantine generals problem it's
probably the most famous one is the
Traveling Salesman problem as a way of
thinking about how to build a spanning
path through a through an arbitrary
weighted graph and and then my personal
favorite is the dining philosophers
problem that asks you to imagine that a
group of philosophers is eating dinner
together and not only can they not eat
unless they're holding a fork in each
hand but they're actually sharing their
Forks after they've gone into each
other's mouths it's quite amazing but
but we have these these problems because
the problems themselves are so abstract
that they're hard for ourselves they're
hard for us to reason about and so we
create these these stories these toy
stories that are maybe a little bit
disconnected from reality but they let
us use our human intuition about how to
solve them and there's a common one that
comes up in the Assyrian community or at
least that's where I saw it first it's
called the Train and hotel problem and
it's if you search on e3 Searchers
there's a bunch of great articles about
people having ideas on how to solve the
trainer Hotel problem and it's
fundamentally how to solve the problem
of asynchronous communications between
smart contracts that live on different
shards and so the toy version of the
problem says hey you're travelling to a
city and you need a train ticket in
order to get there and you need a hotel
a room when you get there and you don't
want to pay for a train ticket until you
know that you've got a hotel room and
but you don't want to book a hotel room
unless you're gonna be able to get a
train ticket and so if the train was on
a smart contract on one shard and
the hotel was a smart contract in
another shard how do you go about
solving the problem of booking both of
those things without potentially being
in a situation where you've you've got
one without the other
and you know there's there's a few
interesting solutions to this problem
some of the more interesting are you
know the ability to actually move smart
contracts from one shard to another
which you know has the potential problem
of leading to denial of service attacks
the idea of of mining two shards are
synchronizing to shards so that the
validators are are trying to solve the
two blocks on to shards at the same time
to allow synchronous communication
between the smart contracts on those two
shards which doesn't scale if you want
to have three smart contracts hakka to
talking to each other and so usually
most people think that the best way to
solve this is just to have some sort of
state locking mechanism where you can
you know more or less put a reservation
in for the train that is cancelable and
then you go in you book the hotel and if
that's successful you you follow through
on the train reservation if it's
unsuccessful then you can cancel the
train reservation so that toilet problem
I think is useful but but I think it's
limited because it's so simple and so I
want to talk about something that maybe
seems even more simple but he's actually
a little bit more basis in reality and
that's Kitty hats so Kitty hats is a
project that was created outside of
dapper - as an extension to Krypto
kitties and it let you put cool hats and
other paraphernalia on your on your cats
and it was a set of smart contracts that
leveraged our smart contracts but we
didn't even know they were doing it let
alone have any any special hooks for
them to be able to do this stuff and it
really you know showed the team and how
one of the properties of watching that
we weren't really expecting when we
started building crypto kitties and
that's this idea of extensibility or
composability so this is sort of what a
kitty hats
implementation would look like if you
imagine that Kitty hats used a stable
coin instead of just eath so if a user
wants to go and buy a hat to put on
their cat the they go through this the
single transaction where they they send
their requests to
the kitty hat sales contract and that
contract through a series of synchronous
calls to other smart contracts is able
to verify that all the things that need
to happen can happen so the first thing
it does is it checks the crypto kitty
smart contract to ensure that the kitty
exists and that the person who's trying
to put a hat on it is actually the owner
of it because you can't put a hat on
somebody else's head can't put a hat on
somebody else's kitty that would that
would just be absurd it makes it
transfers the the stable coin over which
you know will fail if the funds are not
available and then finally it'll put the
cat the Hat on the cat which also could
fail potentially if the the kitty
already had a hat and there was a
conflict there but the nice thing about
a single atomic transaction is even if
that last part fails everything you just
seamlessly gets unwound as that as the
transaction reverse but what if we had
that same scenario where we had these
you know four smart contracts working
together but each of them was on a
different shard well it suddenly becomes
a much more complicated solution so in
in the this solution that I've shown
here and it's not necessarily the only
solution but it was frankly the best I
could come up with it involves locking
up the assets that were involved in the
transaction before the transaction took
place so you see say that see they're in
block one the user is locking up their
cat making sure that that cat can't be
transferred well the rest of the
transaction is there the rest of the
interaction is taking place they're
locking up their stable coin and they're
locking up that hat and then once they
have like sort of a receipt from each of
those other shards saying hey these
these things are locked up they can't
change their state or or change their
ownership then it can go to the sales
contract and say okay it's safe that to
send a message to all these other
contracts and allow these these
transfers to go through and you'll see
here and I haven't explained all of the
the bits and bobs here but what was a
single transaction on a single shard is
when it's across four shards it's now 11
transactions and it's taking seven
blocks possibly much more if those cross
shard interaction calls can't happen in
subsequent blocks which many designs
don't allow
and this kind of interaction between
smart contracts is hardly threat achill
you know you you I'm sure everyone in
this room is familiar with all of the
awesome projects in the dphi space and
compound can't exist without die 0x is
not interesting unless it's talking to a
bunch of ERC 20 tokens and all of these
projects are building on top of each
other and most of them would be
difficult if not intractable to build if
they had to deal with asynchronous
communication with those other smart
contracts so I want to talk about
another revolution that happened and
sort of the peak of that revolution the
open source revolution was in the year
2000 and in 2000 everyone was really
excited about open source and it was
gonna it was gonna completely transform
software and it did but not the way
people thought in 2000 people expected
that Linux on the desktop was we're
gonna replace Windows and software like
OpenOffice and the was gonna
replace Microsoft Office and Photoshop
and and that's not what happened at all
the open source revolution was real and
it completely changed the way that we
think about and make software but it
looks like this it's a bunch of little
tiny components that are built on top of
each other and some of those components
aren't so tiny right there they're
significant but what the power of them
is that they're not solving a particular
user problem it's that they're consists
of a set of it's there a set of tools
that different people can create
different solutions out of and I believe
that the real power of smart contracts
if we think of them in that way as
building blocks that are you know each
building on the next and working
together to create lots of solutions and
not just these monolithic things that
are just replacing one institution at a
time with replacing one institution with
one smart contract and so if you ever
see people talking about the training
hotel problem I want you to imagine in
your head well you know came maybe we've
solved the train and hotel problem but
have they solved the Train hotel
restaurant reservation movie tickets to
or bus a problem because I think that in
reality smart contracts it's very rarely
won smart contract meaning
talk to another it's it's a multiple and
that term that has come to Express this
is his composability and and I truly
believe that composability could is the
superpower of smart contracts you see
here a quote from Jessie Walden of
andreessen horowitz and he wrote a great
piece talking about composability and I
think the you know the key phrase in
there is compounding innovation the fact
that it's not one person or one team
that needs to make one giant step of
innovation it's that everybody can
contribute a little bit and that
compounds over time and as we all know
compounding growth is exponential and
there's no more powerful force in the
world
[Music]
[Applause]
[Music]
with that visit cheese wizard calm to
summon today
thank you so that was cool and all but
what the heck doesn't have to do with
smart contracts and composability the
team at dapper labs was so inspired by
the example of kitty cats that when we
built our new game cheese wizards we
were bought into the notion of
composability and extensibility on day
one and so over the last six weeks or so
we've been running a hackathon with a
bunch of community support and prizes
because we wanted to kick-start the the
the community's creation of some amazing
tools and there's a couple of it's one
of the highlight right here
so on the right my mark Pereira did a
mobile version of our of our of our
battle game it's a you know she's was
just a game where you buy Wizards and
you fight them and there's it's a you
know it's the land of Highlander there
can be only one and whoever wins the Big
Cheese will take home a big old pot of
ether and you know our team didn't have
the time to build a native mobile app
and so mark took it upon himself to
build one which is amazing there is
cheese now over there which I think is
incredible I don't know if we would have
thought of that ourselves it's the
ability for anyone to create a dhow
multiple doubts if they want and it's an
interesting sort of down where the
voting power in those doubts is not
based on whose contribute the most
tokens but who's been the most
successful in the game and so this is
the kind of thing that is possible when
you are building platforms that don't
have platform risk and that's that's
what I think is the the is the real
power of smart contracts and so I think
we've seen this in a bunch of places and
I think that this is going to be the
story of smart contract platforms in the
future if we let it but I get real
worried because I fear that if
composability is the super power of
blockchain that sharding and in
particular asynchronous forcing
asynchronous communications between
smart contracts could be its kryptonite
thank you
you
[Applause]
you