I'm Danny Ryan I work with the etherion
foundation on the research team I do a
lot of work on e to specs research
coordination of client development and
all sorts of fun stuff today give you an
update on what's going on because
there's a lot going on it's kind of hard
to keep up with and hopefully also help
give you the lay of the land and also
help you become acquainted with some of
the fun and interesting talks that are
gonna happen over the next few days so a
lots going on but first I always like to
talk about the architecture of e to the
simple single blockchain of it there in
one so it's not very simple but a lot of
us have a good intuition for it and I
hope that we can carry a good model
mental model of the intuition of e -
moving forward so we divided production
in implementation of this in two phases
the initial phase phase zero called the
beacon chain is a pure proof of stake
blockchain that uses kasparov of G as
its core consensus and builds blocks has
validators and it has this loose tie to
the existing theorem one chain to handle
deposits there's a couple of rolls of
validators do on this chain they build
blocks but just as importantly if not
more importantly they attest to blocks
so every epoch or unit of time
validators are called upon to vote on
what they see is the head of the chain
to give weight to the fork choice and
don't allow a small minority of
proposers to take over the chain so
that's phase zero it is a simple proof
of stake chain it doesn't do that much
but it is the core infrastructure that
upon which we build additional phases
phase one we have the shard chains the
shard chains ask data and I'll talk
about that nuance in a second so instead
of just the beacon chain being built we
have these other shard chains being
built in parallel these shard chains are
also cross-linked back into the beacon
chain and when this happens it serves a
few purposes one it routes the fork
choice of the shard chain into the
beacon chain which should be
kind of canonical a canonical reference
it also serves these points of cross
links serve as the point for
asynchronous communication between shard
chains so with phase two we've take this
take the shard at infrastructure and we
actually add state and execution and a
layer one interpretation of shard chains
and data and I'll get in a little bit
more into what that means a little
further down the line
so in theorem two it's not that
complicated and the next phase part of
phase two would be to get rid of the
work chain role each one into eath to
which we can talk about a little bit
later so theorem two sometimes I think
about it abstractly it's kind of like a
concrete object that we're building in
an abstract void of space sometimes I
think about sometimes like these like
massive space habitats and this Stanford
torus is particularly apt because you
have this like core central component to
the space habitat that serves as the
infrastructure the energy generation
where light is refracted into the outer
torus which is where the actual people
live the user level activity and so to
build this thing sanely you can't just
like build the whole thing on earth
because it's too big you have to build
it in space and you obviously start is
this core system this core like central
infrastructure building it out until we
finally have paradise user activity so
those are the phases of v2 so what's
been going on with specs and research we
froze the spec July first phase zero of
the spec that is and today later today
we're doing a deep dive on this spec it
should be a good time I think it's an
hour workshop digging into that this
point really marks the transition
towards production for client and
implementation teams I finally gave them
something very stable to work towards
and and I'll give you an update on their
progress soon a lot of consensus tests
hand written tests that help us
make sure that clients come to consensus
with each other before we actually get
to production the networks shout out to
proto lambda he did a lot of work on
this and has saved us
huge huge headache debugging things on
instance on networks been a lot of work
on efficient merkel proofs we have these
pretty cool tree structure called simple
serialize tree hashing which allows us
to take generally objects and fit them
into Merkle trees and so we've been
working on how to efficiently make
proofs about these which will be
relevant to execution environment state
execution needs to and like clients and
all sorts of other cool things a lot of
works been going on to decentralize
staking pools this is kind of a
little-known component of the protocol
but all of the different things that a
validator must do their duties we've
been designing in a way that is
multi-party computation friendly and
there's a talk later today on that about
decentralized taking pools if this is
this is kind of a little-known area so
go to that talk check it out and and
some of y'all should probably start
building these multi-party all things
there's been a lot of academic analysis
audits and formal verification I want to
thank you on Zang who's been doing a lot
of work on formalizing Kasper F of G in
this new context of proof of stake a lot
of audits been going on and runtime
verifications been doing some great
formal verification work both in the
deposit contract and recently created a
model of the KB contain a formal model
in which we plan on verifying properties
of the protocol such as safety aliveness
and other other things there's a short
talk during the climate summit tomorrow
if you want to hear more about the KP
keychain networking spec out a lot of
love recently it kind of existed in just
a proto form until a few months ago
shout out to Nimbus lighthouse and
protocol labs remembers that those team
stepped up and helped drive this which
was critical to getting initial Interop
of our clients working and I do just
want a quick side Ghaleb p2p there's
been a lot of quite frankly food around
the p2p
weather
it's sudo a suitable choice and as teams
have been taking more ownership over
this over their domains of this project
and finally integrating them in we've
had a great success and are excited to
continue to use it
phase one speck Justin Drake's given
this thing a lot of love recently it's
now quite frankly pretty elegant mirrors
the phase zero specification a lot of
work on testing ironing out some of the
more nuanced details and exploring some
opportunities to maybe increase the
amount of cross-linking that happens to
help facilitate crush our communication
so something that's in the past six
months the lay of the land in the
direction of what we call phase two
which is that state and execution of
eath to has radically changed and
actually it's not state an execution
it's stateless execution KC from the e
azam team put out a post in April about
using kind of reframing how we think
about this highly scalable system so at
its core what e2 does is it solves data
availability and it's a date
availability engine that comes to
consensus on anywhere between like one
and ten megabytes of data per second and
so reframing the phase two conversation
around how we can more abstractly just
use this highly scalable data layer
instead of having to bake all of the
execution and things into layer one now
what does that actually mean state an
execution an eighth one this is very
limited view of over the world there but
in in consensus we have this strong
notion of state you assume when you're
processing a block that you have access
to all state and you also have a strong
embedded execution engine where we have
these formal and hard-coded rules and
notions of account and account model and
so your changes has transaction data and
execute using these rules upon that
state transitioning that state within
the consensus but in e2 we're moving to
a more abstracted model where instead of
having the heart could its
State execution rules and having the
entirety of state available within the
consensus removing to this abstracted
model which we call execution
environments or E's in which state the
the notion of state the notion of
account and the notion of execution upon
that can be defined in a more abstract
way and can be defined actually not in
the core consensus but at the user level
and so we have these at each of these is
an execution environment which is a
chunk of code wasum code which would
specify the rules of execution within
that realm within that domain and you
can actually deploy more of these the
actual model on the cost of either
burning or locking capitols deploy these
is still up for debate but it would be
expensive because you're deploying code
on this globally accessible thing called
the beacon chain and so where's the
state the state does not exist in the
consensus the state actually exists the
state that you need to operate blocks
which these blocks you know are a little
bit fatter than previous because now
instead of just transaction user level
data we have what we call witnesses
which are the components of state
required to operate on that block so
it's kind of like a the database and
proofs that that data is valid against
the state route and so when you update a
block you're actually not modifying the
state within the consensus you're just
updating the state route which is kind
of like the digests of the state you can
do a lot of really cool and interesting
things here and from my perspective and
what this allows us to do is instead of
us guessing what aetherium can or should
be in 20 30 years this allows us to like
naturally extend and upgrade and modify
execution as there's innovations on that
layer and the really nice thing is that
it gives us a clear trajectory and model
on how eath one can actually be slotted
into eath 2 and has given us more of a
concrete idea of how to handle
create and trajectory so eath one
actually can become one of these
execution environments where essentially
the EVM interpreter written as wasum can
become the exec code within this
execution environment and the state
route the existing current state route
within eath one would be forked in here
along with the ether balances there's a
lot of work going on on evaluating
evaluating stateless execution trying to
understand and capture the complexity of
each one as an ee and there's a there's
a workshop I think it's a couple of
walls and workshops in the last day
there's a fishbowl conversation about
all of this so check it out cool a lot
of work going on a light clients we have
a super light sync protocol on the order
overhead of Bitcoin SP been a lot of
work on incentivized servers Zolt is
giving a talk soon after this about that
starting now let's starts been digging
into it and there's a lot of le s work
that will inform he's to learn more
there's some talks the client journey a
lot has transpired in the past year
we've gone around son once and clients
have also gone from early legend
prototypes into what are beginning to
look like production grade systems the
journey was as you if you've been
following it was difficult for a while
because they were beginning to work as
we were still writing specifications but
as I said we've definitely moved into
that production engineering phase for
phase zero something particularly
exciting that happened recently was
interrupt Thank You Joseph DeLong and
consensus for putting this on at the
time when they came up with the idea I
was a little skeptical it sounded a
little bit crazy and I wasn't sure if it
was going to actually be a good use of
our time by day two we were quite
ecstatic about being all together and
getting things to Interop because we
were making incredible progress so I
think all seven clients that showed up
successfully interrupts I think that's
actually five of them right there and
parody Jasper which could not be in
attendance has also begun to work
through some of these exercises beyond
that
discussions on sink and ironing out
other cornets of the protocol fun little
side projects I think we had a test net
with 2000 validators on a few different
machines which was particularly exciting
so some initial load testing and this
was a fun one this is a couple raspberry
PI's on a small network with deacon
chains running on them mommy later today
I think on this stage is giving a talk
about the Raspberry Pi it should be a
pretty fun one it's about like the load
of eath - and the expected requirements
and actually getting it to run and build
on these small devices so what is coming
up for clients optimizations so one of
the I think probably the the most
obvious place for optimizations is first
BLS signature processing we process a
lot of signatures we have a lot of
validators and even though we can
aggregate these signatures that's still
a high source of load so we've seen
people begin to open up the BLS
implementations and optimize optimize
them seeing some gains order of
magnitude gains there what else the tree
hashing structure we have a lot of
hashing that goes on and if you do it
naively it takes an incredible amount of
load but fortunately much of the tree
doesn't change this is a lot of caching
optimizations going on stabilized we
need to bring these things towards
production stability and grade such that
they can run essentially forever
unstopped and usability eyes that's not
a word but the usability UX getting
these hands getting these things in the
hands of users and making them actual
products is instead of command-line
tools that someone that built them can
sophisticatedly use more usable and real
products there's good some people are
actually doing some independent work on
validator clients right now to actually
like make nice buoys and there's some
promising things in that respect this
guy right so we're also doing some
fuzzing efforts guido recently a while
built out kind of a core infrastructure
for handling differentials buzzing of
clients and recently mehdi from
lighthouse has taken over that
integrated a couple clients in and it's
figuring out how to randomly throw all
sorts of junk at these clients to see
that they all handle these crazy inputs
the same what this does is it takes we
have our consensus tests where all the
all the scenarios that we could think of
but fortunately with randomization we
can come up with all sorts scenarios
that we didn't think of and find the
edge cases before production so what's
next
as i mentioned we're moving we're in
that production phase we're removing
phase zero towards production a lot of
the conversation since Interop has been
about continued test nuts
so both private doing some private load
tests on clients but also opening up
towards public test nuts and incentivize
test nuts so keep your eyes peeled for
that if you're thinking about being a
validator this is your handi your chance
to get your hands dirty and be in an
active when these public test sets come
out be an active participant if it
doesn't work tell somebody if it's hard
to install file an issue like if you
have an idea for increasing the
usability either open up an issue
suggesting it or go and fix it so this
is definitely an exciting time this this
last mile getting these things to
production so be active and be engaged
with it phase one and two rd the specs
for phase one are coming i mean they're
they're they're in a place in which
people are prototyping props the quilt
team yesterday they did a demo of phase
one and a minimal phase two built on top
of lighthouse and beyond that a lot of
work going on just kind of refining this
idea of execution environments it's
quite a blind a large design space so
we're trying to hone that in the coming
months developer tooling and dialogue so
as Casey from wasman likes to say this
this needs to be a humanistic
humanist process a human focused process
the reason that aetherium is so great is
the developer's unity that we have out
here and so making sure that the
transition from eighth one to eath two
enables and enhances the experience of
developers is very important if this
goes according to plan
we can kind of rewire and rework some of
the interfaces and things the things
behind and underneath our current tools
and developer interfaces such that
developers can continue using the things
that they use to continue building on
ethereum and making it great here's a
quick glance at you to track i'm sure
you have it in your hat but there's a
quick view if you want it lots of fun
stuff putting it to to work that should
be fun checking out how we can use
finality on eighth one to enhance the
security all sorts of stuff check it out
I'll be at the phase zero deep dive
today we'll be digging into I know I
like we do this high-level thing where
we just show it all where I kind of go
through it very simply but we're gonna
dig into the different components and
help you read and understand the specs
today I want to highlight the two Oh
client summit which is tomorrow we have
a number of clients working on this
problem as you're aware and they're
going to be doing these like twelve to
fifteen minute talks discussing
different components of the design
different challenges at hand and after
that there'll be a panel talking about
upcoming tests nuts challenges etc it's
all I got for you today build in the
future thanks for having me
[Applause]
you