hello everyone this talk is aimed
primarily at application developers and
I would like to give a quick overview of
the architectural considerations behind
developing decentralized applications
for aetherium on top of s'more so what's
wrong with the web to model well
yesterday we have already heard that the
web is kind of broken so it has these
problems that you have a centralized
trust management based on certification
authorities you cannot really trust
content delivery networks and so there's
this other problem that scaling is so
it's buying more power from data centers
by the person who provides the
application whereas demand is just users
pounding it and there all sorts of like
elastic solutions but none of them so
they're ugly they're just a hairy
solution to providing more computing
power as you have more clients even
though there's this natural thing that
every client who comes they come with a
computer that could just be used so it
would be really natural to scale
computing power by using the actual
computers that the users come with and
the problem however is that so trustless
computing it comes with overhead costs
that are not going to go away so for
example if you are trying to host a
number of movies it will be always
cheaper to do that in a data center than
to do it on a trustless network so
there's always going to be an overhead
and somebody will have to pay for it and
you need to keep that in mind but we're
working really hard to reduce that that
overhead to a acceptable level so that
the other overheads that centralized
solutions
like the profits of unrelated people
they will be comparable or maybe even
lower so so how do we get from web to to
app three first of all you may want to
dispose with the notion of clients and
servers so for now aetherium ecosystem
the app dab the ecosystem is still very
reminiscent of the old ways so we have
the nodes and we have the clients and we
have these things like meter mask and it
looks like we're running a client-server
network but really it's a peer-to-peer
network so as you could see from today's
presentations we're really moving in the
direction that there's going to be some
kind of ethereal node everywhere there
most of them will be light and very
light nodes but still we're going to
have a network where there are many many
nodes and you typically don't connect to
high powered nodes for your needs you
have your own node so the backends that
we're going to have their old general
purpose they're distributed and
basically the the ones that you need to
rely on and the are the three listed on
the slides so you're going to have a
contract content address storage which
will be something so in this case it's
warm IP FS is hopefully so hopefully we
are going to make swarm ipfs compliant
and the addressing mechanism and the
access mechanism will be compatible or
even the same so what I'm going to tell
here applies directly to ipfs as well as
it applies to swarm hopefully it will be
the same thing
there's the blockchain based on census
so wherever you need global consistency
you can solve the blockchain and you
will have a synchronous messaging so
that's that's the things that you can
think of as a back-end but you will not
have
cific databases that you need to query
and so on which has this funny property
that particular business logic the
business logic of your application will
mostly run on the clients which is
either web applications written in
JavaScript or native mobile applications
so you will have to actually consider
that much of your business logic is
going to be run on the client it doesn't
mean that the API will be such that you
will have to do the index traversal
yourself but in reality it is the client
that is going to traverse the index for
you so the you will not send queries
across the network you will actually
traverse the indices as you access them
from the content address storage and you
can only send the query to the API and
it will be executed locally so here's
here's an example of how the HTTP is the
the Web API
it works with swarm so the URLs begin
with the root hash of a collection a
collection is basically a collection of
objects objects are binary files with a
mime type so for example it can be a PNG
image but so it looks very much like a
directory but it really isn't so for
example the second example is a map tile
where that long code is the hierarchical
tile code for for map slides so in a
single directory you will have thousands
or hundreds of thousands or even
millions of files if you think about it
as files but you really shouldn't so
it's really a a database and whenever
you access something like this map tile
you're actually doing the know the
indexed River so locally which is of
course fast because it's it's
done efficiently but it's still done
locally and the property of the API is
that if you change anything in the
collection it also happens fast but it
changes the route - so any put or delete
method will result in a different hash
and it will it will return to you the
the new hash and of course if you want
to have some global state that is
consistent across all the all all the
users then you can register these route
hashes on the blockchain for example in
hierarchical in hierarchical name
registry contracts so in the last
example you see an image which is
registered in an album a photo album
that is actually Joe's personal photo
album the user experience is going to be
very familiar to web users that's what
we're aiming at so interactive
responsive intuitive and so on however
Identity Management will also be done on
the client on the browser side so you
don't have to implement your own
identity management with each DAP you
you get it ready and you're going to
have legal and financial interactions so
it's no longer a click-through contract
it's something that actually has
consequences so it comes with all those
things that are also listed on the slide
so now I will show you a few examples
some of them are already implemented and
downloadable from a source repository
some of them are tearaway vaporware but
all of them have these basic properties
so the current route hash is registered
on blockchain so that every every user
can check on the blockchain which is the
current version of the DAT and that's
where they that's where they proceed
from so we have done away with the
problem of security in her in
and in HTTP but you need to trust
something else on the blockchain most
static and dynamic data are stored in a
content address storage and global state
changes are registered on the blockchain
so it's usually global state changes are
simply changes in a hash if you don't
store a lot of state data in the
blockchain because that's expensive
however you still need to to get those
change changes to the blockchain
eventually so that there's a global
consistency and I have already talked
about about the other things so whenever
you have some local data local state
like what the user is working with you
keep it locally you don't submit it
anywhere you can back it up if you want
to so the first example is a distributed
photo album this is already existing it
can be you know you can download it you
can look at the source you can learn
from it you can take parts so it is
completely open source so both the data
and the web app are hosted in a swarm
and they are hosted in the same
collection that's very important so you
don't have a separate root hash for the
data and that it is the depth and the
data together that have the same root
hash so you can register a photo albums
particular State
which means the photos in it and the
ordering in which they are presented
long term incentives of swarm will make
sure that it's not garbage collected
that's actually not implemented yet
short terms incentives will have the
publishing Goes Down which means that if
your photo album for some reason becomes
hugely popular and half the web wants to
see it it will not be a problem for you
and it will not be a problem for your
users either because the performance is
guaranteed performance is improving
together with popularity the easy part
is
that there's no concurrent editing and
no comments rating so we have styves up
the few difficult problems of that
development in this particular example
however it's still worth looking behind
the scenes so one thing that is
happening here is that the blurred
backgrounds and the thumbnails they get
generated on the client side during
upload which is fine for a photo album
but let's say you want to move on and
you want to do something distributed
like you so you want to do something
like YouTube in a distributed fashion in
that case you need to transport huge
video files or you want to transform
projections for immersive panoramas and
things like that which are
computationally expensive so all that
stuff can you do that in a mobile phone
well you can but you probably don't want
to so in that case you need to do
delegated computations in which case you
submit the data and the specification
and the reward and you want eventually
to have a result of that computation and
the proof that it is correct so there's
gonna be other talks in this session
which we'll delve into that what I would
really like to highlight that there are
two ways to go about it either you
specify in an imperative fashion in a
special blockchain in a special virtual
machine what computations you want
performed or you just make declarations
about the result you don't care how
people actually compute that you simply
verify that it's correct and then you
need to arbitrate it on the blockchain
please talk to me after the presentation
I don't have enough time to to to
explain arbitration here but I think
it's really crucial and a really
interesting part of it the second
example is something like Dropbox
distributing Dropbox there's a huge
demand for that kind of stuff
it has a web app and a locally
synchronized folder the first one is
already in the works it's
I mean it's already usable it's just not
feature complete again here you have
concurrent changes but they're not not
typical when you're syncing between two
devices of yours or between a few users
and also there's gonna be a separate
talk about implementing something like
github in this distributed fashion so
the third example which would be a
distributed social network and the
fourth example a map or a encyclopedia
with no official truth so these things
they are pure vapor where now although
I'm aware of some teams that are working
on projects like this so maybe we will
see something like this in the not very
distant future so there are also ways of
doing doing things like this in a
distributed fashion
moreover doing it in a distributed
fashion in a Content address storage
actually opens up possibilities which
are plain impossible to do in the web
2.0 way so thank you for your time and
if you will have questions I will be
happy to answer them