so welcome we are here to talk about in
Fuhrer how we're hooked on it and what
we're gonna do about it
my name is Jason Carver I work at the
ethereum foundation on all sorts of
Python tooling as well as the Trinity
Python client let's get started so why
are we hooked to in fear obviously it's
delicious it is an obvious thing for DAP
developers to make it as easy as
possible for new people to sign up and
use their app and similarly plugins like
meta masks
ignosi and so on or have the same
incentives right so in fury is a way to
skip the install of the node skip the
sinking of the node and get people on
board fairly obvious setup why that's
easier and more pleasant for a lot of
users and frankly for a lot of casual
users you know 80 to 90 percent of
people they're always gonna minimize
effort they're they're very willing to
make trade-offs about trust and
custodianship to to make it easy but
there is a set of users that were
interested in the sophisticated users
whether that's hobbyists or people
writing scripts to interact with the
chain and they're willing to do more
they're willing to put in some more
effort so the problem is when they try
that they go out and look for
documentation they look for help in the
apps and they don't find anything it's
all built for that 80% user and so they
just skip over it and and they often
don't have any trigger or later to
switch over to something different so
maybe that's okay you know how how bad
is that what how bigger problem is that
well you know there's some obvious ones
like concerns about downtime you know in
fear is gonna be a single point of
failure and no matter how good their
systems are and
they're very good perhaps the worst is
that in fear makes a bad hire or someone
cracks into their systems and they serve
you bad data now they can't explicitly
directly say send your funds from one
account to another or your assets but if
they can control the view of the world
you have it is pretty straightforward to
get you to send funds or assets to the
whatever address they choose for example
by resolving an ENS name to a different
address than the real main that one and
some other things like leaking private
data everything about who you are and
what you're doing is going out - - and
Fuhrer and the other Absalon way and
slightly more subtly the more the more
people the fewer people that are running
nodes the easier it is to spin up other
nodes and do slight manipulations like
eclipse attacks so it's here it's a
problem what are we gonna do about it
well there's a lot of different avenues
to approach this with and there is
dedicated hardware like DAP node or good
plus there's people looking at the
problem of how much storage it takes to
to use on your computer there's people
looking at peer discovery and the thing
that we've found to be one of the
biggest pain points is just the amount
of time that it takes to sink from a
fresh start you know these sophisticated
users who are willing to try something
out there hobbyist they like to tinker
but they'll start up a node and try to
sink it and two hours later have no
indication about how far they are into
that sink and say screw it flip it off
and go do something else that's more fun
to tinker with so we want to fix that
problem the the reigning speed champion
is guess fast sink that's the the one to
beat that's about four hours according
to their latest benchmarks so you know
even
is gonna be a problem for for these
users and so we want to take a look at
that and see how much better can we do
and part of the reason we're asking that
question is if we directly implement
fast sync we're gonna do a lot worse
because python is never gonna match or
beat go and a head-to-head performance
race so we zoom in too fast sync and we
say we look at what parts are taking
most of the time and the majority of
that is downloading state ok there's
things like downloading the headers
downloading receipts but downloading the
state of a recent block which includes
all the things like accounts and storage
for contracts that's the vast majority
so what are we gonna do it's time to
upgrade our sync process so this next
generation of sync we're calling beam
sync and the the ability it gives us is
go from an empty node no data to
executing a recent main net block in
minutes asterisk with just in time state
downloads that's the main concept behind
it so asterisk I don't want to lie to
you it takes longer than that right now
because you have to find peers and
that's unreasonably difficult right now
and header imports can take a while
unless you use a checkpoint which has
its own interesting side tracks we will
get back to those things but we're not
we're considering that out of scope for
beam synchrony so high level
how does beam sync work roughly we
combine the ideas of the way that fast
sync works and the way that stateless
clients work so stateless client gets
all the data I mean just the data it
means to run and block and it dumps it
at the end of the block fast sync is
about getting all of the data all up
front and save it to disk so instead
beam sync works by running
a VM on an empty state pulling the data
as it's needed but saving it and storing
it for future executions so what kind of
effect does that have well there are
about 375 million try notes in the main
that state database and there are
roughly three to four thousand try nodes
that are used per block so that's about
one one hundred thousandth of the amount
of data you need for just one block
versus for everything in the state and
this works out to about 250 times fewer
requests on the network before the first
block can run and we'll get into those
numbers a little bit more later so we
are approaching halfway through and
obviously only great blaze raced over
beam sync so I've got a talk or a post
here rather on medium that goes into a
bit more detail compares it to fasting
and all that so I'll give people a
second to grab that link and also I'm
gonna be posting further beam sync
updates as well as talking about how it
impacts the whole network over time so
feel free to follow up me there to find
out more and while people are getting
their last shot of that you may have
noticed kind of a discrepancy in the
numbers on the last slide if there's a
hundred thousandth of the data then why
is it only 250 times fewer requests
excellent question so fast sync gets to
batch together it's try node requests
into 340 no 384 nodes per request so
beam sync as implemented now can only
request a single node per request and
because the latency the actual time that
the packet is round-tripping between you
and your peer makes up the majority of
the time you lose a factor of 384 okay
so we're about to do a deep dive I'm
sorry for the folks that
I might lose it requires a little bit of
understanding about EVM and the way that
that tries work I'm not gonna have time
to get back out on it so I'm sorry for
everyone else I hope you have fun so
what I'm gonna do here is I'm going to
paint a big picture of kind of how it
works but I'm gonna put it on the slide
bit by bit so that we can kind of stitch
it together the understanding so the
idea here is we're going to jump into a
VM code execution this isn't the way it
really works but it it gets the point
across so let's say we have a push 20
opcode we're gonna push an address onto
the stack that doesn't take that didn't
require any state that was just in the
the byte code so even though our state
database is empty we can continue on
okay but the next opcode asks for the
balance of that address so now the VM
has to check the state database which is
empty and and try to extract that
balance now all we know at this point
all the node knows at this point is the
hash of the root of the Tri so that is
we're gonna call that F here a dot and
that's that's all we've got
so what are we gonna do how are we gonna
get the balance we're gonna find a
friendly Pierre and we'll ask it hey
Pierre do you know what the node is that
has the hash chef this command is the
exact same command that fast Inc uses
right so we're picking backing on this
we don't require any new network
protocols to make them sync happen so we
say Pierre give us can you give us F and
they say sure the node F has children
and B so what does that mean it means
that the hashes of the children of note
F are a and B you know I'm lying to a
little bit here pretending this is a
binary tree or other than a modified
Patricia Merkle tree still gets a point
across so we got a and B back and we
store it in my database
so here's what our local try it looks
like now we've got two children we don't
know what are inside them we have the
root now and what happens at this point
now we're looking for the balance of a
particular address and we know which
address we're looking for so we don't
have to fill out the whole tree we can
just follow the path to the address we
want so let's say the path takes us down
down a and so we want to know what the
children they are so we ask our peer hey
what's what are the children of a it
says the children are D and E we save
that into our database okay so now we're
starting to build just a few pieces that
are necessary to get at the balance of
the address that we care about and so we
do the same thing again where we know a
particular address that we're looking
for the balance for let's say it's down
you're meant to follow it down the path
to e and we ask our peer and they say
hey e is actually a leaf node it
contains the ROP of the account and
which includes things like the balance
that you're interested in so we save
that in in the state database so now
we've got three nodes in the state
database that's enough to not only know
the balance but prove that that balance
is part of the state route from the
previous block and so at this point we
can read the balance out of that leaf
node and push it onto the stack and
continue resume going down the EBM so
let's say you know the the byte code
wants to know if the balance was
non-empty so this is the gist of it you
can see you know later on it may be a
different balances asked for again you'd
be asking for nodes one by one you get
to skip the root node next time but you
know the same concept applies similarly
this is showing you know three layers
the real mean that's closer to six or
seven probably at this point depending
on you know where the accounts so how
long does that take
so let's say there are 3000 nodes per
block and we only get to request one
node in each request and we're connected
to peers but we can only ask one peer at
a time so we get to ask our best peer we
get the one that in this case best means
we're closest to that'll round-trip
fastest so let's say that our best peer
is 100 milliseconds away so you work
that all out you get 300 seconds of time
waiting for state for a block and that
kind of sounds like a problem you can
imagine if it takes five minutes to
download the state for a block then
you're gonna lag behind than that and
then as you process the next block
you're gonna lag further that would not
be tenable but the good news is we don't
have to wait for the first block to
finish before we start executing the
second one so what ends up happening is
you continue to run these all in
parallel and and you catch up along the
way but you know maybe stay perpetual in
five minutes behind main that in reality
it might look something more like
fluctuating between fifteen minutes
behind and one minute behind depending
on the blocks that you're running into
and your peers okay so at this point you
know you're a few minute you've turned
on your node you're five minutes in
maybe some more minutes for a pure
discovery and headers and you've got
main net blocks executing on your local
node this is already a way better
experience than four hours or sometimes
days to run fast sync but it's not good
enough so how can we do better one of
the things we can do is to find out from
our peers which nodes which try nodes
are going to be needed in a block right
so we're gonna call that the block
Witness metadata where the witness is
all the state needed to execute the
block and the metadata is just the
hashes of the state that's needed to
execute the block so
what that allows us to do is match up
the requests again into 384 nodes per
request and it allows us to spread those
requests across multiple Pierce so a
quick look this is going to look very
similar to the past one so we'll go
through a little bit faster of what that
might look like so push an address on to
the stack ask for its balance hit the
empty state database all we know is the
root hash find a peer to help us out and
now instead of asking for that root node
what we do is we get a witness really
I'd probably call it witness metadata or
something and we know which block we're
on of course so we can say hey Pierre
can you tell us which hashes we're gonna
need for block G you say sure we're
gonna need FA and E from last time so
you know at this point we actually can't
store anything in the database we just
have a bunch of keys we don't have any
key value pairs and in fact we don't
know how these stitch together all we
really know is F so at the root but we
can use it to now make the next requests
so we can match them together put them
in a single request we can send it to a
different peer we can send it to we can
split it up and send it to a bunch of
different peers we have a lot of options
and so we get back essentially all the
data that that was requested in the
previous slide so we know F has children
a and B a has children D and E and E is
the account ROP
so we save it into the database that's
enough we can look up and prove the
account balance and push it onto the
stack and then ask follow-up questions
like is that balance zero which is you
know a stateless call okay so how much
does that help us well let's run some
numbers so let's say again 3000 try
nodes per block rough number and but
this time we get to group it into 384 at
a time and you know we're again assuming
and this looks about right from
empirical test that most of the time
spent is latency
we get to group it up and we get to also
split it up so we get to send these
requests to let's say four different
peers at at once and now that we're
sending it to more than our best peer
you know maybe the average round-trip
time actually goes up you know that we
have to rely on some peers that are a
little further away and so maybe each
peer takes 500 milliseconds to
round-trip and so all of that throw it
into you know throw some arithmetic at
it and you get one second of time
waiting on try note requests so this is
a prediction all right the other one is
is known but this is a fairly
straightforward extension that we're
looking at that would be pretty much the
whole game right if you can download all
the state in one second for a block you
can keep up with me and that quite
easily from the beginning of launching
an empty node so how close are we
well v-0 is prototyped in Trinity alpha
the that works on main net right now so
we have executed many main networks over
and over and you know generated local
witnesses that kind of thing but it's
not production ready you know it's this
is meant for experimentation right now
but there's nothing left to research
there's no there's no open questions
really on on d0 and how it works just
more coding to do now the witness
metadata surveying is in its design
phase right so we have ideas about how
to do that that's gonna be coming up
next right after DEFCON you know follow
us to see how that progresses and people
sometimes ask the question well why
hasn't anyone done this before and the
answer is that no one had to you know we
were forced to do it because python is
slow so we had to ask these questions
there was a chicken in the egg
problem with why why we can't couldn't
use witnesses right away and v-0 because
there were no serve servers of those
witnesses and so Trinity can't serve
them until it sinks so we're gonna boot
strap with v-0 in order to sync v1 so
that's it we're we're doing this now
we're talking to other clients to get it
done for them it's a great thing about
working at the foundation is we get to
share all the fun toys that we make up
and we're we're cranking away so follow
us and see what's new it looks like we
don't have time for questions but you
can find me on the side or in the hall
I'm happy to talk thanks for your time
[Applause]
you