►
Description
Topics covered
-----------------------------
01:05 - Introduction
02:54 - EIP overview - Header
04:18 - Motivation
05:42 - Abstract
08:10 - After the Merge
08:25 - High-level introduction of the system after the merge
08:38 - Blockchain
10:22 - Network
11:50 - Client
13:33 - Definition
13:45 - PoS event
18:07 - Transition block
20:15 - Terminal total difficulty
22:22 - Transition process
22:50 - Beacon chain fork
27:15 - Transition diagram
30:03 - If the execution client receives the internal proof of block over the Gossip n/w but the block proposer has not yet received one, does the execution client are going to sit and wait until a block proposer sees some terminal proof of work block?
31:40 - Why does it wait to stop handling those messages until finalization, why doesn’t it stop handling them as soon as it sees the terminal proof of block.
34:05 - Specification
34:12 - PoW block processing
36:54 - Block structure
37:32 - Block validity
38:44 - Block and owner rewards
38:54 - Fork choice rule
39:45 - Network
39:59 - Backward compatibility - EVM
42:25 - Merge mainnet checklist
43:38 - References
44:05 - Q&A
44:45 - How will eth1 services like Infura work when proposing blocks, or will the merge require the validator to run their own instance of the execution client to receive the full reward?
46:11 - Have you heard from 3rd party providers such as Infura, Alchemy, what this means for their offerings? Specifically, how they'll handle coinbase and distribution of priority fees on block proposals?
50:31 - Will priority fees going to the validators after the merge be assigned to whoever was randomly chosen to produce that specific block, or will it be evenly distributed to every active validator on the network?
51:14 - What do you expect rewards to look like for validators in the short and long timeframes post-merge?
53:25 - What is the recommended way for a contract to access randomness?
55:15 - Is the (rough) plan to include EIP-3675 and EIP-TBD, which reintroduces a source of randomness to DIFFICULTY, in the same fork?
55:40 - What do you think miners will do after consensus is changed? Do you think they’ll keep mining the old ETH POW chain, move their mining power to other blockchains or capitulate and join ETH2 as validators?
58:20 - A few words for the community.
Resources:
-------------------
EIP - https://eips.ethereum.org/EIPS/eip-3675
Discussion - https://ethereum-magicians.org/t/eip-3675-upgrade-consensus-to-proof-of-stake/6706
Slides - https://docs.google.com/presentation/d/1rkiS9ZX5hzuE03SodKHfkztBc3f1vUBWgirGvfLCiFk/edit#slide=id.g8cb00373fc_0_96
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Follow at Twitter
-----------------------------------------------
Mikhail Kalinin @mkalinin2 |Micah Zoltu @MicahZoltu | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
The
emerge
will
be
the
biggest
upgrade
to
switch
the
proof
of
work
to
proof
of
a
state
consensus
mechanism.
To
talk
about
the
proposal
we
are
joined
by
mikhail
khalin,
who
is
a
researcher
and
developer
at
consensus?
Welcome
to
the
show,
michael,
I
have
been
following
the
merge
discussion
and
I'm
looking
forward
to
what
this
brings.
I
know
the
community
is
also
eager
to
learn
about
the
proposal,
but
before
we
begin
the
discussion,
I
would
be
curious
to
know
how
mikhail
karman
ended
up
with
ethereum
community.
So,
let's
kick
off
by
a
brief
introduction.
B
B
B
Thanks
a
lot
for
ethereum
foundation
and
their
grand
program,
then
we
are
joined
pegasus,
and
here
we
are
currently
I'm
within
a
team
of
an
rd
team
that
is
devoted
for
it
to
research
and
development,
and
my
occupation
is
the
merge
stuff.
I've
been
here
for
one
and
a
half
years
already
so
join
this
marriage
project
like
in
the
january
of
previous
year.
So
that's
a
bit
about
myself,
living
in
siberia,
working.
B
B
B
This
is
the
core
eap
on
the
standard
track
like
as
puja
just
mentioned,
it's
not
an
eap.
Yet
it's
just
a
pull
request
for
this
moment,
but
I
hope
it
will
turn
into
the
eip
into
the
its
draft
state
like
soon
yeah.
It's
the
category
is
core
because
it's
obviously
it
introduces
the
changes
to
the
course
to
the
core
protocol,
which
will
need
to
be
adopted
by
all
in
its
clients.
B
B
So,
please,
who
are
interested
in
that
in
particular,
go
buy
that
link
and
and
see
the
motivation
section
here,
and
what
else
to
mention
here
is
that
the
beacon
chain
has
been
online
since
december
2020
and
we
haven't
faced
with
any
safety
or
liveness
failures
so
far,
which
demonstrates
its
sustainability
and
readiness
for
securing
the
remain
at
so
yeah
this.
This
is
the
time
for
doing
the
merge.
Actually,
so
that's
that's
all
here,
and
evaluation
and
yep
go
into
abstract
section.
B
This
is
actually
the
description.
What
will
what
this
specification
is
about?
It's
about
the
subversity
and
the
proof
of
work.
The
existing
pro
fork
algorithm
with
the
proof
of
stake
driven
by
the
beacon
chain-
and
yes
here,
is
the
link
to
the
beacon
chains.
Specs
repository
yes,
so
this
the
beacon
chain
specifications
are
sitting
different
place
other
than
the
eips,
so
this
was,
I
guess,
a
lot
of
discussed
a
lot
during
this
2982
eap
process.
So
we're
not
going
to
do
we're
not
supposed
to
discuss
it
here.
B
I
guess
yeah.
The
changes
that
I
introduced
by
these
specifications
are
go
to
the
blog
structure
and
blog
processing
focus
rule
and
network
interface.
Those
are
the
main
sections
of
specification
and
I'd
like
to
highlight
the
rational
behind
all
these
specifications,
so
the
general
idea
of
these
changes.
So
this
is
actually
the
minimal
viable
version
of
the
merge.
B
Those
are
not
go
into
this
specification
and
the
reason
behind
this
is
that
merges
the
change
hot
swap
and
the
underlying
consensus
mechanism
is
already
a
very
complicated
thing
and
we
don't
want
to
bring
more
and
complexities
that
is
not
necessary
for
doing
this
swap
and
all
those
cleanups
and
all
that
we
might
want
to
do
will
be
introduced
in
a
separate
upgrades
which
will
be
after
the
merge.
So
that's
the
general
line
here
and
yeah
you
will.
B
We
will
get
back
to
it
like
throughout
this
presentation,
but
before
we
go
into
the
reads
of
into
the
details
of
specification,
I'd
like
to
zoom
out
for
a
bit
and
just
give
you
a
brief,
very
high
level
introduction
of
the
of
the
system,
how
it
will
look
like
after
the
merge.
So
sorry,
let
me
just
do
this
shortly:
okay,
so
yeah,
okay,
so
we'll
see
after
the
merge
on
the
blockchain
side.
B
B
So
every
execution
payload
maps
one
to
one
on
the
respective
proof
of
state
block
and
back
and
forth,
so
the
beacon
chain
it
becomes
responsible
for
producing
the
execution
payload
and
producing
this
execution
chain
by
the
way
execution
chain
is
the
continuation
of
ethereum
chain.
As
we
know
it
today,
even
the
block
format
stays
the
same.
B
So
it
knows
what
is
the
head
of
the
chain
and
only
the
beacon
chain
knows
what
is
the
head
of
the
chain,
and
so
of
course,
it's
also
responsible
for
yeah
for
consensus
rules.
Verification
we'll
see
it
later.
So
here
we
are.
But
what
is
important
here
is
that
this
execution
chain
retains
this
is
important
for
services
for
json
rpc,
for
a
lot
of
infrastructure
and
tooling
that
uses
these
that
are
heavily
relies
on
this
chain
and
its
format
and
it's
block
format
on
network.
B
We
will,
after
the
merge,
we'll
see
two
networking
stacks.
First,
one
is
the
beacon
chain
network
stack
which
is
responsible
for
consensus
duties.
It
has
like
these
other
stations
that
are
votes
for
this
or
another
block,
and
there
is
the
beacon
block
gossip,
which
will
supersede
the
block
gossip
of
the
execution
chain.
B
But
execution
chain
will
keep
the
transaction
pool.
So
all
the
transaction
will
be
collected
by
the
execution,
clients
and
then
embed,
then
we'll
go
into
a
block
which
will
be
produced
by
the
we
can
change
proposers,
but
with
usage
of
execution,
client
software.
Okay.
So
it's
also
the
history,
sync
remains,
and
the
states
in
remains
so
the
those
services
that
will
you
that
are
relies
on
the
history
sync,
for
example,
or
on
archive
nodes,
we'll
be
able
to
keep
doing
this
after
the
merge.
B
B
B
It's
also
responsible
for
folk
choice,
as
it
was
mentioned
before
and
so
forth.
The
execution
client
keeps
keeps
being
responsible
for
the
evm
for
the
world
state
or
ethereum
account
state,
as
we
know
it
today,
and
for
maintaining
the
execution
chain
and
transaction
pool
and
what
is
also
very
important.
B
B
Let's
get
back
to
our
eip
and
let's
get
back
to
start
from
the
definition
section.
There
is
a
couple
of
like
unusual
definitions
in
this
eap
unusual
with
respect
to
other
eags.
That's
because
it
involves
a
third
party
like
it.
It
involves
an
external
party
like
the
consensus
layer
that
we
can
chain
and
also
it
introduces
the
new
hard
work
process.
So
we
will
go
through
the
details
of
this
one
by
one
yep.
The
consensus,
layer
or
consensus.
B
Client
is
abstracted
away
in
this
eip
by
introduction
these
proof-of-stake
events
that
are
happening
in
the
reads
of
the
proof
of
stake
consensus
and
are
just
statements
about
some
block
about
the
status
of
the
bloc
and
these
events
are
going
to
be
propagated
to
the
execution
there,
and
this
is
how
the
communication
happens
and
how
the
communication
is
specified
in.
In
in
this
document,
so
let's
just
yeah
here
is
these
three
events:
let's
just
go
through
them,
one
by
one.
B
We
have
this
consensus
layer
on
the
left,
execution
layer
on
the
right,
so
the
blog
gossip,
let's
just
suppose,
a
short
story
from
the
communication
of
these
clients.
Let's
suppose
it's
that
there
is
new
block
coming
from
the
blog
gossip
on
the
consensus
side,
it
starts
it
does
some
pre-validation
here
of
this
block
like
checking
the
proposer
signature.
If
it's
valid,
then
this
block
is
sent
to
the
execution
there
in
order
to
check
the
execution.
B
B
B
So
once
the
choice
triggers
here
and
like
the
block
is
designated
as
the
head
of
the
chain,
it's
communicated
down
to
the
execution
layer,
so
it
may,
and
it
should
end
it-
must
take
the
according
action,
so
set
this
block
as
the
head
of
the
chain.
The
same
happens
with
the
when
the
block
is
finalized.
B
In
the
best
case,
the
block
is
finalized
to
epochs
after
it's
been
imported
so
and
there
is
the
respective
messages
sent
to
the
execution
layer,
so
it
can
be
aware
of
finalize
blocks
and
expose
this
property.
The
block
finality
to
the
users.
Okay,
this
is
about
the
event.
The
next
stop.
Okay,
we've
been
talking
about
the
abstraction
of
consensus
layer
now
the
new
hard
fork
mechanism.
B
So
here
we
have
the
core
like
concept,
which
is
called
terminal
total
difficulty
which
actually
triggers
the
transition
process
triggers.
The
emerge
we'll
speak
about
why
this
happens
upon
the
total
difficulty
reach
by
the
network
on
the
next
slide,
but
anyway,
so
once
the
terminal
total
difficulty
is
reached
by
the
network
there
is,
there
is
the
the
first
block
that
reaches
this.
Total
difficulty
is
denoted
as
the
terminal
perform
block.
So
literally
this
will
be
the
last
proof-of-work
block
in
the
network,
so
the
last
block
built
by
the
proof
of
work.
B
B
This
is
what
we
usually
were
referred
as
the
fork
block,
but
since
this
is
a
kind
of
a
bit
different
hard
fork
mechanism,
we
decided
to
use
this
name
transition
block
instead
of
fork
block
to
not
to
confuse
anybody,
because
fork
block
usually
goes
to
the
configurations
like
this
chain
configuration
of
remaining
clients.
I
I
think
that
this
transition
will
be
different
in
that
regard.
B
So
that's
why
the
different
name
here
so
we
have
like
yep
once
again,
total
difficulty
triggers
the
transition
and
signifies
the
terminal
for
block
the
next
block
produced
on
top
of
it
is
going
to
be
the
proof
of
stake
block.
This
is
by
design
and
it's
called
transition
lock,
so
yeah.
Why
terminal
total
difficulty?
B
Why
not
using
the
predefined
hard
fork
number
hard
fork
block
number
as
other
regular
hard
forks?
That's
because
of
this
kind
of
attack,
where
one
party
may
an
adversarial
party
may
create
the
minority
fork.
The
fork
which
has
been
produced
by
the
minority
of
hessian
power,
and
then
this
and
this
minority
for
can
satisfy
this
block
number
requirement,
and
it
could
be
really
revealed
right
before
before
the
merge
or
after
the
merge
already
happened
on
this
adversarial
fork
and
yep.
That's
it.
B
B
When
this
you
know
when
to
reveal
this
block
and
yeah,
they
can
juggle
between
one
proposal
and
another
and
wait
for
their
turn
to
propose
and
so
forth
and
yeah,
but
still
it's
possible,
but
and
following
the
total
difficulty
rule
following
the
terminal
total
difficulty
rule
introduced
by
the
specification,
we
are
enforcing
this
transition
process
to
follow
the
majority
of
hessian
power
and
prevented
this
kind
of
attacks.
So
that's
the
rational.
B
B
B
B
So
it
starts
okay.
So
the
transition
process
starts
with
the
software
upgrade
which
will
deploy
the
beacon
chain
fork.
The
begin
chain
emerge
logic
on
the
consensus
layer
side
and
also
there
will
be
a
respective
update
on
the
execution
side,
which
is
yeah
which,
by
this
time,
will
be
still
the
proof
of
work
chain
or
there
may
not,
as
we
know
it
today,
but
it
it
will
still
listen
to
the
proof
work.
B
So
this
software
upgrade
will
happen
likely
four
weeks
before
the
merge
for
kpop
as
usual
and
yeah.
Once
the
merge
for
kpop
happens,
the
consensus
layer
will
compute
the
terminal
total
difficulty
we'll
speak
about
this
communication
like
a
few
seconds
later
so
and
then
this
computed
terminal,
so
the
difficulty
is
communicated
down
to
the
execution
layer.
So
this
is
the
first
time
there.
B
These
two
clients
starts
to
communicate
so
to
make
the
execution
layer
aware
of
this
at
all
difficulty
and
act
respectively,
we'll
see
how
on
the
next
slide,
okay,
so
this
total
difficulty
is
computed
and
in
the
following
fashion,
we
just
take
the
we
take
the
encore
profile
fork
block.
So
just
that's
the
sum
block.
That's
the
beacon
chain
is
agreed
around
and
but
I
think
it's
difficult
to
estimate
this
terminal
total
difficulty
and
we
compute.
B
Worth
of
seconds-
and
we
compute
target-
preferred
blocks
to
merge
by
dividing
these
target
seconds
by
the
average
block
average
for
four
block
number,
so
we
get
this
total
difficulty
offset,
and
then
we
add
this
offset
to
the
total
difficulty
of
anchor
before
block.
That's
the
how
the
estimation
is
happening,
how
the
computation
is
happening,
yeah
about
the
same
group
perform
block.
B
It
also
agrees
on
the
block
hash
and
this
mechanism
is
going
to
be
used
to
to
get
to
to
obtain
the
center
for
walk.
So
once
the
merge
for
keyboard
happens,
whatever
is
in
the
beacon
state.
What
whatever?
If
one
block
hash
is
in
beacon
state,
is
going
to
be
the
encore
report
block,
that's
it
okay,
so
terminal
total
difficulty
has
been
communicated
and
we
are
roughly
seven
days
after
this
event
has
happened,
and
here
is
the
where
the
actual
transition
starts
so
yeah.
B
There
is
the
terminal
before
block
which
happens
and
is
tracked
by
the
execution
and
consensus
sides
so
because
the
the
execution
side,
of
course,
it
knows
when
it
happens,
because
it
follows
block
processing
that
are
false,
deep
block,
processing
on
the
mainnet
and
yep.
It's
aware
about
the
external
total
difficulty,
also,
the
consensus
there
tracks
this
proof
work
chain
as
well
as
do
today
and
yeah
once
this
terminal
preferred
block
happens
so
the
first,
the
first
section
of
specification
of
dcip
comes
into
effect
and
no
other
blocks.
B
No
descendants
of
the
terminal
block
must
be
processed,
we'll
see,
duration
on
that
later,
also
the
networking
stack
should
not
send.
The
descendants
of
the
yeah
here
is.
The
whole
statement
has
been
cut,
but
yeah.
This
is
also
only
related
to
the
descendants
of
the
terminal
block,
so
one
gossip
for
descendants
of
terminal
blocks
should
be
stopped.
B
Then,
once
the
proposer
of
the
the
bigotry
proposer
sees
this
terminal
preferred
block,
it
takes
this
block
and
builds
the
execution
payload
on
top
of
it
wraps
it.
It
enshrines
it
into
the
beacon
block
sends
it
to
the
beacon
chain
network
over
the
blog,
gossip
and
yep.
It's
adds
this
block
received
by
the
consensus
layer
of
other
clients
is
propagated
down
to
the
execution
layer
and
it's
the
transition
block
that
we've
been
talking
with.
We've
been
mentioning
earlier.
C
C
B
Okay,
so
next,
the
as
of
the
first
proof-of-stake
chain
had
set
event.
We
have
the
fork
choice,
rule
switch
over
to
the
new
one
and
the
transition
process
finished
by
the
first
walk
finalized
event,
and
on
this
event,
the
blog
gossip
that
is
in
the
execution
chain
in
the
execution
network
stack
should
be,
must
must
stop
existing.
So
it
just
must
be
those
message:
handlers
must
be
dropped,
yep,
okay,.
C
B
C
B
C
B
Yeah
yeah,
that's
exactly
as
you
have
described,
okay,
so
yeah!
So
that's
the
transition.
It's
a
bit
tricky,
but
I
hope
this
diagram
helps
to
understand
what
is
going
on
what
is
supposed
to
go?
Okay.
So,
let's
go
briefly
through
specification:
it's
not
that
tricky
as
the
transition
process.
Yep.
Why
you
stop
persistent
perform
blocks,
just
suppose
that
so
it's
all
exposed
in
the
security
considerations,
so
you
may
go
and
check
on
the
ip
and
yeah
suppose
that
there
is
the
consensus
layer,
consensus.
B
The
part
of
software
of
client
software,
that
is
responsible
for
a
consensus
for
the
beacon
chain
is
goes
offline
before
the
transition
and
stays
offline.
Some
for
some
time
and
during
this
period
of
time,
the
terminal,
peripheral
forward
block
happens
and
transition
happens,
and
in
this
case
the
execution
client
will
not
receive
anything
from
the
consensus
side
and
will
keep
producing
proof
of
work
blocks,
even
even
yep.
B
If
those
blocks
will
be.
You
know
if,
if
the
proof-of-work
chain
will
be
kept
building
beyond
this
transition
block,
so
if
somebody
will
decide
to
keep
finding
blocks-
and
in
this
case
execution
client
will
track
this
warm
chain
which
could
lead
to
like
adversary
effects.
Adverse
effects
such
as
the
incorrect
state
of
the
client,
where
the
sinking
from
scratch
will
only
help
once
the
consensus
side
gets
back
to
gets
back
from
its
offline
or
in
the
worst
case
it
could
be
the
some
security
issues.
B
Okay,
so
the
block
structure
keeps
remains
the
same,
and
we
do
this
by
replacing
the
fields
that
are
deprecated
mostly.
Those
are
deprecated
because
of
proof-of-work
deprecation,
which
is
set
down
to
a
set
of
constants
which
are
exposed
here,
pay
attention
to
the
extra
data
that
is
going
to
be
going
to
be
deprecated,
but
probably
it's
important
for
you
just
go
in
to
this
pr
with
this
ap
and
comment
out
on
it.
If
it
is
block
validity
is
also
changed,
and
obviously
this
is
due
to
proof
of
work
deprecation.
B
So
all
these
rule
sets
that
are
related
to
refine
the
hash
and
omers
is
should
be
removed
and
it
is
replaced
with
these
proof-of-stake
and
consensus
validated
event
which
is
applied
here
also
yeah.
It
implies
that
if
the
chain
headset
or
block
finalized
events
are
sent,
are
linked
into
some
block,
then
it
it
is.
It
implies
that
this
block
also
valid
with
respect
to
the
consensus
rules,
so
it
yes,
they
should
be
treated
as
the
same.
You
know
as
the
events
with
the
same
semantics
as
the
consensus
validated
one.
B
B
We
are
removing
block
and
thomas
reward,
so
the
cip
removes
them
and
but
transaction
fee
mechan
mechanics
stays
the
same.
It's
not
affected
yep
the
fork
choice.
Rule
is
gonna,
be
alter
it
on
on
the
first
chain
had
said
event
and
yep.
It's
just
as
follows:
it's
very
straightforward.
What
is
sent
in
this?
What
block
is
referenced
by
this
event?
B
Becomes
the
head
of
the
chain
and
this
chain
becomes
the
canonical
blockchain
yep,
and
also
the
block
finalized,
will
contain
the
information
about
the
chain
headset
event
as
well,
so
just
for
to
avoid
consistency,
issues
there
is
the
potentially
these
two
events
could
be
combined
together,
but
yeah
we'll
see
we'll
think
about
it.
More
network
stack.
B
B
First,
one
is
the
affects
the
difficulty
of
code,
which
will
return
the
zero
because
of
the
constant
because
of
replacing
the
difficulty
field
with
the
constant
value,
but
the
there
is
there
is
the
idea
of
change
this
difficulty
up
code
and
exposed
the
randomness
accumulated
by
the
beacon
chain,
which
is
also
called,
which
is
also
known
as
rendao
by
this
difficulty
of
code.
But
this
change
is
going
to
be
introduced
by
another
eip
and
the
idea
is
to
to
take
this
difficulty
of
code
ea
into
effect
during
the
merge.
B
So
if
anybody
has
their
smart
contract
heavily
depends
on
the
block
hash
as
a
source
of
randomness,
without
combining
it
with
difficulty,
you
should
be
worried
about
about
it
and
yeah.
You
should
go,
and
just
you
know,
reach
us
out
and
discuss
how
to
how
to
potentially
avoid
this
kind
of
you
know
breaking
change
for
what
is
block
hash
for
this
alternative
blockage.
Semantics!
B
B
So
yep
here
is
some
references
for
you
that
has
been
used
here.
The
beacon
chain,
certification,
the
eip
and
the
word
quest
and
the
rnd
discord
for
discussion
join
it.
We're
always
welcome
to
to
discuss
the
merch
and
the
software
on
it
track.
The
progress
with
the
checklist
follow
me
on
twitter
and
that's
it.
Thank
you
so
much.
A
A
We
shared
a
reddit
post
to
collect
comments,
questions
or
any
concern
about
this
pr
3675,
and
we
have
got
some
questions
for
you
in
general,
because
the
merge
is
the
big
overhaul.
The
community
has
mixed
questions
from
different
proposals
and
features
as
well.
So
my
first
set
of
questions
is
related
to
the
topic
of
third-party
providers.
A
B
A
B
Can
you
can
see
this
around
this
section
here
and
here
is
the
execution
layer
proof
of
custody
it's
on
the
list?
It
will
not
likely
go
into
the
initial
merge
what
will
be
introduced
later,
and
it
means
that
every
validator
will
be
enforced
to
run
the
execution
client.
Aside
of
your,
we
can
change
client
software
at
some
point.
So
probably
input
will,
I
don't
know,
will
not
expose
this.
A
B
B
I
guess
it
could
be
done
in
even
a
trustless
way
when
the
service
returns,
you
a
payload
which
sends
some
fans
back,
which
has
a
transaction
that
sends
some
funds
back
to
the
coinbase
that
you
have
provided
and
supports.
It
also
could
be
the
case
like
speaking
of
this
topic.
The
coin
base
could
be
passed
along.
The
assemble
block
requests
from
the
validator
to
to
be
inserted
in
the
the
execution
payload.
C
C
B
Yeah
yeah
right,
even
though,
if
there
will
be
the
possibility
to
outsource
your
execution
duties
to
some
some
kind
of
third
party,
just
keep
in
mind
that
at
some
point
you
will
be
enforced
to
buy
this
proof
of
custody
for
execution
to
run
your
own
execution
client.
So
it's
better
to
be
done
like
earlier
than
later,.
C
Yeah
and
similarly,
the
whoever
you're
outsourcing
your
execution
client
work
to
by
default.
They
have
full
control
over
the
block,
that's
being
produced,
and
so
they
can
produce
blocks
that
a
are
just
malicious
like
are
invalid,
and
if
they
want
to
try
to
slash
you
as
an
example,
similarly,
they
could
produce
blocks
that
just
give
all
the
transaction
fees
to
the
block
browser.
C
So
be
very
careful
if
you
are
relying
on
third-party
execution
clients
who
you
are
trusting
to
do
that.
There's
like,
like,
I
said,
there's
no,
nothing
built
in
to
make
that
a
trustless
operation,
and
so,
if
you
do
point
at
infera
or
alchemy
or
something
you
you
can,
we
can't
stop
you.
But
it's
it's
on
you
to
that.
You're,
trusting
them
to
do
something
that
you're
on
the
hook
for
like
you're
you're,
committing
that
whatever
they
do.
I
assert
that
is
true,
and
even
if
they
do
something,
that's
not
right
or
not
good.
A
Interesting,
there's
a
one,
maybe
the
last
on
this
topic:
oh
no,
that
is
something
related
to
violent
injustice
reward.
So
will
priority
fee
going
to
the
validators
after
the
merge
be
assigned
to
whoever
was
randomly
chosen
to
produce
that
specific
block,
or
will
it
be
evenly
distributed
to
every
active
validator
on
the
network.
B
A
B
That's
a
very
tricky
question.
I
don't
think
you
know
we
what
what
I
am
doing,
my
what
I
yeah.
What
do
I
expect
yeah?
Obviously
there
will
be
transaction
tips
right
and
mv
opportunities
that
will
increase
the
quality
rewards,
but
yeah
it
depends
on
your
setup,
but
anyway
it
will
be
increased
depends
on
the
setup.
I
will
not
I'm
not
going
to
into
the
weeds
of
like
using
the
staking
pools
or
solo
or
whatever,
like
you
know,
or
in
a
solo
mode,
so.
C
C
So
anyone
who
wants
to
get
an
idea
you,
the
places
of
research,
is
you
can
just
go
look
at
what
your
validator
is
making
right
now
or
what
validators
are
making
right
now
and
it
will
be
similar
like
as
more
validators.
Come
online
rewards
go
down.
So
keep
that
in
mind.
I
think
the
ethereum
two
launch
pad
has
a
nice
chart
that
shows
you
know
what
long-term
yields
are
like
that's
the
the
staking
portion
and
then
for
the
block
rewards
portion.
C
C
A
A
B
Yeah
the
recommended
way
after
this
mentioned
difficulty
of
code
ap
will
be
like
accepted
and
comes
into
effect,
which
will
happen
at
the
point
of
merge,
which
we
expect
to
happen
at
the
point
of
merge.
This
is
just
going
to
be
to
use
the
difficulty
of
code
for
randomness,
which
this
randomness
accumulated
by
the
beacon
chain
is
a
much
more
secure
source
of
randomness
that
they
block
hash
the
difficulty
or
all
of
them,
combined
together.
A
C
Just
for
messaging,
so
people
don't
get
confused.
The
op
code
currently
called
difficulty.
I
forget
what
number
it
is
most
likely,
we'll
colloquially,
rename
that
to
randow
or
something
to
make
it
more
clear.
This
is
a
source
of
randomness
and
not
actual
difficulty.
So,
if
you
see
in
the
future
references
to
like
a
randow
or
random
op
code
again,
the
number
will
be
the
thing
that
is
currently
the
difficulty
opcode
today.
B
A
Right
so
there
is
this
one
last
question
I
I
know
I
mean
this,
maybe
a
question
from
mindless
community
to
decide
on,
but
people
are
curious
to
know
what
guests
think
on
that.
What
do
you
think
miners
will
do
after
consensus
is
changed?
Do
you
think
they
will
keep
minding
the
old
pow
chain,
move
their
mining
power
to
the
blockchain
or
calculate
and
join
the
e2
as
validators.
B
In
my
opinion
that
all
these
may
happen
at
the
same
time,
so
I
don't-
I
don't,
have
any
preferences
and
I
know
I'm
not
thinking
about
it
once
the
emerge
happens.
The
ethereum
ad
will
be
not
independent,
dependent
on
the
proof
work
anymore,
and
it
will
be.
It
will
be
really
indifferent
to
what
happens
with
the
proof
of
with
this
proof
of
work,
the
proof-of-work
continuations
of
this
prefork
chain
that
it's
been
relied
upon.
So
if,
if
somebody
keeps
mining
it,
okay,
that's
okay!
A
All
right,
ethereum,
with
over
a
260
billion
usd
market
cap,
is
the
largest
blockchain
to
undergo
such
a
huge
change,
and
this
is
not
only
affecting
the
black
structure
block
processing
for
choice,
rule
but
also
the
model
of
the
network
security
provider.
I
suppose
there
is
still
room
for
value
change,
another
section,
as
some
of
them
are
still
tbd.
A
B
Thanks
for
again
for
inviting
me
that
was
great
to
to
be
here
and
present
this
huge
thing,
which
has
a
lot
of
efforts
behind
it
by
different
contributors,
certain
from
researchers
and
developers
for
like
a
decent
amount
of
time,
and
I'm
very
excited
to
see
how
this
is
progressing
and
how
this
is
starting
to
gain
more
focus
and
we'll
see
what
will
happen
in
the
next
few
months.
But
I
guess
it
will
be
a
really
exciting
journey
too.
A
All
right
on
this
note
for
all
our
youtube
viewers,
thanks
for
watching,
if
you
like
it,
please
share
it
with
people
of
similar
interest.
We
have
added
guest
twitter
handle
and
the
presentation
links
along
with
all
the
references
resources
in
the
description
section.
So,
as
usual,
we'll
be
looking
forward
to
your
feedback.
You
may
leave
a
comment.
I
read
them
all.
Reach
me
on
twitter,
on
the
cathode
is
team
honesty
card.