[Music]
I've been working on the like client
implementation and in this presentation
I would like to talk about how far we
have already progressed with that and
also uh discuss the uh future uh ways of
uh development concerning scalability
security and
decentralization I am proud to announce
that we already have a proof of concept
implementation of the light client
protocol as many of you probably already
know a the purpose of a light client is
to Pro provide safe access to the
ethereum network without having to uh
download and process every block and uh
keep and update an entire copy of the
state
locally uh for all these purposes we
have developed the uh last
protocol
uh it's a the there's a topology shown
on in the slide uh which shows that uh
uh just the blue diamonds who represent
traditional full notes and the green
diamonds who are light notes connecting
to them and
uh and uh the green light notes are
downloading only block headers as each
new block appears in the blockchain
which is a uh lot less Network traffic
uh than downloading entire blocks and uh
they only uh download uh block and state
data uh as it is required by uh the
applications uh this so This protocol is
for for for on demand retal and block
and state data and uh also uh it can uh
relay transactions to the E consensus
Network because the L network is uh
somewhat separated from the from from
the consensus network uh the full nodes
definitely support both e and less
protocol serving the light nodes and the
light notes are only communicating with
with the uh last
protocol uh this structure is uh working
and it is uh uh quite efficient at a
with a low number of light nodes but uh
as the network grows we we will come
into scalability and centralization
issues because as you can see in the
picture uh light not currently can only
connect to full noes and uh uh this is
also both a performance uh battl neck
and uh after some time even uh a can be
a security uh
issue so
uh it would be beneficial if we uh
consider consider uh serving serving
light the service that if uh light notes
could become uh providers of the service
too
uh if we are talking about
centralization problems in the context
of a light client uh we have to address
two important questions one of them is
the concern of security uh how can we uh
trust our headers because uh the light
cents work in a way that uh for the
patri structure ensures that if we
download
any block of State data we can check its
validity by uh by checking a mer proof
and uh and uh checking it against the
root hashes found in the block headers
so if we have correct headers we have a
secure access to the network but as we
are not processing light noes are not
processing the blocks they cannot
directly check the validity of the
headers so we definitely need some
security uh measures to prevent
attacks uh one obvious way is uh
checking the proof of work and later
proof of stake found in the block
headers uh which makes it harder and
more expensive to forge false blocks or
headers uh proof of stake will
definitely uh provide a better level of
security in this aspect but uh proof of
work will also be sufficient even uh and
if we can also incre increase its
security if we de demand a few
confirmations before we accept each
other we can also increase security by
fetching headers from multiple peers
preferably randomly selected peers and
only accept headers as part of the
canonical chain when we have received
them from the majority of of our peers
the other question brings us to the main
topic of my presentation the efficient
uh distribution uh of uh the blockchain
the block and state
data uh and
the the uh general idea about this was
originally that uh uh the light no
should collectively run a DHT Service uh
either swarm or
ipfs or whatever and uh and and store
the state data in the
DHD uh this approach is demonstrated on
this next
slide where uh one node shown on the
left tries to uh do a uh uh State
retrial he wants to retrieve a key
starting with B4 F3 whatever ever uh he
once needs to retrieve the the state TR
node take the hash from the element B of
the of the node and then use it as a
hash and retrieve that node and uh
sequentially retrieve retrieve try noes
until it finds the final node which is
the value it is looking for uh there are
lot of other light notes shown on this
picture because if we are putting the
state on DHT
well dhts use some uh most dhts use a
the So-Cal cadamia structure which is a
great and efficient DHD topology both
swarm and ipfs use it and uh uh it uh
requires uh uh uh nodes uh to access a
few intermediate other nodes before
before finding the node that can serve
the data they are looking for they are
getting closer to the looking uh the
address they are looking for and even
closer and even closer after some time
they're finding the data so uh this DHD
approach is great it has one minor uh
drawback that uh ad DH look up is not
not particularly fast I don't want to
give any estimates of how fast it is but
uh it it takes some time and uh it is
usually not a problem with a general
purpose data storage application where
we if you are looking for lot of small
pieces of data you can usually do that
lookups uh those lookups in parallel but
this is not the case with the tri lookup
because you only get to know the hashes
sequentially so uh a state lookup could
uh take pretty long
uh well uh so uh to address this problem
uh let me present a an an alternative uh
approach which is a which is quite
similar to the DHD approach actually and
it can use much most of the mostly the
same same code base is just a slight
modification but a great Improvement in
efficiency
see so uh while in a DHT uh nodes each
node is assigned a range of hashes and
stores data whose hash falls into into
that range we can uh modify this
approach to be more uh State try
specific and uh assign each node a range
of the state Keys State addresses so uh
basically each Pier uh would uh
store and constantly observe and update
a slice of the state basically
technically few adjacent sub trees which
is uh quite uh efficient in terms of
storage and updating
uh and the advantage of this approach uh
is uh pretty obvious because these notes
can be organized in a cadamia table the
same way the DHD notes can be organized
basically with the same code same same
implementation and uh it it only takes
one uh one Global lookup which is
expensive to uh to find a node who can
serve us an entire mercur proof which is
basically uh all the nodes starting from
the state route up to the value node
this uh this picture shows uh two such
nodes uh uh one of them is observing the
KE range which is B4 C to b4f the other
one is observing the right one is
observing uh B e0 to B E7
prefixes and this next slide shows how
this approach actually works would work
uh each uh each node uh uh as as new
blocks blocks appear in the canonical
chain each uh each peer can uh update
their part of the part of the try from a
node who is observing the same or larger
uh key range uh and in this uh aspect
full nodes are uh are are nodes who are
observing the entire entire state of
course but even light notes can choose
to observe the uh the entire state but
not process blocks just downlo states
there is a a big advantage of this this
approach in addition to increased
performance
uh which is the fact that uh if you are
updating your try downloading the new TR
noes that the uh that exist in the new
version of the state in that uh slice of
the triy uh you can exactly know when
you have red all those uh all those
nodes uh this is basically similar to uh
checking downloading and checking a
Merle proof it's just uh works for an
entire range of keys an entire sub tree
but it can be similarly checked against
the state rout found in the block header
this is big this is a big Advantage
because uh this way uh we can easily uh
measure the equality of the service if
we consider serving uh either sub trees
or individual keys which is well which
is a service and which eventually uh no
will be paying
for then it is uh it is very beneficial
if he can exactly measure its uh it's
it's uh this the value of the service
the quality of the service and this is
uh especially beneficial for smaller
ndes uh because uh uh if they are
choosing uh a key range that is not yet
so heavily served they can provide a
service that that is just as valuable as
the service of the full notes of course
with a smaller volume
and
uh uh I so far I have only talked about
uh the uh distribution and storage of
the state and we we also have to uh uh
made make the the the the actual
blockchain accessible which uh includes
the uh transactions and the receipts
belonging to those transactions for each
block this is a much easier problem than
Distributing the state for this the the
uh the traditional DH approach is just
as efficient as as any but uh maybe if
we we we uh we already have uh have
peers uh who are who who have ranges
assigned to them uh it it is it might be
beneficial to store every transaction
and especially rece it uh by uh referenc
by the block block hash of the block
they are belonging to because uh if we
are uh uh processing logs yeah SL cents
definitely need to process logs
efficiently uh then then log processing
consists of checking Bloom filters and
if we are uh finding a positive match we
have to download all the receipts
belonging to a to a block so uh storing
storing the the the receips belonging to
one block at one place might be a good
idea uh
and it is also uh worth mentioning that
uh uh the relaying of transaction
transactions uh can be uh how how how we
how we should approach this problem in a
network where we have a lot of light
nodes uh if we have much more light noes
than full nodes which will hopefully be
the case in a healthy network uh we can
um we we will probably have to propagate
every new transaction to the Network
through multiple multiple light nodes uh
because most of them won't have direct
access to a full node and if we do that
it it would be beneficial to demand that
every new transaction is propagated uh
through the peers whose address ranges
include the account that has signed the
actual transaction the uh it is it is
very useful because this way every every
propagating every forwarding peer can
check the validity of the
transaction uh because they have
information about the account that has
signed it and the checking the validity
mostly consists of checking the
available uh funds uh of the the signer
and uh and the transaction nors so if
every propagating light note
can uh uh both check the account
balances and nones and also do some
filtering and ordering by the gas price
of the uh by the transaction Creator uh
this this forms a very effective spam
protection for the from the consensus
network uh by only forwarding
transactions to the main Network which
will probably be actually included in
the in the canonical
chain and uh finally to uh conclude my
uh
presentation uh I would like to to uh uh
talk about our future B uh give a quick
road map of uh of of of of of the future
developments as I currently see it we
have planned several stages of release
uh the first stage uh which is which
should hopefully be ready pretty pretty
pretty soon uh may be released in our
next version of the go etherum client we
already be able to uh retrieve data on
demand to the first version of the last
protocol uh right now only from from
Full nodes and probably also be able to
relay
transactions uh this will be a more or
less usable light client but uh full
functionality will be reached at stage
two which will also be able to process
and filter logs and uh probably the uh
multi sampling header retal will also be
included which is what I talked about
before uh fetching headers from multiple
PS to increase
security uh this release will uh still
have uh uh will still have
centralization issues with very great
networks but for for the time coming I
think it will be it will be quite
sufficient and uh in the subsequent
stages of uh development uh we should
definitely address the scalability
issues uh it is uh it will still it
should still be up for discussion
whether we try to go with the regular
traditional DHT approach or the uh uh
State splitting by by by state Keys
approach whatever we have to we have to
uh develop a distributed service which
all which which also includes a simple
microp payment system and for this
purpose we can probably use the So-Cal
swap protocol swarm counting protocol
which is a a very simple but very useful
uh uh useful uh kind of payment Channel
implementation that is used by swarm and
uh we can also use it for for like
client
services and uh by uh when when the uh
development of developments of the proof
of State consensus protocol uh Advance
we can also uh uh employ those
mechanisms uh so basically porting the
light client to proof of sake will
provide a much better protection against
uh uh against fraudulent nodes and the
Cil attacks basically it works as a
reputation system because nodes with a
stake that they can lose by trying to
attack it it it it it gives them some
kind of reputation and definitely makes
attempted attacks more
expensive so by the time uh uh we we
will reach the point we can switch over
to the proof of the consensus consensus
protocol uh we will hopefully also have
a massively scalable
and and secure light client Network too
and I think this is all I could tell you
about this these uh developments in 20
minutes so thank you for your attention
[Applause]
[Music]