►
From YouTube: Merge Community call 5
Description
Agenda: https://github.com/ethereum/pm/issues/564
The Merge Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
B
A
Everybody
to
the
fifth
merged
community
call:
we've
been
trying
to
have
these
periodically
in
between
the
test
nets
and
we'll
be
having
probably
one
more,
at
least
in
advance
of
the
big
event.
But
this
is
the
fifth
one
and
we're
very
happy
to
see
everyone
that
made
time
to
join
here
today,
if
you're,
an
at-home
validator
somebody
who
runs
these
for
fun
or
is
just
a
member
of
the
community
or
you're
a
client
team,
that's
come
to
help
troubleshoot
stuff
or
answer
questions.
Thank
you
for
making
the
time
to
do
this.
A
C
Yeah
sure
I
guess
the
first
thing
you
know
they
mentioned
on
the
test.
Sets
is
two
of
them
have
merged
already,
so
robson
and
sepolia
are
on
proof
of
stake
along
with
kiln,
which
was
our
merge
test
net
that
we
launched
a
while
back.
So
if
you're
like
a
node
operator
or
validator
or
smart
contract
developer
or
infrastructure
provider,
you
don't
need
to
wait
to
test
this
stuff.
C
So
you
know
you
can
test
your
whole
setup
on
roxton
or
sepolia
today,
and
you
know
you
won't
run
through
the
actual
merge
but
90
of
what
you
have
to
do,
and
maybe
more
than
that,
even
you
you
can.
You
can
do
on
a
post,
merge
network.
So
that's
the
thing
I
would.
I
would
like
strongly
encourage
people.
Anyone
who,
like
runs
a
node
either
for
validator
or
or
not.
C
This
is
the
time
to
actually
get
on
the
network
and
and
figure
out
like
what
exactly
you
need
to
set
up
some
folks
at
the
ef
who
work
on
the
merge
launch
pad
or
sorry
that
is
taking
launch
pad.
They
put
together
a
checklist
as
well.
So
I
strongly
recommend
just
like
going
through
that
checklist
and
and
making
sure
you've
got
all
the
kinks
worked
out.
Most
importantly,
is
probably
just
like
making
sure
you
authenticate
your
well
take
a
step
back.
C
But
after
the
merge,
your
execution,
your
node
needs
to
validate
the
actual
blocks
on
the
network
and
to
do
that
it
needs
a
full
execution
client
so
set
that
up
and
the
the
one
quirk
there
is
in
order
to
ensure
the
communication
between
your
beacon
chain,
node
and
execution
layer
node
is
secure.
There's
a
a
a
token.
That's
passed,
I
guess
an
office
an
auth
token.
C
That's
like
an
erc20
token,
that's
passed
from
one
to
the
other
and
that's
something
you
can
all
like
run
through
today,
so
strongly
recommend
doing
that.
The
link
I
posted
has
like
extensive,
extensive
documentation
about
it
and
then,
similarly,
if
you're
a
validator,
there's
one
more
step
which
is
setting
a
fee
recipient.
So
as
a
validator
post
merge
you
receive
transaction
fees
which
currently
go
to
minors,
so
the
portion
of
fees,
that's
not
burnt.
You
need
to
specify
an
address
for
those
fees
to
be
sent
to.
C
Otherwise
it
depends
on
which
find
you
run,
but
either
things
will
break
or
it'll
be
sent
to
the
xerox
address
0x0
address.
So
you
want
to
specify
an
address
that
you
control
and
then
you'll
get
those
fees
when
you
propose
a
blocked
post
merge,
but
you
can
set
all
of
this
up
again
on
a
network
today.
If
you
want
to
run
a
validator,
you
can
do
so
on.
Robston
sepolia
has
a
permission
validator
set,
so
it's
not
anyone
who
can
do
that.
C
D
Sorry,
good
night
yeah,
you
said
it's
like
about
90
or
even
more
of
what
you
need
to
do.
It's
literally
100
of
what
you
do
like
if
you,
if
you
join
the
post-merge
network,
it's
the
exact
same
configuration
of
software
pre-merge,
it's
just
that
maybe
like
logs
and
what
you're
exactly
seeing
as
that's
happening
is
slightly
different.
But
if
you
can
configure
a
node
to
run
in
post,
merge,
you
can
configure
a
node
for
the
merge.
It's
all
100
of
the
steps.
D
D
C
C
So
again
the
merge
has
like
this
two-step
process,
where
first
is
an
upgrade
on
the
beacon
chain
and
second
there's
the
actual
upgrade
on
the
execution
chain
which
which
hands
over
the
consensus
to
the
beacon
chain.
So
you
should
expect
this
to
happen
early
august,
you
should
expect
to
have
probably
around
like
seven
to
maybe
ten
days
once,
like
the
the
kind
of
parameters
are
chosen
to
run
through
the
merge.
C
So
that
means
that
yeah,
if
you
think
that
you
need
more
than
a
week
to
like
get
set
up
on
gourley,
please
start
looking
at
the
other
test
nets.
Now
and
just
writing
a
note
there
and
that'll
get
you.
Basically,
you
know
the
entire
setup
up
and
running,
but
yeah
gordy
will
be
kind
of
the
last
test
nets
to
fork
before
mainnet
and
yeah.
You
can
expect
about
a
week
to
upgrade
nodes
there
and
then
for
mainnet.
C
C
A
C
I
mean
this
call
is
a
good
start,
so
it
depends.
You
know
what
like
level
of
detail
you
want.
If,
if
you
like,
we
have
the
r
d
discord,
which
is,
you
know
like
a
very
granular
thing.
So
if
you
want
to
follow
this
day
in
day
out,
that's
probably
the
right
place.
I
think
if,
if
you
want
to
follow
like
at
a
bit
of
higher
level,
there's
the
el
cordev's
calls
now
on
thursdays
and
the
consensus
their
calls
also
on
thursdays.
C
The
agendas
and
live
streams
are
linked
in
the
ethereum,
slash
pm
repos
and
the
issues
there
at
the
same
place
as
the
agenda,
for
this
call
is
so
watching.
Those,
I
think,
gives
you
like
a
bit
of
a
higher
level
kind
of.
Basically,
we
summarize
everything.
That's
happened
in
the
discord
in
the
past
two
weeks.
So,
if
you
don't
want
to
keep
an
eye
on
that
every
day,
that's
probably
the
best
place
to
be,
and
then
remy
posted
in
the
chat
blog.theorem.org.
C
So
I
think
once
we
do
have
like
the
official
releases-
and
you
know
like
a
proper
announcement-
that's
usually
where
it
goes
up
first
and
it
also
gets
shared
in
other
places.
So
this
is
kind
of
like
the
highest
resolution
of
you
know.
If
you
just
want
to
follow
from
like
a
distance,
then
yeah,
just
keeping
an
eye
out
on
the
blog
is,
is
probably
the
best
place.
We
also
have
a
mailing
list
now,
where
we
post
the
blog.
C
So
the
mailing
list
is
basically
I'll.
Send
you
an
email
saying
you
have
a
new
blog
post,
that's
pretty
much
it,
but
yeah
trent
posted
the
the
the
link
there.
So
once
we
do
fork
gordy
and
one
and
obviously
when
we
fork
mainnet,
we'll
we'll
send
an
opinion,
the
mailing
list
there
as
well.
So
that's
somewhere,
you
can
sign
up
but
yeah.
I
guess
discord
these
types
of
calls
which
are
on
the
ethereum
repo
and
blog.ethereum.org
yeah.
A
A
A
A
Well,
I
guess
they
would
just
be
proposing
if
you're
spinning
up
new
validators
we'd,
encourage
you
to
use
something
besides
prism
or
lighthouse
is
if
there
are
anybody
from
those
teams
that
would
be
included
in
that
definition,
and
you
want
to
jump
in
and
show
your
client
feel
free,
but
yeah.
So
if
you're,
a
news,
taker
or
you're
thinking
of
spinning
up
nodes
just
take
into
account
client
diversity
and
how
it's
important,
that
we
have
a
broad
distribution
of
client
types.
C
Yeah,
I
just
posted
in
the
chat
you
know.
Sometimes
people
wonder
like
why
is
this
important
and
bankrupt?
Has
a
really
good
post
kind
of
go
into
the
details
of
of
yeah?
What
are
what
are
all
the
bad
scenarios
that
can
happen
if
there's
too
much
concentration
in
a
single
client?
Similarly,
client
diversity.org
has
a
bunch
of
guides.
Well,
first,
it
has
some
rough
numbers
for
for
different
clients,
which
is
good.
C
C
They
have
a
one
page
button
to
do
that,
but
then
yeah
they
have
guides
for
like
some
of
the
like
some
of
the
clients
and
and
how
you
can
migrate
from
one
to
the
other.
So
I
I
strongly
recommend
having
having
you
look
at
that
and
then
one
thing
I'll
add
to
that.
Is
it's
also
good
to
have
client
diversity
on
the
execution
layer?
There
are
other
exhibition
layer,
clients
as
well
so
yeah,
it's
it's
worth
yeah,
it's
worth
changing
there
as
well.
C
B
That
sure,
sam
so
there's
different
ways
of
doing
it.
If
you
want
to
deep
dive,
you
can
like
go
through
the
cli
commands
yourself
follow
a
guide,
but
there's
a
bunch
of
different
tools.
Maybe
I
can
paste
all
the
tools
that
I
usually
recommend.
There's
there's
tools
that
are
like
wizard-like,
where
you
just
click
next
next
next
and
answer
a
few
questions
and
you're
done
with
it
pretty
much.
C
Okay,
yeah,
I
was
just
going
to
say
yeah
the
note
on
post
merge
test
net.
So
that's
also
worth
noting.
After
the
merge.
The
two
test
nets
that
will
be
maintained
long
term
are
gordy
and
sepolia.
If
you're
an
application
like
on
other
test
nets,
you
should
migrate
and
basically
the
three
other
test.
Nets,
kill
and
robson
and
ring
to
be
will
be.
C
C
C
You
know
open
c
still
on
ranking
b
people
rely
on
it
a
bit
more,
so
we're
gonna
give
people
a
longer
heads
up
than
leave
wrinkly,
so
we
expect
to
leave
it
up
for
maybe
like
a
year
after
the
merge,
the
caveat
being
that
we're
not
running
ring
to
be
through
the
merge.
So
as
soon
as
the
merge
happens,
rinky
stops
being
like
a
good
testnet
or
a
good
staging
environment
for
mainnet
and
that'll,
be
true
of
all
the
other
networks
that
are
deprecated
as
well.
So
say
there
was
an
upgrade.
C
C
The
the
the
delta
between
like
ricky,
b
and
and
maintenance
is
gonna
just
keep
growing,
so
now's
the
right
time
to
like
start
planning
the
migration.
You
know
you
still
have
a
couple
months
but
yeah
before
the
end
of
the
year,
robson
will
be
shut
down
and
then
in
the
next
year,
ricky
will
as
well
and
both
will
not
be
upgraded
or
maintained
any
any
further.
C
C
D
D
Yeah
yeah,
so
generally,
the
architecture
is
you're
in
your
consensus,
node
you're
on
our
execution
layer,
client.
They
talk
to
get
they
talk
together.
Your
validator
keys
are
sequestered
in
a
piece
of
software
called
the
validator
client.
These
three
things
can
produce
blocks
they
can
attest.
They
can
do
all
that
kind
of
stuff
in
mev
world.
D
It
is
often
not
it's
often
more
valuable
to
get
the
transaction
contents
for
your
execution
layer
from
kind
of
a
third-party
market,
rather
than
just
dipping
into
your
mempool,
because
there
are
various
sophisticated
searchers
in
how
they
combine
these
transactions
and
even
private
markets
on
getting
transactions
into
blocks
where
people
pay,
maybe
higher
fees.
So
there's
an
additional
piece
of
software
that
is
in
active
development.
D
It's
very
much
in
kind
of
very
proactive
testing
phase
and
doing
some
initial
audits
and
people
are
beginning
to
run
it
on
these
test
networks.
This
is
called
mev
boost.
Mev
boost
is
a
side
car
that
sits
right
next
to
your
consensus
layer,
client
and
essentially
gives
your
consensus
layer
client
the
ability
to
ask
this
network
of
builders,
this
network
of
searchers
for
valuable
blocks.
So,
essentially,
not
only
if
you
add
this
mev
boost
sidecar,
you
not
only
can
look
into
your
mempool
for
valuable
blocks,
but
you
can
ask
this
mev
network.
D
If
they
can
give
you
maybe
a
more
valuable
block
than
what
you
have
locally
and
the
the
way
this
works.
Is
it
does
a
little
bit
of
a
dance
with
these
relays
essentially
asks
for
bids.
If
there's
a
high
enough
bid,
it
would
then
kind
of
sign
that
bid
and
then
make
a
then
the
bid
would
be
revealed
and
they
would
get
the
block
and
send
it
to
the
network.
D
The
nice
thing
is
that
this
is
kind
of
a
parallel
work
stream
to
the
existing
consensus
like
tuition
layer
block
building
and
it's
kind
of
additive
in
its
functionality,
rather
than
kind
of
a
totally
totally
separate
work
stream.
So
this
is
something
that
I
believe
some
validators
will
be
running
at
the
merge.
D
D
There
should
be
a
lot
of
risk
in
running
this
software,
but
it
is
an
additional
kind
of
hurdle.
You
know
I'm
when
I'm
thinking
about
the
merge
and
thinking
about
running
through
it.
You
know
to
get
keep
things
simple.
I
might
not
run
muv
boost
and
then
maybe
like
a
week
after
kind
of
layer
that
piece
of
software
into
my
setup,
but
plenty
of
people
will
probably
run
it
at
the
merge.
So
it's
totally
up
to
you
any
questions.
D
A
C
I
think
streets
yeah,
I
think
it's
it's
asking
whether
or
not
we're
still
doing
tests
on
the
merged
test
nets
and
short
answer
is.
We
are
still
running
tests
on
them
and
we
probably
will
up
to
the
merge
on
mainnet,
but
we
don't
consider
we
consider
those
to
be
done
in
that,
like
the
network
has
transitioned
and
it's
stable,
but
we'll
keep
running
a
bunch
of
tests
on
the
various
test
nets
yeah
until
the
main
net
merge.
C
But
not
it
doesn't
mean
that,
like
the
fact
that
we're
running
sync
tests
on
robson
doesn't
mean
that,
like
the
robson
merge
is
not
over,
it
just
means.
We
want
to
test
the
sync
of
the
various
clients
in
a
bunch
of
combinations
in
a
post-merge
context,
and
robson
is
just
a
good
place
to
do
that
now,
because
it's
post
merge,
but
we
do
this
on
shadow
forks.
We
do
this,
I
don't
know
if
we
do
it
on
sepolia,
but
yeah
it.
A
C
Right
so
some
clients
will
generate
one
for
you
if
it's
not
if
it's
not
passed
as
a
parameter
upon
startup.
That
said
that
you
do
need
to
pass
it
to
the
other
client.
So,
for
example,
if
guess,
I
I'm
pretty
sure
get
generates
it
for
you.
If
there's
none,
so
if
guest
generates
a
jwt
token,
even
if
lighthouse
would
also
generate
one,
you
want
to
make
sure
it's
the
same.
So
at
least
one
of
your
components
you
need
to
pass
it.
C
C
I
did
a
bit
earlier,
but
yes,
fee
recipient
gets
passed
the
same
way
by
the
way.
So
you
know,
if
you're
writing
your
your
clients,
there's
going
to
be
a
flag
or
a
config
option
called
like
you
know,
jwt
token
or
something
like
that,
and
then
there'll
be
another
config
option
called
free
recipient
and
you
just
need
to
pass
obviously
a
jw
token
to
the
wwt
token
one
and
then
eat
address
to
the
fee
recipient
one
and
by
an
eth
address.
I
mean
like
an
eth1
execution
layer.
A
Yeah
formatted
address
right,
and
this
is
where
transaction
fees,
if
you,
if
you
create
a
block
you're
entitled
to
the
transaction
fees
that
miners
currently
get
once
we
switch
over
to
proof-of-stake.
So
you
want
to
make
sure
you're
getting
your
proper
reward
amount
and
setting
the
fee
recipient
is
part
of
that.
Yeah.
C
Should
I
start
writing
a
note
on
gordy
right
now
or
join
after
it's
merged?
So
if
you
want
to
run
through
the
merge
on
gordy,
now
would
be
the
right
time
to
start
running
a
node,
because
that
you
know
you'll
have
time
to
to
get
a
get
a
validator
up,
get
everything
set
up,
and
then
you,
you
have
plenty
of
time
to
be
ready
before
the
actual
merge
happens.
So
if,
if
you
do
plan
to
run
a
validator
and
and
run
it
through
the
merge,
it
makes
sense
to
start
running.
C
C
It's
like
a
trusted
endpoint,
so
you
want
to
trust
who
you're
well,
I
guess
take
a
step
back.
Oh
danny
has
a
question,
but
yeah
really
quickly
I'll
just
say
like
infer,
is
not
offering
the
engine
api.
So
it's
like
you,
you
literally
can't
get
access
to
it
and
daddy
will
walk
through
why
it
would
be
a
good.
Why
would
be
a
bad
idea
even
if
you
could
get
access
to
it.
D
There
are
places
in
the
protocol
where
a
validator
might
be
lazy
right.
You
could
I
mean
you
could
technically
offload
everything
and
just
kind
of
sign,
whatever
somebody
tells
you
to
do.
That's
probably
bad.
It's
bad
for
the
protocol,
it's
potentially
bad
for
profitability,
but
this
is
kind
of
the
lazy,
validated
problem
and
the
execution
layer
currently
has
lazy,
validator
problem.
You
could
just
blindly
sign
whatever
people
say
or
you
could
say,
hey
empire
or
somebody.
Can
you
just
check
this
out
for
me?
D
I
don't
want
to
run
it,
so
it
is
technically
possible
to
be
lazy
at
the
merge
for
that.
But
there
are
things
called
proof
of
proof
of
custody
of
execution
that
will
be
layered
into
the
protocol
to
ensure
that
there's
not
the
lazy,
validator
problem
on
the
execution
layer
and
so
inferior
and
others
are
not
currently
offering
engine
api,
because
it's
not
really
a
sustainable
business
model
to
be
offering
something
that
will
be
taken
out
of
the
protocol.
D
C
Execute
the
next
question,
I
think,
is
what
percentage
of
validators
will
run
muv
boost,
I'm
not
sure
that
it's
like
possible
to
know
this
in
advance.
But
one
thing
that's
worth
noting
is
like.
There
are
other
ways
you
know
for,
like
especially
sophisticated
validators,
like
large
capital
operators
to
to
do
mvv.
So
it's
it's
not
like
and
just
like
today,
you
know
there
are
other
ways
to
submit
med
bundles
than
through
flashbots
directly.
C
So
it's
you
know
yeah
it's
hard
to
predict
not
only
because
we
don't
know,
but
also
because
there's
other
alternatives,
and
it
might
very
well
be
that,
like
people
run
multiple,
you
can
imagine
like
multiple
like
pieces
of
software,
just
like
maybe
boost
that
are
different
builder
networks.
That
validators
want
to
run
in
parallel
because
you
get
different
bundles
from
them
kind
of
like
we
see
on
unproven
work
today.
C
So
I
I
don't
know
that
there's
like
a
percentage
estimate,
and
even
if
there
is
that
percentage
estimate,
tells
you
how
many
it
tells
you
how
many
validators
run
flashbots
and
you
can
like
infer.
Maybe
how
much
mvv
goes
through
flashbots,
but
it's
not
like
a
full
overview
of
like
the
entire
mvv
landscape,
either
so
yeah.
I
would
just
caveat
that
and
the
next
one
is
it
go
ahead?
It's
very
good,
as
you
say
next
one.
C
C
We
might
disencourage
it
and
if
the
flashbots
teams,
you
know,
might
also
also
push
that,
just
in
the
case
where,
if
there
was
a
bug
at
the
merge
it's
easier
to
debug,
if
you
know
we
can
assume
that
it's
just
the
execution
and
consensus
air
client
and
that
the
issue
does
not
come
from
like
mvv
boost
like
danny
was
saying.
Mbv
boost
is
pretty
independent
from
like
the
the
consensus
client.
So
it's
not.
C
It
would
be
unpro
improbable
for
that
to
like
cause
the
issue,
but
I
think
just
to
be
like
extra,
safe,
we'd,
probably
recommend
not
running
yet
right
at
the
merge
and
just
waiting
until
it's
finalized.
But
you
know
you
can't
like
stop
people
from
from
running
the
software.
Basically,
there's
no
thing
and
there's
things
like,
for
example,
you
know
flashbots
maintains
a
relay
on
mdv
boost
and
they
can
shut
that
down,
but
anyone
else
could
run
a
relay.
So
it's
not
like
you
know.
Flashbots
doesn't
have
single
and
can't
singlehandedly
control.
C
So,
like
unchained,
you
might
see
just
like
a
bit
more
chaos
related
to
abv,
but
then
at
least
at
the
like
node
software
level,
things
if
things
go
wrong,
it's
it's
easier
to
debug
and
run
through,
and
you
know
in
in
the
in
the
happy
case
like
we
expect
finalization
to
take
like
12
minutes
after
the
merge.
So
it's
yeah
can
maybe
imagine
like
an
hour
or
so
without
any
boost
being
on.
C
C
So,
for
example,
and-
and
I
don't
know
off
the
top
of
my
head
who
has
and
who
hasn't
but
like
you
would
want
to
look
in
like
the
config
file
of
the
network,
that
you're
running
so
say
wraps
it
in
your
case
and
check
is
the
ttd
that's
set
there,
actually
the
the
real
ttd
or
is
it
still
the
fake
number
like
the
the
extremely
high
number?
If
it's
the
high
number,
then
you
would
need
to
keep
that
flag
and
otherwise
you
would
need
to
remove
it
or
you.
C
You
can
still
keep
it,
but
you
you
could
remove
it,
but
I've
different
clients
may
or
may
not
have
upgraded
that
as
part
of
their
default
releases.
So
that's
a
bit
of
a
disappointing
answer,
but
you
you
just
need
to
look
and
I
suspect
clients
will
have
that
in
their
release.
Notes
as
well
once
they
like
update
the
change
yeah
and
that
might
be
something
actually
yeah.
A
A
D
D
Now
it's
expected
that
exited
validators
who
then
also
do
a
change
of
cred
withdrawal,
credential
operation
to
make
sure
they
have
0x01
or
execution
layer
address
withdrawal
credentials,
then
on
some
cadence
would
be
swept
into
the
withdrawals
queue
and
their
entire
balance,
including
any
rewards,
would
go
into
the
execution
layer.
Additionally,
it
looks
as
though
to
reduce
the
incentive
to
churn
the
validator
set.
There
would
be
kind
of
a
partial
withdrawals
function
where,
if
you
have
what's
again
called
an
ox01
or
execution
layer,
address
withdrawal,
credential
or
eth1
withdrawal
credentials.
D
If
you
have
those
set
up
which
you
can
set
up
with
a
new
message,
your
balances
in
excess
of
32
eth
on
some
cadence,
depending
on
the
size
of
the
validator
set,
would
be
swept
into
the
withdrawals,
queue
and
land.
In
that
address
specified
in
the
execution
layer
so
to
make
that
clear,
there
is
the
functionality
to
exit,
get
all
of
your
eth
into
the
execution
layer
back
into
normal
ethereum
addresses
and
there's
ability
to
on
some
cadence
have
your
rewards
swept
into
the
execution
layer.
D
There
is
a
link,
that's
kind
of
a
meta
spec
that
references,
the
eips
and
the
different
things
going
on
the
consensus
layer,
spec,
and
I
will
find
that
link
and
drop
it
in
here.
But
yes,
there's
a
plan.
Yes,
there's
some
additional
testing
to
still
do,
but
yes,
there's
also
general
consensus
on
how
to
do
this
and
it's
just
kind
of
doing
some
final
refinements
and
then
going
into
the
whole
engineering
testing
and
production
phase.
C
And
one
final
note
I'll
add
on
that.
So
this
is
all
about
like
beacon,
chain
withdrawals,
but
we
touched
earlier
that
at
the
merge,
transaction
fees
are
available
to
validator.
So
if
you
do
hold
like
a
derivative,
whether
it's
lido
or
a
centralized
one
on
binance
or
coinbase
or
rocket
pool
or
whatnot,
it
is
a
good
question
to
ask
to
like
the
the
the
party.
C
That's
that's
managing
that,
like
what
is
their
plan
with
regards
to
transactions
needs
an
mvv
because
yeah
that
is
immediately
available,
and
so
you
could
imagine
you
know
anything
from
the
operator
keeping
100
of
it
to
the
operator
distributing
100
of
it
as
it
comes
in
and
all
those
things
are
very
much
technically
possible.
So
there
is
no,
you
know
if
your
operator
is
telling
you
they
cannot
distribute
transaction
fees
because,
like
withdrawals
are
not
live,
that's
just
not
true,
and
it
might
it.
C
A
C
So
this
means
that
at
the
merge
just
like
how
on
mainnet
miners
stop
being
relevant
to
the
consensus
and
the
gourley
proof
of
authority,
signers
stop
being
relevant
to
the
consensus
and
the
consensus
is
taken
over
by
this
public
beacon
chain
that
is
prater
and
we're
all
just
gonna
call
it
gori
after
it's
merged
but
yeah.
This
is
what
happened
so,
even
though
you
cannot
be
a
validator
on
gordy
today,
anyone
can
be
after
the
merge
and
then
sepolia
basically
was
the
opposite.
C
So
sepolia
was
running
proof
of
work
before
its
merge
and
anyone
could
mine
on
sepolia
and
then
after
the
merge,
because
we
want
to
provide
like
a
stable
test
that
basically,
we've
restricted
the
set
of
validators
on
the
network.
So
it's
it's
just
like,
I
guess
proof
of
authority
like
people
can
join
if
they
are
whitelisted
and
there's
like
a
process
for
that.
C
So
it's
like
yeah,
it's
kind
of
weird,
because
gordy
is
going
from
permission
to
unparitioned
and
then
cefolia
is
going
from
un-permissioned
to
permission,
but
it's
just
good
to
have
both
types
of
test
nets,
because
obviously
you
want
validators
to
be
able
to
test
stuff,
but
also
it's
valuable
to
just
have
a
test
net.
Where
you
know
the
validator
set
is
going
to
run
no
matter.
What?
Because
there's
no
incentive
to
maintain
a
test
net
validator.
C
C
So
it's
almost
like
we,
the
term
validator,
is,
is
like
a
bit
weird,
because
every
node
on
the
network
actually
validates
the
blocks,
whether
or
not
they
they
build
it
or
attest
to
it
in
the
proof-of-stake
protocol.
So
there
is
value
in
like
running
your
own
node,
even
though
you're
not
a
validator,
you
know
to
yourself,
because
you
can
just
interact
with
the
network.
C
Permissionlessly,
but
also
to
the
network,
because
this
is
how
you
kind
of
protect
against
validators,
including
and
deciding
to
change
the
protocol
rules
it's
by
having
a
large
set
of
nodes
outside
of
these
validators.
That
act
as
kind
of
a
check
on
the
system.
You
know
like
if
a
validator
creates
a
bad
block.
All
the
other
nodes
will
just
be
able
to
notice
that
okay
there's
a
question
about
like
the
merge
state
so
september
19th.
I
would
not
use
that
as
a
merge
date.
C
I
we
were
like
roughly
trying
to
estimate
when
it
could
happen.
You
know
it
might
happen
during
that
week.
It
could
be
the
week
before
the
week
after
if
we
found
an
issue.
It
could
be.
You
know,
weeks
after
that.
I
think
you
know
people
want
this
to
happen
soon
and
like
we
are
trending
well
towards
like
having
it
happen
earlier.
This
fall
rather
than
later,
this
fall,
but
there's
always
the
risk.
C
You
know
say
we
did
this
gordy
merge
or
even
independent
of
the
gordy
merch
say
we
find
a
really
bad
issue
tomorrow.
We
will
obviously
prioritize
like
a
safe
merge
over
a
quick
one.
Yeah,
so
I
wouldn't
like
you
know,
make
any
I
don't
know
bets
or
like
have
a
large
financial
stake
writing
on
the
verge
happening
on
september
19th.
I
think
it's
like
a
rough
target
that
people
think
is
possible
if
things
continue
roughly
at
their
other
current
base.
Yep.
D
C
A
C
Okay,
yeah
there's
the
last
question
about
mvp
boost
and
like
yeah,
you
know
and
the
sort
of
legality
aspects
of
of
accepting
certain
bundles.
You
know.
First,
you
don't
need
to
run
mev
boost.
You
know
like
so
mbv
boost
gives
you
potentially
more
transaction
fees
and,
like
you
know,
obviously
those
transaction
fees
are
extracted
through
mev
and
there's
a
whole
like
spectrum
of
wbv,
including
like
yeah
sandwich
attacks,
which
is
like
front
running.
C
So
this
is
why,
by
the
way,
there
might
be
a
world
where
you
see
like
large
entities,
maybe
not
run
mev
boost,
maybe
they'll
run
their
own
kind
of
mev.
Maybe
they'll
run
no
mev
first
of
all,
but
you
could
very
much
imagine
a
large
regulated
entity
running
like
their
own
mev
relay
which,
like
blacklists
certain
types
of
bundles
right
and
they
can
run
analysis
on
the
bundle
and
say:
oh,
this
is
front
running.
C
We
don't
want
to
do
this,
you
know
so
we're
just
not
gonna
accept
this
bundle
or
you
know,
and
you
can
imagine
this
is
like
a
a
legal
thing,
but
you
know
there
is
like
this
long
tail,
nft
mvvs.
When
people
like
fat
finger,
you
know
selling
their
punk
for
like
eight
way.
Instead
of
you
know,
80
or
something
you
could
very
much.
D
I
would,
I
would
say,
a
couple
of
things,
one
like
the
who
knows
and
who
knows
and
what
just
jurisdiction-
and
I
think
anyone
who
speaks
confidently
is
to
knowing
one
way
or
the
other
doesn't
know.
And
then
the
other
is
that
the
way
that
me
beautiful
architecture
works
is
that
it
it
can
allows
for
open
relays.
D
A
D
So
it
is,
there
is
a
muv
boost
specification
item
to
say
that
consensus,
air
clients
won't
run,
even
though
the
software
is,
there
won't
actually
dip
into
the
builder
network
to
get
blocks
until
after
the
merge
is
finalized,
it
seems
like
there's
general
consensus
and
it
seems
like
this
will
be
baked
into
clients.
It
does
seem
like
flashbots
who
will
operate.
A
A
People
go
through
it
periodically
and
add
the
checklist,
but
this
is
a
pretty
good
reference
if
you're
looking
for
things
to
follow
and
then
related
to
the
date
like
generally,
yes,
there's
a
rough
idea
of
when
this
could
happen
on
mainnet,
but
to
be
clear,
there's
no
specific
day,
there's
no
specific
time.
Anybody
who
tells
you
that
is
is
wrong
or
they're.
Just
they
have
a
misunderstanding.
So
when
there
is
a
specific
date,
it
will
be
announced
on
the
ethereum
blog
and
throughout
the
broader
ecosystem.
A
There'll
be
enough
time
for
people
to
to
understand
when
it's
actually
happening.
What
else,
if
you're
running,
if
you're
participating
in
validation,
do
not
depend
on
infuria,
you
won't
be
able
to
use
your
infuria
execution
infiera
for
execution
post
merge.
You
need
to
start
running
your
own
execution,
client
locally.
A
C
D
So,
currently,
all
clients
utilize
this
engine
api.
So
the
question
is:
is
it
requisite
that
you
use
the
engineering
api
or
are
there
alternatives?
So
there's
the
kind
of
the
core
specs
the
core
specs
tell
you
the
state
transition.
They
tell
you
how
to
talk
on
the
network
and
that
kind
of
stuff,
but
they
don't
really
tell
you
about
client
architecture.
D
We
have
these
clients
and
pieces
of
software
that
are
very
specialized
at
managing
the
beacon
chain,
managing
proof
of
stake,
validators
balances,
bls
signatures,
all
that
kind
of
stuff,
and
so
it's
very
natural
to
unify
these
pieces
of
software
over
an
interface,
and
that
is
the
engine
api
that
historically
is
very
natural.
It
also
would
be
very
natural
to
look
at
all
these
specs
and
write
one
big
piece
of
software
and
call
it
a
client,
and
so
the
engine
api
does
not
preclude
that
from
happening.
D
But
there
is
not
currently,
from
my
knowledge,
even
a
project-
that's
very
actively
pursuing
this.
I
know
that
nimbus
does
have
a
very
nascent
execution,
layer,
client
and
they're,
considering
doing
an
integrated
build
with
an
optional
engine
api,
if
you
don't
want
to
use
one
side
of
the
or
the
other,
and
you
know
any
any
piece
of
any
domain
that
does
have
clients
on
both
side
of
the
aisle
in
the
same
language.
People
might
experiment
with
that
in
the
future,
but
right
now,
100
of
the
production
clients
are
utilizing.
This
engine
api
thing.
D
Yeah
so
validators
leak
information.
They
make
a
lot
of
messages
and
it
is
very
likely
possible
to
reverse
engineer
where
the
or
you
know
the
origin
of
those
messages
with
respect
to
ip
and
kind
of
figure
out
where
validators
live
on
nodes
and
then
some
of
these
roles,
especially
the
proposal
role,
is
known
in
advance.
D
Some
people
are
experimenting
with
how
to
use
openvpn
and
rotate
vpns
to
allow
to
help
prevent
dos
and
other
things
like
that.
So
more
like
practical
mitigations
in
the
event
that
this
happened,
that
would
you
would
certainly
see
kind
of
a
scramble
to
get
the
practical
mitigations
out.
There
are
also
other
kind
of
protocol
mitigations
like
single
secret
leader
elections.
So
instead
of
that
proposer
being
known
in
advance,
the
proposer
knows
in
advance,
but
everyone
else
doesn't
know
and
that
proposer
then
makes
a
proof
when
they
make
their
block.
D
This
is
very
under
very
active
development,
but
it's
hard
to
say
when
exactly
it
would
come
out
to
mainnet
it's
kind
of
one
of
those
like
security
features
that
is
always
competing
with
user
features.
So
it's
like.
Okay,
do
we
enhance
the
security
of
the
protocol,
or
do
we
get
out
charting
or
something
like
that?
There's
there's
kind
of
always
a
careful
balance
between
those
two
types
of
things.
D
Additionally,
there's
research
into
more
private
networking
components,
so
imagine
land
leveraging
certain
types
of
network
constructions,
like
dandelion
plus
plus,
where
you
pass
messages
around
secretly
before
they
kind
of
enter
into
the
network,
and
so
it's
not
clear
who
the
origin.
The
message
was
so
there's
a
lot
of
good
research
paths
along
that
way,
but
there's
also
a
lot
of
good
practical
mitigations
that'll
be
leveraged
in
the
event
of
attack.
A
We
are
at
time,
thank
you,
everybody
for
joining
tim.
You
have
any
like
final
things
that
you
want
to
go
over.
I
would
say,
if
you're,
so,
if
you're,
a
validator
being
on
this
call,
is
great,
but
if
you
haven't
participated
in
any
test
nets
and
you're
currently
running
validators
for
the
beacon
chain
you
need
to
participate
in
gurley,
don't
run
your
setup
on
the
the
main
net
merge
without
having
participated
in
a
test
net
merge.
A
This
is,
I
don't
know
how
to
how
else
I
can
stress
this,
but
you
should
test
your
stuff
before
we
go
to
mainnet
it's
coming
soon,
and
it
will
be
here
sooner
than
you
expect,
if
you're
not
paying
attention
and
trying
to
trying
to
test
your
stuff
ahead
of
time.
That
was.
I
just
wanted
to
stress
that
again,
if
you're
a
minor
part
of
the
mining
community,
please
pass
this
to
them.
I
know
the
merge
has
been
a
long
time
coming.