[Music]
hi everyone uh I'm Francesco I'm a
researcher at EF and I'm here to talk to
you about uh making ethereum finalized
faster and how this relates to the
future of staking to potential staking
changes to to come um so first of all
let's let's recap what are we actually
trying to achieve with single SL
finality or generally faster finality um
there's actually one goal is faster
finality in itself so we we don't want
to have a ux and security trade-off
you're not supposed to need to uh choose
between um waiting for finality or um
and and getting higher security or
accepting something confirmation faster
but at lower security and uh this is
also not just for regular users but but
for uh rollups uh whose interrupt speed
is essentially bottlenecked by the
finality time on L1 but this is not the
only motivation actually for a faster
finality road map uh one reason is also
just to improve the consensus protocol
that we have and kind of fix some uh
essentially security uh problems that
that exist in it not really uh you know
critical security problems were more um
B basically going from uh the the
current security proper that we have
which are suboptimal to really like
Optimal like provable security
properties and uh yeah one question that
should come to you is why don't we just
do it immediately and the main reason
why we can't uh in the in the short term
is that we just have way too many
validators we have 1 million plus valid
validators I think it's almost like uh
another 100,000 on top of that it's just
way too many to just consistently
aggregate in each slot uh and it's yeah
this essentially is a lot of
verification time for the signature and
a lot of bandwidth to propagate them um
the thing is we don't actually have 1
million validators we have maybe 10,000
nodes it's the exact number is not clear
but something on that order magnitude
and we we already know that we can
handle more than that per slot uh so we
already have Committees of around 30,000
validators per slot so that load we know
we can deal with um oh sorry um yeah so
one thing that that's coming up that's
going to help us is Max CB the ability
for validators to have up to 248 e uh
and to allow for
consolidation and but okay so we have
Max CB in the in the next Fork what else
do we need so first of all we need a a
protocol that actually is like Fast
finalizing and still has all of the
properties that that we want which is
are are many and we have like a quite
unique uh sort of model that we operate
in and then the other thing that we need
is is uh validator set capping so we
don't want to um let's say go from 1
million validators to 30,000 then we are
comfortable that we can handle this load
we turn on uh single s finality or
faster finality and then we round trip
all the way back to 1 million validators
because you know more uh small uh
stakers come in or deconsolidate or
something like that and we're back to
square one and the system actually
breaks and um yeah the first part of of
this just the consensus protocol part we
actually have a lot of progress in
already there's been a lot of work in
the last two years and we essentially
have protocols that we're quite happy
with in in theory uh the second part
it's it's a bit fresher area but I'll
essentially talk to you uh about both
parts in in the rest of the talk so with
the the first part uh I'll focus on a
specific protocol which uh We've call
three slot finality so yeah single slot
finality is a bit of a meme it doesn't
necessarily mean single slot it really
just means like we want to have faster
finality and yeah so what is uh what
does roughly this three slot finality
protocol look like it's more or less
much like the current protocol we really
reusing a lot of the same at least like
conceptual components so it still has a
um what we call a dynamically available
component which is essentially like a
lmy ghost which is what we have today um
and this is the part that's supposed to
keep working even if we cannot finalize
for essentially extra resilience and
then we also have Casper 5G uh this
finality Gadget that eventually gives us
Economic Security as long as two3 of the
de validator set is online and the other
another component that's that's quite
different from today is that um well
first of all we we would be able to
finalize fast but specifically we would
be able to finalize in three slots with
finality being pipelined so that uh you
know you don't need you need multiple
voting rounds for finality but these
would be essentially pipeline over uh
multiple slots and so that we can still
have blocks coming in in between these
rounds uh so yeah this this is what it
would look like uh we have a first slot
a block comes in just like today we have
a first round of votes um at first uh
you know votes just like today have
three components a source a Target which
are Casper 5G Concepts and a head which
just says this is the thing that I uh
beli to be the head of the chain um at
first we would only care about the this
head vote which would be for B in the
ideal case then we would move on to the
next slot new block comes in B Prime uh
now the head the head vote would be for
B Prime so we've moved on to to this
next block the target vote would now be
for the checkpoint BT so you know just
like today we have this concept of check
points that are essentially uh blocks
and EPO for for Casper 5G and these are
the objects that we essentially do
finality over here we would have these
like block slot checkpoints uh so a vote
for BT as a Target would essentially be
trying to say I think that b is ready to
be finalized uh or to be to enter the
finality pipeline essentially uh then we
move on to the next slot uh we get a b
double Prime again this gets a head vote
uh now the the target is the one from
the previous slot so B Prime t+1 and
then the source is BT so now this Source
vote is essentially saying I know that b
Prime uh sorry that b is Justified and
is ready to actually be finalized and
we're kind of getting to the end of the
finality pipeline for B but as you can
see the there's three things kind of
going on at once uh the the you know B
is enters the finality pipeline at the
beginning then B Prime enters in the in
the middle slot and then b double Prime
so all of them are in kind of different
stages of the finality Pipeline and you
can that's reflected by the kinds of
votes that they receive uh and yeah
essentially the the this pipeline for B
would look like this in already after
the first round of voting we could
confirm it at this point we have no
Economic Security but we already have
very strong guarantee that it's not
going to be reorg after the second round
of voting once we've gotten these Target
votes uh b b would be um Justified and
after the third round of voting after we
gotten all of the source votes it would
be
finalized and yeah actually we don't
even need to think about the blocks you
know B Prime and B Double Prime existing
in the middle we could also just focus
about the votes that are relevant to to
be so the head vote the target vote and
the source vote if you really just want
to focus on uh the essentially the
finality pipeline uh for B specifically
and even you know if uh B Prime uh b
double Prime like these other blocks in
the subsequent slots were to be missed
for example the proposer does not show
up uh the protocol actually guarantees
that B can still complete its pipeline
essentially that like no matter what if
the uh proposer of uh slot T is honest
in in uh you know the way it creates B
and sends it in a in a timely manner
then B will successfully go through this
whole Pipeline and be
finalized and yeah I didn't you know go
into more details of why this is the
case but you you can check out the paper
or blog post for that and uh now this is
the um there's this other part to to
this whole discussion which is uh the
one that's a bit less uh understood like
more kind of earlier research which is
validator capping uh so the problem of
making sure that uh we we um always
maintain a kind of constant load that we
know how to handle and we don't you know
do this roundt tripping of reducing the
validator set through consolidation and
then going back up to like a
unsustainable uh validator set
essentially and in specifically I'll
focus on a quite recent idea called
orbit that's one way one point inter
trate of space of how to handle this
problem but I'll try to also introduce
the the problem in general um so this is
from balic uh lat one of vitalic many uh
latest posts on the future of the
protocol in particular the the one from
the uh about the merge so um you can
kind of see essentially this spectrum of
possible ways to to handle this problem
uh on the right all the way on the right
you have this tender style kind of a
small validator Set uh you know maybe a
few hundreds or in the context of
ethereum this could be a few thousands
and these are really you know large
validators with a lot of stake so there
it's quite simple to do you know for
example in ethereum we could say that
there's 30,000 validators as we already
said this is a number that we know we
can handle uh and so we could just say
okay we only have space for 30,000
validators that's that's the most that
we can do if we want to have faster
finality uh but this means that each
validator would have to have like a very
high balance not incredibly high but you
know a couple thousand e or one 1,000 e
um which is much much higher than the
barrier to entry that we have today of
30 to e um so that's kind of one extreme
that would significantly change um the
the barrier to be a Staker uh then the
other extreme is that all the way on the
left um which is essentially
we just do random sampling of a
committee so we say there are no
barriers to entry we could even say you
can be a um Staker with one e or you
know maybe we don't even have a minimum
uh but then we sample we do like random
sampling essentially of a committee and
the issue with this is that um this
committee size is fixed so if the total
validator set is much much bigger than
the committee size then the uh the
committee will in inevitably have like a
very uh small amount of stake like if
only uh you know today we have 1 million
validators only 30,000 can participate
in each slot uh then about 13th of the
only 13th of the stake will uh um exist
within each committee so essentially
very low economic finality so that's
like kind of all the way on the other
end of the of the trade-off space
somewhere in the middle of the tradeoff
space is a solution where we do sampling
in a a somewhat different way that's
still trying to ensure that we have a
fixed size committee but it is trying to
take advantage of existing heterogeneity
in the the way that the stake
distribution is so you know today we we
have sure 1 million validators but many
validators are actually um clustered in
in staking pools even though the
protocol does not actually know about
that and so there is this uh you know
natural concentration of steak that
already does exist and it is you know a
natural thing to to occur um and we can
try to actually take advantage of that
um to to find the point that's somewhere
in between these two extremes and just
to call it out this though there it says
tender style in the context of ethereum
most more likely what this would look
like it's what has been uh called
sometimes rainbow staking so where Maybe
we essentially split up staking into two
different classes of validators uh one
which do uh are responsible for
essentially finality or or a testing and
are more restricted or like have this
higher barrier to entry of having a
higher um amount of e so that we can
um essentially limit the the number of
these entities whereas there could be
like a lighter class of stakers that are
still responsible for things like um
making inclusion list or or even block
proposing or essentially other parts of
the uh of the stick in uh pipeline that
don't really have this like technical
limitation that a testing does but yeah
so that's that's one possible um way to
go about it but I'll discuss this kind
of middle uh one that that we call
orbit so um what is orbit um there's
this um orbit essentially is a technique
for sampling a committee in a particular
way that tries to achieve these two
things of having the committee being of
a fixed uh predetermined size that we
can handle and of having a lot of stake
um so let's uh call T the maximum
effective balance which is becoming 2048
eth as of the next Fork um once we
select this committee we'll take a um so
let's look at how how does a Staker with
s stake so this could be you know 32e
364 etc etc how does it get into the
committee uh it is selected with
probability s overt so proportional to
stake and uh it has uh it gets reward Ed
when it is in the committee so if it is
actually in the committee it is
participating it's a testing it gets
rewarded with some constant reward that
does not depend on stake so this is sort
of the opposite of what happens uh you
know how you normally do this where the
selection is random so you don't make
the selection proportional to stake but
the rewards are proportional to stake um
but because you know we still have this
proportionality in one of the two terms
you still get that the expected rewards
per validator are still proportional to
stake as they of course should be
and so what what does this look like in
practice um on the top you see a
representation of a validator set with
different uh sizes of validators for
example validator with the size T could
be would be like 248 e and then there's
uh you know the same amount of stake
split up in different ways like t over2
t over2 or four validators of size T
over4 and then you see this kind of
projection uh down to the orbit
committee this projection is essentially
trying to tell you what is the expected
outcome when you're sampling from the
validator set on top and you're getting
an orbit committee um expected here is
really like in the probability sense of
expectation so the let's start with the
with the one on the left the Staker with
um T stake 20048 e for example will be
selected always with probability one
it's always going to be in the committee
because as we said the probability was s
over T So T over t uh just always in the
committee uh we move uh next to the T
over2 and T over2 stakers there selected
with probability one half so they'll
only be in the committee half of the
time and so um when you when we think
about expectations essentially we expect
that one of the two will be in the
committee but only one of the two of
course it can be that it's both or none
but that's just the expected uh case
let's say and two over four same thing
they're all selectability 1/4 so that we
expect one of them to be in the
committee and this way of selecting as
essentially this interes in property
that um no matter how you split the
stake so in very to the stake uh to the
stake distribution the size of the orbit
committee is always the same so you can
see you know on the orbit committee line
uh it doesn't matter if we split the
stake as t or T over2 and T over2 or the
other case the expected case is that we
always get one validator per T stake
essentially and so this is essentially
what gives us validator set capping at
least in expectation but then this is
easy to turn into actual validator set
capping in practice because the variance
is low basically and we can we can just
cap it and and and yeah it's not it's
not a big deal then um so yeah more
concretely with a bit more you know
dramatic effect of uh looking at a much
much um more out of proportion kind of
way of splitting stake uh we have still
this like 2048 e validator this like Max
balance validator again it gets
projected down to a single uh 2048 e
validator itself so it's always selected
when we uh take the uh look at the
picture on the right it's the amount of
stake but split up much more
dramatically in uh however many it is I
guess 64 validators of uh 32 with 32
each each so this could be you know Soul
stakers just complete different entities
and again when we project down we only
get one validator so what does this mean
that just on average each of those will
participate only once every 64 slots
essentially so that still the expected
contribution to the orbit committee is
just
one and um again to to repeat like what
does this get us first of all uh what
I've tried to argue uh in the previous
slides is it gets us validator set
capping basically out of the box so if
you say that D is the total deposit size
so today this is just the total amount
of stake which today would be 35
Millions uh this potentially means that
the expected size of the orbit committee
is D overt and this would be basically
with this parameters around 177,000 so
uh before I said today we handle exactly
twice as much of that 34,000 each slot
so we already know that this is
something that we're perfectly able
technically to to handle and then it
gets us uh if we have enough
consolidation like if we have you know
um staking pools and so on consolidate
enough it gets us uh the possibility of
having high economic finality
immediately like a single orbit
committee might be small it might only
be 17,000 validators but it should
contain most of the stake essentially
like most of the Consolidated stake will
always be in it and then another aspect
that I did not touch on is that in
principle it could mean that it's more
plausible to lower the minimum effective
balance so this is the 32 e threshold
for entering the set which is not being
touched in the in the maxb upgrade this
could in principle be be actually U
easier to reduce with something like
orbit just because the mechanism isn't
really sensitive to the minimum
effective balance if you notice I never
actually brought it up in any of the
arguments
before and uh yeah one important
question here is so this sounds like a
big change you're s you're changing
who's participating the way they're
chosen to participate um what does
actually you know what changes what does
home staking in particular uh look like
in this world so let's first start from
actually from what stays the same which
is uh the frequency of participating in
Block construction so proposals and
inclusion list proposals once we do have
inclusion list which hopefully is soon
this is not going to change at all like
uh this does not depend at all on the
way your sample to ATT test uh because
essentially there's no technical
limitations on you know there's only one
person proposing each slot there's only
maybe a few people making inclusion list
uh this has nothing to do with um we we
don't need to restrict this any further
essentially and uh another point that
I'm not going to be able to get into is
that actually the influence of uh home
stay carees or any stares for that
matter on lmd ghost uh on the basically
the regular fourth choice that comes
before finality would completely stay
the same but I'm just not going to be
able to explain exactly why that is the
casee um with the with the time that we
have and uh now what changes so one
important point is that you attest less
often so if you go back to the picture
that we had before with the 64 small
validators with 32 e they're only chosen
once every two EPO essentially like once
every 64 slots uh and so you but you
know it's less often than Consolidated
validators um but it's it's more or less
as often as today just half as often as
to day with the parameters that I said
you instead of once an Epoch you only
attest once every two EPO but the
rewards are changed in such a way that
you're not earning less than than other
Consolidated validators and another
point that it's maybe more important is
uh home sakers would generally have less
influence over finality um because again
if you think about that picture from
before you have the 64 small validator
validators they're kind of compressed to
one so only one of them will actually
end up in the set um um so even if uh
home stakers have you know maybe 10% of
the stake the amount of stake that they
will have in the orbit committee might
be compressed one point there is so this
is probably I would say the most
contentious uh part of of this proposal
um but yeah one one point there is that
it's already kind of the case there's
already very little uh influence that
they have or finality because there's
only maybe 5 to 10% of stake that
actually belongs to to home
stakers and uh yeah I mean this was
just bringing uh yeah just showing you
why this compression happens again um
and one last point is we would probably
want to ensure that we do have enough
consolidation since this is an important
part of how we get better guarantees
from this mechanism um how do we do so
is probably to have consolidation
incentives that uh essentially go down
to zero once we reach a certain amount
of consolidation that we're okay with so
maybe you know 75% or some other amount
that that we're happy with and uh yeah
when we're outside of this uh regime you
have basically this incentive if you're
a saking pool or so on to
consolidate and yeah what's left
essentially for the consensus protocol
part we have to spec it and prototype it
for the rest a lot of it is really like
having these hard discussions in the
community around the future of staking
and you know what of these trade-offs uh
we're happy with um decide what the what
what failure case we're happy with and
then yeah we could introduce orbit
sampling in the current protocol uh and
then we could eventually uh move
actually to to 3sf or you know to some
faster finality protocol thank
you okay okay I'm going to shuffle you
along towards the center so everyone can
look at your beautiful face um thank you
guys again give another round for
Franchesco perfect so let's dive into
the question starting from the top
Avalanche already has single block
finality with subsec block times where
every validator votes on every block
does this proposed system have any
Competitive Edge against Avalanche
consensus yeah so to my knowledge and I
mean it might be outdated but I don't
think so um avalanch does not have any
accountable safety so there's no way to
actually say if there is a consensus
failure for example let's say double
finality there's no way to say which
valers exactly were responsible for it
because the way they reach consensus
through this like subsampling mechanism
that doesn't really uh get everyone to
to express an opinion on a
block okay cool next does 3sf work with
lower slot times so 3sf is kind of built
in a way that doesn't really change the
the way the slot Works uh too much so
it's it would be a slot that it looks
quite similar to today there's some like
minor things that that I didn't talk
about that kind of deviate from this but
generally speaking most of what we could
do with today's slot we would also be
able to do with 3sf I would say cool it
seems three slot finality provides both
constant time finality and liveness what
hypo hypothesis do you make to guarantee
both um
so I'm not entirely sure um what exactly
the yeah I'm not entirely sure but let's
say like
um the if by liveness you mean
availability more specifically then this
is something that relates to this lmd
Ghost part of the protocol um and yeah
it's it's possible to have both of them
finality and availability because we
have these two different uh kind of
chains in a way we have like the
available chain and then finality on top
otherwise there would be an
impossibility result maybe you mean
something else in which case maybe we
can chat about it
later cool does Orbit changes um how
aggregators are sampled from the beacon
ATT tester
sets um no most likely wouldn't I would
say yeah we could just one way to do
this is that we could just reuse all of
the aggregation infrastructure that we
have now including the way the specific
way the aggregators are
selected the majority of homes take
reward actually from the attestation
does this change
would I'm not speaking English correctly
does this change would this change would
make home Saker suffer by a lot and just
withdrawn being a home steaker and go to
liquid staking or something s oh okay no
it's not me it's
question uh so no like the answer is
like um the rewards would actually be um
the expected rewards but when we talk
about attestations expected rewards and
rewards are kind of the same because
your test so frequently like even with
orbit you still be testing once every
two Appo um yeah you you would not
suffer because of that because the
expected rewards are still proportional
to stake so whether you stake 32 e
whether you stake 64 e in one validator
or you have two validators of 32 eth
your expected rewards are the same you
might have a little bit more variance
but it's attestations that we're talking
about you attest so often then the
variance is essentially
irrelevant cool okay uh would this
change the staking AP PR uh as not all
validators are testing anymore only the
selected set um same kind of answer as
before like it wouldn't like when you're
not in the set you don't get paid but
when you're in the set you get paid a
constant amount so whether you are a
2,000 validator or a 32 E validator when
you're in the set you get paid the same
so you can think about it as like once
you're in you get paid way more than you
should like based on your stake like
you're not paid proportionally to stake
so overall the two things balance each
other okay well I just got the sign so I
think that's all the time we have today
thank you so much Franchesco thanks
everyone um we have another five minute
break until it's actually 410 this time
from Pure Das to full dasas