►
From YouTube: Merge Community call 4
Description
B
All
right,
sorry
about
that
everybody
I'm
getting
rusty.
I
used
to
do
this
for
you
global
and
we
had
this
problem
a
lot,
but
I've
forgotten
my
large
call
management
skills,
but
now
everybody's
muted
and
we
should
be
fine,
going
forward.
A
Thanks,
trent,
okay,
so
let
me
repost
the
two
blog
posts
and
and
quickly
kind
of
go
back
over.
It
just
want
to
make
sure
we
have
time
for
a
bunch
of
questions,
so
we
announced
the
robson
merch
transition
earlier
this
week.
The
first
blog
post
I
link,
has
all
the
client
versions
that
that
are
compatible
with
the
upgrade,
as
well
as
like
a
couple
notes
for
node
operators
and
stakers.
A
I
think
the
first
one
of
those
is
that,
obviously,
if
you,
if
you
run
both,
you
need
to
run
both
an
execution
layer
and
consensus
layer
client
to
participate
in
the
transition
on
robston
and
there's
a
new
api
over
which
these
two
communicate
called
the
engine
api,
and
this
api
requires
jwt
as
secret
for
authentication.
A
Most
clients
will
generate
it
upon
starting,
but
you're
gonna
need
to
pass
it
from
basically
the
el
to
the
cl,
or
vice
versa.
So
that's
something
you
should
pay
attention
to
when
you're
kind
of
setting
up
your
on
the
staker
side.
This
is
probably
the
most
important
thing
is
after
the
merge.
A
Stakers
are
the
beneficial
beneficiaries
of
priority
fees
on
the
network.
So
all
the
transaction
fees
that
currently
go
to
miners
go
to
stakers
after
the
merge
and
in
order
to
receive
those.
If
you
write
a
validator,
you
need
to
set
what's
called
the
fee
recipient
as
part
of
your
consensus,
layer,
client,
so
different
clients.
I
have
like
different
ways
to
set
this
up,
but
whatever
you're
using
it's
part
of
their
their
documentation.
A
So
that's
something
you
want
to
look
into,
and
this
basically
asks
you
for
an
eth
address
where
you
want
transaction
fees
to
be
sent
to
when
you
propose
a
block,
and
it's
worth
noting
that
this
is
just
like
a
regular
ether
address,
so
those
fees
are
not
locked
on
the
beacon
chain.
They're
like
immediately
accessible
to
you
after
that
block
is,
is
confirmed
so
so
yeah.
A
Please
do
set
that
up
to
make
sure
that
and
test
it
on
robson
to
make
sure
that
you
can
actually
get
transaction
fees
and
then,
finally,
this
is
the
second
blog
post
that
I
linked.
So
the
merge
is
like
a
two-step
process.
First,
you
need
to
activate
and
upgrade
on
the
beacon
chain
called
bellatrix,
which
basically
starts
listening
for
the
merge
to
happen
and
the
way
that
it
does,
that
is,
it
listens
for
a
specific,
total
difficulty,
proof-of-work
value
to
be
hit
on
the
on
the
network.
A
So
like
it
just
constantly
paints
the
the
proof
of
work
network
and
asks
it
you
know:
have
you
exceeded
this
total
difficulty?
If,
yes,
it
runs
through
the
transition,
if
not
it
pings
again.
A
So
when
we,
when
we
put
out
the
releases
earlier
this
week,
we
selected
a
really
really
high
terminal
total
difficulty,
and
the
reason
for
that
is
because
the
hash
rate
on
robstin
is
super
low
and
it's
easy
for
people
to
kind
of
mess
with
it
at
a
fairly
low
cost,
and
we
wanted
to
make
sure
that
the
bellatrix
upgrade
on
the
beacon
chain
was
was
ready
prior
to
choosing
the
actual
terminal,
total
difficulty.
A
And
so
last
night
that
happened,
and
so
this
morning
we
just
published
a
second
blog
post,
which
has
the
kind
of
actual
terminal
total
difficulty
value
at
which
we
expect
the
transition
to
happen.
And
so
all
you
need
to
do
there
is
you
need
to
pass
this
value
to
both
your
execution,
layer
and
consensus
player
client
and
the
blog
post
has
literally
the
flag
that
you
can
copy
and
paste
for
every
single
client
and
I'll
just
post
the
actual
value
of
the
chat.
A
So
if
you're
already
running
something-
and
you
know
how
to
do
the
override,
you
basically
need
to
override
the
terminal
total
difficulty
to
this.
Stop
yeah
I'll
stop
here
to
make
sure
we
have
like
time
for
plenty
of
questions.
Yeah.
B
Oh
yeah,
so
if
anybody
has
any
questions
related
to
that,
just
put
them
in
the
chat.
Unfortunately,
I'm
gonna
stay
away
from
audio
questions
for
now,.
A
Okay
and
yeah,
while
we're
waiting
yeah
just
worth
noting,
we
do
expect
to
hit
this
this
terminal
total
difficulty
value
and
for
the
merge
to
happen
on
roxton
late
next
week,
probably
around
like
wednesday
or
thursday.
A
It's
really
hard
to
predict
this,
because
proof
of
work
on
test
nets
is
very
unstable,
but
I
would
strongly
suggest
just
running
this
ttd
override
either
today
or
early
next
week,
so
that
you're
you're
good
when
the
merge
happens,
and
one
final
note
also
for
folks
who
folks
have
only
used
the
beacon
chain.
One
thing
to
note
is
that
for
when
the
merge
happens,
you
want
to
have
a
fully
synced
consensus
layer,
client
on
the
beacon
chain
and
execution
layer
client.
If
you've
only
ever
used
the
beacon
chain.
A
You
will
think
that
sinking
is
quite
fast
and
you
will
be
disappointed
when
you
try
to
sync
on
the
execution
layer
side.
So
please
be
mindful
that
it
takes.
It
can
take
up
to
a
few
days
to
sync
a
note
on
robston,
and
so,
if
you
want
that
by
the
end
of
next
week,
I
would
I
would
suggest
I
I
would
suggest
getting
that's
started.
A
Either
today
or
early
next
week-
and
it's
fine
also,
if
you're,
if
you're,
syncing
your
node
and
and
you
still
don't
have
like
the
merge
client
versions-
that's
totally
fine.
You
can
start
your
sync
update
your
client
and
then
and
and
then
finish
your
sync
with
any
client.
Okay
and
now,
there's
like
a
ton
of
questions,
so
I'll
just
start
going
through
that,
what's
the
best
way
to
determine
transaction
finality
on
each
one
execution
after
the
merge
using
the
standard
json
rpc,
is
it
possible
still
yeah?
A
So
basically,
today
there
is
no
way
to
determine
a
transaction
finality
on
the
execution
layer
under
proof
of
work.
All
you
get
is
like
probabilistic
finality
where,
as
more
and
more
blocks
accumulate
the
odds
of
a
reorg
get
much
lower
at
the
merge,
we're
going
to
include
a
new
flag
in
json
rpc
called
finalized,
which
you
can
use
when
querying
your
block,
just
like
you
use
latest
today,
and
that
returns
the
last
finalized
block
on
the
chain,
and
this
block
cannot
be
reverted
unless
there's
basically
a
major
attack
on
the
network.
A
So,
if
you,
if
you,
if
you
want
to
determine
basically
finality
yeah,
just
my
pc,
will
have
a
flag
for
that
and
it
returns.
It
returns
a
block
in
the
last
slot
that
was
finalized,
basically
okay
and
then
there's
a
second
question
about
the
paris
upgrade
on
the
el.
And
what
does
that
do
and
how?
How?
How
does
it
work
alongside
bellatrix?
A
So
these
names
are
really
confusing
and
that's
why
you
should
try
to
call
everything
the
merge,
but
basically,
if
at
a
very
high
level,
the
merges.
This
pro
is
like
this
entire
process,
which
has
different
parts.
A
So
the
first
part
is
for
the
beacon
chain
to
start
pinging
the
execution
layer
chain
and
asking
it
you
know:
are
you
ready
for
the
merge,
and
this
is
what
we
basically
call
bellatrix
so
like
the
beacon
chain
kind
of,
becomes
aware
that
there
will
be
a
transition,
that
it
will
need
to
include
specific
payloads
which
contain
user
transactions
at
a
certain
time
and
and
starts
kind
of
pinging
the
clients
for
that
and
obviously
runs
through
the
entire
merge.
A
Once
that
happens
on
the
execution
layer
side,
we
also
have
changes
which
happen
at
the
merge
and
we've
called
those
paris
and
it's
a
bit
it's
a
bit
weird,
because,
unlike
a
previous
hard
fork,
these
changes
don't
apply,
starting
at
a
specific
blocked
number.
They
apply
only
when
we
hit
this
terminal,
total
difficulty
value,
and
so
in
practice
you
know
what
those
changes
do
is.
First,
they
start,
you
know,
handling
engine
api
calls
from
the
consensus
layer.
A
They
stop
listening
to
proof
of
work
as
a
way
to
get
the
next
block
and
then
there's
a
small.
A
couple
of
small
changes.
For
example,
the
difficulty
op
code
and
now
becomes
the
prevrondao
up
code
so
and,
and
some
parts
of
the
block
headers
are,
are
now
zero
going
forward.
So,
there's
like
all
these
kind
of
changes
in
behavior,
caused
by
the
merge
and
and
that
set
of
changes
on
the
execution
layer
is
what
we
call
paris.
A
But
basically
paris
is
what
happens
on
the
execution
layer
when
ttd
is
hit,
but
it's
a
bit
confusing
to
call
that
paris
and
not
just
the
merge,
so
we've
we'd
mostly
use
the
merge.
But
paris
is
just
like
the
formal
name
of
the
specification
for
executioner
changes.
When
the
merge
happens.
A
Are
we
safe
to
keep
mining
on
robson
for
that
erupts
in
either?
Should
we
switch
off
the
current
hash
rate?
A
Is
it's
fine
on
robston
we're
gonna
increase
it
early
next
week
in
order
to
hit
the
merge
sometime
next
week,
but
if
you
were
already
mining
yeah
and
that's
that's
fine,
there's
no
need
to
take
it
off
and,
like
next
question
is
kind
of
similar
around
like
how
how
much
hash
power
I
I
I'm
not
sure
the
exact
number,
but
I
think
if
community
members
want
to
start
helping
to
mine,
I
I
would
ask
that
you
kind
of
hold
off
until
like
late
monday
or
tuesday,
just
because
it
gives
more
people
time
to
upgrade
their
ttd.
A
How
long
does
it
take
forget
node
to
fully
sync
in
archival
mode?
I
actually
don't
know
the
answer
to
that
question.
You
don't
need
a
full
like
archive
node,
by
the
way
to
run
as
a
consensus
layer,
client
you
can
just
to
run
as
an
executioner,
client
on
the
merge.
You
can
just
run
basically
a
snap
sync
on
geth
snap
sync
takes
on
the
order
of
like
hours,
assuming
you
have
a
good
internet
connection,
I'm
not
sure.
A
Quite
how
how
many
exactly
but
an
archive
note-
I
I
don't
know
it-
would
take
you
probably
more
than
a
week
just
to
do
a
full
archive
sink.
I
don't
know
if
there's
anyone
from
guest
on
the
call
who
can
answer
this.
A
Anyways,
oh,
if
so
I'll,
try
to
find
them,
and
I
need
them
is
the
expectation
to
hit
june
eight
nine
ask
me
natural
hashtag,
or
do
we
need
to
rent
rates
so
again
we're
going
to
need
to
rent
a
little
bit.
I've
seen
that
both
the
consensus
client
that
the
consensus
client
has
its
own
database
is
it
recommended
to
run
both
on
the
same
server?
Yes
like?
Yes,
they
both
have
their
database.
I
don't
know,
I
see
a
lot
of
people
like
from
client
teams.
A
Here
I
see
frederick
from
like
the
ef.
Does
anyone
like
from
either
a
client
team
or
the
ef
want
to
like
maybe
take
a
couple
minutes
and
explain
how
they
set
up
everything
and
and
what
you
all
think
the
best
practices
are,
and
if
you
raise
your
hand,
I
guess
trent
can
unmute
you.
B
A
C
C
Yes,
you
absolutely
can
we
expect
the
same
amount
of
resource
usage
as
we
see
now
pre-merge
as
long
as
there's
both
a
consensus
layer
and
an
execution
layer,
client
running
on
the
machine,
and
there
was
a
second
question
as
to
can
I
still
run
my
valve
data
client
somewhere
else
and
point
it
at
wherever
I
want
to
go.
Yes,
absolutely
still
works
awesome.
Thank
you.
A
Next
question:
is
there
a
consensus
client
recommended
by
you
short
answer
is
no
so
in
the
robson
blog
post.
We
linked
that.
But
client
diversity
matters
a
lot
on
the
network,
especially
after
the
merge.
A
So
we
recommend
that
people
run
a
minority
client
if,
if
they
can
just
because,
if
there's
a
bug
in
any
of
the
clients,
you
don't
want
that
client
to
have
more
than
ideally
a
third,
and
especially
not
two-thirds
of
the
clients
on
the
network,
because
if
there
was
a
bug
in
a
client
with
more
than
a
third
of
those
on
the
network,
you
could
stop
the
network
from
finalizing
and
if
it
was
more
than
two-thirds,
it
could
finalize
something
that
was
wrong
and
that's
really
a
situation
we
want
to
avoid.
A
So
we
yeah
we.
We
really
suggest
that
people
random
minority
client
and
in
the
original,
robson
blog
post,
there's
a
there's,
a
link
right
above
the
client
versions
table
that
shows
you.
What's
the
current
mark,
basically
network
share
of
every
single
client,
so
you
can
make
a
decision
based
on
that
and
there's
also
a
really
good
post
by
bankrupt.
A
That's
linked
right
next
to
it,
which
goes
into
like
technical
details
about
what
are
the
actual
risks,
if
there's
a
majority
client
that
has
more
than
a
third
or
more
than
two-thirds
of
the
the
stake
on
the
network,
so
I
guess,
or
my
personal
recommendation
would
be
a
minority
client,
but
I
I
don't
have
a
strong
one
beyond
that.
A
Okay
and
then
the
second
question
was
the
next
question
was
answered,
then
nick
had
a
question.
How
different
is
implementing
the
merge
on
robson
versus
other
test
native
emergency
success
on
robson
should
be
pretty
confident
the
next
couple
test
nets.
The
short
answer
is,
I
guess
there
is
no
short
answer.
The
answer
is
we're
doing
robsten,
probably
a
bit
earlier
than
we
otherwise
would
in
the
process,
and
the
reason
is
because
it's
such
like
a
big
change
relative
to
other
upgrades
for
node
operators.
A
We
wanted
to
make
sure
that
people
kind
of
got
to
try
it
early
and
then,
if
stuff
goes
wrong
with
your
setup,
you
have
you
know
plenty
of
time
to
fix
it,
and
so
obviously
robson
going
well
is
like
a
good
indicator,
but
we
do
know
that
there's,
like
a
bunch
of
tests
left
to
fix
clients,
still
have
some
issues
here
and
there.
A
So
it's
not
it's
not
a
given
that
just
because
roxton
is
the
successful
then,
like
two
weeks
from
now,
we
move
to
the
next
test
steps
I
think
for
the
next
one
we'll
want
to
have
things
a
bit
more
polished,
but
yeah.
We
thought
it
was
really
important
to
to
give
the
community
like
a
an
opportunity
to
run
through
the
merge
kind
of
asap
so
that
we
can
find
any
issues
before
we
move
together.
Test
nets.
A
Okay,
yeah
good
question
about
tesla
deprecation,
so
to
confirm
the
two
test
nets
that
we
intend
to
maintain
long
term
after
the
merge
are
gordy
and
sepolia
gourley
and
and
basically
the
parador
beacon
chain,
that's
associated
with
it,
which
will
merge
and
kind
of
call
algori
afterwards.
But
that
combination
and
sepolia,
which
is
a
new
testament
that
we've
recently
launched
etherscan,
has
just
added
support
for
it
and
and
and
that
will
be
maintained,
kind
of
in
the
medium
to
long
term
as
well.
A
So
for
the
other
test
nets
you
have
roxton,
which
we're
obviously
running
through
the
merge.
Now
we
intend
to
deprecate
it
after
the
merge,
I'm
not
sure
exactly
when,
but
you
can
expect
some
time
before
the
end
of
the
year.
We
have
another
test:
net
called
rinkeby,
which
runs
proof
of
authority
contest
algorithm.
This
one
is
not
being
run
through
the
merge.
A
So
if
you
have
stuff
on
rinkybee,
it
means
that
once
the
merge
happens
on
mainnet,
rinkeby
won't
be
like
a
good
copy
of
mainnet
for
you
to
test
on
for
smart
contract
developers,
it
shouldn't
change
too
much,
except
for
this
difficulty
op
code.
But
if
you're,
if
you're,
testing
more
like
infrastructure
and
stuff,
then
it'll
be
it'll,
be
quite
different,
so
rinkeby
again
we're
not
to
shut
it
down
overnight.
A
It'll
probably
stay
up
until
like
late
this
year,
but
as
of
the
merge,
we
basically
consider
it
to
be
deprecated
and
then
lastly,
there's
kiln
that's
mentioned
so
kiln
was
the
new
testament
that
we
spun
up
basically
just
test
the
merge
we
launched
it
in
march
and
the
goal
there
was
to
get
some
birdie
testing
from
the
community
about
you
know,
does
do
these
nodes
work
together
and
like
can
you
deploy
your
smart
contract
and
and
kind
of
use?
Ethereum
post
merge,
so
we've
we've
launched
it
then,
and
that
was
always.
A
The
purpose
was
just
to
test
the
merge,
so
I
suspect
we'll
leave
that
one
up
until
the
merge
on
mainnet
and
deprecated
pretty
quickly
after
so
just
to
summarize,
you
know,
rinkaby
is
just
not
being
transitioned
and
will
probably
be
shut
down
by
the
end
of
this
year.
Kiln
is
already
beyond
the
merge
and
will
be
shut
down
shortly
after
the
main
net.
A
Merge
roxton
is
transitioning
as
we're
talking
about
today
and
will
be
shut
down
later
this
year
and
then
gordy
and
sepolia
will
both
transition
and
and
will
will
carry
on
medium
to
long
term.
B
D
Yeah,
hey
everyone
yeah,
so
for
minority
clients,
I
mean
great
thing
that
you
mentioned
modestar.
Is
you
know
robsten
ready
so
for
people
who
do
want
to
set
it
up?
We
actually
have
a
pretty
cool
merge
script.
That
is
basically
like
a
one
line:
command.
Startup
that'll
start
up
a
a
load,
star,
beacon,
node
alongside
the
execution
layer
right
now,
it's
you
can
choose
between
gath,
nethermind
and
baesu.
D
So
you
can
check
that
out
on
our
github
page
github.com
chain
save
load
star
and
then
under
the
kiln
folder
under
devnets.
All
the
instructions
are
there.
You
can
also
find
all
of
that
stuff
in
some
of
our
chain,
safe
blog
posts.
We
do
have
setup
guides
and
some
videos
for
you
as
well,
which
I
can
post
into
the
the
issues
for
this
meeting
afterwards
as
well
in
terms
of
hardware
specs.
It's
not
that's
nothing!
D
Fancy
just
like
a
normal,
like
even
16
gigabyte
ram,
pretty
modern
type
of
processor
will
be
able
to
handle
it
all,
and
we
do
recommend
that
people
use
docker
with
load
star
in
terms
of
preventing
you
know
like
npm
type
supply,
chain,
attacks
and
stuff
like
that.
So
if
you
do
run
docker,
you
shouldn't
have
a
problem
setting
up
load
star.
A
A
I
see
some
nether
mind
people
here,
yeah,
oh
thomas,
go
for
it.
E
Hey,
hey
sure,
yeah,
some
of
the
mind
tests,
all
the
robs
will
be
maintenance
ready.
It
introduced
recently
the
snap
sync
that
gives
you
something
like
around
three
three
hours
to
sync
and
snap
sync
mode
with
the
mainnet,
and
you
can
use
it
on
practically
all
the
network
that
will
be
going
through
the
for
the
merge
testing.
It
does
sync
with
all
the
shadow
forks
test
nets
and
so
on
so
yeah,
like
you're,
really
encouraged
to
run
it.
Let's
also
have
a
look
at
the
documentation
and
docs:
that's
nevermind.io.
E
E
A
Of
course,
thank
you
and
matt
you're
from
basu.
F
Yep,
that's
right,
similar
story
to
what
was
just
said.
We
are
a
minority
client
with
baesu.
We
have
a
lot
of
great
features
that
we'd
love
folks
to
test
out
as
well
like
snapsync
and
our
bonsai
storage
format,
which
we're
eager
to
get
folks
using
especially
on
these
test
nets,
so
that
we
can
of
course
make
sure
that
we're
even
more
merge
ready,
but
we
do
have
stuff
up
and
running
on
robson
right
now,
so
we
would
love
for
you
to
check
us
out.
Try
us
out.
F
We
have,
you
know,
support
for
a
bunch
of
different
platform
types.
So,
whatever
platform
you
have
will
likely
be
supported
with
native
support,
so
you
can
get
great
performance
there
and,
of
course,
always
want
to
see
more
and
more
participation
and
more
and
more
usage
of
these
features.
Reach
us
on
discord.
Give
us
some
feedback.
F
Let
us
know
how
everything
is
going,
you
know,
and
we
would
always,
of
course,
we're
going
to
be
participating
ourselves,
so
we'll
probably
have
some
results
to
share
after
the
actual
merge
and
we're
looking
forward
to
putting
out
some
more
material
around
the
merge
as
well.
So
you
know,
of
course
you
can
find
the
docs
at
baysu.hyperledger.org
and
you
can
find
a
lot
of
material
on
the
hyperledger
discord
and
the
consensus,
discord
and
different
blog
posts
on
twitter
and
consensus.net.
A
I
know
guess:
death
and
prison
are
also
here.
So,
if
you
guys
want
to
give
a
quick
shout
also,
please
do
I
it
feels
it
feels
wrong
to
like
not
allow
it
with
the
with
the
disclaimer
that
they
are
the
two
majority
clients.
Anyone
from
geth
or
prison
wanna
give
a
quick
update,
they
can
talk,
but
they
only
get.
G
H
Hey
yeah,
we're
happy
that
other
clients
are
having
so
much
progress
and
you
should
really
try
them
out
and
see
how
it
works
out
with
them
and
you're
also
happy
to
to
try
out
gap
yeah.
That's
it
seven
seconds.
G
Awesome.
Thank
you.
I
just
wanted
to
add
that
all
the
clients
are
great,
so
definitely
try
every
single
one
of
the
combo
and
give
us
feedback
at
the
end
of
the
day,
like
those
feedbacks
are
very
important.
So
if
you
have
one
client
better
than
the
other
client,
please
do
share
that
with
with
the
other
client.
I
just
want
to
add
that.
A
Yeah
great
point,
any
other
client
teams
here
that
I
missed
or
just
I
need
to
like
scroll
back
and
forth
the
zoom
participants,
but
last
call
client
teams.
I
think
that's
that's
everyone.
We
have.
B
A
So
sea
monkey
asks
about
whether
it's
still
worthwhile
to
have
validators
on
kiln,
or
should
he
shift
or
should
they
shift,
I
guess
their
their
resources
all
over
to
robsten
and
there's
there's
an
answer
from
thurston
already
in
the
chat
like
kiln
is
the
only
network
where
we're
currently
testing
any
v
boost,
so
there's
obviously
value
there,
but
with
regards
to
just
kind
of
running
a
bunch
of
elevators
and
testing
there,
I
I
wanted
to
say
that
it
makes
sense
to
to
move
to
roxton
rather
than
kiln,
but
if
anyone
on
the
client
or
testing
team
is
here
and
disagrees
with
me,
can
you
please
speak
up
my
my
instinct
would
be
yes,
but
I
would
confirm
it
in
the
r
d
discord
just
in
case
there's
something
I'm
missing
that
yeah,
that
that
means
it's
still
valuable
to
do
it
on
kiln.
A
Okay,
next
question
recently
had
to
delete
prism,
beacon
chain
data
to
fix
syncing
issues.
It
took
about
three
days
to
sing
prism.
Is
this
normal?
Is
this
a
normal
amount
of
time
parents?
Do
you
want
to
take
that.
G
Yeah
we
do
get
that
feedback
a
lot,
so
we
are
actually
landing.
We
subjected
to
this
thing
in
our
latest
release,
so
please
do
try
that
the
documentation
is
all
there.
I
will
paste
the
document
teacher
in
the
chat.
So
if
we,
if
you
start
with
the
finalized
state
or
which
is
we
subject,
the
same
thing,
it
is
much
faster
yeah.
A
Awesome
thanks
next
question:
is
it
possible
to
test
the
merge
with
drops?
Then
first
is
what's
a
lower
ttd
since
bellatrix
is
already
activated.
So
that's
what
we
did.
I'm
not
sure
I
understand
the
question,
but
basically
the
new
ttd
is
much
lower
and
this
is
why
people
need
to
overwrite
to
it
and
robson
will
be
the
first
public
test
net
to
run
through
the
merge,
but
I'm
not
sure
if
I'm
actually
answering
your
question
gabrielle.
A
B
A
Okay,
yeah,
oh
yeah,
there
was
a
question
about
koban
and
I
saw
I
think
martin
from
gnosis
is
on
the
call.
Do
you
all
have
a
update
on
covant,
or
should
we
just
consider
it
to
be
deprecated?
I'm
not
I'm
not
quite
sure
what
the
status
is
there
actually.
I
K
Yeah,
sorry
yeah.
Yes,
the
question
was
about
copen,
whether
that
will
or
what
was
the
question.
K
I
know
right
right
right
now
right,
so
no,
it
will
not,
because
coven
is
essentially
open,
ethereum
only
and
yeah
after
announcing
it
three
times
said
open
ethereum
is
dead.
I
think
it's
finally
really
dead.
So
on
our
end
a
little
bit
of
context,
maybe
so
on
also
formally
ex-die
now
notice
chain,
we
will
are
still
planning
to
do
our
merge
or
we
will
see,
but
currently
targeting
to
do
it
yeah
shortly
before
ethereum
we
are
currently
developing
or
well.
K
A
Got
it
thanks
for
clarifying
okay
and
gabriel
has
his
hand
up
from
the
previous
question
so
I've.
I
think
I've
unneutered.
J
J
A
J
A
Yes
and
you
should
the
teaching-
yes,
yes,
oh
so
we're
not
gonna
lower
it
on
robson,
but
basically
you
should,
by
setting
up
your
execution
and
consensus
layer
today,
like
you,
should
be
able
to
know
that,
like
they're
working
together
that
the
cl
is
pinging,
the
el
that
your
jwt
token
is
set
up
right.
So
you
don't
need
to
hit
the
ttd
for
that.
A
But-
and
you
want
all
of
those
things
to
be
set
up
and
and
working
before
the
ttd
hits,
because
that's
when
you
actually
run
through
the
merge,
so
you
yeah,
it
should
be
like
there
shouldn't,
be
anything
stopping
you
from
from
updating
everything
today
and
and
making
sure
that
it
works.
And
then
once
we
hit
ttd
they're
just
gonna
run
through
the
merge.
But
you
should
you
should
kind
of
yeah.
There
shouldn't
be
like
a
block
here
before
that.
A
Oh
there's,
if
you
have
another
question,
maybe
post
it
in
the
chat
but
yeah,
I
I
think
you
should
be
all
right.
A
First,
then,
you
wanted
to
shill
your
automation
tool
that
supports
online
clients.
I
think
we
can
allow
that.
Okay.
C
All
right,
thank
you.
So
I'm
going
to
keep
that
brief.
I
have
an
automation
tool
called
f
dash
docker
at
sdocker.net.
It
supports
all
nine
clients
for
robston.
It
uses
the
official
releases
from
the
client
teams.
It
also
supports
mev
boost,
but
I
think
right
this
very
second.
It's
only
lighthouse
that
actually
has
that
implemented
and
we
don't
have
a
a
relay
yet
for
robston,
but
we
might
get
one.
So
that's
it
just
if
you
want
to
try
things
out
switch
clients
around
quickly.
Online
clients
are
supported.
B
Can
you
share
a
link
to
it?
I
wasn't
able
to
find
it.
A
Okay,
next
question
was
a
working
faucet
for
robson.
There
was
already
a
couple
shared
and
there's
a
link.
I
just
shared
in
the
chat
that,
like
is
pretty
good
across
all
test
nets.
It
tells
you
like
what
are
all
the
faucets
that
they
have
money
in
them,
and
so
it's
a
good,
just
general
faucet
tool
to
see
where
you
can
find
some
some
testnet
piece.
A
Okay,
lots
of
comments.
Have
you
heard
from
infer
already
don't
have
a
robson
cl
checkpoint?
Sync
endpoint?
I
have
not.
Is
anyone
from.
A
How
can
people
contribute
to
the
roughstand
merge
if
they
don't
run
a
client,
yeah
running
a
client?
I
mean
so
so.
There's
a
couple
things
like
one
is
yeah
running
a
client
and
reporting.
Any
issues
is
really
good
and
and
when
I
mean
reporting
any
issues,
it
doesn't
have
to
be
necessarily
technical
issues
like
if
you're
trying
to
run
a
client
and
like
the
documentation
for
the
client
you're
trying
to
use
is
just
like
really
unclear
like
trying
to
highlight.
That
is
also
useful.
A
So
it
doesn't
only
have
to
be
like
an
actual
technical
issue
and
I
think
the
other
bit.
That's
really
helpful
is
if
you
are
a
smart
contract
developer
or
just
like
a
tool
in
your
infrastructure
provider
like
running
through,
like
a
full
deploy
on
either
kiln
or
robson
post.
A
Merge
is
really
helpful
and,
and
we
don't
expect
anything
to
break
at
the
contract
level
or
at
the
tooling
level,
but
it's
just
like
because
I
don't
know
if
you
use
a
bunch
of
like
automation,
tools
or
like
deploy
scripts
and
stuff
like
that,
like
there
might
be
weird
things
that
that
do
end
up
breaking,
even
though
the
network
is
stable
and
finding
those
issues
is
really
important.
Yeah
and
I
think
that's
really
the
two
biggest
ones
beyond
that.
A
Like
I,
I
think
it's
just
trying
to
use
the
stuff
on
kiln
but
yeah.
The
you
know,
most
of
the
value
is
really
just
like
either
running
a
node
and
to
be
careful
when
you
run
a
client,
it
doesn't
necessarily
mean
a
validator
like
you
can
just
run
a
node
and
sync
it
and
make
sure
that
that
works
as
well.
So
it
doesn't
have
to
be
an
actual
validator,
that's
running
and
then
trying
not
only
to
deploy
a
smart
contract
but
more
to
like
deploy
an
entire
kind
of
application
with
a
front
end.
A
Okay,
next
question:
what
are
the
odds
that
somebody
controls
the
new
ttd?
I
mean
I,
I
don't
know
what
the
odds
are
but
like
they,
you
know
it
is
possible,
like
it
does
not
cost
hundreds
of
thousands
of
dollars
to
do
this.
So
the
worst
case
scenario
there
is
like
it
would
be
a
bit
more
annoying
for
end
users,
who
want
to
run
their
own
like
at-home
validators,
who
haven't
already
upgraded
or
overridden
their
ttd.
So
we
recommend
people
do
that
as
quickly
as
possible.
A
All
of
the
like,
the
vast
majority
of
the
the
validators,
though
on
the
network,
are
controlled
by
client
teams
and
the
testing
teams
and
whatnot.
So
all
of
those
have
already
been
upgraded.
So
from
the
network's
perspective
you
know,
even
if
the
ttd
was
hit
now,
it
would
run
through
the
merge
and
be
fine
from
an
end
user
who's
trying
to
like
test
their
validator
setup.
A
If
they
haven't
had
time
to
do
the
override,
it
would
be
a
bit
annoying
because
then
they
need
to
do
the
override
they
might
have
to
manually
set
a
specific
block
as
the
head
or
as
valid
as
part
of
the
chain.
So
it's
not!
It's
not
ideal.
There's
not
really
a
great
solution
against
this,
because
the
hash
rate
on
tesla's
is
just
so
low
and
it's
so
cheap
to
mess
with
them.
A
Okay
does
get
need
to
be
fully
call
up
for
lighthouse
to
be
able
to
talk
to
it,
I'm
seeing
below
an
error
in
lighthouse
while
get
this
thinking
marius.
Do
you
wanna?
Do
you
wanna
get
that.
H
Yeah,
I
I
already
answered
chat
but
yeah.
L
H
Guess
doesn't
need
to
be
fully
synced.
You
and
postmate,
of
course,
will
not
be
fully
synced.
When
you
start
up
a
note,
you
will,
you
will
start
up
both
the
consensus
layer,
node
and
the
execution
layer,
node
and.
H
Yeah,
it
might
just
be
a
configuration
problem
in
that
case,
but
I
also
saw
a
bunch
of
times
that
lighthouse
would
just
lock
this
error
out
if
something
like
if
gas
is
sinking,
so
it
might
just
be
a
logging
issue,
but
yeah
you
should
be.
I.
H
A
Okay,
oh
yeah,
so
aside
tracking
the
difficulty
increasing
so
trent
shared
one
in
the
chat,
I'm
not
sure
the
thing
is
like
these
estimates
are
only
good
if
the
the
hash
rate
stays
stable,
which
we
don't
expect
to
do,
because
we're
gonna
want
to
accelerate
the
hash
rate
sometime
next
week.
So
to
make
sure
we
ship
this
ttd
value
next
week,
you,
the
total
difficulty,
is
part
of
the
block
header.
A
So
if
you
go
on
ether
scan,
you
know,
and
you
look
at
the
last
block,
you
can
see
the
total
difficulty,
but
I
yeah-
I
wouldn't
trust
the
estimations
too
much,
because
you
can
basically
make
it
happen,
much
quicker
or
much
slower,
based
on
on
pretty
small
changes
in
hash
rates,
so
yeah
we're
hoping
to
have
it
hit
around
wednesday,
thursday
next
week.
But
if
it
hit
you
know
on
monday,
because
someone
adds
a
bunch
of
hash
rate
over
the
weekend.
That
is
the
possibility.
A
So
the
best
thing
you
can
do
as
like
a
user
is
just
make
sure
that
you
have
the
ttd
override,
which
is
literally
copy-pasting
two
lines
when
you,
when
you
start
your
client
and
that'll,
make
sure
that
you're,
regardless
of
when
it
hits
your
client,
is
ready.
A
A
No,
so
the
thing
that
does
change
so
transaction
formats
on
the
el
are
unchanged
block.
Header
formats
are
also
unchanged,
but
some
of
the
block
values
will
be
like
set
to
zero.
The
block
format
of
the
consensus
layer
does
change
after
the
merge,
and
so
that's
something
that,
if
you
are
basically
using
these
apis,
the
beacon
apis
that
will
change,
but
on
the
execution
layer.
A
Are
there
any
plans
to
not
publish
the
main
fttd
to
the
public
until
about
a
week
left
from
it?
So
yeah,
that's
a
good
question.
It's
it's
hard,
so
so
there's
different
approaches.
We
can
do
here.
What
the
thing
we
want
to
avoid
is
the
ttd
being
hit
prior
to
bellatrix
being
activated
on
the
beacon
chain?
If
so,
one
way
to
do
that
is,
we
can
activate.
A
You
know
bellatrix
on
the
beacon
chain
quite
early
on
mainnet,
and
it
basically
does
nothing
in
terms
of
functionality
until
the
ttd
is
here.
So
that
gives
us
a
chance
where
it's
like.
We
could
have
just
a
first
client
release
with
bellatrix
and
have
like
a
ttd
of
basically
infinity
and
then
and
then
we
can.
A
We
could
kind
of
choose
the
actual
ttb
in
terms
of
how
much
of
a
heads
up
we
give
people
we,
I
would
personally
prefer
it
to
be
longer
than
a
week
for
people
to
upgrade,
because
it's
mainnet
and
it's
also
worth
noting
on
maintenance.
The
risk
is
like
a
bit
different,
so
on
mainnet
in
proof
of
work,
we
have
the
assumption
that
nobody
can
double
the
hash
rate
overnight,
because
otherwise
they
would
be.
You
could
51
attack
the
chain.
So
you
know,
if
we're
happy
with
like
the
safety
properties
of
proof-of-work.
A
A
The
thing
that
might
happen,
though,
on
mainnet,
is
that,
because
the
merge
is
happening,
hashrate
starts
to
drop
from
the
network
because
people
sell
their
gpus,
so
that
would
mean
that
it
would
take
us
longer
to
hit
the
ttd.
So
there's
a
world.
Where
imagine
we
say
okay,
this
is
the
v
value.
We
expect
it
to
hit
in
two
weeks,
but
people
start
to
sell
their
mining
equipment
that
maybe
we
hit
it
in
like
like
three
weeks.
A
Instead
of
that,
because
the
hash
rate
has
has
gone
down
on
the
network
if
it
were
to
go
down
like
to
the
extreme,
you
know
so
say.
Instead
of
two
weeks,
it's
going
to
take
us
like
16
weeks
to
hit
it,
then
we
can
basically
do
another
override
to
another,
even
lower
value
and
and
and
kind
of,
and
and
kind
of,
not
wait
that
entire
time
would
like
to
reduce
security
on
the
network
because
of
a
really
low
hash
rate.
A
For
months
so
yeah,
we
haven't
quite
decided
the
rollout
plan
for
for
maintenance
yet
like
we,
but
but
for
sure,
like
we
want
better
tricks
to
be
activated
well
before
we
hit
the
ttd,
and
it's
usually
much
easier
to
make
sure
that
happens,
because
it's
highly
improbable
that
a
massive
amount
of
hash
rate
just
shows
up
out
of
nowhere
on
a
chain
that
has
like
ethereum's
level
of
hashrate
already.
A
Is
there
any
reason
to
expect
apps
to
have
more
difficulty
with
the
merge
than
any
other
hard
fork,
such
as
fifteen
bit
nine
for
smart
contracts?
No
short
answer,
I
think
for
infrastructure
and
tooling
providers.
A
The
merge
is
probably
a
bit
more
complex
than
than
1559,
especially
if,
like
you,
you
only
cared
about
either
the
beacon
chain
or
the
application
layer
before
so
for,
but
like
for
smart
contract
developers
and
whatnot,
I
I
I
don't
think
it
is,
and
there
were
two
changes
mentioned
earlier
in
the
chat
where
one
is
just
the
block.
Time
goes
from
like
13
seconds
on
average,
to
like
always
a
multiple
of
12
seconds.
A
It's
not
necessary
that
there's
a
block
every
12
seconds,
because
a
validator
might
be
offline,
but
you
kind
of
get
like
a
change
in
like
the
block
time
dynamics.
So,
if
you're
doing
stuff
like
calculating
apys
based
on
the
number
of
blocks
or
stuff
that
will
be
affected
and
then
the
other
thing
is
that
this
difficulty
op
code
changes
to
prevrondow.
A
So
it's
still
a
pseudo-random
value.
So,
if
you're
using
difficulty
for
pseudorandomness
in
your
smart
contract,
it's
still
going
to
keep
working,
the
only
difference
is
the
size
of
the
value
so
off
the
top
of
my
head.
I
think
the
difficulty
value
is
like
two
to
the
64,
whereas
the
prep
randall
is
two
to
the
256.
A
So
that's
the
only
thing
that
kind
of
changes
like
the
size
of
that
return
value,
and
this
is
actually
a
neat
way
to
know
as
a
smart
contract.
If
the
merge
has
happened,
you
can
just
call
this
up
code
and
if,
if
the
return
value
is
like
a
2
to
256
sized,
then
you
you
know
that
you're
in
a
post,
merge
ethereum.
B
Configs
orson:
do
you
wanna
just
read
out
what
you
shared
in
the
chat
for
the
recording
that
question.
C
Yeah
yeah
yeah:
it's
it's
really
dangerous
to
do
that
or
risky
at
least.
C
Read
out
the
question?
Yes!
Okay!
Sorry,
sorry,
sorry,
so
the
question
is
validating
on
the
bc.
I'm
assuming
that
me
speaking
chain
can,
I
simply
stay
on
the
bc
main
net
and
not
try
out
the
test
nets
and
wait
for
the
merge
to
happen
on
mainnet
so
taking
it
literally
sorta
kinda.
Yes,
as
long
as
you
adjust
your
config
to
have
a
fee
recipient
which
is
really
important
and
to
use
the
engine
api,
once
att
has
actually
been
announced
on
mainnet
authenticated
on
typically
port
8551
with
a
jwt
secret.
C
Now
that
sounds
like
a
change
right.
It
is,
if
you
don't
test
that
your
configuration
works
beforehand.
Then
chances
are
your
configuration
won't
work?
If
you
don't
make
these
changes,
you
won't
go
through
merge.
So
you
know
my
recommendation.
Just
is
find
yourself
a
cheap
little
vps
somewhere.
Try
it
out,
learn
how
to
do
this,
how
to
change
your
current
setup
to
one
that
supports,
merge
and
then
make
the
change
on
mainnet
when
it's
time
to
do
so,
not
now.
A
L
So
cat
editors
are
planning
separate
talks
by
different
el
ncl
client
teams,
where
you
can
get
more
information
about
the
latest
specs
already.
We
are
having
a
lot
of
blogs
going
out
from
the
foundation,
but
if
you
have
any
client
specific
questions,
you
are
invited
to
join
the
people
need
tasks
with
different
clients,
or
you
can
also
follow
the
recording
later
on.
Catalytics
youtube
schedule
is
added
in
the
link
here.
B
Yeah,
I
guess
just
generally
like
if,
if
you
are
running
a
validator
and
you
haven't
participated
in
any
of
the
the
other
testaments
like
consu
gear,
kiln,
now
would
be
the
time,
obviously
you're
not
obligated
to
like,
like
thorson
mentioned
you
you
don't
have
to,
but
it's
probably
in
your
long-term
best
interest
to
have
an
understanding
of
how
these
configurations
get
set
up
just
so
you
know
you
have
peace
of
mind
that
you,
you
understand
how
the
merge
is
coming
and
you're
prepared
for
it
and
then,
like
puja
mentioned
those
calls
we'll
probably
run
this
call
at
least
a
few
more
times
before
the
merge
for
for
general
questions
and
and
things
related
to
cadence
or
timing,
just
to
make
sure
we're
getting
that
information
out
there.
B
But
if
you
have
technical
questions,
definitely
start
going
into
the
the
client
discourse
that
they're
going
to
be
the
best
place
where
you
can
get
information
for
technical
troubleshooting
or
the
eatstaker
discord
is
also
a
great
great
resource
as
well.
A
Yeah
and
then
there's
one
final
question,
but
the
I
just
want
to
touch
on
this
test
that
thing
as
well.
I
think
it's
it's
also
worth
noting
that,
like
gordy
and
sepolia
will
probably
happen
like
much
closer
to
the
main
net
merge
than
like
robson,
I
mean
by
definition,
but
also
like
just
in
terms
of
delay,
between
delays
between
them.
So
if
you
are
like
just
waiting,
you
know,
obviously
we
can't.
A
We
can't
force
you
to
to
use
robson,
but
if
you're,
if
you
are
just
waiting
and
and
then
you
you
go
just
on
gourley
and
and
you
realize,
like
you
need
weeks
and
maybe
like
months
to
like
update
your
setup,
then
you
know
we
might
have
scheduled
the
merchant
maintenance
by
then
so
like,
and
I
don't
think
realistically,
you
should
take
anyone
who's
already
running
your
validated
months
to
adapt
to
this.
A
But
yeah
just
note
that,
like
the
delay
will
be
shorter
there
and
yeah
jonas
asks
like
better
articles
about
running
validators.
We
are
working
on
it.
There's
a
bunch
of
different
efforts
on
that
on
on
that
point,
so
yeah
we'll
we'll
have
more
of
those.
A
Definitely
in
the
coming
weeks
and
months
and
then
finally,
there
was
a
question
about
finality
for
transactions,
so
basically
transactions
themselves,
don't
really
have
a
concept
of
finality
it's
more
blocks
and
today
on
proof
of
work,
there
is
kind
of
no
explicit
finality
so
after
the
merge.
Basically,
if
a
transaction
is
part
of
a
block
and
that
block
has
been
finalized
by
the
proof
of
stake
chain,
then
we
consider
it
final
or
finalized
as
well.
A
So
like
the
transaction,
that's
within
that
block
would
be
finalized
and
basically
what
what
that
means
is
for
that
transaction
to
be
re-org
an
attacker
would
be
willing
would
need
to
like
have
control
over
more
than
two-thirds
of
the
state
and
be
able
to
to
basically
write
an
alternate
history
and
and
that's
a
that's,
basically
the
same
same
level,
more
or
less
of
guarantee
that
you
have
under
under
bitcoin
or
under
proof
of
work.
A
Sorry
with
like
a
51
attack,
so
for
all
kind
of
intents
and
purposes,
that's
usually
pretty
final
yeah
and
then
again
this
will
be
exposed
in
the
json
rpc
api.
So
it's
much
easier
for
applications
to
like
actually
query.
What's
the
latest
finalized
block
and
and
and
return
that
information
to
their
users.
B
Yeah
and
I
just
shared
a
link
to
the
google
group
that
we're
running
for
announcements
if
you're
interested
in
getting
notified
whenever
there's
a
new
blog
post
released
about
something
related
to
the
merge
or
ethereum
generally,
but
obviously
these
next
few
months
are
going
to
be
focused
on
the
merge.
B
That's
probably
the
best
way
to
make
sure
you
don't
miss
something,
and
then
obviously
you
know
as
important
milestones
are
reached,
we'll
broadcast
them
on
the
typical
channels
like
twitter,
the
r
d
discord
all
the
client
discords
things
like
that.
H
H
And
if
you
do
so,
please
please,
please
send
them
to
the
client
teams
so
that
we
can
fix
them
and
yeah
make
sure
to
to
to
test
your
setups
make
sure
to
notify
us
if
if
something
goes,
goes
really
wrong,
and
I
think
we
also
increase
the
bug
bounties
and
we
will
also
be
increasing
the
bug
bounties
around
the
merge,
especially
for
like
the
much
ready
software
and
so
yeah.
B
All
right,
if
there's
no
other
questions
or
comments,
thank
you.
Everybody
for
coming,
like
I
said,
we'll,
probably
be
running
this
again
in
the
future
on
a
more
regular
basis.
So,
however,
you
found
this
keep
tracking
those
channels.
I've
been
tweeting
it
a
lot
but
yeah.
Whenever
the
next
one
is
we'll
be
sure
to
announce
it
and
yeah
the
merge
is
coming
soon
tim.
You
have
anything
else.