[Music]
thank you but just in my defense I
opened my Twitter account only to pitch
this and as soon as this is shipped I'm
going to shut up on Twitter anyway so
today I'm going to be talking about the
status of epbs and epbs during this talk
is going to mean enshrined payload block
separation this is not the usual meaning
and you'll notice that I'll only mention
proposers and Builders towards the last
couple of
slides um the talk is going to be
divided in three
sections the first section I want to
convince you for a while that um
dividing the payload the execution
payload from the consensus block is
something that is necessary in ethereum
it is highly beneficial it is a scaling
factor and it enables other scaling
Solutions like PR Das to actually
fulfill its full
potential we have this problem that we
have since emerge which is our Tech
depth that we adopted this minimalistic
way of merging out of proof of work in
which we included the execution block
the one that has the transactions and
everything that we need to like modify
the ethereum machine inside of the
consensus block that has the
attestations the deposits the exits
everything that we need to decide what
what is our current head and we
distribute them both together this makes
for a large Chun of data that is
distributed among the
nodes when this data has logically
different purposes and logically
different
validations what a node does when when
it reaches gets a block it needs to get
to consensus in two different things one
thing is what is the status of the
network what is the execution status of
the network the validity of the block
and the other thing is given two
different views of the network which one
even both of them possibly valid which
one is the one that we consider the head
of the chain these two validations are
completely independent and they are done
by two different clients even two
different soft pieces of software the
validator runs in the running in the
computers the execution consensus is
about validity the consensus consensus
is about which one of the world the
viewers of the world is the current one
because of our Tech Deb the way that we
validate blocks puts all of the strain
of the network in the very first few
seconds of the slot a block is broadcast
at the beginning of a slot and it needs
to be validated it needs to be
downloaded entirely by by the whole
network and by 4 seconds validators need
to have already checked consensus
executed the execution check that the
blob data was available in the future
check that inclusion list this were're
satisfied and a test for this the rest
of the slots is useless time essentially
we're just counting attestations
aggregating them the node doesn't do
anything if anyone here runs a node
you're going to see here the fans going
off exactly every 12
seconds so that's what the ethereum
validation is today and the question is
can we make this better can we make the
timings better presumably yes we have 4
seconds and we don't use those for
seconds but the problem is that
validators are incentivized to actually
propose their blocks as late as possible
so that they can extract more M out of
them and these timing games make
twigling with this these timings for
attestations a an impossible problem to
solve if we gave more time to actually
sync better blocks larger blocks have
more blobs in the network what would
happen is that validator would just
propose later and extract more m
so why separating them since we do not
need to validate execution to decide
what is our head why not just broadcast
the block which is a minimal block which
is just consensus validate consensus
decide what is our status of the of the
chain and then use the rest of those 12
seconds to validate execution check if
the blobs are available validate
inclusion list do all of the stuff that
is actually heavy in the
High latency path and the low latency
path which is validation of consensus
that takes two seconds you just download
the tiny block validated immediately it
takes 7 70 milliseconds today to
validate the consensus side and just a
test so that's that's a scaling feature
of separating the the payload From the
Block so that was the first part of the
talk I want to I hope I convince you
that the separation gives us a
lot of benefits for ethereum now the
question is what have how can we achieve
separating the block from the payload
and the minimum features that we want
that we need if we want to separate them
would be this so what's what we desire
of such a s of such a separation we
would want to have these validations
done completely independent we want to
validate the consensus side in the fast
path and the execution side in the low
in the in the slow
path we want to separate the propag of
these two blocks the large chunks of
transactions might take longer to come
the blobs that are the huge chance of
transaction might take longer to to to
come we do not need to have a very high
uh Uplink bandwidth to submit the blobs
because it takes 12 seconds to be
disseminated so we solve the bottlenecks
that we have we have today in things
like perer D or full
D and we see immediately one problem and
is that well since now you cannot sign
the block with with the payload because
because otherwise we would have a free
data availability problem we need to
have those two objects being signed
that's it that's not so hard verifying
signatures is not a
problem here's a real problem the real
problem is that now whatever the situ
whatever the designed the mechanism
designed to separate the block from the
payload you will have to deal with new
features uh with new situations uh today
a slot either has a block or it doesn't
those are the two possible stat if you
have a consensus blog you have a payload
and if you don't well you don't have a
payload but in a situation in which you
have validated the blog the consensus
block you attested to it and it's your
head and the payload might be invalid or
might not come or the blobs were not
available or it didn't satisfy an
inclusion list the situation is that we
have two we have one extra status which
is the status in which the consensus
block was valid and the payload was not
and this gives a problem which is a for
Choice problem you need to change for
choice to account for this for this
statuses you need to check that if I
attested to a to a block that whose
parent did not have a payload well that
attestation this does not count towards
a parent that did had a payload and this
is completely independent of any auction
mechanism this is the complication of
for
choice of course you need to still
provide security that you're not going
to be reared for free but anyway so in
such a word the other complication that
you have that client implementers will
have is the fact that we we have it
enshrined in our coding that we get the
block we validate in certain order we we
can validate in parallel execution and
consensus and we all do because the
validations are independent but then we
wait until both validations are done and
we attest now one would naively think
that uh that's easy to separate because
you just send the things that we're
doing in parallel you just no just
validate consensus a test and then
validate execution in the rest and
that's it but that's not so easy because
unfortunately the merge was minimalistic
but then we had capella and in Capella
we added new messages that came from the
consensus layer to the execution layer
in Capella we have withdrawals that are
deducted in the consensus layer and then
later on are well and and are Credit in
the execution layer if we have them
separated we're going to have to do that
logic theed duct first when withdrawals
and then uh credit on the execution
layer when we see a payload so that's a
complication and Electra gives us many
more headaches now in Electra we have
messages in the other direction and in
future Forks we expect to get more and
more messages in the direction from the
L triggered in the L towards the
consensus layer these are for example
deposit requests withdrawal requests and
so forth which you will have to change
your code in such a way that when the
payload comes you process
those okay so the point I'm trying to
make is that the complication has
nothing to do with neither me and the
auction mechanism so now we're going to
start moving to auctioning but before
that let me tell you what the slot will
look like in a in a way in which we
separated the payLo From the Block
regardless of of auctioning mechanism we
will have a broadcast you're going to
have to validate quickly execution which
is fast and then you have the rest of
the slot to just get consensus on
whether or not the payload was
there okay so that was the part of
payload block
separation now we we come to the section
of proposer Builder
separation so I've describe the problem
the big lifting of separating the block
and the payload is in two sections
changing for choice to achieve consensus
on what is the head of the chain and
changing clients uh implementations on
how they sync their block because they
they need to do things in a in a
essentially different way they need to
access the databases in essentially
different way but now the question is
well how do we implement this how do we
achieve an implementation that separates
the block and the payload in a
minimalistic
way and I want to convince you well
which is probably hard but I want to
make a case that with minimal
assumptions uh EIP
7732 is a system that achieves this in
an actual minimal
way
so we need to decide a way of how the
payload appears and I'm I'm going to
talk a little bit about auctions there
are many ideas going around on they all
have acronyms that that are hard to
remember epbs slot auctions APS ETS ATS
I don't know but they all more or less
are in the same way there's someone that
sells a right to produce a payload in
Block auctions the proposer submits a
block a consensus block with a
commitment to a particular payload and
the Builder that's committing for that
particular payload promises to pay
uh a value to for the rights of
producing that payload in slot auctions
the proposer does not commit to a
particular payload it only commits to a
particular Builder and then the Builder
later on produces any payload that he
wishes to produce there's execution
tickets or execution auctions in which
the auctioneer is not a validator but is
the protocol itself the protocol sells
far in advance 32 slots in advance
either tickets and then there's a
lottery that is run uh by random n and
we choose who later 30 later who
proposes a payload or you can actually
sell the protocol can sell can hold an
auction and sell the rights to propose a
slot 302 slots in advance and all of
these mechanisms have their tradeoffs
none of them come for free they all of
them impact the me chain and they all of
them uh produce different kinds of
centralizations all of these mechanisms
that I'm describing here you can or may
not run them with burn that means that
even if the proposer is choosing and
getting some value out of the Builder
you could in principle include a burning
of that value towards the protocol the
one that I didn't include is no auction
but that's certainly possible we wanted
to St it was about enrin payload block
separation in principle I could just
enforce that the proposer is the same
signature as as the
Builder keep everything exactly as it is
today in the M chain and keep using me
boost nothing would change except that
we have all the Machinery to separate
the block and the
payload however if we've already did the
heavy lifting which is changing for
choice and changing block processing
changing the auction is zero work for us
changing the auction is nothing because
the auction we already have it we have
the code that requests header from the
Builder we don't need to change that the
only thing that we need to check is that
the signature will be different it's
coming from a particular
validator so the heavy lifting is done
in a minimal way and adding an auction
to get Block auctions is
Trivial so what are the things that
actually change the problems that adding
the auction increases is that in a world
in which the proposer and the Builder
may be different then you need to give
certain safeties to the Builder if the
proposer and the Builder is the same
then you don't care about protecting the
Builder if the payload came late or if
the payload did if the Builder wanted to
withhold the payload this is because
well the proposer is the same as the
Builder he should have sent everything
together but in a world in with the in
which the proposer and the Builder are
different you need to protect the
Builder you need to give assurances to
the Builder that if the Builder
submitted his block on time the block is
canonical the payload is canonical and
you need to give assurances of hard one
is a new situation this was a previous
slide where the three phenomenas could
happen this is the full the block was
full here the proposal of slot n is
building on top of an empty slot here
the proposer of slot n is reorg entirely
the previous block but now we have a new
situation in which the proposer of slot
n is trying to make the Builder pay for
a payload that he didn't reveal because
the previous block was weak so we need
to prevent that situation from happening
and this is a minimal change likely for
us
uh EF researchers on for Choice are very
good and we have minimal solutions for
this that are a tiny bit more of code to
the previous heavy lifting which is
dealing with the whole
tree so how does the PB epbs slot
actually work on an auction mechanism
the builder at the proposer at the
beginning of the slot requests exactly
as with me boo today with the exact
lines of code will request directly from
the builders not the relays their best
bid it would choose whatever bit he
wants it would include it in the blog
and submit his consensus block that can
be validated immediately before 3
seconds we could have been two seconds
actually because we don't need time to
propose blocks consensus
blocks the rest of the slot well the the
Builder would now have to be protected
is going to count attestations for that
block it's going to count for one second
until he reaches enough attestations in
practice it's going to be 40% of
attestations once the Builder saw 40% of
attestations for the block the Builder
knows that that block cannot be
reor therefore the Builder Reveals His
payload this is a 4 seconds so you have
since then until the very next slot to
validate the payload you can just
increase the gas limit a lot if we could
manage to solve the disk uh the state
growth problem uh you can increase the
blob number a lot because now we have
have 12 seconds to distribute the blocks
you don't have two two seconds to
distribute the
blocks later on there's a light vote
there's a light vote by a committee of
512 members and that vote is to Signal
the rest of the chain that the payload
was on time that the next proposer
should not reort the
payload there are other designs that do
not include uh that do not include a
light vote there there were previous
designs that included a full vote an
aggregated vote an attestation of the
whole committee for the payload or not
uh but this design is robust enough and
it requires only 512
signatures so let me tell you about
implementation status of uh I'm not sure
if I can ah yes it's an empty video but
uh let me tell you about implementation
status of this so we wanted to have a
proof of uh yeah a proof of concept
model for EBS and we have it there's uh
we we are finalizing epbs locally
constructing blocks so we're not
contacting a builder but we are
finalizing a Network that has the
payload and the block separated um two
clients two consensus clients have have
already the implementation is underway
um te I believe is close to being an
interupt uh Nimbus has two EPF uh
working on this uh loads are on Li house
I think they initiated at least they
have the typing but they haven't
Advanced much more but the point is that
it takes it took us a couple of months
of sitting down and coding not more uh
it's not production code but it's
certainly ready the the EIP is ready to
go
uh as I described there's no changes I'm
only mentioning consensus layer changes
there's no changes on the execution
layer that's why the execution layer
guys are happy because we're going to
give them a lot of time to validate the
block without anything on without them
writing a single line of quote however
the interaction with fossil is not
trivial if we want to include inclusion
list which is something that we really
need in in ethereum we're going to have
to involve the execution layer and the
interaction of fossil with the IP with
epbs is not entirely trivial it's not uh
something that I'll describe today here
all right thank you very much
guys all right we'll go through some
questions from most upvoted are there
any other protocols or message
propagation mechanism being explored
other than Li P to be not that I
know simple
answer after implementing epbs on prism
how would you rate the complexity of
changing the entire consensus execution
validation sync Etc while still
maintaining backwards compatibility
that's that's a great question
uh it was much harder than I thought uh
Fortress was the problem and uh but uh
we have now a because we iterated
several times until we realize what is
the right way of doing it so now
backwards looking there was a very
simple way of doing it so my original
implementation was hard but now we have
a very simple
change as I said in two months we did it
now I believe knowing what is the right
design we could have done it in two
weeks what if there's a reorg larger
than depth uh of one nothing changes uh
absolutely nothing changes for Choice uh
my original design used boosts to rely
on the if the block was poor and the pay
the the Builder did not want to uh
reveal the the payload my original for
Choice design uh relied on the network
reorg the whole thing uh luckily
Francesco came up with a simplest
solution that doesn't touch for choice
at all it's the usual lmg ghost
mechanism without any boosts so for
choice is not change is not different in
the way that we count weights the only
difference is in the way that there are
nodes that may or may not have a
payload what do you think about
implementing consensus execution
separation without epbs uh I so the I
think that I the the way I phrase this
talk is that uh there's a big chunk of
changes that are completely independent
of any kind of mechanism for auctioning
and those changes are going to have to
be included in any known road map for
ethereum ethereum in all of the known
road maps for ethereum we have the
separation between payload and block and
that's the heavy lifting that has been
done now you need to put on top of this
an auction just to as an implementation
detail and the way the reason why we
chose uh block auctions is because I do
not know how to implement any of the
other ones and if anyone gives me an
actual spec to implement execution
tickets or future slots without single
slot finality I'll be happy to code it
but these are the only two that we
actually have a spec and we know that
it's robust and safe what about the
impact on the the late block of proposer
boost uh what about the could you repeat
that one what about the impact on the
late block of proposer
boost we I'm not sure if I understand
the question but uh so perhaps oh okay
so the the question is perhaps that if a
block comes late proposer boots can
reorg yes and this is something that we
do today today in order to not
incentivize seeing late blocks we
actually have seen blocks coming in the
early days at 12 seconds trying to reorg
the next block in order to not
incentivize this we actually actively
reorg a block that comes late and that's
not going to change here uh the only
thing that is going to change is that
the Builder uh has a safety mechanism
that if the block came late with a
commitment to its payload then the
Builder may not reveal it because he
knows that it's not going to be forced
to
pay because it has to be reor does this
proposed change require an e spec change
or an EIP and or does it
only require client client
implementation it is a it is a consensus
breaking protocol it's a it's it's not
backwards compatible it's requires any
IP the IP is
7732 we have two more minutes so if
anybody has a Live question that they
want to
ask oh that's uh that that that's a
great question can you repeat the
question so the question is whether or
not we have we if we've implemented syn
no I have not uh purposely because I
really wanted to have the the proof of
concept before Devcon it nothing really
changes though because for sync what you
you don't you can pck it you can pick it
back what we already have today so for
sync you're going to send the full block
together anymore yes are you afraid that
given the changes and introduction of
new features of the offchain PBS uh
pipeline we are soon going to reach a
point of no return where epbs is pretty
hard to even be realized uh I'm not sure
I'm not sure I understand the question
I'm sorry for example when PBS started
we had the relayer just do one thing but
then we did stuff like optimistic relays
recently there have been proposals of
stuff like gateways which again relays
do so we keep adding complexity into the
offchain PBS stuff that would need to be
matched or very or or improved within
epbs do you is this a problem that you
see or foresee or is this a viable risk
for you I I don't I don't see this I I
can tell you something that I see as a
risk uh I don't see this particular
thing a risk because complexity on the
relay all that it will CH change what
epbs the way we proposing is what it
does is it allows the Builder to be a
relay directly and permissionless so
what what you're describing to me sounds
like builders in the protocol which they
are already are because relays are
Builders uh they will have to have this
complexity if they want to compete be
competitive in the market but from the
protocol perspective we don't care what
I do see as a risk though is other
things that are being piggy back on PBS
say for example uh pre-confirmation uh
and all of these extra markets that are
being done I would require I would ask
for the teams that are working on pre-
comps to make it compatible forward
looking compatible with mechanisms of
separation and if the person who has um
answered the multiple current concurrent
proposer question wants to ask him
afterwards we're out of time for
questions um but he'll be around in the
room um thank give a hand to pus
[Applause]