►
From YouTube: PEEPanEIP # 112: EIP-6110: Supply #validator deposits on chain #ethereum #executionlayer
Description
Resources:
-----------------
EIP-6110 - https://eips.ethereum.org/EIPS/eip-6110
Slides - https://docs.google.com/presentation/d/1Q2X8sNzbhdGjOo0IVmjxYfMEdznTRArKGj2DznYCbLk/edit
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
--------------------------
Mikhail Kalinin @mkalinin2 | Kevin Bogner @kevin_bogner | Navie Chan (NC) | Pooja Ranjan @poojaranjan19
Topics covered
-------------------------
0:25 - Skip intro
0:35 - Intro to EIP & guests
1:07 - Guest’s intro - Mikhail Kalinin
1:48 - Guest’s intro - Kevin Bogner
2:28 - Guest’s intro - Naive chan
3:53 - the presentation begins
4:01 - The agenda
4:17 - EIP-6110
4:29 - Deposit reform
4:34 - Eth1Data poll
8:33 - On-chain deposits
10:06 - Benefits of EIP-6110
12:32 - EIP-6110 Data complexity and DOS vectors
13:57 - Transition period
15:25 - Changes in the Execution Layer
17:06 - Deposit structure
17:41 - Block header and Body
18:27 - Block creator
19:44 - Block validator
20:06 - Genesis Config
21:06 - Current state and TODOs in development
22:20 - Specs on Consensus Layer
22:24 - Implementation on Lighthouse - Containers
23:19 - Block processing
23:53 - Deposit receipt processing
24:17 - Testing strategy EIP-6110
25:09 - Implementation status
25:51 - Challenges
27:20 - Guests’ Twitter Contact
28:08 - End of presentation
28:51 - Question - how does data polling will complicate things for CL clients, especially at the time of forking?
30:40 - Do people will have to wait for the deposit sweep finalized before picking up the validator index?
31:04 - Is there a queue system on the EL side?
33:38 - Will the deposit on the EL side go on the SSZ container?
35:15 - What was the rationale to drop the queue and we have a queueless design?
36:45 - Will there be any effect on users' transactions at the time of transition?
37:49 - Will we need EIP-4881 after 6110 is deployed?
39:45 - When on the mainnet, any timeline?
41:05 - Discussion placeholder for this proposal?
44:14 - Word of advice for the Ethereum Community
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
A
Welcome
to
P
penit
episode,
112
I
am
Puja
ranjan
and
super
excited
to
host
our
special
guest
to
talk
about
upcoming
protocol
changes.
Eip6110
Supply,
validated
deposit
on
the
chain
is
a
standard
track.
Core
EIT
originally
proposed
in
December
2022,
has
been
co-authored
by
ethereum
researchers,
Mikhail
kalanin,
Danny,
Ryan
and
Peter
Davis.
To
provide
an
overview
of
this
draft
proposal,
we
are
joined
by
Kevin,
Wagner,
Navi
Chan
and
one
of
the
co-authors
Mikhail
kalanen.
We
are
also
joined
by
the
co-author
Peter
Terrace.
Welcome
all
thanks.
B
Puja
so
I
guess
we
can
search
for
by
introducing
ourselves
yep
okay,
so
my
name
is
Mikhail
I'm
from
consensus,
certainty,
leader
of
txrx
Team,
we're
working
in
on
the
ethereum
protocol
and
ethereum
political
research,
space,
adren
ethereum
back
into
town
2015
in
its
early
days,
and
my
most
significant
contribution
to
the
theorem
by
this
time
was
I
participating
in
the
merged,
another
brilliant
developers
and
researchers
and
yeah.
It
was
interesting
and
really
related
to
the
context
of
our
talk
today,
because
this
6110
proposal
is
a
kind
of
follow-up
to
the
merge.
C
So
my
name
is
Kevin
I'm
based
in
Stuttgart,
Germany
I
started
off
in
core
development,
about
I.
Think
it's
now
eight
months
ago
and
with
a
program
called
ethereum
protocol
fellowship
and
the
program's
goal
is
to
onboard
people
to
ethereum
core
development
and
the
whole
program
lasted
for
six
months
and
was
the
third
iteration
of
the
program,
and
during
this
time
I've
worked
on
a
project
with
navy
with
NC
called
consensus.
D
All
right,
yeah,
so
I
will
continue,
so
my
name
is
NC
or
navy.
So
yeah
same
with
Kevin
like
we
were
in
the
same
cold
heart
in
the
in
the
ethereum.
You
know,
protocol
Fellowship
I
actually
learned
about
this
Fellowship
on
Reddit.
It
was
like
one
day,
I
just
browse,
read
it
and
it
says
like
oh,
this
is
permissionless,
so
I
just
joined
and
you
know
start
contributing
yeah
so
currently
I'm
working
on
ethereum
as
like
a
side
job
like
a
on
a
weekend
thing
so
yeah.
D
E
Hello,
I'm,
Peter,
Davies
I
have
a
similar
background
to
Navy,
though
I
did
maths
at
University
I
then
joined.
What's
now
the
ethereum
political
Fellowship
that
was
called
something
else,
then
yeah
I've
been
working
on
specifying
the
execution
left
of
the
last
almost
two
years
at
this
point
and
I
did
some
work
on
the
CIP
making
some
of
the
suggestions
for
the
design
and
also
doing
some
denial
of
service
analysis.
I.
A
B
So,
let's
get
to
the
proposal,
so
the
agenda
is
quite
support
for
today,
we'll
come
through
the
depository
form.
So
it's
benefits
our
security
analysis
bit
and
guys
we'll
talk
about
the
details
of
execution
and
consensus,
layer,
implementations
and
all
touch
based
on
the
status
of
the
Prototype
and
share
some
challenges
we
found
during
working
on
the
Prototype.
B
So
what
we
see
here
is
basically
the
our
blockchain
that
everyone
is
familiar
with.
We
have
Beacon
blocks
and
every
block
every
beacon
block
contains
the
execution
payload
with
transactions
and
the
other
chain.
Data
begin
blocks.
Also
carry
deposits,
which
is
a
subject
of
horror,
talk
today,
so
every
2048
slots
there
is
the.
If
one
voting
period
that
happens
and
this
eighth
one
during
this
Ethan
voting
period,
proposers
wrote
on
the
view
of
East
one
data.
B
You
can
see
it
here,
it's
basically
three
Fields
this
on
the
view
of
its
one
data
adds
some
follow
distance,
so
the
follow
distance
is
also
defined
as
2048
blocks.
This
large
number
has
been
picked
to
make
this
a
rework
resilient
and
the
entireth
one
data
pole
operates
on
the
assumption
that,
should
there
be
any
reorg
in
the
network,
it
will
not
be
the
size
of
the
reward.
It
will
not
last
more
for
more
than
2048
blocks,
which
is
quite
reasonable.
B
We
are
not
supposed
to
see
such
free
orgs
on
the
main
net,
so
these
two
parameters,
basically
as
a
factor
of
a
big
delay
before
between
the
submit
and
the
deposit
transaction
like
here
and
included
this
transaction
into
the
begin
block
to
be
processed
by
consensus
layer
if
one
voting
period
can
last
less
than
2048
slots.
Basically,
we
need
for
more
than
a
half
of
proposers
from
this
period
to
agree
upon
a
certain
sample
of
fifth
one
data.
B
Each
one
data
includes
the
root
of
deposit
three,
the
deposit
count
content
the
block
hash
at
this
follow
distance,
as
mentioned
before.
So
in
the
best
case,
the
delay
between
submitting
the
transaction
and
included
this
transaction
and
processing
of
this
transaction
by
the
consensus
layer
will
be
around
12
hours.
So
every
deposit
is
a
company
with
a
proof
which
is
a
miracle
proof.
I'll
link
it
to
this
deposit
route
of
with
one
data,
and
this
is
one
of
the
requirements
of
one
of
the
validity
conditions
of
deposits
on
the
consensus
layer
as
of
today.
B
The
Fed
match
transaction
logs,
where
the
deposit
data
of
a
deposit
contract
where
the
deposit
data
are
actually
being
contained,
and
all
this
requires
this
Machinery
to
get
bootstrapped-
requires
the
execution
layer
side
to
be
fully
synced.
It
also
requires
consensus
layer
side
to
obtain
the
entire
deposit
depository
to
start
actually
include
deposits
into
blocks.
So
that's
sort
of
complexity
on
the
Chain
side
and
on
in
the
inside
of
a
client
was
inevitable.
When
we
had
two
chains
in
the
past,
one
was
the
proof
of
stake
they
can
chain.
B
The
other
one
was
the
proof
of
work,
ethereum
mainnet,
and
this
is
basically
the
bridge
mechanism
between
the
two
to
induce
deposit
data
to
the
consensus
layer,
client.
But
today,
after
the
merge
has
happened,
and
we
have
only
one
chain,
we
can
simplify
this
mechanism
a
lot
and
this
is
actually
what
is
proposed
by
ip6110.
So
the
essence
of
this
proposal
is
the
on-chain
deposits
approach.
B
How
does
it
work
basically
execution
layer
client
when
building
a
block
its
scans
for
the
transaction
list?
That
is
prepared
to
be
included
for
you
into
this
block
and
looks
for
deposit
transactions
in
it?
Then
it
gets
the
pay
logs
emitted
by
the
deposit
contract
inside
of
those
deposit
transactions,
parses
deposit
data
out
of
it,
and
includes
this
deposit
data
as
a
separate
list
into
the
same
block.
B
So
after
that,
this
blog
is
submitted
to
the
network
and
every
client
that
receiving
this
block
passes
the
execution
payload
to
the
execution
layer,
client
and
the
execution
layer
client
as
part
of
its
one
as
part
of
its
Block
validation's
matches
this
data,
so
the
execution
layer
client
will
ensure
that
the
list
of
this
data
is
corresponding
to
the
deposit
transactions
that
are
included
in
this
block
if
it's
not
corresponding.
If
there
is
a
mismatch
between
these
two
lists,
the
block
is
deemed
invalid.
B
After
that
consensus
to
your
client
can
securely
read
this
deposit
date
and
process
them,
so
we
don't
need
any
proof
here.
So
all
the
proof
is
happening
on
the
execution
layer
side
and
likewise
we
don't
need
it.
One
data
feature
anymore,
because
this
data
are
naturally
included
on
chain
and
are
accessible
by
the
consensus
layer.
Client.
Okay.
So,
let's
summarize,
the
benefits
of
this
proposal,
first
of
all,
is
just
there
is
instant
deposit
inclusion
versus
like
wait
versus
waiting
for
about
12
or
12
hours
in
case
of
51
data
pool.
B
This
proposal
allows
us
to
get
rid
of
the
quantum
complexity
which
is
which
discounted,
from
necessity
to
have
this
F1
data
Patcher
component,
which
already
has
been
proven
to
be
brittle.
We
had
some
problems
regarding
that
in
the
past
on
the
main
net,
so
so
some
block
proposals
were
freedom
for
quite
short,
but
what
short
period
of
time,
but
it
still
was
annoying
quite
annoying
so
and
this
component
is
pretty
little
and
we
don't
know
what
can
happen
next.
So
there
is
the
new.
B
The
on-chain
deposits
does
not
depend
on
historical
deposit
data,
and
this
is
especially
important
in
the
context
of
historical
data.
Expiry
proposals
like
for
Force.
If
a
portion
of
execution
blocks
can
be
expired
and
not
contained
in
a
node
anymore.
In
a
note,
a
data
that
node
has
access
to.
We
would
need
to
obtain
a
deposit
contract
snapshots.
B
Those
malicious
valeries
has
a
non-trivial
probability
of
coming
to
agreement
and
forcing
everyone
to
come
to
agreement
on
some
arbitrary
fund
data,
which
would
allow
them
to
induce
more
and
more
deposits,
and
though
this
the
number
of
the
files
will
be
constrained
by
the
existing
constants.
We
have
in
a
protocol,
but
anyway,
then,
if
they
come
to
agreement
on
this
one
data
that
does
not
exist,
they
can
increase
their
portion
of
stake
like
why
is
taken
out
of
thin
air.
B
So
there
is
an
issue
about
that,
and
while
chain
deposits
comes
with
basically
the
same
security
thresholds
as
the
core
protocol,
because
they
are
secured
by
the
corporate
call
actually
a
bit
of
data
complexity
and
those
factors
analysis,
the
historical
data
growth
is
negligible.
60Mb
diet
per
year
is
what
we
have
at
the
current
pace
and
which
is
really
nothing
with
respect
to
other
data.
Blockchain
data
that
we
have
to
deal
with.
B
What
is
only
negligible
is
that
clever
actor
can
pack
up
to
1200
deposits
in
a
30
million
gas
block
the
size
of
a
block
that
we
have
today
on
the
main
map
and
yeah.
It
means
that
yeah,
every
deposit
has
a
signature
that
has
to
be
verified
during
processing
this
deposit
and
having
1200
deposits
in
the
block
would
mean
that
the
block
validation
can
be
delayed
by
more
than
a
second
by
the
signature
verification.
B
Fortunately,
there
is
the
the
minimal
deposit
amount
that
we
have
in
the
deposit
contract,
which
is
one
if
and
this
slide
minimal
deposit
demand
gives
us
quite
good
protection
from
this
kind
of
Dos
vectors.
So
someone
will
have
to
obtain
12
1200
each
and
to
employ
this
attack,
and
this
it
will
not
be
burned,
it
will
be
deposited
and
later
on,
it
can
be
withdrawn
and
supports,
but
anyway
it
does
not
seem
to
be
a
viable
dos
attack
long
term.
So
one
can
do
this,
but
it
will
just
slow
down
one
block.
B
It
doesn't
seem
like
a
big
problem.
Yeah
first
about
there
is,
there
will
be
a
transition
period,
so
we
have
F2
and
I.
Can
we
have
a?
We
are
switching
from
one
mechanism
to
the
other.
So
how
does
this
look
like
after
6110
is
activated
after
the
activation,
and
there
will
be
a
gap
because
of
this
follow-up
distance
and
the
voting
period
time
and
the
new
deposits
that
will
be
included
on
chain
will
start
to
be
processed
instantly.
B
We
can
block
deposits
that
are
allowed
since
that
time,
and
after
that
happens,
clients
can
remove
with
one
data
for
Machinery
in
uncoordinated
fashion,
because
the
protocol
will
not
depend
any
more
on
that.
For
this
purpose
we
add
one
variable
with
which
will
hold
this
first
deposit
on
chain
deposit
index
in
the
begin
state.
So
that's
that's
a
valid
transition
now
I'm
in
our
Navy
all.
D
Right,
yes,
so
I
will
cover
the
changes
on
the
execution
layer.
Side
yeah.
So
here
is
a
list
of
you
know
major
changes
on
the
execution,
client
yeah.
So,
first
of
all,
like
you
know,
obviously
we
need
to
define
the
deposit
structure
like
what
kind
of
fields
there
is
in
the
execution
client.
It's
mostly
for
you
know
the
engine,
API,
no
request
parameters
and
the
response,
and
also
like
you
know,
for
the
rlp,
the
input
and
the
output
and
then
on
the
execution
payload.
D
It
will
be
very
similar
to
the
current
execution
payload
except
we,
you
know,
add
the
deposits
in
there
and
then
on
the
Block
header.
We
have
deposits
Roots
as
a
new
field
and
then
in
the
block
body
we
have
the
deposits
and
then
for
the
block.
Creator.
Obviously
you
know
now
it
creates
blogs
based
on
new
block
header
and
block
body,
but
also
it
needs
to
extract
and
decode
deposits
from
the
transaction
receipts
and
then
for
the
block
validation.
There
needs
to
be
like
a
new
mechanic
to
validate
deposits
in
the
Genesis
config.
D
There
will
be
like
a
extra
parameters
which
is
called
the
deposit
control
address.
This
is
something
that
you
know
we
can
get
into
later
and
then
also.
We
need
to
design
like
a
series
of
accepting
tests
for
6110.
So
what
acceptance
test
is
it's
like
a
series
of
API
calls
to
the
execution
clients
and
then
for
each
API
call.
You
know
we
check
on
the
response
and
see
if
everything
you
know
goes
well.
D
So,
for
example,
like
maybe
you
know,
there
is
like
a
full
Choice
updated
and
after
that
you
know,
you
prepare
a
payload
with
deposits
in
it
there,
and
then
you
get
the
payload
and
then
you
check
on
each.
You
know:
API
currency,
the
response
matches
your
expectation
yeah,
so
the
deposit
structure
is
pretty
straightforward,
yeah.
So
the
positive
has
the
public
key,
the
withdrawal
credentials
amount
of
signature
and
index
on
the
execution
layer
side.
These
fields
don't
really
matter
to
the
clients.
It's
just
simply
like
a
placeholder
for
bytes
yeah.
D
But
maybe
one
thing
to
note
is
that
the
public
key
here
is
BLS,
because
it's
originated
from
the
CL
side,
but
PLS
you
know,
was
never
used
on
the
El
side.
So
this
is
a
little
confusing,
but
you
know
nonetheless,
it's
just
you
know
a
name.
You
know
that
just
holds
some
files
yeah.
So
the
changes
here
in
the
block,
header
and
the
block
body
is
very
similar
to
you
know
the
withdrawals
in
the
Shanghai
upgrade.
So
we
have,
as
opposed
to
like
withdrawals
Roots.
D
We
have
deposits
roots
in
the
block
header,
and
then
we
have
you
know
as
opposed
to
withdrawals
who
have
deposits
in
the
body.
The
deposit
Roots
is
the
the
root
hash
of
the
Mercury
on
the
list
of
deposits
in
a
block
body.
Maybe
one
thing
that's
worth
pointing
out
is
like,
because
6110
is
based
on
4844,
so
you
can
see
like
in
the
block
header.
The
deposits
will
should
come
after
excess
data,
gas,
which
is
a
few
from
the
4.44
and
also
yeah.
D
Obviously,
in
the
block
body,
deposits
should
come
after
withdrawals
block
Raider,
so
the
role
for
the
block
Trader
here
is
so
first
off.
It
needs
to
extract
like
a
list
of
deposits
from
the
receipt
logs
and
then
you
know
it
calculates
the
deposit
routes
and
then
no,
you
know
stuff
the
deposit
routes
in
the
header
and
then
the
deposits
into
the
body,
because
the
the
receipts
logs
they
are
like
API
encoded.
D
So
we
need
to
have
like
some
sort
of
mechanism
to
decode
the
ABI
to
extract
the
deposits
from
their
logs,
which
is
like
complete
foreign
in
the
El
world
because
API,
usually
it's
a
it's.
It's
a
CL
thing:
the
pulse
extraction
from
the
logs.
There
are
other
sensitive
because
you
have
like
multiple
receipts
right
and
then
each
receipt
it
has
like
multiple
logs.
So
it
should
like
follow
the
order
strictly.
D
D
Some
of
them
may
not
be
deposits
and
at
the
end,
like
the
extraction,
should
follow
the
other
one
three
and
as
always,
the
way
we
determine
the
log
is
the
deposit
or
not
it's,
based
on
we
check
on
the
address
and
see
if
it's
equal
to
the
deposit
control
address
for
the
validation,
it's
very
similar
to
The
Block
version.
So
pretty
much
like
it
just
extracts.
D
So
the
Genesis
conflict
occurs
like
in
the
block
creation
and
the
block
validation
when
extracting
logs
from
the
the
receipts
it
needs
to
have
like
a
deposit
counter
edges
to
determine
whether
a
log
is
a
deposit
or
not,
even
though,
on
the
main
net,
you
know
the
deposit
contract.
As
you
select
this
address,
it's
not
always
the
case
in
devnets,
or
you
know
some
other
private
Network.
D
D
When
you
do
the
block
creation,
there
will
not
be
any
deposits
inside
the
block
body
and
then
the
deposit
rule
should
be
like
the
the
hash
root
of
the
MP3,
and
then
the
block
validation
should
automatically
fail,
because
when
the
validator
extracts
like
a
list
of
positive
from
the
receipts,
it
shouldn't
get
anything
and
then,
when
it
Compares
nothing
to
something,
it
should
fail
yeah.
So
this
is
the
current
stage
and
also
like
you
know
things
to
do
in
the
future.
On
the
El
side,
so
defining
the
deposit
structure
is
done.
D
The
all
the
you
know,
appropriate
changes
to
the
engine
apis
are
done,
law
creation,
validation
and
also
the
Genesis
conflicts
they're
all
done.
By
being
done,
I
mean
they
are
all
under
the
experimental
features
inside
the
main
branch
on
Bay
Zoo.
So
you
know
anyone
can
you
can
put
a
code
and
just
turn
on
the
experimental
flag,
and
these
features
should
be
activated.
D
A
few
things
to
do
is
the
accepting
tests,
so
we
are
able
to
prepare
payload
with
empty
deposits,
and
you
know
successfully
get
them
for
the
for,
in
the
case
that
you
know
we
want
like
a
valid
deposits,
we
are
still
working
on
it.
Just
because
it's
you
know
quite
hard
to
you
know,
make
up
some
deposits
not
only
deposits
but
also
like
you
need
to
make
up
the
corresponding
logs
in
the
receipts.
So
this
is
something
we're
still
need
to
work
on
and
also
currently
Basu
is
not
44
already.
D
C
Yeah
all
right
I
want
to
talk
about
the
the
specs
under
con
consensus
layer
side,
so
I
decided
to
do
the
implementation
in
Lighthouse,
because
I
have
some
prior
experience
with
it
and
in
terms
of
containers.
We
have
one
new
container
called
deposit
receipt
and
free
containers
that
have
been
extended.
C
C
A
check
has
been
introduced
which
involves
the
deposit
receipt,
start
index
field,
and
this
checks
determines
when
the
former
deposit
mechanism
should
be
disabled,
and
this
is
critical
to
in
ensure
that
all
prior
deposits
are
processed
in
order
to
avoid
any
conflicts
and
between
the
old
process,
deposit
and
the
new
process.
Deposit
receive
function,
so
the
process
deposit
receive
function
essentially
performs
two
tasks:
it
first
initializes
the
deposit
receive
start
index
in
the
beacon,
State
and
second,
it
applies
the
deposits
and
to
achieve
this
apply.
C
C
First,
we
focused
on
setting
up
a
local
devnet,
and
for
this
we
used
a
tool
called
core
courses
and
Contours.
Tosses
is
excellent
for
quickly
setting
up
local
devnets
and
it's
really
straightforward
and
we
quickly
decided
to
move
on
to
a
multi-client
definite.
So
for
this
phase
we
needed
tools
to
help
us
deploy,
destroy
and
swiftly
redeploy
devnets,
and
the
same
setup
is
being
used
for
ongoing
testing.
C
For
eip4844
as
well,
and
we
received
a
lot
of
help
from
peritos
from
the
EF
devops
team,
he
introduced
us
to
kotosis,
created
custom
tools
for
our
multi-client
definite
and
helped
us
a
lot
with
debugging.
So
without
his
support,
this
wouldn't
be
possible
at
all.
So
next,
I
want
to
talk
about
the
current
status
of
the
implementation.
First
of
all
to
eip6110
is
successful,
so
the
Genesis
of
the
definite
is
the
merge.
C
Then
we
spoke
to
Capella
for
l44
and
then
26110
and
all
folks
are
working
smoothly
and
also
deposits
are
being
processed
as
expected.
So,
as
you
can
see
on
the
on
the
right
side,
this
is
an
actual
output
from
our
devnet
from
last
week.
So
it
shows
that
the
deposit
receipts,
as
you
can
see
it,
contains
the
fields
I've
just
mentioned
earlier.
So,
however,
we
also
have
some
items
that
are
currently
work
in
progress.
C
This
issue
was
quite
difficult,
so
we
realized
that
debugging
can
sometimes
be
a
straightforward
process,
but
there
are
also
some
instances
where
nothing
seems
to
be
really
out
of
place
even
in
the
locks.
So
it's
really
difficult
to
pinpoint
the
exact
issue.
Sometime
and
third,
navigating
through
the
versioning
of
execution,
payloads
was
a
little
bit
challenging.
So
we
introduced
a
new
version
v6110
and
understanding
how
these
versions
interacted
was
not
trivial
and
lastly,
the
biggest
challenge
was
harmonizing
and
ensuring
compatibility
for
the
versions
of
basement
Lighthouse
with
respect
to
eip4844.
C
So
as
for
844
is
still
a
work
in
progress.
Finding
the
right
versions
that
are
both
compatible
and
up-to-date
was
tough,
and
this
added
another
layer
of
of
complexity
to
our
process,
but
ultimately,
this
effort
was
worth
it
to
ensure
that
our
prototype
is
as
close
as
possible
to
what
we
are
aiming
for
in
the
in
the
final
output
yeah.
Thanks
for
having
us
it's
it's
been
nice
to
to
have
this
opportunity
to
share
with
you
how
we
envisioned
the
deposit
process
in
the
in
the
future.
C
B
Guys
before
going
to
questions,
I
would
like
to
say
special
thanks
to
Desert
Lighthouse
teams
who
supported
us
in
in
the
development
of
that
prototype
and
the
ethereum
foundation,
who
has
given
a
grant
for
to
fund
this
for
Thai
development
that
was
not
probably
not
possible
without
their
support.
So
let's
move
to
the
questions
right.
A
Great
overview
of
the
present
process
and
explaining
the
proposed
changes,
I'm
excited
to
follow
the
implementation,
progress
and
the
acceptance
tests
and
the
challenges
that
you
have
shared
during
the
implementations
were
great
I
mean
it
is
always
mind-blowing
to
see
how
proposals
those
are
coming
up
are
free
flowing
on
both
El
and
cl.
Thank
you
all
for
sharing
this.
For
the
next
section,
the
Q,
a
section
I
I,
see
here
in
the
chat.
We
do
have
some
questions.
The
first
one
is
from
gajendar
Singh.
F
B
The
current
is
one
data
pause,
reorg
resilient
as
I
mentioned
right,
but
the
new
one
with
this
instant,
instant
deposit
processing,
is
not
that
resilient
reworks.
This
is
because
the
deposit
sequence
in
one
work
in
one
branch
of
a
block
tree
can
be
different
to
the
other
branch
and
means
that,
as
the
according
to
the
existing
proposal,
basically
consensus
layer,
clients
will
have
to
handle
this.
B
As
far
as
I
know,
there
is
the
pop
key
to
index
to
other
index,
cache
that
consensus
that
client
utilizes
for
to
get
faster,
lookups
of
indexes
by
The,
POP
key
and
in
case
this
reversal
takes
into
effect.
It
consists
that
a
client
will
have
to
handle
this
complexity
and
will
have
to
track
if
there
were
some
changes
in
the
up
key
index
matching
depending
on
the
fork.
So
the
some
part
of
this
cache
becomes
really
tight
of
work.
The
fortunate
part
is
that
demand
cash,
that
that
has
been
the
main
portion
of
this
cache.
B
B
F
B
Yeah,
this
brings
us
to
this
slide
and
the
limits
on
on
a
number
of
deposits
after
this
proposal
takes
into
effect
as
it
is
currently
designed,
is
basically
a
the
only
factor
that
limits
number
of
deposits
is
the
size
of
a
block.
I,
don't
know
if
Peter
Davis
want
to
speak
more
about
this,
because
he
did
this
analysis
on
the
number.
E
I'm
very
positive,
to
say
a
few
words
yeah.
The
limit
is
entirely
based
on
the
gas
limit.
There
are
like
where
you
get
down
to
it,
like
really
quite
fundamental
limits.
There's
like
even
no
matter
what
happens.
It's
really
unlikely
that
the
cost
of
making
a
deposit
is
going
to
fall
below
about
15K
gas,
because
the
work
that
actually
occurs
in
the
deposit
contract.
E
You
have
to
be
a
bit
careful
here,
because
the
naive
thing
is
to
look
at
the
cost
of
making
an
individual
con
deposit
in
a
single
transaction,
and
that's
quite
expensive,
there's
a
lot
of
overhead.
But
if
you
make
a
single
transaction
that
sends
a
very
large
number
of
deposits,
you
get
quite
a
lot
of
economies
of
scale.
E
There's
a
lot
of
things
that
you
only
have
to
pay
for
once
things
like
Cold
Storage
reads:
things
like
the
21k
gas
that
you
have
to
pay
to
send
a
transaction
in
the
first
place,
but
once
you
do
the
analysis,
you
come
to
the
conclusion.
There's
this
like
hard
cap,
and
so
we
can
be
confident
and
by
the
way
we
should
like
expect.
E
People
like
people
currently
do
send
transaction
deposits
in
like
big
batches
at
reasonably
large
batches
of
like
several
hundred
anyway,
just
because
they
want
to
save
this
gas
so
yeah,
you
just
have
to
make
sure
that
the
consensus
there
can
cope
with
I
mean
theoretically,
there's
a
possible
it's
possible
in
the
future.
We
could
get
up
to
2
000
deposits
or
slightly
less
than
that,
but
that's
the
sort
of
level
and
I
think
the
conclusion
is
we're
just
going
to
have
to
optimize
the
consensus
of
their
clients
to
be
able
to
support
that.
So.
E
You
know,
there's
no
cue
at
all:
there's
no
queue
on
the
El
layer
and,
like
the
consensus,
require
clients,
don't
have
a
Q,
either
they're
required
to
just
like
throw
set
they're
required
to
validate
all
the
deposits
in
the
block
they
appear,
which
is
different
from
the
current
situation.
Hence
this
analysis.
Okay,.
F
B
So
you
yeah
see
now
it's
currently
rlp
encoded,
as
per
the
EIP
and
yeah,
we'll
see
what
what
other
SSD
fine
efforts
will
will
be
finished
with
I
mean
if
we
turn
with
roles,
for
instance,
if
we
turn
them
into
the
SSD
hash
tree
root
right.
So
we
can
switch
deposits,
deposit
Roots
as
well,
because
this
new
schema
and
yeah,
but
basically
engine
API,
exposed
this
demonstration.
F
A
G
B
Basically,
because
there
is
a
complexity
of
maintaining
the
queue
and
there
is
a
way
of
getting
rid
of
this
queue
with
a
couple
of
implications.
One
is
the
complexity
of
maintaining
The
POP
key
index
cache
that
we
have
discussed
the
other
one
is
the.
Since
there
is
no
queue,
we
can
can't
rate
limit
deposits
process
per
Epoch,
and
this
parameter
is
kind
of
important
for
the
big
subjectivity
period
computation.
B
So
that's
why.
So.
There
is
a
trade-off,
the
a
bit
of
complexity
on
the
cash
inside
and
maintaining
the
queue
versus
maintaining
the
queue
and
the
beacon
state
so
yeah
and
the
current
proposal
decides
in
favor
of
this
cache
complexity.
Probably
if
we
see
other
proposals
emerging
that
require
the
deposit
queue
with
some
other
purposes
is
we
can
combine
the
two
and
switch
back
to
the
key
approach.
Thank.
G
A
Thank
you
so
my
next
question
is
also
with
respect
to
the
change.
When
deployed
with
the
upgrade
in
the
presentation,
there
was
a
mention
of
a
gap.
Perhaps
the
maximum
expected
time
is
15
hours
at
the
time
when
this
proposal
will
be
deployed
on
the
main.
My
question
here
is
about
the
effect
on
users
transaction.
We
understand
that
validators
deposit
would
be
affected,
but
would
there
be
any
effect
to
use
a
transaction
or
is
it
just
a
system
level
operation
not
affecting
anyone
all.
B
The
fact
users
there
will
be
a
slight
increase.
I
guess
it'll
be
a
slight
increase
combination,
complexity
on
the
client
side,
because
we
have,
we
will
have
two
deposit
flows
working
being
processed
together,
but
considering
that
there
is,
on
average,
less
than
two
deposits
per
block
or
like
kind
of
like
one
deposit
per
block.
This
complexity
should
not
be
that
high,
so
this
transition
periods
will
not
affect
users,
I
I,
don't
think
it
will
affect
the
system
either.
Awesome.
A
My
next
question
is
with
respect
to
the
proposal
which
is
currently
managing
helping
out
with
the
exchange
of
information
on
the
interface
level,
so
the
proposal
6110
it
mentions
that
it
will
eliminate
the
requirement
to
maintain
and
distribute
deposit
contracts
snapshots
which,
if
I
understand
correctly,
is
currently
being
taken
care
with.
The
eip4881
4881
is
currently
in
the
review
status,
I'm
curious
to
understand
the
current
status
of
implementation
of
4881
Plus,
or
do
we
need
it?
Even
if
6110
is
deployed,
we.
B
Would
not
need
if
6110
is
default,
we
would
notice
the
snapshots
anymore,
the
bootstrap,
a
node
I,
don't
know.
What's
the
exact
status
of
this
AIP,
maybe
other
people
on
the
call
can
help
with
that.
But
I
know
that
I've
heard
that-
and
probably
this
is
the
implementations
of
the
cap.
Some
clients
already
maintained
these
snapshots
of
deposits.
Contract
stupid,
strap
node
in
a
super
strap
a
node
faster
than
it
would
be
to
obtain
all
logs
from
from
the
execution
layer
client.
B
A
Yeah,
that
is
an
interface
proposal,
so
I
was
curious
to
understand
like
how
we
are
working
right
now
and
if
we
have
implemented
it
in
all
clients.
Nevertheless,
that
is
a
question
for
the
authors
of
that
particular
proposal.
I
hope
that
we
have
this
conversation
sometime
with
co-authors
and
get
this
answers.
A
B
Yeah
sure
so
it's
not
coming
in
the
into
Cancun,
because
it's
quite
it's
moderately
big
but
still
big
feature
and
then
cool
is
quite
packed,
was
quite
packed
already
by
the
time
that
we
have
discussed
this
proposal
and
this
proposal
is
roughly
planned
for
the
hard
Fork
next
Vancouver
and
if
we
will
keep
the
same
Cadence
of
delivering
works
and
mainnet,
we
can
assume
it's
not
yet
decided
at
all.
We
can
assume
that
bamcoon,
for
instance,
happens.
This
fall
and
yeah
like
three
or
four
were
this
year.
B
A
A
Very
well,
we
are
close
to
an
R
Mark
I'll,
be
curious
to
hear
your
thoughts
on
EIP
process,
especially
on
the
consensus
layer,
eib,
and
my
question
is
also
directed
towards
the
discussion.
Placeholder
I
find
the
discussion.
Two
link
is
pretty
much
empty,
but
I'm
assuming
there
are
a
lot
of
discussion
going
on
with
respect
to
this
proposal.
So
where
is
that
actually
taking
place
and
how
people
can
follow
it?
I.
B
Think
a
portion
of
discussion
around
the
cap
happened
during
one
of
the
r
d
meetups,
where
in
person
with
Iman
client
developers
and
ethereum
researchers,
it
was
very
fruitful
discussion
and
yeah.
The
thread
is
empty
indeed,
but
there
is
no
other
threats
with
that
discussed
the
cap.
A
lot
I
mean
so
this
Remains,
the
one
threat.
Where
should
the
discussion
points
to
be
raised
regarding
that
EAP
and
yeah?
With
respect
to
the
AP
process?
Recently
I've
added
the
consensus
layer
specification
to
the
EIP
to
the
CIP
original.
B
It
was
just
the
execution
layer
specification
outlined
in
the
AAP
documents
and
I
think
it
makes
a
lot
of
sense
because
it
gives
a
holistic
View
and
we
can
include
the
consideration.
This
CIP
has
a
lot
of
security
considerations
on
the
consensus,
their
side
and
having
this
consists
layer
and
execution
layer
in
one
place
under
the
hood
of
one
document
makes
it
possible
to
include
include
all
the
security
consideration.
B
Just
you
know
in
one
place,
which
is
great,
that's
that's
kind
of
a
new
I
think
the
AP
process
and
yeah
I
really
like
it
and
join
it.
Maybe
yeah,
Kevin
and
navy
has
some
thoughts
and
has
something
to
have
something
something
to
share
on
how
to
work
with
this
facts
and
how
to
implement
them
and
as
well
as
pick
up
well.
D
Personally,
I
found
the
specification
to
be
you
know,
pretty
straightforward
on
the
execution
layer
side
and
you
know
on
EIP.
There
are
some
pseudo
code
on
in
terms
of
like
how
you
extract
the
and
also
like
the
the
way
you
validate
stuff.
So
I
think.
That's
that's
pretty
easy
to
understand.
You
know
it's
pretty
straightforward.
So
right.
A
That's
good
to
know
they
generally
try
to
keep
a
placeholder
for
discussion
because
I'm
assuming
because
this
proposal
is
affecting
both
layers
and
also
kind
of
Hit.
The
mindset
of
people
who
are
new
trying
to
join
as
a
validator
may
come
up
with
some
questions.
So
it's
a
good
idea
to
keep
this
placeholder
open.
We
should
expect
some
upcoming
questions
or
discussion
on
Fellowship
of
ethereum
magician
as
LinkedIn
The,
Proposal
I.
Think
I
had
a
few
more
questions.
B
C
D
B
I
also
want
to
add
that
ethereum
client
developers
are
open
to
help
and
facilitate
any
feature
development
with
their
clients,
even
considering
they're,
really
quite
busy
with
their
day-to-day
responsibilities.
Yeah.
There
is
a
huge
willingness
to
assist
on
every
contribution
to
the
client,
so
it's
quite
easy
from
that
part
as
well
to
chime
in
to
the
their
core
development.
Absolutely.
A
Thank
you
so
much
for
this
I
suppose
this
is
exciting
to
follow
eap6110
that
is
proposing
a
significant
the
increase
in
deposit
security
by
simplifying
the
process.
Kevin
Navi
Mikhail
Peter.
We
thank
you
all
for
joining
us
on
p
penny
and
sharing
the
proposed
changes.
I
appreciate
you
checking
out
to
share
valuable
information
with
us
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
and
any
other
topic?