►
From YouTube: PEEPanEIP #117: EIP-4788:Beacon block root in the EVM with Alex Stokes #ethereum #eip4788 #validator
Description
Resources:
-----------------
https://eips.ethereum.org/EIPS/eip-4788
https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281
Slides - https://docs.google.com/presentation/d/1vpXXKBMtE5wcVYMjarKQazIO5ZGDLBlZ4k5GqnBH45g/edit?usp=sharing
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Dencun - https://www.youtube.com/playlist?list=PL4cwHXAawZxpnKFDl1KzGOKqwux5JaLlv
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
A
It
is
fascinating
to
see
what
ethereum
blockchain
upgrades
bring
for
its
users
after
the
merge,
along
with
adding
network
security.
Scalability
developers
are
also
focused
on
better
use
cases
for
validators
and
staking
pools.
If
you
are
one
of
those
interested
in
learning
more
about
dun
featured
eips
stay
with
us.
A
Welcome
to
P
pip
episode,
117
I'm
Puja
ranen
back
with
another
special
episode
on
Denon
upgrade
documented
in
February
2022
co-authored
by
Alexa
Stokes
Ana,
dietrix,
Danny,
Ryan,
Martin
send
and
lightline
EIP
4788
Beacon
route
in
evm
is
a
proposal
to
support
a
wide
variety
of
use;
cases
that
improve
trust
assumptions
of
staking
pool
reaking
construction,
smart
contract,
Bridges,
M,
mitigations
and
more
to
learn
more
about
the
proposal.
Let's
welcome
Alex
Stokes
welcome
to
pip
Alex.
A
It's
great
to
see
you
back
for
those
who
aren't
aware.
Alex
is
a
researcher
at
ethereum
foundation
and
he
is
also
me
boost
Community
by
organizing
Community
calls.
He
has
been
generous
enough
to
take
out
time
and
talk
about
ethum
Improvement
proposals
and
other
ongoing
research
work.
In
the
past.
He
enlightened
us
with
talks
on
meev,
Boost,
EIP,
4895
Beacon
chain
push,
withdrawals,
EIP,
44s,
bound
historical
data
in
execution,
clients
account
reforming
with
alterer
upgrade.
B
Yeah
P
was
saying
I'm
a
research
at
thef
doing
a
number
of
things
at
this
point,
and
so
yeah
looking
into
various
topics,
historically
I
had
worked,
you
know
looking
at
proof
of
stake
and
the
different
consist
things
that
we've
done
leading
up
to
the
merge
and
then
now
you
know,
there's
there's
some
things
that
we
could
still
hope
to
improve
around
the
staking
model,
one
of
them
being
the
stuff
we'll
get
look
at
with
the
CIP
and
yeah
from
there.
It
also
kind
of
opens
a
whole
a
whole
box
of
different
things.
B
A
B
Let's
go
ahead
and
dive
in
so
yeah
if
you're
watching
this,
you
have
probably
heard
of
this
theum
has
merged
anniversary
is
coming
up
soon
and
yeah.
We
moved
from
proof,
work
to
proof
of
stake
and
the
way
that
we
chose
to
do
this
was
essentially
with
this
dual
layer
architecture.
So
you
can
imagine,
there's
like
a
cons
layer
that
is
like
figuring
out
sort
of
what
has
happened
in
in
the
world
of
ethereum
and
that
layer
somehow
houses
this
execution
layer.
B
So
the
idea
with
the
merge
is
that
you
had
this
Pro
work
chain
that
was
like
coming
along
and
essentially
it
was
the
cons
kind
of
like
hot
swapped
in
place.
So
you
have
the
execution
layer
where
all
our
applications
live
and
then
now
there's
the
consensus
layer
that
is
forming
consensus
over
again
the
protocol.
So
a
lot
of
that
was
reflecting
sort
of
just
you
know
the
historic
you
know,
let's
say
progress
of
both
of
these
different
efforts
and
in
order
to
merge
them.
B
This
was
probably
the
simplest,
but
that
left
some
things
to
be
desired.
Some
things
around
the
staking
protocol
that
we
could
think
to
improve,
and
one
of
them
is
very
much
just
even
communication
between
the
layers.
This
is
even
reflected
if
you're,
like
a
validator
and
like
the
life
cycle
of
like
eth,
to
sort
of
stake
and
unstake.
So
you
know
what
you
can
kind
of
what
you
could
have
do.
B
Sort
of
immediately
at
the
point
of
the
merge,
was
sort
of
deposit
eth
into
the
deposit
contract,
moving
that
from
the
extion
layer
to
the
cons
layer,
and
it
actually
wasn't
until
this
chapella
heart
Fork
that
we
had
earlier
that
you
could
actually
withdraw
the
eth
from
the
cons
layer
to
the
execution
layer.
So
what
I
was
saying
is
that
you
had
a
way
to
move
eth
from
the
execution
layer
to
the
cons
layer,
and
this
is
like
some
form
of
communication.
B
If,
even
if
it's
like
very
limited,
just
like
moving
e
and
actually
yeah
the
point
of
the
merge,
there
was
no
way
to
even
go
back
the
other
direction
and
with
dra
E
from
the
the
cl
to
the
E.
These
are
like
these
funable
acronyms
we
like
to
use,
because
consensus
layer
is
a
mouthful,
as
is
execution
layer.
So
that
being
said,
you
know,
there's
other
things
we
could
imagine
trying
to
like
sort
of
communicate,
especially
in
like
a
trustless
way
from
one
layer
to
another.
B
You
know
beyond
just
like
okay,
this
e
balance
move
from
here
to
there
there's
a
lot
going
on,
because
there
is
all
this
like
sort
of
cryptoeconomic
security
at
the
consist
layer
with
all
of
the
eth
that
has
been
staked,
there's
like
a
whole
life
like
a
validat
life
cycle
and
there's
like
various
applications
that
you
can
imagine.
Some
of
them
will
look
get
in
a
bit
that
tie
into
like
understanding
this
information
and
if
there
are
a
way
to
like
somehow
gain
information
about.
B
You
know
that
state
inside
the
execution
state
that
we
all
know
and
love.
You
know
that
would
actually
improve
the
trust
assumptions
of
many
of
these
applications.
So
EIP
sets
out
to
do
is
actually
you
know
essentially
close
the
gap
from
not
only
going
from
sort
of
the
CL
or
the
El
to
the
CL,
but
then
back
again
and
like
like
I've,
been
gesturing
at
there's,
like
all
sorts
of
applications
that
you
could
imagine.
You
know,
building
building
with
this,
and
you
know
that
being
said.
B
Many
of
these
they
well
yeah
just
to
run
through
them.
I
mean
again,
there's
probably
even
more
that
you
can
imagine.
Some
big
ones
are
like
staking
pools.
So
these,
like
liquid,
staking
tokens
Lio
rocket,
pool
things
like
this.
They
essentially
need
to
know
the
state
of
the
validators
on
the
consistance
layer
in
order
for
them
to
be
able
to,
like
you
know,
even
function
right
like
you
need
to
understand.
B
Okay,
if
this
validator
is
in
this
pool-
and
it's
supposed
to
have
done
this
like
did
they
and
if
they
didn't,
you
know
what
does
that
mean:
reaking
applications
like
igen
layer,
so
people
now
are
thinking
about.
Okay,
if
we
have
all
this
like
St
locked
up
well,
that
might
be
like
capital
in
efficient,
so
we
could
imagine
sort
of
repurposing
it
in
other
applications
and
again
all
the
same
considerations
apply.
B
You
know
if
a
validator
is
supposed
to
do
this,
what
you
know,
what
what
do
they
actually
do
and
what
does
that
mean
for
my
protocol?
My
application,
another
one
is
around
me
management.
This
one
I
think
is
like
maybe
a
bit
more
speculative
than
the
others,
but
there
are
some
constructions
you
might
have
heard
of
like
Pepsi.
B
Where,
again,
you
could
very
much
imagine
wanting
to
know
sort
of
the
behavior
of
validators
or,
like
me,
builders
in
this
case,
in
the
system
and
understanding
what
they
did
and
using
that
to
actually
improve
the
security
of
whatever
application
you're
designing
and
that
all
being
said,
many
of
these
applications
exist
today,
I
mean
I
gave
you
some.
You
know
some
of
these
like
products
in
the
market
already,
and
you
know
so
that
people
have
like
not.
You
know,
been
doing
this
stuff
at
all.
B
In
fact,
a
lot
of
motivation
for
this
VIP
is
just
recognizing.
Hey
people
are
going
to
do
this
so
like
if
we
can
improve
the
security
of
the
whole
thing
like.
That
would
be
great,
and
this
is
one
way
to
do
this,
because
right
now,
the
way
all
these
applications
work
is
they
have
some
sort
of
trusted
Oracle.
You
can
imagine
just
like
multisig
that
basically
authorized
to
like
vote
in
like
the
the
latest
cons
State
and
that's
essentially
how
H
these
work
today
with
the
zip.
B
You
could
actually
remove
this
Oracle
entirely
and
instead
have
this
trustless
one.
So
that's
very
much
the
motivation
for
this
work
here
and
yeah,
so
EIP
4788.
This
is
again
the
IP
that
is,
you
know,
trying
to
execute
everything.
I
just
said,
so
we
will
in
some
way
get
the
beacon
block
route
from
this
Beacon
chain.
Essentially,
the
the
consist
part
of
the
protocol
that
the
evm
cannot
currently
access,
we'll
somehow
move
this
routee
into
the
evm
and
I'll
explain
a
bit.
B
What
sort
of
like
this
root
thing
is,
and
some
of
these
other
words
in
a
second
but
yeah.
You
can
see
here,
EIP
is
been
open
in
some
form
for
like
over
a
year
now
and
yeah.
This
point
has
quite
quite
a
long
author
list,
so
yeah,
let's,
let's
look
at
the
IP
a
bit
closer.
So
a
big
thing
here
is
this
concept
of
a
beacon
block
route
and
with
the
merge.
B
B
So
we
have
these
accumulators
these
roots
and
where
they
come
from.
Is
that
the
way
we
kind
of
lay
out
our
data
in
the
consist
this
layer
is
with
this?
This
schema
called
ssz
and
it
supports
merization,
just
as
part
of
it,
where
you
can
say
for
some
given
piece
of
data.
I
want
to
also
be
able
to
make
a
mer
tree.
I
can
take
the
root
of
this
tree,
and
that
gives
me
a
commitment
to
all
the
data.
B
This
is
very
handy
because
now
you
can
have
Merle
proofs
to
say
yes,
if
I
trust
the
root
of
this
thing,
then
in
fact
I
can
actually
say:
okay,
this
root
committed
to
this
data
at
this
point
in
time
and
we're
good
to
go.
So
this
is
a
schematic
of
kind
of
what
I
was
just
gesturing
at
so
at
the
very
top
left
here
you
see,
you
know
I
said
zerox
def
beef
Cafe,
that's
like
some
hex
encoding
of
this
route.
B
These
roots
are
like
32
by
values
and
again,
are
these
cryptographic
commitments
to
all
this
data?
So,
for
example,
you
can
imagine
having
the
root
here
of
a
beacon
block,
and
the
way
this
works
is
that
ultimately,
the
root
here
commits
to
the
header
of
this
block
and
turn
the
header
commits
to
the
body.
That's
where
you
see
this
body
route,
but
it
also
commits
to
other
things
like
the
state
route.
So
then,
you
can
see
from
the
state
route.
We
could
have
a
proof
down
to
the
beacon
State.
B
The
beacon
state
has
all
kinds
of
things.
For
example
the
registry
of
validators.
You
can
imagine
making
a
proof
to
like
one
validator
in
this
list
and
then
from
that
one
validator,
you
say:
okay,
for
example,
you
know
I
could
prove
against
this
very
top
level
route.
So
at
that
point
in
time,
as
of
the
state
of
the
chain,
was
this
validator
slashed?
And
here
you
know
I'd
like
to
paint
this.
B
This
picture
that
yeah,
basically,
you
could
reach
any
consistent
state
from
this
route,
and
we
have
these
these
fairly
small
proofs
to
do
this
and
yeah.
We
now
unlock
all
this
information
we
can
use
to
like
Harden
these
these
different
applications
and
protocols.
I
was
talking
about
a
second
ago,
so
that's
pretty
cool.
B
B
The
thing
is,
we
now
have
to
get
them
like
in
the
evm,
so
that's
kind
of
like
the
other
half
of
the
CIP,
and
to
explain
that
we
will
need
a
a
little
more
additional
context
as
well,
so
with
the
way
that
the
software
is
structured.
Today
we
have
this
thing
called
the
engine
API,
it's
like
a
very
core
part
of
the
merge.
You
can
imagine
other
like
CL
and
El
software
that
doesn't
use
the
engine
API.
They
could
have
like
more
of
a
tight
and
process
integration.
B
There's
all
sort
of
things
you
can
imagine,
but
essentially
this
engine
API
gives
you
like
a
sort
of
minimum
functionality.
It
says
you
know
if
you
are
like
part
of
this
ecosystem,
then
there's
a
way
for
like,
for
example,
the
eel
to
get
updates
about
the
latest
h
of
chain,
for
example,
for
the
cl
to
like
understand
if
this
El
block
is
valid.
Things
like
this
and
I
have
this
little
graphic
here,
so
essentially,
there's
like
different
apis.
B
Generally,
we
see
clients
built
like
this
with
like
different
separate
clients
talking
over
the
apis,
and
you
know
they
each
separately
have
their
own.
Like
gossip
Network
peer-to
peer
Network
at
each
layer
of
the
stack,
so
the
reason
I
brought
this
up
is
because
we
essentially
will
use
this
engine
API
here
to
communicate
this
route
and
at
a
very
high
level.
What
does
this
look
like?
Well,
essentially,
for
every
block
the
CL
will'll
send
this
parent
beacon
block
route,
and
you
know
just
to
make
this
clear.
B
The
reason
we
use
the
parent
is
because
you
need
this
thing
available
to
actually
execute
the
block,
which
means
you
needed
to
construct
the
block,
which
means,
if
you
use
the
current
block
group,
you
wouldn't
be
able
to
get
it
to
have
it
in
the
evm.
There's
a
circular
dependency
here,
because
you
can
imagine
a
very
simple
smart
contract
that
changes
execution
just
depending
on
the
value
of
this
rout
and
so
yeah
there.
B
You
can't
you
can't
get
the
current
block
rout
inside
the
current
execution,
but
that's
fine
because
we'll
just
use
the
parent,
so
the
CL
goes
to
send
the
parent,
along
with
an
execution
payload,
which
is
like
some
new
execution
message
that
it
wants
the
El
to
verify
the
El
puts
it
into
the
execution.
Payload
header,
so
this
is
here
to
support
like
syncing
use
cases,
I,
think
I'll
say
more
in
a
minute
about
that
and
right.
So
the
El
then
takes
this
root
value
from
the
CL.
B
It
writes
it
to
the
evm
state
as
a
system
transaction
So,
This,
Is,
A,
New
Concept,
the
CP
introduces
I'll,
say
a
bit
more
in
a
second,
but
essentially
there's
almost
this
new
class
of
operation
or
transaction
that
has
I
won't
say
special
privileges,
but
maybe
we
should
say
that
they
had.
It
has
a
way
to
basically
write
this
in
a
way
that
no
one
else
can
write
and
that
helps
us.
You
know
know
that
the
the
whole
construction
is
secure.
B
So
once
the
El
writes
the
root
it
receives
into
the
evm
state
in
this
like
special
way,
then
it's
just
it's
just
now
a
smart
contract
and
like
anyone
can
read
it
like
any
other
smart
contract
and
get
the
root
value
that
they're
looking
for
so
yeah
I
talked
about
some
of
this,
as
I
was
going
through
the
steps.
Why
do
we
want
to
use
a
parent,
Beacon
blocker?
So
again,
there's
just
this
circular
dependency.
B
B
So
there's
like
a
sort
of
we'll
say,
design
decision
and
of
this
merge
architecture,
which
is
essentially
saying
that
you
actually
want
the
E
and
the
cl
to
be
able
to
operate
independently
as
much
as
possible,
and
so,
for
example,
there
could
be
like
a
reorg
on
the
CL
and
then
suddenly,
there's
like
some
new
e
block
over
here
that
you
know
the
the
local
e
has
never
seen.
It
has
to
say,
hey
execution.
Clients
like
go
tell
me
if
this
chain
makes
sense,
because
I
think
I
should
switch
over
here.
B
The
El
needs
to
go
sync,
this
other
CH,
this
new
branch
of
the
chain-
and
it
will
go,
do
that
and
yeah
you
wouldn't
want
it
to
be
the
case
where
the
execution
layer
is
now
sinking
a
branch
and
for
every
block
it
has
to
kind
of
like
go
back
to
the
CL
and
say
hey:
what
was
the
root
hey?
What
was
the
root?
Hey?
What
was
the
root
instead,
they're,
just
all
sort
of
you
know
very
neatly
committed
to
in
the
header
and
the
El
can
kind
of
just
go
independently.
B
B
State
full
because
we'll
see
in
a
second
there's,
actually
like
somewhat
sophisticated
contract
state
that
we're
keeping
track
of
for
reasons,
I'll
I'll
explain
when
we
get
there.
But
ultimately
you
know
this
would
be
a
precompile,
it
would
have
state
and
we
went
you
know,
there's
some
back
and
forth
around
this
design
decision.
B
You
know
if
you're
really
want
to
get
into
the
weeds,
you
can
go
check
out
the
allore
devs
from
maybe
like
the
last
month
or
so
where
we
we
talked
about
some
of
these
things,
but
ultimately,
we've
settled
on
essentially
the
system
contract.
So,
rather
than
this
be
a
pre-compile,
you
ultimately
now
just
like
do
the
same
thing,
but
have
it
be
a
smart
contract
and
there's
like
a
number
of
reasons
to
do
this?
B
One
of
them
is
just
that
the
staple
precompile
is
like
kind
of
a
novel
notion,
and
it's
just
there's
like
less
sort
of
new
stuff
to
think
about
and
reason
about
both
as
like
a
protocol
designer,
but
also
as
like
protocol
implementer,
especially
from
a
security
perspective.
To
not
have
this
like
new
concept,
whereas
instead
just
like
a
regular,
you
know,
vanilla,
smart
contract
is
one
that
you
know.
We
as
a
community
have
like
a
lot
of
experience
with
and
that's
something
we
like
kind
of
understand
right.
So
that
feels
better.
B
There's
like
another
important
point
which,
if
there
were
a
problem
with
this
EIP
saying,
the
implementation
of
a
precompile
that
would
ultimately
be
like
cons,
is
failure
which
is
bad,
because
you
can
imagine
there's
like
two
clients,
let's
say,
and
they
have
a
difference
and
the
precompile
well,
they
would
just
end
up
with
like,
for
example,
a
different
state
route,
and
then
there
would
be
a
chain
split,
and
that
would
be
a
headache.
This
way
you
know
assuming
the
evm
is
correct.
B
There
could
be
a
problem
with
the
contract
buy
code,
and
that
might
mean
that,
like
the
feature
of
this
like
Beacon
state
route
or
sorry
beacon
block
route,
you
know
fails
for
some
reason,
but
it
wouldn't
mean
a
chain
split
for
the
protocol.
So
you
know
that's
actually
a
pretty
strong
argument
for
for
this
approach,
because
it
just
kind
of
eliminates
this
whole
class
of
of
like
greater
cons,
failures,
yeah
beyond
what
we
would
have
otherwise.
B
So
that
being
said,
the
reason
this
is
like
a
system
contract
and
not
just
a
you
know,
actual
vanilla,
smart
contract
is
that
we
still
need
some
way
to
sort
of
gate
who
can
like
write
roots
to
this
thing
for
security
reasons
that
I'll
I'll
get
you
in
a
second
you.
We
need
to
write
to
it
a
bit
carefully
and
in
a
certain
way,
and
so
you
would
still
need
some
way
to
say:
okay,
even
if
this
is
like
a
contract
with
D
and
B
code.
B
That's
great,
but
you
know
we
need
some
way
to
get.
Who
can
who
can
write
to
it?
And
that's
where
now
the
access
control
is
done
in
the
B
code,
we'll
see
in
a
second?
But
it's
essentially
from
this.
This
address
that
presumably
no
one
knows,
and
only
this
like
system
caller
idea
can
do
it,
because,
basically
you
just
do
it
outside
of
the
actual
evm
ution
and
have
these
sort
of
like
admin
privileges.
B
There's
this
concept
of
the
system
address
that
I
was
just
doing
at
a
second
ago,
and
the
idea
is
that
when
you
get
a
new
block
before
you
execute
any
of
the
transactions
you
as
system
address,
call
into
this
the
smart
contract
that
will
be
deployed-
and
you
write
the
root
from
the
header
into
the
contract,
storage
and
then
now
again,
like
I,
was
just
saying
anyone
can
go
and
call
the
thing.
The
actual
interface
is
that
you
call
it
with
the
Tim
stamp
of
the
slot
you're
quering.
B
If
the
contract
has
it
you'd
get
back
the
parent
beacon
block
rout
for
that
slot,
and
now
we
have
solved
our
problem.
We
have
tust
access
to
the
beacon
State
via
these
proofs
and
series
of
roots
and
things,
and
now
our
applications
are
Off
to
the
Races.
However,
just
as
I've
sort
of
explained,
there
might
be
a
few
more
problems.
For
example,
it's
actually
hard
because
yeah
I
guess
yeah
like
one
way
to
think
about
what
I
just
said
is
that
you
would
for
each
block.
B
You
would
like
go
and
write
the
one
root
and
the
next
block
would
overwrite
the
next
root.
Next
block
would
overr
the
next
root
and
so
on
and
so
on,
and
so
what
this
means
is
that
you?
Basically,
if
you
want
to
use
this
thing,
you
have
to
make
sure
that
the
transaction
you
write
to
verify
proofs
and
know
that
you
know
your
claim
is
correct,
would
need
to
essentially
be
included
in
like
the
same
block
as
the
state
you're
trying
to
make
proofs
against.
B
That's
actually
going
to
be
pretty
tricky
and
there's
just
no
reason
to
really
like
demand
this
of
people.
So,
instead
we
can
just
say:
okay
well,
rather
than
like
one
slot
sort
of
window,
we
can
imagine,
there's
maybe
a
day
of
like
roots
that
are
lying
around
and
so
now
the
actual
implementation
is
not
just
the
one
route,
but
it's
actually
structured
as
this
ring
buffer
a
buffers.
B
You
know,
there's
this
graphic
here
from
Wikipedia
and
basically
it's
just
saying
like
you
have
like
a
fixed
array
and
the
idea
is
you
just
like
use
some
modular
arithmetic
like
index
into
the
array
it
just
slops
around
and
yeah.
You
change
you.
You
pick
the
size
of
the
buffer
to
have
your
window,
for
example
we'll
Target
say
a
day
and
what
this
means
is
like,
rather
than
you
to
get
into
like
the
exact
same
box
that
you're
trying
to
make
a
proof
against
you
like
have
some
time.
B
You
have
say
a
day
to
like
say:
Okay
I
want
to
make
a
proof
about
the
slot
that
just
happened
and
maybe
I
will
like
go
off
and
like
figure
out,
okay,
you
know
I
need
to
reason
about
some
protocol
State
now
and
then
I
need
to
make
the
proof-
and
maybe
this
takes
me
five
minutes
and
then
I
can
actually
get
my
transaction
onchain
from
there.
So
this
should
be
much
better
in
terms
of
of
ux
now
with
the
ring
buffer.
B
There's
like
another
complication,
because
essentially
we
can
have
missed
slots
and
the
way
the
interface
works
is
that
you
can
basically
query
for
any
slot
when
we
say
Miss
slot.
What
we
mean
is
that
essentially
we
expected
there
to
be
a
beacon
block.
There
is
a
validator
who
could
have
made
a
beacon
block
in
this
case
a
whole
merch
block
block
in
the
chain,
but
for
some
reason
did
not
make
it
on
chain
in
time
either
the
validator
wasn't
online.
There
was
a
failure
in
Block,
processing
and
block
production.
B
Once
this
thing
is
deployed
and
say,
there's
a
whole
day
of
roots
in
here
then
now
you
get
back
to
the
same
index
or
the
same
like
cell,
let's
say
of
the
Ring
buffer,
and
if
you
haven't,
you
know,
if
you
for
some
reason
missed
like
writing
in
the
new
route.
What
would
happen
is
you
would
have
the
old
Route?
If
that
makes
sense,
like
modulo
say
a
day
and
I
tried
to
make
a
little
graphic
here,
you
can
imagine
we
go
along
and
fill
each
cell
with
like
a
root.
B
So
now
it
has
like
this
nice
purple
color
because
there's
like
good
data
here,
but
then
we
missed
a
slot
right
there,
where
there's
like
the
red
circle
and
that's
kind
of
indicating.
Okay,
so
sure
there
was
a
root
here,
but
it
was
actually
the
root
from
like
it
would
have
been
that
slot
modul
the
size
of
the
Ring
buffer
right.
B
So
it
would
have
been
like
yesterday's
slot
at
that
point
in
time,
not
today's
slot
that
we
want,
and
that
would
be
bad
if
you
could
say
hey,
give
me
the
root
for
this
slot
and
it's
just
like
the
wrong
information
like
you
can
imagine,
and
somehow
you
like,
have
a
reaking
protocol
and
you
need
to
know.
Okay
if
my
valary
was
slashed
at
this
point
in
time,
like
their
stake,
is
no
longer
any
good
in
my
thing
and
so
I
need
to
like
do
the
accounting
in
the
execution
layer
to
make
up
for
that.
B
What
was
the
roots
that
I
had,
and
you
actually
will
only
return
data
if
the
time
stamp
matches
the
one
you're
querying
and
then
otherwise,
you
just
forget
exactly
what
we
say:
I
think
you
just
return
nothing.
You
do
like
a
revert
so
now
there's
no
way
to
get.
Let's
call
it
stale
data
out
of
the
contract
and
I
lifted
this
pseudo
code
from
the
EIP,
we'll
just
I'll,
just
call
it
some
nice
things,
but
essentially
it's
saying
you
know
the
things
I've
just
covered.
So
as
you
go
to
execute
this
thing,
you
check.
B
First,
you
know
who's
calling
this
contract
within
the
evm.
If
it's
the
special
system
address,
then
you
actually
want
to
run
the
set
routine.
If
not,
you
want
to
call
the
git
routine
and
again
the
logic
or
like
the
rationale
is
that
no
one
should
be
able
to
like
fabricate
a
transaction
from
the
system
address.
We
just
pick
this,
like
particular
address
and,
assuming
you
know
all
of
our
cryptography
is
secure.
There's
no
way
for
someone
really
to
like
find
the
private
key
for
this
address
and
then
make
a
transaction
as
as
that
Center.
B
So,
if
that's,
if
that's
the
case,
then
we
can
use
this
to
actually
know.
Are
we
in
like
the
system
context
or
not,
and
if
we
are,
then
we
will
call
the
set
routine
here,
which
is
basically
saying.
Okay.
Give
me
the
time
stamp
of
the
block
turn
it
into
these,
like
indices
into
each
of
these
separate
ring
buffers
where
I'm
going
to
put
the
timestamp
along
with
here
it
says,
call
data,
but
the
understanding
is
that
the
call
data
contains
these
32
bytes,
the
parent
beac
block
gr.
B
If
you
are
not
the
system
address,
then
you
would
call
the
gate
routine,
where
again
pretty
straightforward.
If
we
have
anything
other
than
32
bytes
we're
actually
just
going
to
revert,
because
we
we
demand
that,
because
we
should
only
be
getting
Roots
into
this
thing
or
sorry
only
get
time
stamps
into
this
thing,
and
we
want
the
time
stamps
to
just
be
the
word
size
of
the
DM.
That's
just
what
will
naturally
come
so
then,
given
the
time
stamp
that
we're
interested
in
in
the
call
data
we
convert
that
into
like
the
same
index.
B
B
We
can
go
ahead
and
just
read
the
root
in
the
same
way
and
return
that
to
the
caller,
so
pretty
lightweight
yeah
should
be
pretty
straightforward,
so
that
was
looking
at
implementation
and
yeah
from
here.
Like
what
kind
of
applications
can
we
imagine
I'll
like
sketch
out
a
few
of
them?
You
know,
hopefully,
if
you're
watching
this,
you
have
more
ideas
and
you
know
can
be
Off
to
the
Races
in
terms
of
building
all
sorts
of
cool
stuff
and
yeah
like
immediately.
B
Builders
bonded
in
the
system
different
things
like
this
and
wanting
to
make
claims
about
that,
because
this
is
a
state
to
to
help
make
secure
constructions.
There
and
right
so
I
mean
the
first
thing
is
immediately:
they
all
all
these
applications
and
even
ones
we
haven't
thought
of
yet
can
use
4788
to
trust,
trustless,
get
access
to
the
the
consensus
layer
and
that's
really
big,
because
it
instantly
improves
all
the
security
of
like
all
of
them
right.
B
They
no
longer
need
these,
like
trusted
multisig
to
do
anything
they
just
yeah
now
have
this
sort
of
as
like
a
protocol
facility,
and
that's
really
great.
So
you
know
I'll
I'll
drill
in
a
bit
to
some
of
these
different
applications
with
saking
pools
right.
So
like
a
very
like
obvious,
like
maybe
almost
too
obvious,
one
is
just
literally
knowing
you
know.
If
I
have
a
validator
in
my
staking
pool
that
I
want
to
manage,
you
know
as
a
system
in
smart
contracts,
are
they
even
registered
yet
like
what
is
their
life
cycle?
B
Have
they
deposited?
Are
they
active?
Are
they
slashed?
Are
they
not
active?
Are
they
have
they
exited
all
these
different?
You
know
attributes
that
a
validator
can
have
and
that's
going
to
have
implications
for
my
sing
protocol,
similarly
valid
performance.
So
this
is
like
a
big
one
is
saying:
like
hey,
you
know,
I
could
actually
prove
so
we
actually,
you
know
we
record
valid
performance,
essentially
in
the
beacon
State,
and
by
doing
so
you
can
figure
out.
B
You
know
what
Rewards
or
and
or
penalties
they
should
incur
and
again
should
be
very
straightforward
to
see
how
that
could
be
really
helpful
for
a
staking
pool,
because
you
can
now
prove
what
happened
and
then
figure
out.
You
know
maybe
there's
like
some
accounting.
You
want
to
do
in
the
execution
layer
for
this
pool,
and
now
you
can
get
this
information
directly
and
yeah.
There's
like
more
qu
consequences
of
this
Fact.
One
thing
would
be
actually
using
like
a
running
stream
of
this
actually
rate
the
performance
of
a
validator.
B
You
can
imagine,
that's
like
some
nice
little
encapsulated
metric,
maybe
to
say
give
like
node
operators
in
Lio
like
a
scorecard
of
sorts
or
like
a
report
card.
You
could
then
imagine
like
a
more
complex
saking
pool
where
you
actually
use
performance
to
actually
like
make
tranches
of
the
LST.
So
it's
like
a
big
thing
is
you
know
for
decentralization
reasons.
We
want
lsts
to
have
like
very
heterogenous
validator
composition,
but
then
you
know
the
more
heterogenous
they
are
the
harder
it
is
to
have
a
single
LST
that
like
represents
all
of
them
and
yeah.
B
You
could
start
to
imagine
tinkering
with
things
here
around
like
actually
making
different
like
classes
of
of
risk
based
on
valid
performance
yeah.
There
there's
like
a
whole
fun
R&D
space
there,
yeah
I'll,
just
say
that
for
now
and
yeah
reaking
I
mean
again
like
even
very
simple
basic
things,
like
you
know,
is,
is
the
valter
registered
in
a
way
that
they
can
participate
in
my
reaking
protocol
like
the
way
at
least
like
I
layer
and
probably
most
or
like,
even
really,
all
restricting
constructions?
B
You
can
imagine
they're
going
to
the
way
that
they
work
is
basically
as
a
validator.
You
can.
You
can
have
stake
at
the
consistence
layer,
but
then,
when
it
comes
back
to
the
execution,
layer
basically
need
to
flow
through
the
the
reaking.
You
know
protocol
in
in
the
execution
layer
and
that's
actually
where
the
accounting
will
happen.
So
if
there
are
any
slashings
there,
they
can
be
accounted
for
and
otherwise
yeah
these
like
reaking
apps,
are
like
meaningless,
or
rather
they
just
they
don't
have
any
security.
B
So
this
is
like
a
very
critical
part,
so
you
can
actually
check
hey.
You
know:
is
this
validator
correctly
or
iured
to
even
participate
in
my
application
in
the
first
place?
Another
one
yeah
is
understanding
like
our
Valor
is
slashed,
so
this
is
saying
like
well
yeah
with
any
reaking.
Broadly
there's
this
mismatch
almost
because
you
have
the
stake
at
the
CL
and
that's
where,
like
independently
things
could
happen,
there
could
be
like
consus
faults
or
cons
penalties.
You
know
less
harshly
that
can
happen
there
and
then
separately.
B
You
have
this
whole
Apper,
where
you
could
have
like
Apper,
slashings
or
Apper
penalties,
and,
like
already
these
things
are
just
like,
like
completely
out
of
sync,
which
is
actually
like
not
great
for
security
of
either
the
application
or
the
consist
layer,
but
that
all
being
said
you
could
imagine
reaking
constructions
where,
like
there's
a
much
tighter
sync
between
these
two
values
and
then
actually
what
happens
is
like.
The
whole
thing
is
is
more
secure
simply
because,
like
if
I'm
slashed
at
the
CL,
that's
probably
going
to
have
implications
for
my
application
layer,
validation.
B
If
I'm
slashed
in
my
application
layer
app,
then
that's
going
to
have
implications.
You
know
like
I,
should
actually
maybe
almost
be
slashed
as
much
as
I
am
in
the
or
you
know
if
I
have
some
penalty
from
an
application
failure
that
should
probably
be
upstreamed
so
to
speak
into
M's
representation
as
well
yeah,
there's
more
I
can
say
about
that.
But
reaking
definitely
will
you
know,
be
improved
or
would
very
much
need
access
to
this
type
of
information
that
the
CIP
provides.
B
This
one
I
kind
of
said
was
more
speculative,
but
again
just
like
MB
Management
there's
a
many
things
we
want
to
do
around
like
improving
the
trust
model
of
M
boost,
which
is
our
our
offchain
PBS
and
ultimately,
it
just
means
like
iterating
different
bits
of
the
design
towards
more
of
like
what
an
enshrined
PBS
with
look
like
and
yeah.
This
is
more
of
like
a
very
high
Lev
type
of
thing.
B
We
could
imagine,
but
yeah
there's
this
notion
of
Pepsi,
which
is
saying
okay,
if
there's
like
a
fixed
auction
format
with
Meo
today.
What
if
this
was
actually
like
a
programmable
thing
you
could
do
and
then
you
could
very
much
imagine
wanting
to
have
like
access
to
this.
This
consist
Slayer
stake
to
do
do
different
things
and
yeah
from
there.
B
Think,
given
you
know
the
value
of
the
information
that
it
sort
of
enables
it's
yeah
there
there's
a
lot
that
could
happen,
whether
that's
like
better
stake,
pooling
constructions,
whether
that's
better
reaking
constructions
or
other
things
like
this,
so
I
think
that
was
all
I
had
for
now
and
yeah.
If
there's
some
questions,
I'm
happy
to
take
some
questions.
A
Well,
thank
you
so
much
Alex
for
the
presentation.
It
was
really
interesting
to
follow.
The
evolution
of
The,
Proposal
I
sure
have
a
few
questions
on
that
will
get
there
in
a
bit
but
other
than
that.
I
love
the
pseudo
code
in
EIP,
I'm,
not
sure.
If
I
have
ever
seen
pseudo
code
added
in
any
of
the
EIP
I've
seen
people
adding
especially
on
ERC
side.
A
People
here
on
the
call
today,
if
you
have
any
question,
feel
free
to
either
raise
your
hand
or
maybe
put
it
on
the
chat,
so
I
can
invite
you
in
the
meantime,
I
would
like
to
start
with
the
first
question,
as
you
mentioned
in
your
talk
about
the
ACDC
or
acde
meeting
discussion,
I'm
wondering
about
the
relationship
with
EIP
210.
So
in
earlier
ecde
meeting
Martin
suay
mentioned
about
the
proposal
which
was
originally
proposed
for
block,
has
refactoring
by
vitalic
Duan
and
the
proposal
isn't
stagnant.
A
That
means
we
never
implemented
that
things
have
changed
now
we
are
in
the
proof
of
a
stake
world.
So
my
question
to
you
is:
do
you
see
EIP
4788
as
an
extension
of
EIP
210
in
more
related
word,
or
do
you
think
that
we
have
carried
anything
from
those
proposal
or
these
proposal
are
independent
of
each
other?.
B
Yeah
I
would
definitely
say
that
at
least
like
the
thinking
behind
210
is
reflected
here.
So
maybe
I
have
my
numbers
off,
but
I
believe
that
the
point
there
was
essentially
to
move
the
block
cashes.
So
already
today
we
have
access
in
a
very
similar
way.
You
can
get
access
to
these
like
cryptographic.
B
You
know
we
don't
call
them
Roots,
but
we
have
like
hashes
of
the
execution
block
headers
those
are
in
the
evm,
and
so,
if
you
want
to
make
proofs
about
the
execution
State,
you
can
kind
of
do
this
in
a
very
similar
way
and
the
way
it
works
today
is
that
you
there's
just
this
block
this
sorry.
This
op
code
block
hash
that
gives
you
access
to
say
the
last
236
of
these
execution,
hashes
and
yeah
from
there
you
can
like
make
proofs.
You
know
verify
proofs.
B
However,
you
want
in
the
evm
and
I
think
again,
if
I
misremember
any
different
IP,
just
let
me
know
but
I
believe
with
210.
The
idea
was.
We
would
essentially
refactor
this
so
that
we
would
move
them
from
like
this
op
code
format
actually
into
the
DM
State
very
much.
How
like
478
is
doing-
and
this
is
actually
where
the
relation
is-
is
there-
was
a
design
decision
with
this
CIP
to
actually
not
copy
the
block,
the
the
block,
hash
off
code
approach
and
do
more
of
this?
B
Like
you
know,
data
is
in
the
state
approach
with
the
IP.
The
reason
why
is
because
we
want
to
support
stateless
execution?
This
is
a
different
call,
but
there's
the
whole
veral
effort
and
moving
from
a
you
know,
Merkel
Patricia,
try
that
we
have
today
to
a
veral,
try
and
there's
many
reasons
we
want
to
do
this.
One
of
them
is
that
it
actually
will
support
efficient
proofs
about
the
C,
State
and
or
sorry
the
execution
State,
and
this
is
helpful.
B
A
B
Like
you
know,
it's
not
the
end
of
the
world,
but
it
does
mean
like
bigger
proofs
and
also
just
like
one
more
thing
to
think
about,
and
then
that
actually
has
like
I
think
pretty
profound
implications
for
implementation.
You
know:
are
there
bugs
in
the
clients,
like?
Is
the
client,
secure
and
and
all
of
this?
B
So
it's
far
simpler,
just
to
say
Hey,
you
know
if
we
have
this
like
unified
approach
to
like
accessing
States,
that's
like
much
preferred
and
that's
definitely
what
that
EIP
was
trying
to
do
and
also
what
this
one
is
doing
by
putting
the
the
data
like
the
history.
Almost
we
care
about
directly
in
the
state.
A
That
sounds
good.
Perhaps
this
is
the
time
that
that
we
can
move
the
proposal
210
to
withdrawn
when
we
have
4788
deployed
on
the
main
net,
all
right
moving
to
maybe
a
similar
question.
I'm
talking
about
EIP
4788
version
2,
originally
written
as
a
pre-compile
EIP
4788,
is
on
the
table
for
quite
some
time,
but
we
saw
some
different
discussion
points
on
various
codev
calls.
We
saw
the
pr
7456
by
Matt
and
again
this
is
called
as
version
two
for
this
proposal.
A
B
Yeah,
so
the
main
thing
was
moving
from
a
precompile
approach
to
implement
the
EIP
to
this
system.
Contract
idea
that
I
was
discussing
so
right,
like
rather
than
have
native
ex,
like
a
native
implementation
that
you
would
call
out
where,
like
there
would
be
some
state,
but
it
would
just
be
attached
to
like
almost
this
like
native
evm
B
code,
it
doesn't
really
make
sense,
but
you
know
almost
like
native
B
code.
B
B
This
notion
that
there's
like
a
big
security
argument,
which
is
that,
basically,
if
there
were
a
problem
with
the
pre-compile
say
between
implementation
of
two
clients
that
actually
lead
to
like
gu,
it's
a
split
because,
like
one
execution
client,
would
think
this,
and
someone
else
would
think
this,
and
you
know
now
there's
a
chain
split.
These
are
bad
and
should
be
avoided
at
like
most
cost,
and
you
know
one
way
to
do
that
is
you
can
actually
say
Okay,
rather
than
sort
of
pull
in
like
an
even
bigger
base
of
implementation.
B
That
needs
to
be
correct
and
vetted,
and
all
of
this
to
know
that
this
is
not
going
to
happen,
we
can
actually
like
restrict
the
scope
by
moving
to
like
a
fully
sort
of
hosted
implementation,
let's
say
inside
the
evm
and
that's
ultimately
what
the
CIP
is
doing
now
with
B2
and
yeah.
You
know
the
thing
is
there
could
still
be
a
bug
in
the
implementation,
but
what
would
mean
is
that?
B
Okay,
maybe
now,
the
security
of
this
Oracle
is
broken
like
the
the
you're
getting
back
a
stale
or
like
the
just
correct
block
rout
block
route,
which
would
also
be
bad,
especially
for
all
these
applications.
I
was
talking
about,
but
you
would
avoid
this
chain
split
because,
basically
the
you
know,
the
client
would
still
compute
a
chain
and
the
chains
would
all
be
un
lock
step,
even
if,
like
the
application,
doesn't
make
any
sense.
So
you
know
I
think
all
in
we
all
thought.
A
That's
awesome.
Security
is
always
a
very
compelling
reason.
Talking
about
security.
Consideration
I
find
that
section
as
too,
as
of
now
in
the
EIP
I
would
highly
appreciate
you
know
adding
something
over
there
like
what
are
the
security
consideration
that
client
should
be
aware
of,
while
implementing
or
anything
that
makes
more
relevance
to
implementers
of
this
proposal
all
right.
My
next
question
is
about
changes
on
El
CL
clients,
so
this
EIP
involves
both
layer.
A
The
proposal
reads
as
a
exposing
Beacon
route
inside
the
evm
allows
for
trust
minimized
access
to
the
consensus
layer.
Yet
this
EIP
is
listed
at
execution
layer
EIP.
Does
it
mean
spec?
Changes
are
only
for
El
and
on
CL
client.
It
is
either
minimal
or
none
or
is
it
because
it
is
getting
into
system
contract.
B
Right,
so
there
are
some
changes
at
this
layer
to
support
this
they're,
actually
quite
minimal,
even
smaller
than
on
the
El
side,
and
essentially
it's
just
saying
that
when
I
go
to
produce
a
block,
the
seal
will
also
need
to
send
over
the
route,
which
is
what
the
will
put
into
it's
execution.
Payload.
And
then
you
know
the
rest
kind
of
follows
from
there.
So
there's
essentially
a
small
change
to
the
engine
API
during
block
production,
but
that's
pretty
much
it
so
yeah,
pretty
lightweight
and
yeah
I.
A
That's
right
right.
My
next
question
is
about
the
timing.
The
Proposal
was
drafted
in
February
2022
and
we
have
had
at
least
two
upgrades
since
then.
Both
of
them
were
major
upgrades.
Why
it
couldn't
have
been
considered
earlier,
I'm
more
looking
into
the
roadblockers.
If
there
were
any
and
not
the
upgrade
priorities.
B
A
B
Right,
yeah,
fair
question,
I
mean
I
think
it
is
mostly
just
priority,
though
you
know
we
wouldn't
like.
We
did
pretty
much
everything
we
could
to
ship.
You
know
just
the
merge
and
not
anything
else,
and
then
from
there.
The
question
was
like
okay.
Well,
there's.
Actually
this
other
really
big
piece
which
is
withdrawals.
So
then
we
wanted
to
ship
that
and
then
yeah
I
mean
conceivably.
We
could
have
included
this
in
an
earlier
Fork,
but
yeah.
There
either
wasn't
enough
sort
of
bandwidth
amongst
the
CVS
or
yeah
I.
B
A
C
Sure,
thanks
Pua
and
hey
Alex.
My
question
is
just
kind
of
clarifying
around
the
implications
for
liquid
staking
protocols
and
like
the
removal
of
trust
assumptions
around
the
oracles
for
these
protocols.
I
think
really
my
question's
more
of
like
a
technically
how
it
works
from
deriving
like
something
like
the
validator
effective
balance
from
the
consensus
ler
block
route.
That's
now
exposed
in
the
evm
I'm
just
wondering
if
that's
still
something
that
requires
a
trusted
actor
to
perform
or
if
there's
a
way
that
it
can
be
done.
B
Right,
that's
a
really
good
question.
So
that's
that's
certainly
like
again,
like
the
I
think.
A
very
big
motivation
of
this
work
is
just
to
say
yeah
like
how
much
can
we
imagine
these
different
applications
like
sing,
pools
and
like
can
we
make
them?
You
know
totally
trustless
and,
for
example,
if
they
need
to
like
prove
off
the
effective
balance
of
some
validator,
that's
great,
but
then
yeah
it's
like
you
know.
Maybe
they
have
trust's
access
to
the
the
data
but
yeah
so
either
way.
B
It's
a
good
question
because
actually
answer
is
there's
still
some
pieces
that
we
may
want
to
consider
another
EIP
where
you
would
actually
even
like
fully
remove
any
trusted.
Bits
And,
The
Trusted
bits
I'm
getting
at
is
that
there
are
some
things
in
the
beacon
state
where
we
actually
may
want
to
change
the
layout
of
different
data
and
that
actually
changes
the
format
of
the
proof
itself.
B
So
you
know
in
the
long
run.
Maybe
you
know
these
indices
I'm
talking
about
will
never
change.
So
it's
never
an
issue.
Maybe
there's
another
EIP.
That's
like
essentially
just
like
a
more
abstract
proof.
You
know
proof
verification,
promile,
and
you
know
you
could
essentially
subsume
this
this
functionality
and
make
the
whole
thing
fully.
Trustless
yeah.
So
there's
like
some,
certainly
some
further
research.
B
We
could
do
there
to
probably
improve
this
even
further,
but
that
being
said,
the
only
time
these
things
that
you
know
this,
this
data,
I'm
talking
about
would
change,
would
be
at
like
across
hard
Forks.
So
it's
not
something
that
is
like
even
a
super
urgent
risk.
Even
after
deploying
this,
this
AIP.
A
Thank
you
so
much
Alex
I
know
it
is
about
time.
I
just
wanted
to.
Let
you
know
I
see.
The
proposal
is
still
in
the
draft
status.
I
would
highly
recommend
it
to
be
moved
towards
the
reviewer
status,
but
before
you
make
the
pull
request,
it
would
be
really
nice
to
see
test
cases.
Reference,
implementation
and
security.
Consideration
section,
which
is
still
mentioned
as
to
do
have
some
words
over
there
I
know
the
proposal
is
already
on
davet,
so
it
would
be
nice
to
fill
up
and
move
the
proposal
as
desde.
B
Yeah
otherwise
no
I
mean
thank
you
all
for
having
me.
Hopefully
this
was
helpful
and
like
at
least
shared
some
of
the
thinking
in
the
context
that
went
into
this
yeah.
Otherwise,
definitely
consider
this.
If
you
need
this
information
in
your
application
like
please,
take
a
look
feel
free
to
reach
out.
If
you
want,
we
can
chat
about
how
to
integrate
it
into
your
your
application
and
yeah
otherwise,
I
think
that's
it
for
now,.
A
Very
well
Alex
Stokes.
We
thank
you
for
joining
us
on
pep
and
talking
about
upcoming
changes
with
EIP
4788.
We
look
forward
to
seeing
this
proposal
on
the
public
test
net
and
finally,
on
the
main
n
with
Denon.
On
this
note,
thank
you
to
all
our
YouTube
viewers
for
watching
and
podcast
subscriber
for
listening
to
this
special
episode.
Should
you
have
any
question
on
this
or
any
other
topic?
Let
us
know
at
eat.
Caters
Discord
check
out
the
description
for
more
info,
we'll
be
back
with
another
interesting
talk
until
next
time.