►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/its-10pm-do-you-know-where-your-mnemonic-is/
Many stakers set up their validators nearly two years ago, and will soon need to revisit them to obtain the rewards they have earned since.
This panel provides a refresher for what stakers did, and why they did it. It discusses protecting mnemonics and keys, and what can be done if they are misplaced or compromised.
Bringing together experts on validating key creation, protection and use, this is a wide-ranging discussion that will be useful for all stakers and potential stakers.
Speaker(s): Adrian Sutton, Oisín Kyne, Paul Hauner, Vasiliy Shapovalov
Track: Staking & Validator Experience
Keywords: staking,withdrawals,security
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
B
B
B
We're
going
to
look
back
at
you
know,
what's
been
done
on
the
key
security
side
for
the
last,
while
we're
gonna
see
what
things
are
looking
like
right
now
in
terms
of
validator
key
security
and
then
we're
going
to
look
a
bit
forward
towards
withdrawals
which
I'm
sure
lots
of
people
want
to
know
about,
but
before
I
get
to
that,
I
would
like
to
do
a
few
introductions.
Will
this
gonna
work
for
me?
Probably
not.
A
B
I
know
it
is
oh
yeah.
Now
it's
connected
three,
so
briefly,
I'll
introduce
myself.
My
name
is
ocean
kind,
I'm
co-founder
at
oboe
Labs
we
build
distributed
validator
technology,
which
is
the
ability
to
run
one
validator
across
multiple
machines
by
multiple
entities
and
yeah.
That's
my
little
quick
intro
I'd
like
to
introduce
Paul
next
hello.
D
Hi
I'm
Adrian
Sutton
I'm,
with
consensus
and
I,
started
out
on
the
basic
team.
Doing
the
execution
layer
side
before
there
was
an
idea
of
a
consensus
layer,
side,
I
spent
about
a
year
and
a
half
pretty
much
full
time
on
Basu
and
then
switched
over
to
techu,
because
I
heard
that
Beacon
chain
was
the
new
hotness
and
teku
is
a
consensus
client.
So
I've
spent
the
last
oh
I,
don't
know
three
to
four
years,
helping
build
that
and
bring
the
merge
to
fruition.
D
B
Awesome
so
we're
gonna
like
test
that
and
figure
out
some
of
the
good,
bad
and
ugly
about
managing
private
Keys,
so
yeah,
so
the
first
thing
I
want
to
do
is
look
back
a
little
about
how
it
started
and
figure
out.
You
know
some
of
the
basics
about
what
is
a
mnemonic
and
stuff,
so
I
thought
Paul.
Would
you
explain
to
us
what
a
mnemonic
is.
C
Oh
yeah
sure
so,
I'm
not
sure
I
can
get
a
textbook
definition,
but
a
mnemonic
is
a
series
of
words.
A
phrase
say:
20
12
to
24
variable
length,
I.
Think
it's
I
think
24
is
a
standard
in
in
F2.
So
a
bunch
of
words
easy
to
remember
supposedly
and
then
from
those
words
you
can,
you
can
generate
any
number
of
validated
keys,
so
there'd
be
signing
keys.
That
would
throw
a
keys.
B
D
Any
kind
of
secret
key,
that's
loaded
into
memory
and
hot
on
a
machine
is
not
as
secure
as
something
that's
locked
up
in
a
safe,
so
they're
at
a
higher
risk
of
being
stolen.
You
still
do
your
best
to
to
secure
them
and
secure
the
machine.
Obviously,
but
we
wanted
to
make
sure
that
there's
a
a
big
difference
between
those
hotkeys
that
that
run
your
valdern
sign
things
and
the
keys
that
actually
control
the
money
and
and
whether
you
can
re
withdraw
it
so
from
your
mnemonic.
D
By
default,
you
would
generate
a
validator
key
using
One
path
and,
as
Paul
said,
you
can
generate
multiple
keys
so
from
a
different
path.
You
get
a
separate
validator
key
and
it's
that
validator
key
that
you
will
use
once
withdrawals
are
implemented
to
set
up,
withdrawals
and
be
able
to
to
actually
recover
your
money
again.
D
Do
they
have
to
come
from
the
same
mnemonic?
No,
they
don't
you
don't
even
have
to
use
a
mnemonic.
You
can
just
generate
the
keys
directly
without
going
through
the
mnemonic
process,
but
typically
it's
a
lot
easier
to
back
up
one
mnemonic
and
not
lose
it
and
etch
it
into
steel
or
whatever.
It
is
and
store
it
in
a
safe.
Well,
then,
to
have
multiple
keys
that
are,
you
know,
being
managed
and
able
to
be
lost,
because
if
you
lose
your
withdrawal
key,
that's
it
it's
game
over
you're,
not
getting
your
32
weeks
back.
B
B
It's
unfortunate.
We
were
supposed
to
have
one
more
panelist,
Jim
McDonald
and
he's
done
a
lot
of
work
in
this
specific
problem,
but
the
reason
that
this
thing
is
titled
is
10
pm.
Do
you
know
where
your
mnemonic
is
is
because
some
unfortunate
people
have
had
these
mnemonics
compromised
over
the
last
two
years
and
I
was
wondering
if
you
guys
wanted
to
kind
of
explain
what
Jim's
proposal
is
for
for
how
we
kind
of
straightened
this
out
but
yeah?
What's
what
is
the
problem?
If
somebody
has
your
mnemonic.
E
Well,
so,
basically,
if
you
used
these
the
the
same
amount
to
generate
the
value
data,
key
and
withdrawal
key
and
withdraw
credentials,
which
is
most
homesteakers
users,
but
it's
much
less
often
happening
for
big
operations
where
it's
usually
different,
Keys
more
owned
by
different
people.
So
if
it's
the
same
the
same
mnemonic,
it
was
used
to
like
what
is
going
to
happen.
E
Is
that
now
the
the
malicious
person
who
compromised
the
key
they
can
like
you're
in
a
race
to
who
can
slash
the
protocol
like
Clash
Royale
data
first,
which
is
if
your
small
validator,
is
not
like
really
a
bigger
problem?
You
stop
validation,
you
get
very
small
fine,
so
let's
selection
penalty
and
it's
not
that
involved,
but
withdrawal
key
compromised
means
that
they
can,
when,
when
the
validator
exits
and
withdrawals
implemented
in
the
human
protocol,
upgrades
allows
to
either
to
get
back
to
execution.
A
B
E
E
C
B
Hey
thank
you
for
teaming
me
up
for
my
next
question,
which
is
to
talk
a
little
bit
about
where
things
went
wrong
with
the
ox0
ones,
and
there
was
like
basically
well
there's
your
hotkeys
and
your
withdrawal
keys
and
there's
like
two
different
ones.
I
wanted
to
touch
on
where
there
were
problems.
The
first
one
is
stake.us
and
the
hotkey
issue.
Does
anyone
explain
what
happened
it's
quite
a
while
ago
it
was
only
two
two
years
there
was
175
validated
slashed
because
they
were
running
the
hotkeys
in
two
different
places.
E
Quite
quite
simple
to
understand,
so
stakehold
is
a
big,
sophisticated
or
not
operator.
They
they
run
like
I,
think
maybe
billions,
maybe
hundreds
of
millions
of
stake,
a
lot
of
them
and
they
have
sophisticated
setups.
So
like
one
of
the
the
feature
they
used
in
in
multiple
protocols
was
they
had
implemented,
something
like
like
in
a
something
that
in
traditional
world
would
be
called
like
web
application
firewall.
E
I'm
not
like
100
sure
that,
because
otherwise
it
could
be,
it
could
have
been
that
they
accidentally
deployed
it
like
to
the
two
things
in
Parable,
not
not
like
at
the
as
the
usual
setup.
But
anyway
they
did.
They
did
have
an
automated
system
for
liveness.
That
at
times
could
have
run
multiple
validators
with
the
same
private
key,
which
is
usually
lead
to
slashable
offense
in
in
protocols,
including
them,
and
they
had
a
system
to
that
should
have
caught
the
the
problems
which
is
like.
E
Usually
people
don't
do
that
like
right
in
in
not
operator
setup,
because
liveness
is
not
as
important
as
safety
slashing
for
for
lack
of
for
so
for
for
missing
a
few
blocks
much
much
much
lesser
than
slashing
liquid
penalties
for
for
double
sign.
It's
like
not
worth
it
usually,
so
that
system
didn't
work
and
they
for
about
like
40
minutes
or
like
about
an
hour.
E
Don't
like
really
like
rookie
numbers
right
so
and
that's
the
case,
because
not
a
lot
of
validators
had
had
issued
the
invalid
block
solid
stations,
because
it's
not
like
you,
you
don't
run
the
with
your
stake
on
a
single
note
like
in
many
other
systems.
Otherwise
they
would
have
like
five
percent
slash
or
like
15
slash,
which
is
like
much
much
higher
and
only
after
that
they
monitoring
and
the
Learning
System
had
triggers
so
like
they're
they're
in
this
with
this
problem
for
a
long
time.
C
I
think
initially
described
the
setup
is
sophisticated.
I
think
that
was
a
very
kind
way
to
refer
to
it.
I
would
I
would
call
it
dangerously
over
complicated,
but
yeah
I
agree.
I
think
that
these
setups,
where
you're
running
multiple
instances
of
the
same
key
in
any
place,
I
think
you
you
really
like
Wesley,
said
you're
just
prioritizing
liveness
over
safety
and
it's
it's
I
think
it's
really
bad
business.
It's
not
it's
not
good!
Economically,
it's
really
bad
for
your
reputation
and
it's
bad
for
the
network
as
well.
D
D
B
Yeah
for
sure,
and
then,
as
you
mentioned,
slashing
you
don't
lose
all
your
money,
but,
as
you
touched
on
earlier,
if
there's
problems
with
withdrawal
Keys,
you
can
be
like
really
in
trouble.
There
was
one
other
very
famous
issue
about
two
years
ago
as
well
by
stakehound.
Does
anyone
remember
what
happened
there
with
their
withdrawal,
keys,
I.
D
E
Don't
know
why
that
happened
like
maybe
it
was
like
problem
on
the
software
side.
Maybe
those
problems
take-hand
side
on
Communications,
on
like
around
backups
system
like
that
bullet
and
lawsuits.
I,
think
right
now,
so
I'm
not
sure
about
that.
But
the
end
result
is
all
that
stake
about
72
million
by.
B
Quite
possibly
or
yeah,
going
through
like
annual
bit
of
Hardware,
they
can
find
but
yeah.
Thank
you
very
much
visily
for
giving
those
descriptions
and
preventing
me
from
having
to
do
it,
but
yeah
I.
Think
we
don't
necessarily
know
you
know
what
happened,
but
what
we
do
know
is
that,
if
anything
happens
to
your
withdrawal,
key
odds
are
very
high.
That
there's
nothing
you
can
do
so
with
that
in
mind,
Genesis
happened
in
December
2020
and
about
six
months
later,
so
there
was
a
change
to
withdrawal
credentials.
D
The
catch
with
it
is
a
is
a
minor
one
but
important
depending
on
how
you
write
your
contracts.
If
you,
you
can
use
any
ethereum
address,
it
can
be
a
contract,
but
the
evm
will
not
execute
when
funds
are
added
to
that.
So,
if
you're
expecting
log
events
to
come
out,
they
won't.
You
won't
have
that
opportunity.
B
And
then
Lido,
when
this
came
out
very
quickly
adopted
it.
Could
you
tell
me
a
bit
about
you
know
what
that
process
was
like
the
risk
of
writing
a
contract
for
something
that
doesn't
exist.
Yet,
how
did
that
kind
of
process
go
and
the
kind
of
migration
you
might
say,
but
there's
no
migration,
but
the
swap
out.
E
Yeah,
so
it
wasn't
too
hot,
actually
like
it's
like.
We
have
done
a
stop
that
is
governance
controlled
and
that
stop
will
be
like
sometimes
like
in
the
future.
When
this
is
also
implemented,
it
will
be
upgraded
and
when
the
ethereum
oscifies
enough,
it
will
be
made
unupgradable,
so
the
RC
files
as
well.
E
So
there
is
like
nothing
complicated
about
this,
like
just
a
smart
contract
that
that
is
a
stuff
that
does
nothing
except
being
upgraded.
Implementing
withdrawals,
handling,
withdrawals
due
to
the
fact
that,
like
you
can't
know
when,
like
you're
not
getting
triggered
when
either
comes
in
is
like
is
harder.
The
you
know
per
second
protocol
is
pretty
complex
and
we,
when
you
add
the
liquidity,
like
liquids
taken
protocol
complexness
on
top
of
it,
it's
it's
pretty
hard
research
to
to
do
it
just
right,
but
we'll
manage
so
sweet.
B
B
E
B
D
Think
I
think
you're
probably
keen
on
this,
but
the
oxo3
is
designed
to
be
a
forced
withdrawal.
So
at
the
moment
you
actually
wind
up
needing
both
your
hotkey
and
your
withdrawal
key
effectively
to
to
get
through
the
full
withdrawal
process,
because,
while
your
validator
is
active,
your
32
Heath
is
remains
locked
up.
You
need
to
exit
your
validator
and
then
it
can
go
through
the
withdrawal
process
and
that's
where
the
withdrawal
key
comes
in.
D
If,
however,
you're
staking
so
you're,
not
staking
yourself,
you've
asked
someone
else
to
stake
on
your
behalf
and
you've,
given
them
your
hotkeys,
knowing
that
they
can't
steal
your
eth,
because
you've
got
the
withdrawal
keys,
not
a
bad
setup.
You
have
one
little
problem
in
that.
You
can't
force
them
to
exit
your
validator
and
actually
get
your
eth
back,
and
so
the
oxo3
credentials
are
intended
to
be
a
way
of
the
withdrawal
credentials
being
able
to
force
exit
a
validator
effectively.
I,
don't
know
if
you
know
the
details
of
how
that
was
planned.
E
So
like
there
is
no
more
details
because,
like
it's
older
drafts,
but
I
think
that
zero
x
x,
zero,
three
equivalentials
are
completely
unnecessary,
they're,
just
a
feature
that
can
be
added
to
0x1
like
the
same
way
handled
this
much
the
same
way
as
deposits
to
the
container
and
like
just
like
consensus,
layer,
processing
messages
from
execution
layer
and
it's
not
even
too
hot.
It's
just
like
needs
to
be
designed
and
Implement
test
that
we
are
actually
working
on
right
now
on
design,
I,
don't
think
it
will.
E
D
So
we
kind
of
set
up
this
idea
that
the
money
will
go
to
whoever
has
the
withdrawal
key
and
the
signing
key
is
in
control
of
actual
signing
and
exit,
and
as
every
time
we
go
and
change
that
you
wind
up
with
a
whole
bunch
of
people
in
quite
unique
situations
that
were
built
around
that
particular
split
of
responsibilities.
And
when
you
change
the
split
you've
got
to
kind
of
make
sure
that
you
don't
break
things
for
other
people
or
introduce
insecurities
because
of
this
particular
way.
They've
set
things
up,
I.
D
I,
don't
know
yeah
I
think
that's
a
fairly
reasonable
one
that
you
know
the
base
assumption.
Is
that
you?
You
are
you
know
it's
your
money,
so
it's
your
validator
and
you
own
all
the
keys
when
you
start
to
move
away
from
that
into
staking
providers,
and
so
on.
You
are
moving
out
of
the
I
guess
ideal
case.
D
D
A
lot
of
the
the
actual
expectations
haven't
been
really
formally
and
strictly
set
down
either
we've
kind
of
given
a
an
expectation
in
many
cases,
but
knowing
that
we
didn't
have
actually
a
plan
for
withdrawals
when
we
set
most
of
them,
we
knew
they
were
going
to
have
to
be
changes,
and
so
there
are
kind
of
some
really
core
things.
Maybe
that
we've
got
to
keep
that
you
know
like
the
money,
goes
to
the
withdrawal
key,
not
the
signing
key.
It
will
never
be
the
signing
key.
That
gets
the
money.
B
I
I
had
a
similar
concern.
I
did
mention
my
background,
but
I
also
like
previously
ran
quite
a
large
validator
and
ran
maybe
10
000
plus
validators,
and
at
one
point
when
they
were
discussing
this,
you
know
new
zero,
x01
withdrawal
type,
and
you
know
that
would
be
the
way
that
ultimately,
like
money
will
come
out.
If
you
are
on
the
ox01
you'll
need
to
like
swap
eventually
before
you
can
withdraw.
B
But
on
that
one
I
do
have
a
question
for
the
two
client
devs
when
it
comes
to
like
I,
don't
say
keeping
people
happy,
but
whenever,
like
people
have
requests
of
how
to
build
staking,
are
you
always
focused
on
the
homesteaker?
Are
you
always
focused
on
Enterprise
liquid?
Staking
pool?
Has
often
come
into
conflict
like
who
are
you
keeping
happy
and
who
are
you
disappointing,
Paul.
C
I
think
Adrian
expressed
a
little
bit
of
that
sentence
with
his
previous
one.
It's
it's
different
for
everyone,
I
think
I
can't
speak
for
all
the
client,
devs
I
can't
even
speak
for
my
entire
team.
I
can
speak
for
myself,
I
like
to
prioritize
the
home,
Staker
I,
think
I
think
that's
kind
of
the
base
instance.
C
If
you
know
what
I
mean,
where
kind
of
all
other
features
are
kind
of
supersets
of
that
and
I
also
think
it
sticks
with
the
ethereum
ethos
of
decentralization
as
well,
but
so
I
would
say
that
making
decisions
that
put
the
home
Staker
in
an
uncomfortable
position
is
probably
almost
always
out
of
the
question.
If
it's,
if
it's
to
benefit
the
institutional
Staker
but
I
would
say
the
other
scenario
where,
if
we
need
to
benefit
the
homesteaker
and
it's
gonna,
it's
gonna
cause
troubles
for
the
institutional
Staker.
C
I
would
probably
be
more
open
to
doing
that.
Just
because
I
have
more
resources,
there's
fewer
of
them.
So
ideally
we
always
want
to
support
everyone.
We
don't
want
to
just
like
you
know,
do
things
to
like
to
disadvantage
institutional
snakes
just
because
we
can,
but
my
personal
preference
is
for
the
for
the
little
guy.
D
Yeah
yeah
I
think
a
part
of
that,
and
almost
probably
underlying
that
is
that
it
tends
to
be
ethereum
that
comes
first
and
and
those
core
principles,
so
I
has
talked
this
morning
was
really
good
in
terms
of
talking
about
some
of
those
principles
behind
ethereum
and
and
decentralization
is
a
key
part
of
that,
and
so
that's
why
I
tend
to
agree
with
the
homesaker
tends
to
come.
First,
they
don't
have
someone
advocating
for
them
and
they're
the
most
decentralized
form
of
validation,
so
yeah.
D
It
does
mean
that
that
there
are
sometimes
those
hard
decisions
that
a
lot
of
people
say.
You
know,
it'd
be
really
nice
to
stake
with
less
eth
or
it'll,
be
really
nice
to
whatever
it
is,
and
you
look
at
it
and
go,
but
that's
really
going
to
hurt
the
protocol
like
it's
going
to
cause
too
much
system
requirements
and
hurt
decentralization
or
it's
whatever
it
is
it's
going
to
reduce
security
or
so
on
enable
more
capture
of
different
things.
D
Absolutely
not
most
of
the
decisions
we
have
to
make
are
good
for
everyone
and
it
works
out
pretty
well.
The
the
external
signer
is
a
really
interesting
one
because
it
wound
up
with
a
niche.
It's
been
used
by
a
number
of
systems,
including
damp
node,
to
make
it
easy
to
swap
clients.
So
you
put
your
keys
into
the
external
signer
and
it
holds
them
and
your
slashing
protection,
and
then
you
can
change
your
validator
client
and
Beacon.
Note
all
you
like,
without
ever
moving
your
keys,
so
homesteakers
have
wound
up
adopting
this
technology.
B
So
you
know
we
now
have
this
world
where
people
are
giving
out
about,
like
you
know,
centralized
relay
or
censoring,
and
that
was
kind
of
the
trade-off
of
going
for
the
blinded
blocks
and
stuff,
but
yeah.
It's
definitely
a
tricky
one
and
I
I
sometimes
am
grateful.
That
I
can
just
ask
tricky
questions.
Don't
have
to
actually
answer
them
most
of
the
time.
B
So
the
next
thing
I
wanted
to
do
a
little
was
look
a
bit
forward
on
kind
of
where
we're
going
next
in
terms
of
withdrawals.
So
we
talked
a
lot
about
like
the
like
withdrawal
credentials,
but
we
haven't
really
talked
much
about
how
it's
going
to
happen.
You
might
say
and
I'm
going
to
try
and
not
ask
like
when
withdrawals,
but
can
I
ask
how
do
withdrawal
spec
has
changed
over
the
last
six
months.
We
started
with
kind
of
a
pull-based
system
and
now
we're
at
like
push
to
Adrian
Paulie.
C
C
Is
a
system
where
the
beacon
chain
automatically
without
user
input,
will
scan
through
the
validators
and
look
for
validators
that
are
fully
withdrawable
withdrawn
and
then
it'll
just
pull
their
eighth
out
and
then
put
it
on
the
the
execution
chain.
It'll
also
look
for
validators
who
have
excess
balance
above
32f
and
then
just
pull
that
excess
balance
out
and
put
on
the
execution
chain.
C
So
this
is
kind
of
so
it's
it's
an
automatic
process
where
you
don't
need
to
go
and
withdraw
F
you
just
kind
of
end
up
with
money
in
the
smart
contract,
which
I
think
is
really
really
nice
I
think
it's
really
good
for
users,
because
it
means
they're
signing
less
weird
messages.
I
know
anyone
who
runs
a
validator
could
probably
empathize,
but
the
idea
of
having
to
go
and
touch
the
keys
on
my
validator
client
or
do
something
with
my
validator
client.
C
Apart
from
just
leaving
it
alone,
it's
just
terrifying
and
it's
horrible,
so
I
think
it's
really
good
to
be
able
to
just
like
have
it
happen
automatically
yeah,
there's
gonna
be
I,
don't
know
if
I.
So
this
there's
going
to
be
a
complication,
though,
and
it
kind
of
it
goes
around
these
two
types
of
withdrawal
Keys
we
have
so
it's
been
mentioned.
There's
a
zero
X,
zero,
zero
Keys,
which
is
a
BLS
with
throttle
key
and
then,
which
was
the
like
Adrian
said.
C
C
Think
it's
a
shame
that
we
have
to
do
this.
We
have
to
make
I
would
say
most
users
go
and
sign
this
message,
but
I
think
it's
unavoidable,
but
then,
after
that,
it'll
all
kind
of
happen
automatically.
So
knowing
that
that
is
very
much
in
the
pipeline
and
looking
like
it's
going
to
happen
where
I
know
Lighthouse
deciding
to
implement
it,
I
think
techu
is
lots
of
clients
are
keen
on
it.
I
would
say
if
you're
creating
a
new
validator
today
I
would
be
using
0x01
I
would
be
using
an
F
address.
C
D
One
really
important
point
is
that
once
you
have
switched
to
an
ox01
key,
so
once
you've
got
an
ethereum
address,
whether
you
started
with
it
or
whether
you
switch
through
this
new
system.
That's
it!
You
can't
change
it
again
and
there's
concerns
around
that,
because
people
want
to
change
it,
but
generally
the
reason
you'd
want
to
change.
It
is
because
you've
gone
and
lost
the
key
to
that
or
you
typed
in
the
wrong
address,
or
something
don't
make
that
mistake.
It's
like
transferring
money
to
that
address
right!
It's
gone!
D
There
is
no
way
to
get
it
back
if
you
don't
control
the
key
because,
as
we
talked
about
before
it's
the
withdrawal
key
that
has
to
own
the
money.
So
if
you
tell
us
that
ox000
the
null
address
owns
your
eth
well
now
it
does
and
you're
not
going
to
get
it
back
and
there's
really
very
little.
We
can
do
about
that.
Well,
there's
nothing!
We
can
do
about
that.
B
For
sure,
I
think
we're
going
to
see
a
lot
of
work
and
there's
actually
a
talk
by
a
test
and
just
briefly
beforehand,
where
it's
now
that
we
can
have
like
solidity
contract
addresses.
You
can
program
your
like
change
of
ownership
in
there
and
not
like
at
with
some
cryptography
or
any
sort
of
like
multi-sig
or
anything
too
weird
yeah.
D
And
that's
absolutely
a
big
part
of
the
reason
that
we've
gone
with
such
a
simple
approach
to
withdrawals.
We
don't
need
to
do
anything
fancy
on
the
consensus
layer
side,
because
you've
now
got
the
full
power
of
the
evm
to
to
work
with
things
and
and
have
upgradable
contracts
or
split
contracts
or
all
kinds
of
things
there
that
let
you
have
this
Behavior
so
think
hard
about
what
address
you
said
is
your
withdrawal
address,
I
would
say
for
most
homesteakers.
D
It
should
be
something
like
from
your
trace
or
you
know
your
Hardware
wallet
that
that
is
very
safe
and
very
secure
and
simple.
Keep
it
simple.
You
don't
need
to
do
anything
fancy
and
then
you
know:
staking
providers
will
use
something
that
is
a
contract
and
probably
upgradeable
so
they've
got
some
control
over
it
and
then
there's
a
range
of
people
in
the
Middle.
B
For
sure
yeah
I
think
the
you've
touched
on
one
of
the
things
that
will
show
up
over
the
next
few
years,
and
this
is
the
evm
having
more
control
over
the
consensus
layer
because,
as
I
pointed
out
right
now,
you
write
an
address
and
money
will
show
up.
But,
like
no
code
is
going
to
execute
and
that's
about
it,
how
do
you
think
that's
going
to
change
and
what
is
the
evm
I,
don't
know
consensus
layer,
API
going
to
look
like
in
three
years
time.
D
I'm
really
hoping
it
doesn't
ever
get
a
say,
I'm
really
hoping
this
stays
a
one-way
thing
from
the
consensus
layer
pushing
to
the
ethereum
layer
or
to
the
to
the
execution
layer,
because
it's
dramatically
simpler
to
get
the
evm
to
call
out
to
the
consensus
layer
is
a
big
deal
and
a
really
big
challenge.
We've
kind
of
done
it
with
deposits
and
it's
the
worst
code
in
any
any
consensus.
D
C
B
E
Like
yeah,
so
we
haven't
settled
on
the
final
design,
yet
so
what
I'm
talking
about
is
the
walk-in
walk-in
progress
solution
right?
It's
almost
ready,
though,
for
like
presentation
and
voting
in
for
photo
Etc,
but
the
gist
of
it.
The
best
solution
we
can
do
is
to
reflect
the
withdrawal
queue
in
on
the
execution
layer.
E
We
like
try,
like
looked
at
multiple
different
approaches,
like
calls
auctions
for
for
the
like,
for
the
place
in
the
queue
some
kind
of
buffers
for
his
roles,
etc,
etc,
and
it
all
I
think
is
like
strictly
inferior
to
allowing
people
to
place
the
like
request
of
withdrawal
and
we
put
them
in
a
queue
on
the
beacon
chain,
and
this
all
happens
and
they
get
there.
They
withdrawals
when
they
time
in
the
queue
passes.
E
So
that's
probably
going
to
be
it's
pretty
like
it's
pretty
complicated
because,
like
there
are
multiple
asynchronous
processes
happening,
like
the
withdrawal
request,
the
Oracle
reports
about
what
happens
on
the
beacon
chain.
Like
you
said
right,
we
like
the
needs
information,
what's
happening
in
Beacon
chain
and
we
can't
get
in
real
time.
It's
it's
just
impossible
right.
So
Oracle
requests
lessons
and
slashing
side
like
we
haven't
had
any.
You
know
lifetime
Lido
but
like
if
it
happens.
It's
like
35
days
process,
at
least
and
somewhere
in
the
middle.
E
It
has
an
uncertain
amount
of
slashing
penalty
which
no
one
knows
like
until
it
happens,
how
much
it
is
going
to
be
because
it's
like
depends
on
the
amount
of
Slash
from
that
like
accumulated
up
to
this
point.
So
when
you
combine
all
the
asynchronous
process
and
you
need
to
like
give
people
exactly
the
amount
the
like
they,
they
need
to
get
it's
becoming
pretty
complex
protocol
button.
B
Awesome
yeah
that
makes
a
lot
of
sense
and
I
think
you're
not
going
to
be
the
only
one.
That's
going
to
have
a
lot
of
pain
with
these
withdrawal
cues
very
soon,
because
everyone
just
thinks
withdrawals,
no
one
thinks
withdrawal,
q
and
that
actually
leads
me
a
bit
to
the
like
balance
skimming,
and
this
is
another
thing
that
gym
are
like
fifth
panelists
is
very
like
in
favor
of
which
is,
if
you
don't
have
any
way
to
take
the
money
above
32
ether.
That's
accumulated.
B
D
It's
a
it's
a
very
similar
process
to
what
Paul
described
in
terms
of
finding
of
scanning
through
the
validators
and
just
it
it
magically
happens.
It's
pushed
from
the
consensus
layer.
The
the
key
thing
is
that
there
will
be
a
limit
to
the
number
of
validators.
We
scan
each
Epoch
to
look
for
whether
you've
got
money
over
that
32e
that
could
be
pushed
to
the
execution
layer.
D
The
reason
for
that
is
that
we've
got
to
fit
it
into
blocks
and
it's
like
another
ethereum
transaction
that
goes
into
a
block,
but
we're
not
charging
gas
for
it.
It
just
happens,
and
so
we
kind
of
have
to
have
a
rate
limiting
on
it
to
make
sure
that
we're
not
effectively
just
blowing
up
our
block,
limit
and
and
execution
clients
are
able
to
process
these
these
blocks
in
a
reasonable
amount
of
time.
D
D
Many
or
that
many
deposits,
but
it
means
that
fairly
regularly
and
it'll,
be
in
in
that
order
of
you
know
low
number
of
months,
I
think
that
we're
aiming
for
generally
fairly
regularly,
whatever
you've
got
over
the
32
eth
gets
swept
to
the
execution
layer.
So
you
start
getting
your
rewards
on
top
of
the
transaction
rewards
you're
getting
when
you
propose
a
block
now.
C
Gonna
say
I
think
I
think
it's
really
good,
because
the
idea
of
a
validator,
so
a
validator
would
say
33f
exiting
taking
an
F.
Putting
32
back
in
is
really
bad
for
consensus
clients,
because
that
extra
validator
slot
they
they
cost
us.
We
have
to
store
that
validator
forever,
it's
more
in
Ram
yeah,
it's
really
bad.
So
so
the
ability
to
like
for
people
to
take
their
earnings
without
creating
a
new
validator
index
is
is
really
good
for
the
protocol.
Yeah.
D
There
were
certainly
a
lot
of
people,
Jim
I,
think
leading
the
charge
being
very
vocal
if
you've
got
to
have
partial
withdrawals
before
you
know,
at
the
same
time
as
withdrawals-
and
you
know
as
as
core
devs,
we
try
not
to
promise
things
until
we're
sure
but
I
think
all
of
us
knew.
That
was
absolutely
right
and
there
was
no
way
that
we
could
could
manage
the
impact
on
the
chain
of
these
churning
validators.
If
we
didn't
have
partial
withdrawals.
E
There
is
also
an
economic
effect
aspect
of
it.
If
there
were
no
scheming
of
rewards,
then
the
B
corporate,
like
the
the
big
State
Controllers,
like
protocols,
exchanges,
whales
Etc.
They
would
get
a
lot
of
leg
up
against
small
stakers
because
they
can
afford
to
compound
and
small
stickers,
can't
like
it's
it's
very
hard
to
them.
So
yeah,
it's
like
it's
very
right,
move
to
make
it
like
skimming,
rewards
a
thing.
E
The
the
like
the
the
slight
drawback
of
this
is
working
against
the
protocols
that
likes
taking
protocols,
because
you
can't
really
understand
if
the
money
you're
getting
on
the
result.
Credentials
comes
from
Rewards
or
comes
from
unstaking,
and
you
need
to
know
that
because,
like
rewards,
you
have
to
reduce
view
to
stake
us
and
unstaken
is
like
something
like
someone
was
drawing
something
gone
wrong
or,
like
me,
slashing
happened
like
you,
you
need
to.
B
Yeah
I'll
also
Echo
the
it
makes
much
more
sense
from
the
compounding
thing,
but
someone
trying
to
write
like
solidity
to
keep
track
of
something
you
know
I,
don't
know.
Was
this
a
very
bad
slashing,
or
was
this
a
skim?
So
it
is
a
bit
tricky
like
that.
I
have
just
one
more
question
before
we
go
to
the
audience
for
a
few.
So
have
a
think
of
anything.
B
D
I
suspect
I
mean
probably
the
majority
of
validators
on
the
network.
Bls
credentials,
sort
of
more
need
to
switch
I,
don't
think
there'll
be
a
huge
rush,
I
think
there'll,
be
you
know
the
initial
burst
and
very
likely.
What
will
happen
is
you
will
submit
it
and
operation
pools
in
clients
will
actually
be
full
and
it'll
probably
get
dropped
from
the
network,
and
it
just
won't
make
it
on
train
at
all
and
you'll
need
to
submit
it
again.
D
So
we'll
kind
of
have
to
work
through
the
the
usability
of
that,
because
if
there
is
a
big
rush,
it's
more
than
we'll
keep
in
the
memory
pool
basically
but
I
think
generally,
it
will
be
over
time
because
people
have
got
to
get
their
withdrawal
keys
out.
It's
something
you
should
take
your
time
and
do
safely
and
not
rush
in
the
first
instant
and
and
once
it's
done
it's
over.
So
it's
it's
fairly
fairly.
One
off.
C
A
C
And
he
was
saying
that
it's
likely
that
the
staking
deposit,
CLI
tool
will
have
the
tooling
to
allow
you
to
do
it
and
I
think
it'll
be
a
little
bit
easier,
because
the
staking
deposit,
CLI,
now
kind
of
like
makes
a
bunch
file
for
you.
And
then
you
need
to
put
potato
at
those
and
that's
kind
of
annoying.
In
my
opinion
and
I
think
what
now
that
the
apis
have
evolved.
C
Hopefully
what
we
can
do
with
the
staking
deposit
CLA
will
like
you,
can
just
input
your
mnemonic
and
then
tell
it
where
a
beacon,
node
is
or
even
a
like
a
public
node
and
then
just
have
it,
publish
it
out
to
it
like
that.
So
it'll
be
a
little
bit
scary
because
you
have
to
touch
some
crypto
stuff
but
I'm,
hoping
that
it'll
it'll
be
okay
and
I.
Think
that
I
think
I'm,
Keen
I
know
Adrian
would
be
Keen
as
well
to
try
and
make
it
nice
and
smooth
for
people
yeah.
D
D
E
My
estimation
is
about
200
000
validators
will
like
rotate
as
soon
as
humanly
possible,
like
safely
possible.
The
reason
is,
like
I,
know,
about
Lido.
We
have
about
50
000
and
every
extra
second
is
an
extra
risk
on
this.
On
this
credential.
We
don't
want
to
do
that
like
we
won't
overload
the
network,
of
course,
but
like
as
soon
as
humanly
possible.
We
do
it.
E
It's
it's
very
important
and
about
I
think
like
150
200
Southern
of
operators
are
on
BLS
credentials
that
are
managed
by
exchanges
and
this
exchange
it.
They
want
to
like
to
pay
the
rewards
as
soon
as
possible,
again
and
like
convert
it
to
liquid
stake
and
derivatives
for
like
custodial,
like
coinbase,
doesn't
CBS.
E
So
that's
going
to
happen
also
very
fast,
like
the
the
protocols
and
custodian
that
aggregate
users
take,
they
will
and
haven't
rotated.
They
will
rotate
like
they
will
rotate
as
soon
as
possible,
because
basically
BLS
0x
zero
zero
credentials
are
as
useful
as
a
potato.
The
only
thing
you
can
do
with
them
is
like
exit
or
rotate
and,
like
that's
just
not
right,
yeah.