►
From YouTube: Ethereum Magicians Protocol Roadmap Session
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 IPFS and more.
https://archive.devcon.org/archive/watch/6/ethereum-magicians-protocol-roadmap-session/index
Note: Due to some technical difficulties, portions of this video were recorded without audio, and have been edited out of this final version.
You can find the full notes for the session here: https://ethereum-magicians.org/t/ethereum-magicians-protocol-roadmap-session-devcon-vi/10866
Join us for a conversation with protocol developers, researchers and more covering learnings from The Merge, potential future changes to the Ethereum protocol & its governance process, and lightning talks on proposed Core EIPs. Find overview agenda in ETH Magicians post https://ethereum-magicians.org/t/ethereum-magicians-protocol-roadmap-session-devcon-vi/10866
Speaker(s): Tim Beiko, Anett Rolikova
Skill level: Intermediate
Track: Layer 1 Protocol
Keywords: eips,ethmagicians
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
A
It
was
kind
of
successful
in
a
huge
room
where
vitalik
went
on
like
a
huge
session
and
brought
like
so
many
research
posts
of
like
that.
Inspired
the
discussions
that
happen
during
the
session
and
then
just
to
give
you
a
quick
overview
of
the
the
roadmap
of
what
we've
been
discussing
like
just
a
few
points.
A
Mainly
we've
been
discussing
the
IP
1559,
the
fee,
Market
change
for
ethereum,
which
was
a
very
hot
discussion
and
also
the
prak
Pao,
which
we
agreed
that
sort
of
conspiracy
driven
AIP,
and
we
should
not
keep
much
of
a
like.
We
should
not
like
pay
much
of
attention
to
that.
As
that's
very
conspiracy
agreement,
then
we
also
started
discussing
about
State
rent,
as
we
realized
that
many
people
are
using
blockchain
as
a
storage.
A
So
you
guys
may
be
wondering
why
everybody
is
sitting
down
even
I'm
like
sitting
down,
because
I
don't
want
to
be
like
too
much
like
oh
I'm
like
important,
and
you
guys
are
not.
But
basically,
three
magician
sessions
are
always
like
everybody's
sort
of
like
on
the
same
same,
like
line
or
something
that
like
there
is
no
such
thing
as
like.
Oh,
these
are
the
cardiffs
or
like.
A
So
if
you
have
like
something
to
say
to
this
session
or
like
to
the
topic
that
is
being
discussed,
feel
free
to
anytime
switch
like
anybody
just
like
take
their
seat
and
be
like
hey,
like
I,
want
to
like,
say
something
to
this
and
even
grab
a
mic
and
I
also
encourage
you
to
take
some
notes
or
some
like
ideas
that
you
have.
We
also
have
a
marker
would
just
like.
Thank
you.
So
much
who's
gonna
take
a
note
from
this
session
and
then
also
I
forgot
your
name.
A
But
there
is
a
guy
who
is
going
to
take
a
note
in
Spanish.
So
we
are
going
to
have
a
translated
notes
from
this
session
as
well
and
make
sure
to
publish
them
on
ethereum,
magician's,
Farm
and
then
I
just
figured
out
that
this
would
be
a
cool
quote
to
my
kick
up
this
session.
To
like
make
ethereum
more
Diversified
as
I
feel
like.
A
We
need
more
clients
to
be
run
in
the
ethereum
ecosystem
and
we
should
not
be
just
focusing
ourselves
or
on
the
main
two
clients
and
by
the
way,
the
QR
code,
weird
until
let
the
QR
code
be
there
and
that's
where
you
can
find
the
slides
and
in
the
slides.
There
are
many
links
that
what
I've
been
just
mentioning
during
my
introduction
speech
and
that's
pretty
much
it
from
my
side
I'm
just
going
to
try
to
encourage
you
all
to
week.
Up
and
like
don't
be
scared,
even
the
mic.
A
B
Yeah
thanks
a
lot
for
the
intro
yeah,
so
I
guess
on
the
point
of
people
asking
questions
and
contributing
I
do
not
have
near
three
hours
of
like
contents
here
right
like
so
like
you
know,
I
have
a
couple
questions
to
kick
things
off
but
like
this
is
very
much
on
you.
If
you
will
have
stuff
you
want
to
discuss.
B
This
is
the
place
for
it
or
we'll
be
out
of
here
in
50
minutes,
but
I
guess
yeah,
there's
like
three
things
on
the
slides,
I,
think
or
needs
to
discuss
with
the
people
here.
First
is
just
like
how
the
merge
went.
It
was
a
pretty
big
piece
of
work,
not
only
technically
but
just
like
making
it
happen
from
like
a
human
perspective.
B
We
have
all
these
teams
working
together,
so
yeah
I'm
personally
curious
to
hear
just
from
the
different
client
teams
and
folks
involved
like
how
that
whole
process
went.
Is
there
things
we
can
do
better
for
like
the
next
one
or
things
we
did
well
that
we
didn't
expect
to
do
so?
Well,
after
that,
like
we
keep
talking
about
like
The
Surge,
Verge,
Purge
Splurge,
all
that
stuff
I
think
I
just
want
to
make
sure
we
have
space.
You
know
to
hear
from
different
kind
teams
about
like
how
they
see
priorities
there.
B
So
we'll
use
this
as
a
sort
of
pressure
valve
for
some
of
those
discussions
yeah
but
again,
yeah.
Please
ask
questions
throughout,
otherwise
this
is
going
to
be
over
pretty
quick
but
yeah
to
kick
it
off.
I
I
just
was
curious
to
hear
from
like
different
folks
on
kite
teams
like
their
perspective,
I'm
like
not
like
technically
how
the
merge
went
like
I.
B
C
I
made
the
mistake
of
sitting
beside
Tim,
it
was
stressful.
It
was
really
really
stressful
and
really
drawn
out
for
a
long
time
and
I
think
as
quarters.
We've
all
felt
that
real
pressure,
so
that's
that's
kind
of
the
personal
view
of
it.
I,
don't
know
how
you
change
that
I'm,
not
sure
we
should,
because
we
should
have
been
under
pressure
to
ship
and
we
were,
but
you
know
I
guess
I'd
say
never
be
in
doubt
that
core
devs
feel
the
pressure
to
ship.
C
We
really
do
yeah
I
think
there
were
a
lot
of
really
good
things.
We
did
the
testing
that
we
we
managed
to
do
was
phenomenal
and
it
was
a
kind
of
another
couple
of
steps
up
on
anything
we've
done
before
for
hard
forks
and
that
kind
of
coordination
and
and
work
that
went
into
that
was
absolutely
fantastic,
starting
with
the
client
teams
testing
their
releases.
But
then
the
EF
support
was
spinning
up
the
shadow
test.
C
C
Think
that
probably
is
a
knock-on
effect
and
we
didn't
necessarily
include
the
execution
clients
early
enough,
which
might
have
been
because
they
were
busy
with
you,
know,
1559
or
something
giant
so
I'm
not
sure
what
the
timelines
there
exactly
were,
but
it
it
felt
like
consensus
side
almost
felt,
confident
and
ready
and
execution
was
kind
of
like
oh
yeah
emerge.
The
merge
is
the
next
thing.
We've
got
time
now
we
can
look
and
it
wasn't
wasn't
a
surprise
to
them.
C
Don't
don't
get
me
wrong,
but
I
think
that
was
a
big
deal,
that
that
would
have
helped
to
bring
that
forward
and
then
have
more
time
on
things
like
being
able
to
pay
real
attention
to
the
hive
test.
We
were
struggling
as
client
developers
to
keep
up
with
the
sport
and
the
last
minute
things
we
knew
about
and
dealing
with
these
Hive
test
reports
that
are
in
a
format
that,
particularly
for
the
cancer
consensus
side,
we
weren't
particularly
familiar
with.
D
Thank
you
made
a
mistake
of
sitting
too
close
to
age,
yeah,
I
I
agree.
It
was
really
stressful,
very,
very
stressful
four
years.
I
think
a
large
part
of
it
was
figuring
out
how
to
deal
with
that
and
how
to
keep
performing
and
keep
delivering
good
code,
not
sure
what
to
do
about
that,
perhaps
having
gone
through
it
once
then,
these
group
of
clients
will
be
better
at
doing
it
again.
D
I
think
it
went
really
well.
I
have
been
quite
disappointed
with
Mev,
since,
since
it's
launched,
I
know,
there's
been
with
some
of
the
implementations
there
there's
been
some
bugs
that
we,
that,
with
like
Json
encoding,
that
really
really
shouldn't
have
hit
us
on
mainnet
I.
Think
it's
probably
because
Mev
like
we
all
kind
of
realize
that
that's
a
thing
is
happening
quite
close
to
the
merge,
didn't
quite
get
enough
time
to
run
with
it
didn't
get
enough
time
for
it
to
be
integrated
into
our
setups
I.
D
Think,
there's
also
some
catching
up
that
those
teams
need
to
do
in
terms
of
announcements
and
cons.
So
if
they
have
failures
with
their
software,
they
need
to
announce
it.
They
need
to
tell
people
instantly
that
there
is
a
problem
and
it's
being
looked
into
not
sit
on
it
for
some
time
and
then
and
then
and
then
publish
it.
Do.
E
I
was
really
happy
to
actually
we
we
almost
launched
in
October
so
just
the
next
year.
So
but
then
I
came
back
to
the
like
after
I
said
that
I
was
like
yeah.
Maybe
maybe
it
was
not
really
the
common
agreement,
the
common
sense
and
I
came
back
today
to
the
Netherlands
team.
Asking
everyone
hey.
Do
you
think
I
can
do
that
for
October,
like
you
think
it's
possible
at
least
do
I
have
to
go,
and
just
like
tell
everyone,
hey
I
was
wrong
and
they
said
no.
E
We
think
it's
possible,
so
I
thought
okay,
yeah
and
well.
There
was
there
was
a
lot
of
work,
but
at
the
same
time
I
remember
thinking
on
the
same
day,
I
think
it
was
good
to
say
it,
because
suddenly
all
the
infrastructure
teams
started
calling
everyone
and
saying
hey
like
we're
launching
in
October.
We
are
totally
unprepared,
we
have
to
start
preparing
and
it
was
needed
like
because
we
needed
node
operators
to
start.
E
Does
it
say
to
use
this
difficulty
bomb
thing
as
a
as
something
that
would
drive
the
dates
talking
to
developers
to
our
team?
I
feel
like
there's,
really
no
more
motivation,
you
can
get
or
no
more,
pushing
or
or
shouting
or
asking
that
you
could
get
for
delivery
on
time.
So
there's
absolutely
no
sense
to
introduce
any
other
stressor.
So
so
the
difficulty
bombing
moved
slightly.
I
hoped
it
won't
move
the
merge
date
and
we
didn't
so
actually
the
merge.
E
F
Like
two
three
weeks
before
the
merge
timeline,
we
saw
a
huge
amount
of
people
thanks
to
a
lot
of
solo
stickers
coming
through
Discord,
asking
tons
of
questions
and
I
think
the
maintainers
were
super
busy
with
you
know,
trying
to
get
the
final
release
out,
didn't
get
to
really
respond
to
a
lot
of
them.
So
I
think
that's
something
that
if
we
had
to
go
through
the
merge,
not
really,
but
if
we
had
to
go
through
it
again
that
we
would
do
that
differently
to
be
ready
for
Community
Support.
F
How
do
we
get
this
new
users
coming
through
this
ecosystem,
like?
How
can
we
support
that
better
and
but
honestly,
it's
definitely
a
hard
challenge,
because,
as
maintainers
like
you're,
really
deep
in
the
weeds
of
like
really
trying
to
get
the
code
out
on
top
of
that,
trying
to
support
tons
of
users
coming
through
is
it's
it's
really
challenging.
F
But
thanks
to
a
lot
of
the
contributors
who
also
chimed
in
and
asked
answering
a
lot
of
other
people's
questions
on
how
to
set
up
their
validators
and
all
that
so
yeah,
it's
definitely
a
community
effort.
It's
not
just
the
maintainers,
all
core
devs.
So
thank
you
for
those
solo
stickers
coming
in
and
asking
questions
and
really
improving
the
client
diversity
and
also
other
contributors
supporting
each
other.
So
yeah.
Thank
you
for
that.
F
G
Hello,
okay,
so
I
wanna,
double
down
on
Paul,
so
I'm
from
prison,
and
so
from
my
team's
perspective,
merge
has
always
just
been
consensus,
execution
and
engine
API
and
boom
done
right
and
then,
like
I
guess
like
just
a
month
before
the
merch,
we
learned:
okay,
there's
this
Mev
stuff.
We
have
to
work
out
now
and
then
there's
this
Mev
booths
and
there's
this
relayer
this
Builder.
So
we
just
keep
adding
more
and
more
actors
to
the
picture
and
then
even
a
few
weeks
before
the
merge
right
there,
there
was
this
tornado
or
cash.
G
They
say
all
fetch
stuff
and
then
flashbots
would
only
relayer.
So
our
team
had
this
big
internal
discussion.
It's
okay.
Should
we
drop
the
support
right
now
like
like?
What
should
we
do
if
flashbart
was
the
only
relayer
and
they
are
sensory
transaction
right,
even
though,
and
maybe
boost
is
a
neutral
piece
of
software
above
flash
about
is
the
only
relayer
then
as
a
client
team,
we
are
indirectly
supporting
censorship
and,
of
course,
I'm
not
happy
with
that
this.
This
is
now
why
we're
here
for
right,
so
I
think,
like
we've
learned
a
lot.
G
I
learned
a
lot
it's
just
like
if
today
relays
are
producing
50
of
the
blocks
on
the
main
net,
are
they
considered
as
layer?
One
right
and
I'm
I'm
I'm
really
happy
to
see
this
more
and
more
like
relayers
flash
balls
they're
joining
the
Oracle
Depot
they're
starting
to
participate
more
on
just
layer,
one
roadmap
like
architecture
and
stuff
like
that,
so
I
do
think
like
we
do
have
to
work
with
them
and
they
have
to
work
with
us
together
to
basically
push
the
space
forward.
D
Okay,
yeah
good
points
by
by
Terrence
I
think
it's
worth
saying
as
well.
That
I
think,
even
though
we
did
have
some
problems
with
Mev
and
I
was
pretty
harsh
on
them
before
I
think
we
did
come
out
of
it
in
a
better
spot
than
we
were
before.
There's
no
like
Mev
guests
now
and
Flash
Sports.
We're
really
happy
to
to
relinquish
that
that
control,
which
was
really
cool.
D
So
I
think
we
really
opened
up
the
world
to
Mev
and
although
we
didn't
solve
it
and
we're
still
not
in
a
great
spot,
I
think
we
ended
up
in
a
better
spot
and
I.
Think
flashbots
have
done
some
good
stuff
towards
that
as
well.
Yeah.
The
circuit
breaker's
good
as
well
yeah.
So
now
there's
the
consensus.
Clients
can
detect
when
the
chain
is
unhealthy
and
then
just
disable
Mev.
D
So
that's
something
that
we
couldn't
really
do
before
in
Mev
Geth
with
the
like
Mev
boot,
flash
plus
could
have
implemented
it,
but
you
know
it's
a
lot
of
work
for
them.
So
yeah
now
there's
a
lot
more
control
from
the
consensus
clients
at
least
into
what's
going
on
with
Mev
and
I.
Think
that's
that's
a
really
good
place
to
be
in.
H
H
Yeah
and
I
guess
like
from
my
perspective,
the
the
whole
situation
with
Mev
was
very
interesting
because
Mev
has
been
around
for
several
years
now,
and
you
know
we've
kind
of
seen
through
the
defy
Summer
and
the
nft
summer.
These
crazy
numbers
about
how
much
Mev
there
is
in
blocks-
and
you
know
for
my
perspective-
was
I
was
thinking
you
know,
there's
so
much
money
in
this
industry,
like
the
solutions
are
just
going
to
appear
and
they're
going
to
be
really
robust
and
they're
going
to
work.
H
I
would
have
been
very
curious
to
see
like
what,
in
you
know,
institutions
would
have
created
their
own
Mev
boost.
Had
this
like
open
source
public
thing
not
existed,
because
I
think
that
there
is
enough
money
in
this
industry
that
some
of
these
big
stickers
would
have
realized.
You
know
there's
no
way
for
us
to
extract
the
movie
anymore.
Let's
create
some
centralized
endpoint
for
people
to
send
bundles
to
and
we'll
just
extract
it
for
our
customers,
and
you
know
Screw
all
the
rest
of
the
stakers.
H
They
can
figure
out
their
own
ways,
so
it's
not
where
we
want
it
to
be
today.
We
want
to
improve
boost
and
make
it
better,
and
we
eventually
want
to
move
to
PBS
where
it's
part
of
the
protocol
and
so
we're
just
working
towards
that,
but
and
I.
Think,
like
also,
you
know,
with
respect
to
thinking
that
the
Mev
industry
was
going
to
build
all
this
stuff.
H
The
core
development
Community
is
also
like
a
very
anti-finalization
of
a
lot
of
things
and
so
to
a
degree
it
felt
like
we
didn't
want
to
think
about
it.
It
felt
wrong
for
us
to
think
about
Mev
in
a
lot
of
cases,
and
it
was
only
later
on
where
we
realized
how
much
interplay
there
was
between
censorship
and
Mev
and
the
ability
to
produce
blocks,
and
it
started
to
just
unfold
very
naturally,
over
the
last
six
to
eight
months
and
I.
B
Yeah
and
I
guess
yes,
talking
about,
like
the
design
of
the
whole
thing,
I'm
curious
to
hear
like
Proto
Macau,
you
both
spend
a
bunch
of
time
like
early
on
with,
like
the
engine
API
and
and
specking
out
of
that,
but
yeah
Miguel.
Do
you
want
to
just
like
walk
us
through,
like
how
do
we
come
up
with
the
merge
like
how
do
we?
How
do
we
get
here.
I
I
I
Client
was
not
called
that
by
that
time,
but
anyway
it
like
made
me
much
easier
to
like
prototype
the
whole
thing,
like
the
consensus
interact
with
the
execution
layer.
It
was
not
done
by
engine
API
by
that
time,
but
anyway
it
was
like
yeah,
the
old
idea
of
like
putting
it
in
a
chart
and
make
it
work
somehow.
So
we
did
this
prototype
then
yeah
after
some
progress
on
the
merge
specs
and
the
ideas
then
protopied
with
like
rheanism
project,
so
just
you
know
forced
us
to
make
the
first
version
of
engine
API
for
the.
I
J
Like
I
mean
I
can
talk
about
that,
I
would
want
to
First
reiterate
over
the
first
moment
in
time
most
that
we
developed
the
merge
I
think
it
was
before
coffee
before
the
whole
pandemic.
I.
Think
in
like
SBC,
there
were
still
discussions
about
ewasum,
but
then
less
than
a
month
later,
in
Paris
during
Evon
X
discussions,
afterwards,
eosm
or
like
the
ID
of
execution
starts,
was
basically
over
and
don't
forget,
and
these
discussions
between
you
and
Guillaume
Danny
me.
Others
Brandon
also
started
where
hey.
J
Maybe
we
can
prototype
the
Catalyst
thing
with
the
evm
applied
to
techu
and
yeah,
like
that's
kind
of
cool,
but
I
took
that's
two
thousand
twenty.
It
took
a
year
more
than
a
year
till
we
got
to
to
rayonism.
So
it's
a
huge
leap
already
where
things
happened
and
then
in
realism
where,
in
this
awkward
spots,
where
alter
was
still
not
shipped
and
London
was
still
not
chapped,
and
we
were
just
like
moment
in
time
where
there's
this
stack
development,
where
you
have
to
convince
people
that
they
need
to
dedicate
resources
on
something.
J
That's
not
the
main
hard
work
to
make
some
kind
of
progress,
definitely
like
there.
There
were
moments
in
time
where
I
was
slightly
like
yeah
out
of
my
humor,
because
of
the
the
way
the
the
these
calls
would
go
like
for
a
month.
We
were
thinking
of
it
like
a
hackathon
where,
okay,
we
just
do
the
Prototype
with
more
than
one
client
and
Martin.
J
Often
it's
just
meant
that
some
clients
would
not
go
and
join
these
cars
to
even
just
get
a
glimpse
of
what
we
were
trying
to
do
after
alter
and
after
London
and
I.
Think
like
this
disco-free
process
for
future
Forks,
we
can
improve
where
that's
the
time,
and
if
we
had
more
people
think
about
the
merge.
We
could
have
realized
that
hey.
We
need
to
make
these
communication
Channels
with
things
like
flashbots
and
MFE
verages.
Very
soon,
all
the
rest,
it's
very
late,
then
you've
got
the
new
situations.
C
K
I
Can
I
continue
on
that
yeah?
It's
just
a
few
few
sentences
left
from
my
end,
okay.
So
after
any,
this
is
the
first
time
we
had
like
engaged
more
client
developers
and
client
development
teams
into
that.
We
had
to
written
to
write
us
back
of
the
engine
API
like
to
make
this.
You
know
some
kind
of
standardized
or
whatever
it
was
even
before
Emperor.
It
was
like,
like
more
than
one
year
ago,
like
yeah,
yeah,
April
and
May.
What
do
you
mean
one
yeah?
I
I
I
think
it's
really
helps
to
collaborate
on
the
things
even
after
the
event,
and
when
we
were
like
on
the
internet
back
to
work,
yeah
and
as
has
been
mentioned,
tests
and
efforts,
client
developers
gave
a
lot
of
feedback,
and
all
this
stuff
I
was
just
and
the
key
takeaway
for
from
from
what
has
been
said,
yeah
the
right
people
at
the
right
moment.
In
time
make
the
things
happen
so
retrospectively.
This
is
what
has
happened
with
the
merge
and
I
think
that
this
may
only
happen.
I
This
kind
of
like
thing
right
people
at
the
right
moment
in
time,
appear
like
in
a
healthy
Community,
which
we
have
currently
the
healthy
community
of
researchers
and
developers
and
yeah,
and
this,
like
prove
the
merge
is
like,
as
for
me,
is
proof
of
like
these,
that
the
this
community
of
research
and
developers
that
we
have
in
ethereum
ecosystem
can
like
capable
of
delivering
like
huge,
big,
sophisticated
projects
and
like
the
merge,
is
like
the
first
one
right.
So
next
is
dank
charging
and
other
things
local
trees.
I
K
Open
this
up,
hey!
Thank
you!
Sorry,
for
being
late,
as
we
are
most
of
the
time
we're
we
are
the
fifth,
the
fifth
consensus,
client,
so
yeah.
We
we
actually
produced
our
first
block
on
mainnet
in
November
of
last
year,
but
it
was
actually
fun
to
basically
Sprint
up
to
to
with
everyone
else
and
basically
caught
up
so
that
sort
of
retrospective
was
was
amazing,
to
see
the
kind
of
feat
that
we
can
get
there
and,
of
course,
with
the
help
of
all
the
other
client
teams
as
well.
K
We
were
able
to
pull
through
so
basically
goes
to
show
that
what
we're
capable
of
when
we
all
work
together,
especially
when
we're
all
focused
on
that
one
thing
and
it
was
to
achieve
a
successful
merge.
So
it
was
really
great
to
for
all
you
guys
to
help
us
basically
pull
us
up
to
where
you
guys
are
I.
K
Guess
one
of
the
hardest
things
that
we
had
to
deal
with
with
being
a
more
later
client
to
be
ready
for
mainnet
is
really
just
the
fact
that
client
stickiness
is
really
really
huge
issue
and
we
definitely
noticed
it
as
we're
going
towards
merch
people
tended
to
not
necessarily
want
to
experiment
with
a
new
client
going
up
to
something
as
critical
as
the
merge.
So
we
found
that
to
be
quite
difficult,
even
though
we
you
know
tried
our
best
to
sort
of
make
it
easier
for
people.
K
You
know
like
one
of
the
best
examples
would
have
been
our
lodestar,
quick
scripts,
that
we
use,
which
is
basically
like
a
one-line
command
for
people
to
start
up
load
star
with
any
of
the
El
clients,
but
you
know
didn't
see
as
much
traction
with
as
we'd
like
to,
but
now
that
we're
pretty
much
caught
up
going
into
withdrawals,
Shanghai
dangsharding,
hoping
to
see
much
more
adoption
with
that
and
yeah.
We
definitely
can't
do
it
without
the
help
of
all
of
our
Collective
Minds
together.
A
C
So
we
we've
just
shared
kind
of
mostly
core
devs
and
researchers.
You
know
our
retrospectors
on
the
merge,
so
my
question
to
everyone
out
in
the
community
is:
what's
it
been
like
like?
What's
your
retrospective
on
how
the
merge
has
gone
how's
it
been
as
a
validator
how's
it
been
as
a
dab
developer
and
those
kinds
of
things
someone's
got
to
start
just
give
someone
a
mic.
Yeah.
L
Hi
I'm
not
there.
It
was
crazy
because
in
Mexico
I'm
trying
to
teach
people
what
this
video
needs
to
make
in
while
people
like
you
are
building
are
creating
I
need
scar
record.
All
the
terminology
is
very
hard
to
understand
and
that
they
don't
teach
people
what
you
are
doing
and
guys
like
me
that
are
nerds
ready
and
all
the
stuff.
L
So
I
think
it's
day
to
day
it's
improving
life,
for
example,
when
I
start
to
make
the
threats
about
all
quartets
in
Spanish.
Skylar
came
to
me
and
said
a
guy,
a
nice.
What
you
are
what
you
are
doing,
they
and
team
Baker
start
to
to
share
my
post.
So
thank
you
to
everyone
for
all
this
I
don't
know,
I
feel
like
very
nervous,
because
I
think
that
I
am
with
a
very,
very
smart
guys,
people
and
it's
like
crazy.
L
D
C
M
This
might
be
like
a
random
question,
but
can
we
have
more
documentation
resources
for
future
core
developers,
because
I've
looked
around
and
it's
very
hard
to
find
and
I
myself
would
like
to
volunteer
to
take
that
task
and
would
love
to
create
a
documentation
of
tutorials
and
road
maps,
because
I
really
want
to
work
on
that.
But
it's
very
hard
to
find
like
a
clear
path
to
become
a
core
developer.
N
Thank
you.
Have
you
heard
about
a
protocol
Fellowship?
It's
exactly
answer
to
your
question.
Oh,
you
were
I'm,
sorry
about
that,
but
you
can
still
participate.
So
this
is
the
thing
so
like.
So,
if
you
didn't
protocol
Fellowship
is
a
kind
of
an
internship
program
where
anybody
can
come
and
work
start
working
on
a
project
and
in
a
way
that
we,
it
provides
certain
mentorship
from
many
of
folks
who
are
sitting
here
and
other
core
devs
and
there
are
also
resources.
N
So
if,
with
the
the
whole
later,
Fellowship
is
coordinated
via
repository
on
GitHub,
where
there
is
also
suggested
reading,
there
are
a
few
things
they
put
together,
but
I
agree.
It's
not
easy!
That's
it's
a
high
wall
that
you
have
to
go
through,
but
so
we
are
I
believe
that
this
might
make
it
easier.
N
You
can
join
if
you
are
not
accepted,
you
just
don't
get
a
stipend,
but
you
can
still
come
and
and
if
you
work
on
a
project
and
over
a
few
weeks
we
see
that
you
have
valuable
out
output,
we
can
still
give
you
this
type
and
as
well,
but
it's
fully
a
permissionless.
You
can
come
to
the
calls
propose
idea
that
you
want
there.
There
are
calls
where
you
can
propose
idea
in
an
issue
similar
to
ACD.
N
A
A
P
Just
quickly
I
was
going
to
say
it's
a
lot
of
the
open
source.
Repos
also
have
tickets
that
are
marked
good
to
start
development
on
so
that's
another
Avenue.
It
does
get
taken
up
by
contributors
and
we
review
and
give
feedback
and
help,
and
so
there
are
a
few
averages,
but
it
is
a
big
it's
a
learning
curve.
Q
So
we
were
working
this
weekend
on
the
eth
Bogota
on
some
hypothesis
regarding
the
new
proof
of
approval
stake
system,
and
one
question
we
written
couldn't
get
answered
was
now
with
the
new
approval
stake
system
is
how
the
Box
the
blocks
get
built.
Is
it
still
purely
an
economical
incentive
as
where
they
choose
the
highest
fees
for
the
or
the
highest
prices
to
include
in
the
blocks
or
are
there?
Other
incentives
include
included
as
there's
an
increased
risk
of
slashing.
E
So
they,
the
blog
building,
doesn't
really
lead
to
the
slash
increase.
Slash
increases
are
only
related
to
the
double
signing
like
signing
two
different
blocks
or
attaching
to
two
different
blocks
of
proposing
to
conflicting
blocks
or
attesting
to
conflicting
blocks,
so
they
yeah
it's.
It
should
be
economical
incentive.
It
should
be
a
line
incentive,
something
that
is
very
natural,
so
the
blood
Builder
is
looking
for
the
payout
and
collects
the
transactions
that
are
paying
the
most
plus.
There
might
be
any
not
clearly
economical,
not
Financial,
but
still
quantifiable
benefits.
J
Right
so
Thomas
is
right
about
slashing.
There
are
inactivity
penalties
which
are
often
confused
with
slashings,
which
you
can
incur.
If
you
miss
your
proposal
and,
for
example,
if
that
latency
is
very
high
because
they're
using
an
external
block
Builder
surface,
so
that's
one
incentive
for
people
to
use
lower
latency
Services.
It
should
just
be
your
or
not,
but
I
do
think.
J
That's
part
of
the
whole
MEP
discussion
and
how
we
make
homesteakers
as
competitive
with
regular
stakers
when
it
comes
to
publishing
blocks
so
that
they
get
adjusted,
timely
and
they're,
not
missed
and
larger
blocks.
Obviously,
and
they
they
are,
they
cost
more
expensive.
They
cost
more
time
to
propagate.
So
that
might
play
a
role.
Q
H
H
B
The
tiny
note
on
that
about
like
following
your
devs
as
the
guy
who
runs
it
the
first
like
six
months
or
so
it
was
my
job
to
attend
all
core
devs
I.
Just
like
didn't
understand
anything
that
was
happening
and
like
it
was
literally
like
too
intimidated
to
like
speak
up
so
like,
if
that's
your
feeling
that's
normal
and
if
you're
smarter
than
me,
it'll,
probably
not
last
six
months
but
like
it
there's
a
lot
of
just
like,
implied
context
that
I
don't
know
it's
really
hard
and
I
felt
really
good
about
myself.
B
When
Danny
Ryan
told
me
the
same
thing
when
he
started
I
think
before
he
started
the
EF,
he
would
attend
the
Casper
CBC
calls
and
he
would
just
share
links
in
the
zoom
chat.
He
was
telling
me
like
you
know
when
somebody
was
like.
Oh,
like
this
paper
came
out.
He
would
just
like
Google
it
to
be
the
first
guy
to
share
the
link
in
Zoom
chat,
so
like
yeah,
the
calls
are
like
hard
to
it's
not
like
a
good
way
to
dive
into
it.
G
I
have
I
when
people
ask
me
any
questions,
I
always
throw
in
these
at
random
ideas.
I
think
this
is
a
good
idea,
just
be
extremely
obsessed
with,
like
eat,
Research
Forum,
and
to
a
point
where
that
you
read
The
Forum
one
two
three
times
and
then
take
notes
to
like,
like
basically
where
the
notes
that
you
can
understand,
then
you
can
transfer
notes
into
blog
posts,
and
then
you
can
share
the
blog
post
to
people
and
then
but
but
when
you're
able
to
do
that,
you
you,
like
you,
can
actually
be
fairly.
A
And
just
make
sure
to
share
everything
on
Twitter.
That's
where
that's
where
the
hype
is
and
that's
like
how
you
can
get
involved
and
go
to
events
and
just
like
speak
up
or
even
take
notes
and
then,
like
even
DM
to
people.
That's
like
how
you
can
basically
get
started
also
great
way
how
to
get
even
closer
to
the
people
in
the
ethereum.
It's
just
volunteer
on
a
conference.
R
R
So
like
in
the
beginning,
there
was
like.
Probably
there
was
like
there's
this
article
on
coindesk
talking
about
like
how
there's
like
eight
or
nine
different
client
teams
like
trying
to
build
for
the
merge,
but
a
lot
of
them
dropped
off
once
like
I
think
there
was
a
point
in
which,
like
the
the
repo
for
how
ethereum's
consensus
was
going
to
happen,
got
like
to
totally
overturned
and
that
made
a
lot
of
playing
teams
mad.
R
R
It
was
very
clear
that,
like
there,
there
wasn't
like
really
much
more
discussion
to
be
had
from,
like
just
anybody
so
like
when
the
Discord
channel
was
like
privatized
like
basically
like
no
one
talked,
because
we
really
have
to
focus
on
the
merge
right
now
and
when
they
started
to
become
like
differences
of
like
client
teams
Readiness
for
the
merge
so
like
some
Clan
teams
were
more
ready
than
others
had
more
features
ready
than
others.
I
think
they're.
The
differences
between
like
preparation
and
resources
for
each
client
teams
got
a
lot
clearer.
B
Wow,
there's
a
lot
to
unpack
in
there
I
think
High
short,
really
short
answer
is
like
slowly
iterating
from
what
we
have
like
I
think
just
like
the
merge
itself
was
kind
of
a
feat
of
governance
to
some
extent
to
get
like
mine
kind
teams
to
work
together
and
agree
on
like
like
agreeing
on
the
big
stuff
was
easy
for
the
merch
I.
Think
everybody
wanted
to
do
it
like
all
the
tiny
things
I
don't
know.
B
I
have
latest
valid
hash
like
burnt
into
my
head
from
typing
in
the
El
Cortez
agenda
like
it's.
Just
like
this
thousand
tiny
things
where
it's
like
the
coordinations
was
really
hard.
I
think
the
other
thing
is
like
and
and
we're
about
to
get
into
seconds.
It's
like
balancing
like
large
protocol
changes,
so
something
like
the
merge
something
like
sharding,
something
like
stateless
with,
like
smaller
things
that
like
bring
it
out
of
value
as
well.
I
I
think
this
is
where
most
of
the
tension
probably
arises
like
different
prioritizations.
B
S
I
mean
my
view
on
all
core
devs
I
mean
like
I,
mean
I.
Think
the
big
thing
that
I
I
feel
is
missing
and
that
I
want
to
see
is
representation
of
like
ethereum's
users
and
the
whole
Community,
rather
than
it
mostly
being
focused
around
one
side
of
the
of
the
of
ethereum,
which
is
the
development
and
I.
Think.
That's
that's
a
big
thing
and
we
would
see
very
interesting
and
different
proposals
if
we
had
more
voices
like
that
on
the
call
also.
T
I
A
T
A
T
A
Especially
is
POS
because
back
in,
like
I,
think
we
had
this
discussion
and
like
with
Mario's
right
at
the
Amsterdam,
where
we
started
talking
about
how
the
EI
process
will
gonna
look
like,
and
that
was
like
April
this
year
and
only
basically
pretty
much
got
as
answer
was
that
it
will
be
consensus
driven.
So
not
not
AIP
process,
as
we
are
used
to
right
now,
which
is
by
the
way
described
in
the
IAP
one,
which
you
guys
can
find
on
eip.etherium.org
yeah.
B
B
We
can't
have
like
90
people
on
a
call
and
so
like
to
your
point
about
like
having
more
more
of
like
the
community
involved.
It's
like
that's
something
where
like
moving
the
calls
are
good
because
they
give
like
a
forcing
function
and
like
some
rhythms
like
I,
wouldn't
take
them
away
completely,
but
moving
to
be
like
more
async
is
something
I've
like
I,
try
to
think
a
lot
about,
and
you
know
so
for
Shanghai.
We
have
like
this
tag
on
on
these
magicians
and,
like
you
know,
anyone
can
tag
their
eat
there.
B
Klein
devs
can
review
it
like
I
can't
force
Klein
devs
to
like
look
at
your
VIP.
If
they
don't
want
to,
like
you
know,
no
one
can
do
that,
but
it's
like
at
least
there's
a
list
and
they
can
scroll
through
it
and
like
if
it
sounds
good
to
them.
It
might
be
like
more
accessible,
and
maybe
you
wrote
it.
You
know
at
9am
Vietnam
time
rather
than
like
4
a.m,
during
yakodev,
awkward,
devs,
so
yeah
I.
B
V
V
B
I'm,
okay,
maybe
okay,
a
better
question
on
like
the
new
upgrades,
I
guess:
I'm
curious,
like
Yeah
from
from
client
team's
perspective,
like
how
much
have
you
been
thinking
about
new
upgrades
because,
like
everyone
on
Twitter,
obviously
talks
about
4844,
a
bunch
of
people
not
in
fine
teams
have
been
contributing
a
couple.
Incline
teams
have
as
well,
but,
like
you
know
mostly
like
we
shipped
the
merge
a
month
ago.
B
V
Yeah
so
I
I
kind
of
think.
Our
main
responsibility
is
our
users
right
now,
and
so
we
have
a
bunch
of
upgrades
coming
up
that
oh
yeah,
okay,
hi,
we
have
a,
we
have
a
so
forget,
at
least
from
my
perspective
forget
it's.
The
most
important
thing
is
the
current
Network
and
it's
not
the
it's
not
the
future,
and
it's
not
this.
V
So
we
have
a
bunch
of
other
things
coming
up
to
improve
things
about
around
the
database
in
gath
the
the
state.
The
way
we
store
the
state
and
so
yeah
I'm
really
excited
about
those
and
because
we've
been
focusing
kind
of
focusing
on
those.
We
haven't
focused
too
much
on
the
upcoming
eaps,
okay,
okay,
like
in
general,
the
team
I
I
personally,
also
like
I
I,
started
implementing
4844
in
Lighthouse.
V
O
D
D
C
Yeah
I
think
I
really
support
Paul's
point
on
the
the
next
thing
we
do
is
withdrawals
like
it's
got
to
be
done.
I
I,
don't
think
it's
reasonable
to
put
in
bigger
things
that
are
then
going
to
delay
getting
withdrawals
out.
We
made
a
promise.
We
shirked
on
the
promise
a
bit
and
you
were
all
very
forgiving,
because
we
got
the
merge
sooner
and
now
we're
going
to
deliver
the
promise
we've
got
to
come
through
on
that.
C
But
I
think
the
thing
that
really
comes
after
the
merge
is
the
use
of
support
for
the
merge
and
the
optimization
and
the
cleanup
and
the
learning
now
that
we're
actually
seeing
it
in
the
real
world
for
real,
there's
a
whole
heap
of
stuff
that
we
can
now
go.
Oh,
we
should
make
this
better
and
it's
not
going
to
be
protocol
upgrades,
it's
just
client,
Improvement
and
so
on.
C
E
E
Yeah
exactly
so
so
yeah!
That's
that's
why
it's
so
interesting,
because
there's
people
are
so
convincing
in
delivering
those
Visions,
yeah
I!
Think
that's
coming
back
to
her
Netherlands
team
thinks
about
the
next
delivery.
I
almost
would
like
to
to
activate
Daniel
here
to
tell
about
his
like
plan
of
of
delivering
them.
W
W
To
be
honest
for
the
whole
team,
and
now
people
want
to
do
things
that
you
know
you
know,
let's
say
slower
a
slower,
Pace
yeah
and
additionally,
we
would
like
to
clean
up
a
little
bit
Yeah,
because
there
was
no
time
I
know
I,
don't
know
if
you
are
aware,
but
like
never
mind
a
few
months
ago.
It
was
completely
different
Team.
It
was
undersized,
very
small.
W
At
some
point,
there
was
only
one
guy
Marek
working
on
the
merge,
which
was
crazy
and
you
know
I
was
really
sorry
when
I
joined
and
I
you
know
met
my
recognized
okay.
We
have
to
do
something
with
that
and
yeah.
Now
it's
we
are
in
a
completely
different
State.
We
can,
you
know,
improve
our
client
a
lot.
We
have
a
lot
of
things
that
actually
we
are
excited
about
and
they
are
not
enough.
I
would
say
one-to-one
related
to
to
Shanghai.
W
These
are
the
things
like
human
yeah
like
database
Improvement,
our
sync
Improvement.
You
know
our
robustness
of
the
clients.
These
are
the
things
that
maybe
are
not
so
excited
exciting
for
the
community,
but
they're
exciting
for
us
and
that's
we
are
mostly
are
talking
about
right
now
and
there
are
also
things
like
you
know:
documentation,
Community,
Support,
user
support.
These
are
things
that
didn't
work
well
in
the
past
and
I
think
in
general
it
should
be
improved
not
only
in
nethermine
but
in
the
whole
Community
yeah.
W
So
this
is
what
actually
excites
us
right
now
and
in
terms
of
particular
eips.
We
already
started.
You
know
investigations,
but
you
know
taking
it
slowly.
You
know
have
fun
with
it.
Like
four,
eight.
Four
four
is
you
know
there
is
one
guy
working
from
our
team.
That's
I
see
that
he's
really
excited
about
it.
That's
cool
there
is.
We
already
started
with
travels.
We
have
some
kind
of
draft
implementation
and
we
know
that
maybe
it's
gonna
change
but
yeah.
Why
not
to
start
playing
with
it
so
yeah
in
general
yeah.
U
K
Yeah
I
can
give
you
an
additional
perspective
from
Minority
client
like
lodestar,
we're
pretty
much
in
the
same
boat,
I
guess
with
like
nethermind,
where
before
like
at
a
point
where
we
haven't
even
hired
the
people
that
you
guys
have
at
this
point.
So
in
terms
of
time,
we
really
haven't
had
as
much
time
to
really
think
too
too
far
ahead.
We're
getting
most
of
the
stuff
from
you
know.
You
guys
in
in
the
community
and
such
but
technical
debt
is
definitely
a
huge
thing
for
us
as
well.
K
We
have
a
lot
of
documentation.
We
need
to
update
stuff
like
this,
which
you
know
it
would
be
nice
to
have
a
Sprint.
That's
just
you
know,
for
technical
debt
and
and
and
getting
our
client
up
to
to
par
in
that
sense.
But
that's
you
know.
We're
really
excited,
of
course,
to
implement
all
the
upcoming
stuff
in
the
roadmap
like
this
was
great
for
me,
because
I
haven't
even
specked
up
48
44
as
much
as
I
should
yet
so
that's
you
know
where
we're
at
basically.
U
So,
on
the
Nimbus
side,
there
is
a
delicate
balance
between
implementing
a
new
thing
that
are
still
moving
targets
and
doing
things
that
are
expecting
from
client
teams
like
testing
and
trying
not
to
introduce
regressions
like
we
had
a
lot
of
Point
release
in
the
past
three
weeks
before
the
match
and
that
took
like
all
of
our
Focus.
But
we
do
like
implementing
new
things
as
well.
U
For
example,
we
took
the
lead
with
load
star
on
the
light
client
thing,
so
this
is
something
that
we
will
continue,
but
we
didn't
start
at
all
on
anything
related
to
the
search
The
Verge,
The
Purge
endless
Branch.
Well,
we
did
try
to
look
into
kcg
commitment,
but
they
changed
a
lot
in
the
past
two
years,
so
everything
has
to
be
thrown
out
and
recorded.
V
F
I
just
wanted
to
share
from
a
small
client
perspective
so
for
Basu
honestly
past
month
has
been
as
equally
hectic
as
preparing
for
the
merge,
with
a
bunch
of
major
fixes
for
bug
fixes.
So,
honestly,
we
haven't
even
thought
of
a
future
eips
honestly
I
think
we
even
haven't
gotten
a
chance
to
rest
and
a
lot
of
the
maintainers
couldn't
make
it
because
they're
still
working
really
hard
working
on
the
fixes.
F
Some
even
donated
some
of
their
opportunity
leave
to
work
on
the
fixes,
so
quite
quite
intense,
but
I
think
afterwards,
we'll
hopefully
get
some
time
to
rest
and
get
all
the
maintainers
together
talk
through.
What's
going
to
be
the
future,
you
know
works
that
we
want
to
work
on.
What
really
resonated
me
personally
with
the
earlier
Talks
by
iOS,
the
subtraction
part,
so
I'm,
hoping
that
as
maintainers
we
got
to
see
which
part
of
our
code
base.
F
Could
we
actually
subtract
I
think
we're
still
talking
about
about
what
eips
are
we
going
to
add
and
add
and
add
to
our
code
base,
but
I
think
there's
going
to
be
some
like
future.
Like
you
know,
Tech
not
future,
like
Tech
debt
from
the
past
to
clear
out
to
modularize
the
the
product
itself,
and
so
looking
into
a
lot
of
I
would
say.
Client
Improvement
is
currently
where
I
see.
Maintainers
are
talking
a
lot
about,
but
yeah
definitely
would
would
have
to
come
talk
about
eips,
yeah.
G
So
I'm,
prism
and
I
think
withdrawals
is
important,
but
it's
also
on
the
easier
side
and
on
the
eip44
we
have
been
lucky
and
optimism
and
then
coinbase
have
been
contributing
to
our
code
base.
So
thank
you
for
that.
But
I
do
want
to
throw
like
a
curveball
I
think,
like
censorship.
Resistance
is
equally
as
important
as
444
and
withdraw
I.
Just
look
at
Mev
watch
info
at
47
of
the
blogs
are
on
the
offback
compliance
right
now,
so
47
of
the
Bloods
or
main
net,
or
have
some
sort
of
censorship.
G
Resistance
yielded
to
it
right.
So
I
do
think
like
there's
something
like
before
full
PBS
there's,
definitely
something
that
we
can
do
to
make
it
better.
We
do
have
some
hybrid
PBS
we
can
do.
We
can
leverage
the
Builder
API.
We
can
iterate
very
fast.
We
can
have
some
map
boosts
CR,
this
type
of
thing,
and
we
thought
this
latest
research
post
does
point
us
to
some
nice
Direction
and
point
out.
B
also
has
a
nice
research
post
as
well
so
I'm
very
excited
for
that,
and
I
definitely
definitely
want
to
prioritize
right
now.
X
I'm
very
sympathetic
to
teams
who
talk
about
wanting
time
to
to
work
on
their
client
and
handle
their
Technical
backload
and
I
thought
that
4844
and
withdrawals
was
a
really
good
example
of
they,
both
kind
of
individually.
Look
like
okay.
We've
got
kind
of
an
idea
of
how
these
two
things
are
going
to
work
but
and
then
putting
them
in
the
same.
V
So
so,
just
as
an
example
for
this
I
actually
implemented
the
forking
based
on
timestamps
for
Shanghai,
which
was
like
a
20
line,
change
and
I
looked
into
doing
the
same
thing
for
sorry
for
for
withdrawals
not
for
Shanghai
and
I,
looked
into
doing
the
same
thing
for
four
eight
four
four
and
it
would
be
like
70
different
files
that
I
would
need
to
touch
just
for
changing
the
changing
the
way
we
we
verify
the
signatures
and
the
sign
up.
So
it's
individually,
it's
it's!
H
E
So
well,
while
we
say
that
we
want
to
slow
down
at
the
same
time,
I'm
thinking
that
nevermind
is
ready
to
to
think
like
a
big
client
like
the
one
that
is,
that
is
leading
the
effort
on
the
exploration.
So
so
by
the
fact
that
we
have
the
large
team.
We
can
both
keep
cleaning
the
technical
lab,
but
also
participate
in
the
research
and
prototyping.
So
so
we've
we've
seen.
We've
heard
that
from
Mikhail
talking
about
has
been
guys.
E
So
we
have
those
excited
people
like
Alexa,
you
know
and
that
in
mind,
and
they
they
want
to
explore.
They
want
to
experiment,
and
this
should
help
everyone
to
to
push
things
forward
and,
and
these
deliveries
are
critical
and
they're
still
time
critical
I'll
be
doing
that
in
parallel,
even
if
the
field
will
be,
we
change
this
style.
That's
that
we
do
that
a
bit
more
mature
way.
I
think
that
maturity
will
come
also
from
the
learning,
from
the
merge
and
from
the
team
being
larger,
so
I
think.
E
W
But
it's
also
another
factor
that
we
need
to
consider
yeah,
but
like
changing.
Let's
say:
10
lines
of
code
or
17
files
two
years
ago
was
completely
different
than
changing
the
same
amount
of
files.
Right
now
the
code
base
is
much
bigger.
The
complexity
is
much
bigger
and
you
know
sometimes
you
know
Small
Change
requires
you
know
days
or
maybe
weeks
of
you
know,
research,
yeah
and
testing
and
testing
especially
testing.
Here.
It's
something
that
we
need
to
improve
and
so
yeah
the
teams
grow
grew,
but
at
the
same
time
it
takes
much
I.
J
If
I
can
add
something
else
and
on
clients,
the
right
now
testing
is
not
much
like
the
experienced
with
testing
is
not
much
better
than
the
experience
introducing
an
EIP
I
think
we
need
a
a
better
platform
to
discuss
like
the
bottlenecks
of
ethereum,
to
understand
it
like
the
complexity
of
syncing
of
disk
IO,
and
so
on
and
tools
like
Hive.
They
are
just
a
stagnant,
sometimes
as
the
clients
themselves
when
it
comes
to
making
changes
or
improvements.
J
V
So
one
thing
about
Hive
is
that
it's
currently
maintained
by
the
guest
team
and
we're
slowly
transitioning
this
over
to
the
testing
team.
So
Mario
wrote
a
lot
of
Hive
tests
for
the
merch.
Basically,
all
of
the
hive
tabs
tests
for
the
merge
and
so
as
I
said
we're
trying
to
increase
we're
trying
to
ramp
up
the
size
of
the
testing
team
within
the
ECM
foundation,
and
that
should
take
some
local.
J
B
B
If
you
want
to
do
something
like
blobs,
we
don't
have
like
blob
testing
right
and
so
we're
gonna
need
to
build
all
that
and
then
then
we'll
have
it
and
it'll
be
easier
to
like
you
know,
grow
the
size
of
blobs
or
something.
But
then,
when
we're
gonna,
we
want
to
do
I,
don't
know
like
daily
availability
sampling.
We
need,
like
you
need,
like
always
to
build
the
new
testing
stuff
and
it's
kind
of
hard
because,
like
you
can't
build
it
in
advance
because
you
need
you
need
to
test
something.
B
If
this
hadn't
happened
and
I'm
not
convinced
that,
like
four
years
ago,
it
would
have
been
possible
for
like
there
were
no
L2
teams,
but,
like
you
know,
for
like
the
Plasma
Team
to
like
ship,
something
like
that,
so
yeah
I
think
we're
making
progress.
I,
don't
know,
that's
ever
going
to
feel
better
is
by
rough
feeling.
C
It's
not
really
early
on
the
research
team
probably
gets
one
first,
then
the
client
teams
get
swamped
and
then
our
work
is
done
and
we're
kind
of
waiting
on
coordination
and
there's
this
lull,
and
that
lull
is
where
we
get
all
of
our
client
optimizations
and
all
the
other
stuff
kind
of
done
and
yeah.
So
that's
real
opportunity
and
and
a
lot
of
the
community
coordination
happens
there.
There's
there's
a
lot
of
time.
C
It
takes
to
go
from
the
code,
is
ready
and
done
to
the
code
is
tested
in
every
possible
situation
and
we've
automated
all
of
that
in
terms
of
the
cross-client
stuff
and
and
the
the
level
of
detail
we
want
for
ethereum
and
then
the
code
is
actually
ready
from
the
community's
perspective
and
all
the
tools
of
updated
and
so
on,
and
all
of
those
kind
of
happen
to
happen
in
sequence.
So
as
long
as
we
don't
shoot
for
a
massive
hard
Fork,
we
can
get
a
you
know.
A
little
hump
of
we
can
get.
C
You
know
say:
withdrawals
done
because
they're
relatively
simple
pick
up
a
lull
and
then
be
ready
to
to
pick
up
something
big
again.
So
it's
not
a
case
of
stop
the
world.
It's
just
managing
those
cycles,
and
probably
the
other
factor
is
that
teams
go
through
that
kind
of
cycle
as
well.
That
you'll
have
a
great
team
and
you're
going
well,
and
then
someone
will
get
a
better
job
offer
somewhere
and
you're
kind
of
suddenly
you've
got
fewer
people
on
your
team
and
you're
rebuilding
with
some
new
people
again
and
yeah.
C
Y
Y
Of
the
office,
that's
the
question
anyway,
but
I
did
I
did
want
to
ask
two
points
about
withdrawals
like
mostly
to
consensus
clients.
So
the
first
point
is
a
few
people
have
said
things
like:
oh,
it's,
a
relatively
small
change,
and
so
my
I
wanted
to
just
check
like.
Is
it
so
so
one
of
the
other
sessions
recently,
one
of
the
points
that
was
made
was
that
you
know
at
the
at
the
time
that
the
withdrawals
become
enabled
also
withdraw
key
rotation
becomes
available.
Y
So
there's
going
to
be
an
enormous
queue
of
people
wanting
to
do
key
rotation.
There's
gonna
be
massive
Mev
from
those
validators
who
are
trying
to
exit
before
they
get
hacked
because
their
key's
been
compromised
over
the
last
two
years,
all
kinds
of
other
sort
of
maybe
things
you
haven't
about
very
much
so
do
those
worry
people
at
all
or
not
at
all,
and
the
second
point
I
wanted
to
raise
about
withdrawals
was
around
whether
it
kind
of
links.
The
text
out
point
that
two
people
have
mentioned
is:
is
there?
Y
Y
It
seems
quite
natural.
You
might
want
to
just
have
a
corresponding
deposit
operation
clean
up
the
deposit
contract
deal
with
the
issues.
Like
kind
of
you
know,
double
counting
issue,
it's
all
this
kind
of
stuff
that
would
make
the
protocol
more
understandable
for
future
Generations.
Is
anyone
interested
in
that
or
is
that
for
later
I.
J
Heard
some
good
arguments
about
cleaning
up
the
deposit
contracts
to
keep
the
supply
in
the
balances
actually
matching
all
the
expectations
rather
than
looking
up
or
like
burning
the
the
deposits
and
then
minting
through
withdrawals.
So
that's
fair
I
do
think
deposits
are
user,
initiated
and
withdrawals
are
system
initiated
so
they're,
fundamentally
different.
C
But
yes,
there's
a
lot
of
tech
debt
there
and
yes,
we
will
fix
it
in
a
hard
Fork
at
some
point
just
to
simplify
like
it's.
It's
ridiculous.
The
beacon
chain
is
still
voting
on
what
it
sees
as
the
Ethan
head
after
the
merge
and
it's
8
000
blocks
behind,
but
hey
it
works
right
and
we
didn't
have
to
touch
it,
and
that
was
good,
but
we
will
have
to
fix
that.
J
S
Yeah
I
want
to
share
my
perspective
on
as
well
I
think,
like
we
have
heard
a
lot
about
tech
debt.
This
is
which
is
like
Fair
these,
the
the
devs
here
like
they
have
the
best
overview
of
that,
and
that
is
like
a
very
important
point,
of
course,
but
I
think
we
also
have
a
different
kind
of
debt,
which
is
like
right
now.
S
Is
is
not
enough,
in
my
opinion,
in
arguing
against
it
like
it's,
it's
we
we
have
to
like
at
some
point
also
start
seeing
the
other
side
like
okay.
So
what
what
is
the
consequence
of
not
doing
it,
like
my
fear,
like
of
course
like,
if
we
have
say
Shanghai,
for
we
managed
to
do
it
in
February
and
then
we
can
do
like
for
it
for
free
for
a
few
months
later.
S
If
things
costs
one
dollar
per
transaction,
which
I
could
do
if
it's
one
cent
per
transaction
so
I
think
like.
We
should
like
be
more
willing
to
like
think
about
this
part
as
well,
and
I
would
love
to
like
understand
how
we
can
also
like
get
that
in
that
thinking
into
our
governance.
Pro
process
as
well.
U
So
currently
we're
releasing
artworks.
Basically,
when
it's
ready,
so
the
more
things
we
put
inside
the
longer
it
takes
to
be
ready
because
of
testing,
for
example.
So
if
we
actually
do,
withdrawals
which
are
supposedly
simple
for
the
talk
from
yesterday
was
less
reassuring.
Regarding
that
we
can
yeah,
maybe
in
February
we
can
have
withdrawals
and
then
for
804
for
the
next
one.
But
if
we
put
both
together,
maybe
it
will
be
only
in
June.
Z
U
AA
I
will
say
one
of
the
added
challenges
that
the
specs
for
4844
and
capella
are
not
unified.
So,
like
he's
working
on
4844
I'm
working
on
capella
and
that's
gonna,
be
a
hell
of
a
pull
request
to
try
to
merge
these
things
and
test
them.
So
they're
kind
of
already
written,
like
they're,
separate
just
sure.
AB
So
one
thing
I
would
add
with
regard
to
hard
Forks
one
versus
two
is
that
you
generally
with
the
hard
Forks
implementing
something
takes
usually
less
time
than
rolling
it
out.
So
implementing
both
withdrawals
and
4844
in
the
same
artwork
definitely
makes
it
longer,
but
I
think
overall,
it
would
still
be
shorter
than
doing
two
hard
works,
because
you
have
a
yeah
sorry.
So.
AB
So
essentially,
I
think
rolling
out
the
hard
work
always
takes
two
to
three
months
of
just
while
every
client
is
yeah,
I'm
not
done
yet.
Let's
test
it,
tests
are
not
done
yet.
Okay,
let's
do
a
hard
work.
This
that's
not
hard
Fork!
That's
that
that
that's
not
so
we
kind
of
I,
don't
necessarily
want
to
say
we
suck
at
rolling
out
things,
but
we
don't
really
push
very
hard.
So
if
we
want
to
roll
out
two
hard
Forks,
then
you
have
this
boilerplate
time
that
will
eat
up
both
up
from
both
of
them.
AC
AC
AC
The
first
time
you've
had
me
in
this
room,
but
you
know:
we've
been:
we've
been
working
with
Proto
for
the
last
five
months
on
eip4844,
implementing
an
imprisonment,
spec
prism
in
Geth
and
I.
Think
to
doncrat's
point
the
difference
between
like
each
one
of
next
year
and
2024
for
a
business
like
coinbase
is
massive
and
I
think.
AC
Most
of
our
customers
who
are
not
in
the
US,
can't
pay
for
it
and
we
as
a
business,
especially
in
the
bear
Market,
can't
subsidize
the
cost
for
them,
and
so
what
that
means
is
that,
in
the
context
of
these
conversations,
the
people
who
may
be
don't
understand
the
technology
benefits
of
decentralization
or
security.
They
then
go
and
say:
hey,
there's
all
these
other
evm
chains.
They
have
sub
one
cent
fees.
Can
we
just
deploy
this
thing
on
that
like?
Would
that
be
a
faster
can
get?
Can
that
get
this
thing
shipped
in
q1?
AC
And
it's
up
to
the
people
like
me,
maybe
or
others,
the
company
who
who
understand
the
whole
process
and
why
we're
doing
Roll-Ups
and
why
this
is
such
an
important
investment
from
a
decentralization
security
perspective
say
no
like
we
need
to
wait.
We
need
to
wait
for
this
to
have
the
right
solution
and
so
I
think
waiting
until
the
beginning
of
next
year.
You
know
first
half
of
next
year,
I
feel
like
that's
like
a
thing
we
can
hold.
We
can
make
it
happen.
Waiting
until
2024
is
really
hard.
AC
That's
going
to
be
a
real
challenge
for
us
and
so
I
think
I
think
from
from
where
I
sit,
our
feeling
is
like,
let's
make
the
list
of
all
of
the
things
that
all
of
the
people
in
this
room
feel
like
we
need
in
order
to
feel
comfortable
and
if
that's
better
monitoring
of
the
network.
So
we
can
understand
bandwidth
if
that's
better
testing,
so
we
can
feel
more
confident
in
the
change
that
we're
making
whatever
it
is
like
give
us.
AC
The
list
give
optimism
the
list
and
we're
ready
to
throw
resources
at
this
and
support
this
and
I
know
that
again,
we
have
a
lot
of
trust
to
build
that
will
come
through
in
its
work
a
year
from
now.
I
hope
that
there's
a
lot
more
trust
here
but
I
do
want
a
voice
like
that's
the
impact
for
for
a
business
like
us
and
we're
ready
to
come
to
the
table
with
you
all
and
work
together
to
figure
out.
How
do
we
make
it
so?
AC
V
V
V
I
think
that's
kind
of
a
it's
a
minor
problem.
It's
it's!
The
other
thing.
The
bigger
problem.
I
I
see
is
that
from
yesterday's
conversation,
just
doesn't
seem
ready
yet
so
withdrawals
the
way
I
see
it
are
basically
done.
They're
like
they
are
implemented
in
some
of
the
clients.
Already
the
specs
seems
to
be
pretty
stable
and
with
Deng
sharding
we
recently
had
a
new
fee.
S
V
Okay,
it's
probably
a
bigger
change
for
the
for
the
consensus
layer,
I
think
for
the
execution
layer.
It's
it's
pretty
pretty
much
done!
And
okay,
okay,
okay,
maybe
I'm
I'm
totally
wrong
here,
but
I
I
agree
with
the
argument
that
so,
even
if
we
were
to
ship
withdrawals
in
January
I
think
we
could
own
the
ship
tank
sharding
September
of
of
2023.
V
If
we
were
to
do
both,
we
can
probably
ship
it
somewhere
in
the
middle
and
so
actually
would,
if
I,
if
I,
really
have.
If
I
really
think
about
it,
it
would
probably
cut
to
two
months
to
to
both
of
it,
even
even
though
I
don't
like
it,
and
even
though
I
don't
like
to
admit
it,
but
I
think
it
might
be
the
right
thing
to
do.
S
You
have
is
probably
that
it
is
a
bit
more
risky
to
do
both
at
the
same
time
and
I.
Think
like
most
people
would
probably
agree
with
that,
like
that
making
a
bigger
change
definitely
adds
to
the
risk
of
the
hard
Fork
itself
and
I
think
we
also
should
have
an
honest
conversation
on,
in
which
cases
we
are
willing
to
accept
those
risks,
because
what
we're
doing
is
just
so
important
that
maybe,
like
some
risks,
have
to
be
accepted
as
part
of
doing
it.
P
Yeah
Paul
from
techu
Team,
just
on
that
I
mean
there's
a
couple
of
aspects.
Maybe
we
need
to
get
better
at
doing
hard,
forks
and
releasing
them
honestly,
it's
a
long
time
between
code
completion
and
getting
to
getting
to
that
gate.
That
may
be
a
thing
we
need
to
address,
but
the
other
side
of
it
Playing
devil's,
advocate
I,
understand
that
4844
might
be
important
and
if
it's
relatively
well
defined,
there's
nothing
physically.
Stopping
us
from
doing
that.
First
and
just
delivering
4844
and
not
delivering
withdrawals,
I
mean
it's
a
it
is.
C
Yeah,
we
should
absolutely
focus
on
doing
the
most
important
thing.
First,
always
I
think
the
point
that's
come
up
a
couple
of
times
is
you
know
when
we
ship
withdrawals
and
it's
actually
when
we
finish
code
completion
because
running
through
test
Nets
doesn't
take
quarter
of
time.
We
put
out
a
release,
it
should
be
pretty
quick
and
easy.
There
is
coordination
cost
and
it
consumes
all
core
devs
for
a
while.
AB
In
between
I,
just
pop
in
so
in
my
opinion,
withdrawals
are
kind
of
specked
out,
so
it
I
mean
there
are
variations,
but
it's
simple:
it's
really
really
simple,
whereas
with
the
4844
that
will
most
definitely
take
a
lot
more
time
to
spec
out
and
it
has
a
lot
more
potential
problems
with
denial
of
service
and
everything
it
affects
Network,
so
withdrawals,
that's
just
a
tiny
consensus
change.
You
know,
tweak
a
bit
the
data
structures
and
done
with
with
4844
that
has
a
much
deeper
implication,
so
I
think
it.
AB
It
will
require
a
lot
more
work
and
in
my
opinion
it
would
be
much
simpler
to
say
that
okay,
for
withdrawals
are
definitely
going
in
and
maybe
give
a
cut
off
that
if
we
for
some
reason,
4844
gets
complicated
and
we
cannot
finish
it
by
month.
X
then
just
say:
okay,
we're
rolling
with
the
withdrawals
first
and
then,
whatever
whatever
the
other,
is
ready.
W
The
the
change
and
that
we
are
very
slow
in
the
second
part,
but
you
know
I
I,
joined
right,
yeah,
I'm,
I'm,
a
new
guy,
but
what
I
observed
with
the
merge?
We
we
shift
shift
in
middle
of
September,
but
what
I
observed
flag
from
my
the
definition?
I
know
the
code
was
not
completed
in
August
and
some
teams
were
like
pushing
the
changes
at
the
very
end
and
for
me
like
when
you
say
that
code
is
completed.
W
B
I
agree:
the
merge
was
not
a
case
where
we
were
called
complete
three
months
before
so
yeah,
but
but
we
have
done
that
before
right,
like
and-
and
you
know
again,
I
think
burden
London
was
like
a
good
example.
As
soon
as
we
were
kind
of
code
complete
on
burden,
we
started
working
on
London
before,
like
it
shipped
and
part
of
the
reason
for
that
three-month
delay
is
not
like
for
the
client
teams.
B
We
can
set
our
schedules
somewhat
independently
of
like
the
release
schedule,
but
that
doesn't
necessarily
mean
you
want
to
like
do
cold,
complete
and
ship
two
weeks
later,
because
there's
still
value
in
giving
people
time
to
upgrade
and
I
I
would
also
argue
the
merge
was
like
cutting
it
close
and
I.
Think
you
know
the
merger's
like
a
big
change,
the
environment
bits
the
like
proof
of
statements,
so
I
think
there
was
a
bunch
of
variables
in
that
one.
B
AD
What
if
we
prototype
some
of
our
ideas
relating
to
things
like
evm
and
transaction
formats,
on
a
layer
two
and
that
way
the
libraries
and
the
tooling
could
adopt
to
that
on
the
layer,
2
stuff
and
then
all
the
downstream
stuff
is
ready
and
then
layer
one
can
implement
it
when
they
have
the
bandwidth
and
not
having
to
rush
in
and
get
those
in.
So
you
can
get
cool
things
like
BLS
transaction
formats
sooner
rather
than
in
2024
or
2025..
J
AD
When
we
go
through
that
big
list
of
proposed
EIP
stuff,
that's
coming
up
in
the
next
thing,
like
half
of
them
are
just
evm
stuff
and
that
stuff
is
easy
to
push
through.
But
then
you
get
into
the
situation
like
we
had
with
subroutines
where
it
was
implemented.
It
was
ready
and
then
the
week
before
the
first
test
net,
all
of
a
sudden
it
gets
ripped
out
I
mean
I
I
like
the
idea,
but
your
voice
in
the
exact
concern.
AD
How
do
we
get
the
commitment
that,
if
it's
done
it
will
ship
on
layer
one
without
substantial
change?
Because
then,
if
you
have
these
changes
on
Layer
Two
and
they
change
substantially,
then
it's
a
burden
on
the
layer,
2
Chain,
if
they
put
it
on
on
one
of
their
Premier
chains
rather
than
on
testnet.
AD
AB
It's
a
bit
strange
because
it
kind
of
looks
like
there
is
commitment
to
go
with
an
EIP
and
in
reality,
what
at
least
what
I've
experienced
is
that
most
layer,
one
most
execution,
clients
won't
even
touch
any
IP
until
somebody
else
actually
implements
it
and
verifies
that
it's
correct.
So
usually
you
have
the
EIP
authors,
which
kind
of
has
to
beg
one
of
the
clients
to
please
implement
it,
and-
and
everybody
is
just
waiting
for
that
client
to
implement
and
find
all
the
corner
cases.
AD
J
B
Oh
just
yeah,
we
can
wrap
up
here,
we're
like
yeah
yeah.
We
can
I
mean
if
there's
final
comments,
we
can
do
that
then
maybe
we
should
take
a
short
break,
but
just
want
to
make
sure
we
wanted
to
keep
the
last
hour
to
discuss
actual
eips,
because
we
we
don't
usually
have
like
forums
to
do
that
with
all
the
client
teams.
So
if
people
want
to
have
less
comments
or
take
a
short
break,
you
can
do
that.
But
let's.