►
Description
Topics covered
-----------------------------
00:32 - EIP introduction
02:02 - Presentation
02:44 - Author’s introduction
03:08 - What is withdraw?
07:39 - How to implement?
08:48 - How is that signaled from the consensus layer to execution layer?
09:13 - How to do the ETH accounting?
11:38 - When is a validator allowed to withdraw?
11:55 - Full withdrawal
13:57 - When to withdraw?
15:35 - How to implement?
16:15 - Validator credential change
17:45 - How to signal?
18:35 - Pull style withdrawals
26:55 - Pull style withdrawals end - to - end
27:43 - Is it worth it?
29:51 - Push-style withdrawals
32:02 - Push-style withdrawals end - to - end
33:19 - Current status
33:30 - How to structure withdrawals?
38:03 - Partial withdrawal
39:35 - tl;dr
41:45 - Open for questions
42:50 - “I seem to remember that the people who stake earlier will also be able to withdraw earlier after the Shanghai Fork (ie first to stake are the first to queue for withdrawals. Do you know where I can find that documentation or am I mistaken?”
45:55 - How do you think the withdrawal processing “before” and “after” any user-level transactions affect the MEVseraching situation?
48:28 - What are the main security considerations for this proposal? Is there anything that may need research that can delay the proposal to be included in Shanghai?
51:07 - Mention of ommers list in the EIP, thoughts?
53:08 - Why not two separate EIP - Core & Networking
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1N6aX-GE-kus73vlq-v7D-z2iwUI4N4ss1tiPamfoTi4/edit#slide=id.p
EIP- https://eips.ethereum.org/EIPS/eip-4895
Discussions-To - https://ethereum-magicians.org/t/eip-4895-beacon-chain-withdrawals-as-system-level-operations/8568
Meta spec - https://notes.ethereum.org/@ralexstokes/Skp1mPSb9
Tweet thread - https://twitter.com/ralexstokes/status/1509224908441718789
Shanghai playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxpok0smGmq-dFGVHQzW84a2
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
-----------------------------------------------
Alex Stokes @ralexstokes | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
Eib4895
is
a
standard
track
core
eip
proposed
last
month
and
is
currently
in
the
draft
status
a
bit
more.
On
the
background
we
know,
beacon,
sheen
was
launched
on
december
1st
2020,
it
enabled
staking
on
ethereum
validators
can
participate
in
network
security,
receive
rewards
for
duties
performed.
However,
collecting
the
reward
in
terms
of
withdrawing
it
to
an
individual's
wallet
is
not
there
yet
to
learn
more
on
validator
staking
and
available
options
for
beacon,
chain
withdrawal.
A
A
Right,
as
we
all
know,
alex
has
been
on
our
show
earlier
talking
about
beacon,
chain
accounting
reform
with
altair
upgrade
eip4s,
so
people,
if
you
have
missed
watching
all
those
episodes
earlier,
please
check
it
out,
especially
episode
34
accounting
reform,
because
that
may
provide
a
bit
more
context
of
what
we
are
going
to
discuss
today
well
from
alex's
last
tweet,
it's
it's
obvious
that
we
there
are
a
lot
to
share
with
their
community.
So
let's
peep
deepen.
B
B
Into
this-
and
I
think
it's
pretty
interesting
just
to
like
see
the
whole
whole
space
and
how
things
shaped
up
so
yeah,
we'll
just
dive
in
so
just
quickly.
Who
am
I
food?
You
gave
a
great
intro,
I'm
a
researcher
at
the
f
alex
stokes.
If
you
want
to
find
me
on,
like,
I
think,
probably
any
platform
you
can
think
of,
I
have
the
same
handle
so
yeah
email
me.
Well,
I
guess
you
could
email
anyway.
Dm
me
message
me
whatever.
I
think
you
should
get
in
touch
with
me.
B
B
You
kind
of
have
these
same
layers
today,
but
they're
switched
together,
and
so
it's
a
little
harder
to
pull
them
apart,
but
they
get
a
little
bit
more
pulled.
Apart
with
the
merge
and
there's
two
like
important
layers
that
we'll
look
at
the
consensus
layer
and
the
execution
layer,
and
so
fuji
mentioned
the
beacon
chain,
that's
the
consensus
layer.
This
is,
you
know
a
way
to
think
about.
It
is
well,
and
it
is
right
now,
its
own
blockchain,
but
all
it's
doing
is
like
forming
this
proof
of
state
consensus.
A
B
I'll
refer
to
it,
like
kind
of
specifically
as
like
the
evm
as
like
this,
like
user
space,
execution,
environment
and
yeah,
so
either
way
after
the
merge,
these
two
things
kind
of
become
one
thing:
the
full
merge
chain,
but
there's
still
these
layers,
and
so
we
have
this
proven
stick
network.
What
does
that
mean?
B
It
refers
again
to
the
consensus
where
now
you
have
these
things
called
validators
validators
are
validating
the
consensus,
that's
why
we
call
them
that,
and
these
are
the
actors
on
the
network
who
are
actually
determining
okay.
What's
the
canonical
chain,
if
you're
familiar
with
proof
of
work
right,
there's
like
miners
and
a
minor
basically
gets
to
vote
for
the
next
block
in
the
chain
by
mining.
B
Doing
your
your
duty
correctly,
but
it's
very
important:
it's
actually
the
security
model
of
this
consensus
that
there's
something
at
risk.
You
know
I
said
here:
asset
assets
at
risk.
This
is
when
they
say
proof
of
stake.
This
is
what
they
mean.
Is
the
stake?
There's
like
something
that
is
valuable
to
you.
B
That
is
basically
going
to
make
sure
that
you
have
quote
skin
in
the
game
and
that's
like
your
deterrent,
because
if
you
do
something
you
know
that
the
protocol
deems
bad,
then
you
can
lose
this
locked
up
asset
and
you
know
on
ethereum
we
have
heath.
So
this
is
the
thing,
and
what
this
looks
like
is
that
in
order
to
actually
participate
as
one
of
these
validators
on
the
network
sort
of
within
the
protocol,
you
have
to
lock
up
328,
that's
the
current
number
of
32.
and
a
way
to
think
about.
B
Then
the
protocol
also
gives
you
some.
You
know
some
reward,
so
you
get
extra
eth
for
doing
so
for
doing
so
well,
and
the
way
to
think
about
this
is
that
it's
kind
of
like
interest
on
this
deposit
that
you
made
so
right.
We
just
we
just
constructed
this
environment.
Where
you
can
do
this
thing,
you
can
be
the
validator
of
the
ethereum
network
and
you
basically
get
something,
and
so
eventually
you're
going
to
want
the
seats
right,
and
so
this
is
what
we're
talking
about
with
drawing
things.
A
B
A
B
A
B
For
doing
well,
and
then
they
want
to
withdraw
their
teeth,
and
so
now
the
question
is
like
okay,
it
sounds
like
something
we
want
like.
How
are
we
going
to
pull
it
off?
How
do
we
implement
it
and
it
turns
out
there's
like
actually
a
pretty
big
design
space
and
like
over
several
like
iterations
of
awkward
devs
and
like
different
things
like
this.
We've
explored
the
trades
of
the
trade-offs
in
this
space
and
I
think
you
know
they're,
certainly
like
a
favorite
solution,
and
so
that's
where
we'll
get
to.
B
We
want
to
implement
these
like
beacon,
chain,
withdrawals
and
there's
basically,
three
sort
of
like
top
level
like
big
questions,
the
first
one
when
is
a
validator
even
allowed
to
withdraw
so
I
kind
of
hinted.
It
was
like
very
important
for
like
network
security,
that
you
know
the
eve
in
this
consensus.
Layer
has
some
sort
of
encumbrances
like
there
are
special
rules
around
when
it
can
do
what.
So
we
need
to
make
sure
that
it's
safe
to
even
withdraw
the
youth
in
the
first
place.
B
Second,
question
is
okay.
If
we
do,
you
know
the
protocol
then
deems
it's
safe
to
withdrawal
disease
like
how
do
we
signal
that?
Because
some
of
this
is
conditional
and
understanding
kind
of
how
the
merge
architecture
is,
but
basically
there
is
a
separation
between
these
two
layers
that
I've
been
sort
of
establishing
or
talking
about,
and
so
we
have
to
like
figure
out
how
to
get
from
one
to
the
other.
B
B
Like
when
do
you
actually
want
to
withdraw-
and
I
think
the
important
thing
here
is
that
you
should
understand
that
the
consensus
layer,
like
the
protocol
itself,
thinks
about
validators
in
these,
like
32
heath
chunks,
which
is
again
this
sort
of
like
principle
deposits?
You
know
this
like
initial
stake,
I
gave
it
this
phrase.
Consensus
stake
weight
because,
like.
B
Like
there
are
many
things,
for
example,
if
you
are
proposing
in
the
network
right
so
you're,
a
validator,
every
validator
is
selected
in
proportion
to
their
stake,
to
propose
a
block
and
sort
of
the
exact
frequency
is
like
your
your
balance
here,
divided
by
the
total
number
of
other
balances
right
and
so
like.
If
there's
like
a
thousand
validators.
A
B
Expect
once
every
thousand
slots
to
propose-
and
essentially
the
idea
here,
is
that
we
want
it.
Oh
yeah.
The
idea
is
that
there
are
many
things
like
this
in
terms
of
shufflings
and
like
assigning
validators
to
different
roles
and
duties
that
are
proportional
to
their
their
stake,
and
it
actually
turns
out
it's
like
far
easier
to
reason.
A
B
Would
be
like?
Oh
this,
other
actor
has
like
you
know
four
times
the
stake
weight
of
this
one
and
then
like
they
propose
returns
as
many
blocks
like.
That
might
not
be
good
because
then
it's
like
okay,
they
kind
of
outsize
influence
on
like
what
the
chain
looks
like
and
there's
censorshippers
there
anyways.
The
point
is:
is
that
you
know
it's
actually
a
really
nice
sort
of
design
element.
A
B
Validators
kind
of
all
look
the
same
in
this
way
and
that's
not
to
say,
though,
that
validators
can
have
different
balances,
there's
basically
a
balance
on
chain
and
there's
a
separate
balance
like
an
effective
balance
is
what
it's
called.
That's
tracked
on
chain
as
well
and
in
terms
of
like
you
know,
figuring
out
these
protocol
rules.
We
use
the
effective
balance,
but
then
my
actual
balance
could
be
higher
than
that
or
lower.
B
B
B
I
just
have
a
different
hobby
who
knows
in
that
case,
I
can
actually
sign
a
message
that
says:
hey
I'm
exiting
at
this
time,
broadcast
it
everywhere
and
then,
if
that
gets
unchained,
then
you
end
up
going
through
this
eventual
process
where
you
can
then
withdraw
like
your
entire
balance.
This
is
what
we
might
call
a
foliage.
All
I
kind
of
hinted
a
second
ago.
B
You
can
end
up
with
a
balance
over
the
sort
of
like
consensus,
stake
weight
just
like
since
it's
important
value,
and
so
then
you
actually
might
imagine
withdrawing
you
know
the
differential
over
that.
So
let's
say
you
have
like
32.3
e,
because
you've,
like
you
know,
have
good
attestations.
You
know
a
good
attestation
sort
of
history,
and
so
the
protocol
weren't
you
for
that.
So
now
you
have
this
diff.
B
So
if
you
have
over,
it's
actually
fine
to
pull
it
out
of
the
system,
and
this
is
what
we
call
a
partial
withdrawal.
There's
a
distinction
here.
I'm
calling
out
we'll
get
to
at
towards
the
end
of
this
talk
in
more
detail,
but
basically
there's
just
like
two
different
modes
here,
but
withdrawing
and
there's
other
there's
many
other
pathways.
The
sort
of
like
state
space
of
being
a
validator
is
actually
kind
of
complicated
because
you
basically
like
deposit.
B
And
then
there's
like
an
activation
queue
and
then
you're
going
and
there's
gonna
be
an
execute,
but
then
also
you
can
get
slash
so
then
it
kind
of
like
forks,
the
whole
thing
anyways
point
being
is
that
you
know
you
eventually
end
up
after
some,
like
very
specific
conditions
are
met
in
this
place,
where
you
can
withdraw
eve.
So
the
high-level
point
here
is
that
the
consensus
layer
takes
care
of
all
this.
B
It's
all
encapsulated
with
respect
to
execution
layer
that,
like
there
are
protocol
rules
that
consistent
clients
are
following
and
enforcing
there
you
go.
I
think
that's
all
I
have
to
say
about
that.
So
right
and
then
the
question
is
just
like
okay,
so
we
assume
that
this
beacon
chain
thing
is,
like
you
know,
handling
the
safety
withdrawals,
and
so
once
it's
deemed
safe
like
what
do
you
do
and
like
I
really
straightforward
answer
that
question?
B
B
Post
merge
there's
just
one
blockchain,
but
you
can
imagine
there's
now
this
like
sub
layer
that
contains
this
layer
that
has
its
own
state,
the
beacon
state,
and
it
has
a
number
of
things
again
like
if
you
want
the
full
details,
go
to
the
consistent
specs,
it's
all
in
there,
but
it
has
things
like
the
genesis
time
of
the
chain.
It
has
things
like
a
list
of
every
validator.
It
has
things
like
a
list
of
every
balance.
B
So
again,
when
I
said
there's
like
the
balances
that
are
tracked,
this
is
where
they're
tracked
the
sort
of
favored
proposal
right
now
is
then
we'll
fork
in
you
know
and
we'll
get
into
exactly.
When
we'll
do
this,
but
sometime
after
the
merge
we
will
add
a
list
to
the
state
of
withdrawals
and
these
withdrawals
are
pretty
straightforward.
There's
an
index
that
just
says
basically
in
the
sequence
of
all
withdrawals
like
you
know
where
they,
where
they
occur,
there's
an
amount
which
is
the
actual
amount
of
eth.
B
So
one
is
about
a
lot
of
withdrawals,
so
hopefully
you
know
without
going
into
any
details,
you
have
some
sense
that
there
are
some
important
like
consensus,
rules
that
are
being
followed.
The
consensus
protocol
enforces
these
rules
and
then
it
just
basically,
you
know
secretes
or
emits
these
withdrawals
whenever
it's
safe
to
do
so.
B
Like
quote
old
credentials
and
they're
marked
with
this.
Like
version,
byte
is
zero
zero
and
in
order
to
execute
a
withdrawal,
you
need
to
have
an
address
that
points
to
you
know
some
evm
account.
So
we
have
these.
This
new
withdrawal
credential
called
a
zero
one
credential
at
least
that's
the
version.
Byte
and
there'll
be
a
way
to
switch,
and
this
is
something
you
must
do,
there's
no
way
to
have
accounts
on
the
beacon
chain
or
in
the
beacon
state
or
anything
like
this,
and
so
this
is
something
you'll
have
to
do.
B
Process
these
withdrawals
at
the
execution
layer
and
the
big
question
here
is,
like
this
whole
notion
of
pull
versus
push,
and
so
those
words
are,
like
you
know,
very
leading.
The
idea
is
very
much
like
okay,
think
about.
If
you
are
sort
of
you
know,
executing
the
withdrawal,
then
you
have
this
huge
pile
of
beef.
Hopefully,
and
the
question
is
like
do,
do
I
pull
it
from
the
the
consistent
layer
to
me
or
do
I
have
because
this
layer
push
it
to
me
right
and
the
intuition
there
is
like
with
push
releases.
B
You
can
kind
of
have
someone
else
do
like
some
of
the
work
and
we'll
see
what
that
means
in
a
second
and
then
yeah,
there's
a
question
of
like
how
do
you
actually
credit
credit
b
in
the
execution
layer
in
the
evm
state
once
once
it's
been
processed
or
received
right?
Okay,
so
I
will
talk
about
pool
style
because
sort
of
historically
that's
what
we
sort
of
looked
at
first
and
what
that
basically
means
is.
Okay,
I
come
to
ethereum
like
I
come
to
the
chain
and
I'm
like
hey.
B
B
B
I
could
just
keep
catching
it
right.
I
could
just
loop
forever
and
what
that
would
do
in
practice
is
print
teeth
and
lots
of
things
start
breaking,
so
we
don't
want
that
either.
So
these
are
two
very
important
tasks
for
the
first
one.
We
have
some
very
convenient
property
that
the
beacon
states
is
described
with
this
thing
called
ssc,
and
what
that
means
is
that
built
in
it.
Has
this
like
merkle
tree
structure
and
that's
important,
because
then
you
can
make
proofs
about
things
in
the
beacon
state.
B
If
you
know
the
state
route,
so
I'll
go
back
for
a
second,
it
gives
a
little
yeah.
So
again
I
try
to
like
jot
down
these
notes
about
what
the
beacon
say
might
look
like
what
this
really
means
is
that,
like
each
of
these
values
is,
if
you
imagine
like
a
merkle
tree
I'll
assume
people
are
familiar
with
that,
but
essentially
imagine
this
tree
structure.
B
Each
of
these
fields
on
this
list
of
notes
is
essentially
a
leaf
in
the
tree
or
like
it
has
you
know
some
node.
It
makes
some
subtree
in
this
this
whole
tree
and
then
what
that
means
is
that
for
any
piece
of
data
you
want
to
pick
in
the
entire
state,
you
can
make
a
miracle
proof
from
that
piece
all
the
way
up
to
the
bridge
and
that
would,
for
example,
you
put
in
a
list
of
withdrawals,
include
withdrawals.
B
B
Is
like
all
the
balances
of
those
validators
and
then
imagine,
there's
like
a
tree
appended
to
the
end
and
that's
like
the
list
of
withdrawals
and
then
like
I'm
trying
to
suggest
here.
You
can
then
make
vertical
proofs.
So
imagine
I
wanted
a
proof
that,
like
you
know,
the
second
withdrawal
was
actually
in
this
list.
Well
I
can.
I
can
do
that
if
there's
some
way
that
the
evm
knew
about
the
route,
then
I
could
give
you
this
proof,
along
with
the
withdrawal
and
you
could
you
know,
watch
within
the
uvm.
B
I
do
want
to
call
it
out,
because
there
are
a
lot
of
other
cool
things
that
we
can
do
around
like
staking
pools
and,
like
I
don't
know
just
having
access
to
finality.
Like
there's
so
many
applications
that
you
could
imagine
in
terms
of
being
able
to
sort
of
trustlessly
access,
the
beacon
state
inside
the
avm,
so.
A
B
B
B
It
could
live
in
like
a
lot
of
different
places,
but
one
that
was
like
kind
of
interesting
and
like
probably
makes
the
most
sense
is
to
like
somehow
have
it
in
the
evm
state
and
basically,
what
this
means
is
that,
in
order
to
access
this
thing,
it
would
kind
of
look
like
a
pre-compile.
So
we
have
these.
B
You
can
basically
say:
okay,
here's
this
like
native
implementation,
that
does
the
the
operation
and
we
can
basically
price
it
differently
in
terms
of
gas,
otherwise,
it'd
be
like
way
too
expensive
to
do
a
lot
of
this
stuff.
So
there's
like
some
of
our
pre-compiles
an
important
bit,
though,
is
that
they're
all
quote
stateless,
meaning,
like
you
know,
there's
like
a
shot
two
five,
six
for
you
compile
right
and
this
freaking
pile.
Doesn't
track
like
the
last
thing
you
hashed
or
the
la
the
the
current
hash
like
it
doesn't
do
anything.
B
It
just
says:
here's
the
fights
and
you'll
get
some
fights
back
and
like
as
someone
using
the
evm.
I
can
basically
make
a
call
to
that
account
and
do
this
operation,
but
I
can't
you
know
there
there's
no,
there's
no
state
that
like
lives
here,
whereas
like,
for
example,
if
you
had
a
regular
smart
contract
in
the
evm,
it
definitely
has
state,
and
that's
in
fact,
like
you
know,
one
of
the
very
special
things
about
the
ubm
either
way
there
are
no
stateful
precompiled.
B
B
Basically,
it's
like
this,
isn't
just
a
user
level
thing
like
there's
some
special
rules
that
we'd
have
to
like
apply
to
it
to
track
these
these
withdrawals
and
so
either
way.
That's
what
it
is
and
then
yeah
just
to
kind
of
round
up
the
questions
I
had.
The
question
is
like:
okay,
assuming
we
had
a
way
to
like
make
proofs
about
withdrawals
if
the
if
they
were
valid
or
not,
and
then
also
we
had
a
way
to
track
which
withdrawals
if
it
consumes.
B
B
It
actually
ends
up
on
the
beacon
chain,
but
then
it
has
to
come
back
from
the
beacon
chain.
So,
like
beef
has
to
come
somewhere.
The
question
question's
aware
and
again
it
kind
of
depends
on
like
the
implementation.
You
imagine.
If
there's
like
some
system
contracts,
maybe
you
can
just
credit
it
kind
of
like
with
the
coinbase
today
right
so
like
with
every
block.
There's
like
some
block
reward.
It
just
comes
out
of
nowhere.
You
could
also
imagine-
and
this.
B
When
we
were
talking
for
a
bit
about
basically
having
a
withdrawal
contract
to
mirror
the
deposit
contract,
and
if
we
did
that
some
sort
of
like
a
very
sort
of
quick
and
dirty
idea
is
you'd
actually
just
put
as
much
eve
as
possible
into
the
contract
and
then
from
there
just
like
a
norm,
it
would
look
like
a
normal
contract
transfer,
which
happens
all
the
time.
It
definitely
would
like
require
the
least
amount
of
like,
for
example,
core
developer
work
or
like
client
work.
B
B
So
just
end
to
end
what
does
this
all
look
like
if
we
were
to
go
this
route
with
full
style
withdrawals
and
essentially
what
user
would
say
is
hey
here's
my
overwithdrawal
receipt
at
like
index
I
in
this
list
it
says
I
owed
this
much
eth
and
like
also
here's
a
proof
that
would
go
to
like
the
staple
precomp
file
thing.
Something
like
this,
the
system
would
say:
okay,
I'm
gonna
verify
the
proof
against
the
beacon
route
that
I
have,
because
I
have
it
somehow
that
looks
good.
B
B
Here
is
that
this
doesn't
have
that
much
to
do.
I
think
the
only
real
thing
you
needed
to
do
well,
it
depends
on
how
you
handle
this
like
stapler
compile,
but
there
is
actually
not
much
that
like
we
needed,
you
know
you
would
need
to
do
in
terms
of
client
development
and
like
actually
writing
new
code,
because
really
you
could
just
imagine
having
the
beacon
state
route
provided
with
evm
and
then
the
rest
of
it
could
be
done
in
user
space.
B
There
could
actually
just
be
a
draw
contract,
and
so
what
that
means
is
now
you
know
it's
not.
Unlike
the
guth
team,
the
messaging
detected
team
one
jumping
now,
but
you
know
who
did
I
miss
aragon?
Another
mind,
point
being:
is
you
don't
have
to
have
the
execution
clients
like
put
all
this
stuff
in
someone
else
is.
Could
right
you
have
a
different
team.
That's
like
writing
this
contract.
They
could
do
formal
verification
of
the
thing,
and
that
could
all
happen
in
parallel,
so
that
was
seemed
like
a
very
nice
benefit.
B
But
then
you
look
at
like
again
the
cost
the
downsides
to
this
there's
this
whole
new
thing
of
like
a
stateful
precompile,
there's
no
prior
precedent
for
that.
We
may
have
something
like
it
one
day,
but
it's
like
definitely
a
new
thing
and,
like
I
think,
historically,
the
source
of
most
sort
of
consensus
failures
on
test
nets,
for
example
like
when
we
go
to
test
all
the
new
stuff
we
do.
B
A
big
big
source
here
is
like
evm
inconsistencies,
so
we
don't
necessarily
want
this
like
new
evm
concept,
if
we
can
avoid
it
and
also
yeah
scheduling
is
on
the
user,
and
so
what
that
means?
Is
you
know
to
do
this?
I
am
initiating
an
edm
transaction,
so
I
have
to
like
there's
gas.
I
have
to
pay
for
the
gas
it
also
is
taking.
B
You
know
that
block
space
away
from
other
people,
so,
ultimately
taking
this
all
in
stride,
it
was
decided
that,
like
this
wasn't
the
preferred
path,
because
we
can
basically
make
it
much
simpler.
So
we'll
look
at
that
now-
and
this
is
the
other
thing
I
mentioned-
about
push
withdrawals.
So
the
general
concepts
are
the
same.
B
If
you
imagine,
there's,
like
you
know,
withdrawals
two,
two,
two
two
two
three
two,
two
four,
those
are
like
indices,
for
example,
in
this
queue
you
can
imagine
like
within
the
next
block.
You
like
pop
off
two
two
three,
two,
three
four
right
and
I
tried
to
draw
like
an
empty
inbox,
and
then
you
see
them
sorry,
you
see
them
in
the
the
inbox
on
the
bottom
right
there
and
then
still,
you
know
the
cl
still
has
these
other
withdrawals
in
the
queue
and
so
yeah.
B
A
B
B
You
know
reserving
block
space
for
them,
because
they're
now,
just
like
separately
pushed
into
the
evm
and
they're
just
handled
on
their
own.
You
don't
have
to
like
do
the
speaking
stateroom
thing,
so
we
don't
need
the
priory
ip
dimensions.
You
don't
need
the
staple
precompile
so
like
all
this
complexity
is
just
kind
of
not
necessary.
So
that's
why
this
is
the
preferred
path.
Again,
it's
like
much
simpler.
Like
I
said
you
basically
from
the
execution
life
perspective.
You
just
get
these
things.
B
So
for
the
end
user,
you
know
again:
what's
the
it
didn't
flow?
What
does
this
look
like?
As
a
user?
You
actually
don't
have
to
do
anything
other
than
be
a
good
validator
that
doesn't
use
a
majority
client.
That's
my
tongue-in-cheek
call
to
improve
that
and
as
a
system
yeah
you
just
you.
Basically
an
execution
layer
seizes
withdrawals
and
you
just
apply
like
a
few
balance
updates
every
block.
Let's
say
so:
it's
it's
much
simpler
for
your
moving
parts
for
sure.
A
B
So
we've
covered
these
questions,
which
is
like
again
when
is
it
safe
to
withdrawal?
Well,
the
consensus
layer
will
manage
this
queue
of
them
and
basically
just
provide
them
to
the
execution
layer
when
it's
the
right
time
how's
that
signaled,
while
they're
just
again
provided
in
a
way
that
we'll
see
in
a
second
and
then
yeah,
the
accounting
actually
is
pretty
straightforward.
You
can
just
add
balances
much
like
we
do
with
the
coinbase
today
and
that's
something
that
we
know
how
to
do,
and
it's
simple
and
straightforward.
B
A
B
Okay,
these
things
are
pushed
somehow,
but
they
do
still
need
to
have
like
some
representation
like
each
stage
of
the
pipeline
and
because
this
layer
we're
lucky
there
there's
like
an
ssd
schema.
So
basically,
there's,
like
you
know
by
writing
down
these
things
that
withdrawals.
This
is
what
I
try
to
do
graphic
on
the
right
here,
where
it
says
withdrawal-
and
these
amounts
like
when
you,
when
you
write
this
down,
there's
like
a
specific
sterilization
that
we
get.
B
So
that's
really
helpful,
and
let
me
jump
back
to
here
so
then
there's
now
some
interface
between
the
consensus
layer
and
the
execution
layer,
and
I
called
it
a
free
parameter.
The
idea
is
like
as
long
as
you
get
the
data
across
it
doesn't
really
matter
what
it's
like.
You
know,
there's
some
json
rpc.
B
Turning
into
a
request
to
the
execution
client
to
then
go
like
sync,
some
fork,
it
didn't
know
about
or
something
right
and
basically
you
don't
want
these
two
clients
to
have
to
be
like
locked
on
each
other.
They
should
have
enough
autonomy
to
like
go
and
basically
get
a
full
view
of
the
network
as
desired.
B
So
what
that
means
is
that
you
may
end
up
passing
around
you
know.
Well,
you'd
at
least
have
a
representation
of
withdrawals
in
these
blocks
that,
like
the
execution
client,
would
have
because
it
might
be
like
processing
them
off
on
some
fork,
without
necessarily
going
to
consist
of
this
client
and
being
like
hey.
B
You
know
what
was
the
withdrawal
two
two
three
or
two
two
four
like
I
don't
know
right,
so
we
need
some
way
to
to
describe
that,
and
this
is
another
sort
of
like
design
decision
point
that
we
came
to
and
again
there's
sort
of
like
a
quirky
dirty
solution.
There's
also
like
a
much
cleaner
solution,
we're
going
with
a
much
cleaner
solution,
but
one
way
we
could
have
done.
This
was
basically
there's
a
notion
of
transaction
types
from
eip2718
and,
for
example,
listeners
almost
certainly
familiar
with
eip1559.
B
The
way
that
that
is
written
is
there's
actually
a
type
two
transaction,
that's
different
from
type
one
or
type,
zero,
there's
a
legacy
type
anyway.
The
point
is
is
that
we
could
have
made
a
new
transaction
type
and
just
like
shove,
the
withdrawal
information
into
that.
So
it
would
work.
It's
not
very
clean,
though
especially
from
like
a
conceptual
perspective,
because
these
things
aren't
user
level
transactions.
If
anything,
they're
like
system
operations,
which
is
the
language
we'll
get
to
there,
was
an
erp
to
go
down
this
road
4863.
B
I
linked
to
it
here
and
yeah.
You
know
we
could
go
find
the
all
core
devs
call,
but
essentially
we
like
talked
about
this
and
the
general
consensus
was
like
hey:
let's,
let's
not
abuse
transactions
in
this
way,
and
so
instead
you
don't
touch
user
level
transactions.
We
have
this
new
type
of
thing
called
operation
and
yeah.
That's
I
specified
today
eip4895
where
things
are
at
again
the
benefits.
Here
you
don't
mix
the
concerns.
It's
like
the
withdrawals
of
firewall
off
completely.
You
don't
have
to
worry
about
like
okay.
B
A
B
B
B
The
question
is
like
okay,
if
I
have
more
than
that,
which
I
can
accrue
just
by
doing
my
job
and
like
accumulating
rewards
like
what
happens
in
terms
of
protocol
security,
this
extra
youth
is
like
actually
not
really
adding
much,
and
so
then
the
question
is
like
okay
like
well.
If
it's
just
sitting
there,
that's
not
capital
efficient,
like
we
should
be
able
to
do
something
about
that,
and
so
this
is
what
we
say.
A
partial
withdrawal
is.
The
idea
is
that
every.
A
B
Your
32,
then
we're
going
to
basically
make
a
withdrawal
for
you
that
will
then
go
into
this
queue.
I
was
just
talking
about
sorry
and
everything
else
is
the
same
from
there.
So
yeah
there's
a
pr
or
working
some
of
the
details
again.
The
idea
is
it's
like
this
automatic
process,
where
you
can
just
imagine
again
this
background
thing.
That's
like
running
and
just
slowly
scanning
through
the
entire
set
circling
back
through
skinning
through
the
entire
set.
B
B
A
B
B
So
definitely
go
there.
If
you
want
to
dive
into
more
of
the
details,
yeah
and
then
just
like
some
takeaways
as
a
validator,
the
only
thing
you
really
have
to
do
is
swap
from
your
zero
zero
credentials.
If
you
have
them
to
zero
one
and
then
from
there,
it
should
be
a
pretty
straightforward
automatic
process
when
the
right
conditions
are
met,
and
then
your
ether
will
just
appear
at
your
equal
address.
I'm
choosing
and
of
course
the
question
is
always
when
so
the
cip
and
also
the
consistent
changes
are
now
cfi.
B
For
shanghai,
cfi
is
considered
for
inclusion,
shanghai's
the
merge
after
sorry,
the
fork
after
the
merch
and
yeah.
So
basically
the
merge
will
happen,
hopefully
very
soon
and
then
from
there.
You
know
the
next
work
that
we
can
pull
off.
We'll
have
these
changes
and
these
features
will
go,
live
I'll
have
to
note,
like
the
shanghai
sort
of
planning
dock.
If
anyone
wants
to
see
what
else
is
on
on
the
plate,
but
48.95
was
definitely
one
of
them
and
I
believe
that
is
it
so
yeah.
A
Thank
you.
Thank
you
for
this
amazing
talk,
the
presentation
was
awesome
and
the
explanation
that
you
have
provided.
I
think
it's
going
to
be
helpful
for
many
people
who
are
even
watching
it
for
the
first
time
like
if
they
are
learning
about
the
beacon
chain
and
the
pus
process
for
the
first
time.
So
thank
you
for
explaining
this
concept
in
such
a
simple
way,
really
appreciate
it.
A
I
know
there
were
multiple
options
available.
You
did
talk
about
all
those
proposals
which
were
there
the
pull
and
the
push,
and
then
we
came
up
came
down
to
eap
4895
for
cfi
in
shanghai.
This
means
that
this
is
one
of
the
best
proposals.
Those
were
available
and,
in
my
mind
it
is
like
the
missing
key
to
the
fully
functional
pos.
Anything
though
you
have
already
answered
most
of
the
questions.
A
B
Yeah
you'll,
probably
if
you're
earlier
in
the
set
you
know
by
index,
then
you'll
get
you'll.
You
know
the
process
will
get
to
you
before
others,
but
yeah.
Essentially,
what
could
happen
is
if
you're
validating
you're
like
okay,
I've
been
doing
this
for
like
a
year
or
whatever,
like
I'm
done.
I
want
to
take
a
break.
You
can
do
that.
You
would
probably
issue
an
exit
and
then
with
the
exits,
you
would
then
go
into
this
exit
queue
and
again.
B
This
is
where
you
end
up
with
a
very
critical
piece
for
proof
of
stake.
Security
is
that
you
can't
like
it
wouldn't
work.
If
you
could
suddenly
have
like
half
of
the
set
exit,
because
then
it
wouldn't
be
uncomfortable,
and
so
the
way
that
you
keep
it
accountable
is
basically
you
you
have
this
like
delay
in
between
when
they
exit
and
when
or
when
they
you
know
when
they
want
to
exit
when
it
actually
takes
effect,
and
the
idea
is
that
the
east
is.
Your
stake
is
still
at
risk
this
whole
time.
A
A
B
Thank
you
right
and
yeah,
and
I
will
say
this
is
why
there's
there's
a
lot
of
desire
to
have
something
like
partial
withdrawals,
because
if
you
didn't
have
this,
then
you
would
have
sort
of
this
like
thunder,
instantiated
problem
where,
like
suddenly,
everyone
needs
to
exit
fully
like,
and
then
you
just
clog
the
execute.
So
this
is
the
idea
with
partial
withdrawals
is
that
you
have
like
if
there
is
sort
of
extra
ease
that
is
not
required
for
security,
then
it's
a
way
to
think
about.
B
A
A
My
next
question
is
related
to
the
withdrawal
flow,
so
it
is
about
the
timing
and
the
mev
impact.
The
eap
suggests
the
withdrawals
in
a
block
are
processed
after
any
user
level,
transactions
are
applied.
How
do
you
think
withdrawal
processing
before
and
after
any
user
level
transaction
affect
the
mav
searching
situation.
B
Yeah,
that's
a
good
question,
so
I
think
the
short
answer
is
that
it
doesn't
really
matter.
There's
actually
some
interesting
discussion
about
this
on
the
fellowship
of
magicians,
which
is
a
forum
we
have
for
eip
discussion
and
different
things
like
this.
So
if
you
go
find
the
if
he
imposed
for
eip4895,
there's
actually
some
conversation
about
this
exact
point:
the
choice
is
okay.
If
we
do
have
these
withdrawals
either
well,
yeah,
really,
this
is
more
for
the
push
design,
but
either
way
you
have.
B
B
For
efficiency
reasons
and
the
question
is
you
have
this
bash?
Do
you
put
it
before
all
the
other
user
transactions
or
at
the
end,
and
you
could
probably
go
either
way?
I
will
say
that
if
it
goes
after
that's
how
we
handle
the
coinbase
right
now
and
so
there's
some
symmetry
there.
It's
like
fewer,
like
differences
to
remember
when
you're
trying
to
like
you
know
reason
about
the
protocol.
So
that's
nice
yeah,
but
there's
like
a
bit
more
to
say,
but
that's
that's
the
highlight
it
doesn't
really
matter.
A
A
A
B
Nothing
comes
to
mind.
I
do
not
think
we
would
have
the
cfi
status
if
people
felt
this
wasn't
in
a
place
where
it
essentially
just
needs
to
be
implemented
and
then
shipped
again.
There
certainly
are
security
considerations,
but
they've
already
been
baked
into
like
the
way
that
we
are
designing,
developing
and
shipping
the
beacon
chain
that
consists
layer,
all
that
yeah
there
aren't
any
like
huge,
open-ended
questions.
B
If
anything
there,
there
were
potential
questions,
but
they've
been
answered,
and
that
was
sort
of
this,
like
you
know
when
I
walked
us
through
this
sort
of
design
space.
With
this
talk,
that
was
the
process
we've
already
gone
through,
was
to
like
answer
those
questions
and
so
yeah.
There's
like
nothing,
there's
nothing
like
suddenly.
That
would
pop
out
of
nowhere
that
I'm
aware
of
that
would
be
like
oh
yeah.
This
isn't
going
to
work
right
like
start
from
scratch,
any
of
that
yeah
should
be
ready
to
go.
A
I
hope
so
generally
a
core
proposal,
and
especially
when
it
comes
to
dealing
with
money
or
the
ether
people
worry
about
like
how
careful
are
we,
and
I
really
do
trust
on
the
ethereum
client
developers
team
if
they
have
put
it
into
cfi?
That
means
a
lot
and
might
have
considered
whatever
can
be
considered
at
this
stage.
Maybe
in
later
stage,
if
anything
is
identified,
may
require
further
research.
B
A
So
I
suppose
the
request
here
from
the
editors
is
to
consider
this
proposal
to
not
include
the
mention
of
the
omer
list,
as
well
as
also
the
mention
of
eip
3675,
because
it
seems
like
these
are
too
much
information
tmi
and
may
not
be
needed
for
for
general
implementers.
This
is
good
piece
of
information,
but
may
not
be
directly
related
to
keeping
it
as
a
part
of
proposal.
What
are
your.
B
Yeah
I
agree,
I
saw
similar
comments
and
it's
on
my
to-do
list
to
go
update
the
ip
to
make
those
edits.
I
don't
think
I
don't
think
they're
terrible
there,
but
I
hear
the
argument
that
you
know
for
this.
Erp
we
wanted
to
be
super
polished
would
be
like
a
very
particular
thing
where
it
is
just
those
exact
changes
required
to
implement
the
future.
So.
B
A
Good
to
hear
that,
I'm
not
sure
if
there
is
any
rules
for
this
kind
of
information
being
added
to
eip,
but
it
is
always
good
to
have
a
cleaner
and
smaller
eip.
It's
not
only
helpful
to
edit
us,
but
for
other
people
to
you
know
understand
in
a
simple
way.
Thank
you.
My
last
question,
for
you
is,
is
something
that
I
have
been
trying
to
understand.
A
You
did
mention
about
the
changes
that
are
being
brought
by
this
proposal
and
two
of
the
most
important
changes
are
like
addition
of
withdrawal
route
to
the
header
and
the
other
one
is
the
addition
of
withdrawal
data
to
the
block
body.
So
these
are
two
different
parts,
one
for
core.
Changing
the
consensus
rule
one
for
networking.
Why
not
to
have
two
separate
proposals?
Why
do
we
want
to
have
it
bundled
together
in
one
proposal.
B
Right
so
kind
of,
like
I
was
saying
the
previous
question.
Some
of
this
is
like
down
to
the
actual
like
sort
of
syntax
of
vips
and
I'm
very
open
to
like
changing
the
ip
to
like
fit
more
in
line
with
what,
for
example,
the
ip
editors
expect
so
yeah,
I
think
there's
definitely
room
to
split
some
of
that
out.
B
I
think,
in
terms
of
like
communicating,
because,
like
again,
there
was
this
like
history
and
this
moment
of
a
process
of
working
through
different
designs,
and
it
was
helpful
just
to
have
like
one
eip.
That
did
everything
you
know
and
I
just
like
had
it
all
in
one
place.
Certainly
it
makes
sense
to
revisit
now,
especially
that
we've
all
agreed
to
like
the
general
approach
like
how
yeah
what
should
go
to
vip.
How
does
that
look
like?
There
are
some
things
that
are
network
and
level
concerns
so
again
also.
B
A
Yeah,
I
think
so
it
will
be
really
helpful
because
when
we
are
having
it
into
two
separate
eips,
if
something
is
changed
for
one
particular,
you
know
piece
of
the
code
there
that
will
be
affecting
only
one
proposal
and,
moreover,
networking
eip,
I'm
not
sure
if
that
needs
to
go
on
the
devnet
when
they're,
when
it
is
getting
prepared
for
the
for
any
hard
fork.
So
it
will
be
easier
for
even
implementing
implementation
team
right.
B
A
B
B
That's,
I
think
now,
where
a
lot
of
the
core
developers
and
co
are
focusing
their
efforts
and
that's
the
area.
I
think
that
we
feel,
like
you
know,
even
today,
like
needs
the
most
attention
so
you're
watching
this,
because
you
like
our
validator
and
you
wanted
to
learn
how
to
work
like
this
is
great
it's
coming
up,
but
there's
work
to
do
in
the
meantime,
so
run
some
more
nodes
file
web
reports.
If
there's
even
documentation
you
can
you
know
you
can
improve,
then
by
all
means.
A
A
It
is
even
helpful
before
we
actually
get
to
the
proposal,
because
the
way
it
is
explained
that
that
provides
the
entire
context,
the
history
that
okay,
fine,
even
if
we
are
not
going
through
the
pull
process,
it
explains
that
it
was
there
at
some
point
of
time.
So
I
think
that's
a
good
best
practices,
kind
of
thing
that
maybe
other
authors
can
follow
and
help
us
go
along
the
journey.
B
A
A
If
you
like,
this
episode,
hit
like
and
share
to
increase
the
reach,
we
want
all
these
information
to
be
shared
with
with
the
community
more
and
more
so,
though
they
be
able
to
participate
not
only
to
the
merge
testing,
but
also
in
in
the
process
of
helping
out
a
proposal
to
get
into
the
next
status.
So
please
join
the
discussion
at
discussion
tooling,
provided
in
the
description.
A
Should
you
have
any
question
on
this
or
any
other
proposal?
Let
us
know
in
comment
section
or
share
us
with
on
eth
catalyst.
Discord
subscribe
to
ethereum
categories
youtube
channel.
If
you
haven't
done
it
already
see
you
next
time
with
another
interesting
talk
till
then
keep
watching
keep
sharing
your
love
with
ethereum
cat
hair
have
a
good
rest
of
the
day.