[Music]
so uh subtitle here is vision and road
map however the slides will be more
somewhat Technical and maybe
philosophical um uh but the vision is um
is simple it's to create a protocol that
multiple applications can run over that
is encrypted and provides certain
guarantees
um and this has become more apparent
over this week that this is uh this is
an interest and it's in demand from uh
from many people so people who are
building daps um we we saw a few on
Monday uh and ethereum itself
so in in in turning complete flash
fashion uh we are doing a similar thing
with the network protocol and in that it
can be used for uh for more than what
for more than just ethereum so um a
little bit about me uh was born and
raised in Texas so um the yagy thing
that been pointed out we would say y'all
ain't going to need that um uh which is
important in networking uh because we
don't uh we don't want to put things on
a network that we don't need um it adds
complexity and uh and that's that's
that's not good um so before I started
programming I worked in uh in networking
at a strong interest in networking
network security um and uh uh helped
build internet service providers uh that
kind of thing got into programming uh
wrote helped write a C++ bit torrent
tracker that um that
uh was so bitor itself was controversial
um and and the reason that I I mentioned
this is because um it's it's a important
to remember that we're adding encryption
um here and this can this can be a
double-edged sword so our objective is
is to build what we need for for the
protocol um to have integrity and and
that includes encryption
um anything beyond that uh is is
um we would like any anything beyond
that to be able to be built on this
protocol uh if it's feasible something
else could come along that's better
there may be other protocols out there
uh uh already uh that they have the
potential to to facilitate this role
um so uh what what what we would like is
a multi-protocol uh peer-to-peer
protocol so right now if you use bit
torrent um the uh the peer Network that
you're connected to and the things that
you can do with that Network and those
code bases is to uh send and receive
files um and it's really efficient um
because of uh because of how it's done
so now if we want to allow multiple
protocols to use a similar peer-to-peer
Network um we're we're we're we're
starting to layer things and if you have
two layers um that's usually that's
usually not not too difficult to do
something just needs to be lighter than
the other different properties whatever
or you you know just go back and forth
it keeps it really simple um when we
want to start adding more layers to this
uh it gets really complicated um really
fast so uh with with the protocol um for
ethereum uh scalability efficiency and
usability are are really important uh if
if if if if the network is slow
um I I think we can all agree that that
that wouldn't be a good thing um faster
network uh that's not the goal that's
not the most important thing um
but between the two this helps with
robustness so the network can respond to
events faster um DHT tables uh can be
kept more up to dat so the general
status of the network um can be more
robust and and stable if if if it's
quick if it's efficient um
uh privacy um we'll uh talk a little bit
about privacy um later I think um to me
I think that um that encryption is is is
a form of
privacy um so so if we are encrypting
traffic we are automatically um adding
some form of
privacy so the internet as most
applications as most application
developers know it um is is is
pretty can be laid out simple
so uh a lot of Networks run on Ethernet
or perhaps they run a cell phone or ADSL
um these things um a lot of those so for
example DSL actually most DSL
connections use a form of ethernet um
Internet
Protocol uh TCP and and UDP so an
interesting thing about these protocols
is
um they have their own sort of uh form
of how you use the protocol so if you
want to build an application that uses
TCP there's a lot of things that are
going on in the background to to allow
that to work to begin with so if you
just took TCP and you put it on a on a
small network uh you're fine if you take
TCP uh IP and you put it on the internet
um with just the simplest uh ethernet IP
and you know tsp I it it won't really
there's a lot of problems um
so uh an important part uh also um each
of these well these two have address
resolution so ethernet has addresses and
we have address resolution protocol um
IP has addresses which um some kind
there's ways that you can uh that you
have Discovery so on
on the routing side of things uh we have
protocols that are used for
infrastructure um notably
NLS is is is on all of them so
um the interesting thing is is that a
lot of a lot of problems that uh large
peer-to-peer networks need to solve to
to be to be robust um are really
problems uh that
uh Engineers um uh working on uh keeping
the internet up uh they they are
problems that these Engineers are also
researching solutions
for so uh to give an example of this um
here's a diagram of a just a network
diagram from a like a test thing and um
uh it gets complex really quick um we
don't have cell phones in here um um uh
there there's there's a lot of things
going on with with the internet so this
isn't here but there could be a Sonet
ring here so that if one part of the
fiber gets cut everything uh just goes
the other direction around the ring um
so uh yeah
um
uh the diagram I have a hard time
reading it from behind
uh so this is uh this is an example of
different kinds of networks so um frame
relay switched um and then for for other
connectivity just imagine that every
single one of these connections is is a
different uh is a different way of the
connection routes messages differently
but yet they all get along on the
internet most of the time um so can can
I ask very silly question yeah like for
software developer like why do I I'm
going to get to that
okay so um so uh do we have do we have
Solutions um so considering privacy uh
as well as scalability of the internet
um there there's a lot there's a lot of
people working on this um IPv6
uh is
um um there's there's a part of IPv6
that tries to help with privacy
um now uh one interesting thing about
IPv6 is they are 128bit addresses so
they're not quite large enough for us
for to to to use um on a on a
peer-to-peer Network that that depends
on cryptographic properties uh for um uh
for shaping the network or for um peers
connecting and we'll get to that later
so uh recent issue um this is a blog
post from from an engineer at at MIT and
uh IPv6 has this really interesting
thing where everybody who actually gets
an who gets an address um doesn't get a
full address and they can generate their
own um private addresses just ad hoc out
of nowhere um and uh so it's kind of
like an ephemeral address but the
problem is is that uh routing
equipment relies on addresses that don't
change
um uh
because because it can do so quickly um
so if every computer in the world
changed its address um uh every 5
minutes uh it would be really really
difficult to scale that so that uh every
message can go from its source to its
destination um the amount of memory and
and processing power for uh core Network
equipment would uh would have to change
or algorithms have to change so um yes
so uh um if you're interested in IPv6 um
and
how how um there there is there is a
project that's trying to build on IPv6
um for privacy and encryption it's
called
cjdns um that's pretty cool if you want
to check that out
um so
so a lot of what I'm covering here is is
the internet as we know it today for
most application developers um so all
major browsers today should be using
TLS uh which is like version four of SSL
or something like that they they change
the name of it
um yeah so TLS is a protocol that run
that that runs on tcpip so it's similar
to http or IMAP or pop or um uh any
application protocol um except TLS is to
say well use TLS so start your
connection with with TLS and then it
will be encrypted and then just start
sending messages once you know that that
that it's encrypted so a few of the
things with with TLS is that TLS itself
um uh is is is is pretty good it's well
researched um the attacks against uh
against TLs are often edge cases and
rely on attacks on other um uh
cryptographic uh algorithms or the at
the end of the day U the issue is is the
implementation so um TLS used by
everyone uh today everybody uses uh root
certificate authorities um and and this
is centralized
um uh that that works for certain use
cases but ethereum is is decentralized
so the usability of TLS is is is also
somewhat of a black box because um if
you're a developer and um and you write
JavaScript uh web application or
something there's no way for your web
application to determine if it's running
on an encrypted connection or not um and
and if your web application wanted to
determine if it's running on an
encrypted connection it couldn't find
out um like who it's connected to over
this encrypted connection um the only
way that we could do this right now is
to actually
Implement TLS inside of TLS with
JavaScript or something which would just
be uh not fun um so on a on a on a more
um concerning level uh TLS most of its
problems have have had to do with
browsers implementing it and making it
really easy to downgrade the connection
and so um this has been used as a as an
attack Vector to basically when the
browser goes to connect con you
intercept a packet and you quickly get
the browser to connect with a lower uh
uh security so say 56-bit encryption
instead of um uh as or as and uh uh and
and downgrade the line
um uh and and implementations are really
geared towards running HTTP over it uh
not not other
protocols um so one last thing um
uh maybe maybe some of us here have seen
this slide before um and uh and and
again uh to your question I I I'll I'll
cover uh what this stuff is about and
why um so this is a a p this is an image
from a paper from researchers I think at
at Harvard and they're basically saying
okay you can use um net flow analysis to
figure out out what's going on uh with
tour um and the reason that I present
this is is because um so this isn't
necessarily a problem um but it's
something that uh that I guess you could
say uh Freedom Fighters and people
interested in privacy and freedom um uh
there's there's ongoing research here so
um how how do we actually have have
privacy like how can we send and receive
information over the internet and
there's no way for somebody to figure
out um what what is being uh sent and
and received um so what's important here
um is really not the attack or its tour
or anything like that um what's
important to know is that uh in data
centers all over the world there's
there's there's equipment for net net
flow analysis and what this does is this
equipment read reads every packet that
comes into the network um some of them
do this based on sampling so they'll
read 5% of every packet that comes onto
the network and extrapolate information
from that so the purpose of this
equipment is to help um is is to help
their Network they they don't install
this equipment to EAS drop on traffic or
figure out what people are doing they
they often times they install this
equipment because it helps uh figure out
where denial service attacks are coming
from so back back to the double-edged
sword thing there's a lot of cases um uh
where um where there's there's a balance
um and uh yeah so
um when uh when I started working on the
networking stuff
um G was like uh yeah so we're going to
run everything on this um uh no no press
um this is actually really really really
applicable um and I'll get to that in a
bit
uh
so yeah so uh the ethereum network
protocol uh as we have it today is um uh
ethereum relays transactions blashes and
BLX whisper messages and filters right
now uh presumably swarm will be content
hashes and content blocks um I'm
probably missing something here uh later
I expect that we're going to add things
like simple payment
verification um and uh and uh so right
now we also sort of have P2P here um and
all it does is uh exchange
peers um so each of these protocols sort
of has um
different requirements kind of um
so ethereum and swarm are both kind of
hybrid so um that's a typo uh um the
relaying of transactions is is fairly
important relaying of blocks that can be
that can be fairly important uh same
with relay hashes but the throughput of
relaying blocks is much higher than the
throughput uh of relaying transactions
naturally um so uh so if you wanted to
send uh 10 transactions down the line
and and and 10 blocks the 10 blocks are
always going to use uh more bandwidth
than the 10 transactions um now by the
way not not for sure it depends on the
size of the contract yeah if you have 10
10 empty blocks
yeah so so if you sampled 10,000 blocks
this is
true
okay um uh because the blocks contain
the transactions so blocks are actually
groups of yeah transactions um so uh it
it it could be argued that some of these
messages
need higher priority than than others
and what does high higher priority mean
on a network um that means that there's
lower latency the message gets there
faster than the others um
so
uh on to answering the question earlier
um about everything uh
with routing and privacy um uh we won't
be solving those problems with this
protocol um this this protocol is for a
stable robust Network protocol that's
encrypted and multiple applications are
are running over the protocol so um so
there won't be anything to do with
routing priorities um multicast or
broadcast right
now multicast and broadcast is written
in code so send to every peer and so uh
it's it's it's really it's unicast um
uh or the direction of the flow so um
some protocols similar to what will be
proposed as provide a mechanism such
that you can connect to something and
say um uh don't send me data I'm just
going to send you data uh or or they can
they can say the same thing are you okay
with me asking question from uh no wait
till the end yeah um
so some uh
yeah um so some good reading material
for all of this uh if if if you're
interested or you're working on similar
um uh similar uh similar systems um is
the uh the Speedy draft from Google uh
this blog post which is really recent
and does a great great job of describing
um uh Network buffering and and
what do you do when you have to send out
100 megabytes of messages and um and you
can only send out one megabyte um and
more in the context of of scalability
not necessarily a single application um
bit torent uh is is excellent
um the idea of uh bit torr is takes a
file and breaks it into a whole bunch of
piece pieces creates a uh Merkel um
Merkel root hash of it uh and then uses
that as to being able to hand out pieces
um and the way that um uh the way that's
done is is alol um for the DHD stuff
which which I won't cover um uh Amazon
Dynamo blog post and cadima um these are
both really good um the Amazon Dynamo is
just a great uh sort introduction
um so uh I couldn't come up with with a
name so it's it's it's called
RPX and um uh so it will provide an
encrypted line um multiplexing multiple
applications over the line um flow
control uh and then later uh constraints
peer Discovery and and peer
rating um each of these sort of fit with
privacy scalability efficiency or or
usability um and uh and and the
constraints this could say constraints
uh and metrics um which uh which is sort
of connected with the with the peer
rating system
um and uh I don't have I don't have
sides for that um but
that um so I can swear there was picture
or something here yeah okay um so in in
encryption is
uh the way that we're using encryption
is
um relatively new so last I don't know
five years there's there's other
projects that that are doing this um
we're not the only ones um but most of
the web right now is encrypted with TLS
and uh
uh and and we know how this works with
certificates and the server has a
certificate and they send it back and
forth and things like that so um what
we're doing is every node uh every
endpoint of the connection of a
connection if you want to call it that
um uh
is uh is generated via a public private
key pair and the address of the public
key is the address on the on the network
um
or uh yeah yeah
um so uh of course everything should
always be
encrypted um and uh and
authenticated um so I'll I'll get to the
authentication bit um but um so a lot of
protocols you
they they authentic they they
authenticate every packet or every
message um and uh and what's being
proposed here is to um is to have
authentication essentially out of band
from the application so the wir line is
doing
authentication um in fact this network
protocol is is authenticating the
traffic rather than rather than the the
cipher the Box Cipher um or the
application
itself um so uh there was an article
posted on Skype about um uh about using
crypto and I'm just going to read this
designers and implementers should
refrain from optimizing well studied
protocols to achieve some specific
application need unless they're prepared
to revisit and reevaluate the above
security proofs small small in
significant changes in protocols can
result in invalidating the guarantees of
such proofs um so a lot of factors in
here um in this paper were about uh or
about key sizes and and and parameters
um and uh this was released by
enisa um you you to link this paper
earlier um so with encryption we are not
changing in
parameters
um we are using the cryptographic prim
Primitives um as as they're expected to
be
used however we're com combining a few
things because we are multiplexing
application traffic over a cryptographic
channel so um so it's uh we're basically
changing the time in which we are
processing uh information uh about uh
authentication um uh it's it's streamed
um instead of coming up with some new
protocol or using uh using a self
authenticating block
Cipher
um
so
yeah so uh
encryption um the the first version of
proposed encryption protocol is uh is is
this so uh
the uh the implementation is that um I
want to connect to a peer so I need to
get their public IP address uh sorry
there yeah public IP uh port and public
key so um so I will always have the the
other uh the remote public key um they
might not have mine um and I I might get
it from the DHT I might get it from
another peer um or of course I already
knew uh I already know this this Beer's
public key
um
so when the connection is started the
first message that's sent by the by the
side that initiates the connection is uh
uh they using ECI they use the remotes
public key to encrypt um their address
concatenated by um a signature of of uh
of information
so um ethereum in general is relying on
our ability to recover public keys from
ecdsa signatures and so um what we're
doing here is we can extract we can
recover the public key from this
signature
so when the connection is started I'm
sending uh my public key encrypted with
their public key so this also means that
if I send this to the wrong person
they're not going to be able to decrypt
it
um and they won't know my address and
can you please explain the sign
brief um this this is uh signing with uh
with ecdsa
and uh the private the private key is
used to sign uh the the ticket or or the
non so the ticket is is essentially um
uh the previous uh based on the previous
session um uh and then concatenate a a
random uh value which is used um to do
uh um ephemeral Diffy helmet um
so th this part and and how this works
um this is this is similar to TLS um
we're just uh we're doing a lot of
things in one message and we're relying
on the fact that we know the other
side's public key uh with with web
browsers today um you have to connect
and find out what the public key is and
they have to tell you the public key um
and so we're not doing that as a part of
starting the connection um and then uh
this knot um the details of this knots
is in the is in the proposal and uh it
could move into the encrypted payload or
not um uh this needs to be reviewed
um uh as as to whether it's better to do
one way or the other and um uh uh I'm
I'm open at the end of uh afterwards of
getting together with anyone who's
interested in helping determine what the
best thing to do is because this
potentially changes um
uh has side effects based on where it's
at so what does that
non um it it's used it's used for uh
it's used
for um for changing for updating the
session so after every successful
connection
uh you you update the session and so um
when that is combined with using uh
ephemeral um uh public Keys
then if somebody steals your laptop or
they steal your server and they have
your private Keys um they could have
they could have packet logged everything
coming out of your server and they won't
be able to decrypt it
um so so that's a part of
that yeah
yeah um so can you just say again what
the nons ticket are
from uh they they are used as
uh in the in the
signature
that
uh yeah
the uh so so so the ticket is a value
that have stored from a previous session
from a previous
connection and and the not is because
there there is no value and so this this
uh um establishes a new value um
so this is similar to what's being done
with TLS um so TL TLS uses this for uh
for uh uh driving key material for the
shared secret um and and uh that's what
we're using that for as
well um as I said and and I want to
reiterate um the the the purpose here is
to create something that we can we can
use this needs to be uh reviewed um uh
because while
um while we're not doing anything that's
that's not by the book um there's
implications on how um on on how we use
this information to derive shared
Secrets um and to and to update them
so um so multiplexing uh is really
simple because we already have it um uh
right now the way that that uh that
we're doing it is um each sub protocol
has like 10 packets um and uh or or five
or whatever and and we're stacking those
into one um packet type and
then based on what's what what protocols
both connections agree on um uh is how
we determine which packet type is which
packet type uh when we receive it the um
I think the the networking guys are
familiar with this um and that that's
called adap message IDs and there's a
there's a weaky article page on this
actually it was last why you can well so
that's the question
marks um uh so so it's been proposed
that uh uh that uh that we go to a
system where we have a protocol type and
a packet type and it's just two values
in instead of instead of stacking one
um so whether we do that or not we have
to we have to get together we have to
decide maybe tomorrow and uh so but it's
it's a it's an implementation thing so I
think the idea behind the Adaptive
message was to to to make it harder for
filters to filter
us one of one doesn't give serious prote
in any sense yeah it's one of them but
okay I kind of like like it it wasart
yeah I mean I like it too um it uh who's
well well there are people that don't
like it I don't think that they that
they hate it um I'm I'm 5050 I I I like
both um but the Adaptive message idea I
think is was sort of a little
artistic yeah
ums bys it's very much like rlp so
yeah uh
maybe a style thing it's like to say hey
we have
SM um so flow control um uh so we're not
actually going to do this but I think
it's funny um uh that uh messages are on
the internet are obviously
information on a journey through space
and time
um uh
so what
what's interesting is these vehicles can
uh operate differently um when mixed
together in the same environment um and
with running multiple protocols over a
single line we we have a very similar
thing um in Berlin there's a lot of
cyclists um which is really interesting
because um I can ride my bicycle to this
office faster than I can drive a car
here um so
uh usually five minutes faster and it
takes 10 minutes to cycle here um
so um also uh applicable um buses planes
mass transportation are carrying a lot
of people from from point A to point B
um and uh it's it's uh in most cases
it's economical to to maximize
um how the vehicle are are built and and
and how they travel um flying around an
empty plane across the ocean uh is is is
not a good idea um and so uh for for the
same reason uh flow control um helps
ensure that the bandwidth that we have
available uh is is um uh is is used is
maximized um so one of the most similar
implementations to to this is
speedy um which is for uh HTTP over
TLS this should really maybe say
Google's data centers um instead of
Google Plex um
and I haven't read the latest draft but
prior drafts essentially the flow
control for Speedy is for Infinite Space
and Time um so my understanding of speed
is that you can have as many
applications or channels as as you want
and each channel does its own flow
control um uh which um that can work
really well in an environment where I
have a browser and my browser connects
using Speedy to a uh application server
running a
certificate which matches who I'm who
I'm talking to so in a peer-to-peer
Network we are connecting to peers and
uh and we don't know who they are
um so uh uh so uh where where this is
relevant is um that um it it might not
make sense uh for us to uh go this route
because what Google can do with this
under the under the assumption that of
how browsers are working is that Google
can optimize their systems from the
browser all the way to the source of the
to the multiple sources of data within
their own system so for Google Speedy is
multiplexing their entire operations
which uh which is mostly web
applications search and uh and Gmail and
Maps um and uh and and this works great
for them it also works good for browsers
because browsers are um you hit the page
it downloads and it's done and so the
goal of Speedy is that is is so that
that happens as fast as possible and
while the protocol itself allows for all
of these channels um a web browser when
you click and you open a page only has a
finite amount of of information and so
the web browser will only uh will only
um you know nothing out there is is is
going to uh really exploit that um so
with uh with with RPX we have the
ethereum protocol as as it is with just
a slight change on the packet type um
it's
encrypted uh and the the flow control is
is is simple um and uh
deterministic um so for the flow control
um what I want to do is uh is is is talk
about that with with the with the
Whiteboard um as sort of a part of the
the the
Q&A
um uh by the way uh how many people by
chance have read the Speedy white
paper okay cool okay
um
uh okay so how how does this work um uh
uh so um the application needs to send
data so it sends a message
um compression I'm
sure uh there's some questions on that
um uh uh header is is is added so these
three steps so the header may be first
um the the authentication is done uh uh
based on on the B stream not on the
messages um and so what we say is that
uh every 8 kilobytes we insert a Shaw 3
hash of of of of the
previous of the previous 8 kilobytes um
and then so our our overhead for
authenticating the traffic is is reduced
substantially and and in addition to
that um
uh it
it um it it operates on the same signal
that's used for the uh for for framing
um then uh then uh then encryp the bites
send it out um and uh and and we get out
the other
side
so why is FL control um
important
uh
so a
uh a network connection has a limited
bandwidth so in many cases network
connections have a fixed bandwidth um
ethernet uh ethernet typically does um
although uh to a single application you
don't know how much bandwidth is
available um it's it's it's it's an it's
an unknown factor that changes over time
and it can change
substantially um and and only the
operating system has control over this
um so when
when uh with
ethereum uh we we want to allow daps to
run over the same peer
protocol and
sometimes you have to make decisions um
so if if you have a network connection
that is only 1 megabit per second and
you need to send 10 megabytes um you're
going to have to you're going to have to
wait and if your application needs that
10 megabytes sent uh in a certain amount
of time um you need to you need to do
something about this um uh at least be
able to tell your application the data's
the data is not going to get there in
time
um more more importantly when you're
running multiple applications over over
one connection um we don't want one
application to be able to take up all
all of the bandwidth
um
so when when when the network connection
gets to the point to where it's full uh
you can't make the network connection
bigger um and in fact it's it's quite
likely that if the network connection
gets full um congestion actually goes up
and it's going to even get smaller and
and your choices are to drop drop the
packets that you're wanting to
send or um the the the other option is
to block the application from sending
more
packets
um in order to do this uh the
application our networking layer needs
more information about the con
connection because as is
um uh if if if if I want to relay 100
megabytes of blocks um I can I can tell
the OS to send 100 megabytes of blocks
um and and the OS might stop me at 2
megabytes or 4 megabytes or 16 megabytes
it's it's different different for every
operating system um so uh so we want to
employ a mechanism so that
um so that there's essentially a pipe
there's bandwidth for each subprotocol
that's that's running on the line and we
want to do so in a way that there's
enough information exchanged between the
two peers that they know when it's
overflowing
or we can also use this to know when uh
when there's more bandwidth available um
and if there's more bandwidth available
maybe we can use this for swarm maybe we
can use this for for something else um
that's not that's not a part of the
protocol uh right now because that's
that's an implementation
detail
um
so uh this is the Ros speec and um uh I
I this part was not in the um in the in
The Ether pad or or on GitHub this is
currently on on uh on on both and um and
and as can be seen uh it needs to be
cleaned up and formalized um and I think
it would be helpful to have some
diagrams um so that uh so that the
implementations uh are
similar so next
steps um in addition to to implementing
this um um is uh is peer Discovery
constraints um on the way that the flow
control system works um and and that
will imply guarantees and that will also
um that will also imply that uh we will
have some insight into into what's
happening on the network at scale when
we're doing uh testing and
simulations um uh and things like that
because we can we can we can log
we can log what's happening with flow
control and change some parameters and
then and then see what happens and so
essentially uh we can actually work over
over a long period of time to optimize
the throughput of the entire network to
optimize the throughput and the latency
of the of the entire network um and uh
and and uh what what RPX does is it just
says that
uh uh uh that that we have Framing and
and that there's information that the
peers will send uh Delta window updates
uh back back and forth with each other
um and then the peer rating
system um
which uh which is definitely an
implementation detail um that's not a
part of this um but it's a part of Li
P2P so that an an application that is
actually appear PE to-peer application
um and and depends on an exchange of
peer-to-peer
messages um uh can ensure that it's
connecting to to good peers for what it
needs um so maybe your needs are swarm
right now and you aren't Mining ethereum
and you don't need to download all of
the you know you're just doing
transactions and and swarm um because
you're using simple payment
verification
um and uh and so you'll want you'll want
good peers that that provide uh
responsive simple payment verification
and obviously uh however swarm works
that could be another protocol um or
another implementation but uh um yeah so
you're ratings okay
um that that that's it so e