[Music]
it it is right okay so yeah I'm Lucas
and I've got Stefan here with me um our
talk was originally designed to be two
talks but do some scheding things we had
to merge them together so well we'll do
our best to make sure we go through the
content and everyone understands
everything so yeah I'll start with my
part and then we're going to have Stefan
thank you St thank
you okay so we're going to start with
EIP 70002 execution layer triggerable
withdrawals before it was named
execution layer triggerable exits but
there are some updates that um made we
renamed the zip before talking about the
EIP I want to go through a little bit of
a context here so I'm assuming that
everyone is aware that in ethereum we
have validators and they are staking 32
e and then they performing the duties
like voting at the U voting for new
blocks with at the stations proposing
new blocks and things like that and well
when you're creating a validator maybe
everyone knows that but we have two sets
of credentials you have your validator
key which is associated with your
validator public key which is used for
signing your blocks signing your
attestations and everything and you have
your withdraw uh key which is kind of
represents the uh ownership of the state
amount of of of E
um another concept is solo staking
versus delegated staking so this is kind
of a different thing like staking is
staking but uh I think solo staking will
be uh kind of the most basic uh thing
when you think about staking you know
you have your laptop you create a
validator you have the validator key you
have your withdraw key so you own kind
of everything and when it comes to
delegate staking there is like a bunch
of different uh Arrangements you have
custodial non-custodial but for this
exercise that's just assume that you own
the withdrawal key someone else owns the
validator key because they're running
your node for you but they do need the
key because they're going to be signing
the the stations and everything so they
need the key so that let's just do with
that okay another thing before we jump
into the EIP uh I want to touch on
voluntary exits so um voluntary exit
since phase zero has been pretty much
the same you if you want to exit
validator you don't want a stake anymore
you will uh send a volun assigned
voluntary exit message but that message
is signed with your validator key so you
sign that message broadcast it through
uh send it through the beon API it's
going to be propagated in the network
eventually included in a block and after
some time your validator joins the exit
Cube pretty straightforward uh however
as you can see in the diagram here if
you don't have the validator key you're
kind of in trouble because you don't
really have a way of accessing your
valid dator and you need to kind of ring
your operator hey could you please exit
my validator for me well if they are you
know nice people they will do it for you
but you know it's kind of like a grief
Tech Vector because technically the the
node operator can um like not really do
their best job uh when doing their
decisions and everything and they have
ways of like slowly chipping away your
uh your uh steak which not great there
are ways around this some other
operators will give you a pre-sign exit
message when you join the uh the system
so you keep that message safe whenever
you want to exit you already have the
signed message and then you can exit
this is a workaround because there are a
lot of complications with this there's a
lot of you know you need to keep that
message safe you don't you're not 100%
sure if that message is going to work
and they have to have all the
infrastructure around managing that
message and everything so it's yeah it's
kind of a heck well back to the problem
that we were talking about
we you can only exit your validator
today with your validator key right and
the solution is easy just allow both the
validator key and the withdraw key to
exit the validator yep it's it's pretty
straightforward unfortunately
implementing it it's not that
easy um and that's pretty much the
context and how we get to EIP
7002 so why it's not easy it's important
to remember that when it comes to the
consensus uh layer and the execution
layer the consensus layer doesn't have
like a complete view of what happens on
the execution layer right so it's got
like a limited amount of information
that comes through that side I think a
good example of this is you think about
deposit processing stepan is going to be
talking a little bit about about it
later it's a complicated it's a
complicated Mass you know it's a whole
system keeps updating and fetching
information it's not that easy so what
we really need is we need a mechanism to
create a message on the execution layer
send that message all the way to the
consensus layer but that message has to
be authenticated with an account on the
execution layer side but at the same
time all the authorization happens on
the consensus layer side because the
consensus layer is the one that knows
who's the validator what's the withdraw
credential associated with that
validator what's the balance and all
this kind of stuff so that's the kind of
the the thing that we're trying to solve
here um and that's pretty much the idea
with withdraw requests so it's a request
that comes from the e goes to the CL and
it's got um pretty much three uh pieces
of information one is the source address
which is supposed to be the address that
you have set as withdraw credential on
your
validator the public key which is
basically what is the validator you send
you're sending this request to and the
amount which is an interesting one so
before we didn't have the amount so the
amount was introduced because after EIP
7251 if you guys were here to listen to
post talk on Max CB now it's possible
for validators to have more than 32 e uh
balance right so technically you can
have a validator with like a th000 eth
or something stake so we basically split
the uh the withdraw into two different
types of withdraw you can do a full
withdraw which means I I want to
withdraw every single way that I have
staked which basically translate into an
exit or I want to do a partial
withdrawal which means well you know I
have 100 E I want 50 back because I want
to buy a new car or something so you do
like a partial withdrawal you get it
back into your uh account and then you
can use the money and that's the we use
the amount Feud for that so an amount
equals zero means a full withdraw which
can be a bit a bit weird to think about
but and an amount uh greater than zero
is it's like a partial withdraw I just
want to withdraw part of my stake
hopefully everything makes sense until
now
um and on this diagram I'm trying to
capture uh how things have changed
compared to the previous diagram so the
way that we're creating this mechanism
is basically now we're going to
introduce this withdraw request smart
contract on the execution layer side and
that con has pretty much two uh two
functional two functions so the first
one is a function that the user is going
to call to basically create a a request
so when when the user wants to create a
request I'm going to send send a
transaction signing it with my withdraw
key not the validator key and the Contra
is going to look at it like oh okay that
that that's cool someone's creating a
withdraw request it's going to set that
address as the source address on the
request uh and I'm going to be on this
request here we pass two pieces of
information the validat public key and
the amount eventually uh the execution
client is going to call the contract and
read uh the information for it read the
request that are on the on the Queue the
is on the contract State and send it
over to the Bono to engine API and
that's I'm not going to go in a lot of
details of that because again not a lot
of time but basically when whenever it's
time to create a block and the beon node
is going to receive those requests from
the El uh some verification happens and
everything and then the authorization
part uh happens on the consensus side
it's going to look at the request make
sure that the source address so the
account that is send in this transaction
here matches the with credentials on the
validator on the consensus side and um
some other rules you know make sure that
you exit you're creating a request for
the right validator and
everything cool so hopefully this makes
a bit more sense uh one interesting
thing uh to note here and that was
actually probably like half of my
original talk is that when you look at
this uh this kind of Orange area here
you can see that this mechanism for
sending requests from E to CL can be
quite useful for a bunch of different
things and yep we did notice that and
that's why we have um EIP
7685 which introduced this concept of uh
execu um general purpose execution layer
requests so now we already have all this
mechanism for creating different types
of requests for the next four Spectra we
already have three types of requests we
have withdrawals the ones that we were
just talking about we have deposits the
one that Stephan's going to talking
about and if you were here for the
previous talk consolidations it also
happens through a execution layer
request so um that was kind of the most
interesting part of uh this uh system so
yeah take a look into that because it's
pretty
cool uh before I finish I just want to
go through a few uh caveats because you
know there's no free lunch there's
always something that you need to give
away so the problem with uh withraw
requests and kind of the execution
requests in general is that
but creating a successful transaction on
the El side like creating a request
doesn't guarantee that that request is
going to be successfully processed on
the consensus layer side I know it
sounds a bit weird so it the the user
experience is a bit clunky you kind of
need to look at the consensus side make
sure that everything works out create
the request and that just kind of hope
that nothing's going to change in this
in between um hopefully it's not going
to be too bad but it's it can it can
happen and another interesting thing is
if you currently have a validator and
your validator has a contract address
set as withdraw
credentials um well things are going to
be a bit bit more complicated uh for
those of you who are familiar with the
evm uh the contract that is creating the
request is not looking at the
transaction sender for authentication
it's looking for the message caller so
that means that if you are interacting
with the request contract using a smart
contract the smart contract address is
going to be the one that's going to end
up on the source address right so for
this whole thing to work your validator
withdraw credentials has to be the
contract address not the add not the
account that is sent in the
transaction so again I'm sorry for you
if you're in this situation um hopefully
if you have upgradeable smart contract
you can kind of get away with it you can
use like delegate calls and do some very
smart stuff to make it work uh that's
not my expertise I'm not going to talk
too much about it but there is a way for
you uh but yeah just keep that in mind
when you uh looking into
this um oh yeah one important thing is
that this does not replace voluntary
exits voluntary exits are still the
easiest way to exit your validator if
you have the validator key you sign the
message it's going to be broadcast to
the network it doesn't cost you gas or
anything there's no transactions
involved so yeah yeah keep doing that if
you can but this is basically like a way
of kind of filling that Gap that we have
on those scenarios where you don't have
your your your validator key and quickly
before I run out of time uh I just want
to mention that withdraw requests uh
different from withdrawals in the sense
that if you guys remember capella that's
when we introduced withdrawals a
withdraw requests can eventually
generate a withdraw when you're doing
like a partial withdraw but they're not
same thing just because yeah the
terminology and things like that okay
that was a lot hopefully enough for
people to understand I'll leave it here
and then I'll hand over to Stefan for
his Mar thank
you oh thank you how does that work just
yeah next
slide
okay hello
uh so I'm going to talk about EIP
6110 which is Supply validator deposits
on
chain and you may wonder what the CIP is
about because validator deposits are
already on chain but the keyword here is
Supply so essentially the CIP changes
how the deposits made to the deposit
contract which sits on the execution
layer how these deposits are supply to
the consens Slayer where either a new
validator is initially ized or an
existing validator balance is topped up
so I'm going to start by explaining
briefly how the current deposit
processing works and then I'll go over
the depositing processing after this EIP
which will be part of the next
Fork yeah so current deposit processing
uh basically a user submits a
transaction containing deposit data to a
deposit contract which is uh essentially
32 if and users usually do that via the
staking launch
pad and then there is this uh 8 hour
delay where the consensus layer has to
consider the state of the deposit
contract and this has been designed to
be 248 blocks uh when with proof of work
blocks which are which were around 14
seconds and this was done to ensure that
if there are any issues with if1 uh then
uh essentially that wouldn't impact the
beacon chain and 8 Hour was just it
gives about enough wiggle room to ensure
that any issues are
fixed and then there is a voting which
is a 64 EPO and it's kind of this is
like a off-protocol consensus mechanism
it was designed before the merge and
basically it ensures that validators
agree on the state on on the same view
of the deposit contract which sits in
the EO
and before the merge basically the EO is
driven by proof of work so there was no
real connection between the execution
layer and the consensus
layer um and then this voting basically
it finishes when at least half half
number of the votes are the same and
after that proposers include those
deposits uh alongside the
block and then all notes can verify
these
blocks and then
uh a valid deposit basically either
creates a new validator or it tops up
the balance of an existing
validator and this is a diagram of the
current uh process so you can see this
user he uh B basically does a deposit
transaction use the stank launch p and
then the important part here is
basically you can see on the right the
Bon note and it has this chunky if1
module which constantly psts the E via
the Json RPC API and it does that 248
blocks uh constantly it POS it in order
to build the merco tree which then can
be used to produce proofs which are
included alongside
deposits uh and this is the current
process which is still still ethereum
works like that even though we have
already migrated to proof of stake we
still use this J an
RPC and the way this the EAP 6110 works
is it simplifies a lot basically the
same deposit transaction is made uh but
then the deposits come directly from the
e via the engine API and they're
included in blocks and then they process
on finalization of the chain which is
currently around 13 minutes and then the
same flow the same
it's again the same thing a valid
deposit will are create new validator or
top up an existing
validator and the diagram now uh looks
like this which is pretty much what
Lucas showed you basically have the
execution requests and now you get the
deposit request over the engine API so
whenever a proposer proposes a block
they get the deposit requests and uh
basically this whole E1 module which was
quite chunky now it's no longer part of
the Bon
note
um so this is the diagram and to quickly
summarize the advantages of the
EIP basically there is nowadays a delay
of around 11.4 hours before
your UH validator is added to the
activation queue and this is basically
the follow distance this 248 blocks
which is around eight hours and then
there's this voting of around
uh 32 EPO which is 33.4
hours uh and now this is reduced to Just
Around 13 minutes or two
AO and another Advantage is the
increased security because we no longer
uh rely on this off protocol mechanism
now we can just now we just inherit the
security of the
chain and uh also there is not a benefit
because currently we have these deposit
contract snapshots which basically are
um a merket tree up to a certain point
uh in in in time and we no longer need
this because we no longer need to
provide proofs because we're just uh
getting the deposits from the engine
API and one other benefit is that we no
longer rely on the Json RPC API we only
rely on the engine
API and it's also we just no longer need
that very Legacy Legacy and brittle part
of the C clients code uh which is always
good to delete
stuff uh and one more slide I wanted to
show I wanted to quickly show that this
EAP is actually not is actually simple
to uh Implement so if you're interested
you can go over this link and see how we
implement it we generally try to do
small PR so it's just eight PRS but it's
not big changes uh so if you ever want
to check how ANP is implemented actually
this is a good one to go over because
it's quite
simple um yeah and that's uh that's it
pretty
[Applause]
much thank you thank you we're going to
get to some some questions now um and
again uh if you're new to
uh seeing a talk today scan the QR code
add your question and you can vote if
there's one that's already there and you
would like to see it answered just to
make sure it gets answered and push to
the top of the que um thank you thank
you so we will start with why a valid
request from the execution layer would
be rejected on the consensus
layer um I can probably take that one um
it's it's hard to it's hard to go
through all the different reasons why uh
I think the best way of thinking about
it is that I like to separate that the e
is doing the authentication side of the
uh request and the C is doing the
authorization side of the request so I
think the easiest example that I can
think of uh for example for withdraw
requests let's say that you create a
request for someone else's valid dator
right so the transaction is going to be
successful the request is going to be
added to the uh to the contract but when
the cles that request is going to try to
match the source address with the
validator uh validator withdraw
credentials it's going to say well well
you don't really own that you can't
really do that right so that's one of
the reasons um yeah like there are other
more specific rules that can but I think
that's probably the easiest way to think
about it the E doesn't really know the
rule the business rules on the CL side
in the same way that a can't really
validate beforehand that that's the
right uh validator so that's kind of
part of the reason hopefully yeah that's
it thank you and looks like we have
another one for you right again so why
do you think contract address as a
withdrawal itial is a
caveat um
it's it's more like it's a more
complicated thing because um there there
are two problems with this one is that
the currently the validator withdra
credentials cannot be updated so once
you I didn't really touch on the whole
BLS credential side of things which is
something that already was there before
but the way that it works right now once
you set your validator withdraw
credentials to one address you can never
change that address so so a few problems
happens here the first one is as I
mentioned if you have your valid dator
credentials set to a contract address
that is not upgradeable you're never
going to be able to update that code to
call the request contract so you you
you're you're already kind of locked out
from this mechanism straight away if you
have an upgradable contract you can
write some code to kind of get around it
um so it's more like a kvat in terms of
something that people need to get their
heads around and make sure that they
consider when they implementing because
I think the natural thing to think is
well I'm going to sign the transaction
with this credential with this account
sorry uh key and that's the one that's
going to show up on the request but that
that's why it's kind of a
caveat thank you all right now for you
um if EIP 6110 makes eth1 vote Legacy do
we have to carry all eth1 voting fields
and Logics in consensus layer even in
post Electra yeah sure uh so there is a
little bit of transition period when the
when post electrod to transition to the
new way because we still have to process
deposits VI the old way for some time
but after that is done we can pretty
much remove all of the this Legacy code
in uh in next releases after the
fork thank you um is there a proof
generation process to withdrawal similar
to performing igen layer
withdraws um unfortunately I'm not
familiar with IG layer withdrawals
process but there's no proof generation
on this withdrawal um hopefully uh if I
understand the question there's no Pro
Generation Um what if a deposited
request failed will users eth be
refunded so when you deposit if to the
smart
contract there is technically no way a
deposit request fails so if the deposit
request fails that that means that there
is like a consensus failure which yeah
it wouldn't be refunded but it's a big
issue all right I think we have time for
one maybe two more um how resilient is
the engine API comparing to Json RPC API
yeah so the engine API basically drives
the execution uh the consensus layer
client drives the execution layer client
via the engine API so it is very
resilient the Json RPC API can
uh it's not it's still very reliable but
it is not uh critical so there could be
some implementations in some Clans which
are less reliable to the engine API
which is very very critical awesome and
we have just about 5 seconds left so
probably not enough time to get to next
question but if you'd like to come up to
the speakers and ask them questions
later they'll be sticking around for a
little bit um so thank you very much
let's have a big