►
From YouTube: Merge Community Call #3
Description
A
All
right
welcome
everybody
to
the
third
merged
community
call,
there's
been
tons
of
progress
over
the
past
month
month
and
a
half
moving
towards
new
test
nets,
fixing
old
ones
and
we're
going
to
share
a
little
bit
about
that,
and
just
generally
talk
about
what
validators
users
and
the
general
community
can
expect.
When
the
merge
actually
happens,
let
me
grab
the
agenda
again.
A
B
C
One
of
these
things
is
that
the
difficulty
value
gets
replaced
with
the
random
value
from
the
beacon
chain.
So
if
you
are
running
an
application
that
uses
difficulty
as
a
source
of
pseudo
randomness,
this
will
still
work.
It
will
just
be
a
different
random
value
that
we
get,
and
one
thing
to
note
is
that
the
random
value
is
much
bigger
than
the
current
difficult
difficulty
value.
C
If,
if
I
have
the
numbers
right,
I
think
the
current
random
value,
the
current
difficulty
value
is
about
64
bytes
and
the
difficulty
is
256..
So
that's
also
a
neat
way
you
can
check
at
an
app
level
if
the
merge
has
oh
bits.
Sorry.
So
if
the
yeah,
if
the
the,
if
the
value
that's
returned,
I
buy
this
up
code
is
now
256
bits.
It
means
you're
you're
in
a
post,
more
post
merged
world
on
chain
and
that's
one
of
the
big
changes.
C
The
other
changes
anything
else
that
has
to
do
with
proof
of
work.
So
things
like
the
anything
except
the
difficulties
of
things
like
the
mix
hash,
the
the
list
of
uncles
and
whatnot.
Basically,
all
gets
zeroed
out
at
the
application
layer.
The
random
value
is
the
only
one
that
kind
of
gets
added,
replacing
the
current
difficulty
value.
C
C
I
think
if
we
want
to
quickly
like
chat
about
stuff
that
happened
since
the
last
of
these
calls.
So
right
before
christmas,
we
launched
the
kinsugi
testnet,
which
is
basically
a
new
testnet.
That's
running
the
post-merge
version
of
ethereum,
so
it
has
both
a
beacon
chain
on
it
and
an
execution
layer
execute
some
transactions.
C
That's
called
kiln
and
we
expect
kim
to
be
the
last
test
net
that
we
launched
before
forking
the
existing
test
nets
like
gordy
and
robsten
and
whatnot.
So
I
think
one
thing
for
applications.
That's
really
worth
doing
both
on
kimsugi
that's
live
today
and
if
not
on
kinzugi,
absolutely
on
kiln
when
it
goes
live,
is
making
sure
that,
like
your
entire
tooling
workflow
and
deployment
workflow
works,
it
should
and
there
shouldn't
like
and
we've
we've
tried
with
like
a
handful
of
applications
already
and
and
things
kind
of
work
as
expected.
C
But
I
think
you
should
really
see
kiln
if
possible.
Kenzugi
has
like
a
dress
rehearsal
before
the
testnets
fork.
So
if
you
can
deploy
kind
of
a
staging
version
on
that,
there
is
an
and
like
an
infer
sign
forever.
There's
like
an
rpc
endpoint,
you
can.
You
can
just
point
to
you:
don't
have
to
like
run
your
own
node.
C
C
I
think
it's
really
important
to
stress
this,
like
this
is
kind
of
the
time
to
find
out
that,
like
your,
you
know,
your
your
contract
deployment
script
doesn't
work
for
whatever
reason
and
or
your
ui
is
actually
weird
for
whatever
reason
like
these
are
the
things
we're
hoping
to
find
out
a
special
special
eye,
I
think,
is
towards
like
tracing
so
the
applications
we've
we've
deployed
already.
Don't
really
use
like
extensive
tracing.
C
And
oh
and
yeah,
the
the
last
thing.
I
think
that
I
have
is
the
agenda,
the
idea
of
outsourcing
to
a
web3
provider.
Your
execution
client
is
probably
not
going
to
be
possible
after
the
merge.
So
right
now
it
is
possible
if
you
run
just
the
beacon
chain
node
to
outsource
your
kind
of
it's
one,
node
to
to
say
infer
our
alchemy,
because
you're
only
just
getting
kind
of
information
from
the
from
the
deposit
contract.
But
after
the
merge.
C
Basically,
if
you're
a
validator,
you
need
to
produce
blocks
and
you
get
paid
to
produce
blocks,
including
transaction
fees
which
are
like
immediately
available
to
use,
and
so
because
of
that
you
actually
need
to
run
your
own.
Your
own
node
on
the
execution
layer
yeah.
So
that's
something
that
that
people
should
be
should
be
aware
of
in
the
future.
There'll
be
some
cryptographic
incentives
to
to
or
not,
incentives,
but
like
disincentives
to
rely
on
the
third
party.
C
C
Go
ahead,
oh,
I
was
just
going
to
say:
yeah.
We
there
there
are
a
bunch
of
like
ad
hoc
guides
to
do
that
right
now,
like
for
kintsugi,
but
one
thing
we
are
planning
for
like
kiln
is
to
have
a
bit
more
like
detailed
guide
for,
like
hey,
I'm
running
a
beacon
node.
How
do
I
add
an
execution
node
or
vice
versa?
C
If
you
are
running
a
node
on
on
the
proof
of
work,
ethereum
network
today,
you're
gonna
need
to
run
a
beacon,
node
post
merge
to
get
the
head
of
the
chain,
so
we're
gonna,
try
and
just
flesh
that
out
a
bit
more
and
like
what
do
you
actually
need
to
do?
How
do
you
make
sure
that
you've
done
it
right
and
so
on.
A
But
if
you
have
either
staked
in
the
deposit
contract,
you
won't
be
able
to
access
that
or
exit
from
the
beacon
chain
at
the
merge
that
happens
later.
But
as
tim
mentioned,
you
will
get
transaction
fees,
those
will
be
immediately
available
and
actually
I'm
it
was.
The
call
yesterday
paul
from
the
lighthouse
team
was
talking
about
how
you
know
getting
that
process
started
about
how
to
design
the
or
standardizing
the
flow
of
allowing
validators
to
designate
which
address
receives
transaction
fees
from
the
execution
layer.
E
Yeah,
so
the
the
current
spec
allows
for
the
el
to
override
what
it
gets
from
the
consensus
layer.
So
the
consensus
layer
passes
the
the
coin
based
address
to
the
execution
layer,
but
the
execution
layer
like
the
spec,
allows
for
the
execution
layer
to
to
to
ignore
that
and
change
that,
and
so
what
like
might
happen
in
the
future.
If
the
consensus
layer
does
not
provide
an
address,
then
it
might
just
take
the
configured
address
of
the
execution
list.
B
Whether
or
not
it's
possible
to
set
up
multiple
execution
clients
that
are
backups
of
each
other,
so
that
way,
if
you
need
to
upgrade
like
the
os
that
your
execution
clients
running
on,
you
can
fail
over
to
something
else.
And
I
don't
know
if
we
have
the
tooling
for
that
built
anywhere.
Centralized.
B
So
I
don't
think
we
have
someone
correct
me
here,
marius
may
know,
or
timor
trent.
I
don't
think
there
is
any
tooling
that
is
built
by
any
of
the
core
devs
or
anything
for
automatic
failover
from
one
execution
client
to
another.
So
the
idea
here
is:
you
have
one
beacon,
client
and
two
extrusion
clients
in
that
way.
If
you
want
to
turn
one
of
those
execution,
clients
off
it'll
fail
over
to
another
one.
B
B
A
B
G
B
The
other
way
around
is
it
more
difficult
and
from
a
configuration
standpoint,
does
the
user
just
need
to
connect
to
execution
clients
and
point
them
both
at
the
same
beacon,
client?
And
that's
it
like
everything
should
just
work
or
is
there
like
they
will
they
need
to
do
some
sort
of
special
setup
for
like
for
the.
E
A
If
people
haven't
realized
that
we're
moving
into
sort
of
open
discussion,
so
if
anybody
does
have
a
question
that
isn't
addressed
in
the
agenda
or
isn't
coming
up,
naturally
just
raise
your
hand
or
put
it
in
the
chat.
Otherwise,
we
could
talk
all
day
about
random
things.
If
you
don't
bring
it
up,
keep
going
micah.
Whoever
was
talking.
G
Sure,
usually,
most
speaker
nodes
have
a
concept
of
a
failover
rpc,
and
currently
you
can
specify
that
in
a
flag.
So
you
have
your
main
execution
client
and
then
you
have
your
failover
rpc
client.
For
any
reason,
if
the
main
client
is
missing,
then
the
beaker
node
switches
to
the
failover
rpc,
the
same
logic
would
apply
in
the
future.
So
if
you
have
two
execution
engines,
you
should
be
able
to
target
the
main
one
during
regular
functioning
and
the
backup
one
later
on.
G
As
far
as
I
know,
this
is
an
untested
feature
for
the
execution
client.
It's
a
very
stable
running
feature
for
just
deposits
like
right
now
how
it
is
in
the
kitchen,
but
with
the
execution
engine.
I
don't
think
it's
a
really
well
tested
feature
yet,
but
it's
something
that
will
be
tested
by
the
time.
The
march
happens.
B
G
So
I'm
not
sure
of
that
of
that
right
now,
but
I
think
it
should
send
it
to
both
places,
because
currently
the
beacon
node
like
queries,
both
the
failover
as
well
as
the
main
one
to
know
how
many
healthy
nodes
it's
connected
to
at
all
times.
So
I'd
assume
in
the
future.
It
would
just
send
a
set
head
message
to
both
okay,
but
you'd
have
you'd
have
to
ask
cl
dev
about
the
exact
behavior.
A
Thanks
guys
remy
your
question
for
the
recording
I'll,
just
read
it
out:
how
will
validators
choose
the
ethereum
account
for
their
transaction
fees,
go
into
the
transaction
fees
they
will
gain
from
proposing
a
block.
I
think
paul
mentioned
that
when
you
start
up
the
node,
you
will
be
prompted
with
your
users
will
be
prompted
to
enter
an
address,
and
I
don't
think
I
think
what
he
mentioned
was
that
you
won't
be
able
to
move
past
that
without
entering
and
tim
is
unmuted
and
he's
going
to
swoop.
In
with
some
info.
C
Yeah,
so
that's
basically
it
you
need
to
provide
it
to
your
node
upon
startup.
But
one
thing
to
make
clear:
is
you
get
the
transaction
fees
yeah?
You
only
get
the
transaction
fees
and
not
like
any.
I
guess
fee
for
proposing
the
block
itself
so
like
the
the
fee
that
you
get
for
actually
proposing
the
block
accrues
on
the
beacon
chain,
but
then
the
actual
transaction
fees
accrue
on
the
execution
layer.
B
A
B
B
It's
not
a
big
deal,
if,
like
your
whole
country,
goes
offline,
your
country
consists
of
you
know:
50
of
validators,
that's
going
to
cause
all
those
people
to
leak
much
faster,
so
it
really
depends
on
the
specific
scenario.
But
for
the
normal
case,
what
transcend
is
exactly
right:
you're,
probably
not
even
going
to
notice.
H
That's
one
of
the
reasons
why
it's
important
to
not
correlate
yourself
by
using
the
same
software
same
hardware
if
you're
validating
in
the
cloud
same
cloud
providers,
because
if
any
of
those
things
fail
for
a
large
majority
of
the
network,
you're
going
to
leak
a
lot
faster
than
if
you're
using
you
know,
less
than
majority
used.
Software
and
hardware.
F
G
G
If,
for
any
reason,
you
need
to
migrate,
follow
all
the
procedures
for
migration,
but
in
principle
the
slashing
protection
database
make
sure
that
the
validator
doesn't
sign
anything
that
it
could
get
slashed
for.
So
you
don't
have
to
worry.
If
you're
offline
for
a
bit,
the
validator
wouldn't
automatically
get
slashed.
B
Yeah,
just
a
clarification
on
the
terminology
slashing
usually
means
you're
actually
being
actively
penalized.
This
is
different
from
leaking,
so
there's
leaking
and
they're
slashing
so
leaking
is
just
like.
If
you
go
offline,
you
don't
show
up
to
a
test
you're
not
going
to
get
penalized.
You
just
like
fleet
a
little
bit
of
money.
If
that
makes
sense,.
I
Can
I
be
even
more
pedantic
about
the
terminology
here
please,
so
you
are
penalized
for
being
offline.
You
receive
penalties
they're
about
the
same
as
the
rewards
you
would
otherwise
receive.
So
if
you're
offline
for
a
day,
then
you're
back
online
for
a
day
you
end
up.
Even
there
is
a
leak.
This
is
happens
when
the
whole
network
is
not
finalizing
and
that
you
receive
more
severe
penalties
for
being
offline.
So
we
call
that
the
the
leak
specifically
and
then
slashing
slashing
is
punishment.
I
You're
not
punished
for
being
offline,
you're
punished
for
breaking
rules
and
that's
very
severe
you're,
basically
ejected
from
the
network,
and
you
lose
some
of
your
your
stake.
It's
very
hard
to
get
slashed.
You
have
to
be.
You
have
to
screw
something
up
in
your
in
your
setup
to
to
get
slashed.
You're
not
gonna,
get
slashed
in
the
normal
course
of
events.
D
I
Yeah
it
it's
complicated
and
I've
written
about
it
and
I'll
drop
a
url
in
the
in
the
chat,
but
it's
never
happened
on
the
beacon
chain.
So
far,
so
we
have
never
had
a
leak
on
the
on
the
beacon
chain.
In
the
like
13
14
months,
it's
been
running.
It
should
be
an
extremely
rare
condition.
If
you
are
online
80
of
the
time
or
more
during
a
leak,
then
you
end
up
even
you,
you
don't
earn
any
reward,
but
you
don't
get
any
penalty.
D
Thank
you
so
much
just
one
more
clarification
on
that
does
the
validator
have
to
always
re-authenticate
itself
with
its
originating
ip
address,
or
so
I'm
I'm
imagining
some
water
for
load,
balanced
infrastructure
where
you've
got
failover
band
links
where
if
one
goes
down,
you
use
the
other.
Does
that
really
matter,
and
would
it
be
not
too
hard
for
this
thing
to
be
able
to,
you
know,
publish
itself
from
a
different
ip
address.
I
Yeah
ipaddress
is
more
or
less
irrelevant
in
the
gossip
network.
So
yeah
you
can
come
back.
You
may,
if
you
start,
if
you
lose
your
database
and
you
lose
your
ethereum
node
record,
then
you
might
have.
It
might
be
slightly
slower
to
find
new
peers,
but
we're
talking
minutes
we're
not
talking
hours
for
that.
So
basically
yeah.
No,
no
problem
at
all.
B
I'm
going
to
throw
out
something
wrong
here
in
hopes
that
someone
corrects
me,
I
believe,
if
you
want
to
be
very
careful
with
failover
validator
clients,
because
if
remember
correctly,
if
you
have
two
validator
clients
running
on
two
different
machines
and
they're,
both
trying
to
validate
that
is
one
of
the
conditions
where
you
can
get
slashed.
Is
that
accurate.
I
B
Yeah
so
in
general,
the
advice
that
I've
heard
given
out
is
you're
far
better
off
just
running
one
validator
and
eating
the
downtime.
Then
you
are
trying
to
set
up
a
failure
node,
unless
you
are
really
really
really
really
careful
and
so
like
either
spend
you
know,
months
of
engineering
time
to
set
up
failover.
That
is
very
careful
to
never
go
wrong
or
just
accept
that
you'll
have
some
down
time,
because
the
downtime
is
much
less
punishing
than
double
signing.
A
A
A
C
I
Only
to
the
extent
you
don't
get
the
block
reward
or
any
transaction
fees
associated
with
that
so
yeah.
Indeed,
that
would
be
unlucky
to
be
offline
when
you
you're
a
block
proposal,
but
there's
no
penalty
for
being
for
not
proposing
a
block.
You
just
miss
out
on
the
block
reward
and
the
transaction
fees.
A
A
And
just
generally,
I
should
have
mentioned
this
at
the
beginning,
but
if
somebody
can
respond
verbally,
I
know
everybody
is
maybe
not
able
to,
but
if
you
can
ask
or
respond
to
a
question
verbally,
it
helps
because
this
is
being
recorded
and
then
it'll
be
transcribed,
but
the
chat
is
a
little
more
ephemeral
but
yeah.
I
appreciate
everybody
who's,
asking
questions
and
answering
them
in
the
chat
as
well.
A
A
Yep
yeah-
and
this
is
kind
of
related
to
a
bigger
topic
that
concerns
users
like
in
reality,
users,
applications
they're,
not
going
to
notice
any
difference
leading
up
to
at
the
point
of
the
merge
and
directly
after
you
know,
this
is
like
updating
some
sort
of
app
in
the
background,
once
you
open
the
app
it
kind
of
just
works,
you're
not
going
to
really
notice
anything,
the
services
will
continue.
Just
the
same.
A
You
won't
have
to
like
more
broadly
you're,
not
going
to
have
to
transfer
your
ether
to
a
new
chain
you
won't
have
to,
or
if
you're
a
developer
your
contracts
aren't
going
to
have
to
be
migrated.
You
know
what
we're
trying
to
do
is
make
the
make
this
as
seamless
as
possible,
and
you
won't
really
have
to
do
any
sort
of
transition
or
migration.
C
C
That's
probably
a
good
segue
but
like
when
you
see
the
first,
when
you
see
the
first
block
having
been
finalized
on
the
beacon
chain
after,
like
the
last
the
last
book
for
work,
one
is
kind
of
when
you
know
that
the
transition
has
happened
successfully
and
that
this
first
block
is
not
going
to
reorg
and
say
you're
in
exchange.
You
can
kind
of
like
accept
a
deposit
or
like
reopen
deposits
or
whatever
yeah
marius.
C
F
F
E
E
That
164
blocks
have
been
executed
on
top
of
a
block
or
64
slots.
No,
it's
two
times
64
slots
have
been
have
been
passed,
then
the
then
the
block
gets
marked
as
finalized.
So
it's
it's.
It's
not
the
new
block,
the
news
block,
but
it's
some
block
a
bits
further
a
bit
of
time
ago,
but
you
can
always
be
sure
that
this
block
will
not
change
except
for
very,
very
like
yeah.
No
it
will.
It
will
not
change.
So
that's
the
difference
in
in
how
the
new
world
works.
E
You
can
be
sure
that
stuff
doesn't
change,
so
we
make
sure
to
expose
this
behavior
to
the
user,
for
example,
for
for
for
exchanges
to
say.
Okay,
once
a
transaction
has
been
included
in
a
finalized
block
or
the
the
block
that
had
a
certain
transaction
was
finalized,
then
we
will
accept
the
payment
or
whatever
and
so
yeah.
That's
basically,
every
call
that
you
could
specify
pending
or
latest
tool
will
now
also
accept
finalized.
B
C
B
C
B
Yeah
and
the
the
key
here
is
that,
if,
in
order
for
a
reorg-
unlike
with
the
bitcoin
or
proofwork
ethereum
today
or
proof
of
work
networks,
they
can
automatically
reorg,
you
know
back.
If
someone
does
launch
51
attack,
an
automatic
bureau
can
occur
and
the
clients
will
reorg
back.
However
many
blocks
it
can
be
up
to
infinite
or
up
to
genesis.
I
guess
the
caveat
here
is
with
proof
of
stake.
B
We
do
have
the
ability
to
launch
a
user-activated,
hard
fork
which
can
reorg
past
the
finalization
point,
and
this
would
be
in
a
very
extreme
scenario
where
validators
have
been
shown
to
be
actively
attacking
the
network
and
we
want
to
make
sure
they
get
punished
for
it,
and
so,
unlike
proof-of-work,
we
can
in
proof
of
stake.
We
actually
can
punish
validators
after
the
fact.
B
So,
if
we
see
some
evidence
of
malfeasance
by
validators
by
large
chunk
of
validators
that
the
protocol
could
not
identify,
we
can
go
back
and
slash
them
later
now
this
would
be
you
know
talked
about.
This
would
not
be
something
that
just
happens
automatically
again,
unlike
proof
of
work,
none
of
this
would
be
automatic.
This
would
be
a
very
manual
intervention
where
we
tell
users
hey,
please
upgrade
your
clients
that
does
this
roll
back
it'd
be
a
major
thing.
A
E
E
So
if
the
network
breaks
down,
then
nodes
will
use
a
lot
more
disk
space
than
they
use
during
normal
operation,
but
that,
first
of
all
that
shouldn't
happen
on
mainnet
and
second
of
all,
the
teams
are
already
thinking
about
how
to
reduce
reduce
this,
the
disk
space
during
during
times
of
non-finalization
and
yeah.
That's
basically.
A
A
C
Word
of
block,
so
the
block
the
block
rewards.
Basically,
there
is
no
block
reward
on
the
execution
layer
post
merge
right,
like
the
rewards
that
exist
on
the
beacon
change
on
the
beacon
chain,
go
and
change,
so
you
get
today
already
rewards
for
proposing
a
block
on
the
beacon
chain.
You
get
rewards
for
a
testing
two
others
blocks
on
the
beacon
chain,
so
that
stays
the
same
and
then
transaction
fees
on
the
execution
layer
stay
the
same.
So
you
know
every
transaction
on
ethereum
pays
a
fee.
Part
of
that
fee
is
burnt.
C
The
rest
of
the
fee
goes
to
the
block
producer,
and
so
after
the
merge
validators
who
are
block
producers
get
the
sub
of
those
two
things
they
get
their
current
rewards
on
the
beacon
chain
to
the
same
extent
that
they've
already
had
there's
no
like
increase
or
anything
like
that.
It's
still
based
on
the
total
number
of
validators
that
whole
thing,
but
they
also
get
the
transaction
fees
from
the
execution
layer
sent
to
any
ethereum
address
that
they
want.
C
C
A
C
Yeah,
I
don't
think
we're
100
set
on
it
yet,
but
what
seems
what's
going
to
happen
for
sure
is
some
test
nets
will
be
deprecated.
What
seems
likeliest
and
again,
this
could
change.
Is
that
rinkaby
does
not
transition
to
the
merge,
so
rinkeby
seems
like
the
least
likely
test
nets
to
to
make
it
if
your
application
runs
on
rankingb
only.
I
would
strongly
suggest
starting
to
look
at
other
tests.
C
Gordy
seems
very
likely
to
just
transition
and
stick
around
long
term.
So
if
you're,
if
you're
on
gordy,
you're,
probably
good
and
then
finally
there's
a
new
proof-of-work
testnet
that
was
launched
a
couple
months
ago
called
septolia
and
the
the
goal
is
likely
to
transition
sepolia
over
run
the
merge
on
it
and
then
maintain
it
instead
of
robsten,
just
because
it's
a
bit
of
a
newer
test
net
and
it's
it's
less
heavy,
so
pldr,
gordy
and
sapolia
are
looking
like
the
best
candidates.
C
Post-Merge
one
thing
also
is:
there's
testaments
basically
have
two
values.
One
of
the
values
is
like
a
staging
environment
for
applications.
The
other
value
is
like
a
staging
environment
for
client
devs,
and
the
things
you
want
to
test
for
client
devs
are
slightly
different,
like
we'd
like
to
test
our
client
software
in
cases
where
the
network
is
not
not
finalizing,
for
example,
and
things
are,
aren't
going
well
and
that's
obviously
not
great
for
for
applications.
C
You
probably
just
want
to
test
on
like
a
copy
of
mainnet,
so
there's
plans
to
like
make
one
of
the
the
like
post-merge
test
nets,
more
geared
towards
like
client
testing,
where
we
we
regularly
turn
off
some
validators
cause
it
not
to
finalize
make
sure
that
that
the
client
software
can
handle
that
and
then
there's
another
one.
That'll
probably
be
a
bit
more
stable
and
and
where
you
know
you
can
expect
kind
of
similar
situations
to
mainnet.
C
We
haven't
really
made
that
call
yet,
but
it's
it's
probably
gonna
be
you
know.
Gordy
and
septolia
are
likely
to
be
like
one
of
each
yeah.
So
that's
that's
something
we'll
we'll
have
better
information
on
in
the
next
couple
weeks,
but
if
you
are
on
rinkebee,
I
definitely
suggest
looking
looking
at
the
point
of
the
test
nets.
The
other
one
sorry
like
coven
is
the
one
where
I
really
don't
have
a
view.
It's
a
bit
unclear
what
the
situation
is
there.
C
I
know
in
the
past,
they've
lagged
updating
it
until
after
may,
after
mainnet
has
updated.
I
think
there
were
some
plans
updated
for
the
merge,
but
it's
it's
not
fully
clear
to
me
yet
so
I
think
yeah.
If,
if
you
are
just
on
coven,
you
probably
want
to
reach
out
to
like
the
maintainers.
If
it's
to
to
understand
a
bit
better
with
the
with
the
premise
there.
A
If
not,
I
think
those
are
all
the
things
I
noted
from
the
discussion
somebody
asked
about
incentivizing
solo
staking.
I
think
we
touched
on
that
earlier
about
their
anti-correlation
penalties
and
if
you
abstract,
that
or
de-abstract
that
that
would
mean
if
you're
staking
on
the
same
cloud
provider.
You
know
if,
if
the
majority
of
the
network
is
all
on
aws
and
aws
went
down
that
there
would
be
a
pretty
big
slashing
event
or
no,
there
would
be
a
inactivity
leak
and
that's
one
way.
A
Solo
staking
is
incentivized,
there
are
other,
maybe
not
incentives,
but
initiatives
from
people
like
superfiz
and
the
east
staker
community
to
onboard
more
people-
and
you
know,
remy-
has
also
done
some
work
with
guides
and
in
helping
people
understand
the
best
practices
for
running
your
own
validator
guide.
So
there's
a
ton
of
community
work,
that's
gone
into
solo
staking
and
that's.
A
A
B
A
And
this
is
yeah
just
to
be
clear
for
anybody.
Anybody
who's
a
validator
currently
or
is
looking
to
get
into
it
soon.
Prism
and
geth
are
great
clients.
You
know
they've
been
around
for
years.
They
have
great
people
working
on
them.
This
is
nothing
against
those
teams,
but
client
diversity
is
really
really
important
and
it's
not
something
where
we
want
to
like.
A
It's
only
an
issue
once
once
it's
a
problem,
you
know
it's
not
something
where
it's
causing
a
problem
now,
but
it'll
be
an
issue
once
there's
a
failure
to
finalize
or
a
bug
in
one
of
the
majority
clients.
So
we
want
to
take
care
of
the
the
problem
now,
rather
than
down
the
road
when
there's
actually
a
bigger
problem.
A
Anything
else
in
the
chat
yeah
somebody
asked
about
timing
and
marius,
rightfully
answered
it'll
happen
when
it
happens.
Basically,
yeah
there's
a
checklist.
I
don't
have
the
link
on
me
now,
but
maybe,
if
somebody
has
the
tim's
tim's
gonna
get
it
but
yeah
it
it's
hard
to
predict
when
everything
happens-
and
I
know
everyone
is
in
crypto-
is
used
to
things
taking
longer
than
they
seem
that
they
shouldn't
take
that's
kind
of
the
way
it
goes.
But
one
thing
we
want
to
be
really
clear
on
is
that
any
upgrades
are
secure.
A
You
know,
there's
no
bugs,
and
it's
not
going
to
introduce
issues
if
it
if
it
goes,
live
we're
not
testing
in
production,
so
security
and
safety
for
the
chain,
stability.
These
things
are
all
way
more
important
than
hitting
a
certain
deadline.
So
the
the
broader
answer
is,
you
know
the
merge
will
happen
when
it
happens
when
all
the
client
teams
are
comfortable.
When
there's
been
enough,
testing
we've
gone
through
the
transition
enough
times,
and
everybody
is
confident
that
this
is
gonna.
This
is.
A
Through
well-
and
it's
not
gonna
cause
other
issues.
Oh
right,
there's
the
link
yeah
the
things
in
this
readiness
checklist.
Aren't
you
know
it's
not
like.
They
all
have
equal
weight,
so
take
that
with
a
grain
of
salt,
but
it's
a
pretty
it's
a
good
way
to
get
an
overview
of
the
things
that
are
being
worked
on
a
bunch
of
great
links
to
the
work
and
what's
left
so,
if
you're
interested
in
timing.
This
is
probably
your
best
bet
for
understanding
when
the
merge
is
actually
going
to
take
place.
C
Well,
yeah,
so
one
thing
I'll
post
this
in
the
agenda
as
well,
but
frederick
at
the
ef
has
helped
set
up
a
google
group
that
people
can
subscribe
to
to
get
like
blog
posts,
announcements
about
the
merge,
so
we
will
post
everything
on
blog.ethereum.org
and
I
think,
there's
already
rss
feed.
So
if,
if,
if
you're
on
rss,
you
can
use
that,
but
if
you
just
want
to
get
like
a
simple
kind
of
digest
of
the
the
upgrade
news
related
to
the
merge.
C
Let
me
share
the
link
in
the
chat
here.
We'll
make
sure
there
won't
be
more
than
the
blog
post,
but
you'll
get
an
email
saying:
hey,
there's
a
new
blog
post
yeah.
So
you
can
just
join
here
if
you're,
not
using
google
or
gmail,
you
can
just
if
you
send
an
email
to
this
email
that
I
posted
at
announcements
plus
subscribe
at
ethereum.org
it'll
reply
back
and
ask
you
to
subscribe.
It
did
go
on
my
spam,
the
first
time.
So
please
check
that.
C
A
I
Can
I
just
clarify
that
the
trend,
if
you're
staking
then
the
encouragement
is
to
run
your
own
execution?
Client
infuria
is
undecided
about
whether
they'll
provide
that,
but
that's
by
the
buy,
if
you're
staking
run
your
own
client.
If
you
are
running
a
dap
and
you're
providing
a
service,
and
you
just
hook
into
the
normal
one
apis,
you
don't,
you
can
just
carry
on
using
infuria
or
alchemy
or
whoever
you
use.
As
you
always
have
done,
you
don't
need
to
get
involved
with
this
side
at
all.
I
A
B
So
the
thing
that
we've
been
talking
about
in
the
chat
the
regard
to
unsafe,
head
and
safe
head
so
when,
by
the
time
the
merge
goes
live
the
expectation
is,
is
that
when
you
ask
for
the
latest
block,
you
will
get
what's
called
the
safe
head
and
the
safe
head
is
about
12
12
seconds
behind
real
time,
ish
12
16
seconds.
Something
like
that.
So
just
be
aware,
you
can
ask
for
unsafe
head,
but
unsafe,
head
is
very
like
is
likely
to
get
reworked
so
be
prepared.
B
So
if
you
ask
for
unsafe
head,
I
don't
think
json
rpcs
are
available
yet,
but
eventually
before
the
merger
should
be,
you
have
to
run
safehead
that'll,
give
you
the
absolute
latest
and
greatest.
So,
if
you're,
like
someone
doing
mev
or
something
where
you
absolutely
need
to
know
exactly
the
latest
things
going
on,
you
can
get
that
just
be
aware.
That
is
likely
to
get
reorg
like
high
probability.
B
If
you
ask
for
the
safe
head
or
latest
what
you're
used
to
getting
you're
now
going
to
get
blocks
a
little
later
than
you
do
currently
so
they're
going
to
be
delayed
by
12
16
seconds
or
so,
and
but
the
on
the
plus
side,
it
is
very
unlikely
that
those
will
get
reorganized
like
they'll,
only
get
reorgan
very
bizarre
scenarios.
In
almost
all
cases,
it's
probably
going
to
stick
around
to
finalization,
so
just
be
aware
that
things
are
going
to
get
a
little
slower.
B
A
Great
yeah
somebody
asked
where
this
will
be
recorded
or
where
the
recording
will
be
hosted
and
it
will
be
on
the
ethereum
cat
herders
youtube,
where
the
other
calls
have
been
uploaded
and
I
think
we've
been
producing
notes
for
all
of
them.
So
if
you'd
rather
read
this
then
listen
to
it
it'll
be
available
on
one
of
the
the
repos
that
we'll
link
to.
A
As
a
final
final
note,
if
anybody
on
the
call
was
looking
and
looking
to
get
into
validating
on
their
own
or
just
curious
about
proof
of
stake
generally,
they
want
to
learn
more
about
participating
in
consensus.
I
cannot
recommend
superfiz
and
the
eaststaker
community
more
than
I
can't
recommend
them
enough.
You
should
definitely
check
them
out.
They've
done
great
work.
Like
I
mentioned
earlier,
you
know
creating
tutorials,
helping
people
understand,
what's
required
of
them,
and
yeah
definitely
get
involved
with
that
community.
They're
amazing.
J
Yeah
thanks,
I
I
does
my
audio
even
work.
I've
spent
the
past
hour
fighting
with
with
my
audio
so
yeah.
It's
it's
great
to
be
here.
I
can't
wait
to
go
and
catch
up,
but
yeah,
so
easttaker
tries
to
be
a
welcoming
first
and
knowledgeable
second
community
and
that's
a
really
weird
thing
for
a
lot
of
technical
people,
but
we
really
just
want
to
welcome
people
and
help
them
feel
comfortable
getting
into
staking.
A
Yep
and
as
as
marius
mentioned,
we
are
more
than
happy
to
have
anybody
help
us
test
the
merge,
and
that
just
means
you
know
joining
the
test
net
breaking
things
where
they
can
be
broken
and
then
telling
marius
how
you
broke
it.
So,
if
you're
interested
in
helping
with
that
join
the
ethereum
r
d
discord,
if
you
need
a
link
to
that,
just
dm
me
on
twitter
and
I
will
I'll
send
you
a
an
invite
link.
I
don't
have
it
on
hand
right
now,
but
yeah.
Thank
you
again.
Everybody
for
coming.
E
So
also
also,
if
you're
a
depth
developer,
deploy
your
step
on
the
test
net
to
see
if
the
dap
works,
like
the
the
smart
contract
should
like
there
shouldn't
be
a
problem
there,
but
also
check
out,
if,
like
your
back,
end
works.
If,
like
we
make
some
changes
to
how
the
the
header
works
and
stuff
like
this,
so
it
would
like.
I
would
advise
any
project
to
deploy
their
code
and
also
test
it
with,
with
their
back
end
on
the
new
testnets.