okay hello everyone I hope you're all
really excited to hear the latest news
about the light client well the good
news is that it's already in public beta
testing stage we are behaving it's being
prepared for the official release if you
would like to try it I will show the
necessary links at the end of my
presentation yeah if you haven't tried
it yet the first thing you will notice
is that it syncs absolutely fast this is
of course mainly because it doesn't have
to process state transitions just
download and Jack headers processing
headers is a lot faster than processing
entire blocks our current implementation
can process up to five to ten thousand
headers per second on a good desktop
computer to improve sinking even further
it is possible to start sinking from a
trusted checkpoint which is represented
by the root of a mercury containing all
previous block hashes it's called a
canonical history this structure also
allows to access all the headers that
hasn't been downloaded during initial
sync which could be useful for searching
for old logs or accessing all
transactions currently there is such a
checkpoint hard-coded into into the
client but in the future if we can make
this these checkpoints or some
equivalent information a part of the
consensus then it will be possible to
obtain these checkpoints from the
servers in a safe and trust this way in
addition to a fast thinking another
important to feature of the light client
is that it has generally low resource
requirements since everything can be
flashed on demand the database basically
acts like a cash it can be kept really
small memory requirements are also
significantly lower than with a good foo
node mainly because we don't have to
process entire
it this aspect of the get implementation
can be improved even further and still
it provides an aqueous interface that is
compatible with the existing phone or
the interface it's not perfect yet but
it's it can already work with mist
hopefully tomorrow you will also see a
nice missed demo using the lifeline by
Alex several people have already
successfully tested in on smaller
devices to this picture is from Martin
Brooks syncing with an int'l Addison and
this screenshot is from a Raspberry Pi
using running mr. using the light client
got to see of John Gary's who by the way
also donated a lie server to help the
public testing and like other community
members provided a lot of useful
feedback during testing he in addition
to basic protocol functionality another
important question is whether all of
this can work in a large scale with good
performance the basic client strategy is
simple it always tries to have a few
active server connections selected
randomly from a suitable pair set
whenever one of them seems slow or
unresponsive it drops it and looks for
another one servers they can take care
of themselves by limiting the bandwidth
spent benefit of clients and dropping
also dropping them if necessary mmm they
so they limit the time and resources
spent on on on serving serving clients
for limiting client bandwidth oh we
needed some smarter mechanism than
simply delaying request replies because
that would ruin the user experience of
the client which depends heavily on so
it quick survey responses this is why we
created client side for control which is
a simple feedback mechanism
Thank that can tell clients when they
can send the next request so that the
client can better distribute their
requests among the few server
connections they have if they send a
crust too early they would get the
immediately disconnected they shouldn't
do that but these strict rules have the
advantage that requests never get queued
up on the server side and therefore they
can be answered immediately this
mechanism can ensure a good distribution
of server load throughout the entire
network but we also need some market
forces to incentivize the running of
good servers in theory micropayment is
the ideal way to incentivize high
quality service and responsible use of
resources but on the other hand which we
should also take into consideration that
the requiring payment for all Elias
requests would seriously hinder the
adoption of the protocol and also a
limit its usefulness you couldn't even
sync up to make your first payment using
a lifeline and then so another important
question is whether it is possible to
create a an ecosystem we're both free
and paid services have their place and
purpose fortunately I believe the answer
is yes with a service like this demand
changes very rapidly while the available
server capacity is a change is
relatively slowly so if you want to
provide high quality service you have to
have a lot of reserve capacity and you
easily get a low utilization ratio which
means of course that the servers can is
sad the remaining capacity at a lower
priority and a lower price so basically
our model is that clients are buying
priority from the servers and on the
lowest possible priority level if the
service still have some free capacity
they can basically give it away for free
which of course still wouldn't insure
that they actually do this but we
angry at the service model and they will
have a natural incentive to do so
pre-service is a good indicator of
reserve capacities which are necessary
for providing a high quality service
that is actually it is actually worth
paying for so in our model pre-service
can act as an as an advertisement and
also as I protection against the scam
for clients so so the it can protect
them from for from paying for and then
getting those service in return so the
basic client strategy should be that
even if you are willing to pay for
services if if you find a new server
through peer discovery first you always
evaluate it for free collectors and
statistics about availability and
average delays and then if the
statistics I'll acceptable then you can
start paying for it and I wanted to talk
about the new discovery protocol we're
working on unfortunately there's no time
for many details it's a new feature is
an advertisement in a feature where
nodes can advertise their capabilities
they can a big multiple category
identifier or so-called topics and
advertise them under under these
categories and of course they can also
look for notes who advertise themselves
under certain topics of course one of
such topics will be light server and
finally I would quickly like to talk
about one of my future development plans
which could greatly enhance the
performance and reflective respective
flexibility of the light protocol by
allowing clients to run complex
operations on the server side in theory
basically a suckfest can provide any
information a client needs but if they
want to evaluate something more complex
like and a contract the accessor
function that accesses 8,000 state
entries that would also mean
a thousand consecutive arias requests
which would take a very long time
usually evaluating complex data
structures on server side could be
orders of magnitude faster and I don't
only want to evaluate contact mashup of
contract functions I would like to
create a universal virtual machine that
can access anything anything from the
block chain including block headers
transactions receipts logs everything
and allow clients to run any code in
such a virtual machine on server side so
that basically they can ask any question
about the blockchain that a foo not can
possibly answer of course if we are
running code on the server side we have
to make sure that the client can somehow
know that they are getting the correct
answer and there are two possible
approaches to achieve this and I would
like to make both of these options
available for clients to choose
according to their priorities one of
such one of these approaches is a that
when a certain in the server runs a
virtual machine code it collects all the
data it accesses and creates more proofs
for all of them and returns this proves
to the client so that client can with
one request and one imply the client can
rerun the entire function and have other
data available another approach might be
useful than processing large amounts of
data and it's a more generalized option
computing approach very much like what a
crystal was talking about yesterday
basically it's about server signing
statements saying that I guarantee that
running this function with this block
chain as an input returns in this many
clock cycles with these results the
client can
ask multiple randomly selected servers
to answer the same question evaluate the
same function hopefully all of them were
returned the same and then the client
can believe it in the unlikely case when
they return different results of course
at least one of them will be false and
the client should post the statements to
a judge contract which can which will
then request the intermediate states of
off of this vm execution from the from
the signing parties until it finds the
one single instruction that has been
executed differently and punish that one
which has been lying by taking away a
security deposit this both of these
approaches have their advantages and
disadvantages but whichever one the
clients are choosing this remote virtual
machine execution he will basically be
the ultimate flexible Elias request
which can minimum emission minimalize
any gap between the capabilities of full
and light plants which I believe will
bring us closer to realizing our
original vision we had with athyrium so
we already and thank you for your
attention and if you as I promised here
are some links there's a gator channel
you that I am / 18 / light client and
this is the main forum of the where you
can follow the developments you can ask
questions and whatever news I have I
always posted there and there's also a
wiki page with with with the
instructions for two to try the current
beta version so please please stay tuned
for much development in the near future
I was so
lot of documentation is coming soon
because another good news is that now
both parity and C++ wants to implement
the light protocol so of course we have
to improve specifications better because
so far I have concentrated mostly on on
code thank you