►
From YouTube: Merge community call 7
Description
A
A
B
Sure,
yeah
so
good
morning
or
afternoon,
everyone
yeah
like
currently
saying
this
is
gonna,
be
the
last
of
these
community
calls
hopefully
under
something.
I
went,
it's
really
bad
with
emerge,
but
yeah.
I
I
think
we
were
safe.
That's
the
last
one.
I
guess
there's
two
things
that
I
think
are
worth
highlighting
today.
The
first
is
that,
yes,
we
had
bellatrix
go
live
yesterday
and
we'll
have
the
actual
transition
happen
sometime
next
week
in
order
to
track
that,
there's
a
bunch
of
different
websites.
B
I've
personally
been
using
bordell.wtf
to
track
it
so
because
we
use
the
value
we
we
we
can't
have
a
specific
time
for
when
the
merge
happens,
but
it's
roughly
looking
like
it'll
be
late
utc
on
on
wednesday,
since
first
announcing
kind
of
the
the
actual
ttd
and
and
merge
releases
a
lot
of
the
execution
layer.
Client
teams
have
put
out
new
releases
that
either
fix
some
bugs
or
have
just
some
suggested
improvements.
B
So
if
you
are
writing
a
node,
it's
worth
having
one
more
look
at
the
blog
post
and
and
seeing
if
you're
on
the
latest
version
of
your
client,
and
if
not,
you
can
kind
of
look
at
the
release,
notes
on
the
client
you're
using
and
and
determine
whether
you
want
to
upgrade
so.
This
is
mostly
for
the
consensus
sort
of
mostly
for
the
execution
layer
clients.
B
So,
yes,
please
have
a
look
at
the
post
at
the
post
itself
and
and
kind
of
make
that
call,
and
then
thirdly,
this
morning
literally
minutes
before
this
call,
we
put
out
another
blog
post
about
the
test
net
shutdown.
So
several
months
ago
we
announced
that
killed,
robsten
and
rinkeby
are
deprecated,
with
the
merge
and
kill
was
scheduled
to
be
shut
down
when
the
merge
happens,
and
so
this
is
what
will
happen
so
next
sometime
next
week
that
test
net
will
be
shut
down.
B
Obviously
it's
kind
of
you
know
impossible
to
like
fully
shut
down
a
test
net.
Anyone
can
still
run
a
note
on
it
if
they
want
so
by
shutdown.
What
we
mean
is
kind
of
the
nodes.
The
boot
nodes
run
by
client
and
testing
teams
will
be
turned
off
and
then
infrastructure
providers
will
likely
stop
supporting
that
network
as
well.
And
so
you
know
you
can
still
run
a
node,
but
it
might
be
much
harder
and
if
you're,
an
application
or
user
who
just
wants
a
test
net
to
use,
that's
a
smooth
experience.
B
B
That
said,
we've
heard
already
from
like
several
infrastructure
providers
that
they're
gonna
stop
supporting
or
kind
of
gracefully
shut
down
support
for
robson
and
rinkeby,
so
that
might
also
mean
just
less
functionality
and
stuff
like
that.
So
if
you're
using
any
of
kale
and
robson
and
rankibi,
I
highly
suggest
you
move
to
gordie
or
sepolia.
B
Those
two
are
are
very
much
intended
to
be
supported
long
into
the
future
and
hello
to
all
the
mcon
people
traveling
in
it's
pretty
neat
to
see
the
room
they're
slowly,
filling
up,
hey
yeah,
so
those
are
those
are
the
three
things
I
had.
Oh
and
yeah.
I
guess
actually
one
last
quick
last
one
if
you
do
want
to
watch
the
merge
happen,
eat
steak
here.
Bank
class,
cat
herders
and
a
bunch
of
others
are
organizing
a
community
call
livestream
when
the
merge
is
happening.
B
B
A
A
A
B
No
yeah
I'll,
say
you
know
it's
very
possible
that
we
see
some
minor
issues
when
the
merge
happens.
Like
you
know,
we
saw
in
bellatrix,
there
was
like
a
a
short
drop
in
participation
rates.
I
think
we
expect
those
things
to
happen
and
and
we'll
we'll
deal
with
them
as
they
come
and
yeah
like
the
way
a
theorem
is
designed
like
it's.
It's
made
to
operate
in
very
imperfect
conditions,
and
so
I
think
we
don't
need
100
of
nodes
to
update
exactly
perfectly
for
this
to
work.
B
Obviously
we
want
to
get
us
as
high
as
we
can,
but
if
we
see-
and
I
suspect
we'll
see
some
minor
issues
on
the
day
of
you
know
myself
and
others
will
kind
of
chase
those
down
and
and
make
sure
they
get
fixed.
But
yeah
like
we
did
on
bellatrix
and
and
bellatrix
is
basically
back
to
the
pre.
Sorry
like
we
did
on
the
beacon
chain
and
and
the
beacon
chains,
basically
like
the
pre-bellatrix
levels
of
at
the
stations
and
participation,
so
yeah,
I'm
I'm
feeling
good.
A
Yeah
I'll
also
share,
given
we
have
a
little
bit
of
extra
space
here
check
out
that
link.
I
just
put
in
the
chat
it's
a
compilation
of
a
bunch
of
responses
from
core
devs,
including
their
summary
of
their
feelings,
leading
up
to
the
merch,
and
you
can
find
out
if
people
are
scared.
In
those
comments.
B
Okay,
so
there's
a
good
question
about
exchanges
and
mining
pools
and
whatnot
and
like
ensuring
user
safety
during
the
merge
and
so
for
mining
pools.
It's
it's
obviously
like
a
bit
different
because,
like
I'm,
not
a
my
pool
operator,
but
I
suspect
what
I
would
do
if
I
was
one
is
something
like
you
want
to
mine
all
the
way
up
to
the
last
block
and
you
know,
distribute
those
rewards.
B
So
I
think,
if
you're
a
mining
pool
mining
all
the
way
up
to
like
the
last
proof
of
work
block
making
sure
that,
like
the
chain,
has
finalized
and
has
come
to
consensus
on
that
last
proof
of
work
block
before
sending
out
your
rewards
is
a
smart
thing
to
do.
Similarly,
for
an
exchange,
you
know
exchanges
do
this,
every
network
upgrade,
but
they
typically
pause,
withdrawals
and
deposits
just
to
make
sure
that
the
chain
has
settled.
So
if
again,
I
was
operating
in
exchange.
I
would
do
this.
B
There
might
you
know
if
any
issue
come
up
you'd
much
rather
have
deposits
of
withdrawals
halted
and
then
for
non-censoring
any
boost
relays.
There's
an
answer
in
the
chat
around
blocks
route
manifold
as
well
said
they.
They
were
working
on
one,
but
it's
unclear
if
it's
if
it's
released
yet
so,
there's
some
links
in
the
chat
there
risks
if
risks
risks.
If
the
hash
rate
stops
to
go
down,
the
hash
rate
starts
to
go
down.
So
basically,
if
it
goes
down
a
little
bit,
not
much
happens.
B
You
know
the
merge
just
happens
later
than
expected.
We
reach
the
terminal
total
difficulty
later
over
the
past
handful
of
days.
It's
actually
gone
up
a
bit
so,
but
it
might,
it
might
go
down
in
the
next
couple
days.
You
know
so
if
we
reach
the
merge
on
like
the
17th
rather
than
the
14th
we'll
do
nothing
we'll
just
wait
an
extra
three
days
if
there
was
a
world
where
say
for
whatever
reason,
50
of
the
hash
rate
drops
overnight,
which
is
very
unlikely
or
you
know
it.
B
It's
just
like
10
a
day
over
the
next
week
or
something
like
that.
It
just
makes
it
that,
instead
of
reaching
ttd
on
like
the
15th
or
17
were
like
you
know,
say
a
month
out,
then
we
could
coordinate
a
ttd
override,
which
is
like
we
did
on
some
of
the
test
nets,
where
we
just
choose
a
lower
ttd
value
and
put
out
new
client
releases
with
it,
and
that
coordination
you
know,
choosing
the
value
putting
out
the
releases
getting
everyone
to
upgrade
usually
takes
at
least
like
a
week.
B
So
it's
not
worth
doing
if
the
hash
rate
is
not
dropped
enough
to
delay
things
by
over
a
week,
but
if
we
saw
that
it's
dropped
enough
to
delay
things
by
say
a
month,
especially
in
the
case
where,
like
it
dropped
below
like
50
or
something
and
there's,
maybe
these
weird
scenarios
where
there
could
be
like
a
51
percent
attack.
If
that
hash
rate
came
back
online
client
teams
would
probably
decide
to
just
change
the
tpd
and
and
do
an
override.
But
it's
not
looking
like.
That's
that's
going
to
happen
mika.
A
B
B
So
that
means
that
if
you
use
infera
post
merge
as
your
el,
you
won't
be
able
to
produce
a
block
and
and
to
verify
blocks
that
are
being
produced
by
the
networks,
so
it
would
be
kind
of
strictly
worse
in
terms
of
like
potential
rewards.
Obviously
it
might
be
lower
cost
to
do
that,
but
I
it's
not
something
infrared
has
like
mentioned
to
us.
B
A
Regular
node
operators
it
had
will
become
much
more
expensive
and
the
reason
for
this
is
twofold:
when
you
have
to
run
two
clients
is
more
operationally
complex,
but
two.
You
need
to
retain
receipt,
history
and,
I
believe,
block
header
history
and
I
maybe
block
body
which
I
don't
know
on
that
one.
Whereas
previously
you
could
run
like
a
number
of
the
different
clients
allowed
you
to
prune
history
in
order
to
save
space,
so
you
could
run
it
on
like
150
gigabytes
of
disk
right
now.
A
You
need
like
six
or
seven
hundred
gigabytes
for
the.
I
think
the
smallest
node
requires
like
six
hundred
dollars
now:
okay,
okay,
so
there
are
a
number
of
people
who
previously
could
run
a
node
and
now
cannot
run
a
node
and
so
there's
discussion
on
maybe
trying
to
fix
this,
but
there's
no
eta
on
on
fixing
it
but
yeah.
I
I
personally
do
suspect
that
there
will
be
some
number
of
users.
I've
seen
people
frustrated
with
the
change
and
some
people
giving
up
and
running
nodes
because
of
this
yeah.
B
So
I
think,
like
yeah,
so
short
answer
is
like,
of
course,
if
the
requirements
increase,
less
people
will
run
the
nodes
and
the
questions
like
by
how
much
I
think
you
know,
client
teams
are
working
on
ways
to
like
optimize
that
I
know
you
know
the
get
team
and
I
believe,
a
while
back.
Eragon
was
working
on
a
way
to
like
run.
You
know
a
beacon
like
client
in
parallel
and-
and
I
know
that
the
cl
teams
have
worked
on
ways
to
like
optimize
the
storage
as
well.
B
So
I
suspect
over
time,
like
the
the
overhead
of
running,
both
is
something
that
will
work
on
minimizing,
but
for
sure.
In
the
meantime,
in
the
meantime,
if
there's
more
overhead,
then
it
means
less
people
might
be
able
to
run
this,
and
so
they
might
use
something
like
or
alchemy.
Unfortunately,
yeah.
B
B
So
you
know
there's
probably
some
minimal
effect
and
if
I
don't
know
if
it's
showing
up
in
block
times
yet,
but
it
might
show
up
and
say,
mining
rewards
every
hundred
thousand
blocks
it
increases
so
and
the
merge,
I
suspect,
is
going
to
happen
last.
I
check
it
was
like
something
like
40
000
blocks
at
the
current
difficulty,
so
wherever
the
difficulty
bomb
is
kind
of
at
now,
it's
likely
that
it
will.
B
B
Okay,
so
there's
some
discussion
in
the
chat
there's
some
questions
in
the
chat
about
about.
Basically
this
history,
storage
and
whatnot,
a
question
about:
what's
the
lightest
weight,
non-validating
home
node
setup,
I
don't
have
the
exact
answer
here.
I
don't
know
if
someone
on
the
call
has
an
answer.
B
C
A
C
Yes,
I
think
yeah
so
yeah
it
it
did
go
well.
The
only
issues
we
saw
was
with
one
teku
aragon
note,
but
that
was
my
mistake.
I
didn't
clean
the
machine
properly
earlier,
so
it
had
some
stale
data
and
aragon
basically
thought
it
was
on
the
old
shadow
fork
rather
than
the
new
one,
whereas
the
beacon
no
thought
it
was
on
a
new
one,
and
it
just
was
unhealthy.
C
B
Fred
has
a
question:
what's
the
best
public
dashboard
to
follow
during
the
merge,
so
I
think,
unless
you're,
like
monitoring
your
own
nodes,
the
first
thing
you
probably
like
beacon
chain
has
a
bunch
of
charts.
They
usually
lag
a
little
bit,
unfortunately,
but
I
think
that's
probably
the
best
public
one
on
the
live
stream.
B
I
suspect
people
will
be
sharing
their
screens
and
looking
at
like
more
granular
monitoring
as
well,
so
the
live
stream
we
mentioned
earlier,
we'll
probably
have
some
better
or
like
more
recent
data
and-
and
basically
I
think
the
first
thing
you
were
looking
at
is
like.
Does
the
network
finalize
on
the
other
side
and
that
basically
tells
us?
You
know
over
two-thirds
of
the
validators
agreed
on
on
the
merge
block
and
the
transition
and
we're
coming
checking
along
that's
a
very
low
bar
for
success.
B
I
think
the
second
thing
we
look
at
this
participation
rate,
so
it's
like
you
know,
between
two
thirds
and
a
hundred
percent.
How
many
validators
are
still
are
still
doing
all
their
duties,
and
I
think
from
that
you
know,
there's
a
bunch
of
other
kind
of
secondary
metrics,
we'll
start
looking
at
one,
I'm
particularly
curious
to
see
myself
is
like
fee
recipients,
you
know,
are
there
cases
where
we
can?
We
can
tell
that
like
large
validator
sets
have
not
or
or
miss
set
their
fee
recipient.
B
I
think
you
know
from
there
it
it
becomes.
You
know
it
becomes
much
more
cases
where,
like
you
know,
the
network
is
coming
is
going
along,
we
haven't
lost
any
throughput
and
whatnot,
and
it's
more
about
like.
Are
there
specific
operators
that
that
are
having
issues
or
or
do
we
see?
You
know
we
might
see
some
issue
with
a
specific
client,
combo
and
trying
to
to
try
and
grade
those,
but
yeah
beacon
chain
has
some
some
good
dashboards.
That
will
give
you
this
high
level
information.
B
B
B
There'll
be
a
full
transcript
as
well.
Usually
the
transcripts
lag
by
a
couple
days.
So
if
you,
if
you
want
to
get
the
info
before
the
merge,
I
recommend
in
this
case
actually
watching
the
recording,
because
you
might
get
the
transcripts
like
next
monday,
which
might
be
like
24
hours
or
something
before
the
merge.
B
How
many
validators
do
you
think
will
run
lbv
boost
after
the
merge?
I
don't
know.
I
know
some
sticky
pools
have
like
made
commitments
to
run
specific
like
specific
mev
instances,
and-
and
so
I
I
suspect
you
know-
they'll-
probably
be
a
couple
of
like
the
larger
chunks
of
validators
that
end
up
running
it,
but
I
don't
know
for
all
the
staking
pools.
B
C
C
C
I
think
the
only
thing
they
recommend
is
that
you
don't
run
too
many
validators,
but
if
you
just
have
a
handful,
it
should
be
fine
and
they
were
testing
a
different
board
rocks
something
if
I'm
not
wrong,
it's
supposed
to
be
a
lot
more
powerful
overboard
compared
to
raspberry
pi,
and
it
had
some
different
architecture
that
allowed
you
to
have
better
ssds
connected
to
them.
I
know
there
would
like
a
lot
of
advantages
to
using
that
one
so
talk
to
them.
They
should
be
the
best
people
to
help
with
this.
B
Yeah,
it's
pal
question.
I
don't
have
strong.
I
guess
you
know.
The
only
strong
opinion
I
have
about
these
is
that
if
you're,
a
user,
you
should
try
and
figure
out
whether
like
the
chain
you're
interacting
us
is,
is,
is
safe
in
a
way
and
like
there's
many
ways,
you
can
look
at
that
and
there's
many
things
that
people
forking
ethereum
can
do
in
order
to
make
things
safer.
B
And
basically
you
know
one
of
the
the
very
obvious
ones
is
just
like
replay
protection
like
if
you
make
a
transaction
on
a
chain
you
want
it.
You
want
it
to
ideally
not
be
able
to
be
replayed
on
another
network
so
that
you
know
the
transaction
you're
only
making
one
transaction
when
you
think
you're
making
one
transaction
to
me
personally,
that's
like
the
very
minimal
bar
of
like
safety-
and
you
know
some
of
these
chains
like
these.
These
potential
forex
have
not
then
this
this,
like
very
basic
technical
thing.
B
So
you
know
my
thoughts
on
it
is
like
none
of
these
forks
have
released
software.
That's
at
the
very
minimum
bar
of
secure
for
users
doesn't
mean
that
they
can't
do
it.
Doesn't
mean
that,
like
they're
not
free
to
fork
the
network
but
yeah,
that's
my
rough
feeling
is
like
so
far
everything
we've
seen
from
them
has
been
like
very
subpar
in
terms
of
quality.
B
B
A
B
B
B
B
B
Sorry,
so
those
are
two
different
things,
so
two
epochs
should
happen
if
we
have
at
least
two
thirds
of
clients
updated
and
and
participating
as
expected,
and
so
that's
that's
kind
of
the
very
minimal
bar
means.
The
merge
has
happened
and
we're
we're
kind
of
finalizing
on
the
network,
but
it
could
mean
that
we
have
up
to
a
third
of
the
network.
That's
not
operating
correctly
and
obviously
we'd
want
to
figure
out
what
the
issue
is.
Is
there
and
fix
it?
So
you
know
it
could
be
a
broken
client.
B
B
Okay,
so
yeah
yeah,
so
there's
a
question
about
basically
block
times
and
how
it
impacts
protocols
that
might
use
time
that
might
use
this
to
calculate
annual
interest
rates.
So
the
thing
is
on
proof
of
work.
Timestamps
are
very
like
malleable,
so
sometimes
protocols
don't
use
the
time
to
calculate
annual
interest
rates.
Instead,
they
use
like
the
number
of
blocks
they
make
an
assumption
about.
You
know
how
many
number
of
blocks
there's
in
a
year
and
they
kind
of
go
from
there.
B
So
if
we
just
very
naively
go
from
13
second
to
12
seconds,
it
means
there's
more
blocks
in
a
single
year.
So,
if
you've
been
using
that,
if,
if
you've
been
using,
that
kind
of
proxy
of,
like
you
know
a
year,
divided
by
13
seconds
to
count
the
number
of
blocks
of
the
year
now,
you
probably
want
to
use
12..
B
None
of
those
are
like
perfect
proxies
because
the
13
seconds
you
know
we
have
stuff
like
the
difficulty
bomb
that
shows
up,
and
it's
it's
only
like
a
rough
average
and
then
the
12.
Second,
we
have
things
like
validators
being
offline,
which
could
which
could
cause
some
slots
to
be
missed.
We
see
this
less
than
like
less
than
one
percent
of
the
time
right
now.
B
So
you
know
if
you
are
using
number
of
blocks
as
a
proxy
for
time,
you
should
double
check
those
calculations,
and
the
thing
that's
also
worth
noting
is
that
post
merged
timestamps
are
actually
a
reliable
indicator
of
time,
so
the
time
stamps
will
indicate
the
time
stamps
on
the
execution
layer
indicate
kind
of
the
start
time
of
the
slot.
So
if
you
just
want
to
like
straight
up
use
time
for
your
calculation,
you
can
do
that
in
a
more
reliable
way.
Post
merge.
B
Okay
and
then
there's
an
article
about
about
more
details
around
network
finalization,
so,
okay,
any
particular
hack
concerns
closer
to
the
merge
events.
So
the
thing
the
thing
with
the
merge
is
basically
like
the
execution
layer
itself
doesn't
really
change
much
right.
There's
one
op
code
that
changes
so
in
terms
of
like
smart
contracts
being
hackable.
B
There's
not
really
a
ton
that
you're
you're
introducing
here
like
it's
not
like
we're,
adding
some
new
up
codes
and
they
can
be
used
in
the
way
that
was
previously
unusable
and
kind
of
affect
the
the
outcome
of
of
transactions
and
that's
by
design
right
like
you,
don't
want
the
merge
to
require
upgrades
from
applications.
So,
ideally
you
shouldn't
change
the
behavior
on
applications.
So
I
think
at
that
level,
like
that's,
not
something
we're
concerned
about.
B
You
know
I,
with
regards
to
stuff
like
bridges
and
oracles
and
whatnot
that
kind
of
feed
in
to
like
you
know
that,
like
report
data
back
to
the
chain,
that
becomes
very
much
like
an
infrastructure.
A
great
question
again
where,
like
you
know,
oracles
should
also
upgrade
their
nodes
and
they
should
make
sure
they're
on
the
right
chain,
but
that's
something
they
must
do
every
every
hard
fork
right
yeah.
B
Not
like
you,
you,
you,
don't
have
a
strong
guarantee
that,
like
the
chain
you're
on
wall
pre-org
as
even
more
so,
if,
if
yeah
your
view
of
the
network
drops
below
50.
So
if
you
are
say
like
an
exchange
or
something
or
someone,
none,
even
just
a
user,
you
know
who's
settling
in
an
off-chain
transaction
or
selling,
a
transaction
which
has
some
off-chain
implications.
You
just
can't
be
sure
that
this
won't
reorg,
whereas
once
once
a
block
or
once
an
epoch
gets
finalized.