►
Description
Topics covered
-----------------------------
1:22 - Guests introduction
1:47 - Plan
2:31 - Merge transition - Ethereum today
5:10 - Bellatrix, Consensus Layer
11:30 - Paris, Execution Layer
16:22 - Merge transition
18:55 - Terminal total difficulty vs. block number
24:07 - TTD hits before Bellatrix
30:18 - TTD override
31:50 - Merge rollout
33:38 - Questions
34:21 - How confident devs are that we do not have to do TTD override for the mainnet Merge?
41:30 - What would be the difference in activation time in terms of hrs./days/weeks between Bellatrix & Paris.
46:01 - Is it simple or difficult to estimate the activation time?
47:46 - PoS post Merge
47:58 - Client diversity
50:50 - Running a node
52:34 - Saving the Planet
53:02 - Ultrasound money
53:30 - Priority fees
54:05 - Block confirmations
55:10 - Finalized and safe blocks
56:30 - RANDAO
56:45 - Stable block times
57:30 - Transaction fees
57:57 - Withdrawals
58:15 - Proof of Execution
58:50 - Resources
59:40 - what if a beacon chain validator goes offline for any reason just before the transition and gets online after the merge has already occurred on the mainnet? Can the validator get back on the right chain? Is there any penalty/slashing proposed for such validators?
Resources:
-----------------
Slides: https://docs.google.com/presentation/d/1g5pTIVNuiVU0h654_jTQbwcZ0RbcsL-CNOMuCmzfbk8/edit?usp=sharing
EIP-4399 with Mikhail Kalinin - https://youtu.be/wwfOqmCbPNU
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
EIP-3675 with Mikhail Kalinin - https://youtu.be/zNIrIninMgg
The Merge playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
-----------------------------------------------
Mikhail Kalinin @mkalinin2 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
The
merge
upgrade
where
ethereum
blockchain
will
fully
switch
its
consensus
mechanism
from
proof
of
work
to
proof
of
stake
is
on
the
horizon.
Many
curious
cats
are
looking
for
information
on
the
transition
process,
so
ethereum
cathode
is
bring.
The
merge
special
series.
Welcome
to
p
penny
episode.
73,
I'm
your
host
fujaranjan
and
with
me
today
is
a
very
talented,
edm
developer,
mikhail
kalanin
mikel
is
a
co-author
for
two
merge,
eips
and
co-contributor
of
execution
engine
specs
about
a
year
ago.
A
B
B
B
B
B
How
does
it
look
like
and
as
we
as
we
as
we
know,
we
have
like
the
well
known
the
mainnet
and
the
mainnet
is
basically
the
the
ethereum
is
basically
the
execution
layer
chain
secured
by
the
proofwork
consensus
mechanism.
So
we
have
this
like
kind
of
like
new
term
here,
the
execution
by
a
chain.
It's
it's
very
important
to
have
this
term
alongside
the
other
term,
the
consensus
layer
chained
to
reason
about
the
merge.
B
So
we
have
the
execution
layer
change
secured
by
the
proof,
work
mechanism
and
on
the
other
side,
we
have
another
chain
which
is
called
the
beacon
chain,
which
is
basically
the
consensus
layer
chain
for
for
the
for
the
new
ethereum
for
the
ethereum
after
the
merge.
So
this
chain
is
the
proof-of-stake
consensus.
B
It
represents
the
proof-of-stake
consensus,
a
novel
consensus
mechanism
that
will
be
used
post,
merge
and
the
merge
basically
is
the
hot
swapping
of
the
consensus
mechanism
from
proof-of-work
to
proof-of-stake,
which
will
bring
these
two
chains
together
and
as
we
we
are
having
a
deal
with
the
two
chains.
There
are
two
hard
works,
basically
hard
forks
on
each
of
these
chains
to
be
happened.
B
To
make
the
transition
to
the
proof
of
stake,
so
these
the
names
of
these
two
card
works
are
belatrix,
which
is
the
consensus
layer
chain
upgrade
and
the
paris
which
is
the
execution
layer
chain
upgrade
and
the
bellatrix
follows
the
beacon
chain,
hard
fork,
name
annotation,
which
is
the
name
of
star
and
the
stars.
Names
of
the
star
stars
are
used
for
the
beacon
chain.
Hard
forks.
B
Paris
is
the
name
of
the
city.
Obviously,
and
it
follows
the
the
main
net
work
names
notation.
So
that's
the
distinction
between
the
two
and
the
order
of
these
hard
forks
in
the
context
of
the
merge
transition
does
matter.
We
will.
We
will
speak
about
it
in
the
next
slide,
and
so
the
first
one
that
is
about
to
happen.
The
first
one
that
is
coming
is
the
belatrix
upgrade.
B
So
we
will
speak
about
the
electrics
right
now,
so
this
belatrix
is
the
consensus
layer
upgrade
that
basically
prepares
the
beacon
change
for
the
merge
so
before.
I
think
it
makes
sense
to
say
a
couple
of
words
how
the
consistently
upgrades
are
happening,
how
people
can
change
how
it
works
happening
so
yeah
and
for
the
people
who
are
familiar
with
the
mainnet.
You
know
that
the
hard
works
are
triggered
by
reaching
the
certain
block
number,
but
on
the
beacon
chain.
There
are
no
notion
of
block
numbers.
B
There
are
slots,
because
the
beacon
chain
is
a
time-sensitive
system
and
it
has
its
logical
clock
which
are
highly,
which
are
tightly
coupled
to
the
real
clock
and
yeah.
This
the
the
slots
are
basically
the
the
atomic
measure
of
the
the
kinchin
time
and
the
big
train,
hard
forks
that
happen
upon
reaching
the
hardwork
epoch.
B
Epoch
is
like
a
span
of
slots
so
and
in
that
regard,
the
upgrades
on
on
the
consistent
slayer
side
on
the
beacon
chain
are
highly
deterministic.
So
we
can
predict
the
moment
in
time
when
the
hard
work
on
the
beacon
chain
happens
up
to
up
to
a
second.
Basically,
so
the
the
latrix
part
of
the
merge
will
be
a
highly
deterministic
part
in
terms
of
rollout
in
terms
of
transition
and.
B
Before
belatrix
will
happen
on
the
beacon
chain,
obviously
client
upgrade
is
required
to
bring
the
bellatrix
logic
on
it.
But
it's
worth
mentioning
here
that
it
might
seem
that
the
only
consensus
layer,
clients
we
can
chain
clients
needs
to
be
updated,
because
this
is
the
consensus
data
update.
But
it's
not
that
right
and
to
the
bellatrix
compatible.
B
Ethereum
client
looks
like
the
combination
of
the
beacon
chain,
beacon
chain,
clients
and
the
execution,
their
clients,
which
are
the
clients
that
are
running
currently
on
the
mainnet,
but
they
are
modified
to
adhere
to
the
new
consensus
rules
and
be
driven
by
the.
We
can
change
clients.
So
before
belatrix
this
upgrade
happens,
every
node
is
upgraded
and
is
represented
by
the
two
parts,
the
consensus
layer,
part
and
the
execution
part,
and
they
communicate
via
engine
api
protocol
that
is
exposed
by
the
execution
layer
side.
B
This
engine
api
basically
is
an
interface
for
the
consistently
a
client
to
lead
and
to
update
the
execution
they
aside.
So
it's
like
the
communication
is
directed
by
the
consensus
layer
and
before
belatrix
this
upgrade
happens
and
it
matter
it
is
required
to
have
the
execution
layer.
Part.
Also
upgraded
because,
right
after
bellatrix
ebook
hits
the
consistency.
A
client
starts
to
actively
monitor
the
execution
layer
chain
for
so-called
terminal
total
difficulty
event.
We
will
cover
these
events
in
the
upcoming
slides.
B
So
the
what
does
bilateral's
upgrade
contain
by
itself
when
bellatrix
hits
the
consensus
layer,
proposers
will
start
to
produce
the
updated
beacon
blocks.
These
beacon
blocks
will
contain
a
placeholder
for
an
execution
payload.
Actually
they
will
contain
the
execution
payload
structure
in
in
the
body,
but
this
execution
payload
will
be
empty
before
the
merge.
So
it's
a
placeholder
for
basically
the
execution
block
that
will
happen
when
the
network
will
reach
the
terminal
total
difficulty.
So
the
there
is
an
upgraded
structure.
B
B
B
Also,
what
cameras
with
bilateral
is
the
optimistic
sync
support.
You've
probably
heard
about
it.
It's
a
sync
approach
that
is
used
as
merged
by
all
clients,
but
what
matters
for
transition
is
that
the
ttd
will
be
set
either
before
bellatrix
or
it
may
be
set
after
that.
We
will
also
cover
this
data
so
yeah.
B
Mainnet
hard
forks
it
it
includes
eips.
It
includes
a
couple
of
eips.
One
is
the
main
merge
ap,
which
is
basically
the
state
consensus
upgrade
the
other
one
is
quantum
difficulty
with
free
brandow
and
the
company
and
companion
eap
and
a
component
change
to
the
previous
one,
and,
unlike
the
all,
the
hard
works
that
you
have
familiar
with,
it's
activated
it's
trigger.
It
perform
the
reaching
a
certain
amount
of
total
difficulty,
which
we
call
the
terminal
total
difficulty.
B
So
basically,
what
why
the
why
we
use
total
difficulty
for
triggering
paris
this,
like
the
topic
for
the
next
slide,
but
just
like,
let's
try
to
imagine
the
the
rollout
of
like
paris
how
it
will
look
like
so
we
have,
we
have
belatrix
happened
previously.
We
have
covered
this
part.
Now
we
have
the
next
event
that
we
are
expecting
for
as
a
part
of
the
merge
rollout
as
a
part
of
the
merge
transition.
B
B
So
the
terminal
total
difficulty
basically
denotes
the
last
proof-of-work
block
and
the
system
that
we
call
the
terminal
work
block
and
then
the
proof-of-stake
side.
The
consensus
layer
side,
should
shame
in
and
produce
the
block
on
top
of
this
terminal
perform
block,
and
since
the
and
this
is
going
to
be,
the
first
group
of
state
block
in
the
system
also
called
transition
block,
and
this
spirits
proof
of
stake
block
will
will
have
the
basically
will
be
a
parent's
block.
B
B
So
paris
is
activated
not
on
the
terminal
proof-of-work
block,
as
it
might
seem
like
the
first
house,
but
it
is
activated
like
inside
of
the
first
river
state
block
so
and
yeah
also
one
important
thing
here
to
say
that
this
is
the
how
to
say
it
better.
It's
like
less
predictable,
much
less
predictable
part
of
the
merge
than
the
previous
one
than
the
belatrix,
because
we
used
the
terminal,
total
difficulty
and
total
difficulty
basically
is
affected
by
hash
power
fluctuations
in
the
network,
so
the
before
paris.
B
B
It
doesn't
mean
that
we
are
anticipating
that
we
are
predicting
that,
according
to
our
predictions,
will
happen
four
weeks
after,
if-
and
here
we
have
like
a
number
of
assumption-
if,
for
instance,
the
hash
power
will
remain
the
same,
that's
the
main
assumption,
basically
and
yeah.
If,
if
hash
power
increases
as
we
can,
as
we
recently
see
on
bobstein,
we
can
see
the
ttd
hits
much
earlier
than
expected.
B
Also,
if
it's
is,
if
the
hash
power
goes
down,
we
can
see
that
ttd
may
may
happen
like
not
in
in
in
four
weeks,
but
in
eight
weeks,
and
we
have
a
counter
measures
for
both
both
of
this
scenarios
yeah.
So
we
have,
we
have
covered
belatrix,
various
and
now,
let's
just
let's
just
briefly,
describe
the
happy
case
of
the
entire
merge
transition.
B
B
So
then
we're
waiting
for
belatrix
ebook,
it's
highly
predictable
event.
So
it's
like
predictable
up
to
a
second.
We
will
definitely
know
when
it
happens.
So,
once
the
balatric's
work
happens,
then
we
are
waiting
for
the
proof-of-work
network
to
reach
this
amount
of
total
difficulty
that
we
call
terminal
totally
once
it
happens,
yeah
there
and
we
are
trying
to
pick
a
ttd
to
happen
after
belatrix
to
ttd
event
happen
after
bellatrix.
This
is
very
important
for
the
transition
and
what
will
go?
B
What
can
go
wrong
if
it
if
it's
not
like,
if
it,
if,
if
td
hits
before
belatrix
yeah,
we'll
we'll
see
it
soon
pretty
much
soon,
then
after
terminal
before
block
is
produced
by
the
proofwork
network,
we
are
expecting
that
consensusly,
a
proposer
that
is
eligible
to
propose
this
period
of
time
in
this
slot.
It
will
take
this
terminal
proof
of
work,
block
and
produce
the
first
proof
of
this
state
block
on
top
of
it,
and
this
proof-of-stake
block
will
include
the
execution
layer
payload,
which
is
stripped
down
execution
layer
block.
B
Basically,
the
block
without
fields
related
to
proof
of
work,
and
this
block
will
adhere
to
the
new
rules
that
are
listed
in
these
two
eaps.
So
this
is
going
to
be
the
first
paris
vlog,
so
that's
it
the
electrics
then
ttd,
then
paris
like
paris
and
ttd
are
very
close
to
each
other.
So
we
expect
this
to
happen
like
pretty
much
soon
after
we
expect
fairs
to
happen
pretty
much
soon
after
tdd.
B
So
next
before
we
before
we
dive
deeper
into
what
what
can
happen
if
dtd
hits
before
the
belatrix
yeah,
probably
one
of
the
we
should
clarify
one
thing,
probably
one
of
the
most
important
questions
here
is:
why
ttd,
why
do
we
use
total
difficulty
to
trigger
this
upgrade?
Why
not
use
block
number
as
usual
and
avoid
this
kind
of
you
know
acceleration
of
the.
B
B
That's
what
upgrade
means
in
this
context
and
for
hub
so
open
the
focus
rule.
What
you
would
like
to
have
is
you'd
like
to
have
like
one
one
fork:
choice
rule
you
would
like
to
see
the
canonical
chain
that
is
defined
according
to
one
portrait
rule.
You
want
to
take
this
canonical
chain
and
start
building
blocks
and
start
using
the
new
fork
choice
rule
on
top
of
this
canonical
chain
and
in
the
proof
of
work
network.
B
The
canonical
chain
is
the
one
that
is
backed
by
the
highest
amount
of
work,
the
highest
amount
of
work,
and
this
amount
of
work
is
represented
by
the
total
difficulty
in
theorem
and
other
preferred
blockchains.
So
the
total
difficulty
is
basically
a
model
of
the
amount
of
work
put
into
the
network.
The
higher
the
total
difficulty
would
be
higher
the
amount
of
work
that
have
been
put
into
this
particular
chain
and
vice
versa.
So
it's
not
about
block
number.
So
it's
not
the
highest
block
number
totally
difficult.
B
It's
not
the
highest
block
number
for
choice,
rule
it's
the
total
difficulty
for
choice
rule,
and
this
is
why
the
proof
of
stake
chain
should
take
the
the
heaviest
and
the
the
proof
of
work.
The
chain,
with
the
highest
total
difficulty
of
the
chain
that
has
been
built
by
proof
of
work,
consensus
mechanism
with
the
highest
total
difficulty,
take
this
chain
and
start
building
on
top
of
it.
That's
basically
it
and
yeah.
B
So
this
is
the
only
right
way
to
do
this
upgrade
and
what
can
go
wrong
if
we
use
like
the
highest
block
number,
the
block
number
to
activate
the
fork
is
basically
the
minority
hash
power
chain.
So
the
chain
like,
let's
say,
with
10
of
hash
power
that
we
currently
have
on
the
main
net,
can
reach
the
the
block
number,
the
heart
workbook
number
that
we
could
use.
B
If
we
would
use
the
block
the
the
block
number
as
a
trigger
for
the
merge,
the
minority
hash
power
chain
would
could
reach
this
much
faster
could
reach
this
block
number
much
faster
and
hijack
the
transition.
There
are
some
possibilities,
of
course,
yeah.
This.
This
attack
requires
some
communication
between
the
proposer
and
the
miner,
but
it's
it's
it's
just
details,
so
this
just
proved
that
the
block
number
doesn't
work,
this
specific
attack,
so
that
that's
why
we
use
the
terminal
total
difficulty.
B
Instead
of
block
number
so
the
terminal
of
the
difficulty
once
again,
the
total
difficulty
is
the
the
basement
for
the
proof-of-work
punctures
rule
and
and
during
the
merge
there
is
a
handover
from
the
proof
work
to
the
proof-of-stake
fortress
rule,
and
that's
it
that's
why
the
we
want
to
use
the
certain
amount
of
total
difficulty,
and
this
amount
is
when
we
pick
up
the
value
we
anticipate
it
will
be
reached
since
in
some
future
we
are
not
like.
Obviously,
we
are
not
anticipating
that
it
will
that
it
has
happened
already.
B
So
it's
like
some
some
value
that
we
are
foreseen.
So
what
can
go
wrong?
What
what
can
happen?
Basically,
when
ttp
hits
before
bellatrix
so,
first
of
all,
according
to
like
yeah,
there
is
one
specific
thing
about
execution
layer,
clients
that
I
have
mentioned
before
the
extrusion,
their
clients
also
to
monitor
the
the
chain
for
ttd
and
once
ctd
hits.
B
That's
that's.
That
would
be
a
security
vulnerability.
So
that's
why
actually,
a
client
would
stop
processing
the
roof
workbox
after
the
merge
transition
and
we'll
just
basically
wait
for
consensus
layer,
clients
yeah,
so
this
misconfiguration
may
happen.
If,
like
user,
who
is
not
familiar
familiar
with
consensus,
their
clients,
they
just
have
updated
their
proof
of
work
client
because
they
are
following
their
track
and
the
upgrades
and
forgot
about
the
other
side.
B
So
it
will
just
stop
working
at
some
point
at
at
the
point
where
ttd
hits,
and
so
what
does
it
mean
for
the
network?
So
if
yeah?
Yes,
what
does
it
mean
for
the
network?
Why
it's
import?
Why
it's
like
important
to
mention
here?
So
it
means
that
all
honest
nodes
that
have
been
upgraded
before
before
the
say
like
yeah,
in
the
preparation
to
the
metrics,
and
we
see
we
picked
up
the
ttd
before
to
to
be
included
in
this
upgrade.
B
B
Basically,
it's
not
a
security,
it's
not
a
safety
failure,
it's
a
liveness
failure
and
when
a
bellatrix
work
evoc
happens
on
the
other
side
of
the
stack
on
the
consensus
player
side,
the
first
proposer
of
after
belatrix
will
basically
start
the
transition
process
will
create
the
first
proof
of
state
block,
but
what
we
will
have,
what
we'll
see
is
like,
I
know,
minutes
hours
of
of
the
chain,
just
not
progressing
or
the
extras
chain
is
not
progressing.
So
that's
that's
what
what
will
happen?
B
Basically,
this,
what
what
has
almost
happened
on
robsten
and
to
to
prevent
this?
The
countermeasure
that
we
used
on
drops
and
that
we
that
we
basically
plan
to
use
to
accelerate
the
merge
rather
than
this
to
slow
down
the
merge
we
use
the
ttd
override.
So
we
just
in
this
case
what
what
helps
is
to
override
it,
be
it
set
it
to
a
higher
value.
That
may
not
happen
like
I
don't
know
in
an
ear
or
whatever.
B
This
is
what
we
did
in
robsten.
We
set
an
enormous
amount
of
total
difficulty
as
a
ttd
and
then
weight
where
the
electrics
has
happened,
and
basically
now
we're
expecting
the
the
ttd
to
happen
under
obstacles
so
that
that
what
could
what
could
happen,
but
one
thing
to
mention
here
this
this
event,
the
ttd
before
belatrix.
B
If,
for
instance,
if
we
can
see
the
merge
accelerated
by
by
the
times
of
two,
so
it's
it
would
mean
that
we
have
the
same
amount
of
hidden
hash
power
somewhere
and
basically
this
hash
power
may
employ
a
51
attack
which
breaks
the
security
assumptions
of
the
term.
So
we
are
like
not
expecting
bttd
to
hit
before
bellatrix
on
the
main
end,
but
on
the
test
nets.
It's
it's
a
it's
really
the
case
that
may
happen.
B
B
The
first
option
here
is
to
cut
the
releases
with
the
new
ttd
value,
but
it
hits
the
release
pipeline
of
each
client.
It
takes
like
more
time
to
to
to
do,
and
it
also
require
it
hits
the
pipeline
of
the
infrastructure
to
upgrade
their
clients
and
what
is
easier
and
what
is
less
complicated
in
terms
of
time
brings
less
time.
Complexity
is
using
the
cli
argument
that
requires
the
client
restart,
like
both
clients,
cl
part
and
el
part,
is
required
to
be
restarted
with
the
new
ttd
value.
B
A
B
Have
picked
up
for
our
robson
now
currently
this
cheat
sheet,
but
it's
really
useful
to
to
take
a
look
if
you
are
running
a
client.
So
this
is
what
you
can
use
to
operate.
The
tuberider
ttd
when
it's
needed.
Also
it's
mentioned
in
the
blog
and
the
recent
blog
post
about
the
robson
emerge
on
robson
yeah,
and
this
robston
case
made
us
think
about
the
following
merger
out.
B
It
makes
sense
for
the
mainnet
as
well
for
this
particular
purpose.
Also.
The
other
purpose
of
having
this
same
procedure
on
the
mainnet
is
that,
because
the
infrastructure
users
are
used
to
do
the
same
actions,
the
same,
like
sequence
of
actions,
to
go
to
run
through
the
immerse
transition,
so
there
are
like
a
two-fault
meaning
for
having
the
same
rollout
for
the
mainnet
and
once
again
we're
not
expecting
the
ttd.
B
A
A
So
if
you
have
missed
it
earlier
check
out
the
recording
of
beep
and
eve
episode,
41
and
57
for
eip
3675
and
43
99,
which
mikhail
mentioned
in
his
presentation
earlier
so
well
again,
you
did
a
great
job
in
explaining
everything,
and
I
have
a
few
more
questions,
though
you
have
already
answered
most
of
the
frequently
asked
question:
I've
got
a
few
more
of
them
for
you
right
now.
We
are
on
to
the
merge
rollout
screen.
So
let
me
quickly
take
this
question,
which
is
about
the
roll
out
for
main
net.
A
We
saw
that
for
roxton
we
have
to
go
for
the
ttd
override
how
confident
developers
are
that
this
is
going
to
be
one
time
thing,
or
you
are
expecting
that
this
can
be
a
case,
though
increasing
hash
power
would
be
extremely
expensive
in
case
of
main
net.
How
how
confident
we
are
that
we
would
be
going
ahead
with
the
ttd.
C
B
Yeah,
I
see
one
okay,
so
tdd
override.
First
of
all,
it's
also
used
for
accelerating
the
merge,
but
for
like
slowing
down
the
merge
that
we
use
for
robston.
I
would
say
that
bringing
that
much
hash
power
to
the
mainnet
is
just
impossible,
because
it
would
break
our
assumption
on
the
ethereum
security
today.
B
So
it's
not
that
it's
not
just
enormously
expensive.
It's
just
impossible.
There
is
not
that
like.
There
is
not
that
hash
power
that
is
working
somewhere
in
the
internet
that
can
be
used
to
like
significantly
accelerate
the
ttd
event,
also
yeah,
and
also
we
will
likely,
I
don't
know
likely
or
not,
but
I
would
say
that
probably
it's
not
that
bad
to
have
like
picking
up
this
td
value
after
the
latricks
has
already
happened
on
the
main
net.
B
What
can
also
happen
on
a
mainnet
and
why
we
even
developed
and
invented
this
mechanism
of
ttd
override
is
the
the
case
where
we
have
the
hash
power
drop
drop
off.
It's
just
significant
drop
in
the
hash
power
that
leads
to
delaying
the
merge
and
say
that
we
were
expecting
ttd
event
to
happen
like
in
a
month
or
in
a
couple
of
weeks,
and
instead
it
happens
in
two
months
and
or
like
four
weeks.
B
So
what
we
can
do
here
is
use
dtd
override
to
like
reset
the
ttd
value,
to
make
it
happen
to
make
the
ttd
hit
close
it
in
time
and
like
to
manage
this.
So
we
can
man
we
can.
We
can
like
manage
this
ttd
event
from
like
one
side
when
the
emerge
is
about
to
be
slowing
down,
slow
down
or
from
the
other
side.
When
it's
about
be
accelerated-
and
I
don't
know-
I
personally
did
not
expect
significant
drop-offs
and
the
hash
rate
before
the
merge,
but
we
have
this
safeguard.
B
B
Yeah
definitely
so
yes,
if,
if
like
merge
happens,
like
I
don't
know,
say
three
days
after
it's
been
expected
on
the
main
end,
it's
okay!
So
that's
that's!
That's
healthy!
We
will
not
like
use
the
ttd
override
to
hit
the
exact
to
to
meet
the
exact
date
and
exact
time.
Also
taking
the
nature
of
like
all
these
mainnet
hard
forks,
it's
with
the
block
block,
height
block
height,
is
prone
to
this
person
process
fluctuation.
B
So
it's
like
a
pretty
unpredictable
thing,
probably
for
the
merge.
It
will
be
even
more.
The
fluctuations
will
be
more
intense
but
they're
different
kind
of
fluctuation,
this
basically
population
and
hash
power,
so
yeah,
so
people
should
expect
the
marriage
to
happen.
Like
I
don't
know
after
a
few
days,
I
would
say
this
is
my
opinion.
B
C
My
opinion
is
mostly
my
expectation
is
mostly
the
same,
though
I'm
a
little
more
pessimistic
in
terms
of
depending
defending
against
the
unforeseen,
and
so
I
agree
with
michael
that's
most
likely
we'll
see
a
slight
delay
due
to
hash
power
drop
off.
I
doubt
we'll
see
a
huge
delay,
but
I
think
that's
more
likely
than
a
lot
of
other
people
think
I
think
the
chance
of
acceleration
are
very
low
unless
there's
an
active
attack
of
some
kind.
C
This
causes
us
to
ttd
override
and
then
they
bring
all
that
hash
power
back
to
accelerate,
and
so
you
could
do
some
sort
of
weird
attack
like
that
and
if
we're
not
paying
attention,
then
we
could
accidentally,
you
know
screw
something
up
and
have
it
arrive
too
soon,
not
because
a
bunch
of
hash
power
appeared
out
of
nowhere,
but
because
hash
power
left,
we
compensated
with
the
ttd
override
and
then
hash
power
came
back.
It's
a
very
extreme
scenario,
seems
unlikely,
but
I
think
it's
something
that
we
should
keep
in
mind.
A
B
Okay,
so,
first
of
all
the
they're
activated
on
different
chains,
the
bellatrix
on
the
beacon
chain,
the
paris
is
the
execution
layer
chain
upgrade
there
are
different
triggers
for.
For
for
these
two,
we
have
four
keyboard
for
belatrix,
which
is
highly
predictable.
We
have
this
ttd
for
paris,
so
paris
is
the
first
block
after
ttb
hits
the
network
and
yeah.
So
belatrix
enables
the
what
this
works.
What
this
upgrades
are
about
electrics
enables
the
consensus
layer,
the
beacon
chain
for
for
the
merge.
B
B
So
we
have
these
two
type
of
nodes,
two
type
of
clients
under
under
the
hood
of
ethereum
client.
One
is
the
consensus
layer,
the
other
one
is
the
execution
layer
and
they
need
to
communicate
to
each
other.
So
the
belatrix
sets
this
communication
channel
and
they
started
to
communicate
with
each
other
after
bilaterals
happens,
so
it
makes
sense
up
to
belatrix
for
a
consensus
layer
to
monitor
the
execution.
B
This
is
what
this
is
all
included
in
balatrix,
but
it's
just
rolling
out
after
rib
electrics
happens,
block
structure
changes,
but
sometimes
after
when
ttd
happens,
the
the
the
the
new
delegation
of
the
execution
payload
to
the
ael
side
of
the
executioner
side,
this
new
mechanism
starts
working.
Paris
is
basically
about
upgrading
the
execution
layer.
So,
first
of
all,
the
execution
network
starts
to
adhere
to
the
proof
of
stake
for
choice,
rule.
B
B
B
Yeah,
it
has
some
other
things
like
the
for
yellow
americorps
yeah,
so,
okay,
so
it
has
another
eap
as
well.
So
the
difficulty
of
code
is
supplanted
by
pre-brandow
and
randall
is
like
the
mechanism.
That's
used
for
randomness
on
the
consistency
aside,
yeah,
but
that's
the
topic
for
another
talk
or
another
mention
like
yeah,
not
go
deeper
into
detail.
So
we
have
this
update
in
the
evm
in
one
of
the
evm
of
codes,
also
yeah.
B
If
we
would
like
to
go,
I
I
can
go
further
to
the
previous
state
here
and
cover
probably
what
happens
with
all
of
that
after
the
merge
like
what
will
happen
with
the
network.
What
what
new
things
we
will
have
so
yeah
paris
is
about
upgrading
the
execution
layer
and
then
here
it
at
at
here
in
the
exhibition
there
to
the
proof
of
stake.
Punctuation.
A
B
As
the
practice
shows
us
it's
difficult
on
the
test
nets
for
the
mainnet,
as
it's
been
said,
we're
not
personally,
I'm
not
expecting
the
huge
drop-off
in
the
hashpower,
so
the
prediction
should
be
pretty
accurate
like
up
to
up
to
a
few
days,
but
we'll
see
what
happens
so.
It's
like
on
the
main
net,
it's
much
more.
The
prediction
can
be
much
more
accurate,
considering
the
assumption
that
we
can
make
on
the
main
net.
There
is
a
lot
of
hash
power
there.
B
There
is
the
crypto
economic
motivation
to
basically
keep
keep
the
proof
of
work
chain,
sustainable,
keep
its
building
blocks
and
yeah.
That's
that's!
That's
like
much
weaker
assumption
that
assumptions
that
we
have
on
the
test
nets,
where
we
don't
have
enough
of
a
hash
power
to
maintain
like
the
hype,
higher
costs,
the
high
cost
of
attack
so
attack
and
test
nets.
A
B
B
Why
should
I
choose
anything
down?
Go
ethereum!
There
is
a
lot
of
reasons
why
you
would
do
this,
I'm
like
looking
and
on
all
these
engineering
efforts
and
on
all
that
happening
with
the
around
testing
and
so
forth.
There
is
a
bunch
of
clients,
really
that's
yeah
they're
for
really
good
quality
and
they
are
active
working
on
preparation
of
the
merge
so
that
you
would
like
to
take
a
look
at
we
we
had
previous
yeah.
So
don't
be
lazy.
B
Do
do
your
job
here
so
yeah
that
that
that's
not
the
contribution
to
your
own
preference,
but
that's
the
contribution
to
the
security
of
the
network.
It's
really
important
to
not
have
the
client
that
takes
the
majority,
like
two-thirds
previous
two-thirds
of
the
stake.
Previously
we
had
this
issue
with
like
prism,
who
took
the
mature,
who,
who
was,
which
was
the
majority
client
for
the
beacon
chain.
B
B
You
may
take
a
look
as
well
at
the
minority
project,
so
it's
multiplexer
that
allows
for
running
like
different
tail
clients
on
the
one
single
client,
so
that
that
may
help
to
that
may
also
help
to
afford
client
diversity
running
a
node,
so
run
node
for
a
user
will
not
yeah
going
briefly
what
it
makes,
what
it
does
mean
to
run
a
node
as
a
user.
So
I
was
like
looking
at
the
lighthouse
database
profile.
So
it's
like
the
default.
B
The
default
modes
they
have
like
yearly
disks
usage
is
like
5.7
gigabytes,
which,
which
is
not
that
bad
it,
which
is
like
easy.
With
respect
to
what
the
ell
clients
do
usually
have
like
what
the
footprint,
what
the
disc
green,
the
yellow
clients
usually
have
in
terms
of
like
networking.
There
are
ways
to
optimize
clients
for
you.
We
can
change
clients
for
users
like
not
subscribing
to
other
stations
topic
at
all,
so
yeah,
that's
that's
something
that
client
teams
will
definitely
work
on
as
well.
B
So
that's
very
important
for
the
network.
Security
yeah,
but
sweller
will
have
something
interesting,
like
block,
rewards
and
and
in
ev
post
merge.
So
that's
that
should
alleviate
their
their
thing.
So
yeah
work
is
about
to
be
turned
off.
That's
what
we
have
that's
what
the
emerge
about.
So
it's
nothing
to
just
to
talk
about
here.
B
Basically,
yeah
about
yeah,
post,
marriage,
theorem,
will
be
kind
of
will
become
an
ultrasound
money,
the
amendment
by
justin
break,
so
why
it
happens
because
we
don't
have
walk,
rewards
anymore.
We
will
not
pay
to
eve
for
each
block
proposed
by
produced
by
miners,
because
there
will
be
no
work
for
it.
This
block
rewards
just
deprecated
goes
away,
but
but
whatnot
goes
away.
B
Is
the
transaction
priority
fees,
so
they
will
go
to
what
errors
after
the
merge,
while
veterans
will
have
to
configure
the
fee
recipient
field.
This
is
a
part
of
like
a
node
configuration
in
preparations,
merge
and
all
the
priority
fees
will
go
to
the
recipient
field,
that
is
in
the
execution
layer
block
so
and
the
weathers
will
can
take
this
this
period,
piece
like
without
a
without
like
waiting
for
the
withdrawal
pipeline
to
be
enabled
there
is.
B
I
think
it
is
very
important
to
mention
that
there
is
a
huge
shift.
It's
like
it's
a
probably
not
huge,
but
just
it's
a
big
shift,
at
least
in
the
block
confirmations,
so
we
previously
used
this
key
k.
Block
confirmation
rule
in
the
proof
of
work
will
currently
use
it,
but
in
the
proof-of-stake
there
are
finalized
and
safe
blocks
instead
of
a
sca
block
and
permission
rule.
B
So,
instead
of
like
waiting
for
32
blocks
to
confirm
the
transaction,
you
will
be,
you
will
be
waiting
for
your
transaction
to
be
included
in
a
finalized,
blog
and
yeah.
The
clients
have
the
execution
layer.
Clients
have
these
up
updating
the
json
rpc,
this
new
block
text,
so
this
is
basically
look
like
it
get
blocked
by
a
number
and
the
tag
finalized
or
tag
save
to
to
query
for
these
blocks
and
yeah.
B
There
is
like
the
difference
between
finalized
and
safe
finalized
is
like
what
is
what
we
call
like
economically
finalized,
so
to
rework
this
for
someone
to
make
this
block
reward,
it
will
require
to
one
third
of
of
state
to
be
slashed,
which
is
huge
if
we
we
like
apply
this
rule
to
today's
numbers.
Also
we'll
have
a
notion
of
safe
block.
The
safe
block
is
like
very
unlikely
to
be
rewarded
unless
there
is
like
a
high
network
delay
or
an
attack
on
the
network.
B
For
so
far,
the
health
network,
safe
block,
is
not
going
to
be
rewarded
and
save
block
will
be
point
to
justified
block,
which
is
like
one
block
close
one
ebook
closer
to
the
head
of
the
chain.
Then
the
finalized
one,
so
this
will
will
be
post
merge
and
then,
since
time,
this
save,
lock
algorithm
will
be
improved
and
it
will
be
closed
to
the
head.
The
safe
block
will
be
close
to
the
hat,
so
I
guess
basically
we'll
be
like
one
block
behind
the
hat
and
the
latest
will
point
to
the
head.
B
B
So
it's
like
there
is
like
a
stable
block
supply
space,
also
transaction
fees.
It's
very
important
to
say
that
transaction
fees
are
not
going
to
be
affected
by
the
merge.
Probably
like.
Probably
this
stable
block
times
will
have
a
slight
effect
on
like
the
gas
price,
but
the
merge
is
not
about
it.
The
merge
is
not
about
a
change
in
the
transaction.
B
It
has
now
this.
This
kind
of
goal,
yeah
and
withdrawals-
will
come
in
the
upgrade
next
to
the
merge.
So
you
can
read
about
it.
It's
called
like
the
work
name
for
the
upgrade
it's
capella,
so
you
can
take
a
look
at
the
consensus
specs
repository
for
for
this
specification
for
withdrawal
specification.
B
Also,
the
proof
of
execution
that
I've
mentioned
will
challenge
and
slash
those
values
that
are
not
executing
the
payload
before
testing
to
it,
and
this
will
come
sometimes
in
the
future,
and
we
will
get
this
allows
us
to
get
rid
of
this.
Like
honesty,
assumption
on
those
on
the
executing
the
payload
before
I
destined
to
it,
okay,
so
there
are
some
resources.
I
also
strongly
recommend
to
listen
and
to
check
the
merge
community
call
number
four
that
has
recently
happened
like
her
last
friday.
B
It
was
great
a
great
explanation
of
what
needs
to
be
prepared
for
the
merge
in
terms
of
infrastructure,
in
terms
of
like
node
upgrades,
also,
the
hardware
requirement
and
other
stuff
have
been
covered
during
the
start.
So
that's
that
that's
all
I
have
today
during
the
test
and
the
marriage
efforts.
It's
not
it's
never
late!
So
before
the
merge,
any
anything
that
you
can
do
like
sending
transaction,
deploying
your
application
and
giving
us
the
feedback
will
be
very.
Very
valuable
thanks
a
lot
for
for
your
attention.
B
A
Questions
probably
yeah.
Thank
you
mikhail.
Thank
you
for
all
these.
I
have
one
last
question
for
you.
It
is
about
the
transition
of
the
merge
and
it
especially
for
the
users
who
would
like
to
join
the
ethereum
network
at
this
point
of
time.
It
would
be
really
unfortunate,
but
what,
if
a
beacon
chain
validated,
goes
offline
for
any
reason
just
before
the
transition
can
it
can
the
validator
get
back
on
the
right
chain
or
and
also
if
there
are
any
penalty
or
slashing
proposed
for
any
such
incidents?.
B
Sure
good
question:
actually,
whether
if
validator
is
running
the
up-to-date
software
and
should
be
ttd
override
happen,
the
validator
running
his
client
would
be
right
will
be
correct
with
the
most
up-to-date
ttd
value.
This
is
why
it
is
important
to
follow
all
the
communication
channels
and
worse
to
to
be
on
track
with
this.
If
this,
if
this
is
like
the
case,
so
the
software
is
up
to
date,
but
then
the
other
goes
back
online.
B
A
Good
to
know
well,
thank
you
so
much
for
sharing
all
these
valuable
information.
It's
time
to
wrap
up
having
proof
of
stake
as
the
consensus
mechanism
for
ethereum
is
a
dream
of
the
ethereum
community.
For
many
years
the
launch
of
beacon
chain
in
2020
was
the
first
realization
of
the
dream
coming
true
with
the
merge
of
robsten
the
public
testnet,
we
are
even
closer.
I
hope
information
shared
today
will
be
helpful
for
developers
as
well
as
non-developer
people,
understanding
the
transition
process
mikhail.
A
We
appreciate
you
taking
our
time
and
talking
about
bellatrix,
paris
and
the
transition
process
thanks
future,
and
on
this
note,
thanks
to
everyone
watching
and
listening
to
this
special
episode
on
merge,
should
you
have
any
question:
leave
a
comment
or
reach
us
at
eat.
Cat
hurdles
discard
check
out
description
for
links
to
useful
resources
and
guest
twitter
to
follow.