good morning my name is a hiker drop I
work at status on Nimbus which is a
client for eat theorem 1 and helium 2
client forestry resources take the
devices written in me and today we will
be talking about the etherium networking
spec how it evolved and what was the
various design rationales that I went to
into it so the person the major
difference between a theorem 1 and a
theorem 2 is that we are transitioning
to the p2p which is a protocol developed
by protocol labs for the purposes of
developing ipfs it might short out of
this project and I figured I should
start with few words why this transition
was made and why we decided to move to
the p2p and there are I would say two
major reasons not to most important
promises a flea p2p and the first one is
that it promises to take a theorem to
many new places where it wasn't quite
possible to use it before and the reason
this is possible because all
communication in the p2p is carried all
over this so-called the p2p streams
which in turns are layered over let's
call them physical connections which
could be an arbitrary network
connections that establish between two
nodes it could be a TCP link in a
classical case it could be some UDP
scheme like quick which will give us
very good censorship resistant in the
future it could be the WebSockets in the
browser
it could even be snail mail let's don't
forget the that protocol loves the
people who created the p2p they want the
system that would work on Mars so one of
the key features of Lippett appears that
it's not only option allowing these
streams to be multiplexed over a single
connection but a node in the network can
relay the connections for other nodes
and a single physical link can carry
many logical link between arbitrary
nodes and we call
this multi multiplexing in the lipid
Opie sense and it's easy with the manger
key enabler - for creating things like a
tea room light clans running in the
browser and the other significant reason
is gossip sub this framework in the p2p
for broadcasting data as we know a lot
of the traffic in a cryptocurrencies
network like aetherium it's about
broadcasting blocks and now with the
theorem to the majority of traffic is
actually broadcasting the ad stations
the other stations are the votes that
the participant in the proof of stake
consensus exchange with which is each
other these votes allow them to reach
finality and to cross link the state of
all the various charts including each
one so we know that from experience and
from just theoretical reasoning that
floods up the system where every message
reaches everybody in the network you see
and it's fully broadcasted on every step
just one scale to the scale that we want
to reach with the theorem but the p2p
comes with the significant cost it it
took quite a lot of convincing for the
teams to jump on shame because when you
look at the large list of components
that you have to implement it could be a
little bit intimidating the reference
code written in go is spread over
multiple repositories and it's bit hard
to make sense of it so we were many
teams were worried whether we'll be able
to make it on time but luckily the
limitation teams have rising to the
challenge and we now have the p2p
implementations written in go JavaScript
Russ Python Java in him and I've missed
at the
C++ one developed so far not for helium
two purposes but it exists as well and I
should mention that our own one there's
an enum it's a should be perfectly
usable and seen C++ projects in the
future and what's more important is that
during all this implementation are
currently at the stage where they can
talk to each other during the interrupt
walking we demonstrated networks where
all these clients were able to reach
consensus over the p2p but that's
obviously not the end of the road we
have a lot of work to do ahead of us and
the leap p2p spec that we created for a
tearoom - is actually divided in you can
say to treat two or more phases we
identified some initial targets some
initial minimal set of common
requirements that all the clans have to
implement you know in order to be able
to talk to each other but these are not
the underpinnings of a secure system for
launching maintenance we would be
changing a lot of the protocols to more
modern cryptography more modern way of
doing this we'll be adding new
transports and even this is not where
the road ends over time there will be a
lot of new high-level protocols defined
for things like light clans for the
communication within shards and so on so
just to give you an example here is a
comparison between this minimum winter
of spec and what we expect to do in form
a net in just few months we'll be
changing the encryption framework and
the keys that are used to indentify the
nodes will be switching to the supports
changing the SU protocol negotiation
scheme in the p2p and so on you are
introducing compression quite you can
say that the entire stack on every
single layer there will be new
developments
so in closing remarks
I would like to stress out that what we
are creating here would be very valuable
not just for a theorem like we're
creating this system of Oh between so
many programming languages now that
could serve as the foundation layer for
any kind of distributed applications in
the future and that's centralized
when we are ready it will be very easy
for many developers to just take over
the Shelf implementation of lipid to be
for their language and build something
amazing with it so the p2 is not just
for a tea room but material our effort
will make it much much stronger all
right so I figured the next part of the
talk we walk us through how do you
connect to the network like what are the
individual steps the first thing you
need is a discovery mechanism now I did
mention that the p2p is going to go
through further revolution with one area
where it didn't quite meet the needs of
a tea room right now was a discovery
since a tea room has been sober
absolving the discovery problem for a
while and we have identified some unique
requirements that we won't have in the
network the existing repeat fit
solutions for discovery didn't quite
meet them so instead we decided to unite
the efforts for a tea room one
development and here on to I need to
introduce a new discovery mechanism
called discovery five which will be used
in both networks so the key features
that are missing in the p2p at this
point is one first of all the capability
advertising this is where a known a node
can make sure that can be found on the
criteria that it supports a particular
protocol for example this could be a
note that supports the right client
protocol and it can act as a server and
the other feature is topic advertising
now this is more about that this node
has access to some resource for example
it could be the fact that the node is
currently connected to a party
shirt so you can sync the information on
this particular chart and you need to
find nodes which are already connected
to it and we didn't discover v5 there is
this general purpose mechanism of
attaching arbitrary data so it's both
extensible in the future for adding more
relevant information and it's quite easy
to adapt it to the needs of Lippe 2p
already so after we have found other
nodes on the network what we usually do
is we will start listening to the
broadcast the gossip sub traffic as I
mentioned and here I've listed the few
particular gossip gossip sub topics that
are relevant for kind of following the
progress on the beacon chain and we have
a topic where new blocks are produced we
have a other topic where all the other
stations are being sent and current in
interrupt we use a single topic for that
so that's enough to to monitor the whole
network but what we plan to do in the
future is to introduce separate topics
for each individual chart and then
you'll be able to choose like whether
you want to listen to the traffic for
finalized box or the traffic's for at
the station on a given chart and then
there are a few topics which are
beginning much slower amounts of traffic
these are just for announcing exits
where a validator once talk to the
network or for slashings when something
behaves badly okay
and now again here I would like to
stress out it if you have a lip p2p
implementation you don't have to write a
full-blown plant you can just implement
an SSD decoder and you can tune in to
the gossips of traffic and start
obtaining useful information all right
but now that after we have connected the
p2p goes through a process where it
negotiates the protocols that
can use and to exchange messages with
the other clans we call this request
response kind of the domain of the spec
and it so far it involves only few
requests which are important for syncing
the beacon chain and but before you
start with this when you connect to
another node you start by exchanging
your status information with this node
and the status information includes four
bytes in the NT fire which is kind of
acts as a marker for the particular
software version you are using for
example you can imagine if there was a
hard fork in these four bytes will be
modified in a way to indicate that you
are now following different rules and
you can also be on a different network
you can be on a test net and this again
will be written in this form right in
the end fire and the other piece
information that this exchange is what
is the finalized route actually
currently working on and what is your
headlock and obviously this is important
because it allows the class to determine
who should be thinking information who
is right I have much quicker all right
the next request is after the status
message tells you whether you have to
sync so the next request is your request
box by given range and you usually do
this when you are quite a bit behind
it's intended for historic blocks and
it's optimized in a way that the clients
will be able to implement cold storage
of the beacon chain you have database
with random access and the range queries
are supposed to hit only this database
of cold storage for historic works we
also have a way to request recent blocks
which is you request them by their hash
what you would usually do is you connect
to the network you start listening to
the other stations you notice that
certain blocks for example the
attestation is referencing a block that
you are missing so you will request in
the missing ones and this is a little
bit like thinking backwards instead of
forward all right I'll just then finish
with
[Music]
hearing the anti I've left some links
for anyone who wants to dig deeper in
this respect that I have discussed and
thank you
[Applause]
you